Ressourcenhierarchie für Ihre Google Cloud-Landing-Zone festlegen

Last reviewed 2023-08-31 UTC

Eine Ressourcenhierarchie erleichtert die Organisation Ihrer Ressourcen in Google Cloud. In diesem Dokument wird beschrieben, wie Sie die Ressourcenhierarchie als Teil des Landing-Zone-Designs auswählen. Es richtet sich an Cloud-Systemadministratoren, Architekten und technische Fachkräfte, die an der Entwicklung der Ressourcenhierarchie beteiligt sind. Dieses Dokument ist Teil einer Reihe zu Landing Zones. Er enthält Beispielhierarchien, die zeigen, wie Unternehmen Ressourcen in Google Cloud strukturieren können.

Designfaktoren für Ressourcenhierarchie

Wenn Sie die Ressourcenhierarchie in Google Cloud definieren, müssen Sie berücksichtigen, wie Ihre Organisation derzeit funktioniert und welcher Endzustand mit der Cloud-Transformation angestrebt wird. Die beste Methode zum Verwalten von Ressourcen basiert auf der Arbeitsweise, die Sie für Ihre Organisation in der Cloud beabsichtigen. Da jede Organisation unterschiedlich ist, gibt es nicht nur einen optimalen Ansatz für die Ressourcenhierarchie.

Es wird jedoch empfohlen, die Struktur der Unternehmensorganisation nicht der Ressourcenhierarchie zuzuordnen. Konzentrieren Sie sich stattdessen auf Ihre Geschäftsanforderungen und Abläufe in Google Cloud.

Google Cloud-Ressourcenhierarchie

Die Ressourcenhierarchie in Google Cloud beginnt am Stammknoten, der als Organisation bezeichnet wird. Unternehmen wird empfohlen, nur einen einzigen Stammknoten zu verwalten, mit Ausnahme spezifischer Situationen. Sie definieren niedrigere Hierarchieebenen anhand von Ordnern und Projekten und erstellen Ordner innerhalb von Ordnern, um die Hierarchie zu erstellen. Sie können die Projekte, die Ihre Arbeitslasten hosten, auf jeder beliebigen Hierarchieebene erstellen.

Das folgende Diagramm zeigt einen Stammknoten namens Organisation und Ordner auf den Ebenen 1, 2 und 3. Projekte und Unterordner werden in den Ordnern auf Ebene 2 erstellt.

Faktoren der Ressourcenhierarchie

Berücksichtigen Sie beim Festlegen der Ressourcenhierarchie die folgenden Faktoren:

• Wer ist für Cloud-Ressourcen verantwortlich? Sind es Ihre Abteilungen, Tochtergesellschaften, technischen Teams oder Rechtssubjekte?
• Welche Complianceanforderungen bestehen?
• Gibt es bevorstehende Geschäftsereignisse wie Fusionen, Übernahmen und Abwanderungen?

Ressourceninteraktionen in der Hierarchie verstehen

Organisationsrichtlinien werden von untergeordneten Objekten in der Ressourcenhierarchie übernommen, können jedoch durch Richtlinien ersetzt werden, die auf einer niedrigeren Ebene definiert sind. Weitere Informationen finden Sie unter Informationen zu Evaluierungen der Hierarchie. Mit Einschränkungen für Organisationsrichtlinien können Sie Richtlinien für die gesamte Organisation oder wichtige Teile davon festlegen und gleichzeitig Ausnahmen zulassen.

Zulassungsrichtlinien, ehemals IAM-Richtlinien, werden von Nachfolgerelementen übernommen und Zulassungsrichtlinien auf niedrigerer Ebene sind additiv. Zulassungsrichtlinien können jedoch durch Ablehnungsrichtlinien ersetzt werden, mit denen Sie die Berechtigungen auf Projekt-, Ordner- und Organisationsebene einschränken können. Ablehnungsrichtlinien werden vor Zulassungsrichtlinien angewendet.

Beachten Sie außerdem Folgendes:

• Cloud Logging enthält aggregierte Senken, mit denen Sie Logs auf Ordner- oder Organisationsebene zusammenfassen können. Weitere Informationen finden Sie unter Sicherheit für Ihre Google Cloud-Landing-Zone festlegen.
• Die Abrechnung ist nicht direkt mit der Ressourcenhierarchie verknüpft, sondern auf Projektebene zugewiesen. Wenn Sie jedoch zusammengefasste Informationen auf Ordnerebene abrufen möchten, können Sie die Kosten nach Projekthierarchie analysieren und Abrechnungsberichte verwenden.
• Mit hierarchischen Firewallrichtlinien können Sie konsistente Firewallrichtlinien für die gesamte Organisation oder bestimmte Ordner implementieren. Die Übernahme ist implizit, was bedeutet, dass Sie den Traffic auf jeder beliebigen Ebene zulassen oder ablehnen oder die Entscheidung an eine niedrigere Ebene delegieren können.

Entscheidungspunkte für das Design der Ressourcenhierarchie

Das folgende Flussdiagramm zeigt die Dinge, die Sie berücksichtigen müssen, um eine optimale Ressourcenhierarchie für Ihre Organisation auszuwählen.

Das obige Diagramm umreißt die folgenden Entscheidungspunkte:

1. Haben verschiedene Tochtergesellschaften, regionale Gruppen oder Geschäftseinheiten sehr unterschiedliche Richtlinienanforderungen?
   1. Wenn ja, folgen Sie dem Design anhand von Regionen oder Tochtergesellschaften.
   2. Falls nicht, fahren Sie mit dem nächsten Entscheidungspunkt fort.

2. Benötigen Ihre Arbeitslast- oder Produktteams eine starke Autonomie über ihre Richtlinien? Sie haben beispielsweise kein zentrales Sicherheitsteam, das Richtlinien für alle Arbeitslast- oder Produktteams festlegt.

   1. Falls ja, lesen Sie die Informationen unter Design basierend auf dem Framework für die Rechenschaftspflicht.

   2. Falls nicht, lesen Sie die Informationen unter Design basierend auf der Anwendungsumgebung.

Ihr spezifischer Anwendungsfall führt möglicherweise zu einem anderen Design der Ressourcenhierarchie, als im Entscheidungsdiagramm vorgeschlagen wird. Die meisten Organisationen entscheiden sich für einen hybriden Ansatz und wählen unterschiedliche Designs auf verschiedenen Ebenen der Ressourcenhierarchie aus. Dabei beginnen sie mit dem Design mit den größten Auswirkungen auf Richtlinien und Zugriff.

Option 1: Auf Anwendungsumgebungen basierende Hierarchie

In vielen Organisationen definieren Sie unterschiedliche Richtlinien und Zugriffssteuerungen für verschiedene Anwendungsumgebungen wie Entwicklung, Produktion und Tests. Separate Richtlinien, die in jeder Umgebung standardisiert sind, vereinfachen die Verwaltung und Konfiguration. Angenommen, Sie haben Sicherheitsrichtlinien, die in Produktionsumgebungen strenger als in Testumgebungen sind.

Verwenden Sie eine Hierarchie basierend auf Anwendungsumgebungen, wenn Folgendes zutrifft:

• Sie haben separate Anwendungsumgebungen mit unterschiedlichen Richtlinien- und Verwaltungsanforderungen.
• Sie haben zentralisierte Sicherheits- oder Prüfanforderungen, die ein zentrales Sicherheitsteam in der Lage sein muss, konsistent auf allen Produktionsarbeitslasten und -daten zu erzwingen.
• Sie benötigen verschiedene IAM-Rollen (Identity and Access Management), um in verschiedenen Umgebungen auf Ihre Google Cloud-Ressourcen zugreifen zu können.

Vermeiden Sie diese Hierarchie, wenn Folgendes zutrifft:

• Sie führen nicht mehrere Anwendungsumgebungen aus.
• Es bestehen keine Abweichungen bei Anwendungsabhängigkeiten und Geschäftsprozessen in Ihren Umgebungen.
• Es bestehen große Richtlinienunterschiede für verschiedene Regionen, Teams oder Anwendungen.

Das folgende Diagramm zeigt eine Hierarchie für example.com, ein fiktives Finanztechnologieunternehmen.

Wie im vorherigen Diagramm dargestellt, hat example.com drei Anwendungsumgebungen mit unterschiedlichen Richtlinien, Zugriffssteuerungen, gesetzlichen Anforderungen und Prozessen. Es gibt folgende Umgebungen:

• Entwicklungs- und QA-Umgebung: Diese Umgebung wird von Entwicklern verwaltet, die sowohl interne Mitarbeiter als auch Berater sind. Sie übergeben kontinuierlich Code und sind für die Qualitätssicherung verantwortlich. Diese Umgebung ist für die Nutzer Ihres Unternehmens nie verfügbar. Die Umgebung hat weniger strenge Integrations- und Authentifizierungsanforderungen als die Produktionsumgebung und Entwicklern werden genehmigte Rollen mit geeigneten Berechtigungen zugewiesen. Die Entwicklungs- und QA-Umgebung ist nur für Standardanwendungsangebote von example.com vorgesehen.

• Testumgebung: Diese Umgebung wird für Regressions- und Anwendungstests verwendet und unterstützt die Business-to-Business-Angebote (B2B) von example.com-Clients, die example.com-APIs verwenden. Zu diesem Zweck erstellt example.com zwei Projekttypen:

  • Interne Testprojekte zur Vervollständigung der internen Regression, Leistung und Konfiguration für B2B-Angebote.
  • Client-UAT-Projekte mit Unterstützung für mehrere Mandanten, damit B2B-Kunden ihre Konfigurationen validieren und die example.com-Anforderungen an Nutzerfreundlichkeit, Branding, Workflows, Berichte usw. anpassen können.

• Produktionsumgebung: In dieser Umgebung werden alle Produktangebote gehostet, die validiert, akzeptiert und gestartet werden. Diese Umgebung unterliegt den PCI DSS-Bestimmungen (Payment Card Industry Data Security Standard), verwendet Hardwaresicherheitsmodule (HSMs) und ist für Elemente wie Authentifizierung und Zahlung in Drittanbieterprozessoren integriert. Die Audit- und Compliance-Teams sind wichtige Beteiligten dieser Umgebung. Der Zugriff auf diese Umgebung wird streng kontrolliert und ist hauptsächlich auf automatisierte Bereitstellungsprozesse beschränkt.

Weitere Informationen zum Entwerfen einer Hierarchie, die auf Anwendungsumgebungen basiert, finden Sie im Blueprint für Unternehmensgrundlagen unter Organisationsstruktur.

Option 2: Auf Regionen oder Tochtergesellschaften basierende Hierarchie

Einige Organisationen operieren in unterschiedlichen Regionen und haben Tochtergesellschaften, die an verschiedenen geografischen Standorten tätig sind oder aus Fusionen und Übernahmen resultieren. Diese Organisationen benötigen eine Ressourcenhierarchie, die die Skalierbarkeits- und Verwaltungsoptionen in Google Cloud verwendet und die Unabhängigkeit für verschiedene Prozesse und Richtlinien beibehält, die zwischen den einzelnen Regionen oder Tochtergesellschaften bestehen. Diese Hierarchie verwendet Tochtergesellschaften oder Regionen als höchste Ordnerebene in der Ressourcenhierarchie. Bereitstellungsverfahren sind normalerweise auf die Regionen ausgerichtet.

Verwenden Sie diese Hierarchie, wenn Folgendes zutrifft:

• Regionen oder Tochtergesellschaften arbeiten unabhängig voneinander.
• Regionen oder Tochtergesellschaften haben unterschiedliche operative Backbones, digitale Plattformangebote und Prozesse.
• Ihr Unternehmen hat für die einzelnen Regionen oder Tochtergesellschaften unterschiedliche Standards bezüglich Complianceanforderungen und gesetzlichen Auflagen.

Im folgenden Diagramm sehen Sie eine Beispielhierarchie für eine globale Organisation mit zwei Tochtergesellschaften und einer Holdinggruppe mit einer regionalen Struktur.

Das obige Diagramm hat die folgende Hierarchiestruktur:

• Die folgenden Ordner befinden sich auf der ersten Ebene:
  • Die Ordner Subsidiary 1 und Subsidiary 2 stellen die beiden Tochtergesellschaften des Unternehmens dar, die unterschiedliche Zugriffsberechtigungen und Richtlinien als der Rest der Organisation haben. Jede Tochtergesellschaft verwendet IAM, um den Zugriff auf ihre Projekte und Google Cloud-Ressourcen einzuschränken.
  • Der Ordner Holding group stellt die Gruppen dar, die gemeinsame allgemeine Richtlinien über Regionen hinweg haben.
  • Der Ordner Bootstrap stellt die allgemeinen Ressourcen dar, die zum Bereitstellen Ihrer Google Cloud-Infrastruktur erforderlich sind. Weitere Informationen dazu finden Sie im Blueprint für Unternehmensgrundlagen.
• Auf der zweiten Ebene befinden sich im Ordner Holdinggruppe die folgenden Ordner:
  • Die Ordner APAC, EMEA und Americas stellen die verschiedenen Regionen innerhalb der Gruppe dar, die unterschiedliche Governance, Zugriffsberechtigungen und Richtlinien haben.
  • Der Ordner Shared infrastructure stellt Ressourcen dar, die in allen Regionen global verwendet werden.
• In jedem Ordner befinden sich verschiedene Projekte mit den Ressourcen, für die diese Tochtergesellschaften oder Regionen zuständig sind.

Sie können weitere Ordner hinzufügen, um verschiedene Rechtssubjekte, Abteilungen und Teams innerhalb Ihres Unternehmens zu trennen.

Option 3: Auf einem Framework für Rechenschaftspflicht basierende Hierarchie

Eine auf einem Framework für Rechenschaftspflicht basierende Hierarchie funktioniert am besten, wenn Ihre Produkte unabhängig ausgeführt werden oder Organisationseinheiten klar definierte Teams haben, die für den Lebenszyklus der Produkte zuständig sind. In diesen Organisationen sind die Produktinhaber für den gesamten Produktlebenszyklus verantwortlich, einschließlich Prozessen, Support, Richtlinien, Sicherheit und Zugriffsrechten. Ihre Produkte sind unabhängig voneinander. Außerdem sind organisationsweite Richtlinien und Kontrollen nicht üblich.

Verwenden Sie diese Hierarchie, wenn Folgendes zutrifft:

• Sie sind Geschäftsführer einer Organisation, in der für jedes Produkt eine klare Inhaberschaft und Rechenschaftspflicht gelten.
• Ihre Arbeitslasten sind unabhängig voneinander und haben nicht viele gemeinsame Richtlinien.
• Ihre Prozesse und externen Entwicklerplattformen werden als Dienst- oder Produktangebote bereitgestellt.

Das folgende Diagramm zeigt eine Beispielhierarchie für einen E-Commerce-Plattformanbieter.

Das obige Diagramm hat die folgende Hierarchiestruktur:

• Die folgenden Ordner befinden sich auf der ersten Ebene:
  • Die Ordner mit den Namen Ecommerce Modules und Logistics and Warehousing Modules stellen die Module innerhalb des Plattformangebots dar, für die während des Produktlebenszyklus dieselben Zugriffsberechtigungen und Richtlinien erforderlich sind.
  • Der Ordner Reconciliation and Billing stellt die Produktteams dar, die für die End-to-End-Module für bestimmte Geschäftskomponenten innerhalb des Plattformangebots verantwortlich sind.
  • Der Ordner Bootstrap stellt die allgemeinen Ressourcen dar, die zum Bereitstellen Ihrer Google Cloud-Infrastruktur erforderlich sind. Weitere Informationen dazu finden Sie im Blueprint für Unternehmensgrundlagen.
• In jedem Ordner befinden sich verschiedene Projekte mit den unabhängigen Modulen, für die verschiedene Produktteams verantwortlich sind.

Weitere Informationen finden Sie unter Fabric FAST Terraform-Framework-Ressourcenhierarchie.

Best Practices für die Ressourcenhierarchie

In den folgenden Abschnitten werden die Best Practices für das Entwerfen einer Ressourcenhierarchie beschrieben, die wir unabhängig von der ausgewählten Ressourcenhierarchie empfehlen.

Weitere Best Practices zum Konfigurieren von Konten und Organisationen für Cloud Identity und Google Workspace finden Sie unter Best Practices zum Planen von Konten und Organisationen.

Einzelnen Organisationsknoten verwenden

Verwenden Sie nach Möglichkeit einen einzelnen Organisationsknoten, um den Verwaltungsaufwand zu reduzieren. Erwägen Sie jedoch die Verwendung mehrerer Organisationsknoten für die folgenden Anwendungsfälle:

• Sie möchten größere Änderungen an Ihren IAM-Ebenen oder der Ressourcenhierarchie testen.
• Sie möchten in einer Sandbox-Umgebung experimentieren, die nicht dieselben Organisationsrichtlinien enthält.
• Ihre Organisation enthält Tochterunternehmen, die wahrscheinlich verkauft werden oder künftig vollständig als separate Entitäten ausgeführt werden.

Standardisierte Namenskonventionen verwenden

Verwenden Sie in der gesamten Organisation eine standardisierte Namenskonvention. Der Sicherheitsgrundlagen-Blueprint hat eine Beispiel-Namenskonvention, die Sie an Ihre Anforderungen anpassen können.

Bootstrapping-Ressourcen und allgemeine Dienste getrennt verwalten

Speichern Sie separate Ordner für das Bootstrapping der Google Cloud-Umgebung mit Infrastruktur als Code (IaC) und für gängige Dienste, die von Umgebungen oder Anwendungen gemeinsam genutzt werden. Platzieren Sie den Bootstrap-Ordner direkt unter dem Organisationsknoten in der Ressourcenhierarchie.

Platzieren Sie die Ordner für gängige Dienste je nach ausgewählter Struktur auf verschiedenen Hierarchieebenen.

Platzieren Sie den Ordner für gängige Dienste direkt unter dem Organisationsknoten, wenn Folgendes zutrifft:

• Ihre Hierarchie verwendet Anwendungsumgebungen auf der obersten Ebene und Teams oder Anwendungen auf der zweiten Ebene.
• Sie haben freigegebene Dienste wie Monitoring, die für alle Umgebungen gemeinsam genutzt werden.

Platzieren Sie den Ordner für gängige Dienste auf einer niedrigeren Ebene unterhalb der Anwendungsordner, wenn Folgendes zutrifft:

• Sie haben Dienste, die von Anwendungen gemeinsam genutzt werden, und stellen eine separate Instanz für jede Bereitstellungsumgebung bereit.

• Anwendungen teilen sich Mikrodienste, die für jede Bereitstellungsumgebung eine Entwicklung und Tests erfordern.

Das folgende Diagramm zeigt eine Beispielhierarchie, in der sich ein freigegebener Infrastrukturordner befindet, der von allen Umgebungen und freigegebenen Dienstordnern für jede Anwendungsumgebung auf einer niedrigeren Ebene in der Hierarchie verwendet wird:

Das obige Diagramm hat die folgende Hierarchiestruktur:

• Die Ordner auf der ersten Ebene lauten:
  • Die Ordner Development environment und Production environment enthalten die Anwendungsumgebungen.
  • Der Ordner Shared infrastructure enthält allgemeine Ressourcen, die von allen Umgebungen gemeinsam genutzt werden, z. B. das Monitoring.
  • Der Ordner Bootstrap enthält die allgemeinen Ressourcen, die zur Bereitstellung der Google Cloud-Infrastruktur erforderlich sind, wie im Blueprint für Unternehmensgrundlagen beschrieben.
• Auf der zweiten Ebene gibt es die folgenden Ordner:
  • Ein Ordner in jeder Umgebung für jede Anwendung (App 1 und App 2), der die Ressourcen für diese Anwendungen enthält.
  • Ein Shared-Ordner für beide Anwendungsumgebungen, die Dienste enthalten, die von den Anwendungen gemeinsam genutzt werden, aber für jede Umgebung unabhängig sind. Beispiel: Sie haben ein Secret-Projekt auf Ordnerebene, damit Sie auf Ihre Produktions-Secrets und Nicht-Produktions-Secrets unterschiedliche Zulassungsrichtlinien anwenden können.
• In jedem Anwendungsordner befinden sich verschiedene Projekte mit den unabhängigen Modulen, die Teil jeder Anwendung sind.

Nächste Schritte

• Erstellen Sie das Netzwerk für Ihre Landing-Zone (das nächste Dokument in dieser Reihe).
• Blueprint für Unternehmensgrundlagen
• Lesen Sie die Blueprints und Whitepapers, die unter Best Practices für mehr Sicherheit in Google Cloud verfügbar sind.