← Microsoft Entra ID & Microsoft 365 Administration

Enterprise Apps und Workloadidentitäten

Im Prüfbericht steht Files.Read.All, und das klingt nach einer Berechtigung. Es sind zwei: Als delegierte Berechtigung liest die Anwendung nur, was die angemeldete Person ohnehin sehen darf — als Anwendungsberechtigung liest sie jede Datei im Tenant. Derselbe Name, ein Klick Unterschied. Dieses Modul behandelt Identitäten für Software: welche Zugriffsart wann gilt, warum ein gespeichertes Geheimnis die schlechteste der drei Nachweisarten ist und wie ein Bereitstellungsablauf ganz ohne auskommt.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-13

Software braucht eine eigene Identität

Im ersten Modul stand der Dienstprinzipal als eine von fünf Objektarten. Hier wird er zum Gegenstand: Jede Anwendung, jeder Nachtlauf und jedes Skript, das auf Tenantdaten zugreift, braucht eine Identität, unter der es handelt. Die Frage ist nicht ob, sondern welche — und mit welchem Berechtigungsnachweis sie sich ausweist.

Der bequeme Weg ist immer derselbe: Man nimmt das Konto einer Person, meist eines mit vielen Rechten. Das funktioniert bis zum ersten Abteilungswechsel, bis zur ersten Kennwortänderung oder bis zu dem Tag, an dem jemand fragt, wer eigentlich diese 40.000 Postfachzugriffe verursacht hat und die Antwort ein Mensch ist, der zu dieser Zeit im Urlaub war.

Workload-Identität — Eine Identität für Software statt für Menschen — eine Anwendung, ein Dienst, ein Skript oder ein Container. Sie hat einen eigenen Lebenszyklus, eigene Berechtigungen und einen eigenen Berechtigungsnachweis.

LernzielDu kannst delegierten von anwendungseigenem Zugriff unterscheiden, die drei Arten von Berechtigungsnachweisen gegeneinander abwägen und einen Ablauf entwerfen, der ohne gespeichertes Geheimnis auskommt.

Zwei Zugriffsarten, und der Unterschied ist grundsätzlich

Die Dokumentation trennt zwei Szenarien, und diese Trennung entscheidet über die Reichweite jeder Berechtigung.

Delegierter Zugriff: Eine Person ist angemeldet, die Anwendung handelt in ihrem Namen. Beide müssen getrennt berechtigt sein — die Anwendung über die erteilte Berechtigung, die Person über ihre eigenen Rechte.
Anwendungseigener Zugriff: Niemand ist angemeldet. Die Anwendung handelt als sie selbst — der Fall für Automatisierung, Hintergrunddienste und Sicherungsläufe.

Die beiden Arten heißen technisch verschieden: Beim delegierten Zugriff spricht man von Bereichen, beim anwendungseigenen von Anwendungsrollen. Werden Letztere durch Zustimmung erteilt, nennt man sie Anwendungsberechtigungen.

Der Unterschied ist auch am Ergebnis der Zustimmung ablesbar: Eine erteilte delegierte Berechtigung erscheint als OAuth2PermissionGrant, eine erteilte Anwendungsberechtigung als Zuweisung einer Anwendungsrolle am Dienstprinzipal. Wer einen Tenant prüft, sollte beide Listen ansehen — sie stehen an verschiedenen Stellen und die zweite ist die gefährlichere.

Anwendungseigener Zugriff ist laut Dokumentation dann angebracht, wenn es unerwünscht ist, dass eine bestimmte Person angemeldet ist, oder wenn sich die benötigten Daten nicht auf eine einzelne Person eingrenzen lassen. Das ist eine hohe Hürde — und sie wird routinemäßig übersprungen, weil anwendungseigener Zugriff einfacher einzurichten ist.

Derselbe Name, zwei völlig verschiedene Reichweiten

Hier steht der Befund, den man aus diesem Modul mitnehmen sollte. Berechtigungen tragen in beiden Arten denselben Namen, bedeuten aber Verschiedenes. Die Dokumentation führt das an einem Beispiel aus, das man sich merken sollte:

Files.Read.All als delegierte Berechtigung: Die Anwendung kann nur die Dateien lesen, die die angemeldete Person persönlich lesen kann. Sie kommt an nichts heran, was der Person verschlossen ist.
Files.Read.All als Anwendungsberechtigung: Die Anwendung kann jede Datei im Tenant lesen. Es gibt keine Person, deren Rechte die Reichweite begrenzen würden.

Derselbe Eintrag in einer Liste, ein Klick Unterschied bei der Auswahl — und der Unterschied zwischen „liest, was diese Person ohnehin sieht“ und „liest alles“. Wer eine Berechtigungsliste prüft und nur die Namen liest, hat die wichtigere Hälfte der Information nicht angesehen.

Die PrüffrageBei jeder erteilten Berechtigung lautet die erste Frage nicht, wie sie heißt, sondern welcher Art sie ist. Erst danach ist die zweite Frage sinnvoll, ob der Umfang zum Zweck passt — bei einer Anwendungsberechtigung ist der Umfang immer der ganze Tenant, sofern die Schnittstelle keine Einschränkung anbietet.

Delegierte Berechtigung — Erlaubt der Anwendung, im Namen einer angemeldeten Person zu handeln. Die tatsächliche Reichweite ist die Schnittmenge aus der Berechtigung und dem, was die Person selbst darf.

Wer zustimmen darf

Aus der Reichweite folgt, wer eine Berechtigung überhaupt erteilen kann. Bei delegierten Berechtigungen können Personen für ihre eigenen Daten zustimmen; Verwaltende können für alle zustimmen. Bei Anwendungsberechtigungen gilt laut Dokumentation, dass im Allgemeinen nur eine verwaltende Person oder der Eigentümer des Dienstprinzipals der Schnittstelle zustimmen kann.

Das ist keine Formalie, sondern der Grund, warum die Zustimmung zu Anwendungsberechtigungen ein eigener Kontrollpunkt ist: Sie erzeugt einen Zugriff, den keine Benutzerberechtigung mehr begrenzt. Wer sie erteilt, vergibt Rechte am gesamten Bestand — dauerhaft und ohne dass eine Anmeldung dazu nötig wäre.

AbgrenzungDie Steuerung der Zustimmung selbst — Zustimmungsrichtlinien für Endnutzer, der Genehmigungsablauf und das Entziehen erteilter Zustimmung — ist im Track m365-collaboration im Modul apps-consent-governance ausgebaut. Hier geht es um die Identität der Anwendung und ihren Berechtigungsnachweis.

Drei Wege, wie sich eine Anwendung ausweist

Eine Anwendung muss beweisen, dass sie sie selbst ist. Dafür gibt es drei Möglichkeiten, und sie unterscheiden sich vor allem darin, wer das Geheimnis verwaltet.

Geheimnis: Eine Zeichenfolge, die bei der Registrierung entsteht. Muss sicher gespeichert und regelmäßig gewechselt werden. Läuft ab.
Zertifikat: Ein Schlüsselpaar statt einer Zeichenfolge. Sicherer in der Handhabung, aber ebenfalls zu speichern, zu erneuern und läuft ab.
Föderierter Berechtigungsnachweis: Kein Geheimnis auf der eigenen Seite. Die Anwendung weist sich mit einem Token aus, das ein externer Anbieter ausstellt.

Die Dokumentation ist über die ersten beiden ungewöhnlich deutlich: Anmeldeinformationen dieser Art stellen ein Sicherheitsrisiko dar, müssen sicher gespeichert und regelmäßig gewechselt werden — und man trägt das Risiko eines Dienstausfalls, wenn sie ablaufen.

Der Ausfall, den niemand einplantEin abgelaufenes Geheimnis ist der klassische Vorfall am Montagmorgen: Nichts wurde geändert, niemand hat etwas getan, und trotzdem läuft der Nachtlauf nicht mehr. Die Ursache liegt Monate zurück — im Moment der Erstellung, als jemand eine Laufzeit gewählt und keine Erinnerung gesetzt hat.

Am Objekt sind die drei Wege an eigenen Feldern zu erkennen, und das ist die Grundlage jeder Bestandsaufnahme: passwordCredentials führt die Geheimnisse, keyCredentials die Zertifikate und federatedIdentityCredentials die Vertrauensbeziehungen. Eine Anwendungsregistrierung ohne Einträge in den ersten beiden Listen ist eine, die nichts verlieren kann.

Verwaltete Identitäten: zwei Bauformen

Läuft die Arbeitslast in Azure, gibt es einen Weg, bei dem die Plattform den Berechtigungsnachweis übernimmt. Verwaltete Identitäten sind Dienstprinzipale besonderer Art — im ersten Modul standen sie schon als die Variante ohne Anwendungsobjekt, die sich nicht direkt bearbeiten lässt.

Systemzugewiesen: Entsteht an einer Azure-Ressource. Geteilter Lebenszyklus: Wird die Ressource gelöscht, löscht Azure den Dienstprinzipal mit. Nicht teilbar — nur diese eine Ressource kann die Identität nutzen. Der Name entspricht immer dem Namen der Ressource.
Benutzerzugewiesen: Eine eigenständige Azure-Ressource. Unabhängiger Lebenszyklus, muss ausdrücklich gelöscht werden. Kann von mehreren Ressourcen gemeinsam genutzt werden.

Die Dokumentation nennt die benutzerzugewiesene Variante ausdrücklich als empfohlenen Typ, weil sie unabhängig von der Rechenressource bereitgestellt und mehreren Ressourcen zugewiesen werden kann. Das klingt nach einer Kleinigkeit und entscheidet in der Praxis darüber, ob eine Neuinstallation der Ressource die Berechtigungsvergabe zerstört.

Die Kehrseite der EmpfehlungDer unabhängige Lebenszyklus heißt auch: Niemand räumt auf. Eine systemzugewiesene Identität verschwindet mit ihrer Ressource, eine benutzerzugewiesene bleibt — mit allen Rechten, die sie je bekommen hat. Wer sie einsetzt, übernimmt die Pflicht, sie beim Rückbau wieder zu entfernen.

Föderierte Berechtigungsnachweise: der Weg ohne Geheimnis

Die dritte Möglichkeit löst das Problem, statt es zu verwalten. Statt ein Geheimnis abzulegen, richtet man eine Vertrauensbeziehung zu einem externen Identitätsanbieter ein — GitHub, ein Kubernetes-Cluster, Google Cloud, Amazon Web Services oder ein Anbieter nach den offenen Standards SPIFFE und SPIRE.

Die externe Arbeitslast holt sich ein Token bei ihrem eigenen Anbieter→Sie legt dieses Token bei der Microsoft-Identitätsplattform vor→Die Plattform prüft die Vertrauensbeziehung und das Token gegen die OpenID-Connect-Adresse des Anbieters→Bei Erfolg stellt sie ein Zugriffstoken aus→Die Arbeitslast greift damit auf die geschützten Ressourcen zu

Kein Geheimnis auf der eigenen Seite

Der Gewinn ist laut Dokumentation doppelt: Der Aufwand für die manuelle Verwaltung von Anmeldeinformationen entfällt, und damit auch das Risiko, dass ein Geheimnis abfließt oder ein Zertifikat abläuft. Einrichten lässt sich das sowohl an einer benutzerzugewiesenen verwalteten Identität als auch an einer Anwendungsregistrierung.

Was das für ein Bereitstellungswerkzeug bedeutetEin Ablauf in GitHub Actions, der bisher ein Geheimnis als Variable hinterlegt hatte, braucht danach keines mehr. Das entfernt genau die Sorte Geheimnis, die am häufigsten versehentlich in einem Protokoll oder einem Quelltext landet.

Das Verfahren trägt weiter, als der Name vermuten lässt. Die Dokumentation nennt ausdrücklich Arbeitslasten auf jedem Kubernetes-Cluster — auch bei anderen Anbietern und im eigenen Rechenzentrum —, Abläufe in GitHub Actions, Arbeitslasten in Google Cloud und Amazon Web Services sowie Dienstverbindungen in Azure Pipelines. Es ist also kein Azure-Sonderweg, sondern der allgemeine Weg für Software, die außerhalb von Azure läuft und trotzdem an geschützte Ressourcen muss.

Die drei Werte, die genau passen müssen

Der föderierte Berechtigungsnachweis sagt, welches Token von welchem Anbieter vertraut werden soll. Er tut das über drei Angaben, und die Dokumentation ist an dieser Stelle ungewöhnlich präzise.

issuer — wer das Token ausgestellt hat.
subject — für wen oder was es ausgestellt wurde, etwa ein bestimmter Zweig eines bestimmten Projektarchivs.
audience — für welchen Empfänger es bestimmt ist.

Alle drei müssen unter Beachtung der Groß- und Kleinschreibung genau mit den Werten im vorgelegten Token übereinstimmen. Ein Großbuchstabe an der falschen Stelle führt nicht zu einer Warnung, sondern dazu, dass die Anmeldung abgelehnt wird — und die Fehlermeldung nennt selten, welcher der drei Werte nicht passte.

Eine Grenze, die überraschtVon Microsoft Entra ID ausgestellte Token lassen sich in diesem Ablauf nicht verwenden — der Ablauf unterstützt sie ausdrücklich nicht. Wer versucht, mit einem Entra-Token ein Entra-Token zu holen, baut einen Kreis, den die Plattform nicht zulässt.

Das Geheimnis, das abläuft

Wo Geheimnisse oder Zertifikate unvermeidbar bleiben — etwa bei einer Anwendung außerhalb der Cloud, für die es keinen föderierten Weg gibt — verschiebt sich die Aufgabe von der Vermeidung zur Beherrschung.

Laufzeit bewusst wählen, nicht die Voreinstellung übernehmen. Eine lange Laufzeit verschiebt den Ausfall nur weiter nach hinten.
Den Ablauftermin an einer Stelle führen, an der jemand hinsieht — nicht im Kopf der Person, die den Nachweis erstellt hat.
Zwei Nachweise überlappend führen: den neuen anlegen, umstellen, prüfen, erst dann den alten entfernen.
Zertifikat dem Geheimnis vorziehen, wo beides möglich ist.

Die überlappende Umstellung ist dasselbe Muster wie beim Lizenzumzug aus dem Modul zu Gruppen: Überlappung ist billiger als Lücke. Der Unterschied ist, dass hier kein Mensch merkt, wenn es schiefgeht — ein Nachtlauf beschwert sich nicht, er läuft einfach nicht mehr.

Möglich ist die Überlappung, weil eine Anwendungsregistrierung mehrere Einträge in passwordCredentials und keyCredentials gleichzeitig führen kann. Genau das ist auch die Falle bei der Bestandsaufnahme: Eine Registrierung, deren neuestes Geheimnis noch lange gültig ist, kann daneben ein altes tragen, das jemand vor Jahren angelegt und nie entfernt hat. Für einen Angreifer zählt nicht das neueste, sondern jedes.

Was eine Prüfung ansehen mussNicht „hat diese Anwendung ein gültiges Geheimnis?“, sondern „wie viele hat sie, und wer kennt jedes davon?“. Ein vergessener zweiter Nachweis ist ein Zugang ohne Eigentümer — er läuft irgendwann ab, aber bis dahin funktioniert er.

Berechtigungen zuschneiden, wenn es keine Person mehr gibt

Beim delegierten Zugriff begrenzt die angemeldete Person die Reichweite. Beim anwendungseigenen Zugriff fällt diese Begrenzung weg — und damit die Kontrolle, auf die man sich sonst unbewusst verlässt.

Übrig bleibt nur der Zuschnitt der Berechtigung selbst. Praktisch heißt das: die engste Berechtigung wählen, die den Zweck erfüllt, und prüfen, ob die Schnittstelle eine Eingrenzung anbietet — manche tun das, viele nicht. Wo sie es nicht tut, ist die ehrliche Feststellung, dass die Anwendung Zugriff auf den gesamten Bestand hat, und die Entscheidung muss auf dieser Grundlage fallen.

Ein Blick auf die Namen hilft dabei mehr als jede Beschreibung. User.Read ist eng, User.Read.All liest alle Benutzer, User.ReadWrite.All ändert sie, und Directory.ReadWrite.All deckt das halbe Verzeichnis ab. Die Endung .All ist dabei das Signal, bei dem man innehalten sollte — zusammen mit einer Anwendungsberechtigung bedeutet sie den gesamten Tenant ohne jede weitere Schranke.

Der Zusammenhang mit dem ersten ModulEs ist dieselbe Frage wie beim Rollenzuschnitt: erst die Aufgabe benennen, dann die kleinste Berechtigung suchen. Der Unterschied ist, dass hier niemand sich beschwert, wenn zu viel vergeben wurde — eine Anwendung nutzt einfach nur einen Teil dessen, was sie darf, und der Rest fällt erst auf, wenn ihn jemand missbraucht.

Durchgerechnet: ein Nachtlauf ohne gespeichertes Geheimnis

Von einem Benutzerkonto zu einer Workload-Identität

Szenario

Ein nächtlicher Bereitstellungslauf legt Benutzerkonten an. Er läuft in GitHub Actions unter den Anmeldedaten einer Kollegin, deren Konto die Rolle Global Administrator trägt. Nach ihrem Abteilungswechsel bricht der Lauf ab.

Anforderungen

Der Lauf soll unabhängig von einzelnen Personen funktionieren.
Es soll kein Geheimnis im Bereitstellungswerkzeug liegen.
Die Rechte sollen so eng sein, wie die Aufgabe es zulässt.

Schritte

Zugriffsart bestimmen: Der Lauf hat keine angemeldete Person, also anwendungseigener Zugriff — und damit die Aufgabe, den Umfang selbst zu begrenzen.
Anwendungsregistrierung anlegen und die engste Berechtigung wählen, die das Anlegen von Konten erlaubt. Nicht Global Administrator, sondern die passende Rolle aus dem ersten Modul.
Statt eines Geheimnisses einen föderierten Berechtigungsnachweis einrichten, der dem Token aus dem Projektarchiv vertraut.
issuer, subject und audience genau setzen — die Groß- und Kleinschreibung muss stimmen, und subject bezeichnet den konkreten Zweig oder die konkrete Umgebung, nicht das ganze Archiv.
Testlauf, dann das alte Benutzerkonto aus dem Ablauf entfernen und prüfen, dass nirgends mehr ein Geheimnis hinterlegt ist.

Merksatz: Am Ende gibt es kein Geheimnis, das ablaufen oder abfließen könnte — und keine Person, deren Wechsel den Betrieb anhält.

Der Preis ist Einrichtungsaufwand und eine neue Fehlerquelle: Stimmt einer der drei Werte nicht, schlägt die Anmeldung fehl, und die Meldung ist wenig hilfreich. Wer das zum ersten Mal einrichtet, sollte Zeit für genau diesen Abgleich einplanen — er ist die einzige wirklich fehleranfällige Stelle des Verfahrens.

Die Reihenfolge, die alles zusammenhält

Zugriffsart bestimmen: im Namen einer Person oder als Anwendung selbst→Bei anwendungseigenem Zugriff die Berechtigung selbst zuschneiden — es gibt keine Person, die begrenzt→Berechtigungsnachweis wählen: föderiert vor Zertifikat vor Geheimnis→In Azure verwaltete Identitäten nutzen, benutzerzugewiesen als Regelfall→Wo ein Geheimnis unvermeidbar ist: Ablauftermin führen und überlappend wechseln

Kein Geheimnis ist besser als ein gut verwaltetes

Der rote Faden dieses Moduls ist derselbe wie im ersten: Rechte gehören an eine Identität mit eigenem Lebenszyklus, und ihr Umfang folgt der Aufgabe. Der Unterschied ist, dass Software sich nicht beschwert — weder über zu viele Rechte noch über einen Nachweis, der bald abläuft.

Gleich im CheckDie Übungen prüfen die Unterscheidung der Zugriffsarten, die Reichweite gleichnamiger Berechtigungen, die Wahl zwischen den Bauformen verwalteter Identitäten und die genaue Einrichtung eines föderierten Berechtigungsnachweises.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität5 Primärquellen · zuletzt geprüft: 2026-09-13