Role Based Access Control ???

Role Based Access Control
Uit Wikipedia, de vrije encyclopedie
Ga naar: navigatie, zoeken
Role Based Access Control (RBAC) is een methode waarmee op een effectieve en efficiënte wijze de toegang tot informatiesystemen kan worden ingericht.
Inhoud[verbergen]
1 Methode
1.1 Voorbeeld RBAC
2 Standaarden
3 Alternatieve toegangscontrole methodieken
4 Bekende RBAC hulpmiddelen
5 Zie ook
6 Externe links
//

[bewerk] Methode
Kenmerk van RBAC is dat individuen niet rechtstreeks worden geautoriseerd in informatiesystemen, maar dat ze uitsluitend rechten krijgen op basis van een vorm van groepslidmaatschap, op basis van de rol die ze hebben binnen een organisatie of bedrijfsproces. Ook de permissies op objecten/functies in informatiesystemen kunnen worden gegroepeerd in rollen.
Door het koppelen van de rol van de gebruiker in de organisatie aan een rol in een informatiesysteem, is het eenvoudig om de effectieve rechten van een gebruiker te bepalen. Het daadwerkelijk toekennen van rechten en permissies aan een gebruiker en het verstrekken van gerelateerde objecten (tokens en dergelijke) heet provisioning.
In het kader van RBAC trajecten wordt binnen organisaties een overzicht van de gebruikte rollen opgesteld middels de techniek van role-mining.

[bewerk] Voorbeeld RBAC
Bob vervult de rol van baliemedewerker bij een bank.
Het CRM-systeem kent de rol klantcontactbeheer.
De organisatierol baliemedewerker wordt gekoppeld aan de informatiesysteemrol klantcontactbeheer. Daarmee verkrijgt Bob automatisch de rechten die nodig zijn om de CRM functie van klantcontact te kunnen uitvoeren.
Op zich levert deze inrichting geen besparing op. Maar als nu ook Alice wordt benoemd als baliemedewerker, dan verkrijgt ook zij automatisch de rechten die nodig zijn om de CRM functie van klantcontact te kunnen uitvoeren. En als Bob van rol wisselt doordat hij niet langer baliemedewerker is maar de functie van hypotheekadviseur krijgt, dan raakt hij ook automatisch de klantcontactbeheer functies kwijt.

[bewerk] Standaarden
Het Amerikaanse NIST heeft een standaard voor RBAC gedefinieerd. De meeste producten die op de markt zijn verschenen zijn in staat om de standaard te volgen.

[bewerk] Alternatieve toegangscontrole methodieken
RBAC is niet een model om de autorisaties op een dynamische wijze toe te kennen. Om dat te realiseren kan de methode van Rule Based Access Control of Lattice Based Access Control worden toegepast. Deze beide vormen van toegangscontrole zijn ook onder de noemer Mandatory Access Control te vatten.
Ook Discretionary access control is een vorm van toegangscontrole, waarbij de eigenaar van een object zelf bepaalt wie welke toegangsrechten mag uitoefenen.

[bewerk] Bekende RBAC hulpmiddelen
BetaSystems SAM Jupiter
BHOLD Company
BMC Control SA en IdM
CA eTrust
HP Select Access
IBM TIM en TAM (Tivoli Identity Manager en Tivoli Access Manager)
Microsoft Authorization Manager (Azman)
Novell Access Manager
Sun Identity Management Suite

[bewerk] Zie ook
Bell-La Padula vertrouwelijkheidsmodel
Biba integriteitsmodel
Take-Grant Model
The Clark-Wilson integriteitsmodel
Graham-Denning Model
Security Enhanced Linux

[bewerk] Externe links
Role Based Access Controls at NIST - De RBAC standaard van het NIST
Handreiking Identity Management van het Genootschap van Informatiebeveiligers (GvIB)

Categorieën: Informatiebeveiliging Identity and Access Management

Zet RBAC bij het grof vuil
Woensdag,16:55 doorRedactieReacties: 14
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 -