Identity-Sprawl im Mittelstand: Was drei typische AD-plus-Cloud-Setups über die reale Angriffsfläche verraten
6 Min. Lesezeit
Identity-Sprawl ist im Mittelstand die Regel, nicht die Ausnahme. Wer drei typische Setups nebeneinanderlegt – Active Directory mit Entra-ID-Sync und parallelem SaaS, hybride Hyperscaler-Rollen, fragmentierte IdP-Landschaft mit Altlasten – sieht schnell, wo Dokumentation und reale Berechtigungsstruktur auseinanderlaufen. Angreifer sehen dasselbe, nur früher.
Das Wichtigste in Kürze
- Identity-Sprawl entsteht aus AD-Altlasten, parallel gewachsener SaaS-Nutzung und unvollständigen Hyperscaler-Rollen.
- Dokumentierte Berechtigungen und gelebte Berechtigungen decken sich im Mittelstand selten vollständig.
- Kerberoasting, Pass-the-Hash und Golden-Ticket-Angriffe nutzen genau diese Lücken.
- Die kritische Metrik ist nicht die Anzahl der Accounts, sondern der Delta zwischen Soll- und Ist-Zustand.
- Zentrales IAM mit konsequenter Lifecycle-Steuerung reduziert die Angriffsfläche messbar.
VerwandtCopilot-Sicherheitsrisiko 2026 / Ransomware 2026: Unternehmen zahlen
Die Annahme, Identitäten seien zentral gesteuert, hält einer sauberen Inventur selten stand. Personalabgänge, Projektwechsel, SaaS-Trials, Service-Accounts für verschwundene Integrationen: Jede dieser Routinen hinterlässt Artefakte in einem der Identity-Systeme. Die Summe dieser Artefakte bildet die reale Angriffsfläche – nicht das Organigramm.
Drei anonymisierte Setups aus typischen Mittelstandsumgebungen zeigen das Muster. Alle drei sind generische Patterns, keine Einzelfälle. Wer in einem dieser Setups Details wiedererkennt, sollte die eigenen Checks überprüfen, bevor es jemand anderes tut. Stand der folgenden Einordnung: April 2026.
Was ist Identity-Sprawl?
Identity-Sprawl beschreibt den Zustand, in dem Nutzer- und Service-Identitäten über mehrere getrennte Systeme hinweg wachsen, ohne dass ein gemeinsamer Lifecycle-Prozess sie konsistent hält. Jedes dieser Systeme – Active Directory, Entra ID, einzelne SaaS-Tools, Cloud-IAM – verwaltet einen Teilbestand. Der Gesamtbestand ist selten jemandem vollständig bekannt.
Setup 1: Active Directory, Entra-ID-Sync und unmanaged SaaS
Das häufigste Pattern im Mittelstand: Ein lokales Active Directory als Leitsystem, Entra ID (früher Azure AD) per Entra Connect synchronisiert, Microsoft 365 als Produktivitätsbasis. Daneben wächst eine SaaS-Landschaft, die niemand vollständig inventarisiert hat.
In der Dokumentation steht: AD ist die Quelle. Offboarding deaktiviert den AD-Account, die Synchronisation entfernt den Entra-Nutzer, der Zugang zu Microsoft 365 fällt weg. In der Realität existieren parallel SaaS-Tools mit lokalen Nutzern, Tools mit Google-Login für die Marketing-Abteilung, ein CRM mit eigenem Passwort-Login seit dem Test vor drei Jahren. Das Offboarding erreicht diese Systeme nicht.
Dazu kommt ein technisches Detail, das AD-Admins kennen: Accounts mit Service Principal Name (SPN) sind Kerberoasting-Kandidaten. In der Praxis tragen Service-Accounts von alten ERP-Integrationen oder Monitoring-Systemen oft SPNs und schwache Passwörter aus einer Zeit, in der die Domain noch kleiner war. Ein authentifizierter Domain-Nutzer reicht, um Service-Tickets anzufordern und offline zu brechen.
Das Missverhältnis in Setup 1 liegt zwischen der sauberen On/Off-Logik im AD und den SaaS-Tools, die sich an dieser Logik nicht beteiligen. Wer nur das AD härtet, härtet die Hälfte des Systems.
Eine pragmatische Inventur in einer typischen Umgebung dieser Größenordnung findet regelmäßig zwischen acht und zwanzig SaaS-Tools, die nicht im offiziellen Portfolio stehen. Marketing-Automation, Design-Suiten, Projektmanagement-Werkzeuge, Zeiterfassungstools für einzelne Standorte. Jedes davon hat einen eigenen Admin, eigene Passwortrichtlinien und keinen Bezug zum AD-Lifecycle. Bei Personalwechseln bleiben Lizenzen aktiv. Bei Tool-Wechseln bleiben Altdaten zugänglich.
Setup 2: Active Directory mit hybriden Hyperscaler-Rollen
Ambitionierter aufgestellte Mittelständler betreiben zusätzlich Workloads in AWS oder Azure. Entwickler erhalten Rollen, DevOps-Teams automatisieren Deployments, Service Accounts sprechen über Access Keys oder Managed Identities mit Cloud-Ressourcen.
In der Dokumentation heißt es: Cloud-Zugriff läuft über Entra ID oder eine AWS-SSO-Integration, Rollen sind minimal geschnitten. In der Realität haben Engineers temporäre Rollen behalten, die für einen Migrationssprint 2024 gedacht waren. Ein Access Key liegt seit zwei Jahren in einem Skript auf einem Build-Server. Eine Cross-Account-Rolle wurde für einen ehemaligen Dienstleister angelegt und nie entfernt.
Der kritische Punkt ist die Übergangsschicht. Wenn ein AD-Account über Entra ID eine Rolle in Azure annehmen kann und diese Rolle wiederum Zugriff auf KeyVaults oder Storage-Accounts hat, entsteht ein Pfad, der selten vollständig abgebildet wird. Pass-the-Hash oder Token-Diebstahl auf einem lokalen Rechner eröffnet in dieser Konstellation Möglichkeiten, die deutlich über den klassischen AD-Perimeter hinausgehen.
Hinzu kommt eine Eigenheit der Cloud-Welt, die in AD-Audits selten mitgedacht wird: Berechtigungen sind häufig rollen-basiert, aber an Workloads gebunden, die selbst Identitäten haben. Eine virtuelle Maschine mit Managed Identity, eine Pipeline mit OIDC-Token, eine Funktion mit System-Assigned Identity – das sind keine Nutzer im klassischen Sinne, aber sie haben Zugriffsrechte. Wer diese Workload-Identitäten nicht inventarisiert, übersieht eine ganze Klasse potenzieller Angriffsflächen. Compliance-Audits gegen ISO 27001 oder die NIS2-Anforderungen an Zugriffskontrolle adressieren diese Schicht selten explizit.
Setup 3: Fragmentiert, mehrere IdPs, veraltete Service-Accounts
Das dritte Pattern sieht man oft nach Zukäufen, Reorganisationen oder gewachsenen Herstellerstrukturen. Ein lokales AD für die Kernorganisation, ein zweites AD aus einem übernommenen Tochterunternehmen, ein separater IdP für die Produktionsumgebung, dazu Okta oder Google Workspace für einen Geschäftsbereich.
Die Dokumentation zeichnet diese Welt oft als „übergangsweise“. Die Realität bleibt jahrelang so. Trusts zwischen den AD-Domains wurden einmal eingerichtet und nicht wieder angefasst. Service-Accounts existieren in beiden Verzeichnissen, mit überlappenden Rechten und oft identischen Passwörtern. Privilegierte Gruppen wie „Domain Admins“ enthalten Accounts, deren ursprünglicher Zweck niemand mehr rekonstruieren kann.
Zentrales IAM versus fragmentierter Status Quo
| Dimension | Zentrales IAM | Fragmentierter Status Quo |
|---|---|---|
| Offboarding | Ein Prozess, kaskadiert in alle Systeme | Pro System manuell, lückenhaft |
| Sichtbarkeit | Eine Konsole für alle Identitäten | Mehrere Admin-Portale, kein Abgleich |
| Audit | Konsolidiertes Log, vergleichbare Events | Log-Fragmente in jedem System |
| Setup-Aufwand | Hoch, erfordert Prozess- und Tool-Disziplin | Niedrig, entsteht durch Nicht-Entscheidung |
| Angriffsfläche | Klar umrissen, gezielt härtbar | Unübersichtlich, wiederkehrende Altlasten |
Der größte Risikofaktor in Setup 3 ist nicht die Fragmentierung selbst, sondern die Annahme, sie sei temporär. Solange kein Lifecycle-Prozess die Altlasten abbaut, wächst die Zahl nicht mehr zuzuordnender Service-Accounts Jahr für Jahr.
Zentrales IAM – Pro
- Eine konsolidierte Sicht auf Identitäten
- Offboarding kaskadiert in alle Systeme
- Audit-Pfade sind durchgängig nachvollziehbar
- Privilegierte Zugriffe lassen sich gezielt hardenen
Fragmentierter Status Quo – Pro
- Niedrige initiale Setup-Hürde
- Einzelne Teams können autonom arbeiten
- Tool-Wechsel sind lokal möglich
- Keine zentrale Abhängigkeit
Zentrales IAM – Contra
- Hoher initialer Implementierungsaufwand
- Erfordert Prozess-Disziplin über Abteilungen hinweg
- Single Point of Failure bei Ausfall
- Lizenzkosten für IAM-Plattformen
Fragmentierter Status Quo – Contra
- Wachsende Zahl verwaister Accounts
- Keine konsolidierte Audit-Sicht
- Offboarding-Lücken bei jedem Personalwechsel
- Angriffsfläche skaliert mit der Zeit
Was Angreifer routinemäßig finden
Die Techniken, mit denen diese Lücken ausgenutzt werden, sind dokumentiert und seit Jahren stabil. Kerberoasting gegen Service-Accounts mit schwachen Passwörtern. Pass-the-Hash über lokal gecachte Credentials. Golden-Ticket-Angriffe, wenn ein Angreifer einmal krbtgt-Zugriff hatte. Alle drei erfordern keine Zero-Days, sondern eine Domain, in der Lifecycle-Disziplin über Jahre nachgelassen hat.
Ein typischer Angriffspfad lässt sich rekonstruieren. Er beginnt unauffällig und endet mit Zugriff auf Systeme, die nie im primären Scope standen.
Typischer Angriffspfad in Identity-Sprawl-Umgebungen
T0 – Initialer Zugang: Phishing-Mail, kompromittierte Sitzung auf einem Notebook. Der Angreifer steht als normaler Domain-Nutzer in der Umgebung.
T+1 Tag – Enumeration: Auflistung der Domain, Gruppen, Service Principal Names. Tools wie BloodHound oder vergleichbare Techniken kartieren Pfade zu privilegierten Accounts.
T+2 Tage – Kerberoasting: Anforderung von Service-Tickets für Accounts mit SPN, offline-Brute-Force gegen schwache Passwörter. Mehrere Service-Accounts fallen.
T+3 Tage – Lateral Movement: Ein kompromittierter Service-Account hat Zugriff auf einen Jump-Host. Pass-the-Hash oder gecachte Tokens erweitern die Reichweite.
T+5 Tage – Cloud-Übergang: Ein Account mit hybriden Rollen erlaubt den Sprung in die Cloud-Umgebung. Access Keys in Skripten oder vergessene Rollen beschleunigen den Weg.
T+7 Tage – Ziel erreicht: Zugriff auf Dateispeicher, Datenbanken oder Backup-Systeme. Die Umgebung ist aus Sicht des Angreifers vollständig kartiert.
Die Zeitachse ist generisch, aber in der Größenordnung realistisch. Wer den T+3-Schritt nicht bemerkt, bemerkt in der Regel auch T+7 erst, wenn Daten bereits abgeflossen sind.
Praxisorientiert lässt sich die Situation zusammenfassen: Die Angriffsfläche in typischen Mittelstandsumgebungen ist nicht das AD allein, sondern die Summe aus AD, synchronisierten Cloud-Identitäten, unmanaged SaaS und historisch gewachsenen Service-Accounts. Wer eine dieser Schichten nicht inventarisiert, härtet nicht die reale Umgebung, sondern ihre Dokumentation.
Konkret heißt das für die operative Arbeit: Eine Inventur über alle Identity-Quellen ist die Voraussetzung jeder weiteren Maßnahme. Pro Quelle drei Spalten: Account, letzter Login, Eigentümer. Wer die zweite Spalte nicht füllen kann, hat die erste nicht im Griff. Wer die dritte nicht benennen kann, hat keinen Ansprechpartner für ein Offboarding. In dieser Schlichtheit liegt der größte Hebel – und gleichzeitig der Punkt, an dem die meisten Projekte scheitern, weil keine Stelle dauerhaft zuständig ist.
Die zweite Schicht ist die Härtung der bereits inventarisierten Accounts. Service-Accounts mit SPN: Passwörter mit ausreichender Länge und Komplexität, Rotation in dokumentierten Intervallen. Privilegierte Gruppen: regelmäßige Reviews, Tiered-Admin-Modell wo möglich. krbtgt-Account: Doppel-Reset im halbjährlichen Rhythmus. Lokale Administrator-Passwörter: LAPS oder vergleichbare Lösungen. Keine dieser Maßnahmen ist neu, alle sind dokumentiert, viele scheitern an der Umsetzung im Tagesgeschäft.
Wichtig ist die Reihenfolge: Inventur kommt vor Härtung. Eine Härtungsmaßnahme an einem Account, der gar nicht mehr aktiv genutzt werden müsste, ist verschwendete Energie. Eine Härtungsmaßnahme an einem Account, dessen Existenz niemand kennt, findet erst gar nicht statt. Beide Fälle sind im Mittelstand häufiger als die Annahme einer sauberen Account-Landschaft suggeriert. Eine ehrliche Bestandsaufnahme produziert meist mehr Erkenntnisse als ein neues Tool.
Die dritte Schicht betrifft die Cloud-Übergänge. Conditional Access in Entra ID, Privileged Identity Management für temporäre Rollen, kein dauerhafter Cross-Account-Zugriff in AWS, Workload-Identitäten anstelle von Long-Lived Access Keys. Auch hier gilt: Die Konzepte sind dokumentiert, die Implementierung erfordert Aufmerksamkeit über mehrere Quartale.
Die pragmatische Konsequenz ist nicht das große IAM-Projekt zum Ende des Geschäftsjahres. Es ist eine einfache Inventur: Welche Identitäten existieren, wer hat sie erstellt, wer hat sie zuletzt benutzt, welche Rechte haben sie heute. Diese Liste, ehrlich geführt, entscheidet über den Abstand zwischen Soll- und Ist-Zustand – und damit über die reale Angriffsfläche.
Häufige Fragen
Was ist Identity-Sprawl genau?
Identity-Sprawl bezeichnet die unkontrollierte Ausbreitung von Nutzer- und Service-Identitäten über mehrere Systeme hinweg, ohne dass ein zentraler Lifecycle-Prozess sie konsistent hält. Typische Treiber sind SaaS-Wildwuchs, historisch gewachsene AD-Strukturen und parallele Hyperscaler-Rollen. Der Begriff wird sowohl in BSI-nahen Veröffentlichungen als auch in der internationalen IAM-Diskussion verwendet.
Wie unterscheidet sich Identity-Sprawl von Privilege Creep?
Privilege Creep beschreibt das Anwachsen einzelner Berechtigungen pro Account über die Zeit. Identity-Sprawl ist die Stufe darüber: das Anwachsen der Anzahl von Identitäten und der Systeme, in denen sie existieren. In der Praxis treten beide Phänomene zusammen auf und verstärken sich gegenseitig.
Warum reicht ein zentrales AD nicht aus?
Ein AD regelt, was dokumentiert und angebunden ist. SaaS-Tools mit lokalem Login, Cloud-Rollen ohne vollständige Entra-Integration und Altlasten aus Zukäufen stehen häufig außerhalb dieser Kontrolle. Die tatsächliche Berechtigungslandschaft ist größer als das, was im AD sichtbar ist.
Was ist der schnellste Hebel zur Reduktion der Angriffsfläche?
Eine konsequente Inventur aller Service-Accounts, gefolgt von Passwort-Rotation und Entfernung nicht mehr benötigter Accounts. Parallel: Review der Gruppe „Domain Admins“ und ähnlich privilegierter Gruppen. Beides ist ohne Tool-Investition möglich und adressiert die häufigsten realen Angriffspfade.
Wie relevant sind Kerberoasting oder Pass-the-Hash heute noch?
Beide Techniken sind dokumentiert, seit Jahren stabil und in Penetrationstests Standardrepertoire. Sie funktionieren nicht, weil sie neu wären, sondern weil die zugrundeliegenden AD-Schwächen in vielen Umgebungen unverändert bestehen.
Lesetipps der Redaktion
Mehr aus dem MBF Media Netzwerk
Quelle Titelbild: Pexels / Brett Sayles (px:4716292)
