Implementieren von Verwaltungsmodellen der geringste Rechte

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

Der folgende Auszug ist aus dem Handbuch zurSicherheitsplanung für Administratorkonten , das am 1. April 1999 veröffentlicht wurde:

"In den meisten sicherheitsbezogenen Schulungen und Dokumentationen wird die Implementierung eines Prinzips der geringsten Rechte erläutert, organisationen folgen diesem jedoch nur selten. Das Prinzip ist einfach, und die Auswirkungen der ordnungsgemäßen Anwendung erhöhen ihre Sicherheit und verringern Ihr Risiko. Das Prinzip besagt, dass sich alle Benutzer mit einem Benutzerkonto anmelden sollten, das über die absoluten Mindestberechtigungen verfügt, die zum Abschließen der aktuellen Aufgabe erforderlich sind, und nicht mehr. Dies bietet schutz vor schädlichem Code und anderen Angriffen. Dieses Prinzip gilt für Computer und die Benutzer dieser Computer. "Ein Grund, warum dieses Prinzip so gut funktioniert, ist, dass Es Sie zwingt, interne Untersuchungen zu unternehmen. Beispielsweise müssen Sie die Zugriffsberechtigungen bestimmen, die ein Computer oder Benutzer wirklich benötigt, und diese dann implementieren. Für viele Organisationen mag diese Aufgabe anfänglich wie eine große Menge Arbeit erscheinen. Es ist jedoch ein wichtiger Schritt, um Ihre Netzwerkumgebung erfolgreich zu schützen. "Sie sollten allen Domänenadministratorbenutzern ihre Domänenberechtigungen im Rahmen des Konzepts der geringsten Rechte gewähren. Wenn sich beispielsweise ein Administrator mit einem privilegierten Konto anmeldet und versehentlich ein Virenprogramm ausgeführt wird, hat der Virus Administratorzugriff auf den lokalen Computer und die gesamte Domäne. Wenn sich der Administrator stattdessen mit einem nicht privilegierten (nichtadministrativen) Konto angemeldet hätte, wäre der Schadensbereich des Virus nur der lokale Computer, da er als lokaler Computerbenutzer ausgeführt wird. "In einem anderen Beispiel dürfen Konten, denen Sie Administratorrechte auf Domänenebene gewähren, keine erhöhten Rechte in einer anderen Gesamtstruktur haben, auch wenn eine Vertrauensstellung zwischen den Gesamtstrukturen besteht. Diese Taktik hilft dabei, weit verbreitete Schäden zu verhindern, wenn es einem Angreifer gelingt, eine verwaltete Gesamtstruktur zu gefährden. Organisationen sollten ihr Netzwerk regelmäßig überwachen, um sich vor einer unbefugten Ausweitung von Berechtigungen zu schützen."

Der folgende Auszug ist aus dem Microsoft Windows-Sicherheit Resource Kit, das erstmals 2005 veröffentlicht wurde:

"Denken Sie immer an Sicherheit, um die geringste Anzahl von Berechtigungen zu gewähren, die zum Ausführen der Aufgabe erforderlich sind. Wenn eine Anwendung, die über zu viele Berechtigungen verfügt, kompromittiert werden soll, kann der Angreifer den Angriff möglicherweise über das hinaus erweitern, was er wäre, wenn die Anwendung unter der geringsten Anzahl von Berechtigungen gewesen wäre. Untersuchen Sie beispielsweise die Folgen, die ein Netzwerkadministrator hat, der unbeabsichtigt eine E-Mail-Anlage öffnet, die einen Virus startet. Wenn der Administrator mit dem Domänenadministratorkonto angemeldet ist, hat der Virus administratorrechte auf allen Computern in der Domäne und somit uneingeschränkten Zugriff auf fast alle Daten im Netzwerk. Wenn der Administrator mit einem lokalen Administratorkonto angemeldet ist, hat der Virus Administratorrechte auf dem lokalen Computer und kann daher auf alle Daten auf dem Computer zugreifen und schadhafte Software wie Schlüsselstrichprotokollierungssoftware auf dem Computer installieren. Wenn der Administrator mit einem normalen Benutzerkonto angemeldet ist, hat der Virus nur Zugriff auf die Daten des Administrators und kann keine schadhafte Software installieren. Durch die Verwendung der geringsten Berechtigungen, die zum Lesen von E-Mails erforderlich sind, wird in diesem Beispiel der potenzielle Umfang der Kompromittung erheblich reduziert."

Das Berechtigungsproblem

Die in den vorherigen Ausschnitten beschriebenen Prinzipien haben sich nicht geändert, aber bei der Bewertung von Active Directory-Installationen finden wir aussergeänderlich viele Konten, denen Rechte und Berechtigungen gewährt wurden, die weit über diejenigen hinausgehen, die für die täglichen Aufgaben erforderlich sind. Die Größe der Umgebung wirkt sich auf die Rohzahlen von Konten mit zu hohen Berechtigungen aus, aber nicht die verzeichnisse mit mittleren Anteilen können Dutzende von Konten in den gruppen mit den höchsten Berechtigungen enthalten, während große Installationen hunderte oder sogar Tausende haben können. Mit wenigen Ausnahmen folgen Angreifer in der Regel dem Pfad des geringsten Widerstands, unabhängig von der Raffinesse der Fähigkeiten und des Angriffs eines Angreifers. Sie erhöhen die Komplexität ihrer Tools und Herangehensweisen nur, wenn einfachere Mechanismen fehlschlagen oder von Defenders verhindert werden.

Leider hat sich der Pfad des geringsten Widerstands in vielen Umgebungen als die übermäßige Nutzung von Konten mit umfassenden und umfassenden Berechtigungen erwiesen. Allgemeine Berechtigungen sind Rechte und Berechtigungen, die es einem Konto ermöglichen, bestimmte Aktivitäten in einem großen Abschnitt der Umgebung durchzuführen. Beispielsweise können Helpdeskmitarbeitern Berechtigungen erteilt werden, die es ihnen ermöglichen, die Kennwörter für viele Benutzerkonten zurückzusetzen.

Tiefe Berechtigungen sind leistungsstarke Berechtigungen, die auf ein schmales Segment der Bevölkerung angewendet werden, z. B. die Rechte eines Technikeradministrators auf einem Server, damit er Reparaturen durchführen kann. Weder allgemeine noch tiefe Berechtigungen sind notwendigerweise gefährlich, aber wenn vielen Konten in der Domäne dauerhaft umfassende und umfassende Berechtigungen gewährt werden, kann es schnell verwendet werden, um die Umgebung für die Zwecke des Angreifers neu zu konfigurieren oder sogar große Segmente der Infrastruktur zu zerstören.

Pass-the-Hash-Angriffe, bei denen es sich um eine Art Angriff mit Diebstahl von Anmeldeinformationen handelt, sind ubiquitiert, da die Tools für ihre Ausführung frei verfügbar und einfach zu verwenden sind und viele Umgebungen anfällig für Angriffe sind. Pass-the-Hash-Angriffe sind jedoch nicht das eigentliche Problem. Der Kern des Problems ist zweifach:

  1. In der Regel ist es für einen Angreifer einfach, tiefe Berechtigungen auf einem einzelnen Computer zu erhalten und diese Berechtigungen dann allgemein an andere Computer zu übertragen.
  2. Es gibt in der Regel zu viele permanente Konten mit hohen Berechtigungen in der gesamten Computerlandschaft.

Selbst wenn Pass-the-Hash-Angriffe beseitigt werden, würden Angreifer einfach verschiedene Taktiken verwenden, nicht eine andere Strategie. Anstatt Schadsoftware einzugeben, die Tools zum Diebstahl von Anmeldeinformationen enthält, können sie Schadsoftware zum Protokollieren von Tastatureingaben oder eine beliebige Anzahl anderer Ansätze nutzen, um Anmeldeinformationen zu erfassen, die in der gesamten Umgebung leistungsfähig sind. Unabhängig von den Taktiken bleiben die Ziele unverändert: Konten mit umfassenden und umfassenden Berechtigungen.

Das Gewähren übermäßiger Berechtigungen ist nicht nur in Active Directory in kompromittierten Umgebungen zu finden. Wenn eine Organisation die Angewohnheit entwickelt hat, mehr Berechtigungen zu gewähren, als erforderlich ist, befindet sie sich in der Regel in der gesamten Infrastruktur, wie in den folgenden Abschnitten erläutert.

In Active Directory

In Active Directory ist es üblich, dass die EA-, DA- und BA-Gruppen eine übermäßige Anzahl von Konten enthalten. In der Regel enthält die EA-Gruppe einer Organisation die wenigsten Mitglieder, DA-Gruppen enthalten in der Regel einen Multiplikator der Anzahl von Benutzern in der EA-Gruppe, und Administratorengruppen enthalten in der Regel mehr Mitglieder als die Populationen der anderen Gruppen kombiniert. Dies liegt häufig daran, dass Administratoren in irgendeiner Weise "weniger privilegiert" sind als DAs oder EAs. Obwohl sich die Rechte und Berechtigungen, die jeder dieser Gruppen gewährt werden, unterscheiden, sollten sie effektiv als gleichermaßen leistungsfähige Gruppen betrachtet werden, da ein Mitglied von einer Gruppe selbst zu einem Mitglied der anderen beiden machen kann.

Auf Mitgliedsservern

Wenn wir die Mitgliedschaft von lokalen Administratorgruppen auf Mitgliedsservern in vielen Umgebungen abrufen, finden wir Mitgliedschaften, die von einer Handvoll lokaler Konten und Domänenkonten bis hin zu Dutzenden geschachtelten Gruppen reichen, die, wenn sie erweitert werden, Hunderte oder sogar Tausende konten mit lokalen Administratorrechten auf den Servern verfügbar machen. In vielen Fällen werden Domänengruppen mit großen Mitgliedschaften in den lokalen Administratorgruppen von Mitgliedsservern geschachtelt, ohne die Tatsache zu berücksichtigen, dass jeder Benutzer, der die Mitgliedschaften dieser Gruppen in der Domäne ändern kann, administrative Kontrolle über alle Systeme erhalten kann, auf denen die Gruppe in einer lokalen Administratorgruppe geschachtelt wurde.

Auf Arbeitsstationen

Obwohl Arbeitsstationen in der Regel deutlich weniger Mitglieder in ihren lokalen Administratorgruppen als Mitgliedsserver haben, wird Benutzern in vielen Umgebungen die Mitgliedschaft in der lokalen Administratorgruppe auf ihren PCs gewährt. In diesem Fall stellen diese Benutzer selbst bei aktivierter UAC ein erhöhtes Risiko für die Integrität ihrer Arbeitsstationen dar.

Wichtig

Sie sollten sorgfältig überlegen, ob Benutzer Administratorrechte auf ihren Arbeitsstationen benötigen, und wenn sie dies tun, ist es möglicherweise besser, ein separates lokales Konto auf dem Computer zu erstellen, der Mitglied der Gruppe Administratoren ist. Wenn Benutzer Rechteerweiterungen benötigen, können sie die Anmeldeinformationen dieses lokalen Kontos für die Erhöhung der Rechte angeben. Da das Konto jedoch lokal ist, kann es nicht verwendet werden, um andere Computer zu gefährden oder auf Domänenressourcen zu zugreifen. Wie bei allen lokalen Konten sollten die Anmeldeinformationen für das lokale privilegierte Konto jedoch eindeutig sein. Wenn Sie ein lokales Konto mit den gleichen Anmeldeinformationen auf mehreren Arbeitsstationen erstellen, machen Sie die Computer für Pass-the-Hash-Angriffe verfügbar.

In Anwendungen

Bei Angriffen, bei denen das Ziel das geistige Eigentum einer Organisation ist, können Konten, denen leistungsstarke Berechtigungen innerhalb von Anwendungen gewährt wurden, darauf ausgerichtet werden, die Exfiltration von Daten zu ermöglichen. Obwohl den Konten, die Zugriff auf sensible Daten haben, möglicherweise keine erhöhten Berechtigungen in der Domäne oder im Betriebssystem gewährt wurden, stellen Konten, die die Konfiguration einer Anwendung oder den Zugriff auf die Informationen der Anwendung ändern können, ein Risiko dar.

In Datenrepos repositorys

Wie bei anderen Zielen können Angreifer, die Zugriff auf geistiges Eigentum in Form von Dokumenten und anderen Dateien suchen, auf die Konten zielen, die den Zugriff auf die Dateispeicher, Konten mit direktem Zugriff auf die Dateien oder sogar Gruppen oder Rollen steuern, die Zugriff auf die Dateien haben. Wenn beispielsweise ein Dateiserver zum Speichern von Vertragsdokumenten verwendet wird und der Zugriff auf die Dokumente mithilfe einer Active Directory-Gruppe gewährt wird, kann ein Angreifer, der die Mitgliedschaft der Gruppe ändern kann, kompromittierte Konten der Gruppe hinzufügen und auf die Vertragsdokumente zugreifen. In Fällen, in denen der Zugriff auf Dokumente von Anwendungen wie SharePoint bereitgestellt wird, können Angreifer die Anwendungen wie zuvor beschrieben als Ziel verwenden.

Reduzieren von Berechtigungen

Je größer und komplexer eine Umgebung ist, desto schwieriger ist es, sie zu verwalten und zu schützen. In kleinen Organisationen kann das Überprüfen und Reduzieren von Berechtigungen ein relativ einfaches Angebot sein, aber jeder zusätzliche Server, jede Arbeitsstation, jedes Benutzerkonto und jede Anwendung, die in einer Organisation verwendet wird, fügt ein weiteres Objekt hinzu, das geschützt werden muss. Da es schwierig oder sogar unmöglich sein kann, jeden Aspekt der IT-Infrastruktur einer Organisation ordnungsgemäß zu schützen, sollten Sie sich zuerst auf die Konten konzentrieren, deren Berechtigungen das größte Risiko darstellen. Dies sind in der Regel die integrierten privilegierten Konten und Gruppen in Active Directory und privilegierte lokale Konten auf Arbeitsstationen und Mitgliedsservern.

Sichern lokaler Administratorkonten auf Arbeitsstationen und Mitgliedsservern

Obwohl sich dieses Dokument auf die Sicherung von Active Directory konzentriert, wie bereits erwähnt, beginnen die meisten Angriffe auf das Verzeichnis als Angriffe auf einzelne Hosts. Es können keine vollständigen Richtlinien zum Schützen lokaler Gruppen auf Mitgliedssystemen bereitgestellt werden, aber die folgenden Empfehlungen können Ihnen helfen, die lokalen Administratorkonten auf Arbeitsstationen und Mitgliedsservern zu schützen.

Sichern lokaler Administratorkonten

Bei allen Versionen von Windows derzeit im Mainstream-Support ist das lokale Administratorkonto standardmäßig deaktiviert, wodurch das Konto für Pass-the-Hash- und andere Diebstahlangriffe auf Anmeldeinformationen unbrauchbar wird. In Domänen mit älteren Betriebssystemen oder in denen lokale Administratorkonten aktiviert wurden, können diese Konten jedoch wie zuvor beschrieben verwendet werden, um kompromittierte Computer auf Mitgliedsservern und Arbeitsstationen zu verteilen. Aus diesem Grund werden die folgenden Steuerelemente für alle lokalen Administratorkonten auf in die Domäne beigetretenen Systemen empfohlen.

Ausführliche Anweisungen zum Implementieren dieser Steuerelemente finden Sie in Anhang H: Sichern lokaler Administratorkonten und -gruppen. Stellen Sie jedoch vor der Implementierung dieser Einstellungen sicher, dass lokale Administratorkonten derzeit nicht in der Umgebung verwendet werden, um Dienste auf Computern oder andere Aktivitäten durchzuführen, für die diese Konten nicht verwendet werden sollen. Testen Sie diese Einstellungen gründlich, bevor Sie sie in einer Produktionsumgebung implementieren.

Steuerelemente für lokale Administratorkonten

Integrierte Administratorkonten sollten nie als Dienstkonten auf Mitgliedsservern verwendet werden, und sie sollten auch nicht für die Anmeldung bei lokalen Computern verwendet werden (mit Ausnahme des Tresor-Modus, der auch dann zulässig ist, wenn das Konto deaktiviert ist). Das Ziel der Implementierung der hier beschriebenen Einstellungen besteht im Verhindern, dass das lokale Administratorkonto jedes Computers verwendet werden kann, es sei denn, die Schutzkontrollen werden zuerst umgekehrt. Durch die Implementierung dieser Steuerelemente und die Überwachung von Administratorkonten auf Änderungen können Sie die Wahrscheinlichkeit eines Erfolgs eines Angriffs, der auf lokale Administratorkonten zielt, erheblich reduzieren.

Konfigurieren von Gruppenrichtlinienobjekten zum Einschränken von Administratorkonten auf Domain-Joined Systemen

Fügen Sie in mindestens einem Gruppenrichtlinienobjekt, das Sie erstellen und mit Arbeitsstations- und Mitgliedsserver-OUs in jeder Domäne verknüpfen, das Administratorkonto den folgenden Benutzerrechten unter Computerkonfiguration\Richtlinien\Windows Einstellungen\Sicherheit Einstellungen\Lokale Richtlinien\Benutzerrechtezuweisungen hinzu:

  • Zugriff vom Netzwerk auf diesen Computer verweigern
  • Anmelden als Batchauftrag verweigern
  • Anmelden als Dienst verweigern
  • Anmelden über Remotedesktopdienste verweigern

Wenn Sie diesen Benutzerrechten Administratorkonten hinzufügen, geben Sie an, ob Sie das lokale Administratorkonto oder das Administratorkonto der Domäne mit der Bezeichnung des Kontos hinzufügen. For example, to add the NWTRADERS domain's Administrator account to these deny rights, you would type the account as NWTRADERS\Administrator, or browse to the Administrator account for the NWTRADERS domain. Um sicherzustellen, dass Sie das lokale Administratorkonto einschränken, geben Sie administrator in diese Einstellungen für Benutzerrechte im Gruppenrichtlinienobjekt-Editor.

Hinweis

Auch wenn lokale Administratorkonten umbenannt werden, gelten die Richtlinien weiterhin.

Diese Einstellungen stellen sicher, dass das Administratorkonto eines Computers nicht zum Herstellen einer Verbindung mit den anderen Computern verwendet werden kann, auch wenn es versehentlich oder böswillig aktiviert ist. Lokale Anmeldungen mit dem lokalen Administratorkonto können nicht vollständig deaktiviert werden, und Sie sollten auch nicht versuchen, dies zu versuchen, da das lokale Administratorkonto eines Computers für die Verwendung in Notfallwiederherstellungsszenarien konzipiert ist.

Wenn ein Mitgliedsserver oder eine Arbeitsstation von der Domäne ohne andere lokale Konten mit Administratorrechten nicht mehr zugeordnet wird, kann der Computer in den abgesicherten Modus gestartet werden, das Administratorkonto kann aktiviert werden, und das Konto kann dann verwendet werden, um Reparaturen auf dem Computer vorzunehmen. Wenn Reparaturen abgeschlossen sind, sollte das Administratorkonto erneut deaktiviert werden.

Schützen lokaler privilegierter Konten und Gruppen in Active Directory

Gesetz Nr. 6: Ein Computer ist nur so sicher, wie der Administrator vertrauenswürdig ist. - Zehn unveränderliche Gesetze zur Sicherheit (Version 2.0)

Die hier bereitgestellten Informationen sollen allgemeine Richtlinien zum Schützen der integrierten Konten und Gruppen mit den höchsten Berechtigungen in Active Directory enthalten. Ausführliche Schritt-für-Schritt-Anweisungen finden Sie auch in Anhang D: Sichern von Built-In-Administratorkonten in Active Directory,Anhang E: Schützen von Enterprise-Administratorgruppen in Active Directory,Anhang F:Schützen von Domänenadministratorgruppen in Active Directory und in Anhang G:Schützen von Administratorgruppen in Active Directory .

Bevor Sie eine dieser Einstellungen implementieren, sollten Sie auch alle Einstellungen gründlich testen, um zu ermitteln, ob sie für Ihre Umgebung geeignet sind. Nicht alle Organisationen können diese Einstellungen implementieren.

Sichern integrierter Administratorkonten in Active Directory

In jeder Domäne in Active Directory wird im Rahmen der Erstellung der Domäne ein Administratorkonto erstellt. Dieses Konto ist standardmäßig Mitglied der Domänenadministratoren- und Administratorgruppen in der Domäne. Wenn die Domäne die Stammdomäne der Gesamtstruktur ist, ist das Konto auch Mitglied der Gruppe Enterprise Admins. Die Verwendung des lokalen Administratorkontos einer Domäne sollte nur für anfängliche Buildaktivitäten und ggf. Notfallwiederherstellungsszenarien reserviert werden. Um sicherzustellen, dass ein integriertes Administratorkonto verwendet werden kann, um Reparaturen für den Fall durchzuführen, dass keine anderen Konten verwendet werden können, sollten Sie die Standardmitgliedschaft des Administratorkontos in keiner Domäne in der Gesamtstruktur ändern. Stattdessen sollten Sie Richtlinien befolgen, um das Administratorkonto in jeder Domäne in der Gesamtstruktur zu schützen. Ausführliche Anweisungen zum Implementieren dieser Steuerelemente finden Sie in Anhang D: Sichern Built-In Administratorkonten in Active Directory.

Steuerelemente für integrierte Administratorkonten

Das Ziel der Implementierung der hier beschriebenen Einstellungen besteht im Verhindern, dass das Administratorkonto jeder Domäne (keine Gruppe) verwendet werden kann, es sei denn, eine Reihe von Steuerelementen wird umgekehrt. Durch die Implementierung dieser Kontrollen und die Überwachung der Administratorkonten auf Änderungen können Sie die Wahrscheinlichkeit eines erfolgreichen Angriffs erheblich reduzieren, indem Sie das Administratorkonto einer Domäne nutzen. Für das Administratorkonto in jeder Domäne in Ihrer Gesamtstruktur sollten Sie die folgenden Einstellungen konfigurieren.

Aktivieren Sie das Flag "Konto ist vertraulich und kann nicht delegiert werden" für das Konto.

Standardmäßig können alle Konten in Active Directory delegiert werden. Die Delegierung ermöglicht es einem Computer oder Dienst, die Anmeldeinformationen für ein Konto, das sich beim Computer oder Dienst authentifiziert hat, anderen Computern zu präsentieren, um Dienste im Namen des Kontos zu erhalten. Wenn Sie aktivieren, dass das Attribut Konto ist vertraulich ist und nicht für ein domänenbasiertes Konto delegiert werden kann, können die Anmeldeinformationen des Kontos nicht anderen Computern oder Diensten im Netzwerk präsentiert werden. Dies schränkt Angriffe ein, die die Delegierung nutzen, um die Anmeldeinformationen des Kontos auf anderen Systemen zu verwenden.

Aktivieren des Flags "Smartcard ist für interaktive Anmeldung erforderlich" für das Konto

Wenn Sie die Smartcard für das interaktive Anmeldeattribut für ein Konto aktivieren, setzt Windows das Kennwort des Kontos auf einen zufälligen 120-Zeichen-Wert zurück. Indem Sie dieses Flag für integrierte Administratorkonten festlegen, stellen Sie sicher, dass das Kennwort für das Konto nicht nur lang und komplex, sondern auch für keinen Benutzer bekannt ist. Technisch gesehen ist es nicht erforderlich, Smartcards für die Konten zu erstellen, bevor sie dieses Attribut aktivieren. Nach Möglichkeit sollten smartcards jedoch für jedes Administratorkonto erstellt werden, bevor die Kontoeinschränkungen konfiguriert werden und die Smartcards an sicheren Speicherorten gespeichert werden.

Obwohl das Festlegen der Smartcard für das Flag für die interaktive Anmeldung erforderlich ist, wird das Kennwort des Kontos zurückgesetzt, es verhindert jedoch nicht, dass ein Benutzer mit Rechten zum Zurücksetzen des Kennworts des Kontos das Konto auf einen bekannten Wert setzt und den Namen und das neue Kennwort des Kontos für den Zugriff auf Ressourcen im Netzwerk verwendet. Aus diesem Grund sollten Sie die folgenden zusätzlichen Steuerelemente für das Konto implementieren.

Konfigurieren von Gruppenrichtlinienobjekten zum Einschränken der Administratorkonten von Domänen auf Domain-Joined Systemen

Obwohl das Deaktivieren des Administratorkontos in einer Domäne das Konto effektiv unbrauchbar macht, sollten Sie zusätzliche Einschränkungen für das Konto implementieren, falls das Konto versehentlich oder böswillig aktiviert wird. Obwohl diese Steuerelemente letztendlich vom Administratorkonto rückgängig gemacht werden können, besteht das Ziel im Erstellen von Kontrollen, die den Fortschritt eines Angreifers verlangsamen und den Schaden begrenzen, den das Konto verursachen kann.

Fügen Sie in mindestens einem Gruppenrichtlinienobjekt, das Sie erstellen und mit Arbeitsstations- und Mitgliedsserver-OUs in jeder Domäne verknüpfen, das Administratorkonto jeder Domäne den folgenden Benutzerrechten unter Computerkonfiguration\Richtlinien\Windows Einstellungen\Sicherheit Einstellungen\Lokale Richtlinien\Benutzerrechtezuweisungen hinzu:

  • Zugriff vom Netzwerk auf diesen Computer verweigern
  • Anmelden als Batchauftrag verweigern
  • Anmelden als Dienst verweigern
  • Anmelden über Remotedesktopdienste verweigern

Hinweis

Wenn Sie dieser Einstellung lokale Administratorkonten hinzufügen, müssen Sie angeben, ob Sie lokale Administratorkonten oder Domänenadministratorkonten konfigurieren. Wenn Sie z. B. das lokale Administratorkonto der NWDOMAINS-Domäne zu diesen ny-Rechten hinzufügen möchten, müssen Sie entweder das Konto als NWDOMAINS\Administrator eingeben oder zum lokalen Administratorkonto für die NWDOMAINS-Domäne navigieren. Wenn Sie administrator in diese Benutzerrechteeinstellungen in der Gruppenrichtlinienobjekt-Editor eingeben, schränken Sie das lokale Administratorkonto auf jedem Computer ein, auf den das Gruppenrichtlinienobjekt angewendet wird.

Es wird empfohlen, lokale Administratorkonten auf Mitgliedsservern und Arbeitsstationen auf die gleiche Weise wie domänenbasierte Administratorkonten zu beschränken. Daher sollten Sie in der Regel das Administratorkonto für jede Domäne in der Gesamtstruktur und das Administratorkonto für die lokalen Computer diesen Einstellungen für Benutzerrechte hinzufügen.

Konfigurieren von Gruppenrichtlinienobjekten zum Einschränken von Administratorkonten auf Domänencontrollern

In jeder Domäne in der Gesamtstruktur sollte die Richtlinie Standarddomänencontroller oder eine mit der Organisationseinheit Domänencontroller verknüpfte Richtlinie geändert werden, um das Administratorkonto jeder Domäne den folgenden Benutzerrechten unter Computerkonfiguration\Richtlinien\Windows Einstellungen\Sicherheit Einstellungen\Lokale Richtlinien\Benutzerrechtezuweisungen hinzuzufügen:

  • Zugriff vom Netzwerk auf diesen Computer verweigern
  • Anmelden als Batchauftrag verweigern
  • Anmelden als Dienst verweigern
  • Anmelden über Remotedesktopdienste verweigern

Hinweis

Diese Einstellungen stellen sicher, dass das lokale Administratorkonto nicht zum Herstellen einer Verbindung mit einem Domänencontroller verwendet werden kann, obwohl sich das Konto, sofern aktiviert, lokal bei Domänencontrollern anmelden kann. Da dieses Konto nur in Notfallwiederherstellungsszenarien aktiviert und verwendet werden soll, wird davon ausgesehen, dass physischer Zugriff auf mindestens einen Domänencontroller verfügbar ist oder dass andere Konten mit Zugriffsberechtigungen für Domänencontroller remote verwendet werden können.

Konfigurieren der Überwachung integrierter Administratorkonten

Wenn Sie das Administratorkonto jeder Domäne gesichert und deaktiviert haben, sollten Sie die Überwachung so konfigurieren, dass änderungen am Konto überwacht werden. Wenn das Konto aktiviert ist, das Kennwort zurückgesetzt wird oder andere Änderungen am Konto vorgenommen werden, sollten Warnungen an die Benutzer oder Teams gesendet werden, die für die Verwaltung von AD DS verantwortlich sind, sowie an die Teams für die Reaktion auf Vorfälle in Ihrer Organisation.

Schützen von Administratoren, Domänenadministratoren und Enterprise Administratorgruppen

Sichern Enterprise Administratorgruppen

Die Gruppe Enterprise-Administratoren, die sich in der Stammdomäne der Gesamtstruktur befindet, sollte täglich keine Benutzer enthalten, mit ausnahme des lokalen Administratorkontos der Domäne, vorausgesetzt, sie ist wie zuvor beschrieben und in Anhang D: Schützen von Built-In-Administratorkonten in Active Directory geschützt.

Wenn EA-Zugriff erforderlich ist, sollten die Benutzer, deren Konten EA-Rechte und -Berechtigungen benötigen, vorübergehend in der Gruppe Enterprise Administrator platziert werden. Obwohl Benutzer die Konten mit sehr privilegierten Berechtigungen verwenden, sollten ihre Aktivitäten überwacht und vorzugsweise mit einem Benutzer ausgeführt werden, der die Änderungen vorsät, und einem anderen Benutzer, der die Änderungen beobachtet, um die Wahrscheinlichkeit eines unbeabsichtigten Missbrauchs oder einer Fehlkonfiguration zu minimieren. Wenn die Aktivitäten abgeschlossen sind, sollten die Konten aus der EA-Gruppe entfernt werden. Dies kann über manuelle Verfahren und dokumentierte Prozesse, softwarebasierte PiM-/PAM-Software (Privileged Identity/Access Management) von Drittanbietern oder eine Kombination aus beidem erreicht werden. Richtlinien zum Erstellen von Konten, die zum Steuern der Mitgliedschaft privilegierter Gruppen in Active Directory verwendet werden können, finden Sie unter Attraktive Konten für Diebstahl von Anmeldeinformationen. Ausführliche Anweisungen finden Sie in Anhang I: Erstellen von Verwaltungskonten für geschützte Konten und Gruppen in Active Directory.

Enterprise Administratoren sind standardmäßig Mitglieder der integrierten Administratorengruppe in jeder Domäne in der Gesamtstruktur. Das Entfernen Enterprise Administratorgruppe aus den Administratorengruppen in jeder Domäne ist eine ungeeignete Änderung, da im Falle eines Notfallwiederherstellungsszenarios für die Gesamtstruktur wahrscheinlich EA-Rechte erforderlich sind. Wenn die Enterprise Admins-Gruppe aus Administratorengruppen in einer Gesamtstruktur entfernt wurde, sollte sie der Gruppe Administratoren in jeder Domäne hinzugefügt werden, und die folgenden zusätzlichen Steuerelemente sollten implementiert werden:

  • Wie bereits beschrieben, sollte die Gruppe Enterprise-Administratoren täglich keine Benutzer enthalten, mit Ausnahme des Administratorkontos der Gesamtstruktur-Stammdomäne, das wie in Anhang D: Schützen von Built-In-Administratorkonten in Active Directorybeschrieben geschützt werden sollte.
  • In Gruppenrichtlinienobjekten, die mit Organisationsgruppen verknüpft sind, die Mitgliedsserver und Arbeitsstationen in jeder Domäne enthalten, sollte die EA-Gruppe den folgenden Benutzerrechten hinzugefügt werden:
    • Zugriff vom Netzwerk auf diesen Computer verweigern
    • Anmelden als Batchauftrag verweigern
    • Anmelden als Dienst verweigern
    • Lokal anmelden verweigern
    • Verweigern der Anmeldung über Remotedesktopdienste.

Dadurch wird verhindert, dass sich Mitglieder der EA-Gruppe bei Mitgliedsservern und Arbeitsstationen anmelden. Wenn Jumpserver zum Verwalten von Domänencontrollern und Active Directory verwendet werden, stellen Sie sicher, dass sich Sprungserver in einer Organisationseinheit befinden, mit der die restriktiven Gruppenrichtlinienobjekte nicht verknüpft sind.

  • Die Überwachung sollte so konfiguriert werden, dass Warnungen gesendet werden, wenn Änderungen an den Eigenschaften oder der Mitgliedschaft in der EA-Gruppe vorgenommen werden. Diese Warnungen sollten mindestens an Benutzer oder Teams gesendet werden, die für die Active Directory-Verwaltung und die Reaktion auf Vorfälle verantwortlich sind. Sie sollten auch Prozesse und Verfahren zum vorübergehenden Aufpopulieren der EA-Gruppe definieren, einschließlich Benachrichtigungsverfahren, wenn eine legitime Auf population der Gruppe ausgeführt wird.

Schützen von Domänenadministratorgruppen

Wie bei der Gruppe Enterprise-Administratoren sollte die Mitgliedschaft in Domänen-Admins-Gruppen nur in Build- oder Notfallwiederherstellungsszenarien erforderlich sein. Es sollten keine täglichen Benutzerkonten in der DA-Gruppe vorhanden sein, mit Ausnahme des lokalen Administratorkontos für die Domäne, sofern es wie in Anhang D: Sichern von Built-In-Administratorkonten in Active Directorybeschrieben gesichert wurde.

Wenn DA-Zugriff erforderlich ist, sollten die Konten, die diese Zugriffsebene benötigen, vorübergehend in der DA-Gruppe für die gewünschte Domäne platziert werden. Obwohl die Benutzer die Konten mit sehr privilegierten Berechtigungen verwenden, sollten Aktivitäten überwacht und vorzugsweise mit einem Benutzer ausgeführt werden, der die Änderungen vorsät, und einem anderen Benutzer, der die Änderungen beobachtet, um die Wahrscheinlichkeit eines unbeabsichtigten Missbrauchs oder einer Fehlkonfiguration zu minimieren. Wenn die Aktivitäten abgeschlossen sind, sollten die Konten aus der Gruppe Domänen-Admins entfernt werden. Dies kann mit manuellen Verfahren und dokumentierten Prozessen, mit softwarebasiertem PiM-/PAM-Software (Privileged Identity/Access Management) von Drittanbietern oder einer Kombination aus beidem erreicht werden. Richtlinien zum Erstellen von Konten, die zum Steuern der Mitgliedschaft privilegierter Gruppen in Active Directory verwendet werden können, finden Sie in Anhang I: Erstellen von Verwaltungskonten für geschützte Konten und Gruppen in Active Directory.

Domänenadministratoren sind standardmäßig Mitglieder der lokalen Administratorgruppen auf allen Mitgliedsservern und Arbeitsstationen in ihren jeweiligen Domänen. Diese Standardschachtelung sollte nicht geändert werden, da sie sich auf die Unterstützungs- und Notfallwiederherstellungsoptionen ausdrückt. Wenn Domänenadministratorgruppen aus den lokalen Administratorgruppen auf den Mitgliedsservern entfernt wurden, sollten sie der Gruppe Administratoren auf jedem Mitgliedsserver und jeder Arbeitsstation in der Domäne über eingeschränkte Gruppeneinstellungen in verknüpften Gruppenrichtlinienobjekten hinzugefügt werden. Die folgenden allgemeinen Steuerelemente, die in Anhang F: Schützen von Domänenadministratorgruppen in Active Directory ausführlich beschrieben werden, sollten ebenfalls implementiert werden.

Für die Gruppe Domänen-Admins in jeder Domäne in der Gesamtstruktur:

  1. Entfernen Sie alle Mitglieder aus der DA-Gruppe, mit Ausnahme des integrierten Administratorkontos für die Domäne, sofern es wie in Anhang D: Sichern von Built-In-Administratorkonten in Active Directorybeschrieben gesichert wurde.

  2. In Gruppenrichtlinienobjekten, die mit Organisationsgruppen verknüpft sind, die Mitgliedsserver und Arbeitsstationen in jeder Domäne enthalten, sollte die DA-Gruppe den folgenden Benutzerrechten hinzugefügt werden:

    • Zugriff vom Netzwerk auf diesen Computer verweigern
    • Anmelden als Batchauftrag verweigern
    • Anmelden als Dienst verweigern
    • Lokal anmelden verweigern
    • Anmelden über Remotedesktopdienste verweigern

    Dadurch wird verhindert, dass sich Mitglieder der DA-Gruppe bei Mitgliedsservern und Arbeitsstationen anmelden. Wenn Jumpserver zum Verwalten von Domänencontrollern und Active Directory verwendet werden, stellen Sie sicher, dass sich Sprungserver in einer Organisationseinheit befinden, mit der die restriktiven Gruppenrichtlinienobjekte nicht verknüpft sind.

  3. Die Überwachung sollte so konfiguriert werden, dass Warnungen gesendet werden, wenn Änderungen an den Eigenschaften oder der Mitgliedschaft der DA-Gruppe vorgenommen werden. Diese Warnungen sollten mindestens an Benutzer oder Teams gesendet werden, die für AD DS und Reaktion auf Vorfälle verantwortlich sind. Sie sollten auch Prozesse und Prozeduren zum vorübergehenden Aufsenden der DA-Gruppe definieren, einschließlich Benachrichtigungsverfahren, wenn eine legitime Auf population der Gruppe ausgeführt wird.

Schützen von Administratorgruppen in Active Directory

Wie bei den EA- und DA-Gruppen sollte die Mitgliedschaft in der Gruppe Administratoren (BA) nur in Build- oder Notfallwiederherstellungsszenarien erforderlich sein. Es sollten keine täglichen Benutzerkonten in der Gruppe Administratoren vorhanden sein, mit Ausnahme des lokalen Administratorkontos für die Domäne, wenn es wie in Anhang D: Schützen von Built-In-Administratorkonten in Active Directorybeschrieben gesichert wurde.

Wenn Administratorzugriff erforderlich ist, sollten die Konten, die diese Zugriffsebene benötigen, vorübergehend in der Gruppe Administratoren für die gewünschte Domäne platziert werden. Obwohl die Benutzer die Konten mit stark privilegierten Berechtigungen verwenden, sollten Aktivitäten überwacht und vorzugsweise mit einem Benutzer ausgeführt werden, der die Änderungen vorsät, und einem anderen Benutzer, der die Änderungen beobachtet, um die Wahrscheinlichkeit eines unbeabsichtigten Missbrauchs oder einer Fehlkonfiguration zu minimieren. Nachdem die Aktivitäten abgeschlossen wurden, sollten die Konten sofort aus der Gruppe Administratoren entfernt werden. Dies kann mit manuellen Verfahren und dokumentierten Prozessen, mit softwarebasiertem PiM-/PAM-Software (Privileged Identity/Access Management) von Drittanbietern oder einer Kombination aus beidem erreicht werden.

Administratoren sind standardmäßig die Besitzer der meisten AD DS in ihren jeweiligen Domänen. Die Mitgliedschaft in dieser Gruppe kann in Build- und Notfallwiederherstellungsszenarien erforderlich sein, in denen der Besitz oder die Fähigkeit zum Übernehmen des Besitzes von Objekten erforderlich ist. Darüber hinaus erben DAs und EAs aufgrund ihrer Standardmitgliedschaft in der Gruppe Administratoren eine Reihe ihrer Rechte und Berechtigungen. Die Standardgruppenschachtelung für privilegierte Gruppen in Active Directory sollte nicht geändert werden, und die Administratorengruppe jeder Domäne sollte wie in Anhang G:Schützen von Administratorgruppen in Active Directory und in den allgemeinen Anweisungen unten beschrieben geschützt werden.

  1. Entfernen Sie alle Mitglieder aus der Gruppe Administratoren, mit Ausnahme des lokalen Administratorkontos für die Domäne, sofern es wie in Anhang D: Sichern von Built-In-Administratorkonten in Active Directorybeschrieben geschützt wurde.

  2. Mitglieder der Gruppe Administratoren der Domäne sollten sich nie bei Mitgliedsservern oder Arbeitsstationen anmelden müssen. In mindestens einem Gruppenrichtlinienobjekt, das mit Arbeitsstations- und Mitgliedsserver-OUs in jeder Domäne verknüpft ist, sollte die Gruppe Administratoren den folgenden Benutzerrechten hinzugefügt werden:

    • Zugriff vom Netzwerk auf diesen Computer verweigern
    • Anmelden als Batchauftrag verweigern,
    • Anmelden als Dienst verweigern
    • Dadurch wird verhindert, dass Mitglieder der Gruppe Administratoren zum Anmelden oder Herstellen einer Verbindung mit Mitgliedsservern oder Arbeitsstationen verwendet werden (es sei denn, es werden zuerst mehrere Kontrollen verletzt), wo ihre Anmeldeinformationen zwischengespeichert und dadurch kompromittiert werden können. Ein privilegiertes Konto sollte niemals für die Anmeldung bei einem System mit geringeren Berechtigungen verwendet werden, und das Erzwingen dieser Kontrollen bietet Schutz vor einer Reihe von Angriffen.
  3. In der Organisationseinheit der Domänencontroller in jeder Domäne in der Gesamtstruktur sollten der Gruppe Administratoren die folgenden Benutzerrechte erteilt werden (sofern sie nicht bereits über diese Rechte verfügen), die es den Mitgliedern der Gruppe Administratoren ermöglichen, funktionen auszuführen, die für ein gesamtstrukturweites Notfallwiederherstellungsszenario erforderlich sind:

    • Auf diesen Computer vom Netzwerk aus zugreifen.
    • Lokale Anmeldung zulassen
    • Anmelden über Remotedesktopdienste zulassen
  4. Die Überwachung sollte so konfiguriert werden, dass Warnungen gesendet werden, wenn Änderungen an den Eigenschaften oder der Mitgliedschaft in der Gruppe Administratoren vorgenommen werden. Diese Warnungen sollten mindestens an Mitglieder des Teams gesendet werden, das für die verwaltung AD DS ist. Warnungen sollten auch an Mitglieder des Sicherheitsteams gesendet werden, und Es sollten Verfahren zum Ändern der Mitgliedschaft in der Gruppe "Administratoren" definiert werden. Diese Prozesse sollten insbesondere ein Verfahren enthalten, mit dem das Sicherheitsteam benachrichtigt wird, wenn die Gruppe Administratoren geändert wird, sodass warnungsmeldungen beim Senden erwartet werden und kein Alarm ausgelöst wird. Darüber hinaus sollten Prozesse implementiert werden, um das Sicherheitsteam zu benachrichtigen, wenn die Verwendung der Gruppe Administratoren abgeschlossen ist und die verwendeten Konten aus der Gruppe entfernt wurden.

Hinweis

Wenn Sie Einschränkungen für die Gruppe Administratoren in Gruppenrichtlinienobjekten implementieren, wendet Windows die Einstellungen zusätzlich zur Gruppe Administratoren auf Mitglieder der lokalen Administratorgruppe eines Computers an. Aus diesem Grund sollten Sie beim Implementieren von Einschränkungen für die Gruppe "Administratoren" vorsichtig vorgehen. Es wird zwar empfohlen, Netzwerk-, Batch- und Dienstanmeldungen für Mitglieder der Gruppe "Administratoren" zu verhindern, aber sie sollten lokale Anmeldungen oder Anmeldungen nicht über die Remotedesktopdienste. Das Blockieren dieser Anmeldetypen kann die legitime Verwaltung eines Computers durch Mitglieder der lokalen Administratorgruppe blockieren. Der folgende Screenshot zeigt Konfigurationseinstellungen, die den Missbrauch von integrierten lokalen Konten und Domänenadministratorkonten sowie den Missbrauch von integrierten lokalen oder Domänenadministratorgruppen blockieren. Beachten Sie, dass das Benutzerrecht Anmeldung über Remotedesktopdienste verweigern die Gruppe Administratoren nicht enthält, da die Einbeziehung in diese Einstellung diese Anmeldungen auch für Konten blockieren würde, die Mitglieder der Administratorengruppe des lokalen Computers sind. Wenn Dienste auf Computern so konfiguriert sind, dass sie im Kontext einer der in diesem Abschnitt beschriebenen privilegierten Gruppen ausgeführt werden, kann die Implementierung dieser Einstellungen dazu führen, dass Dienste und Anwendungen fehlschlagen. Daher sollten Sie wie bei allen Empfehlungen in diesem Abschnitt die Einstellungen für die Anwendbarkeit in Ihrer Umgebung gründlich testen.

Administratormodelle mit geringsten Rechten

Role-Based Access Controls (RBAC) für Active Directory

Im Allgemeinen sind rollenbasierte Zugriffssteuerungen (Role-Based Access Controls, RBAC) ein Mechanismus zum Gruppieren von Benutzern und zum Bereitstellen des Zugriffs auf Ressourcen basierend auf Geschäftsregeln. Im Fall von Active Directory ist die Implementierung von RBAC für AD DS der Prozess der Erstellung von Rollen, an die Rechte und Berechtigungen delegiert werden, damit Mitglieder der Rolle täglich Administrative Aufgaben ausführen können, ohne ihnen übermäßige Berechtigungen zu gewähren. RBAC für Active Directory kann mit nativen Tools und Schnittstellen entworfen und implementiert werden, indem Sie Software nutzen, die Sie möglicherweise bereits besitzen, indem Sie Produkte von Drittanbietern oder eine beliebige Kombination dieser Ansätze kaufen. Dieser Abschnitt enthält keine Schritt-für-Schritt-Anweisungen zum Implementieren von RBAC für Active Directory, sondern erläutert die Faktoren, die Sie bei der Auswahl eines Ansatzes zur Implementierung von RBAC in Ihren AD DS berücksichtigen sollten.

Native Ansätze für RBAC für Active Directory

In der einfachsten RBAC-Implementierung können Sie Rollen als AD DS-Gruppen implementieren und Rechte und Berechtigungen an die Gruppen delegieren, die ihnen die tägliche Verwaltung innerhalb des festgelegten Bereichs der Rolle ermöglichen.

In einigen Fällen können vorhandene Sicherheitsgruppen in Active Directory verwendet werden, um Einer Auftragsfunktion entsprechende Rechte und Berechtigungen zu gewähren. Wenn z. B. bestimmte Mitarbeiter in Ihrer IT-Organisation für die Verwaltung und Wartung von DNS-Zonen und -Einträgen verantwortlich sind, kann die Delegierung dieser Zuständigkeiten so einfach wie das Erstellen eines Kontos für jeden DNS-Administrator und das Hinzufügen zur Gruppe DNS-Administratoren in Active Directory sein. Im Gegensatz zu gruppen mit höheren Berechtigungen verfügt die GRUPPE DNS-Administratoren über wenige leistungsstarke Rechte in Active Directory, obwohl Mitgliedern dieser Gruppe Berechtigungen delegiert wurden, die ihnen die Verwaltung von DNS ermöglichen, aber weiterhin kompromittiert werden und Missbrauch zu Rechteerweiterungen führen kann.

In anderen Fällen müssen Sie möglicherweise Sicherheitsgruppen erstellen und Rechte und Berechtigungen an Active Directory-Objekte, Dateisystemobjekte und Registrierungsobjekte delegieren, damit Mitglieder der Gruppen bestimmte administrative Aufgaben ausführen können. Wenn Ihre Helpdesk-Operatoren beispielsweise für das Zurücksetzen vergessener Kennwörter, die Unterstützung von Benutzern bei Konnektivitätsproblemen und die Problembehandlung von Anwendungseinstellungen verantwortlich sind, müssen Sie möglicherweise Delegierungseinstellungen für Benutzerobjekte in Active Directory mit Berechtigungen kombinieren, mit denen Helpdeskbenutzer eine Remoteverbindung mit den Computern der Benutzer herstellen können, um die Konfigurationseinstellungen der Benutzer anzeigen oder ändern zu können. Für jede Rolle, die Sie definieren, sollten Sie Dies identifizieren:

  1. Welche Aufgaben Mitglieder der Rolle täglich ausführen und welche Aufgaben seltener ausgeführt werden.
  2. Auf welchen Systemen und in welchen Anwendungen Mitgliedern einer Rolle Rechte und Berechtigungen gewährt werden sollen.
  3. Welchen Benutzern die Mitgliedschaft in einer Rolle gewährt werden soll.
  4. Wie die Verwaltung von Rollenmitgliedschaften ausgeführt wird.

In vielen Umgebungen kann es schwierig sein, rollenbasierte Zugriffssteuerungen für die Verwaltung einer Active Directory-Umgebung manuell zu erstellen und zu verwalten. Wenn Sie über klar definierte Rollen und Zuständigkeiten für die Verwaltung Ihrer IT-Infrastruktur verfügen, sollten Sie zusätzliche Tools nutzen, um Sie bei der Erstellung einer verwaltbaren nativen RBAC-Bereitstellung zu unterstützen. Wenn z. B. Forefront Identity Manager (FIM) in Ihrer Umgebung verwendet wird, können Sie FIM verwenden, um die Erstellung und Auflastung von Administratorrollen zu automatisieren, was die laufende Verwaltung erleichtern kann. Wenn Sie Microsoft Endpoint Configuration Manager und System Center Operations Manager (SCOM) verwenden, können Sie anwendungsspezifische Rollen verwenden, um Verwaltungs- und Überwachungsfunktionen zu delegieren und auch eine einheitliche Konfiguration und Überwachung für alle Systeme in der Domäne zu erzwingen. Wenn Sie eine Public Key-Infrastruktur (PKI) implementiert haben, können Sie Smartcards für IT-Mitarbeiter aus- und fordern, die für die Verwaltung der Umgebung verantwortlich sind. Mit FIM Credential Management (FIM CM) können Sie sogar die Verwaltung von Rollen und Anmeldeinformationen für Ihre Verwaltungsmitarbeiter kombinieren.

In anderen Fällen kann es für eine Organisation vorzuziehen sein, die Bereitstellung von RBAC-Software von Drittanbietern in Betracht zu ziehen, die "out-of-box"-Funktionen bietet. Kommerzielle COTS-Lösungen (Standard) für RBAC für Active Directory, Windows und nicht Windows-Verzeichnisse und Betriebssysteme werden von einer Reihe von Anbietern angeboten. Bei der Wahl zwischen nativen Lösungen und Produkten von Drittanbietern sollten Sie die folgenden Faktoren berücksichtigen:

  1. Budget: Wenn Sie in die Entwicklung von RBAC mit Software und Tools investieren, die Sie möglicherweise bereits besitzen, können Sie die Softwarekosten für die Bereitstellung einer Lösung senken. Wenn Sie jedoch nicht über Mitarbeiter verfügen, die erfahrungs in der Erstellung und Bereitstellung nativer RBAC-Lösungen sind, müssen Sie möglicherweise Beratungsressourcen für die Entwicklung Ihrer Lösung nutzen. Sie sollten die erwarteten Kosten für eine benutzerdefinierte Lösung sorgfältig abwägen und die Kosten für die Bereitstellung einer "vorgefertigten" Lösung abwägen, insbesondere wenn Ihr Budget begrenzt ist.
  2. Zusammensetzung der IT-Umgebung: Wenn Ihre Umgebung hauptsächlich aus Windows-Systemen besteht oder Sie Active Directory bereits für die Verwaltung von Nicht-Windows-Systemen und -Konten nutzen, können benutzerdefinierte native Lösungen die optimale Lösung für Ihre Anforderungen bereitstellen. Wenn Ihre Infrastruktur viele Systeme enthält, auf denen Windows nicht ausgeführt wird und die nicht von Active Directory verwaltet werden, müssen Sie möglicherweise Optionen für die Verwaltung von nicht Windows-Systemen getrennt von der Active Directory-Umgebung in Betracht ziehen.
  3. Berechtigungsmodell in der Lösung: Wenn ein Produkt auf der Platzierung seiner Dienstkonten in Gruppen mit hohen Berechtigungen in Active Directory basiert und keine Optionen bietet, die keine übermäßigen Berechtigungen für die RBAC-Software erfordern, haben Sie die Active Directory-Angriffsfläche nicht wirklich reduziert, sondern nur die Zusammensetzung der gruppen mit den meisten Berechtigungen im Verzeichnis geändert. Wenn ein Anwendungsanbieter keine Kontrollen für Dienstkonten bereitstellen kann, die die Wahrscheinlichkeit minimieren, dass die Konten kompromittiert und böswillig verwendet werden, sollten Sie andere Optionen in Betracht ziehen.

Privileged Identity Management

Privileged Identity Management (PIM), manchmal auch als Privileged Account Management (PAM) oder Privileged Credential Management (PCM) bezeichnet, ist der Entwurf, die Konstruktion und die Implementierung von Ansätzen zur Verwaltung privilegierter Konten in Ihrer Infrastruktur. Im Allgemeinen bietet PIM Mechanismen, mit denen Konten temporäre Rechte und Berechtigungen gewährt werden, die zum Ausführen von Build- oder Breakfixfunktionen erforderlich sind, anstatt Berechtigungen dauerhaft an Konten angefügt zu lassen. Ob PIM-Funktionen manuell erstellt oder über die Bereitstellung von Drittanbietersoftware implementiert werden, kann eines oder mehrere der folgenden Features verfügbar sein:

  • Anmeldeinformationen "Tresore", bei denen Kennwörter für privilegierte Konten "ausgecheckt" und ein anfängliches Kennwort zugewiesen werden, und dann "eingecheckt", wenn Aktivitäten abgeschlossen wurden. Zu diesem Zeitpunkt werden Kennwörter für die Konten erneut zurückgesetzt.
  • Zeitgebundene Einschränkungen bei der Verwendung privilegierter Anmeldeinformationen
  • Einmalige Verwendung von Anmeldeinformationen
  • Workflowgenerierte Berechtigungsgewährung mit Überwachung und Berichterstellung von ausgeführten Aktivitäten und automatisches Entfernen von Berechtigungen, wenn Aktivitäten abgeschlossen oder die zugewiesene Zeit abgelaufen ist
  • Ersetzen von hart codierten Anmeldeinformationen wie Benutzernamen und Kennwörtern in Skripts durch Anwendungsprogrammierschnittstellen (APPLICATION Programming Interfaces, APIs), mit denen Anmeldeinformationen nach Bedarf aus Tresoren abgerufen werden können
  • Automatische Verwaltung von Dienstkontoanmeldeinformationen

Erstellen nicht privilegierter Konten zum Verwalten privilegierter Konten

Eine der Herausforderungen bei der Verwaltung privilegierter Konten ist, dass die Konten, die privilegierte und geschützte Konten und Gruppen verwalten können, standardmäßig privilegierte und geschützte Konten sind. Wenn Sie geeignete RBAC- und PIM-Lösungen für Ihre Active Directory-Installation implementieren, können die Lösungen Ansätze enthalten, die es Ihnen ermöglichen, die Mitgliedschaft der am besten privilegierten Gruppen im Verzeichnis effektiv zu entsäuern, und die Gruppen nur vorübergehend und bei Bedarf aufpopulieren.

Wenn Sie native RBAC und PIM implementieren, sollten Sie jedoch in Erwägung ziehen, Konten zu erstellen, die nicht über Berechtigungen verfügen und die einzige Funktion haben, privilegierte Gruppen in Active Directory bei Bedarf auf- und zu entsäuern. Anhang I: Erstellen von Verwaltungskonten für geschützte Konten und Gruppen in Active Directory enthält schritt-für-Schritt-Anweisungen, die Sie zum Erstellen von Konten für diesen Zweck verwenden können.

Implementieren robuster Authentifizierungssteuerelemente

Gesetz Nr. 6: Es gibt tatsächlich jemand, der versucht, Ihre Kennwörter zu erraten. - 10 Unveränderliche Gesetze der Sicherheitsverwaltung

Pass-the-Hash- und andere Angriffe zum Diebstahl von Anmeldeinformationen sind nicht spezifisch Windows Betriebssystemen und auch nicht neu. Der erste Pass-the-Hash-Angriff wurde 1997 erstellt. In der Vergangenheit erforderten diese Angriffe jedoch angepasste Tools, waren bei ihrem Erfolg treffer- oder missverfehlt, und angreifer mussten über ein relativ hohes Maß an Fähigkeiten verfügen. Die Einführung von frei verfügbaren, einfach zu verwendenden Tools, die Anmeldeinformationen nativ extrahieren, hat in den letzten Jahren zu einem exponentiellen Anstieg der Anzahl und des Erfolgs von Angriffen mit Diebstahl von Anmeldeinformationen führte. Angriffe mit Diebstahl von Anmeldeinformationen sind jedoch nicht die einzigen Mechanismen, mit denen Anmeldeinformationen gezielt verwendet und kompromittiert werden.

Obwohl Sie Kontrollen implementieren sollten, um Sie vor Angriffen mit Diebstahl von Anmeldeinformationen zu schützen, sollten Sie auch die Konten in Ihrer Umgebung identifizieren, die am wahrscheinlichsten von Angreifern als Ziel verwendet werden, und stabile Authentifizierungssteuerungen für diese Konten implementieren. Wenn Ihre Konten mit den meisten Berechtigungen die single-factor-Authentifizierung wie Benutzernamen und Kennwörter verwenden (beides ist "etwas, das Sie wissen", was ein Authentifizierungsfaktor ist), sind diese Konten schwach geschützt. Ein Angreifer benötigt nur Kenntnisse des Benutzernamens und des Kennworts, das dem Konto zugeordnet ist, und Pass-the-Hash-Angriffe sind nicht erforderlich. Der Angreifer kann sich als Benutzer bei allen Systemen authentifizieren, die Anmeldeinformationen für einzelne Faktoren akzeptieren.

Die Implementierung der mehrstufigen Authentifizierung schützt Sie zwar nicht vor Pass-the-Hash-Angriffen, aber die Implementierung der mehrstufigen Authentifizierung in Kombination mit geschützten Systemen kann dies ermöglichen. Weitere Informationen zum Implementieren geschützter Systeme finden Sie unter Implementieren sicherer administrativer Hosts,und die Authentifizierungsoptionen werden in den folgenden Abschnitten erläutert.

Allgemeine Authentifizierungssteuerelemente

Wenn Sie die mehrstufige Authentifizierung wie Smartcards noch nicht implementiert haben, sollten Sie dies in Erwägung ziehen. Smartcards implementieren hardwareerzwingten Schutz privater Schlüssel in einem Paar aus öffentlichem und privatem Schlüssel. So wird verhindert, dass auf den privaten Schlüssel eines Benutzers zugegriffen oder verwendet wird, es sei denn, der Benutzer stellt der Smartcard die richtige PIN, Kennung oder biometrische Kennung vor. Auch wenn die PIN oder Kennung eines Benutzers von einer Tastatureingabeprotokollierung auf einem kompromittierten Computer abgefangen wird, muss die Karte auch physisch vorhanden sein, damit ein Angreifer die PIN oder Kennung wiederverwenden kann.

In Fällen, in denen lange, komplexe Kennwörter aufgrund des Widerstands der Benutzer schwierig zu implementieren waren, bieten Smartcards einen Mechanismus, mit dem Benutzer relativ einfache PINs oder Passcodes implementieren können, ohne dass die Anmeldeinformationen anfällig für Brute-Force- oder Tabellenangriffe sind. Smartcard-PINs werden nicht in Active Directory oder lokalen SAM-Datenbanken gespeichert, obwohl Anmeldeinformationshashes weiterhin im durch LSASS geschützten Speicher auf Computern gespeichert werden können, auf denen Smartcards für die Authentifizierung verwendet wurden.

Zusätzliche Steuerelemente für VIP-Konten

Ein weiterer Vorteil der Implementierung von Smartcards oder anderen zertifikatbasierten Authentifizierungsmechanismen ist die Möglichkeit, die Authentifizierungsmechanismussicherung zum Schutz vertraulicher Daten zu nutzen, auf die VIP-Benutzer zugriffen können. Authentifizierungsmechanismussicherung ist in Domänen verfügbar, in denen die Funktionsebene auf Windows Server 2012 server 2008 R2 oder Windows Server 2008 R2 festgelegt ist. Wenn sie aktiviert ist, fügt authentication Mechanism Assurance dem Kerberos-Token eines Benutzers eine vom Administrator designierte globale Gruppenmitgliedschaft hinzu, wenn die Anmeldeinformationen des Benutzers während der Anmeldung mithilfe einer zertifikatbasierten Anmeldemethode authentifiziert werden.

Dadurch können Ressourcenadministratoren den Zugriff auf Ressourcen wie Dateien, Ordner und Drucker steuern. Dies basiert darauf, ob sich der Benutzer zusätzlich zum verwendeten Zertifikattyp mithilfe einer zertifikatbasierten Anmeldemethode anmeldet. Wenn sich ein Benutzer beispielsweise mithilfe einer Smartcard anmeldet, kann der Zugriff des Benutzers auf Ressourcen im Netzwerk anders angegeben werden als der Zugriff, wenn der Benutzer keine Smartcard verwendet (d. h. wenn sich der Benutzer durch Eingabe eines Benutzernamens und Kennworts anmeldet). Weitere Informationen zur Authentifizierungsmechanismussicherung finden Sie unter Authentifizierungsmechanismussicherung für AD DS in Windows Server 2008 R2 Schritt-für-Schritt-Anleitung.

Konfigurieren der Privilegierten Kontoauthentifizierung

Aktivieren Sie in Active Directory für alle Administratorkonten das Attribut Smartcard für interaktive Anmeldung erforderlich, und überwachen Sie änderungen an (mindestens) den Attributen auf der Registerkarte Konto für das Konto (z. B. cn, name, sAMAccountName, userPrincipalName und userAccountControl).

Obwohl das Festlegen der Smartcard für die interaktive Anmeldung bei Konten das Kennwort des Kontos auf einen zufälligen Wert mit 120 Zeichen zurückgesetzt und Smartcards für interaktive Anmeldungen erfordert, kann das Attribut dennoch von Benutzern mit Berechtigungen überschrieben werden, die es ihnen ermöglichen, Kennwörter für die Konten zu ändern, und die Konten können dann verwendet werden, um nicht interaktive Anmeldungen nur mit Benutzername und Kennwort zu erstellen.

In anderen Fällen können, je nach Konfiguration von Konten in Active Directory und Zertifikateinstellungen in Active Directory-Zertifikatdienste (AD CS) oder einer PKI eines Drittanbieters, UPN-Attribute (User Principal Name) für Administrator- oder VIP-Konten für eine bestimmte Art von Angriff verwendet werden, wie hier beschrieben.

UPN Hijacking für Zertifikatss spoofing

Obwohl eine gründliche Erörterung von Angriffen auf Public Key-Infrastrukturen (Public Key Infrastructures, PKIs) außerhalb des Rahmens dieses Dokuments liegt, sind Angriffe auf öffentliche und private PKIs seit 2008 exponentiell gestiegen. Sicherheitsverletzungen öffentlicher PKIs wurden allgemein bekannt gemacht, aber Angriffe auf die interne PKI einer Organisation sind vielleicht sogar noch produktiver. Bei einem solchen Angriff werden Active Directory und Zertifikate genutzt, damit ein Angreifer die Anmeldeinformationen anderer Konten auf eine Weise spoofen kann, die schwer zu erkennen ist.

Wenn ein Zertifikat für die Authentifizierung bei einem in die Domäne integrierten System präsentiert wird, werden die Inhalte des Attributs "Subject" oder "Subject Alternative Name" (SAN) im Zertifikat verwendet, um das Zertifikat einem Benutzerobjekt in Active Directory zu zuordnen. Abhängig vom Typ des Zertifikats und seiner Konstruktion enthält das Subject-Attribut in einem Zertifikat in der Regel den allgemeinen Namen (Common Name, CN) eines Benutzers, wie im folgenden Screenshot gezeigt.

Screenshot: Attribut "Subject" in einem Zertifikat enthält in der Regel den allgemeinen Namen eines Benutzers.

Standardmäßig erstellt Active Directory den CN eines Benutzers, indem der Vorname des Kontos + " " + Nachname verkettet wird. CN-Komponenten von Benutzerobjekten in Active Directory sind jedoch nicht erforderlich oder garantiert eindeutig, und das Verschieben eines Benutzerkontos an einen anderen Speicherort im Verzeichnis ändert den Distinguished Name (DN) des Kontos. Dies ist der vollständige Pfad zum Objekt im Verzeichnis, wie im unteren Bereich des vorherigen Screenshots gezeigt.

Da zertifikatssubjektnamen nicht als statisch oder eindeutig garantiert werden, werden die Inhalte des alternativen Subject-Namens häufig verwendet, um das Benutzerobjekt in Active Directory zu finden. Das SAN-Attribut für Zertifikate, die für Benutzer von Unternehmenszertifizierungsstellen (in Active Directory integrierte Zertifizierungsstellen) ausgestellt wurden, enthält in der Regel den UPN oder die E-Mail-Adresse des Benutzers. Da UPNs in einer AD DS-Gesamtstruktur garantiert eindeutig sind, wird das Auffinden eines Benutzerobjekts per UPN häufig als Teil der Authentifizierung mit oder ohne Zertifikate ausgeführt, die am Authentifizierungsprozess beteiligt sind.

Die Verwendung von UPNs in SAN-Attributen in Authentifizierungszertifikaten kann von Angreifern genutzt werden, um betrügerische Zertifikate zu erhalten. Wenn ein Angreifer ein Konto kompromittiert hat, das in der Lage ist, UPNs für Benutzerobjekte zu lesen und zu schreiben, wird der Angriff wie folgt implementiert:

Das UPN-Attribut für ein Benutzerobjekt (z. B. ein VIP-Benutzer) wird vorübergehend in einen anderen Wert geändert. Das SAM-Kontonamenattribut und der CN können zu diesem Zeitpunkt ebenfalls geändert werden, obwohl dies aus den oben beschriebenen Gründen in der Regel nicht erforderlich ist.

Wenn das UPN-Attribut für das Zielkonto geändert wurde, wird ein veraltetes, aktiviertes Benutzerkonto oder das UPN-Attribut eines neu erstellten Benutzerkontos in den Wert geändert, der ursprünglich dem Zielkonto zugewiesen wurde. Veraltete, aktivierte Benutzerkonten sind Konten, die über einen längeren Zeitraum nicht angemeldet, aber nicht deaktiviert wurden. Sie werden von Angreifern ins Visier genommen, die sich aus den folgenden Gründen "in klar verständlicher Sicht" verbergen möchten:

  1. Da das Konto aktiviert ist, aber in letzter Zeit nicht verwendet wurde, ist es unwahrscheinlich, dass die Verwendung des Kontos Warnungen auslöst, wie die Aktivierung eines deaktivierten Benutzerkontos möglich ist.
  2. Die Verwendung eines vorhandenen Kontos erfordert nicht die Erstellung eines neuen Benutzerkontos, das möglicherweise von Verwaltungsmitarbeitern bemerkt wird.
  3. Veraltete Benutzerkonten, die weiterhin aktiviert sind, sind in der Regel Mitglieder verschiedener Sicherheitsgruppen und erhalten Zugriff auf Ressourcen im Netzwerk, was den Zugriff und das "Einblenden" auf eine vorhandene Benutzerpopulation vereinfacht.

Das Benutzerkonto, für das der Ziel-UPN jetzt konfiguriert wurde, wird verwendet, um ein oder mehrere Zertifikate von der Active Directory-Zertifikatdienste.

Wenn Zertifikate für das Konto des Angreifers erhalten wurden, werden die UPNs für das "neue" Konto und das Zielkonto auf ihre ursprünglichen Werte zurückgegeben.

Der Angreifer verfügt nun über mindestens ein Zertifikat, das für die Authentifizierung bei Ressourcen und Anwendungen bereitgestellt werden kann, als wäre der Benutzer der VIP-Benutzer, dessen Konto vorübergehend geändert wurde. Obwohl eine vollständige Erörterung aller Möglichkeiten, wie Zertifikate und PKI von Angreifern als Ziel verwendet werden können, außerhalb des Rahmens dieses Dokuments liegt, wird dieser Angriffsmechanismus bereitgestellt, um zu veranschaulichen, warum Sie privilegierte konten und VIP-Konten in AD DS auf Änderungen überwachen sollten, insbesondere für Änderungen an attributen auf der Registerkarte Konto für das Konto (z. B. cn, name, sAMAccountName, userPrincipalName und userAccountControl). Zusätzlich zur Überwachung der Konten sollten Sie einschränken, wer die Konten auf eine möglichst kleine Gruppe von Administratorbenutzern ändern kann. Ebenso sollten die Konten von Administratorbenutzern geschützt und auf nicht autorisierte Änderungen überwacht werden.