App Management Policies blockieren Client Secrets im ganzen Tenant

In vielen Tenants, die ich derzeit betreue, sind App-Registrierungen ein Dauerthema. Fast jede Woche stoße ich auf Service Principals, die im Hintergrund mit unsicheren, unbefristeten Client Secrets laufen – oft als Schatten-IT oder als Überbleibsel alter Automatisierungen. An dieser Stelle helfen die App Management Policies in Microsoft Entra ID. Mit ihnen könnt ihr das Anlegen von Secrets für den gesamten Tenant oder gezielt für einzelne Apps blockieren und die maximale Lebensdauer von Passwörtern und Zertifikaten festlegen. Die Identity-Governance wird dadurch spürbar besser.

App Management Policies setzen Regeln für Secrets technisch durch

Die Idee dahinter ist einfach. Anstatt allein auf Schulungen und Prozesse zu vertrauen, setzt ihr technisch durch, dass niemand mehr im Portal oder per API ein neues Client Secret für eine App anlegt, es sei denn, ihr habt eine Ausnahme definiert. Ebenso lässt sich die maximale Gültigkeit von Zertifikaten begrenzen. Für Tenants, in denen früher gern zu „schnellen“ Lösungen gegriffen wurde, ist das ein großer Fortschritt. Gesteuert werden die Policies über Microsoft Graph; Microsoft beschreibt die Details in der offiziellen Dokumentation und in der Referenz zum Graph-Objekt tenantAppManagementPolicy.

Die Tenant Default Policy bildet das Sicherheitsnetz für App-spezifische Ausnahmen

Bevor ihr loslegt, solltet ihr wissen, dass es zwei Arten von Policies gibt. Die Tenant Default Policy gilt global, einzelne App Management Policies weist ihr gezielt bestimmten Apps zu. Die Tenant Default Policy setzt ihr zuerst, sie dient als Sicherheitsnetz. Läuft bei euch noch eine Legacy-Anwendung, die zwingend Client Secrets braucht, lockert ihr die Vorgaben nur für diese App und bleibt bei allen anderen konsequent. Das wird vor allem dann wichtig, wenn moderne und alte Anwendungen nebeneinander laufen und sich die alten nicht kurzfristig modernisieren lassen. Diese Mischung erlebe ich häufig. Laut der aktuellen Ankündigung beginnt die Einführung mit einem Audit-Modus, sodass ihr erst einmal beobachten könnt, welche Apps betroffen wären, bevor eine harte Blockade greift.

flowchart TD
    Start["App Registrierung"] --> CheckPolicy["Policy prüfen"]
    CheckPolicy -->|"Ausnahme für App konfiguriert?"| ExceptionPolicy["App Policy" ]
    ExceptionPolicy -->|"Erlaubt?"| AllowSecret["Secret/Credential erlaubt"]
    ExceptionPolicy -->|"Nicht erlaubt"| BlockSecret["Secret/Credential blockiert"]
    CheckPolicy -->|"Keine Ausnahme"| DefaultPolicy["Tenant Default Policy"]
    DefaultPolicy -->|"Erlaubt?"| AllowSecret
    DefaultPolicy -->|"Nicht erlaubt"| BlockSecret

Abbildung: So wird die App Management Policy beim Anlegen neuer Credentials geprüft

Die Konfiguration läuft ausschließlich über Microsoft Graph

Im Entra-ID-Portal lässt sich das nicht einstellen. Konfiguriert wird ausschließlich über Microsoft Graph, zum Beispiel mit dem PowerShell-Modul Microsoft.Graph. Die Standard-Policy legt ihr mit Update-MgPolicyDefaultAppManagementPolicy fest. Dafür braucht ihr die Rolle „Cloud Application Administrator“ (oder höher) und die Lizenz Workload Identities Premium. Für eine Ausnahme bei einer einzelnen App nehmt ihr Update-MgPolicyAppManagementPolicy und gebt die Ziel-App über ihre Objekt-ID an. Ein typischer Aufruf, der Secrets tenantweit blockiert und für eine App trotzdem eine Ausnahme zulässt, sieht so aus:

# Tenant Default: Secrets blockieren
Update-MgPolicyDefaultAppManagementPolicy -PasswordCredentialCreationBlocked $true
# Ausnahme für App 12345678-1234-1234-1234-123456789abc
Update-MgPolicyAppManagementPolicy -AppId 12345678-1234-1234-1234-123456789abc -PasswordCredentialCreationBlocked $false

Tipp aus der Praxis: Startet mit dem Audit-Modus, behaltet die Logs im Blick und informiert alle App-Owner rechtzeitig. Von der Umstellung sind oft auch Integrationen betroffen, die kaum jemand auf dem Schirm hat.

In größeren Tenants lohnt es sich, vorher ein Inventar aller App-Registrierungen und ihrer Authentifizierungsmethoden anzulegen. Wie das mit Graph PowerShell geht, habe ich im Beitrag Client Secrets sicher ablösen – Alternativen, Audit und Migration gezeigt.

Legacy-Apps brauchen befristete und dokumentierte Ausnahmen

Nicht jede App lässt sich sofort modernisieren. Deshalb könnt ihr die Policies gezielt abschwächen, etwa damit eine Legacy-Lösung für einen festgelegten Zeitraum weiterhin Client Secrets nutzen darf. Diesen Zeitraum solltet ihr unbedingt dokumentieren! Schatten-Integrationen werden häufig unterschätzt, und nicht selten bleibt plötzlich eine Automatisierung im Hintergrund stehen. Mit einer vorgeschalteten Audit-Phase behaltet ihr beim Rollout den Überblick, darauf würde ich nicht verzichten. Achtet außerdem auf die Laufzeiten von Zertifikaten. Standardmäßig sind sehr lange Laufzeiten möglich, deshalb lohnt sich eine realistische Obergrenze für neue Zertifikate.

App Management Policies geben Admins endlich echte Kontrolle über App-Registrierungen

Für mich gehören die App Management Policies zu den wichtigsten Neuerungen der letzten Jahre, wenn es um Governance in Entra ID geht. Client Secrets zentral zu blockieren und Ausnahmen eng zu steuern, erleichtert vor allem den Admins das Leben, denen Schatten-Integrationen schlaflose Nächte bereitet haben. Disziplin und Nacharbeit bleiben zwar nötig, doch eine echte Standardisierung lässt sich jetzt technisch erzwingen. Wer die Policies überlegt einsetzt, erhöht die Sicherheit und steht bei künftigen Audits besser da. Als Tenant-Admin schläft man dann auch ein Stück ruhiger.