Non-human identity-risico begint in de architectuur

Lees hier de eerste en hier de tweede blog terug.

Architectuur creëert identiteiten, niet beleid

Non-human identities ontstaan zelden vanuit een bewuste keuze om een nieuwe identiteit toe te voegen. Meestal zijn ze een bijproduct van architectuur. Elke moderne cloudarchitectuur optimaliseert voor:

• Snelheid: ontwikkelteams moeten snel kunnen bouwen, testen en uitrollen zonder handmatige tussenstappen.
• Schaal: architecturen moeten automatisch kunnen meegroeien met gebruik, data en workloads.
• Automatisering: handmatig beheer maakt plaats voor scripts, pipelines en platformlogica.
• Herhaalbaarheid: omgevingen en deployments moeten consistent opnieuw kunnen worden opgebouwd.

Deze eigenschappen leveren wendbaarheid op, maar hebben ook een keerzijde. Identiteiten ontstaan sneller dan ze worden begrepen, krijgen ruimere rechten dan noodzakelijk en blijven vaak bestaan nadat hun oorspronkelijke taak is veranderd of verdwenen. Dat is niet alleen een governancevraagstuk. Het is een architectuurrealiteit. Als identiteit pas na het ontwerp wordt toegevoegd, loopt beheersing per definitie achter de feiten aan.

Automatisering maakt tijdelijk vertrouwen structureel

In cloudomgevingen is automatisering geen optimalisatie meer, maar een voorwaarde.
Resources worden:

• Automatisch aangemaakt: Via templates, pipelines of platformservices, zonder menselijke tussenkomst.
• Automatisch geconfigureerd: Instellingen en koppelingen worden door automatisering toegepast.
• Automatisch gedeployed: Nieuwe versies worden continu uitgerold naar test- en productieomgevingen.

Elke automatiseringsstap introduceert een identiteit die:

• Toegang nodig heeft om resources te lezen, wijzigen of aan te maken.
• Bevoegdheden krijgt vaak breder dan strikt noodzakelijk, om fouten te voorkomen.
• Daarna meestal blijft bestaan ook wanneer de oorspronkelijke taak of context verandert.

Wat begint als “tijdelijk voor de pipeline”, wordt vaak structureel. Niet omdat iemand dat zo wil, maar omdat architecturen zelden expliciet definiëren wanneer een identiteit mag verdwijnen.

CI/CD-pipelines: de meest vertrouwde identiteiten

CI/CD pipelines zijn vaak de eerste plek waar non-human identity-risico zichtbaar wordt. Ze moeten resources aanmaken (bijvoorbeeld infrastrucuur, services of dependencies), configuraties wijzigen (inclusief netwerk-, security- en identity-instellingen) en code naar productie uitrollen zonder handmatige goedkeuring bij elke stap. Daardoor behoren pipeline-identiteiten vaak tot de krachtigste identiteiten in de omgeving.

Om dit betrouwbaar te kunnen doen, krijgen ze brede rechten. En omdat deployments moeten blijven werken, worden die rechten zelden teruggedraaid. Het gevolg: pipelines met productie-toegang,identiteiten die meerdere omgevingen overstijgen en rechten die ouder zijn dan de applicatie zelf. Dit voelt praktisch. Maar architectonisch is het impliciet vertrouwen op schaal.

Microservices en service-to-service vertrouwen

Cloud-native architecturen breken applicaties op in kleine, zelfstandige services. Elke service:

• Communiceert met andere services voor data-uitwisseling en procesafhandeling.
• Data opvraagt uit databases, queues of externe systemen.
• Acties triggert elders zoals het starten van processen of het aanpassen van state.

Elke interactie vereist een identiteit. Wat vaak ontbreekt in het ontwerp:

• Expliciete vertrouwensgrenzen tussen services.
• Duidelijke scoping per afhankelijkheid.
• Onderscheid tussen “mag praten” en “mag handelen”.

Het resultaat is een netwerk van services dat functioneert, maar waarbij vertrouwen transitief wordt. En transitief vertrouwen is precies wat Zero Trust probeert te vermijden.

AI-workloads: identiteiten zonder pauzeknop

AI-workloads versterken hetzelfde patroon. Ze draaien autonoom, halen continu data op, roepen andere services aan en kunnen vervolgacties starten. Er is geen duidelijk loginmoment en vaak ook geen natuurlijk afsluitmoment. De toegang blijft bestaan zolang de workload actief is.

Wat vaak wordt onderschat is hoe breed de toegang moet zijn om “flexibel” te blijven, hoe moeilijk het is om rechten te beperken zonder functionaliteit te breken en hoe weinig zicht er is op wat de workload daadwerkelijk gebruikt. AI-workloads maken non-human identities niet alleen talrijker, maar ook moeilijker af te bakenen.

Omgevingen vervagen sneller dan verwacht

In theorie zijn ontwikkel-, test- en productieomgevingen strikt gescheiden. In de praktijk delen pipelines identiteiten tussen deze omgevingen, worden secrets hergebruikt omdat dit ‘tijdelijk’ of ‘praktisch’ is en worden tijdelijke uitzonderingen onder druk van deadlines en stabiliteit permanent. Niet uit nalatigheid, maar uit tijdsdruk.

Architecturen die deze uitzonderingen toestaan, creëren identiteiten die omgevingsoverstijgend vertrouwen krijgen. Zodra dat gebeurt, is de blast radius geen abstract concept meer.

Het patroon achter de voorbeelden

De rode draad is niet tooling en niet discipline. Het patroon is dit:

• Architecturen worden ontworpen voor functionaliteit,
• en identiteiten worden achteraf passend gemaakt.

Maar identiteiten zijn geen bijzaak. Ze zijn het trust model. Zolang identiteiten ontstaan als afgeleide van architectuur, zal governance altijd achterlopen.

Vier signalen die je nu al kunt herkennen

Net als in de eerdere blogs is dit geen handleiding, maar er zijn wel signalen die je kunt zien:

• Architectuurdiagrammen waarin identiteiten niet voorkomen
• Pipelines met meer rechten dan individuele services
• Workloads die meerdere omgevingen kunnen bereiken
• AI-processen waarvan niemand precies weet welke toegang ze nodig hebben

Zijn deze patronen aanwezig, dan is het identiteitsrisico niet incidenteel. Het is structureel in de architectuur ingebouwd.

Vooruitblik: van architectuur naar operatie

De eerste blog liet zien welke identiteitslaag vaak wordt genegeerd. De tweede blog maakte duidelijk waarom klassieke Zero Trust-aannames bij non-human identities tekortschieten. Deze derde blog toont waar het risico ontstaat: in architecturen die automatisering en functionaliteit centraal stellen, maar identiteit niet als zelfstandig ontwerpprincipe behandelen.

Daarmee blijft één vraag over: hoe houd je grip in een omgeving die voortdurend verandert? In de vierde en laatste blog kijken we naar de operationele realiteit: eigenaarschap, lifecycle, monitoring en identity drift. Niet om architectuur te vertragen, maar om haar beheersbaar te maken.