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 stammt aus The Administrator Accounts Security Planning Guide (Administratorleitfaden zur Sicherheitsplanung für Konten), der erstmals am 1. April 1999 veröffentlicht wurde:

„In den meisten sicherheitsbezogenen Schulungskursen und Dokumentationen wird die Implementierung eines Prinzips der geringsten Rechte diskutiert, aber Organisationen befolgen es selten. Das Prinzip ist einfach, und bei korrekter Anwendung wird Ihre Sicherheit erheblich erhöht und Ihr Risiko verringert. Das Prinzip besagt, dass sich alle Benutzer*innen mit einem Benutzerkonto anmelden müssen, das über die minimal erforderlichen Berechtigungen zum Durchführen der aktuellen Aufgabe verfügt und keinen darüber hinausgehenden. Diese Vorgehensweise bietet Schutz vor bösartigem Code und anderen Angriffen. Das Prinzip gilt für Computer und die Benutzer*innen dieser Computer. Ein Grund, aus dem dieses Prinzip so gut funktioniert, ist der Zwang, interne Recherchen anzustellen. Beispielsweise müssen Sie die Zugriffsberechtigungen ermitteln, die ein Computer oder ein*e Benutzer*in wirklich benötigt, und diese dann implementieren. Für viele Organisationen mag diese Aufgabe zunächst sehr arbeitsintensiv erscheinen, sie ist jedoch ein wichtiger Schritt zum erfolgreichen Schutz Ihrer Netzwerkumgebung. Sie sollten allen Domänenadministratorbenutzer*innen Domänenberechtigungen nach dem Konzept der geringsten Rechte gewähren. Wenn sich beispielsweise ein*e Administrator*in mit einem privilegierten Konto anmeldet und versehentlich ein Virusprogramm ausführt, hat der Virus administrativen Zugriff auf den lokalen Computer und die gesamte Domäne. Wenn sich der bzw. die Administrator*in stattdessen mit einem nicht privilegierten (nicht administrativen) Konto angemeldet hätte, wäre der Schaden des Virus auf den lokalen Computer beschränkt, da er als lokale*r Computerbenutzer*in 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 zwischen den Gesamtstrukturen eine Vertrauensstellung besteht. Durch diese Taktik wird das Ausbreiten von Schäden verhindert, wenn es Angreifer*innen gelingt, eine verwaltete Gesamtstruktur zu beeinträchtigen. Organisationen sollten ihre Netzwerke regelmäßig überwachen, um vor der nicht autorisierten Eskalation von Berechtigungen zu schützen.“

Der folgende Auszug stammt aus dem Microsoft Windows Security Resource Kit, das erstmals 2005 veröffentlicht wurde:

„Stellen Sie sich Sicherheit immer als Gewähren der geringsten Menge an Berechtigungen vor, die für die Ausführung der Aufgabe erforderlich sind. Wenn eine Anwendung, die über zu viele Berechtigungen verfügt, beeinträchtigt wird, kann der oder die Angreifer*in den Angriff möglicherweise über die Möglichkeiten der Anwendung, wenn sie über die geringsten möglichen Berechtigungen verfügen würde, hinaus ausweiten. Untersuchen Sie beispielsweise die Folgen, wenn ein*e Netzwerkadministrator*in unwissentlich durch das Öffnen einer E-Mail-Anlage einen Virus startet. Wenn der oder die Administrator*in mit dem Domänenadministratorkonto angemeldet ist, verfügt der Virus über Administratorrechte auf allen Computern in der Domäne und somit uneingeschränkten Zugriff auf nahezu alle Daten im Netzwerk. Bei der Anmeldung mit einem lokalen Administratorkonto verfügt der Virus über Administratorrechte auf dem lokalen Computer und kann somit auf alle Daten auf dem Computer zugreifen und schädliche Software wie etwa eine Tastaturprotokollierungssoftware auf dem Computer installieren. Wenn der oder die Administrator*in mit einem normalen Benutzerkonto angemeldet ist, hat der Virus nur Zugriff auf die eigenen Daten der Person und kann keine schädliche Software installieren. Durch die Verwendung der geringsten erforderlichen Berechtigungen zum Lesen von E-Mails wird in diesem Beispiel der potenzielle Umfang der Beeinträchtigung erheblich verringert.“

Das Berechtigungsproblem

Die in den vorherigen Auszügen beschriebenen Prinzipien haben sich nicht geändert. Bei der Bewertung von Active Directory-Installationen stellen wir jedoch ohne Ausnahme eine übermäßig große Anzahl von Konten fest, denen Rechte und Berechtigungen weit über die für die tägliche Arbeit erforderlichen hinaus gewährt wurden. Die Größe der Umgebung wirkt sich auf die reine Anzahl von Konten mit übermäßigen Berechtigungen aus, aber nicht die Verhältnisse: Verzeichnisse verfügen möglicherweise über Dutzende von Konten in den Gruppen mit dem umfangreichsten Berechtigungen, während in großen Installationen Hunderte oder sogar Tausende auftreten können. Mit wenigen Ausnahmen und unabhängig von der Ausgereiftheit der Fähigkeiten und Ausrüstung von Angreifer*innen gehen diese in der Regel den Weg des geringsten Widerstands. Sie erhöhen die Komplexität ihrer Tools und Konzepte nur, wenn einfachere Mechanismen ausfallen oder von der Verteidigung abgewehrt werden.

Leider hat sich der Weg des geringsten Widerstands in vielen Umgebungen als übermäßige Nutzung von Konten mit horizontal und vertikal umfassenden Berechtigungen herausgestellt. Horizontal umfassende Berechtigungen ermöglichen es einem Konto, bestimmte Aktivitäten in einem großen Abschnitt der Umgebung auszuführen. Beispielsweise können Helpdeskmitarbeiter*innen Berechtigungen erteilt werden, mit denen sie die Kennwörter für viele Benutzerkonten zurücksetzen können.

Vertikal umfassende Berechtigungen werden auf ein schmales Segment der Population angewandt, z. B. die Gewährung von Administratorrechten auf einem Server für technische Mitarbeitende, damit sie Reparaturen ausführen können. Weder horizontal noch vertikal umfassende Berechtigungen sind notwendigerweise gefährlich, aber wenn vielen Konten in der Domäne dauerhaft umfassende Berechtigungen gewährt werden, kann eine Beeinträchtigung eines Kontos schnell verwendet werden, um die Umgebung für die Zwecke der Angreifer*innen umzukonfigurieren oder sogar große Teile der Infrastruktur zu zerstören.

Pass-the-Hash-Angriffe als bestimmte Art des Diebstahls von Anmeldeinformationen sind allgegenwärtig, da die Tools für die Ausführung frei verfügbar und einfach zu verwenden sind und da viele Umgebungen anfällig für Angriffe sind. Pass-the-Hash-Angriffe sind jedoch nicht das eigentliche Problem. Im Kern des Problems stehen zwei Erkenntnisse:

1. Für Angreifer*innen ist es in der Regel einfach, auf einem einzelnen Computer vertikal umfassende Berechtigungen zu erhalten und diese Rechte dann breit gefächert an andere Computer zu verteilen.
2. Es gibt in der Regel zu viele Konten, die dauerhaft über umfassende Berechtigungen in der gesamten Computerlandschaft verfügen.

Selbst wenn Pass-the-Hash-Angriffe eliminiert werden, können Angreifer*innen einfach andere Taktiken verwenden und müssen nicht die Strategie wechseln. Anstatt Schadsoftware zu installieren, die Tools zum Diebstahl von Anmeldeinformationen enthält, können sie Schadsoftware installieren, die Tastatureingaben protokolliert, oder eine Reihe anderer Ansätze zum Erfassen von Anmeldeinformationen nutzen, die in der gesamten Umgebung aktiv sind. Unabhängig von der Taktik bleiben die Ziele gleich: Konten mit horizontal und vertikal umfassenden Berechtigungen.

In beeinträchtigten Umgebungen sind übermäßige Berechtigungen nicht auf Active Directory beschränkt. Wenn eine Organisation gewohnheitsmäßig umfassendere Berechtigung gewährt als erforderlich, zieht sich dies in der Regel durch die gesamte Infrastruktur.

In Active Directory

In Active Directory wird häufig festgestellt, dass die Gruppen „Organisations-Admins“, „Dömanenadministratoren“ und „Administratoren“ eine übermäßige Anzahl von Konten enthalten. Meistens enthält die Gruppe „Organisations-Admins“ einer Organisation die wenigsten Mitglieder, die Gruppe „Dömanenadministratoren“ ein Vielfaches der Anzahl der Benutzer*innen in der Gruppe „Organisations-Admins“ und die Gruppe „Administratoren“ mehr Mitglieder als die anderen Gruppen zusammen. Dies liegt häufig an der Annahme, dass Administrator*innen über geringere Berechtigungen verfügen als Dömanenadministrator*innen oder Organisationsadministrator*innen. Obwohl die Rechte und Berechtigungen in jeder dieser Gruppen unterschiedlich sind, sollten sie effektiv als gleich mächtige Gruppen betrachtet werden, da sich ein Mitglied einer Gruppe selbst zu einem Mitglied der beiden anderen machen kann.

Auf Mitgliedsservern

Wenn wir die Mitglieder lokaler Administratorengruppen auf Mitgliedsservern in vielen Umgebungen abrufen, finden wir einige lokale Konten und Domänenkonten bis hin zu Dutzenden geschachtelten Gruppen, die gemeinsam betrachtet Hunderte oder sogar Tausende von Konten mit lokalen Administratorberechtigungen auf den Servern ergeben. In vielen Fällen sind Domänengruppen mit umfassenden Mitgliedschaften in den lokalen Administratorengruppen der Mitgliedsserver verschachtelt, ohne zu berücksichtigen, dass alle Benutzer*innen, die die Mitgliedschaften dieser Gruppen in der Domäne ändern können, die administrative Kontrolle über alle Systeme erhalten kann, auf denen die Gruppe in einer lokalen Administratorengruppe geschachtelt ist.

Auf Arbeitsstationen

Arbeitsstationen weisen zwar in der Regel deutlich weniger Mitglieder in ihren lokalen Administratorengruppen auf als Mitgliedsserver, Benutzer*innen wird jedoch in vielen Umgebungen die Mitgliedschaft in der lokalen Administratorengruppe auf ihren persönlichen Computern gewährt. In diesem Fall stellen diese Benutzer*innen selbst bei aktivierter Benutzerkontensteuerung ein erhöhtes Risiko für die Integrität ihrer Arbeitsstationen dar.

Wichtig

Sie sollten sorgfältig überlegen, ob Benutzer*innen Administratorrechte auf ihren Arbeitsstationen benötigen. Wenn das der Fall ist, besteht ein besserer Ansatz darin, ein separates lokales Konto auf dem Computer zu erstellen, das Mitglied der Gruppe „Administratoren“ ist. Wenn Benutzer*innen erweiterte Berechtigungen benötigen, können sie die Anmeldeinformationen dieses lokalen Kontos dafür angeben. Da es sich um ein lokales Konto handelt, kann es nicht dazu verwendet werden, andere Computer zu beeinträchtigen oder auf Domänenressourcen zuzugreifen. 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, öffnen Sie die Computer für Pass-the-Hash-Angriffe.

In Anwendungen

Bei Angriffen, die auf das geistige Eigentum einer Organisation abzielen, können Konten, denen umfassende Berechtigungen in Anwendungen gewährt wurden, zur Exfiltration von Daten herangezogen werden. Obwohl Konten, die Zugriff auf vertrauliche Daten haben, möglicherweise keine erweiterten Berechtigungen in der Domäne oder auf dem Betriebssystem haben, stellen Konten, die die Konfiguration einer Anwendung oder den Zugriff auf die von ihr bereitgestellten Informationen ändern können, ein Risiko dar.

In Datenrepositorys

Wie bei anderen Zielen können Angreifer*innen, die auf geistiges Eigentum in Form von Dokumenten und anderen Dateien zugreifen möchten, auf Konten, die den Zugriff auf Dateispeicher steuern, Konten mit direktem Zugriff auf Dateien oder sogar Gruppen oder Rollen mit Zugriff auf Dateien abzielen. 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*e Angreifer*in, der bzw. die die Mitgliedschaft in der Gruppe ändern kann, kompromittierte Konten hinzufügen und auf die Vertragsdokumente zugreifen. Wenn der Zugriff auf Dokumente durch Anwendungen wie SharePoint bereitgestellt wird, können Angreifer wie zuvor beschrieben die Anwendungen anzielen.

Verringern von Berechtigungen

Je größer und komplexer eine Umgebung ist, desto schwieriger sind die Verwaltung und der Schutz. In kleinen Organisationen kann das Überprüfen und Verringern von Berechtigungen relativ einfach sein. Jeder zusätzliche Server, jede Arbeitsstation, jedes Benutzerkonto und jede Anwendung in einer Organisation fügt jedoch 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. In der Regel sind dies die integrierten privilegierten Konten und Gruppen in Active Directory sowie privilegierte lokale Konten auf Arbeitsstationen und Mitgliedsservern.

Schützen lokaler Administratorkonten auf Arbeitsstationen und Mitgliedsservern

Auch wenn dieses Dokument wie bereits erläutert auf die Sicherung von Active Directory konzentriert ist, beginnen die meisten Angriffe auf das Verzeichnis als Angriffe auf einzelne Hosts. Vollständige Richtlinien zum Schutz lokaler Gruppen auf Mitgliedssystemen können nicht bereitgestellt werden, aber anhand der folgenden Empfehlungen können die lokalen Administratorkonten auf Arbeitsstationen und Mitgliedsservern besser geschützt werden.

Schützen lokaler Administratorkonten

Bei allen Versionen von Windows, die derzeit grundlegend unterstützt werden, ist das lokale Administratorkonto standardmäßig deaktiviert. Somit ist dieses Konto für Pass-the-Hash- und andere Angriffe zum Diebstahl von Anmeldeinformationen nicht nutzbar. In Umgebungen mit älteren Betriebssystemen oder aktivierten lokalen Administratorkonten können diese Konten dazu missbraucht werden, um Beeinträchtigungen auf Mitgliedsserver und Arbeitsstationen zu verteilen. Daher werden die folgenden Kontrollen für alle lokalen Administratorkonten auf in die Domäne eingebundenen Systemen empfohlen.

Ausführliche Anweisungen zum Implementieren dieser Kontrollen finden Sie in Anhang H: Schützen lokaler Administratorkonten und -gruppen. Bevor Sie diese Einstellungen implementieren, sollten Sie jedoch sicherstellen, dass derzeit keine lokalen Administratorkonten in der Umgebung verwendet werden, um Dienste auf Computern oder andere Aktivitäten auszuführen, für die diese Konten nicht verwendet werden sollten. Testen Sie diese Einstellungen gründlich, bevor Sie sie in einer Produktionsumgebung implementieren.

Kontrollen für lokale Administratorkonten

Integrierte Administratorkonten sollten niemals als Dienstkonten auf Mitgliedsservern verwendet werden. Auch zum Anmelden bei lokalen Computern sind sie nicht geeignet (außer im abgesicherten Modus, selbst wenn das Konto deaktiviert ist). Durch die hier beschriebenen Einstellungen soll verhindert werden, dass das lokale Administratorkonto eines Computers verwendet werden kann, sofern die Schutzkontrollen nicht vorher rückgängig gemacht werden. Wenn Sie diese Kontrollen implementieren und Administratorkonten auf Änderungen überwachen, können Sie die Erfolgswahrscheinlichkeit eines Angriffs auf lokale Administratorkonten erheblich verringern.

Konfigurieren von Gruppenrichtlinienobjekten zum Einschränken von Administratorkonten auf Systemen, die in die Domäne eingebunden sind

Fügen Sie in den Gruppenrichtlinienobjekten, die Sie erstellen und mit Organisationseinheiten für Arbeitsstationen und Mitgliedsserver in den einzelnen Domänen verknüpfen, den folgenden Benutzerrechten unter Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Zuweisen von Benutzerrechten das Administratorkonto 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 durch die Bezeichnung des Kontos an, ob Sie das lokale Administratorkonto oder das Administratorkonto der Domäne hinzufügen. Um beispielsweise diesen Verweigerungsrechten das Administratorkonto der Domäne NWTRADERS hinzuzufügen, geben Sie das Konto als NWTRADERS\Administrator ein oder navigieren zum Administratorkonto für die Domäne NWTRADERS. Um sicherzustellen, dass Sie das lokale Administratorkonto einschränken, geben Sie in diesen Benutzerberechtigungseinstellungen im Gruppenrichtlinienobjekt-Editor Administrator ein.

Hinweis

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

Durch diese Einstellungen wird sichergestellt, 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 dies sollte auch nicht versucht werden, da das lokale Administratorkonto eines Computers für die Verwendung in Notfallwiederherstellungsszenarien konzipiert ist.

Wenn ein Mitgliedsserver oder eine Arbeitsstation aus der Domäne getrennt wird, ohne dass anderen lokalen Konten Administratorrechte gewährt wurden, kann der Computer im abgesicherten Modus gestartet und das Administratorkonto aktiviert werden. Über das Konto können dann Reparaturen auf dem Computer durchgeführt werden. Nach Abschluss der Reparatur sollte das Administratorkonto wieder deaktiviert werden.

Schützen von lokalen privilegierten Konten und Gruppen in Active Directory

Regel Nummer 6: Ein Computer ist nur so sicher, wie der oder die Administrator*in vertrauenswürdig ist. - Zehn unumstößliche Sicherheitsgesetze (Version 2.0)

Die hier bereitgestellten Informationen sollen allgemeine Richtlinien für den Schutz der integrierten Konten und Gruppen mit den umfassendsten Berechtigungen in Active Directory darstellen. Ausführliche Anweisungen in einzelnen Schritten finden Sie auch in Anhang D: Sichern integrierter Administratorkonten in Active Directory, Anhang E: Schützen von Organisationsadministratorengruppen in Active Directory, Anhang F: Schützen von Domänenadministratorengruppen in Active Directory und Anhang G: Schützen von Administratorengruppen in Active Directory.

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

Schützen 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 Gruppen „Domänenadministratoren“ und „Administratoren“ in der Domäne, und wenn die Domäne die Stammdomäne der Gesamtstruktur darstellt, ist das Konto auch Mitglied der Gruppe „Organisations-Admins“. Die Verwendung des lokalen Administratorkontos einer Domäne sollte auf anfängliche Buildaktivitäten und ggf. Notfallwiederherstellungsszenarien beschränkt werden. Um sicherzustellen, dass für Reparaturen ein integriertes Administratorkonto verwendet werden kann, falls keine anderen Konten möglich sind, sollten Sie nie die Standardmitgliedschaft des Administratorkontos in einer Domäne in der Gesamtstruktur ändern. Stattdessen sollten Sie Richtlinien für den Schutz des Administratorkontos in jeder Domäne der Gesamtstruktur befolgen. Ausführliche Anweisungen zum Implementieren dieser Kontrollen finden Sie in Anhang D: Schützen integrierter Administratorkonten in Active Directory.

Steuerelemente für integrierte Administratorkonten

Das Ziel der Implementierung der hier beschriebenen Einstellungen besteht darin, zu verhindern, dass das Administratorkonto (keine Gruppe) der einzelnen Domänen verwendet werden kann, sofern nicht eine Reihe von Kontrollen umgekehrt wird. Wenn Sie diese Kontrollen implementieren und Administratorkonten auf Änderungen überwachen, können Sie die Erfolgswahrscheinlichkeit eines Angriffs über das Administratorkonto einer Domäne erheblich verringern. In jeder Domäne Ihrer Gesamtstruktur sollten Sie für das Administratorkonto 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. Mit der Delegierung kann ein Computer oder Dienst die Anmeldeinformationen für ein Konto, das sich beim Computer oder Dienst authentifiziert hat, anderen Computern zur Verfügung stellen, um Dienste im Namen des Kontos abzurufen. Wenn Sie das Attribut Konto ist vertraulich und kann nicht delegiert werden für ein domänenbasiertes Konto aktivieren, können die Anmeldeinformationen des Kontos nicht gegenüber anderen Computern oder Diensten im Netzwerk angegeben werden. Angriffe, die mithilfe der Delegierung die Anmeldeinformationen des Kontos auf anderen Systemen verwenden, werden dadurch eingeschränkt.

Aktivieren Sie das Flag „Benutzer muss sich mit einer Smartcard anmelden“ für das Konto.

Wenn Sie das Attribut Benutzer muss sich mit einer Smartcard anmelden für ein Konto aktivieren, setzt Windows das Kennwort des Kontos auf einen 120-stelligen Zufallswert zurück. Durch Festlegen dieses Flags für integrierte Administratorkonten stellen Sie sicher, dass das Kennwort für das Konto nicht nur lang und komplex, sondern auch keinen Benutzer*innen bekannt ist. Es ist technisch nicht erforderlich, Smartcards für die Konten zu erstellen, bevor dieses Attribut aktiviert wird. Wenn möglich, sollten jedoch Smartcards für jedes Administratorkonto vor dem Konfigurieren von Kontoeinschränkungen erstellt werden, und die Smartcards sollten an sicheren Orten aufbewahrt werden.

Das Kennwort des Kontos wird beim Festlegen des Flags Benutzer muss sich mit einer Smartcard anmelden zurückgesetzt, Benutzer*innen mit Berechtigungen zum Zurücksetzen des Kontokennworts können jedoch das Konto auf einen bekannten Wert festlegen und den über den Namen des Kontos und das neue Kennwort auf Ressourcen im Netzwerk zugreifen. Sie sollten daher die folgenden zusätzlichen Kontrollen für das Konto implementieren.

Konfigurieren von Gruppenrichtlinienobjekten zum Einschränken der Administratorkonten für Domänen auf Systemen, die in die Domäne eingebunden sind

Das Deaktivieren des Administratorkontos in einer Domäne macht das Konto zwar effektiv unbrauchbar, Sie sollten jedoch zusätzliche Einschränkungen für das Konto implementieren, falls versehentlich oder böswillig aktiviert wird. Obwohl dies letztlich vom Administratorkonto rückgängig gemacht werden können, besteht das Ziel darin, Kontrollen zu erstellen, die den Fortschritt von Angreifer*innen verlangsamen und den Schaden, den das Konto anrichten kann, begrenzen.

Fügen Sie in einem oder mehreren Gruppenrichtlinienobjekten, die Sie erstellen und mit Organisationseinheiten für Arbeitsstationen und Mitgliedsserver in jeder Domäne verknüpfen, das Administratorkonto der einzelnen Domänen zu den folgenden Benutzerrechten unter Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Zuweisen von Benutzerrechten 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. Um beispielsweise diesen Verweigerungsrechten das lokale Administratorkonto der Domäne NWTRADERS hinzuzufügen, müssen Sie das Konto als NWTRADERS\Administrator eingeben oder zum lokalen Administratorkonto für die Domäne NWTRADERS navigieren. Wenn Sie in diesen Einstellungen für Benutzerberechtigungen im Gruppenrichtlinienobjekt-Editor Administrator eingeben, schränken Sie das lokale Administratorkonto auf jedem Computer ein, auf den das Gruppenrichtlinienobjekt angewandt wird.

Es wird empfohlen, lokale Administratorkonten auf Mitgliedsservern und Arbeitsstationen auf die gleiche Weise wie domänenbasierte Administratorkonten einzuschrä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 zu 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 das Gruppenrichtlinienobjekt des Standarddomänencontrollers oder eine Richtlinie, die mit der Organisationseinheit für Domänencontroller verknüpft ist, so geändert werden, dass die Administratorkonten der einzelnen Domänen den folgenden Benutzerrechten unter Computerkonfiguration\Richtlinien\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Zuweisen von Benutzerrechten hinzugefügt werden:

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

Hinweis

Durch diese Einstellungen wird gewährleistet, dass das lokale Administratorkonto nicht zum Herstellen einer Verbindung mit einem Domänencontroller verwendet werden kann. Das Konto kann sich jedoch lokal bei Domänencontrollern anmelden, sofern es aktiviert ist. Da dieses Konto nur in Notfallwiederherstellungsszenarien aktiviert und verwendet werden sollte, wird davon ausgegangen, dass physischer Zugriff auf mindestens einen Domänencontroller verfügbar ist oder andere Konten mit Berechtigungen für den Remotezugriff auf Domänencontroller verwendet werden können.

Konfigurieren der Überwachung integrierter Administratorkonten

Wenn Sie das Administratorkonto aller Domänen abgesichert und deaktiviert haben, sollten Sie die Überwachung von Änderungen am Konto konfigurieren. Wenn das Konto aktiviert, sein Kennwort zurückgesetzt oder andere Änderungen vorgenommen werden, sollten Warnungen an die Benutzer*innen oder Teams gesendet werden, die für die Verwaltung von AD DS verantwortlich sind, sowie an die für die Reaktion auf Incidents in Ihrer Organisation zuständigen Teams.

Schützen der Gruppen „Administratoren“, „Domänenadministratoren“ und „Organisations-Admins“

Schützen von Organisationsadministratorengruppen

Die Gruppe „Organisations-Admins“, die sich in der Stammdomäne der Gesamtstruktur befindet, sollte keine Benutzer*innen auf täglicher Basis enthalten. Eine mögliche Ausnahme bildet das lokale Administratorkonto der Domäne, sofern es wie zuvor und in Anhang D: Schützen integrierter Administratorkonten in Active Directory beschrieben geschützt ist.

Wenn Zugriff für Organisationsadministrator*innen erforderlich ist, sollten die Benutzer*innen, deren Konten entsprechende Rechte und Berechtigungen erfordern, vorübergehend in die Gruppe „Organisations-Admins“ aufgenommen werden. Obwohl Benutzer*innen die Konten mit umfassenden Berechtigungen verwenden, sollten ihre Aktivitäten überwacht werden. Vorzugsweise sollte ein*e Benutzer*in die Änderungen vornehmen und ein*e andere*r sie beobachten, um die Wahrscheinlichkeit von unbeabsichtigtem Missbrauch oder Fehlkonfigurationen zu minimieren. Nach Abschluss der Aktivitäten sollten die Konten wieder aus der Gruppe „Organisations-Admins“ entfernt werden. Dies kann durch manuelle Verfahren und dokumentierte Prozesse, PIM/PAM-Software (Privileged Identity/Access Management) von Drittanbietern oder eine Kombination aus beiden erreicht werden. Richtlinien zum Erstellen von Konten, über die die Mitgliedschaft von privilegierten Gruppen in Active Directory gesteuert werden kann, finden Sie unter Attraktive Konten für den Diebstahl von Anmeldeinformationen, und ausführliche Anweisungen finden Sie in Anhang I: Erstellen von Verwaltungskonten für geschützte Konten und Gruppen in Active Directory.

Organisations-Admins sind standardmäßig Mitglieder der integrierten Gruppe „Administratoren“ jeder Domäne in der Gesamtstruktur. Das Entfernen der Gruppe „Organisations-Admins“ aus den Gruppen „Administratoren“ aller Domänen ist als Änderung nicht angemessen, da bei einem Szenario der Notfallwiederherstellung der Gesamtstruktur wahrscheinlich Organisationsadministratorrechte erforderlich sind. Wenn die Gruppe „Organisations-Admins“ aus Administratorengruppen in einer Gesamtstruktur entfernt wurde, sollte sie der Gruppe „Administratoren“ in jeder Domäne hinzugefügt werden, und die folgenden zusätzlichen Kontrollen sollten implementiert werden:

• Wie zuvor beschrieben sollte die Gruppe „Organisations-Admins“ keine Benutzer*innen auf täglicher Basis enthalten. Eine mögliche Ausnahme bildet das lokale Administratorkonto der Gesamtstruktur, das wie in Anhang D: Schützen integrierter Administratorkonten in Active Directory beschrieben geschützt werden sollte.
• In Gruppenrichtlinienobjekten, die mit Organisationseinheiten mit Mitgliedsservern und Arbeitsstationen in jeder Domäne verknüpft sind, sollte die Gruppe „Organisations-Admins“ 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 des Anmeldens über Remotedesktopdienste

Hierdurch wird verhindert, dass sich Mitglieder der Gruppe „Organisations-Admins“ bei Mitgliedsservern und Arbeitsstationen anmelden. Wenn Jumpserver zum Verwalten von Domänencontrollern und Active Directory verwendet werden, stellen Sie sicher, dass sie sich in einer Organisationseinheit befinden, mit der die eingeschränkten Gruppenrichtlinienobjekte nicht verknüpft sind.

• Die Überwachung sollte so konfiguriert werden, dass Warnungen gesendet werden, wenn Änderungen an Eigenschaften oder Mitgliedschaften der Gruppe „Organisations-Admins“ vorgenommen werden. Diese Warnungen sollten mindestens an Benutzer*innen oder Teams gesendet werden, die für die Active Directory-Verwaltung und die Reaktion auf Incidents verantwortlich sind. Sie sollten auch Prozesse und Verfahren für das vorübergehende Auffüllen der Gruppe „Organisations-Admins“ definieren, einschließlich Benachrichtigungsverfahren, wenn eine legitime Auffüllung der Gruppe ausgeführt wird.

Schützen der Domänenadministratorengruppen

Wie bei der Gruppe „Organisations-Admins“ sollte die Mitgliedschaft in den Gruppen „Domänenadministratoren“ nur in Build- oder Notfallwiederherstellungsszenarien erforderlich sein. In der Gruppe „Domänenadministratoren“ sollten keine täglich genutzten Benutzerkonten enthalten sein, mit Ausnahme des lokalen Administratorkontos für die Domäne, sofern es wie in Anhang D: Schützen integrierter Administratorkonten in Active Directory beschrieben abgesichert wurde.

Wenn Zugriff für Domänenadministrator*innen erforderlich ist, sollten die Konten, die diese Zugriffsebene benötigen, vorübergehend in der Gruppe „Domänenadministratoren“ für die betreffende Domäne platziert werden. Obwohl die Benutzer*innen die Konten mit umfassenden Berechtigungen verwenden, sollten Aktivitäten überwacht werden. Vorzugsweise sollte ein*e Benutzer*in die Änderungen vornehmen und ein*e andere*r sie beobachten, um die Wahrscheinlichkeit von unbeabsichtigtem Missbrauch oder Fehlkonfigurationen zu minimieren. Nach Abschluss der Aktivitäten sollten die Konten wieder aus der Gruppe „Domänenadministratoren“ entfernt werden. Dies kann durch manuelle Verfahren und dokumentierte Prozesse, PIM/PAM-Software (Privileged Identity/Access Management) von Drittanbietern oder eine Kombination aus beiden erreicht werden. Richtlinien zum Erstellen von Konten, über die die Mitgliedschaft von privilegierten Gruppen in Active Directory gesteuert werden kann, 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 Administratorengruppen auf allen Mitgliedsservern und Arbeitsstationen in ihren jeweiligen Domänen. Diese Standardschachtelung sollte nicht geändert werden, da sie die Unterstützungsfähigkeit und die Optionen für Notfallwiederherstellung beeinträchtigt. Wenn Domänenadministratorengruppen aus den lokalen Administratorengruppen auf den Mitgliedsservern entfernt wurden, sollten sie der Gruppe „Administratoren“ auf jedem Mitgliedsserver und jeder Arbeitsstation in der Domäne über die Einstellungen für eingeschränkte Gruppen in verknüpften Gruppenrichtlinienobjekten hinzugefügt werden. Die folgenden in Anhang F: Schützen von Domänenadministratorengruppen in Active Directory ausführlich beschriebenen allgemeinen Steuerelemente sollten ebenfalls implementiert werden.

Gehen Sie für die Gruppe der Domänenadministratoren in jeder Domäne der Gesamtstruktur wie folgt vor:

1. Entfernen Sie alle Mitglieder aus der Gruppe „Domänenadministratoren“, ggf. mit Ausnahme des integrierten Administratorkontos für die Domäne, sofern es wie in Anhang D: Schützen integrierter Administratorkonten in Active Directory beschrieben abgesichert wurde.

2. In Gruppenrichtlinienobjekten, die mit Organisationseinheiten mit Mitgliedsservern und Arbeitsstationen in jeder Domäne verknüpft sind, sollte die Gruppe „Domänenadministratoren“ 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

   Hierdurch wird verhindert, dass sich Mitglieder der Gruppe „Domänenadministratoren“ bei Mitgliedsservern und Arbeitsstationen anmelden. Wenn Jumpserver zum Verwalten von Domänencontrollern und Active Directory verwendet werden, stellen Sie sicher, dass sie sich in einer Organisationseinheit befinden, mit der die eingeschränkten Gruppenrichtlinienobjekte nicht verknüpft sind.

3. Die Überwachung sollte so konfiguriert werden, dass Warnungen gesendet werden, wenn Änderungen an Eigenschaften oder Mitgliedschaften der Gruppe „Domänenadministratoren“ vorgenommen werden. Diese Warnungen sollten mindestens an Benutzer*innen oder Teams gesendet werden, die für die AD DS-Verwaltung und die Reaktion auf Incidents verantwortlich sind. Sie sollten auch Prozesse und Verfahren für das vorübergehende Auffüllen der Gruppe „Domänen-Admins“ definieren, einschließlich Benachrichtigungsverfahren, wenn eine legitime Auffüllung der Gruppe ausgeführt wird.

Schützen von Administratorgruppen in Active Directory

Wie bei den Gruppen „Organisations-Amins“ und „Domänenadministratoren“ sollte die Mitgliedschaft in der integrierten Gruppe „Administratoren“ (BA) nur in Build- oder Notfallwiederherstellungsszenarien erforderlich sein. In der Gruppe „Administratoren“ sollten keine allgemeinen Benutzerkonten vorhanden sein, mit Ausnahme des integrierten Administratorkontos für die Domäne, sofern es wie in Anhang D: Sichern integrierter Administratorkonten in Active Directory beschrieben geschützt wurde.

Wenn Zugriff für Administrator*innen erforderlich ist, sollten die Konten, die diese Zugriffsebene benötigen, vorübergehend in der Gruppe „Administratoren“ für die betreffende Domäne platziert werden. Obwohl die Benutzer*innen die Konten mit umfassenden Berechtigungen verwenden, sollten Aktivitäten überwacht werden. Vorzugsweise sollte ein*e Benutzer*in die Änderungen vornehmen und ein*e andere*r sie beobachten, um die Wahrscheinlichkeit von unbeabsichtigtem Missbrauch oder Fehlkonfigurationen zu minimieren. Nach Abschluss der Aktivitäten sollten die Konten sofort aus der Gruppe „Administratoren“ entfernt werden. Dies kann durch manuelle Verfahren und dokumentierte Prozesse, PIM/PAM-Software (Privileged Identity/Access Management) von Drittanbietern oder eine Kombination aus beiden erreicht werden.

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

1. Entfernen Sie alle Mitglieder aus der Gruppe „Administratoren“, ggf. mit Ausnahme des lokalen Administratorkontos für die Domäne, sofern es wie in Anhang D: Schützen integrierter Administratorkonten in Active Directory beschrieben 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 den einzelnen Domänen 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
   • Hierdurch wird verhindert (sofern nicht zuvor mehrere Kontrollen verletzt werden), dass Mitglieder der Gruppe „Administratoren“ zum Anmelden bei Mitgliedsservern oder Arbeitsstationen oder zum Herstellen einer Verbindung mit diesen verwendet werden, auf denen ihre Anmeldeinformationen zwischengespeichert und dadurch gefährdet werden könnten. Ein privilegiertes Konto sollte niemals zum Anmelden bei einem System mit geringeren Berechtigungen verwendet werden, und die Erzwingung dieser Kontrollen bietet Schutz vor einer Reihe von Angriffen.

3. Auf der Organisationseinheit für Domänencontroller in jeder Domäne in der Gesamtstruktur sollten der Gruppe „Administratoren“ die folgenden Benutzerrechte gewährt werden (sofern sie nicht bereits über diese Rechte verfügt), sodass die Mitglieder dieser Gruppe die erforderlichen Funktionen für ein gesamtstrukturweites Notfallwiederherstellungsszenario ausführen können:

   • 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 Eigenschaften oder Mitgliedschaften der Gruppe „Administratoren“ vorgenommen werden. Diese Warnungen sollten mindestens an Mitglieder des Teams gesendet werden, das für die AD DS-Verwaltung zuständig ist. Warnungen sollten auch an Mitglieder des Sicherheitsteams gesendet werden, und es sollten Verfahren zum Ändern der Mitgliedschaft in der Gruppe „Administratoren“ definiert werden. Insbesondere sollten diese Prozesse ein Verfahren einschließen, durch das bei Änderungen an der Gruppe „Administratoren“ das Sicherheitsteam benachrichtigt wird, sodass empfangene Warnungen erwartet werden und keine Warnung ausgelöst wird. Darüber hinaus sollten Prozesse zur Benachrichtigung des Sicherheitsteams implementiert werden, wenn die Verwendung der Gruppe „Administratoren“ abgeschlossen 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 nicht nur auf die Mitglieder der Gruppe „Administratoren“ der Domäne auch auf Mitglieder der lokalen Administratorgruppe eines Computers an. Daher sollten Sie beim Implementieren von Einschränkungen in der Gruppe „Administratoren“ vorsichtig vorgehen. Obwohl es ratsam ist, Netzwerk-, Batch- und Dienstanmeldungen für Mitglieder der Gruppe „Administratoren“ nach Möglichkeit zu untersagen, sollten lokale Anmeldungen oder Anmeldungen über Remotedesktopdienste nicht eingeschränkt werden. Das Blockieren dieser Anmeldetypen kann die legitime Verwaltung eines Computers durch Mitglieder der lokalen Administratorgruppe blockieren. Der folgende Screenshot zeigt Konfigurationseinstellungen, die zusätzlich zum Missbrauch von integrierten lokalen oder Domänenadministratorgruppen den Missbrauch von integrierten lokalen und Domänenadministratorkonten blockieren. Beachten Sie, dass das Benutzerrecht Anmelden über Remotedesktopdienste verweigern die Gruppe „Administratoren“ nicht einschließt, da die Einbeziehung dieser Gruppe in diese Einstellung diese Anmeldungen auch für Konten blockieren würde, die Mitglieder der Gruppe „Administratoren“ 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 zu Fehlern bei Diensten und Anwendungen führen. Daher sollten Sie, wie bei allen Empfehlungen in diesem Abschnitt, die Einstellungen gründlich auf Anwendbarkeit in Ihrer Umgebung testen.

Rollenbasierte Zugriffssteuerungen für Active Directory

Im Allgemeinen sind rollenbasierte Zugriffssteuerungen (Role-Based Access Controls, RBAC) ein Mechanismus zum Gruppieren von Benutzer*innen und Ermöglichen des Zugriffs auf Ressourcen basierend auf Geschäftsregeln. Bei Active Directory ist die Implementierung von RBAC für AD DS der Prozess der Erstellung von Rollen, an die Rechte und Berechtigungen delegiert werden, sodass Mitglieder der Rolle tägliche Verwaltungsaufgaben ausführen können, ohne ihnen übermäßige Berechtigungen zu gewähren. RBAC für Active Directory kann über native Tools und Schnittstellen entworfen und implementiert werden. Dies kann über Software, die Sie möglicherweise bereits besitzen, Produkte von Drittanbietern oder eine Kombination dieser Ansätze erfolgen. In diesem Abschnitt werden keine ausführlichen Anweisungen zum Implementieren von RBAC für Active Directory bereitgestellt, sondern stattdessen werden die Faktoren erläutert, die Sie bei der Auswahl eines Ansatzes für die Implementierung von RBAC in Ihren AD DS-Installationen 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 für die tägliche Verwaltung innerhalb des festgelegten Bereichs der Rolle an die Gruppen delegieren.

In einigen Fällen können Rechte und Berechtigungen entsprechend einer beruflichen Funktion über vorhandene Sicherheitsgruppen in Active Directory erteilt werden. Wenn beispielsweise bestimmte Mitarbeitende in Ihrer IT-Organisation für die Verwaltung und Wartung von DNS-Zonen und -Datensätzen verantwortlich sind, kann das Delegieren dieser Zuständigkeiten lediglich im Erstellen von Konten für alle DNS-Administrator*innen und dem Hinzufügen zur Gruppe „DNS-Administratoren“ in Active Directory bestehen. Die Gruppe „DNS-Administratoren“ verfügt im Gegensatz zu Gruppen mit umfassenderen Berechtigungen über wenige hohe Rechte in Active Directory. Mitgliedern dieser Gruppe wurden jedoch Berechtigungen zur Verwaltung von DNS delegiert, daher kann die Gruppe weiterhin gefährdet werden, und Missbrauch kann zu einer Erhöhung von Berechtigungen führen.

In anderen Fällen müssen Sie möglicherweise Sicherheitsgruppen erstellen und Rechte und Berechtigungen an Active Directory-, Dateisystem- und Registrierungsobjekte delegieren, damit Mitglieder der Gruppen bestimmte Verwaltungsaufgaben ausführen können. Wenn Ihre Helpdeskoperator*innen beispielsweise für das Zurücksetzen vergessener Kennwörter, die Unterstützung von Benutzer*innen 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, über die sie Remoteverbindungen mit den Computern der Benutzer*innen herstellen können, um ihre Konfigurationseinstellungen anzuzeigen oder zu ändern. Für jede definierte Rolle sollten Sie Folgendes ermitteln:

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 Mitglieder einer Rolle Rechte und Berechtigungen erhalten sollen.
3. Welchen Benutzer*innen die Mitgliedschaft in einer Rolle gewährt werden sollte.
4. Wie die Verwaltung von Rollenmitgliedschaften durchgeführt wird.

In vielen Umgebungen kann es schwierig sein, rollenbasierte Zugriffssteuerungen für die Verwaltung einer Active Directory-Umgebung manuell zu erstellen. Wenn Sie über klar definierte Rollen und Zuständigkeiten für die Verwaltung Ihrer IT-Infrastruktur verfügen, für die Erstellung einer verwaltbaren nativen RBAC-Bereitstellung auch zusätzliche Tools nutzen. Wenn beispielsweise Forefront Identity Manager (FIM) in Ihrer Umgebung verwendet wird, können Sie mit FIM die Erstellung und Auffüllung von Verwaltungsrollen automatisieren und dadurch die fortlaufende Verwaltung vereinfachen. Wenn Sie Microsoft Endpoint Configuration Manager und System Center Operations Manager (SCOM) verwenden, können Sie mithilfe von anwendungsspezifischen Rollen Verwaltungs- und Überwachungsfunktionen delegieren und eine konsistente Konfiguration und Überwachung systemübergreifend in der Domäne erzwingen. Wenn Sie eine Infrastruktur mit öffentlichen Schlüsseln (Public Key Infrastructure, PKI) implementiert haben, können Sie Smartcards für die für die Verwaltung der Umgebung verantwortlichen IT-Mitarbeitenden ausstellen und erfordern. Mit FIM Credential Management (FIM CM) können Sie sogar die Verwaltung von Rollen und Anmeldeinformationen für Ihre Verwaltungsmitarbeitenden kombinieren.

In anderen Fällen kann eine Organisation vorzugsweise die Bereitstellung von RBAC-Software von Drittanbietern in Erwägung ziehen, die sofort einsatzbereite Funktionen bietet. COTS-Lösungen (Commercial Off-The-Shelf) für RBAC für Active Directory-, Windows- und Nicht-Windows-Verzeichnisse und Betriebssysteme werden von verschiedenen Anbietern bereitgestellt. Bei der Entscheidung zwischen nativen Lösungen und Produkten von Drittanbietern sollten Sie die folgenden Faktoren berücksichtigen:

1. Budget: Durch Investitionen in die Entwicklung von RBAC mit Software und Tools, die Sie möglicherweise bereits besitzen, können Sie die mit der Bereitstellung einer Lösung verbundenen Softwarekosten senken. Sofern Sie nicht über Mitarbeiter*innen verfügen, die Erfahrung mit dem Erstellen und Bereitstellen nativer RBAC-Lösungen haben, müssen Sie jedoch möglicherweise Beratungsressourcen für die Entwicklung Ihrer Lösung in Anspruch nehmen. Sie sollten die erwarteten Kosten für eine maßgeschneiderte Lösung sorgfältig mit den Kosten für die Bereitstellung einer ohne Konfiguration einsatzfähigen 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 bereits Active Directory für die Verwaltung von Nicht-Windows-Systemen und -Konten nutzen, stellen benutzerdefinierte native Lösungen möglicherweise die optimale Lösung für Ihre Anforderungen dar. Wenn Ihre Infrastruktur viele Systeme enthält, auf denen nicht Windows 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 es für ein Produkt erforderlich ist, Dienstkonten in Active Directory-Gruppen mit umfassenden Berechtigungen zu platzieren, und es keine Optionen ohne übermäßige Berechtigungen für die RBAC-Software gibt, haben Sie Ihre Active Directory-Angriffsfläche nicht verkleinert und nur die Zusammensetzung der Gruppen mit den umfassendsten Berechtigungen im Verzeichnis geändert. Wenn ein Anwendungsanbieter keine Kontrollen für Dienstkonten bereitstellen kann, die die Wahrscheinlichkeit einer Beeinträchtigung und böswilligen Nutzen der Konten minimieren, sollten Sie andere Optionen in Betracht ziehen.

Privileged Identity Management

Privileged Identity Management (PIM), auch als Privileged Account Management (PAM) oder Privileged Credential Management (Privileged Credential Management, PCM) bezeichnet, umfasst den Entwurf, die Konstruktion und die Implementierung von Ansätzen zur Verwaltung privilegierter Konten in Ihrer Infrastruktur. Im Allgemeinen stellt PIM Mechanismen bereit, über die Konten temporäre Rechte und Berechtigungen zum Ausführen von Funktionen zum Erstellen oder Beheben von Problemen gewährt werden, anstatt den Konten dauerhaft Berechtigungen hinzuzufügen. Unabhängig davon, ob die PIM-Funktionen manuell erstellt oder über Drittanbietersoftware implementiert werden, können einige der folgenden Features verfügbar sein:

• Tresore für Anmeldeinformationen, bei denen Kennwörter für privilegierte Konten „ausgecheckt“ und einem Kennwort zugewiesen, dann nach Abschluss der Aktivitäten wieder „eingecheckt“ werden. Zu diesem Zeitpunkt werden die Kennwörter für die Konten wieder zurückgesetzt.
• Zeitgebundene Einschränkungen für die Verwendung privilegierter Anmeldeinformationen
• Anmeldeinformationen zur einmaligen Verwendung
• Durch den Workflow generierte Gewährung von Berechtigungen mit Überwachung und Berichterstellung zu den ausgeführten Aktivitäten und automatischem Entfernen der Berechtigungen nach Abschluss der Aktivitäten oder Ablauf der zugeteilten Zeit
• Ersatz von hartcodierten Anmeldeinformationen wie Benutzernamen und Kennwörtern in Skripts mit Anwendungsprogrammierschnittstellen (Application Programming Interfaces, APIs), über die Anmeldeinformationen nach Bedarf aus Tresoren abgerufen werden können
• Automatische Verwaltung von Anmeldeinformationen für Dienstkonten

Erstellen von nicht privilegierten Konten zum Verwalten privilegierter Konten

Eine der Herausforderungen bei der Verwaltung privilegierter Konten besteht darin, dass die Konten für die Verwaltung privilegierter und geschützter Konten und Gruppen 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, bei denen Sie die Gruppen mit den umfassendsten Berechtigungen im Verzeichnis effektiv leeren und nur vorübergehend und bei Bedarf auffüllen.

Wenn Sie RBAC und PIM nativ implementieren, sollten Sie jedoch in Erwägung ziehen, Konten zu erstellen, die nicht über Berechtigungen verfügen und nur die Funktion haben, privilegierte Gruppen in Active Directory bei Bedarf aufzufüllen und zu leeren. Anhang I: Erstellen von Verwaltungskonten für geschützte Konten und Gruppen in Active Directory enthält ausführliche Anweisungen zum Erstellen von Konten zu diesem Zweck.

Implementieren robuster Authentifizierungskontrollen

Regel Nummer 6: Es gibt tatsächlich eine Person, die versucht, Ihre Kennwörter zu erraten. - 10 unumstößliche Gesetze der Sicherheitsverwaltung

Pass-the-Hash- und andere Angriffe zum Diebstahl von Anmeldeinformationen sind weder spezifisch für Windows-Betriebssysteme noch neu. Der erste Pass-the-Hash-Angriff wurde 1997 erstellt. In der Vergangenheit waren für diese Angriffe jedoch angepasste Tools erforderlich, sie waren unzuverlässig und erforderten ein relativ hohes Maß an Kenntnissen. Die Einführung von frei verfügbaren, einfach zu verwendenden Tools, die nativ Anmeldeinformationen extrahieren, hat in den letzten Jahren zu einer exponentiellen Zunahme der Anzahl und des Erfolgs von Angriffen zum Diebstahl von Anmeldeinformationen geführt. Diese Angriffe sind jedoch bei Weitem nicht die einzigen Mechanismen, mit denen Anmeldeinformationen angezielt und beeinträchtigt werden.

Sie sollten zwar Kontrollen zum Schutz vor Angriffen zum Diebstahl von Anmeldeinformationen implementieren, jedoch auch die Konten in Ihrer Umgebung identifizieren, auf die auf Angreifer wahrscheinlich abzielen, und robuste Authentifizierungskontrollen für diese Konten implementieren. Wenn für Ihre Konten mit den umfassendsten Berechtigungen eine einstufige Authentifizierung verwendet wird, z. B. Benutzername und Kennwort (beide stellen eine Information dar, die Sie kennen, und bilden damit einen Authentifizierungsfaktor), sind diese Konten nur schwach geschützt. Ein*e Angreifer*in benötigt lediglich Kenntnisse über den Benutzernamen und das Kennwort des Kontos, und es sind keine Pass-the-Hash-Angriffe erforderlich, um sich als Benutzer*in bei Systemen zu authentifizieren, die Ein-Faktor-Anmeldeinformationen akzeptieren.

Obwohl die Implementierung einer mehrstufigen Authentifizierung Sie nicht vor Pass-the-Hash-Angriffen schützt, ist dies durch die Implementierung in Kombination mit geschützten Systemen möglich. Weitere Informationen zum Implementieren geschützter Systeme finden Sie unter Implementieren von sicheren administrativen Hosts, und die Authentifizierungsoptionen werden in den folgenden Abschnitten erläutert.

Allgemeine Authentifizierungskontrollen

Wenn Sie noch keine mehrstufige Authentifizierung wie Smartcards implementiert haben, sollten Sie dies in Erwägung ziehen. Smartcards implementieren einen durch Hardware erzwungenen Schutz privater Schlüssel in einem Paar aus öffentlichem und privatem Schlüssel und verhindern somit den Zugriff auf den Schlüssel eines Benutzers oder einer Benutzerin, sofern nicht die für diese Smartcard korrekten Anmeldeinformationen (PIN, Passcode oder biometrische Kennung) vorgelegt werden. Selbst wenn die PIN oder die Kennung des Benutzers bzw. der Benutzerin durch Protokollierung von Tastatureingaben auf einem beeinträchtigten Computer abgefangen wird, muss die Karte auch physisch vorhanden sein, damit Angreifer*innen die PIN oder Kennung wiederverwenden können.

In Fällen, in denen lange und komplexe Kennwörter aufgrund der Ablehnung auf Benutzerseite schwierig zu implementieren sind, bieten Smartcards einen Mechanismus, mit dem Benutzer*innen problemlos relativ einfache PINs oder Kennungen verwenden können, ohne dass die Anmeldeinformationen anfällig für Brute-Force- oder Rainbow-Table-Angriffe sind. Die Smartcard-PINs werden nicht in Active Directory oder lokalen SAM-Datenbanken gespeichert, obwohl Hashes der Anmeldeinformationen trotzdem in einem LSASS-geschützten Speicher aufbewahrt werden können, wenn auf diesen Computern Smartcards zur Authentifizierung verwendet wurden.

Zusätzliche Kontrollen für VIP-Konten

Ein weiterer Vorteil der Implementierung von Smartcards oder anderen zertifikatbasierten Authentifizierungsmechanismen ist die Möglichkeit, die Authentifizierungsmechanismus-Zusicherung zum Schutz vertraulicher Daten zu nutzen, auf die VIP-Benutzer*innen zugreifen können. Authentifizierungsmechanismus-Zusicherung ist in Domänen verfügbar, in denen die Funktionsebene auf Windows Server 2012 oder Windows Server 2008 R2 festgelegt ist. Bei Aktivierung fügt die Authentifizierungsmechanismus-Zusicherung dem Kerberos-Token von Benutzer*innen eine administratorseitig festgelegte globale Gruppenmitgliedschaft hinzu, wenn die Anmeldeinformationen der Benutzer*innen bei der Anmeldung mithilfe einer zertifikatbasierten Anmeldemethode authentifiziert werden.

Dadurch können Ressourcenadministrator*innen den Zugriff auf Ressourcen wie Dateien, Ordner und Drucker darauf basierend steuern, ob sich Benutzer*innen zusätzlich zum verwendeten Zertifikattyp mit einer zertifikatbasierten Anmeldemethode anmelden. Wenn sich Benutzer*innen beispielsweise mit einer Smartcard anmelden, kann der Zugriff auf Ressourcen im Netzwerk sich vom Zugriff, wenn keine Smartcard verwendet wird (d. h. bei Anmeldung durch Eingabe eines Benutzernamens und Kennworts), unterscheiden. Weitere Informationen zur Authentifizierungsmechanismus-Zusicherung finden Sie unter Detaillierte Anleitung zur Authentifizierungssicherung für AD DS unter Windows Server 2008 R2.

Konfigurieren der Authentifizierung für privilegierte Konten

Aktivieren Sie in Active Directory für alle Verwaltungskonten das Attribut Benutzer muss sich mit einer Smartcard anmelden, und überwachen Sie Änderungen an (mindestens) einem der Attribute auf der Registerkarte Konto für das Konto (z. B. „cn“, „name“, „sAMAccountName“, „userPrincipalName“ und „userAccountControl“).

Beim Festlegen von Benutzer muss sich mit einer Smartcard anmelden wird das Kennwort des Kontos auf einen zufälligen Wert von 120 Zeichen zurückgesetzt, und für interaktive Anmeldungen werden Smartcards gefordert. Das Attribut kann jedoch weiterhin von Benutzer*innen mit Berechtigungen zum Ändern von Kennwörtern für die Konten überschrieben werden, sodass mit diesen Konten dann nicht interaktive Anmeldungen nur mit Benutzername und Kennwort eingerichtet werden können.

Andere Fälle sind abhängig von der Konfiguration der Konten in Active Directory und der Zertifikateinstellungen in Active Directory-Zertifikatdienste (AD CS) oder einer PKI eines Drittanbieters. Unter Umständen können Benutzerprinzipalnamen (UPN) für Administrator- oder VIP-Konten das Ziel einer bestimmten Art von Angriff werden, wie hier beschrieben.

UPN-Hijacking für Zertifikatspoofing

Auch wenn eine umfassende Erörterung von Angriffen auf Infrastrukturen mit öffentlichen Schlüsseln (Public Key Infrastructure, PKI) im Rahmen dieses Dokuments nicht möglich ist, haben Angriffe auf öffentliche und private PKIs seit 2008 exponentiell zugenommen. Es wurde umfangreich über Vorstöße gegen öffentliche PKIs berichtet, Angriffe auf die interne PKI einer Organisation sind jedoch möglicherweise noch erfolgsversprechender. Bei einem solchen Angriff werden Active Directory und Zertifikate so genutzt, dass ein*e Angreifer*in die Anmeldeinformationen anderer Konten auf eine schwer zu erkennende Weise spoofen kann.

Beim Vorlegen eines Zertifikats für die Authentifizierung bei einem in die Domäne eingebundenen System wird das Zertifikat mithilfe der Inhalte der Attribute „Subject“ oder „SAN“ (Subject Alternative Name, alternativer Antragstellername) einem Benutzerobjekt in Active Directory zugeordnet. Abhängig vom Typ und der Erstellung des Zertifikats enthält das Attribut „Subject“ in der Regel den allgemeinen Namen (Common Name, CN) eines Benutzers oder einer Benutzerin, wie im folgenden Screenshot gezeigt.

Standardmäßig erstellt Active Directory den CN von Benutzer*innen, indem Vorname + „ “ + Nachname des jeweiligen Kontos verkettet wird. CN-Komponenten von Benutzerobjekten in Active Directory müssen jedoch nicht eindeutig sein, und beim Verschieben eines Benutzerkontos an einen anderen Speicherort im Verzeichnis wird der Distinguished Name (DN) des Kontos geändert: der vollständige Pfad zum Objekt im Verzeichnis, wie im unteren Bereich des vorherigen Screenshots gezeigt.

Da zertifikatsspezifische Antragstellernamen nicht garantiert statisch oder eindeutig sind, wird das Benutzerobjekt häufig anhand des alternativen Antragstellernamens in Active Directory gesucht. Das SAN-Attribut für Zertifikate, die Benutzer*innen von Unternehmenszertifizierungsstellen (in Active Directory integrierte Zertifizierungsstellen) ausgestellt werden, enthält in der Regel den UPN oder die E-Mail-Adresse der Benutzer*innen. Da UPNs in einer AD DS-Gesamtstruktur garantiert eindeutig sind, wird das Suchen eines Benutzerobjekts nach UPN häufig als Teil der Authentifizierung durchgeführt, wobei Zertifikate am Authentifizierungsvorgang beteiligt sein können, aber nicht müssen.

Die Verwendung von UPNs in SAN-Attributen in Authentifizierungszertifikaten kann von Angreifern zum Erhalten betrügerischer Zertifikate genutzt werden. Wenn ein Konto beeinträchtigt wurde, das die Möglichkeit hat, UPNs für Benutzerobjekte zu lesen und zu schreiben, wird der Angriff folgendermaßen implementiert:

Das UPN-Attribut für ein Benutzerobjekt (z. B. ein*e VIP-Benutzer*in) wird vorübergehend in einen anderen Wert geändert. Das SAM-Kontonamensattribut und der CN können zu diesem Zeitpunkt ebenfalls geändert werden, obwohl dies aus den zuvor 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 dem Zielkonto ursprünglich zugewiesen wurde. Veraltete aktivierte Benutzerkonten sind Konten, die nicht deaktiviert wurden, obwohl über einen längeren Zeitraum keine Anmeldung mehr stattfand. Sie werden aus den folgenden Gründen von Angreifern angegriffen, die beabsichtigen, sich zu zeigen, ohne erkannt zu werden:

1. Da das Konto aktiviert ist, aber nicht kürzlich verwendet wurde, werden wahrscheinlich bei seiner Verwendung keine Warnungen ausgelöst, wie es bei der Aktivierung eines deaktivierten Benutzerkontos möglicherweise der Fall wäre.
2. Die Verwendung eines vorhandenen Kontos erfordert keine Erstellung eines neuen Benutzerkontos, das möglicherweise von Verwaltungsmitarbeitenden bemerkt wird.
3. Veraltete Benutzerkonten, die noch aktiviert sind, stellen in der Regel Mitglieder verschiedener Sicherheitsgruppen dar und haben Zugriff auf Ressourcen im Netzwerk, sodass es einfacher ist, Zugriff zu erhalten und sich dabei als normale*r Benutzer*in auszugeben.

Mit dem Benutzerkonto, für das der Ziel-UPN nun konfiguriert wurde, werden Zertifikate von Active Directory-Zertifikatdienste angefordert.

Nachdem die Zertifikate für das Konto des Angreifers oder der Angreiferin abgerufen wurden, werden die UPNs für das „neue“ Konto und das Zielkonto auf die ursprünglichen Werte zurückgesetzt.

Der oder die Angreifer*in verfügt nun über Zertifikate für die Authentifizierung bei Ressourcen und Anwendungen als der oder die VIP-Benutzer*in, dessen bzw. deren Konto vorübergehend geändert wurde. Eine umfassende Erläuterung aller möglichen Angriffe auf Zertifikate und PKI liegt außerhalb des Rahmens dieses Dokuments. Dieser Angriffsmechanismus wird jedoch zur Veranschaulichung bereitgestellt, warum Sie privilegierte und VIP-Konten in AD DS auf Änderungen überwachen sollten, insbesondere bei Änderungen an Attributen auf der Registerkarte Konto für das Konto („cn“, „name“, „sAMAccountName“, „userPrincipalName“, „userAccountControl“ u. a.). Zusätzlich zur Überwachung der Konten sollten Sie Änderungen an Konten auf eine möglichst kleine Gruppe von Administratorbenutzer*innen beschränken. Ebenso sollten die Konten von Administratorbenutzer*innen geschützt und auf nicht autorisierte Änderungen überwacht werden.