Architekturschutz
Die Grundlagen von Active Directory kennst du bereits aus Modul B4. Du weißt also, wie Benutzer, Gruppen und Berechtigungen zusammenspielen. Jetzt wechseln wir die Perspektive: Wir betrachten Active Directory nicht als Verzeichnisdienst, sondern als eines der wichtigsten Sicherheitsziele innerhalb eines Unternehmens. Denn wer weitreichende Kontrolle über Active Directory erlangt, kann häufig auch weitreichende Kontrolle über Benutzerkonten, Systeme und Zugriffsrechte der gesamten AD-Umgebung erlangen.
„Dann reicht es also nicht, einfach die Domain Controller gut zu konfigurieren?“
„Genau. Sicherheit beginnt schon bei der Architektur. Wir müssen überlegen, wo die Domain Controller stehen, wer sie administrieren darf und von welchen Systemen aus diese Administration überhaupt möglich ist.“
Domain Controller: das Herzstück des Active Directory
Domain Controller (DCs) stellen die zentralen Funktionen von Active Directory Domain Services (AD DS) bereit. Sie authentifizieren Benutzer und Computer, speichern und replizieren Verzeichnisinformationen und sind an der Bereitstellung von Gruppenrichtlinien beteiligt.
Zu den besonders sensiblen Daten gehört die AD-Datenbank NTDS.dit. Sie enthält unter anderem Informationen über Benutzer- und Computerkonten sowie die für die Authentifizierung benötigten Passwort-Hashes. Damit wird schnell klar, warum Domain Controller für Angreifer besonders attraktive Ziele sind.
„Wenn ein Angreifer einen Domain Controller vollständig kompromittiert – hat er dann automatisch alle Benutzerpasswörter?“
„Nicht die Klartextpasswörter. Aber er kann unter Umständen auf die in Active Directory gespeicherten Passwort-Hashes und andere hochsensible Verzeichnisdaten zugreifen. Vor allem kann die Kontrolle über einen Domain Controller sehr weitreichende Möglichkeiten eröffnen, Identitäten und Berechtigungen innerhalb der Domain zu manipulieren.“
💡 Merke: Ein Domain Controller gehört zur höchsten Vertrauensebene einer klassischen AD-Umgebung. Seine Kompromittierung kann die Vertrauenswürdigkeit der gesamten Domain infrage stellen.
Die Angriffsfläche der Domain Controller klein halten
Aus dieser besonderen Rolle folgt ein wichtiges Architekturprinzip:
Auf Domain Controllern sollte nur das betrieben werden, was für ihre Aufgabe erforderlich ist.
Ein Domain Controller ist deshalb kein geeigneter Platz für einen Webserver, Fileserver oder beliebige Geschäftsanwendungen. Zusätzliche Software und Dienste schaffen zusätzliche Angriffsmöglichkeiten.
Das gilt auch für Verwaltungs- und Sicherheitssoftware: Wenn beispielsweise eine Management-, Backup- oder Monitoring-Lösung weitreichende Kontrolle über Domain Controller besitzt, muss auch diese Lösung entsprechend stark geschützt werden.
Physischer Schutz
Auch physischer Zugriff spielt eine Rolle. Ein Angreifer, der Zugriff auf einen Server oder dessen Datenträger erhält, könnte versuchen, die darauf gespeicherten Daten offline auszulesen oder das System zu manipulieren.
Domain Controller gehören deshalb in physisch geschützte Serverbereiche. Bei physischen Servern empfiehlt Microsoft außerdem TPM und BitLocker zum Schutz der Datenträger.
Bei virtualisierten Domain Controllern musst du zusätzlich bedenken: Wer die zugrunde liegende Virtualisierungsplattform administrativ kontrolliert, kann unter Umständen auch den Domain Controller beeinflussen. Der Schutz endet also nicht an der virtuellen Maschine.
Netzwerkzugriffe begrenzen
Auch ein Domain Controller benötigt Netzwerkkommunikation – beispielsweise für Kerberos, LDAP, DNS, SMB oder RPC. Daraus folgt aber nicht, dass er uneingeschränkt mit allen Netzen kommunizieren sollte.
Firewall-Regeln sollten deshalb nur die tatsächlich erforderlichen Kommunikationsbeziehungen zulassen.
Insbesondere normale Internetnutzung, Web-Browsing oder E-Mail haben auf einem Domain Controller nichts verloren. Ausgehende Internetkommunikation sollte grundsätzlich stark eingeschränkt werden. Benötigte Verbindungen – beispielsweise für bestimmte Sicherheits- oder Managementdienste – werden gezielt freigegeben.
Administration isolieren
Ein weiterer entscheidender Punkt betrifft nicht den Domain Controller selbst, sondern den Rechner, von dem aus er administriert wird.
Stell dir vor, Tom arbeitet den ganzen Tag auf seinem normalen Arbeitsplatzrechner. Er öffnet E-Mails, besucht Webseiten und testet Programme. Anschließend meldet er sich von genau diesem Rechner mit einem Domain-Admin-Konto an der AD-Infrastruktur an.
Ein normaler Arbeitsplatz ist einer wesentlich größeren Angriffsfläche ausgesetzt. Ist er bereits kompromittiert, können privilegierte Anmeldeinformationen oder administrative Sitzungen zum Ziel des Angreifers werden. Damit wird der kompromittierte Arbeitsplatz zum möglichen Sprungbrett in die Identitätsinfrastruktur.
Deshalb sollten hochprivilegierte administrative Tätigkeiten von speziell abgesicherten Administrationssystemen aus erfolgen. Microsoft bezeichnet solche Systeme als Privileged Access Workstations (PAWs).
Eine PAW wird nicht für normale Büroarbeit, E-Mail oder allgemeines Web-Browsing verwendet. Sie bildet einen vertrauenswürdigen Ausgangspunkt für administrative Zugriffe.
Nicht jedes System darf jedem System vertrauen
Bislang haben wir einen einzelnen Domain Controller betrachtet. Active Directory kann jedoch aus mehreren Domains bestehen. Mehrere AD-Domains können zu einem Forest gehören. Ein Forest teilt unter anderem ein gemeinsames Schema und eine gemeinsame Konfiguration. Zwischen den Domains eines Forests bestehen automatisch Vertrauensbeziehungen. Beispielsweise könnte eine größere Organisation mehrere Domains besitzen:
Mehrere Domains können organisatorische oder administrative Gründe haben. Sie stellen innerhalb desselben Forests jedoch keine vollständig voneinander unabhängigen Sicherheitsgrenzen dar. Das ist ein wichtiger Punkt:
💡 Der Forest ist die maßgebliche Sicherheitsgrenze einer klassischen Active-Directory-Umgebung.
Wer Kontrolle über besonders privilegierte Komponenten eines Forests erlangt, kann unter bestimmten Voraussetzungen auch andere Domains innerhalb dieses Forests beeinflussen. Wenn Bereiche tatsächlich unterschiedliche Vertrauensanforderungen besitzen und voneinander isoliert werden müssen, kann deshalb die Trennung in unterschiedliche Forests erforderlich sein.
Szenario: Die NovaHealth Solutions AG übernimmt die MediLab GmbH. Die IT muss entscheiden, ob deren Active Directory in den bestehenden NovaHealth-Forest integriert oder als eigener Forest weitergeführt wird. Folgende Alternativen stehen zur Auswahl:
Die NovaHealth möchte die Labor-IT möglichst stark von der eigenen Identitätsinfrastruktur isolieren. Du entscheidest: Welche Variante bietet dafür die stärkere Sicherheitsgrenze?
Klicke auf Lösung, um dein Ergebnis zu vergleichen:
B ist richtig. Eine zusätzliche Domain innerhalb desselben Forests schafft keine vergleichbare Sicherheitsgrenze. Soll die Laborumgebung gegenüber der NovaHealth-Identitätsinfrastruktur stärker isoliert werden, ist ein separater Forest die geeignetere Architektur. Benötigte Zugriffe zwischen beiden Umgebungen müssen dann gezielt eingerichtet werden, da es keine automatischen transitiven Vertrauensstellungen gibt.
Privilegierte Zugriffe in Ebenen trennen
Selbst eine gut geschützte AD-Infrastruktur hilft wenig, wenn Administratoren ihre hochprivilegierten Konten auf beliebigen Systemen verwenden. Genau hier setzt das AD DS Tier Model an. Es teilt administrative Identitäten und Systeme nach ihrer Vertrauensebene auf:
| Tier | Typische Systeme | Beispiele für administrative Identitäten |
|---|---|---|
| Tier 0 | Identitätsinfrastruktur | Domain Controller, AD CS, Entra Connect, Tier-0-Administratoren |
| Tier 1 | Server und Unternehmensanwendungen | Datei-, Datenbank- und Anwendungsserver, Serveradministratoren |
| Tier 2 | Endbenutzersysteme | Workstations, Benutzerkonten, Helpdesk-/Clientadministratoren |
Dabei gilt ein entscheidendes Prinzip:
⚠️ Hochprivilegierte Credentials dürfen nicht niedrigeren Vertrauensebenen ausgesetzt werden.
„Aber ein Domain Admin kann sich doch auf einer normalen Workstation anmelden. Warum sollte er das nicht tun?“
„Weil technische Möglichkeit und sichere Administration zwei verschiedene Dinge sind. Wenn du Tier-0-Credentials auf einer kompromittierten Workstation verwendest, kann der Angreifer versuchen, genau diese privilegierten Credentials oder die Sitzung zu übernehmen. Aus einem kompromittierten Client kann so eine Kompromittierung der Identitätsinfrastruktur werden.“
Das Tier-Modell soll genau diesen Eskalationspfad unterbrechen. Ein Administrator verwendet deshalb unterschiedliche administrative Identitäten für unterschiedliche Vertrauensebenen und führt besonders kritische Tätigkeiten von entsprechend geschützten PAWs aus. Die nachfolgende Abbildung zeigt die sichere Variante:
Entscheidend ist dabei nicht allein die Netzwerksegmentierung. Ein eigenes VLAN kann die Architektur unterstützen – die eigentliche Trennung des Tier-Modells basiert aber auf administrativen Identitäten, Zugriffswegen und Vertrauensgrenzen. Ein Tier-0-Konto gehört deshalb nicht auf eine Tier-1- oder Tier-2-Workstation.
Und ist dieses Tier-Modell noch aktuell?
Hier entsteht häufig Verwirrung. Microsoft hat das klassische Tier-Modell nicht einfach abgeschafft. Für Active Directory Domain Services dokumentiert Microsoft weiterhin ein AD DS Tier Model mit Tier 0, Tier 1 und Tier 2.
Daneben existiert das umfassendere Enterprise Access Model (EAM). Es erweitert die Grundidee auf moderne hybride IT-Umgebungen mit On-Premises-Systemen, Cloud-Diensten, Anwendungen und unterschiedlichen Zugriffspfaden. Vereinfacht kannst du dir die Entwicklung so vorstellen:
Das AD DS Tier Model bleibt dabei ein wichtiges Modell für die Absicherung klassischer Active-Directory-Umgebungen. Das Enterprise Access Model betrachtet darüber hinaus die gesamte moderne Unternehmensumgebung. Für uns ist vor allem das zugrunde liegende Sicherheitsprinzip entscheidend:
💡 Ein System oder Konto mit niedrigerem Vertrauensniveau darf nicht zum Sprungbrett für die Kompromittierung einer höheren Vertrauensebene werden.
Schauen wir, ob du die Architekturkonzepte zum Schutz von Active Directory verinnerlicht hast. Beantworte die folgenden Quizzes:
Ordne die Bedeutungen den korrekten Begriffen zu: