Client Secrets in Entra ID lassen sich durch sichere Verfahren ersetzen

In vielen Tenants, die ich betreue, finde ich nach wie vor erstaunlich viele Entra-ID-App-Registrierungen mit klassischen Client Secrets. Für ältere oder „nebenbei“ entstandene Integrationen war das oft der bequemste Weg. Sicher ist er nicht, und verwalten lässt er sich auch schlecht. Regelmäßig begegnen mir Secrets aus dem Vorjahr, zu denen es keine saubere Dokumentation gibt und deren Ablaufdatum offenbar niemand im Blick hat. Bevor man Client Secrets ablösen kann, muss man also erst einmal herausfinden, wo sie überall im Einsatz sind.

Am Anfang steht eine Bestandsaufnahme aller Client Secrets

Ich starte jede Ablösung mit einem Überblick: Welche Anwendungen in Entra ID nutzen noch Client Secrets, und wie lange sind diese gültig? Meist greife ich dafür zur Microsoft Graph PowerShell, weil sich die Daten damit in wenigen Minuten zusammentragen lassen. Mit folgendem Skript lese ich alle App-Registrierungen samt aktiven Secrets und Ablaufdaten aus:

Get-MgApplication -All | ForEach-Object {
    $app = $_
    foreach ($secret in $app.PasswordCredentials) {
        [PSCustomObject]@{
            AppDisplayName = $app.DisplayName
            AppId = $app.AppId
            SecretDisplayName = $secret.DisplayName
            StartDate = $secret.StartDateTime
            EndDate = $secret.EndDateTime
        }
    }
} | Sort-Object EndDate

Wenn Secrets „ewig“ gültig oder längst abgelaufen sind, sollten die Alarmglocken läuten. Meist bedeutet das, dass sich niemand regelmäßig ums Aufräumen kümmert. In manchen Umgebungen stoße ich auf App-Registrierungen, deren geheime Schlüssel seit ihrer Erstellung nie erneuert wurden. Gelangt jemand an alte Dokumentationen oder an den Quellcode, hat er damit unter Umständen einen bequemen Zugang.

Lang laufende Client Secrets werden schnell zum Sicherheitsrisiko

Klassische Client Secrets haben einen grundsätzlichen Schwachpunkt. Sobald jemand den Secret Value in eine Datei oder ein Repository schreibt, ist der Schutz praktisch dahin. Secrets landen dann im Quellcode-Repository, erscheinen in Build-Logs oder werden aus Versehen weitergegeben. Wie gefährlich kompromittierte Secrets in App-Registrierungen sind, haben die Angriffe von Midnight Blizzard auf Exchange Online im letzten Jahr schmerzhaft vor Augen geführt – und zwar selbst dann, wenn das eigentliche Secret schon lange nicht mehr genutzt wird. Mehr dazu steht in meiner Analyse der Lehren aus Midnight Blizzard hier im Blog.

Dazu kommt ein organisatorisches Problem. Projekte oder Dienstleister legen App-Registrierungen an, halten aber weder die Besitzer noch den Einsatzzweck so fest, dass später noch jemand weiß, wozu eine App existiert und wer sie braucht. Gibt es außerdem kein Management für die Lebensdauer der Secrets, wird das Aufräumen zur Detektivarbeit.

Praxistipp: In der Entra-ID-Oberfläche könnt ihr für jede App-Registrierung „Eigentümer“ festlegen. Damit sind die Verantwortlichkeiten dokumentiert, und das zahlt sich spätestens dann aus, wenn ein Secret abläuft oder erneuert werden muss.

Mehrere Verfahren kommen ganz ohne klassische Secrets aus

Inzwischen gibt es ausgereifte Alternativen, mit denen sich Client Secrets ablösen lassen und die Sicherheit deutlich steigt. Welcher Weg passt, hängt vom Anwendungstyp ab:

• Managed Identities für Azure-Ressourcen: Über diese „eingebaute“ Identität greifen VMs, Functions oder App Services auf Azure-Dienste zu, ohne dass dafür ein Secret oder Zertifikat nötig ist.
• Zertifikatbasierte Authentifizierung: Zertifikate liegen sicher im Azure Key Vault und lassen sich dort automatisch rotieren. Für eigene Backend-Services oder Daemons ist das meist die beste Wahl.
• Workload Identity Federation: CI/CD-Systeme wie GitHub Actions, Azure DevOps oder Kubernetes können „federated credentials“ verwenden. An die Stelle des klassischen Secrets tritt dann ein Vertrauensmodell, bei dem etwa GitHub ein Token ausstellt, das Entra ID akzeptiert (Details und Beispiele finden sich in der Microsoft-Doku).

Viele Teams schrecken vor dem Wechsel zurück, weil er auf den ersten Blick nach viel Arbeit aussieht. Meiner Erfahrung nach hält sich der Aufwand aber in Grenzen, während die Sicherheit spürbar zunimmt. Sind die wichtigsten Integrationen erst einmal umgestellt, geht der Rest meist deutlich leichter von der Hand.

App-Management-Policies setzen dem Wildwuchs bei Secrets Grenzen

Microsoft stellt mittlerweile einige Governance-Werkzeuge bereit, mit denen sich der Umgang mit Secrets besser steuern lässt. Mit sogenannten App-Management-Policies kann man zum Beispiel die maximale Lebensdauer neuer Secrets begrenzen oder das Anlegen neuer „password credentials“ ganz unterbinden (eine Anleitung dazu gibt es hier). In größeren Tenants, in denen viele Teams eigene App-Registrierungen erstellen, gehören diese Kontrollen aktiviert und in regelmäßigen Abständen überprüft.

Ebenso wichtig ist mir, dass jede App-Registrierung über ihren gesamten Lebenszyklus mindestens einen Owner hat und klar dokumentiert ist, wofür sie gedacht ist. Dann lässt sich die Verantwortung für Erneuerungen oder die spätere Ablösung problemlos übergeben, und im Tenant sammeln sich keine „verwaisten Apps“ an.

Der Umstieg gelingt am besten Schritt für Schritt

Wer umstellen will, sollte sich nicht alles auf einmal vornehmen. Sinnvoll ist zuerst eine Priorisierung. Welche Anwendungen haben weitreichende Berechtigungen? Bei welchen sind die Secrets bereits abgelaufen oder laufen in Kürze ab? Diese Kandidaten nimmt man sich dann der Reihe nach vor, die kritischsten zuerst. Für viele Szenarien, etwa Deployments aus GitHub oder Azure DevOps, ist der Wechsel zu föderierten Credentials bereits ausführlich beschrieben (siehe Microsoft Docs).

Das folgende Diagramm zeigt vereinfacht, wie die Authentifizierung mit Workload Identity Federation abläuft:

flowchart TD
    DevOpsPipeline["DevOps Pipeline"] --> TokenIssuer["Token-Aussteller (z.B. GitHub)"]
    TokenIssuer --> EntraID["Entra ID"]
    EntraID --> AppResource["Ziel-Ressource (z.B. API)"]

Abbildung: Föderierte Workload-Authentifizierung ohne Client Secret

Die Ablösung von Client Secrets lohnt sich ab dem ersten Schritt

Anfangs mag das Vorhaben nach viel Arbeit klingen. Doch schon mit der Bestandsaufnahme und den ersten Umstellungen gewinnt man rasch Übersicht und senkt die Risiken im Tenant spürbar. Bei neuen Anwendungen sollte das klassische Client Secret ohnehin die Ausnahme bleiben. Und für bestehende Integrationen ist jetzt ein guter Zeitpunkt, auf andere Authentifizierungsverfahren umzusteigen. Wer dabei auf Dokumentation, klare Zuständigkeiten und Policies achtet, ist besser geschützt und sieht der nächsten Secret-Erneuerung deutlich gelassener entgegen.