Role Based Access Control
Iedereen krijgt dagelijks met Access control te maken. Of het nu gaat om een deur waar je geen sleutel van hebt, een systeem waarin je alleen maar bestanden kunt lezen of een bord dat zegt dat je ergens niet mag komen. Access control is een wijd begrip, maar kort gezegd bepaalt het wie er toegang tot een systeem krijgt.
Om dit te bereiken moet er eerst bepaald worden welke gebruikersgroepen er zijn, wat voor rechten ze hebben en wie van deze groepen deel uitmaakt. De eerste stap binnen access control is het opstellen van een raamwerk waarin alle rechten en gebruikers binnen het systeem bepaald zijn. Dit kan bijvoorbeeld via Access Control Lists. Access control lists zijn letterlijk tabellen waarin staat wat een gebruiker met een bestand, map of applicatie mag doen. Microsoft heeft een aardig presentatie waarin ACL's worden uitgelegd.
De oplossing voor dit probleem heet RBAC: Role Based Access Control. RBAC is ontworpen door het Amerikaanse National Institute of Standards and Technology (NIST). Met deze techniek worden permissies gekoppeld aan rollen en rollen aan gebruikers. Het beheren van zo'n systeem bestaat dus uit het beheren van de rollen (en functies) van gebruikers en het beheren van permissies van rollen.
Role Based Access Control
Administratieve lasten
Gewoonlijk is er een directe relatie tussen de beheerkosten en het aantal permissies dat uitgedeeld moet worden per gebruiker. In de meeste organisaties zal het gebruiken van een RBAC dan ook de beheerlasten omlaag laten gaan: het aantal te beheren permissies is lager.
Betrouwbaarheid
Doordat permissies niet meer worden uitgedeeld op persoonsniveau maar zijn gekoppeld aan rollen / functies en de taken die daarbij horen, is het beheren van de permissies eenvoudiger. Doordat minder handelingen hoeven te worden verricht voor het wijzigen ervan is de kans op fouten ook kleiner. Dit heeft een betrouwbaardere autorisatiestructuur tot gevolg.
Uitgangspunten:
- Een RBAC systeem moet het mogelijk maken rollen, gebruikers en permissies op te slaan in een database.
- Een gebruiker moet aan meerdere rollen kunnen worden gekoppeld.
- Het systeem moet het principe van "Separation of Duty" (dit is het principe dat bepaalde taken door minimaal twee personen moeten worden uitgevoerd ter voorkoming van fraude) ondersteunen.
- Het systeem moet gebaseerd zijn op bestaande technologiën.
- Het systeem moet overerfbaarheid (inheratance) ondersteunen. /li>
- Als een gebruiker aan meerdere rollen is gekoppeld en de permissies bij deze rollen conflicteren met elkaar, dan gaat de laagste permissie boven de hoogste (bijvoorbeeld geen toegang gaat voor wel toegang).
- Het systeem moet alle wijzigingen op en toekennen van rollen vastleggen in een log bestand.
- Het systeem moet gegroepeerd een overzicht van alle permissies gekoppeld aan een gebruiker kunnen laten zien.
- Het systeem moet een overzicht van alle gebruikers met een bepaalde permissie (gekoppeld aan een rol) kunnen laten zien.
- Het systeem moet een beheerders interface hebben voor toevoegen/wijzigen/verwijderen van rollen, permissies en gebruikers en voor het toekennen van permissies aan rollen en rollen aan gebruikers.
- Een rol moet in staat zijn aan één of meerdere "groepen" op de te beheren systemen te koppelen.
- ”Gebruikersobjecten” zijn mensen, applicaties, apparaten of functies.
- Met rollen worden systeem rechten bedoeld waarop twee criteria van toepassing zijn:
- Systemen die functioneel gezien bij elkaar horen zijn in één groep geplaatst..
- Permissies die geschikt zijn voor bepaalde gebruikersgroepen zijn samengevoegd.
- Het modelleren van een RBAC-model kan op drie verschillende manieren:
- “Bottom Up” - door de rollen vast te stellen aan de hand van reeds aanwezige groepen en permissies op de te beheren systemen.
- “Top Down” - door de rollen vast te stellen aan de hand van een analyse van business processen en andere eisen.
- “Hybrid” - door de rollen middels een combinatie van Top Down en Bottom Up methodes vast te stellen.
- De Top Down benadering is het moeilijkste te implementeren omdat het waarschijnlijk resulteert in een groot aantal wijzigingen op reeds aanwezige groepen en permissies.
- De Bottom UP benadering is eenvoudiger te implementeren omdat het van het reeds aanwezige groepen en permissies model uitgaat.
- Meestal is de meest succesvolle aanpak voor modellering de Hybride benadering.
- Het doel van modelleren is een maximale flexibiliteit te bereiken met een minimum aan administratieve lasten.
- Het delegeren van beheer op gebruikers, rollen en permissies moet worden meegenomen in het modellerings proces. Een sterk gedecentraliseerd model (met veel gedelegeerde verantwoordelijkheden) kan het beste met de Top Down benadering worden vastgesteld.
- Vastleggen van rollen met een Top Down benadering zorgt voor het samenvoegen van business processen in organisatie parameters.
- Een Top Down benadering is alleen succesvol als alle business units zich conformeren aan het systeem.
- Een Rol wordt normaliter gekoppeld aan een groep op het te beheren systeem.
- De succesvolle implementatie van een RBAC systeem is afhankelijk van een goede analyse van te verdelen permissies.
- Een Rol heeft geen zin als er geen permissies mee worden verdeeld.
- Zorg voor jaarlijkse controle van het model.
- De beste manier om het model te controleren is met behulp van "what ... if" scenario's en het doorlopen van cases.
Een RBAC systeem levert dus met minder kosten een betrouwbaardere ICT op. De berekening waarmee kan worden bepaald of het inzetten van RBAC een voordeel oplevert staat hieronder:
Meer informatie:
Een uitgebreide introductie, praktijkvoorbeelden, kosten-baten analyse en een "referentie implemenatie" van een RBAC webserver voor UNIX en Windows NT zijn te vinden op deze pagina.
Het NIST heeft ook een presentatie online staan waarin RBAC besproken wordt, inclusief duidelijke praktijkvoorbeelden.
RBAC is inderdaad niet zo zeer een revolutionair nieuw idee,
maar de praktijk is dat dit soort dingen nauwelijks gebruikt
worden. Dat RBAC een Goed Idee is wisten we al, maar een
onderzoek naar de reden waarom het bijna nergens toegepast
wordt, en wat er moet veranderen om te zorgen dat het wel
gebruikt gaat worden lijkt me nuttiger.
te maken gehad, op MVS en VM/370
sudo kan het ook al jaren
het NIST heeft niets nieuws ontdekt/ontwikkeld... wellicht
alleen met nieuwe namen opgeschreven met referentie naar
huidige tijd en technieken
bron, want NIST stelt als bron "Role based access control (also called
role based security), as formalized in 1992 by Ferraiolo and Kuhn".
Ik lees trouwens niets over de rol van de afdeling personeel, die beheert
meestal functie omschrijvingen en de IT kan dan de groepsprofielen
creeëren die bij het functieprofiel hoort.
concept nu toch echt wel behoorlijk achterhaald vanuit een
security oogpunt. ABAC lijkt veel
hoopgevender wat dat betreft:
http://video.google.nl/videosearch?q=Authorization-Based+Access+Control
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
