[Thematopic] Rechten toewijzen

[sanfranjake]

Thema topic: Rechten toewijzen

Introductie

Welkom in het tweede thema topic! Vorige maand zijn we gestart met een nieuw item in de Softe Goederen fora om ook de andere aspecten van een ICT omgeving te belichten. Het eerste topic ging over monitoring, en kan je hier teruglezen.

Deze maand hebben we gekozen voor het thema "Rechten toewijzen". De gemiddelde omgeving wordt alleen maar complexer, en toch willen we graag voorkomen dat onbevoegden toegang krijgen tot vertrouwelijke informatie. Daarom willen we graag jouw ervaringen weten. Heb je bijvoorbeeld een procedure gemaakt voor het aanvragen van wijzigingen, wijs je rechten met de hand toe of heb je dit geautomatiseerd?

Thema: Rechten toewijzen

Iedereen die met computersystemen werkt is wel eens geconfronteerd met een "toegang geweigerd". Vaak zijn binnen bedrijven complexe rechtenstructuren aangebracht om gebruikers toegang te verschaffen tot verschillende netwerkbronnen. De manieren om deze rechten toe te wijzen grenzen aan het oneindige. De complexiteit van rechtentoewijzing maakt het voor de gemiddelde systeembeheerder een uitdaging om zijn netwerk te beveiligen tegen alle mogelijke gevaren.

Er zijn vele manieren om rechten toe te wijzen voor het gebruik van bronnen op een netwerk. Netwerkmappen, e-mailaccounts, werkstations, applicaties, faxen, printers en discussiefora zijn dikwijls voorzien van uitgebreide lijsten waarin gebruikers toegang wordt verschaft tot informatie.

Gebruik jij een centraal systeem zoals Samba, Active Directory of eDirectory? Gebruik je groepen, of combinaties van groepen om machtigingen te beheren, of wijs je aan elke gebruiker met de hand overal rechten toe? Heb je groepen/verzamelingen gebruikers aan de hand van de bedrijfsstructuur samengesteld, of op basis van een ander rollensysteem? Gebruik je de vaak bij opleidingen geleerde onderverdeling in meerdere groepen, bijvoorbeeld bij Active Directory Users-Global Groups-Domain Local Groups-Resources?

Hanteer je op elk platform dezelfde methode? Moeten gebruikers voor elke bron apart inloggen? Hoe heb je je Mac's, Linux machines, Windows pc's en Cisco routers aan elkaar gekoppeld? Log je overal met dezelfde accounts in? Of heb je er juist bewust voor gekozen om authenticatie op meerdere niveau's plaats te laten vinden?

Heb je een procedure waarmee gebruikers toegangen kunnen aanvragen, of misschien het gehele toewijzen van rechten geautomatiseerd? En hoe heb je binnen de IT afdeling zelf de rechten verdeeld? Mag iedereen overal bij, of heb je een apart profiel voor de helpdeskmedewerkers, consultants, beheerders? Hoe zijn bij jou de rechtenstructuren tot stand gekomen, waren bijvoorbeeld gebruikers, informatie, resources of iets heel anders het uitgangspunt? Hoe regel je toegang tot bronnen wanneer gebruikers zich buiten het beschermde netwerk bevinden? Vindt er ook een vorm van controle plaats op alle toegewezen rechten, een soort logboek?

Voorbeeld reactie

Een reactie zou bijvoorbeeld kunnen bestaan uit het volgende - het staat je volledig vrij dit over te nemen, of volledig te negeren:

Welke technisch systemen voor accounts gebruik je? Gebruik je een centraal systeem?:
Wat heb je waar aan gekoppeld:
Gebruik je dit systeem enkel voor een platform of juist multi-platform?
Wie is verantwoordelijk voor de juistheid / integriteit van dit systeem?
Als een collega nieuw bij je begint - wanneer maak je die dan aan? Op wie zijn vraag?
Werk je met groepen? Hoeveel groepen heb je, en wat stellen die groepen zoal voor?
Wie bepaalt er wie in welke groep gezet wordt? Wie doet dat bij jullie? Is daar een procedure voor
Heeft iedereen toegang tot alle documenten of is dit erg afgemeten per afdeling, project of klantengroep? Heeft een gebruiker een prive gedeelte op de server? En zijn mailbox, is die prive? Hoe ga je om met mensen die toegang willen heben tot dit prive gedeelte?
Is iedereen bij jullie administrator of zijn de rechten juist heel erg afgemeten?

Het volgende thema topic...

Zal over backups gaan. Een erg belangrijk item in elke it infrastructuur. Veel digitale bedrijfsinformatie moet volgens de wet vijf jaar bewaard worden.

Heb jij een uitgedacht backupprotocol? Welk medium gebruik je, welke software? Wat wordt er geback-upt? Wat backup je elke dag, en wat backup je juist niet of misschien eens per half jaar?

Mocht je suggesties hebben voor een volgend thema-topic, laat het ons dan weten op softegoederen @ tweakers.net.

[ Voor 13% gewijzigd door elevator op 21-01-2008 20:27 ]

[tim427]

Nou thuis heb ik gewoon een Windows Server 2008 bak met AcitveDirectory.

Alle clients zijn Windows Vista.

Iedereen zo min mogelijk rechten gegeven i.v.m. veiligheid. Zelf werk ik ook met een "minder" account (maar wel ietsjes meer ).

Programma's instaleren moet gedaan worden als Administrator.

Printers worden ook zo gedeeld, shares ook. Nu kan iedereen op iedere PC inloggen.

Ik heb ook niet alleen policies voor de users gemaakt, ik heb ook policies voor de PC's. Want een simpele bak hoeft geen MediaCenter te kunnen starten .

[zomertje]

Korte samenvatting van het interne netwerk op het werk:
In Unix zorgen we er vooral voor dat mensen geen shell kunnen krijgen. Dan kun je ze al aardig beperken in wat ze mogen en wat niet. Rechtstreeks via een menu in de applicatie of acties via de achterliggende scripts. Verder hebben we een Samba dumpschijf en schermen we vooral directory's af via groepen zowel in Windows als in Unix.Essentiele dingen zijn alleen lezen of staan helemaal dicht. Local adminrechten worden alleen aan een selecte groep (sommige devvers bijvoorbeeld) uitgedeeld.

De ASP omgeving die we voor klanten hebben is wat stricter:
Klanten mogen niet zomaar elkaars zaken zien/lezen dus hier is alles redelijk dichtgetimmerd via Citrix en drivemappings. In een verkenner vinden zij dus alleen hun eigen twee drives en verder niets. In Citrix kun je per programma toewijzen wie dit mag starten en dit dus in zijn citrix opstartscherm krijgt.

[SirDarkAngel]

Rustig hier, maar bij deze:

Ik doe op het moment zelf systeembeheer voor veel kleine klanten. Doordat er vaak geen expertise is als ik er niet ben geef ik vaak op lokale systemen lokale administrator rechten.

Op deze pc's probeer ik zoveel mogelijk links te maken naar een file server toe. Denk hieraan aan Roaming profiles en een Home drives. Deze 2 zijn alleen voor de gebruiker zelf toegankelijk en voor de administrator.

Vervolgens wordt er een afdelingsschijf gemaakt met submappen. Hierop worden rechten gegeven met behulp van security groups in AD. Ik tracht voor elke map een aparte groep te maken zodat alles overzichtelijk blijft voor mezelf en een eventuele opvolgers.

Gebruikers wijs ik vervolgens de weg naar bovenstaande plaatsen en leg uit dat de bestanden in de back-up worden mee genomen als ze de bestanden hier ook plaatsen. Dit is een reden waardoor vele gebruikers de juiste plaatsen gaan opzoeken.

Is er eens een client gesloopt door een fout van de gebruiker of andere factor is het een image plaatsen en doorgaan.

Dit soort procedures werken alleen in kleine omgevingen en met vaste werkplekken (mening). Heb een soortgelijke situatie gezien bij Capgemini (groot bedrijf dus) en hier waren er regelmatig problemen. Veel gebruikers maakte de pc onwerkbaar en aangezien de gebruikers vaak buiten zaten was de data hierdoor zoek. Ook zijn er bij grotere bedrijven altijd mensen aanwezig een keer een programma te installeren op lokale pc's waardoor lokale administrator een overbodige luxe is voor de gebruikers.

[LauPro]

Een beetje na aanleiding van dit topic wil ik hier even verderbomen.

De insteek van dit topic is mijns inziens verkeerd. We bespreken hier eigenlijk direct al de technische implementatie zonder dat er eerst goed wordt nagedacht over de indeling van de informatie op zichzelf.

Allereerst moet er goed worden bekeken wie welke taken heeft binnen het totale bedrijfsproces. Dit klinkt een beetje wollig maar het komt er op neer dat er klink ern klaar geïnventariseerd wordt wie wat precies mag doen. Het lastige is vaak dat sommige applicaties met losse databestanden werken terwijl andere weer alles in een database stoppen. En dat sommige applicaties helemaal geen rechtenstructuur kennen, afschermen op bestandsniveau zorgt dan voor de grootste problemen.

Dus voordat je jezelf op een onhaalbare utopische serveromgeving stort is het verstandig om gewoon grenzen te stellen. Wat gaat er worden beveiligd? Wil je bijvoorbeeld voorkomen dat medewerkers perongelijk een databestand op internet zetten? Een goede filterende proxy kan een hoop doen, tegelijkertijd misschien ook een hoop tijd kosten en frustraties opleveren.

Uiteindelijk moet er bij de meeste bedrijven gewoon geld worden verdiend en zeer strakke beveiligingsprotocollen ondersteunen daar niet bij. Het zorgt voor veel drempels en vaak dat er onderling alsnog veel bestanden over en weer gaan (of nog erger: wachtwoorden). Zeker in kleinere bedrijven waar gebruikers vaak meerdere taken hebben gebeurt dit vaak. Ik druf het nog wel sterker te stellen dat bij zeker 90% bij de bedrijven tot 10 medewerkers iedereen (op de schoonmaker na) bij alle data kan.

En dat is ook wel logisch, want het schept vaak ook een beeld van wantrouwen. Toch moeten bedrijven vaak door schade en schande wijs worden op dit gebied. Eigenlijk is het concept van Starwars nog wel het beste. Geef mensen een rangorde en afhankelijk van hun positie kunnen ze bij bepaalde informatie. Helaas is dit in de praktijk niet te doen, dit aangezien je geen controle hebt over het personeel. Er is altijd een risico dat iemand wat uitlekt, om wat voor een reden dan ook. Dit kan heel simpel een bankmedewerker zijn die even kijkt wat zijn buurman op de rekening heeft staan en waar hij die nieuwe auto van heeft gekocht tot een beveiligingsmedewerker die een filmpje van een stelletje in een gesloten fietsenstalling publiceerd.

Even terug naar het topic, hoe te beveiligen. Kernpunt hierbij is in mijn optiek dat er een duidelijke scheiding wordt gemaakt tussen programmatuur, data en werkbestanden. Programmatuur zijn de uitvoerbare bestanden van de applicaties zelf, data bestaat uit bestanden die bijvoorbeeld in een database opgeslagen zijn. De gebruiker heeft dan niet zelf toegang tot deze data maar enkel via de applicatie. Werkbestanden zijn bij wijze van spreken de Word en Excelbestanden.

Ik moet nu echt gaan pitten misschien morgen wat meer.

[alt-92]

LauPro schreef op dinsdag 15 januari 2008 @ 03:56:
De insteek van dit topic is mijns inziens verkeerd. We bespreken hier eigenlijk direct al de technische implementatie zonder dat er eerst goed wordt nagedacht over de indeling van de informatie op zichzelf.

De insteek is niet verkeerd hoor Er is gewoon tot nu toe niemand geweest die dat gepost heeft

Allereerst moet er goed worden bekeken wie welke taken heeft binnen het totale bedrijfsproces. Dit klinkt een beetje wollig maar het komt er op neer dat er klink ern klaar geïnventariseerd wordt wie wat precies mag doen.

Een variant die onder andere RoleBased Access Control wordt genoemd

Zoals je al aangeeft: in een kleinere onderneming <25 personen zit daar al gauw overlap in.
In grotere ondernemingen is dat verschil vaak duidelijker aan te geven.

[LauPro]

alt-92 schreef op dinsdag 15 januari 2008 @ 22:15:
De insteek is niet verkeerd hoor Er is gewoon tot nu toe niemand geweest die dat gepost heeft

Een beetje plan van aanpak vind ik niet verkeerd in ieder geval. Je stort mensen nu meteen in het diepe om direct al in GPO's te denken of op objectniveau.

Een variant die onder andere RoleBased Access Control wordt genoemd

RBAC is een beetje overgewaardeerd als je het mij vraagt, de support in Windows Server is in ieder geval een beetje matig en op veel Unix platforms ook. In DBMS'en is het meestal beter geregeld alswel op applicatieniveau in diverse ERM/CRM-pakketten.

Maar dat maakt het beheer er niet makkelijker op als je in verschillende systemen diverse beveligingsmodellen moet voeren. We kennen allemaal wel die kleine maatwerkpakketjes met irritante rechtensysteempjes e.d..

LDAP is natuurlijk eigenlijk ideaal maar wordt meestal alleen voor authorisatie gebruikt. Plus vaak hebben printers e.d. de meest belabberde support die je je kan bedenken.

Zoals je al aangeeft: in een kleinere onderneming <25 personen zit daar al gauw overlap in.
In grotere ondernemingen is dat verschil vaak duidelijker aan te geven.

Ook in grote bedrijven gaat het vaak mis. Vaak zijn de verantwoordelijkheden op afdelingsniveau en heeft met door middel van de gebruikelijke sociale controle alles afgedekt. Net zoals je niet zomaar in de bureaula van de directeur gaat zitten loeren.

Ook heb je al snel te maken met grote grijze gebieden in je beveiliging. Het is gebruikelijk om een of meerdere shares te hebben met daarop diverse bestanden. Meestal heeft men op shareniveau gewoon wat rechten ingesteld en misschien wat submappen, wat daar allemaal onder hangt weet vaak niemand totdat de disk vol zit en moet worden opgeschoond.

Om even een voorbeeld te nemen als bij planet. De beveiliging moet over de gehele linie gelden. Wat mij betreft kan poort 21 op dergelijke servers sowieso gewoon keihard dichtgezet worden (op een publieke FTP-server na dan). Of in ieder geval dat er binnen het bedrijfsnetwerk zeer beveiligd met het grote boze internet kan worden gecommuniceerd.

Sowieso worden bedrijfsnetwerken nog steeds veels te makkelijk met het internet verbonden. De standaard routerfunctie in modems is daar debet aan maar ook de veel te lakse houding van veel managers.

[alt-92]

LauPro schreef op dinsdag 15 januari 2008 @ 23:38:
Een beetje plan van aanpak vind ik niet verkeerd in ieder geval. Je stort mensen nu meteen in het diepe om direct al in GPO's te denken of op objectniveau.

Het is een discussie topic, geen HOWTO
Er staat dan ook geen vaste aanpak in, en ook het gedeelte wat je aanhaalt (het non-technische, procedurele deel) staat genoemd in de openingspost.

Gelukkig lever je met je post gelijk een nuttige bijdrage wat dat betreft

RBAC is een beetje overgewaardeerd als je het mij vraagt, de support in Windows Server is in ieder geval een beetje matig en op veel Unix platforms ook.

Wellicht komt dat ook omdat er niet één vaste manier van implementeren is.
Wij gebruiken bijvoorbeeld AD Global groups met nesting om verschillende competenties van een rol te bundelen, en daarmee kom je héél ver.
Het ontwerp van je model is wat dat betreft gewoon heel belangrijk voor het welslagen van je implementatie.

In DBMS'en is het meestal beter geregeld alswel op applicatieniveau in diverse ERM/CRM-pakketten.

Maar dat maakt het beheer er niet makkelijker op als je in verschillende systemen diverse beveligingsmodellen moet voeren. We kennen allemaal wel die kleine maatwerkpakketjes met irritante rechtensysteempjes e.d..

Ligt dat aan je beveiligingsmodel zelf, of aan dat kleine maatwerkpakketje met irritante rechtensysteem?

Ook in grote bedrijven gaat het vaak mis. Vaak zijn de verantwoordelijkheden op afdelingsniveau en heeft met door middel van de gebruikelijke sociale controle alles afgedekt. Net zoals je niet zomaar in de bureaula van de directeur gaat zitten loeren.

Ik werk in een groot bedrijf, en daar is toch echt een behoorlijk strakke structuur geimplementeerd.
Daar speelt sociale controle weliswaar een rol (onder de noemer Compliance) maar de daadwerkelijke implementatie gebeurt d.m.v. een RBAC principe.
Waar je eerder problemen gaat ondervinden is dat verschillende bedrijfsonderdelen ieder hun eigen 'kingdom' willen regeren en dat daardoor de implementatie niet éénduidig verloopt.

De afdelingsleider of 2e level manager is degene die permissies kan aanvragen met goedkeuring van de eigenaar van de 'rol' - waarbij de rol een bundeling kan zijn van de benodigde File Access groepen, applicatiegroepen en competenties waar de medewerker van de afdeling uit hoofde van zijn werkzaamheden op afdeling X in die en die functie gebruik van moet kunnen maken.

[ Voor 7% gewijzigd door alt-92 op 16-01-2008 00:04 ]

[LauPro]

alt-92 schreef op woensdag 16 januari 2008 @ 00:00:
Het is een discussie topic, geen HOWTO
Er staat dan ook geen vaste aanpak in, en ook het gedeelte wat je aanhaalt (het non-technische, procedurele deel) staat genoemd in de openingspost.

Natuurlijk zit er wat overlap in, maar het opsommen van een aantal mogelijkheden behandelt de zaak niet imo.

Gelukkig lever je met je post gelijk een nuttige bijdrage wat dat betreft

Gelukkig

Wellicht komt dat ook omdat er niet één vaste manier van implementeren is.
Wij gebruiken bijvoorbeeld AD Global groups met nesting om verschillende competenties van een rol te bundelen, en daarmee kom je héél ver.

Heel ver, maar op een gegeven moment zul je toch de workarounds in moeten duiken omdat er altijd wel weer een applicatie is die er net ff iets anders over denkt. Theoretisch gezien zou je gewoon alle applicaties op een readonly share moeten kunnen zetten, totdat je er net een tegen komt die een tempfile in zijn program map neer wil plempen. Daar gaat dan je hele beveiligingsmodel de prullenbak in.

Het ontwerp van je model is wat dat betreft gewoon heel belangrijk voor het welslagen van je implementatie.

Dit is een beetje open deur maargoed.

Ligt dat aan je beveiligingsmodel zelf, of aan dat kleine maatwerkpakketje met irritante rechtensysteem?

Ik vind sowieso dat het verboden moet worden om op applicatieniveau user logins te maken. Dit moet gewoon eens fatsoenlijk via LDAP oid gaan gebeuren. En alstjeblieft nu eens niet van die ranzige Windows authorization koppelingen.

Ik werk in een groot bedrijf, en daar is toch echt een behoorlijk strakke structuur geimplementeerd.
Daar speelt sociale controle weliswaar een rol (onder de noemer Compliance) maar de daadwerkelijke implementatie gebeurt d.m.v. een RBAC principe.
Waar je eerder problemen gaat ondervinden is dat verschillende bedrijfsonderdelen ieder hun eigen 'kingdom' willen regeren en dat daardoor de implementatie niet éénduidig verloopt.

Natuurlijk zal elke gebruiker voor zijn rechten op willen komen. Zeker als de situatie voorheen anders was en men wordt beperkt. Er zijn diverse praktijkvoorbeelden van systeembeheerders die op een blauwe Maandag een zeer strekke GPO invoeren met een leuk bedrijfsachtergrondje op het bureaublad. Je moest eens weten hoeveel mensen je daarmee tegen de haren in kan strijken. Dit gaat dan welliswaar niet om beveiligen meer maar het uniform maken van de desktop wat de support weer ten goede komt. Discussiepunt blijft dan wat een achtergrond voor een invloed kan hebben (mits het geen balipc is oid).

De afdelingsleider of 2e level manager is degene die permissies kan aanvragen met goedkeuring van de eigenaar van de 'rol' - waarbij de rol een bundeling kan zijn van de benodigde File Access groepen, applicatiegroepen en competenties waar de medewerker van de afdeling uit hoofde van zijn werkzaamheden op afdeling X in die en die functie gebruik van moet kunnen maken.

Je praat nu al over relatief grote objecten en daar is het dan ook eenvoudig. Maar als je een user echt alleen toegang wil geven tot data en bijv. niet tot de applicaties zelf dan komt er veel meer bij kijken. Wat dat betreft is het webbased computing concept zeer interessant.

[alt-92]

LauPro schreef op woensdag 16 januari 2008 @ 01:02:
Heel ver, maar op een gegeven moment zul je toch de workarounds in moeten duiken omdat er altijd wel weer een applicatie is die er net ff iets anders over denkt. Theoretisch gezien zou je gewoon alle applicaties op een readonly share moeten kunnen zetten, totdat je er net een tegen komt die een tempfile in zijn program map neer wil plempen. Daar gaat dan je hele beveiligingsmodel de prullenbak in.

Euh.. nee, dan gaat $brakke-noncompliant-applicatie de prullenbak in.
Die voldoet dan namelijk sowieso al niet aan application design guidelines die (in dit geval) voor het Windows platform gelden.
De hele reden waarom je een beveiligingsmodel opzet ondermijn je op het moment dat je je er niet aan gaat houden met dergelijke fratsen

[Anoniem: 178962]

Sowieso is dit vanaf Windows Vista volledig afgevangen, een programma kan gerust denken dat ie in z'n eigen map aan het schrijven is, maar stiekum schrijft ie een speciale map in de gebruiker z'n home.

Op die manier kun je toch heel streng zijn qua rechten en alles dicht gooien, maar ondertussen blijven alle oude brakke applicaties werken.

Want je kunt wel hard roepen van applicatie xyz gaat het raam uit, maar als xyz ooit is aangeschaft voor veel te veel geld en er eigenlijk geen alternatief is zal dat toch niet snel gebeuren (een situatie die ik zelf ooit heb meegemaakt en ik denk vele met mij)

[LauPro]

alt-92 schreef op woensdag 16 januari 2008 @ 01:11:
Euh.. nee, dan gaat $brakke-noncompliant-applicatie de prullenbak in.
Die voldoet dan namelijk sowieso al niet aan application design guidelines die (in dit geval) voor het Windows platform gelden.
De hele reden waarom je een beveiligingsmodel opzet ondermijn je op het moment dat je je er niet aan gaat houden met dergelijke fratsen

Er zijn zoveel applicaties die niet compliant zijn waar niet zomaar een alternatief voor is.

Als multinational heb je dan een leuke positie dat je kan gaan shoppen maar voor het MKB is het vaak snel over. Zeker hele marktspecifieke software waar al jaren aan ontwikkeling in zit. Bij dit soort pakketten worden de gebruikers gegijzeld door de vendor lockin om nog maar te zwijgen over de aanschafprijs (zie TRRoads).

Tja en die truc van Vista ken ik echter ben ik persoonlijk jaren terug al van de fat clients afgestapt, Windows Server 2008 heeft van dezelfde functie dus biedt misschien een mogelijkheid. Maar ook dan is het best mogelijk dat het niet werkt of dat de fabrikant gewoon geen support geeft.

[Anoniem: 178962]

Tenzij de applicatie echt direct de hardware aan wil spreken (iets wat vanaf NT not done is, note the pun) werkt dat hoor, het wordt volledig in de onderliggende laag afgevangen, de software weet niet eens dat ie niet schrijft waar ie denkt dat ie schrijft.

Support is dus niet nodig.

Windows Server 2008 biedt dus zeker mogelijkheden, hoewel de definitie van een 'fat' en 'thin' client door de jaren heen natuurlijk nogal gewijzigd is.

Je hebt tegenwoordig 'thin' clients (qua prijs, stroomverbruik, afmetingen) die Vista aankunnen. Natuurlijk heb je ook weer thin clients krachtiger als wat we een paar jaar geleden thin clients noemde voor nog minder geld en nog kleinere afmetingen.

[LauPro]

Stel dat er toch een onderdeel breekt met Vista, die fabrikant zal dan geen support geven heel simpel. Dit kan desnoods een vage driver zijn voor een bepaalde hardwarekey oid.

Natuurlijk wijzigen de specs van 'thin' clients, maar het verschil blijft dat het renderen/weergeven op de client gebeurt en het genereren/aansturen op de server.

[Anoniem: 178962]

Wat bedoel je met die laatste zin te zeggen? Jouw definitie van het verschil tussen een thin client en een fat client?

Ik snap niet precies hoe dat relevant is (maar het is dan ook laat).

[LauPro]

In zoverre dat bij een thin client er geen security issue is en bij een fat client wel omdat daar de executables op worden uitgevoerd.

[_H_G_]

Anoniem: 178962 schreef op woensdag 16 januari 2008 @ 02:02:
Tenzij de applicatie echt direct de hardware aan wil spreken (iets wat vanaf NT not done is, note the pun) werkt dat hoor, het wordt volledig in de onderliggende laag afgevangen, de software weet niet eens dat ie niet schrijft waar ie denkt dat ie schrijft.

Support is dus niet nodig.
...

Da's wel kort door de bocht. Het pakket kan (zal) voor een MKB bedrijf veel belangrijker zijn dan het OS, ook met bijbehorende software die ook geen ondersteuning voor 2008 geeft (ouwe database meuk e.d.). Ik heb dan geen problemen om iedereen wijzigingsrechten te geven op de betreffende map t.o.v. een nieuw OS te installeren met de risico's van dien. "Sorry meneer, wij ondersteunen geen Windows Server 2008 en zijn van mening dat het daar aan ligt".

Voor grote bedrijven zal het zeker anders zijn (betere software die vaak al half maatwerk is of zelfs eigen software is), maar zijnde MKB zoek ik toch een balans tussen flexibiliteit en veiligheid. Zolang je de risico's kent en afdekt, wat is dan het probleem om de veiligheid te verminderen op bepaalde onderdelen? Omdat je zo nodig wil voldoen aan een ideaal?

[ Voor 3% gewijzigd door _H_G_ op 16-01-2008 08:42 ]

[alt-92]

Omdat (sinds we het over MKB hebben waar Windows het meest gebruikt wordt) het dan gelijk Microsoft's schuld is dat er een vulnerability is?

Overdreven, ik geef het toe. Maar /. staat vol met dat soort redenaties. Je doet 't nooit goed.

[ Voor 25% gewijzigd door alt-92 op 16-01-2008 09:53 ]

[elevator]

Enigszins laat, maar toch ook een reactie van mij

Welke technisch systemen voor accounts gebruik je? Gebruik je een centraal systeem?
Wij gebruiken voor onze Windows servers "gewoon" ActiveDirectory (één enkel domain) - ooit zijn we begonnen met een NT4 domain en dan groei je haast automatisch door naar Active Directory.

In deze AD zitten al onze gebruikers - zowel serviceaccounts, mailboxen, distributielijsten en security groepen zijn hier in vastgelegd.

Voor onze servers in het DMZ gebruiken we echter lokale gebruikers en groepen, net zoals voor onze niet-Windows servers en apparaten.

Wat heb je waar aan gekoppeld:
Alle Windows servers en clients gebruiken deze active directory.

Onze PABX haalt zijn contactgegevens uit deze zelfde active directory, net zoals ons "smoelenboek" op het intranet. Onze multi-functional printers gebruiken ook activedirectory om gemakkelijk gescande documenten door te kunnen mailen naar gebruikers.

Onze FreeBSD servers (voornamelijk internet infra servers), alle switches, printers en dergelijke gebruiken echter geen centrale authenticatie maar gebruiken juist de authenticatie van het apparaat zelf. Onze FreeBSD servers hebben dus allemaal individueel een /etc/passwd file

Verder worden alle mailsignatures automatisch gegenereerd uit de informatie uit de activedirectory en authenticeert ons ERP tegen de active directory.

Gebruik je dit systeem enkel voor een platform of juist multi-platform?
Half half, we gebruiken het wel om informatie op te halen (zie eerder voorbeeld van de multifunctional printers en intranet), maar voor authenticatie wordt het enkel door Windows gebruikt.

Wie is verantwoordelijk voor de juistheid / integriteit van dit systeem?
Als een collega nieuw bij je begint - wanneer maak je die dan aan? Op wie zijn vraag?
Ik voeg deze twee puntjes even samen.

Als een nieuwe collega begint (of het nou een stage plek is, vast contract of interim medewerker) dan is onze HRM afdeling altijd op de hoogte. Deze stuurt via een halfslachtig werkend workflow systeempje op ons intranet naar alle betrokken afdelingen (management team, facility management, ICT, etc) een melding dat er een nieuwe medewerker is begonnen.

Voor het ICT gedeelte handelt onze helpdesk medewerker de creatie van deze gebruiker vervolgens volledig af. Op vraag van HRM is HRM ook de enige partij die nieuwe gebruikers mag aanvragen - elke andere aanvraag (bijvoorbeeld direct van een manager) wordt geweigerd.

Hiernaast zijn er uiteraard de dagelijkse wijzigingen aan de personeelsinformatie - mensen veranderen van telefoonnummer of van functietitel. Omdat deze administratie allemaal al centraal gebeurt bij HRM, hebben wij in samenspraak met HRM een automatische export lopen van bepaalde publieke gegevens van de medewerkers (functie titel, manager, telefoonnummer, etc) welke we automatisch via een script dagelijks importeren in de active directory. DIt zorgt ervoor dat als iemand van functietitel wijzigt dit automatisch aangepast is in haar of zijn signature, in het smoelenboek, in de elektronische telefoonlijst, in de telefooncentrale en in alle multifunctional printers.

Een systeem wat erg goed werkt - de verantwoordelijkheid is dus grotendeels gedeelt - ICT zorgt voor het technische (groepen, etc) en HRM zorgt voor de HR gegevens.

Werk je met groepen? Hoeveel groepen heb je, en wat stellen die groepen zoal voor?
Al onze resources (fileshares, Citrix applicaties, etc) zitten in onze active directory, per resource zit hiervoor een groep.

Bijvoorbeeld - een fileshare onder de hoofdfolder 'Projects' genaamd "Tweakers.net" zal een groepsnaam hebben die zowel de hoofdfolder omvat als de sharenaam zelf. Je krijgt dan bijvoorbeeld: PRJ_Tweakers.net als groepsnaam. Hierdoor kunnen wij door middel van scripts, automatisch alle rechten setten en resetten van folders - de naam van de folder is namelijk 1 op 1 gelinked aan de naam van de rechtengroep in AD.

Daarnaast werken we met Query-Based-Distribution lists welke gebruik maken van de informatie uit AD om onze distributielijsten volledig automatisch samen te stellen - deze worden dan ook 'automatisch' up to date gehouden door de dagelijkse import van de HR gegevens.

Wie bepaalt er wie in welke groep gezet wordt? Wie doet dat bij jullie? Is daar een procedure voor
Per groep voor een fileshare, mailbox, applicatie en dergelijke is de eigenaar (meestal de aanvrager) ingevuld in de 'Managed by' tab van active directory. Op het moment dat iemand toegang wilt tot een resource zal de eigenaar van deze resource toestemming moeten geven (per mail) aan die gebruiker. Wij proberen dit zoveel mogelijk direct tussen collega en eigenaar te laten lopen (oftewel - een collega vraagt direct aan de eigenaar van die resource of hij toegang mag hebben, en die eigenaar mailed ICT zijn of haar OK hiervoor), maar in de praktijk gebeurt het nog erg veel dat ICT hier een doorgeefluik speelt.

In de toekomst willen we dit automatiseren in twee stappen - eerst willen we zorgen dat het aanvragen van toegang automatisch kan (via een elektronisch formulier) waarna de toegang automatisch gevraagd wordt bij de eigenaar. Een tweede stap zal zijn dat we dit automatisch in het systeem willen verwerken, maar dat is nog erg ver weg.

Heeft iedereen toegang tot alle documenten of is dit erg afgemeten per afdeling, project of klantengroep? Heeft een gebruiker een prive gedeelte op de server? En zijn mailbox, is die prive? Hoe ga je om met mensen die toegang willen heben tot dit prive gedeelte?
Collegas krijgen op het moment dat ze in dienst treden toegang tot hun afdelings schijf en tot hun homefolders. Beide zijn - net zoals alle andere resources - enkel toegankelijk voor de mensen welke daar toe per se toegang toe moeten hebben.

Een collega hun homefolders is enkel maar toegankelijk voor deze gebruiker zelf, zelfs de manager heeft hier geen toegang toe, ditzelfde geld voor de mailbox.

Op het moment dat iemand per se toegang wilt hebben tot een homefolder (wat erg sporadisch voorkomt), moet dit goedgekeurd worden door de HR directeur.

Is iedereen bij jullie administrator of zijn de rechten juist heel erg afgemeten?
De gebruikers hebben beperkte rechten op hun systeem - zelfs power user rechten zijn voor geen enkele gebruiker uitgedeeld.

[elevator]

En thema topic af

[Anoniem: 199042]

Wij gebruiken de laatste tijd meer en meer MOSS 2007.
Heel handig eigenlijk. Je zet de teamsite op en geeft een verantwoordelijke administratorrechten en laat deze persoon dan zelf mensen toevoegen naargelang behoefte. Dit scheelt in werkuren want op de fileserver zelf hebben ze een sysadmin ( mij ) nodig.