Muster für die Verwendung von Active Directory in einer Hybridumgebung

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

In diesem Dokument werden die Anforderungen beschrieben, die beim Bereitstellen von Active Directory in Google Cloud zu berücksichtigen sind, und Sie erfahren, wie Sie die richtige Architektur auswählen.

Wenn Sie Active Directory mit Cloud Identity oder Google Workspace verbinden (siehe Muster zum Authentifizieren von Mitarbeiternutzern in einer Hybridumgebung), können Sie Nutzern aus Ihren vorhandenen Active Directory-Domains ermöglichen, sich auf Google Cloudzu authentifizieren und darauf zuzugreifen. Sie können Active Directory auch in Google Cloud bereitstellen, wenn Sie Active Directory verwenden möchten, um Windows-Server auf Google Cloud zu verwalten, oder wenn Sie Protokolle verwenden, die von Google Cloudnicht unterstützt werden.

Bevor Sie Active Directory in Google Cloudbereitstellen, müssen Sie zuerst entscheiden, welche Domain und Architektur der Gesamtstruktur Sie verwenden und wie Sie sie in Ihre vorhandene Active Directory-Gesamtstruktur einbinden möchten.

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 Ressourcen 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 auf 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 auf Google Cloud

Wenn Sie eine Bereitstellung in Google Cloud planen, für die Active Directory erforderlich ist, müssen Sie zwischen zwei Optionen wählen, um die Bereitstellung an Ihre vorhandenen Sicherheitszonen anzupassen:

• Vorhandene Sicherheitszone auf Google Cloudausweiten Sie können eine oder mehrere Ihrer vorhandenen Sicherheitszonen auf Google Cloud erweitern. Stellen Sie dazu eine freigegebene VPC auf Google Cloud bereit und verbinden Sie sie über Cloud VPN oder Cloud Interconnect mit der vorhandenen Zone.

  Ressourcen, die lokal und unter Google Cloud bereitgestellt werden und sich eine gemeinsame Zone teilen, können auch eine gemeinsame Active Directory-Gesamtstruktur nutzen. Daher ist es nicht erforderlich, eine separate Gesamtstruktur für Google Cloudbereitzustellen.

  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 aufGoogle Clouderweitern, sind alle Bereitstellungen auf 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. Zum Trennen dieser Arbeitslasten in Google Cloudkönnen Sie zwei freigegebene VPCs erstellen und sie als neue Sicherheitszonen betrachten. Anschließend stellen Sie zwei zusätzliche Active Directory-Gesamtstrukturen in Google Cloudbereit, eine pro Sicherheitszone. Gegebenenfalls können Sie Vertrauensstellungen zwischen Gesamtstrukturen einrichten, um die Authentifizierung über Sicherheitszonen hinweg zu ermöglichen.

  

Interaktion zwischen lokalen Ressourcen und Google Cloud Ressourcen

Der zweite Faktor, der bei der Erweiterung Ihres Active Directory aufGoogle Cloud berücksichtigt werden muss, ist die Interaktion von Nutzern und Ressourcen zwischen der lokalen Umgebung und Google Cloud. Je nach Anwendungsfall kann diese Interaktion leicht bis schwer sein.

Leichte Interaktion

Wenn der einzige Zweck der Verwendung von Active Directory auf Google Cloud darin besteht, eine Gruppe von Windows-Servern zu verwalten und Administratoren die Anmeldung bei diesen Servern zu ermöglichen, ist die Interaktion zwischen den Umgebungen gering:

• Die Gruppe der Mitarbeiter, die auf Google Cloud mit Ressourcen interagieren, ist auf Verwaltungsmitarbeiter beschränkt.
• In Google Cloud bereitgestellte Anwendungen 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 undGoogle Cloud -Umgebung auf eine der folgenden zwei Arten einbinden:

• Zwei disjunkte Active Directory-Gesamtstrukturen: Sie können die beiden Umgebungen isolieren, wenn Sie zwei separate Active Directory-Gesamtstrukturen verwenden, die keine Vertrauensstellung teilen. In der Gesamtstruktur Google Cloudverwalten Sie einen separaten Satz von Nutzerkonten, um Administratoren die Authentifizierung zu ermöglichen.

  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 Human Resources Information System (HRIS) bereitgestellt werden, können Sie möglicherweise einen ähnlichen Mechanismus verwenden, um Nutzerkonten in derGoogle 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 das Maß der Isolation zwischen Umgebungen als schwächer angesehen werden kann, können Sie mit separaten Gesamtstrukturen eine Vertrauensgrenze zwischen Ihrer lokalen Umgebung und der Google Cloud -Umgebung aufrechterhalten.

Moderate Interaktion

Ihr Anwendungsfall ist möglicherweise komplexer. Beispiel:

• Administratoren, die sich auf Windows-Servern anmelden, die aufGoogle Cloud bereitgestellt sind, 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 auf Google Cloudbereitgestellt 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 Virtual Desktop Infrastructure (VDI), erfordern möglicherweise eine starke Interaktion zwischen lokalen Ressourcen und Ressourcen, die auf Google Cloudbereitgestellt 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 aufGoogle Cloud berücksichtigt werden muss, ist die administrative Autonomie.

Wenn Sie Arbeitslasten auf lokale Umgebungen und Google Cloudverteilen möchten, können sich die Arbeitslasten, die Sie auf Google Cloud ausführen, stark von den lokalen Arbeitslasten unterscheiden. 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, der bei der Erweiterung Ihres Active Directory aufGoogle Cloud berücksichtigt werden muss, 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 für Google Cloud bereitstellen, wahrscheinlich von anderen Infrastrukturen oder Anwendungen ab, die lokal ausgeführt werden. Daher ist eine hochverfügbare Hybridkonnektivität eine wichtige Anforderung.

Wenn Sie eine separate Active Directory-Gesamtstruktur oder -Domain für Google Cloudbereitstellen 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 zur Sicherstellung der Geschäftskontinuität verwenden, spiegeln Ihre Arbeitslasten 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 für Google Cloudbereitstellen und eine Vertrauensstellung verwenden, um sie mit Ihrem lokalen Active Directory zu verbinden, erstellen Sie möglicherweise eine Abhängigkeit, die den Zweck der Einrichtung untergraben. Wenn das lokale Active Directory nicht mehr verfügbar ist, sind möglicherweise auch alle aufGoogle Cloud bereitgestellten Arbeitslasten, die eine domainübergreifende oder Gesamtstruktur-übergreifende Authentifizierung erfordern, nicht mehr 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. Alternativ können Sie eine vorhandene Active Directory-Domain aufGoogle Clouderweitern. Wenn Sie zusätzliche Domaincontroller fürGoogle Cloud bereitstellen und Verzeichnisinhalte zwischen Umgebungen replizieren, können Sie dafür sorgen, 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 der synchronisierten Gesamtstrukturen stellen Sie eine separate Active Directory-Gesamtstruktur für Google Cloudbereit. In dieser Gesamtstruktur verwalten Sie alle auf 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 HRIS als führendes System zur Verwaltung von Nutzerkonten verwenden, können Sie das HRIS so konfigurieren, dass Nutzerkonten in der 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 passt zu einem der Muster für redundante Bereitstellungen und Sie möchten Laufzeitabhängigkeiten zwischen Ihrer lokalen Umgebung und Google Cloudvermeiden.
• Sie möchten eine Vertrauensgrenze zwischen Ihrer lokalen Active Directory-Umgebung und der 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 den lokalen und lokalen Ressourcen, die von Active Directory verwaltet werden, eine geringe bis keine Interaktion zwischen den lokalen und den On- Google Cloud-Ressourcen erfolgt.
• In der Google Cloud-gehosteten Active Directory-Umgebung benötigen Sie nur wenige Nutzerkonten.

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 Hybridkonnektivität zwischen Ihren lokalen und Google Cloud Netzwerken einrichten.
• Das auf Google Cloudgehostete Active Directory ist 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.
• Sie können Teams, die die Google Cloud-gehostete Active Directory-Gesamtstruktur verwalten, ein hohes Maß an administrativer 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 der Ressourcen-Gesamtstruktur stellen Sie eine separate Active Directory-Gesamtstruktur für Google Cloudbereit. Sie verwenden diese Gesamtstruktur, um alle inGoogle Cloud bereitgestellten Ressourcen sowie eine minimale Anzahl von administrativen Nutzerkonten zu verwalten, die für die Verwaltung der Gesamtstruktur erforderlich sind. Durch die Einrichtung einer Vertrauensstellung für die Gesamtstruktur zu Ihrer vorhandenen lokalen Active Directory-Gesamtstruktur ermöglichen Sie Nutzern aus Ihrer vorhandenen Gesamtstruktur, sich zu authentifizieren und auf Ressourcen zuzugreifen, die von derGoogle 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:

• Die beabsichtigte Verwendung von Google Cloud passt zu einem der Muster für verteilte Bereitstellungen und eine Abhängigkeit zwischen Ihrer lokalen Umgebung und Google Cloudist akzeptabel.
• Sie möchten eine Vertrauensgrenze zwischen Ihrer lokalen Active Directory-Umgebung und der Google Cloud-gehosteten Active Directory-Umgebung aufrechterhalten – entweder als Maßnahme der gestaffelten Sicherheitsebenen oder weil Sie eine Umgebung als vertrauenswürdiger betrachten als die andere.
• Sie erwarten eine moderate Interaktion zwischen den lokalen und den On- Google Cloud-Ressourcen, die von Active Directory verwaltet werden.
• Sie haben eine große Anzahl von Nutzern, die auf Ressourcen zugreifen müssen, die auf Google Cloudbereitgestellt sind, 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 Google Cloud-gehostete Active Directory-Gesamtstruktur verwalten, ein hohes Maß an administrativer Autonomie gewähren.

Best Practices:

• Verbinden Sie die beiden Active Directory-Gesamtstrukturen mithilfe einer einseitigen Vertrauensstellung, sodass das von Google Cloudgehostete Active Directory Ihrem vorhandenen Active Directory vertraut, aber nicht umgekehrt.
• Verwenden Sie die selektive Authentifizierung, um die Ressourcen im 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 Cloudzu 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 auf Google Cloudbereit. Dadurch werden alle Domaindaten sowie der globale Katalog repliziert und unterGoogle Cloudverfügbar gemacht. Durch die Verwendung separater Active Directory-Standorte für Ihre lokalen und Google Cloud Subnetze stellen Sie sicher, dass Clients mit den Domaincontrollern kommunizieren, die ihnen am nächsten sind.

Denken Sie über die Verwendung des Musters der erweiterten Domain nach, wenn eine oder mehrere der folgenden Bedingungen zutreffen:

• Die beabsichtigte Verwendung von Google Cloud passt zu einem der redundanten Bereitstellungsmuster und Sie möchten Laufzeitabhängigkeiten zwischen Ihrer lokalen Umgebung und Google Cloudvermeiden.
• Sie erwarten eine starke Interaktion zwischen den lokalen und denGoogle Cloud-Ressourcen, die von Active Directory verwaltet werden.
• Sie möchten die Authentifizierung für Anwendungen beschleunigen, deren Authentifizierung auf LDAP basiert.

Vorteile:

• Das auf Google Cloudgehostete Active Directory ist 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.
• Sie können die Kommunikation zwischen Ihrem lokalen Netzwerk undGoogle Cloudeinschränken. Dadurch sparen Sie Bandbreite und verbessern die Latenz.
• Der gesamte Inhalt des globalen Katalogs wird in Active Directory repliziert und kann über Google Cloud-gehostete Ressourcen effizient aufgerufen werden.

Best Practices:

• Wenn Sie alle Domains replizieren, ist die Kommunikation zwischen Ihrem lokalen Netzwerk und dem Netzwerk Google Cloud auf die Active Directory-Replikation zwischen Domaincontrollern beschränkt. Wenn Sie nur einen Teil der Domains der Gesamtstruktur replizieren, müssen in die Domain eingebundene Server, die aufGoogle Cloud ausgeführt werden, möglicherweise weiterhin mit Domaincontrollern nicht replizierter Domains kommunizieren. Achten Sie darauf, dass die Firewallregeln, die für die Kommunikation zwischen lokalen Systemen gelten, Google Cloud alle relevanten Fälle berücksichtigen.
• Beachten Sie, 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 beiGoogle 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 auf Google Cloudzu verwalten. Beachten Sie jedoch, dass das Speichern von Nutzerpasswörtern im Cache einen Kompromiss darstellt. Wenn Sie zulassen, dass RODCs Passwörter im Cache speichern und den Passwort-Cache vorab füllen, können auf 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 Passwort-Caching deaktivieren, stellt ein manipulierter RODC möglicherweise nur ein begrenztes Risiko für den Rest Ihres Active Directory dar. Sie verlieren jedoch den Vorteil, dassGoogle Cloud von einem Ausfall lokaler Domaincontroller unberührt bleibt.

Erweiterte Gesamtstruktur

Im Muster der erweiterten Gesamtstruktur stellen Sie eine neue Active Directory-Domain aufGoogle Cloudbereit, binden sie aber in Ihre vorhandene Gesamtstruktur ein. Sie verwenden die neue Domain, um alle in Google Cloud bereitgestellten Ressourcen zu verwalten und eine minimale Anzahl administrativer Nutzerkonten für die Verwaltung der Domain zu verwalten.

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 von der Google Cloud-gehosteten 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 beabsichtigte Verwendung von Google Cloud passt zu einem der Muster für verteilte Bereitstellungen und eine Abhängigkeit zwischen Ihrer lokalen Umgebung und Google Cloud ist akzeptabel.
• Die Ressourcen, die Sie bereitstellen möchten, um Google Cloud eine andere Domainkonfiguration oder -struktur als Ihre bestehenden Domains bieten zu müssen, oder Sie möchten Teams, die die von Google Cloudgehostete Domain verwalten, ein hohes Maß an administrativer Autonomie gewähren.
• Sie erwarten eine moderate bis starke Interaktion zwischen den lokalen und den lokalen Google Cloud-Ressourcen, die von Active Directory verwaltet werden.
• Sie haben viele Nutzer, die auf Ressourcen zugreifen müssen, die in Google Cloudbereitgestellt sind, 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 Cloudgehostete Ressourcen effizient aufgerufen werden.
• Der Replikationstraffic zwischen Ihrem lokalen Netzwerk undGoogle Cloud ist auf die Replikation des globalen Katalogs beschränkt. Dies kann dazu beitragen, den Bandbreitenverbrauch insgesamt zu begrenzen.
• Sie können Teams, die die Google Cloud-gehostete Active Directory-Domain verwalten, ein hohes Maß an administrativer Autonomie gewähren.

Best Practices:

• Verwenden Sie redundante Dedicated Interconnect-, Partner Interconnect- oder Cloud VPN-Verbindungen, um für eine hochverfügbare Netzwerkverbindung zwischen Ihrem lokalen Netzwerk und Google Cloudzu sorgen.

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. So können Sie dafür sorgen, dass sich Nutzer auch dann bei von Google Cloudgehosteten Ressourcen 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 sich ein Ausfall lokaler Domaincontroller oder der Verlust der Netzwerkverbindung zu Ihrer lokalen Umgebung auf IhreGoogle Cloud-gehosteten Arbeitslasten auswirkt.
• Sie erwarten eine moderate Interaktion zwischen den lokalen und den lokalen Ressourcen, die von Active Directory verwaltet werden Google Cloud.
• Sie haben viele Nutzer aus einer einzelnen Active Directory-Domain, die auf Ressourcen zugreifen müssen, die in Google Cloudbereitgestellt sind, z. B. auf Webanwendungen, die IWA zur Authentifizierung verwenden.

Vorteile:

• 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 Netzwerk Google Cloudist 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 Google Cloud-gehostete Active Directory-Gesamtstruktur verwalten, ein hohes Maß an administrativer 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 separatenGoogle 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 mithilfe einer einseitigen Vertrauensstellung, sodass das Google Cloud-gehostete 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.
• Beachten Sie, 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 beiGoogle 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 auf Google Cloud
• Fehlertolerante Active Directory-Umgebung in Google Cloudbereitstellen
• Best Practices für das VPC-Design
• Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.