Geheimnisse und Zertifikate von Entra-Anwendungen überwachen und rechtzeitig erneuern

Wie verhindert man, dass eine Entra-Anwendung wegen eines abgelaufenen Client Secrets oder Zertifikats ausfällt? Alle App-Credentials müssen mit Anwendung, Einsatzort, Eigentümer und Ablaufdatum inventarisiert werden. Die Erneuerung erfolgt vor dem Ablauf im Parallelbetrieb: neues Credential hinzufügen, Zielsystem aktualisieren, echte Anmeldung validieren und erst danach das alte Credential entfernen.

Ein Secret oder Zertifikat ist nicht die Anwendung selbst. Es ist ein Nachweis, mit dem sich eine Workload als Service Principal authentifiziert. Läuft dieser Nachweis ab, erhält die Anwendung kein Token mehr. Typische Fehler sind invalid_client, ungültige Client Credentials oder Zertifikatsfehler.

Credential-Arten unterscheiden

Für neue Produktionsworkloads sollte ein Secret die Ausnahme bleiben. Wenn Hosting und Hersteller es erlauben, sind Managed Identity, Workload Identity Federation oder Zertifikate robuster und betrieblich besser beherrschbar. Client Secrets bleiben eher ein Kompatibilitäts- oder Übergangsmechanismus.

Client Secret

Ein symmetrischer geheimer Wert wird bei der Tokenanforderung verwendet. Er ist einfach einzurichten, aber bei Speicherung und Verteilung riskant. Der Wert wird im Portal nur bei Erstellung angezeigt und muss sicher gespeichert werden.

Zertifikat

Die Anwendung signiert eine Client Assertion mit dem privaten Schlüssel; Entra kennt den öffentlichen Zertifikatsteil. Microsoft empfiehlt für Produktionsanwendungen häufig Zertifikate statt Client Secrets. Der private Schlüssel muss sicher geschützt werden.

Federated Identity Credential

Workload Identity Federation ermöglicht bestimmten externen Workloads, ohne gespeichertes Secret auf Basis eines Vertrauensverhältnisses ein Token zu erhalten. Typische Szenarien sind GitHub Actions, Kubernetes oder andere unterstützte Plattformen.

Managed Identity

Für unterstützte Azure-Ressourcen kann eine verwaltete Identität die Credential-Verwaltung reduzieren. Die Plattform verwaltet die Identität; die Anwendung benötigt kein eigenes Secret im Code.

Die beste Methode hängt vom Hosting und der Anwendung ab. Ein Secret sollte nicht reflexartig verwendet werden, nur weil es schnell erstellt ist.

Ein vollständiges Credential-Register

Für jede Anwendung werden mindestens erfasst:

• Anzeigename und Client ID,
• Application Object und Service Principal,
• fachlicher und technischer Owner,
• Zielsystem oder Hostingort,
• Credential-Typ,
• Key ID oder Zertifikat-Thumbprint,
• Start- und Ablaufdatum,
• Speicherort des privaten Materials,
• Rotationsverfahren,
• letzte erfolgreiche Nutzung,
• Vorwarnfristen,
• Rückfallkontakt.

Der geheime Wert oder private Schlüssel gehört nicht in das Register. Es verweist nur auf einen sicheren Secrets Store.

Wo Credentials liegen können

Neben Certificates & secrets einer App Registration können Credentials an Service Principals, SAML-SSO-Konfigurationen, Provisioning-Connectors oder Drittanbieteranwendungen vorkommen. Eine reine App-Registration-Liste ist deshalb unvollständig.

Prüfen Sie:

• App Registrations,
• Enterprise Applications,
• SAML-Signaturzertifikate,
• SCIM-Provisioning-Secrets,
• Automation Accounts und Runbooks,
• Azure Key Vault,
• CI/CD-Systeme,
• Power Automate Custom Connectors,
• lokale Dienste und geplante Aufgaben,
• Quellcode- und Konfigurationsrepositories.

Sichere Speicherung

Secrets gehören nicht in:

• Quellcode,
• unverschlüsselte Konfigurationsdateien,
• Tickets oder E-Mails,
• Wiki-Seiten,
• Chatnachrichten,
• Desktop-Notizen.

Geeignete Speicherorte sind beispielsweise verwaltete Secrets Stores wie Azure Key Vault oder ein freigegebenes Enterprise-Passwortmanagement, abhängig von Architektur und Anwendung. Zugriff und Abruf sollten protokolliert und auf Workload beziehungsweise Betreiber begrenzt sein.

Ablaufüberwachung

Microsoft Entra stellt Empfehlungen für auslaufende Anwendungs- und Service-Principal-Credentials bereit, teils als Preview und über Microsoft Graph. Unabhängig vom genutzten Feature sollte eine eigene Betriebsüberwachung Vorwarnungen erzeugen.

Empfohlene Stufen:

• langfristige Vorwarnung für Planung,
• zweite Warnung mit zugewiesenem Change,
• kritische Warnung kurz vor Ablauf,
• Eskalation bei fehlendem Owner,
• Incident bei bereits abgelaufenem Credential.

Die Vorlaufzeit muss zur Anwendung passen. Ein geschäftskritischer Dienst mit externem Hersteller benötigt mehr Zeit als ein internes Skript mit sofort verfügbarem Owner.

Rotation im Parallelbetrieb

1. Verwendung ermitteln

Vor der Rotation muss bekannt sein, wo das Credential hinterlegt ist. Client ID allein reicht nicht. Suchen Sie in Deployment-Konfiguration, Key Vault, App Service, Automatisierung, lokalen Diensten und Herstellerportalen.

2. Neues Credential erstellen

Erzeugen Sie ein neues Secret, Zertifikat oder föderiertes Vertrauen. Verwenden Sie klare Beschreibung und angemessene Laufzeit. Kopieren Sie geheime Werte direkt in den sicheren Speicher.

3. Zielsystem aktualisieren

Aktualisieren Sie den Secret-Verweis oder das Zertifikat in der Workload. Bei mehreren Instanzen kann ein gestaffeltes Deployment nötig sein.

4. Neue Anmeldung validieren

Für die Prüfung der erfolgreichen Umstellung reichen Health Checks allein selten aus. Relevant sind vor allem die passenden Sign-in-Logs: Service-Principal-Sign-ins und Managed-Identity-Sign-ins werden in Microsoft Entra getrennt ausgewertet und sollten deshalb auch getrennt in Monitoring und Diagnose auftauchen.

Ein erfolgreicher Health Check reicht nicht immer. Prüfen Sie:

• Tokenanforderung,
• Service-Principal-Sign-in-Logs,
• verwendeten Zertifikat-Thumbprint, soweit sichtbar,
• tatsächliche API-Aktion,
• Anwendungstelemetrie,
• Fehler- und Retry-Verhalten.

5. Beobachtungsphase

Lassen Sie altes und neues Credential kurz parallel gültig, wenn die Anwendung das unterstützt und das Risiko vertretbar ist. Beobachten Sie, ob weiterhin das alte Credential genutzt wird.

6. Altes Credential entfernen

Erst nach erfolgreicher Validierung wird das alte Credential entfernt. Danach erfolgt ein erneuter Test, um versteckte Instanzen zu erkennen.

Zertifikatsrotation

Zertifikate erfordern zusätzliche Kontrollen:

• privater Schlüssel vorhanden und geschützt,
• korrekte Key Usage und Algorithmusunterstützung,
• Zertifikatskette, falls Anwendung relevant,
• Uhrzeit und Gültigkeitsbeginn,
• Thumbprint im Zielsystem,
• Berechtigungen auf den privaten Schlüssel,
• Deployment auf alle Instanzen.

Ein häufiges Fehlerbild ist, dass nur das öffentliche Zertifikat in Entra aktualisiert wird, die Anwendung aber weiterhin mit dem alten privaten Schlüssel signiert.

SAML-Signaturzertifikate

Bei SAML-Enterprise-Applications können Zertifikate für das Signieren von Assertions oder Metadaten relevant sein. Die Rotation muss mit dem Service Provider abgestimmt werden. Je nach Anbieter kann ein sekundäres Zertifikat vorbereitet oder ein Metadaten-Refresh genutzt werden.

Testen Sie:

• neues Zertifikat in beiden Systemen,
• Signaturvalidierung,
• NameID und Claims unverändert,
• Login über Pilotbenutzer,
• Rückfall auf altes Zertifikat während des Wartungsfensters.

Typische Fehlerbilder

invalid_client

Mögliche Ursachen:

• Secret abgelaufen,
• falscher Secret-Wert statt Secret-ID verwendet,
• falsche Client ID oder Tenant ID,
• Zertifikat fehlt oder Thumbprint passt nicht,
• Credential im falschen App-Objekt erstellt,
• Uhrzeitabweichung oder fehlerhafte Assertion.

Neues Secret erstellt, Anwendung weiterhin gestört

Das neue Secret wird nicht automatisch in der Anwendung aktualisiert. Prüfen Sie sicheren Speicher, Konfigurationsreferenz, Deployment, Neustart und tatsächlich verwendete Instanz.

Altes Credential zu früh gelöscht

Rollback:

• falls altes Secret nicht wiederherstellbar ist, neues Credential erstellen,
• Zielsystem aktualisieren,
• Tokenanforderung testen,
• Incident dokumentieren.

Client-Secret-Werte können nach Erstellung nicht erneut angezeigt werden. Ein gelöschtes Secret wird nicht einfach wieder eingeblendet.

Owner hat das Unternehmen verlassen

Der technische Betrieb muss Eigentümer unabhängig vom Ersteller pflegen. Ergänzen Sie neue Owner, ermitteln Sie Verwendung, rotieren Sie Credentials und entfernen Sie persönliche Abhängigkeiten.

Anwendung nutzt unbekanntes Credential

Sign-in-Logs, Key IDs, Thumbprints und Konfigurationssuche helfen bei der Zuordnung. Löschen Sie unbekannte Credentials nicht ohne Beobachtungs- und Testphase, wenn ein geschäftskritischer Prozess möglich ist.

Incident bei bereits abgelaufenem Credential

1. betroffene Anwendung und Geschäftsprozess identifizieren,
2. Fehlermeldung und Zeitpunkt sichern,
3. Owner und Betrieb informieren,
4. neues Credential erstellen,
5. sicher im Zielsystem hinterlegen,
6. Dienst kontrolliert neu laden,
7. Token und Fachfunktion testen,
8. Backlog oder fehlgeschlagene Jobs nachverarbeiten,
9. Ursache für fehlende Warnung beheben,
10. weitere Credentials desselben Owners prüfen.

Berechtigungen bei Rotation nicht erweitern

Credential-Rotation ist kein Anlass, Permissions neu und breiter zu erteilen. Die Identität bleibt derselbe Service Principal. Falls gleichzeitig eine neue App Registration erstellt wird, müssen Consent, Rollen, Zuweisungen und Conditional Access gesondert geprüft werden.

Automatisierung der Inventarisierung

Microsoft Graph kann Applications und Service Principals samt Credential-Metadaten auslesen. Eine Inventarisierung sollte:

• Key IDs und Ablaufdaten erfassen,
• App- und Service-Principal-Credentials getrennt behandeln,
• Owner und letzte Nutzung ergänzen,
• Warnungen deduplizieren,
• keine Secret-Werte ausgeben,
• Ausnahmen und akzeptierte Risiken dokumentieren.

Preview-Empfehlungen können ergänzen, aber nicht den einzigen Betriebsmechanismus bilden.

Testkatalog

1. neues Secret im Parallelbetrieb,
2. neues Zertifikat mit Thumbprint-Prüfung,
3. Anwendung auf jeder Instanz,
4. Token für korrekten Tenant und Ressource,
5. tatsächliche Lese-/Schreiboperation,
6. altes Credential noch aktiv,
7. altes Credential entfernt,
8. Neustart oder Redeployment,
9. Failover-Instanz,
10. Alarmierung für nächstes Ablaufdatum.

Für die fachliche Einordnung einer Anwendung helfen zuerst Enterprise Applications und App Registrations unterscheiden und anschließend App-Berechtigungen und Admin Consent prüfen.

So werden ablaufende App-Zugangsdaten vom Notfall zum planbaren Wartungsvorgang

Credential-Betrieb besteht aus Inventar, Eigentum, sicherer Speicherung, Vorwarnung und getesteter Rotation. Neues und altes Credential werden kontrolliert parallel betrieben, die echte Anmeldung wird in Protokollen bestätigt und erst danach wird der Altbestand entfernt. Dadurch wird das Ablaufdatum zu einem normalen Change statt zu einem unangekündigten Anwendungsausfall.