Entra App-Registrierung: Rotation von Zugangsdaten und Secrets-Hygiene

Was Ist Credential-Hygiene Bei Entra App-Registrierungen

Die Rotation von Zugangsdaten bei Entra App-Registrierungen betrifft die Client-Secrets, Zertifikate und federated credentials, mit denen sich Ihre Anwendungen authentifizieren – und sie gehört zu den am meisten übersehenen Ecken der Identitäts-Angriffsfläche in einem Tenant. Jede App-Registrierung, die sich selbst authentifiziert, ob Daemon, CI/CD-Pipeline oder API-Integration, braucht ein Credential, um zu beweisen, dass sie ist, wer sie vorgibt zu sein. Dieses Credential ist ein passwordCredential (ein Client-Secret), ein keyCredential (ein hochgeladener Zertifikats-Public-Key) oder ein federated credential (eine Vertrauensbeziehung zu einem externen Identity-Provider, ganz ohne Secret-Material). Vergisst man, eines davon zu rotieren, wird aus einem routinemäßigen Credential still und leise eine dauerhafte Hintertür – ohne MFA-Prompt und oft ohne einen Owner, der sie im Blick behält.

Das ist relevant, weil das Credential einer App-Registrierung genau das gewährt, was die Berechtigungen dieser Anwendung erlauben: Microsoft-Graph-API-Scopes, delegierte oder Application Permissions, manchmal verzeichnisweiten Lese-/Schreibzugriff. Microsofts eigene Empfehlung ist eindeutig: Client-Secrets sind weniger sicher als Zertifikats- oder federated Credentials und sollten in Produktion nicht verwendet werden; mit Workload Identity Federation entfällt der Wartungsaufwand der manuellen Credential-Verwaltung sowie das Risiko geleakter Secrets oder ablaufender Zertifikate. Ein Tenant, der App-Credentials nie inventarisiert, kann ein routinemäßiges Secret nicht von einem unterscheiden, das still und leise jeden Admin überlebt hat, der einmal wusste, wofür es gedacht war.

Das ist ein anderer Blickwinkel als bei überprivilegierten App-Registrierungen (behandelt in Azure App-Registrierungen: Sicherheitsrisiken) – jener Beitrag dreht sich darum, was eine App tun kann; dieser hier dreht sich darum, wie lange ihre Schlüssel zur Tür gültig bleiben und ob überhaupt jemand das Schloss im Blick hat. Ein geleaktes langlebiges Secret wird genauso missbraucht wie ein durch Phishing erbeutetes OAuth-Token bei OAuth Consent Phishing: lautlos, mit den eigenen Berechtigungen der App, bis jemand bemerkt, dass die Aktivität nicht zum normalen Verhalten der App passt.

Wie Es Funktioniert: Secrets, Zertifikate Und Warum Rotation Übersprungen Wird

Jedes application- und servicePrincipal-Objekt in Microsoft Graph stellt zwei Credential-Sammlungen bereit:

• passwordCredentials — Client-Secrets, jeweils mit keyId, startDateTime und endDateTime. Laut der passwordCredential-Ressourcenreferenz ist endDateTime der ISO-8601-UTC-Zeitstempel, nach dem das Secret nicht mehr funktioniert.
• keyCredentials — hochgeladene Zertifikats-Public-Keys für zertifikatsbasierte Authentifizierung (CBA), jeweils mit eigenem Ablaufdatum.

Im Portal erstellte Client-Secrets sind auf eine maximale Laufzeit von 24 Monaten begrenzt, und Microsoft empfiehlt ausdrücklich, ein Ablaufdatum unter 12 Monaten zu setzen, statt standardmäßig das Maximum zu wählen. In der Praxis machen Teams oft das Gegenteil: Sie wählen die längste angebotene Laufzeit, damit nichts unerwartet ausfällt, und lassen die App danach in Ruhe. Zwei Jahre später hat die Person, die sie eingerichtet hat, das Unternehmen verlassen, das Secret ist immer noch gültig, und niemand erinnert sich mehr, welche Pipeline oder welches Skript davon abhängt.

Ein verwandtes, aber eigenständiges Problem ist Credential-Sprawl: Eine Anwendung sammelt im Lauf der Zeit mehrere aktive Secrets an, weil Rotation durch Hinzufügen eines neuen Secrets erfolgte statt durch Ersetzen des alten. Jedes zusätzliche aktive Secret ist ein weiterer Zugangsweg, der nachverfolgt, widerrufen und geprüft werden muss – und alte Secrets aus einer Rotation, die „funktioniert hat", werden routinemäßig nie aufgeräumt. Es ist üblich, mehrere Jahre alte App-Registrierungen mit drei oder vier aktiven Secrets vorzufinden, jedes von einem anderen Admin während eines anderen Vorfalls angelegt, keines davon je widerrufen.

Zertifikatsbasierte Authentifizierung ist grundsätzlich die sicherere der beiden Credential-Arten – der private Schlüssel eines Zertifikats muss nie übertragen oder in eine Konfigurationsdatei eingefügt werden, wie es bei einem Secret-Wert der Fall ist. Aber ein aktives CBA-Zertifikat bleibt ein aktives Credential mit Ablaufdatum und einem Wirkungsradius, falls der private Schlüssel kompromittiert wird, und Microsoft empfiehlt, Zertifikate von einer vertrauenswürdigen CA ausstellen zu lassen, mit einer Richtlinie, die vertrauenswürdige Aussteller erzwingt, statt selbstsignierter Zertifikate mit unbegrenztem Vertrauen.

Rotationslücken Bei Entra App-Registrierungen Erkennen: Veraltet Oder Ausufernd

Beginnen Sie mit einer Inventarisierung, nicht mit einer Stichprobe – Sie können nicht rotieren, was Sie nicht gezählt haben.

Jedes Credential Über Microsoft Graph Inventarisieren

Fragen Sie die Credentials jeder Anwendung direkt ab:

GET https://graph.microsoft.com/v1.0/applications
    ?$select=id,displayName,passwordCredentials,keyCredentials

Die Antwort enthält endDateTime für jedes Secret und Zertifikat, sodass Sie bereits abgelaufene oder bald ablaufende Credentials markieren können.

Tenant-Weit Per PowerShell Skripten

Das Microsoft Graph PowerShell SDK macht es einfacher, dies tenant-weit statt App für App auszuführen:

# Erfordert: Connect-MgGraph -Scopes "Application.Read.All"
Get-MgApplication -All -Property Id, DisplayName, PasswordCredentials, KeyCredentials |
  ForEach-Object {
    $app = $_
    $app.PasswordCredentials | ForEach-Object {
      [PSCustomObject]@{
        App        = $app.DisplayName
        Type       = "Secret"
        KeyId      = $_.KeyId
        Expires    = $_.EndDateTime
        DaysLeft   = ($_.EndDateTime - (Get-Date)).Days
      }
    }
    $app.KeyCredentials | ForEach-Object {
      [PSCustomObject]@{
        App        = $app.DisplayName
        Type       = "Certificate"
        KeyId      = $_.KeyId
        Expires    = $_.EndDateTime
        DaysLeft   = ($_.EndDateTime - (Get-Date)).Days
      }
    }
  } | Sort-Object DaysLeft

Die Signale Lesen, Die Zählen

Ordnen Sie aus dieser Inventarisierung Befunde konkretem Risiko zu:

Tatsächliche Nutzung In Den Sign-In-Logs Bestätigen

Prüfen Sie, wie Credentials tatsächlich genutzt werden, nicht nur, was existiert, über die Sign-in-Logs von Service Principals. Jedes Sign-in-Ereignis trägt ein Feld ClientCredentialType: Der Wert Client-Secret zeigt passwortbasierte Authentifizierung an, während zertifikatsbasierte Authentifizierung als Client-Assertion erscheint, zusammen mit einer ClientCredentialKeyID, die Sie auf die konkrete keyId in der Credential-Liste der App zurückführen können. Diese Zuordnung zeigt Ihnen, welches Credential tatsächlich produktiv im Einsatz ist und welche toter Ballast sind, den niemand entfernt hat – eine Unterscheidung, die die reine Credential-Inventarisierung allein nicht liefern kann. Taucht ein Credential eher in einer Risikoerkennung als in einem routinemäßigen Sign-in auf, behandeln Sie es so, wie es Azure Identity Protection: Reaktion auf Kompromittierte Konten für jedes andere geleakte-Credential-Signal empfiehlt.

Credential-Änderungen Im Audit-Log Nachverfolgen

Für die historische Änderungsnachverfolgung filtern Sie das Entra-Audit-Log nach Category = ApplicationManagement: Hinzufügungen und Entfernungen von Credentials bei Anwendungen und Service Principals werden als geänderte Eigenschaften der Zielressource protokolliert, die Sie pro App überprüfen können – siehe die Referenz zu Microsoft-Entra-Audit-Log-Aktivitäten. Exportieren Sie diese bei Bedarf einer längeren Aufbewahrung als dem Standardfenster des Admin Centers in ein SIEM oder einen Log-Analytics-Workspace, gemäß der Übersicht zu Audit-Logs.

Behebung: Rotieren, Einschränken Und Weg Von Secrets

Erst Inventarisieren, Dann Rotieren

Führen Sie die obige Graph-Abfrage über alle Anwendungen aus, bevor Sie irgendetwas anfassen — Sie müssen wissen, welche Secrets tatsächlich von einem laufenden Workload referenziert werden, bevor Sie sie widerrufen. Ein noch genutztes Secret zu rotieren oder zu löschen bricht den davon abhängigen Workload, dieser Schritt ist also nicht optional.

Ersetzen, Nicht Hinzufügen

Bei der Rotation erstellen Sie das neue Secret oder Zertifikat, aktualisieren den konsumierenden Workload, verifizieren die Authentifizierung, dann löschen Sie das alte Credential. Ein neues hinzuzufügen und das alte „sicherheitshalber" zu belassen, ist genau, wie Multi-Secret-Sprawl überhaupt erst entsteht.

Zu Zertifikaten Oder Federated Credentials Wechseln

Microsoft empfiehlt Zertifikate gegenüber Client-Secrets, bevor eine App produktiv geht, und federated credentials, wo die Workload-Plattform sie unterstützt — das eliminiert das Rotationsproblem vollständig, statt es lediglich besser zu verwalten.

Den Standard Tenant-Weit Erzwingen

Statt sich darauf zu verlassen, dass jeder App-Owner sich selbst diszipliniert, erzwingen Sie Credential-Standards über eine Application Management Policy. Policies werden über Microsoft Graph oder Graph PowerShell konfiguriert (keine Portal-UI) und können die Zertifikatslaufzeit begrenzen sowie neue Password Credentials komplett blockieren:

# Erfordert: Connect-MgGraph -Scopes "Policy.ReadWrite.ApplicationConfiguration"
$policy = @{
  displayName    = "Enforce credential standards"
  isEnabled      = $true
  applications   = @{
    keyCredentials = @(
      @{
        restrictionType = "asymmetricKeyLifetime"
        maxLifetime     = "P180D"
        state           = "enforced"
      }
    )
    passwordCredentials = @(
      @{
        restrictionType = "passwordAddition"
        state           = "enforced"
      }
    )
  }
}
New-MgPolicyAppManagementPolicy -BodyParameter $policy

Siehe das Tutorial zur Durchsetzung von Secret- und Zertifikatsstandards und die Konfiguration von Application-Management-Policy-Einschränkungen für alle verfügbaren Einschränkungstypen, einschließlich der Frage, ob eine Policy auf bestimmte Apps oder tenant-weit angewendet wird.

Einen Owner Zuweisen Und Regelmäßig Überprüfen

Ein Credential, das niemandem gehört, ist ein Credential, das niemand rotiert oder widerruft, wenn es fällig ist. Kombinieren Sie Ownership mit einer wiederkehrenden Überprüfung der oben genannten Inventarisierungsabfrage — mindestens monatlich für Apps mit privilegierten Graph-Berechtigungen.

Zertifikatsvertrauen Prüfen, Nicht Nur Ablauf

Für CBA im Speziellen: Bestätigen Sie, dass aktive Zertifikate von einer vertrauenswürdigen CA gemäß Ihren Sicherheits-Best-Practices für App-Registrierungseigenschaften stammen, und nicht von einem selbstsignierten Zertifikat, an dessen Ausstellung sich niemand mehr erinnert.

Verwandte Beiträge: Entra SAML-Signaturzertifikat Abgelaufen behandelt, was passiert, wenn ein anderer Zertifikatstyp — SAML-Signierung — unüberwacht abläuft, und Microsoft Entra ID Sicherheit Auditieren: Leitfaden führt durch die Überprüfung von App-Berechtigungen als Teil eines umfassenderen Tenant-Audits.

Wie EtcSec Dies Erkennt

EtcSecs Entra-Audit prüft die Credentials von Anwendungen und Service Principals bei jedem Scan direkt gegen Microsoft Graph. APP_NO_CREDENTIAL_ROTATION markiert Apps, deren Credentials veraltet sind, ohne dass eine Ersatz-Aktivität stattgefunden hat; APP_SECRET_LONG_EXPIRY und APP_SECRET_EXPIRED erfassen Secrets mit überlanger Laufzeit oder bereits abgelaufenem endDateTime; APP_MULTIPLE_SECRETS deckt Credential-Sprawl durch additive Rotation auf; SP_STALE_CREDENTIAL weitet dieselbe Prüfung auf Service Principals aus; und CBA_CERTIFICATES_ACTIVE inventarisiert jede Anwendung, die derzeit auf zertifikatsbasierte Authentifizierung setzt, damit Sie Vertrauen und Ablauf bewusst prüfen können, statt es erst zu merken, wenn es ausfällt.