Wir beleuchteten in der Vergangenheit ausführlich die Vorteile des Enhanced Secure Administration Environment (ESAE). Doch Microsoft hat es Ende 2020 in die Rente geschickt. Oder doch nicht? Hier ein aktueller Einblick, ob und wie das ESAE-Modell weiterlebt.
Ein Gastbeitrag der TEAL Technology Consulting GmbH .
Hinweis: Dieser Beitrag ist Bestandteil einer mehrteilen ESAE-Serie. Um einen Gesamtüberblick übers Thema zu erhalten und auf dem aktuellen Stand zu sein, sollten Sie alle Teile nacheinander lesen.
-
- Teil 1: Basics & Architekturplanung
- Teil 2: Privileged Access Management & Shadow Principals
- Teil 3: Schutzmaßnahmen für die Umgebung
- Teil 4: Windows IPSec im Detail erklärt
- Teil 5: Die ESAE-Architektur von Microsoft
- Teil 6: ESAE ist tot, lang lebe SAE! (dieser Beitrag)
Darum geht es in diesem Teil der ESAE-Serie:
Ruhestand für ESAE?!
Im Dezember 2020 veröffentlichte Microsoft eine aktualisierte Fassung seiner Securing Privileged Access-Dokumentation (die mittlerweile erneut überarbeitet wurde).
Einer der Artikel beginnt mit folgendem Bild:
Das Bild suggeriert, dass das „alte“ ESAE-Modell ausgedient hat und in Rente geschickt worden wäre. Auf den ersten Blick ist das verwirrend.
Die große Frage lautet seitdem: Sind jetzt alle ESAE-Bemühungen umsonst gewesen?
So viel vorweg: Auch wenn Microsoft viele wichtige Punkte anders darstellt und ergänzt, die Grundprinzipien bleiben dieselben! Wer eine sichere Infrastruktur-Umgebung betreiben möchte, kommt auch in Zukunft nicht an den klassischen ESAE-Maßnahmen vorbei.
Support-Ende für das ESAE-Modell?
Kurz nach Veröffentlichung der Dokumentation gab es viel Aufregung. Unternehmen hatten Angst, dass bereits getätigte Investitionen umsonst waren. Wir hörten deshalb mehrfach diese Fragen von unseren Kunden:
-
- “Laufen wir Gefahr, dass unsere jetzige ESAE-Architektur durch Microsoft nicht mehr supportet wird?”
- “Wie hoch ist der Sicherheitsgewinn gegenüber dem jetzigen ESAE-Setup?”
- “Wie hoch ist der Aufwand, die neue Architektur umzusetzen?”
Bevor wir in diesem Beitrag auf die Fragen eingehen, ist zuerst eine Definition des Begriffs notwendig: Was genau ist ESAE?
Wie definiert Microsoft ESAE?
In dem Retirement-Artikel von Microsoft steht:
„The Enhanced Security Admin Environment (ESAE) architecture (often referred to as red forest, admin forest, or hardened forest) is a legacy approach to provide a secure environment for Windows Server Active Directory (AD) administrators.“
ESAE wird also mehr oder weniger mit dem Red-Forest-Modell gleichgesetzt.
Wer die vorherigen ESAE-Artikel gelesen hat, unsere Top-10-Maßnahmen-Infografik kennt (s.u.) oder auch die zahlreichen anderen Seiten im Internet zu dem Thema ESAE liest, stellt fest, dass der Begriff ESAE für die meisten viel mehr bedeutet als Red Forest.
Doch für die Beantwortung der Fragen werden wir die Definition aus dem ESAE-Retirement-Artikel verwenden.
ESAE und der Support
Frage eines Kunden: „Laufen wir Gefahr, dass unsere jetzige ESAE-Architektur durch Microsoft nicht mehr supportet wird?“
Die direkte Antwort von Microsoft lautet:
“While not a mainstream recommendation, this architectural pattern is valid in a limited set of scenarios.”
Diese Szenarien sind laut Microsoft:
-
-
- “Isolated on-premises environments”
- “Highly regulated environments”
- “High level security assurance is mandated”
-
Es gibt also auch weiterhin valide Szenarien, in denen Microsoft das “klassische” ESAE-Modell unterstützt. Auch interessant ist, dass Microsoft selbst weiterhin ein ESAE-Setup betreibt.
Weiterhin möchten wir dazu ausführen, dass ESAE eine Architektur und kein Produkt ist. Insofern gibt und gab es noch nie einen Produkt-Support im klassischen Sinne.
Um die Frage also etwas ausführlicher zu beantworten, müssen wir uns anschauen, aus welchen Komponenten eine ESAE-Architektur im Wesentlichen besteht. Glücklicherweise nutzt die Architektur viele Built-in Funktionalitäten der Betriebssysteme, weshalb die Liste erfreulich kurz ausfällt:
| Produkt | Support-Ende |
| Windows 10 | Rollierend 12 Monate seit dem letzten Update |
| Windows Server 2019 | 09.01.2029 |
| Windows Server 2022 | 13.10.2031 |
| MIM 2016 SP2* | 13.01.2026 |
| LAPS** | N/A |
*MIM kann für die Anforderung von Shadow-Principal-Rechten genutzt werden. Man kann die höheren Rechte allerdings auch per Powershell anfordern, verliert dann allerdings die Möglichkeit von Approval Workflows.
**LAPS ist leider nicht auf der Product and Services Lifecycle Information-Seite zu finden. Allerdings wurde die Version 6.2 am 10.06.2020 veröffentlicht. Wir gehen daher davon aus, dass LAPS langfristig supportet wird.
Die Tabelle (inklusive langer Fußnoten) bestätigt somit auch das, was Microsoft in dem Retirement-Artikel sagt: Man muss sich keine Sorgen machen!
Was ist mit dem Sicherheitsgewinn?
Frage eines Kunden: „Wie hoch ist der Sicherheitsgewinn gegenüber dem jetzigen ESAE-Setup?“
Diese Frage ist, wie oben schon erwähnt, konkret nur im Kunden-Kontext zu beantworten. Freundlicherweise definiert Microsoft selbst im Artikel “Measuring Success” diese Erfolgskriterien:
„A successful strategy must address all the points attackers can use to intercept privileged access workflows including four distinct initiatives:
-
-
- Privileged Access workflow elements of the privileged access workflow including underlying devices, operating systems, applications, and identities
- Identity systems hosting the privileged accounts and the groups, and other artifacts that confer privilege on the accounts
- User access workflow and authorized elevation paths that can lead to privileged access
- Application interfaces where zero trust access policy is enforced and role-based access control (RBAC) is configured to grant privileges”
-
Nachfolgend gehen wir auf jede davon ein.
ESAE und der Privileged Access Workflow & Identity Systems
Wenn man die Definition aus dem Retirement-Artikel („provide a secure environment for Windows Server Active Directory administrators“) zugrunde legt und der Absicherung der kompletten Privileged Access Plane gegenüberstellt, ist der Sicherheitsgewinn natürlich signifikant.
Wir haben uns mal die Mühe gemacht und die erste ESAE-Dokumentation aus dem Jahr 2017 aus www.web.archive.org gekramt. Darin steht:
„Tier 0 – Direct Control of enterprise identities in the environment. Tier 0 includes accounts, groups, and other assets that have direct or indirect administrative control of the Active Directory forest, domains, or domain controllers, and all the assets in it. The security sensitivity of all Tier 0 assets is equivalent as they are all effectively in control of each other.“
Wenn man also heute schon seine kompletten Tier-0-Systeme inklusive denen in der Cloud abgesichert hat, ist der Sicherheitsgewinn aus unserer Sicht gering. Wie weit fortgeschritten das Vorhaben ist, muss natürlich jeder für sich selbst bewerten.
Aus unserer Erfahrung ist es aber ein intensiver Weg, alle Tier-0-Systeme zu identifizieren und abzusichern. Das bleibt aber auch im neuen Modell nicht aus und ist mindestens genauso komplex wie zuvor.
ESAE und der User Access Workflow
Der Punkt ist leider ohne nähere Erläuterung seitens Microsoft nicht zu bewerten.
In dem Schaubild der „planes“ oben ist kein „authorized elevation path“ vom normalen User zu „privileged access“ zu erkennen. Aus unserer Sicht aus gutem Grund, da es den per Definition eigentlich nicht geben soll…
ESAE und die Application Interfaces
Das ist aus unserer Sicht tatsächlich eine Neuerung gegenüber dem “klassischen” Ansatz. Zumindest in der Konsequenz, mit der es in der Zero-Trust-Dokumentation gefordert wird:
„This is the core of Zero Trust. Instead of believing everything behind the corporate firewall is safe, the Zero Trust model assumes breach and verifies each request as though it originated from an uncontrolled network.“
Allerdings muss man die Praktikabilität des Punktes (in der geforderten Konsequenz) hinterfragen. Sicher, es gibt heute Technologien wie Azure Conditional Access und Azure Application Proxy, mit denen man relativ leicht für einen Teil der Anwendungen eine Verifizierung der Requests auf Basis mehrerer Datenpunkte durchführen kann, bevor man einem Nutzer (oder einer App) Zugang gewährt.
Denn: Wenn man sich die Technologien genauer anschaut, wird man feststellen, dass die Story noch nicht rund ist.
Der Azure Application Proxy unterstützt beispielsweise nur Web-Applikationen. Was aber macht man mit den ganzen (eingekauften) Applikationen, die einen eigenen Fat Client mitbringen? Da hilft dann wohl nur ein umfassendes App-Modernisierungsprogramm…
In den anderen fünf Bereichen sieht es vermutlich ähnlich oder schlechter aus. Deshalb wird es unserer Meinung nach noch einige Zeit dauern, bis eine normale Firma Zero Trust großflächig einsetzen kann.
Wie groß ist der Aufwand?
An dieser Stelle fällt es schwer, nicht zynisch zu werden.
Auf der einen Seite ist ein Argument von Microsoft, dass der Aufbau des Red Forests zu lange dauert. Auf der anderen Seite ist eines der Erfolgskriterien die Einführung eines Zero-Trust-Models auf allen technischen Ebenen des Unternehmens. So eine Einführung dauert je nach Unternehmen sicherlich mehrere Jahre.
Mit der jetzigen Dokumentation sehen wir uns derzeit nicht in der Lage, auch nur eine High-Level-Schätzung dafür zu machen. Grundsätzlich kann man aber feststellen, dass sowohl das alte ESAE-Modell als auch die neue Architektur enorm zeitaufwändig sind und viel Kraft bei der Einführung kosten.
Diese Anstrengungen müssen aber zwingend angegangen werden! Man vergleiche zum Beispiel den Schaden durch eine erfolgreiche Ransomware-Attacke. Dieser kann in die Hunderttausende oder gar Millionen gehen.
IT-Security sollte immer als eine konstante Investition in das Wissen der eigenen Belegschaft und der Absicherung der Infrastruktur gesehen werden. Es ist schlicht falsch zu glauben, es kann einmalig ein hoher Betrag investiert werden und danach sei man „sicher“!
Wie Microsoft selbst sagt, geht es darum, die Hürden möglichst hoch zu legen. Und es gilt, die Attacken möglichst teuer und unattraktiv für die Angreifer zu machen.
Was sollen die Änderungen?
Man könnte behaupten, dass Microsoft die Architektur abändert, um sich auf lange Sicht des on-prem Active Directories zu entledigen und gleichzeitig das Cloud-Geschäft anzukurbeln. Die Wahrheit liegt unserer Meinung nach dazwischen.
Microsoft hat vollkommen recht, dass in Zukunft immer mehr Cloud-Services genutzt werden und gerade alte Legacy-Architekturen immer wieder zu erfolgreichen Einbrüchen führen. Deswegen finden wir es richtig und konsequent, sich alter Gewohnheiten zu entledigen und moderne sowie hochsichere Produkte und Arbeitsweisen zu implementieren.
Gleichzeitig ist die Realität bei den meisten Kunden aus unserer Sicht eine andere. Die wenigsten Unternehmen können gewachsene Strukturen „einfach so“ auf eine Cloud-Only-Strategie setzen. Ebenso wenig ist es von Heute auf Morgen möglich, zentrale und wichtige Legacy-Applikationen zu modernisieren oder auszutauschen. Gleiches gilt für ein seit Jahren gewachsenes Active Directory: Das kann keiner mal nebenbei nach Azure AD migrieren.
Letztendlich beobachten wir eine hybride Strategie. Zum einen hat keiner unserer Kunden bislang den Weg zu 100 Prozent in die Cloud geschafft. Zum anderen werden aber immer mehr Workloads in der Cloud abgebildet. Da ist es nur konsequent, den Blick auch auf die Cloud-Produkte zu richten. Diese können genutzt werden, um die eigene Cloud-Instanz abzusichern, aber gleichzeitig auch on-prem Umgebungen sicherer zu machen.
Wir sehen immer mehr, dass Unternehmen beispielsweise Cloud PAWs oder Services wie Azure Sentinel nutzen, um beispielsweise SPLUNK zu ersetzen. Das kann sinnvoll sein. Und dieses Vorgehen bietet jede Menge neue Möglichkeiten, um eine Umgebung besser abzusichern.
Unser Fazit
Zusammenfassend kann man sagen, dass Microsoft sehr wichtige Punkte anspricht. Und die Company aus Redmond wirft die Frage auf, ob man mit den lokalen Gegebenheiten die jeweilige Umgebung vernünftig absichern kann.
Klar ist, dass man sich mit dem Thema Security nachhaltig beschäftigen und seine Umgebung konsequent sowie iterativ verbessern muss. Ob mit oder ohne Red Forest: Die meisten anderen Maßnahmen aus unserer Top-10-Liste (s.o.) sind nach wie vor valide und müssen betrachtet werden. Zudem sind sie unter Umständen um Cloud-Lösungen erweiterbar.
Über den Autor
Die TEAL Technology Consulting GmbH ist spezialisiert auf Infrastruktur-Security-Projekte im On-Premises- und Cloud-Umfeld. Zudem gehört TEAL zu den führenden Anbietern für die Adaption des Microsoft ESAE-Modells zur sicheren Infrastruktur-Administration. Als Partnerfirma ergänzt TEAL sinnvoll das Portfolio der FB Pro GmbH.
Bilder: kjpargeter / www.freepik.com, Microsoft, TEAL