Blueprint bereitstellen

Last reviewed 2025-05-15 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

Wenn Sie Ihre eigene Unternehmensgrundlage gemäß den Best Practices und Empfehlungen dieses Blueprints bereitstellen möchten, folgen Sie den allgemeinen Aufgaben, die in diesem Abschnitt zusammengefasst sind. 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.

Prozess Schritte

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

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

So stellen Sie eine Verbindung zu einer vorhandenen lokalen Umgebung her:

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-Abrechnungskonto verwenden, müssen Sie zusätzliches Projektkontingent 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.

Zusätzliche 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 Steuerelemente, die Ihnen helfen können, Ihre Sicherheits- und Compliance-Anforderungen zu erfüllen. 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 soll nicht alle Sicherheitskontrollen abdecken, die Sie auf bestimmte Arbeitslasten anwenden können. Weitere Informationen zu den Sicherheitsprodukten und ‑lösungen von Google finden Sie im Google Cloud Best Practices Center für Sicherheit.

Prüfen Sie, ob die folgenden Kontrollmaßnahmen für Ihre Grundlage geeignet sind, basierend auf Ihren Compliance-Anforderungen, Ihrer Risikobereitschaft und der Vertraulichkeit der Daten.

Kontrolle 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. Das Blueprint bereitet die erforderlichen Netzwerksteuerungen und einen VPC Service Controls-Perimeter für den Testlauf vor. Der Perimeter wird jedoch erst erzwungen, wenn Sie zusätzliche Schritte ausführen.

Ressourcenstandorte einschränken

Möglicherweise müssen Sie behördliche Anforderungen erfüllen, die vorschreiben, dass Cloud-Ressourcen nur an genehmigten geografischen 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. Das Blueprint bietet optionale Variablen in der Bereitstellungspipeline für die Aktivierung.

Datenzugriffslogs aktivieren

Möglicherweise müssen Sie jeden 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 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.

Bewerten Sie den operativen Prozess, der für die Überprüfung von Access Approval-Anfragen erforderlich ist, um mögliche Verzögerungen bei der Behebung von Supportvorfällen 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 Betriebsaufwand, die mit Key Access Justifications verbunden sind, 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 Entwicklerarbeitsplätzen 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 in Betracht ziehen.

Zugriff auf die Google Cloud Console beschränken

MitGoogle Cloud können Sie den Zugriff auf die Google Cloud -Konsole 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, die Sie für den Nutzerzugriff auf webbasierte Anwendungen wie die Console im Rahmen einer größeren Zero-Trust-Bereitstellung als vertrauenswürdig einstufen.

Namenskonventionen

Wir empfehlen, eine standardisierte Namenskonvention für IhreGoogle Cloud -Ressourcen zu verwenden. 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 Organisation Google Cloud. Beispiel: bootstrap, common, production, nonproduction, development oder network.

Beispiel: fldr-production

Projekt-ID

prj-environmentcode-description-randomid

  • environmentcode ist eine Kurzform des Umgebungsfelds (wahlweise b, c, p, n, d oder net). Für Hostprojekte mit freigegebene VPC wird environmentcode der zugehörigen Umgebung verwendet. Für Projekte für Netzwerkressourcen, die umgebungsübergreifend freigegeben werden, z. B. 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. Dem Blueprint wird automatisch eine zufällige alphanumerische ID mit vier Zeichen hinzugefügt.

Beispiel: prj-c-logging-a1b2

VPC-Netzwerk

vpc-environmentcode-vpctype

  • environmentcode ist eine Kurzform des Umgebungsfelds (wahlweise b, c, p, n, d oder net).
  • vpctype ist wahlweise svpc, float oder peer.

Beispiel: vpc-p-svpc

Subnetz

sn-environmentcode-vpctype-region{-description}

  • environmentcode ist eine Kurzform des Umgebungsfelds (wahlweise b, c, p, n, d oder net).
  • vpctype ist wahlweise svpc, float oder peer.
  • region ist eine beliebige 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 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-svpc-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 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-svpc

Cloud Router

cr-environmentcode-vpctype-region{-description}

  • environmentcode ist eine Kurzform des Umgebungsfelds (wahlweise b, c, p, n, d oder net).
  • vpctype ist wahlweise svpc, float oder peer.
  • region ist eine beliebige 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 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-svpc-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-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 svpc, float oder peer.
  • region ist eine beliebige 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 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-svpc-useast1-cr1

Gruppe

grp-gcp-description@example.com

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

Beispiel: grp-gcp-billingadmin@example.com

Benutzerdefinierte Rolle

rl-description

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

Beispiel: rl-customcomputeadmin

Dienstkonto

sa-description@projectid.iam.gserviceaccount.com

Dabei gilt:

  • 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

Dabei gilt:

  • 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

Alternativen zu Standardempfehlungen

Die im Blueprint empfohlenen Best Practices funktionieren möglicherweise nicht für alle 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: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 umfasst Tochterunternehmen, die wahrscheinlich in Zukunft verkauft werden oder als völlig separate Einheiten geführt werden.
  • Sie möchten in einer Sandbox-Umgebung experimentieren, die keine Verbindung zu Ihrer bestehenden Organisation hat.

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

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 Einheiten oder Tochtergesellschaften
  • Ordner basierend auf dem Framework für Rechenschaftspflicht

Organisationsrichtlinien:Im Blueprint werden alle Einschränkungen für Organisationsrichtlinien auf Organisationsebene erzwungen.

Möglicherweise gelten für verschiedene Bereiche des Unternehmens unterschiedliche Sicherheitsrichtlinien oder Arbeitsweisen. In diesem Szenario erzwingen Sie Einschränkungen für Organisationsrichtlinien an 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:Im Blueprint wird Cloud Build zum Ausführen der Automatisierungspipeline verwendet.

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:Im Blueprint 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:Im Blueprint wird von einem lokalen Active Directory ausgegangen. Identitäten werden mithilfe von Google Cloud Directory Sync mit Cloud Identity verbunden.

Wenn Sie Google Workspace bereits verwenden, können Sie die Google-Identitäten nutzen, 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:Mit dem Blueprint werden regionale Ressourcen in zwei verschiedenen Google Cloud Regionen bereitgestellt, um die Entwicklung von Arbeitslasten unter Berücksichtigung von Hochverfügbarkeit und Notfallwiederherstellung zu ermöglichen.

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

Wenn Sie Einschränkungen hinsichtlich der Datenhoheit haben oder Ihre Verfügbarkeitsanforderungen in einer einzelnen Region erfüllt werden können, konfigurieren Sie möglicherweise nur eineGoogle 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ürGoogle Cloud.

Hybridnetzwerk: Der Blueprint verwendet Dedicated Interconnect über mehrere physische Standorte undGoogle 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 überhaupt kein Hybridnetzwerk.

VPC Service Controls-Perimeter:Im Blueprint wird ein einzelner Perimeter empfohlen, der alle Dienstprojekte für Ihre freigegebene VPC-Topologie umfasst.

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 für organisationsweite 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 zuständig 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 möglicherweise nur ein einzelnes Projekt für die Verwaltung des Schlüsselzugriffs 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 Logsenken:Im 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 annehmen, um sie vor der Projekterstellung zu prüfen und zu genehmigen. Alternativ kann das Team die Pull-Anfrage selbst als Reaktion auf ein Ticket erstellen.

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

SIEM-Exporte:Das Blueprint verwaltet alle Sicherheitsergebnisse in 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.

Nächste Schritte