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

• De nachtmerrie van security managers
  
• Outsourcing: Horen, Zien, Zwijgen?
  
• Certificeringen: Bewijzen van onvermogen
  
• Leuke speledingetjes
  
• Security volgens WC-Eend
  
• Een triviaal bureautje in de periferie
  
• Koud onderzoek
  
• Wie Zwijgt Stemt Toe
  
• Een Lesje in Beveiliging
  
• Voortschrijdend Inzicht Mag Niet
  
• De Chinezen Komen Niet - Ze Zijn Er Al!
  
• Het anti-terrorismehoesje
  
• Niemand is de Baas
  
• Zin en Onzin
  
• This is Me
  
• Wat niet meet, wat niet deert
  
• De Chinezen komen, of niet natuurlijk (deel 2)
  
• Afscheid van het netwerk
  
• De Chinezen komen! Of niet, natuurlijk.
  
• Een kwakkelend dossier
  
• "Nederland is goed voorbereid"
  
• Headhunter incident
  
• Ethiek en Security
  
• De kleren van de keizer zijn dood, leve de nieuwe kleren van de keizer
  
• Over Security Architectuur
  
• Best Practices bestaan niet
  
• Unified Threat Management: dure mensen, goeie spullen?
  
• Security maturity
  
• Komt het nog wel goed
  
• Geen nieuws is goed nieuws
  
• Awareness best belangrijk
  
• Een papieren tijger in een zilveren lijstje
  
• Een goed idee is niet goed genoeg
  
• Uit de loopgraven
  
• Waarom beveiligingsbeleid faalt
  
• Groot slaat dood