Enterprise Access Model
Microsofts Weiterentwicklung des klassischen AD-Tiering-Modells für hybride und Cloud-Umgebungen — strukturiert privilegierten Zugriff in Control Plane, Management Plane und Data/Workload Plane statt starrer Tier-Grenzen.
Das Enterprise Access Model ist Microsofts aktuelle Referenzarchitektur für privilegierten Zugriff in modernen, hybriden IT-Umgebungen. Es löst das klassische Tiering-Modell aus der Active Directory-Ära konzeptionell ab und erweitert es um Cloud-Identitäten, SaaS-Workloads und Zero-Trust-Prinzipien. Wer das Modell versteht, versteht auch, warum die alten Tier-Grenzen allein nicht mehr ausreichen, sobald Entra ID und Microsoft 365 ins Spiel kommen.
Geschichte: Vom AD-Tiering zur Enterprise-Architektur
Das klassische Administrative Tier Model entstand um 2014 als Reaktion auf die Welle von Pass-the-Hash- und Lateral-Movement-Angriffen, die sich in dieser Zeit häuften. Es löste ein konkretes Problem: In den meisten Active Directory-Umgebungen verwendeten Administratoren ein einziges Konto für alle Aufgaben — vom Helpdesk auf Endgeräten bis zur Domain-Controller-Verwaltung. Das Ergebnis war eine Angriffsfläche, die es Angreifern ermöglichte, von einem kompromittierten Arbeitsplatz in wenigen Schritten zur vollständigen Domänenübernahme zu gelangen.
Das Drei-Tier-Modell (Tier 0: Identitätssteuerung, Tier 1: Server und Anwendungen, Tier 2: Endgeräte) war für reine On-Premises-Umgebungen eine elegante Lösung. Mit dem Aufkommen von Azure, Entra ID, Microsoft 365 und hybriden Identitätssystemen wie Azure AD Connect (heute Microsoft Entra Connect) wurden die starren Tier-Grenzen jedoch zunehmend unzureichend: Cloud-Identitäten, SaaS-Zugriffe und Management-APIs ließen sich nicht sauber in das Drei-Stufen-Schema einfügen.
Microsoft veröffentlichte um 2020 das Enterprise Access Model (ursprünglich als Teil der „Privileged Access" Guidance unter dem Namen „Privileged Access Model") als Weiterentwicklung, die diese Lücken schließt. Es ist kein Bruch mit dem Tiering-Modell, sondern eine Erweiterung seiner Kernprinzipien auf eine Cloud-native Welt.
Die drei Ebenen des Enterprise Access Model
Das Modell strukturiert die IT-Umgebung in drei funktionale Ebenen — Planes — anstelle der alten numerierten Tiers.
| Plane | Entspricht (alt) | Enthält | Angriffsziel |
|---|---|---|---|
| Control Plane | Tier 0 (erweitert) | Entra ID, Active Directory, PKI, Entra Connect, ADFS, privilegierte Identitätsplattformen | Vollständige Identitätskontrolle |
| Management Plane | Teil von Tier 1 (unternehmensweites IT-Management) | IT-Management-Tools, Server, Cloud-Abonnement-Verwaltung, Backup-Systeme, SCCM/Intune, Azure Management | Infrastrukturkontrolle, Datenzugriff |
| Data / Workload Plane | Teil von Tier 1 (Workload-spezifisch) + Tier 2 (Nutzer-/App-Zugriff) | Anwendungen, Daten, Endgeräte, SaaS-Dienste, B2B/B2C-Zugriffe | Geschäftskritische Daten und Prozesse |
Die Zuordnung ist nicht 1:1: Das alte Tier 1 wird im EAM in Management Plane und Data/Workload Plane aufgeteilt, während Tier 2 in User-Access- und App-Access-Zugriffspfade reorganisiert wird, die das Modell zusätzlich definiert.
Die Umbenennung ist nicht nur kosmetisch. Die Control Plane umfasst jetzt explizit auch Cloud-Identitätssysteme — ein Entra-ID-Global-Administrator hat dieselbe faktische Macht wie ein Domain Admin in einer reinen On-Premises-Umgebung und gehört daher in dieselbe Sicherheitsstufe. Ein Azure-Subscription-Owner, der die gesamte Cloud-Infrastruktur kontrolliert, ist ebenfalls Control-Plane-Material, auch wenn er technisch keinen Zugriff auf den lokalen Domain Controller hat.
Die Data/Workload Plane ist eine echte konzeptionelle Neuerung: Das alte Tier-2-Modell kannte nur Endgeräte und Nutzer. Das Enterprise Access Model erkennt an, dass Anwendungen, SaaS-Dienste und Daten selbst Angriffsziele mit eigenen Zugriffsmodellen sind — und dass deren Verwaltungskonten eine eigene Sicherheitsklasse bilden.
Control Plane: Identität ist das neue Tier 0
Im klassischen Tiering-Modell waren Domain Controller die Kronjuwelen von Tier 0. Im Enterprise Access Model erweitert sich die Control Plane auf alle Systeme, die Identitätsentscheidungen treffen oder darauf einwirken können.
Zur Control Plane gehören der lokale Active Directory mit seinen Domain Controllern und allen Replikationspartnern, die Entra-ID-Instanz des Unternehmens sowie alle Konten mit Global-Administrator- oder Privileged-Role-Administrator-Rechten. Entra Connect (früher Azure AD Connect) synchronisiert Identitäten zwischen On-Premises-AD und Entra ID und kann in beide Richtungen schreiben — wer dieses System kompromittiert, kontrolliert effektiv beide Welten. Das gilt ebenso für Active Directory Certificate Services (AD CS), da ein kompromittiertes CA-Zertifikat zur Ausstellung gefälschter Kerberos-Tickets genutzt werden kann.
Der praktische Unterschied zum alten Modell: Ein Cloud-Administrator, der ausschließlich mit Entra ID und Azure-Ressourcen arbeitet und noch nie einen lokalen Domain Controller berührt hat, muss trotzdem als Control-Plane-Konto behandelt werden — mit denselben Anforderungen an dedizierte Workstations, starke Authentifizierung und Zugriffsüberwachung.
Management Plane: Infrastruktur sicher verwalten
Die Management Plane entspricht weitgehend dem alten Tier 1 und umfasst die IT-Management-Werkzeuge, die Infrastruktur und Workloads verwalten. Dazu zählen Deployment-Systeme wie Microsoft Endpoint Configuration Manager (SCCM) oder Intune, Backup-Lösungen, Monitoring-Plattformen, Virtualisierungsinfrastruktur sowie die Management-APIs von Cloud-Anbietern (Azure Resource Manager, AWS Management Console).
Eine wichtige Erkenntnis des Enterprise Access Model: Management-Plane-Systeme haben oft transitiven Control-Plane-Zugriff. Ein Backup-Server, der Domain-Controller-Backups enthält, ein SCCM-Server, der Software auf Domain Controllern deployed, oder ein Monitoring-Agent mit privilegiertem Zugriff auf alle Server — all diese Systeme können einen Angriffspfad zur Control Plane darstellen, auch wenn sie nominell nur Management-Plane sind. Ihre Absicherung folgt denselben Prinzipien wie Tier-1-Systeme im klassischen Modell, aber mit expliziter Prüfung transitiver Abhängigkeiten.
Das Konzept der Intermediäre
Eine wichtige konzeptionelle Erweiterung des Enterprise Access Model ist die explizite Modellierung von Intermediären als kritische Komponente in der Zugriffskette. Intermediäre sind Systeme, die den Zugriff zwischen Administratoren und den verwalteten Systemen vermitteln: VPN-Gateways, Jump-Server, Remote-Desktop-Gateways, Virtual Desktop Infrastructure (VDI), Cloud-Shell-Umgebungen oder Proxy-Dienste für Anwendungsveröffentlichung.
Intermediäre sind aus Angreifersicht attraktiv, weil sie häufig Credentials oder Session-Tokens privilegierter Konten zwischenspeichern und gleichzeitig weniger streng gesichert sind als die eigentlichen Ziele. Ein kompromittierter Jump-Server, von dem Tier-1-Administratoren auf Server zugreifen, gibt Angreifern einen Stützpunkt auf der Management-Plane — ohne dass sie jemals direkt an die verwalteten Server herankommen müssen.
Das Enterprise Access Model verlangt, dass Intermediäre entsprechend ihrer Nutzung klassifiziert werden: Ein Jump-Server, von dem aus Control-Plane-Systeme verwaltet werden, ist selbst ein Control-Plane-System und muss entsprechend gehärtet und überwacht werden.
Gerätesicherheitsstufen: Enterprise, Specialized, Privileged
Das Modell definiert drei Gerätesicherheitsstufen mit steigenden Anforderungen, die den verschiedenen Ebenen zugeordnet werden.
Privileged (PAW) ist die höchste Stufe und entspricht den Privileged Access Workstations (PAWs) aus dem klassischen Tiering-Modell. Diese physisch oder strikt virtuell isolierten Geräte werden ausschließlich für die Verwaltung von Control-Plane-Systemen genutzt. E-Mail, Webbrowser und Office-Anwendungen haben auf einem PAW nichts zu suchen — diese Produktivitätsanwendungen sind die häufigsten Vektoren für Phishing und Malware.
Specialized ist die mittlere Stufe für Management-Plane-Rollen. Diese Geräte sind gehärtet, erlauben keine Self-Administration und schränken die Anwendungsinstallation ein. Sie bieten nicht den extremen Isolationsgrad eines PAW, reduzieren aber die Angriffsfläche erheblich gegenüber Standard-Arbeitsplätzen.
Enterprise ist die Basissicherheitsstufe für alle Endnutzer und Data/Workload-Plane-Zugriffe. Enterprise-Geräte erfüllen die grundlegenden Sicherheitsanforderungen (Verschlüsselung, aktuelle Patches, Endpoint-Protection), werden aber für allgemeine Produktivitätsaufgaben genutzt.
Allen Stufen gemeinsam ist das Prinzip, dass privilegierte Konten niemals von Geräten einer niedrigeren Sicherheitsstufe aus verwendet werden — nicht aus Bequemlichkeit, nicht aus Zeitdruck, und auch nicht in Ausnahmesituationen.
Zero Trust als integrales Architekturprinzip
Das Enterprise Access Model ist im Kern die Anwendung von Zero-Trust-Prinzipien auf das privilegierte Zugriffsmanagement. Wo das klassische Tiering-Modell primär auf Netzwerksegmentierung und GPO-Anmeldebeschränkungen setzte — also auf netzwerkbasierte Kontrollen — verlagert das Enterprise Access Model die Durchsetzung auf Identität und Gerätecompliance.
Conditional Access in Entra ID ist das zentrale Durchsetzungswerkzeug: Zugriff auf Control-Plane-Ressourcen wird nicht nur an die Identität, sondern auch an den Gerätezustand (compliant, hybrid-joined), den Standort, die Risikobewertung der Sitzung und das verwendete Authentifizierungsverfahren geknüpft. Ein Global-Administrator-Konto mit korrektem Passwort und MFA-Token erhält keinen Zugriff auf privilegierte Verwaltungsportale, wenn er von einem nicht-verwalteten Privatgerät aus zugreift — diese Richtlinie lässt sich in Conditional Access direkt abbilden.
Diese Verlagerung ist entscheidend in hybriden Umgebungen: Wenn Administratoren von überall arbeiten und Cloud-Management-APIs keine Netzwerkgrenzen kennen, sind Netzwerksegmentierung und Firewallregeln allein keine ausreichende Kontrolle. Identität und Gerät müssen die Sicherheitsgrenze bilden.
Implementierung in hybriden Umgebungen
Die typische Unternehmensumgebung, für die das Enterprise Access Model ausgelegt ist, kombiniert lokales Active Directory mit Entra ID, nutzt Microsoft 365 für E-Mail und Zusammenarbeit, betreibt Server sowohl On-Premises als auch in Azure und verwendet Intune für das Gerätemanagement. In dieser Realität entstehen Angriffspfade, die das klassische Tiering-Modell nicht adressiert.
Ein Beispiel: Ein Angreifer kompromittiert das Microsoft 365-Konto eines Nutzers (kein privilegiertes Konto, Tier 2 im alten Modell). Über SharePoint-Zugriff gelangt er an ein Skript, das Zugangsdaten für eine Azure Automation-Runbook enthält. Das Runbook hat Contributor-Rechte auf eine Azure-Subscription, die wiederum einen virtuellen Domain Controller enthält. Dieser Angriffspfad führt von einem Standard-User-Konto zur Control Plane — über Cloud-Ressourcen, die im klassischen Tier-Modell nicht sichtbar waren.
Das Enterprise Access Model adressiert dies durch drei Anforderungen: Erstens werden alle Identitäten mit signifikantem Zugriff auf Cloud-Ressourcen explizit einer Plane zugeordnet und entsprechend geschützt. Zweitens werden Service Principals und Managed Identities in Entra ID als privilegierte Identitäten behandelt, wenn sie Control- oder Management-Plane-Zugriff haben. Drittens werden Cloud-native Sicherheitsdienste wie Microsoft Defender for Identity, Defender for Cloud und Entra ID Protection in die Überwachungsstrategie integriert.
Praktische Implementierungsreihenfolge
Die vollständige Umsetzung des Enterprise Access Model ist ein mehrphasiges Vorhaben. Für die meisten Organisationen gilt: Der Einstieg erfolgt über die Grundlagen des klassischen Tiering-Modells, nicht sofort über das vollständige Enterprise Access Model.
In der ersten Phase steht Tier-0-Härtung im Vordergrund: Domain Controller absichern, Domain-Admin-Konten von alltäglicher Verwaltung trennen, Authentication Policies und GPO-Anmeldebeschränkungen konfigurieren, LAPS für lokale Administratorkonten einführen. Diese Maßnahmen schließen die häufigsten und gefährlichsten Angriffspfade.
In der zweiten Phase folgt die Cloud-Integration: Entra-ID-Global-Administratoren werden identifiziert und mit PAW-Anforderungen versehen, Conditional-Access-Richtlinien für privilegierte Rollen werden konfiguriert, Entra Connect wird als Control-Plane-System behandelt und entsprechend gehärtet.
Die dritte Phase adressiert die vollständige Plane-Klassifikation: Alle Service Principals, Managed Identities und Automation-Konten werden auf ihren Zugriff hin bewertet und klassifiziert, Intermediäre werden identifiziert und in die Sicherheitsarchitektur einbezogen, und Just-in-Time-Zugriff über Entra ID Privileged Identity Management (PIM) wird für alle Control-Plane-Rollen aktiviert.
Organisationen, die noch kein Tiering-Modell implementiert haben, sollten mit Tier-0-Härtung beginnen — das Enterprise Access Model ohne diese Grundlage zu implementieren wäre wie ein Dach zu bauen, bevor das Fundament steht.
Relevanz für den Mittelstand
Das Enterprise Access Model klingt nach Enterprise-Architektur für Konzerne, ist aber für jedes Unternehmen relevant, das Microsoft 365 oder Azure nutzt. Die Kernfrage lautet: Wer in Ihrer Organisation hat Global-Administrator-Rechte in Entra ID, und von welchen Geräten aus werden diese Rechte verwendet?
In der Praxis finden wir regelmäßig, dass Global-Administrator-Konten dieselben sind, die für alltägliche Microsoft-365-Verwaltung, Helpdesk-Aufgaben und normale Arbeitsaufgaben genutzt werden. Ein einziges kompromittiertes Passwort — oder eine Phishing-Mail, die MFA umgeht — gibt Angreifern vollständige Kontrolle über die gesamte Microsoft-Cloud-Umgebung. Die Control-Plane-Anforderungen des Enterprise Access Model sind für dieses Szenario die richtige Antwort: dedizierte Admin-Konten, Conditional Access mit Gerätebindung, und keine Nutzung privilegierter Konten auf Standard-Arbeitsplätzen.