Entra Service Principal: Überprivilegierte Admin-Rolle erkennen und beheben

Wodurch ein Entra Service Principal mit Admin-Rolle überprivilegiert wird

Ein überprivilegierter Entra Service Principal mit Admin-Rolle – gemessen daran, was seine Automatisierung tatsächlich tut – ist eine der am wenigsten überprüften Identitäten in Microsoft Entra ID und zugleich eine der gefährlichsten: Anders als ein menschlicher Admin muss er nie eine MFA-Abfrage bestehen, hat selten einen Lifecycle-Owner und überlebt oft das Projekt, das ihn erzeugt hat. Ein Service Principal ist die tenant-lokale Identität einer Anwendung oder eines Skripts – das, als das sich Terraform, eine CI/CD-Pipeline oder eine benutzerdefinierte Automatisierung authentifiziert, wenn sie Microsoft Graph aufruft. Erteilt man einem davon eine Verzeichnis-Admin-Rolle wie Globaler Administrator, Privileged Role Administrator oder Application Administrator, kann er alles tun, was ein menschlicher Admin in dieser Rolle auch könnte – Benutzer anlegen, Zugangsdaten zurücksetzen, neuen Berechtigungen zustimmen, Conditional Access ändern.

Es lohnt sich, das von einer verwandten, aber unterschiedlichen Exposition zu trennen. Eine Verzeichnisrolle (Thema dieses Artikels) gewährt tenant-weite administrative Fähigkeiten, zugewiesen über roleManagement/directory/roleAssignments. Eine App-Rollenzuweisung – die delegierten oder Anwendungsberechtigungen der Graph API wie Directory.ReadWrite.All, erteilt über servicePrincipals/{id}/appRoleAssignedTo (Grant an appRoleAssignment for a service principal) – ist dagegen ein separater, auf eine einzelne Ressourcen-API begrenzter Mechanismus und Thema von überprivilegierten Graph-API-Berechtigungen bei App-Registrierungen. Ein Service Principal kann keine, eine oder beide davon besitzen; dieser Artikel behandelt die Seite der Verzeichnisrolle.

Das Problem auf der Seite der Verzeichnisrolle ist die Exposition, nicht die Rolle an sich. Ein überprivilegierter Service Principal mit Admin-Rolle läuft rund um die Uhr, authentifiziert sich nicht-interaktiv mit einem Client Secret oder Zertifikat – und laut Microsofts eigener Anleitung zum Risiko von Workload-Identitäten „können [Workload-Identitäten] keine Multi-Faktor-Authentifizierung durchführen", „haben oft keinen formalen Lifecycle-Prozess" und „müssen ihre Zugangsdaten oder Secrets irgendwo speichern" (Securing workload identities with Microsoft Entra ID Protection). Auch die verpflichtende MFA-Durchsetzung von Microsoft Entra erreicht diese Identitäten ausdrücklich nicht: Microsoft bestätigt, dass Workload-Identitäten „von keiner der beiden Phasen" des verpflichtenden MFA-Rollouts betroffen sind (Plan for mandatory Microsoft Entra multifactor authentication). Ein geleaktes Secret für einen Service Principal mit Admin-Rolle ist eine geleakte, MFA-resistente Admin-Sitzung.

Diese Lücke ist selten eine einzelne Fehlkonfiguration. Meist ist es ein Cluster verwandter blinder Flecken, die sich gegenseitig verstärken: Die Admin-Rolle ist breiter als die Automatisierung braucht, niemand besitzt den Service Principal, das Deaktivieren entzieht die Berechtigung nicht wirklich, und – zunehmend – die Identität mit der Rolle stammt nicht einmal aus dem eigenen Tenant.

Wie überprivilegierte Service Principals entstehen

Standing, nicht eligible

Privileged Identity Management (PIM) erlaubt es, die Rollenzuweisung eines menschlichen Admins als eligible zu führen – inaktiv, bis er sie aktiviert, zeitlich begrenzt und protokolliert. Service Principals können dieses Modell nicht nutzen: Microsoft-Entra-Rollen, Azure-Rollen und PIM für Gruppen können einem Service Principal ausschließlich eine aktive Zuweisung erteilen, weil eligible Zuweisungen einen Aktivierungsschritt (Genehmigung, MFA-Abfrage) erfordern, den eine nicht-interaktive Identität nicht durchführen kann (Eligible and time-bound role assignments in Azure RBAC). In der Praxis ist jeder Service Principal mit Admin-Rolle in Ihrem Tenant konstruktionsbedingt eine Standing-Zuweisung – es gibt kein PIM-Sicherheitsnetz, das sie zeitlich begrenzt, sofern nicht separat ein Ablaufdatum für die Zuweisung gesetzt wurde.

Kein Owner

servicePrincipal.owners soll die Frage „Wer ist dafür verantwortlich" beantworten. Microsoft Graph stellt es als Sammlung bereit, die per POST /servicePrincipals/{id}/owners-$ref-Aufruf befüllt wird (servicePrincipal: Add owner) – aber nichts erzwingt, dass sie bei der Erstellung befüllt wird. Ein Service Principal, der bei einer Rollenzuweisungs-Prüfung mit leerer Owners-Sammlung auftaucht, hat eine Admin-Rolle, über die niemand benachrichtigt wird, die niemand beim Offboarding überprüft und die niemand in einem Incident-Call erklären kann.

Deaktiviert, aber weiterhin berechtigt

accountEnabled an einem Service Principal ist ein boolescher Wert, der die Anmeldung blockiert, wenn er auf false gesetzt ist – „keine Benutzer können sich bei dieser App anmelden, selbst wenn sie ihr zugewiesen sind" (servicePrincipal resource type). Er berührt Rollen- oder App-Rollenzuweisungen nicht – deren Entfernung ist eine eigene Operation mit eigenem Cmdlet, Remove-MgServicePrincipalAppRoleAssignment (Microsoft Learn). Ein Team, das eine Integration „stilllegt", indem es accountEnabled auf false setzt und es dabei belässt, lässt die Admin-Rollenzuweisung vollständig intakt – ein erneutes Aktivieren des Kontos, oder ein Angreifer, der dasselbe Flag zurücksetzen kann, stellt den Admin-Zugriff sofort wieder her.

Aus einer externen Organisation

Nicht jeder Service Principal in Ihrem Tenant wurde von Ihnen erstellt. Multi-Tenant-App-Registrierungen legen lokal einen Service Principal an, während das zugrunde liegende Anwendungsobjekt im Home-Tenant des Anbieters oder Partners verbleibt – festgehalten als appOwnerOrganizationId, die Microsoft Entra auch in die zusätzlichen Details des Audit-Ereignisses bei der Bereitstellung des Service Principal schreibt (Understand why a service principal was created in your tenant). Stimmt appOwnerOrganizationId nicht mit Ihrer eigenen Tenant-ID überein und hält dieser Service Principal zusätzlich eine Admin-Rolle, haben Sie standing Admin-Zugriff an eine Identität delegiert, die ein Dritter kontrolliert – das Anwendungs-Äquivalent zur Cross-Tenant-Gastexposition, die die meisten Teams bereits für Benutzerkonten im Blick haben, für Anwendungen jedoch fast nie.

Erkennung

Ziehen Sie jede Verzeichnisrollenzuweisung und gleichen Sie ab, welche Principals Service Principals sind und welche Benutzer oder Gruppen – Get-MgRoleManagementDirectoryRoleAssignment filtert nicht selbst nach Principal-Typ, daher muss das über einen Abgleich mit Get-MgServicePrincipal aufgelöst werden (List Microsoft Entra role assignments):

Connect-MgGraph -Scopes "RoleManagement.Read.Directory","Application.Read.All"

$roles = Get-MgRoleManagementDirectoryRoleDefinition
$spAssignments = foreach ($role in $roles) {
    Get-MgRoleManagementDirectoryRoleAssignment -Filter "roleDefinitionId eq '$($role.Id)'" |
        ForEach-Object {
            $sp = Get-MgServicePrincipal -ServicePrincipalId $_.PrincipalId -ErrorAction SilentlyContinue
            if ($sp) {
                [pscustomobject]@{
                    ServicePrincipal = $sp.DisplayName
                    RoleAssigned     = $role.DisplayName
                    AccountEnabled   = $sp.AccountEnabled
                    OwnerCount       = (Get-MgServicePrincipalOwner -ServicePrincipalId $sp.Id).Count
                    AppOwnerOrgId    = $sp.AppOwnerOrganizationId
                }
            }
        }
}
$spAssignments | Format-Table -AutoSize

Dieselbe Abfrage funktioniert auch direkt gegen Microsoft Graph, ohne das PowerShell-Modul – nützlich für ein Skript, das außerhalb einer Workstation mit installiertem Graph SDK läuft:

GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments?$filter=roleDefinitionId eq '{role-template-id}'

Jedes Ergebnis liefert eine principalId; lösen Sie sie über GET /servicePrincipals/{id} auf, um den Principal-Typ zu bestätigen und accountEnabled, appOwnerOrganizationId sowie – über GET /servicePrincipals/{id}/owners – die Owners-Sammlung im selben Aufruf zu ermitteln (List Microsoft Entra role assignments).

Für das Zuweisungsereignis selbst filtern Sie die Microsoft-Entra-Audit-Logs nach dem Dienst Core Directory und der Kategorie Role Management, und suchen Sie dann nach Aktivitätseinträgen vom Typ „Add member to role", wobei Sie TargetResources auf den Typ ServicePrincipal eingrenzen, um nicht-menschliche Zuweisungen von Benutzer-Zuweisungen zu trennen (Easily Manage Privileged Role Assignments in Microsoft Entra ID Using Audit Logs). Exportieren Sie diese Logs, bevor sie ablaufen – die Aufbewahrung der Entra-Audit-Logs ist standardmäßig kurz und geht ohne konfigurierte Diagnoseeinstellungen leicht verloren.

Behebung

1. Rolle richtig dimensionieren. Ersetzen Sie breite Admin-Rollen (Globaler Administrator, Privileged Role Administrator) durch die schmalste integrierte oder benutzerdefinierte Rolle, die die tatsächlichen Graph-Aufrufe der Automatisierung abdeckt – die meisten Integrationen benötigen Application Administrator oder eine ressourcenbegrenzte Rolle, nicht Globaler Administrator. Ein Service Principal, der nur Benutzer provisioniert, braucht nicht dieselbe Rolle wie einer, der Conditional Access verwaltet.
2. Owner zuweisen. POST /servicePrincipals/{id}/owners mit einem $ref auf einen verantwortlichen Engineer, damit die Zuweisung in Access Reviews auftaucht statt erst während eines Incidents sichtbar zu werden.
3. Berechtigungen entfernen, bevor deaktiviert wird. Führen Sie Remove-MgServicePrincipalAppRoleAssignment (oder die entsprechende Entfernung der Verzeichnisrolle) als Teil des Decommissioning-Runbooks aus – verlassen Sie sich nicht allein auf accountEnabled: $false, und betrachten Sie eine „deaktivierte" Integration erst dann als abgeschlossen, wenn die Rollenzuweisung selbst weg ist.
4. Wo möglich ein Ablaufdatum setzen. Da Service Principals nur aktive Zuweisungen halten können, nutzen Sie bei der Vergabe die Enddatum-Option der Zuweisung, damit eine Admin-Rolle nicht stillschweigend zum Dauerzustand wird.
5. Workload-Identitäten mit Conditional Access absichern. Conditional Access für Workload-Identitäten kann die Anmeldung eines Single-Tenant-Service-Principal nach Standort oder Identity-Protection-Risikostatus blockieren – es erzwingt keine MFA (das können Service Principals nicht), schließt aber einen Teil der Lücke, die MFA nicht erreichen kann.
6. Service Principals aus externen Organisationen einzeln bewerten. Bestätigen Sie für jeden SP_EXTERNAL_ORGANIZATION-Treffer mit Admin-Rolle, dass die Anbieterbeziehung aktuell und die Rolle weiterhin gerechtfertigt ist – dieselbe Sorgfalt, die Sie bei einem Gastkonto mit standing Zugriff anwenden würden, angewendet auf eine Anwendung statt auf eine Person.

Das ergänzt die Prüfung, die die meisten Teams für menschlichen privilegierten Zugriff bereits durchführen – siehe Azure Privilegierter Zugriff: Zu Viele Globale Admins und How to Audit Microsoft Entra ID Security – und ist eigenständig, aber verwandt mit überprivilegierten Graph-API-Berechtigungen bei der App-Registrierung selbst, was eine separate Exposition zur Verzeichnisrolle des Service Principal darstellt.

Wie EtcSec das erkennt

EtcSecs Azure-Audit prüft PA_SERVICE_PRINCIPAL_ADMIN und SP_HIGH_PRIVILEGE gegen jede von einem Service Principal gehaltene Verzeichnisrollenzuweisung und kennzeichnet zusätzlich SP_NO_OWNER, SP_DISABLED_WITH_PERMISSIONS und SP_EXTERNAL_ORGANIZATION, sodass die oben beschriebenen Lücken bei Ownership, Lifecycle und Cross-Tenant-Zugriff als Findings sichtbar werden, statt jedes Quartal einen manuellen PowerShell-Sweep über jede Rollendefinition im Tenant zu erfordern.