Cqure Platformblog
Het is eindelijk zover, het Amerikaanse NIST heeft een concept standaard op het gebied van autorisatiebeheer gepubliceerd, namelijk NIST SP 800-162 met als titel “Guide to Attribute Based Access Control (ABAC) Definition and Considerations”: De eerste gedachten rondom ABAC bestaan al een poosje en er ontstond eigenlijk wel behoefte aan een NIST standaard. Niet dat er zo hard een standaard nodig was, maar als er een stempel NIST op een standaard wordt gezet, dan betekent dat eigenlijk meteen dat de standaard tot het arsenaal aan instrumenten van de security professional mag worden gerekend.
Waarom ABAC?
ABAC houdt in dat er geen autorisaties aan een persoon worden gegeven op grond van identiteit of plek in een organisatie, maar op basis van attributen van een identiteit. Dat helpt ons niet meteen verder, maar het helpt wel om autorisatiebeheer de cloud in te krijgen. En dat is feitelijk hard nodig, want met de traditionele identity management en access control oplossingen is dat eigenlijk niet meer mogelijk. Kijk maar eens naar het traditionele Role Based Access Control. Als je iemand in RBAC termen wilt autoriseren, dan moet je die persoon een ‘rol’ toekennen en dan krijgt die persoon vervolgens de autorisaties die bij die rol horen. Maar iemand die uit de cloud komt, wie is dat? En welke rol kunnen we die persoon geven? En een tweede beperking van RBAC is dat we de context niet als een beperking mee kunnen geven. Ja, we kunnen wel Rule Based Access Control mechanismen toevoegen, maar er ontstaat dan zeker een wildgroei aan rollen en uitzonderingen daarop.
Waarom ABAC ons de cloud inleidt zal ik proberen duidelijk te maken. In de cloud hebben we namelijk te maken met het feit dat service providers te maken krijgen met digitale identiteiten die door externe Identity Providers zijn verstrekt. Denk aan je DigiD identiteit die door de overheid als IdP wordt uitgereikt en door andere overheidsservice providers wordt gebruikt. Een identiteit die door die service providers wordt vertrouwd ook. Dat is meteen het kernbegrip: Vertrouwen. Een service provider die een identity provider vertrouwt, mag ook de door die IdP verstrekte digitale identiteiten en de attributen van die identiteit vertrouwen. Denk aan een attribuut als e-mailadres, of BSN, of… Leuk klassiek filmpje hierover is de presentatie van Dick Hardt over Identity 2.0.
In geval van ABAC wordt vervolgens op basis van de waarde van een attribuut bepaald of de persoon die een service wil benaderen op basis van zijn identiteitsattributen gerechtigd is om bij een service te komen. Op basis van mijn BSN mag alleen ik mijn eigen WOB-aanslag van mijn gemeente zien.
Dat betekent nogal wat. Er worden nieuwe protocollen gebruikt (denk aan SAML en XACML), er worden nieuwe technieken gebruikt (denk aan policy enforcement points) en er moeten nieuwe autorisatieregels worden ontwikkeld.
Migratie vanaf RBAC is feitelijk niet heel moeilijk. Als je een rol als een attribuut beschouwt, dan ben je al een aardig eind op dreef.
En dat is misschien ook wel het bezwaar tegen de nieuwe NIST standaard. NIST maakt het wel heel moeilijk. Bekijk gewoon afbeelding 3 in de standaard en je hebt het concept eigenlijk wel door. De rest maakt het alleen maar moeilijk.
