Microsoft 365 · Automationsidentitäten
Eine Automation benötigt eine eigene, nachvollziehbare Identität und genau die Rechte, die ihr technischer Auftrag verlangt. Ein persönliches Benutzerkonto mit gespeichertem Kennwort ist dafür selten geeignet. Je nach Plattform kommen eine App-Identität, eine von Azure verwaltete Identität oder – bei älteren Systemen – ein eng begrenztes technisches Benutzerkonto infrage. Die Wahl entscheidet über Ausfallrisiko, Berechtigungsumfang, Nachweisbarkeit und laufenden Pflegeaufwand.
Die Kurzantwort: Für unbeaufsichtigte Abläufe wird eine Arbeitslastidentität geplant
Arbeitet eine Anwendung ohne angemeldete Person, passt eine App-Identität mit Anwendungsberechtigungen. Läuft sie auf einer unterstützten Azure-Ressource, vermeidet eine verwaltete Identität eigene Zugangsdaten. Ein technisches Benutzerkonto bleibt eine begründungsbedürftige Ausweichlösung für Systeme, die keine moderne Anwendungsanmeldung beherrschen.
| Ausgangslage | Passender Ansatz | Wesentliche Grenze |
|---|---|---|
| Eine Person startet den Vorgang und arbeitet mit eigenen Rechten | Benutzerkonto mit delegiertem Zugriff | Die Anwendung kann nur handeln, wenn Benutzer und App berechtigt sind |
| Hintergrunddienst greift ohne Benutzer auf Microsoft 365 zu | App-Registrierung und Service Principal | Anwendungsrechte benötigen Zustimmung und sorgfältige Begrenzung |
| Automation läuft auf unterstützter Azure-Ressource | Verwaltete Identität | Nur die zugeordnete Azure-Ressource darf diese Identität verwenden |
| Workload läuft bei vertrauenswürdigem externem Identitätsanbieter | Workload Identity Federation | Issuer, Subject und Audience müssen exakt an die Workload gebunden sein |
| Altsystem kann nur Benutzername und Kennwort | Eng begrenztes technisches Konto als Übergang | Zusätzliches Geheimnis, Lizenzbedarf und höheres Betriebsrisiko |
Die Identitätsentscheidung braucht sechs Angaben
- Welcher konkrete Prozess soll auf welche Daten oder Funktionen zugreifen?
- Arbeitet eine angemeldete Person mit oder läuft der Vorgang unbeaufsichtigt?
- Auf welcher Plattform und in welcher Organisation wird die Automation ausgeführt?
- Welche kleinste Menge von Objekten und Aktionen benötigt sie?
- Wie authentifiziert sie sich ohne dauerhaft gespeichertes Benutzerkennwort?
- Wer verantwortet Berechtigungen, Protokolle, Änderungen und Stilllegung?
1. Zuerst wird der technische Auftrag vollständig beschrieben
„Das Skript braucht Microsoft-365-Zugriff“ ist keine Berechtigungsanforderung. Benötigt werden Quelle, Ziel, Aktion, Häufigkeit und zulässige Grenzen.
Lesen, verändern, senden und administrieren sind getrennte Aufgaben
Ein Archivierungsprozess liest möglicherweise Nachrichten aus einem benannten Postfach. Ein Websiteformular versendet Nachrichten aus einer festen Absenderadresse. Eine Personalautomation legt Benutzer an. Diese Vorgänge benötigen verschiedene Rechte und besitzen sehr unterschiedliche Auswirkungen. Eine pauschale Administratorrolle wäre für keinen dieser Aufträge eine angemessene Abkürzung.
Die Beschreibung nennt daher die exakte Aktion: beispielsweise Nachrichten in Postfach A lesen, aber weder löschen noch aus anderen Postfächern abrufen; Dateien in SharePoint-Website B anlegen, aber keine Websites erstellen; Benutzerstammdaten aus einem geprüften Quellsystem aktualisieren, aber keine privilegierten Rollen vergeben.
Interaktive und unbeaufsichtigte Ausführung werden nicht vermischt
Bei delegiertem Zugriff meldet sich eine Person an. Die Anwendung handelt in ihrem Namen; sowohl die gewährten App-Berechtigungen als auch die Rechte des Benutzers begrenzen den Zugriff. Das passt zu einem Werkzeug, das ein Mitarbeiter bewusst bedient und dessen Ergebnis unmittelbar kontrolliert.
Ein Nachtlauf, Sicherungsdienst oder Hintergrundprozess besitzt keine anwesende Person. Er benötigt App-only-Zugriff mit einer eigenen Arbeitslastidentität. Ein zufällig ausgewählter Mitarbeiter darf nicht dauerhaft als unsichtbarer technischer Träger dienen, denn Austritt, Rollenwechsel, Mehrfaktoranmeldung oder Kennwortänderung würden den Betrieb mit der Personalverwaltung verkoppeln.
Fehlerfolgen bestimmen die notwendige Begrenzung
Ein lesender Bericht kann bei einer Störung falsche Kennzahlen liefern. Eine schreibende Automation kann Dateien überschreiben, Nachrichten massenhaft versenden oder Benutzer verändern. Deshalb werden maximale Datensätze pro Lauf, zulässige Empfänger, erlaubte Zielbereiche und Abbruchbedingungen bereits fachlich festgelegt.
Wo eine API keine ausreichend feine Berechtigung anbietet, kompensiert die Architektur das nicht durch Hoffnung. Eine eigene SharePoint-Website, ein abgegrenztes Postfach, eine vorgelagerte Funktions-API oder ein manueller Freigabeschritt kann den möglichen Schaden wirksamer begrenzen als eine weitreichende organisationsweite Freigabe.
2. Benutzerkonto, App-Identität und verwaltete Identität lösen verschiedene Probleme
„Dienstkonto“ ist kein eindeutiger Microsoft-Objekttyp. Gemeint sein kann ein normaler Benutzer, ein Service Principal oder eine verwaltete Identität. Für Betrieb und Prüfung muss die tatsächliche Form benannt werden.
Ein persönliches Benutzerkonto gehört zu einer natürlichen Person
Persönliche Konten eignen sich für interaktive Arbeit, bei der Anmeldung, Mehrfaktorauthentifizierung, Rollen und Protokolle einer Person zugeordnet werden. Ihre Verwendung in einem unbeaufsichtigten Skript verwischt diese Zuordnung. Die Protokolle zeigen dann den Mitarbeiter, obwohl tatsächlich ein Server gehandelt hat.
Auch ein zusätzlich angelegter Benutzer mit einem Namen wie „Service Automation“ bleibt technisch ein Benutzerkonto. Es benötigt abhängig von den verwendeten Diensten eine Lizenz, besitzt Kennwort und Authentifizierungsmethoden und muss gegen interaktive Anmeldung geschützt werden. Für ältere Produkte kann dies vorübergehend notwendig sein; es wird dann ausdrücklich als Ausnahme mit Ablösungsplan geführt.
App-Registrierung und Service Principal bilden die Identität einer Anwendung
Die App-Registrierung beschreibt die Anwendung: Kennung, mögliche Anmeldewege und angeforderte Berechtigungen. Der Service Principal ist ihre konkrete Repräsentation im Microsoft-Entra-Mandanten. An ihm werden die in dieser Organisation geltenden Zugriffe und Zustimmungen sichtbar. Bei einer mandantenfähigen Herstelleranwendung entsteht in jedem nutzenden Mandanten ein eigener Service Principal.
Eine intern entwickelte Hintergrundanwendung wird vorzugsweise als Single-Tenant-Anwendung registriert, wenn kein Zugriff fremder Organisationen benötigt wird. Name, Zweck, fachlicher und technischer Eigentümer werden so gewählt, dass ein Administrator später erkennen kann, warum die Identität existiert und welche Abschaltung sie verursacht.
Eine verwaltete Identität vermeidet eigene Zugangsdaten auf Azure-Ressourcen
Azure kann einer unterstützten virtuellen Maschine, Function, Web App oder anderen Rechenressource eine verwaltete Identität zuweisen. Die Anwendung bezieht Microsoft-Entra-Token über die Plattform, ohne ein Client Secret oder privates Zertifikat selbst zu speichern und zu erneuern. Berechtigungen bleiben trotzdem erforderlich; der entfallende Schlüssel macht eine zu weit berechtigte Identität nicht automatisch sicher.
Eine systemseitig zugewiesene Identität teilt ihren Lebenszyklus mit genau einer Azure-Ressource. Wird diese Ressource gelöscht, verschwindet auch der Service Principal. Eine benutzerseitig zugewiesene verwaltete Identität existiert eigenständig und kann mehreren unterstützten Ressourcen zugeordnet werden. Die Wahl richtet sich danach, ob Berechtigungen bewusst an eine Ressource oder an einen unabhängig verwalteten Arbeitsauftrag gebunden sein sollen.
Workload Identity Federation bindet externe Plattformen ohne gespeichertes Microsoft-Geheimnis an
Für unterstützte Workloads außerhalb von Azure kann Microsoft Entra einem vertrauenswürdigen externen Identitätsanbieter vertrauen. Die externe Plattform – etwa ein klar begrenzter GitHub-Actions-Workflow oder eine Kubernetes-Workload – liefert ein eigenes kurzlebiges Token, das gegen ein Microsoft-Zugriffstoken ausgetauscht wird. Ein dauerhaft hinterlegtes Client Secret entfällt.
Die Vertrauensbeziehung muss Issuer, Subject und Audience exakt festlegen. Ein zu allgemeiner Subject-Filter könnte mehreren Repositories, Branches oder Workloads denselben Zugriff eröffnen. Federation ersetzt daher die Geheimnisverwaltung, nicht die sorgfältige Definition von Quelle und Berechtigung.
3. Der Zugriff wird auf Aktion und Ressourcenbestand begrenzt
Die richtige Identitätsart ist erst der Anfang. Entscheidend bleibt, welche API-Rechte, Rollen und konkreten Objekte diese Identität tatsächlich erreichen kann.
Delegierte und Anwendungsberechtigungen werden bewusst gewählt
Delegierte Berechtigungen wirken im Kontext eines angemeldeten Benutzers. Sowohl die Anwendung als auch der Benutzer müssen die Aktion ausführen dürfen. Anwendungsberechtigungen wirken ohne Benutzer und eignen sich für Hintergrunddienste; sie können deshalb einen deutlich größeren Organisationsumfang erreichen und benötigen häufig Administratorzustimmung.
Eine Automation erhält nicht vorsorglich die größte verfügbare Microsoft-Graph-Berechtigung. Die technische Umsetzung beginnt mit der kleinsten dokumentierten Berechtigung und prüft, ob der Dienst darüber hinaus eine Ressourcenbegrenzung ermöglicht. Unbenutzte Zustimmungen werden entfernt, statt als vermeintliche Reserve bestehen zu bleiben.
Postfachzugriff wird auf die vorgesehenen Postfächer beschränkt
Eine Anwendung, die aus einem Funktionspostfach sendet, benötigt keinen Versand aus jedem Postfach der Organisation. Exchange Online Application RBAC kann einem Service Principal eine Rolle zusammen mit einem definierten Ressourcenumfang zuweisen. Die Freigabe wird mit einem erlaubten und einem ausdrücklich nicht erlaubten Postfach getestet.
Dabei werden parallel erteilte Microsoft-Entra-Anwendungsberechtigungen berücksichtigt. Microsoft beschreibt diese Berechtigungen als additiv: Eine organisationsweite Mail.Send-Zustimmung in Entra wird durch eine engere Exchange-Zuweisung nicht automatisch aufgehoben. Der breite Grant muss entfernt werden, wenn ausschließlich der begrenzte Umfang gelten soll.
Datei- und Verwaltungszugriffe erhalten eigene Grenzen
Bei SharePoint wird geprüft, ob ein ausgewählter Websitescope anstelle organisationsweiten Dateizugriffs verwendet werden kann. Für Azure-Ressourcen werden Rollen auf der kleinsten geeigneten Ebene vergeben: konkrete Ressource oder Ressourcengruppe statt gesamtes Abonnement. Verzeichnisrollen werden nur verwendet, wenn eine gewöhnliche API-Berechtigung den Auftrag nicht erfüllen kann.
Eine Automation, die Benutzer anlegt, darf nicht automatisch privilegierte Administratoren erzeugen. Eine Anwendung, die Rechnungsdateien überträgt, benötigt keine Berechtigung zum Löschen sämtlicher Websites. Fachliche Eingabeprüfung und technische Autorisierung ergänzen sich: Auch korrekt authentifizierte Anfragen werden auf zulässige Mandanten, Objekte, Dateitypen und Mengen geprüft.
Prüfung des kleinsten wirksamen Zugriffs
- Jede Berechtigung lässt sich einer konkreten Aktion des Prozesses zuordnen.
- Erlaubte Ressourcen sind enger gefasst als die gesamte Organisation, sofern der Dienst dies unterstützt.
- Parallele Grants in Entra, Exchange, SharePoint und Azure wurden gemeinsam ausgewertet.
- Die Automation kann keine privilegiertere Rolle oder neue Zustimmung selbst erzeugen.
- Ein nicht vorgesehener Benutzer, ein fremdes Postfach und eine fremde Website werden nachweislich abgewiesen.
- Für unvermeidbar breite Rechte bestehen zusätzliche technische und organisatorische Begrenzungen.
4. Die Anmeldung kommt möglichst ohne dauerhaftes Geheimnis aus
Ein Zugriffsschlüssel im Skript ist zugleich ein Sicherheits- und Verfügbarkeitsproblem. Er kann kopiert werden, bleibt in Backups erhalten und lässt den Prozess beim unbemerkten Ablauf ausfallen.
Verwaltete Identität oder Federation haben Vorrang, wenn die Plattform sie unterstützt
Bei einer verwalteten Identität authentifiziert Azure die ausführende Ressource. Bei Federation bestätigt eine festgelegte externe Plattform die konkrete Workload. In beiden Fällen muss die Anwendung kein statisches Microsoft-Geheimnis verwalten. Token sind kurzlebig und werden bei Bedarf bezogen.
Die Anwendung prüft dabei keine selbst gebauten Tokenmechanismen, sondern verwendet unterstützte Bibliotheken und Plattformendpunkte. Entwicklungs-, Test- und Produktivumgebung erhalten getrennte Identitäten. So kann ein Testlauf nicht versehentlich auf produktive Postfächer oder Dateien zugreifen.
Zertifikate sind für App-Identitäten belastbarer als gemeinsam verwendete Kennwörter
Ist eine geheimnisfreie Variante nicht verfügbar, kann eine App sich mit einem Zertifikat authentifizieren. Der private Schlüssel bleibt in einem geeigneten Schlüsselspeicher und wird nur der ausführenden Umgebung zugänglich gemacht. In der App-Registrierung liegt der öffentliche Anteil zur Prüfung der signierten Anforderung.
Auch Zertifikate laufen ab und benötigen einen Wechselprozess. Vor dem Ablauf wird ein zweites Zertifikat hinterlegt, der Dienst darauf umgestellt und der alte Schlüssel erst nach erfolgreichem Test entfernt. Ein Ablaufdatum ohne verantwortlichen Termin ist keine Rotation.
Client Secrets bleiben kurzlebige, geschützte Ausnahmen
Ein Client Secret wird nicht im Quellcode, in einer unverschlüsselten Konfigurationsdatei, in einem Ticket oder im Chat gespeichert. Es liegt in einem dafür vorgesehenen Secretspeicher und wird zur Laufzeit abgerufen. Protokolle dürfen weder den Wert noch vollständige Authentifizierungsanforderungen ausgeben.
Die Gültigkeit bleibt so kurz, wie der zuverlässige Wechselprozess erlaubt. Ein zweites gültiges Secret ermöglicht die unterbrechungsarme Rotation. Danach wird der alte Wert aktiv widerrufen. Wenn das Zielsystem nur ein dauerhaftes Benutzerkennwort unterstützt, werden Netzwerkquelle, Anmeldeort, Rechte und Nutzung zusätzlich begrenzt und eine Ablösung geplant.
5. Jede Arbeitslastidentität erhält Eigentümer, Überwachung und ein Ende
Eine sichere Erstkonfiguration veraltet, wenn niemand Zustimmungen, Zertifikate, Herstellerwechsel und ausbleibende Nutzung kontrolliert.
Fachlicher und technischer Eigentümer beantworten verschiedene Fragen
Der fachliche Eigentümer erklärt, warum der Prozess benötigt wird, welche Daten er verarbeiten darf und wann er stillgelegt werden kann. Der technische Eigentümer verantwortet App-Registrierung, Ausführungsumgebung, Berechtigungen, Zugangsdaten und Fehlerbehandlung. Beide Rollen werden namentlich oder über eine belastbare Organisationsfunktion dokumentiert.
Mindestens eine Vertretung verhindert, dass ein Urlaub oder Austritt die Wartung blockiert. Eigentümer in Microsoft Entra werden nicht mit organisationsweiten Administratorrechten verwechselt: Wer eine App fachlich verantwortet, benötigt nicht automatisch die Möglichkeit, beliebige Mandanteneinstellungen zu ändern.
Protokolle verbinden Anmeldung, technische Aktion und Geschäftsvorgang
Microsoft-Entra-Anmeldeprotokolle zeigen Tokenanforderungen einer Arbeitslastidentität. Die Anwendung protokolliert zusätzlich Vorgangskennung, Ziel, Anzahl verarbeiteter Objekte, Ergebnis und Korrelations-ID. So lässt sich unterscheiden, ob Anmeldung, Autorisierung, API-Aufruf oder fachliche Verarbeitung fehlgeschlagen ist.
Geheimnisse, vollständige Nachrichtentexte und unnötige personenbezogene Inhalte gehören nicht in Diagnoseprotokolle. Warnungen entstehen bei wiederholten Anmeldefehlern, ungewohntem Volumen, Zugriff außerhalb des vorgesehenen Zeitfensters oder Änderungen an Berechtigungen und Zugangsdaten.
Nicht mehr benötigte Identitäten werden kontrolliert stillgelegt
Vor einer Löschung wird die Identität zunächst deaktiviert oder ihr Zugriff entzogen. Ein Beobachtungszeitraum zeigt, ob noch ein unbekannter Prozess davon abhängt. Anschließend werden Berechtigungen, Federation, Geheimnisse, Zertifikate, Rollen und die App- beziehungsweise Service-Principal-Objekte nach dokumentierter Reihenfolge entfernt.
Bei systemseitig zugewiesenen verwalteten Identitäten endet der Lebenszyklus mit der Azure-Ressource. Bei benutzerseitig zugewiesenen Identitäten und App-Registrierungen erfolgt die Bereinigung separat. Ein gelöschter Server entfernt daher nicht automatisch jede ehemals für ihn angelegte Berechtigung.
6. Die Abnahme beweist erlaubte Zugriffe und wirksame Grenzen
Ein erfolgreicher API-Aufruf beweist nur, dass irgendein Zugriff funktioniert. Eine belastbare Abnahme prüft zusätzlich, was die Identität ausdrücklich nicht tun darf.
Positive Tests verwenden einen vollständigen realen Vorgang
Die produktionsnahe Probe meldet sich mit der vorgesehenen Identität an, bezieht ein Token für die richtige Ressource und führt genau die benötigte Aktion aus. Ergebnis, Protokoll und fachlicher Zielzustand werden gemeinsam geprüft. Ein Mailversand endet beispielsweise erst mit korrekter Absenderanzeige und nachvollziehbarer Zustellung, nicht mit der erfolgreichen Tokenanforderung.
Tests finden mit gekennzeichneten Datensätzen und kontrollierten Empfängern statt. Entwicklungszugänge werden nicht in die Produktion kopiert. Die dokumentierten Objekt- und Client-IDs werden anhand ihrer Bezeichnung und ihres Mandanten geprüft, damit nicht versehentlich eine ähnlich benannte Identität verwendet wird.
Negative Tests bestätigen den kleinsten Umfang
Die Anwendung versucht kontrolliert den Zugriff auf ein fremdes Postfach, eine nicht freigegebene SharePoint-Website oder eine unzulässige Aktion. Jeder Versuch muss mit einem erwarteten Autorisierungsfehler enden. Wird er erfolgreich ausgeführt, ist die Berechtigung weiter als beschrieben und die Abnahme scheitert.
Zusätzlich werden eine falsche Ausführungsumgebung, ein widerrufenes Geheimnis und eine nicht passende Federation-Bindung geprüft. Fehler dürfen weder stillschweigend übersprungen noch durch einen zweiten, weiter berechtigten Zugang kaschiert werden.
Übergabe und Wiederanlauf werden praktisch erprobt
Ein zweiter Administrator findet App, Service Principal, Berechtigungen, Ausführungsort, Protokolle und Wechseltermine anhand der Dokumentation. Er kann die Automation kontrolliert deaktivieren und wieder starten, ohne geheime Werte aus einem persönlichen Passwortspeicher des ursprünglichen Entwicklers zu benötigen.
Bei Zertifikat oder Secret wird der Wechsel vor dem ersten regulären Ablauf einmal getestet. Bei einer verwalteten Identität wird die Neubereitstellung der Ressource entsprechend ihrem Lebenszyklus geprüft. Erst danach gilt die Automation als betriebsfähig.
Abnahmeprotokoll für Automationsidentitäten
- Identitätsart, Mandant, Objekt-ID, Zweck und Ausführungsplattform sind dokumentiert.
- Erlaubte Aktionen funktionieren mit der vorgesehenen Ressource und realistischem Datenumfang.
- Nicht erlaubte Postfächer, Websites, Rollen und Aktionen werden nachweislich abgewiesen.
- Anmeldung benötigt kein persönliches Benutzerkonto und möglichst kein dauerhaftes Geheimnis.
- Fehler, ungewöhnliche Nutzung und Berechtigungsänderungen werden erkennbar protokolliert.
- Eigentümer, Vertretung, Rotation, Wiederanlauf und Stilllegung sind praktisch geklärt.
Häufige Fragen zu Dienstkonten und verwalteten Identitäten
Ist ein Dienstkonto einfach ein zusätzlicher Microsoft-365-Benutzer?
Der Begriff ist technisch unscharf. Ein zusätzliches Benutzerkonto kann als technisches Konto verwendet werden, bleibt aber eine Benutzeridentität mit Kennwort, möglicher Lizenz und eigenem Lebenszyklus. Moderne Hintergrunddienste verwenden vorzugsweise einen Service Principal oder eine verwaltete Identität.
Benötigt eine verwaltete Identität ein Kennwort oder Client Secret?
Nein. Die Azure-Plattform stellt der zugeordneten Ressource Token bereit, ohne dass die Anwendung ein eigenes Geheimnis verwaltet. Die Identität benötigt weiterhin passende Berechtigungen für den Zieldienst und kann nur auf unterstützten Azure-Ressourcen verwendet werden.
Ist eine App-Registrierung dasselbe wie ein Service Principal?
Nein. Die App-Registrierung beziehungsweise das Anwendungsobjekt beschreibt die Anwendung. Der Service Principal ist ihre konkrete Instanz und Sicherheitsidentität in einem Mandanten. An ihm gelten die lokalen Zugriffe und Zustimmungen dieser Organisation.
Wann ist ein technisches Benutzerkonto noch vertretbar?
Wenn ein notwendiges Altsystem weder moderne App-Anmeldung noch einen vorgeschalteten sicheren Vermittler unterstützt. Das Konto wird dann eng berechtigt, gegen interaktive Fremdnutzung geschützt, überwacht und mit einem konkreten Ablösungsplan geführt.
Reicht es, einer App nur die kleinste Microsoft-Graph-Berechtigung zu geben?
Sie ist ein notwendiger Anfang. Zusätzlich wird geprüft, ob die Berechtigung auf bestimmte Postfächer, SharePoint-Websites oder Azure-Ressourcen begrenzt werden kann und ob parallele Grants in anderen Verwaltungsebenen den Umfang wieder erweitern.
Technische Quellen
- Microsoft Entra: Verwaltete Identitäten für Azure-Ressourcen
- Microsoft Entra: Anwendungsobjekte und Service Principals
- Microsoft Identity Platform: Berechtigungen und Zustimmung
- Microsoft Entra: Workload Identity Federation
- Microsoft Graph: App-only-Zugriff mit Client Credentials
- Exchange Online: Application RBAC
Microsoft 365 in Frankfurt
Eine Automation soll sicher auf Microsoft 365 zugreifen?
fra.digital wählt die passende Identitätsform, begrenzt Anwendungsrechte auf den benötigten Bestand und richtet Anmeldung, Protokollierung sowie verlässlichen Betrieb ein.
