Schützen von Domänencontrollern vor Angriffen

Gilt für: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Drittes Gesetz: Wenn ein Angreifer oder eine Angreiferin uneingeschränkten physischen Zugriff auf Ihren Computer hat, ist es nicht mehr Ihr Computer. - Zehn unumstößliche Sicherheitsgesetze (Version 2.0)

Domänencontroller stellen den physischen Speicher für die Active Directory Domain Services-Datenbank (AD DS) sowie die Dienste und Daten bereit, mit denen Unternehmen ihre Server, Arbeitsstationen, Benutzer*innen und Anwendungen effektiv verwalten können. Wenn Angreifer*innen privilegierten Zugriff auf einen Domänencontroller erlangen, können sie die AD DS-Datenbank ändern, beschädigen oder zerstören – und damit auch alle Systeme und Konten, die von Active Directory verwaltet werden.

Da Domänencontroller alle Elemente in der AD DS-Datenbank lesen und schreiben können, bedeutet die Kompromittierung eines Domänencontrollers, dass Ihre Active Directory-Gesamtstruktur nie wieder als vertrauenswürdig betrachtet werden kann, es sei denn, Sie können eine bekanntermaßen fehlerfreie Sicherung wiederherstellen und die Lücken schließen, die die Kompromittierung ermöglicht haben.

Je nach Vorbereitung, Werkzeugen und Fähigkeiten der Angreifer*innen benötigen diese nicht Tage oder Woche, um irreparable Schäden anzurichten, sondern nur wenige Minuten oder Stunden. Es ist nicht so wichtig, wie lange Angreifer*innen privilegierten Zugriff auf Active Directory haben, sondern wie viel sie für den Moment geplant haben, in dem sie privilegierten Zugriff erhalten. Die Kompromittierung eines Domänencontrollers kann der direkte Weg zur Zerstörung von Mitgliedsservern, Arbeitsstationen und der gesamten Active Directory-Struktur sein. Angesichts dieser Bedrohungslage müssen Domänencontroller separat und strenger als die allgemeine Infrastruktur gesichert werden.

Physische Sicherheit für Domänencontroller

In diesem Abschnitt finden Sie Informationen zur physischen Absicherung von Domänencontrollern. Domänencontroller können physische oder virtuelle Computer in Rechenzentren, Zweigstellen oder Remotestandorten sein.

Domänencontroller des Rechenzentrums

Physische Domänencontroller

In Rechenzentren sollten physische Domänencontroller in speziellen sicheren Racks oder Gehäusen installiert werden, die von der allgemeinen Serverpopulation getrennt sind. Wenn möglich, sollten Domänencontroller mit TPM-Chips (Trusted Platform Module) konfiguriert werden und alle Datenträger auf den Servern der Domänencontroller sollten mit BitLocker-Laufwerkverschlüsselung geschützt werden. BitLocker verursacht einen geringfügigen Leistungsoverhead im einstelligen Prozentbereich, schützt das Verzeichnis jedoch vor Gefährdung, selbst wenn Datenträger vom Server entfernt werden. BitLocker kann auch dazu beitragen, Systeme vor Angriffen wie Rootkits zu schützen, da die Änderung von Startdateien dazu führt, dass der Server im Wiederherstellungsmodus startet, sodass die ursprünglichen Binärdateien geladen werden können. Wenn ein Domänencontroller für die Verwendung von Software-RAID, SAS (Serial Attached SCSI), SAN/NAS-Speicher oder dynamischen Volumes konfiguriert ist, kann BitLocker nicht implementiert werden. Daher sollte auf Domänencontrollern nach Möglichkeit ein lokal angeschlossener Speicher (mit oder ohne Hardware-RAID) verwendet werden.

Virtuelle Domänencontroller

Wenn Sie virtuelle Domänencontroller implementieren, sollten Sie sicherstellen, dass diese auf physischen Hosts ausgeführt werden, die von anderen virtuellen Computern in der Umgebung getrennt sind. Auch wenn Sie eine Virtualisierungsplattform eines Drittanbieters verwenden, sollten Sie virtuelle Domänencontroller in Hyper-V in Windows Server bereitstellen. Eine solche Lösung bietet eine minimale Angriffsfläche und kann mit den Domänencontrollern verwaltet werden, auf denen sie gehostet wird, anstatt mit den restlichen Virtualisierungshosts. Wenn Sie System Center Virtual Machine Manager (SCVMM) für die Verwaltung Ihrer Virtualisierungsinfrastruktur implementieren, können Sie die Verwaltung der physischen Hosts, auf denen sich Domänencontroller-VMs befinden, sowie der Domänencontroller selbst an autorisierte Administrator*innen delegieren. Sie sollten auch eine Trennung des Speichers der virtuellen Domänencontroller in Erwägung ziehen, um Speicheradministrator*innen daran zu hindern, auf die VM-Dateien zuzugreifen.

Hinweis

Wenn Sie virtualisierte Domänencontroller zusammen mit anderen VMs mit weniger vertraulichen Daten auf denselben physischen Virtualisierungsservern (Hosts) platzieren möchten, sollten Sie eine Lösung implementieren, die die rollenbasierte Trennung von Aufgaben erzwingt, z. B. abgeschirmte VMs in Hyper-V. Diese Technologie bietet umfassenden Schutz vor Fabricadministrator*innen (einschließlich Virtualisierungs-, Netzwerk-, Speicher- und Sicherungsadministrator*innen), die böse Absichten hegen oder sich nicht gut auskennen. Die Technologie nutzt einen Vertrauensanker mit Remotezertifikaten und sicherer VM-Bereitstellung und sorgt effektiv für Sicherheit auf einem Niveau, das dem eines dedizierten physischen Servers entspricht.

Zweigstellenstandorte

Physische Domänencontroller in Zweigstellen

An Standorten, an denen sich mehrere Server befinden, die aber keinen physischen Schutz in einem Maß bieten, dass die Rechenzentrumsserver als sicher gelten können, sollten physische Domänencontroller mit TPM-Chips und BitLocker-Laufwerkverschlüsselung für alle Servervolumes konfiguriert werden. Wenn ein Domänencontroller an einem Standort nicht in einem abschließbaren Raum untergebracht werden kann, sollten Sie erwägen, an diesem Standort schreibgeschützte Domänencontroller (Read-Only Domain Controllers, RODCs) einzusetzen.

Virtuelle Domänencontroller in Zweigstellen

Sie sollten virtuelle Domänencontroller in Zweigstellen nach Möglichkeit auf physischen Hosts ausführen, die von den Hosts getrennt sind, auf denen sich die anderen virtuellen Computern am Standort befinden. In Zweigstellen, in denen virtuelle Domänencontroller nicht auf getrennten physischen Hosts ausgeführt werden können, sollten Sie TPM-Chips und BitLocker-Laufwerkverschlüsselung mindestens auf den Hosts implementieren, auf denen die virtuellen Domänencontroller ausgeführt werden – wenn möglich, auf allen Hosts. Je nach Größe der Zweigstelle und der Sicherheit der physischen Hosts sollten Sie an diesen Standorten nach Möglichkeit RODCs bereitstellen.

Sicherheit an Remotestandorten mit begrenztem Platz

Wenn zu Ihrer Infrastruktur Standorte gehören, an denen nur Platz für einen einzigen physischen Server ist, sollte ein Server installiert werden, der Virtualisierungsworkloads ausführen kann. Außerdem sollte die BitLocker-Laufwerkverschlüsselung so konfiguriert werden, dass alle Volumes auf dem Server geschützt sind. Eine VM auf dem Server sollte als RODC ausgeführt werden, andere Server sollten als separate VMs auf dem Host laufen. Informationen zur Planung der Bereitstellung von RODCs finden Sie im Leitfaden zur Planung und Bereitstellung von schreibgeschützten Domänencontrollern. Weitere Informationen zum Bereitstellen und Sichern virtualisierter Domänencontroller finden Sie unter Ausführen von Domänencontrollern in Hyper-V. Ausführlichere Anleitungen zum Verstärken der Sicherheit von Hyper-V, zum Delegieren der VM-Verwaltung und zum Schützen von VMs finden Sie auf der Microsoft-Website im Solution Accelerator-Leitfaden zur Sicherheit in Hyper-V.

Domänencontroller-Betriebssysteme

Alle Domänencontroller sollten unter der neuesten Version von Windows Server ausgeführt werden, die in Ihrer Organisation unterstützt wird. Organisationen sollten Legacybetriebssysteme im Domänencontrollerbestand möglichst schnell ausmustern. Indem Sie Domänencontroller auf dem aktuellen Stand halten und ältere Domänencontroller außer Betrieb nehmen, können Sie von neuen Funktionen und Sicherheitsfeatures profitieren. Diese Funktionen und Features sind in Domänen oder Gesamtstrukturen mit Domänencontrollern, die ein veraltetes Betriebssystem ausführen, möglicherweise nicht verfügbar.

Hinweis

Wie bei allen Konfigurationen, die hohe Anforderungen an die Sicherheit stellen und nur einen Zweck erfüllen, empfiehlt es sich, das Betriebssystem in der Installationsoption Server Core bereitzustellen. Dies bietet mehrere Vorteile: die Angriffsfläche wird minimiert, die Leistung wird verbessert und die Wahrscheinlichkeit menschlicher Fehler wird verringert. Zudem empfiehlt es sich, alle Vorgänge und Verwaltungsfunktionen remote auf dedizierten Endpunkten mit einem hohen Maß an Sicherheit auszuführen, wie z. B. Arbeitsstationen mit privilegiertem Zugriff (Privileged Access Workstations (PAWs) oder sicheren Verwaltungshosts.

Sichere Konfiguration von Domänencontrollern

Für die Erstellung einer anfänglichen Baseline für die Sicherheitskonfiguration von Domänencontrollern, die später von GPOs erzwungen werden kann, stehen verschiedene Tools zur Verfügung. Diese Tools werden im Abschnitt Verwalten der Sicherheitsrichtlinieneinstellungen in der Dokumentation zu den Microsoft-Betriebssystemen oder in der Desired State Configuration (DSC) für Windows beschrieben.

RDP-Einschränkungen

Gruppenrichtlinienobjekte, die mit allen Domänencontrollern in einer Gesamtstruktur verknüpft sind, sollten so konfiguriert werden, dass RDP-Verbindungen nur von autorisierten Benutzer*innen und Systemen wie z. B. Jumpservern zugelassen werden. Die Steuerung dieser Konfiguration lässt sich durch eine Kombination aus Einstellungen für Benutzerrechte und einer in GPOs implementierten WFAS-Konfiguration erreichen, sodass die Richtlinie einheitlich angewendet wird. Wenn die Richtlinie umgangen wird, setzt die nächste Aktualisierung der Gruppenrichtlinie das System wieder auf die richtige Konfiguration zurück.

Patch- und Konfigurationsverwaltung für Domänencontroller

Auch wenn es kontraintuitiv erscheinen mag, sollten Sie Domänencontroller und andere kritische Infrastrukturkomponenten getrennt von Ihrer allgemeinen Windows-Infrastruktur patchen. Wenn Sie für alle Computer in Ihrer Infrastruktur eine Software zur Verwaltung der Unternehmenskonfiguration verwenden, kann eine Kompromittierung der Systemverwaltungssoftware dazu verwendet werden, alle von dieser Software verwalteten Infrastrukturkomponenten zu gefährden oder zu zerstören. Indem Sie die Patch- und Systemverwaltung für Domänencontroller vom allgemeinen Bestand trennen, können Sie nicht nur die Menge der auf den Domänencontrollern installierten Software reduzieren, sondern auch deren Verwaltung genau kontrollieren.

Blockieren des Internetzugriffs für Domänencontroller

Eine der Überprüfungen, die im Rahmen einer Active Directory-Sicherheitsbewertung ausgeführt werden, ist die Verwendung und Konfiguration von Internet Explorer auf Domänencontrollern. Auf Domänencontroller sollte kein Webbrowser verwendet werden. Eine Analyse von Tausenden von Domänencontrollern hat zahlreiche Fälle aufgedeckt, in denen privilegierte Benutzer*innen Internet Explorer verwendet haben, um das Intranet der Organisation oder das Internet zu durchsuchen.

Wie bereits im Abschnitt „Fehlkonfiguration“ von Wege der Gefährdung beschrieben, ist die Sicherheit einer Organisation einem gravierenden Risiko ausgesetzt, wenn auf einem der leistungsfähigsten Computer in einer Windows-Infrastruktur mit einem Konto mit hohen Berechtigungen auf das Internet oder ein infiziertes Intranet zugegriffen wird. Ob durch einen Drive-by-Download oder per Download von mit Schadsoftware infizierten „Hilfsprogrammen“ – Angreifer*innen können Zugriff auf alle Elemente und Komponenten erlangen, die sie benötigen, um die Active Directory-Umgebung vollständig zu kompromittieren oder sogar zu zerstören.

Obwohl Windows Server und aktuelle Versionen von Internet Explorer viele Schutzmaßnahmen vor schädlichen Downloads bieten, wurde in den meisten Fällen, in denen Domänencontroller und privilegierte Konten zum Zugriff auf das Internet verwendet wurden, Windows Server 2003 auf den Domänencontrollern ausgeführt, oder die Schutzmechanismen neuerer Betriebssysteme und Browser wurden absichtlich deaktiviert.

Das Starten von Webbrowsern auf Domänencontrollern sollte durch Richtlinien und technische Steuerelemente eingeschränkt werden. Darüber hinaus sollte der allgemeine Internetzugriff auf Domänencontrollern streng kontrolliert werden.

Microsoft empfiehlt allen Organisationen, für die Identitäts- und Zugriffsverwaltung zu einem cloudbasierten Ansatz zu wechseln und von Active Directory zu Microsoft Entra ID zu migrieren. Microsoft Entra ID ist eine vollständige cloudbasierte Identitäts- und Zugriffsverwaltungslösung für die Verwaltung von Verzeichnissen, das Gewähren des Zugriffs auf lokale und Cloud-Apps und den Schutz von Identitäten vor Sicherheitsbedrohungen. Microsoft Entra ID bietet außerdem robuste und differenzierte Sicherheitskontrollmechanismen für den Schutz von Identitäten, wie z. B. die Multi-Faktor-Authentifizierung, Richtlinien für bedingten Zugriff, Identitätsschutz, Identitätsgovernance und Privileged Identity Management.

Die meisten Organisationen arbeiten während des Übergangs zur Cloud in einem Hybrididentitätsmodell, wobei einige Elemente ihrer lokalen Active Directory-Instanz mithilfe von Microsoft Entra Connect synchronisiert werden. Auch wenn ein solches Hybridmodell in fast jeder Organisation vorhanden ist, empfiehlt Microsoft den cloudbasierten Schutz dieser lokalen Identitäten mithilfe von Microsoft Defender for Identity. Die Konfiguration des Defender for Identity-Sensors auf Domänencontrollern und AD FS-Servern ermöglicht eine hochgradig sichere, unidirektionale Verbindung mit dem Clouddienst über einen Proxy und zu bestimmten Endpunkten. Eine vollständige Erläuterung der Konfiguration dieser Proxyverbindung finden Sie in der technischen Dokumentation für Defender for Identity. Diese streng kontrollierte Konfiguration stellt sicher, dass das Risiko verringert wird, dass diese Server eine Verbindung mit dem Clouddienst herstellen, und Organisationen profitieren von den höheren Schutzfunktionen vonj Defender for Identity. Microsoft empfiehlt auch, diese Server mit einer cloudbasierten Endpunkterkennung wie z. B. Microsoft Defender for Servers zu schützen.

Organisationen, die aufgrund gesetzlicher oder anderer richtlinienbasierter Anforderungen eine lokale Implementierung von Active Directory beibehalten müssen, empfiehlt Microsoft, den Internetzugriff auf Domänencontrollern vollständig zu unterbinden.

Einschränkungen für Umkreisfirewalls

Umkreisfirewalls sollten so konfiguriert werden, dass ausgehende Verbindungen von Domänencontrollern mit dem Internet blockiert werden. Domänencontroller müssen zwar möglicherweise über Standortgrenzen hinaus kommunizieren, aber Umkreisfirewalls können so konfiguriert werden, dass die Kommunikation zwischen Standorten gemäß den Richtlinien zugelassen wird, die Sie unter Konfigurieren einer Firewall für Domänen und Vertrauensstellungen von Active Directory finden.

Verhindern des Webzugriffs auf Domänencontrollern

Sie können eine Kombination aus einer AppLocker-Konfiguration, einer „Black Hole“-Proxykonfiguration und einer WFAS-Konfiguration verwenden, um den Internetzugriff und die Verwendung von Webbrowsern auf Domänencontrollern zu verhindern.