Secret Watcher: Überwachung des Ablaufs von Secrets¶

Ein abgelaufenes Secret ist eine häufige Ursache für eine fehlschlagende pipeline oder Anwendung. Der Secret Watcher ist eine geplante Prüfung, die die Secrets der App-Registrierungen ansieht, von denen die Plattform abhängt, und einen Alert auslöst, bevor sie ablaufen. Diese Seite beschreibt das Muster und was du konfigurieren musst. Die wiederkehrende Aufgabe drumherum steht im Wartungskalender.

Was überwacht wird¶

Element	Beispiele
Deployment-Identitäten der Plattform	Die Service Principals in `mcp.json`, die die pipelines nutzen (Betriebsverantwortlichkeiten)
Spoke-Service-Principals	Einer pro spoke (Spoke ändern)
Andere App-Registrierungen, die dem Plattform-Team gehören	Alles, was im Mapping unten aufgeführt ist

Die Prüfung liest die Client Secrets (Passwort-Credentials) jeder aufgeführten App-Registrierung. In der hier beschriebenen Version liest sie keine Zertifikate oder Federated Credentials. Federated Credentials haben kein Secret, das ablaufen kann, was ein Grund ist, sie zu bevorzugen (Secrets von App-Registrierungen).

So funktioniert es¶

flowchart LR
    s["Schedule<br/>(weekly)"] --> p["Pipeline loops<br/>over tenants"]
    p --> sc["Script"]
    sc -- "read-only Graph access" --> e["Entra ID<br/>app registrations"]
    sc -- "alert" --> o["On-call / incident tool"]

Eine pipeline läuft nach Zeitplan. Im Beispiel läuft sie wöchentlich, montagmorgens.
Die pipeline geht alle Tenants im Scope durch und führt das Script einmal pro Tenant aus.
Das Script meldet sich bei Microsoft Graph als Reader-Service-Principal in diesem Tenant an (Client Credentials).
Es sucht die für den Tenant aufgeführten App-Registrierungen in einer Mapping-Datei und liest ihre Secrets.
Für jedes Secret berechnet es die verbleibende Zeit und sendet einen Alert an das On-call-Tool, wenn das Secret bald abläuft.

Schwellenwerte im Beispiel¶

Verbleibende Zeit	Schweregrad des Alerts	Meldung
30 Tage oder mehr	Keiner
Weniger als 30 Tage	Info	Das Secret läuft innerhalb von 30 Tagen ab
Weniger als 3 Tage	Critical	Dringend: Das Secret läuft in `<days, hours>` ab
Bereits abgelaufen	Critical	Dringend: Das Secret ist bereits abgelaufen

Wähle eigene Schwellenwerte. Sie müssen dem Owner genug Zeit zum Rotieren lassen, einschließlich der Zeit, um eine Genehmigung einzuholen und die pipeline auszuführen. Eine wöchentliche Prüfung mit einer ersten Warnung bei 30 Tagen gibt dir etwa vier Gelegenheiten zu handeln.

Was du brauchst¶

Element	Hinweise
Ein Reader-Service-Principal pro Tenant	Berechtigung, App-Registrierungen zu lesen (die Microsoft-Graph-Application-Permission `Application.Read.All`). Gib ihm nicht mehr als das
Eine Mapping-Datei	Pro Tenant: die Tenant-ID, ein Name und die Liste der zu überwachenden App-IDs (Client-IDs). Beispiel unten
Ein sicherer Speicher für die Credentials	Zum Beispiel eine pipeline-Variablengruppe oder ein Key Vault. Die pipeline liest pro Tenant Client-ID, Secret und Tenant-ID
Ein Integration Key des On-call-Tools	Der Alert wird als Event an das Tool gesendet (siehe Monitoring ausrollen)
Eine pipeline mit Zeitplan	Geht die Tenants durch und ruft das Script auf

Beispiel für die Mapping-Datei, mit Platzhaltern:

{
  "customers": [
    {
      "tenant_id": "<tenant-id>",
      "name": "<organisation name>",
      "spn_ids": [
        "<app-id-1>",
        "<app-id-2>"
      ]
    }
  ]
}

Auch der Reader-Service-Principal hat ein Secret

Die Identität, die die Secrets überwacht, hat selbst ein Secret, das abläuft. Setze es auf dieselbe Liste und rotiere es nach einem festen Zeitplan. Wenn du keine Berechtigung bekommst, die App-Registrierungen in einem Tenant zu lesen, kannst du diesen Tenant nicht überwachen: Setze die Secrets dieses Tenants auf eine manuelle Liste im monatlichen Health Check.

Einen Tenant hinzufügen oder ändern¶

Schritt	Tenant hinzufügen	Tenant ändern
1	Lege den Reader-Service-Principal im Tenant an und gib ihm Lesezugriff auf App-Registrierungen	Aktualisiere den Eintrag in der Mapping-Datei (neue oder entfernte App-IDs)
2	Füge den Eintrag zur Mapping-Datei hinzu	Prüfe, ob die Credentials im sicheren Speicher aktuell sind
3	Speichere die Credentials des Readers im sicheren Speicher	Prüfe, ob das Script den Eintrag weiterhin verarbeitet
4	Füge den Tenant mit seinen Credentials zur Tenant-Liste in der pipeline hinzu	Prüfe die pipeline-Parameter
5	Führe die pipeline einmal aus und prüfe, ob der Tenant gelesen wird und ob ein Test-Secret kurz vor dem Ablauf einen Alert auslösen würde

Wenn ein Alert eintrifft¶

Finde den Owner der App-Registrierung. Bei Plattform-Identitäten ist das das Plattform-Team. Bei einer Anwendungs- Registrierung, die zu einem workload gehört, ist es das workload-Team (Wartungskalender).
Rotiere das Secret oder ersetze es durch ein Federated Credential, wenn der Service das unterstützt.
Nutze für eine Deployment-Identität der Plattform das Rotationsverfahren der Plattform (die pipeline update-spn legt ein neues Secret im hub Key Vault ab, siehe Pipelines und Workflows).
Halte die Rotation im Change-Record fest und prüfe den nächsten Lauf der pipeline, die das Secret nutzt.
Entferne Registrierungen, die niemandem gehören, nach einer Frist.

Grenzen¶

Es überwacht nur die App-Registrierungen in der Mapping-Datei. Eine neue App-Registrierung bleibt unsichtbar, bis jemand sie hinzufügt.
Es liest nur Client Secrets, keine Zertifikate (zum Beispiel Application-Gateway-Zertifikate im Key Vault).
Es ist eine Prüfung, keine Rotation. Jemand muss weiterhin auf den Alert reagieren.