In diesem Handbuch werden bewährte Methoden zum Ausführen von Active Directory in Google Cloud vorgestellt. Das Handbuch konzentriert sich auf Vorgehensweisen, die entweder Google Cloud-spezifisch oder von besonderer Bedeutung für die Bereitstellung von Active Directory in Google Cloud sind. Sie sollten das Handbuch als Ergänzung zu den von Microsoft veröffentlichten allgemeinen Best Practices zum Sichern von Active Directory betrachten.
Architektur
In den folgenden Abschnitten werden bewährte Methoden für die Architektur beschrieben.
Verwenden Sie das Architekturmuster, das Ihren Anforderungen am besten entspricht
Um Active Directory in Google Cloud bereitzustellen, müssen Sie zuerst entscheiden, welche Domain- und Gesamtstrukturarchitektur verwendet werden soll. Wenn Sie Active Directory bereits verwenden, müssen Sie auch entscheiden, ob und wie die beiden Umgebungen integriert werden sollen.
Welches Design am besten zu Ihrer Situation passt, hängt von einer Reihe von Faktoren ab, darunter dem Design Ihres lokalen Netzwerks, der Interaktion zwischen lokalen und Google Cloud-Ressourcen sowie Ihren Anforderungen an Verfügbarkeit und administrative Autonomie. In unseren Mustern zur Verwendung von Active Directory in einer Hybridumgebung erfahren Sie, wie diese Faktoren Ihr Design bestimmen sollten.
Wenn Sie eine Vertrauensgrenze zwischen Google Cloud und Ihrer lokalen Umgebung beibehalten möchten, sollten Sie das -Ressourcenstrukturmuster implementieren. In diesem Muster stellen Sie eine separate Gesamtstruktur in Google Cloud bereit und verwenden eine Einweg-Gesamtstrukturvertrauensstellung, um die Google Cloud-Gesamtstruktur in Ihre vorhandene lokale Active Directory-Gesamtstruktur zu integrieren.
Separate Prüfung und Produktion
Abhängig von Ihrer Verwendung von Active Directory kann es erforderlich sein, während der Entwicklung und des Testens von Anwendungen häufige Änderungen in Active Directory vorzunehmen. Entwickler müssen möglicherweise in der Lage sein, Active Directory-Konten zu erstellen und zu ändern, Gruppenmitgliedschaften zu ändern, wenn Anwendungen Gruppen für die Autorisierung verwenden, oder Computer beizutreten und zu entfernen.
Um zu verhindern, dass Entwicklungs- und Testarbeiten die Produktionsauslastung beeinträchtigen oder die Sicherheit Ihrer Bereitstellung beeinträchtigen, sollten Sie eine separate Active Directory-Domain oder Gesamtstruktur für Entwicklung und Test bereitstellen.
Mit einer separaten Entwicklungs- und Testdomäne oder Gesamtstruktur können Sie auch administrative Änderungen überprüfen, bevor Sie sie auf die Produktion anwenden. Beispiele für solche Änderungen sind das Experimentieren mit Gruppenrichtlinien, das Testen von Automatisierungsskripten oder potenziell riskante Aktionen wie das Erhöhen der Funktionsebene einer Gesamtstruktur.
Richten Sie den Cloud Identity-Verbund zusätzlich zur Bereitstellung von Active Directory in Google Cloud ein
Durch die Bereitstellung von Active Directory in Google Cloud können Sie Windows-VMs in Google Cloud verwalten, Nutzer können sich mit ihren vorhandenen Nutzerkonten bei Windows-VMs anmelden und -Anwendungen unterstützen, die auf Kerberos, NTLM oder LDAP basieren. zur Authentifizierung.
Um jedoch die Google Cloud Console, das gcloud Befehlszeilentool oder andere Google- und Google Cloud-Tools verwenden zu können, müssen Sie sich mit einer Google-Identität authentifizieren. Die Bereitstellung von Active Directory in Google Cloud ist daher kein Ersatz dafür, Ihr vorhandenes Active Directory mit Google Cloud zu föderieren, wenn Sie Active Directory als Ihr führendes System für die Verwaltung von Nutzer verwenden möchten.
Wenn Sie beispielsweise eine separate Gesamtstruktur in Google Cloud bereitstellen, können Sie einen Verbund für Ihr lokales Active Directory einrichten, wie in der folgenden Abbildung dargestellt. Nutzer mit Konten im lokalen Active Directory können dann Tools verwenden, für die eine Google-Identität erforderlich ist, sowie Ihre Anwendungen, deren Authentifizierung auf Active Directory basiert.
Wenn Sie stattdessen Ihre vorhandene Gesamtstruktur oder Domain auf Google Cloud erweitern möchten, können Sie auch Domänencontroller und AD FS-Server verwenden, die auf Google Cloud bereitgestellt werden, um den Verbund einzurichten.
Mit Federation können Sie auch einen gemeinsamen Lebenszyklus für Google-Konten und Active Directory-Konten erzwingen, sodass beim Deaktivieren eines Benutzerkontos in Ihrem lokalen Active Directory auch der entsprechende Google-Nutzer gesperrt wird.
Netzwerk
Im folgenden Abschnitt werden bewährte Methoden für das Netzwerk beschrieben.
Stellen Sie Active Directory in einem freigegebenen VPC-Netzwerk bereit
Stellen Sie Domänencontroller in einem freigegebenen VPC-Netzwerk bereit, damit Active Directory für mehrere Projekte verwendet werden kann. Die Verwendung eines gemeinsam genutzten VPC-Netzwerks bietet mehrere Vorteile:
Jede Anwendung, für die möglicherweise Active Directory-Zugriff erforderlich ist, kann möglicherweise in einem separaten Projekt bereitgestellt werden. Durch die Verwendung separater Projekte können Sie Ressourcen isolieren und den Zugriff individuell verwalten.
Sie können ein dediziertes Projekt für Active Directory-Domänencontroller verwenden, mit dem Sie genau steuern können, welche Ihrer Nutzer auf verwandte Google Cloud-Ressourcen zugreifen können.
In gemeinsam genutzten VPC-Netzwerken können Sie die IP-Adressverwaltung und die Firewall-Konfiguration zentralisieren, um die Konsistenz über mehrere Projekte hinweg sicherzustellen.
Da VPCs eine globale Ressource sind, können Sie dasselbe gemeinsam genutzte VPC-Netzwerk in mehreren Regionen verwenden.
Stellen Sie Domänencontroller nicht extern zur Verfügung
Vermeiden Sie es, Domänencontrollern externe IP-Adressen zuzuweisen, um die Angriffsfläche von Active Directory zu verringern.
Da VM-Instanzen ohne externe IP-Adressen standardmäßig keinen Internetzugang haben, müssen Sie zusätzliche Schritte ausführen, um sicherzustellen, dass die Windows-Aktivierung und Windows-Updates auf Domänencontrollern nicht beeinträchtigt werden.
Um die Windows-Aktivierung zu unterstützen, aktivieren Sie Private Google Access in dem Subnetz, in dem Sie Domänencontroller bereitstellen möchten, und stellen Sie sicher, dass die VM-Instanzen auf kms.windows.googlecloud.com zugreifen können. Dadurch kann die Aktivierung ohne direkten Internetzugang erfolgen.
Es gibt mehrere Optionen zur Unterstützung von Windows-Updates:
Wenn Sie über einen lokalen WSUS-Server verfügen, können Sie die Hybrid-Konnektivität konfigurieren und Ihre Domänencontroller so konfigurieren, dass der WSUS-Server als Quelle für Updates verwendet wird.
Sie können den Internetzugang über ein NAT-Gateway aktivieren, indem Sie Cloud NAT bereitstellen.
Wenn Sie eine Hybridkonnektivität eingerichtet haben, können Sie den ausgehenden Traffic auch über ein lokales NAT-Gateway oder einen Proxyserver weiterleiten.
Reservieren Sie statische IP-Adressen für Domänencontroller im Voraus
Da Domänencontroller als DNS-Server dienen, muss ihnen eine IP-Adresse zugewiesen werden, die sich nicht ändert. Konfigurieren Sie dazu statische interne IP-Adressen für die Domaincontroller-VMs.
Wenn Sie eine IP-Adresse reservieren, wird standardmäßig automatisch eine nicht verwendete Adresse ausgewählt. Um sicherzustellen, dass die IP-Adressen von Domänencontrollern leicht zu speichern sind, reservieren Sie eine interne statische IP-Adresse.
Stellen Sie auf den Domänencontrollern die IP-Adresse des Netzwerkadapters auf dieselbe Adresse ein. Obwohl dieser Schritt optional ist, wird verhindert, dass Active Directory Warnmeldungen ausgibt, die darauf hinweisen, dass die IP-Adresse des Computers möglicherweise noch dynamisch zugewiesen wird.
Stellen Sie Domänencontroller in mehreren Zonen bereit
Stellen Sie mindestens zwei Domänencontroller und bereit, um die Verfügbarkeit zu erhöhen Verteilen Sie sie auf mehrere Zonen. Da Subnetze und IP-Adressen nicht an eine Zone gebunden sind, können Sie alle Domänencontroller in einem einzigen Subnetz bereitstellen.
Wenn Sie Workloads in mehreren Regionen bereitstellen möchten, sollten Sie Domänencontroller in jeder relevanten Region bereitstellen. Da Subnetze eine regionale Ressource sind, erfordert die Bereitstellung in einer zusätzlichen Region ein zusätzliches Subnetz.
Erstellen Sie eine Webseite pro Region
Wenn ein Client versucht, einen Domänencontroller zu finden, sucht er zuerst nach einem Domänencontroller am Active Directory-Standort, der der IP-Adresse des Clients entspricht. Wenn auf dieser Webseite kein Domänencontroller verfügbar ist, fährt der Client fort und versucht, einen Domänencontroller an einer anderen Site zu finden.
Sie können dieses Verhalten nutzen, indem Sie für jede Region, in der Sie Domänencontroller oder Domänenclients bereitstellen, einen separaten Standort erstellen. Clients bevorzugen dann automatisch die Verwendung von Domaincontrollern in derselben Region, wodurch die Latenz und die Kosten für ausgehende Datenübertragungen zwischen Regionen verringert werden können.
Wenn Sie Clients in Regionen haben, die keinen Domänencontroller haben, können Sie beeinflussen, welche Domänencontroller diese Clients auswählen, indem Sie die Site-Link-Kosten anpassen, um die geografische Nähe der Regionen widerzuspiegeln, und den Try Next Closest aktivieren Site -Einstellung.
Die Verwendung mehrerer Standorte beeinflusst das Replikationsverhalten zwischen Domänencontrollern. Ein Nachteil der Verwendung mehrerer Standorte kann sein, dass die Replikation zwischen Standorten weniger häufig erfolgt als die Replikation innerhalb eines Standorts.
Sie können jedoch keine Active Directory-Standorte in Managed Microsoft AD erstellen, da Managed Microsoft AD die Active Directory-Standorte und -Dienste nicht unterstützt.
Verwenden Sie private Cloud DNS-Weiterleitungszonen
Wenn Sie eine neue VM-Instanz in Compute Engine erstellen, wird das Betriebssystem so vorkonfiguriert, dass ein Standard-DNS-Server verwendet wird, der Zugriff auf internes DNS und öffentliches DNS bietet.
Bevor Sie einen Computer einer Active Directory-Domain hinzufügen können, müssen Sie sicherstellen, dass der Computer die von Active Directory verwalteten DNS-Einträge auflösen kann. Der Standard-DNS-Server, den Compute Engine für eine VM-Instanz konfiguriert, bietet Zugriff auf internes DNS und öffentliches DNS, kann jedoch keine von Active Directory verwalteten DNS-Namen auflösen.
Erstellen Sie eine private DNS-Weiterleitungszone in Cloud DNS, damit Clients von Active Directory verwaltete DNS-Einträge auflösen können. Konfigurieren Sie die Zone so, dass Abfragen, die Ihrer Active Directory-Domain entsprechen, an Ihre Domänencontroller weitergeleitet werden.
Die Verwendung einer privaten DNS-Weiterleitungszone bietet mehrere Vorteile gegenüber der Konfiguration von Clients für die direkte Verwendung Ihrer Active Directory-Domänencontroller als DNS-Server:
Sie müssen die Netzwerkkonfiguration von VM-Instanzen nicht anpassen. Dies vereinfacht das Erstellen neuer VMs.
Wenn Sie einen Domänencontroller heraufstufen oder herabstufen, müssen Sie nur die Konfiguration der privaten DNS-Weiterleitungszone aktualisieren und keine Clienteinstellungen ändern.
VM-Instanzen haben weiterhin Zugriff auf internes DNS.
Alle DNS-Einträge, die nicht mit Ihrer Active Directory-Domain übereinstimmen, werden von Cloud DNS verarbeitet, wodurch die Belastung Ihrer Domänencontroller verringert wird.
Wenn Sie mehrere Domains verwenden, erstellen Sie für jede Active Directory-Domain eine separate private DNS-Weiterleitungszone.
Private Cloud-DNS-Weiterleitungszonen sind auf eine einzelne VPC beschränkt. Wenn Sie mehrere VPCs verwenden, die mit Peering verbunden sind, können Sie die privaten Weiterleitungszonen anderen VPCs aussetzen, indem Sie DNS-Peering konfigurieren.
Sie müssen die DNS-Einstellungen auf Domänencontrollern noch manuell konfigurieren. Verwenden Sie 127.0.0.1 als primären DNS-Server und, optional, die IP-Adresse eines anderen Domänencontrollers als sekundären DNS-Server. Weitere Informationen finden Sie unter Empfohlene DNS-Einstellungen und alternative Optionen.
Hybridkonnektivität
Im folgenden Abschnitt werden bewährte Methoden für die Hybridkonnektivität beschrieben.
Verwenden Sie die eingehende DNS-Weiterleitung, um Google Cloud-DNS-Namen lokal aufzulösen
Clients in Ihrem lokalen Netzwerk müssen möglicherweise in der Lage sein, die DNS-Namen der in Google Cloud bereitgestellten Ressourcen aufzulösen. Wenn du Erweitern Sie Ihren Wald oder bereitstellen a Ressourcenwald Verwenden Sie dann in Google Cloud die eingehende DNS-Weiterleitung, damit lokale Clients DNS-Einträge nach in Google Cloud bereitgestellten Ressourcen suchen können. Um die eingehende Weiterleitung zu verwenden, erstellen Sie eine DNS-Serverrichtlinie, um eine eingehende Weiterleitungs-IP-Adresse zuzuweisen und diese Adresse dem lokalen Netzwerk zugänglich zu machen.
Wenn die in Google Cloud verwendete DNS-Domain (z. B. cloud.example.com) eine Unterdomäne der lokal verwendeten DNS-Domain ist (z. B. example.com), richten Sie die DNS-Delegierung ein. Erstellen Sie einen NS -Datensatz in der lokalen Domain, der auf die IP-Adresse des eingehenden Weiterleiters verweist. Der Eintrag NS bewirkt, dass Clients, die versuchen, einen DNS-Namen in der von Google Cloud gehosteten Domain nachzuschlagen, an die IP-Adresse des eingehenden Weiterleiters umgeleitet werden.
Wenn sich die in Google Cloud verwendeten DNS-Domänen und Ihr lokales Active Directory unterscheiden (z. B. cloud.example.com und corp.example.com), konfigurieren Sie die bedingte DNS-Weiterleitung in Ihren lokalen Domains und verwenden Sie die IP-Adresse der eingehenden Weiterleitung als Ziel. Wenn lokale Domänencontroller aufgefordert werden, einen DNS-Namen in der von Google Cloud gehosteten Domain aufzulösen, leiten sie die Quest an die IP-Adresse des eingehenden Weiterleiters weiter.
Stellen Sie bei Verwendung der eingehenden DNS-Weiterleitung sicher, dass Ihre Firewalls entsprechend konfiguriert sind.
Eine eingehende DNS-Weiterleitung ist nicht erforderlich, wenn Sie Erweitern Sie Ihre bestehende Domain zu Active Directory. In diesem Szenario werden alle DNS-Einträge der Domain automatisch in Google Cloud und Ihrer lokalen Umgebung repliziert und in beiden Umgebungen zur Suche bereitgestellt.
Verwenden Sie die ausgehende DNS-Weiterleitung, um lokale DNS-Namen aus Google Cloud aufzulösen
Clients, die in Google Cloud ausgeführt werden, müssen möglicherweise in der Lage sein, die Namen der lokal bereitgestellten Ressourcen aufzulösen. Wenn Sie Ihre Gesamtstruktur erweitern oder eine Ressourcengesamtstruktur in Google Cloud bereitstellen, erstellen Sie eine private Weiterleitungszone in Cloud DNS, um DNS-Abfragen für Sie weiterzuleiten lokale Domänen zu Ihren lokalen DNS-Servern.
Stellen Sie bei Verwendung der ausgehenden DNS-Weiterleitung sicher, dass Ihre Firewalls entsprechend konfiguriert sind.
DNS-Ausgangsweiterleitung ist nicht erforderlich, wenn Sie Sie Ihre bestehende Domain zu Active Directory erweitern. In diesem Szenario werden alle DNS-Einträge der Domain automatisch in Google Cloud und Ihrer lokalen Umgebung repliziert und in beiden Umgebungen zur Suche bereitgestellt.
Verwenden Sie VPN-Tunnel, um den LDAP-Verkehr zu sichern
Active Directory nutzt das LDAP-Protokoll in großem Umfang. Im Gegensatz zu den meisten anderen von Active Directory verwendeten Protokollen wird LDAP standardmäßig nicht verschlüsselt.
Google Cloud stellt sicher, dass der Datenverkehr zwischen virtuellen Maschinen verschlüsselt ist. Daher ist die Verwendung von unverschlüsseltem LDAP in Ihrer VPC akzeptabel. Wenn Sie Ihre VPC mit einem lokalen Netzwerk verbinden, achten Sie darauf, dass der LDAP-Verkehr nur über vertrauenswürdige Kanäle ausgetauscht wird.
Wenn Sie Cloud VPN verwenden, um Google Cloud und Ihr lokales Netzwerk zu verbinden, wird der Datenverkehr zwischen Google Cloud und Ihrem lokalen VPN-Endpunkt automatisch mit IPSec verschlüsselt.
Cloud Interconnect und Partner Interconnect bieten keine Verschlüsselung. Um eine sichere Kommunikation zu gewährleisten, richten Sie mithilfe einer VPN-Appliance vom Google Cloud Marketplace einen VPN-Tunnel über die Interconnect-Verbindung ein.
Verwenden Sie selektive Authentifizierung und AES für Gesamtstrukturvertrauensstellungen
Wenn Sie eine Vertrauensstellung zwischen Active Directory-Gesamtstrukturen erstellen, bevorzugen Sie Gesamtstrukturvertrauensstellungen gegenüber externen Vertrauensstellungen und nutzen Sie die folgenden Funktionen, um die Sicherheit zu verbessern:
Aktivieren Sie die selektive Authentifizierung für ausgehende Vertrauensstellungen in der Ressourcengesamtstruktur. Durch die selektive Authentifizierung wird sichergestellt, dass Nutzer aus der Organisationsgesamtstruktur nur auf Ressourcen in der Ressourcengesamtstruktur zugreifen können, wenn ihnen ausdrücklich eine Berechtigung erteilt wurde.
Aktivieren Sie die -Durchsetzung für die Gesamtstrukturgrenze für die vollständige Kerberos-Delegierung für eingehende Vertrauensstellungen in der Organisationsgesamtstruktur. Diese Funktion verhindert Angriffe auf die Eskalation von Berechtigungen, indem Ressourcen in der Ressourcengesamtstruktur nicht zugelassen werden, um Ticket Granting Tickets (TGTs) von Benutzern in der Organisationsgesamtstruktur anzufordern.
Aktivieren Sie die Option . Die andere Domain unterstützt die Option Kerberos AES-Verschlüsselung beim Erstellen von Vertrauensstellungen. Diese Option stellt sicher, dass Tickets, die für die gesamtstrukturübergreifende Authentifizierung verwendet werden, mit AES anstelle des weniger sicheren RC4-Algorithmus verschlüsselt werden.
Sicherheit
Im folgenden Abschnitt werden bewährte Methoden für die Sicherheit beschrieben.
Vermeiden Sie, dass die Google Cloud-Sicherheit die Active Directory-Sicherheit beeinträchtigt
Mit Active Directory können Sie genau steuern, welche Nutzer auf welche Ressourcen zugreifen dürfen. Wenn Computer als VM-Instanzen in Compute Engine bereitgestellt werden und Nutzer Zugriff auf das zugrunde liegende Google Cloud-Projekt haben, müssen Sie zusätzliche Pfade berücksichtigen, über die ein Nutzer möglicherweise auf einen Computer zugreifen kann:
Ein Projektmitglied, dem in einem Google Cloud-Projekt die Rolle Compute Instance Admin zugewiesen wurde, kann die Funktion zum Zurücksetzen von Kennwörtern verwenden, um lokale Administratorkonten zu erstellen. Lokale Administratorkonten stellen eine Bedrohung für die Sicherheit Ihrer Active Directory-Domain dar, da sie dazu verwendet werden können, Gruppenrichtlinien zu untergraben oder schädliche Software zu installieren, die möglicherweise Domänenanmeldeinformationen anderer angemeldeter Nutzer erfasst.
Durch Hinzufügen eines Startskripts kann ein privilegiertes Projektmitglied schädlichen Code in eine VM einfügen, die beim nächsten Neustart des Computers als
nt authority\systemausgeführt wird.Über die serielle Console kann ein privilegiertes Projektmitglied auch auf die Windows Special Administration Console (SAC) zugreifen. Windows betrachtet Anmeldungen über den SAC als lokale Anmeldungen. Der SAC kann daher missbraucht werden, um Richtlinien auszuweichen, die Anmeldungen über RDP verweigern, aber lokale Anmeldungen nicht verweigern.
Ein privilegiertes Projektmitglied kann den SAC verwenden, um einen
crashdump-Befehl auszugeben, der dazu führen kann, dass ein Speicherauszug auf die Festplatte geschrieben wird. Ein solcher Speicherauszug kann vertrauliche Informationen und Anmeldeinformationen enthalten.Durch Mounten der persistenten Festplatte auf einer anderen VM oder Verwenden von Snapshots kann ein privilegiertes Projektmitglied möglicherweise von Computern auf Festplatteninhalte zugreifen, möglicherweise einschließlich Speicherabbilder, auf denen der Nutzer sonst keine Berechtigung zum Anmelden hätte.
Wenn Sie Managed Microsoft AD verwenden, sind Sie standardmäßig besser vor diesen zusätzlichen Zugriffspfaden geschützt. Der Dienst erlaubt privilegierten Nutzern in Ihrem Projekt nicht, das Domänenadministratorkennwort zurückzusetzen, Startskripts auszuführen oder auf die serielle Console auf den AD-Domänencontroller-VMs zuzugreifen.
Stellen Sie zur weiteren Minderung dieser Risiken sicher, dass die IAM-Berechtigungen von Projekten mit VM-Instanzen mit Domänenbeitritt auf der Basis der geringsten Berechtigungen verwaltet werden. Sie können das Risiko für Nutzer von Organisationsrichtlinien, Gruppenrichtlinien und geschützten VMs weiter reduzieren:
Verwenden Sie eine Organisationsrichtlinie, um den Zugriff auf die serielle Schnittstelle zu deaktivieren.
Wenden Sie eine Gruppenrichtlinie an, die die Erstellung lokaler Administratorkonten verhindert, indem Sie den Kontomanager deaktivieren. Definieren Sie in Ihrer Gruppenrichtlinie (Computerkonfiguration > Einstellungen > Windows-Einstellungen > Ini-Dateien) die Einstellung INI-Dateien, um die folgende Einstellung anzuwenden:
- Aktion: Aktualisieren
- Dateipfad:
C:\Program Files\Google\Compute Engine\instance_configs.cfg - Name des Bereichs:
accountManager - Attributsname:
disable - Attributwert:
true
Wenden Sie eine Gruppenrichtlinie an, mit der alle lokalen Administratorkonten von VM-Instanzen entfernt werden. Verwenden Sie die Funktion Lokale Nutzer und Gruppen (Computerkonfiguration > Einstellungen > Systemsteuerungseinstellungen > Lokale Nutzer und Gruppen), um die Gruppenmitgliedschaft aus der Gruppe Administratoren und anderen vertraulichen Gruppen zu entfernen.
Erwägen Sie die Verwendung geschützter VMs in Kombination mit der BitLocker-Festplattenverschlüsselung, um zu verhindern, dass persistente Festplatten oder Snapshots von nicht autorisierten Benutzern gelesen werden können.
Vermeiden Sie Active Directory-Sicherheit, die die Sicherheit von Google Cloud beeinträchtigt
In einer Active Directory-Domain vertrauen Rechner Domaincontrollern, die die Authentifizierung und Autorisierung für sie durchführen. Sofern dies nicht durch Gruppenrichtlinien, die lokale Sicherheitsrichtlinie eines Computers oder die selektive Authentifizierung eingeschränkt ist, kann sich ein Nutzer, der seine Identität bei einem der Domänencontroller erfolgreich nachgewiesen hat, bei jedem Computer in der Domain anmelden.
Durch die Möglichkeit für Active Directory-Nutzer, sich an einem beliebigen Computer anzumelden, können Angreifer möglicherweise seitliche Bewegungen innerhalb einer Domain ausführen. Solche seitlichen Bewegungen können zu Eskalationen von Berechtigungen führen, wenn einige VM-Instanzen von Firewall-Einschränkungen ausgenommen sind oder Google Cloud -Dienstkonten verwenden: Auf die Anmeldeinformationen eines Dienstkontos können alle Prozesse und Nutzer einer VM-Instanz zugreifen. Jeder Nutzer, der sich mit Active Directory bei einem Computer anmelden kann, kann daher auf diese Anmeldeinformationen für das Dienstkonto zugreifen, um Zugriff auf alle Google Cloud-Ressourcen zu erhalten, auf die das Dienstkonto Zugriff hat.
Beim Einrichten von Managed Microsoft AD erstellt der Dienst eine Gruppe, um bestimmten Nutzern die Möglichkeit zu geben, RDP in VMs mit Domänenbeitritt durchzuführen.
Um das Risiko von seitlichen Bewegungen zu verringern, organisieren Sie Nutzer in Verwaltungsebenen und verwenden Sie Zugriff auf diesen Computer über das Netzwerk verweigern und Anmeldung über Remotedesktopdienste verweigern Gruppenrichtlinien, um den Zugriff auf Ihre VMs basierend auf der Ebene der Ebene einzuschränken.
Nutzen Sie in einer -Ressourcenstruktur-Topologie die selektive Authentifizierung zusätzlich, um die Anzahl der Nutzer aus anderen Gesamtstrukturen, die sich bei Ihren VMs anmelden dürfen, weiter einzuschränken. Sie können die Verwaltung selektiver Authentifizierungsberechtigungen vereinfachen, indem Sie Google Cloud- und Active Directory-Ressourcenstrukturen ausrichten: Wenn Active Directory-Organisationseinheiten Google Cloud-Projekten zugeordnet sind, können Sie Nutzern das Recht einräumen, sich auf einer Ebene zu authentifizieren, die mit Google übereinstimmt Cloud-Projekt.
In Fällen, in denen weder selektive Authentifizierung noch Gruppenrichtlinien anwendbar sind, erstellen Sie ein separates Dienstkonto, exportieren Sie die Dienstkontoschlüssel, speichern Sie sie auf der lokalen Festplatte der VM-Instanz oder auf einer Dateifreigabe und schützen Sie sie mit einem NTFS ACL, sodass nur autorisierte Active Directory-Nutzer die Schlüssel lesen und verwenden können.
Verwenden Sie dedizierte Projekte für Domänencontroller
Domänencontroller spielen eine entscheidende Rolle für die Sicherheit einer Active Directory-Domain, und ein Kompromiss eines einzelnen Domänencontrollers kann zu einem Kompromiss Ihrer gesamten Active Directory-Gesamtstruktur führen.
Verwenden Sie ein separates Google Cloud-Projekt, um Domänencontroller bereitzustellen und den Zugriff auf dieses Projekt mit den geringsten Berechtigungen zu gewähren, um das Risiko eines nicht autorisierten Zugriffs zu begrenzen. Beachten Sie beim Erstellen des Projekts, dass einige Berechtigungen möglicherweise von übergeordneten Ordnern geerbt werden. Um zu vermeiden, dass versehentlich Zugriff durch Vererbung gewährt wird, sollten Sie das Projekt außerhalb Ihrer üblichen Ordnerhierarchie erstellen.
Achten Sie beim Konfigurieren von IAM-Richtlinien für das Projekt besonders darauf, den Zugriff auf VM-Instanzen, die persistenten Festplatten, die die Datenbank ntds.dit enthalten, sowie alle Speicherorte, die möglicherweise Sicherungen enthalten, einzuschränken.
Zusätzlich zur Verwendung von IAM-Richtlinien, um den Zugriff auf das Projekt zu beschränken, sollten Sie das Projekt vor versehentlichem Löschen schützen.
Verwenden Sie separate VMs und Projekte zum Verwalten von Active Directory
Um Active Directory verwalten zu können, müssen Sie Tools wie Active Directory-Nutzer und -Computer oder das Active Directory-Verwaltungscenter verwenden können. Für diese Tools müssen Sie sich mit einem privilegierten Domänenkonto anmelden. Dadurch wird der Computer, auf dem Sie diese Tools ausführen, zu einem attraktiven Ziel für Diebstahl von Anmeldeinformationen oder Keylogging.
Um das Risiko zu minimieren, dass ein Angreifer privilegierte Domänenanmeldeinformationen erhält, verwenden Sie dedizierte VM-Instanzen für die Domänenverwaltung und behandeln Sie solche Verwaltungs-VMs wie Workstations mit privilegiertem Zugriff:
Verwenden Sie Gruppenrichtlinien, um sicherzustellen, dass nur eine ausgewählte Teilmenge von Nutzern das Recht hat, sich bei Verwaltungs-VMs anzumelden. Wenn Sie eine gestufte Verwaltung implementiert haben, entspricht diese Nutzergruppe der Stufe 0.
Ähnlich wie bei Domänencontrollern können administrative VMs gefährdet werden, indem Projektmitglieder lokale Administratorkonten erstellen, sich über die serielle Console anmelden oder ihre dauerhaften Festplatten manipulieren. Um das Risiko eines nicht autorisierten Zugriffs zu begrenzen, verwenden Sie ein separates Google Cloud-Projekt für administrative VMs und gewähren Sie den Zugriff auf dieses Projekt mit den geringsten Berechtigungen.
Wenn Sie über die Hybrid-Konnektivität von einem lokalen Netzwerk aus auf administrative VMs zugreifen möchten, stellen Sie administrative VMs in einem dedizierten VPC-Subnetz bereit. Mit einem Subnetz für Verwaltungs-VMs können Sie bei der Konfiguration Ihrer lokalen Firewalls besser zwischen Verwaltungs-VMs und anderen VMs unterscheiden. Wenn Sie eine Shared VPC verwenden, verwenden Sie Berechtigungen auf Subnetzebene, um sicherzustellen, dass nur privilegierte Administratoren VM-Instanzen im Verwaltungssubnetz bereitstellen dürfen. Diese Vorgehensweise stellt sicher, dass Nutzer Firewall-Regeln nicht umgehen können, wenn lokale Firewalls andere Regeln für Verwaltungs-VMs anwenden als für andere VMs, indem sie Nicht-Verwaltungs-VMs in das Verwaltungs-Subnetz einfügen.
Erwägen Sie außerdem, die Gruppenrichtlinie, mit der Anmeldebeschränkungen für Verwaltungs-VMs verwaltet werden, auf das Verwaltungssubnetz zu beschränken. Diese Vorgehensweise erzwingt die Abstimmung zwischen Anmeldebeschränkungen (basierend auf einer Gruppenrichtlinie) und Firewallregeln (basierend auf Subnetz- / IP-Adresse).
Zusätzlich zur Verwendung von IAM-Richtlinien, um den Zugriff auf das Projekt zu beschränken, sollten Sie das Projekt vor versehentlichem Löschen schützen.
Verwenden Sie Firewall-Regeln, um Domänencontroller und Server zu sichern
Domänencontroller stellen eine Reihe von Diensten bereit, darunter LDAP, DNS, Kerberos und RPC. Abhängig von Ihren Anwendungsfällen benötigen in Google Cloud bereitgestellte VMs sowie lokal ausgeführte Computer möglicherweise Zugriff auf verschiedene Teilmengen dieser Dienste, um Active Directory nutzen zu können.
Bei Verwendung von Managed Microsoft AD werden die AD-Domänencontroller in einem dedizierten Mandantenprojekt bereitgestellt. Das Netzwerk, in dem sich die AD-Domänencontroller befinden, wird automatisch durch gehärtete AD-spezifische Firewall-Regeln geschützt.
Um die Angriffsfläche von Domänencontrollern und Ihren VMs zu verringern, sollten Sie Firewalls verwenden, um jegliche Netzwerkkommunikation zu verbieten, die nicht unbedingt erforderlich ist. Weitere Informationen darüber, welche Firewall-Konfigurationen für den Zugriff auf Active Directory aus Ihrer VPC oder aus lokalen Netzwerken erforderlich sind, finden Sie in unserem Handbuch zu Verwenden von Active Directory über Firewalls hinweg.
Organisieren Sie Active Directory-Ressourcen und -Nutzer in Verwaltungsebenen
Einige Computer in einer Active Directory-Gesamtstruktur sind für die Gesamtsicherheit von Active Directory wichtiger als andere. Domänencontroller und administrative VMs sind zwei Beispiele für Computer, die besonders kritisch und daher besonders empfindlich gegenüber potenziellen Angriffen sind.
Verwenden Sie eine Taxonomie von Ebenen, um die Kritikalität jeder Ihrer Maschinen zu ermitteln. Während die richtige Anzahl von Ebenen von Ihrem spezifischen Setup abhängt, können Sie zuerst zwischen drei Ebenen unterscheiden:
Tier 0 (sehr kritisch): Diese Schicht umfasst alle Computer, die für die Sicherheit Ihrer Active Directory-Gesamtstruktur von entscheidender Bedeutung sind. Sobald ein einzelner Tier 0-Computer gefährdet ist, müssen Sie davon ausgehen, dass Ihre gesamte Gesamtstruktur gefährdet ist.
Tier 1 (kritisch): Diese Schicht umfasst die meisten Server in Ihrer Umgebung, einschließlich Anwendungsservern und Datenbankservern. Ein kompromittierter Tier-1-Server kann erhebliche geschäftliche Auswirkungen haben, stellt jedoch keine unmittelbare Bedrohung für die gesamte Gesamtstruktur dar.
Tier 2 (normal): Diese Stufe umfasst Arbeitsstationen oder andere Allzweckmaschinen. Es wird erwartet, dass ein Kompromiss eines Tier 2-Computers nur begrenzte Auswirkungen auf das Geschäft und die allgemeine Sicherheit hat.
Obwohl die unmittelbaren Auswirkungen eines kompromittierten Tier 2-Computers möglicherweise begrenzt erscheinen, besteht das Risiko von Folgewirkungen: Wenn ein Nutzer, der Administratorzugriff auf Tier 0- oder Tier 1-Computer hat, angelockt wird, sich bei einem kompromittierten Tier 2-Computer anzumelden, Sie könnten Opfer eines Keyloggers oder anderer Formen des Diebstahls von Anmeldeinformationen werden. Die erfassten Anmeldeinformationen können dann verwendet werden, um Maschinen höherer Ebenen anzugreifen, wodurch die Gesamtauswirkung eskaliert.
Stellen Sie sicher, dass Sie nicht nur Computer, sondern auch Benutzerkonten kategorisieren und einschränken, auf welche Gruppe von Computern diese Nutzer Zugriff haben, um solche Folgewirkungen zu vermeiden:
Tier 0 (sehr kritisch): Nutzer, die Zugriff auf Tier 0-Computer haben.
Tier 1 (kritisch): Nutzer, die Zugriff auf Tier 1-Computer haben.
Tier 2 (Normal): Nutzer, die Zugriff auf Tier 2-Computer haben.
Verwenden Sie die folgende Tabelle als Richtlinie, für die Nutzer Zugriff auf welche Ressourcen haben sollen:
| Group | Stufe | Domainzugang | Computerzugriff der Stufe 0 | Tier 1-Computerzugriff | Tier 2-Computerzugriff |
|---|---|---|---|---|---|
| Active Directory-Administratoren | 0 | Administrator | eingeschränkter Nutzer | Gesperrt | Gesperrt |
| Administrationsserver-Administratoren | 0 | eingeschränkter Nutzer | Administrator | Gesperrt | Gesperrt |
| Serveradministratoren | 1 | eingeschränkter Nutzer | Gesperrt | Administrator | Gesperrt |
| VDI-Workstation-Administratoren | 2 | eingeschränkter Nutzer | Gesperrt | Gesperrt | Administrator |
| VDI-Workstations-Nutzer | 2 | eingeschränkter Nutzer | Gesperrt | Gesperrt | eingeschränkter Nutzer |
Weitere Informationen und bewährte Methoden zum Implementieren eines Verwaltungsschichtmodells in Active Directory finden Sie in der Microsoft-Dokumentation.
Wenn Sie das Administrationsschichtmodell in Ihrer Active Directory-Gesamtstruktur verwenden, stellen Sie sicher, dass die Integrität nicht durch Gesamtstrukturvertrauensbeziehungen beeinträchtigt wird. Wenn die vertrauenswürdige Gesamtstruktur auch ein abgestuftes Verwaltungsmodell anwendet, verwenden Sie die selektive Authentifizierung, um sicherzustellen, dass Nutzer aus der vertrauenswürdigen Gesamtstruktur nur auf Ressourcen innerhalb derselben Ebene zugreifen dürfen:
Wenn die vertrauenswürdige Gesamtstruktur keine gestufte Verwaltung implementiert, ordnen Sie die vertrauenswürdige Gesamtstruktur einer bestimmten Schicht zu und verwenden Sie die selektive Authentifizierung, um sicherzustellen, dass Nutzer aus der vertrauenswürdigen Gesamtstruktur nur auf Ressourcen dieser bestimmten Schicht zugreifen dürfen.
Verwenden von VPC-Dienststeuerelementen und privatem Google-Zugriff für lokale Hosts
Mit Managed Microsoft AD-APIs können Sie das Administratorkennwort zurücksetzen und andere vertrauliche Vorgänge ausführen. Für kritische Produktionsbereitstellungen empfehlen wir, VPC Service Controls zu aktivieren und Private Google Access für lokale Hosts zu verwenden, um die Sicherheit zu erhöhen.
Verwaltung
Im folgenden Abschnitt werden bewährte Methoden für die Verwaltung von Active Directory beschrieben.
Richten Sie die Ressourcenstrukturen von Google Cloud und Active Directory aus
Wenn Sie eine neue Active Directory-Domain oder Gesamtstruktur in Google Cloud bereitstellen, müssen Sie eine Organisationseinheitsstruktur (OU) definieren, um Ihre Ressourcen mit Ihrer Active Directory-Domain zu organisieren. Anstatt eine völlig neue Struktur zu entwerfen oder die Struktur anzuwenden, die Sie in Ihrer lokalen Umgebung verwenden, erstellen Sie eine Organisationseinheitenstruktur, die an Ihrer Google Cloud-Ressourcenhierarchie ausgerichtet ist:
Wenn Sie ein abgestuftes Verwaltungsmodell verwenden, müssen die Organisationseinheiten der obersten Ebene Ihre Verwaltungsebenen widerspiegeln.
Erstellen Sie für jede Ebene Organisationseinheiten für Nutzer und Gruppen. Wenn Sie eine große Anzahl von Nutzern und Gruppen verwalten möchten, erstellen Sie gegebenenfalls Unter-Organisationseinheiten.
Erstellen Sie für jede Ebene eine Organisationseinheit
Projectsund Unter-Organisationseinheiten für jedes Google Cloud-Projekt, das Active Directory-Ressourcen enthält. Verwenden Sie die projektspezifische Unter-Organisationseinheit, um Computerkonten, Dienstkonten oder andere Active Directory-Ressourcen zu verwalten, die den Google Cloud-Ressourcen des jeweiligen Projekts entsprechen. Stellen Sie sicher, dass zwischen Organisationseinheiten und Projekten eine 1:1-Zuordnung besteht.
Das folgende Diagramm zeigt eine Beispielhierarchie, die diesen Prinzipien folgt:
Wenn die Anzahl der Projekte, die Active Directory-Ressourcen enthalten, moderat ist, können Sie unter der Organisationseinheit Projects eine flache Organisationseinheitsstruktur erstellen. Wenn Sie eine große Anzahl von Projekten verwalten möchten und Ihre Google Cloud-Ressourcenhierarchie so konzipiert haben, dass mehrere Ordnerebenen verwendet werden, sollten Sie diese Ordnerstruktur unter der Organisationseinheit Projects berücksichtigen.
Das Ausrichten Ihrer Active Directory-Organisationseinheitsstruktur und der Google Cloud-Ressourcenhierarchie bietet mehrere Vorteile:
Wenn Sie Administratorrechte mithilfe von IAM-Richtlinien an ein Google Cloud-Projekt delegieren, müssen Sie Projektbenutzern möglicherweise auch bestimmte Berechtigungen in Active Directory gewähren. Beispielsweise müssen Compute Engine-Administratoren möglicherweise in der Lage sein, Computer unter einer bestimmten Organisationseinheit mit der Domain zu verbinden. Durch das Ausrichten von Organisationseinheiten und Google Cloud-Projekten können Sie solche Berechtigungen in Active Directory auf derselben Granularitätsstufe wie in Google Cloud erteilen.
Wenn Sie Gruppenrichtlinienobjekte (Group Policy Objects, GPOs) zum Verwalten von Computern verwenden möchten, können Sie mithilfe einer Organisationseinheitenstruktur, die die Google Cloud-Ressourcenhierarchie widerspiegelt, sicherstellen, dass Gruppenrichtlinienobjekte konsistent auf alle VMs eines bestimmten Projekts oder Ordners angewendet werden.
Wenn Sie eine gesamtstrukturübergreifende Vertrauensstellung mit bedingter Authentifizierung verwenden, können Sie die Organisationseinheiten verwenden, die Google Cloud-Projekten entsprechen, um die Berechtigung Erlaubt, pro Projekt zu authentifizieren.
Wenn Sie ein Projekt in Google Cloud löschen, können Sie einfach die zugehörige Organisationseinheit löschen, um das Risiko zu verringern, dass veraltete Ressourcen in Ihrem Verzeichnis verbleiben.
Wenn Sie der Meinung sind, dass Ihre OU-Struktur von Ihrer Projektstruktur abweichen muss, kann dies ein Hinweis darauf sein, dass Ihre Projektstruktur zu feinkörnig oder zu grobkörnig ist.
Verwenden Sie Google-Zeitserver
Die Kerberos-Authentifizierung basiert auf Zeitstempeln als Teil ihres Protokolls. Damit die Authentifizierung erfolgreich ist, müssen die Uhren des Client- und Servercomputers innerhalb eines bestimmten Bereichs synchronisiert werden. Standardmäßig erlaubt Active Directory nicht mehr als 5 Minuten Unterschied.
In einer lokalen Active Directory-Umgebung ist dies die Standardkonfiguration für die Synchronisierung von Zeit:
- Bei Computern mit Domänenbeitritt wird die Zeit mit einem Domaincontroller synchronisiert.
- Domaincontroller synchronisieren ihre Zeit mit dem PDC-Emulator ihrer Domain.
- PDC-Emulatoren aller Domains synchronisieren ihre Zeit mit dem PDC-Emulator der Gesamtstruktur-Stammdomain.
In dieser Konfiguration ist der PDC-Emulator der Gesamtstruktur-Stammdomain die letzte Zeit für Active Directory. Es ist üblich, diesen Computer so zu konfigurieren, dass ein externer NTP-Server als Zeitquelle verwendet wird.
In Compute Engine wird für Windows-VMs die Metadatenserver (metadata.google.internal) als NTP-Server verwendet, der wiederum auf den NTP-Servern von Google für die richtige Zeit basiert. Durch das Verbinden einer VM mit einer Active Directory-Domain wird diese Standardkonfiguration nicht geändert.
Behalten Sie die Standardkonfiguration von Compute Engine bei, es sei denn, der PDC-Emulator Ihrer Gesamtstruktur-Stammdomain wird außerhalb von Google Cloud bereitgestellt.
Wenn Ihr PDC-Emulator außerhalb von Google Cloud bereitgestellt wird, konfigurieren Sie ihn so, dass time.google.com als NTP-Quelle verwendet wird.
Alternativ können Sie das Active Directory-Standardverhalten der Synchronisierung von Zeit mit dem PDC-Emulator wiederherstellen, indem Sie Compute Engine-VMs für die Verwendung der NTP-Quelle DOMHIER neu konfigurieren und die Firewall-Regeln konfigurieren, um eingehenden NTP-Traffic (UDP/123) zu Ihren Domaincontrollern zuzulassen.
Konsolidieren und überwachen Sie Überwachungsprotokolle
Wenn Sie Active Directory in Google Cloud bereitstellen, ist die Sicherheit Ihrer Active Directory-Gesamtstruktur und Ihrer Google Cloud-Projekte an eine andere gebunden: Verdächtige Aktivitäten in Active Directory und Windows können die Sicherheit einiger anderer Ressourcen in Google Cloud gefährden Genauso wie verdächtige Aktivitäten in Google Cloud Ihr Active Directory gefährden können.
Konsistente Überwachungsprotokolle sind ein wichtiges Instrument, um Bedrohungen oder Fehlkonfigurationen frühzeitig zu erkennen und frühere Aktivitäten zu rekonstruieren und zu untersuchen. Mit Cloud Audit Logging können Sie Administrationsaktivitätsprotokolle und Datenzugriffsprotokolle erfassen und analysieren. Ebenso können Sie die Firewall-Regelprotokolle und VPC-Flussprotokolle verwenden, um den Netzwerkverkehr zu analysieren. Diesen Plattformdiensten sind jedoch keine sicherheitsrelevanten Ereignisse in Active Directory bekannt. Installieren Sie das, um einen konsistenten Überwachungspfad zu erstellen, der sowohl plattformbezogene Überwachungsereignisse als auch Active Directory-bezogene Überwachungsereignisse abdeckt Cloud-Protokollierungsagent auf Domänencontrollern und Computern mit Domänenbeitritt zum Exportieren von Windows-Sicherheitsereignisprotokollen in die Cloud-Protokollierung.
Standardmäßig erfasst das Windows-Sicherheitsereignisprotokoll möglicherweise nicht alle Ereignisse, die Sie für Ihre Überwachungszwecke benötigen. Lesen Sie die Microsoft-Empfehlungen zum Konfigurieren von Überwachungsrichtlinien und zur Überwachung von Active Directory auf Anzeichen von Kompromissen, um sicherzustellen, dass Sie alle relevanten Überwachungsereignisse erfassen.
Bei einer großen Anzahl von Ereignissen können kritische Ereignisse leicht übersehen werden. Um zu vermeiden, dass kritische Ereignisse fehlen, erstellen Sie protokollbasierte Metriken für Ereignisse, die besonders kritisch oder verdächtig sein können, und ziehen Sie in Betracht, Warnungen zu konfigurieren, um Sie zu benachrichtigen, wenn die Die Ereignisrate ändert oder überschreitet akzeptable Schwellenwerte.
Nächste Schritte
Finden Sie heraus, welches Muster für die Verwendung von Active Directory in einer Hybridumgebung am besten zu Ihrer Situation passt.
Erfahren Sie, wie Sie Active Directory für VMs so konfigurieren können, dass sie automatisch einer Domain beitreten.
Probieren Sie andere Google Cloud-Funktionen selbst aus. mit unseren Anleitungen testen