ESAE ist tot, lang lebe SAE! Oder: Totgesagte leben länger

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 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.

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. Einer der Artikel beginnt mit folgendem Bild:

Auf den ersten Blick ist das verwirrend. Sind jetzt alle ESAE-Bemühungen umsonst gewesen? Müssen wir nun alles neu machen?

So viel vorweg: Auch wenn Microsoft viele wichtige Punkte anders darstellt und ergänzt, die Grundprinzipien bleiben dieselben. Und 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 neuen Dokumentation kam ein technischer Leiter von einem unserer Kunden auf uns zu und fragte uns:

Nach dem Lesen der Artikel habe ich das Gefühl, dass ich etwas tun muss, allerdings stelle ich mir folgende Fragen:

        • 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?

In diesem Beitrag gehen wir auf die Fragen im Allgemeinen ein. Die letzten zwei Fragen können natürlich nur im Kontext der vorherrschenden Situation beim Kunden konkret beantwortet werden.

Doch bevor wir damit loslegen, ist eine Begriffsbestimmung notwendig: Was genau ist ESAE für Microsoft?

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 des Kunden: „Laufen wir Gefahr, dass unsere jetzige [ESAE] Architektur durch Microsoft nicht mehr supportet wird?“

Die direkte Antwort von Microsoft: „For customers that have already deployed this architecture, there is no urgency to retire an implementation if it’s being operated as designed and intended.“

Weiterhin möchten wir dazu ausführen, dass ESAE eine Architektur und kein Produkt ist. Insofern gibt und gab es noch nie einen Produktsupport 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 Die nächste Version (voraussichtlich) Windows Server 2022 enthält weiterhin Active Directory, womit der Support bis 2032 gesichert sein sollte.
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 des Kunden: „Wie hoch ist der Sicherheitsgewinn gegenüber dem jetzigen [ESAE] Setup?“

Diese Frage ist, wie oben schon erwähnt, konkret nur im Kundenkontext 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

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 original ESAE -okumentation aus dem Jahr 2017 aus www.web.archive.org gekramt:

„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.

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önne 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.

Doch so ist es nicht. 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, hochsichere Produkte und Arbeitsweisen zu implementieren.

Gleichzeitig ist die Realität bei vielen Unternehmen aus unserer Sicht eine andere. Die wenigsten gewachsenen Strukturen können „einfach so“ auf eine Cloud-only-Strategie setzen und zentrale, wichtige Legacy-Applikationen modernisieren oder einfach austauschen. Gleiches gilt für ein seit Jahren gewachsenes Active Directory. Das kann man nicht einfach mal so nach Azure AD migrieren.

Verstehen Sie uns nicht falsch: Dem Strategie-Artikel von Microsoft können wir voll beipflichten. Das sind definitiv die richtigen, strategischen Ziele. Allerdings sind wir von der konkreten Umsetzungsbeschreibung im Security Rapid Modernization Plan enttäuscht. Der RAMP deckt nur die Privileged Access Plane ab – und auch nicht unbedingt vollständig.

Die anderen Ebenen werden gar nicht behandelt. Und auch von einer Zero-Trust-Einführung ist hier nichts mehr zu finden. Wenn man die Zero-Trust-Dokumentation liest, gibt es auch hier keine konkreten Handlungsbeschreibungen.

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.


Ü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

Ähnliche Beiträge:

Schreibe einen Kommentar