Blueprints für Unternehmensgrundlagen

Last reviewed 2023-12-20 UTC

Sie können diese Seite drucken oder die Seite im PDF-Format mit der Druckfunktion Ihres Browsers speichern und die Option Speichern unter PDF-Option wählen. Kehren Sie für die Standardversion dieser Seite zum Blueprint für Unternehmensgrundlagen zurück.

Der Inhalt dieses Dokuments wurde im Dezember 2023 zum letzten Mal aktualisiert und stellt den Stand bei der Erstellung dar. Die Sicherheitsrichtlinien und -systeme von Google Cloud können sich aber in Zukunft ändern, da wir den Schutz unserer Kundinnen und Kunden kontinuierlich verbessern.

In diesem Dokument werden die Best Practices beschrieben, mit denen Sie ein grundlegendes Ressourcenset in Google Cloud bereitstellen können. Eine Cloud-Grundlage ist die Basis für Ressourcen, Konfigurationen und Funktionen, mit denen Unternehmen Google Cloud für ihre Geschäftsanforderungen nutzen können. Eine gut konzipierte Grundlage ermöglicht konsistente Governance, Sicherheitskontrollen, Skalierung, Sichtbarkeit und Zugriff auf freigegebene Dienste für alle Arbeitslasten in Ihrer Google Cloud-Umgebung. Nachdem Sie die in diesem Dokument beschriebenen Kontrollen und Governance bereitgestellt haben, können Sie Arbeitslasten in Google Cloud bereitstellen.

Der Blueprint für Unternehmensgrundlagen (ehemals Blueprint zu Sicherheitsgrundlagen) richtet sich an Architekten, Sicherheitsexperten und Plattformentwicklerteams, die für das Design einer für Unternehmen geeigneten Umgebung in Google Cloud verantwortlich sind. Dieser Blueprint enthält Folgendes:

• Ein GitHub-Repository "terraform-example-foundation", das die bereitstellbaren Terraform-Assets enthält.
• Eine Anleitung, die die Architektur, das Design und Kontrollen beschreibt, die Sie mit dem Blueprint implementieren (dieses Dokument).

Sie haben zwei Möglichkeiten zur Verwendung dieser Anleitung:

• Zum Erstellen einer vollständigen Grundlage basierend auf den Best Practices von Google. Sie können alle Empfehlungen aus diesem Leitfaden als Ausgangspunkt bereitstellen und dann die Umgebung an die spezifischen Anforderungen Ihres Unternehmens anpassen.
• So prüfen Sie eine vorhandene Umgebung in Google Cloud: Sie können bestimmte Komponenten Ihres Designs mit den von Google empfohlenen Best Practices vergleichen.

Unterstützte Anwendungsfälle

Der Blueprint zur Unternehmensgrundlage bietet eine grundlegende Ebene von Ressourcen und Konfigurationen, mit denen Sie alle Arten von Arbeitslasten in Google Cloud aktivieren können. Egal, ob Sie vorhandene Computing-Arbeitslasten zu Google Cloud migrieren, Container-Webanwendungen erstellen oder Big-Data- und ML-Arbeitslasten erstellen – mit dem Blueprint für Unternehmensgrundlagen können Sie Ihre Umgebung zur Unterstützung von Unternehmensarbeitslasten im großen Maßstab erstellen.

Nachdem Sie den Blueprint zur Unternehmensgrundlage bereitgestellt haben, können Sie Arbeitslasten direkt bereitstellen oder zusätzliche Blueprints bereitstellen, um komplexe Arbeitslasten zu unterstützen, die zusätzliche Funktionen erfordern.

Ein Defense-in-Depth-Sicherheitsmodell

Google Cloud-Dienste profitieren vom zugrunde liegenden Sicherheitsdesign der Infrastruktur von Google. Es liegt in Ihrer Verantwortung, Sicherheit in die Systeme zu integrieren, die Sie auf Google Cloud aufbauen. Mit dem Blueprint zur Unternehmensgrundlage können Sie ein Defense-in-Depth-Sicherheitsmodell für Ihre Google Cloud-Dienste und -Arbeitslasten implementieren.

Das folgende Diagramm zeigt ein Defense-in-Depth-Sicherheitsmodell für Ihre Google Cloud-Organisation, das Architekturkontrollen, Richtlinienkontrollen und Aufdeckungskontrollen kombiniert.

Das Diagramm beschreibt die folgenden Kontrollen:

• Richtlinienkontrollen sind programmatische Einschränkungen, die akzeptable Ressourcenkonfigurationen erzwingen und riskante Konfigurationen verhindern. Der Blueprint verwendet eine Kombination aus Richtlinienkontrollen, einschließlich der IaC-Validierung (Infrastructure as Code) in den Pipeline- und Organisationsrichtlinieneinschränkungen.
• Architekturkontrollen sind die Konfiguration von Google Cloud-Ressourcen wie Netzwerke und Ressourcenhierarchie. Die Blueprint-Architektur basiert auf Best Practices für die Sicherheit.
• Mit Aufdeckungskontrollen können Sie ungewöhnliches oder böswilliges Verhalten innerhalb der Organisation erkennen. Der Blueprint verwendet Plattformfeatures wie Security Command Center, lässt sich in Ihre vorhandenen Aufdeckungskontrollen und Workflows wie ein Security Operations Center (SOC) einbinden und bietet Funktionen zum Erzwingen benutzerdefinierter Aufdeckungskontrollen.

Wichtige Entscheidungen

In diesem Abschnitt werden die allgemeinen Architekturentscheidungen des Blueprints zusammengefasst.

Das Diagramm zeigt, wie Google Cloud-Dienste zu wichtigen Architekturentscheidungen beitragen:

• Cloud Build: Infrastrukturressourcen werden über ein GitOps-Modell verwaltet. Ein deklarativer IaC wird in Terraform geschrieben und in einem Versionsverwaltungssystem zur Überprüfung und Genehmigung verwaltet. Ressourcen werden mit Cloud Build als CI/CD-Automatisierungstool (Continuous Integration und Continuous Deployment) bereitgestellt. Die Pipeline erzwingt auch Richtlinien-als-Code-Prüfungen, um zu prüfen, ob Ressourcen vor der Bereitstellung die erwarteten Konfigurationen erfüllen.
• Cloud Identity: Nutzer und Gruppenmitgliedschaft werden von Ihrem vorhandenen Identitätsanbieter synchronisiert. Die Kontrollen für die Lebenszyklusverwaltung von Nutzerkonten und die Einmalanmeldung (SSO) basieren auf den vorhandenen Kontrollen und Prozessen Ihres Identitätsanbieters.
• Identity and Access Management, IAM: Zulassungsrichtlinien (früher IAM-Richtlinien) ermöglichen den Zugriff auf Ressourcen und werden basierend auf der Jobfunktion auf Gruppen angewendet. Nutzer werden den entsprechenden Gruppen hinzugefügt, um nur Lesezugriff auf Grundlagenressourcen zu erhalten. Alle Änderungen an Grundlagenressourcen werden über die CI/CD-Pipeline bereitgestellt, die privilegierte Dienstkontoidentitäten verwendet.
• Resource Manager: Alle Ressourcen werden unter einer einzelnen Organisation verwaltet, mit einer Ressourcenhierarchie von Ordnern, die Projekte nach Umgebungen organisieren. Projekte sind mit Metadaten für Governance verknüpft, einschließlich der Kostenzuordnung.
• Netzwerk: Netzwerktopologien verwenden eine freigegebene VPC, um Netzwerkressourcen für Arbeitslasten in mehreren Regionen und Zonen bereitzustellen, nach Umgebung getrennt und zentral verwaltet. Alle Netzwerkpfade zwischen lokalen Hosts, Google Cloud-Ressourcen in den VPC-Netzwerken und Google Cloud-Diensten sind privat. Standardmäßig ist kein ausgehender Traffic vom oder eingehender Traffic aus dem öffentlichen Internet zulässig.
• Cloud Logging: Aggregierte Logsenken sind so konfiguriert, dass Logs, die für Sicherheit und Auditing relevant sind, zur langfristigen Aufbewahrung, Analyse und zum Export in externe Systeme in einem zentralen Projekt erfasst werden.
• Cloud Monitoring: Monitoring-Scoping-Projekte sind so konfiguriert, dass die Messwerte zur Anwendungsleistung für mehrere Projekte an einem Ort angezeigt werden.
• Organisationsrichtliniendienst: Einschränkungen für Organisationsrichtlinien sind so konfiguriert, dass verschiedene risikoreiche Konfigurationen verhindert werden.
• Secret Manager: Zentralisierte Projekte werden für ein Team erstellt, das für die Verwaltung und Prüfung der Verwendung vertraulicher Anwendungs-Secrets zuständig ist, um die Compliance-Anforderungen zu erfüllen.
• Cloud Key Management Service (Cloud KMS): Zentralisierte Projekte werden für ein Team erstellt, das für die Verwaltung und Prüfung von Verschlüsselungsschlüsseln zuständig ist, um die Compliance-Anforderungen zu erfüllen.
• Security Command Center: Bedrohungserkennungs- und Monitoring-Funktionen werden mit einer Kombination aus integrierten Sicherheitskontrollen aus dem Security Command Center und benutzerdefinierten Lösungen bereitgestellt, mit denen Sie Sicherheitsereignisse erkennen und darauf reagieren können.

Alternativen zu diesen Schlüsselentscheidungen finden Sie unter Alternativen.

Nächste Schritte

• Authentifizierung und Autorisierung (nächstes Dokument in dieser Reihe).

Authentifizierung und Autorisierung

In diesem Abschnitt wird erläutert, wie Sie mit Cloud Identity die Identitäten verwalten, die Ihre Mitarbeiter für den Zugriff auf Google Cloud-Dienste verwenden.

Externer Identitätsanbieter als „Source of Truth“

Wir empfehlen, Ihr Cloud Identity-Konto mit Ihrem vorhandenen Identitätsanbieter zu föderieren. Dank Föderation können Sie sicherstellen, dass Ihre vorhandenen Prozesse zur Kontoverwaltung für Google Cloud und andere Google-Dienste gelten.

Wenn Sie noch keinen Identitätsanbieter haben, können Sie Nutzerkonten direkt in Cloud Identity erstellen.

Hinweis: Wenn Sie Google Workspace bereits verwenden, verwendet Cloud Identity dieselbe Konsole, dieselben Verwaltungsfunktionen und Nutzerkonten wie Ihr Google Workspace-Konto.

Das folgende Diagramm zeigt eine allgemeine Ansicht der Identitätsföderation und der Einmalanmeldung (SSO). Als Beispiel für den Identitätsanbieter wird Microsoft Active Directory in der lokalen Umgebung verwendet.

In diesem Diagramm werden die folgenden Best Practices beschrieben:

• Nutzeridentitäten werden in einer Active Directory-Domain verwaltet, die sich in der lokalen Umgebung befindet und mit Cloud Identity föderiert ist. Active Directory verwendet Google Cloud Directory Sync, um Identitäten in Cloud Identity bereitzustellen.
• Nutzer, die versuchen, sich bei Google-Diensten anzumelden, werden für die Einmalanmeldung (SSO) mit SAML zum externen Identitätsanbieter weitergeleitet. Dabei werden ihre vorhandenen Anmeldedaten zur Authentifizierung verwendet. Es werden keine Passwörter mit Cloud Identity synchronisiert.

Die folgende Tabelle enthält Links zur Einrichtungsanleitung für Identitätsanbieter.

Identitätsanbieter	Anleitung
Active Directory	Active Directory-Nutzerkonten bereitstellen Active Directory-Einmalanmeldung (SSO)
Microsoft Entra ID (früher Azure AD)	Google Cloud mit Microsoft Entra ID föderieren
Andere externe Identitätsanbieter (z. B. Ping oder Okta)	Ping Identity-Lösungen in Google Identity Services einbinden Okta mit Google Cloud-Anbietern verwenden Best Practices für die Verbindung von Google Cloud mit einem externen Identitätsanbieter

Wir empfehlen dringend, die Multi-Faktor-Authentifizierung bei Ihrem Identitätsanbieter zu erzwingen. Dies erfolgt über einen Phishing-resistenten Mechanismus, wie z. B. einen Titan-Sicherheitsschlüssel.

Die empfohlenen Einstellungen für Cloud Identity werden nicht über den Terraform-Code in diesem Blueprint automatisiert. Die empfohlenen Sicherheitseinstellungen, die Sie zusätzlich zur Bereitstellung des Terraform-Codes konfigurieren müssen, finden Sie unter Verwaltungsfunktionen für Cloud Identity.

Gruppen für die Zugriffssteuerung

Ein Hauptkonto ist eine Identität, der Zugriff auf eine Ressource gewährt werden kann. Hauptkonten umfassen Google-Konten für Nutzer, Google-Gruppen, Google Workspace-Konten, Cloud Identity-Domains und Dienstkonten. Mit einigen Diensten können Sie auch allen Nutzern, die sich mit einem Google-Konto authentifizieren, oder allen Nutzern im Internet Zugriff gewähren. Damit ein Hauptkonto mit Google Cloud-Diensten interagieren kann, müssen Sie ihm Rollen in Identity and Access Management (IAM) zuweisen.

Zum Verwalten einer großen Anzahl von IAM-Rollen empfehlen wir, dass Sie Nutzer anhand ihrer Jobfunktionen und Zugriffsanforderungen Gruppen zuweisen und dann diesen Gruppen IAM-Rollen zuweisen. Sie sollten Nutzer mithilfe der Prozesse in Ihrem vorhandenen Identitätsanbieter zur Gruppenerstellung und -mitgliedschaft hinzufügen.

Wir empfehlen, den einzelnen Nutzern keine IAM-Rollen zuzuweisen, da einzelne Zuweisungen die Komplexität der Verwaltung und Prüfung von Rollen erhöhen können.

Der Blueprint konfiguriert Gruppen und Rollen für den Lesezugriff auf Grundlagenressourcen. Wir empfehlen, alle Ressourcen im Blueprint über die Grundlagenpipeline bereitzustellen und Nutzern keine Rollen in Gruppen zuzuweisen, um Grundlagenressourcen außerhalb der Pipeline zu ändern.

Die folgende Tabelle zeigt die Gruppen, die vom Blueprint zum Aufrufen von Grundlagenressourcen konfiguriert werden.

Name	Beschreibung	Rollen	Geltungsbereich
[e-mail]	Administratoren mit umfangreichen Berechtigungen, die IAM-Rollen auf Organisationsebene zuweisen können. Sie können auf jede andere Rolle zugreifen. Diese Berechtigung wird für die tägliche Verwendung nicht empfohlen.	Administrator der Organisation	Organisation
[e-mail]	Administratoren mit umfangreichen Berechtigungen, die das Cloud-Rechnungskonto ändern können. Diese Berechtigung wird für die tägliche Nutzung nicht empfohlen.	Rechnungskontoadministrator	Organisation
[e-mail]	Das Team, das für die Anzeige und Analyse der Ausgaben in allen Projekten verantwortlich ist.	Rechnungskonto-Betrachter	Organisation
		BigQuery-Nutzer	Abrechnungsprojekt
[e-mail]	Das Team, das für die Prüfung sicherheitsbezogener Logs verantwortlich ist.	Loganzeige BigQuery-Nutzer	Logging-Projekt
[e-mail]	Das Team, das für das Monitoring der Leistungsmesswerte von Anwendungen verantwortlich ist.	Monitoring-Betrachter	Monitoring-Projekt
[e-mail]	Das Team, das für die Prüfung der Cloud-Sicherheit verantwortlich ist.	Sicherheitsprüfer	Organisation
[e-mail]	Das Team, das für die Anzeige und Verwaltung der Netzwerkkonfigurationen zuständig ist.	Compute-Netzwerkbetrachter	Organisation
[e-mail]	Das Team, das für die Konfiguration von Security Command Center zuständig ist.	Sicherheitscenter-Administratorbearbeiter	Organisation
[e-mail]	Das Team, das für die Verwaltung, Speicherung und Prüfung von Anmeldedaten und anderen Secrets zuständig ist, die von Anwendungen verwendet werden.	Secret Manager-Administrator	Secrets-Projekte
[e-mail]	Das Team, das für die Erzwingung der Verwaltung des Verschlüsselungsschlüssels verantwortlich ist, um Compliance-Anforderungen zu erfüllen.	Cloud KMS-Betrachter	KMS-Projekte

Wenn Sie Ihre eigenen Arbeitslasten auf Basis der Grundlagen erstellen, erstellen Sie zusätzliche Gruppen und weisen IAM-Rollen zu, die auf den Zugriffsanforderungen für jede Arbeitslast basieren.

Es wird dringend empfohlen, einfache Rollen wie Inhaber, Bearbeiter oder Betrachter zu vermeiden und stattdessen vordefinierte Rollen zu verwenden. Einfache Rollen sind zu weit gefasst und stellen ein potenzielles Sicherheitsrisiko dar. Die Rollen "Inhaber" und "Bearbeiter" können zu einer Rechteausweitung und seitlichen Bewegungen führen und die Rolle "Betrachter" enthält Zugriff zum Lesen aller Daten. Best Practices für IAM-Rollen finden Sie unter IAM sicher verwenden.

Super Admin-Konten

Cloud Identity-Nutzer mit dem Super Admin-Konto umgehen die SSO-Einstellungen der Organisation und authentifizieren sich direkt bei Cloud Identity. Diese Ausnahme ist bewusst so konzipiert, dass der Super Admin weiterhin auf die Cloud Identity-Konsole zugreifen kann, wenn eine SSO-Fehlkonfiguration oder ein Ausfall auftritt. Dies bedeutet jedoch, dass Sie zusätzlichen Schutz für Super Admin-Konten berücksichtigen müssen.

Zum Schutz Ihrer Super Admin-Konten empfehlen wir, dass Sie in Cloud Identity immer die Bestätigung in zwei Schritten mit Sicherheitsschlüsseln erzwingen. Weitere Informationen finden Sie im Hilfeartikel Best Practices für die Sicherheit von Administratorkonten.

Probleme mit Privatnutzerkonten

Wenn Sie Cloud Identity oder Google Workspace vor der Einführung von Google Cloud nicht verwendet haben, verwenden die Mitarbeiter Ihrer Organisation möglicherweise bereits Privatnutzerkonten, die mit ihren Unternehmens-E-Mail-Identitäten verknüpft sind, um auf andere Google-Dienste wie die Google Marketing Platform oder YouTube zuzugreifen. Privatnutzerkonten sind Konten, die den Personen, die sie erstellt haben, vollständig gehören und von diesen verwaltet werden. Da diese Konten nicht von Ihrer Organisation kontrolliert werden und sowohl private als auch Unternehmensdaten enthalten können, müssen Sie entscheiden, wie Sie diese Konten mit anderen Unternehmenskonten konsolidieren.

Wir empfehlen Ihnen, im Rahmen der Einrichtung von Google Cloud vorhandene Privatnutzerkonten zu konsolidieren. Wenn Sie Google Workspace nicht bereits für alle Ihre Nutzerkonten verwenden, empfehlen wir, das Erstellen neuer Privatnutzerkonten zu blockieren.

Verwaltungsfunktionen für Cloud Identity

Cloud Identity bietet verschiedene Verwaltungsfunktionen, die nicht durch Terraform-Code im Blueprint automatisiert werden. Wir empfehlen Ihnen, jede dieser Best Practice-Sicherheitskontrollen früh beim Aufbau Ihrer Grundlagen zu erzwingen.

Funktion	Beschreibung
Bestätigung in zwei Schritten implementieren	Nutzerkonten können durch Phishing, Social Engineering, Password Spraying oder verschiedene andere Bedrohungen manipuliert werden. Die Bestätigung in zwei Schritten trägt dazu bei, diese Bedrohungen abzuwehren. Wir empfehlen, die Bestätigung in zwei Schritten für alle Nutzerkonten in Ihrer Organisation mit einem Phishing-resistenten Mechanismus wie Titan-Sicherheitsschlüsseln oder anderen Schlüsseln zu erzwingen, die auf den Phishing-resistenten FIDO-U2F-Standards (CTAP1) basieren.
Sitzungsdauer für Google Cloud-Dienste festlegen	Persistente OAuth-Tokens auf Entwickler-Workstations können ein Sicherheitsrisiko darstellen, wenn sie offengelegt werden. Wir empfehlen, eine Richtlinie zur erneuten Authentifizierung so festzulegen, dass eine Authentifizierung alle 16 Stunden mithilfe eines Sicherheitsschlüssels erforderlich ist.
Sitzungsdauer für Google-Dienste festlegen	(Nur für Google Workspace-Kunden) Persistente Websitzungen in anderen Google-Diensten können ein Sicherheitsrisiko darstellen, wenn sie offengelegt werden. Wir empfehlen, eine maximale Websitzungsdauer zu erzwingen und diese an die Kontrollen für die Sitzungsdauer bei Ihrem SSO-Anbieter anzupassen.
Daten aus Cloud Identity für Google Cloud-Dienste freigeben	Audit-Logs zur Administratoraktivität von Google Workspace oder Cloud Identity werden normalerweise in der Admin-Konsole verwaltet und angezeigt, separat von Ihren Logs in der Google Cloud-Umgebung. Diese Logs enthalten Informationen, die für Ihre Google Cloud-Umgebung relevant sind, z. B. Nutzeranmeldungsereignisse. Wir empfehlen, Cloud Identity-Audit-Logs für Ihre Google Cloud-Umgebung freizugeben, damit Logs aus allen Quellen zentral verwaltet werden können.
Identitätsbestätigung nach der Einmalanmeldung einrichten	Beim Blueprint wird davon ausgegangen, dass Sie die SSO mit Ihrem externen Identitätsanbieter einrichten. Wir empfehlen Ihnen, eine zusätzliche Kontrollebene zu aktivieren, die auf der Risikoanalyse von Google für die Anmeldung basiert. Nachdem Sie diese Einstellung angewendet haben, können Nutzer bei der Anmeldung zusätzliche risikoabhängige Identitätsbestätigungen sehen, wenn Google der Meinung ist, dass eine Nutzeranmeldung verdächtig ist.
Probleme mit Privatnutzerkonten beheben	Nutzer mit einer gültigen E-Mail-Adresse in Ihrer Domain, aber ohne Google-Konto, können sich für nicht verwaltete Privatnutzerkonten registrieren. Diese Konten können Unternehmensdaten enthalten, werden aber nicht von Ihren Prozessen zur Verwaltung des Kontolebenszyklus gesteuert. Wir empfehlen Ihnen, sicherzustellen, dass alle Nutzerkonten verwaltete Konten sind.
Kontowiederherstellung für Super Admin-Konten deaktivieren	Die Selbstwiederherstellung für Super Admin-Konten ist für alle Neukunden standardmäßig deaktiviert. Für bestehende Kunden ist diese Einstellung möglicherweise aktiviert. Durch das Deaktivieren dieser Einstellung verringern Sie das Risiko, dass ein manipuliertes Telefon, ein manipuliertes E-Mail-Konto oder ein Social Engineering-Angriff Angreifern in Ihrer Umgebung Super Admin-Berechtigungen gewähren kann. Planen Sie einen internen Prozess, damit ein Super Admin einen anderen Super Admin in Ihrer Organisation kontaktieren kann, wenn er keinen Zugriff mehr auf sein Konto hat. Sorgen Sie außerdem dafür, dass alle Super Admins mit dem Prozess für die supportgestützte Wiederherstellung vertraut sind.
Passwortanforderungen für Nutzer durchsetzen und beobachten	In den meisten Fällen werden Nutzerpasswörter über Ihren externen Identitätsanbieter verwaltet. Super Admin-Konten umgehen die SSO jedoch und müssen bei der Anmeldung in Cloud Identity ein Passwort verwenden. Deaktivieren Sie die Wiederverwendung von Passwörtern und überwachen Sie die Passwortstärke für alle Nutzer, die ein Passwort für die Anmeldung in Cloud Identity verwenden. Dies gilt insbesondere für Super Admin-Konten.
Organisationsweite Richtlinien für die Verwendung von Gruppen festlegen	Standardmäßig können externe Nutzerkonten den Gruppen in Cloud Identity hinzugefügt werden. Wir empfehlen, Freigabeeinstellungen so zu konfigurieren, dass Gruppeninhaber keine externen Mitglieder hinzufügen können. Beachten Sie, dass diese Einschränkung nicht für das Super Admin-Konto oder andere delegierte Administratoren mit Administratorberechtigungen für Google Groups gilt. Da die Föderation von Ihrem Identitätsanbieter mit Administratorberechtigungen ausgeführt wird, gelten die Gruppenfreigabeeinstellungen nicht für diese Gruppensynchronisierung. Wir empfehlen Ihnen, die Steuerelemente beim Identitätsanbieter und im Synchronisierungsmechanismus zu prüfen, um sicherzustellen, dass Mitglieder, die nicht zur Domain gehören, nicht zu Gruppen hinzugefügt werden, oder Gruppeneinschränkungen anzuwenden.

Nächste Schritte

• Mehr über die Organisationsstruktur erfahren (nächstes Dokument in dieser Reihe).

Organisationsstruktur

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.

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 visuell lesbare 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)

Netzwerk

Netzwerke sind erforderlich, damit Ressourcen innerhalb Ihrer Google Cloud-Organisation und zwischen Ihrer Cloud-Umgebung und der lokalen Umgebung kommunizieren können. In diesem Abschnitt wird die Struktur des Blueprints für VPC-Netzwerke, IP-Adressbereich, DNS, Firewallrichtlinien und die Konnektivität zur lokalen Umgebung beschrieben.

Netzwerktopologie

Das Blueprint-Repository bietet die folgenden Optionen für Ihre Netzwerktopologie:

• Verwenden Sie für jede Umgebung separate freigegebene VPC-Netzwerke, ohne dass der Netzwerktraffic direkt zwischen Umgebungen zugelassen wird.
• Verwenden Sie ein Hub-and-Spoke-Modell, das ein Hub-Netzwerk hinzufügt, um jede Umgebung in Google Cloud zu verbinden, wobei der Netzwerkverkehr zwischen Umgebungen durch eine virtuelle Netzwerk-Appliance (NVA) gesteuert wird.

Wählen Sie die dual freigegebene VPC-Netzwerktopologie aus, wenn Sie keine direkte Netzwerkverbindung zwischen Umgebungen wünschen. Wählen Sie die Hub-and-Spoke-Netzwerktopologie aus, wenn Sie Netzwerkverbindungen zwischen Umgebungen zulassen möchten, die von einer NVA gefiltert werden, z. B. wenn Sie vorhandene Tools verwenden, die einen direkten Netzwerkpfad zu jedem Server in Ihrer Umgebung erfordern.

Beide Topologien verwenden eine freigegebene VPC als Hauptnetzwerknetzwerkkonstrukt, da eine freigegebene VPC eine klare Trennung der Zuständigkeiten ermöglicht. Netzwerkadministratoren verwalten Netzwerkressourcen in einem zentralisierten Hostprojekt und Arbeitslastteams stellen ihre eigenen Anwendungsressourcen bereit und nutzen die Netzwerkressourcen in Dienstprojekten, die an das Hostprojekt angehängt sind.

Beide Topologien enthalten eine Basisversion und eine eingeschränkte Version jedes VPC-Netzwerks. Das Basis-VPC-Netzwerk wird für Ressourcen verwendet, die nicht vertrauliche Daten enthalten, und das eingeschränkte VPC-Netzwerk wird für Ressourcen mit sensiblen Daten verwendet, die VPC Service Controls erfordern. Weitere Informationen zur Implementierung von VPC Service Controls finden Sie unter Ressourcen mit VPC Service Controls schützen.

Duale freigegebene VPC-Netzwerktopologie

Wenn Sie die Netzwerkisolation zwischen Ihren Entwicklungs-, Nicht-Produktions- und Produktionsnetzwerken in Google Cloud benötigen, empfehlen wir die duale freigegebene VPC-Netzwerktopologie. Diese Topologie verwendet für jede Umgebung separate freigegebene VPC-Netzwerke, wobei jede Umgebung zusätzlich zwischen einem grundlegenden freigegebenen VPC-Netzwerk und einem eingeschränkten freigegebenen VPC-Netzwerk aufgeteilt wird.

Das folgende Diagramm zeigt die Dual-VPC-Netzwerktopologie.

Im Diagramm werden die wichtigsten Konzepte der dualen freigegebenen Topologie für freigegebene VPC beschrieben:

• Jede Umgebung (Produktion, Nicht-Produktion und Entwicklung) hat ein freigegebenes VPC-Netzwerk für das Basisnetzwerk und ein freigegebenes VPC-Netzwerk für das eingeschränkte Netzwerk. Dieses Diagramm zeigt nur die Produktionsumgebung, aber für jede Umgebung wird dasselbe Muster wiederholt.
• Jedes freigegebene VPC-Netzwerk hat zwei Subnetze, wobei sich jedes Subnetz in einer anderen Region befindet.
• Die Verbindung mit lokalen Ressourcen wird über vier VLAN-Anhänge für die Dedicated Interconnect-Instanz für jedes freigegebene VPC-Netzwerk ermöglicht, wobei vier Cloud Router-Dienste verwendet werden (zwei in jeder Region für Redundanz). Weitere Informationen finden Sie unter Hybridkonnektivität zwischen der lokalen Umgebung und Google Cloud.

Diese Topologie lässt zu, dass der Netzwerkverkehr direkt zwischen Umgebungen fließt. Wenn der Netzwerkverkehr direkt zwischen Umgebungen fließen muss, müssen Sie zusätzliche Schritte ausführen, um diesen Netzwerkpfad zuzulassen. Beispiel: Sie können Private Service Connect-Endpunkte konfigurieren, um einen Dienst von einem VPC-Netzwerk zu einem anderen VPC-Netzwerk freizugeben. Alternativ können Sie Ihr lokales Netzwerk so konfigurieren, dass der Traffic von einer Google Cloud-Umgebung zur lokalen Umgebung und dann zu einer anderen Google Cloud-Umgebung geleitet wird.

Hub-and-Spoke-Netzwerktopologie

Wenn Sie Ressourcen in Google Cloud bereitstellen, die einen direkten Netzwerkpfad zu Ressourcen in mehreren Umgebungen erfordern, empfehlen wir die Hub-and-Spoke-Netzwerktopologie.

Die Hub-and-Spoke-Topologie verwendet einige der Konzepte, die Teil der dualen freigegebenen VPC-Topologie sind. Die Topologie wird jedoch geändert, um ein Hub-Netzwerk hinzuzufügen. Das folgende Diagramm zeigt die Hub-and-Spoke-Topologie.

Im Diagramm werden die folgenden Schlüsselkonzepte der Hub-and-Spoke-Netzwerktopologie beschrieben:

• Dieses Modell fügt ein Hub-Netzwerk hinzu. Jedes der Entwicklungs-, Nicht-Produktions- und Produktionsnetzwerke (Spokes) ist über VPC-Netzwerk-Peering mit dem Hub-Netzwerk verbunden. Wenn Sie dagegen das Kontingentlimit überschreiten, können Sie stattdessen ein HA VPN-Gateway verwenden.
• Die Verbindung zu lokalen Netzwerken ist nur über das Hub-Netzwerk zulässig. Alle Spoke-Netzwerke können mit freigegebenen Ressourcen im Hub-Netzwerk kommunizieren und diesen Pfad verwenden, um eine Verbindung zu lokalen Netzwerken herzustellen.
• Die Hub-Netzwerke enthalten eine NVA für jede Region, die redundant hinter internen Netzwerk-Load-Balancer-Instanzen bereitgestellt wird. Diese NVA dient als Gateway zum Zulassen oder Ablehnen der Kommunikation zwischen Spoke-Netzwerken.
• Das Hub-Netzwerk hostet auch Tools, für die eine Verbindung zu allen anderen Netzwerken erforderlich ist. Sie können beispielsweise Tools auf VM-Instanzen für die Konfigurationsverwaltung in der gemeinsamen Umgebung bereitstellen.
• Das Hub-and-Spoke-Modell wird für eine Basisversion und eine eingeschränkte Version jedes Netzwerks dupliziert.

Zum Aktivieren des Spoke-Spoke-Traffics stellt der Blueprint NVAs im freigegebenen Hub-VPC-Netzwerk bereit, die als Gateways zwischen Netzwerken dienen. Routen werden von Hub zu Spoke-VPC-Netzwerken über benutzerdefinierten Routenaustausch ausgetauscht. In diesem Szenario muss die Verbindung zwischen Spokes über die NVA weitergeleitet werden, da VPC-Netzwerk-Peering nicht transitiv ist, und Spoke-VPC-Netzwerke daher keine Daten direkt miteinander austauschen können. Sie müssen die virtuellen Appliances so konfigurieren, dass der Traffic zwischen den Spokes selektiv zugelassen wird.

Weitere Informationen zur Verwendung von NVAs zur Steuerung des Traffics zwischen Spokes finden Sie unter Zentralisierte Netzwerk-Appliances in Google Cloud.

Muster für die Projektbereitstellung

Wenn Sie neue Projekte für Arbeitslasten erstellen, müssen Sie entscheiden, wie die Ressourcen in diesem Projekt eine Verbindung zu Ihrem vorhandenen Netzwerk herstellen. In der folgenden Tabelle werden die Muster zum Bereitstellen von Projekten beschrieben, die im Blueprint verwendet werden.

Muster	Beschreibung	Nutzungsbeispiel
Freigegebene Basisprojekte	Diese Projekte werden als Dienstprojekte für ein Basisprojekt mit freigegebener VPC konfiguriert. Verwenden Sie dieses Muster, wenn Ressourcen in Ihrem Projekt folgende Kriterien haben: Fordern Sie eine Netzwerkverbindung zur lokalen Umgebung oder zu den Ressourcen in derselben freigegebenen VPC-Topologie an. Fordern Sie einen Netzwerkpfad zu den Google-Diensten an, die sich auf der privaten virtuellen IP-Adresse befinden. Fordern Sie keine VPC Service Controls an.	example_base_shared_vpc_project.tf
Freigegebene eingeschränkte Projekte	Diese Projekte werden als Dienstprojekte für ein eingeschränktes Hostprojekt in einer freigegebenen VPC konfiguriert. Verwenden Sie dieses Muster, wenn Ressourcen in Ihrem Projekt folgende Kriterien haben: Fordern Sie eine Netzwerkverbindung zur lokalen Umgebung oder zu den Ressourcen in derselben freigegebenen VPC-Topologie an. Fordern Sie einen Netzwerkpfad zu den Google-Diensten an, die auf der eingeschränkten virtuellen IP-Adresse enthalten sind. VPC Service Controls erforderlich	example_restricted_shared_vpc_project.tf
Floating-Projekte	Floating-Projekte sind nicht mit anderen VPC-Netzwerken in Ihrer Topologie verbunden. Verwenden Sie dieses Muster, wenn Ressourcen in Ihrem Projekt folgende Kriterien haben: Sie benötigen keine vollständige Mesh-Verbindung zu einer lokalen Umgebung oder zu Ressourcen in der freigegebenen VPC-Topologie. Sie benötigen kein VPC-Netzwerk oder Sie möchten das VPC-Netzwerk für dieses Projekt unabhängig von Ihrer Haupt-VPC-Netzwerktopologie verwalten, z. B. wenn Sie einen IP-Adressbereich verwenden möchten, der mit den bereits verwendeten Bereichen in Konflikt steht. Es kann vorkommen, dass Sie das VPC-Netzwerk eines Floating-Projekts von der Haupt-VPC-Netzwerktopologie trennen und gleichzeitig eine begrenzte Anzahl von Endpunkten zwischen Netzwerken bereitstellen möchten. Veröffentlichen Sie in diesem Fall Dienste mit Private Service Connect, um den Netzwerkzugriff auf einen einzelnen Endpunkt über VPC-Netzwerke hinweg zu teilen, ohne das gesamte Netzwerk freizugeben.	example_floating_project.tf
Peering-Projekte	Peering-Projekte erstellen ihre eigenen VPC-Netzwerke und verbinden sich mit anderen VPC-Netzwerken in Ihrer Topologie. Verwenden Sie dieses Muster, wenn Ressourcen in Ihrem Projekt folgende Kriterien haben: Erzwingen Sie die Netzwerkverbindung im direkt verbundenen VPC-Netzwerk, aber keine transitive Konnektivität zu einer lokalen Umgebung oder anderen VPC-Netzwerken. Das VPC-Netzwerk für dieses Projekt muss unabhängig von Ihrer Hauptnetzwerktopologie verwaltet werden. Wenn Sie Peering-Projekte erstellen, sind Sie dafür verantwortlich, nicht in Konflikt stehende IP-Adressbereiche zuzuweisen und das Kontingent für Peering-Gruppen zu planen.	example_peering_project.tf

Zuweisung von IP-Adressen

In diesem Abschnitt wird erläutert, wie die Blueprint-Architektur IP-Adressbereiche zuweist. Möglicherweise müssen Sie die spezifischen IP-Adressbereiche ändern, die auf der Verfügbarkeit der IP-Adresse in der vorhandenen Hybridumgebung basieren.

Die folgende Tabelle enthält eine Aufschlüsselung des IP-Adressbereichs, der dem Blueprint zugewiesen ist. Die Hub-Umgebung gilt nur für die Hub-and-Spoke-Topologie.

Zweck	VPC-Typ	Region	Hub-Umgebung	Entwicklungsumgebung	Nicht-Produktionsumgebung	Produktionsumgebung
Primäre Subnetzbereiche	Basis	Region 1	10.0.0.0/18	10.0.64.0/18	10.0.128.0/18	10.0.192.0/18
		Region 2	10.1.0.0/18	10.1.64.0/18	10.1.128.0/18	10.1.192.0/18
		Nicht zugewiesen	10.{2-7}.0.0/18	10.{2-7}.64.0/18	10.{2-7}.128.0/18	10.{2-7}.192.0/18
	Eingeschränkt	Region 1	10.8.0.0/18	10.8.64.0/18	10.8.128.0/18	10.8.192.0/18
		Region 2	10.9.0.0/18	10.9.64.0/18	10.9.128.0/18	10.9.192.0/18
		Nicht zugewiesen	10.{10-15}.0.0/18	10.{10-15}.64.0/18	10.{10-15}.128.0/18	10.{10-15}.192.0/18
Zugriff auf private Dienste	Basis	Global	10.16.0.0/21	10.16.8.0/21	10.16.16.0/21	10.16.24.0/21
	Eingeschränkt	Global	10.16.32.0/21	10.16.40.0/21	10.16.48.0/21	10.16.56.0/21
Private Service Connect-Endpunkte	Basis	Global	10.17.0.1/32	10.17.0.2/32	10.17.0.3/32	10.17.0.4/32
	Eingeschränkt	Global	10.17.0.5/32	10.17.0.6/32	10.17.0.7/32	10.17.0.8/32
Proxy-only-subnets	Basis	Region 1	10.18.0.0/23	10.18.2.0/23	10.18.4.0/23	10.18.6.0/23
		Region 2	10.19.0.0/23	10.19.2.0/23	10.19.4.0/23	10.19.6.0/23
		Nicht zugewiesen	10.{20-25}.0.0/23	10.{20-25}.2.0/23	10.{20-25}.4.0/23	10.{20-25}.6.0/23
	Eingeschränkt	Region 1	10.26.0.0/23	10.26.2.0/23	10.26.4.0/23	10.26.6.0/23
		Region 2	10.27.0.0/23	10.27.2.0/23	10.27.4.0/23	10.27.6.0/23
		Nicht zugewiesen	10.{28-33}.0.0/23	10.{28-33}.2.0/23	10.{28-33}.4.0/23	10.{28-33}.6.0/23
Sekundäre Subnetzbereiche	Basis	Region 1	100.64.0.0/18	100.64.64.0/18	100.64.128.0/18	100.64.192.0/18
		Region 2	100.65.0.0/18	100.65.64.0/18	100.65.128.0/18	100.65.192.0/18
		Nicht zugewiesen	100.{66-71}.0.0/18	100.{66-71}.64.0/18	100.{66-71}.128.0/18	100.{66-71}.192.0/18
	Eingeschränkt	Region 1	100.72.0.0/18	100.72.64.0/18	100.72.128.0/18	100.72.192.0/18
		Region 2	100.73.0.0/18	100.73.64.0/18	100.73.128.0/18	100.73.192.0/18
		Nicht zugewiesen	100.{74-79}.0.0/18	100.{74-79}.64.0/18	100.{74-79}.128.0/18	100.{74-79}.192.0/18

Die obige Tabelle veranschaulicht diese Konzepte zum Zuweisen von IP-Adressbereichen:

• Die Zuweisung von IP-Adressen ist in Bereiche für jede Kombination aus freigegebener Basis-VPC, eingeschränkter freigegebener VPC, Region und Umgebung unterteilt.
• Einige Ressourcen sind global und erfordern keine Untergruppen für jede Region.
• Bei regionalen Ressourcen wird der Blueprint standardmäßig in zwei Regionen bereitgestellt. Darüber hinaus gibt es nicht verwendete IP-Adressbereiche, sodass Sie in sechs zusätzliche Regionen erweitern können.
• Das Hub-Netzwerk wird nur in der Hub-and-Spoke-Netzwerktopologie verwendet, während die Entwicklungs-, Nicht-Produktions- und Produktionsumgebungen in beiden Netzwerktopologien verwendet werden.

In der folgenden Tabelle wird erläutert, wie die einzelnen Arten von IP-Adressbereichen verwendet werden.

Zweck	Beschreibung
Primäre Subnetzbereiche	Ressourcen, die Sie in Ihrem VPC-Netzwerk bereitstellen, z. B. VM-Instanzen, verwenden interne IP-Adressen aus diesen Bereichen.
Zugriff auf private Dienste	Bei einigen Google Cloud-Diensten wie Cloud SQL müssen Sie für den Zugriff auf private Dienste einen Subnetzbereich zuweisen. Der Blueprint reserviert global für jedes freigegebene VPC-Netzwerk einen /21-Bereich, um IP-Adressen für Dienste zuzuweisen, die Zugriff auf private Dienste erfordern. Wenn Sie einen Dienst erstellen, der vom Zugriff auf private Dienste abhängt, weisen Sie ein regionales /24-Subnetz aus dem reservierten /21-Bereich zu.
Private Service Connect	Der Blueprint stellt jedes VPC-Netzwerk mit einem Private Service Connect-Endpunkt für die Kommunikation mit Google Cloud APIs bereit. Mit diesem Endpunkt können Ihre Ressourcen im VPC-Netzwerk Google Cloud APIs erreichen, ohne ausgehenden Traffic zum Internet oder öffentlich beworbenen Internetbereichen zu benötigen.
Proxybasierte Load-Balancer	Bei einigen Arten von Anwendungs-Load-Balancern müssen Nur-Proxy-Subnetze vorab zugewiesen werden. Auch wenn der Blueprint keine Anwendungs-Load-Balancer bereitstellt, die diesen Bereich erfordern, hilft die Vorabzuweisung von Bereichen, Probleme zu vermeiden, wenn Arbeitslasten einen neuen Subnetzbereich anfordern müssen, um bestimmte Load-Balancer-Ressourcen zu aktivieren.
Sekundäre Subnetzbereiche	Einige Anwendungsfälle, z. B. containerbasierte Arbeitslasten, erfordern sekundäre Bereiche. Der Blueprint weist Bereiche aus dem RFC 6598-IP-Adressbereich für sekundäre Bereiche zu.

Zentralisierte DNS-Einrichtung

Für die DNS-Auflösung zwischen Google Cloud und lokalen Umgebungen empfehlen wir einen hybriden Ansatz mit zwei autoritativen DNS-Systemen. Bei diesem Ansatz übernimmt Cloud DNS die autoritative DNS-Auflösung für Ihre Google Cloud-Umgebung und die vorhandenen lokalen DNS-Server übernehmen die autoritative DNS-Auflösung für lokale Ressourcen. Ihre lokale Umgebung und die Google Cloud-Umgebung führen DNS-Lookups zwischen Umgebungen über Weiterleitungsanfragen durch.

Das folgende Diagramm zeigt die DNS-Topologie für mehrere VPC-Netzwerke, die im Blueprint verwendet werden.

Das Diagramm beschreibt die folgenden Komponenten des DNS-Designs, die durch den Blueprint bereitgestellt werden:

• Das DNS-Hub-Projekt im gemeinsamen Ordner ist der zentrale Punkt des DNS-Austauschs zwischen der lokalen Umgebung und der Google Cloud-Umgebung. Die DNS-Weiterleitung verwendet dieselben Dedicated Interconnect-Instanzen und Cloud Router, die bereits in Ihrer Netzwerktopologie konfiguriert sind.
  • In der Dual-freigegebenen VPC-Topologie verwendet der DNS-Hub das freigegebene VPC-Basisnetzwerk.
  • In der Hub-and-Spoke-Topologie verwendet der DNS-Hub das freigegebene VPC-Netzwerk des Basis-Hubs.
• Server in jedem freigegebenen VPC-Netzwerk können DNS-Einträge aus anderen freigegebenen VPC-Netzwerken über die DNS-Weiterleitung auflösen, die zwischen Cloud DNS in jedem freigegebenen VPC-Hostprojekt und dem DNS-Hub konfiguriert ist.
• Lokale Server können DNS-Einträge in Google Cloud-Umgebungen mithilfe von DNS-Serverrichtlinien auflösen, die Abfragen von lokalen Servern zulassen. Der Blueprint konfiguriert eine Serverrichtlinie für eingehenden Traffic im DNS-Hub, um IP-Adressen zuzuweisen. Die lokalen DNS-Server leiten Anfragen an diese Adressen weiter. Alle DNS-Anfragen an Google Cloud erreichen zuerst den DNS-Hub, wodurch dann Einträge von DNS-Peers aufgelöst werden.
• Server in Google Cloud können DNS-Einträge in der lokalen Umgebung mithilfe von Weiterleitungszonen auflösen, die lokale Server abfragen. Alle DNS-Anfragen an die lokale Umgebung stammen vom DNS-Hub. Die DNS-Anfragequelle ist 35.199.192.0/19.

Firewallrichtlinien

Google Cloud verfügt über mehrere Firewallrichtlinientypen. Hierarchische Firewallrichtlinien werden auf Organisations- oder Ordnerebene erzwungen, um die Firewallrichtlinienregeln für alle Ressourcen in der Hierarchie konsistent zu übernehmen. Darüber hinaus können Sie Netzwerk-Firewallrichtlinien für jedes VPC-Netzwerk konfigurieren. Der Blueprint kombiniert diese Firewallrichtlinien, um gemeinsame Konfigurationen in allen Umgebungen mithilfe hierarchischer Firewallrichtlinien zu erzwingen und spezifischere Konfigurationen für jedes einzelne VPC-Netzwerk mithilfe von Netzwerkfirewallrichtlinien zu erzwingen.

Der Blueprint verwendet keine Legacy-VPC-Firewallregeln. Es wird empfohlen, nur Firewallrichtlinien zu verwenden und die Verwendung mit Legacy-VPC-Firewallregeln zu vermeiden.

Hierarchische Firewallrichtlinien

Der Blueprint definiert eine einzelne hierarchische Firewallrichtlinie und hängt die Richtlinie an jeden der Ordner für Produktion, Nicht-Produktion, Entwicklung, Bootstrap und allgemeine Ordner an. Diese hierarchische Firewallrichtlinie enthält die Regeln, die in allen Umgebungen allgemein erzwungen werden sollen. Sie delegiert die Auswertung detaillierterer Regeln an die Netzwerk-Firewallrichtlinie für jede einzelne Umgebung.

In der folgenden Tabelle werden die Regeln der hierarchischen Firewallrichtlinien beschrieben, die vom Blueprint bereitgestellt werden.

Regelbeschreibung	Traffic-Richtung	Filter (IPv4-Bereich)	Protokolle und Ports	Aktion
Delegieren Sie die Auswertung des eingehenden Traffics von RFC 1918 an niedrigere Ebenen in der Hierarchie.	Ingress	192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12	all	Go to next
Delegieren Sie die Auswertung des ausgehenden Traffics an RFC 1918 an niedrigere Ebenen in der Hierarchie.	Egress	192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12	all	Go to next
IAP für die TCP-Weiterleitung	Ingress	35.235.240.0/20	tcp:22,3390	Allow
Windows Server-Aktivierung	Egress	35.190.247.13/32	tcp:1688	Allow
Systemdiagnosen für Cloud Load Balancing	Ingress	130.211.0.0/22, 35.191.0.0/16, 209.85.152.0/22, 209.85.204.0/22	tcp:80,443	Allow

Netzwerk-Firewallrichtlinien

Der Blueprint konfiguriert für jedes Netzwerk eine Netzwerk-Firewallrichtlinie. Jede Netzwerk-Firewallrichtlinie beginnt mit einer Mindestanzahl von Regeln, die den Zugriff auf Google Cloud-Dienste zulassen und den ausgehenden Traffic an alle anderen IP-Adressen ablehnen.

Im Hub-and-Spoke-Modell enthalten die Netzwerk-Firewallrichtlinien zusätzliche Regeln, um die Kommunikation zwischen Spokes zu ermöglichen. Die Netzwerk-Firewallrichtlinie lässt ausgehenden Traffic von einem zum Hub oder einem anderen Spoke zu und lässt eingehenden Traffic von der NVA im Hub-Netzwerk zu.

In der folgenden Tabelle werden die Regeln in der globalen Netzwerk-Firewallrichtlinie beschrieben, die für jedes VPC-Netzwerk im Blueprint bereitgestellt werden.

Regelbeschreibung	Traffic-Richtung	Filtern	Protokolle und Ports
Lassen Sie ausgehenden Traffic zu Google Cloud APIs zu.	Egress	Der Private Service Connect-Endpunkt, der für jedes einzelne Netzwerk konfiguriert ist. Siehe Privater Zugriff auf Google APIs.	tcp:443
Verweigern Sie ausgehenden Traffic, der nicht mit anderen Regeln übereinstimmt.	Egress	Alle	all
Ausgehenden Traffic von einem Spoke zu einem anderen Spoke zulassen (nur für Hub-and-Spoke-Modell).	Egress	Das Aggregat aller in der Hub-and-Spoke-Topologie verwendeten IP-Adressen. Traffic, der eine Spoke-VPC verlässt, wird zuerst an die NVA im Hub-Netzwerk weitergeleitet.	all
Eingehenden Traffic von der NVA im Hub-Netzwerk zulassen (nur für Hub-and-Spoke-Modell).	Ingress	Traffic, der von den NVAs im Hub-Netzwerk stammt.	all

Wenn Sie den Blueprint zum ersten Mal bereitstellen, kann eine VM-Instanz in einem VPC-Netzwerk mit Google Cloud-Diensten, aber nicht mit anderen Infrastrukturressourcen im selben VPC-Netzwerk kommunizieren. Damit VM-Instanzen kommunizieren können, müssen Sie der Netzwerk-Firewallrichtlinie und den Tags zusätzliche Regeln hinzufügen, die explizit die Kommunikation der VM-Instanzen ermöglichen. Tags werden VM-Instanzen hinzugefügt und der Traffic wird anhand dieser Tags ausgewertet. Tags haben außerdem IAM-Steuerelemente, mit denen Sie diese zentral definieren und ihre Verwendung an andere Teams delegieren können.

Hinweis: Alle Verweise auf Tags in diesem Dokument beziehen sich auf Tags mit IAM-Steuerelementen. Wir empfehlen keine VPC-Firewallregeln mit Legacy-Netzwerk-Tags.

Das folgende Diagramm zeigt ein Beispiel für das Hinzufügen benutzerdefinierter Tags und Netzwerk-Firewallregeln, damit Arbeitslasten innerhalb eines VPC-Netzwerks kommunizieren können.

Das Diagramm veranschaulicht die folgenden Konzepte dieses Beispiels:

• Die Netzwerk-Firewallrichtlinie enthält Regel 1, die ausgehenden Traffic aus allen Quellen mit der Priorität 65530 ablehnt.
• Die Netzwerk-Firewallrichtlinie enthält Regel 2, die eingehenden Traffic von Instanzen mit dem Tag service=frontend zu Instanzen mit dem Tag service=backend mit der Priorität 999 zulässt.
• Die Instanz-2-VM kann Traffic von instance-1 empfangen, da der Traffic mit den von Regel 2 zulässigen Tags übereinstimmt. Regel 2 wird abgeglichen, bevor Regel 1 auf Grundlage des Prioritätswerts ausgewertet wird.
• Die Instanz-3-VM empfängt keinen Traffic. Die einzige Firewallrichtlinienregel für diesen Traffic ist Regel 1, also wird ausgehender Traffic von instance-1 abgelehnt.

Privater Zugriff auf Google Cloud APIs

Damit Ressourcen in Ihren VPC-Netzwerken oder lokalen Umgebungen Google Cloud-Dienste erreichen können, empfehlen wir eine private Verbindung anstelle von ausgehendem Internettraffic zu öffentlichen API-Endpunkten. Der Blueprint konfiguriert den privaten Google-Zugriff in jedem Subnetz und erstellt interne Endpunkte mit Private Service Connect, um mit Google Cloud-Diensten zu kommunizieren. Wenn sie zusammen verwendet werden, ermöglichen diese Steuerelemente einen privaten Pfad zu Google Cloud-Diensten, ohne sich auf den ausgehenden Internet-Traffic oder öffentlich beworbene Internetbereiche zu verlassen.

Der Blueprint konfiguriert Private Service Connect-Endpunkte mit API-Bundles, um zu unterscheiden, auf welche Dienste in welchem Netzwerk zugegriffen werden kann. Das Basisnetzwerk verwendet das Bundle all-apis und kann jeden Google-Dienst erreichen, und das eingeschränkte Netzwerk verwendet das vpcsc-Bundle, das den Zugriff auf eine begrenzte Anzahl von Diensten ermöglicht, die VPC Service Controls unterstützen.

Für den Zugriff von Hosts, die sich in einer lokalen Umgebung befinden, empfehlen wir die Verwendung einer Konvention für benutzerdefinierten FQDN für jeden Endpunkt, wie in der folgenden Tabelle beschrieben. Der Blueprint verwendet für jedes VPC-Netzwerk einen eindeutigen Private Service Connect-Endpunkt, der für den Zugriff auf eine andere Gruppe von API-Bundles konfiguriert ist. Sie müssen daher berücksichtigen, wie Diensttraffic von der lokalen Umgebung mit dem richtigen API-Endpunkt an das VPC-Netzwerk weitergeleitet wird. Wenn Sie VPC Service Controls verwenden, müssen Sie dafür sorgen, dass der Traffic an die Google Cloud-Dienste den Endpunkt innerhalb des gewünschten Perimeters erreicht. Konfigurieren Sie Ihre lokalen Steuerelemente für DNS, Firewalls und Router, um den Zugriff auf diese Endpunkte zu ermöglichen, und konfigurieren Sie lokale Hosts für die Verwendung des entsprechenden Endpunkts. Weitere Informationen finden Sie unter Über Google-APIs auf Back-Ends zugreifen.

In der folgenden Tabelle werden die Private Service Connect-Endpunkte beschrieben, die für jedes Netzwerk erstellt werden.

VPC	Umgebung	API-Bundle	IP-Adresse des Private Service Connect-Endpunkts			Benutzerdefinierter FQDN
Basis	Allgemein	all-apis	10.17.0.1/32			c.private.googleapis.com
	Entwicklung	all-apis	10.17.0.2/32			d.private.googleapis.com
	Nicht-Produktion	all-apis	10.17.0.3/32			n.private.googleapis.com
	Produktion	all-apis	10.17.0.4/32			p.private.googleapis.com
Eingeschränkt	Allgemein	vpcsc	10.17.0.5/32			c.restricted.googleapis.com
	Entwicklung	vpcsc	10.17.0.6/32			d.restricted.googleapis.com
	Nicht-Produktion	vpcsc	10.17.0.7/32			n.restricted.googleapis.com
	Produktion	vpcsc	10.17.0.8/32			p.restricted.googleapis.com

Damit Traffic für Google Cloud-Dienste einen DNS-Lookup zum richtigen Endpunkt hat, konfiguriert der Blueprint private DNS-Zonen für jedes VPC-Netzwerk. In der folgenden Tabelle werden diese privaten DNS-Zonen beschrieben.

Name der privaten Zone	DNS-Name	Eintragtyp	Daten
googleapis.com.	*.googleapis.com.	CNAME	private.googleapis.com. (für Basisnetzwerke) oder restricted.googleapis.com. (für eingeschränkte Netzwerke)
	private.googleapis.com (für Basisnetzwerke) oder restricted.googleapis.com (für eingeschränkte Netzwerke)	A	Die IP-Adresse des Private Service Connect-Endpunkts für dieses VPC-Netzwerk.
gcr.io.	*.gcr.io	CNAME	gcr.io.
	gcr.io	A	Die IP-Adresse des Private Service Connect-Endpunkts für dieses VPC-Netzwerk.
pkg.dev.	*.pkg.dev.	CNAME	pkg.dev.
	pkg.dev.	A	Die IP-Adresse des Private Service Connect-Endpunkts für dieses VPC-Netzwerk.

Der Blueprint hat zusätzliche Konfigurationen, um zu erzwingen, dass diese Private Service Connect-Endpunkte konsistent verwendet werden. Für jedes freigegebene VPC-Netzwerk wird außerdem Folgendes erzwungen:

• Eine Netzwerk-Firewallregel, die ausgehenden Traffic von allen Quellen an die IP-Adresse des Private Service Connect-Endpunkts auf TCP:443 zulässt.
• Eine Netzwerk-Firewallrichtlinienregel, die ausgehenden Traffic zu 0.0.0.0/0 ablehnt, einschließlich der Standarddomains, die für den Zugriff auf Google Cloud-Dienste verwendet werden.

Internetverbindung

Der Blueprint lässt keinen eingehenden oder ausgehenden Traffic zwischen seinen VPC-Netzwerken und dem Internet zu. Bei Arbeitslasten, die eine Internetverbindung erfordern, müssen Sie zusätzliche Schritte ausführen, um die erforderlichen Zugriffspfade zu entwerfen.

Für Arbeitslasten, die ausgehenden Traffic zum Internet benötigen, empfehlen wir, ausgehenden Traffic über Cloud NAT zu verwalten, um ausgehenden Traffic ohne unerwünschte eingehende Verbindungen zuzulassen, oder über Secure Web Proxy für eine genauere Kontrolle, um nur ausgehenden Traffic zu vertrauenswürdigen Webdiensten zuzulassen.

Für Arbeitslasten, die eingehenden Traffic aus dem Internet erfordern, empfehlen wir Ihnen, Ihre Arbeitslast mit Cloud Load Balancing und Google Cloud Armor zu entwerfen, um von DDoS- und WAF-Schutzmaßnahmen zu profitieren.

Es wird nicht empfohlen, Arbeitslasten zu entwerfen, die eine direkte Verbindung zwischen dem Internet und einer VM über eine externe IP-Adresse auf der VM ermöglichen.

Hybridkonnektivität zwischen einer lokalen Umgebung und Google Cloud

Zum Herstellen einer Verbindung zwischen der lokalen Umgebung und Google Cloud empfehlen wir die Verwendung von Dedicated Interconnect, um die Sicherheit und Zuverlässigkeit zu maximieren. Eine Dedicated Interconnect-Verbindung ist eine direkte Verbindung zwischen Ihrem lokalen Netzwerk und Google Cloud.

Im folgenden Diagramm wird die Hybridkonnektivität zwischen der lokalen Umgebung und einem Google Virtual Private Cloud-Netzwerk vorgestellt.

Im Diagramm werden die folgenden Komponenten des Musters für die Verfügbarkeit von 99,99% für Dedicated Interconnect beschrieben:

• Vier Dedicated Interconnect-Verbindungen mit zwei Verbindungen in einer Metropolregion (Metro) und zwei Verbindungen in einer anderen Metropolregion.
• Die Verbindungen werden in zwei Paare aufgeteilt, wobei jedes Paar mit einem separaten lokalen Rechenzentrum verbunden ist.
• VLAN-Anhänge werden verwendet, um jede Dedicated Interconnect-Instanz mit Cloud Routern zu verbinden, die der Topologie für freigegebene VPC zugeordnet sind. Diese VLAN-Anhänge werden im Projekt prj-c-interconnect gehostet.
• Jedes freigegebene VPC-Netzwerk hat vier Cloud Router, zwei in jeder Region, wobei der dynamische Routingmodus auf global gesetzt ist, sodass jeder Cloud Router alle Subnetze unabhängig von der Region ankündigen kann.

Cloud Router nutzen das globale dynamische Routing, um Routen für alle Subnetze im VPC-Netzwerk zu bewerben. Cloud Router bewerben Routen in Remote-Subnetzen (Subnetze außerhalb der Cloud Router-Region) im Vergleich zu lokalen Subnetzen (Subnetze, die sich in der Cloud Router-Region befinden) mit einer niedrigeren Priorität. Optional können Sie beworbene Präfixe und Prioritäten ändern, wenn Sie die BGP-Sitzung für einen Cloud Router konfigurieren.

Für den Traffic von Google Cloud zu einer lokalen Umgebung wird der Cloud Router verwendet, der den Cloud-Ressourcen am nächsten ist. Innerhalb einer einzelnen Region haben mehrere Routen zu lokalen Netzwerken denselben Multi-Exit-Diskriminator-Wert (MED) und Google Cloud verwendet Equal Cost Multi-Path (ECMP)-Routing, um ausgehenden Traffic zwischen allen möglichen Routen zu verteilen.

Lokale Konfigurationsänderungen

Sie müssen zusätzliche Änderungen in Ihrer lokalen Umgebung konfigurieren, um die Verbindungen zwischen der lokalen Umgebung und Google Cloud zu konfigurieren. Der Terraform-Code im Blueprint konfiguriert automatisch Google Cloud-Ressourcen, ändert jedoch keine Ihrer lokalen Netzwerkressourcen.

Einige der Komponenten für die Hybridkonnektivität von Ihrer lokalen Umgebung zu Google Cloud werden automatisch durch den Blueprint aktiviert, darunter:

• Cloud DNS wird mit der DNS-Weiterleitung zwischen allen freigegebenen VPC-Netzwerken an einen einzelnen Hub konfiguriert, wie unter DNS-Einrichtung beschrieben. Eine Cloud DNS-Serverrichtlinie wird mit IP-Adressen für eingehenden Traffic konfiguriert.
• Cloud Router ist so konfiguriert, dass Routen für alle Subnetze und benutzerdefinierte Routen für die von den Private Service Connect-Endpunkten verwendeten IP-Adressen exportiert werden.

Um Hybridkonnektivität zu aktivieren, müssen Sie die folgenden zusätzlichen Schritte ausführen:

1. Dedicated Interconnect-Verbindung bestellen
2. Konfigurieren Sie lokale Router und Firewalls, um ausgehenden Traffic zum internen IP-Adressbereich zuzulassen, der unter IP-Adressbereichszuweisung definiert ist.
3. Konfigurieren Sie Ihre lokalen DNS-Server so, dass sie für Google Cloud gebundene DNS-Lookups an die Weiterleitungs-IP-Adressen für eingehenden Traffic weiterleiten, die bereits durch den Blueprint konfiguriert sind.
4. Konfigurieren Sie Ihre lokalen DNS-Server, Firewalls und Router so, dass sie DNS-Abfragen von der Weiterleitungszone von Cloud DNS (35.199.192.0/19) akzeptieren.
5. Konfigurieren Sie lokale DNS-Server so, dass sie auf Abfragen von lokalen Hosts an Google Cloud-Dienste mit den unter Privater Zugriff auf Cloud APIs definierten IP-Adressen antworten.
6. Konfigurieren Sie für die Verschlüsselung während der Übertragung über die Dedicated Interconnect-Verbindung MACsec für Cloud Interconnect oder konfigurieren Sie HA VPN über Cloud Interconnect für die IPsec-Verschlüsselung.

Weitere Informationen finden Sie unter Privater Google-Zugriff für lokale Hosts.

Nächste Schritte

• Weitere Informationen zu Erkennungskontrollen (nächstes Dokument in dieser Reihe)

Aufdeckungskontrollen

Bedrohungserkennungs- und Monitoring-Funktionen werden mit einer Kombination aus integrierten Sicherheitskontrollen aus Security Command Center und benutzerdefinierten Lösungen bereitgestellt, mit denen Sie Sicherheitsereignisse erkennen und darauf reagieren können.

Zentrales Logging für Sicherheit und Audit

Der Blueprint konfiguriert Logging-Funktionen, um Änderungen an Ihren Google Cloud-Ressourcen mit Logs zu verfolgen und zu analysieren, die zu einem einzelnen Projekt zusammengefasst werden.

Das folgende Diagramm zeigt, wie der Blueprint Logs aus mehreren Quellen in mehreren Projekten in einer zentralen Logsenke aggregiert.

Das Diagramm beschreibt Folgendes:

• Logsenken werden auf dem Organisationsknoten so konfiguriert, dass Logs aus allen Projekten in der Ressourcenhierarchie zusammengefasst werden.
• Mehrere Logsenken sind so konfiguriert, dass sie Logs, die einem Filter entsprechen, an verschiedene Ziele für die Speicherung und Analyse senden.
• Das prj-c-logging-Projekt enthält alle Ressourcen für den Logspeicher und die Analyse.
• Optional können Sie zusätzliche Tools konfigurieren, um Logs in ein SIEM zu exportieren.

Der Blueprint verwendet verschiedene Logquellen und schließt diese Logs in den Logsenkenfilter ein, damit die Logs an ein zentrales Ziel exportiert werden können. In der folgenden Tabelle werden die Logquellen beschrieben.

Logquelle	Beschreibung
Audit-Logs zur Administratoraktivität	Sie können Audit-Logs zu Administratoraktivitäten nicht konfigurieren, deaktivieren oder ausschließen.
Audit-Logs zu Systemereignissen	Audit-Logs zu Systemereignissen können nicht konfiguriert, deaktiviert oder ausgeschlossen werden.
Audit-Logs zu Richtlinienverstößen	Sie können Audit-Logs zu Richtlinienverstößen nicht konfigurieren oder deaktivieren, aber optional mit Ausschlussfiltern ausschließen.
Audit-Logs zum Datenzugriff	Standardmäßig aktiviert der Blueprint keine Datenzugriffslogs, da das Volumen und die Kosten dieser Logs hoch sein können. Um festzulegen, ob Sie Datenzugriffslogs aktivieren möchten, bewerten Sie, wo Ihre Arbeitslasten sensible Daten verarbeiten. Überlegen Sie auch, ob Sie Datenzugriffslogs für jeden Dienst und jede Umgebung aktivieren müssen, die mit sensiblen Daten arbeiten.
VPC-Flusslogs	Der Blueprint aktiviert VPC-Flusslogs für jedes Subnetz. Der Blueprint konfiguriert das Log-Sampling so, dass 50% der Logs erfasst werden, um die Kosten zu senken. Wenn Sie zusätzliche Subnetze erstellen, müssen Sie dafür sorgen, dass für jedes Subnetz VPC-Flusslogs aktiviert sind.
Logging von Firewallregeln	Der Blueprint aktiviert das Logging von Firewallregeln für jede Firewallrichtlinienregel. Wenn Sie zusätzliche Firewallrichtlinienregeln für Arbeitslasten erstellen, müssen Sie dafür sorgen, dass das Firewallregel-Logging für jede neue Regel aktiviert ist.
Cloud DNS Logging	Der Blueprint aktiviert Cloud DNS-Logs für verwaltete Zonen. Wenn Sie zusätzliche verwaltete Zonen erstellen, müssen Sie diese DNS-Logs aktivieren.
Audit-Logging von Google Workspace	Erfordert einen einmaligen Aktivierungsschritt, der nicht durch den Blueprint automatisiert wird. Weitere Informationen finden Sie unter Daten für Google Cloud-Dienste freigeben.
Access Transparency-Logs	Erfordert einen einmaligen Aktivierungsschritt, der nicht durch den Blueprint automatisiert wird. Weitere Informationen finden Sie unter Access Transparency aktivieren.

In der folgenden Tabelle werden die Logsenken und ihre Verwendung mit unterstützten Zielen im Blueprint beschrieben.

Sink	Ziel	Zweck
sk-c-logging-la	Logs, die an Cloud Logging-Buckets weitergeleitet werden, mit Log Analytics und einem aktivierten verknüpften BigQuery-Dataset	Analysieren Sie Logs aktiv. Führen Sie Ad-hoc-Prüfungen mit dem Log-Explorer in der Console aus oder schreiben Sie SQL-Abfragen, Berichte und Ansichten mit dem verknüpften BigQuery-Dataset.
sk-c-logging-bkt	An Cloud Storage weitergeleitete Logs	Speichern Sie Logs langfristig für Compliance-, Audit- und Vorfall-Tracking-Zwecke. Wenn Sie Compliance-Anforderungen für die obligatorische Datenaufbewahrung haben, sollten Sie optional auch die Bucket-Sperre konfigurieren.
sk-c-logging-pub	An Pub/Sub weitergeleitete Logs	Exportieren Sie Logs auf eine externe Plattform wie das vorhandene SIEM. Dies erfordert zusätzliche Arbeit für die Einbindung in Ihre SIEM-Funktion, z. B. die folgenden Mechanismen: Für viele Tools ist die Einbindung von Drittanbietern in Pub/Sub die bevorzugte Methode zum Aufnehmen von Logs. Für Google Chronicle können Sie Google Cloud-Daten in Chronicle aufnehmen, ohne eine zusätzliche Infrastruktur bereitzustellen. Für Splunk können Sie mit Dataflow Logs von Google Cloud zu Splunk streamen.

Eine Anleitung zum Aktivieren zusätzlicher Logtypen und zum Schreiben von Logsenkenfiltern finden Sie unter Logbereichstool.

Bedrohungsmonitoring mit Security Command Center

Wir empfehlen die Aktivierung von Security Command Center Premium für Ihre Organisation, um Bedrohungen, Sicherheitslücken und Fehlkonfigurationen in Ihren Google Cloud-Ressourcen automatisch zu erkennen. Security Command Center erstellt Sicherheitsergebnisse aus mehreren Quellen, darunter:

• Security Health Analytics: Erkennt häufige Sicherheitslücken und Fehlkonfigurationen für alle Google Cloud-Ressourcen.
• Angriffspfadrisiko: Zeigt einen simulierten Pfad, wie ein Angreifer Ihre wichtigen Ressourcen anhand der Sicherheitslücken und Fehlkonfigurationen, die von anderen Quellen von Security Command Center erkannt werden, ausnutzen können.
• Event Threat Detection: wendet Erkennungslogik und proprietäre Bedrohungsinformationen auf Ihre Logs an, um Bedrohungen nahezu in Echtzeit zu identifizieren.
• Container Threat Detection: erkennt gängige Containerlaufzeit-Angriffe.
• Virtual Machine Threat Detection: Erkennt potenziell schädliche Anwendungen, die auf virtuellen Maschinen ausgeführt werden.
• Web Security Scanner: Sucht nach OWASP-Top-Ten-Sicherheitslücken in Ihren webbasierten Anwendungen in Compute Engine, App Engine oder Google Kubernetes Engine.

Weitere Informationen zu den Sicherheitslücken und Bedrohungen, die von Security Command Center behoben werden, finden Sie unter Security Command Center-Quellen.

Sie müssen das Security Command Center nach der Bereitstellung des Blueprints aktivieren. Eine Anleitung finden Sie unter Security Command Center für eine Organisation aktivieren.

Nachdem Sie Security Command Center aktiviert haben, empfehlen wir, die von Security Command Center generierten Ergebnisse in Ihre vorhandenen Tools oder Prozesse zu exportieren, um Bedrohungen zu erkennen und darauf zu reagieren. Der Blueprint erstellt das Projekt prj-c-scc mit einem Pub/Sub-Thema, das für diese Integration verwendet werden soll. Verwenden Sie je nach vorhandenen Tools eine der folgenden Methoden, um Ergebnisse zu exportieren:

• Wenn Sie die Console verwenden, um Sicherheitsergebnisse direkt in Security Command Center zu verwalten, konfigurieren Sie Rollen auf Ordner- und Projektebene für Security Command Center, damit Teams Sicherheitsergebnisse nur für die Projekte ansehen und verwalten können, für die sie zuständig sind.

• Wenn Sie Chronicle als SIEM verwenden, nehmen Sie Google Cloud-Daten in Chronicle auf.

• Wenn Sie ein SIEM- oder SOAR-Tool mit Integrationen in Security Command Center verwenden, geben Sie Daten für Cortex XSOAR, Elastic Stack, ServiceNow, Splunk oder QRadar an.

• Wenn Sie ein externes Tool verwenden, das Ergebnisse aus Pub/Sub aufnehmen kann, konfigurieren Sie kontinuierliche Exporte in Pub/Sub und Ihre vorhandenen Tools so, dass Ergebnisse aus dem Pub/Sub-Thema aufgenommen werden.

Benachrichtigungen über logbasierte Messwerte und Leistungsmesswerte

Wenn Sie mit der Bereitstellung von Arbeitslasten auf der Grundlage beginnen, empfehlen wir die Verwendung von Cloud Monitoring zur Messung der Leistungsmesswerte.

Der Blueprint erstellt für jede Umgebung ein Monitoring-Projekt wie prj-p-monitoring. Dieses Projekt wird als den Bereich festlegendes Projekt konfiguriert, um aggregierte Leistungsmesswerte für mehrere Projekte zu erfassen. Der Blueprint stellt ein Beispiel mit logbasierten Messwerten und einer Benachrichtigungsrichtlinie bereit, um E-Mail-Benachrichtigungen zu generieren, wenn Änderungen an der IAM-Richtlinie vorgenommen werden, die auf Cloud Storage-Buckets angewendet wird. So können Sie verdächtige Aktivitäten bei vertraulichen Ressourcen wie dem Bucket im prj-b-seed-Projekt überwachen, das den Terraform-Zustand enthält.

Im Allgemeinen können Sie auch Cloud Monitoring verwenden, um die Leistungsmesswerte und den Status Ihrer Arbeitslastanwendungen zu messen. Abhängig von der operativen Verantwortung für die Unterstützung und Überwachung von Anwendungen in Ihrer Organisation können Sie detailliertere Monitoringprojekte für verschiedene Teams erstellen. Mit diesen Monitoring-Projekten können Sie Leistungsmesswerte aufrufen, Dashboards zum Anwendungszustand erstellen und Benachrichtigungen auslösen, wenn das erwartete SLO nicht erreicht wird.

Das folgende Diagramm zeigt eine allgemeine Ansicht, wie Cloud Monitoring Leistungsmesswerte aggregiert.

Informationen zum effektiven Monitoring von Arbeitslasten auf Zuverlässigkeit und Verfügbarkeit finden Sie im Site Reliability Engineering-Buch von Google, insbesondere im Kapitel zum Überwachen von verteilten Systemen.

Benutzerdefinierte Lösung für automatisierte Loganalyse

Möglicherweise müssen Sie Benachrichtigungen für Sicherheitsereignisse erstellen, die auf benutzerdefinierten Abfragen von Logs basieren. Benutzerdefinierte Abfragen können die Funktionen Ihres SIEM ergänzen, indem sie Logs in Google Cloud analysieren und nur die Ereignisse exportieren, die eine Untersuchung erfordern, insbesondere wenn Sie nicht die Möglichkeit haben, alle Cloud-Logs in Ihr SIEM-Tools zu exportieren.

Der Blueprint unterstützt diese Loganalyse, indem eine zentralisierte Quelle von Logs eingerichtet wird, die Sie mit einem verknüpften BigQuery-Dataset abfragen können. Zur Automatisierung dieser Funktion müssen Sie das Codebeispiel unter bq-log-alerting implementieren und die Grundlagenfunktionen erweitern. Mit dem Beispielcode können Sie regelmäßig eine Logquelle abfragen und ein benutzerdefiniertes Ergebnis an Security Command Center senden.

Im folgenden Diagramm wird der allgemeine Ablauf der automatisierten Loganalyse vorgestellt.

Das Diagramm zeigt die folgenden Konzepte der automatisierten Loganalyse:

• Logs aus verschiedenen Quellen werden in einem zentralisierten Log-Bucket mit Loganalysen und einem verknüpften BigQuery-Dataset zusammengefasst.
• BigQuery-Ansichten sind so konfiguriert, dass Logs für das Sicherheitsereignis abgefragt werden, das Sie beobachten möchten.
• Cloud Scheduler überträgt alle 15 Minuten ein Ereignis an ein Pub/Sub-Thema und löst Cloud Functions aus.
• Cloud Functions fragt die Ansichten nach neuen Ereignissen ab. Wenn Ereignisse gefunden werden, werden sie als benutzerdefinierte Ergebnisse an Security Command Center übertragen.
• Security Command Center veröffentlicht Benachrichtigungen über neue Ergebnisse in einem anderen Pub/Sub-Thema.
• Ein externes Tool wie ein SIEM abonniert das Pub/Sub-Thema, um neue Ergebnisse aufzunehmen.

Das Beispiel hat mehrere Anwendungsfälle, um potenziell verdächtiges Verhalten abzufragen. Beispiele sind eine Anmeldung aus einer Liste von Super Admins oder anderen von Ihnen angegebenen Konten mit umfangreichen Berechtigungen, Änderungen an den Logging-Einstellungen oder Änderungen an Netzwerkrouten. Sie können die Anwendungsfälle erweitern, indem Sie neue Abfrageansichten für Ihre Anforderungen schreiben. Schreiben Sie eigene Abfragen oder verweisen Sie auf Sicherheitsloganalysen für eine Bibliothek von SQL-Abfragen, mit denen Sie Google Cloud-Logs analysieren können.

Benutzerdefinierte Lösung zur Reaktion auf Asset-Änderungen

Damit Sie in Echtzeit auf Ereignisse reagieren können, empfehlen wir Ihnen, Cloud Asset Inventory zu verwenden, um Assetänderungen zu überwachen. In dieser benutzerdefinierten Lösung ist ein Asset-Feed so konfiguriert, dass Benachrichtigungen über Änderungen an Ressourcen in Echtzeit an Pub/Sub ausgelöst werden. Cloud Functions führt dann benutzerdefinierten Code aus, um Ihre eigene Geschäftslogik basierend darauf zu erzwingen, ob die Änderung zugelassen werden sollte.

Der Blueprint enthält ein Beispiel für diese benutzerdefinierte Governance-Lösung, die IAM-Änderungen überwacht, die hochsensible Rollen wie Organisationsadministrator, Inhaber und Bearbeiter hinzufügen. Im folgenden Diagramm wird diese Lösung beschrieben.

Das obige Diagramm zeigt diese Konzepte:

• Änderungen an einer Zulassungsrichtlinie werden vorgenommen.
• Der Cloud Asset Inventory-Feed sendet eine Echtzeitbenachrichtigung über die Änderung der Zulassungsrichtlinie an Pub/Sub.
• Pub/Sub löst eine Funktion aus.
• Cloud Functions führt benutzerdefinierten Code aus, um die Richtlinie zu erzwingen. Die Beispielfunktion prüft, ob die Änderung die Rolle "Organisationsadministrator", "Inhaber" oder "Bearbeiter" zu einer Zulassungsrichtlinie hinzugefügt hat. Ist dies der Fall, erstellt die Funktion ein benutzerdefiniertes Sicherheitsergebnis und sendet es an das Security Command Center.
• Optional können Sie dieses Modell verwenden, um Abhilfemaßnahmen zu automatisieren. Schreiben Sie zusätzliche Geschäftslogik in Cloud Functions, um automatisch Maßnahmen für das Ergebnis zu ergreifen, z. B. um die Zulassungsrichtlinie auf den vorherigen Zustand zurückzusetzen.

Darüber hinaus können Sie die von dieser Beispiellösung verwendete Infrastruktur und Logik erweitern, um anderen Ereignissen, die für Ihr Unternehmen wichtig sind, benutzerdefinierte Antworten hinzuzufügen.

Nächste Schritte

• Mehr über vorbeugende Steuerelemente (nächstes Dokument in dieser Reihe) erfahren

Vorbeugende Kontrollen für akzeptable Ressourcenkonfigurationen

Es wird empfohlen, Richtlinieneinschränkungen zu definieren, die akzeptable Ressourcenkonfigurationen erzwingen und riskante Konfigurationen verhindern. Der Blueprint verwendet eine Kombination aus Organisationsrichtlinieneinschränkungen und der IaC-Validierung (Infrastructure-as-Code) in Ihrer Pipeline. Durch diese Kontrollen wird verhindert, dass Ressourcen erstellt werden, die nicht Ihren Richtlinien entsprechen. Wenn Sie diese Kontrollen früh im Design und Build Ihrer Arbeitslasten erzwingen, können Sie spätere Abhilfemaßnahmen vermeiden.

Einschränkungen für Organisationsrichtlinien

Der Organisationsrichtliniendienst erzwingt Einschränkungen, um sicherzustellen, dass bestimmte Ressourcenkonfigurationen in Ihrer Google Cloud-Organisation nicht erstellt werden können, auch nicht durch eine Person mit einer IAM-Rolle mit ausreichend Rechten.

Der Blueprint erzwingt Richtlinien auf dem Organisationsknoten, sodass diese Kontrollen von allen Ordnern und Projekten innerhalb der Organisation übernommen werden. Mit diesem Richtlinien-Bundle sollen bestimmte Konfigurationen mit hohem Risiko verhindert werden, z. B. die Freigabe einer VM im öffentlichen Internet oder das Gewähren des öffentlichen Zugriffs auf Storage-Buckets, es sei denn, Sie erlauben explizit eine Ausnahme von der Richtlinie.

In der folgenden Tabelle werden die Einschränkungen für Organisationsrichtlinien vorgestellt, die im Blueprint implementiert sind:

Organisationsrichtlinie-Beschränkung	Beschreibung
compute.disableNestedVirtualization	Verschachtelte Virtualisierung auf Compute Engine-VMs kann das Monitoring und andere Sicherheitstools für Ihre VMs umgehen, wenn sie schlecht konfiguriert sind. Diese Einschränkung verhindert die Erstellung der verschachtelten Virtualisierung.
compute.disableSerialPortAccess	IAM-Rollen wie compute.instanceAdmin ermöglichen den privilegierten Zugriff auf den seriellen Port einer Instanz mithilfe von SSH-Schlüsseln. Wenn der SSH-Schlüssel offengelegt wird, kann ein Angreifer auf den seriellen Port zugreifen und Netzwerk- und Firewall-Kontrollen umgehen. Diese Einschränkung verhindert den Zugriff auf den seriellen Port.
compute.disableVpcExternalIpv6	Externe IPv6-Subnetze können für nicht autorisierten Internetzugriff freigegeben werden, wenn sie schlecht konfiguriert sind. Diese Einschränkung verhindert die Erstellung externer IPv6-Subnetze.
compute.requireOsLogin	Das Standardverhalten bei der Einstellung SSH-Schlüssel in Metadaten kann den nicht autorisierten Remotezugriff auf VMs zulassen, wenn Schlüssel verfügbar gemacht werden. Diese Einschränkung erzwingt die Verwendung von OS Login anstelle von metadatenbasierten SSH-Schlüsseln.
compute.restrictProtocolForwardingCreationForTypes	Eine VM-Protokollweiterleitung für externe IP-Adressen kann zu nicht autorisiertem ausgehenden Internettraffic führen, wenn sie schlecht konfiguriert ist. Diese Einschränkung ermöglicht die VM-Protokollweiterleitung nur für interne Adressen.
compute.restrictXpnProjectLienRemoval	Das Löschen eines freigegebenen VPC-Hostprojekts kann alle Dienstprojekte beeinträchtigen, die Netzwerkressourcen verwenden. Diese Einschränkung verhindert das versehentliche oder böswillige Löschen der freigegebenen VPC-Hostprojekte, da sie das Entfernen der Projektsperre für diese Projekte verhindert.
compute.setNewProjectDefaultToZonalDNSOnly	Eine Legacy-Einstellung für das globale (projektweite) interne DNS wird nicht empfohlen, da dies die Dienstverfügbarkeit reduziert. Diese Einschränkung verhindert die Verwendung der Legacy-Einstellung.
compute.skipDefaultNetworkCreation	In jedem neuen Projekt, für das die Compute Engine API aktiviert ist, werden ein Standard-VPC-Netzwerk und zu moderate Standard-VPC-Firewallregeln erstellt. Mit dieser Einschränkung wird die Erstellung der Standardnetzwerk- und Standard-VPC-Firewallregeln übersprungen.
compute.vmExternalIpAccess	Standardmäßig wird eine VM mit einer externen IPv4-Adresse erstellt, die zu einem nicht autorisierten Internetzugriff führen kann. Mit dieser Einschränkung wird eine leere Zulassungsliste externer IP-Adressen konfiguriert, die die VM verwenden kann. Alle anderen werden abgelehnt.
essentialcontacts.allowedContactDomains	Standardmäßig können Wichtige Kontakte so konfiguriert werden, dass Benachrichtigungen über Ihre Domain an eine andere Domain gesendet werden. Durch diese Einschränkung wird erzwungen, dass nur E-Mail-Adressen in genehmigten Domains als Empfänger für wichtige Kontakte festgelegt werden können.
iam.allowedPolicyMemberDomains	Standardmäßig können Zulassungsrichtlinien jedem Google-Konto zugewiesen werden, einschließlich nicht verwalteter Konten und Konten, die zu externen Organisationen gehören. Mit dieser Einschränkung wird sichergestellt, dass Zulassungsrichtlinien in Ihrer Organisation nur verwalteten Konten aus Ihrer eigenen Domain gewährt werden können. Optional können Sie zusätzliche Domains zulassen.
iam.automaticIamGrantsForDefaultServiceAccounts	Standardmäßig werden Standarddienstkonten automatisch zu moderate Rollen zugewiesen. Diese Einschränkung verhindert, dass Standarddienstkonten automatisch eine IAM-Rolle zugewiesen wird.
iam.disableServiceAccountKeyCreation	Dienstkontoschlüssel sind nichtflüchtige Anmeldedaten mit hohem Risiko. In den meisten Fällen kann eine sicherere Alternative zu Dienstkontoschlüsseln verwendet werden. Diese Einschränkung verhindert das Erstellen von Dienstkontoschlüsseln.
iam.disableServiceAccountKeyUpload	Das Hochladen von Schlüsselmaterial für das Dienstkonto kann das Risiko erhöhen, wenn Schlüsselmaterial bereitgestellt wird. Diese Einschränkung verhindert das Hochladen von Dienstkontoschlüsseln.
sql.restrictAuthorizedNetworks	Cloud SQL-Instanzen können über einen nicht authentifizierten Internetzugriff bereitgestellt werden, wenn die Instanzen so konfiguriert sind, dass sie autorisierte Netzwerke ohne Cloud SQL Auth-Proxy verwenden. Diese Richtlinie verhindert die Konfiguration autorisierter Netzwerke für den Datenbankzugriff und erzwingt stattdessen die Verwendung des Cloud SQL Auth-Proxys.
sql.restrictPublicIp	Cloud SQL-Instanzen können nicht authentifiziertem Internetzugriff ausgesetzt sein, wenn die Instanzen mit öffentlichen IP-Adressen erstellt werden. Diese Einschränkung verhindert öffentliche IP-Adressen auf Cloud SQL-Instanzen.
storage.uniformBucketLevelAccess	Auf Objekte kann in Cloud Storage standardmäßig über Legacy-Access Control Lists (ACLs) statt auf IAM zugegriffen werden. Dies kann zu inkonsistenten Zugriffssteuerungen und zu einer versehentlichen Offenlegung führen, wenn falsch konfiguriert wird. Der Zugriff auf Legacy-ACLs ist von der Einschränkung iam.allowedPolicyMemberDomains nicht betroffen. Diese Einschränkung erzwingt, dass der Zugriff nur über den einheitlichen Zugriff auf Bucket-Ebene von IAM konfiguriert werden kann, nicht über Legacy-ACLs.
storage.publicAccessPrevention	Cloud Storage-Buckets können nicht autorisiertem Internetzugriff ausgesetzt sein, wenn sie falsch konfiguriert sind. Diese Einschränkung verhindert ACLs und IAM-Berechtigungen, mit denen der Zugriff auf allUsers und allAuthenticatedUsers gewährt wird.

Diese Richtlinien sind ein Ausgangspunkt, den wir für die meisten Kunden und die meisten Szenarien empfehlen. Möglicherweise müssen Sie jedoch die Einschränkungen für Organisationsrichtlinien ändern, um bestimmte Arbeitslasttypen zu berücksichtigen. Beispielsweise wird eine Arbeitslast, die einen Cloud Storage-Bucket als Back-End für Cloud CDN zum Hosten öffentlicher Ressourcen verwendet, von storage.publicAccessPrevention blockiert, oder eine öffentliche Cloud Run-Anwendung, die keine Authentifizierung erfordert, wird durch iam.allowedPolicyMemberDomains blockiert. Ändern Sie in diesen Fällen die Organisationsrichtlinie auf Ordner- oder Projektebene, um eine enge Ausnahme zu ermöglichen. Sie können auch Organisationsrichtlinien Einschränkungen bedingt hinzufügen, indem Sie ein Tag definieren, das eine Ausnahme oder Erzwingung für Richtlinien gewährt, und das Tag dann auf Projekte und Ordner anwenden.

Weitere Einschränkungen finden Sie unter Verfügbare Einschränkungen und benutzerdefinierte Einschränkungen.

Infrastruktur als Code vor der Bereitstellung validieren

Der Blueprint verwendet einen GitOps-Ansatz zur Verwaltung der Infrastruktur. Das bedeutet, dass alle Infrastrukturänderungen über die versionsgesteuerte Infrastruktur als Code (IaC) implementiert werden und vor dem Deployment validiert werden können.

Die im Blueprint erzwungenen Richtlinien definieren akzeptable Ressourcenkonfigurationen, die von Ihrer Pipeline bereitgestellt werden können. Wenn Code, der an Ihr GitHub-Repository gesendet wird, die Richtlinienprüfungen nicht besteht, werden keine Ressourcen bereitgestellt.

Informationen zur Verwendung von Pipelines und zur Durchsetzung von Kontrollen über die CI/CD-Automatisierung finden Sie unter Bereitstellungsmethode.

Nächste Schritte

• Mehr über die Bereitstellungsmethode erfahren (nächstes Dokument in dieser Reihe)

Einrichtungsverfahren

Wir empfehlen die Verwendung einer deklarativen Infrastruktur, um die Grundlage konsistent und kontrollierbar bereitzustellen. Dieser Ansatz unterstützt eine konsistente Governance, indem Richtliniensteuerungen zu akzeptablen Ressourcenkonfigurationen in Ihren Pipelines erzwungen werden. Der Blueprint wird mit einem GitOps-Ablauf bereitgestellt, wobei Terraform verwendet wird, um die Infrastruktur als Code (IaC), ein Git-Repository für die Versionsverwaltung und Genehmigung von Code und Cloud Build für die CI/CD-Automatisierung in der Bereitstellungspipeline zu definieren. Eine Einführung in dieses Konzept finden Sie unter Infrastruktur als Code mit Terraform, Cloud Build und GitOps verwalten.

In den folgenden Abschnitten wird beschrieben, wie die Bereitstellungspipeline zum Verwalten von Ressourcen in Ihrer Organisation verwendet wird.

Pipelineebenen

Zur Trennung der Teams und des Technologie-Stacks, die für die Verwaltung verschiedener Ebenen Ihrer Umgebung verantwortlich sind, empfehlen wir ein Modell, das unterschiedliche Pipelines und verschiedene Identitäten verwendet, die für jede Schicht des Stacks verantwortlich sind.

Im folgenden Diagramm wird unser empfohlenes Modell vorgestellt, mit dem eine Grundlagenpipeline, eine Infrastrukturpipeline und eine Anwendungspipeline getrennt werden können.

Im Diagramm werden die Pipeline-Ebenen in diesem Modell vorgestellt:

• Die Grundlagenpipeline stellt die Grundlagenressourcen bereit, die auf der gesamten Plattform verwendet werden. Wir empfehlen, dass ein zentrales Team für die Verwaltung der Grundlagenressourcen verantwortlich ist, die von mehreren Geschäftseinheiten und Arbeitslasten genutzt werden.
• In der Infrastrukturpipeline werden Projekte und Infrastrukturen bereitgestellt, die von Arbeitslasten wie VM-Instanzen oder Datenbanken verwendet werden. Mit dem Blueprint wird eine separate Infrastrukturpipeline für jede Geschäftseinheit eingerichtet. Sie können aber auch eine einzelne Infrastrukturpipeline bevorzugen, die von mehreren Teams verwendet wird.
• Die Anwendungspipeline stellt die Artefakte für jede Arbeitslast bereit, z. B. Container oder Images. Möglicherweise haben Sie viele verschiedene Anwendungsteams mit einzelnen Anwendungspipelines.

In den folgenden Abschnitten wird die Nutzung der einzelnen Pipelineebenen vorgestellt.

Grundlagenpipeline

Die Grundlagenpipeline stellt die Grundlagenressourcen bereit. Außerdem wird die Infrastrukturpipeline eingerichtet, die zum Bereitstellen von Infrastruktur verwendet wird, die von Arbeitslasten verwendet wird.

Um die Grundlagenpipeline zu erstellen, klonen Sie zuerst die terraform-example-foundation in Ihr eigenes Git-Repository oder verzweigen sie. Führen Sie die Schritte in der README-Datei 0-bootstrap aus, um den Bootstrap-Ordner und die Ressourcen zu konfigurieren.

Phase

Beschreibung

0-bootstrap

Bootstrapping einer Google Cloud-Organisation. Mit diesem Schritt wird auch eine CI/CD-Pipeline für den Blueprint-Code in nachfolgenden Phasen konfiguriert. Das CICD-Projekt enthält die Cloud Build-Grundlagenpipeline zum Bereitstellen von Ressourcen. Das seed-Projekt enthält die Cloud Storage-Buckets, die den Terraform-Status der Grundlageninfrastruktur enthalten, sowie Dienstkonten mit umfangreichen Berechtigungen, die von der Grundlagenpipeline verwendet werden, um Ressourcen zu erstellen. Der Terraform-Status wird durch die Objektversionsverwaltung geschützt. Wenn die CI/CD-Pipeline ausgeführt wird, fungiert sie als die Dienstkonten, die im Projekt seed verwaltet werden.

Nachdem Sie die Grundlagenpipeline in der Phase 0-bootstrap erstellt haben, stellen die folgenden Phasen Ressourcen in der Grundlagenpipeline bereit. Lesen Sie die README-Anleitung für jede Phase und implementieren Sie jede Phase sequenziell.

Phase	Beschreibung
1-org	Richtet übergeordnete freigegebene Ordner, Projekte für freigegebene Dienste, Logging auf Organisationsebene und grundlegende Sicherheitseinstellungen über Organisationsrichtlinien ein.
2-environments	Richtet Entwicklungs-, Nicht-Produktions- und Produktionsumgebungen in der von Ihnen erstellten Google Cloud-Organisation ein.
3-networks-dual-svpc oder 3-networks-hub-and-spoke	Richtet freigegebene VPCs in der ausgewählten Topologie und den zugehörigen Netzwerkressourcen ein.

Infrastrukturpipeline

In der Infrastrukturpipeline werden die Projekte und Infrastruktur bereitgestellt, z. B. die VM-Instanzen und Datenbanken, die von Arbeitslasten verwendet werden. Die Grundlagenpipeline stellt mehrere Infrastrukturpipelines bereit. Diese Trennung zwischen der Grundlagenpipeline und der Infrastrukturpipeline ermöglicht eine Trennung zwischen plattformweiten Ressourcen und arbeitslastspezifischen Ressourcen.

Das folgende Diagramm zeigt, wie der Blueprint mehrere Infrastrukturpipelines konfiguriert, die für separate Teams vorgesehen sind.

Das Diagramm beschreibt die folgenden Schlüsselkonzepte:

• Jede Infrastrukturpipeline wird verwendet, um Infrastrukturressourcen unabhängig von den Grundlagenressourcen zu verwalten.
• Jede Geschäftseinheit hat eine eigene Infrastrukturpipeline, die in einem dedizierten Projekt im Ordner common verwaltet wird.
• Jede Infrastrukturpipeline hat ein Dienstkonto mit der Berechtigung, Ressourcen nur für die Projekte bereitzustellen, die dieser Geschäftseinheit zugeordnet sind. Diese Strategie erstellt eine Aufgabentrennung zwischen den privilegierten Dienstkonten, die für die Grundlagenpipeline verwendet werden, und denen, die von jeder Infrastrukturpipeline verwendet werden.

Dieser Ansatz mit mehreren Infrastrukturpipelines wird empfohlen, wenn Sie mehrere Entitäten in Ihrer Organisation haben, die die Fähigkeiten und Notwendigkeiten zur separaten Verwaltung ihrer Infrastruktur haben, insbesondere wenn sie unterschiedliche Anforderungen wie die Arten der Pipelinevalidierungsrichtlinie haben, die erzwungen werden soll. Alternativ können Sie auch eine einzelne Infrastrukturpipeline verwenden, die von einem einzigen Team mit konsistenten Validierungsrichtlinien verwaltet wird.

In der terraform-example-foundation konfiguriert Phase 4 eine Infrastrukturpipeline und Phase 5 ein Beispiel für die Verwendung dieser Pipeline zum Bereitstellen von Infrastrukturressourcen.

Phase	Beschreibung
4-projects	Richtet eine Ordnerstruktur, Projekte und eine Infrastrukturpipeline ein.
5-app-infra (optional)	Stellt Arbeitslastprojekte mit einer Compute Engine-Instanz unter Verwendung der Infrastrukturpipeline als Beispiel bereit.

Anwendungspipeline

Die Anwendungspipeline ist für die Bereitstellung von Anwendungsartefakten für jede einzelne Arbeitslast verantwortlich, z. B. Images oder Kubernetes-Container, die die Geschäftslogik Ihrer Anwendung ausführen. Diese Artefakte werden in Infrastrukturressourcen bereitgestellt, die von der Infrastrukturpipeline bereitgestellt worden sind.

Der Blueprint zu Unternehmensgrundlagen richtet Ihre Grundlagenpipeline und die Infrastrukturpipeline ein, stellt jedoch keine Anwendungspipeline bereit. Ein Beispiel für eine Anwendungspipeline finden Sie im Blueprint für Unternehmensanwendungen.

Pipeline mit Cloud Build automatisieren

Der Blueprint verwendet Cloud Build, um CI/CD-Prozesse zu automatisieren. In der folgenden Tabelle werden die Steuerelemente beschrieben, die in die Grundlagenpipeline und die Infrastrukturpipeline eingebunden sind, die vom Repository terraform-example-foundation bereitgestellt werden. Wenn Sie eigene Pipelines mit anderen CI/CD-Automatisierungstools entwickeln, empfehlen wir die Anwendung ähnlicher Steuerelemente.

Steuerelement	Beschreibung
Build-Konfigurationen trennen, um Code vor der Bereitstellung zu validieren	Der Blueprint verwendet zwei Build-Konfigurationsdateien für die gesamte Pipeline und jedes mit einer Phase verknüpfte Repository enthält zwei Cloud Build-Trigger, die mit diesen Build-Konfigurationsdateien verknüpft sind. Wenn Code an einen Repository-Zweig übertragen wird, werden die Build-Konfigurationsdateien ausgelöst, um zuerst cloudbuild-tf-plan.yaml auszuführen. Dadurch wird Ihr Code mit Richtlinienprüfungen und dem Terraform-Plan anhand dieses Zweigs validiert. Dann führt cloudbuild-tf-apply.yaml terraform apply für das Ergebnis dieses Plans aus.
Terraform-Richtlinienprüfungen	Der Blueprint enthält eine Reihe von Einschränkungen für Open Policy-Agents, die durch die Richtlinienvalidierung in Google Cloud CLI erzwungen werden. Diese Einschränkungen definieren die zulässigen Ressourcenkonfigurationen, die von Ihrer Pipeline bereitgestellt werden können. Wenn ein Build die Richtlinie in der ersten Build-Konfiguration nicht erfüllt, stellt die zweite Build-Konfiguration keine Ressourcen bereit. Die im Blueprint erzwungenen Richtlinien werden von GoogleCloudPlatform/policy-library auf GitHub abgezweigt. Sie können zusätzliche Richtlinien für die Bibliothek schreiben, um benutzerdefinierte Richtlinien zu erzwingen, die Ihren Anforderungen entsprechen.
Prinzip der geringsten Berechtigung	Die Grundlagenpipeline hat für jede Phase ein anderes Dienstkonto mit einer Zulassungsrichtlinie, die nur die minimalen IAM-Rollen für diese Phase zuweist. Jeder Cloud Build-Trigger wird als das spezifische Dienstkonto für diese Phase ausgeführt. Die Verwendung unterschiedlicher Konten verringert das Risiko, dass sich Änderungen an einem Repository auf die Ressourcen auswirken können, die von einem anderen Repository verwaltet werden. Informationen zu den einzelnen IAM-Rollen, die auf jedes Dienstkonto angewendet werden, finden Sie im Terraform-Code sa.tf in der Bootstrap-Phase.
Private Cloud Build-Pools	Der Blueprint verwendet private Cloud Build-Pools. Mit privaten Pools können Sie optional zusätzliche Kontrollen erzwingen und beispielsweise den Zugriff auf öffentliche Repositories einschränken oder Cloud Build in einem VPC Service Controls-Perimeter ausführen.
Benutzerdefinierte Builder von Cloud Build	Der Blueprint erstellt einen eigenen benutzerdefinierten Builder, um Terraform auszuführen. Weitere Informationen finden Sie unter 0-bootstrap/Dockerfile. Diese Steuerung erzwingt, dass die Pipeline konsistent mit einem bekannten Satz von Bibliotheken in angepinnten Versionen ausgeführt wird.
Bereitstellungsgenehmigung	Optional können Sie eine manuelle Genehmigungsphase zu Cloud Build hinzufügen. Diese Genehmigung fügt einen zusätzlichen Prüfpunkt nach dem Auslösen, jedoch vor der Ausführung des Builds hinzu, damit ein berechtigter Nutzer den Build manuell genehmigen kann.

Verzweigungsstrategie

Wir empfehlen eine persistente Verzweigungsstrategie, um Code an Ihr Git-System zu senden und Ressourcen über die Grundlagenpipeline bereitzustellen. Im folgenden Diagramm wird die persistente Verzweigungsstrategie beschrieben.

Im Diagramm werden drei persistente Zweige in Git (Entwicklung, Nicht-Produktion und Produktion) beschrieben, die die entsprechenden Google Cloud-Umgebungen widerspiegeln. Es gibt auch mehrere sitzungsspezifische Feature-Zweige, die keinen Ressourcen entsprechen, die in Ihren Google Cloud-Umgebungen bereitgestellt sind.

Wir empfehlen, einen Pull-Anfrageprozess (PR) in Ihr Git-System zu erzwingen, damit jeder Code, der in einen persistenten Zweig zusammengeführt wird, eine genehmigte Pull-Anfrage hat.

Führen Sie die folgenden allgemeinen Schritte aus, um Code mit dieser persistenten Verzweigungsstrategie zu entwickeln:

1. Wenn Sie neue Funktionen entwickeln oder an einer Fehlerkorrektur arbeiten, erstellen Sie einen neuen Zweig basierend auf dem Entwicklungszweig. Verwenden Sie eine Namenskonvention für den Zweig, die die Art der Änderung, eine Ticketnummer oder eine andere Kennzeichnung sowie eine visuell lesbare Beschreibung wie feature/123456-org-policies enthält.
2. Wenn Sie die Arbeit im Feature-Zweig abschließen, öffnen Sie eine PR, die auf den Entwicklungszweig abzielt.
3. Wenn Sie die PR senden, löst die PR die Grundlagenpipeline aus, um terraform plan und terraform validate zum Staging und Prüfen der Änderungen auszuführen.
4. Nachdem Sie die Änderungen am Code validiert haben, führen Sie das Feature oder die Fehlerkorrektur im Entwicklungszweig zusammen.
5. Der Zusammenführungsprozess löst die Grundlagenpipeline aus, um terraform apply auszuführen, um die neuesten Änderungen im Entwicklungszweig in der Entwicklungsumgebung bereitzustellen.
6. Prüfen Sie die Änderungen in der Entwicklungsumgebung mit beliebigen manuellen Prüfungen, Funktionstests oder End-to-End-Tests, die für Ihren Anwendungsfall relevant sind. Stufen Sie dann Änderungen an der Nicht-Produktionsumgebung hoch, indem Sie eine PR öffnen, die auf den Nicht-Produktionszweig abzielt, und führen Sie Ihre Änderungen zusammen.
7. Zum Bereitstellen von Ressourcen in der Produktionsumgebung wiederholen Sie den gleichen Vorgang wie in Schritt 6: Überprüfen und validieren Sie die bereitgestellten Ressourcen, öffnen Sie eine PR für den Produktionszweig und führen Sie die Zusammenführung durch.

Nächste Schritte

• Best Practices für Vorgänge (nächstes Dokument in dieser Reihe)

Best Practices für Vorgänge

In diesem Abschnitt werden Vorgänge vorgestellt, die Sie für die Bereitstellung und den Betrieb zusätzlicher Arbeitslasten in der Google Cloud-Umgebung berücksichtigen müssen. In diesem Abschnitt werden nicht alle Vorgänge in Ihrer Cloud-Umgebung aufgelistet. Es werden jedoch Entscheidungen in Bezug auf die vom Blueprint bereitgestellten Architekturempfehlungen und -ressourcen vorgestellt.

Grundlagenressourcen aktualisieren

Der Blueprint bietet zwar einen übersichtlichen Ausgangspunkt für Ihre Grundlagenumgebung, doch können Ihre Grundlagenanforderungen im Laufe der Zeit wachsen. Nach der ersten Bereitstellung können Sie die Konfigurationseinstellungen anpassen oder neue freigegebene Dienste erstellen, die von allen Arbeitslasten genutzt werden sollen.

Zum Ändern von Grundlagenressourcen empfehlen wir, alle Änderungen über die Grundlagenpipeline vorzunehmen. Eine Einführung in den Ablauf des Schreibens und Zusammenführens von Code und Auslösen der Bereitstellungspipelines finden Sie unter Verzweigungsstrategie.

Attribute für neue Arbeitslastprojekte festlegen

Wenn Sie neue Projekte über das Projekt-Factory-Modul der Automatisierungspipeline erstellen, müssen Sie verschiedene Attribute konfigurieren. Der Prozess zum Entwerfen und Erstellen von Projekten für neue Arbeitslasten sollte Entscheidungen zu folgenden Themen enthalten:

• Welche Google Cloud APIs aktiviert werden sollen
• Welche freigegebene VPC verwendet werden soll oder ob ein neues VPC-Netzwerk erstellt werden soll
• Welche IAM-Rollen für das erste project-service-account erstellt werden sollen, die von der Pipeline erstellt wird
• Welche Projektlabels angewendet werden sollen
• Der Ordner, in dem das Projekt bereitgestellt wird
• Zu verwendendes Rechnungskonto
• Ob das Projekt einem VPC Service Controls-Perimeter hinzugefügt werden soll
• Ob ein Budget und ein Schwellenwert für Abrechnungsbenachrichtigungen für das Projekt konfiguriert werden sollen

Eine vollständige Referenz der konfigurierbaren Attribute für jedes Projekt finden Sie in den Eingabevariablen für das Projekt-Factory in der Automatisierungspipeline.

Berechtigungen in großem Umfang verwalten

Wenn Sie Arbeitslastprojekte zusätzlich zu Ihrer Grundlage bereitstellen, müssen Sie berücksichtigen, wie Sie den gewünschten Entwicklern und Nutzern dieser Projekte Zugriff gewähren. Wir empfehlen, Nutzer zu einer Gruppe hinzuzufügen, die von Ihrem vorhandenen Identitätsanbieter verwaltet wird, die Gruppen mit Cloud Identity zu synchronisieren und dann die IAM-Rollen auf die Gruppen anzuwenden. Beachten Sie immer das Prinzip der geringsten Berechtigung.

Wir empfehlen außerdem die Verwendung des IAM Recommenders, um Zulassungsrichtlinien zu ermitteln, die überprivilegierte Rollen gewähren. Entwerfen Sie einen Prozess, um Empfehlungen regelmäßig zu prüfen oder Empfehlungen automatisch auf Ihre Bereitstellungspipelines anzuwenden.

Änderungen zwischen dem Netzwerk- und dem Anwendungsteam

Bei den vom Blueprint bereitgestellten Netzwerktopologien wird davon ausgegangen, dass Sie ein Team für die Verwaltung von Netzwerkressourcen und separate Teams für die Bereitstellung von Arbeitslastinfrastrukturressourcen haben. Wenn die Arbeitslastteams die Infrastruktur bereitstellen, müssen sie Firewallregeln erstellen, um die beabsichtigten Zugriffspfade zwischen den Komponenten ihrer Arbeitslast zuzulassen. Sie sind jedoch nicht berechtigt, die Netzwerk-Firewallrichtlinien selbst zu ändern.

Planen Sie, wie Teams zusammenarbeiten, um die Änderungen an den zentralisierten Netzwerkressourcen zu koordinieren, die für die Bereitstellung von Anwendungen erforderlich sind. Sie können beispielsweise einen Prozess entwerfen, bei dem ein Arbeitslastteam Tags für seine Anwendungen anfordert. Das Netzwerkteam erstellt dann die Tags und fügt der Netzwerk-Firewallrichtlinie Regeln hinzu, die den Traffic zwischen Ressourcen mit den Tags ermöglichen, und delegiert die IAM-Rollen zur Verwendung der Tags an das Arbeitslastteam.

Umgebung mit dem Active Assist-Portfolio optimieren

Zusätzlich zum IAM-Recommender bietet Google Cloud das Active Assist-Portfolio von Diensten, um Empfehlungen zur Optimierung Ihrer Umgebung zu geben. Beispielsweise bieten Firewallstatistiken oder der Recommender für unbeaufsichtigte Projekte umsetzbare Empfehlungen zur Verbesserung des Sicherheitsstatus.

Entwerfen Sie einen Prozess, um Empfehlungen regelmäßig zu prüfen oder Empfehlungen automatisch auf Ihre Bereitstellungspipelines anzuwenden. Entscheiden Sie, welche Empfehlungen von einem zentralen Team verwaltet werden sollen und welche Verantwortung bei Arbeitslastinhabern liegt. Wenden Sie dann IAM-Rollen an, um entsprechend auf die Empfehlungen zuzugreifen.

Ausnahmen von Organisationsrichtlinien gewähren

Der Blueprint erzwingt eine Reihe von Einschränkungen für Organisationsrichtlinien, die den meisten Kunden in den meisten Szenarien empfohlen werden. Sie können jedoch auch legitime Anwendungsfälle haben, die nur begrenzte Ausnahmen von den Organisationsrichtlinien erfordern, die Sie umfassend erzwingen.

Mit dem Blueprint wird beispielsweise die Einschränkung iam.disableServiceAccountKeyCreation erzwungen. Diese Einschränkung ist eine wichtige Sicherheitskontrolle, da ein gehackter Dienstkontoschlüssel erhebliche negative Auswirkungen haben kann. In den meisten Szenarien sollten sicherere Alternativen zu Dienstkontoschlüsseln für die Authentifizierung verwendet werden. Es gibt jedoch Anwendungsfälle, die sich nur mit einem Dienstkontoschlüssel authentifizieren können, z. B. ein lokaler Server, der Zugriff auf Google Cloud-Dienste benötigt und die Workload Identity-Föderation nicht verwenden kann. In diesem Szenario können Sie eine Ausnahme von der Richtlinie zulassen, solange zusätzliche Kompensationskontrollen wie Best Practices für die Verwaltung von Dienstkontoschlüsseln erzwungen werden.

Daher sollten Sie einen Prozess für Arbeitslasten entwickeln, um eine Ausnahme von Richtlinien anzufordern, und dafür sorgen, dass die Entscheidungsträger, die für die Erteilung von Ausnahmen verantwortlich sind, über das technische Wissen zur Validierung des Anwendungsfalls und zur Beratung darüber verfügen, ob zusätzliche Steuerelemente vorhanden sein müssen, um einen Ausgleich zu schaffen. Wenn Sie einer Arbeitslast eine Ausnahme gewähren, legen Sie die Einschränkung der Organisationsrichtlinie so eng wie möglich fest. Sie können auch Organisationsrichtlinien Einschränkungen hinzufügen, indem Sie ein Tag definieren, das eine Ausnahme oder Erzwingung für Richtlinien gewährt, und das Tag dann auf Projekte und Ordner anwenden.

Ressourcen mit VPC Service Controls schützen

Der Blueprint hilft Ihnen, Ihre Umgebung für VPC Service Controls vorzubereiten, indem Sie die Basis- und eingeschränkten Netzwerke trennen. Standardmäßig aktiviert der Terraform-Code jedoch VPC Service Controls nicht, da diese Aktivierung einen störenden Prozess verursachen kann.

Ein Perimeter verweigert den Zugriff auf eingeschränkte Google Cloud-Dienste über Traffic, der von außerhalb des Perimeters stammt, einschließlich der Console, Entwickler-Workstations und der für die Bereitstellung von Ressourcen verwendeten Grundlagenpipeline. Wenn Sie VPC Service Controls verwenden, müssen Sie Ausnahmen für den Perimeter entwerfen, die die gewünschten Zugriffspfade zulassen.

Ein VPC Service Controls-Perimeter ist für Exfiltrationskontrollen zwischen Ihrer Google Cloud-Organisation und externen Quellen vorgesehen. Der Perimeter dient nicht dazu, Zulassungsrichtlinien für eine detaillierte Zugriffssteuerung auf einzelne Projekte oder Ressourcen zu ersetzen oder zu duplizieren. Wenn Sie einen Perimeter entwerfen und einrichten, empfehlen wir die Verwendung eines gemeinsamen einheitlichen Perimeters für einen geringeren Verwaltungsaufwand.

Wenn Sie mehrere Perimeter so gestalten müssen, dass sie den Diensttraffic innerhalb Ihrer Google Cloud-Organisation genau steuern, empfehlen wir, die Bedrohungen, die von einer komplexeren Perimeterstruktur behandelt werden, und die Zugriffspfade zwischen den Perimetern, die für beabsichtigte Vorgänge benötigt werden, anzugehen.

Prüfen Sie Folgendes, um VPC Service Controls zu übernehmen:

• Welche Ihrer Anwendungsfälle erfordern VPC Service Controls.

• Ob die erforderlichen Google Cloud-Dienste VPC Service Controls unterstützen

• Wie der Break-Glass-Zugriff konfiguriert werden soll, um den Perimeter zu ändern, falls er Ihre Automatisierungspipelines stört

• Best Practices für die Aktivierung von VPC Service Controls zum Entwerfen und Implementieren des Perimeters.

Nachdem der Perimeter aktiviert wurde, sollten Sie einen Prozess entwickeln, mit dem neue Projekte konsistent zum richtigen Perimeter hinzugefügt werden. Außerdem sollten Sie Ausnahmen planen, wenn Entwickler einen neuen Anwendungsfall haben, der von Ihrer aktuellen Perimeter-Konfiguration abgelehnt wird.

Organisationsweite Änderungen in einer separaten Organisation testen

Wir empfehlen, Änderungen in der Produktion niemals ohne Tests bereitzustellen. Bei Arbeitslastressourcen wird dieser Ansatz durch separate Umgebungen für Entwicklung, Nicht-Produktion und Produktion unterstützt. Einige Ressourcen in der Organisation haben jedoch keine separaten Umgebungen, um Tests zu ermöglichen.

Bei Änderungen auf Organisationsebene oder anderen Änderungen, die sich auf Produktionsumgebungen wie die Konfiguration zwischen Ihrem Identitätsanbieter und Cloud Identity auswirken können, sollten Sie eine separate Organisation zu Testzwecken erstellen.

Remotezugriff auf virtuelle Maschinen steuern

Da wir empfehlen, die unveränderliche Infrastruktur über die Grundlagenpipeline, die Infrastrukturpipeline und die Anwendungspipeline bereitzustellen, empfehlen wir Ihnen außerdem, Entwicklern nur eingeschränkten Zugriff auf eine virtuelle Maschine über SSH oder RDP für außergewöhnliche Anwendungsfälle zu gewähren.

Für Szenarien, die einen Remotezugriff erfordern, empfehlen wir, den Nutzerzugriff nach Möglichkeit mit OS Login zu verwalten. Bei diesem Ansatz werden verwaltete Google Cloud-Dienste verwendet, um Zugriffssteuerung, Verwaltung des Kontolebenszyklus, Bestätigung in zwei Schritten und Audit-Logging zu erzwingen. Wenn Sie den Zugriff über SSH-Schlüssel in Metadaten oder RDP-Anmeldedaten zulassen müssen, liegt es in Ihrer Verantwortung, den Lebenszyklus von Anmeldedaten zu verwalten und Anmeldedaten sicher außerhalb von Google Cloud zu speichern.

In jedem Szenario kann ein Nutzer mit SSH- oder RDP-Zugriff auf eine VM ein Risiko für die Rechteausweitung sein. Berücksichtigen Sie dies bei der Entwicklung Ihres Zugriffsmodells. Der Nutzer kann Code auf dieser VM mit den Berechtigungen des zugehörigen Dienstkontos ausführen oder den Metadatenserver abfragen, um das Zugriffstoken aufzurufen, das zur Authentifizierung von API-Anfragen verwendet wird. Dieser Zugriff kann dann eine Rechteausweitung sein, wenn der Nutzer absichtlich nicht mit den Berechtigungen des Dienstkontos arbeiten möchte.

Budgetüberschreitungen durch Planung von Budgetbenachrichtigungen minimieren

Der Blueprint implementiert Best Practices, die im Google Cloud-Architektur-Framework: Kostenoptimierung eingeführt wurden, um die Kosten zu verwalten, darunter:

• Verwenden Sie ein einziges Rechnungskonto für alle Projekte in der Unternehmensgrundlage.

• Weisen Sie jedem Projekt ein Metadatenlabel billingcode zu, mit dem Kosten zwischen Kostenstellen zugewiesen werden.

• Budgets und Schwellenwerte für Benachrichtigungen festlegen

Es liegt in Ihrer Verantwortung, Budgets zu planen und Abrechnungsbenachrichtigungen zu konfigurieren. Der Blueprint erstellt Budgetbenachrichtigungen für Arbeitslastprojekte, wenn die prognostizierten Ausgaben bei 120% des Budgets liegen. Mit diesem Ansatz kann ein zentrales Team Vorfälle mit erheblichen Budgetüberschreitungen identifizieren und minimieren. Erhebliche unerwartete Ausgabenerhöhungen ohne klare Ursache können ein Indikator für einen Sicherheitsvorfall sein und sollten aus Sicht der Kostenkontrolle und -sicherheit untersucht werden.

Hinweis: Budgetbenachrichtigungen decken einen anderen Typ von Benachrichtigungen ab als die Abrechnungskategorie der wichtigen Kontakte. Budgetbenachrichtigungen beziehen sich auf den Verbrauch der Budgets, die Sie für jedes Projekt definieren. Abrechnungsbenachrichtigungen von „Wichtige Kontakte“ beziehen sich auf Preisaktualisierungen, Fehler und Gutschriften.

Je nach Anwendungsfall können Sie ein Budget festlegen, das auf den Kosten eines gesamten Umgebungsordners oder allen Projekten im Zusammenhang mit einer bestimmten Kostenstelle basiert, anstatt für jedes Projekt detaillierte Budgets festzulegen. Außerdem empfehlen wir, Budget und Benachrichtigungseinstellung an Arbeitslastinhaber zu delegieren, die einen detaillierteren Schwellenwert für Benachrichtigungen für ihre tägliche Überwachung festlegen könnten.

Eine Anleitung zum Erstellen von FinOps-Funktionen, einschließlich der Prognose von Budgets für Arbeitslasten, finden Sie unter Erste Schritte mit FinOps in Google Cloud.

Kosten zwischen internen Kostenstellen zuordnen

Mit der Console können Sie Ihre Abrechnungsberichte aufrufen, um Kosten in mehreren Dimensionen aufzurufen und zu prognostizieren. Zusätzlich zu den vordefinierten Berichten empfehlen wir, dass Sie Abrechnungsdaten in ein BigQuery-Dataset im Projekt prj-c-billing-logs exportieren. Mit den exportierten Abrechnungseinträgen können Sie benutzerdefinierte Dimensionen, z. B. Ihre internen Kostenstellen, basierend auf Projektlabel-Metadaten wie billingcode zuweisen.

Die folgende SQL-Abfrage ist eine Beispielabfrage, um die Kosten für alle Projekte zu verstehen, die nach dem Projektlabel billingcode gruppiert sind.

#standardSQL
SELECT
   (SELECT value from UNNEST(labels) where key = 'billingcode') AS costcenter,
   service.description AS description,
   SUM(cost) AS charges,
   SUM((SELECT SUM(amount) FROM UNNEST(credits))) AS credits
FROM PROJECT_ID.DATASET_ID.TABLE_NAME
GROUP BY costcenter, description
ORDER BY costcenter ASC, description ASC

Informationen zum Einrichten dieses Exports finden Sie unter Cloud Billing-Daten in BigQuery exportieren.

Wenn Sie interne Buchhaltung oder Rückbuchung zwischen Kostenstellen benötigen, sind Sie dafür verantwortlich, die aus dieser Abfrage abgerufenen Daten in Ihre internen Prozesse einzubinden.

Ergebnisse aus Aufdeckungskontrollen in Ihr vorhandenes SIEM aufnehmen

Die Grundlagenressourcen helfen Ihnen zwar beim Konfigurieren aggregierter Ziele für Audit-Logs und Sicherheitsergebnisse, doch liegt es in Ihrer Verantwortung, zu entscheiden, wie Sie diese Signale nutzen und verwenden.

Wenn Sie Logs aus allen Cloud- und lokalen Umgebungen in einem vorhandenen SIEM aggregieren müssen, entscheiden Sie, wie Sie Logs aus dem prj-c-logging-Projekt und Ergebnissen aus Security Command Center in Ihre vorhandenen Tools und Prozesse aufnehmen möchten. Sie können einen einzelnen Export für alle Logs und Ergebnisse erstellen, wenn ein einzelnes Team für die Überwachung der Sicherheit in Ihrer gesamten Umgebung verantwortlich ist, oder Sie können mehrere Exporte erstellen, die nach den Logs und Ergebnissen gefiltert sind, die für mehrere Teams mit unterschiedlichen Verantwortlichkeiten erforderlich sind.

Wenn das Logvolumen und die Kosten unerschwinglich sind, können Sie Duplikate vermeiden, indem Sie Google Cloud-Logs und -Ergebnisse nur in Google Cloud aufbewahren. Sorgen Sie in diesem Szenario dafür, dass Ihre vorhandenen Teams den richtigen Zugriff und die richtigen Schulungen haben, um direkt mit Logs und Ergebnissen in Google Cloud zu arbeiten.

• Erstellen Sie für Audit-Logs Logansichten, um einzelnen Teams Zugriff auf eine Teilmenge von Logs in einem zentralisierten Log-Bucket zu gewähren, anstatt Logs in mehrere Buckets zu duplizieren, wodurch die Log-Speicherkosten erhöht werden.
• Gewähren Sie aus Sicherheitsgründen Rollen auf Ordner- und Projektebene für Security Command Center, damit Teams Sicherheitsergebnisse nur für die Projekte, für die sie zuständig sind, direkt in der Console aufrufen und verwalten können.

Kontinuierliche Entwicklung der Bibliothek für Kontrollen

Der Blueprint beginnt mit einer Referenz der Kontrollen, um Bedrohungen zu erkennen und zu verhindern. Wir empfehlen Ihnen, diese Kontrollen zu prüfen und je nach Ihren Anforderungen zusätzliche Kontrollen hinzuzufügen. In der folgenden Tabelle sind die Mechanismen zur Durchsetzung von Governance-Richtlinien und deren Erweiterung für zusätzliche Anforderungen zusammengefasst:

Durch den Blueprint erzwungene Richtlinienkontrollen	Anleitung zum Erweitern dieser Kontrollen
Security Command Center erkennt Sicherheitslücken und Bedrohungen aus mehreren Sicherheitsquellen.	Definieren Sie benutzerdefinierte Module für Security Health Analytics und benutzerdefinierte Module für Event Threat Detection.
Der Organisationsrichtliniendienst erzwingt eine empfohlene Reihe von Einschränkungen für Organisationsrichtlinien für Google Cloud-Dienste.	Erzwingen Sie zusätzliche Einschränkungen aus der vordefinierten Liste verfügbarer Einschränkungen oder erstellen Sie benutzerdefinierte Einschränkungen.
Die OPA-Richtlinie (Open Policy Agent) validiert Code in der Grundlagenpipeline für akzeptable Konfigurationen vor der Bereitstellung.	Entwickeln Sie zusätzliche Einschränkungen basierend auf der Anleitung unter GoogleCloudPlatform/policy-library.
Benachrichtigungen zu logbasierten Messwerten und Leistungsmesswerten konfigurieren logbasierte Messwerte, um Benachrichtigungen über Änderungen an IAM-Richtlinien und Konfigurationen einiger vertraulicher Ressourcen zu senden.	Entwerfen Sie zusätzliche logbasierte Messwerte und Benachrichtigungsrichtlinien für Logereignisse, die nicht in Ihrer Umgebung auftreten sollten.
Eine benutzerdefinierte Lösung für die automatisierte Loganalyse fragt Logs regelmäßig nach verdächtigen Aktivitäten ab und erstellt Ergebnisse von Security Command Center.	Schreiben Sie zusätzliche Abfragen, um Ergebnisse für Sicherheitsereignisse zu erstellen, die Sie überwachen möchten. Verwenden Sie dazu Sicherheitsloganalysen als Referenz.
Eine benutzerdefinierte Lösung zur Reaktion auf Asset-Änderungen erstellt Ergebnisse von Security Command Center und kann Abhilfemaßnahmen automatisieren.	Erstellen Sie zusätzliche Cloud Asset Inventory-Feeds, um Änderungen für bestimmte Asset-Typen zu überwachen, und schreiben Sie zusätzliche Cloud Functions-Funktionen mit benutzerdefinierter Logik, um auf Richtlinienverstöße zu reagieren.

Diese Kontrollen können sich ändern, wenn sich Ihre Anforderungen und Google Cloud-Reife ändern.

Verschlüsselungsschlüssel mit dem Cloud Key Management Service verwalten

Google Cloud bietet für alle Kundeninhalte eine Standardverschlüsselung inaktiver Daten, aber auch Cloud Key Management Service (Cloud KMS), um Ihnen zusätzliche Kontrolle über Ihre Verschlüsselungsschlüssel für inaktive Daten zu bieten. Wir empfehlen Ihnen, zu prüfen, ob die Standardverschlüsselung ausreicht oder ob Sie Compliance-Anforderungen haben, sodass Sie Cloud KMS selbst verwalten müssen. Weitere Informationen finden Sie unter Entscheiden, wie Sie Compliance-Anforderungen für die Verschlüsselung inaktiver Daten erfüllen.

Der Blueprint stellt ein prj-c-kms-Projekt im gemeinsamen Ordner und ein prj-{env}-kms-Projekt in jedem Umgebungsordner zur Verwaltung der Verschlüsselungsschlüssel zentral bereit. Mit diesem Ansatz kann ein zentrales Team Verschlüsselungsschlüssel prüfen und verwalten, die von Ressourcen in Arbeitslastprojekten verwendet werden, um regulatorische und Compliance-Anforderungen zu erfüllen.

Je nach operativem Modell möchten Sie möglicherweise eine einzelne zentralisierte Projektinstanz von Cloud KMS unter der Kontrolle eines einzelnen Teams verwenden, oder Sie möchten Verschlüsselungsschlüssel separat in jeder Umgebung verwalten oder Sie bevorzugen möglicherweise mehrere verteilte Instanzen, damit die Rechenschaftspflicht für Verschlüsselungsschlüssel an die entsprechenden Teams delegiert werden kann Ändern Sie das Terraform-Codebeispiel nach Bedarf entsprechend Ihrem operativen Modell.

Optional können Sie Organisationsrichtlinien für vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEKs) erzwingen, um zu erzwingen, dass bestimmte Ressourcentypen immer einen CMEK-Schlüssel erfordern und dass nur CMEK-Schlüssel aus einer Zulassungsliste vertrauenswürdiger Projekte verwendet werden können.

Anmeldedaten von Anwendungen mit Secret Manager speichern und prüfen

Wir empfehlen, keine vertraulichen Secrets (z. B. API-Schlüssel, Passwörter und private Zertifikate) an Quellcode-Repositories zu übergeben. Übertragen Sie stattdessen das Secret an Secret Manager und weisen Sie dem Nutzer oder Dienstkonto, das auf das Secret zugreifen muss, die IAM-Rolle Zugriffsfunktion für Secret Manager-Secret zu. Wir empfehlen, die IAM-Rolle einem einzelnen Secret zuzuweisen, nicht allen Secrets im Projekt.

Nach Möglichkeit sollten Sie Produktions-Secrets automatisch in den CI/CD-Pipelines generieren und für Nutzer unzugänglich aufbewahren, außer in Break-Glass-Situationen. Achten Sie in diesem Szenario darauf, keine IAM-Rollen zum Anzeigen dieser Secrets für Nutzer oder Gruppen zuzuweisen.

Der Blueprint stellt ein einzelnes prj-c-secrets-Projekt im gemeinsamen Ordner und ein prj-{env}-secrets-Projekt in jedem Umgebungsordner bereit, um Secrets zentral zu verwalten. Mit diesem Ansatz kann ein zentrales Team Secrets prüfen und verwalten, die von Anwendungen verwendet werden, um regulatorische und Compliance-Anforderungen zu erfüllen.

Je nach operativem Modell können Sie eine einzelne zentralisierte Instanz von Secret Manager unter der Kontrolle eines einzelnen Teams verwenden oder Secrets in jeder Umgebung separat verwalten oder mehrere verteilte Instanzen von Secret Manager bevorzugen, damit jedes Arbeitslastteam seine eigenen Secrets verwalten kann. Ändern Sie das Terraform-Codebeispiel nach Bedarf entsprechend Ihrem operativen Modell.

Break-Glass-Zugriff auf Konten mit umfangreichen Berechtigungen planen

Wir empfehlen zwar, Änderungen an Grundlagenressourcen über einen versionierten IaC zu verwalten, der von der Grundlagenpipeline bereitgestellt wird, doch kann es außergewöhnliche oder Notfallszenarien geben, die einen privilegierten Zugriff zum direkten Ändern Ihrer Umgebung erfordern. Wir empfehlen, Break-Glass-Konten (manchmal auch als Firecall- oder Notfallkonten bezeichnet) mit hohem privilegierten Zugriff auf Ihre Umgebung zu planen, wenn ein Notfall eintritt oder die Automatisierungsprozesse unterbrochen werden.

In der folgenden Tabelle werden einige Beispielzwecke für Break-Glass-Konten beschrieben.

Break-Glass-Zweck	Beschreibung
Super Admin	Notfallzugriff auf die Rolle Super Admin, die mit Cloud Identity verwendet wird, um beispielsweise Probleme im Zusammenhang mit der Identitätsföderation oder Multi-Faktor-Authentifizierung zu beheben (MFA).
Organisationsadministrator	Notfallzugriff auf die Rolle Organisationsadministrator, der dann Zugriff auf jede andere IAM-Rolle in der Organisation gewähren kann.
Foundation-Pipeline-Administrator	Notfallzugriff zum Ändern der Ressourcen in Ihrem CICD-Projekt in Google Cloud und im externen Git-Repository für den Fall, dass die Automatisierung der Grundlagenpipeline fehlschlägt.
Operations oder SRE	Ein Betriebs- oder SRE-Team benötigt privilegierten Zugriff, um auf Ausfälle oder Vorfälle zu reagieren. Dies kann Aufgaben wie den Neustart von VMs oder die Wiederherstellung von Daten umfassen.

Ihr Mechanismus für den Zugriff auf Break-Glass hängt von den vorhandenen Tools und Verfahren ab. Einige Beispielmechanismen sind:

• Verwenden Sie Ihre vorhandenen Tools für die privilegierte Zugriffsverwaltung, um einen Nutzer vorübergehend einer Gruppe hinzuzufügen, die mit IAM-Rollen mit hohen Berechtigungen vordefiniert ist, oder verwenden Sie die Anmeldedaten eines Kontos mit umfangreichen Berechtigungen.
• Stellen Sie Konten vorab nur für Administratoren bereit. Zum Beispiel könnte die Entwicklerin Dana die Identität "[e-mail]" für die tägliche Verwendung und die Rolle "[e-mail]" für den Zugriff auf Break-Glass haben.
• Verwenden Sie eine Anwendung wie den privilegierten Just-in-Time-Zugriff, mit der Entwickler privilegierte Rollen selbst eskalieren können.

Unabhängig vom verwendeten Mechanismus sollten Sie sich überlegen, wie Sie die folgenden Fragen im Betrieb beantworten:

• Wie entwerfen Sie den Umfang und den Detaillierungsgrad des Break-Glass-Zugriffs? Beispielsweise können Sie für unterschiedliche Geschäftseinheiten unterschiedliche Break-Glass-Mechanismen entwerfen, damit diese sich nicht gegenseitig stören.
• Wie verhindert der Mechanismus Missbrauch? Benötigen Sie Genehmigungen? Beispiel: Sie haben möglicherweise aufgeteilte Vorgänge, bei denen eine Person Anmeldedaten enthält und eine andere Person das MFA-Token enthält.
• Wie prüfen und melden Sie den Zugriff auf Break-Glass? Sie können beispielsweise ein benutzerdefiniertes Event Threat Detection-Modul konfigurieren, um bei Verwendung eines vordefinierten Break-Glass-Kontos ein Sicherheitsergebnis zu erstellen.
• Wie entfernen Sie den Zugriff auf Break-Glass und setzen normale Vorgänge fort, nachdem der Vorfall beendet ist?

Für allgemeine Aufgaben zur Rechteausweitung und das Rollback von Änderungen empfehlen wir, automatisierte Workflows zu entwerfen, bei denen ein Nutzer den Vorgang ausführen kann, ohne dass eine Rechteausweitung für die Nutzeridentität erforderlich ist. Dieser Ansatz kann dabei helfen, menschliche Fehler zu reduzieren und die Sicherheit zu verbessern.

Für Systeme, die regelmäßig Eingriffe erfordern, ist die Automatisierung der Korrektur möglicherweise die beste Lösung. Google empfiehlt Kunden einen Zero-Touch-Produktionsansatz, um alle Produktionsänderungen mithilfe von Automatisierung, sicheren Proxys oder geprüften Break-Glass vorzunehmen. Google bietet die SRE-Bücher für Kunden an, die den SRE-Ansatz von Google verwenden möchten.

Nächste Schritte

• Lesen Sie Blueprint bereitstellen (nächstes Dokument in dieser Reihe).

Blueprint bereitstellen

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 übergeordneten Aufgaben aus, die in diesem Abschnitt zusammengefasst sind, um Ihre eigene Unternehmensgrundlage gemäß 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: Erstellen Sie ein Cloud Identity-Konto und bestätigen Sie die Domaininhaberschaft. Fordern Sie ein Rechnungskonto mit monatlicher Abrechnung bei Ihrem Google Cloud-Vertriebsteam an 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“ für die Synchronisierung von Nutzerkonten und SSO. 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 Ihr Tool zur Verwaltung des Quellcodes aus. Die Anleitung für terraform-example-foundation wird in ein Git-Repository geschrieben, das in Cloud Source Repositories gehostet wird. Legen Sie Ihre CI/CD-Automatisierungstools fest. Die terraform-example-foundation bietet unterschiedliche Anleitungen für verschiedene Automatisierungstools. Bereiten Sie Folgendes vor, um eine Verbindung zu einer vorhandenen lokalen Umgebung herzustellen: Planen Sie die Zuweisung von IP-Adressen anhand der Anzahl und Größe der Bereiche, die für den Blueprint erforderlich sind. Bestellen Sie die 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. Bei Verwendung eines Selfservice-Rechnungskontos 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.
Zusätzliche Schritte nach der IaC-Bereitstellung	Führen Sie nach der Bereitstellung des Terraform-Codes folgende Schritte aus: Schließen Sie die lokalen Konfigurationsänderungen ab. Aktivieren Sie Security Command Center Premium. Exportieren Sie Cloud Billing-Daten nach BigQuery. Registrieren Sie sich für einen Cloud Customer Care-Plan. 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. Lesen Sie die Best Practices für den Betrieb und planen Sie, wie Sie Ihre vorhandenen Vorgänge und Funktionen mit den Grundlagenressourcen verbinden.

Zusätzliche Verwaltungsfunktionen für Kunden mit sensiblen Arbeitslasten

Google Cloud bietet zusätzliche Verwaltungsfunktionen, 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. In diesem Abschnitt werden nicht alle Sicherheitskontrollen beschrieben, die Sie auf bestimmte Arbeitslasten anwenden können. Weitere Informationen zu den Sicherheitsprodukten und -lösungen von Google finden Sie im Best Practices-Center für Sicherheit in Google Cloud.

Prüfen Sie anhand der Compliance-Anforderungen, der Risikobereitschaft und der Vertraulichkeit von 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 ausführen, um ihn zu entwerfen und zu aktivieren.
Ressourcenstandorte einschränken	Möglicherweise bestehen für Sie rechtliche Bestimmungen, dass Cloud-Ressourcen nur an zugelassenen 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 Bestimmungen erfüllen können. Der Blueprint bietet optionale Variablen in der Bereitstellungspipeline zur 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, die Datenzugriffslogs erfordern. Aktivieren Sie außerdem 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 Betriebsprozess, der zur 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. Evaluieren Sie die Kosten und den operativen Aufwand im Zusammenhang mit Key Access Justifications sowie ihre 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 für eine konfigurierbare Workstation-Option in Ihrer eigenen Umgebung bewerten.
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ürdigen IP-Adressbereichen und Gerätebestätigung einschränken. Für einige Attribute ist ein zusätzliches Abo für BeyondCorp Enterprise erforderlich. Prüfen Sie die Zugriffsmuster, denen Sie für den Zugriff auf webbasierte Anwendungen wie die Console als Teil einer größeren Zero-Trust-Bereitstellung vertrauen.

Namenskonventionen

Wir empfehlen, für Ihre Google Cloud-Ressourcen eine standardisierte Namenskonvention zu verwenden. In der folgenden Tabelle werden empfohlene 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 (b, c, p, n, d oder net). Hostprojekte von freigegebenen VPCs verwenden den environmentcode der zugehörigen Umgebung. Projekte für Netzwerkressourcen, die von allen Umgebungen gemeinsam genutzt werden, z. B. das Projekt interconnect, verwenden den Umgebungscode net. 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 alphanumerische vierstellige 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 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 ein Erreichen der Zeichenbeschränkung 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 eine Überschreitung der 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 enthält 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 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 eine Überschreitung der 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 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 eine Überschreitung der 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	[e-mail] Dabei sind description zusätzliche Informationen zur Gruppe. Sie können kurze, visuell lesbare Abkürzungen verwenden. Beispiel: [e-mail]
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	[e-mail] 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: [e-mail]
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, wobei 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 die Rechenschaftspflicht
Organisationsrichtlinien: Der Blueprint erzwingt alle Einschränkungen für Organisationsrichtlinien auf dem Organisationsknoten.	Möglicherweise haben Sie unterschiedliche Sicherheitsrichtlinien oder Arbeitsweisen für verschiedene Teile des Unternehmens. In diesem Szenario erzwingen Sie 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 zum Ausführen der Automatisierungspipeline.	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: Der Blueprint verwendet Cloud Source Repositories als verwaltetes privates Git-Repository.	Sie können Ihr bevorzugtes Versionsverwaltungssystem zum Verwalten von Code-Repositories wie GitLab, GitHub oder Bitbucket verwenden. 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 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 Einschränkungen mit unterstützten Diensten.
Mehrere Regionen: Mit dem Blueprint werden regionale Ressourcen in zwei verschiedenen Google Cloud-Regionen bereitgestellt, 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 mehr Google Cloud-Regionen konfigurieren, um Ressourcen näher am Endnutzer zu erstellen und dabei eine geringere Latenz zu erzielen. Wenn Sie Einschränkungen hinsichtlich der Datenhoheit 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 stellt eine Reihe von IP-Adressbereichen bereit.	Möglicherweise müssen Sie die spezifischen IP-Adressbereiche ändern, die basierend auf der Verfügbarkeit der IP-Adresse in der vorhandenen Hybridumgebung verwendet werden. 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 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 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 Sie ein einzelnes Team haben, das für die Verwaltung und Prüfung vertraulicher Secrets in der gesamten Organisation verantwortlich ist, können Sie nur ein einziges Projekt zur Verwaltung des Zugriffs auf Secrets verwenden. Wenn Sie Arbeitslast-Teams erlauben, ihre eigenen Secrets zu verwalten, verwenden Sie möglicherweise kein zentrales Projekt zur Verwaltung des Zugriffs auf Secrets. Stattdessen können 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 für die Verwaltung und Prüfung der Verschlüsselungsschlüssel im gesamten Unternehmen zuständig ist, können Sie 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.
Monitoring-Scoping-Projekte: Der Blueprint konfiguriert ein einzelnes Monitoring-Scoping-Projekt für jede Umgebung.	Sie können detailliertere Bereichsprojekte konfigurieren, die von verschiedenen Teams verwaltet werden und sich auf die Gruppe von Projekten beziehen, die die von jedem Team verwalteten Anwendungen enthalten.
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 akzeptieren, um sie vor der Projekterstellung zu überprüfen und zu genehmigen, oder das Team kann die Pull-Anfrage selbst als Reaktion auf ein Ticketsystem erstellen. Unter Umständen 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: Der Blueprint verwaltet alle Sicherheitsergebnisse in Security Command Center.	Entscheiden Sie, ob Sie Sicherheitsergebnisse aus Security Command Center in Tools wie Chronicle 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

• Implementieren Sie den Blueprint mithilfe der Terraform-Beispielgrundlage auf GitHub.
• Weitere Informationen zu Best Practices für Design-Prinzipien finden Sie im Google Cloud-Architektur-Framework.

• Prüfen Sie die Bibliothek mit Blueprints, um das Design und den Build gängiger Unternehmensarbeitslasten zu beschleunigen. Dazu gehören:

  • Daten aus Google Cloud in ein gesichertes BigQuery-Data Warehouse importieren

  • Daten aus einem externen Netzwerk in ein gesichertes BigQuery-Data Warehouse importieren

  • Mit Cloud Functions eine sichere serverlose Architektur bereitstellen

  • Mit Cloud Run eine sichere serverlose Architektur bereitstellen

• Erhalten Sie weitere Informationen zu ähnlichen Lösungen zur Bereitstellung in der Grundlagenumgebung.

• Wenn Sie Zugriff auf eine Demoumgebung erhalten möchten, kontaktieren Sie uns unter [e-mail].