MSP FAQ: een permanent service-principal-geheim is geen workloadidentiteit

Automation-accounts en integraties authenticeren vaak met een service-principal-clientgeheim: een lange tekenreeks, maandenlang geldig, die elk script of elke engineer met toegang ertoe kan gebruiken om als die identiteit op te treden. Het toevoegen van multi-factorauthenticatie aan de menselijke kant van een account verandert dat niet; het geheim zelf blijft een permanent verificatiemiddel met een eigen schaderadius.

Waarom clientgeheimen als verouderd worden behandeld

Microsofts eigen richtlijnen zijn expliciet: service-principals met clientgeheimen moeten als een verouderde aanpak worden behandeld en worden vervangen door beheerde of gefedereerde identiteiten waar de hostingomgeving dat ondersteunt. Een clientgeheim mag alleen bestaan wanneer een workload echt geen sterker verificatiemiddel kan gebruiken. Het probleem is niet dat geheimen onmogelijk te beveiligen zijn — het is dat ze ergens moeten worden opgeslagen, volgens een schema moeten worden geroteerd en handmatig moeten worden ingetrokken als ze lekken, en elk van die stappen is een plek waar fouten kunnen ontstaan.

Wat workloadidentiteitsfederatie wegneemt

Met workloadidentiteitsfederatie kan een externe workload — een CI/CD-pipeline, een Kubernetes-cluster, een script dat buiten Azure draait — tokens van de eigen identiteitsprovider vertrouwen en deze omwisselen voor kortlopende Microsoft Entra-toegangstokens, zonder dat er ooit een geheim wordt gegenereerd, opgeslagen of geroteerd. Microsofts vergelijking van de drie modellen is helder: gefedereerde service-principals en beheerde identiteiten zijn geheimvrij en werken in gehoste, self-hosted en on-premises omgevingen, terwijl service-principals op basis van geheimen niet geheimvrij zijn en nog altijd het operationele risico meedragen dat bij elk langlopend verificatiemiddel hoort.

Voor een MSP die veel klanttenants beheert

De tenantdimensie is even belangrijk als het type verificatiemiddel. Eén service-principal die over meerdere klanttenants wordt gedeeld, maakt van één gelekt geheim een klantoverstijgend incident; een identiteit moet aan het bereik van één tenant gebonden zijn, ongeacht welk verificatiemodel wordt gebruikt. Waar federatie nog niet mogelijk is, behandel het clientgeheim dan als een permanent risico: inventariseer waar het wordt gebruikt, laat het binnen 90 dagen of minder verlopen en plan de verwijdering zodra federatie is ingevoerd.

Bronnen: Microsoft Learn — Workloadidentiteitsfederatie, Microsoft Learn — Service-principals en beheerde identiteiten.