Veiligheid openbare schijf

Onze o-schijf is toegankelijk voor alle medewerkers. Iedereen kan dus in ieders map gaan rondneuzen, wat dus niet ideaal is.
Daarom zouden we de boomstructuur en (vooral) de gebruikersrechten graag willen aanpassen.

Wat is zo'n ideale structuur voor een openbare schijf? Per dienst? Ieder een mapje met zijn naam?

Ik had ergens ook horen waaien het dat het OCMW dit jaar al hieromtrent aanpassingen moet doen en het gemeentebestuur volgend jaar?

Alvast bedankt voor de reacties!

Bij ons is het historisch zo gegroeid dat elke dienst een eigen map heeft en de rechten op die map met een group in activedirectory gezet worden. Daarnaast hebben we één "publiek" map waar iedereen in kan (voor de uitwisseling tussen diensten), en een aparte projects-map met daaronder specifieke projecten die dienstoverschrijdend zijn en waar we opnieuw met een group in AD rechten op zetten, in sommige gevallen twee groups (een voor alleen lezen en een voor r/w).

We gebruiken ook aparte homedrives voor de diensthoofden, vooral dan bedoeld om evaluatieverslagen e.d. op te slaan.

Ondertussen zijn we stilletjesaan aan het migreren naar 1 map per departement (volgens ons organigram), met daaronder:
- per dienst een map voor de dienst (zoals vroeger dus)
- een submap voor het volledige departement
- een map voor het departementshoofd en zijn staf

Belangrijke zaken om op te letten:
- Definieer een duidelijke structuur en hou je daar ook aan
- Gebruik altijd groepen om de rechten te definiëren. Werk bij voorkeur volgens het AGLP-principe: een gebruiker (Account) is lid van een Global Group (G), de Global Group zit in een Local Group (L), en de Local Group wordt gebruikt om de rechten (Permissions) te zetten. Geef ook duidelijke namen aan je groepen, bvb: global group begint met GG, local met LG, etc.
- Werk zo weinig mogelijk met afwijkende rechten op subfolders (bvb max. 2 niveaus), anders krijg je op den duur een spaghettistructuur
- Communiceer over de gekozen structuur (laat ze desnoods vastleggen door het college/de raad of integreer ze in de e-policy)

Het klopt uiteraard dat de meeste implementaties van AGLP-structuur weinig zinvol zijn in een single-domain forest omdat de domain local group gewoon hetzelfde is als de global group en er toch geen andere domains zijn die die global group kunnen gebruiken. Het is in zo'n geval weinig zinvol van je aantal groups x2 te doen enkel voor de vorm.

AGLP wordt wél nuttig in twee situaties:
1. Op het moment dat je wél naar een multiple-domain forest gaat (bvb doordat OCMW en stad samen gaan werken, doordat je netwerk gekoppeld wordt aan een overheidsbedrijf, ...): dan heb je al de correcte structuur en mag je niet eerst al je ACLs gaan aanpassen. Dat zal misschien niet snel gebeuren, maar je weet nooit wat de politiek boven ons hoofd beslist waardoor het ineens allemaal rap moet gaan.

2. Als je je rechten baseert op "rollen" ipv op diensten. Traditioneel worden rechten per "dienst" ingesteld, en zit een gebruiker in één dienst, en heeft elke dienst een map, etc. Maar dat is eigenlijk niet de goeie manier van werken: diensten werken ook samen, en dus krijg je als je enkel "dienst"-groups hebt inderdaad situaties waarin óf de gebruiker zich aan de technologie moet aanpassen óf je moet afwijken van je rechtenstructuur (waarmee je op den duur óf weer spaghetti krijgt, óf een enorme pak documentatie krijgt waarin het weer zoeken wordt).

Als je daarentegen met role-based rights werkt dan heb je enerzijds de diensten, maar anderzijds ook bepaalde rollen (bvb MAT, CBS, project X, evaluatoren, departement, lokatie, ...) met elk hun global group. Gebruikers zijn daarbij meestal lid van verschillende groepen: een departementshoofd zit zowel in de groep van zijn dienst, in de groep van evaluatoren, in bepaalde projectgroepen, etc.

Waar global groups een bepaalde "rol" definiëren, worden de local groups gebruikt om een bepaald "toegangsrecht" te definiëren, en kun je daarmee dus je rechten zetten. Daarbij kan er een overlapping bestaan met de global groups (vooral als je rechten op een dienst-map instelt), maar kan je evenzeer een heleboel global groups in één local group steken.

Concreet voorbeeld: er wordt een nieuw evaluatiereglement gemaakt. Er wordt een projectgroep samengesteld die daarmee bezig, die bestaat uit het management team, de personeelsdienst, en een externe consultant. Men wil een map om dit project uit te werken, waar de projectgroep moet kunnen schrijven, en alle evaluatoren mogen lezen.

In dit geval heb je al een aantal global groups: MAT, personeelsdienst, evaluatoren bestaan al als 'rol', dus daar hoef je niet naar om te zien.

Je maakt een nieuwe map + 2 bijbehorende local groups (een voor read en een voor read/write), steekt de desbetreffende global groups in die groups en bent klaar. Het is daarbij zelfs geen probleem om die consultant toegang te geven: je maakt gewoon een user aan die alleen in een aparte global group zit (bvb GG_EXTERNEN_PRJEVALUATIE) en steekt die gewoon bij in de local group.

Na een tijdje blijkt dat het project ook een database nodig heeft, met dezelfde rechten als op de map. Steek je die database in SQLServer, dan kan je gewoon dezelfde local group hergebruiken om daar de nodige rechten toe te kennen en moet je dus in SQL geen 4 verschillende users aanmaken

Komt er een tweede consultant bij, of is er iemand nieuws die als rol ook evaluator heeft, dan hoef je er nooit bij stil te staan waar die overal rechten moet krijgen: van zodra die de nodige "rollen" (= global group) krijgt gaat de rest vanzelf.

Als je er bovendien in kan slagen het toekennen van "rollen" te koppelen aan het HRM-systeem (want dat is de 'authentieke bron'), dan hoef je als systeembeheerder zelfs bijna nooit meer een gebruiker toe te voegen aan een group: als de personeelsdienst hun systeem bijwerkt wordt de 'rol', en daarmee dus ook de rechten automatisch bijgewerkt.