Volledige Toegangscontrole

Deel 1: Identiteits- en Toegangsbeheer gedaan op de juiste wijze

Dit is deel één van een tweedelige serie waarin een innovatieve manier wordt besproken om autorisaties te beheren en af te dwingen. Dit deel schetst de ambitie van een bedrijfssysteem om gebruikersrechten te beheren en hun toegang tot informatie te controleren. Het vormt de basis voor deel twee, waarin ik een interessante oplossing presenteer om deze ambitie te verwezenlijken.

De basis leggen

Identiteits- en Toegangsbeheer (Identity and Access Management) is een kernfunctie in informatiebeveiliging. Elke organisatie heeft een manier nodig om eerst de gebruikers van hun informatie te identificeren en vervolgens te authenticeren – of het nu mensen, computersystemen of nieuwe vormen van kunstmatige intelligentie zijn – om hun rechten vast te stellen. Gelukkig zijn er volwassen standaarden zoals OpenID Connect ontstaan, die helpen bij het implementeren van single sign-on en een gemeenschappelijke taal bieden voor de identificatie van die gebruikers.

Identiteit is een middel om iets te identificeren. Je hebt een naam, een burgerservicenummer, een mobiel nummer, een aantal e-mailadressen, die elk als een identificator kunnen worden gebruikt. Niet elke identificator is uniek. In IT-systemen is dat vaak problematisch, dus doen we er alles aan om unieke identificatoren te creëren. Evenzo proberen we te voorkomen dat mensen meerdere identiteiten hebben. Denk aan een patiënt bij een apotheek. Als deze recepten heeft van verschillende artsen onder verschillende identiteiten, kan het gemakkelijk zijn om een schadelijke interactie tussen medicijnen te missen. Met een enkele Identiteit kan er automatisch een waarschuwing worden gegenereerd. Dit vereist zowel een gedeeld als goed beheerd identiteitsysteem. Dit alles is onderdeel van Identiteitsbeheer. Uiteraard zijn er ook nadelen van een gedeelde identiteit, maar dat valt buiten de scope van deze blog.

Authenticatie gaat over het vaststellen van echtheid. Je kunt beweren dat je de persoon bent zoals geïdentificeerd door eves@dropping.it, maar ik heb enig bewijs nodig voordat ik het geloof. Je kunt bewijs delen via iets wat jij en ik beiden weten – een wachtwoord of een andere geheime code –, iets waarvan ik weet dat jij het in je bezit hebt – een geregistreerde app, een telefoonnummer, een e-mailaccount, een privésleutel, een geregistreerd apparaat, een paspoort –, en natuurlijk iets waarvan ik weet dat het jouw lichamelijke kenmerken zijn – vingerafdruk, gezicht, iris, handpalm. Uiteraard moet dit ook worden beheerd. Dingen kunnen veranderen (telefoonnummer), moeten veranderen (wachtwoord), of langzaam evolueren (gezichtskenmerken).

Autorisatie is de reikwijdte van informatie die je mag raadplegen, je toegangsniveau en mogelijk de voorwaarden voor toegang. Conceptueel is het de eenvoudigste van de drie. Echter, het effectief beheren ervan is vaak een uitdaging. Er is zoveel verandering om bij te houden, en er zijn vaak meerdere systemen en actoren betrokken, waardoor het moeilijk is om autorisaties altijd up-to-date te houden. Dat maakt Toegangsbeheer een interessante mogelijkheid.

In IT wordt doorgaans het principe van minste privilege geïmplementeerd, waarbij geen enkele gebruiker toestemming krijgt tenzij deze echt nodig is. Daarnaast moet de toegang tot digitale middelen beperkt zijn tot alleen die middelen waarvoor de gebruiker toestemming heeft. Dit wordt vaak als vanzelfsprekend beschouwd, maar authenticatie, identificatie en autorisatie zijn behoorlijk nutteloos tenzij je directories vertrouwd kunnen worden en je toegang effectief wordt gecontroleerd.

Digitale middelen zijn het weefsel waaruit het wereldwijde web is opgebouwd. Het is de ‘r’ in url, uri en urn. Het is een abstracte term, die erkent dat een locatie op het web kan verwijzen naar elk soort digitaal ding – een beetje gestructureerde data, een document, een dashboard, een sensor, een algoritme, om een paar concrete voorbeelden van middelen te geven.

Met de proliferatie van cloud computing, vooral met sterk gedistribueerde cloud-native architecturen, is dit uitdagender geworden dan ooit. Ja, zero trust wint nog steeds terrein, maar het is ook waar dat het echt toepassen ervan verre van eenvoudig is. Hier is de pessimistische kijk op de wereld de algemeen geaccepteerde norm: neem aan dat niets veilig is tenzij het tegendeel is bewezen. In deze blog presenteer ik enkele frisse ideeën over hoe je je toegangscontrole kunt heroverwegen en zo je zero trust goed kunt krijgen.

Principes

Wanneer je een referentiearchitectuur ontwerpt voor Identiteits- en Toegangsbeheer, is het een goede praktijk om te beginnen met het afstemmen met je stakeholders over het doel van de architectuur. Hoewel details kunnen variëren, zie ik veel organisaties convergeren naar deze drie hoofddoelen:

1. Toestemmingsverlening voldoet aan het principe van minste privilege.
2. Toestemmingen worden altijd afgedwongen zoals verleend.
3. Toestemmingshandhaving kan worden bewezen.

Met andere woorden, je doet een gedurfde belofte, je houdt de belofte, en bevoegde autoriteiten kunnen verifiëren dat je je belofte inderdaad hebt gehouden. Zonder uitzonderingen.

Als je denkt dat dit een te hoge lat is om te halen, lees dan verder. Er is een zeer pragmatische implementatie die ik zo meteen ga uitleggen. Maar eerst moet je de juiste scope begrijpen.

Scope

Het is van vitaal belang om een duidelijke scope vast te stellen voor elke architectuur, en deze is zeker geen uitzondering. Traditioneel, althans in mijn ervaring, omvatte de scope voor Identiteits- en Toegangsbeheer in wezen ‘enterprise applicaties’. Met andere woorden, het was gericht op het beschermen van toegang tot bedrijfsbronnen. En met gesiloode applicaties werkte dat redelijk goed. Met bedrijfsintegratie begonnen de zaken echter gecompliceerd te worden – vooral wanneer systemen werden opengesteld voor integratie door derden. Onlangs is er de toegevoegde complexiteit van gedistribueerde en mobiele netwerken, waardoor virtuele grenzen in je IT-landschap steeds doordringbaarder worden. Hoe beheer je de toegang tot je diensten, middelen, digitale activa, als je de gebruikers die toegang hebben niet beheert? Nog erger, als je niet eens de clienttoepassingen beheert die die mensen gebruiken?

Meestal wordt het beheren van toegang tot APIs heel anders behandeld dan het beheren van toegang tot applicaties. Vaak is het een volledig apart proces. En soms wordt het zelfs beheerd in een ander deel van de organisatie. Als je terugkijkt naar die zakelijke doelen, is het minder dan duidelijk hoe je een lijn kunt trekken tussen toestemmingen om toegang te krijgen tot een applicatie en toestemmingen om toegang te krijgen tot een API-bron. Het zijn letterlijk slechts twee verschillende soorten interfaces – een gebruikersinterface en een application programming interface. Bovendien kan een interne clienttoepassing – misschien een single page webapplicatie of een mobiele app – heel goed dezelfde API gebruiken als de externe clienttoepassing.

Onthoud dat “gebruikers” in dit opzicht alle soorten identiteiten kunnen betekenen. Ik heb al mensen, computersystemen en vormen van kunstmatige intelligentie genoemd die ergens op het spectrum tussen systeem en mens liggen. Met onze steeds meer gedistribueerde architecturen en nieuwe soorten computing – natural language processing, zelfrijdende auto’s, autonome handelssystemen, robots, drones – is een meer holistische benadering van informatiebeveiliging dringend nodig. Het scheiden van API-toegangscontrole van applicatietoegangscontrole is niet langer geschikt voor het doel. Dat oplossen zal een aanzienlijke waarde voor je bedrijf ontsluiten. Volledige controle hebben over de informatie die je deelt, zal zowel schade door informatielekken voorkomen als diepe samenwerking binnen de organisatie en met zakenpartners mogelijk maken.

Whitepaper De Keuzegids Voor Identity and Access Management

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

Nu downloaden

Een van de grootste en misschien wel meest beschamende inbreuken aller tijden was de SolarWinds supply-chain aanval. SolarWinds Corporation is een Amerikaans bedrijf dat software ontwikkelt voor bedrijven om hun netwerken, systemen en IT-infrastructuur te beheren. Vanuit het perspectief van de hackers was dit bedrijf een felbegeerde prooi. Software die de kern van een computernetwerk bewaakt, heeft immers brede toegang tot alle vitale systemen van een organisatie.

Vermeende Russische hackers slaagden erin kwaadaardige code te injecteren die een achterdeur verschafte in hun “Orion” monitor, waardoor veel van de 18 duizend klanten van SolarWinds tegelijk werden geïnfecteerd. Inclusief enkele zeer hooggeplaatste – het Pentagon, de FBI en de National Nuclear Security Administration. Hoewel details van de gelekte informatie schaars zijn, lijkt het veilig om aan te nemen dat de netwerkbewakingssoftware toegang gaf tot meer middelen dan nodig voor alleen netwerk- en prestatiemonitoring. Opnieuw bleek het vertrouwen in leveranciers riskant. Het bedrijf kreeg een forse boete van $26 miljoen en lijdt onder een aangetaste reputatie. De marktwaarde is ongeveer gehalveerd en vertoont bijna drie jaar na de hack geen tekenen van herstel.

Aangezien we niet terug kunnen naar de gesloten netwerken van vroeger, is de enige verstandige scope voor toegangsbeheer al je digitale activa en alle informatie die in en uit die activa stroomt, ongeacht locatie, technologie of gebruiker.

Denk bijvoorbeeld aan:

• Informatie technologie, Operationele Technologie en Engineering Technologie.
• Toegang door een operator, beheerder, gewone werknemer, klant, leverancier, zakenpartner, autoriteit, …
• Toegang via lokale console, Intranet, Extranet, VPN, Citrix desktop, Cloud desktop of regulier internet.
• Gegevens bewaard in relationele databases, in no-sql databases, in bestanden en mappen, of in casemanagement- of documentmanagementsystemen.
• Gegevens uitgewisseld via berichten, waarschuwingen, gebeurtenissen, e-mails, batchbestanden, …
• Systemen beheerd in de Cloud, in privé-datacenters, op lokale machines, op mobiele apparaten en zelfs IoT-apparaten die aan de rand leven.
• Websites, mobiele apps, APIs, excelsheets, dashboards, rapporten, …

En dan nogmaals.

Zakelijke waarde

Ik weet het, het klinkt overdreven optimistisch om aan te nemen dat zo’n grote en diverse scope ooit consistent en effectief kan worden beheerst. Het lijkt misschien onmogelijk, althans zonder de bank te breken en al je flexibiliteit te verliezen. Maar niet volledig weten wat je hebt blootgesteld, niet weten wie toegang heeft en niet weten welke risico’s eraan verbonden zijn, is ook geen aantrekkelijke propositie. Misschien veronderstel je dat het alleen kan worden gedaan in een relatief kleine organisatie met een strikte hiërarchie. Geloof me, mijn oplossing is niet alleen logisch vanuit een beveiligingsperspectief, maar schaalt ook goed naar grote en complexe organisaties.

Denk nu eens even aan de potentiële voordelen die het je zou brengen. Een enkel beheerpunt voor gebruikers, applicaties en hun toestemmingen. Indien nodig beheerd als een gefedereerd web van vertrouwen. Goed beheerd, conform richtlijnen en consistent afgedwongen. En het beste van alles, altijd up-to-date.

Ik denk dat het mogelijk is. Sterker nog, ik ben eerder betrokken geweest bij zo’n implementatie. Bovendien geloof ik sterk dat alleen organisaties die een sterk ondernemingsperspectief nemen op het beheren van toegang tot hun digitale activa, succesvol zullen worden en blijven in het digitale tijdperk. Autoriteiten eisen het steeds meer, klanten verwachten het en het is veilig om aan te nemen dat hackers het blijven uitdagen. Dus, zonder twijfel, is het belangrijk. Maar is het urgent genoeg om nu actie te ondernemen? Nou, ik kan je alleen maar adviseren dat je niet moet wachten op een ongelukkige gebeurtenis die het dringender maakt dan je zou willen.