MSP-FAQ: Ein stehendes Dienstprinzipal-Geheimnis ist keine Workload-Identität

Automatisierungskonten und Integrationen authentifizieren sich häufig mit einem Dienstprinzipal-Client-Secret: einer langen Zeichenfolge, die monatelang gültig ist und von jedem Skript oder Ingenieur mit Zugriff darauf genutzt werden kann, um als diese Identität aufzutreten. Das Hinzufügen von Multi-Faktor-Authentifizierung zur menschlichen Seite eines Kontos ändert daran nichts; das Secret selbst bleibt eine stehende Berechtigung mit eigenem Schadensradius.

Warum Client-Secrets als Legacy gelten

Microsofts eigene Anleitung macht deutlich, dass Dienstprinzipale mit Client-Secrets als veralteter Ansatz zu behandeln sind und durch verwaltete oder föderierte Identitäten ersetzt werden sollten, wo immer die Hosting-Umgebung dies unterstützt. Ein Client-Secret sollte nur dann existieren, wenn eine Workload tatsächlich keine stärkere Berechtigung nutzen kann. Das Problem liegt nicht darin, dass Secrets unmöglich zu sichern wären – sie müssen irgendwo gespeichert, nach einem Zeitplan rotiert und bei einem Leak manuell widerrufen werden, und jeder dieser Schritte birgt Fehlerpotenzial.

Was Workload-Identity-Federation entfernt

Workload-Identity-Federation ermöglicht es einer externen Workload – einer CI/CD-Pipeline, einem Kubernetes-Cluster, einem Skript außerhalb von Azure –, Tokens des eigenen Identity-Providers zu vertrauen und sie gegen kurzlebige Microsoft-Entra-Zugriffstokens einzutauschen, ohne dass jemals ein Secret erzeugt, gespeichert oder rotiert wird. Microsofts Vergleich der drei Modelle ist eindeutig: föderierte Dienstprinzipale und verwaltete Identitäten sind secret-frei und funktionieren gleichermaßen in gehosteten, selbst gehosteten und On-Premises-Umgebungen, während secret-basierte Dienstprinzipale nicht secret-frei sind und weiterhin das operationale Risiko jeder langlebigen Berechtigung tragen.

Für einen MSP mit vielen Kundentenants

Die Tenant-Dimension zählt ebenso wie der Berechtigungstyp. Ein einzelner Dienstprinzipal, der über mehrere Kundentenants hinweg genutzt wird, verwandelt ein geleaktes Secret in einen Vorfall mit Auswirkungen auf mehrere Kunden; die Identität sollte unabhängig vom verwendeten Berechtigungsmodell an den Scope eines einzelnen Tenants gebunden sein. Wo Federation noch nicht möglich ist, ist das Client-Secret als stehendes Risiko zu behandeln: erfassen, wo es eingesetzt wird, auf eine Gültigkeit von höchstens 90 Tagen setzen und die Entfernung terminieren, sobald Federation verfügbar ist.

Quellen: Microsoft Learn — Workload identity federation, Microsoft Learn — Service principals and managed identities.