Organisationsstruktur

Last reviewed 2023-12-20 UTC

Der Stammknoten zum Verwalten von Ressourcen in Google Cloud ist die Organisation. Die Google Cloud-Organisation bietet eine Ressourcenhierarchie, die eine Inhaberstruktur für Ressourcen und Verbindungspunkte für Organisationsrichtlinien und Zugriffssteuerungen bietet. Die Ressourcenhierarchie besteht aus Ordnern, Projekten und Ressourcen und definiert die Struktur und Nutzung von Google Cloud-Diensten innerhalb einer Organisation.

Ressourcen, die niedriger in der Hierarchie sind, übernehmen Richtlinien wie IAM-Zulassungsrichtlinien und Organisationsrichtlinien. Alle Zugriffsberechtigungen werden standardmäßig abgelehnt, bis Sie Zulassungsrichtlinien direkt auf eine Ressource anwenden oder die Ressource die Zulassungsrichtlinien von einer höheren Ebene in der Ressourcenhierarchie übernimmt.

Das folgende Diagramm zeigt die Ordner und Projekte, die durch den Blueprint bereitgestellt werden.

Die Organisationsstruktur von example.com

In den folgenden Abschnitten werden die Ordner und Projekte im Diagramm beschrieben.

Ordner

Der Blueprint verwendet Ordner, um Projekte anhand ihrer Umgebung zu gruppieren. Diese logische Gruppierung wird verwendet, um Konfigurationen wie Zulassungsrichtlinien und Organisationsrichtlinien auf Ordnerebene anzuwenden. Alle Ressourcen im Ordner übernehmen dann die Richtlinien. In der folgenden Tabelle werden die Ordner beschrieben, die Teil des Blueprints sind.

Ordner Beschreibung
bootstrap Enthält die Projekte, die zum Bereitstellen von Grundlagenkomponenten verwendet werden
common Enthält Projekte mit Ressourcen, die von allen Umgebungen gemeinsam genutzt werden.
production Enthält Projekte mit Produktionsressourcen.
nonproduction Enthält eine Kopie der Produktionsumgebung, mit der Sie Arbeitslasten testen können, bevor Sie sie für die Produktion übernehmen.
development Enthält die Cloud-Ressourcen, die für die Bereitstellung verwendet werden.
networking Enthält die Netzwerkressourcen, die von allen Umgebungen gemeinsam genutzt werden.

Projekte

Der Blueprint verwendet Projekte, um einzelne Ressourcen basierend auf ihrer Funktionalität und ihren beabsichtigten Grenzen für die Zugriffssteuerung zu gruppieren. In der folgenden Tabelle werden die im Blueprint enthaltenen Projekte beschrieben.

Ordner Projekt Beschreibung
bootstrap prj-b-cicd Enthält die Bereitstellungspipeline, mit der die Grundlagenkomponenten der Organisation aufgebaut werden Weitere Informationen finden Sie unter Bereitstellungsmethode.
prj-b-seed Enthält den Terraform-Status Ihrer Infrastruktur und das Terraform-Dienstkonto, das zum Ausführen der Pipeline erforderlich ist. Weitere Informationen finden Sie unter Bereitstellungsmethode.
common prj-c-secrets Enthält Secrets auf Organisationsebene Weitere Informationen finden Sie unter Anmeldedaten für Anwendungen mit Secret Manager speichern.
prj-c-logging Enthält die aggregierten Logquellen für Audit-Logs. Weitere Informationen finden Sie unter Zentralisiertes Logging für Sicherheit und Audit.
prj-c-scc Enthält Ressourcen zum Konfigurieren von Security Command Center-Benachrichtigungen und anderen benutzerdefinierten Sicherheitsmonitorings. Weitere Informationen finden Sie unter Bedrohungsmonitoring mit Security Command Center.
prj-c-billing-logs Enthält ein BigQuery-Dataset mit den Abrechnungsexporten der Organisation Weitere Informationen finden Sie unter Kosten zwischen internen Kostenstellen zuweisen.
prj-c-infra-pipeline Enthält eine Infrastrukturpipeline zum Bereitstellen von Ressourcen wie VMs und Datenbanken, die von Arbeitslasten verwendet werden sollen. Weitere Informationen finden Sie unter Pipelineebenen.
prj-c-kms Enthält Verschlüsselungsschlüssel auf Organisationsebene. Weitere Informationen finden Sie unter Verschlüsselungsschlüssel verwalten.
networking prj-net-{env}-shared-base Enthält das Hostprojekt für ein freigegebenes VPC-Netzwerk für Arbeitslasten, die keine VPC Service Controls erfordern. Weitere Informationen finden Sie unter Netzwerktopologie.
prj-net-{env}-shared-restricted Enthält das Hostprojekt für ein freigegebenes VPC-Netzwerk für Arbeitslasten, die VPC Service Controls erfordern. Weitere Informationen finden Sie unter Netzwerktopologie.
prj-net-interconnect Enthält die Cloud Interconnect-Verbindungen, die die Konnektivität zwischen Ihrer lokalen Umgebung und Google Cloud bieten. Weitere Informationen finden Sie unter Hybridkonnektivität.
prj-net-dns-hub Enthält Ressourcen für einen zentralen Kommunikationspunkt zwischen Ihrem lokalen DNS-System und Cloud DNS. Weitere Informationen finden Sie unter Zentrale DNS-Einrichtung.
Umgebungsordner (production, non-production und development) prj-{env}-monitoring Enthält ein den Umfang festlegendes Projekt, um Messwerte aus Projekten in dieser Umgebung zu aggregieren. Weitere Informationen finden Sie unter Benachrichtigungen zu logbasierten Messwerten und Leistungsmesswerten.
prj-{env}-secrets Enthält Secrets auf Ordnerebene Weitere Informationen finden Sie unter Anmeldedaten von Anwendungen mit Secret Manager speichern und prüfen.
prj-{env}-kms Enthält Verschlüsselungsschlüssel auf Ordnerebene. Weitere Informationen finden Sie unter Verschlüsselungsschlüssel verwalten.
Anwendungsprojekte Enthält verschiedene Projekte, in denen Sie Ressourcen für Anwendungen erstellen. Weitere Informationen finden Sie unter Projektbereitstellungsmuster und Pipelineebenen.

Governance für Ressourceninhaberschaft

Wir empfehlen, Labels auf Ihre Projekte konsistent anzuwenden, um die Governance und die Kostenzuordnung zu unterstützen. In der folgenden Tabelle werden die Projektlabels beschrieben, die jedem Projekt für die Governance im Blueprint hinzugefügt werden.

Label Beschreibung
application Der menschenlesbare Name der Anwendung oder Arbeitslast, die mit dem Projekt verknüpft ist.
businesscode Ein kurzer Code, der beschreibt, welcher Geschäftseinheit das Projekt gehört. Der Code shared wird für allgemeine Projekte verwendet, die nicht explizit mit einer Geschäftseinheit verknüpft sind.
billingcode Ein Code, der zur Bereitstellung von Rückbuchungsinformationen verwendet wird.
primarycontact Der Nutzername des primären Kontakts, der für das Projekt verantwortlich ist. Da Projektlabels keine Sonderzeichen wie @ enthalten dürfen, wird der Nutzername ohne das @example.com-Suffix auf den Nutzernamen gesetzt.
secondarycontact Der Nutzername des sekundären Kontakts, der für das Projekt verantwortlich ist. Da Projektlabels keine Sonderzeichen wie @ enthalten dürfen, legen Sie nur den Nutzernamen ohne das @example.com-Suffix fest.
environment Ein Wert, der den Umgebungstyp identifiziert, z. B. bootstrap, common, production, non-production,development oder network.
envcode Ein Wert, der den Umgebungstyp identifiziert, gekürzt auf b, c, p, n, d oder net.
vpc Die ID des VPC-Netzwerks, das von diesem Projekt verwendet werden soll.

Google sendet gelegentlich wichtige Benachrichtigungen wie Kontosperrungen oder Aktualisierungen von Produktbedingungen. Der Blueprint verwendet wichtige Kontakte, um diese Benachrichtigungen an die Gruppen zu senden, die Sie während der Bereitstellung konfigurieren. Wichtige Kontakte werden auf dem Organisationsknoten konfiguriert und von allen Projekten in der Organisation übernommen. Wir empfehlen Ihnen, diese Gruppen zu prüfen und sicherzustellen, dass E-Mails zuverlässig überwacht werden.

Wichtige Kontakte werden für einen anderen Zweck verwendet als die Felder primarycontact und secondarycontact, die in Projektlabels konfiguriert sind. Die Kontakte in Projektlabels sind für die interne Governance vorgesehen. Wenn Sie beispielsweise nicht konforme Ressourcen in einem Arbeitslastprojekt identifizieren und die Inhaber kontaktieren müssen, können Sie das Feld primarycontact verwenden, um die Person oder das Team zu ermitteln, das für diese Arbeitslast verantwortlich ist.

Nächste Schritte

  • Netzwerk (nächstes Dokument in dieser Reihe)