image

Column: Zet RBAC bij het grof vuil

woensdag 27 augustus 2008, 16:55 door Redactie, 22 reacties

In de slag om compliance aan SOX en vergelijkbare 'hoge normen' stellen beveiligingsspecialisten RBAC voor als conditio sine qua non. Deze trend wint nog steeds terrein. Er zijn ook al consultants die RBAC-compliancy eisen van software zoals Active Directory of IDM, in het kader van SOX. RBAC-achtige features in allerlei software wordt ook verpakt in compliancy termen - sommige leveren 'GRC'-modules en sinds enige tijd is er zelfs 'Compliancy As A Service (CaaS). Dit is niet heel vreemd: RBAC is eind jaren tachtig bedacht om dit soort problemen op te lossen. Maar noch SOX noch PCI-DSS schrijven het voor; er wordt alleen een "adequate internal control" geëist, en vendors en consultants roepen in koor dat RBAC in allerlei subsmaken de enige manier is. Was dat maar waar. RBAC is een slecht plan en brengt je juist verder van adequate interne controls omdat het niet werkt.

Rollenexplosie
Het uitgangspunt bij RBAC is dat medewerkers die hetzelfde werk doen, dezelfde rechten en applicaties nodig hebben. RBAC wekt daarmee de schijn van efficiency en 'consolidatie', van rechtvaardigheid. Deze schoonheid trekt mensen met een ordelijke geest aan, waarvan er velen in de ICT werken. Maar wat is hetzelfde werk? Het idee dat verschillende mensen dezelfde rol hebben en dus gelijk zijn, is een misvatting. Een secretaresse heeft meestal rechten op de mailbox van de baas. Een programmeur heeft toegang tot de source code repository. Maar welke baas? Welke repository? Sommige bazen hebben meerdere secretaresses of delen secretaresses. En programmeurs hebben de hebbelijkheid niet altijd aan alle projecten te werken.

Medewerkers hebben altijd meer dan één rol. Sommige medewerkers hebben sóms maar één rol. Zelfs in de spreekwoordelijke koekjesfabriek hebben mensen meerdere petten - denk aan lijn en projectrollen, interimtaken en allerlei vormen van samenwerking en taakwaarneming. Bovendien zijn er ook autorisaties nodig voor eenmalige taken, zoals toegang tot een dataset voor het maken van jaarrekeningen of root toegang tot een systeem om een storing op te lossen.

Ieder RBAC project stuit dan ook op het feit dat er meer rollen dan gebruikers zijn. En dan gaan ze groepen samenstellen op grond waarvan mensen rechten krijgen. Iedereen krijgt alle rechten die een ander lid van het groepje nodig heeft. Je krijgt dus altijd meer rechten dan je nodig hebt. Dat draagt niet bij tot meer veiligheid, integendeel, want als iemand expliciet rechten krijgt dan is misbruik wel heel moeilijk aan te tonen. Op dit vraagstuk struikelen de meeste implementaties. Maar er is meer mis.

Autorisaties waarop?
In normale omgevingen zal RBAC alleen de toegang tot applicaties, devices en directories kunnen regelen. Dit zijn hooguit indirecte waarborgen van de veiligheid van de informatie; er is immers geen mechanisme dat afdwingt waar de informatie staat. Door deze beperkingen is RBAC een puur IT-feestje, waarbij je niet op medewerking van 'de business' of 'Corporate Security' hoeft te rekenen. Een goed werkende RBAC zou ervoor kunnen zorgen dat gebruikers sneller en met minder fouten toegang tot IT resources krijgen, maar dat heeft niets met compliancy (het voorkomen van misbruik immers) te maken.

Niet alles is rolgebonden
Het klassieke rollendenken kent twee variabelen, rollen (functies) en autorisaties. RBAC koppelt autorisaties alleen aan functies van personen. Beveiligingseisen zijn echter niet alleen afhankelijk van medewerkers. Sommige taken mogen niet op bepaalde systemen worden uitgevoerd, omdat ze op minder veilige plaatsen staan. Denk daarbij aan balie PC's en thuiswerkplekken, maar ook aan meer en minder beveiligde zones en panden.

Op jacht naar de bron
RBAC vraagt aan een bronsysteem actuele attributen op grond waarvan rechten uitgedeeld kunnen worden. Het bronsysteem voor rollen is meestal de HR administratie. Daarin staat wel op welke afdeling iemand zit (of zat) en wat de functienaam van iemand is (of was). Maar je hebt veel meer input nodig als je niet met heel grove schetsen autorisaties wilt uitdelen, veel meer informatie dan HR heeft. Die moet je gaan bijhouden. Als je geen bron hebt, dan moet je alles handmatig gaan doen. Nu zijn er soms wel andere registers die de benodigde informatie bevatten. Maar om het urenschrijfsysteem, de prikklok en het helpdesksysteem te koppelen als bron voor deze onmisbare informatie, gaat nogal ver. Het zal slechts incidenteel kunnen, omdat vrijwel al deze registraties achteraf vastleggen, terwijl RBAC de informatie vooraf nodig heeft.

Datakwaliteit
RBAC en ieder ander geautomatiseerd autorisatiebeheer is 100% afhankelijk van triggers in bronsystemen. De datakwaliteit is kritiek, en hoe meer brongegevens je moet gebruiken, hoe meer data die nu nog informationeel is, kritiek wordt. Voor HR is het kamernummer een leuk extraatje, maar als je er provisioning aan koppelt moet het kloppen. En blijven kloppen.

Het gebruik van meerdere bronnen leidt tot interessante synchronisatievragen en arbitraire keuzes over welke gegevens wanneer leidend zijn. Als één systeem 90% goede data heeft, dan gaat 10% van de autorisaties fout. Met vijf bronsystemen met ieder 90% kwaliteit mag je blij als er wel eens een transactie lukt. Bedenk je dat als data op twee plekken staat in plaats van op een plek, iedere waarde in het eigen systeem kan kloppen maar dat ze ten opzichte van elkaar kunnen verschillen waarmee de datakwaliteit daalt. Hoge kwaliteit van data is fijn, maar zeker niet gratis.

Onderhoud
Naast bronnen voor triggers heb je voor alle geautomatiseerde provisioning business logica nodig: iedereen die op kamernummer A213 zit krijgt default printer B11787_VNS. Zit iemand in project HUPSA dan moet hij bij de projectenshare, op de testkamer V4_120 kunnen komen, rechten op bepaalde VPN's krijgen en een nieuwere versie van bepaalde software op de PC hebben. Echter, niet iedereen in het project heeft precies hetzelfde nodig. Stopt die persoon bij project HUPSA, dan moet hij nog twee maanden bij de data kunnen voor de nazorg maar niet meer bij de rest, terwijl andere mensen die stoppen met het project geen nazorgtaken hebben en dus ook niet onder de twee maanden regel vallen. Bij een gemiddeld project zijn deze zaken bovendien niet van te voren bekend, dus ze moeten snel.

Als je dit soort vragen projecteert op een organisatie met enige schaalgrootte, een paar projecten en een reorganisatietje hier en daar, dan weet je dat je dagelijks tientallen mutaties in de logica zult hebben. En dit zijn mutaties die in de regel in de applicatiecode zitten. Als dat zo is, heb je na iedere logicawijziging een nieuwe release van de Code. De Change Manager ziet je al aankomen; en met maar één change window per week kom je er in ieder geval niet.

RBAC 2.0?
Jean Pierre Vincent beschrijft in het blad Informatiebeveiliging een concept voor "RBAC 2.0" met een structuurwijziging (een extra abstractielaag), om niet persoonsgebonden rules te kunnen bevatten. Een prima idee, waarvoor de 'toolleveranciers' wel even hun systemen moeten aanpassen. Dat zal misschien gebeuren, maar het existentiële probleem van de beschikbaarheid van brongegevens en de realiteit van de almaar wijzigende logica wordt er niet door opgelost. Zij maken RBAC tot een monstrum van complexiteit. De implementatie- en de beheeruitdaging zal navenant zijn, evenals de foutkans, dus het beweren dat de kosten zullen dalen en de veiligheid zal toenemen is erg optimistisch, ongeacht de wijzigingen in RBAC 2.0 of later.

De belangrijkste argumenten om RBAC in te voeren zijn vermindering van de kosten en het verhogen van de veiligheid. Veiliger en goedkoper, omdat het eenvoudiger zou worden. Welnu, in de zestienjarige geschiedenis van RBAC is aangetoond dat het niet in te voeren is. Mislukte projecten zijn per definitie duur. En het mislukken is echt niet omdat het niet serieus geprobeerd is, knappere koppen dan alle Security.nl lezers bij elkaar hebben de tanden erop stukgebeten. Stukjes van RBAC zie je soms wel, maar het grote geheel is nergens gelukt. Het is net zoiets als PKI en X.500 - er zitten bruikbare zaken in, maar het grote concept is te complex en te ambitieus. Onbruikbaar dus. Het is dan ook hoog tijd dat we met z'n allen afspreken nooit meer te zeggen dat RBAC een bruikbare oplossing is. Voor je het weet staat het daadwerkelijk in een bindende richtlijn. Dan moeten we het bouwen en dat heeft uiteindelijk maar één mogelijke uitkomst: een compleet fiasco. Daarmee verliezen we veel van de opgebouwde geloofwaardigheid die we als ICT Security zo moeizaam opgebouwd hebben.


Door Peter Rietveld, Senior Security consultant bij Traxion - The Identity Management Specialists -

Vorige columns van Peter

Reacties (22)
27-08-2008, 21:28 door Anoniem
Leuk.... Maar noem nou eens een goed alternatief voor een complexe organisatie!
28-08-2008, 01:48 door Jachra
Medewerkers hebben altijd meer dan één rol. Sommige medewerkers hebben sóms maar één rol. Zelfs in de spreekwoordelijke koekjesfabriek hebben mensen meerdere petten - denk aan lijn en projectrollen, interimtaken en allerlei vormen van samenwerking en taakwaarneming. Bovendien zijn er ook autorisaties nodig voor eenmalige taken, zoals toegang tot een dataset voor het maken van jaarrekeningen of root toegang tot een systeem om een storing op te lossen.

Indien je de rollen duidelijk definieert, dan maakt het niet uit wie hoeveel rollen heeft. Het maakt wel overzichtelijk wie wat mag. En hiermee voldoet men wel degelijk aan "adequate internal control". Je maakt het gemakkelijker om op elk moment een helder en duidelijk overzicht te krijgen van de rechten binnen een bedrijf. Deze overzichten kan men invoeren in diverse BI-software pakketten. Daarmee kan je gemakkelijk bekijken of je gestelde KPI's wel gehaald worden en voldoen.

Sorry Peter, maar je slaat de plank behoorlijk mis.
28-08-2008, 09:29 door Anoniem
Peter,

Ik heb dit persoonlijk samen met een collega gerealiseerd bij meerdere klanten van meer dan 20.000 medewerkers en je slaat de plank volledig mis.

Het is allemaal mogelijk en het werkt en goed en al jaren.

En ja je moet er even over nadenken.

Niet zomaar overal kritiek opgeven op basis van theorie.


De groeten
28-08-2008, 09:30 door Anoniem
Peter slaat de plank helemaal niet mis, aangezien hij niet zegt dat RBAC geen meerwaarde kan leveren bij de rapportages over de rechten die een persoon heeft binnen een organisatie. Hij zegt wel dat RBAC geen meerwaarde levert voor de veiligheid.

[QOUTE]
...
Dat draagt niet bij tot meer veiligheid, integendeel, want als iemand expliciet rechten krijgt dan is misbruik wel heel moeilijk aan te tonen.
...
[/QOUTE]

Iemand die meer rechten heeft dan hij of zij nodig heeft kan een potentiele security risico zijn (bewust of onbewust).
28-08-2008, 09:40 door Anoniem
Door AnoniemPeter,

Ik heb dit persoonlijk samen met een collega gerealiseerd bij meerdere klanten van meer dan 20.000 medewerkers en je slaat de plank volledig mis.

Het is allemaal mogelijk en het werkt en goed en al jaren.

En ja je moet er even over nadenken.

Niet zomaar overal kritiek opgeven op basis van theorie.


De groeten

En wat was het doel van RBAC bij deze klanten? De beveiliging verhogen OF toch mooie rapportages kunnen leveren die weergeven wat een gebruiker allemaal mag binnen de organisatie?
28-08-2008, 10:26 door Jachra
Door Anoniem
Door AnoniemPeter,

Ik heb dit persoonlijk samen met een collega gerealiseerd bij meerdere klanten van meer dan 20.000 medewerkers en je slaat de plank volledig mis.

Het is allemaal mogelijk en het werkt en goed en al jaren.

En ja je moet er even over nadenken.

Niet zomaar overal kritiek opgeven op basis van theorie.


De groeten

En wat was het doel van RBAC bij deze klanten? De beveiliging verhogen OF toch mooie rapportages kunnen leveren die weergeven wat een gebruiker allemaal mag binnen de organisatie?

Door middel van RBAC verhoog je weldegelijk de veiligheid. Immers definieer je dan duidelijk welke bevoegdheden een medewerker mag hebben. Men kan dan ook niet zomaar buiten die bevoegdheden treden. Tevens vereist het gebruik van RBAC een cultuur verandering binnen een bedrijf. Zonder een dergelijke cultuurverandering is RBAC gedoemd om te falen als project.
28-08-2008, 10:40 door Anoniem
Peter Rietveld:

En het mislukken is echt niet omdat het niet serieus geprobeerd is, knappere koppen dan alle Security.nl lezers bij elkaar hebben de tanden erop stukgebeten.
Dat betekent dat die 'knappere koppen' geen security.nl lezers zijn. Misschien is dat de reden dat het ze niet lukt?
28-08-2008, 11:10 door Anoniem
Beste Peter

Het implementeren van RBAC is geen doel op zich. Het doel is om een systematiek te vinden die een organisatie in staat stelt autorisaties te beheren en af te dwingen binnen de ICT-toepassingen en past bij de organisatie. Een van de vormen kan RBAC zijn, maar hoeft dit niet persé te zijn. Tevens zul je moeten bepalen tot hoever je wil gaan. Het is natuurlijk een utopie te denken dat je RBAC implementeren voor alle duizenden toepassingen in een organisatie.

Tevens is een aantal organisaties er in geslaagd om autorisatiemanagement in te richten op basis van RBAC, en wel met succes. Redenen om dit te doen zijn naast het moeten voldoen aan wet- & regelgeving met betrekking tot het "in control" zijn ten aanzien van wie heeft toegang tot wat (en ja hoeft niet met RBAC, maar goed er staat ook nergens geschreven dat je de boekhouding het meest efficient kunt doen met een financiële toepassing), het instaat om operational excellence te bereiken en last but not least in staat te zijn continue organisatiewijzigingen in de organisatie te volgen voor wat betreft autorisaties.

Kortom, als ik je artikel lees, moet bekennen dat dit niet gebaseerd is op de dagelijkse praktijk. Natuurlijk is het implementeren van autorisatiemanagement op basis van RBAC geen sinecure, maar zeker geen onmogelijkheid.
28-08-2008, 12:12 door Anoniem
Door AnoniemBeste Peter

Het implementeren van RBAC is geen doel op zich. Het doel is om een systematiek te vinden die een organisatie in staat stelt autorisaties te beheren en af te dwingen binnen de ICT-toepassingen en past bij de organisatie. Een van de vormen kan RBAC zijn, maar hoeft dit niet persé te zijn. Tevens zul je moeten bepalen tot hoever je wil gaan. Het is natuurlijk een utopie te denken dat je RBAC implementeren voor alle duizenden toepassingen in een organisatie.

Tevens is een aantal organisaties er in geslaagd om autorisatiemanagement in te richten op basis van RBAC, en wel met succes. Redenen om dit te doen zijn naast het moeten voldoen aan wet- & regelgeving met betrekking tot het "in control" zijn ten aanzien van wie heeft toegang tot wat (en ja hoeft niet met RBAC, maar goed er staat ook nergens geschreven dat je de boekhouding het meest efficient kunt doen met een financiële toepassing), het instaat om operational excellence te bereiken en last but not least in staat te zijn continue organisatiewijzigingen in de organisatie te volgen voor wat betreft autorisaties.

Kortom, als ik je artikel lees, moet bekennen dat dit niet gebaseerd is op de dagelijkse praktijk. Natuurlijk is het implementeren van autorisatiemanagement op basis van RBAC geen sinecure, maar zeker geen onmogelijkheid.

Volgens mij ben je een collega van me als je tekst zo analyseer lol

Ik was die anonieme van " ik heb dit persoonlijk bij".

Dat er verbeterpunten zijn ja die zijn er altijd maar het heeft bij ons een scala aan knelpunten opgelost.

Eerlijk gezegd ..raakt me de kritiek van Peter Rietveld me enigzins omdat dit gewoon niet aansluit bij wat ik in de praktijk ervaar en gerealiseerd is.

Ik zie het daarom maar als kritiek op basis van theorie. En mbt die knappe koppen...kwestie van langer nadenken.
En ja RBAC lost niet alles op maar wel de aandachtspunten zoals hierboven beschreven.
28-08-2008, 12:12 door Mameomowskwooz
Door Anoniem
Tevens is een aantal organisaties er in geslaagd om autorisatiemanagement in te richten op basis van RBAC, en wel met succes. Redenen om dit te doen zijn naast het moeten voldoen aan wet- & regelgeving met betrekking tot het "in control" zijn ten aanzien van wie heeft toegang tot wat (en ja hoeft niet met RBAC, maar goed er staat ook nergens geschreven dat je de boekhouding het meest efficient kunt doen met een financiële toepassing), het instaat om operational excellence te bereiken en last but not least in staat te zijn continue organisatiewijzigingen in de organisatie te volgen voor wat betreft autorisaties.

Kortom, als ik je artikel lees, moet bekennen dat dit niet gebaseerd is op de dagelijkse praktijk. Natuurlijk is het implementeren van autorisatiemanagement op basis van RBAC geen sinecure, maar zeker geen onmogelijkheid.

Het is natuurlijk maar net hoe je succes definieert. Als je iedereen (bijna) alle rechten op (bijna) alles geeft kun je misschien argumenteren dat je met RBAC "in control" bent omdat je op ieder moment een overzicht hebt over je autorisaties. Tsja, dan degradeer je RBAC dus tot een rapportage-methodiek.
Ik meen dat Peter zijn kritiek zich meer richt op RBAC als een methode om daadwerkelijk pro-actief "in control" te zijn. RBAC was toch bedoeld om gebruikers toegang te verschaffen tot slechts die informatie en applicaties die ze werkelijk nodig hebben voor hun rol? Dat is juist de functie die hier bekritiseerd wordt.
28-08-2008, 14:21 door Anoniem
da's een goede.
"Ik kan niet fietsen, zet alle fietsen bij het vuil"
28-08-2008, 15:03 door Anoniem
Door Mameomowskwooz
Door Anoniem
Tevens is een aantal organisaties er in geslaagd om autorisatiemanagement in te richten op basis van RBAC, en wel met succes. Redenen om dit te doen zijn naast het moeten voldoen aan wet- & regelgeving met betrekking tot het "in control" zijn ten aanzien van wie heeft toegang tot wat (en ja hoeft niet met RBAC, maar goed er staat ook nergens geschreven dat je de boekhouding het meest efficient kunt doen met een financiële toepassing), het instaat om operational excellence te bereiken en last but not least in staat te zijn continue organisatiewijzigingen in de organisatie te volgen voor wat betreft autorisaties.

Kortom, als ik je artikel lees, moet bekennen dat dit niet gebaseerd is op de dagelijkse praktijk. Natuurlijk is het implementeren van autorisatiemanagement op basis van RBAC geen sinecure, maar zeker geen onmogelijkheid.

Het is natuurlijk maar net hoe je succes definieert. Als je iedereen (bijna) alle rechten op (bijna) alles geeft kun je misschien argumenteren dat je met RBAC "in control" bent omdat je op ieder moment een overzicht hebt over je autorisaties. Tsja, dan degradeer je RBAC dus tot een rapportage-methodiek.
Ik meen dat Peter zijn kritiek zich meer richt op RBAC als een methode om daadwerkelijk pro-actief "in control" te zijn. RBAC was toch bedoeld om gebruikers toegang te verschaffen tot slechts die informatie en applicaties die ze werkelijk nodig hebben voor hun rol? Dat is juist de functie die hier bekritiseerd wordt.

Doelstelling die je kunt bereiken met het inrichten van autorisatiemanagement op basis van RBAC is om in plaats van detective controls (op basis van rapportages) te groeien naar een systeem van preventive controls, waarbij deze op een geautomatiseerde wijze worden afgedwongen. Dat is toch wel pro-actief naar mijn mening, toch ?
28-08-2008, 15:09 door Anoniem
Door Mameomowskwooz
Door Anoniem
Tevens is een aantal organisaties er in geslaagd om autorisatiemanagement in te richten op basis van RBAC, en wel met succes. Redenen om dit te doen zijn naast het moeten voldoen aan wet- & regelgeving met betrekking tot het "in control" zijn ten aanzien van wie heeft toegang tot wat (en ja hoeft niet met RBAC, maar goed er staat ook nergens geschreven dat je de boekhouding het meest efficient kunt doen met een financiële toepassing), het instaat om operational excellence te bereiken en last but not least in staat te zijn continue organisatiewijzigingen in de organisatie te volgen voor wat betreft autorisaties.

Kortom, als ik je artikel lees, moet bekennen dat dit niet gebaseerd is op de dagelijkse praktijk. Natuurlijk is het implementeren van autorisatiemanagement op basis van RBAC geen sinecure, maar zeker geen onmogelijkheid.

Het is natuurlijk maar net hoe je succes definieert. Als je iedereen (bijna) alle rechten op (bijna) alles geeft kun je misschien argumenteren dat je met RBAC "in control" bent omdat je op ieder moment een overzicht hebt over je autorisaties. Tsja, dan degradeer je RBAC dus tot een rapportage-methodiek.
Ik meen dat Peter zijn kritiek zich meer richt op RBAC als een methode om daadwerkelijk pro-actief "in control" te zijn. RBAC was toch bedoeld om gebruikers toegang te verschaffen tot slechts die informatie en applicaties die ze werkelijk nodig hebben voor hun rol? Dat is juist de functie die hier bekritiseerd wordt.

Ik denk dat die knappe knoppen het gewoon aan ervaring ontbreekt.
30-08-2008, 23:33 door Anoniem
Volgens mij is de kern van het artikel dat RBAC wel degelijk kan werken, als er maar aan een aantal randvoorwaarden wordt voldaan. Dit zijn vooral organisatorische randvoorwaarden. En wordt daar niet aan voldaan, dan kan je RBAC beter in de vuilnisbak pleuren.

RBAC is geen Snake Oil. Maar dat geldt voor zo ongeveer iedere IT oplossing...
03-09-2008, 10:34 door Anoniem
Dit is weer typisch zo een verhaal dat goed had kunnen zijn ware het niet doorspekt met ondoordachte en niet gekwantificeerde opmerkingen.
Neem bijvoorbeeld het feit dat de suggestie gewekt wordt dat Security.nl lezers dom zijn. [...knappere koppen dan alle Security.nl lezers bij elkaar hebben...], maar ook [... het grote geheel is nergens gelukt...] welke suggereerd dat Peter inzage heeft in all alle bedrijven waar dan ook ter wereld. Dit noemt men 'limitless arguments', deze vorm van argumentatie is niet op feiten gebasseerd en wordt vaak gebruikt door mensen om anderen van hun gelijk te overtuigen.
03-09-2008, 19:41 door Anoniem

Neem bijvoorbeeld het feit dat de suggestie gewekt wordt dat Security.nl lezers dom zijn. [...knappere koppen dan alle Security.nl lezers bij elkaar hebben...], maar ook [... het grote geheel is nergens gelukt...] welke suggereerd dat Peter inzage heeft in all alle bedrijven waar dan ook ter wereld. [\quote]

Noem er eens paar?
04-09-2008, 12:17 door Anoniem
Door AnoniemDit is weer typisch zo een verhaal dat goed had kunnen zijn ware het niet doorspekt met ondoordachte en niet gekwantificeerde opmerkingen.
Neem bijvoorbeeld het feit dat de suggestie gewekt wordt dat Security.nl lezers dom zijn. [...knappere koppen dan alle Security.nl lezers bij elkaar hebben...], maar ook [... het grote geheel is nergens gelukt...] welke suggereerd dat Peter inzage heeft in all alle bedrijven waar dan ook ter wereld. Dit noemt men 'limitless arguments', deze vorm van argumentatie is niet op feiten gebasseerd en wordt vaak gebruikt door mensen om anderen van hun gelijk te overtuigen.

Dit is heel eenvoudig te werleggen door een gelukt voorbeeld te noemen, waar RBAC inderdaad heeft bijgedragen aan een verhoging van de veiligheid zonder de flexibiliteit van een onderneming noemswaardig te beinvloeden.

Dat zou niet al te moeilijk moeten zijn toch? ;-)
04-09-2008, 13:50 door Anoniem
Het is natuurlijk eenvoudig om RBAC af te branden maar de grote fout zit in de generalisatie die veel modelfetisjisten maken. Elk model, dus ook RBAC, heeft begrenzingen (en dat is wat de auteur duidelijk beschrijft). De tendens om de uitzonderingen weer modelmatig in te gaan richten (de genoemde 2e abstractielaag) is uiteraard een heilloze weg want ook die modellering kent z'n grenzen.

Dit denken zie je ook terug in het verschil tussen managers en leiders. Een leider kijkt naar model en ziet aanknopingspunten, pakt er onderdelen uit en probeert een verandering in te zetten. Daarbij is de verandering het doel en het model een middel.

Een manager gaat echter met het model aan de haal en verheft het middel tot doel waardoor automatisch een mechanisme in werking treedt dat meer model ook tot betere resultaten leidt en een 100% adoptie het ultieme doel wordt. Ik moet de eerste organisatie nog tegenkomen die daar successen mee heeft geboekt.

In mijn evangelisatie van RBAC zie ik vooral veel waarde in de delta rapportages tussen de, middels RBAC mechanismen gecontroleerde rechten (mainstream), en de vele handmatig uitgedeelde rechten. Dat geeft inzicht en met inzicht kun je ook verantwoording afleggen en dat is de crux van compliancy.

Ik ga er van uit, mede gezien de reacties, dat de auteur met een stevige opinie de boel heeft willen opschudden. In dat licht kan deze column geen kwaad. Wat de auteur met "knappere koppen" bedoelt kan ik niet plaatsen. Zijn dat verandermanagers? CIO's? RBAC consultants? Ook dit is een generalisatie die geen recht doet aan de vele expertises en mensen die bij een geslaagd compliancy verandertraject (met mogelijk gebruik van RBAC modellering) betrokken moeten zijn.

Wim Schreuder
ICT architect - technische infrastructuur

Menzis zorg en inkomen
05-09-2008, 15:35 door Anoniem
De knapste koppen van IT security zitten op security.nl! En zo is het maar net.
07-09-2008, 20:47 door Anoniem
RBAC is inderdaad geen doel op zichzelf. Het is een middel dat een aantal voordelen kan hebben, waaronder compliance rapportages, en vereenvoudiging van het toekennen van rechten aan mensen. RBAC is daarbij in feite een middel om de efficiency van al deze processen te vergroten. Het heeft ook wat nadelen daardoor, want het leidt tot minder flexibiliteit, en managers moeten beter kunnen definieren wat hun medewerkers nou eenmaal (zouden moeten) doen. Dat laatste is een proces op zichzelf. Deze informatie kun je vervolgens vastleggen in een rol.

In mijn bedrijf is dat goed gelukt, maar daarmee is niet gezegd dat je meteen voor alle gevallen een oplossing hebt. Er zijn altijd aanvullende maatregelen nodig. Bijv. toegang tot documentatie staat daar min of meer los van. Dat is vaak per project, of per systeem, georganiseerd, en dat geldt dan ook voor de rechten om de betreffende documenten te mogen bekijken, of aan te passen. Maar dit kan heel goed naast RBAC bestaan.

Kortom, het is een goed middel, maar zonder een overall plan heeft ook RBAC niet zoveel zin, zeker omdat je toch behoorlijk moet investeren om het goed voor elkaar te krijgen.
09-09-2008, 11:07 door Anoniem
[Maar noch SOX noch PCI-DSS schrijven het voor; er wordt alleen een "adequate internal control" geëist, en vendors en consultants roepen in koor dat RBAC in allerlei subsmaken de enige manier is.]
Klopt, het ligt dus ook genuanceerder, RBAC is niet in alle gevallen noodzakelijk maar biedt in sommige gevallen een oplossing om de control in adequaat in te vullen, de oplossing moet in verhouding staan tot het doel van de control, en het totale concept (het kan voordelig zijn indien meerdere controls met een beperkt aantal oplossingen worden afgedekt).
[Het idee dat verschillende mensen dezelfde rol hebben en dus gelijk zijn, is een misvatting]
Medewerkers kunnen prima dezelfde rol hebben en tegelijkertijd niet "gelijk" zijn, je wilt juist af van (zeker in grote ondernemingen) persoonsgebonden autorisaties waardoor het geheel onbeheersbaar en ondoorzichtig wordt. Een rolexplosie door uit te gaan van inrichting van rollen op basis van de minste rechten levert daarom onvoldoende voordeel en rechtvaardiging voor het optuigen van "RBAC". Groeperen van medewerkers kan in veel situaties prima; je moet hierbij wel de uitgangspunten en criteria vaststellen waaronder dat gebeurt, bv het waarborgen van functiescheiding t.a.v. kritieke of risicovolle processen, het rekening houden met licenties, bedrijfskritische gegevens enz. Autorisaties die niet binnen deze categorieen vallen kunnen veelal prima worden samengevoegd om de beheersbaarheid te vergroten en de risico's (de facto) te verkleinen. De risico's van veel huidige (niet RBAC) implementaties dienen hierbij niet uit het oog te worden verloren..
[Ieder RBAC project stuit dan ook op het feit dat er meer rollen dan gebruikers zijn]
Onjuist, een gemiddeld rol-gebruikers ratio van 1:15 is prima mogelijk bij een wat grotere implementatie.
[Autorisaties waarop? In normale omgevingen zal RBAC alleen de toegang tot applicaties, devices en directories kunnen regelen. Dit zijn hooguit indirecte waarborgen van de veiligheid van de informatie; er is immers geen mechanisme dat afdwingt waar de informatie staat. Door deze beperkingen is RBAC een puur IT-feestje, waarbij je niet op medewerking van 'de business' of 'Corporate Security' hoeft te rekenen. .]
Security bestaat uit veel componenten die met elkaar samenhangen, op alle niveau's dien je uiteraard maatregelen te nemen om bedreigingen het hoofd te kunnen bieden. RBAC pretendeert geen totaaloplossing te zijn voor alle bedreigingen. V.w.b. data, het draait om data, niet om directories; dat dien je te borgen in je implementatie (procedureel & technisch: waar relevant)
[Niet alles is rolgebonden]
Niet alles hoeft met RBAC opgelost te worden, het locatievoorbeeld kun je ook andere/meerdere manieren oplossen zonder impact op RBAC.
[Op jacht naar de bron RBAC vraagt aan een bronsysteem actuele attributen op grond waarvan rechten uitgedeeld kunnen worden. Het bronsysteem voor rollen is meestal de HR administratie.]
HR administraties zijn vaak een uitdaging, maar vaak ook de meest geschikte (beschikbare/betrouwbare (;)) bron voor een aantal noodzakelijke basisgegevens. Je kunt het ook beperken tot het gebruik van basisgegevens (persnr, key, locatie, manager etc.) een HR systeem is een HR systeem, en dat moet je inderdaat bijhouden ;-)
[Datakwaliteit] ; mee eens, datakwaliteit en datadefinitie vormt vaak een uitdaging.
[Stukjes van RBAC zie je soms wel, maar het grote geheel is nergens gelukt. Het is net zoiets als PKI en X.500 - er zitten bruikbare zaken in, maar het grote concept is te complex en te ambitieus. Onbruikbaar dus. Het is dan ook hoog tijd dat we met z'n allen afspreken nooit meer te zeggen dat RBAC een bruikbare]
Het concept en implementaties worden vaak te complex en te ambitieus gemaakt en daarbuiten is het opzetten van RBAC zoals eerder werd opgemerkt geen sinicure. Het gaat erom een passende oplossing te bieden voor een specifieke situatie en doelstelling. RBAC invoeren staat niet gelijk met een complete IAM implementatie op basis van rollen, binnen sommige organisaties kan het prima worden ingericht via een administratief proces.
09-09-2008, 11:12 door knakker
[Maar noch SOX noch PCI-DSS schrijven het voor; er wordt alleen een "adequate internal control" geëist, en vendors en consultants roepen in koor dat RBAC in allerlei subsmaken de enige manier is.]

Klopt, het ligt dus ook genuanceerder, RBAC is niet in alle gevallen noodzakelijk maar biedt in sommige gevallen een oplossing om de control in adequaat in te vullen, de oplossing moet in verhouding staan tot het doel van de control, en het totale concept (het kan voordelig zijn indien meerdere controls met een beperkt aantal oplossingen worden afgedekt).

[Het idee dat verschillende mensen dezelfde rol hebben en dus gelijk zijn, is een misvatting]
Medewerkers kunnen prima dezelfde rol hebben en tegelijkertijd niet "gelijk" zijn, je wilt juist af van (zeker in grote ondernemingen) persoonsgebonden autorisaties waardoor het geheel onbeheersbaar en ondoorzichtig wordt. Een rolexplosie door uit te gaan van inrichting van rollen op basis van de minste rechten levert daarom onvoldoende voordeel en rechtvaardiging voor het optuigen van "RBAC". Groeperen van medewerkers kan in veel situaties prima; je moet hierbij wel de uitgangspunten en criteria vaststellen waaronder dat gebeurt, bv het waarborgen van functiescheiding t.a.v. kritieke of risicovolle processen, het rekening houden met licenties, bedrijfskritische gegevens enz. Autorisaties die niet binnen deze categorieen vallen kunnen veelal prima worden samengevoegd om de beheersbaarheid te vergroten en de risico's (de facto) te verkleinen. De risico's van veel huidige (niet RBAC) implementaties dienen hierbij niet uit het oog te worden verloren..

[Ieder RBAC project stuit dan ook op het feit dat er meer rollen dan gebruikers zijn]
Onjuist, een gemiddeld rol-gebruikers ratio van 1:15 is prima mogelijk bij een wat grotere implementatie.
[Autorisaties waarop? In normale omgevingen zal RBAC alleen de toegang tot applicaties, devices en directories kunnen regelen. Dit zijn hooguit indirecte waarborgen van de veiligheid van de informatie; er is immers geen mechanisme dat afdwingt waar de informatie staat. Door deze beperkingen is RBAC een puur IT-feestje, waarbij je niet op medewerking van 'de business' of 'Corporate Security' hoeft te rekenen. .]

Security bestaat uit veel componenten die met elkaar samenhangen, op alle niveau's dien je uiteraard maatregelen te nemen om bedreigingen het hoofd te kunnen bieden. RBAC pretendeert geen totaaloplossing te zijn voor alle bedreigingen. V.w.b. data, het draait om data, niet om directories; dat dien je te borgen in je implementatie (procedureel & technisch: waar relevant)

[Niet alles is rolgebonden]
Niet alles hoeft met RBAC opgelost te worden, het locatievoorbeeld kun je ook andere/meerdere manieren oplossen zonder impact op RBAC.

[Op jacht naar de bron RBAC vraagt aan een bronsysteem actuele attributen op grond waarvan rechten uitgedeeld kunnen worden. Het bronsysteem voor rollen is meestal de HR administratie.]
HR administraties zijn vaak een uitdaging, maar vaak ook de meest geschikte (beschikbare/betrouwbare (;)) bron voor een aantal noodzakelijke basisgegevens. Je kunt het ook beperken tot het gebruik van basisgegevens (persnr, key, locatie, manager etc.) een HR systeem is een HR systeem, en dat moet je inderdaat bijhouden ;-)
[Datakwaliteit] ; mee eens, datakwaliteit en datadefinitie vormt vaak een uitdaging.
[Stukjes van RBAC zie je soms wel, maar het grote geheel is nergens gelukt. Het is net zoiets als PKI en X.500 - er zitten bruikbare zaken in, maar het grote concept is te complex en te ambitieus. Onbruikbaar dus. Het is dan ook hoog tijd dat we met z'n allen afspreken nooit meer te zeggen dat RBAC een bruikbare]
Het concept en implementaties worden vaak te complex en te ambitieus gemaakt en daarbuiten is het opzetten van RBAC zoals eerder werd opgemerkt geen sinicure. Het gaat erom een passende oplossing te bieden voor een specifieke situatie en doelstelling. RBAC invoeren staat niet gelijk met een complete IAM implementatie op basis van rollen, binnen sommige organisaties kan het prima worden ingericht via een administratief proces.

Roel
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.