Waarom Zero Trust faalt zonder grip op non-human identities

De vraag is dus niet of Zero Trust faalt. De vraag is: welke ontwerp¬aannames houden het tegen?

De blog 'De blinde vlek in Zero Trust: identiteiten zonder mens' lees je hier terug.

Ontwerpaannames die ongemerkt niet meer kloppen

Zero Trust rust op drie principes:

• Verify explicitly: Elke toegang moet expliciet worden gevalideerd op basis van identiteit en context
• Use least privilege: Identiteiten krijgen alleen de minimale rechten die nodig zijn om hun taak uit te voeren
• Assume breach: Het ontwerp gaat ervan uit dat misbruik kan plaatsvinden, en beperkt vooraf de impact

Deze principes zijn universeel. Maar de manier waarop we ze toepassen is dat niet. Bij non-human identities breken vooral de impliciete aannames onder deze principes zonder dat we het merken.

Aanname 1: Verificatie gebeurt bij een loginmoment

In veel ontwerpen is verificatie gekoppeld aan één expliciet moment: de login. Bij gebruikers werkt dat prima. Maar workloads loggen niet in. Er is geen interactief moment waarop beleid wordt geëvalueerd en daarna “klaar” is. Authenticatie gebeurt automatisch, via tokens, claims en context, en wordt daarna vaak als vertrouwd beschouwd.

Het probleem is niet dat verificatie ontbreekt. Het probleem is dat verificatie impliciet wordt, omdat we niet expliciet ontwerpen voor workloads. Als verificatie impliciet is, wordt vertrouwen dat ook.

Aanname 2: Least privilege is een configuratiekeuze

Least privilege wordt vaak gezien als iets dat je instelt. Een rol, een policy, een permissie. In de praktijk groeit toegang mee met functionaliteit:

• nieuwe features vragen extra rechten
• afhankelijkheden nemen toe
• permissies worden zelden ingetrokken

Bij gebruikers valt dit op. Bij non-human identities blijft het meestal onzichtbaar. Het gevolg is voorspelbaar:

• kleine workloads met brede rechten
• toegang die ouder is dan de applicatie zelf
• privileges die “tijdelijk” waren, maar permanent zijn geworden

Dit is geen operationele fout. Het is een ontwerpfout. Bij non-human identities bepaalt least privilege niet alleen wat mag, maar ook hoe groot de impact is als het misgaat.

Aanname 3: Assume breach begint bij incident response

“Assume breach” wordt vaak geassocieerd met wat je doet na een incident. Voor workloads is dat te laat. Misbruik van non-human identities blijft vaak lang onopgemerkt:

• geen gebruiker die iets merkt
• geen device dat afwijkend gedrag vertoont
• geen login die faalt

Daarom moet assume breach bij workloads beginnen in het ontwerp.

• Beperkte blast radius: Als een identiteit wordt misbruikt, is de impact vooraf begrensd.
• Duidelijke scheiding tussen omgevingen: Toegang tot productie staat los van ontwikkel- of testomgevingen.
• Geen impliciet vertrouwen tussen services: Services vertrouwen elkaar niet automatisch, ook niet binnen dezelfde omgeving.

Niet als noodscenario, maar als structurele architectuurkeuze.

Signalen dat je Zero Trust-ontwerp niet klopt

Zonder tools of dashboards kun je vaak al zien dat een Zero Trust-ontwerp niet klopt. Waarschuwingssignalen zijn onder andere:

• workloads die dezelfde identiteit delen
• één identiteit die meerdere omgevingen kan benaderen
• rechten die langer bestaan dan de workload zelf
• toegang die wordt verklaard met “dat is handig”

In de praktijk worden deze signalen zelden als incident gezien, maar bijna altijd als “hoe het nu eenmaal gegroeid is”. Dit zijn geen implementatiedetails. Dit zijn ontwerpgevolgen.

Wat er moet veranderen vóórdat tooling helpt

Als Zero Trust ook voor non-human identities moet werken, vraagt dat om een andere manier van denken:

• identity als lifecycle, niet als account
• trust boundaries gebaseerd op identiteit en context, niet op netwerk
• architectuur die bepaalt welke identiteiten ontstaan, niet andersom

Zonder deze verschuiving wordt Zero Trust een verzameling controles, geen samenhangend model.

Welke vragen je na deze blog zou moeten stellen

Deze blog introduceert geen nieuwe controls of tooling. Maar ze zou wél moeten veranderen hoe je naar je architectuur kijkt. Na deze blog zou je jezelf bij elke workload moeten afvragen:

• Waar vindt verificatie hier écht plaats? Is dat een expliciet ontwerpkeuze, of een aanname die we nooit hebben uitgesproken?
• Wat is hier de blast radius van vertrouwen? Welke impact accepteren we als deze identiteit vandaag wordt misbruikt?
• Welke rechten zijn hier historisch gegroeid? En welke zijn bewust gekozen?
• Welke identiteiten bestaan bij gratie van architectuur, niet beleid? En wat zegt dat over onze ontwerpkeuzes?

Dit zijn geen implementatievragen. Dit zijn architectuurvragen. Als je ze niet kunt beantwoorden, is dat geen tekortkoming van tooling, maar een signaal dat het ontwerp zelf nooit expliciet is gemaakt.

Vooruitblik: waar dit echt misgaat

Deze blog ging niet over oplossingen, maar over ontwerpkeuzes die vaak onzichtbaar blijven. In de volgende blog maken we zichtbaar waar deze keuzes ontstaan. In cloud- en AI-architecturen ontstaan identiteiten sneller dan governance kan bijhouden. Niet als theoretisch probleem, maar als direct gevolg van moderne ontwerpkeuzes. Want architectuur bepaalt niet alleen hoe systemen werken, maar ook hoeveel vertrouwen ze automatisch krijgen.

Kun je hulp gebruiken bij jouw Zero Trust-ontwerp? Neem contact met ons op en onze Azure-architect helpt je bepalen waar vertrouwen, identiteit en toegang explicieter ingericht kunnen worden.