MSP FAQ: en stående tjänsthuvudhemlighet är inte arbetsbelastningsidentitet

Automatiseringskonton och integrationer autentiserar ofta med en tjänsthuvud-klienthemlighet: en lång sträng, giltig i månader, som alla skript eller ingenjörer med tillgång till den kan använda för att agera som den identiteten. Att lägga till multifaktorautentisering på den mänskliga sidan av ett konto ändrar inte det; själva hemligheten förblir en stående autentiseringsuppgift med en egen påverkansradie.

Varför klienthemligheter behandlas som legacy

Microsofts egen vägledning är tydlig med att tjänsthuvuden med klienthemligheter bör behandlas som en föråldrad metod och ersättas med hanterade eller federerade identiteter där värdmiljön stöder det. En klienthemlighet bör bara finnas när en arbetsbelastning verkligen inte kan använda en starkare autentiseringsuppgift. Problemet är inte att hemligheter är omöjliga att säkra — det är att de måste lagras någonstans, roteras enligt schema och återkallas manuellt om de läcker, och vart och ett av dessa steg är en plats där ett misstag kan ske.

Vad arbetsbelastningsidentitetsfederation tar bort

Arbetsbelastningsidentitetsfederation låter en extern arbetsbelastning — en CI/CD-pipeline, ett Kubernetes-kluster, ett skript som körs utanför Azure — lita på token från sin egen identitetsleverantör och växla dem mot kortlivade Microsoft Entra-åtkomsttoken, utan att någon hemlighet någonsin genereras, lagras eller roteras. Microsofts jämförelse av de tre modellerna är direkt: federerade tjänsthuvuden och hanterade identiteter är hemlighetsfria och fungerar i både värdbaserade, självhanterade och lokala miljöer, medan hemlighetsbaserade tjänsthuvuden inte är hemlighetsfria och fortfarande bär den operativa risk som följer med alla långlivade autentiseringsuppgifter.

För en MSP som hanterar många kundklienter

Klientdimensionen spelar lika stor roll som autentiseringstypen. Ett enda tjänsthuvud som delas mellan flera kundklienter förvandlar en läckt hemlighet till en incident som drabbar flera kunder; identiteten bör bindas till en enda klients omfattning oavsett vilken autentiseringsmodell som används. Där federation ännu inte är möjlig, behandla klienthemligheten som en stående risk: inventera var den används, sätt utgångstid till 90 dagar eller mindre och kalenderlägg dess borttagning när federationen väl är på plats.

Källor: Microsoft Learn — Workload identity federation, Microsoft Learn — Service principals and managed identities.