Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Rechtenstructuur als levend wezen

 

fijnstof griep virus

Bij veel organisaties is door de jaren heen de nodige vervuiling opgetreden in de rechtenstructuur van het filesysteem. Dit kan een technische vervuiling zijn als gevolg van bijvoorbeeld wijziging van gebruikte server (van Novell naar NT4 naar Windows 2003 en vervolgens Windows 2008, et cetera). Dit kan ook het gevolg zijn van organisatorische veranderingen, zoals het centraliseren van ict-diensten en samenvoegen van afdelingen. Wat is de impact van deze vervuiling op de organisatie?

Vrijwel iedere organisatie begint om de zoveel jaar met een schone lei en dan ziet de wereld van mappen en rechten er gestructureerd uit. Na verloop van tijd verandert de samenstelling van de organisatie en de samenstelling van de gebruikte data. Een structuur van mappen en rechten beweegt helaas niet zo flexibel mee met de organisatie. En zo ontstaat geleidelijk een structuur en indeling van rechten die niet meer goed overeenkomt met de behoeften van de organisatie.

Instroom, doorstroom en uitstroom

De groeiende afwijking die ontstaat wordt groter omdat vervuiling mee gekopieerd wordt met iedere mutatie in het personeelsbestand. Instroom, doorstroom en in mindere mate uitstroom van personeel gaat gepaard met het uitdelen van rechten op een structuur die uit de pas gaat lopen met de organisatie. Wanneer een gestandaardiseerd en genormaliseerd proces voor het verwerken van deze mutaties ontbreekt, dan kunnen problemen in de rechtenstructuur en security-incidenten eenvoudig ontstaan. Een praktijkvoorbeeld:

Bij het toekennen van autorisaties voor een nieuwe arts in een ziekenhuis wordt een kopie gemaakt van een collega in een soortgelijke functie. Het risico hiervan is dat de nieuwe arts zo autorisaties krijgt die hij helemaal niet nodig heeft. De voorbeeldpersoon had bijvoorbeeld extra rechten om bestanden in een projectmap te kunnen bewerken. Er is ook een gevaar dat de voorbeeldgebruiker lid is van autorisaties (groepen) die op hun beurt ook weer lid zijn van groepen die vervolgens rechten uitdelen. Zo is de impact bijna niet te overzien.

In de praktijk wordt er weinig aandacht besteed aan het ontnemen van autorisaties wanneer een kopie wordt gemaakt van een andere medewerker. Het is immers van groter belang dat de nieuwe medewerker direct zijn/haar werk kan doen en in eerste instantie niet wat er mogelijk teveel gedaan kan worden. Daarnaast is de it-afdeling niet altijd op de hoogte van welke toegang tot gedeelde data en projectmappen exact nodig is. De nieuwe arts krijgt zo ongewenst en ongezien te veel rechten op mappen in het filesysteem en heeft toegang tot strikt persoonlijke patiëntgegevens.

Ook bij doorstroom van personeel, bijvoorbeeld een arts-assistent wordt arts in het ziekenhuis, gaat het vaak mis, omdat extra rechten worden toegekend die nodig zijn in de nieuwe functie en ‘oude’ rechten niet worden afgenomen.

Bij uitstroom van medewerkers moeten de bijbehorende user account tijdig worden vergrendeld zodat de toegang tot de bestanden en mappen ook direct wordt stopgezet. De situatie die dan ontstaat is dat het user account nog wel toegang heeft tot de bestanden en mappen, echter het user account kan niet meer voor de toegang gebruikt worden. In het geval van een (tijdelijke) ontgrendeling van het user account is alle toegang direct weer actief. Bij uitstroom is het daarom goed om over alternatieven na te denken, zoals het overzetten van de rechten van de medewerker naar de leidinggevende.

Compliance en audits

Organisaties die niet kunnen garanderen dat zij hun rechtenstructuur op orde hebben, lopen het risico dat zij niet compliant zijn met interne en/of externe wet- en regelgeving. Een opsomming van meest voorkomende compliancy-issues die gaan spelen wanneer de rechtenstructuur vervuild is:

•             Informatiebeveiliging: Het komen tot een adequate informatiebeveiliging vereist een goede en accurate controle op de personen die toegang hebben tot vertrouwelijke informatie, zoals patiëntgegevens. Bij vervuiling in de rechtenstructuur kan adequate informatiebeveiliging niet worden gegarandeerd.

•             Telefonie en internettoegang: Sommige organisaties hanteren strikt beleid over wie internettoegang mag krijgen. Internettoegang wordt dan gezien als een extra autorisatie, omdat het kan leiden tot hoge belasting van de bandbreedte en tot improductiviteit bij medewerkers. Wanneer rechten worden gekopieerd kunnen dit soort extra autorisaties worden mee gekopieerd.

•             Downloaden: Veel organisaties hebben een strikt beleid omtrent het downloaden en installeren van software op het eigen werkstation. Veelal geldt dat medewerkers na initiële installatie van hun pc geen andere software mogen installeren. Dit om hardnekkige virussen te voorkomen. Wanneer rechten gekopieerd worden van met name oudere medewerker in een soortgelijke functie, gaat het regelmatig mis. Medewerkers die al meer dan tien jaar in dienst zijn, hebben zich vaak wel het recht verworven om software te downloaden.

Vervuiling voorkomen

De map ‘rechtenstructuur’ is een levend wezen. Het verandert van dag tot dag en er zit veel menselijke interactie in. Het is daarom onrealistisch om te denken dat vervuiling in de rechtenstructuur volledig voorkomen kan worden. Waar menselijke interactie is, worden immers fouten gemaakt. Het is wel mogelijk om zo veel mogelijke menselijke handelingen te automatiseren en de standaardiseren.

Zo is het mogelijk om beheertaken, zoals create, delete user, reset wachtwoord, et cetera, te automatiseren met identity en access management-software. Met het inrichten van een identity management (idm)-oplossing kan het inrichten van toegangsrechten goed en secuur ingericht worden middels een automatische ontmantelingsprocedure of aanpassing van de toegangsrechten bij uitdiensttreding of functiewijziging. De idm-oplossing zorgt voor een automatische koppeling tussen de contractgegevens van medewerkers in het personeelssysteem en de Active Directory. Voor de niet-loondienstmedewerkers (externe partij, uitzendkrachten, maatschappen, et cetera) kunnen zaken ingeregeld worden als beperkte levensduur van het gebruikersaccount.

Door dit te combineren met role based access control (rbac) wordt naast userbeheer ook autorisatiebeheer geautomatiseerd. Volgens de rbac-methode worden autorisaties niet op individuele basis toegekend, maar op basis van rollen die zijn opgebouwd uit afdeling, functie, locatie en kostenplaats van een medewerker. Op basis van de rol die iemand vervult in de organisatie kan bij indiensttreding een account worden aangemaakt, waarmee hij/zij toegang krijgt tot exact de juiste applicaties die hij of zij nodig heeft voor het uitoefenen van zijn werkzaamheden. De leidinggevende hoeft geen aanvullende actie ondernemen zoals extra rechten toewijzen. Op het moment dat een rol van een persoon wijzigt, is de mutatie in het personeelssysteem de trigger om ook de rechten aan te passen aan de nieuwe rol en de voormalige rechten op te heffen.

Arnout van der Vorst is identity management architect bij Tools4ever

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/5114666). © Jaarbeurs IT Media.

6,5


Lees meer over


 

Reacties

@Arnout
Goed dat je aandacht vraagt voor wat ik zelf de 'role lifecycle' zou willen noemen en waar nog veel mis gaat bij menige organisatie. Over het algemeen krijgt een eenmaal opgevoerde gebruiker namelijk steeds meer rechten omdat structuur inderdaad nog als een levend wezen is. Even voor de duidelijkheid, de structuur moet naar mijn opinie dus juist niet evolueren maar het proces omdat we naast RBAC ondertussen steeds meer naar ABAC gaan. Tenslotte komen gebruikers steeds vaker met eigen middelen en is het misschien slim om deze eerst te autoriseren om zodoende te voorkomen dat de gehele rechtenstructuur omzeilt wordt.

@ Arnout,

Leuk stuk en een zeer actueel en herkenbaar onderwerp. Waar voor dank!

@ Ewout,

Ik sluit me volledig bij je aan. De rol van een optimaal proces is ook hier cruciaal.

Tja, als je voor elk project een rol aan gaat maken en er honderden rollen ontstaan ben je weer ver van huis.

Verder wat Ewout zegt.

Wel een leuk artikel om weer eens na te gaan hoe "wij" het intern doen. Hoe zou een life-cycle er voor een rol uitzien? En hoe ingewikkeld/duur is het om een rol omzeep te helpen?

Zo herkenbaar.

Ik heb ooit gewerkt bij een organisatie die, afhankelijk van de vraag, vestigingen opende en sloot. De vestigingen konden groeien en krimpen met corresponderende veranderingen in de personele samenstelling.
Ieder personeelslid kreeg bevoegdheden, gerelateerd aan zijn functie. So far so good.

Bij een functiewijziging kreeg de functionaris de rechten die bij deze nieuwe functie hoorden; deze waren beschreven in een profiel. Voor het gemak behield hij zijn oude profiel en had er nu twee. Dat konden er drie of vier worden.
De voortdurende groei en krimp leidden tot frequente reorganisaties. Bij elke reorganisatie werden nieuwe profielen bedacht en uitgereikt. Voor de zekerheid bleven de oude bestaan en hielden de mensen al hun oude profielen.

Uiteindelijk waren er meer verschillende profielen dan er personeelsleden waren. (Meer dan 1000).

Het zat de beheerders niet echt lekker. Ze hebben wel ideeën geopperd om de zaak te saneren. Ze kregen deze echter niet "verkocht" in de organisatie.

@ Henri Koppen:
Als je eenmaal een grote achterstand hebt (zoals in het voorbeeld hierboven) zul je van scratch moeten beginnen: mensen interviewen en op basis daarvan een profiel toekennen. Dat kost gemakkelijk twee manuur per interview (afspreken, praten, uitwerken). Stel dat je met drie mensen praat, dan is dat 6 manuren. Vervolgens een profiel in concept bedenken, doorpraten met een collega, goedkeuring krijgen van een chef, dan inventariseren welke personeelsleden uitsluitend dit profiel toegekend krijgen, deze wijziging aankondigen, doorvoeren en de klachten opvangen.
Ik denk dat het gemakkelijk 40 manuren kost om één categorie gebruikers / functies / rollen te saneren qua bevoegdheden. Doorlooptijd: 2-3 maanden. Hoeveel categorieën gebruikers zijn er? 10, 20, 50?

Arnout,
Een juist IAM product kan je best veel mogelijkheden en flexibiliteit bieden. Wat we al traditioneel met ACL`s doen kunnen we hiermee vervangen door RBAC met veel wendbaarheid. Met de juiste IAM oplossing kun je zelfs de vervuiling binnen je Identity Store (Microsoft AD, eDirctory etc) voorkomen. De voordelen van IAM mogelijkheden zoals RBAC kunnen we in verschillende plekken in de architectuur en diensten zien. Een voorbeeld, je kunt RBAC gebruiken voor het inrichting van je SharePoint.

Tijd geleden in een artikel op deze site "I AM in de Cloud" heb ik gezegd:

"Een eigen centrale plek voor Identity & Access Management biedt je de mogelijkheid om altijd de regie te blijven behouden over wie er toegang heeft tot wat en dit aantoonbaar te kunnen maken (audit), centralisatie van provisioning van accounts voor applicaties en bedrijfsprocessen , afdwingen/controle over sterk wachtwoordbeleid en authenticatieprotocollen en nog meer"

Dit is maar een deel van wat IAM kan doen. De kracht en mogelijkheden van IAM is helaas nog niet bekend voor veel organisaties en ict`ers. Veel mensen denken aan alleen "Single Sign On/SSO" als we het over IAM hebben. Als voorbeeld, we hebben een tijd geleden op deze site gezien hoe Marco Gianotten in zijn artikel van deze onwetendheid misbruik wilde maken om zijn product te verkopen/aan te smeren.
Hopelijk kunnen we door onze publicaties dit verschijnsel verder bekend maken.

Een IAM product kun je voor verschillende taken inzetten:
1- intern (voor o.a. zaken die jij hier benoemd hebt en nog meer),
2- extern (in een SaaS en Cloud omgeving, zie mijn artikel)
3- federatie (tussen verschillende domeinen en organisaties)

Afhankelijk van het IAM-product, de geschiktheid van je applicaties en nog wat andere zaken zal je zien welke voordelen je van IAM mag verwachten.

@Henri:
Ik vermoed dat je niet goed bekend bent met RBAC. Het kan ook zijn dat ik je vraag/reactie verkeerd begrepen heb!

@Ewout
Autoriseren van gebruikers device is ook een mogelijkheid die je van sommige IAM producten mag verwachten. Ik heb er vaak op aangedrongen om je als klant, vooraf aan een IAM traject door een IAM consultant/specialist goed te laten informeren. Met IAM kun je veel zaken realiseren als je aan een aantal randvoorwaarden voldoet!

Karel dank voor je uitleg en toelichting en voorbeeld, zo zou het inderdaad kunnen gaan.

Reza, ik ben bekend en bedreven met RBAC al gebruik ik die term niet. Met het managen van life-cycles van rollen ben ik echter niet bekend mee anders dan dat je dit in beleid opneemt, of dat je autorisatie iteraties hebt waarbij leidinggevende de rollen van hun lijnmedewerkers moeten bekrachtigen (en er dus ook verantwoordelijk voor zijn).

Rollen zijn bitchy omdat niet elke applicatie centrale rollen aankan of dat je door gescheiden entiteiten (fusie/overname) nog wel eens in de knel kan komen.

Als rollen niet meer dan een applicatie of beperkte hoeveel applicaties (en onderliggende data structuur) bevatten ben ik erg voorstander voor om een "transparantie organisatie" approach te kiezen. Hiermee kun je het aantal rollen drastisch laag houden. Dit werkt alleen prettig als je dit echt als strategie hanteert en dit ook actief uitdraagt naar iedereen die betrokken is.

Wilgroei aan rollen is een typische verborgen kosten post. Het kost geld, maar die kosten zijn moeilijk toe te wijzen of onderdeel te maken van KPI's of TCO.

Erg herkenbaar - zowel het artikel als de reacties.

De rode draad door het geheel is de combinatie van korte termijn denken en angst. Waarom?

Wel - het laten voortbestaan van oude profielen komt vrijwel zeker doordat het aanmaken van nieuwe profielen altijd “sneller” is. In ieder geval sneller dan uitzoeken wat de gevolgen zijn als de oude verwijderd zouden worden. En nog een stap daarvoor: ook sneller dan nadenken over een structuur waarbij op voorhand helder is wat er moet gebeuren als er op een later moment een nieuwe profiel structuur nodig is.

Beiden kost NU extra tijd en helpen niet om op korte termijn te kunnen “scoren”. Met als gevolg dat er niemand (?) is die inzicht heeft in de gevolgen van het verwijderen van profielen. Gaat er informatie verloren? Welke is dat dan en waar is dat opgeslagen?

Aangezien die vragen niet beantwoord kunnen worden, wordt alles bij het oude gelaten. Totdat de zaak helemaal vast loopt en de IT afdeling weer eens de zwarte piet krijgt omdat ze “niet flexibel” zijn. Terwijl diezelfde IT afdeling ook de tijd niet krijgt om op voorhand iets neer te zetten waarmee ze wel flexibel in kunnen spelen op latere veranderingen.

En zo blijven we maar ronddraaien in hetzelfde cirkeltje...

:-)

En dat, Will, noemen we Technical Debt :-) Goede samenvatting.

Als je kijkt welke taken uitgevoerd worden door een IT afdeling dan staande belangrijke EN urgente zaken bovenaan. Alles wat niet bijdraagt aan het halen van deadlines of direct iets oplevert is het slachtoffer, gedegen Kennis Management voorop. Vaak een teken van zwak leiderschap.

@Reza
No offense maar mijn ervaring met IAM consultants is dat deze toch nog te vaak vanuit het product denken dat ze verkopen in plaats van het proces. Rollen moeten niet bepaald worden door de IT-afdeling maar door de organisatie, een EDP auditor kan dit naar mijn opinie dus beter doen dan een IAM consultant.

Dank voor de reacties op het artikel, leuk om te lezen dat het onderwerp leeft. Het werken met een structuur van rollen voor toewijzing van autorisaties heb ik voor het gemak maar het label RBAC gegeven, aangezien dat een herkenbare term is. In feite doe ik zelf verreweg de meeste implementaties op de ABAC manier, waarbij een set attributen uit bijvoorbeeld HRM leidt naar de juiste set van autorisaties.

@Ewout: proces versus product is inderdaad een goed punt, je loopt snel het gevaar dat je binnen je eigen product-bubbel blijft hangen. Ik ben het met je eens dat rollen door de organisatie gedragen moeten worden. Echter vind ik wel dat er een scheiding is tussen rollen met autorisaties "tot de poort" en "achter de poort". Wie een applicatie mag benaderen en wat de persoon vervolgens in de applicatie mag zijn 2 zaken die volgens mij niet beide in de organisatie zelf beheerd kunnen worden.

@Karel: bij organisaties die in extreme mate in beweging zijn lijkt het me lastig om tot rollen/sjablonen/profielen te komen. Ik zou dan meer zien in een top 25/50 om echt de basis-autorisaties uit te delen en vervolgens een hoge mate van self-service introduceren om het overgebleven gat te vullen. Het hangt wel van de volwassenheid van de organisatie af of dit gedragen kan worden.

@Henri: wildgroei aan rollen en de bijkomende beheerslast is een bekend onderbuikgevoel. Ik geloof sterk in toepassing van self-service, ook voor het beheer van rollen. Ik zie bijvoorbeeld prima het scenario waar de business zelf rollen die lees/schrijfrechten op afdelingsmappen kunnen toewijzen aan hun eigen scope van medewerkers. De autorisaties in de rollen zijn dan opgesteld door IT, de toewijzing aan users doet de business dan zelf.

@Henri,
Toch denk ik dat je een gesprekje met een IAM consultant zou moeten hebben om wat nieuwe inzichten op het gebied van IAM en ook zaken zoals RBAC te krijgen.

@Ewout:
Ik kan me voorstellen dat je deze ervaring hebt. Er zijn genoeg ITèrs die heel sterk vanuit techniek denken en niet vanuit de behoefte van de klant. Een mooi voorbeeld was een artikel over IT Store op deze site van een tijd geleden, dat door een consultant geschreven was die smoorverliefd was op de techniek van een leverancier, hij was de behoefte van zijn klanten vergeten.

Zeer mee eens dat voor het bepalen van rollen bij de business moet zijn. Het bepalen van rollen zien we als een onderdeel van het functioneel ontwerp van een IAM traject. Een collega van mij zei eerder in zijn artikel:

"Het opstellen van het functioneel ontwerp mag geen feestje van de automatiseringsafdeling zijn. In tegendeel, de business en organisatie moeten achter dit document staan"

http://cio.nl/it-beheer/82689-van-statische-bedrijfsprocessen-naar-domino-effect





Herkenbaar artikel, en volgens mij is de context van dit artikel de basis geweest van wat we nu IAM noemen.

Het artikel positioneert de eigen toolbox, echter het grootste probleem ligt bij de moeder van alle problemen Microsoft. De SID history zou je bij migraties of grote veranderingen achter willen laten, omdat niemand de helpdesk wil opschalen met 2-300% na een migratie adviseert iedereen om de problemen uit vervlogen tijden maar mee te nemen...en daarmee wordt de continuïteit van problemen tot in den eeuwigheid gewaarborgd. Met dank aan...

Verder raad ik iedereen aan om met simpele tools te starten om indienst, doorstroom en uitdienst in te regelen op basis van een HRM systeem. Dat kom je de grootste problemen al tegen, namelijk dat er geen goede afspraken zijn, dat iedere afdeling zijn eigen afspraken wil en dat HRM systemen ook niet altijd up-to-date zijn. Als je na 12-18 maanden dit hebt getackeld, kan je eens naar andere tools gaan kijken.

Het aanschaffen van een IAM tool om allerlei zaken te gaan blokkeren is m.i. pertinent fout, je hebt je AD policies oftewel een punt van entry om beveiligingen aan te maken en niet 2 systemen. IAM is 80% organisatie en 20% tooling.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×