Blueprint bereitstellen

Last reviewed 2023-12-20 UTC

In diesem Abschnitt werden der Prozess, den Sie zum Bereitstellen des Blueprints verwenden können, sowie seine Namenskonventionen und Alternativen zu Blueprint-Empfehlungen beschrieben.

Zusammenfassung

Führen Sie die in diesem Abschnitt zusammengefassten allgemeinen Aufgaben aus, um Ihre eigene Unternehmensgrundlage in Übereinstimmung mit den Best Practices und Empfehlungen aus diesem Blueprint bereitzustellen. Die Bereitstellung erfordert eine Kombination aus erforderlichen Einrichtungsschritten, einer automatisierten Bereitstellung über die terraform-example-foundation auf GitHub und zusätzlichen Schritten, die manuell konfiguriert werden müssen, nachdem die erste Grundlagenbereitstellung abgeschlossen ist.

Prozesse Schritte

Voraussetzungen für die Bereitstellung der Grundlagenpipeline-Ressourcen

Führen Sie die folgenden Schritte aus, bevor Sie die Grundlagenpipeline bereitstellen:

Bereiten Sie Folgendes vor, um eine Verbindung zu einer vorhandenen lokalen Umgebung herzustellen:

Schritte zum Bereitstellen der terraform-example-foundation von GitHub

Folgen Sie der README-Anleitung für jede Phase, um die terraform-example-foundation von GitHub bereitzustellen:

  • Implementieren Sie Phase 0-bootstrap zum Erstellen einer Grundlagenpipeline.

    Wenn Sie ein Self-Service-Rechnungskonto verwenden, müssen Sie zusätzliche Projektkontingente anfordern, bevor Sie mit der nächsten Phase fortfahren.

  • Implementieren Sie Phase 1-org zum Konfigurieren von Ressourcen auf Organisationsebene.
  • Implementieren Sie Phase 2-environments zum Erstellen von Umgebungen.
  • Implementieren Sie Phase 3-networks-dual-svpc or 3-networks-hub-and-spoke, um Netzwerkressourcen in Ihrer bevorzugten Topologie zu erstellen.
  • Implementieren Sie Phase 4-projects zum Erstellen einer Infrastrukturpipeline bereit.
  • Optional können Sie für die Beispielnutzung der Infrastrukturpipeline Phase 5-app-infra implementieren.

Weitere Schritte nach der IaC-Bereitstellung

Führen Sie nach der Bereitstellung des Terraform-Codes die folgenden Schritte aus:

Zusätzliche Verwaltungsfunktionen für Kunden mit sensiblen Arbeitslasten

Google Cloud bietet zusätzliche administrative Funktionen, mit denen Sie Ihre Sicherheits- und Complianceanforderungen erfüllen können. Einige Funktionen führen jedoch zu zusätzlichen Kosten oder operativen Kompromissen, die möglicherweise nicht für jeden Kunden geeignet sind. Diese Funktionen erfordern auch benutzerdefinierte Eingaben für Ihre spezifischen Anforderungen, die nicht vollständig im Blueprint automatisiert werden können und einen Standardwert für alle Kunden haben.

In diesem Abschnitt werden Sicherheitskontrollen vorgestellt, die Sie zentral auf Ihre Grundlage anwenden. Dieser Abschnitt ist nicht als vollständige Liste aller Sicherheitskontrollen gedacht, die Sie auf bestimmte Arbeitslasten anwenden können. Weitere Informationen zu den Sicherheitsprodukten und -lösungen von Google finden Sie in den Best Practices für mehr Sicherheit in Google Cloud.

Prüfen Sie anhand Ihrer Compliance-Anforderungen, Risikobereitschaft und Vertraulichkeit der Daten, ob die folgenden Kontrollen für Ihre Grundlage geeignet sind.

Steuerelement Beschreibung

Ressourcen mit VPC Service Controls schützen

Mit VPC Service Controls können Sie Sicherheitsrichtlinien definieren, die den Zugriff auf von Google verwaltete Dienste außerhalb eines vertrauenswürdigen Perimeters verhindern, den Zugriff auf Daten von nicht vertrauenswürdigen Standorten blockieren und das Risiko der Daten-Exfiltration verringern. VPC Service Controls kann jedoch dazu führen, dass vorhandene Dienste nur funktionieren, wenn Sie Ausnahmen definieren, um beabsichtigte Zugriffsmuster zuzulassen.

Prüfen Sie, ob der Wert der Minderung des Risikos der Daten-Exfiltration die erhöhte Komplexität und den operativen Aufwand der Einführung von VPC Service Controls rechtfertigt. Der Blueprint bereitet eingeschränkte Netzwerke und optionale Variablen vor, um VPC Service Controls zu konfigurieren. Der Perimeter wird jedoch erst aktiviert, wenn Sie zusätzliche Schritte zum Entwerfen und Aktivieren ausführen.

Ressourcenstandorte einschränken

Möglicherweise bestehen rechtliche Anforderungen dafür, dass Cloud-Ressourcen nur an genehmigten geografischen Standorten bereitgestellt werden dürfen. Diese Einschränkung der Organisationsrichtlinie erzwingt, dass Ressourcen nur in der Liste der von Ihnen definierten Standorte bereitgestellt werden können.

Assured Workloads aktivieren

Assured Workloads bietet zusätzliche Compliancekontrollen, mit denen Sie bestimmte regulatorische Regelungen erfüllen können. Der Blueprint bietet optionale Variablen in der Bereitstellungspipeline für die Aktivierung.

Datenzugriffslogs aktivieren

Möglicherweise müssen Sie den gesamten Zugriff auf bestimmte sensible Daten oder Ressourcen protokollieren.

Prüfen Sie, wo Ihre Arbeitslasten sensible Daten verarbeiten, für die Datenzugriffslogs erforderlich sind, und aktivieren Sie die Logs für jeden Dienst und jede Umgebung, die mit sensiblen Daten arbeitet.

Zugriffsgenehmigung aktivieren

Durch die Zugriffsgenehmigung wird sichergestellt, dass Cloud Customer Care und Ingenieure immer Ihre explizite Genehmigung benötigen, wenn sie auf Ihre Daten zugreifen müssen.

Bewerten Sie den operativen Prozess, der für die Prüfung von Zugriffsgenehmigungsanfragen erforderlich ist, um mögliche Verzögerungen bei der Behebung von Supportvorfällen zu minimieren.

Key Access Justifications aktivieren

Mit Key Access Justifications können Sie programmatisch steuern, ob Google auf Ihre Verschlüsselungsschlüssel zugreifen kann, auch für den Zugriff auf Ihre Kundeninhalte durch automatisierte Vorgänge und Cloud Customer Care.

Bewerten Sie die Kosten und den operativen Aufwand im Zusammenhang mit Key Access Justifications sowie die Abhängigkeit von Cloud External Key Manager (Cloud EKM).

Cloud Shell deaktivieren

Cloud Shell ist eine Online-Entwicklungsumgebung. Diese Shell wird auf einem von Google verwalteten Server außerhalb Ihrer Umgebung gehostet. Daher unterliegt sie nicht den Kontrollen, die Sie möglicherweise auf Ihren eigenen Entwickler-Workstations implementiert haben.

Wenn Sie genau steuern möchten, welche Workstations ein Entwickler verwenden kann, um auf Cloudressourcen zuzugreifen, deaktivieren Sie Cloud Shell. Sie können auch Cloud Workstations im Hinblick auf eine konfigurierbare Workstation-Option in Ihrer eigenen Umgebung evaluieren.

Zugriff auf die Google Cloud Console beschränken

Mit Google Cloud können Sie den Zugriff auf die Google Cloud Console anhand von Attributen für die Zugriffsebene wie Gruppenmitgliedschaft, vertrauenswürdige IP-Adressbereiche und Geräteüberprüfung einschränken. Für einige Attribute ist ein zusätzliches Abo für Chrome Enterprise Premium erforderlich.

Bewerten Sie die Zugriffsmuster, denen Sie für den Nutzerzugriff auf webbasierte Anwendungen wie die Console im Rahmen einer größeren Zero-Trust-Bereitstellung vertrauen.

Namenskonventionen

Wir empfehlen eine standardisierte Namenskonvention für Ihre Google Cloud-Ressourcen. In der folgenden Tabelle werden die empfohlenen Konventionen für Ressourcennamen im Blueprint beschrieben.

Ressource Namenskonvention

Ordner

fldr-environment

environment ist eine Beschreibung der Ressourcen auf Ordnerebene in der Google Cloud-Organisation. Beispiel: bootstrap, common, production, nonproduction, development oder network.

Beispiel: fldr-production

Projekt-ID

prj-environmentcode-description-randomid

  • environmentcode ist eine Kurzform des Umgebungsfelds (entweder b, c, p, n, d oder net). Freigegebene VPC-Hostprojekte verwenden den environmentcode der zugehörigen Umgebung. Für Projekte für Netzwerkressourcen, die von verschiedenen Umgebungen gemeinsam genutzt werden, z. B. das Projekt interconnect, wird der Umgebungscode net verwendet.
  • description sind weitere Informationen zum Projekt. Sie können kurze, visuell lesbare Abkürzungen verwenden.
  • randomid ist ein zufälliges Suffix, um Konflikte bei Ressourcennamen zu vermeiden, die global eindeutig sein müssen, und um Angreifer abzuwehren, die Ressourcennamen erraten. Der Blueprint fügt automatisch eine zufällige alphanumerische Kennung von vier hinzu.

Beispiel: prj-c-logging-a1b2

VPC-Netzwerk

vpc-environmentcode-vpctype-vpcconfig

  • environmentcode ist eine Kurzform des Umgebungsfelds (wahlweise b, c, p, n, d oder net).
  • vpctype ist wahlweise shared, float oder peer.
  • vpcconfig ist entweder base oder restricted, um anzugeben, ob das Netzwerk mit VPC Service Controls verwendet werden soll oder nicht.

Beispiel: vpc-p-shared-base

Subnetz

sn-environmentcode-vpctype-vpcconfig-region{-description}

  • environmentcode ist eine Kurzform des Umgebungsfelds (wahlweise b, c, p, n, d oder net).
  • vpctype ist wahlweise shared, float oder peer.
  • vpcconfig ist entweder base oder restricted, um anzugeben, ob das Netzwerk mit VPC Service Controls verwendet werden soll oder nicht.
  • region ist eine gültige Google Cloud-Region, in der sich die Ressource befindet. Wir empfehlen, Bindestriche zu entfernen und eine abgekürzte Form einiger Regionen und Richtungen zu verwenden, um das Erreichen von Zeichenbeschränkungen zu vermeiden. Beispiel: au (Australien), na (Nordamerika), sa (Südamerika), eu (Europa), se (Südosten) oder ne (Nordosten).
  • description sind zusätzliche Informationen zum Subnetz. Sie können kurze, visuell lesbare Abkürzungen verwenden.

Beispiel: sn-p-shared-restricted-uswest1

Firewallrichtlinien

fw-firewalltype-scope-environmentcode{-description}

  • firewalltype ist hierarchical oder network.
  • scope ist global oder die Google Cloud-Region, in der sich die Ressource befindet. Wir empfehlen, Bindestriche zu entfernen und eine abgekürzte Form einiger Regionen und Richtungen zu verwenden, um das Erreichen von Zeichenbeschränkungen zu vermeiden. Beispiel: au (Australien), na (Nordamerika), sa (Südamerika), eu (Europa), se (Südosten) oder ne (Nordosten).
  • environmentcode ist eine Kurzform des Umgebungsfelds (wahlweise b, c, p, n, d oder net), das die Richtlinienressource besitzt.
  • description sind zusätzliche Informationen zur hierarchischen Firewallrichtlinie. Sie können kurze, visuell lesbare Abkürzungen verwenden.

Beispiel:

fw-hierarchical-global-c-01

fw-network-uswest1-p-shared-base

Cloud Router

cr-environmentcode-vpctype-vpcconfig-region{-description}

  • environmentcode ist eine Kurzform des Umgebungsfelds (wahlweise b, c, p, n, d oder net).
  • vpctype ist wahlweise shared, float oder peer.
  • vpcconfig ist entweder base oder restricted, um anzugeben, ob das Netzwerk mit VPC Service Controls verwendet werden soll oder nicht.
  • region ist eine gültige Google Cloud-Region, in der sich die Ressource befindet. Wir empfehlen, Bindestriche zu entfernen und eine abgekürzte Form einiger Regionen und Richtungen zu verwenden, um das Erreichen von Zeichenbeschränkungen zu vermeiden. Beispiel: au (Australien), na (Nordamerika), sa (Südamerika), eu (Europa), se (Südosten) oder ne (Nordosten).
  • description sind zusätzliche Informationen zum Cloud Router. Sie können kurze, visuell lesbare Abkürzungen verwenden.

Beispiel: cr-p-shared-base-useast1-cr1

Cloud Interconnect-Verbindung

ic-dc-colo

  • dc ist der Name Ihres Rechenzentrums, mit dem eine Cloud Interconnect-Verbindung verbunden ist.
  • colo ist der Name der Colocations-Einrichtung, mit der die Cloud Interconnect-Verbindung aus dem lokalen Rechenzentrum verbunden ist.

Beispiel: ic-mydatacenter-lgazone1

Cloud Interconnect-VLAN-Anhang

vl-dc-colo-environmentcode-vpctype-vpcconfig-region{-description}

  • dc ist der Name Ihres Rechenzentrums, mit dem eine Cloud Interconnect-Verbindung verbunden ist.
  • colo ist der Name der Colocations-Einrichtung, mit der die Cloud Interconnect-Verbindung aus dem lokalen Rechenzentrum verbunden ist.
  • environmentcode ist eine Kurzform des Umgebungsfelds (wahlweise b, c, p, n, d oder net).
  • vpctype ist wahlweise shared, float oder peer.
  • vpcconfig ist entweder base oder restricted, um anzugeben, ob das Netzwerk mit VPC Service Controls verwendet werden soll oder nicht.
  • region ist eine gültige Google Cloud-Region, in der sich die Ressource befindet. Wir empfehlen, Bindestriche zu entfernen und eine abgekürzte Form einiger Regionen und Richtungen zu verwenden, um das Erreichen von Zeichenbeschränkungen zu vermeiden. Beispiel: au (Australien), na (Nordamerika), sa (Südamerika), eu (Europa), se (Südosten) oder ne (Nordosten).
  • description sind zusätzliche Informationen zum VLAN. Sie können kurze, visuell lesbare Abkürzungen verwenden.

Beispiel: vl-mydatacenter-lgazone1-p-shared-base-useast1-cr1

Gruppe

grp-gcp-description@example.com

Dabei sind description zusätzliche Informationen zur Gruppe. Sie können kurze, visuell lesbare Abkürzungen verwenden.

Beispiel: grp-gcp-billingadmin@example.com

Benutzerdefinierte Rolle

rl-description

Dabei sind description zusätzliche Informationen zur Rolle. Sie können kurze, visuell lesbare Abkürzungen verwenden.

Beispiel: rl-customcomputeadmin

Dienstkonto

sa-description@projectid.iam.gserviceaccount.com

Wobei:

  • description sind zusätzliche Informationen zum Dienstkonto. Sie können kurze, visuell lesbare Abkürzungen verwenden.
  • projectid ist die global eindeutige Projekt-ID.

Beispiel: sa-terraform-net@prj-b-seed-a1b2.iam.gserviceaccount.com

Storage-Bucket

bkt-projectid-description

Wobei:

  • projectid ist die global eindeutige Projekt-ID.
  • description sind zusätzliche Informationen zum Storage-Bucket. Sie können kurze, visuell lesbare Abkürzungen verwenden.

Beispiel: bkt-prj-c-infra-pipeline-a1b2-app-artifacts

Alternativen zu Standardempfehlungen

Die im Blueprint empfohlenen Best Practices funktionieren möglicherweise nicht für jeden Kunden. Sie können jede der Empfehlungen an Ihre spezifischen Anforderungen anpassen. In der folgenden Tabelle werden einige der allgemeinen Varianten vorgestellt, die Sie basierend auf Ihrem vorhandenen Technologie-Stack und Ihrer Arbeitsweise möglicherweise benötigen.

Entscheidungsbereich Mögliche Alternativen

Organisation: Der Blueprint verwendet eine einzelne Organisation als Stammknoten für alle Ressourcen.

Unter Ressourcenhierarchie für Ihre Google Cloud-Landing-Zone festlegen werden Szenarien eingeführt, in denen Sie möglicherweise mehrere Organisationen bevorzugen, zum Beispiel:

  • Ihre Organisation enthält Tochterunternehmen, die wahrscheinlich in Zukunft verkauft werden oder als vollständig separate Entitäten ausgeführt werden.
  • Sie möchten in einer Sandbox-Umgebung ohne Verbindung zu Ihrer vorhandenen Organisation experimentieren.

Ordnerstruktur: Der Blueprint hat eine einfache Ordnerstruktur, in der die Arbeitslasten in die Ordner production, non-production und development auf der obersten Ebene unterteilt sind.

Unter Ressourcenhierarchie für Ihre Google Cloud-Landing-Zone festlegen werden andere Ansätze zum Strukturieren von Ordnern erläutert. Diese basieren darauf, wie Sie Ressourcen verwalten und Richtlinien übernehmen möchten, zum Beispiel:

  • Ordner basierend auf Anwendungsumgebungen
  • Ordner basierend auf regionalen Entitäten oder Tochtergesellschaften
  • Ordner basierend auf dem Framework für Rechenschaftspflicht

Organisationsrichtlinien: Der Blueprint erzwingt alle Einschränkungen für Organisationsrichtlinien auf dem Organisationsknoten.

Möglicherweise haben Sie für verschiedene Bereiche des Unternehmens unterschiedliche Sicherheitsrichtlinien oder Arbeitsmethoden. Erzwingen Sie in diesem Szenario Einschränkungen für Organisationsrichtlinien auf einem niedrigeren Knoten in der Ressourcenhierarchie. Lesen Sie die vollständige Liste der Einschränkungen für Organisationsrichtlinien, die dazu beitragen, Ihre Anforderungen zu erfüllen.

Tools für die Bereitstellungspipeline: Der Blueprint verwendet Cloud Build, um die Automatisierungspipeline auszuführen.

Sie bevorzugen möglicherweise andere Produkte für Ihre Bereitstellungspipeline, z. B. Terraform Enterprise, GitLab-Runners, GitHub Actions oder Jenkins Der Blueprint enthält alternative Anweisungen für jedes Produkt.

Code-Repository für die Bereitstellung: Der Blueprint verwendet Cloud Source Repositories als verwaltetes privates Git-Repository.

Verwenden Sie Ihr bevorzugtes Versionsverwaltungssystem zum Verwalten von Code-Repositories wie GitLab, GitHub oder Bitbucket.

Wenn Sie ein privates Repository verwenden, das in Ihrer lokalen Umgebung gehostet wird, konfigurieren Sie einen privaten Netzwerkpfad von Ihrem Repository zu Ihrer Google Cloud-Umgebung.

Identitätsanbieter: Der Blueprint geht von einem lokalen Active Directory aus und verbindet Identitäten mithilfe von Google Cloud Directory Sync mit Cloud Identity.

Wenn Sie bereits Google Workspace verwenden, können Sie die Google-Identitäten verwenden, die bereits in Google Workspace verwaltet werden.

Wenn Sie noch keinen Identitätsanbieter haben, können Sie Nutzeridentitäten direkt in Cloud Identity erstellen und verwalten.

Wenn Sie bereits einen Identitätsanbieter wie Okta, Ping oder Azure Entra ID haben, können Sie möglicherweise Nutzerkonten in Ihrem vorhandenen Identitätsanbieter verwalten und mit Cloud Identity synchronisieren.

Wenn Sie Datenhoheits- oder Complianceanforderungen haben, die die Verwendung von Cloud Identity verhindern, und wenn Sie keine verwalteten Google-Nutzeridentitäten für andere Google-Dienste wie Google Ads oder die Google Marketing Platform benötigen, dann ziehen Sie möglicherweise die Mitarbeiteridentitätsföderation vor. Beachten Sie in diesem Szenario Einschränkungen bei unterstützten Diensten.

Mehrere Regionen: Der Blueprint stellt regionale Ressourcen in zwei verschiedenen Google Cloud-Regionen bereit, um das Arbeitslastdesign unter Berücksichtigung der Anforderungen an Hochverfügbarkeit und Notfallwiederherstellung zu ermöglichen.

Wenn Sie Endnutzer an mehr geografischen Standorten haben, können Sie weitere Google Cloud-Regionen konfigurieren, um Ressourcen mit geringerer Latenz näher am Endnutzer zu erstellen.

Wenn Sie Einschränkungen für die Datenhoheit haben oder Ihre Verfügbarkeitsanforderungen in einer einzelnen Region erfüllt werden können, konfigurieren Sie möglicherweise nur eine Google Cloud-Region.

IP-Adresszuweisung: Der Blueprint enthält eine Reihe von IP-Adressbereichen.

Möglicherweise müssen Sie die spezifischen IP-Adressbereiche ändern, die auf der Verfügbarkeit der IP-Adresse in der vorhandenen Hybridumgebung basieren. Wenn Sie die IP-Adressbereiche ändern, verwenden Sie den Blueprint als Richtlinie für die Anzahl und Größe der benötigten Bereiche und prüfen Sie die gültigen IP-Adressbereiche für Google Cloud.

Hybridnetzwerk: Der Blueprint verwendet Dedicated Interconnect über mehrere physische Standorte und Google Cloud-Regionen hinweg für maximale Bandbreite und Verfügbarkeit.

Abhängig von Ihren Anforderungen an Kosten, Bandbreite und Zuverlässigkeit können Sie stattdessen Partner Interconnect oder Cloud VPN konfigurieren.

Wenn Sie Ressourcen mit privater Verbindung bereitstellen müssen, bevor eine Dedicated Interconnect-Verbindung abgeschlossen werden kann, können Sie mit Cloud VPN beginnen und später zu Dedicated Interconnect wechseln.

Wenn Sie noch keine lokale Umgebung haben, benötigen Sie möglicherweise überhaupt kein Hybridnetzwerk.

VPC Service Controls-Perimeter: Der Blueprint empfiehlt einen einzelnen Perimeter, der alle Dienstprojekte enthält, die einem eingeschränkten VPC-Netzwerk zugeordnet sind. Projekte, die einem Basis-VPC-Netzwerk zugeordnet sind, sind nicht Teil des Perimeters.

Möglicherweise haben Sie einen Anwendungsfall, in dem mehrere Perimeter für eine Organisation erforderlich sind, oder Sie entschließen sich möglicherweise, VPC Service Controls überhaupt nicht zu verwenden.

Weitere Informationen finden Sie unter Entscheiden, wie die Daten-Exfiltration über Google APIs minimiert werden soll.

Secret Manager: Der Blueprint stellt ein Projekt für die Verwendung von Secret Manager im Ordner common von organisationsweiten Secrets und ein Projekt in jedem Umgebungsordner für umgebungsspezifische Secrets bereit.

Wenn Sie ein einzelnes Team haben, das für die Verwaltung und Prüfung vertraulicher Secrets in der gesamten Organisation verantwortlich ist, möchten Sie möglicherweise nur ein einziges Projekt für die Verwaltung des Zugriffs auf Secrets verwenden.

Wenn Sie Arbeitslastteams ihre eigenen Secrets verwalten lassen, können Sie möglicherweise kein zentrales Projekt für die Verwaltung des Zugriffs auf Secrets verwenden und zulassen, dass Teams ihre eigenen Instanzen von Secret Manager in Arbeitslastprojekten verwenden.

Cloud KMS: Der Blueprint stellt ein Projekt für die Verwendung von Cloud KMS im Ordner common für organisationsweite Schlüssel und ein Projekt für jeden Umgebungsordner für Schlüssel in jeder Umgebung bereit.

Wenn Sie ein einzelnes Team haben, das in der gesamten Organisation für die Verwaltung und Prüfung der Verschlüsselungsschlüssel verantwortlich ist, möchten Sie möglicherweise nur ein einziges Projekt zur Verwaltung des Zugriffs auf Schlüssel verwenden. Mit einem zentralisierten Ansatz können Sie Compliance-Anforderungen wie PCI-Schlüssel-Custodians erfüllen.

Wenn Sie es Arbeitslastteams ermöglichen, ihre eigenen Schlüssel zu verwalten, verwenden Sie möglicherweise kein zentrales Projekt zur Verwaltung des Zugriffs auf Schlüssel, sondern lassen Teams ihre eigenen Instanzen von Cloud KMS in Arbeitslastprojekten verwenden.

Aggregierte Logsenken: Der Blueprint konfiguriert eine Reihe von Logsenken auf dem Organisationsknoten, sodass ein zentrales Sicherheitsteam Audit-Logs aus der gesamten Organisation prüfen kann.

Möglicherweise verfügen Sie über verschiedene Teams, die für die Prüfung verschiedener Teile des Unternehmens zuständig sind, und diese Teams benötigen möglicherweise unterschiedliche Logs für ihre Aufgaben. Entwerfen Sie in diesem Szenario mehrere aggregierte Senken in den entsprechenden Ordnern und Projekten und erstellen Sie Filter, sodass jedes Team nur die erforderlichen Logs erhält. Sie können auch Logansichten für eine detaillierte Zugriffssteuerung auf einen gemeinsamen Log-Bucket erstellen.

Granularität von Infrastrukturpipelines: Der Blueprint verwendet ein Modell, bei dem jede Geschäftseinheit eine separate Infrastrukturpipeline zur Verwaltung ihrer Arbeitslastprojekte hat.

Sie könnten möglicherweise eine einzelne Infrastrukturpipeline bevorzugen, die von einem zentralen Team verwaltet wird, wenn Sie ein zentrales Team haben, das für die Bereitstellung aller Projekte und Infrastrukturen zuständig ist. Dieses zentrale Team kann Pull-Anfragen von Arbeitslastteams annehmen, die vor der Projekterstellung geprüft und genehmigt werden, oder das Team kann die Pull-Anfrage selbst als Reaktion auf ein Ticketsystem erstellen.

Möglicherweise bevorzugen Sie detailliertere Pipelines, wenn einzelne Arbeitslastteams die Möglichkeit haben, ihre eigenen Pipelines anzupassen, und Sie möchten detailliertere privilegierte Dienstkonten für die Pipelines entwerfen.

SIEM-Exporte: Der Blueprint verwaltet alle Sicherheitsergebnisse im Security Command Center.

Entscheiden Sie, ob Sie Sicherheitsergebnisse aus Security Command Center in Tools wie Google Security Operations oder in Ihr vorhandenes SIEM exportieren möchten oder ob Teams die Sicherheitsergebnisse mit der Console ansehen und verwalten sollen. Sie können mehrere Exporte mit eindeutigen Filtern für verschiedene Teams mit unterschiedlichen Bereichen und Verantwortlichkeiten konfigurieren.

DNS-Lookups für lokale Google Cloud-Dienste: Der Blueprint konfiguriert einen eindeutigen Private Service Connect-Endpunkt für jede freigegebene VPC, der dazu beitragen kann, Designs mit mehreren VPC Service Controls-Perimetern zu aktivieren.

Möglicherweise benötigen Sie kein Routing von einer lokalen Umgebung zu Private Service Connect-Endpunkten auf diesem Detaillierungsgrad, wenn Sie nicht mehrere VPC Service Control-Perimeter benötigen.

Anstatt lokale Hosts den Private Service Connect-Endpunkten nach Umgebung zuzuordnen, können Sie dieses Design vereinfachen, um einen einzelnen Private Service Connect-Endpunkt mit dem entsprechenden API-Bundle zu verwenden, oder die generischen Endpunkte für private.googlepais.com und restricted.googleapis.com nutzen.

Nächste Schritte