RBAC, ofwel role based access control, is in! Steeds meer organisaties die ik spreek zien het belang van op een gestructureerde wijze toekennen en beheren van autorisaties in het netwerk. De situatie is nu vaak dat bij het toekennen van autorisaties een kopie wordt gemaakt van een collega die ‘ongeveer’ dezelfde functie heeft. Zo krijgen nieuwe medewerkers vaak toegang tot systemen en applicaties die zij helemaal niet nodig hebben. Er wordt zelden aandacht besteed aan het ontnemen van autorisaties na het kopiëren van een gebruiker. En dat heeft consequenties voor onder meer de licentiekosten en de informatiebeveiliging.
RBAC is één van de mogelijkheden om dit probleem op te lossen. RBAC bestaat uit een matrix van rollen, functies en specifieke toegangsrechten. Als bijvoorbeeld een nieuwe medewerker in dienst komt, dan wordt via de RBAC-matrix bepaalt wat de nieuwe medewerker mag op het netwerk. Zover de theorie. In de praktijk blijkt dat met name het vullen van een dergelijke matrix veel problemen met zich meebrengt, want medewerkers voelen zich vaak uniek en dit leidt niet zelden tot net zoveel rollen als er medewerkers zijn. En dat levert uiteindelijk een eindeloze en onwerkbare matrix op. Organisaties zijn daarom bang om RBAC binnen hun organisatie te implementeren. Toch zijn er organisaties die eraan beginnen en er dan naar streven om 100 procent van de medewerkers in de RBAC-matrix te krijgen. Dit is mijns inziens onbegonnen werk en neemt jaren tijd in beslag van zowel management als de security officer.
Wil je een snelle start maken met RBAC? Dat is heel goed mogelijk, maar streef dan niet naar 100 procent in de eerste instantie. Op basis van de informatie uit het hr-systeem is het heel goed mogelijk om de top 50 meest voorkomende combinaties van afdelingen en functies in de organisatie te ontdekken. Hiermee kan al 80 procent van de RBAC-matrix worden gevuld. En dat kan al binnen een paar dagen! Vervolgens wordt via een workflowapplicatie de overige 20 procent handmatig ingevuld door de manager van een medewerker.
Het kan misschien wel jaren duren voordat de RBAC-matrix 100 procent ingevuld is, maar door gebruik te maken van bestaande systemen en bronnen, zoals het hr-systeem, én het centraal stellen van de manager wordt het vullen van de RBAC-matrix een hanteerbaar proces met een direct resultaat. Dat betekent voordeel met betrekking tot haalbaarheid van RBAC, de hoeveelheid benodigde moeite en een positieve ict audit-normering. Een indirecte spin-off is een reductie van onder meer licentiekosten, opslag en security-incidenten.
Je krijgt de RBAC tabellen nooit compleet. Een bedrijf is niet statisch. Het de koppeling personeelsadministratie met netwerkrechten levert echter veel op.
RBAC is een eind jaren 80 concept. Heel erg baanbrekend is bovenstaande dus niet. Bovendien kunnen niet alle rechten op basis van afdelingen en functies worden toegekend. Zo kan iemand “software engineer” zijn, maar als je geen idee hebt in welke projecten hij/zij werkt weet je niet waarop rechten moeten worden toegekend (bijvoorbeeld welke mappen/repositories).
De claim die de auteur geeft in zijn samenvatting dat het leidt tot positieve ict-normering een reductie van licentiekosten, opslag en secutiry incidenten zie ik nergens onderbouwd in het stuk. Ik ben geinteresseerd in de onderbouwing daarvan.
@Willem: met de software engineer als voorbeeld zou je specifieke project rollen kunnen bouwen met daarin opgenomen de specifieke rechten/mappen/repositories t/m de verschillende OTAP-omgevingen. Er kan heel veel met rollen maar vergt wel werk.
@Urbanunr3st
Dat zou inderdaad kunnen, maar niet vanuit het personeelsmanagement systeem zoals de auteur suggereert.
Je krijgt binnen een mum van tijd meer rollen dan medewerker als je niet uitkijkt. En wie controleert of al die rechten ook weer worden ingetrokken?
Ik begrijp gewoon niet wat de auteur met dit stuk wil zeggen. RBAC is niet nieuw. De door hem genoemde voordelen worden niet onderbouwd.
Zoals Willem al aangeeft, is het concept niet nieuw.
De uitdaging is echter niet alleen om de goede rollen te definiëren (zoals de auteur al aangeeft), maar vooral om een goede administratie bij te houden
Mensen met meerdere rollen, mensen die in meerdere projecten werken, of erger nog, mensen die in verschillende projecten verschillende rollen vervullen maken dit concept lastig te implementeren en onderhouden.
Bij een klant is op dit moment een RBAC implementatie bezig. Ik heb tot zover mijn ervaringen samengevat in het volgende artikel:
http://www.servercare.nl/Lists/Posts/Post.aspx?ID=92
Een van de grotere gevaren is (zoals bij de meesten bekend) het teveel aanmaken van rollen. Het is derhalve van belang behalve een technische invulling van RBAC ook de organisatorische en procedurele invulling goed vast te leggen.
Bij een klant hebben wij RBAC geïmplementeerd. Wij hebben m.n. de brug geslagen tussen ICT en de business, waardoor de organisatorische en procedurele invulling goed is ingeregeld. De klant heeft de Identity Award 2008 gewonnen (http://www.argentum.biz/content/implementatie-en-inrichting-rolgebasseerd-werken.html).
In het kader van risicomanagement is een zichtbare beveiligingsorganisatie een kans.
Dit is de oplossing, en zo voer je hem in, is wat er wel staat, niet hoe de oplossing het probleem oplost. Wil ik eigenlijk wel weten, als klant zijnde…
De eerste stap is wellicht uitvoerbaar, maar daarna? Het rollenprobleem is geen IT-probleem, de oplossing is dus autorisaties bundelen en de business request based rollen laten ‘kopen’.
Het grootste probleem is in de praktijk niet de rollenmatrix, hoe onzettend moeilijk dit ook moge zijn, maar de toekenning van users aan rollen. Daarom dat RBAC projecten na een ‘vliegende start’ altijd stoppen; niemand weet stap twee.