Es mag unmöglich erscheinen, eine Eskalation des ersten Zugriffs bis hin zum Domänenadministrator in Ihrer Active Directory (AD)-Umgebung zu verhindern. Insbesondere nach mehreren Jahren erfolgreicher Red-Team-Einsätze, bei denen jedes Mal neue Angriffswege gefunden wurden. Die Sicherung Ihrer kritischen Ressourcen ist zwar eine Herausforderung, aber mit dem richtigen Ansatz dennoch nicht unmöglich.

In diesem Blogbeitrag erfahren Sie, wie Sie Sicherheitsgrenzen in einer On-Prem-AD- und Azure-Umgebung sinnvoll implementieren können, um Ihre kritischen Assets nach dem Prinzip der Administrationsstufen (Tiers) zu schützen. Ebenso zeigen wir Ihnen, wie BloodHound Enterprise dabei helfen kann. Und Sie erfahren, wie Sie Ihre AD-Objekte und Azure-Ressourcen in einer Struktur organisieren, die Ihre Sicherheitsgrenzen abbildet.

Der Blogbeitrag wurde in Zusammenarbeit zwischen Teal und SpecterOps erstellt.

Wir empfehlen Ihnen, sich ein grundlegendes Verständnis von Angriffspfaden anzueignen, bevor Sie diesen Blog-Beitrag lesen. Mehr Infos zum Thema finden Sie im ersten Teil von wald0s tiefem Einblick: Das Manifest zur Verwaltung von Angriffswegen.

Vergangene und neue Microsoft Empfehlungen

In der Vergangenheit empfahl Microsoft die Verwendung der Enhanced Security Admin Environment (ESAE)-Architektur. Ziel war es eine sichere Umgebung für AD-Administratoren zu schaffen und eine vollständige Kompromittierung eines produktiven Forest im Falle einer Kompromittierung durch Nicht-Administratoren zu verhindern. Das AD-Tier-Modell war Teil von ESAE. Da Microsoft ESAE vor der Entstehung von Azure entwickelt hat, wurde ESAE ausdrücklich für On-Prem-AD konzipiert. Dank des Internet-Archivs können Sie hier noch die alte Version von Microsofts Securing Privileged Access with EASE, das Stufenmodell und Weiteres lesen.

Am 15. Dezember 2020 veröffentlichte Microsoft eine neue, überarbeitete Version von Securing Privileged Access auf Microsoft Docs, einschließlich des Enterprise Access Model, das sowohl On- Prem, Operational Technology (OT), Azure als auch andere Cloud-Anbieter umfasst. ESAE wurde also von Microsoft in den Ruhestand versetzt und die Empfehlungen zurückgezogen.

Die Grundsätze der alten und der neuen Empfehlungen von Microsoft sind im Wesentlichen aber dieselben. Sie empfehlen eine abgestufte Verwaltung mit dedizierten Administratorkonten. Administratoren sollten eine gehärtete Privileged Access Workstation (PAW) verwenden, wenn sie administrative Aufgaben ausführen, und die Admin-Sitzung muss eine Multi-Faktor-Authentifizierung (MFA) und Just-In-Time-Einschränkungen (JIT) erfordern. Bei der Bereitstellung von PAWs und anderen kritischen Ressourcen muss das Clean-Source-Prinzip beachtet werden.

Der Hauptunterschied zwischen den beiden Empfehlungspaketen ist der Fokus auf Azure. Die früheren Empfehlungen konzentrierten sich stark auf die Verhinderung von zwischengespeicherten Anmeldeinformationen, was in On-Prem-Umgebungen ein großes Sicherheitsproblem darstellt. Die neuesten Empfehlungen von Microsoft umfassen Azure-Technologien wie Conditional Access, die für Azure von großer Bedeutung sind, da die Bedienfelder im Internet erreichbar sind.

Da die Grundprinzipien beider Systeme gleich sind (Beschränkung des Zugriffs durch Berechtigungen), empfehlen wir die Verwendung von Elementen aus ESAE als Grundlage für die Erstellung von Sicherheitsgrenzen im On-Prem AD und die Verwendung der neuesten Empfehlungen von Microsoft für Azure.

In den folgenden Unterabschnitten werden wir uns mit dem Stufenmodell von ESAE und dem entsprechenden Enterprise Access Model aus dem neuesten Securing Privileged Access beschäftigen.

Modell der Active Directory-Verwaltungsebenen

Der Zweck des Stufenmodells besteht darin, Sicherheitsgrenzen zu implementieren, die kritische Ressourcen vor Geräten mit hohem Risiko schützen, wie z. B. normale Workstations, die häufig von Angreifern kompromittiert werden.

• • Tier-0: Kritische Assets mit direkter oder indirekter Kontrolle über den gesamten AD Forest. Enterprise Admins haben direkte Kontrolle, während ein SCOM- Administratorkonto indirekte Kontrolle hat, wenn DCs SCOM-Agenten installiert
  • Tier-1: Unternehmensserver und -anwendungen. Diese Systeme haben keine direkte oder indirekte Kontrolle über die
  • Tier-2: Arbeitsstationen und andere Geräte

Assets einer höheren Ebene (näher an Tier-0) können Assets einer niedrigeren Ebene kontrollieren, aber nicht umgekehrt. Beispielsweise können Domänenadministratoren in Tier-0 das Recht haben, das Kennwort eines beliebigen Benutzerkontos zurückzusetzen. Im Gegensatz dazu erlaubt das Tiering dem Helpdesk nur das Zurücksetzen des Passworts von Benutzern in Tier-2, nicht aber von Serveradministratoren in Tier-1 und Tier-0.

Der zweite Grundsatz des Schichtmodells schränkt die Anmelderechte der Benutzer so ein, dass sich die Benutzerkonten nur bei einer einzigen Schicht anmelden dürfen. Natürlich können sich Benutzer der zweiten Ebene nicht auf kritischen Servern der Tier-0 anmelden. Weniger intuitiv ist, dass Domänenadministratoren sich nicht auf Computern der Ebenen eins und zwei anmelden können, obwohl sie die volle Kontrolle über sie haben. Diese Einschränkung ist darauf zurückzuführen, dass die Benutzeranmeldeinformationen (in den meisten Fällen) auf dem Computer zwischengespeichert werden, auf dem sich der Benutzer anmeldet. Ein böswilliger Benutzer mit administrativen Rechten auf diesem Computer kann die Anmeldedaten stehlen, z. B. mithilfe von Mimikatz, und sich als Benutzer des Opfers ausgeben, um sich auf anderen Systemen anzumelden, auf die der Benutzer des Opfers Zugriff hat.

Die Konsequenz dieses Grundsatzes ist, dass Mitarbeiter mit Tier-0-Zugang einen eigenen Tier-0-Benutzer und ein separates Tier-2-Konto haben müssen, das sie für ihren regulären Tier-2-Arbeitsplatz für E-Mails, Web-Browsing usw. nutzen können. Dieser Grundsatz gilt nicht nur für persönliche Benutzerkonten, sondern für alle Konten, einschließlich Dienstkonten.

Die gelben Pfeile in der obigen Abbildung zeigen an, dass sich Benutzer einer niedrigeren Schicht bei Systemen höherer Schichten anmelden können, aber nur bei Bedarf. Wenn Sie z. B. einen Dateiserver in Tier-1 haben, den Benutzer der Tier-2 verwenden, müssen die Benutzer über Netzwerkanmelderechte auf diesem Server verfügen. Dennoch können Benutzer aus Tier-2 keine interaktive Anmeldung auf dem Computer über RDP oder ein anderes Netzwerkprotokoll durchführen und haben auch keine administrativen Rechte auf dem Computer, da dies gegen das Tiering verstoßen würde.

Als Konsequenz des Clean-Source-Prinzips müssen Administratoren mit privilegiertem Zugriff auf eine bestimmte Ebene die privilegierte Sitzung von einer Workstation aus aufbauen, die zur gleichen Ebene gehört. Daher sind PAWs erforderlich und Administratoren können ihre regulären Arbeitsstationen der Tier-2 nicht für die Verwaltung von Tier-1 und Tier-0 verwenden.

Zugriffsmodell für Unternehmen

Das Enterprise Access Model ist der Ersatz für das Stufenmodell in Microsofts neuesten Empfehlungen:

Das Konzept ist dem AD-Tiering sehr ähnlich. Die Control Plane ist das Äquivalent von Tier-0, während die Management Plane und die Data/Workload Plane Tier-1 sind. Der Zugriff auf die Ebenen in Tier-1 und Tier-0 sollte von Privileged Devices and Workstations (auch PAWs genannt) erfolgen, getrennt vom regulären Benutzer- und Anwendungszugriff von Geräten in Tier-2.

Der privilegierte Zugriff sollte vollständig vom Benutzerzugriff isoliert sein, wie in der Privileged Access Strategy von Microsoft dargestellt:

Wie man Sicherheitsgrenzen schafft

Wie können Sie Ihre Umgebungen so verändern, dass sie dem Konzept der abgestuften Verwaltung entsprechen? Und, was sehr wichtig ist, wie können Sie dies effektiv und sicher tun? In diesem Abschnitt werden die allgemeinen Phasen der Implementierung von Sicherheitsgrenzen in On-Prem-AD und Azure behandelt. Wir werden die Tiering-Terminologie sowohl für On-Prem-AD als auch für Azure verwenden.

Klassifizieren Sie Ihre Systeme

Es ist wichtig, dass Sie zunächst Ihre Sicherheitsgrenzen festlegen, d. h. zu welcher Ebene Ihre Ressourcen gehören und welche Mitarbeiter Zugang zu welchen Ressourcen haben sollen. Sie können Ihre kritischen Werte nicht vor unprivilegierten Benutzern schützen, wenn Sie Ihre kritischen Werte nicht kennen und nicht wissen, welchen Benutzern Sie Zugang gewähren.

Wir empfehlen, mit der Implementierung einer einzigen Sicherheitsgrenze zu beginnen, um Ihr Tier-0 vom Rest Ihrer Umgebung zu isolieren, da Tier-0 volle Kontrolle über alles bietet.

Identifizierung potenzieller Angriffswege und Festlegung von Prioritäten

Identifizieren Sie mögliche Angriffspfade, die Ihre Sicherheitsgrenzen überschreiten und setzen Sie Prioritäten, je nachdem, wie kritisch der Angriffspfad für die Umgebung ist.

Mit der FOSS (Free and Open-Source Software)-Version von BloodHound können Sie kritische Angriffspfade mit Hilfe von Analysefunktionen wie „Kürzeste Pfade von Domain Users zu wertvollen Zielen“ identifizieren. Mit BloodHound können Sie aber auch die eingehende Kontrolle über Ihre Tier-0 Assets auflisten:

Sie sollten versuchen, alle kompromittierenden Berechtigungen für Tier-0-Assets, die Nicht-Tier-0-Objekten gewährt werden, zu finden und diese priorisieren. FOSS BloodHound bietet keinen Schweregrad für Angriffspfade, aber Sie können die Angriffspfade manuell priorisieren. Ein Angriffspfad, dem nur sehr wenige Benutzer in der Umgebung ausgesetzt sind, muss nicht so dringend behoben werden wie Angriffspfade, die von allen Benutzern ausgenutzt werden können, z. B. wenn die Gruppe Domain Users kompromittierende Berechtigungen hat.

BloodHound Enterprise (BBHE) kann Ihnen helfen, diesen Prozess zu beschleunigen. BHE bildet alle Angriffspfade von der gesamten AD-Domäne oder dem Azure-Tenant in Richtung Tier-0 ab. Es misst die Exposition jedes Angriffspfads, d. h. den Prozentsatz der Benutzer mit den erforderlichen Rechten, um ihn zu missbrauchen. Im folgenden Beispiel hat ein Tier-0-AD-Benutzer (ADMINISTRATOR@TESTLAB.LOCAL) eine Sitzung auf einem Nicht-Tier-0-Computer (WIN10.TESTLAB.LOCAL), wodurch die Anmeldeinformationen des Tier-0-Benutzers für Nicht-Tier-0-Benutzer mit Ausführungszugriff auf diesen Nicht-Tier-0-Computer offengelegt werden:

Es mag nicht wie ein bedeutendes Problem erscheinen, da nur ein einziger Tier-0-Benutzer betroffen ist. Aber laut BHE handelt es sich um einen kritischen Befund. Und wenn wir die Zeitachse überprüfen, können wir sehen, dass der Gefährdungsgrad 100% beträgt:

Eine 100-prozentige Gefährdung bedeutet, dass 100% der Benutzer und Computer in der Domäne die Möglichkeit haben, einen Angriffspfad zu missbrauchen und Zugriff auf den Nicht-Tier-0-Computer zu erhalten. BHE kann Ihnen auf diese Weise helfen, Angriffspfade zu Tier-0 zu identifizieren und Ihnen eine Kritikalität basierend auf dem Gefährdungsgrad aufzeigen.

Inzwischen wurde die Azure-Unterstützung hinzugefügt und BHE ist nun auch in der Lage, Angriffspfade in Azure abzubilden:

Erstellung einer Roadmap und Umsetzung

Kritische Angriffspfade sollten hohe Priorität haben und einige sind Low-Hanging Fruits, die sofort und fast ohne Risiko unerwünschter Nebeneffekte behoben werden können. So können Sie beispielsweise schnell korrigieren, wenn der Eigentümer eines Tier-0-Objekts kein Tier-0-Objekt ist, indem Sie den Eigentümer z. B. in „Domain Admins“ ändern.

Andere Angriffspfade lassen sich mit einer Einzelmaßnahme nicht wirksam beheben und erfordern mehr Planung, z. B. wenn sich ein Tier-0 Administrator auf einem Tier-1-Server anmeldet. Diesmal ist vielleicht nur ein einziger Benutzer betroffen, aber Sie müssen sicherstellen, dass alle Benutzer über die richtigen Konten verfügen, die richtigen Anmeldeberechtigungen haben und wissen, welches Benutzerkonto für welche Systeme zu verwenden ist. Andernfalls wird das Problem immer wieder auftreten.

Daher ist es wichtig, einen Plan (Roadmap) zu erstellen, wie und in welcher Reihenfolge Sie die Probleme beseitigen und Ihre Sicherheitsgrenzen durchsetzen, um damit das Risiko eines Ausfalls der Produktionssysteme zu verringern.

Es ist von Vorteil, wenn Sie Aufgaben parallel ausführen können. Aber denken Sie daran, dass sowohl Systeme als auch Menschen nicht zu viel gleichzeitig bewältigen können. Die gleichzeitige Implementierung mehrerer Dinge in ein und demselben System erhöht das Risiko von Systemausfällen und erschwert die Fehlersuche. Auf der humanen Seite sollten Sie das IT-Personal nicht mit Aufgaben überlasten, da es für den Erfolg entscheidend ist.

Am besten sind Abhilfemaßnahmen in der Reihenfolge zu planen und zu terminieren, wie es aufgrund der Kenntnis aller Angriffspfade sinnvoll ist. Wenn Administratoren beispielsweise gezwungen werden, physische PAWs in Tier-0 zu verwenden, hat das wenig bis gar keinen Nutzen, solange Ihre Umgebung Angriffspfade von Domänenbenutzern zur Tier-0 enthält. Solche Angriffspfade umgehen den Schutz durch PAWs vollständig.

Unvorhergesehene Herausforderungen und Hindernisse treten auf und es werden ständig neue kritische Schwachstellen veröffentlicht. Daher müssen Sie die Roadmap und die Prioritätenliste regelmäßig bewerten und aktualisieren.

In den folgenden Abschnitten wird ein Beispiel für einen generischen High-Level-Fahrplan für die Isolierung von Tier-0 mit einer Sicherheitsabgrenzung beschrieben.

1. 1. 1. Behebung von leicht zu lösenden Tier-0-Angriffspfaden
      2. Bewertung der Sicherheitsprinzipale mit Kontrolle auf Tier-0-Systemen
      3. Bewertung der Folgen einer On-Prem-AD-Anmeldung
      4. Entwurf und Aufbau einer Tiering-Struktur
      5. Sicherstellen der korrekten Anmeldeberechtigungen im On-Prem-AD
      6. Verschieben der AD-Objekte und Azure-Ressourcen
      7. Beseitigung der verbleibenden Tier-0-Angriffspfade
      8. Implementierung einer Privileged Access Workstation (PAW)
      9. Einführung einer Just-in-Time (JIT)-Administration

1)   Behebung von leicht zu behebenden Tier-0-Angriffswegen

Gehen Sie die identifizierten Tier-0-Angriffspfade durch und beurteilen Sie, ob es sich um etwas handelt, das mit einer schnellen Lösung und einem geringen bis gar keinem Risiko eines Systemausfalls dauerhaft gelöst werden kann. Beseitigen Sie diese Angriffspunkte.

Der BHE bietet für jeden Angriffsweg einen Leitfaden zur Behebung des Problems:

2)   Bewertung von Sicherheitsprinzipien mit Kontrolle auf Tier-Zero-Systemen

Angenommen Sie haben definiert, welche Systeme zu Tier-0 gehören. Dann gehen Sie die Liste der Sicherheitsprinzipale durch, die Zugang auf jedem Tier-0-System haben. Dann entscheiden Sie, ob Sie diesen Zugriff benötigen und zu Tier-0 gehören. FOSS BloodHound und BHE können Ihnen diese Liste zur Verfügung stellen, oder Sie können RBAC-Rollen, ACLs, lokale Gruppen usw. manuell durchgehen. Denken Sie daran, auch die hinzugefügten Gruppen zu bewerten. Danach sollten Sie eine vollständige Liste der Tier-0-Assets haben, einschließlich der Systeme, Benutzer, Gruppen

3)   Folgen der On-Prem-AD-Anmeldung bewerten

Alle Tier-0-Benutzer im lokalen AD, einschließlich Dienstkonten, dürfen sich nicht auf Nicht-Tier-0-Computern anmelden. Ermitteln Sie, wo zusätzliche Nicht-Tier-0-Konten erforderlich sind. Persönliche Benutzer sind einfach, weil Personen mehrere Konten verwalten können. Dienstkonten hingegen sind knifflig. Ein Dienstkonto für ein bestimmtes System erfordert in der Regel, Anmelderechte auf vielen Computern, in jedem Tier. Sie sollten diese Systeme so umkonfigurieren, dass sie mindestens ein Dienstkonto pro Tier verwenden. Wenn dies nicht möglich ist, sollten Sie separate Systeminstanzen pro Tier einrichten.

4)   Entwerfen Sie eine Tiering-Struktur und bauen Sie sie auf.

Für die IT-Sicherheitsabteilung und die IT-Administratoren ist es vorteilhaft, eine Struktur in Ihrer Umgebung zu schaffen, die es leicht macht, Ihre Sicherheitsgrenzen zu erkennen. Klare Sicherheitsgrenzen machen es für Administratoren einfacher zu erkennen, ob eine bestimmte Änderung die Sicherheitsgrenzen verletzt, ohne die Sicherheitsabteilung zu konsultieren. Außerdem lassen sich so Angriffspfade systematisch und effizient lösen bzw. leichter lösen.

On-Prem-AD-Tiering-Struktur

Im On-Prem AD möchten Sie eine OU-Struktur, die Ihre Ebenen widerspiegelt. Dies ist ein einfaches Beispiel dafür, wie es aussehen könnte:

Die Position eines AD-Objekts macht deutlich, zu welcher Ebene es gehört. Unter den OUs “Accounts, Computers, and Groups OUs” können Sie eine OU-Struktur erstellen, die die Abteilungen des Unternehmens repräsentiert (oder was auch immer in Ihrem Unternehmen sinnvoll ist). Es könnte auch andersherum sein, etwa so:

Sie sollten sich darüber im Klaren sein, dass der übergeordnete Container der gleichen oder einer höheren Stufe angehören muss. Volle Kontrolle über einen übergeordneten Container ermöglicht es Angreifern, einen ACE auf dem übergeordneten Container zu erstellen, der den untergeordneten Objekten volle Kontrolle gewährt. Das bedeutet, dass volle Kontrolle über einen übergeordneten Container implizit volle Kontrolle über seine untergeordneten Objekte bedeutet (es sei denn, die Vererbung ist für untergeordnete Objekte deaktiviert). Die Accounts, Computers, and Groups OUs im obigen Screenshot sind beispielsweise alle Tier-0-OUs, da sie Tier-0-Objekte enthalten.

Azure-Tiering-Struktur

Anleitungen und bewährte Verfahren für Azure sind im Cloud Adoption Framework von Microsoft gut beschrieben, welches eine hervorragende Ressource für den Aufbau Ihrer Azure-Umgebung ist. Eines der Schlüsselkonzepte sind Azure-Landing Zones, eine skalierbare und modulare Methode zur Verwaltung von Azure-Ressourcen im Rahmen von Abonnements. Das folgende Diagramm ist ein Microsoft-Beispiel für eine Organisation mit mehreren Landing Zones:

Wie im On-Prem-AD, sollten Sie Ihre Azure-Ressourcen so organisieren, dass die Sicherheitsgrenzen klar zu erkennen sind. Dies können Sie erreichen, indem Sie Ihre Tier-0-Ressourcen unter einer oder mehreren Azure-Landing-Zones anordnen. Sie können auch die Verwaltungs- oder Ressourcengruppenebene verwenden, um Ihre Ressourcen in Tiers zu unterteilen, wenn dies für Ihre Umgebung besser geeignet ist. Es ist jedoch wichtig, daran zu denken, dass die der höchsten Stufe übergeordnete Ressourcen (Gruppen/Abonnements), denen untergeordneten Ressourcen angehören, automatisch auch Tier-0 angehören. Zum Beispiel sind die übergeordneten Ressourcen von Tier-0 Ressourcen immer in Tier-0.

5)   Sicherstellen der korrekten On-Prem-AD-Anmeldeberechtigungen

Bevor wir die AD-Objekte in die neue OU-Struktur verschieben, sollten wir sicherstellen, dass sich die Benutzerkonten an den richtigen Stellen anmelden können und sich nicht an anderen Stellen anmelden können. Eine einfache Lösung besteht darin, alle Benutzerkonten jeder Ebene in einer Gruppe zusammenzufassen und GPOs zu verwenden, die mit den Ebenen-OUs verknüpft sind. Dort wird die Anmeldung für Benutzer verweigert, die zu anderen Ebenen gehören:

Durch die Verwendung von Verweigerungsregeln müssen wir uns nicht um die Mitgliedschaft in lokalen Gruppen kümmern, die Anmelderechte vergeben. Denn Verweigerungsregeln haben Vorrang vor den Erlaubnisregeln. Manchmal können wir jedoch keine Verweigerungsregeln verwenden. Im obigen Beispiel kann die Netzwerkanmeldung für Benutzer der zweiten Ebene nicht verweigert werden, da die Benutzer der zweiten Ebene in der Lage sein müssen, sich bei Netzwerkdiensten zu authentifizieren, die in der ersten Ebene gehostet werden. Daher müssen wir sicherstellen, dass Benutzer der zweiten Ebene nicht Mitglieder von Administratoren oder anderen privilegierten Gruppen auf Computern der ersten Ebene sind.

6)   AD-Objekte und Azure-Ressourcen verschieben

Jetzt, da Ihre neue Tiering-Struktur steht, ist es an der Zeit, AD-Objekte und Azure-Ressourcen in diese zu verschieben. Die Verschiebung muss nicht unbedingt eine tatsächliche Verschiebung des AD-Objekts oder der Azure-Ressource sein, sondern kann auch die Erstellung einer neuen ersetzenden Instanz sein.

AD-Objekte verschieben

Bevor Sie ein AD-Objekt verschieben, müssen Sie einige Dinge beachten, um Beschädigungen zu vermeiden:

• • Vererbte Berechtigungen: Wenn Sie eine Access Control Entity (ACE) in der Access Control List (ACL) eines AD-Objekts erstellen, können untergeordnete Objekte so eingestellt werden, dass sie die ACE erben. Sofern die Vererbung für untergeordnete Objekte nicht deaktiviert ist, erben untergeordnete Objekte ACEs von ihren übergeordneten Containern. Infolgedessen können sich die Berechtigungen für ein AD-Objekt ändern, wenn Sie das AD- Objekt verschieben, was das Risiko von Systemausfällen birgt. Um Überraschungen zu vermeiden, sollten Sie die geerbten ACEs des aktuellen übergeordneten Containers des AD- Objekts mit denen des neuen übergeordneten Containers vergleichen und feststellen, ob Sie dem neuen übergeordneten Container oder dem AD-Objekt selbst irgendwelche Berechtigungen hinzufügen müssen. Das Lesen von ACLs in AD ist nicht einfach. Dieses PowerShell-Skript kann Ihnen dabei helfen: Get-ADObjectACL.ps1.
  • Angenommen, Sie haben Zweifel daran, wie ein bestimmter ACE genutzt wird, beispielsweise wenn die Berechtigung zu weit gefasst ist (wie z. B. volle Kontrolle für Domänenbenutzer). Dann können Sie den Zugriff auf das AD-Objekt überprüfen, indem Sie die System Access Control List (SACL) des AD-Objekts ändern. So können Sie überwachen, welche Identitäten auf dieses Objekt zugreifen und welche Aktionen sie ausführen, bevor Sie entscheiden, welche ACEs für das AD-Objekt ausreichend sind. Weitere Informationen finden Sie auf den Folien “Method Two: Granted vs. Requested Permissions” (ab Folie 43) aus der Präsentation von wald0 zu diesem Thema hier.
  • GPOs und Einstellungen: Das Verschieben eines Benutzer- oder Computerobjekts kann zu einer Änderung der angewendeten GPOs führen. Im folgenden Beispiel möchten wir unseren ADCS-Server von der OU “Servers\ADCS” zur OU “Tier0\Computers\ADCS” verschieben. Durch diese Verschiebung wird die Verknüpfung des GPO “Servereinstellungen” vom Server aufgehoben und stattdessen das GPO “Tier0-Computerkonfiguration” verknüpft.

Beachten Sie, dass es in einer realen Umgebung schwierig sein kann, festzustellen, welche Einstellungen für einen Computer oder Benutzer gelten, der die Gruppenrichtlinienverwaltung verwendet. GPOs, die näher mit einem Objekt verknüpft sind, können Einstellungen überschreiben, die weiter entfernt sind. Sie müssen auch sicherstellen, dass ein WMI-Filter den Benutzer oder Computer nicht ausfiltert.

Policy Analyzer ist ein großartiges kostenloses Tool für den Vergleich von GPO-Einstellungen mit anderen Einstellungen. Es ermöglicht Ihnen auch, die aktuellen lokalen Einstellungen eines Computers mit einem Satz von GPOs zu vergleichen. Das ist sehr nützlich, da auch andere Dinge, z.B. SCCM-Einstellungen oder manuelle Konfigurationen, auf dem Computer wirken können. Wenn die Option ” Verarbeiten, auch wenn sich die Gruppenrichtlinienobjekte nicht geändert haben” auf einem Computer nicht aktiviert wurde, werden die GPO-Einstellungen nur einmal wirksam, und Administratoren könnten die Einstellungen danach überschrieben haben. Wenn Sie die Verknüpfung eines Gruppenrichtlinienobjekts mit einem Computer aufheben, gelten die Einstellungen des Gruppenrichtlinienobjekts nicht mehr. Doch das ist nicht immer der Fall, da einige Einstellungen bestehen bleiben. Daher ist es sehr empfehlenswert, die aktuellen lokalen Einstellungen auf einem Computer sorgfältig mit den Einstellungen zu vergleichen, die beim Verschieben auf den Computer übertragen werden, um ein unwissentliches Überschreiben wichtiger Einstellungen zu vermeiden.

• • Hart kodierte Distinguished Names (OU-Pfade): Manche Skripte, Tools und manuelle Verfahren sind so konfiguriert, dass sie nach AD-Objekten unter einer bestimmten OU suchen und möglicherweise nicht mehr funktionieren, wenn AD-Objekte außerhalb dieser OU verschoben werden. Es gibt keine einfache Möglichkeit, hart kodierte Distinguished Names zu entdecken. Das Beste, was Sie tun können, ist sicherzustellen, dass Sie die richtigen Personen zu möglichen Problemen befragen, bevor ein AD-Objekt verschoben wird.

Azure-Ressourcen verschieben

Wie beim On-Prem-AD gibt es auch beim Verschieben von Azure-Ressourcen eine Menge zu beachten. Zum Beispiel ändert sich die ID einer Azure-Ressource nach einer Verschiebung, was zu den gleichen Problemen führen kann wie hart kodierte Distinguished Names für On-Prem AD.
Wir empfehlen Ihnen dringend, den Microsoft-Leitfaden zum Verschieben von Azure-Ressourcen zu lesen, der hier verfügbar ist. Er enthält Links zu Anleitungen zum Verschieben bestimmter Ressourcentypen und zu den Typen, die Sie nicht verschieben können.

7)   Beseitigung der verbleibenden Tier-Zero-Angriffspfade

Sie sollten die meisten Ihrer Tier-0-Angriffspfade bereits beseitigt haben, indem Sie die einfach zu behebenden Probleme gelöst und eine Struktur implementiert haben, die Ihre Sicherheitsgrenzen widerspiegelt. Wenn es noch Angriffspfade in Tier-0 gibt, sollten Sie diese jetzt beheben.

8)   Implementierung einer Privileged Access Workstation (PAW)

PAW ist ein umfangreiches Thema und wir werden in diesem Blogbeitrag nicht im Detail auf PAW eingehen können. Teal hat hier jedoch einen Blog-Beitrag über PAW veröffentlicht. Eine weitere hervorragende Referenz ist Microsoft‘s Privileged Access Devices .

Es gibt noch zwei wesentliche Dinge in Bezug auf PAW, die wir erwähnen möchten:

9)   Einführung der Just-in-Time-Verwaltung (JIT)

Es gibt viele benutzerdefinierte und nicht-native JIT-Lösungen, sowohl für On-Prem AD als auch für Azure, die wir in diesem Blogbeitrag nicht behandelt haben. LAPS kann Ihnen bei der JIT-Verwaltung in On-Prem AD helfen, aber die meisten PIM/PAM-Lösungen bieten bessere Optionen. In Azure können Sie JIT mittels Azure AD PIM konfigurieren, welches mit einer Azure AD Premium P2-Lizenz geliefert wird.

Messung der Fortschritte

Je nach Blickwinkel können Sie den Fortschritt Ihrer Umsetzung auf verschiedene Weise messen. Wenn Sie Ihre Roadmap in eine Liste von Aufgaben unterteilt haben, können Sie die Anzahl der erledigten Aufgaben im Verhältnis zur Gesamtzahl der Aufgaben als Maßstab verwenden. So erhalten Sie eine Vorstellung davon, wie weit Sie in Ihrem Fahrplan sind. Um die Effektivität Ihrer Sicherheitsgrenze zu messen, könnten Sie die Anzahl der Angriffspfade zählen, die die Sicherheitsgrenze durchqueren und ihnen eine Gewichtung auf der Grundlage ihrer Kritikalität geben.

BHE sammelt fortlaufend Daten und misst die Auswirkungen der von Ihnen durchgeführten Korrekturen von Angriffspfaden auf der BHE-Posture-Seite. Die Gesamtbelastung von Tier-0 wird im zeitlichen Verlauf dargestellt:

Wartung

Wenn Sie eine Sicherheitsgrenze (ganz oder teilweise) festgelegt haben, müssen Sie unbedingt dafür sorgen, dass diese nicht mit der Zeit verschwindet.

Eine Möglichkeit dazu ist die Konfiguration von Detektoren auf der Grundlage von Änderungen an Tier-0-Assets. In diesem Artikel zum Beispiel wird erklärt, wie man Benutzer erkennt, die zur Gruppe der Domänenadministratoren hinzugefügt wurden. Eine andere Lösung könnte darin bestehen, ein Skript zu erstellen, das ACEs, Gruppenmitgliedschaften und RBAC-Rollen von Tier-0 mit einer Vorlage vergleicht. Es meldet jede neue Entität, die das Tiering durchbricht, basierend auf dem Standort des Sicherheitsprinzipals, der die Berechtigung gewährt.

BHE kann Sie auch bei der Wartung unterstützen. Sie können in BHE sehen, dass neue Angriffspfade in BHE auftreten und die Gefährdung zunimmt, wenn ein Systemadministrator eine Fehlkonfiguration vorgenommen hat, die Ihre Sicherheitsgrenze durchbricht. BHE wird ständig um neue Angriffspfade erweitert und von Forschern sowie durch die Community veröffentlicht. Das hilft Ihnen, über neuen Angriffstypen auf dem Laufenden zu bleiben.

Wrap Up

Es ist nicht einfach Sicherheitsgrenzen zu implementieren, aber es ist machbar. Der Schlüssel zum Erfolg liegt darin, die umfangreichen Konzepte in einfache Aufgaben zu zerlegen. Selbst wenn Sie nur eine einzige Sicherheitsgrenze teilweise implementieren können, werden Ihre kritischen Werte immer noch deutlich besser geschützt sein als die von Organisationen, die es nicht einmal versucht haben. Je weiter Sie kommen, desto größer sind Ihre Chancen, dass ein Angreifer keinen Zugang zu Ihren kritischen Beständen erhält.

Wenn Sie mehr zu diesem Thema lesen möchten, finden Sie auf diesen Seitenweitere Informationen:

• • Microsofts aktuelle Securing Privileged Access
  • Microsofts old on-prem Securing Privileged Access
  • Microsoft’s Cloud Adoption Framework
  • Teal-Blog
  • BloodHound Enterprise-Blog
  • SpecterOps-Blog