Microsoft macht die Rolle rückwärts: Tiering ist nicht tot, es ist überlebenswichtig
1007959
wp-singular,post-template-default,single,single-post,postid-1007959,single-format-standard,wp-theme-bridge,wp-child-theme-bridge-child,bridge-core-3.3.4.8,groovy_menu_1-4-8,metaslider-plugin,,qode-title-hidden,qode-child-theme-ver-1.0.0,qode-theme-ver-30.8.8.9,qode-theme-bridge,disabled_footer_top,qode_header_in_grid,qode-wpml-enabled,wpb-js-composer js-comp-ver-8.7.3,vc_responsive
blog header microsoft windows

Microsoft macht die Rolle rückwärts: Tiering ist nicht tot, es ist überlebenswichtig

Microsoft veröffentlicht ein Active Directory Tier Model auf GitHub. Für viele klingt das nach einem neuen Tool. Für uns ist es der offizielle Beweis für etwas, das wir seit Jahren sagen: Wer seine privilegierten Identitäten nicht sauber trennt, spielt mit dem Totalausfall.

Vor ein paar Jahren klang es noch so, als sei das klassische ESAE- beziehungsweise Tiering-Modell ein Auslaufmodell. Cloud, Zero Trust, moderne Identitätsplattformen, neue Security-Architekturen. Alles sollte moderner, flexibler und weniger „Legacy“ werden.

Und ja: Die Cloud hat vieles verändert. Entra ID, Conditional Access, moderne Authentifizierung, Privileged Identity Management und Zero Trust sind wichtige Bausteine einer modernen Sicherheitsarchitektur. Aber die Grundfrage ist dieselbe geblieben:

Wer darf eigentlich worauf zugreifen und was passiert, wenn genau diese Identität kompromittiert wird?

Genau deshalb ist das neue Active Directory Tier Model von Microsoft (veröffentlicht auf GitHub) so spannend. Microsoft stellt dort ein deklaratives PowerShell-Framework bereit, mit dem sich ein Active-Directory-Tiering-Modell für Tier 0, Tier 1 und Tier 2 deployen und auditieren lässt. Das Repository beschreibt unter anderem OUs, Gruppen, Benutzer, ACL Delegations, GPOs, ADMX, Managed Service Accounts, Windows LAPS Permissions, idempotente Re-Runs, Drift Detection und reproduzierbare Builds über eine versionierte JSON-Konfiguration.

Oder weniger technisch gesagt: Microsoft bringt Tiering wieder sehr deutlich auf die Bühne.

Und das ist keine kleine Randnotiz. Das ist ein ziemlich klarer Schritt.

Tiering war nie wirklich weg

Wenn man sich die Diskussion rund um ESAE, Red Forest und Tiering anschaut, wurde in den letzten Jahren viel durcheinandergeworfen. In unserem älteren Artikel ESAE is dead – Long live SAE, oder Totgesagte leben länger? haben wir genau diese Verwirrung schon einmal eingeordnet: Microsoft hatte ESAE im Kontext des Red-Forest-Modells neu bewertet, aber die zugrunde liegenden Sicherheitsprinzipien blieben weiterhin relevant. Gerade die Absicherung von Tier-0-Systemen, privilegierten Identitäten und administrativen Zugriffspfaden bleibt aus TEAL-Sicht zentral.

Das neue Microsoft-Projekt bestätigt diesen Punkt jetzt noch einmal sehr deutlich. Denn Tiering ist keine nostalgische On-Prem-Idee aus alten Active-Directory-Zeiten. Tiering ist ein Sicherheitsprinzip.

Es geht darum, kritische Systeme, Identitäten und administrative Berechtigungen so voneinander zu trennen, dass ein kompromittierter Client nicht automatisch der erste Schritt zum Domain Admin wird.

Typische Beispiele:

    • Ein Tier-0-Admin meldet sich nicht an einem normalen Client an.
    • Hochprivilegierte Zugangsdaten werden nicht auf unsauberen Systemen hinterlassen.
    • Kritische Identitätssysteme werden besonders stark geschützt.
    • Berechtigungen werden nicht historisch gewachsen, sondern bewusst modelliert.
    • Angriffspfade zwischen den Ebenen werden sichtbar gemacht und reduziert.

Genau diese Grundidee haben wir auch in unserem Artikel Datensicherheit durch Tiering – Schutz auf jeder Ebene beschrieben: Microsoft Tiering unterteilt IT-Systeme in unterschiedliche Ebenen, um hochkritische Systeme von weniger kritischen Ressourcen zu trennen und Angreifern den Weg durch die Umgebung zu erschweren.

Das Problem: Zu viele Rechte, zu wenig Struktur

In der Theorie klingt Tiering logisch… in der Praxis sieht es oft anders aus. Viele Unternehmen haben über Jahre gewachsene Active-Directory-Strukturen, historische Gruppen, alte Service Accounts, lokale Administratorrechte, Sonderberechtigungen und „temporäre“ Ausnahmen, die nie wieder entfernt wurden. Das Ergebnis ist häufig kein klares Tiering-Modell, sondern ein Berechtigungs-Teppich. Und genau das lieben Angreifer.

Ein Angriff muss nicht direkt auf den Domain Controller starten. Es reicht oft ein kompromittierter Client, ein zu mächtiger lokaler Admin, ein schlecht abgesicherter Server oder ein Account, der irgendwo Zugriff hat, wo er ihn nie hätte haben dürfen. Aus einem kleinen Problem wird dann ein Angriffspfad.

Und aus einem Angriffspfad wird im schlimmsten Fall ein vollständiger Kompromiss der Umgebung.

Die Gefahr liegt selten nur in einer einzelnen Fehlkonfiguration. Gefährlich wird es, wenn mehrere scheinbar kleine Schwächen zusammen eine Kette bilden. Genau diese Perspektive spielt auch bei Attack Path Management eine zentrale Rolle, wie wir bereits im Kontext von BloodHound OpenGraph beschrieben haben: Die entscheidende Frage ist nicht nur, ob ein einzelnes System sauber ist, sondern welche Kette aus Identitäten, Berechtigungen und Vertrauensbeziehungen zu kritischen Systemen führt.

Was Microsoft jetzt konkret bereitstellt 

Mit dem neuen Active Directory Tier Model liefert Microsoft kein magisches „Einmal klicken und alles ist sicher“-Produkt.

Aber Microsoft stellt ein Framework bereit, das viele technische Aufgaben rund um Aufbau, Deployment und Audit eines Tiering-Modells strukturierter und wiederholbarer macht.

Laut Repository handelt es sich um ein PowerShell-Framework, das ein Active-Directory-Tier-Modell aus einer versionierten JSON-Konfiguration deployen und auditieren kann. Es unterstützt unter anderem wiederholbare Deployments, Drift Auditing, strukturierte Findings und modulare Tests.

Das ist vor allem für Unternehmen interessant, die ein Tiering-Modell bewusst nach Microsoft-Vorgaben aufbauen oder bestehende Strukturen dagegen prüfen wollen.

Besonders spannend ist dabei nicht nur das Deployment, sondern die Audit-Funktion.

Microsoft dokumentiert für das Framework eine Drift Detection über Audit-TierModel.ps1. Dieses Skript analysiert den aktuellen Active-Directory-Zustand gegen die deklarative Tier-Model-Konfiguration und identifiziert unter anderem fehlende Objekte, abweichende Konfigurationen und strukturierte Drift Findings zur weiteren Bearbeitung.

Drift Detection ist gut – aber ersetzt kein Attack Path Management

Drift Detection hat eine wichtige Grenze… sie prüft gegen das Modell, das du definiert hast.

Wenn du dich sehr eng an Microsoft-Vorgaben hältst, kann dir das helfen, Abweichungen sichtbar zu machen. Wenn deine Umgebung aber stark angepasst ist, eigene Prozesse, Sonderrollen, individuelle Delegationen oder historisch gewachsene Strukturen enthält, reicht ein reiner Vergleich gegen ein Standardmodell nicht aus.

Wenn Custom-Konfigurationen im Spiel sind, landet man schnell beim Attack Path Management, weil man dort den tatsächlichen Angriffsweg sieht, unabhängig davon, wo er entsteht.

Drift Detection kann dir zeigen, ob bestimmte OUs, Gruppen, ACLs oder GPOs vom geplanten Zustand abweichen. Die Microsoft-Dokumentation beschreibt dafür unter anderem Audit-Ergebnisse mit Summary, Warnings, Errors und Drift Findings sowie mögliche Ausgaben als JSON, HTML oder NUnit XML.

Attack Path Management geht darüber hinaus und betrachtet, welche Kombinationen aus Berechtigungen, Identitäten und Vertrauensbeziehungen tatsächlich gefährlich werden können. Genau diese Sicht ist besonders wichtig, wenn Umgebungen nicht sauber standardisiert sind oder wenn AD, Entra ID, Cloud, SaaS und weitere Plattformen zusammen gedacht werden müssen.

Microsoft nimmt Tiering wieder sichtbar ernst 

Microsoft dokumentiert, automatisiert und auditiert Tiering wieder sehr sichtbar. Das Repository beschreibt das Ziel, eine Active-Directory-Tier-Model-Struktur für Tier 0, Tier 1 und Tier 2 zu deployen und zu auditieren. Außerdem verweist es auf Dokumentation zu Deployment, Drift Detection, Logging, GPO Management, ADMX Management, Conditional Principals, CI/CD Integration, Test Coverage und Sentinel Monitoring.

Damit wird sehr deutlich: Tiering ist kein alter Zopf. Tiering ist weiterhin Stand der Technik.

Natürlich haben sich Werkzeuge verändert und natürlich ist die Cloud wichtiger geworden. Entra ID, Privileged Access, Conditional Access, Zero Trust und moderne Identity Security müssen mitgedacht werden.

Aber die Grundprinzipien bleiben gleich:

    • Privilegierte Identitäten müssen besonders geschützt werden.
    • Administrative Zugriffe müssen getrennt werden.
    • Tier-0-Systeme dürfen nicht über niedrigere Ebenen kompromittierbar sein.
    • Login- und Admin-Pfade müssen bewusst gestaltet werden.
    • Die Umsetzung muss regelmäßig überprüft werden.

Was das für Unternehmen bedeutet 

Für Unternehmen ist das neue Microsoft-Framework vor allem ein guter Anlass, die eigene Tiering-Strategie zu überprüfen. Nicht irgendwann. JETZT!

Tiering ist kein Projekt, das man einmal abschließt und dann abhakt. Tiering ist ein Betriebsmodell.

Der TEAL-Ansatz aus unserem Tiering-Artikel bleibt deshalb weiterhin sinnvoll: Angriffspfade analysieren, Systeme und Benutzer klassifizieren, Schutzmechanismen implementieren, Berechtigungen migrieren und die Umgebung kontinuierlich validieren. Der Artikel beschreibt diesen Ansatz als vier Phasen: Vorbereitung mit Angriffspfadanalyse und Klassifizierung, Implementierung von Schutzmechanismen, Migration und Neuzuordnung der Berechtigungen sowie Validierung und kontinuierliche Kontrolle.

Wenn du das neue Microsoft-Tiering-Framework zum Anlass nehmen willst, eure Umgebung zu hinterfragen, starte nicht direkt mit Skripten.

Starte mit den richtigen Fragen:

    • Welche Systeme sind bei euch wirklich Tier 0?
    • Welche Accounts haben direkten oder indirekten Einfluss auf diese Systeme?
    • Wo melden sich privilegierte Benutzer tatsächlich an?
    • Welche Admin-Konten existieren historisch noch?
    • Welche Service Accounts haben zu weitreichende Rechte?
    • Welche Gruppen wurden über Jahre verschachtelt und nie bereinigt?
    • Gibt es technische Anmelderestriktionen zwischen den Tiers?
    • Wird regelmäßig geprüft, ob neue Angriffspfade entstanden sind?
    • Habt ihr einen Soll-Zustand, gegen den ihr Abweichungen messen könnt?
    • Nutzt ihr Attack Path Management, um reale Angriffswege sichtbar zu machen?

Erst wenn diese Fragen beantwortet sind, wird ein Framework wirklich wertvoll. Denn Tools können nur automatisieren, was vorher verstanden wurde.

Unsere Meinung & Fazit

Aus TEAL-Sicht ist die Veröffentlichung des Active Directory Tier Models ein positives Signal.

Nicht, weil jetzt plötzlich alles neu wäre. Sondern weil Microsoft damit ein Sicherheitsprinzip wieder sehr sichtbar macht, das in vielen Unternehmen zu lange als „altes AD-Thema“ behandelt wurde.

„Totgesagte leben länger. Ich habe es ja gleich gesagt!“ – so Fabian Böhm (CEO & Security Architect bei TEAL Consulting) nach der Microsoft Veröffentlichung.

Microsoft hat mit den neuen Skripten und der Dokumentation sicherlich dazu beigetragen, den Einstieg in Tiering zu vereinfachen. Das begrüßen wir ausdrücklich. Gleichzeitig ändert sich am grundsätzlichen Vorgehen wenig: Klassifizieren, trennen, technische Schutzmaßnahmen umsetzen, Berechtigungen sauber migrieren und regelmäßig validieren.

Tiering ist nicht tot. Tiering ist Pflichtprogramm.

Du möchtest mehr zum Blogbeitrag erfahren und dich mit einem Experten von TEAL dazu austauschen, dann buche hier ein Beratungsgespräch!

LATEST POSTS