De blinde vlek in Zero Trust: identiteiten zonder mens

De ongemakkelijke realiteit

Veel organisaties zijn ervan overtuigd dat ze identity goed hebben ingeregeld.

• MFA is ingeschakeld met extra verificatie voor gebruikers.
• Conditional Access is uitgerold met regels die bepalen wanneer en hoe gebruikers toegang krijgen.
• Zero Trust staat op de roadmap of wordt zelfs als “af” beschouwd.

En toch draait een groot deel van de cloudomgeving op identiteiten die:

• nooit inloggen: ze authenticeren automatisch, zonder menselijke interactie.
• nooit MFA gebruiken: extra verificatie is voor deze identiteiten meestal niet mogelijk.
• en zelden expliciet worden gecontroleerd: ze blijven bestaan en behouden rechten, ook als de workload verandert.

Dat is geen randverschijnsel. Dat is de grootste onbewaakte aanvalsvector in moderne cloudomgevingen. In eerdere blogs heb ik geschreven over Zero Trust als fundament, over de impact van AI en over waarom klassieke netwerkbeveiliging tekortschiet. Eén conclusie kwam steeds terug: vertrouwen verschuift weg van het netwerk en richting identiteit. In dit blog zoom ik daarom in op wat daarbij structureel wordt genegeerd: identiteiten die geen mens zijn.

Identity ≠ gebruikers

Jarenlang hebben we security ingericht rond gebruikers. Accounts, MFA, conditional access, alles is ontworpen voor mensen die bewust inloggen. Maar moderne omgevingen draaien allang niet meer alleen op mensen. Cloud workloads, automatisering, CI/CD pipelines en AI-toepassingen functioneren via identiteiten die autonoom handelen. Ze vragen geen toestemming, klikken niet verkeerd en melden zich niet bij de servicedesk. Ze doen gewoon wat ze mogen doen. En precies daar wringt het. Als identity de nieuwe perimeter is, dan bewaken we die perimeter vandaag vooral voor gebruikers. Niet voor wat namens hen opereert.

Identity als nieuw control plane binnen Zero Trust

Zero Trust heeft duidelijk gemaakt dat netwerkgrenzen onvoldoende bescherming bieden. Vertrouwen wordt niet langer bepaald door waar iets vandaan komt, maar door wie of wat toegang vraagt, in welke context.

Daarmee is identity het centrale control plane geworden voor:

• Toegang tot data: Wie of wat mag gevoelige informatie lezen, wijzigen of verwerken.
• Toegang tot workloads: Welke applicaties, services of processen mogen resources gebruiken of beheren.
• Communicatie tussen services: Welke systemen onderling mogen praten en welke acties daarbij zijn toegestaan.

In theorie geldt dit identiteitsmodel voor alle entiteiten in een omgeving, mensen én systemen. In de praktijk wordt Zero Trust echter bijna altijd user-centric geïmplementeerd. Dat is geen tekortkoming van Zero Trust als model. Het is een bewuste, en risicovolle, vereenvoudiging in de uitvoering.

De explosie van non-human identities

Elke moderne cloudomgeving bevat een groeiend aantal identiteiten die geen mens zijn:

• Service principals: Technische accounts die applicaties of services gebruiken om toegang te krijgen tot cloudresources, vaak met vaste en brede rechten.
• Managed identities: Door het platform beheerde identiteiten waarmee workloads zich authenticeren zonder wachtwoorden of secrets.
• API-identiteiten: Identiteiten die gebruikt worden voor communicatie tussen systemen, applicaties of externe diensten.
• Automatisering en scripts: Identiteiten die worden gebruikt door geplande taken, scripts en beheerprocessen om wijzigingen door te voeren.
• CI/CD pipelines: Identiteiten waarmee build- en deploymentprocessen code uitrollen naar cloudomgevingen.
• AI-agents en workloads: Autonome processen die data ophalen, modellen trainen of acties uitvoeren zonder directe menselijke interactie.

In veel organisaties zijn deze identiteiten inmiddels talrijker dan gebruikersaccounts. Ze worden automatisch aangemaakt, snel aangepast en zelden actief beheerd. Ze zijn essentieel voor schaal en snelheid. Maar ze groeien sneller dan ons beveiligingsdenken en vaak zonder expliciete ontwerpkeuzes.

Waarom non-human identities gevaarlijker zijn dan gebruikers

Non-human identities zijn niet per definitie onveilig. Ze worden gevaarlijk door de manier waarop we ermee omgaan.

Typische kenmerken:

• Geen MFA: Deze identiteiten kunnen niet extra worden beschermd met gebruikersmaatregelen zoals MFA.
• Langlevende tokens en permissies: Toegang blijft vaak maanden of jaren geldig, ongeacht of de workload nog bestaat.
• Onduidelijk eigenaarschap: Het is vaak niet duidelijk welk team of welke persoon verantwoordelijk is.
• Minimale monitoring: Misbruik of afwijkend gedrag blijft lang onopgemerkt.
• ‘Set-and-forget’-configuraties: Eenmaal ingericht worden rechten zelden opnieuw bekeken.

Een gebruiker kan een fout maken en dat valt meestal op. Een service principal met te ruime rechten maakt geen fouten. Die doet exact wat hij mag doen. En dat is vaak veel te veel, voor veel te lang, zonder dat iemand het merkt. Identity-security faalt hier niet spectaculair, maar stilletjes, totdat incident response ineens geen gebruikersaccount onderzoekt, maar een workload. Dit is het punt waarop teams zich vaak realiseren dat ze dit risico al jaren met zich meedragen.

Waarom dit ook kleine organisaties raakt

Dit probleem beperkt zich niet tot grote enterprises. Ook kleine organisaties maken dagelijks gebruik van:

• Cloud-automatisering: Processen die automatisch resources aanmaken, wijzigen of verwijderen zonder menselijke tussenkomst.
• API-integraties: Koppelingen tussen interne systemen en externe diensten die continu toegang nodig hebben.
• Scripts met verhoogde rechten: Technische scripts die beheeracties uitvoeren en vaak meer rechten hebben dan strikt noodzakelijk.
• AI-experimenten: Proof-of-concepts en pilots die data ophalen of acties uitvoeren, meestal zonder volwassen governance.

Sterker nog: in kleinere omgevingen groeit dit risico vaak sneller, omdat snelheid en flexibiliteit belangrijker zijn dan formele controlemechanismen.

Tegelijkertijd hebben kleine organisaties hier juist een voordeel:

• Minder legacy: Minder verouderde systemen en uitzonderingen die beveiliging complex maken.
• Minder uitzonderingen: Beleid en toegangsregels zijn eenvoudiger en consistenter toe te passen.
• Sneller overzicht: Het aantal workloads en identiteiten is beperkt en daardoor beter beheersbaar.

Zero Trust voor non-human identities is daarom geen luxe voor grote organisaties. Het is een noodzakelijke discipline in elke cloudomgeving, juist ook in kleine teams.

Wat je vandaag al zou moeten weten

Dit blog is bewust geen handleiding. Maar er zijn een paar dingen die elke organisatie, groot of klein, nu al zou moeten kunnen beantwoorden. Zonder tooling-project. Zonder redesign. Als je deze vragen niet kunt beantwoorden, heb je geen zicht op je identiteitsperimeter.

• Kun je alle non-human identities in je omgeving benoemen?
• Weet je welke workloads welke identiteit gebruiken?
• Is voor elke non-human identity een eigenaar aangewezen?
• Kun je zien wanneer en waar een identity wordt gebruikt?
• Kun je met zekerheid zeggen welke identiteiten productie-toegang hebben?

Dit zijn geen maturity-vragen. Dit zijn basisvoorwaarden voor Zero Trust. Zonder dit inzicht is Zero Trust geen strategie, maar een aanname. Als het antwoord hierop “nee” is, dan is Zero Trust in jouw omgeving, hoe goed bedoeld ook, fundamenteel incompleet.

Conclusie:

Zero Trust faalt niet omdat het concept tekortschiet. Het faalt wanneer we identity blijven reduceren tot gebruikers. Terwijl cloudplatformen en AI-systemen steeds autonomer worden, groeit het aantal identiteiten dat namens ons handelt zonder expliciete controle, zonder duidelijke grenzen en vaak zonder duidelijke eigenaar. Wie Zero Trust serieus neemt, moet voorbij de mens durven kijken.

In de volgende blog maken we de stap van inzicht naar ontwerp: hoe pas je Zero Trust-principes toe op non-human identities zonder ze te behandelen als uitzonderingen? Niet als theoretisch model, maar als bewuste architectuurkeuze.