Recente grote storingen in de cloudservices zijn moeilijk te missen. Spraakmakende incidenten waarbij providers als AWS, Azure en Cloudflare betrokken zijn, hebben grote delen van het internet ontwricht, waardoor websites en diensten waarvan veel andere systemen afhankelijk zijn, offline zijn gehaald. De resulterende rimpeleffecten hebben applicaties en workflows stopgezet waar veel organisaties dagelijks op vertrouwen.
Voor consumenten worden deze storingen vaak als hinderlijk ervaren, omdat ze bijvoorbeeld geen eten kunnen bestellen, inhoud kunnen streamen of geen toegang kunnen krijgen tot online diensten. Voor bedrijven zijn de gevolgen echter veel ernstiger. Wanneer het boekingssysteem van een luchtvaartmaatschappij offline gaat, vertaalt verloren beschikbaarheid zich rechtstreeks in omzetverlies, reputatieschade en operationele verstoring.
Deze incidenten benadrukken dat cloudstoringen veel meer gevolgen hebben dan computers of netwerken. Een van de meest kritische en impactvolle gebieden is identiteit. Wanneer authenticatie en autorisatie worden verstoord, is het resultaat niet alleen maar downtime; het is een essentieel operationeel en veiligheidsincident.
Cloudinfrastructuur, een gedeeld storingspunt
Cloudproviders zijn geen identiteitssystemen. Maar moderne identiteitsarchitecturen zijn sterk afhankelijk van in de cloud gehoste infrastructuur en gedeelde diensten. Zelfs als een authenticatiedienst zelf functioneel blijft, kunnen storingen elders in de afhankelijkheidsketen identiteitsstromen onbruikbaar maken.
De meeste organisaties vertrouwen op de cloudinfrastructuur voor kritieke identiteitsgerelateerde componenten, zoals:
- Datastores met identiteitskenmerken en directory-informatie
- Beleids- en autorisatiegegevens
- Load balancers, controlevlakken en DNS
Deze gedeelde afhankelijkheden introduceren risico’s in het systeem. Een storing in een van deze kan de authenticatie of autorisatie volledig blokkeren, zelfs als de identiteitsprovider technisch gezien nog actief is. Het resultaat is een verborgen Single Point of Failure dat veel organisaties helaas pas ontdekken tijdens een storing.
Identiteit, de poortwachter voor alles
Authenticatie en autorisatie zijn geen geïsoleerde functies die alleen worden gebruikt tijdens het inloggen; het zijn continue poortwachters voor elk systeem, elke API en elke service. Moderne beveiligingsmodellen, met name Zero Trust, zijn gebaseerd op het principe van “Vertrouw nooit, verifieer altijd”. Die verificatie is volledig afhankelijk van de beschikbaarheid van identiteitssystemen.
Dit geldt zowel voor menselijke gebruikers als voor machine-identiteiten. Applicaties worden voortdurend geverifieerd. API’s autoriseren elk verzoek. Services verkrijgen tokens om andere services aan te roepen. Als identiteitssystemen niet beschikbaar zijn, werkt niets.
Hierdoor vormen identiteitsstoringen een directe bedreiging voor de bedrijfscontinuïteit. Ze moeten het hoogste niveau van incidentrespons teweegbrengen, met proactieve monitoring en waarschuwingen voor alle afhankelijke services. Door identiteitsdowntime als een secundair of puur technisch probleem te behandelen, wordt de impact ervan aanzienlijk onderschat.
De verborgen complexiteit van authenticatiestromen
Authenticatie omvat veel meer dan het verifiëren van een gebruikersnaam en wachtwoord, of een sleutel, nu organisaties steeds meer overstappen op wachtwoordloze modellen. Eén enkele authenticatiegebeurtenis veroorzaakt doorgaans een complexe reeks handelingen achter de schermen.
Identiteitssystemen zijn gewoonlijk:
- Los gebruikerskenmerken uit mappen of databases op
- Sessiestatus opslaan
- Geef toegangstokens uit die bereiken, claims en kenmerken bevatten
- Voer fijnmazige autorisatiebeslissingen uit met behulp van beleidsengines
Autorisatiecontroles kunnen zowel plaatsvinden tijdens de uitgifte van tokens als tijdens runtime wanneer toegang wordt verkregen tot API’s. In veel gevallen moeten API’s zichzelf authenticeren en tokens verkrijgen voordat ze andere services kunnen aanroepen.
Elk van deze stappen is afhankelijk van de onderliggende infrastructuur. Datastores, beleidsengines, tokenstores en externe services worden allemaal onderdeel van de authenticatiestroom. Een storing in een van deze componenten kan de toegang volledig blokkeren, wat gevolgen heeft voor gebruikers, applicaties en bedrijfsprocessen.
Waarom traditionele hoge beschikbaarheid niet genoeg is
Hoge beschikbaarheid wordt breed geïmplementeerd en absoluut noodzakelijk, maar is vaak onvoldoende voor identiteitssystemen. De meeste ontwerpen met hoge beschikbaarheid zijn gericht op regionale failover: een primaire implementatie in de ene regio en een secundaire in een andere. Als één regio uitvalt, verschuift het verkeer naar de back-up.
Deze aanpak faalt wanneer storingen gedeelde of mondiale services beïnvloeden. Als identiteitssystemen in meerdere regio’s afhankelijk zijn van hetzelfde cloudcontrolevlak, dezelfde DNS-provider of dezelfde beheerde databaseservice, biedt regionale failover weinig bescherming. In deze scenario’s faalt het back-upsysteem om dezelfde redenen als het primaire systeem.
Het resultaat is een identiteitsarchitectuur die op papier veerkrachtig lijkt, maar instort onder grootschalige cloud- of platformbrede storingen.
Veerkracht ontwerpen voor identiteitssystemen
Echte veerkracht moet doelbewust worden ontworpen. Voor identiteitssystemen betekent dit vaak het verminderen van de afhankelijkheid van één enkele provider of één storingsdomein. Benaderingen kunnen bestaan uit multi-cloudstrategieën of gecontroleerde lokale alternatieven die toegankelijk blijven, zelfs als de clouddiensten achteruitgaan.
Even belangrijk is het plannen van een slechte werking. Het volledig weigeren van de toegang tijdens een storing heeft de hoogst mogelijke zakelijke impact. Het toestaan van beperkte toegang, op basis van in de cache opgeslagen attributen, vooraf berekende autorisatiebeslissingen of verminderde functionaliteit, kan de operationele schade en reputatieschade dramatisch verminderen.
Niet alle identiteitsgerelateerde gegevens hebben hetzelfde beschikbaarheidsniveau nodig. Sommige attributen of autorisatiebronnen zijn mogelijk minder fouttolerant dan andere, en dat kan acceptabel zijn. Waar het om gaat is dat deze afwegingen doelbewust worden gemaakt, op basis van bedrijfsrisico’s in plaats van architectonisch gemak.
Identiteitssystemen moeten zo worden ontworpen dat ze probleemloos falen. Wanneer uitval van de infrastructuur onvermijdelijk is, moet de toegangscontrole voorspelbaar verslechteren en niet volledig instorten.
Klaar om aan de slag te gaan met een robuuste oplossing voor identiteitsbeheer? Probeer de Curity Identity Server gratis.
