In diesem Dokument werden die Anforderungen beschrieben, die bei der Bereitstellung von Active Directory in Google Cloud zu berücksichtigen sind. Außerdem erfahren Sie, wie Sie die richtige Architektur auswählen.
Wenn Sie Active Directory mit Cloud Identity oder Google Workspace verbinden (siehe Muster für die Authentifizierung von Belegschaftsnutzern in einer Hybridumgebung), können Sie Nutzern aus Ihren vorhandenen Active Directory-Domains die Authentifizierung und den Zugriff auf Ressourcen in Google Cloud ermöglichen. Sie können Active Directory auch in Google Cloud bereitstellen, wenn Sie planen, Active Directory zur Verwaltung von Windows-Servern in Google Cloud zu verwenden, oder wenn Sie auf Protokolle angewiesen sind, die von Google Cloud nicht unterstützt werden.
Bevor Sie Active Directory auf Google Cloud bereitstellen, müssen Sie zuerst entscheiden, welche Domain und Architektur für die Gesamtstruktur Sie verwenden und wie Sie sie in Ihre vorhandene Active Directory-Gesamtstruktur integrieren.
Anforderungen prüfen
Active Directory unterstützt eine Reihe von Architekturen für Domains und Gesamtstrukturen. In einer Hybridumgebung besteht eine Option darin, eine einzelne Active Directory-Domain über mehrere Umgebungen hinweg zu erweitern. Alternativ können Sie separate Domains oder Gesamtstrukturen verwenden und diese mithilfe von Vertrauensstellungen verbinden. Welche Architektur die beste ist, hängt von Ihren Anforderungen ab.
Prüfen Sie die folgenden Faktoren, um die beste Architektur auszuwählen:
- Ausrichtung an vorhandenen Sicherheitszonen
- Interaktion zwischen lokalen und Google Cloud-Ressourcen
- Administrative Autonomie
- Verfügbarkeit
In den folgenden Abschnitten werden diese Faktoren erläutert.
Ausrichtung an vorhandenen Sicherheitszonen
Überprüfen Sie zuerst den Aufbau Ihres lokalen Netzwerks.
In Ihrer lokalen Umgebung haben Sie möglicherweise Ihr Netzwerk in mehrere Sicherheitszonen unterteilt – z. B. durch die Verwendung separater VLANs oder Subnetze. In einem Netzwerk, das in Sicherheitszonen segmentiert wurde, ist die Kommunikation innerhalb einer Sicherheitszone entweder uneingeschränkt möglich oder unterliegt nur einfachen Firewall- und Audit-Richtlinien. Dagegen unterliegt jede Kommunikation zwischen mehreren Sicherheitszonen strengen Firewall-, Audit- oder Traffic-Prüfungsrichtlinien.
Der Zweck von Sicherheitszonen geht jedoch über das bloße Beschränken und Prüfen der Netzwerkkommunikation hinaus – Sicherheitszonen sollten Vertrauensgrenzen implementieren.
Vertrauensgrenzen
Jeder Rechner in einem Netzwerk führt mehrere Prozesse aus. Diese können lokal über Interprocess Communication miteinander kommunizieren und über Protokolle wie HTTP zwischen Maschinen kommunizieren. In diesem Kommunikationsnetzwerk vertrauen sich Peers nicht immer gleichermaßen. Beispielsweise vertrauen Prozesse unter Umständen Prozessen, die auf demselben Rechner ausgeführt werden, mehr als Prozessen, die auf anderen Rechnern ausgeführt werden. Und einige Rechner gelten möglicherweise als vertrauenswürdiger als andere.
Eine Vertrauensgrenze erzwingt die Differenzierung zwischen Kommunikationsparteien, wodurch einer Gruppe von Kommunikationsparteien mehr vertraut wird als einer anderen Gruppe.
Vertrauensgrenzen sind wichtig, um die Auswirkungen eines Angriffs einzudämmen. Angriffe enden selten, sobald ein einzelnes System manipuliert wurde – unabhängig davon, ob es sich bei dem System um einen einzelnen Prozess oder einen ganzen Rechner handelt. Stattdessen versucht ein Angreifer wahrscheinlich, den Angriff auf andere Systeme auszuweiten. Da zwischen Systemen in einer Vertrauensgrenze keine Differenzierung stattfindet, ist es einfacher, einen Angriff innerhalb dieser Vertrauensgrenze auszuweiten, als Systeme über eine Vertrauensgrenze hinweg anzugreifen.
Sobald ein System in einer Vertrauensgrenze manipuliert wurde, muss angenommen werden, dass alle anderen Systeme in dieser Vertrauensgrenze manipuliert wurden. Anhand dieser Annahme können Sie Vertrauensgrenzen ermitteln oder überprüfen, ob eine bestimmte Systemgrenze eine Vertrauensgrenze ist. Beispiel:
Beispiel: Ein Angreifer hat die höchste Zugriffsebene für Ziel A erreicht (z. B. Administrator- oder Root-Zugriff auf einen Rechner oder eine Anwendung). Wenn er diese Berechtigungen nutzen kann, um dieselbe Zugriffsebene für Ziel B zu erreichen, dann befinden sich A und B definitionsgemäß innerhalb derselben Vertrauensgrenze. Andernfalls verläuft eine Vertrauensgrenze zwischen A und B.
Durch die Beschränkung der Netzwerkkommunikation können Sicherheitszonen bei der Implementierung von Vertrauensgrenzen helfen. Damit eine Sicherheitszone jedoch zu einer echten Vertrauensgrenze wird, müssen die Arbeitslasten auf jeder Seite der Grenze zwischen Anfragen aus derselben Sicherheitszone und Anfragen, die aus anderen Sicherheitszonen stammen, differenzieren – und letztere genauer untersuchen.
Zero-Trust-Modell
Das Zero-Trust-Modell ist das bevorzugte Netzwerkmodell in Google Cloud.
Bei einem einzelnen manipulierten System in einer Vertrauensgrenze können Sie davon ausgehen, dass alle Systeme innerhalb dieser Grenze manipuliert sind. Diese Annahme legt nahe, dass kleinere Vertrauensgrenzen besser sind. Je kleiner die Vertrauensgrenze ist, desto weniger Systeme werden manipuliert und desto mehr Grenzen muss ein Angreifer überwinden, damit sich ein Angriff ausbreitet.
Das Zero-Trust-Modell führt diese Idee zu ihrer logischen Schlussfolgerung: Jeder Rechner im Netzwerk wird als eindeutige Sicherheitszone und Vertrauensgrenze behandelt. Die gesamte Kommunikation zwischen Rechnern unterliegt denselben Kontrollen und Firewallregeln und alle Netzwerkanfragen werden so behandelt, als stammten sie von einer nicht vertrauenswürdigen Quelle.
Auf Netzwerkebene können Sie ein Zero-Trust-Modell implementieren, wenn Sie mithilfe von Firewallregeln den Traffic beschränken und ihn mit VPC-Flusslogs und Firewallregel-Logging analysieren. Auf Anwendungsebene müssen Sie dafür sorgen, dass alle Anwendungen Authentifizierungen, Autorisierungen und Audits konsequent und sicher durchführen.
Vertrauensgrenzen in Active Directory
In einer Active Directory-Domain vertrauen Rechner Domaincontrollern, die die Authentifizierung und Autorisierung für sie durchführen. Sobald ein Nutzer seine Identität einem der Domaincontroller gegenüber bestätigt hat, kann er sich standardmäßig auf allen Rechnern derselben Domain anmelden. Alle Zugriffsrechte, die der Nutzer vom Domaincontroller erhält (in Form von Berechtigungen und Gruppenmitgliedschaften), gelten für zahlreiche Rechner der Domain.
Durch die Verwendung von Gruppenrichtlinien können Sie unterbinden, dass Nutzer auf bestimmte Rechner zugreifen, bzw. ihre Rechte auf bestimmten Computern einschränken. Sobald ein Rechner jedoch manipuliert wurde, kann ein Angreifer möglicherweise Passwörter, Passwort-Hashes oder Kerberos-Tokens anderer Domainnutzer stehlen, die auf demselben Rechner angemeldet sind. Der Angreifer kann diese Anmeldedaten dann nutzen, um den Angriff auf andere Domains in der Gesamtstruktur auszuweiten.
Angesichts dieser Faktoren ist es am besten, vorauszusetzen, dass sich alle Rechner einer Gesamtstruktur in einer Vertrauens-Sicherheitsgrenze befinden.
Im Vergleich zu Domaingrenzen, deren Zweck darin besteht, die Replikation zu steuern und verschiedenen Teilen der Organisation administrative Autonomie zu gewähren, können Gesamtstrukturgrenzen eine stärkere Isolation bieten. Gesamtstrukturen können als Vertrauensgrenze dienen.
Active Directory-Gesamtstrukturen mit Sicherheitszonen abgleichen
Angenommen, die Gesamtstruktur als Vertrauensgrenze beeinflusst das Design der Sicherheitszonen. Wenn sich eine Gesamtstruktur über zwei Sicherheitszonen erstreckt, ist es für Angreifer einfacher, die Grenze zwischen diesen Sicherheitszonen zu überwinden. Dadurch werden die beiden Sicherheitszonen faktisch zu einer und bilden eine einzelne Vertrauensgrenze.
In einem Zero-Trust-Modell kann jeder Rechner in einem Netzwerk als separate Sicherheitszone betrachtet werden. Das Bereitstellen von Active Directory in einem solchen Netzwerk untergräbt dieses Konzept und weitet die effektive Sicherheitsgrenze auf alle Rechner der Active Directory-Gesamtstruktur aus.
Damit eine Sicherheitszone als Vertrauensgrenze dienen kann, müssen Sie dafür sorgen, dass sich die komplette Active Directory-Gesamtstruktur in der Sicherheitszone befindet.
Auswirkungen auf die Erweiterung von Active Directory in Google Cloud
Wenn Sie eine Bereitstellung in Google Cloud planen, für die Active Directory erforderlich ist, müssen Sie sich zwischen zwei Optionen entscheiden, um die Bereitstellung an Ihre vorhandenen Sicherheitszonen anzupassen:
Bestehende Sicherheitszone auf Google Cloud erweitern: Sie können eine oder mehrere Ihrer vorhandenen Sicherheitszonen auf Google Cloud erweitern, indem Sie eine freigegebene VPC in Google Cloud bereitstellen und sie mit Cloud VPN oder Cloud Interconnect mit der vorhandenen Zone verbinden.
Ressourcen, die lokal und in Google Cloud bereitgestellt werden und eine gemeinsame Zone haben, können auch eine gemeinsame Active Directory-Gesamtstruktur nutzen, sodass keine separate Gesamtstruktur in Google Cloud bereitgestellt werden muss.
Betrachten Sie als Beispiel ein vorhandenes Netzwerk mit einem Entwicklungsperimeter- und einem Produktionsperimeternetzwerk als Sicherheitszonen sowie jeweils einer separaten Active Directory-Gesamtstruktur in den einzelnen Sicherheitszonen. Wenn Sie die Sicherheitszonen auf Google Cloud erweitern, sind alle Bereitstellungen in Google Cloud ebenfalls Teil einer dieser beiden Sicherheitszonen und können dieselben Active Directory-Gesamtstrukturen verwenden.
Neue Sicherheitszonen einführen: Das Erweitern einer Sicherheitszone ist möglicherweise nicht anwendbar – entweder, weil Sie eine Zone nicht weiter erweitern möchten oder weil die Sicherheitsanforderungen Ihrer vorhandenen Sicherheitszonen nicht den Anforderungen Ihrer Google Cloud-Bereitstellungen entsprechen. Sie können Google Cloud als zusätzliche Sicherheitszonen behandeln.
Betrachten Sie beispielsweise eine lokale Umgebung, die zwar ein Perimeternetzwerk hat, jedoch nicht zwischen Entwicklungs- und Produktionsarbeitslasten unterscheidet. Damit diese Arbeitslasten in Google Cloud getrennt werden, können Sie zwei freigegebene VPCs erstellen und als neue Sicherheitszonen betrachten. Anschließend stellen Sie zwei zusätzliche Active Directory-Gesamtstrukturen in Google Cloud bereit, eine pro Sicherheitszone. Gegebenenfalls können Sie Vertrauensstellungen zwischen Gesamtstrukturen einrichten, um die Authentifizierung über Sicherheitszonen hinweg zu ermöglichen.
Interaktion zwischen lokalen und Google Cloud-Ressourcen
Der zweite Faktor, der bei der Erweiterung Ihres Active Directory auf Google Cloud zu berücksichtigen ist, ist die Interaktion von Nutzern und Ressourcen zwischen lokal und Google Cloud. Je nach Anwendungsfall kann diese Interaktion leicht bis schwer sein.
Leichte Interaktion
Wenn der einzige Zweck der Verwendung von Active Directory in Google Cloud darin besteht, eine Reihe von Windows-Servern zu verwalten und Administratoren die Anmeldung bei diesen Servern zu ermöglichen, ist die Interaktion zwischen Umgebungen leicht:
- Die Gruppe der Mitarbeiter, die mit Ressourcen in Google Cloud interagieren, ist auf Verwaltungsmitarbeiter beschränkt.
- Anwendungen, die in Google Cloud bereitgestellt werden, interagieren möglicherweise überhaupt nicht mit lokalen Anwendungen oder tun dies, ohne auf Windows-Authentifizierungsfunktionen wie Kerberos und NTLM angewiesen zu sein.
In einem leichten Szenario können Sie Ihre lokale Umgebung und die Google Cloud-Umgebung auf eine der folgenden beiden Arten integrieren:
Zwei disjunkte Active Directory-Gesamtstrukturen: Sie können die beiden Umgebungen isolieren, wenn Sie zwei separate Active Directory-Gesamtstrukturen verwenden, die keine Vertrauensstellung teilen. Wenn Sie Administratoren die Authentifizierung ermöglichen möchten, verwalten Sie in der Google Cloud-Gesamtstruktur einen separaten Satz von Nutzerkonten.
Durch das Führen doppelter Nutzerkonten erhöht sich der Verwaltungsaufwand und es besteht die Gefahr, dass vergessen wird, Konten zu deaktivieren, wenn Mitarbeiter das Unternehmen verlassen. Ein besserer Ansatz besteht darin, diese Konten automatisch bereitzustellen.
Wenn Nutzerkonten in Ihrem lokalen Active Directory von einem Personalverwaltungssystem (Human Resources Information System: HRIS) bereitgestellt werden, können Sie möglicherweise einen ähnlichen Mechanismus verwenden, um Nutzerkonten in der Google Cloud-Gesamtstruktur bereitzustellen und zu verwalten. Alternativ können Sie Tools wie Microsoft Identity Manager verwenden, um Nutzerkonten zwischen Umgebungen zu synchronisieren.
Zwei Active Directory-Gesamtstrukturen mit Gesamtstruktur-übergreifender Vertrauensstellung: Wenn Sie zwei Active Directory-Gesamtstrukturen verwenden und diese mit einer Gesamtstruktur-übergreifenden Vertrauensstellung verbinden, können Sie vermeiden, doppelte Konten zu führen. Administratoren verwenden dasselbe Nutzerkonto, um sich in beiden Umgebungen zu authentifizieren. Obwohl die Isolation zwischen Umgebungen als schwächer angesehen werden kann, können Sie durch die Verwendung separater Gesamtstrukturen eine Vertrauensgrenze zwischen Ihrer lokalen und der Google Cloud-Umgebung aufrechterhalten.
Moderate Interaktion
Ihr Anwendungsfall ist möglicherweise komplexer. Beispiel:
- Administratoren, die sich auf Windows-Servern anmelden, die in Google Cloud bereitgestellt werden, müssen möglicherweise auf lokal gehostete Dateifreigaben zugreifen.
- Anwendungen verwenden möglicherweise Kerberos oder NTLM, um sich über Umgebungsgrenzen hinweg zu authentifizieren und zu kommunizieren.
- Sie können Mitarbeitern die Verwendung der integrierten Windows-Authentifizierung (IWA) ermöglichen, um sich bei Webanwendungen zu authentifizieren, die in Google Cloud bereitgestellt werden.
In einem moderaten Szenario birgt die Verwendung von zwei disjunkten Active Directory-Gesamtstrukturen eventuell zu große Einschränkungen: Sie können Kerberos nicht für die Authentifizierung zwischen den beiden Gesamtstrukturen verwenden und bei der Passthrough-Authentifizierung von NTLM müssen Nutzerkonten und Passwörter synchronisiert sein.
In diesem Fall empfehlen wir die Verwendung von zwei Active Directory-Gesamtstrukturen mit einer Gesamtstruktur-übergreifenden Vertrauensstellung.
Starke Interaktion
Bestimmte Arbeitslasten, einschließlich Bereitstellungen der virtuellen Desktopinfrastruktur (VDI), erfordern unter Umständen eine starke Interaktion zwischen lokalen Ressourcen und solchen, die in Google Cloud bereitgestellt werden. Wenn Ressourcen über mehrere Umgebungen hinweg eng miteinander verbunden sind, ist es möglicherweise nicht praktikabel, eine Vertrauensgrenze zwischen Umgebungen aufrechtzuerhalten. Außerdem kann sich die Verwendung von zwei Gesamtstrukturen mit einer Gesamtstruktur-übergreifenden Vertrauensstellung als zu einschränkend erweisen.
In diesem Fall empfehlen wir, eine einzelne Active Directory-Gesamtstruktur zu nutzen und diese in den verschiedenen Umgebungen freizugeben.
Administrative Autonomie
Der dritte Faktor, der bei der Erweiterung Ihres Active Directory auf Google Cloud zu berücksichtigen ist, ist die administrative Autonomie.
Wenn Sie Arbeitslasten lokal und in Google Cloud verteilen möchten, unterscheiden sich die Arbeitslasten, die Sie in Google Cloud ausführen, möglicherweise stark von den lokalen Arbeitslasten. Sie könnten sich sogar dafür entscheiden, die beiden Umgebungen von verschiedenen Teams verwalten zu lassen.
Die Aufteilung der Zuständigkeiten auf verschiedene Teams setzt voraus, dass jedem Team eine gewisse administrative Autonomie gewährt wird. In Active Directory können Sie Teams die Befugnis erteilen, Ressourcen zu verwalten, indem Sie die delegierte Administration oder separate Domains verwenden.
Die delegierte Administration ist eine einfache Möglichkeit, Verwaltungsaufgaben zu delegieren und Teams eine gewisse Autonomie zu gewähren. Durch die Aufrechterhaltung nur einer einzelnen Domain können Sie außerdem einfacher für Konsistenz zwischen Umgebungen und Teams sorgen.
Sie können jedoch nicht alle Verwaltungsfunktionen delegieren und die gemeinsame Nutzung einer einzelnen Domain kann den Verwaltungsaufwand für die Koordinierung zwischen Teams erhöhen. In einem solchen Fall empfehlen wir die Verwendung separater Domains.
Verfügbarkeit
Der letzte Faktor bei der Erweiterung Ihres Active Directory auf Google Cloud ist die Verfügbarkeit. Für jede Domain in einer Active Directory-Gesamtstruktur dient der Domaincontroller als Identitätsanbieter für Nutzer in dieser Domain.
Bei der Verwendung von Kerberos zur Authentifizierung muss ein Nutzer an verschiedenen Stellen mit einem Active Directory-Domaincontroller interagieren:
- Erstauthentifizierung (Erhalt eines Ticket gewährenden Tickets)
- Regelmäßige erneute Authentifizierung (Aktualisierung eines Ticket gewährenden Tickets)
- Authentifizierung für eine Ressource (Erhalt eines Servicetickets)
Für die Erstauthentifizierung und die regelmäßige erneute Authentifizierung ist nur die Kommunikation mit einem einzelnen Domaincontroller erforderlich – einem Domaincontroller der Domain, der der Nutzer angehört.
Bei der Authentifizierung für eine Ressource muss möglicherweise mit mehreren Domaincontrollern interagiert werden, je nach der Domain, in der sich die Ressource befindet:
- Befindet sich die Ressource in derselben Domain wie der Nutzer, kann der Nutzer denselben Domaincontroller (oder einen anderen Domaincontroller derselben Domain) verwenden, um den Authentifizierungsprozess abzuschließen.
- Befindet sich die Ressource in einer anderen Domain, besteht aber eine direkte Vertrauensstellung zur Domain des Nutzers, dann muss der Nutzer mit mindestens zwei Domaincontrollern interagieren: mit einem in der Ressourcendomain und einem in der Domain des Nutzers.
- Wenn die Ressource und der Nutzer zu verschiedenen Domains gehören und nur eine indirekte Vertrauensstellung zwischen diesen Domains besteht, ist für eine erfolgreiche Authentifizierung die Kommunikation mit den Domaincontrollern jeder Domain im Vertrauenspfad erforderlich.
Wenn Sie Nutzer und Ressourcen in verschiedenen Active Directory-Domains oder -Gesamtstrukturen platzieren, kann dadurch die Verfügbarkeit insgesamt beeinträchtigt werden. Da für die Authentifizierung die Interaktion mit mehreren Domains erforderlich ist, kann sich ein Ausfall einer Domain auf die Verfügbarkeit von Ressourcen in anderen Domains auswirken.
Angesichts der möglichen Auswirkungen der Active Directory-Topologie auf die Verfügbarkeit empfehlen wir, Ihre Active Directory-Topologie mit Ihrer Hybridstrategie abzugleichen.
Verteilte Arbeitslasten
Um von den einzigartigen Funktionen jeder Computing-Umgebung zu profitieren, können Sie einen hybriden Ansatz verwenden, um Arbeitslasten auf diese Umgebungen zu verteilen. In einer solchen Konfiguration hängen die Arbeitslasten, die Sie in Google Cloud bereitstellen, wahrscheinlich von anderen Infrastrukturen oder Anwendungen ab, die lokal ausgeführt werden, was eine hochverfügbare Hybridkonnektivität zu einer kritischen Anforderung macht.
Wenn Sie eine separate Active Directory-Gesamtstruktur oder -Domain in Google Cloud bereitstellen und eine Vertrauensstellung verwenden, um sie mit Ihrem lokalen Active Directory zu verbinden, fügen Sie eine weitere Abhängigkeit zwischen Google Cloud und Ihrer lokalen Umgebung hinzu. Diese Abhängigkeit wirkt sich nur minimal auf die Verfügbarkeit aus.
Redundante Arbeitslasten
Wenn Sie Google Cloud zum Sicherstellen der Geschäftskontinuität einsetzen, spiegeln Ihre Arbeitslasten in Google Cloud einige der Arbeitslasten in Ihrer lokalen Umgebung wider. Diese Konfiguration ermöglicht es der einen Umgebung, die Rolle der anderen Umgebung zu übernehmen, wenn ein Fehler auftritt. Sie müssen also jede Abhängigkeit zwischen diesen Umgebungen untersuchen.
Wenn Sie eine separate Active Directory-Gesamtstruktur oder -Domain in Google Cloud bereitstellen und diese über eine Vertrauensstellung mit Ihrem lokalen Active Directory verbinden, können Sie möglicherweise eine Abhängigkeit erstellen, die den Zweck der Einrichtung untergräbt. Wenn das lokale Active Directory nicht mehr verfügbar ist, sind unter Umständen auch alle Arbeitslasten in Google Cloud, die auf einer domain- oder Gesamtstruktur-übergreifenden Authentifizierung basieren, nicht verfügbar.
Wenn Sie für Geschäftskontinuität sorgen möchten, können Sie in allen Umgebungen, die nicht miteinander verbunden sind, separate Active Directory-Gesamtstrukturen einsetzen. Sie haben auch die Möglichkeit, eine vorhandene Active Directory-Domain auf Google Cloud zu erweitern. Durch die Bereitstellung zusätzlicher Domaincontroller in Google Cloud und die Replikation von Verzeichnisinhalten zwischen Umgebungen stellen Sie sicher, dass die Umgebungen isoliert arbeiten.
Integrationsmuster
Nachdem Sie Ihre Anforderungen geprüft haben, können Sie mithilfe des folgenden Entscheidungsbaums eine geeignete Gesamtstruktur und Domainarchitektur bestimmen.
Die folgenden Abschnitte beschreiben die einzelnen Muster.
Synchronisierte Gesamtstrukturen
Im Muster synchronisierte Gesamtstrukturen stellen Sie eine separate Active Directory-Gesamtstruktur in Google Cloud bereit. Mit dieser Gesamtstruktur verwalten Sie alle in Google Cloud bereitgestellten Ressourcen sowie die Nutzerkonten, die zur Verwaltung dieser Ressourcen erforderlich sind.
Anstatt eine Vertrauensstellung zwischen der neuen Gesamtstruktur und einer vorhandenen lokalen Gesamtstruktur zu erstellen, synchronisieren Sie die Konten. Wenn Sie ein Personalverwaltungssystem als Hauptsystem zur Verwaltung von Nutzerkonten verwenden, können Sie es so konfigurieren, dass Nutzerkonten in der von Google Cloud gehosteten Active Directory-Gesamtstruktur bereitgestellt werden. Alternativ können Sie Tools wie Microsoft Identity Manager verwenden, um Nutzerkonten zwischen Umgebungen zu synchronisieren.
Denken Sie über die Verwendung des Musters der synchronisierten Gesamtstrukturen nach, wenn eine oder mehrere der folgenden Bedingungen zutreffen:
- Ihre beabsichtigte Verwendung von Google Cloud entspricht einem der redundanten Bereitstellungsmuster und Sie wollen Laufzeitabhängigkeiten zwischen Ihrer lokalen Umgebung und Google Cloud vermeiden.
- Sie möchten eine Vertrauensgrenze zwischen Ihrer lokalen Active Directory-Umgebung und der auf Google Cloud gehosteten Active Directory-Umgebung aufrechterhalten – entweder als Maßnahme der gestaffelten Sicherheitsebenen oder weil Sie einer Umgebung mehr vertrauen als der anderen.
- Sie erwarten, dass zwischen Active Directory-verwalteten lokalen und Google Cloud-Ressourcen nur leichte oder gar keine Interaktionen stattfinden.
- Die Anzahl der Nutzerkonten, die Sie in der von Google Cloud gehosteten Active Directory-Umgebung benötigen, ist gering.
Vorteile:
- Mit dem Muster der synchronisierten Gesamtstrukturen können Sie eine starke Isolation zwischen den beiden Active Directory-Umgebungen aufrechterhalten. Ein Angreifer, der eine Umgebung manipuliert, kann möglicherweise aus einem Angriff auf die zweite Umgebung wenig Nutzen ziehen.
- Für den Betrieb von Active Directory müssen Sie keine Hybridverbindung zwischen Ihren lokalen und Google Cloud-Netzwerken einrichten.
- Das von Google Cloud gehostete Active Directory ist nicht von einem Ausfall Ihres lokalen Active Directory betroffen. Das Muster eignet sich gut bei Anwendungsfällen für die Geschäftskontinuität oder anderen Szenarien, die eine hohe Verfügbarkeit erfordern.
- Sie können Teams, die die von Google Cloud gehostete Active Directory-Gesamtstruktur verwalten, eine hohe administrative Autonomie gewähren.
- Dieses Muster wird vom Verwalteten Dienst für Microsoft Active Directory unterstützt.
Best Practices:
- Synchronisieren Sie nicht die Passwörter der Nutzerkonten zwischen den beiden Active Directory-Gesamtstrukturen. Dies würde die Isolation zwischen den Umgebungen untergraben.
- Verlassen Sie sich nicht auf die Passthrough-Authentifizierung, da die Passwörter der Nutzerkonten dafür synchronisiert werden müssen.
- Sorgen Sie dafür, dass die Konten eines Mitarbeiters in beiden Active Directory-Umgebungen deaktiviert oder entfernt werden, wenn dieser Mitarbeiter das Unternehmen verlässt.
Ressourcen-Gesamtstruktur
Im Muster Ressourcen-Gesamtstruktur stellen Sie eine separate Active Directory-Gesamtstruktur in Google Cloud bereit. Sie verwenden diese Gesamtstruktur, um alle Ressourcen zu verwalten, die in Google Cloud bereitgestellt werden, sowie einen minimalen Satz von Nutzerkonten, die für die Verwaltung der Gesamtstruktur erforderlich sind. Durch die Einrichtung einer Vertrauensstellung zu Ihrer bestehenden, lokalen Active Directory-Gesamtstruktur ermöglichen Sie es Nutzern Ihrer bestehenden Gesamtstruktur, sich zu authentifizieren und auf Ressourcen zuzugreifen, die von der Google Cloud-gehosteten Active Directory-Gesamtstruktur verwaltet werden.
Bei Bedarf können Sie dieses Muster in eine Hub-and-Spoke-Topologie umwandeln, wobei Ihre vorhandene Active Directory-Gesamtstruktur im Mittelpunkt steht und mit vielen Ressourcen-Gesamtstrukturen verbunden ist.
Denken Sie über die Verwendung des Musters der Ressourcen-Gesamtstruktur nach, wenn eine oder mehrere der folgenden Bedingungen zutreffen:
- Ihre geplante Verwendung von Google Cloud entspricht einem der verteilten Bereitstellungsmuster. Eine Abhängigkeit zwischen Ihrer lokalen Umgebung und Google Cloud ist akzeptabel.
- Sie möchten eine Vertrauensgrenze zwischen Ihrer lokalen Active Directory-Umgebung und der auf Google Cloud gehosteten Active Directory-Umgebung aufrechterhalten – entweder als Maßnahme der gestaffelten Sicherheitsebenen oder weil Sie einer Umgebung mehr vertrauen als der anderen.
- Sie erwarten einen mäßigen Grad an Interaktion zwischen Active Directory-verwalteten Ressourcen lokal und in Google Cloud.
- Sie haben eine große Anzahl von Nutzern, die auf in Google Cloud bereitgestellte Ressourcen zugreifen müssen, z. B. auf Webanwendungen, die IWA zur Authentifizierung verwenden.
Vorteile:
- Mit dem Muster der Ressourcen-Gesamtstruktur können Sie eine Vertrauensgrenze zwischen den beiden Active Directory-Umgebungen aufrechterhalten. Abhängig von der Konfiguration der Vertrauensstellung erhält ein Angreifer, der eine Umgebung manipuliert, möglicherweise nur wenig oder gar keinen Zugriff auf die andere Umgebung.
- Dieses Muster wird von Managed Microsoft AD vollständig unterstützt.
- Sie können Teams, die die von Google Cloud gehostete Active Directory-Gesamtstruktur verwalten, eine hohe administrative Autonomie gewähren.
Best Practices:
- Verbinden Sie die beiden Active Directory-Gesamtstrukturen über eine einseitige Vertrauensstellung, sodass das von Google Cloud gehostete Active Directory Ihrem vorhandenen Active Directory vertraut, aber nicht umgekehrt.
- Verwenden Sie die selektive Authentifizierung, um die Ressourcen im von Google Cloud gehosteten Active Directory einzuschränken, auf die Nutzer aus dem lokalen Active Directory zugreifen dürfen.
- Verwenden Sie redundante Dedicated Interconnect-, Partner Interconnect- oder Cloud VPN-Verbindungen, um für eine hochverfügbare Netzwerkverbindung zwischen Ihrem lokalen Netzwerk und Google Cloud zu sorgen.
Erweiterte Domain
Beim Muster Erweiterte Domain erweitern Sie eine oder mehrere Ihrer vorhandenen Active Directory-Domains auf Google Cloud. Für jede Domain stellen Sie einen oder mehrere Domaincontroller in Google Cloud bereit. Dadurch werden alle Domaindaten sowie der globale Katalog repliziert und in Google Cloud verfügbar gemacht. Durch die Verwendung separater Active Directory-Standorte für Ihre lokalen und Google Cloud-Subnetze sorgen Sie dafür, dass Clients mit den ihnen am nächsten gelegenen Domaincontrollern kommunizieren.
Denken Sie über die Verwendung des Musters der erweiterten Domain nach, wenn eine oder mehrere der folgenden Bedingungen zutreffen:
- Ihre geplante Verwendung von Google Cloud entspricht einem der redundanten Bereitstellungsmuster und Sie wollen Laufzeitabhängigkeiten zwischen Ihrer lokalen Umgebung und Google Cloud vermeiden.
- Sie erwarten eine starke Interaktion zwischen von Active Directory verwalteten Ressourcen lokal und in Google Cloud.
- Sie möchten die Authentifizierung für Anwendungen beschleunigen, deren Authentifizierung auf LDAP basiert.
Vorteile:
- Das von Google Cloud gehostete Active Directory ist nicht von einem Ausfall Ihres lokalen Active Directory betroffen. Das Muster eignet sich gut bei Anwendungsfällen für die Geschäftskontinuität oder anderen Szenarien, die eine hohe Verfügbarkeit erfordern.
- Sie können die Kommunikation zwischen Ihrem lokalen Netzwerk und Google Cloud einschränken. Dadurch sparen Sie Bandbreite und verbessern die Latenz.
- Der gesamte Inhalt des globalen Katalogs wird in Active Directory repliziert und kann über von Google Cloud gehostete Ressourcen effizient aufgerufen werden.
Best Practices:
- Wenn Sie alle Domains replizieren, ist die Kommunikation zwischen Ihrem lokalen Netzwerk und dem Google Cloud-Netzwerk auf die Active Directory-Replikation zwischen Domaincontrollern beschränkt. Wenn Sie nur einen Teil der Domains Ihrer Gesamtstruktur replizieren, müssen in Google Cloud ausgeführte Server, die einer Domain angehören, möglicherweise noch mit Domaincontrollern von nicht replizierten Domains kommunizieren. Achten Sie darauf, dass die Firewallregeln für die Kommunikation zwischen lokal und Google Cloud alle relevanten Fälle berücksichtigen.
- Achten Sie darauf, dass die standortübergreifende Replikation nur in bestimmten Intervallen erfolgt. Aktualisierungen, die auf einem lokalen Domaincontroller durchgeführt werden, treten daher erst nach einer Verzögerung in Google Cloud in Erscheinung (und umgekehrt).
- Erwägen Sie die Verwendung von schreibgeschützten Domaincontrollern (Read-only Domain Controllers, RODCs), um eine schreibgeschützte Kopie der Domaindaten in Google Cloud zu verwalten. Achten Sie jedoch darauf, dass das Speichern von Nutzerpasswörtern im Cache einen Kompromiss darstellt. Wenn Sie zulassen, dass RODCs Passwörter im Cache speichern und den Cache für Passwörter vorab befüllen, können in Google Cloud bereitgestellte Ressourcen von einem Ausfall lokaler Domaincontroller unberührt bleiben. Die Sicherheitsvorteile der Verwendung eines RODC gegenüber einem regulären Domaincontroller sind jedoch begrenzt. Wenn Sie das Speichern von Passwörtern im Cache deaktivieren, stellt ein manipulierter RODC möglicherweise nur ein geringes Risiko für den Rest Ihres Active Directory dar. Sie verlieren jedoch den Vorteil, dass Google Cloud von einem Ausfall lokaler Domaincontroller unberührt bleibt.
Erweiterte Gesamtstruktur
Im Muster der erweiterten Gesamtstruktur stellen Sie eine neue Active Directory-Domain in Google Cloud bereit, integrieren diese jedoch in Ihre vorhandene Gesamtstruktur. Sie verwenden die neue Domain für die Verwaltung aller Ressourcen, die in Google Cloud bereitgestellt werden, sowie einer minimalen Anzahl administrativer Nutzerkonten für die Verwaltung der Domain.
Wenn Sie die impliziten Vertrauensstellungen auf andere Domains der Gesamtstruktur ausweiten, ermöglichen Sie Ihren vorhandenen Nutzern aus anderen Domains die Authentifizierung und den Zugriff auf Ressourcen, die durch die in Google Cloud gehostete Active Directory-Domain verwaltet werden.
Denken Sie über die Verwendung des Musters der erweiterten Gesamtstruktur nach, wenn eine oder mehrere der folgenden Bedingungen zutreffen:
- Ihre geplante Verwendung von Google Cloud entspricht einem der verteilten Bereitstellungsmuster. Eine Abhängigkeit zwischen Ihrer lokalen Umgebung und Google Cloud ist akzeptabel.
- Die Ressourcen, die Sie in Google Cloud bereitstellen möchten, erfordern eine andere Domainkonfiguration oder -struktur als Ihre vorhandenen Domains, oder Sie möchten den Teams, die die in Google Cloud gehostete Domain verwalten, eine hohe administrative Autonomie gewähren.
- Sie erwarten eine mittlere bis starke Interaktion zwischen von Active Directory verwalteten Ressourcen lokal und in Google Cloud.
- Sie haben viele Nutzer, die auf in Google Cloud bereitgestellte Ressourcen zugreifen müssen, z. B. auf Webanwendungen, die IWA zur Authentifizierung verwenden.
Vorteile:
- Der gesamte Inhalt des globalen Katalogs wird in Active Directory repliziert und kann über von Google Cloud gehostete Ressourcen effizient aufgerufen werden.
- Der Replikationstraffic zwischen Ihrem lokalen Netzwerk und Google Cloud ist auf die globale Katalogreplikation beschränkt. Dies kann dazu beitragen, den Bandbreitenverbrauch insgesamt zu begrenzen.
- Sie können Teams, die die von Google Cloud gehostete Active Directory-Domain verwalten, eine hohe administrative Autonomie gewähren.
Best Practices:
- Verwenden Sie redundante Dedicated Interconnect-, Partner Interconnect- oder Cloud VPN-Verbindungen, um eine hochverfügbare Netzwerkverbindung zwischen Ihrem lokalen Netzwerk und Google Cloud zu gewährleisten.
Ressourcen-Gesamtstruktur mit erweiterter Domain
Das Muster der Ressourcen-Gesamtstruktur mit erweiterter Domain ist eine Erweiterung des Musters der Ressourcen-Gesamtstruktur. Mit dem Muster der Ressourcen-Gesamtstruktur können Sie eine Vertrauensgrenze zwischen Umgebungen aufrechterhalten und administrative Autonomie bieten. Eine Einschränkung der Ressourcen-Gesamtstruktur besteht darin, dass ihre Gesamtverfügbarkeit von der Verfügbarkeit lokaler Domaincontroller und der zuverlässigen Netzwerkverbindung zu Ihrem lokalen Rechenzentrum abhängt.
Sie können diese Einschränkungen überwinden, wenn Sie das Muster der Ressourcen-Gesamtstruktur mit dem Muster der erweiterten Domain kombinieren. Durch die Replikation der Domain befinden sich Ihre Nutzerkonten in Google Cloud und Sie können sicherstellen, dass sich Nutzer bei von Google Cloud gehosteten Ressourcen auch dann authentifizieren können, wenn lokale Domaincontroller nicht verfügbar sind oder die Netzwerkverbindung unterbrochen wird.
Denken Sie über die Verwendung des Musters der Ressourcen-Gesamtstruktur mit erweiterter Domain nach, wenn eine oder mehrere der folgenden Bedingungen zutreffen:
- Sie möchten eine Vertrauensgrenze zwischen Ihrer primären Active Directory-Gesamtstruktur und der Ressourcen-Gesamtstruktur aufrechterhalten.
- Sie möchten verhindern, dass ein Ausfall lokaler Domaincontroller oder der Verlust der Netzwerkverbindung zu Ihrer lokalen Umgebung sich auf Ihre in Google Cloud gehosteten Arbeitslasten auswirken.
- Sie erwarten eine mäßige Interaktion zwischen von Active Directory verwalteten Ressourcen lokal und in Google Cloud.
- Sie haben viele Nutzer aus einer einzelnen Active Directory-Domain, die auf in Google Cloud bereitgestellte Ressourcen zugreifen müssen, z. B. auf Webanwendungen, die IWA für die Authentifizierung verwenden.
Vorteile:
- Von Google Cloud gehostete Ressourcen sind von einem Ausfall Ihres lokalen Active Directory nicht betroffen. Das Muster eignet sich gut bei Anwendungsfällen für die Geschäftskontinuität oder anderen Szenarien, die eine hohe Verfügbarkeit erfordern.
- Mit dem Muster können Sie eine Vertrauensgrenze zwischen den beiden Active Directory-Gesamtstrukturen aufrechterhalten. Abhängig von der Konfiguration der Vertrauensstellung erhält ein Angreifer, der eine Umgebung manipuliert, möglicherweise nur wenig oder gar keinen Zugriff auf die andere Umgebung.
- Die Kommunikation zwischen Ihrem lokalen Netzwerk und dem Google Cloud-Netzwerk ist auf die Active Directory-Replikation zwischen Domaincontrollern beschränkt. Sie können Firewallregeln implementieren, um jegliche andere Kommunikation zu unterbinden und so die Isolation zwischen den Umgebungen zu verstärken.
- Sie können Teams, die die von Google Cloud gehostete Active Directory-Gesamtstruktur verwalten, eine hohe administrative Autonomie gewähren.
- Sie können Managed Microsoft AD für die Ressourcen-Gesamtstruktur verwenden.
Best Practices:
- Stellen Sie Domaincontroller für die erweiterte Domain in einem separaten Google Cloud-Projekt und einer separaten VPC bereit, um diese Komponenten von den Komponenten der Ressourcen-Gesamtstruktur zu trennen.
- Verwenden Sie VPC-Peering, um die VPC entweder mit der freigegebenen VPC oder der VPC, die von der Ressourcen-Gesamtstruktur genutzt wird, zu verbinden. Konfigurieren Sie außerdem Firewalls, um die Kommunikation mit der Kerberos-Nutzerauthentifizierung und der Einrichtung der Gesamtstruktur-Vertrauensstellung zu beschränken.
- Verbinden Sie die beiden Active Directory-Gesamtstrukturen über eine einseitige Vertrauensstellung, sodass das ein von Google Cloud gehostetes Active Directory Ihrer vorhandenen Active Directory-Gesamtstruktur vertraut, aber nicht umgekehrt.
- Setzen Sie die selektive Authentifizierung ein, um die Ressourcen in der Ressourcen-Gesamtstruktur einzuschränken, auf die Nutzer aus anderen Gesamtstrukturen zugreifen dürfen.
- Achten Sie darauf, dass die standortübergreifende Replikation nur in bestimmten Intervallen erfolgt. Aktualisierungen, die auf einem lokalen Domaincontroller durchgeführt werden, treten daher erst nach einer Verzögerung in Google Cloud in Erscheinung (und umgekehrt).
- Denken Sie über die Verwendung von RODCs für die erweiterte Domain nach, lassen Sie jedoch das Speichern von Passwörtern im Cache zu, um die Verfügbarkeitsvorteile im Vergleich zum Muster der Ressourcen-Gesamtstruktur zu bewahren.
Weitere Informationen
- Weitere Informationen zu Managed Microsoft AD
- Best Practices für die Bereitstellung einer Active Directory-Ressourcen-Gesamtstruktur in Google Cloud
- Fehlertolerante Active Directory-Umgebung in Google Cloud bereitstellen
- Best Practices für das VPC-Design
- Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.