Das ESAE-Modell im Einsatz – Teil 1: Basics & Architekturplanung

In dieser Blog-Serie wird das Konzept hinter Microsoft ESAE erklärt. Und es gibt tiefe Einsichten, die in Kundenprojekten gewonnen wurden.

Ein Gastbeitrag der TEAL Technology Consulting GmbH .

TEAL ist einer der führenden Anbieter für die Adaption des Microsoft ESAE-Modells (Microsoft Enhanced Security Administrative Environment) zur sicheren Infrastruktur-Administration. In einer mehrteiligen Blog-Serie informiert TEAL über die Konzepte hinter Microsoft ESAE und die Erfahrungen, die bei Kundenprojekten gewonnen wurden. 

TEAL ist spezialisiert auf Infrastruktur-Security-Projekte im On-Premises- und Cloud-Umfeld. Als Partnerfirma ergänzt TEAL sehr gut das Portfolio der FB Pro GmbH.

Der Aufbau einer ESAE-inspirierten Umgebung

In den letzten Monaten durften wir ein spannendes Projekt realisieren: Wir bauten für einen weltweit tätigen Versicherer eine Umgebung auf, die von ESAE inspiriert wurde. Unsere Erfahrungen und Erkenntnisse teilen wir in dieser Blog-Serie.

Zu Anfang möchten wir erklären, worum es sich bei ESAE handelt, warum man es braucht, und aus welchen Komponenten die Umgebung besteht. Später werden wir einzelne Komponenten näher beleuchten, um danach unsere praktischen Erfahrungen und unseren Umgang mit den Stolpersteinen zusammen zu fassen.

Was ist ESAE?

ESAE ist ein Design-Approach von Microsoft, um Credential Theft und Pass the Hash- / Pass the Ticket-Angriffe zu erschweren bzw. deren Auswirkung zu reduzieren. Zu den Themen Credential Theft, Pass the Hash / Pass the Ticket gibt es sehr gute Blog-Serien und Whitepaper, weshalb wir uns auf eine kurze Zusammenfassung beschränken und weiterführende Themen verlinken.

Das Problem

Aufgrund der Art und Weise, wie Windows und Active Directory funktionieren, gibt es eine Reihe von Möglichkeiten für Angreifer, Passwörter oder deren Hashes auszulesen und weiter zu verwenden. Alles, was dazu nötig ist, sind Admin-Rechte auf einer Workstation und frei zugängliche Tools wie Mimikatz.

Admin-Rechte können beispielsweise über einen Phishing-Angriff oder einen Social-Engineering-Angriff erbeutet werden. Allein im Jahr 2016 wurden laut der Studie „Wombat Security State of the Phish 2017” 76% aller Organisationen Opfer von Phishing-Angriffen. Gerade bei größeren Organisationen ist die Wahrscheinlichkeit groß, dass früher oder später ein Angreifer Erfolg hat.

Im nächsten Schritt versucht der Angreifer, sich im Netzwerk auszubreiten. Früher mussten er sich zeitaufwändig mittels Trial und Error durch das Netzwerk bewegen, um irgendwann privilegierte Konten zu erbeuten. Heute gibt es Tools wie Bloodhound, die innerhalb weniger Minuten den Weg vom erbeuteten Rechner zum Domain-Admin-Konto (oder jedem beliebigen anderen Konto) aufzeigen.

Die ESAE-Lösung

ESAE ist keine einzelne Technik, kein Tool oder Service, der die genannten Probleme löst. Stattdessen ist ESAE eine Sammlung von Techniken, Tools und Arbeitsweisen, die es einem Angreifer erschweren, hoch privilegierte Konten zu erbeuten und damit Schaden anzurichten.

Kern der Lösung ist es, die IT-Services und -Systeme anhand des Schutzbedarfs in verschiedene Klassen (Englisch: Tiers) zu unterteilen. Und es werden die Admin-Konten für die Tiers mit hohem Schutzbedarf in einen eigenen Administrationsforest ausgelagert.

Die Tier-Unterteilungen

Wenn man sich die Microsoft-Dokumentation betrachtet, werden die Systeme wie folgt in die Tiers einsortiert:

    • Tier 0: Enterprise-Identity-Systeme wie Active Directory, PAM-Systeme, ADFS
    • Tier 1: Enterprise-Anwendungen wie E-Mail, Kollaboration- und sonstige Line-of-Business-Applications
    • Tier 2: Workstations

Wichtig: Jede Firma hat das eine oder andere höchst schützenswerte System, welches nicht in die Definition für Tier 0 fällt. Diese Systeme können und sollten natürlich genauso geschützt werden!

Per se haben die Admin-Konten jedoch keine stehenden Administrationsrechte. Diese müssen über eine Just-in-Time Privilege Access Management-Lösung (PAM) für einen definierten Zeitraum angefordert werden. Weiterhin kann die Umgebung nur mit gehärteten Privilege Access Workstations (PAWs) administriert werden.

Unser Kunde und seine Situation

Obwohl der Kunde in zahlreichen Ländern vertreten ist, arbeiteten die einzelnen Landesgesellschaften in der Vergangenheit weitestgehend autark. Es gab nur wenig gemeinsam genutzte Applikationen und kaum gemeinsame Projekte. Aufgrund einer neuen Firmenstrategie sollten die Landesgesellschaften näher zusammenrücken und gemeinsam das Geschäft weiter vorantreiben.

Mit dem Wunsch, gemeinsam Applikationen nutzen zu können, stellt sich unweigerlich die Frage, wie sich die Benutzer gegenüber der Applikation authentifizieren sollen. Aktuell hat jede Landesgesellschaft ihren eigenen Verzeichnisdienst (meistens Active Directory). 

Active Directory Trusts existieren nicht. Eine technische Lösung wäre, Trusts zwischen den Gesellschaften, die miteinander arbeiten wollen, einzurichten. Voraussetzung dafür ist, dass die Domänencontroller der verschiedenen Firmen miteinander kommunizieren können, was eine dauerhafte Netzwerkverbindung mit entsprechender Firewall-Konfiguration zwischen den Gesellschaften bedingt. 

Da Active Directory Forest Trusts nicht transitiv sind, würde die Lösung zu einer Vielzahl an Trusts führen, die verwaltet werden wollen:

Andererseits funktionieren Pass the Hash (PtH)- und Pass the Ticket (PtT)-Attacken auch über Trust-Grenzen hinweg. Um solch ein Konstrukt sicher betreiben zu können, müssten alle Landesgesellschaften die gleichen Sicherheitsmaßnahmen treffen und diese konsequent überwachen. Im Falle unseres Kunden ist das akuell nicht der Fall.

Eine andere Lösung stellt die Claims Based Authentication dar. Mit dem Aufkommen von Cloud-Applikationen wurde diese Art der Authentifizierung immer populärer und wichtiger. Dabei geht es darum, dass die Identitäten separat von der Applikation verwaltet werden. 

Im ersten Schritt geht der Application-Provider eine Vertrauensstellung mit einem Identity Provider (zum Beispiel Active Directory Federation Services) ein. Im zweiten Schritt identifiziert man den Benutzer anhand von verschiedenen Informationen (Claims). Diese Claims werden mit einem Security-Token transportiert.

Eine ausführlichere Beschreibung gibt es hier . Wie auf dem Bild zu sehen ist, kann das Verfahren lose gekoppelt über das Internet genutzt werden – muss es aber nicht.

Als aufmerksamer Leser werden Sie sich jetzt fragen, ob man damit nicht genau so viele (ADFS-)Trusts braucht wie im oben beschriebenen Szenario. Auf den ersten Blick: ja.

Allerdings können die Microsoft Active Directory Services so konfiguriert werden, dass eine zentrale Instanz quasi als Drehscheibe für die Authentifizierungs-Tokens agiert. Somit muss jede Applikation und jeder Identity Provider aka Landesgesellschaft genau einen Trust mit der zentralen Instanz eingehen.

Genau solch ein Konstrukt sollte in einer separaten Lokation neu aufgebaut und mittels ESAE administriert werden.

Die Anforderungen

Jetzt stellt sich natürlich die Frage: Welche Komponenten sind für die Gesamtlösung notwendig? Und nach welchen Prinzipien sollen diese aufgebaut und betrieben werden?

Nachfolgend haben wir versucht, das möglichst kompakt zusammenzufassen. Dabei beschränken wir uns auf die Besonderheiten einer ESAE-Umgebung und lassen einige Aspekte, die für den Betrieb jeder IT-Umgebung notwendig sind (bspw. detaillierte Backup- und Desaster-Recovery-Anforderungen), in der Aufzählung aus.

Schichtentrennung und Least Priviledge Administration

    • Physische und logische Trennung der Tier-0-Systeme von Tier 1 und Tier 2
    • Keine Nutzung von Tier-1- und Tier-2-Services, die ein Tier-0-System kompromittieren könnten (zum Beispiel Monitoring-Agent)
    • Zugriffsbeschränkung der Konten: Administration nur auf gleichem Tier, kein Log-in auf niedrigerem Tier

    • Principle of Least Priviledge mit Just-in-Time Administration

Härtung

    • Alle Systeme müssen nach Best-Practice gehärtet werden
    • Administrativen Zugriff nur über gehärtete Priviledge-Admin-Workstations mit Multi-Faktor-Authentifizierung
    • Verschlüsselung der Festplatten
    • Installation nur von vertrauenswürdigen Quellen (Hash-Kontrolle)
    • Lange Passwörter mit kurzen Laufzeiten, für Dienstkonten möglichst Group Managed Service Accounts

Prozesse und Betrieb

    • Reduktion der Tier-0-Administratoren auf ein Minimum
    • Gut ausgebildetes Personal mit positivem Führungszeugnis

Was ist daran neu?

Wer schon länger in der IT unterwegs ist, dem kommen die meisten Anforderungen sicherlich bekannt vor. Wie in der Einleitung dargestellt, handelt es sich bei einer ESAE-Umgebung nicht um eine bahnbrechend neue Technologie, sondern größtenteils um die konsequente Umsetzung verschiedener Techniken und Vorgehensweisen. 

Allerdings hat Microsoft für die Anforderung der Principle of Least Priviledge mit Just-in-Time Administration doch eine neue technische Antwort, die genau für die Abwehr von Credential Theft und PtH- / PtT-Attacken entwickelt wurde. Es handelt sich dabei um den bereits erwähnten Administrationsforest mit einer Priviledge Access Management-Lösung. 

Konkret realisiert wird das durch ein neues Active-Directory-Feature, dem Shadow Principal, in Verbindung mit dem neuen Microsoft Identity Manager (MIM)-Modul namens Priviledge Access Management (PAM). Wie das genau funktioniert, beschreiben wir in einem bald folgenden Artikel.

Die Architektur des Kundenprojektes

So sieht die konkrete Gesamt-Architektur des Kundenprojektes aus:

ESAE Kundenprojekt Architektur (Bild: TEAL)

Wie auf dem Diagramm zu sehen ist, besteht die Umgebung nur aus einer Handvoll Server. Auf den ersten Blick erscheint es viel Aufwand, eine an ESAE-orientierte Umgebung nur für den Betrieb von zwei ADFS-Servern aufzubauen. Dies ist dem Projektvorgehen des Kunden geschuldet, welches den phasenweisen Auf- und Ausbau der Umgebung vorsieht. 

Die dargestellte Architektur ist nur der erste Schritt. Einerseits sollen weitere kritische Dienste in der Umgebung aufgebaut (bspw. eine globale lPKI) werden. Zum anderen wird die Umgebung durch weitere Sicherheitsmaßnahmen erweitert, zum Beispiel mit der Anbindung an ein SIEM-System.

Hier noch eine Liste der Systeme inkl. einer kurzen Funktionsbeschreibung:

      • 2 Hyper-V-Server
        • Virtualisierungsplattform zum Hosten aller weiteren Systeme
      • Externe Firewall und VPN Gateway
        • Endpunkt für den Aufbau der Administrationsverbindungen
        • Äußere Firewall
      • Loadbalancer
        • Loadbalancing für die ADFS Server
      • Interne Firewall
        • Trennung DMZ und internes Netz
      • 2 Active Directory Domain-Controller („Green Forest”)
        • Produktionsforest mit den Diensten, die konsumiert werden sollen
      • 2 Active Directory Domain-Controller („Red Forest”)
        • Administrationsforest mit den Tier-0-Systemen
      • 2 Active Directory Federation-Server
        • Drehscheibe für Claims based Authentication
      • 1 MIM PAM-Server
        • Priviledged Access Management mit Just in Time Administration
      • 1 WSUS-Server
        • Installation von Microsoft-Updates
      • 1 SCOM-Server, ein SCOM-Gateway und ein SQL-Server für die SCOM-Datenbanken
        • Überwachung der Umgebung
      • 1 NXLog Server
        • Sammeln und weiterleiten von Event-Log-Einträge

Auf die Kernkomponenten werden wir in den kommenden Beiträgen näher eingehen.

Bilder: Pixabay, Microsoft, TEAL, FAQ-o-Matic

Ähnliche Beiträge:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.