Die verborgene Gefahr von Schatten-Konten in der Microsoft 365-Automatisierung

Von Mirko Peters · 2026-08-26

Willkommen zurück zu einem weiteren Deep Dive in die Architektur, Sicherheit und die administrativen Realitäten des Microsoft-365-Ökosystems. Wenn Sie Cloud-Infrastruktur verwalten, …

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Willkommen zurück zu einem weiteren Deep Dive in die Architektur, Sicherheit und administrative Realität des Microsoft 365-Ökosystems. Wenn Sie Cloud-Infrastruktur verwalten, Workflows aufbauen oder die IT eines Unternehmens verantworten, müssen wir über eine tickende Zeitbombe sprechen, die offen sichtbar ist. In unserer letzten Episode Service Principal Security: Stop Using Personal Accounts haben wir eine Praxis beleuchtet, die so verbreitet ist, dass fast jede Organisation sie pflegt: geschäftskritische Automatisierung direkt an persönliche Benutzerkonten zu binden. Es beginnt als harmloser Abkürzungsweg. Ein Ingenieur muss schnell einen Power Automate-Flow einrichten, eine Logic App anbinden, Daten über eine API synchronisieren oder eine Datenaktualisierung in Power BI konfigurieren. Um Zeit zu sparen, meldet er die Verbindung mit seinen eigenen administrativen Anmeldedaten an. Es funktioniert sofort, das Projekt startet ohne Probleme, und alle machen weiter. Doch was passiert, wenn dieser Ingenieur das Team wechselt, sein Kennwort zurücksetzt, eine neue Richtlinie für bedingten Zugriff auslöst oder das Unternehmen verlässt? Die Automatisierung bricht, in der Produktion herrscht Stille, und die Organisation stellt fest, dass sie geschäftskritische Logik auf einer geliehenen Identität betrieben hat. Dieser Beitrag vertieft diese Gedanken und zeigt, warum Schatten-Konten Ihre Infrastruktur-Resilienz untergraben und wie Sie Ihren Ansatz modernisieren können, bevor Plattformänderungen Ihnen die Entscheidung abnehmen.

Wenn wir über Cloud-Architektur sprechen, reden wir oft über Redundanz, Failover-Cluster und Disaster Recovery. Dennoch übersehen viele Organisationen die Resilienz der Identität völlig. Wenn ein Unternehmen Workflows auf menschlichen Anmeldedaten aufbaut, entsteht ein fragiles Geflecht von Abhängigkeiten, das unweigerlich zu unerwarteten Ausfällen führt. Lassen Sie uns die Kernmechanik dieser Krise aufschlüsseln und untersuchen, wie der Übergang zu einem wirklich unternehmenstauglichen Identitätsmodell gelingt.

Der digitale Arbeitsplatz entwickelt sich schneller denn je, und die Standardisierung der Authentifizierung nicht-menschlicher Workloads ist keine optionale Best Practice mehr. Für das Überleben in modernen Cloud-Umgebungen ist sie ein verpflichtender Schritt.

Die Schatten-Konto-Falle in der Microsoft 365-Automatisierung

Die meisten Identitätsprobleme in der Unternehmensautomatisierung entstehen aus dem Streben nach Geschwindigkeit. Wenn Entwickler oder Administratoren in Microsoft 365 schnelle Integrationen bauen, fühlt sich die Nutzung eines bestehenden Benutzerkontos reibungslos an. Die Berechtigungen sind bereits vergeben, die Anmeldeaufforderungen sind vertraut, und die Bereitstellung dauert Minuten statt Stunden. Diese Bequemlichkeit erzeugt jedoch das Schatten-Konto-Modell. Persönliche Konten fungieren als verborgene Infrastrukturidentitäten und übertragen menschliche Schwachstellen in automatisierte Systeme.

Betrachten Sie die aktuelle Sicherheitslandschaft. Organisationen setzen strikte Richtlinien für Multi-Faktor-Authentifizierung (MFA), risikobasierte Anmeldesperren und regelmäßige Kennwortrotation ein, um menschliche Benutzer zu schützen. Diese Sicherheitsmaßnahmen sind für menschliche Mitarbeitende absolut notwendig, für kopflose Automatisierung jedoch verheerend. Wenn ein Skript oder ein Cloud-Flow auf einem persönlichen Konto basiert, stoppt jede routinemäßige Sicherheitsintervention – etwa eine MFA-Abfrage, ein erzwungenes Zurücksetzen des Kennworts oder eine verdächtige Anmeldeprüfung – die Automatisierung sofort. Der Workflow scheitert nicht an einem Programmierfehler, sondern daran, dass ein Mensch sein Kennwort ändern musste.

Hinzu kommt, dass das Offboarding zum administrativen Albtraum wird. Verlässt ein Mitarbeitender das Unternehmen, wird sein Konto irgendwann deaktiviert oder gelöscht. Wenn dieses Konto heimlich kritische SharePoint-Integrationen, automatisierte Berichtsprozesse oder Benachrichtigungsworkflows für Kunden antreibt, brechen diese Systeme zusammen. Oft entdecken IT-Teams diese defekten Abhängigkeiten erst, nachdem der Geschäftsbetrieb bereits gestört ist. Menschliche Konten als Infrastrukturidentitäten zu behandeln, ist ein architektonisches Anti-Pattern, das ein untragbares operatives Risiko erzeugt.

Identitätsverfall und die versteckten Kosten menschlicher Abhängigkeiten

Identitätsverfall ist ein stiller Killer in der Unternehmens-IT. Er entsteht, wenn die Annahmen, auf denen ein Authentifizierungsmechanismus beruht, im Laufe der Zeit langsam an Gültigkeit verlieren, bis das System unerwartet ausfällt. Sind Workflows an menschliche Konten gebunden, zeigt sich Identitätsverfall auf mehrere zerstörerische Arten. Rollen ändern sich, Abteilungen werden zusammengelegt, und Berechtigungen driften auseinander. Ein Konto, das früher passenden Zugriff auf eine bestimmte Website oder Datenbank hatte, kann durch ein Compliance-Audit oder einen Rollenwechsel plötzlich geänderte Rechte besitzen.

Hängt ein automatisierter Workflow von genau diesem Benutzerkontext ab, bricht jede Änderung an den Zugriffsrechten des Benutzers die Automatisierungskette. Daraus entsteht eine Kultur der Angst: IT-Administratoren scheuen sich, Benutzerkonten zu ändern, Sicherheitsprofile anzupassen oder ehemalige Mitarbeitende sauber offboarden, weil sie vermuten, dass etwas Unsichtbares kaputtgehen könnte. Service-Konten, die als ungesicherte Geisterbenutzer laufen, sind ein weiteres Symptom dieses Verfalls. Organisationen legen häufig generische Benutzerkonten an, etwa scriptrunner@company.com, vergeben dauerhafte Passwörter, umgehen MFA und verwenden sie in Dutzenden Skripten. Diese Geisterkonten verfügen selten über eine ordentliche Protokollierung, es fehlen moderne Sicherheitskontrollen, und sie stellen erhebliche Compliance-Verstöße dar, die spätestens bei einem Audit ans Licht kommen.

Wer sich auf menschliche Abhängigkeiten stützt, verliert Transparenz, Nachvollziehbarkeit und Kontrolle. Moderne Cloud-Architekturen verlangen, dass jede Workload aus eigenen architektonischen Stärken besteht, völlig unabhängig von den Personen, die sie ursprünglich entwickelt oder bereitgestellt haben.

Warum Microsoft den Wechsel weg von benutzerbasierten Workflows erzwingt

Sollten die operativen Risiken von Schatten-Konten nicht ausreichen, um Organisationen zum Umdenken zu bewegen, wird es die Plattform-Roadmap mit Sicherheit tun. Microsoft schließt aggressiv die Tür zu veralteten Authentifizierungsverfahren und benutzerbasierter Automatisierung. Auf dem Weg zum Identitätsmodell 2026 geht die Ära der Automatisierung ohne Dienstprinzipal zu Ende. Die alten SharePoint 2013-Workflows werden eingestellt, Azure AD Graph wird vollständig abgekündigt, und app-only moderne Authentifizierung wird im gesamten Ökosystem zur strikten Anforderung.

Die Botschaft von Microsoft auf Plattformebene ist eindeutig: Automatisierung braucht ihre eigene Identität. Jahrelang stellte das alte Architekturmodell eine grundsätzlich fehlerhafte Frage: „Welche Person führt diese Automatisierung aus?“ Moderne Cloud-Governance ersetzt diese Frage durch eine deutlich sicherere: „Welche bestimmte Workload ist berechtigt, diese Aktion durchzuführen?“ Dieser Wechsel verändert alles daran, wie wir Cloud-Lösungen entwerfen, bereitstellen und steuern.

Wer sich diesem Wandel nicht anpasst, kämpft gegen die natürliche Entwicklungsrichtung der Plattform. Organisationen, die an benutzerbasierter Automatisierung festhalten, werden plötzlich vor kaskadierenden Ausfällen stehen, sobald Microsoft veraltete APIs abkündigt und strikte moderne Authentifizierungsstandards durchsetzt. Der Umstieg auf Workload-Identitäten ist deshalb nicht nur ein Sicherheits-Upgrade, sondern eine Ausrichtung auf die künftige Richtung der Unternehmenssoftware.

Identität als Infrastruktur mit Dienstprinzipalen behandeln

Um Schatten-Konten zu beseitigen, müssen Organisationen ein neues Denken einführen: Identität ist Infrastruktur. So wie wir virtuelle Maschinen, Speicherkonten und Netzwerkkomponenten als eigenständige Infrastrukturressourcen behandeln, müssen wir Anwendungs- und Workload-Identitäten mit genau derselben Sorgfalt behandeln. Damit kommen wir zu Dienstprinzipalen (Service Principals).

Ein Dienstprinzipal fungiert als nicht interaktive Laufzeitidentität, die eine Workload oder Anwendung statt eines menschlichen Mitarbeitenden repräsentiert. Mit dem Entkopplungsprinzip in der Unternehmenssicherheit stellen Organisationen sicher, dass Anwendungen über eigenständige Identitätsgrenzen verfügen. Verlässt ein Mitarbeiter das Unternehmen, setzt sein Passwort zurück oder aktualisiert sein MFA-Gerät, bleibt der Dienstprinzipal völlig unberührt, weil sein Lebenszyklus vollständig von menschlichen Aktivitäten getrennt ist.

Identität als Bereitstellungsartefakt zu behandeln bedeutet: Wenn Sie eine Logic App, eine Function App oder eine Unternehmensintegration bereitstellen, werden der zugehörige Dienstprinzipal bereitgestellt, berechtigt und als Code verwaltet. Dieser infrastrukturnahe Ansatz verbessert die Ausfallsicherheit deutlich, sorgt für saubere Prüfpfade und beseitigt die fragilen menschlichen Abhängigkeiten, die stille Ausfälle verursachen.

Verwaltete Identitäten und die Stärke der geheimnisfreien Authentifizierung

Service Principals lösen zwar das Problem der menschlichen Abhängigkeit, brachten aber früher eine neue Herausforderung mit sich: die Verwaltung von Geheimnissen. Client Secrets, Zertifikate oder Kennwörter in Konfigurationsdateien, Umgebungsvariablen oder Key Vaults abzulegen, machte Organisationen weiterhin anfällig für Secret Sprawl und den Diebstahl von Anmeldedaten. Glücklicherweise hat sich die Cloud-Architektur mit der Einführung von Managed Identities von statischen Anmeldedaten gelöst.

Managed Identities gelten als Höhepunkt der cloudnativen Identitätsarchitektur, weil Azure den gesamten Lebenszyklus der Anmeldedaten automatisch verwaltet. Die Plattform übernimmt im Hintergrund die Erstellung, Rotation, Speicherung und Ablauf der Anmeldedaten sowie die Durchsetzung des Vertrauens. Entwickler und Administratoren müssen die zugrunde liegenden Anmeldedaten nie verarbeiten, einsehen oder rotieren.

Damit entsteht eine Authentifizierung ganz ohne Geheimnisse („Zero-Secret“). Indem Sie statische Client Secrets und Kennwörter vollständig eliminieren, schließen Sie einen der häufigsten Angriffsvektoren, die Angreifer ausnutzen. Ist die Identität über Azure direkt an den Lebenszyklus der Ressource gebunden, wird Vertrauen nativ auf Plattformebene hergestellt. Workloads authentifizieren sich sicher mit kurzlebigen, von der Plattform ausgestellten Tokens. So sinken das Risiko eines Angriffs und der betriebliche Aufwand deutlich.

Statische Geheimnisse mit Federated Credentials ersetzen

Managed Identities eignen sich ideal für Workloads, die direkt in Azure laufen. Viele unternehmensweite Automatisierungspipelines greifen jedoch auf externe CI/CD-Systeme, Multi-Cloud-Umgebungen oder Entwicklertools wie GitHub Actions zurück. In diesen Szenarien werden häufig langlebige Client Secrets erzeugt und in externen Repositories gespeichert. Diese Praxis schafft erhebliche Sicherheitslücken.

Hier kommen Federated Credentials und OpenID Connect (OIDC) ins Spiel. Mit föderierter Identität kann eine externe Workload eine temporäre, vertrauensbasierte Beziehung zu Microsoft Entra ID aufbauen, ohne dass im Ruhezustand gespeicherte Anmeldedaten nötig sind. Statt eines dauerhaften Kennworts fordert die externe Pipeline ein Token direkt bei ihrem nativen Anbieter an, legt dieses kryptografisch signierte Token bei Entra ID vor und erhält im Gegenzug ein kurzlebiges Zugriffstoken.

Dieses flüchtige Identitätsmodell stellt sicher, dass auf keinem Datenträger und in keiner Konfigurationseinstellung eine wiederverwendbare Anmeldedaten existiert. Wird ein externes Repository kompromittiert, finden Angreifer keine statischen Geheimnisse, die sie abgreifen könnten. Federated Credentials schließen die Lücke zwischen Multi-Cloud-Betrieb und Unternehmenssicherheit und zeigen, dass schnelle Automatisierung und robuster Schutz problemlos nebeneinander bestehen können.

Die Berechtigungsausweitung in moderner Cloud-Architektur eindämmen

Sobald Organisationen erfolgreich auf Service Principals, Managed Identities und Federated Credentials umstellen, entsteht ein neues Architekturrisiko: die Berechtigungsausweitung (Permission Creep). Eine leistungsfähige, gut funktionierende Identität mit übermäßigen Berechtigungen wird im Falle einer Kompromittierung zu einer gefährlichen Waffe. Entwickler vergeben allzu oft zu weitreichende Graph-API-Bereiche wie `Application.ReadWrite.All` oder `Directory.ReadWrite.All`, nur um Bereitstellungsreibungen zu vermeiden und Berechtigungsfehler bei der Ersteinrichtung nicht untersuchen zu müssen.

Das Ergebnis ist eine Landschaft voller überprivilegierter Service Principals, die im gesamten Mandanten unbemerkt agieren. Angreifer suchen gezielt nach Maschinenidentitäten, denn ein schlecht gesicherter Service Principal mit hohen Rechten gewährt ihnen dauerhaften, unauffälligen Zugriff auf die gesamte Umgebung. Maschinen-Token bewegen sich oft schneller und erregen weniger Verdacht als menschliche Anmeldungen. Deshalb sind sie bevorzugte Ziele für laterale Bewegungen und Datenexfiltration.

Um diese Lage zu entschärfen, müssen Sie das Prinzip der minimalen Berechtigungen konsequent umsetzen. Service Principals dürfen nur die spezifischen, granularen Anwendungsberechtigungen erhalten, die sie für ihre vorgesehenen Aufgaben benötigen. Sie müssen regelmäßig überprüft, auf auffälliges Verhalten überwacht und mit genau derselben Sorgfalt behandelt werden wie der Root-Zugriff auf physische Produktionsinfrastruktur. Wenn Sie eine geeignete Architektur für Workload-Identitäten mit konsequenter Berechtigungs-Governance kombinieren, lässt sich Automatisierung aufbauen, die zugleich hochgradig belastbar und außergewöhnlich sicher ist.

Fazit

Die Zeit, in der Unternehmensautomatisierung auf persönlichen Benutzerkonten aufgebaut wurde, geht nun offiziell zu Ende. Wie wir im gesamten Artikel gezeigt haben, führt die Anbindung kritischer Microsoft 365-Workflows an persönliche Anmeldedaten zu fragiler Infrastruktur, gravierenden Sicherheitslücken und dem unvermeidlichen Problem des Identitätsverfalls. Angesichts der aggressiven Abkündigung veralteter Authentifizierungsmethoden durch Microsoft und der ständigen Gefahr betrieblicher Ausfälle durch ausgeschiedene Mitarbeitende ist es nicht mehr vertretbar, am bisherigen Zustand festzuhalten. Wer Dienstprinzipale einsetzt, verwaltete Identitäten für eine Authentifizierung ohne Geheimnisse nutzt, föderierte Anmeldeinformationen verwendet und Berechtigungen konsequent verwaltet, kann seine Automatisierungsprozesse in sichere, belastbare Unternehmenswerte verwandeln.

Wenn Sie diese Konzepte vertiefen und praxiserprobte Strategien zur Absicherung Ihrer Automatisierungsumgebungen kennenlernen möchten, hören Sie sich unbedingt unsere Episode Service Principal Security: Stop Using Personal Accounts an. Sie bietet zahlreiche praktische Einblicke, mit denen Sie Ihre aktuelle Architektur überprüfen, Schatten-Konten beseitigen und Ihren Microsoft 365-Mandanten gegen die drohende Identitätskrise wappnen können.