Patroon voor access management
- Onderdeel van
- Thema's
- Contact
- Guus van den Berg
- Guus.vandenberg@cip-overheid.nl
- Status
- Dit thema wordt momenteel opnieuw bekeken door de Expertgroep Beveiliging
Criteria
Vertrouwelijkheid, Integriteit, Controleerbaarheid
Context
Binnen iedere organisatie moet de toegang tot informatie beperkt worden tot personen of systemen die geautoriseerd zijn om de informatie in te zien of te kunnen wijzigen. Daarbij wordt veelal onderscheid gemaakt naar medewerkers (zowel intern als extern), klanten, (zaken)partners en individuen in andere rollen. Onderstaande figuur schetst de omgeving waarin toegang verleend wordt tot het IT-middel.
Probleem
De geschetste problemen uit het themapatroon worden hieronder toegelicht:
- Samenhang ontbreekt in registraties van identiteiten en hun toegangsrechten.
- Need to know dilemma. Starre rollenmodellen werken contraproductief. Vaak wordt gebruik gemaakt van Role Based Access Control (hierna RBAC). Het definiëren van een rollenmodel is lastig, omdat medewerkers op basis van de toegewezen rollen enkel de toegangsrechten toegewezen dienen te krijgen die zij nodig hebben om hun taken te vervullen (Need to know). Wordt er te ‘ruim’ geautoriseerd, dan ontstaan er risico’s van ongeoorloofde toegang, maar een te ‘strikt’ ingeregeld rollenmodel zorgt voor een ‘explosie’ van rollen waardoor een onwerkbare situatie ontstaat.
- Definiëren van toegangsrechten is een moeizaam en langdurig proces. Organisaties zijn bovendien geen ‘vaste structuren’. Reorganisaties volgen elkaar vaak sneller op dan de doorlooptijd van het samenstellen en doorvoeren van een bedrijfs-rollenmodel. RBAC implementaties worden veelal ervaren als ‘in beton' gegoten structuren van toegangsrechten die te wensen overlaat aan flexibiliteit. Dit probleem en het ‘need to know’ dilemma hebben tot gevolg:
- Het IT-landschap wordt maar gedeeltelijk (rol-) gemodelleerd.
- Rollenmodellen lopen achter bij de werkelijke situatie.
- Organisaties onderscheiden (te) veel rollen; soms meer rollen dan medewerkers!
- Deze effecten veroorzaken inefficiënt toegangsbeheer of zelfs het ‘vastlopen’ van IAM-projecten.
- Management heeft geen overzicht en inzicht in verstrekte toegangsrechten aan medewerkers. Management is niet adequaat om toegangsrechten op maat te verlenen of in te trekken.
- Procedures en/of technieken ontbreken om vast te stellen tot welke gegevens subjecten zich toegang hebben verschaft en in hoeverre dit in strijd is met bedrijfsregels (beleid).
- Inspanning voor handmatige uitvoering van wijzigingen wordt te groot. Het aantal wijzigingen is te groot voor handmatige invoering van identiteiten en toegangsrechten van subjecten op elk individueel systeem (IT-middel).
- Toegangsrechten worden niet ingetrokken wanneer medewerkers deze voor hun werk niet meer nodig hebben, of wanneer ze de organisatie verlaten.
Oplossing
Voor de geschetste problemen 1 t/m 8 zijn verschillende oplossingen mogelijk die een systematische aanpak opleveren. Niet alle problemen zijn met techniek op te lossen zoals 1, 2, 5 en 8, maar kunnen qua impact worden gereduceerd door faciliterende technische maatregelen. Een systematische aanpak vraagt per informatiesysteem een methode, waarmee bepaald wordt hoe de toegangsrechten verdeeld worden over de betrokkenen. De bekendste methoden zijn: DAC, RBAC en MAC. Voor autorisatieprofielen worden op de gegevenslaag deze drie methoden gebruikt, waarbij in de praktijk mengvormen voorkomen in één en dezelfde onderliggende infrastructuur.
- Directe koppeling van subjecten aan acties op objecten (DAC).
- Aan de hand van rollen. Identiteiten vervullen één of meerdere rollen in een organisatie. Bij elke rol hoort een set toegangsrechten (RBAC).
- Op basis van classificatie van gegevens (MAC). Subjecten krijgen een clearance-label toegekend, oftewel een formeel vertrouwensniveau (geheim, zeer geheim of confidentieel). Gegevens zijn in een organisatie die MAC gebruikt op dezelfde wijze geclassificeerd en gelabeld.
Op de technologielaag ontwikkelt zich een nieuwe methode: ABAC. Aanvullend op Access Control wordt Access Governance (AG) toegepast, waarmee achteraf kan worden bepaald welk subject toegang heeft gehad tot welke objecten. De volgende technologie methoden worden toegepast:
- Aan de hand van regels (bedrijfsregels, bijv. grenswaarden: max. transactie 20k Euro voor rol R);
- Aan de hand van beweringen (assertions) over attributen van een subject wordt een certificaat, verstrekt door een vertrouwde derde partij) via Attribute/Assertion Based Access Control (ABAC)
- Op basis van de context (bijvoorbeeld: subject is geauthenticeerd met 2-factor authenticatie; gebruiker werkt remote, de gebruiker die de transactie heeft ingevoerd, mag hem niet goedkeuren);
- Op basis van de content (bijv: een gebruiker mag alleen klanten van de eigen vestiging behandelen)
Methode 1: DAC: Discretionary Access Control
Iedere applicatie, bestand of dataset heeft een eigenaar. Ieder te beveiligen object heeft zijn eigen repository. De data-eigenaar vult de repository voor zijn object met de toegangsrechten van de geautoriseerde subjecten. Bij een functieverandering verwijdert of wijzigt de eigenaar de rechten van het subject. DAC wordt geïmplementeerd via Access Control Lists (ACL), vaak afgebeeld in applicatie matrices. Toegang tot objecten is gekoppeld aan de identiteit van een subject. Er is dus een directe toegangsrelatie van subject naar object.
DAC wordt beheersbaar door subjecten in te delen in klassen (class) of kringen; (b.v. owner, group, system, world). De toegangscontrole in Unix, VMS en PC-Windows werkt op deze basis. Permissies worden verleend als: No access, Read, Write, Change en Full Access. In dit model wordt bij een verandering van de functie van de betrokkene de rechten van de persoon (of systeem) in de repository rechtstreeks gewijzigd.
Methode 2: RBAC: Role Base Access Control
Toegang wordt centraal geregeld, aan de hand van vastgestelde regels, die aangeven hoe subjecten en objecten interacteren. Toegang tot objecten wordt verleend op basis van de rol die een subject heeft binnen een organisatie. Omdat er geen directe koppeling is tussen subject en object, wordt RBAC ook wel Non-discretionary Access Control genoemd. Hieronder is het RBAC principe geschetst. Een rol is een afspiegeling van de taken van een subject op een bepaald moment en is daarmee een afspiegeling van de autorisaties die iemand heeft. Een rol is applicatieoverstijgend en bestaat zelfstandig. Een subject vervult één of meerdere rollen in een organisatie. Vanuit een specifieke rol in het bedrijfsproces krijgt hij toegang tot IT-functies, uitgevoerd door IT-middelen. Rollen zijn bedoeld om toegewezen te worden aan meerdere subjecten.
Het vaststellen van autorisaties van een rol binnen RBAC kan in twee richtingen: bottom-up en top-down. De bottom-up methode gebruikt bestaande autorisaties en groepeert deze tot rollen. Dit wordt bij voorkeur geautomatiseerd uitgevoerd en wordt role-mining genoemd. De top-down aanpak gaat uit van de bedrijfsprocessen. Vanuit een bedrijfsproces wordt afgeleid welke autorisaties minimaal nodig zijn om een bepaalde taak uit te voeren. Beide methoden hebben specifieke voor- en nadelen. Role-mining is relatief onnauwkeurig en vergt voor controle op de juistheid van de verkregen rollen alsnog een zekere ‘top-down’ aanpak. De top-down methode kan in de praktijk van grote organisaties een zodanig lange doorlooptijd hebben, dat het verkregen rollenmodel al weer achter loopt op de realiteit van snel veranderende organisaties. Beperk daarom het aantal rollen tot wat absoluut noodzakelijk is.
Methode 3: MAC: Mandatory Access Control
Centraal wordt geregeld, dat subjecten toegang hebben tot gegevens met een classificatie (label) van maximaal het subjectgebonden ‘vertrouwensniveau’ (clearinglevel). Het label is een attribuut dat behoort tot het subject. Elk afzonderlijk dataobject heeft een attribuut. De gezamenlijke repository van de toegangsregels wordt beheerd door de verschillende eigenaren van IT-middelen én datasets.
MAC verleent het subject toegang tot objecten op basis van Clarence level labels, die worden vergeleken met overeenkomstige classificatie labels van de subjecten. MAC verleent toegang tot geclassificeerde data, tot maximaal het vertrouwensniveau wat aan het subject is toegekend. Zowel het subject als object bezit labels, die wanneer ze voldoen aan de bedrijfsregels, toegang geven tot IT-middelen en gegevens. MAC is bedoeld voor het verwerken van geclassificeerde gegevens en kan op verschillende manieren worden ingevuld, b.v. met RBAC, maar ook met ABAC.
Implementatie ABAC: Attribute/Assertion Based Access Control
Deze vorm van Access Control is een techniek om DAC, RBAC of MAC te kunnen implementeren. In ABAC worden toegangsrechten geassocieerd met een set van regels, die zijn uitgedrukt in meetbare parameters of attributen; die vervolgens worden toegekend aan subjecten die kunnen bewijzen dat zij voldoen aan de regels. ABAC, geeft dus toegang tot IT-diensten op basis van een bewering over de eigenschappen (attributen) van de dienstaanvrager (subject). De attributen kunnen allerlei formaten of gedaantes hebben: groepen, rollen, clearance levels, context etc. ABAC past in een omgeving, waar de eigenaar van het object de identiteit van het subject niet exact kent, zoals het internet of een gefedereerde omgeving. Bepaalde kenmerken worden gebruikt om te bepalen of iemand toegang krijgt zonder de identiteit eerst vast te stellen. Die kenmerken kunnen geborgd zijn in certificaten of tokens uitgegeven door een derde partij.
Implementatie AG: Access Governance
Access Governance, hierna afgekort met AG, is geen methode van Access Control, maar een aanvulling op DAC, RBAC, MAC of implementaties van ABAC en stelt het management in staat om de reeds toegekende rechten geautomatiseerd en detectief te beheersen. In snel veranderende organisaties, die toegang verlenen op basis van DAC, of die de vereiste autorisatieregels niet voldoende fijnmazig kunnen implementeren in RBAC of A/CBAC, kan Access Governance (AG) worden toegepast. Dit is een systeem, dat in plaats van de toegang proactief te regelen op basis van Need-to-know, reactief bepaalt of subjecten op basis van verleende autorisaties toegang hebben gehad tot IT-services, waar ze gelet op verleende autorisaties en bedrijfsregels toegang toe zouden mogen hebben. AG is dus controle achteraf.
De meerwaarde van AG is vooral de menselijke tussenkomst. Als bij AG vals alarm geslagen wordt, dan kan dat via een handmatige nacontrole of in overleg met de gebruiker recht gezet worden. Access Control is echter absoluut en onjuiste afkeuring leidt tot onnodige hinder. AG controleert toegang aan de hand van bedrijfsregels. Dit zijn meetbare parameters, afgeleid van autorisatiematrices, de inrichting van IT-systemen en de beheerprocessen voor logische toegang.
We onderscheiden twee soorten bedrijfsregels:
- Generieke Bedrijf Regels (GBR’s): Generieke bedrijfsregels omvatten de toetsingscriteria die zijn afgeleid vanuit het generieke informatiebeveiligingsbeleid van de organisatie. Deze regels zijn van toepassing op meer dan één specifiek IT-systeem. Voorbeeld van een GBR: “Accounts zijn herleidbaar tot een natuurlijk persoon”.
- Specifieke Bedrijf Regels (SBR’s): Per IT-systeem worden bedrijfsregels gedefinieerd die specifiek voor het betreffende systeem van toepassing zijn. De regels worden opgesteld vanuit autorisatiematrices (indien aanwezig) en stellen eisen t.a.v. van het beheersen van functiescheidingen en van het afschermen van kritieke functies. Voorbeeld van een SBR: “Een gebruiker met autorisatie PQR mag geen toegang worden verleend tot een systeem waarvoor autorisatie XYZ nodig is”.
AG kan voor het oplossen van probleem 5 en 6 worden gecombineerd met RBAC of CBAC.
Architectuur
Onderstaande figuur schetst de bouwblokken van een architectuur voor verschillende vormen van Access management. Links een per IT-middel (DAC) en rechts een centraal geregelde methode van Access Management. In mengvormen van DAC en MAC wordt IdM vaak ook buiten het IT-middel geregeld, al dan niet gebruikmakend van een Authentication Service zoals Kerberos.
Architectuur voor intern geregelde toegang tot IT-middelen
Deze figuur schetst de generieke opzet voor AM op basis van RBAC of CBAC. Deze opzet is tevens geschikt voor web-based toegang en kan worden uitgebreid met toegang tot systemen van een externe vertrouwde partij ( zie Patroon voor federatie van identity management).
In het Policy Administration Point vindt het beheer van de autorisaties plaats. Het gaat hier om beheer van z.g. access-policies, of anders gezegd: de Toegangsregels en Criteria. Die policies bestaan uit wachtwoordconventies, authenticatie methode voor specifieke resources en kenmerken die een gebruiker moet hebben voor autorisatie tot een resource. De Criteria en Toegangsregels waaronder een bepaalde toegang kan worden verleend wordt uitgedrukt in XACML statements en worden opgeslagen in een daarvoor geschikte Policy Repository.
De toegang wordt verleend in de volgende stappen:
- De Authenticatie Service verzorgt de authenticatie van de medewerker in het Intranet en treedt tevens op als Kerberos server.
- De gebruiker logt via de Authenticatie Service in op zijn IT-account met behulp van een wachtwoord (of bedrijfspas + Pincode). Dit authenticatieproces heet PKInit. Het resultaat is een Kerberos ticket op de client van de medewerker (pijl 4).
- Als een gebruiker een middel (resource) wil gebruiken dat vraagt om een SAML-token, dan kan de gebruiker het benodigde SAML-token verkrijgen bij de Identity Federation Service. Deze Identity Federation Service treedt in dat geval op als Security Token Service en voert een protocolconversie van Kerberos naar SAML uit (pijlen 5 en 6).
- Voor het plaatsen van additionele informatie over de medewerker in het SAML-token kan de Identity Federation Service via LDAP informatie ophalen uit het Policy Information Point (pijl 16).
- Het verzoek om toegang van de gebruiker komt binnen bij het Policy Enforcement Point (PEP) (pijl 7).
- Het PEP bevraagt het Policy Decision Point (PDP) of de desbetreffende gebruiker toegang kan krijgen tot het gevraagde IT-Middel (pijl 8).
- Het PDP raadpleegt het PIP en het Policy Administration Point (PAP) en ontvangt de relevante toegangsregels uit de Policy Repository (pijlen 9,10 en 11).
- Als het PEP van de PDP verneemt dat de gebruiker toegang tot het IT-middel mag krijgen, dan wordt die verleend (pijl 12).
Afwegingen
Bepalende factoren bij de keuze van de Access management methodes zijn de omvang van de organisatie en het belang dat gehecht wordt aan de granulariteit van de autorisaties van subjecten. De tabel geeft aan welke van AM-problemen (1 t/m 8) kunnen worden opgelost door de verschillende methoden van toegang. Wat opvalt is de relatief slechte score van DAC en RBAC, wat overigens wel de meest toegepaste methoden zijn. ABAC is een veelbelovende implementatievorm van DAC, RBAC of MAC, maar de sortering van ondersteunende tools daarvoor is nog beperkt. MAC vereist dat IT-componenten labeling van gegevens ondersteunen, voor zowel input, verwerking als output van gegevens. Voorts moeten aan gebruikers van geclassificeerde gegevens via MAC systemen vertrouwensniveaus worden toegekend. AG is geen Access Control, maar een veelbelovende methode om via ‘intelligence’ achteraf te kunnen bepalen wie toegang heeft gehad tot welke resources. Ondersteunende tools daarvoor zijn beperkt leverbaar.
| Nr | Welk probleem kan worden opgelost met AM-methode | DAC | RBAC | MAC | ABAC | AG |
|---|---|---|---|---|---|---|
| 1 | Need to know dilemma van een strikt ingeregeld rollenmodel | √ | - | nvt | nvt | nvt |
| 2 | Definiëren toegangsrechten is een moeizaam en langdurig proces | - | - | √ | √ | nvt |
| 3 | Samenhang van registraties voor IdM en AM ontbreekt | - | √ | √ | √ | nvt |
| 4 | Management heeft geen overzicht in verstrekte toegangsrechten | √ | √ | √ | √ | √ |
| 5 | Management is niet adequaat voor verlenen/ intrekken van rechten | - | - | √ | √ | √ |
| 6 | Ongewenste toegang tot gegevens wordt niet opgemerkt | - | - | √ | - | √ |
| 7 | Aantal wijzigingen te groot voor handmatig aanbrengen | - | √ | √ | √ | √ |
| 8 | Toegangsrechten worden niet tijdig ingetrokken | - | √ | √ | √ | √ |
- DAC geeft de eigenaar van het object rechtstreeks invloed op wie toegangsrechten krijgt tot de applicatie. Dit is voor systemen met gevoelige informatie een pluspunt. Een arbeidsintensieve methode, waarvan de beheerinspanning exponentieel toeneemt bij het groeien van het aantal objecten en subjecten. Problemen 4 t/m 8 kunnen worden opgelost in combinatie met AG.
- RBAC: Een doelmatig ingericht RBAC-systeem vereenvoudigt het toekennen en intrekken van autorisaties aanzienlijk. Voorwaarde van succes met RBAC is beperking van het aantal rollen. Richtgetal: 100 rollen voor organisaties van 5000 medewerkers. Soms moeten daarvoor compromissen gesloten worden, die tegen het ‘need-to-know’ principe ingaan. Een nadeel van RBAC is het arbeidsintensieve proces voor het bepalen van rollen. Dit kan worden versneld door rolemining toe te passen. Een ander nadeel is dat vooral oudere systemen geen RBAC ondersteunen, waardoor er procedures nodig zijn voor uitzonderingen.
- MAC biedt oplossingen voor alle generieke Access management problemen, maar wordt vanwege de vergaande consequenties voor organisatie en techniek slechts beperkt toegepast. Security Enhanced Linux (SE-Linux) is speciaal ontwikkeld voor MAC en biedt goede kansen voor de toekomstige implementaties. De aanpassingen die in de Linux-kernel nodig zijn om SE-Linux te kunnen draaien, zijn in de bekende distributies geïmplementeerd.
- ABAC is een technologie gebaseerd op SAML om DAC, RBAC of MAC mee te kunnen implementeren. Het is ontwikkeld voor een omgeving, waar de eigenaar van het object de identiteit van het subject niet (exact) kent en is bedoeld voor webservices en internet toepassingen. ABAC is door toepassing van niet-bedrijfsgebonden attributen conventies tevens geschikt voor federatieve toepassingen. Voor ABAC geldt ook een beperkte ondersteuning van bestaande en oudere IT-platformen.
- AG is geen Access management, maar een aanvulling daarop. Het is een relatief nieuwe aanpak en technologie. AG is ontwikkeld om alle gangbare Access Control methoden eenvoudig te kunnen monitoren, gericht op het oplossen van problemen 4 t/m 8. Alvorens vanuit een bestaande situatie met DAC te kiezen voor RBAC, dient aanvulling met AG serieus te worden overwogen.