Blueprint bereitstellen

Voraussetzungen für die Bereitstellung der Pipeline-Ressourcen der Foundation

Führen Sie die folgenden Schritte aus, bevor Sie die Foundation-Pipeline bereitstellen:

• Erstellen Sie ein Cloud Identity-Konto und bestätigen Sie die Domaininhaberschaft.
• Beantragen Sie bei Ihrem Google Cloud-Vertriebsteam ein Rechnungskonto mit Rechnungsstellung oder erstellen Sie ein Selfservice-Rechnungskonto.
• Erzwingen Sie Best Practices für die Sicherheit von Administratorkonten.
• Prüfen Sie Probleme mit Privatnutzerkonten und gleichen Sie sie ab.
• Konfigurieren Sie Ihren externen Identitätsanbieter als „Source of Truth“, um Nutzerkonten und SSO zu synchronisieren.
• Stellen Sie die Gruppen für die Zugriffssteuerung bereit, die zum Ausführen des Blueprints erforderlich sind.
• Bestimmen Sie die Netzwerktopologie, die Sie verwenden werden.
• Wählen Sie ein Tool zur Quellcodeverwaltung aus. Die Anleitung für terraform-example-foundation wird in ein Git-Repository geschrieben, das in Cloud Source Repositories gehostet wird.
• Entscheiden Sie sich für Ihre CI/CD-Automatisierungstools. Die terraform-example-foundation bietet unterschiedliche Anleitungen für verschiedene Automatisierungstools.

Wenn Sie eine Verbindung zu einer vorhandenen lokalen Umgebung herstellen möchten, müssen Sie Folgendes vorbereiten:

• Planen Sie die IP‑Adresszuweisung anhand der Anzahl und Größe der Bereiche, die gemäß dem Blueprint erforderlich sind.
• Bestellen Sie Ihre Dedicated Interconnect-Verbindungen.

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 Selfservice-Abrechnungskonto verwenden, müssen Sie ein zusätzliches Projektkontingent anfordern, bevor Sie mit der nächsten Phase fortfahren können.

• 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.

Zusätzliche Schritte nach der IaC-Bereitstellung

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

• Führen Sie die Änderungen an der lokalen Konfiguration aus.
• Aktivieren Sie Security Command Center Premium.
• Exportieren Sie Cloud Billing-Daten nach BigQuery.
• Registrieren Sie sich für einen Cloud Customer Care-Tarif.
• Aktivieren Sie Access Transparency-Logs.
• Geben Sie Daten aus Cloud Identity für Google Cloud frei.
• Wenden Sie die Verwaltungsfunktionen für Cloud Identity an, die nicht durch das IaC-Deployment automatisiert werden.
• Prüfen Sie, welche der zusätzlichen Verwaltungsfunktionen für Kunden mit sensiblen Arbeitslasten für Ihren Anwendungsfall geeignet sind.
• Sehen Sie sich die Best Practices für den Betrieb an und planen Sie, wie Sie Ihre vorhandenen Abläufe und Funktionen mit den Foundation-Ressourcen verknüpfen.

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 zur Konfiguration von VPC Service Controls vor. Der Perimeter wird jedoch erst aktiviert, wenn Sie zusätzliche Schritte zum Entwerfen und Aktivieren ausführen.

Ressourcenstandorte einschränken

Möglicherweise gelten für Sie behördliche Anforderungen, dass Cloud-Ressourcen nur an genehmigten Standorten bereitgestellt werden dürfen. Mit dieser Einschränkung der Organisationsrichtlinie wird erzwungen, dass Ressourcen nur an den von Ihnen definierten Standorten bereitgestellt werden können.

Assured Workloads aktivieren

Assured Workloads bietet zusätzliche Compliance-Kontrollen, mit denen Sie bestimmte Regulierungssysteme einhalten können. Der Blueprint bietet optionale Variablen in der Bereitstellungspipeline zur Aktivierung.

Datenzugriffslogs aktivieren

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

Bewerten 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 arbeiten.

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.

Prüfe den operativen Prozess, der für die Prüfung von Anträgen auf Zugriffsberechtigung erforderlich ist, um mögliche Verzögerungen bei der Behebung von Supportanfragen zu vermeiden.

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 Overhead 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 und unterliegt daher 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 als konfigurierbare Workstation-Option in Ihrer eigenen Umgebung verwenden.

Zugriff auf die Google Cloud Console beschränken

Mit Google Cloud können Sie den Zugriff auf die Google Cloud Console anhand von Attributen auf 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.

Prüfen Sie die Zugriffsmuster, die Sie für den Nutzerzugriff auf webbasierte Anwendungen wie die Console als Teil einer größeren Zero-Trust-Bereitstellung vertrauenswürdig erachten.

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 (b, c, p, n, d oder net). Bei freigegebene VPC-Hostprojekten wird die environmentcode der zugehörigen Umgebung verwendet. Für Projekte mit Netzwerkressourcen, die für mehrere Umgebungen freigegeben sind, wie das Projekt interconnect, wird der Umgebungscode net verwendet.
• description sind zusätzliche 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 vierstellige alphanumerische Kennung 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 einige Regionen und Richtungen abzukürzen, um die Zeichenbeschränkung nicht zu überschreiten. 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 einige Regionen und Richtungen abzukürzen, um die Zeichenbeschränkung nicht zu überschreiten. 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 einige Regionen und Richtungen abzukürzen, um die Zeichenbeschränkung nicht zu überschreiten. 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 einige Regionen und Richtungen abzukürzen, um die Zeichenbeschränkung nicht zu überschreiten. 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 steht description für 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 steht description für 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 weltweit eindeutige Projekt-ID.

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

Storage-Bucket

bkt-projectid-description

Wobei:

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

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

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

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 Unternehmen geführt werden.
• Sie möchten in einer Sandbox-Umgebung experimentieren, die keine Verbindung zu Ihrer bestehenden Organisation hat.

Ordnerstruktur: Der Blueprint hat eine einfache Ordnerstruktur, bei der Arbeitslasten in der obersten Ebene in die Ordner production, non-production und development 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 einem Framework für Rechenschaftspflicht

Organisationsrichtlinien:Im Blueprint werden alle Einschränkungen für Organisationsrichtlinien am Organisationsknoten erzwungen.

Möglicherweise gelten für verschiedene Bereiche des Unternehmens unterschiedliche Sicherheitsrichtlinien oder Arbeitsweisen. In diesem Szenario werden Einschränkungen der Organisationsrichtlinie auf einem niedrigeren Knoten in der Ressourcenhierarchie erzwungen. 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:Im Blueprint wird Cloud Build verwendet, 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 Anleitungen für jedes Produkt.

Code-Repository für die Bereitstellung:In der Vorlage wird Cloud Source Repositories als verwaltetes privates Git-Repository verwendet.

Verwenden Sie Ihr bevorzugtes Versionskontrollsystem zum Verwalten von Code-Repositories, z. B. 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 setzt ein lokales Active Directory voraus und föderiert 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 die Einschränkungen bei unterstützten Diensten.

Mehrere Regionen:Der Blueprint stellt regionale Ressourcen in zwei verschiedenen Google Cloud-Regionen bereit, um ein Arbeitslastdesign mit Hochverfügbarkeit und Notfallwiederherstellungsanforderungen zu ermöglichen.

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

Wenn Sie Einschränkungen hinsichtlich der Datensouveränität haben oder Ihre Verfügbarkeitsanforderungen in einer einzelnen Region erfüllt werden können, können Sie nur eine Google Cloud-Region konfigurieren.

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.

Je nach 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 keine lokale Umgebung haben, benötigen Sie möglicherweise kein hybrides Netzwerk.

VPC Service Controls-Perimeter:Der Blueprint empfiehlt einen einzelnen Perimeter, der alle Dienstprojekte umfasst, die mit einem eingeschränkten VPC-Netzwerk verknüpft sind. Projekte, die mit einem Basis-VPC-Netzwerk verknüpft sind, sind nicht im Perimeter enthalten.

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 ein einzelnes Team für die Verwaltung und Prüfung vertraulicher Secrets in der gesamten Organisation verantwortlich ist, sollten Sie möglicherweise nur ein einziges Projekt für die Verwaltung des Zugriffs auf Secrets verwenden.

Wenn Sie es Arbeitslastteams ermöglichen, ihre eigenen Secrets zu verwalten, verwenden Sie möglicherweise kein zentrales Projekt zur Verwaltung des Zugriffs auf Secrets, sondern lassen 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 ein einzelnes Team für die Verwaltung und Prüfung von Verschlüsselungsschlüsseln in der gesamten Organisation zuständig ist, sollten Sie für die Verwaltung des Zugriffs auf Schlüssel nur ein einziges Projekt 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.

Zusammengefasste Logsenke:Mit dem Blueprint wird eine Reihe von Logsenken am Organisationsknoten konfiguriert, damit 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 zur Prüfung und Genehmigung vor der Projekterstellung akzeptieren. Alternativ kann das Team die Pull-Anfrage selbst als Reaktion auf ein Ticketsystem erstellen.

Detailliertere Pipelines eignen sich beispielsweise, wenn einzelne Arbeitslastteams ihre eigenen Pipelines anpassen können und Sie detailliertere privilegierte Dienstkonten für die Pipelines entwerfen möchten.

SIEM-Exporte:Der Blueprint verwaltet alle Sicherheitserkenntnisse 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 individuellen Filtern für verschiedene Teams mit unterschiedlichem Umfang und unterschiedlichen 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.googleapis.com und restricted.googleapis.com nutzen.