Volledige Toegangscontrole – deel 2

Deel 2: OAuth Scopes werken magisch

In deel 1 heb ik de ambitie geschetst voor een systeem dat toegang op bedrijfsniveau beheert. In veel gevallen gebruiken verbindingen met digitale bronnen iets dat een application programming interface (API) wordt genoemd. In dit laatste deel onthul ik hoe je zo’n toegangsbeheersysteem kunt in kaart brengen en bouwen. Dit vereist een nauwe samenwerking tussen je Identity Provider en je API Gateway. Het vereist ook een API-First mindset. Beide zijn tegenwoordig vrij eenvoudig en krachtig. En het beste van alles is dat ze gemakkelijk te schalen zijn – zelfs over hybride clouds en verschillende technologieën heen. Ten slotte neem ik je mee op een droomreis. Veel leesplezier!

Het mogelijk maken

Om volledige controle te hebben over de toegang tot je digitale activa, op elke schaal, zonder de bank te breken en zonder je flexibiliteit te verliezen, is een duidelijke scheiding van verantwoordelijkheden de beste optie. Conceptueel zijn er slechts een paar soorten componenten te beheren: Identity Providers en API Gateways. Er zijn ook een paar soorten belanghebbenden: Informatiebeheerders, Personeelsmanagers, Lijnmanagers en Auditors. Als je die binnen je informatielandschap op elkaar afstemt, ben je goed op weg naar volledige toegangscontrole.

Ik wil beginnen waar je digitale activa worden beheerd. Laten we eerst afspreken dat al je gegevens op de een of andere manier door software worden verwerkt, of het nu een tekstverwerker, een website, een workflow management systeem of een ERP-systeem is. Dus als je de toegang tot deze activa wilt beheren, moet je ervoor zorgen dat toegang alleen mogelijk is via de software die je beheert. Dit kan al een aantal maatregelen vereisen. Op netwerkniveau (herinner je Solarwinds nog?), op databaseniveau (vergeet niet je back-ups te versleutelen) en op fysiek niveau (bewaar die tapes achter goed gesloten deuren). Immers, wat heeft het voor zin om te investeren in het beveiligen van toegang tot gegevens in de database als de back-ups vrij toegankelijk zijn? Allemaal vrij standaard cybersecurity zaken. Vooral in cloud computing zullen de bekende cloud-native principes je begeleiden bij het inkapselen van je digitale activa binnen je diensten.

Vervolgens wil je ervoor zorgen dat toegang tot deze diensten alleen mogelijk is via goed gedefinieerde interfaces met behulp van industriestandaard protocollen. Ja, ik heb het over APIs. Het maakt niet uit welke stijl je implementeert, REST, AsyncAPI, GraphQL of een andere smaak, het belang is dat je de toegang tot je digitale middelen buiten de service die het implementeert kunt beheren. Dit is uiteraard belangrijk, omdat het de beste manier is om:

• Consistent gedrag te creëren
• Overzicht te behouden
• Proliferatie van beheer- en governance-inspanningen te vermijden

Daarom zijn gebruikersaccounts, applicaties en permissies allemaal digitale activa die je op bedrijfsniveau zou moeten beheren. Sta je mensen de luxe toe van één identiteit met één set inloggegevens, die al hun digitale behoeften bedient. Ik weet, misschien beter dan de meeste mensen, dat dit makkelijker gezegd dan gedaan is. Tegelijkertijd weet ik dat de authenticatie- en autorisatiestandaarden enorm zijn verbeterd, en een slim gebruikte Identity Integration Hub is een krachtig hulpmiddel om al je identiteits- en toegangsbeheeronderdelen samen te voegen.

Effectief de last van management aanpakken

Zodra je toegang hebt tot je digitale activa via APIs, heb je de optie om een API Gateway te gebruiken om toegang tot je APIs en daarmee tot je digitale activa te controleren. Klopt, een API Gateway is een waardevol hulpmiddel om toegang te controleren. Hoe? Nou, toegangscontrole bouwt voort op autorisatie, autorisatie bouwt voort op authenticatie en authenticatie bouwt voort op identificatie. Een API-specificatie kan worden gebruikt om het vereiste authenticatiemechanisme te definiëren. Kijk eens naar dit fragment:

securitySchemes:
    JWT:
      description: OAuth2 JWT bearer token assertion
      type: OAuth2
      scheme: bearer
      bearerFormat: JWT

Dit fragment definieert effectief dat je de API alleen kunt benaderen met een ID-token als authenticatie. Dit is geweldig, omdat je de handtekening van de JWT kunt valideren (om vast te stellen dat het een origineel token is) en dus de inhoud van de JWT kunt vertrouwen. Bovendien kun je de inhoud gemakkelijk gebruiken voor een autorisatiedoel. Daar komen de OAuth-scopes om de hoek kijken. Hoewel dit nog niet veel wordt toegepast, kunnen OAuth-scopes echt magisch werken bij het controleren van toegang tot je digitale activa.

security:

  - ApiKeyAuth: ["account.read", "finance.supervise"]

Deze formele definitie stelt dat alleen gebruikers met ten minste één van de scopes “account.read” of “finance.supervise” in de “scopes” sectie van hun JWT toegang hebben tot de API-resource. Het is ook een eenvoudige verklaring voor de API Gateway om af te dwingen. En het werkt ook geweldig vanuit een beheersperspectief.

Een software-token kan worden vergeleken met de plastic sleutelkaart die je krijgt om je hotelkamer binnen te gaan. Beide geven toegang tot een bron, beide kunnen ongeldig worden verklaard, en beide zijn voorbeelden van autorisatie – je hebt toegang tot de bron zolang je token of kaart nog geldig is. Eén sleutelkaart kan toegang geven tot meerdere kamers. Evenzo kan een software-token een aantal scopes bevatten. Je kunt andere eigenschappen toevoegen om de beveiliging te verbeteren. Bijvoorbeeld, je kunt een foto op een sleutelkaart afdrukken, je kunt een hotel in verschillende zones verdelen. Met een JWT kun je ook handig informatie toevoegen. Bijvoorbeeld, de Authentication Context Class Reference geeft de betrouwbaarheid van de authenticatie aan. Je kunt dit gebruiken om ervoor te zorgen dat basisauthenticatie je alleen toegang geeft tot basisinformatie.

Door deze scopes te definiëren (je bent vrij om je eigen scopes te definiëren zoals je wilt), definieert de eigenaar van de API expliciet het machtigingsniveau dat nodig is voor toegang tot de resource. Vervolgens kun je de scope binden aan een of meer gebruikersgroepen of gebruikersrollen. Dit is de verantwoordelijkheid van een access manager. Iemand met het overzicht om laag-niveau permissies logisch te groeperen in hoger-niveau rechten die zinvol zijn in een organisatie. Ten slotte moet een lijnmanager de rol toewijzen aan iemand in zijn lijn die het eigenlijke werk doet. Dit brengt scheiding van taken op het juiste niveau. Tegelijkertijd is het zeer schaalbaar en eenvoudig te organiseren. Het past goed in microservice-architecturen en een agile manier van werken. Het is eenvoudig te auditen. Wat valt er niet te houden?

Whitepaper De Keuzegids Voor Identity and Access Management

Wil je jouw Identity and Access Management gelijk vanaf het begin goed regelen?

Nu downloaden

Onlangs heb ik een vrij complex systeem ontworpen voor het uitwisselen van informatie tussen overheidsinstanties en burgers. Begrijpelijkerwijs was beveiliging een belangrijke drijfveer voor het ontwerp. Burgers kunnen alleen toegang krijgen tot de informatie die naar hen is verzonden, en overheidsinstanties kunnen alleen informatie sturen naar burgers die vooraf toestemming hebben gegeven. Bovendien kunnen burgers andere burgers gemachtigd toegang geven tot specifieke delen van hun informatie. Evenzo kunnen overheidsinstanties organisaties aanwijzen om hen te vertegenwoordigen.

Ik heb het gehele systeem ‘API-First’ ontworpen, waardoor elke ‘resource’ kan worden blootgesteld via een API Gateway. Dit is ons belangrijkste punt van toegangscontrole geworden. Daarnaast hebben we een beheerdersportaal gecreëerd waarin overheidsinstanties hun eigen gebruikers en vertegenwoordigingen kunnen beheren en autoriseren. In een ander portaal beheren burgers hun delegaties. Alternatief kunnen ze ervoor kiezen om een mobiele app te gebruiken.

Onze Identity Provider genereert een OpenID Connect-token dat alle informatie bevat die de API Gateway gebruikt om toegang tot alle resources te controleren, inclusief de APIs om gebruikers en hun autorisaties te beheren (OpenID Connect Scopes). Nu het systeem in werking is, lijkt de beveiliging bijna moeiteloos. De beheerslast is laag, de prestaties zijn hoog, terwijl de handhaving solide en volledig transparant is. Het is ook gebaseerd op industriestandaarden, wat zorgt voor toekomstige onderhoudbaarheid, onder andere.

Kantoorapplicaties

Nu vraag je je misschien af hoe je je kantoorapplicaties en dergelijke kunt beschermen? Ze gebruiken tenslotte geen API die je kunt beheren om toegang te krijgen tot bestanden op je netwerk. Ze zijn een geïntegreerde gebruikersinterface en backend-applicatie. Een loutere monoliet. En gebruikers kunnen die bestanden openen met software die je niet kunt controleren.

Hoewel ik niet denk dat deze oudere architecturen binnenkort zullen verdwijnen, zie ik toch enkele hoopvolle tekenen. Vooral in cloud-native applicaties, waar er een elegante oplossing is voor dit probleem. Een eenvoudige opslagoplossing die is ontworpen als een netwerk-API. Er is zoveel te waarderen aan de AWS S3-service dat alternatieve implementaties zoals Minio en S3Proxy overal in cyberspace worden gebruikt. S3 is niet precies een bestandsservice, maar een gedistribueerde object store. Het is robuust, veerkrachtig, hyper schaalbaar en vooral, het is een API. Conceptueel is het een kleine stap voor Office-tools om objectopslag toe te voegen als functie. Hek, zelfs de SharePoint API zou zo’n taak kunnen uitvoeren. Zodra we daar zijn, heb je de volledige controle.

Hoe verder met Digitale Governance?

Het is gemakkelijk te voorspellen dat, zodra al je toegangscontrole gecentraliseerd is, governance een belangrijke bottleneck zal worden. En ja, dit zal een heroverweging vereisen. Gelukkig zijn we goed op weg naar een gedistribueerd governance-model. Een model waarbij verantwoordelijkheden worden gedelegeerd, binnen de juiste kaders, zodat de verantwoordelijkheid nog steeds kan worden gewaarborgd. Misschien beter dan ooit tevoren.

Het geheim van digitale governance heet “shift left and shield right”. Dat betekent radicaal delegatie van verantwoordelijkheid naar het laagst mogelijke niveau waar eigenaarschap wordt gevoeld. Geef deze eigenaren tools die hen begeleiden bij het nemen van verstandige beslissingen en het stellen van goede beleidsregels. Zorg ervoor dat, wanneer ze buiten hun kaders gaan, ze goedkeuring nodig hebben van een ‘hogere’ autoriteit. Zorg er ook voor dat deze beleidsregels volledig worden gehandhaafd. Dat is het gedeelte waar shield right in beeld komt. Als je je autorisatiebeleidsregels goed verklaart, kan de digitale infrastructuur ervoor zorgen dat alleen goed geautoriseerde actoren toegang hebben tot je digitale activa. Geen uitzonderingen, geen achterdeurtjes. Gegarandeerd.

Ik heb eerder geschreven over API-beveiliging, 42Crunch, en hoe hun toolset je API-beveiliging versterkt. Dit is nu relevanter dan ooit.

Is dit echt een Panacee?

Nou, eerlijk gezegd niet voor de volle 100%. Er is één categorie digitale activa die we tot nu toe niet hebben besproken. En dat zijn de systemen waarbij de maker van een digitaal actief ook degene is die de toegang tot zijn actief beheert. Echter, hij beheert de toegang buiten de reikwijdte van de toegangsbeheersystemen. Dit doorbreekt de scheiding van taken zoals besproken. Het introduceert ook ernstige problemen – er is geen toezicht op permissies, en autorisaties worden vaak niet goed beheerd. Niet goed.

Typisch gebeurt dit met systemen waarbij documenten, projecten of zaken worden beheerd. Een enkele gebruiker, zoals geïdentificeerd door de identity provider, zal verschillende toegangsniveaus hebben tot verschillende projecten, zaken, accounts in het systeem, op basis van hun betrokkenheid. Standaard kun je niets openen, tenzij de eigenaar van een actief je een “betrokkenheidsrol” heeft verleend.

Fundamenteel gezien is het probleem dat de identificators van deze activumtypes (projecten, zaken, klant-ID’s, mappen) niet worden beheerd in je Identity Provider. Bijgevolg laat je Identity Provider je niet toe om toegang te beheren tot die niet-geïdentificeerde digitale objecten. In mijn ogen is dat logisch. Ten eerste zijn er geen standaarden beschikbaar om een interface voor het beheren van die identificators te creëren. Ten tweede kunnen deze activa zeer dynamisch zijn. Denk aan een IT-servicebeheersysteem, waar (veel) honderden zaken dagelijks worden afgesloten, maar het toegangsniveau van een enkele medewerker tot elke zaak sterk kan variëren.

Je zou OPA — de Open Policy Agent die veel wordt gebruikt in cloud-native omgevingen — kunnen overwegen. Het biedt een moderne declaratieve taal om toegangscontrolebeleidsregels te definiëren. In feite bieden WSO2 API Manager en WSO2 Identity Server beide een OPA-integratie als Policy Decision Engine. Maar het pakt het fundamentele probleem niet aan. Regels zijn gebaseerd op feiten, en de feiten worden beheerd buiten de reikwijdte van de beslissingsengine. Bovendien bezit de dienst die beschermd moet worden de gegevens voor zijn eigen bescherming.

Groot dromen

Laat me even dromen over een potentiële oplossing. Identity Providers bevatten doorgaans een functie om groepen gebruikers te beheren. Je kunt vaak rollen toewijzen aan een groep gebruikers, zodat elk lid van de groep automatisch de permissies van deze rol erft. Wat als we het zo zouden bekijken. Elk project heeft een groep leden, een groep eigenaren en een groep scrum masters. Wat als we die groepen zouden kunnen koppelen aan de betrokkenheidsrollen in het projectmanagementsysteem. We zouden de groepen alleen als een aangepaste claim aan het token hoeven toe te voegen. Bovendien zouden we eenvoudig de SCIM2-standaard als interface kunnen toepassen.

Denk er eens over na. Er zijn veel potentiële voordelen. Vanuit governance-oogpunt zou het veel beter zijn om één punt van administratie van permissies te hebben. Alleen als je een volledig overzicht hebt, kun je ongewenste samenloop van permissies analyseren en aanpakken, bijvoorbeeld. Wanneer iemand van baan verandert, kun je al zijn permissies intrekken. Maar er zijn ook meer praktische voordelen. Wanneer het laatste lid van een actieve “eigenaar”-groep wordt ontslagen, kan automatisch een waarschuwing worden gegenereerd om de vacature in te vullen. Wanneer iemand naar een nieuwe positie wordt overgeplaatst, kunnen hun lidmaatschappen automatisch worden gepland voor herverdeling. Wanneer ze op vakantie gaan, kan toegang tijdelijk worden gedelegeerd. Wanneer een langdurige ziekte toeslaat, kunnen permissies worden herverdeeld. En het allerbeste, geen enkele API zal ooit onbeheerd blijven.

Slotgedachte

Is volledige toegangscontrole haalbaar zonder de bank te breken en zonder flexibiliteit te verliezen? Nou, ja, maar misschien nog niet vandaag. Althans niet in elke organisatie voor de volle honderd procent. Maar je kunt ongetwijfeld een lange weg afleggen, en, onder bepaalde voorwaarden en met enige inspanning, kun je het morgen volledig bereiken. Het kan wat doorzettingsvermogen en hard werk vereisen, je zult misschien enkele hoeken moeten afsnijden of tussenstappen moeten nemen. Maar uiteindelijk zal het de moeite waard zijn. Immers, elke digitale organisatie zou moeten evolueren naar een goed geoliede machine, waarbij beveiliging inherent is geworden.

Waarom niet gelijk vandaag beginnen?

Wil je meer over dit onderwerp te weten komen? Wij zijn er om je te helpen. Neem contact met ons op.