In vielen Tenants, die ich betreue, stehen den Hunderten Benutzerkonten inzwischen immer mehr Service Principals gegenüber. Diese Identitäten entstehen meist für Automatisierungen, Integrationen oder interne Tools und geraten danach schnell in Vergessenheit. Mit dem neuen Lizenzmodell „Microsoft Entra Workload ID Premium“ kann man Conditional Access erstmals gezielt auf solche Workload Identities anwenden. Trocken ist das Thema keineswegs, denn gerade Service Principals mit privilegierten Rechten bieten eine erhebliche Angriffsfläche.

Service Principals brauchen inzwischen ebenso Schutz wie Benutzerkonten

Bei der klassischen Zugangskontrolle kamen Service Principals bisher kaum vor. Die meisten Admins haben sich auf Benutzerkonten konzentriert, also auf MFA, Named Locations und Risk Policies. Spätestens nach mehreren Vorfällen – ich denke etwa an kompromittierte App-Registrierungen und gestohlene Client-Secrets – ist aber klar, dass auch Identitäten ohne Benutzerbezug auf mehreren Ebenen geschützt werden müssen. Mit Conditional Access für Workload Identities setzt man Richtlinien wie „Anmeldungen außerhalb bekannter IPs blockieren“ oder „Risikobehaftete Service Principals blockieren“ direkt durch. Das funktioniert allerdings nur mit Single-Tenant-Service-Principals, die ausschließlich im eigenen Tenant verwendet werden und nicht als Managed Identity laufen. Welche Typen von Workload Identities es gibt, habe ich in einem eigenen Beitrag beschrieben.

Die Richtlinien decken zwei Szenarien ab und haben klare Grenzen

Die neuen Conditional-Access-Steuerungen für Workload Identities erlauben Regeln, die sich gezielt auf Service Principals beziehen. Zwei Szenarien sehe ich in der Praxis besonders oft:

  • Zugriff auf bekannte IP-Bereiche einschränken: Über „Named Locations“ blockiert man Anmeldungen, die nicht aus den definierten Adressbereichen kommen. Das eignet sich vor allem für automatisierte Dienste im Rechenzentrum oder für Azure Functions, deren Quell-IPs bekannt sind.
  • Zugriff anhand des Service-Principal-Risikos steuern: Stuft Entra ID Protection einen Service Principal als „risikoreich“ ein, lässt sich der Zugriff blockieren oder zunächst im Report-only-Modus testen (siehe Workload Identity Risk).

Beachtet dabei, dass diese Richtlinien nur für Single-Tenant-Service-Principals gelten. Multi-Tenant-Apps und Managed Identities werden derzeit nicht unterstützt (vgl. Workload Identities Overview). In manchen Integrationsszenarien bleibt dadurch nur wenig Spielraum. Wer noch mit Client-Secrets arbeitet, sollte ohnehin über Alternativen wie Workload Identity Federation nachdenken (eine praktische Anleitung findet ihr hier).

Praxistipp: Testet neue CA-Richtlinien für Workload Identities immer zuerst im Report-only-Modus. Bei produktiven Diensten sperrt man sonst schnell versehentlich legitime Zugriffe. Auch die Fehlermeldungen helfen nicht immer weiter, denn hinter einem „Access Denied“ kann ein CA-Block ebenso stecken wie ein falsches Secret.

Die Sign-in-Logs verraten, welche Service Principals als Kandidaten infrage kommen

Bevor ihr Richtlinien für Workload Identities ausrollt, solltet ihr euch die Sign-in-Logs der Service Principals ansehen. Im Microsoft Entra Admin Center findet ihr sie unter Sign-in logs → Service principal sign-ins. Dort erkenne ich meist, aus welchen IP-Bereichen sich Anwendungen anmelden, welche Service Principals besonders aktiv sind und ob auffällige Fehlversuche auftauchen. Mit diesen Informationen lassen sich Named Locations sauber definieren, und der Schutz lässt sich auf die privilegierten Identitäten konzentrieren. Bei sehr vielen Einträgen hilft ein Filter auf ApplicationId oder App-Namen.

So gehe ich typischerweise vor:

# PowerShell 7, Module: Microsoft.Graph (mind. Version 2.8)
# Anzeigen der letzten 50 Service Principal Sign-ins
Get-MgAuditLogSignIn -Filter "servicePrincipalId ne null" -Top 50 | Select-Object AppDisplayName, IPAddress

Voraussetzungen: Microsoft Graph PowerShell, Berechtigung AuditLog.Read.All, Entra Workload ID Premium

Der Schutzmechanismus prüft erst den Standort und danach das Risiko

Wie Anmeldung, IP-Prüfung, Risikobewertung und Durchsetzung der Richtlinien zusammenspielen, erkläre ich gern an einem einfachen Flussdiagramm. Es bildet den Ablauf von Conditional Access für Workload Identities bei Service Principals ab:

flowchart TD
    A["Service Principal Anmeldung"] --> B["CA Richtlinien prüfen"]
    B --> C["IP-Standort prüfen"]
    C --> D["Zugelassene IP?"]
    D -- "Nein" --> X["Blockiert"]
    D -- "Ja" --> E["Risiko prüfen"]
    E --> F["Risikofrei?"]
    F -- "Nein" --> X
    F -- "Ja" --> G["Zugriff gewährt"]

Abbildung: Ablauf einer Conditional-Access-Prüfung für Service Principals mit IP- und Risikoprüfung.

Agent Identities ändern einiges, aber noch nicht alles

Einen interessanten Ausblick bieten Agent Identities (Entra Agent ID), die nächste Generation von Maschinenidentitäten, die bereits in den Startlöchern steht. Sie bringen standardisierte Lebenszyklen und eine bessere Governance mit. Künftig sollen sie außerdem feinere Steuerungsmöglichkeiten bieten, auch für Conditional Access. Im Jahr 2025 greifen die hier beschriebenen Mechanismen aber weiterhin vor allem bei klassischen Service Principals aus App-Registrierungen ([mehr zu Agent ID: /blog/microsoft-entra-agent-id-build-2025]). Für Managed Identities und Multi-Tenant-Szenarien fehlen wichtige Kontrollmöglichkeiten. Wer Governance umfassend angehen will, sollte diese Lücke nicht aus den Augen verlieren.

Der Aufwand lohnt sich, wenn man ihn sorgfältig plant

Wer Service Principals nicht länger als Blackbox behandeln will, gewinnt mit Conditional Access für Workload Identities deutlich an Kontrolle. Mit ein paar Häkchen ist es allerdings nicht getan. Fehlen der Überblick und ein klares IP-Konzept oder verzichtet man auf einen Pilotbetrieb im Report-only-Modus, sperrt man sich schnell selbst aus oder lässt Lücken offen. Dass nur Single-Tenant-Service-Principals unterstützt werden und Managed Identities außen vor bleiben, erschwert die Planung zusätzlich. Trotzdem halte ich es für einen wichtigen Schritt, dass sich Service Principals jetzt mit Named Locations und Risk Policies absichern lassen. Wer das zeitnah angeht, schützt die eigenen Dienste und schafft endlich einen nachvollziehbaren Kontrollrahmen für die Maschinenidentitäten im Tenant.