Security-Strategie für Active Directory : Trennung von Systemen und Absicherung administrativer Konten

Von Inés Atug und André Windsch, Bonn

Nahezu jedes Unternehmensnetzwerk nutzt ein Active Directory (AD), um die Berechtigungen für Anwender, Administratoren, Anwendungen und Systeme zu verwalten – so ist es nicht verwunderlich, dass ADs auch ein beliebtes Ziel für Angreifer sind. Zudem konnten viele bekannte Sicherheitslücken der Software beispielsweise wegen der gewünschten Abwärtskompatibilität nicht behoben werden und so ist es die Aufgabe von Administratoren, ihr AD ausreichend zu sichern. Dazu sollte ein AD-Administrator möglichst über alle bekannten Sicherheitslücken und passende Gegenmaßnahmen informiert sein. Erschwerend kommt hinzu, dass ein Administrator nicht sicher sein kann, ob nicht bereits eine Kompromittierung stattgefunden hat.

AD-Schwachstellen

Das AD hat einige designspezifische Besonderheiten, die sich insbesondere aus Kompatibilitätsgründen technisch schwer bis nicht verhindern lassen. Zur Absicherung beziehungsweise Minimierung der bekannten dieser Schwachstellen, genauso wie zur Adressierung diverser Risiken für administrative Konten, Rollen und des AD, empfiehlt Microsoft die Etablierung einer „Enhanced Security Administrative Environment“ (ESAE), also einer administrativen Umgebung mit erhöhter Sicherheit.

Die meisten einfachen Angriffe basieren leider immer noch auf unsicheren Zugangsinformationen, worauf in diesem Artikel nicht eingegangen wird. Weitere Schwachstellen liegen in der AD-Architektur begründet. Das bekannteste Beispiel ist sicherlich „Pass the Hash“: Bei diesem Angriff kann sich ein Angreifer gegenüber einem AD mittels Benutzername und Passwort-Hashwert authentifizieren, wenn eine LM- oder NTLM-Authentifizierung ermöglicht wird. Der Passwort-Hashwert lässt sich beispielsweise aus dem Client des Benutzers auslesen und ein Angreifer kann sich dann mit dessen Berechtigungen im Netzwerk bewegen. Diese Schwachstelle ist zu unterbinden, indem man LM- und NTLM-Authentifizierung nicht mehr zulässt. Stattdessen wird dann Kerberos für die Benutzerauthentifizierung eingesetzt – dies fordert auch die Grundschutzanforderung APP.2.2.A9 „Schutz der Authentisierung beim Einsatz von AD“ (siehe www.bsi.bund.de/DE/Themen/ITGrundschutz/ITGrundschutzKompendium/bausteine/APP/APP_2_2_Active_Directory.html).

Kerberos-Attacken

Das Kerberos-Protokoll ist dafür zuständig, einen Client gegenüber dem Server zu identifizieren – es kann aber auch für eine Authentifizierung des Servers gegenüber Clients verwendet werden. Um den Dienst nutzen zu können, ist eine Anmeldung am Kerberos-Server notwendig, der sich typischerweise auf dem Domain-Controller (DC) befindet. Der Client fragt zunächst ein TicketGranting-Ticket (TGT) an, das er später verwendet, um weitere Tickets ohne erneute Authentifizierung zu erhalten. Typischerweise geschieht das bei der Benutzeranmeldung; es kann aber auch erst dann durch eine Authentifizierung beim DC erfolgen, wenn das TGT benötigt wird (siehe Abb. 1, Schritt 1). Der DomainController prüft die Anmeldeinformationen und erstellt ein TGT – dazu antwortet er dem Client mit dem verschlüsselten und signierten TGT, wobei die Inhalte des TGT nur durch den entsprechenden Kerberos-Dienst (KRBTGT) geöffnet und gelesen werden können (Abb. 1, Schritt 2).

Sobald der Client Zugriff auf einen Dienst benötigt, schickt er eine Anfrage zum Ticket-GrantingService (TGS) zusammen mit dem TGT an den Domain-Controller (Abb. 1, Schritt 3). Der DC öffnet das enthaltene TGT und kontrolliert die Prüfsumme des enthaltenen Privilege-Attribute-Certificates (PAC). Bei Erfolg wird auf Basis der Inhalte des TGT ein zugehöriges TGS-Ticket für den Client ausgestellt. Dabei wird das TGS-Ticket mit dem Schlüssel des angefragten Ziel-Dienstes verschlüsselt und dann an den Client gesendet (Abb. 1, Schritt 4). Mithilfe des TGS kann sich der Client nun beim entsprechenden Anwendungsserver anmelden (Abb. 1, Schritt 5).

Alle weiteren Schritte des Protokolls sind optional und umfassen die Authentifizierung des Anwendungsservers gegenüber dem Client (Abb. 1, Schritt 6) sowie eine Anfrage des Anwendungsservers an den DC auf Validierung des erhaltenen TGS durch Überprüfung des enthaltenen PAC (Abb. 1, Schritt 7 und 8).

Zwei der bekanntesten Angriffe sind die sogenannten Silver und Golden Tickets. Beide basieren auf einem gefälschten KerberosTicket, wobei es sich beim „Golden Ticket“ um ein gefälschtes TGTTicket und beim „Silver Ticket“ um ein gefälschtes TGS-Ticket handelt.

• Ein Silver Ticket ist ein gefälschtes TGS-Ticket eines Dienstes, zum Beispiel eines Anwendungsservers. Bei der Verwendung eines Silver Ticket erfolgt keine Kommunikation mit dem DC (siehe Abb. 2 – die Schritte 1 bis 4 des Kerberos-Protokolls werden ausgelassen), wodurch solche Angriffe – besonders mittels Monitoring – schwer zu entdecken sind. Für die Fälschung eines TGSTickets benötigt ein Angreifer den Passwort-Hash des Ziel-Dienstes. Je nachdem, für welche Dienste ein Angreifer Silver Tickets erstellen kann, besteht die Möglichkeit mithilfe mehrerer Silver Tickets ein Golden Ticket zu erlangen.
• Ein Golden Ticket ist ein gefälschtes TGT und gilt damit nicht speziell für einen Anwendungsserver (wie ein Silver Ticket), sondern kann dazu dienen, um TGS für alle an den Domain-Controller angebundenen Anwendungsserver zu erstellen. Je nachdem, welche Trust-Beziehungen zu anderen Domänen bestehen, können die gewonnen Informationen auch dort verwendet werden. Wie beim Silver Ticket benötigt der Angreifer hierzu den entsprechenden Passwort-Hash – in diesem Fall den des Kerberos-Diensts KRBTGT (Abb. 3, Schritt 3).

Attacken gegen den Domain-Controller

Während bei Silver- und Golden-Ticket das Kerberos-Verfahren im AD angegriffen wird, ist bei den DCShadow- und DCSyncAngriffen der Domain-Controller das Ziel. Wenn ein Angreifer die Rechte eines Domain-Benutzers, der zur Admin-Gruppe gehört, erlangt hat und über eine Konsole mit Systemrechten verfügt, kann er einen DC mittels DCShadow simulieren und darüber die Informationen aus einer Domain-Controller-Replikation erhalten. Es ist auch möglich Änderungen darüber an andere DCs replizieren zu lassen.

DCSync ermöglicht es einem Angreifer, sich die Passwort-Hashes des DC zu kopieren, wenn die Rechte „DS-Replication-Get-Changes“ und „Replicating Directory Changes All“ sowie in manchen Umgebungen „Replicating Directory Changes In Filtered Set“ gesetzt sind. Die Mitglieder der Administratoren-Gruppe und der DC-Gruppe verfügen in der Regel standardmäßig über diese Rechte. Hat ein Angreifer (z. B. durch einen anderen Angriff) die Möglichkeit, entsprechende Rechte zu vergeben, muss der benutzte Account jedoch kein Mitglied einer privilegierten Gruppe sein.

Attacken gegen Passwörter

Ein klassischer PasswortBrute-Force-Angriff wird in verschieden Variationen zum Brechen von offline verfügbaren Passwort-Hashes verwendet. Für aktive Systeme nutzen Angreifer mittlerweile vermehrt das sogenannte Passwort-Spraying, bei dem sie nicht versuchen, wenige/spezifische Benutzerkonten zu brechen, sondern vielmehr wenige, häufig verwendete Passwörter bei einer großen Zahl von Benutzernamen testen, um so typische Gegenmaßnahmen zu umgehen.

Abwehr durch ESAE

Microsofts Antwort auf die genannten Schwachstellen im AD ist das Enhanced-Security-Administrative-Environment-(ESAE)-Konzept (http:// aka.ms/esae). Durch seine Umsetzung lässt sich das Ausnutzen der genannten Schwachstellen zwar nicht vollständig verhindern, aber die Wahrscheinlichkeit deutlich senken, dass ein Angreifer Zugriff auf alle für ihn notwendigen Informationen erhält. Viele Angriffe benötigen lokale Administrationsrechte und frei zugängliche Werkzeuge wie beispielsweise Mimikatz (https://github.com/gentilkiwi/mimikatz). Lokale Adminrechte können Angreifer beispielsweise mittels Phishing erbeuten oder Hashwerte lokal auslesen.

AD wurde mit Windows 2000 eingeführt und über die Jahre nahmen die Schwachstellen und Sicherheitslücken zu – diese wurden teilweise behoben, teilweise auch nicht. Vor allem dann, wenn dadurch keine Abwärtskompatibilität mehr gegeben wäre, wurden Schwachstellen nicht oder nicht vollständig korrigiert. Daher hat Microsoft das ESAE-Konzept entwickelt, um das Ausnutzen bekannter Schwachstellen zu erschweren. Aber Achtung: Das ESAE-Konzept hilft nicht, wenn bereits eine Kompromittierung stattgefunden hat und bislang unentdeckt geblieben ist!

ESAE ist weder eine einzelne Technik noch ein Werkzeug – es gibt auch keine fertigen Gruppenrichtlinien (GPOs), die man einfach einspielen könnte. Bei dem ESAEKonzept handelt es sich um einen Design-Vorschlag für AD, der auch die Absicherung der administrativen Clients umfasst und damit einen ganzheitlichen Ansatz zur Absicherung vertritt. Im Mittelpunkt steht ein Schichten-Modell (engl. Tiers), das die Systeme einer Umgebung unterschiedlichen Schichten zuordnet. Dabei werden die besonders gefährdeten, hoch privilegierten Administrationskonten (z. B. Domain-Admin) in einen separaten Forest – auch „Red Forest“ genannt – ausgelagert. Die im Folgenden beschriebenen Design-Prinzipien bilden die Basis für dieses Vorgehen.

Principle of Least Privilege

Personen und Dienste sollten nur diejenigen Berechtigungen haben, die sie zur Ausführung ihrer Tätigkeit wirklich benötigen. In einer gröberen Form wird dieses Prinzip mittlerweile in vielen Unternehmen in Form von rollenbasierter Zugriffskontrolle (RBAC) umgesetzt, indem man Mitarbeiter speziellen Rollen und damit Berechtigungen permanent zuordnet, die sie zur Ausführung ihrer Tätigkeit irgendwann einmal benötigen (vergleiche etwa ORP.1.A5 „Vergabe von Berechtigungen“ und ORP.4.A2 „Regelung für Einrichtung, Änderung und Entzug von Berechtigungen“ im IT-Grundschutz). Allerdings werden einige der auf diese Weise zugeordneten Rechte nur selten benötigt, wodurch sich das „Least“ relativiert und erhöhte Risiken durch die Kompromittierung entsprechender Benutzerkonten bestehen.

Im Rahmen von ESAE ist daher vorgesehen, dass man Rollen und Rechte nur für die tatsächlich notwendige Dauer zuweist. Um den hierdurch entstehenden Aufwand zu reduzieren, gibt es verschiedene Möglichkeiten. Zunächst kann diese Maßnahme an das Risiko für die jeweiligen Rollen gekoppelt werden: Dabei sollten mindestens alle Tier0-Rollen und -Benutzerkonten (siehe unten) enthalten sein – außerdem diejenigen Rollen und Accounts aus Tier 1, die aus unternehmerischer/behördlicher Sicht zu kritischen Prozessen gehören. Zudem kann man den Fokus auf Rollen beziehungsweise Berechtigungen legen, die nicht mehrfach täglich benötigt werden. Je nach Umgebung bietet sich zudem eine technische Lösung zur Beantragung und (teil-)automatisierten Freigabe der Rechte an, wobei die Beantragung einschließlich der Begründung protokolliert und für kritischere Rechte auch überwacht werden sollte.

Einige der spezifischen Anforderungen zum Prinzip der geringsten Privilegien bezieht sich auf die drei kritischsten Rollen im AD: Domain-, Enterprise- und Schema-Administratoren. Diese haben effektiv die volle Kontrolle über das AD und damit auch seine Umgebung – eine Eskalation der Rechte von einer der drei Rollen zu den jeweils anderen ist ebenfalls möglich. Diese Rollen sollten nur dann zum Einsatz kommen, wenn sie tatsächlich als Ganzes notwendig sind, was typischerweise in folgenden Fällen gegeben ist:

• Initiale Erstellung der Domäne (auch hier können und sollten nach den ersten Schritten Rollen mit weniger Rechten übernehmen)
• Initiale Erstellung sowie Änderungen am Schema
• domainweite Änderungen
• Unternehmens-/Behördenweite Änderungen

Für alle anderen Änderungen sind typischerweise andere Rollen mit spezifischen, einzelnen Rechten ausreichend.

Es wird im Rahmen von ESAE zwar nicht gefordert, hat sich aber als Best Practice etabliert, dass diese Rollen höchstens 4 Mitglieder enthalten – aus Redundanz-Gründen und für den Fall einer Kompromittierung eines der Mitglieder sollte aber jede Rolle mindestens 2 Mitglieder bekommen. Die Passwörter der jeweiligen Accounts sollten nach jeder Verwendung geändert werden, (soweit möglich) niemandem bekannt und an einem sicheren Ort (z. B. physischer Safe) hinterlegt sein. Zudem sollte jede Nutzung der Accounts nicht nur geloggt, sondern auch im Rahmen des Monitorings überwacht werden.
Abschließend ist den Autoren dieses Beitrags wichtig, explizit auf technische Konten (Dienstkonten) hinzuweisen, da diese im Rahmen des Prinzips der geringsten Privilegien oder beim RBAC gerne übersehen werden. Damit lässt sich jedoch gegebenenfalls das komplette Sicherheitsdesign umgehen!

Assume Breach Principle

Man sollte immer von einer bereits bestehenden Kompromittierung ausgehen, die nur noch nicht bemerkt wurde. Dieses Prinzip wird durch diverse Statistiken legitimiert, wobei es bei der jeweiligen Dauer bis zur Entdeckung (z. B. bei Datenlecks in DE im Mittel knapp ein halbes Jahr) zu berücksichtigen gilt, dass nicht alle Vorfälle, die entdeckt werden auch gemeldet werden, auf der anderen Seite aber auch Vorfälle seit Jahren laufen können, die noch immer nicht entdeckt und daher nicht erfasst wurden.

Aus dem Assume-Breach-Prinzip ergeben sich zwei wichtige Konsequenzen: Die erste ist das nachfolgend erörterte Clean-Source-Prinzip. Die zweite ist die Erkenntnis, dass es unmöglich ist, alle Kompromittierungen zu verhindern und man somit auch der Erkennung und Behandlung von Vorfällen (Baustein DER im ITGS) eine wichtige Rolle einräumen muss. Im konkreten Fall ist es wichtig, die AD-Umgebung zu überwachen und zu protokollieren – vor allem die Aktivitäten administrativer Konten.

Clean Source Principle

Das Prinzip der sauberen (in diesem Kontext: sicheren) Quelle Active Directory besagt, dass die Sicherheit von Beginn an hergestellt sein muss, da sich ansonsten eine potenzielle Kompromittierung von Beginn bis zum Ende durchziehen kann. Aus diesem Prinzip ergeben sich im Rahmen von ESAE viele wichtige Punkte für die Sicherheit der Umgebung – die wichtigsten lauten:

• Bezug von Software, externem Code, Hardware, Updates und Informationen aus sicheren Quellen: Dazu sollte ein angemessener Freigabe-Prozess etabliert sein und Produkte sollten direkt vom Hersteller kommen. Werden Images an einem eigenen Speicherplatz (Repository) vorgehalten, sollte man sicherstellen, dass nur freigegebene Software darin enthalten und keine unbemerkte Änderung möglich ist. In vielen Fällen können hierzu Signaturen des Herstellers zur Integrität/Authentizitäts-Prüfung dienen.
• Administratoren sollten dedizierte Arbeitsstationen/Clients verwenden (siehe APP.2.2.A14 „Verwendung dedizierter privilegierter Administrationssysteme“ und Abschnitt PAW weiter unten): Diese dürfen nur für administrative Tätigkeiten genutzt werden und sollten so gehärtet sein, dass sie nur Software und Dienste enthalten, die für die Administration notwendig sind. Als weitere Absicherung kann man den Zugriff von diesem Gerät exklusiv auf diejenigen Systeme beschränken, die von diesem Client aus administriert werden. Alle anderen Tätigkeiten, die nicht direkt in Bezug auf diese Administration stehen (z. B. E-Mails lesen und Recherchen im Internet), müssen von einem anderen Client aus erfolgen, wodurch man für Admin-Clients die häufigsten Punkte zur Kompromittierung eliminiert.
• Im Rahmen der Vorfallsbehandlung sollte man immer auf den letzten garantiert sauberen/sicheren Stand zurückgreifen, anstatt den aktuellen Stand zu „säubern“: Denn bei einer Bereinigung können leicht Hintertüren sowie Möglichkeiten zur Persistierung des Angreifers übersehen werden. Um eine weitere Kompromittierung sicher auszuschließen, wäre es am besten das System komplett neu aufzusetzen. Da hierbei je nach System aber viele Daten verloren gehen können (Persistenz über die Backups), sollte man an dieser Stelle eine spezifische Abwägung treffen.
• Alle Sicherheitsanforderungen müssen von Beginn an beim Aufsetzen neuer Systeme, Anwendungen oder Änderungen des Designs oder Schemas eingehalten werden, da sonst eine Kompromittierung vor der Etablierung von Sicherheitsfunktionen erfolgen kann.
• Verschiedene Systeme, Anwendungen und Rollen lassen sich unterschiedlich gut absichern und sind verschiedenen Gefährdungen ausgesetzt – daher sollten sie als unterschiedlich sicher angesehen werden. Dies ist einer der Kernpunkte von ESAE und führt zur Unterteilung der Umgebung in verschiedene, logische Schichten, die diese verschiedenen „Vertrauensbereiche“ oder „Sicherheitsbereiche“ abbilden. Zwischen diesen Bereichen werden Regelungen für Zugriffe und Kontrolle/Steuerung eingeführt, welche die Einhaltung des Clean-Source-Prinzips sicherstellen sollen.

ESAE-Tier-Design

Das in Schichten (engl.: Tiers) aufgeteilte Design soll die Wahrscheinlichkeit der Kompromittierung kritischer Benutzerkonten sowie der Eskalation auf höhere Berechtigungen reduzieren. Dazu unterteilt ESAE die Umgebung in drei logische, administrative Ebenen: Tier 0, Tier 1 und Tier 2. Hinzu kommt die Empfehlung eines dedizierten Admin-Forests (ESAE Admin Forest oder Red Forest), der die kritischsten Rollen und Systeme in einen separaten und restriktiver abgesicherten Forest auslagert und im Grundschutz Kompendium in ähnlicher Form als Hochschutz-Anforderung APP.2.2.A15 „Trennung von Administrations- und Produktionsumgebung“ aufgenommen wurde. Implizit gibt es in der Gesamtumgebung noch eine weitere Ebene für Benutzer; da das ESAE-Design zur Absicherung administrativer Zugriffe ausgelegt ist, wird diese jedoch nicht explizit erwähnt.

Die logischen ESAE-Ebenen sind unabhängig von physischen Zonen des Netzwerks und lassen sich nicht (oder zumindest kaum) in physischer Form abbilden. Die drei logischen Ebenen, die dann auch im AD auftauchen, sind wie folgt aufgebaut (vgl. Abb. 4 auf S. 26):

• Tier 0 enthält Benutzerkonten, Rollen und Systeme, die direkt oder indirekt das AD kontrollieren können und damit am kritischsten für die Gesamtsicherheit sind. Diese Rollen und Systeme lassen sich sehr restriktiv absichern, sodass sie wenige, potenzielle Angriffspunkte bieten. Daher hat diese Ebene aus Sicherheitssicht den höchsten Vertrauenslevel. Typische Systeme, Anwendungen und Rollen für Tier 0 sind der Domain-Controller (DC), das AD und die zugehörige Datenbank, Domain-, Enterprise- und Schema-Administratoren, technische Lösungen zur Rechteverwaltung sowie alle Systeme oder Anwendungen zum Schutz, zur Updateverwaltung oder zum Backup von anderen Tier0-Systemen.
• Tier 1 enthält Benutzerkonten, Rollen und Systeme, die direkt oder indirekt Ressourcen des Unternehmens kontrollieren können. Sie sind damit für die Gesamtumgebung weniger kritisch, spielen aber typischerweise aus unternehmerischer Sicht eine wichtige Rolle. Zu Tier 1 gehören beispielsweise Web-, File- und Virtualisierungs-Server, Datenbanken sowie deren jeweilige Administratoren. Zu dieser Ebene gehören außerdem die Systeme und Rollen, die zum Update, zur Absicherung oder für Backups von Tier 1 dienen.
• Tier 2 enthält Benutzerkonten, Rollen und Systeme, die zur Verwaltung der Client-Umgebung gehören – beispielsweise Clients, Drucker oder Telefonanlagen. Tier 2 ist die Schicht mit dem niedrigsten Vertrauenslevel, da eine Kompromittierung hier beispielsweise über E-Mail oder Internet am wahrscheinlichsten ist und eine restriktive Absicherung die normale Arbeitsweise der meisten Nutzer zu stark einschränken würde.

  Die Zuordnung von Benutzerkonten, Rollen und Systemen soll zu genau einer Schicht erfolgen. Wäre eine Zuordnung zu mehreren Schichten möglich, muss geprüft werden, bei welcher Zuordnung die Einhaltung der Zugriffs- sowie Kontroll-Regelungen (siehe unten) möglich bleibt. Ist die Einhaltung der Regelungen nicht möglich, müssen separate Rollen, Accounts oder Systeme verwendet werden, die den jeweiligen Ebenen zugeordnet sind und regelkonform zu betreiben sind. Vor allem bei administrativen Accounts muss man darauf achten, sie nicht Rollen aus verschiedenen Ebenen zuzuordnen.

  Zwischen den Ebenen gelten spezifische Regeln für den Zugriff und die Kontrolle/Steuerung. Diese müssen auch durch Servicekonten eingehalten werden, da ansonsten das komplette Design unterminiert werden kann.

Kontroll-/Steuerungs-Regelung

Die Kontroll-/Steuerungs-Regelung besagt, dass kein Mitglied einer Schicht kontrollierende oder steuernde Funktionen für eine Schicht mit einem höheren Vertrauenslevel übernehmen darf (rechte Seite in Abb. 4). Eine Steuerung der eigenen Schicht ist generell gestattet – die Steuerung einer niedrigeren Schicht ist gestattet, sofern sie zur Aufgabenerfüllung notwendig ist. Als Beispiel kann hier das AD selbst (Tier 0) angeführt werden, das bestimmungsgemäß auch Server und Clients der anderen Schichten steuert.

Diese Regel dient vor allem dazu, die Eskalierung von Rechten von Systemen oder Rollen zu erschweren, die leicht durch einen Angreifer übernommen werden können – beispielsweise von Client-Administratoren hin zu kritischeren Systemen wie Server oder Domain-Controller. Auch innerhalb der im Rahmen dieser Regelung erlaubten steuernden Zugriffe sollte man aber trotzdem weiterhin das Prinzip der geringsten Privilegien umsetzen!

Zugriffs-/Anmelde-Regelung

Die Regelung für den Zugriff und die Anmeldung (linke Seite in Abb. 4) ist genau entgegengesetzt zur Regelung für die Steuerung und wirkt auf den ersten Blick kontraintuitiv: Sie besagt, dass kein Mitglied einer Ebene sich auf Systemen mit einem niedrigeren Vertrauenslevel anmelden darf. Eine Anmeldung auf der eigenen oder auf höheren Ebenen ist gestattet, sofern sie zur Aufgabenerfüllung notwendig ist.

Hintergrund dieser Regelung ist, dass viele Methoden zur Anmeldung Informationen zu Benutzerkonten auf dem jeweiligen System hinterlassen. Durch die Anmeldung auf einem potenziell unsicheren System wird ein Account daher den höheren Risiken der niedrigeren Ebene ausgesetzt.

Separater Forest

In der Hochschutz-Anforderung APP.2.2.A15 „Trennung von Administrations- und Produktionsumgebung“ im Grundschutz Kompendium wird der Einsatz eines eigenen Forest für Domain-Controller und besonders kritische Systeme empfohlen (Red Forest). Dieser ist mit einem One-Way-Trust mit dem Forest verbunden, der im Tier 0 verortet ist. Im Red Forest werden die besonders kritischen Systeme und Rollen verwaltet – dabei sind die gleichen Prinzipien wie zuvor geschildert umzusetzen.

Um so wenig Angriffsfläche zu bieten wie möglich, wird um den Red Forest eine kleine IT-Umgebung mit all den Dingen aufgebaut, die es sonst auch gibt: AD, DNS, Firewall, WSUS, Datensicherung und so weiter. Im Fall von Antimalwaresoftware oder anderer Anwendungen, die oft „nach Hause telefonieren“ müssen, sollte man in einer Red-Forest-Umgebung überlegen, ob diese dadurch einen Sicherheitsmehrwert verwirklichen oder eher die Angriffsfläche erhöhen.

Privileged-Access-Workstation (PAW)</h3Y Bei einer Privileged-AccessWorkstation (PAW) handelt es sich um einen dedizierten, stark gehärteten Client für administrative Tätigkeiten. Die PAW kann verwendet werden, um die Anforderung aus APP.2.2.A14 „Verwendung dedizierter privilegierter Administrationssysteme“ zu erfüllen. Die Härtung beginnt bereits mit der Absicherung von Risiken aus der Lieferkette von Hard- und Software. So ist etwa jeweils vor Installation von Betriebssystem und Software die Authentizität zu überprüfen – doch auch eine mögliche Manipulation auf dem Lieferweg der Hardware sollte bedacht und mittels Risikoanalyse bewertet werden. Für eine PAW sollte man alle üblichen Härtungsmaßnahmen nutzen: Deaktivierung/Deinstallation nicht benötigter Dienste und Anwendungen, Verzicht auf lokale Administratoren, Installation von Antimalwaresoftware sowie eine restriktiv konfigurierte Firewall (s. a. http://aka.ms/cyberpaw). Darüber hinaus ist die PAW vom Internet und damit auch von E-Mails zu isolieren, da die meisten Angriffe über diese Kanäle erfolgen. Auch das Risiko indirekter Angriffe über kompromittierte Systeme im Netzwerk sollte begrenzt werden – hierzu ist der Zugriff im Netzwerk auf die Systeme, welche die PAW notwendigerweise erreichen muss, zu beschränken. Gegen physische Angriffe sollte die PAW in einem abgeschlossenen Bereich aufgestellt und administriert werden, zu dem nur dafür benötigte Personen Zutritt haben. Weiterhin sind auch Sicherheitsmaßnahmen zum Schutz bei Verlust oder Diebstahl zu treffen. Um eine angemessene Rollentrennung zu erreichen, darf ein Administrator nicht über administrative Berechtigungen für seine PAW verfügen. Administratoren sind dabei sowohl Benutzer mit administrativen Rechten als auch „normale“ Anwender: Auch Administratoren benötigen ja eine Möglichkeit nicht-administrative Arbeiten (z. B. Recherchen im Internet oder den Abruf von E-Mails) durchzuführen. Dazu gibt es verschiedene Ansätze, um eine PAW zu realisieren. Hierbei ist wichtig, dass die Clean-Source- und Assume-Breach-Prinzipien nicht verletzt werden. Die Verwendung eines dedizierten, eigenständigen Clients, der nur für administrative Zwecke verwendet wird, ist die präferierte Umsetzung des PAW-Konzepts. Auf diesem Client sind dann ausschließlich die administrativen Werkzeuge des Administrators installiert, die er für die Ausübung seiner Tätigkeit benötigt. Alternativ kann der dedizierten PAW eine virtuelle Maschine für die Benutzertätigkeiten hinzugefügt oder über einen virtuellen Desktop auf einen „normalen“ Client zugegriffen werden. Dabei ist wichtig zu beachten, dass dieses Vorgehen „andersherum“ – als VM-Zugriff auf die Admin-Workstation von einer Benutzer-Workstation – nicht sicher und daher nicht zu empfehlen ist! Es ist für die Sicherheit der gesamten ESAE-Umgebung wichtig, diese mittels einer PAW aufzusetzen. Auch die Login-Restriktionen müssen beachtet werden: So soll eine PAW, die für Tier 0 verwendet wurde, nicht in Tier 1 oder Tier 2 eingesetzt werden. Wie bereits bei Clients für normale Nutzer, könnten die PAWs für niedrigere Tiers als VM innerhalb einer PAW eines höheren Tiers realisiert werden. Dies führt dazu, dass man mit einer initialen PAW startet, die nicht ans AD angebunden, jedoch stark gehärtet ist. Nach dem Aufsetzen des AD und anderer notwendiger Systeme (z. B. Netzkomponenten) werden dann die geplanten PAWs installiert und die initiale PAW vernichtet beziehungsweise sicher gelöscht und neu aufgesetzt.

Privileged-Access-Management (PAM)

Über ein Privileged-Access-Management (PAM) lassen sich weitere für einen Angreifer erschwerende Maßnahmen umsetzen. So können administrative Rollen, die für einzelne administrative Tätigkeiten benötigt werden, auch nur zeitweise an Administratoren vergeben werden. Dabei kann man festlegen, welche Berechtigungen automatisch freigegeben werden dürfen und welche Berechtigungen eines Vier-Augen-Prinzips bedürfen.

Vor allem für den Red Forest sollte man jedoch gut überlegen, ihn mit einem PAM auszustatten, da auch ein PAM (wie das AD) Begehrlichkeiten von Angreifern weckt und daher eher ein zusätzliches Ziel darstellt als einen zusätzlichen Sicherheitsnutzen mitbringt.

Risiken des ESAE

Wenn man beim Design und der Konzeption des ESAE nicht achtgibt, kann man durch Konfigurationsfehler oder eine unvollständige Umsetzung des ESAE-Konzepts Wege für Angreifer schaffen, um an höhere administrative Berechtigungen zu gelangen. So gibt es sogenannte Shadow-Admin-Konten, die erhöhte administrative Berechtigungen aufweisen, jedoch in der Regel nicht zu den administrativen Konten gezählt werden.

Zudem gibt es Berechtigungen, die standardmäßig in Anwendungen vergeben sind und dazu genutzt werden können, um Informationen aus dem AD zu erhalten – dazu gehören beispielsweise „Replicating Directory Changes“ und „Replicating Directory Changes All“. Wenn beide Berechtigungen vergeben sind, kann ein Angreifer eine Synchronisierung des Domain-Controllers anstoßen und so die Passwort-Hashwerte der Benutzer erhalten. Diese Einstellung ist beispielsweise in SharePoint für das Servicekonto „User Profile Synchronization“ (UPS) enthalten.

In Tier 0 eines ESAE sind, wie beschrieben, alle Systeme und Anwendungen zu verorten, die für den Betrieb und das Management des Tier 0 notwendig sind. Dabei kann es passieren, dass einzelne Anwendungen oder Systeme nicht bedacht werden: Wenn beispielsweise der Domain-Controller virtualisiert und die verwendete Virtualisierungsplattform nicht in Tier 0, sondern in Tier 1 betrieben wird, kann ein Angreifer mit administrativem Zugriff auf der Virtualisierungsplattform über diesen Zugang das VMDK-Image des Domain-Controllers erhalten. Das gleiche gilt für die Datensicherung: Läuft sie in Tier 1 und sichert Tier 0, kann ein Angreifer mit Zugriff auf diese Datensicherung Zugriff auf die Daten des Domain-Controllers erhalten.

Fazit

Im Active Directory (AD) gibt es etliche Schwachstellen – aufgrund der Ausgestaltung mancher Angriffe sind diese schwer oder gar nicht über ein Sicherheitsmonitoring zu erkennen. Dies kann dazu führen, dass Kompromittierungen des AD lange unentdeckt bleiben.

Als mögliche Lösung hat Microsoft zur Absicherung des AD das Konzept des „Enhanced Security Administrative Environment“ (ESAE) vorgestellt, zu dessen grundlegenden Sicherheitsgedanken das Clean-Source- und das Assume-Breach-Prinzip zählen. Das ESAE-Konzept setzt zudem über die Verwendung von gesondert abgesicherten Workstations (PAWs) auf die Trennung von privilegierter und nicht-privilegierter Arbeit. Bei Bedarf kann man durch einen Red Forest zur separaten Absicherung besonders schützenswerter Rollen sowie eine PAM-Lösung den Schutz erhöhen.

Allerdings ist die Umsetzung des ESAE-Konzepts sehr aufwendig und bedarf eines AD-Spezialisten-Teams, damit keine Schwachstellen in der Umsetzung bestehen. Zudem sollte man seine Administratoren frühzeitig in die Entwicklungen einbeziehen, da sich durch das ESAE-Konzept gegebenenfalls ihre Arbeitsweise ändert und manche Aufgaben auch länger dauern können. Es ist jedoch wichtig, dass das Sicherheitskonzept bei den Administratoren nicht auf Widerstand trifft, da diese anderenfalls Workarounds schaffen könnten, die das ESAE-Konzept schwächen oder unterminieren.

Abschließend sei noch erwähnt, dass das Azure AD zwar vom Namen her AD enthält, aber nicht auf dem (klassischen) Active Directory basiert – somit sind AD-spezifische Schwachstellen nicht auf Azure AD anwendbar.

Inés Atug ist Senior Expert, Security Consulting, André Windsch Security Consultant bei der HiSolutions AG.