MSP-FAQ: houd menselijke en machinetoegang gescheiden per tenant

MSP's die technische toegang en automatisering beheren over tientallen klanttenants, krijgen te maken met een specifieke variant van een groeiend brancheprobleem: non-human identities — serviceaccounts, API-sleutels, automatiseringstokens — moeten anders worden beheerd dan de mensen die ze aanmaken.

Waarom NHI's apart beheer nodig hebben

Het Non-Human Identity Top 10-project van OWASP merkt op dat machine-identiteiten niet intrinsiek aan een persoon zijn gekoppeld en dat gangbare menselijke beveiligingsmaatregelen, zoals MFA, er niet goed op aansluiten. De mismatch zit vooral in de levenscyclus: wanneer een technicus vertrekt, wordt diens account doorgaans binnen enkele uren uitgeschakeld, maar de serviceaccounts en API-sleutels die hij of zij heeft aangemaakt, kunnen met volledige rechten blijven doorlopen totdat iemand ze expliciet opspoort en intrekt. Omdat non-human identities in moderne omgevingen ruimschoots in de meerderheid kunnen zijn ten opzichte van menselijke accounts, laat een MSP die beide op dezelfde manier beheert feitelijk zijn grootste identiteitspopulatie onbeheerd achter.

Kortlevend boven permanent

De consistente aanbeveling van OWASP en de Cloud Security Alliance is om langlevende geheimen te vervangen door efemere, kortlevende tokens die automatisch verlopen, in plaats van referenties die na uitgifte voor onbepaalde tijd blijven werken. Een gelekt langlevend token geeft een aanvaller onbeperkte tijd; een token dat binnen minuten tot uren verloopt, beperkt de schade zelfs als het uitlekt.

Wat dit betekent in het tenantmodel van een MSP

• Gebruik afzonderlijke identity providers of service principals voor menselijke technici versus automatisering.
• Laat een break-glass-referentie van een technicus nooit dienstdoen als servicereferentie voor een pipeline.
• Koppel machinetokens aan één enkele klanttenant — geef nooit een permanente sleutel uit die alle tenants omspant.
• Houd tokenlevensduren in minuten tot uren en roteer bij elke personeels- of automatiseringswijziging.
• Leg de identiteitsklasse (menselijk of non-human) samen met de tenant-ID vast in elk toegangsrecord.

De oplossing is niet één tool, maar een bestuursgewoonte: behandel automatisering als een eigen identiteitspopulatie, met een eigen least-privilege-scope per tenant, in plaats van als een verlengstuk van de technicus die het heeft opgezet.

Bronnen: OWASP Non-Human Identities Top 10, Cloud Security Alliance — Defining Non-Human Identity.