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 Als PDF speichern 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 Cloudbereitstellen können. Eine Cloud-Grundlage ist die Basis für Ressourcen, Konfigurationen und Funktionen, mit denen UnternehmenGoogle Cloud für ihre Geschäftsanforderungen nutzen können. Eine gut konzipierte Grundlage ermöglicht eine einheitliche 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 Cloudbereitstellen.

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 Cloudverantwortlich sind. Dieser Blueprint besteht aus folgenden Elementen:

• Ein GitHub-Repository für 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 in diesem Leitfaden als Ausgangspunkt verwenden und die Umgebung dann an die spezifischen Anforderungen Ihres Unternehmens anpassen.
• Vorhandene Umgebung in Google Cloudprüfen. Sie können bestimmte Komponenten Ihres Designs mit den von Google empfohlenen Best Practices vergleichen.

Unterstützte Anwendungsfälle

Der Blueprint zur Unternehmensbasis bietet eine grundlegende Ebene von Ressourcen und Konfigurationen, mit denen Sie alle Arten von Arbeitslasten in Google Cloudaktivieren können. Egal, ob Sie vorhandene Computing-Arbeitslasten zu Google Cloudmigrieren, 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 Google-Infrastruktur. Sie sind dafür verantwortlich, die Sicherheit in die Systeme zu integrieren, die Sie auf Google Cloudaufbauen. 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 IhreGoogle 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 IaC-Validierung (Infrastructure-as-Code) in Ihrer Pipeline und in den Einschränkungen der Organisationsrichtlinien.
• Architekturkontrollen sind die Konfiguration von Google Cloud Ressourcen wie Netzwerken 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 architektonischen Entscheidungen des Blueprints zusammengefasst.

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

• Cloud Build:Infrastrukturressourcen werden mit einem 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. Außerdem werden in der Pipeline Policy-as-Code-Prüfungen erzwungen, um vor der Bereitstellung zu prüfen, ob die Ressourcen den erwarteten Konfigurationen entsprechen.
• Cloud Identity:Nutzer und Gruppenmitgliedschaften werden über Ihren 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 Lesezugriff auf die Foundation-Ressourcen zu erhalten. Alle Änderungen an Foundation-Ressourcen werden über die CI/CD-Pipeline bereitgestellt, die bevollmächtigte Dienstkontoidentitäten verwendet.
• Resource Manager:Alle Ressourcen werden in einer einzigen Organisation verwaltet. Dabei wird eine Ressourcenhierarchie von Ordnern verwendet, in der Projekte nach Umgebungen organisiert werden. Projekte werden mit Metadaten für die Verwaltung versehen, 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 für die Sicherheit und Prüfung relevante Logs in einem zentralisierten Projekt zur langfristigen Aufbewahrung, Analyse und für den Export in externe Systeme erfasst werden.
• Organization Policy Service: Einschränkungen für Organisationsrichtlinien sind dafür konfiguriert, verschiedene Konfigurationen mit hohem Risiko zu verhindern.
• Secret Manager:Zentrale Projekte werden für ein Team erstellt, das für die Verwaltung und Prüfung der Verwendung vertraulicher Anwendungs-Secrets verantwortlich ist, um Compliance-Anforderungen zu erfüllen.
• Cloud Key Management Service (Cloud KMS): Zentrale Projekte werden für ein Team erstellt, das für die Verwaltung und Prüfung von Verschlüsselungsschlüsseln verantwortlich ist, um 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 wichtigen Entscheidungen 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, mit denen Ihre Mitarbeiter auf Google Cloud-Dienste zugreifen.

Externer Identitätsanbieter als „Source of Truth“

Wir empfehlen, Ihr Cloud Identity-Konto mit Ihrem vorhandenen Identitätsanbieter zu föderieren. Mit Föderation wird sichergestellt, dass Ihre vorhandenen Kontoverwaltungsprozesse auf Google Cloud und andere Google-Dienste angewendet werden.

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 einen 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 für die Bereitstellung von Identitäten an Cloud Identity.
• Nutzer, die versuchen, sich in Google-Diensten anzumelden, werden zum externen Identitätsanbieter für Einmalanmeldung (SSO) mit SAML weitergeleitet, wobei ihre vorhandenen Anmeldedaten zur Authentifizierung verwendet werden. Es werden keine Passwörter mit Cloud Identity synchronisiert.

Die folgende Tabelle enthält Links zu Einrichtungsanleitungen für Identitätsanbieter.

Identitätsanbieter	Anleitung
Active Directory	Active Directory-Nutzerkonten bereitstellen Active Directory-Einmalanmeldung (SSO)
Microsoft Entra ID (früher Azure AD)	Föderieren Google Cloud mit Microsoft Entra ID
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 Föderierung vonGoogle 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 durch den Terraform-Code in diesem Blueprint automatisiert. Unter Verwaltungsfunktionen für Cloud Identity finden Sie die empfohlenen Sicherheitseinstellungen, die Sie zusätzlich zur Bereitstellung des Terraform-Codes konfigurieren müssen.

Gruppen für die Zugriffssteuerung

Ein Hauptkonto ist eine Identität, der Zugriff auf eine Ressource gewährt werden kann. Hauptkonto umfassen Google-Konten für Nutzer, Google-Gruppen, Google Workspace-Konten, Cloud Identity-Domains und Dienstkonten. Bei 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.

Wenn Sie IAM-Rollen in großem Umfang verwalten möchten, sollten Sie Nutzer basierend auf ihren Aufgabenbereichen und Zugriffsanforderungen Gruppen zuweisen. Gewähren Sie dann IAM-Rollen für diese Gruppen. Sie sollten Nutzer mithilfe der Prozesse in Ihrem vorhandenen Identitätsanbieter zur Gruppenerstellung und -mitgliedschaft hinzufügen.

Wir empfehlen nicht, einzelnen Nutzern IAM-Rollen zu gewähren, da die Verwaltung und Prüfung von Rollen durch individuelle Zuweisungen erschwert werden kann.

Im Blueprint werden Gruppen und Rollen für den Lesezugriff auf die Foundation-Ressourcen konfiguriert. 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.

In der folgenden Tabelle sind die Gruppen aufgeführt, die vom Blueprint für die Anzeige von Ressourcen der Foundation konfiguriert werden.

Name	Beschreibung	Rollen	Umfang
[e-mail]	Administratoren mit umfangreichen Berechtigungen, die IAM-Rollen auf Organisationsebene zuweisen können. Sie können auf jede andere Rolle zugreifen. Dieses Berechtigung wird für die tägliche Nutzung nicht empfohlen.	Administrator der Organisation	Organisation
[e-mail]	Stark privilegierte Administratoren, die das Cloud-Rechnungskonto ändern können. Dieses Berechtigung wird für die tägliche Nutzung nicht empfohlen.	Rechnungskontoadministrator	Organisation
[e-mail]	Das Team, das für die Prüfung der Ausgaben in allen Projekten verantwortlich ist.	Rechnungskonto-Betrachter	Organisation
		BigQuery-Nutzer	Abrechnungsprojekt
[e-mail]	Das Team, das für die Prüfung sicherheitsrelevanter Logs verantwortlich ist.	Loganzeige BigQuery-Nutzer	Logging-Projekt
[e-mail]	Das Team, das für die Prüfung der Cloudsicherheit verantwortlich ist.	Sicherheitsprüfer	Organisation
[e-mail]	Das Team, das für die Anzeige und Pflege von Netzwerkkonfigurationen verantwortlich ist.	Compute-Netzwerkbetrachter	Organisation
[e-mail]	Das Team, das für die Konfiguration von Security Command Center verantwortlich ist.	Sicherheitscenter-Administratorbearbeiter	Organisation
[e-mail]	Das Team, das für die Verwaltung, Speicherung und Prüfung von Anmeldedaten und anderen Geheimnissen verantwortlich 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.

Wir empfehlen dringend, einfache Rollen wie „Inhaber“, „Bearbeiter“ oder „Betrachter“ zu vermeiden und stattdessen vordefinierte Rollen zu verwenden. Einfache Rollen gewähren zu viele Berechtigungen 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, siehe 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 auch bei einer SSO-Fehlkonfiguration oder einem Ausfall weiterhin auf die Cloud Identity-Konsole zugreifen kann. Sie müssen jedoch zusätzlichen Schutz für Super Admin-Konten in Betracht ziehen.

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 vor der Einrichtung von Google Cloudweder Cloud Identity noch Google Workspace verwendet haben, verwenden die Mitarbeiter Ihrer Organisation möglicherweise bereits Privatnutzerkonten, die mit ihren geschäftlichen 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, vorhandene Privatnutzerkonten im Rahmen des Onboardings in Google Cloudzu konsolidieren. Wenn Sie Google Workspace nicht 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, jede dieser Best Practices-Sicherheitskontrollen frühzeitig im Prozess des Aufbaus der Grundlagen zu erzwingen.

Steuerung	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 zu mindern. 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ürGoogle Cloud -Dienste festlegen	Dauerhafte OAuth-Tokens für Entwickler-Workstations können ein Sicherheitsrisiko darstellen. Wir empfehlen, dass Sie eine Richtlinie für die erneute Authentifizierung festlegen, die eine Authentifizierung alle 16 Stunden mit einem Sicherheitsschlüssel erfordert.
Sitzungsdauer für Google-Dienste festlegen	(nur 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 Ihrer Google Cloud -Umgebung. Diese Protokolle enthalten Informationen, die für Ihre Google Cloud Umgebung relevant sind, z. B. Anmeldeereignisse von Nutzern. Wir empfehlen, Cloud Identity-Audit-Logs für IhreGoogle Cloud -Umgebung freizugeben, um Logs aus allen Quellen zentral zu verwalten.
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 basierend auf der Anmelderisikoanalyse von Google zu aktivieren. 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 Privatnutzernkonten 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 enthalten möglicherweise Unternehmensdaten, werden aber nicht durch Ihre Prozesse zur Kontolebensdauerverwaltung gesteuert. Wir empfehlen Ihnen, dafür zu sorgen, dass alle Nutzerkonten verwaltete Konten sind.
Kontowiederherstellung für Super Admin-Konten deaktivieren	Die eigenständige Kontowiederherstellung durch Super Admins ist für alle neuen Kunden standardmäßig deaktiviert. Bei Bestandskunden 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 Passwortwiederverwendung und überwachen Sie die Passwortstärke für alle Nutzer, die sich mit einem Passwort in Cloud Identity anmelden, insbesondere für Super Admin-Konten.
Organisationsweite Richtlinien für die Verwendung von Gruppen festlegen	Standardmäßig können Gruppen in Cloud Identity externe Nutzerkonten hinzugefügt werden. Wir empfehlen, die Freigabe-Einstellungen zu konfigurieren, sodass Gruppeninhaber keine externen Mitglieder hinzufügen können. Hinweis: Diese Einschränkung gilt nicht für das Super Admin-Konto oder andere delegierte Administratoren mit Gruppenadministrator-Berechtigungen. Da die Föderierung über Ihren Identitätsanbieter mit Administratorberechtigungen ausgeführt wird, gelten die Einstellungen für die Gruppenfreigabe 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

• Weitere Informationen zur Organisationsstruktur (nächstes Dokument in dieser Reihe)

Organisationsstruktur

Der Stammknoten für die Verwaltung 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 vom Blueprint bereitgestellt werden.

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

Ordner

Im Blueprint werden Ordner verwendet, um Projekte nach 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 für alle Umgebungen freigegeben sind.
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 für alle Umgebungen freigegeben sind.

Projekte

Im Blueprint werden Projekte verwendet, um einzelne Ressourcen basierend auf ihrer Funktionalität und den vorgesehenen Grenzen für die Zugriffssteuerung zu gruppieren. In der folgenden Tabelle werden die Projekte beschrieben, die im Blueprint enthalten sind.

Ordner	Projekt	Beschreibung
bootstrap	prj-b-cicd	Enthält die Bereitstellungspipeline, mit der die Grundlagenkomponenten der Organisation aufgebaut werden Weitere Informationen finden Sie unter Bereitstellungsmethodik.
	prj-b-seed	Enthält den Terraform-Zustand Ihrer Infrastruktur und das Terraform-Dienstkonto, das zum Ausführen der Pipeline erforderlich ist. Weitere Informationen finden Sie unter Bereitstellungsmethodik.
common	prj-c-secrets	Enthält Secrets auf Organisationsebene Weitere Informationen finden Sie unter Anmeldedaten von Anwendungen mit Secret Manager speichern.
	prj-c-logging	Enthält die aggregierten Logquellen für Audit-Logs. Weitere Informationen finden Sie unter Zentrales 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-export	Enthält ein BigQuery-Dataset mit den Abrechnungsexporten der Organisation Weitere Informationen finden Sie unter Kosten auf interne Kostenstellen verteilen.
	prj-c-infra-pipeline	Enthält eine Infrastrukturpipeline zum Bereitstellen von Ressourcen wie VMs und Datenbanken, die von Arbeitslasten verwendet werden. 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, für die keine VPC Service Controls erforderlich sind. 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-Dienststeuerungen erfordern. Weitere Informationen finden Sie unter Netzwerktopologie.
	prj-net-interconnect	Enthält die Cloud Interconnect-Verbindungen, die die Konnektivität zwischen Ihrer lokalen Umgebung undGoogle Cloudbieten 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.
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 die Inhaberschaft von Ressourcen

Wir empfehlen, Labels einheitlich auf Ihre Projekte anzuwenden, um die Verwaltung und Kostenzuordnung zu erleichtern. In der folgenden Tabelle werden die Projektlabels beschrieben, die jedem Projekt im Blueprint für die Governance 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, verkürzt zu b, c, p, n, d oder net.
vpc	Die ID des VPC-Netzwerks, das für dieses Projekt voraussichtlich verwendet wird.

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

„Wichtige Kontakte“ wird 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 Verwaltung gedacht. 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 Cloudzu 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.

Dual-freigegebene VPC-Netzwerktopologie

Wenn Sie die Netzwerkisolation zwischen Ihren Entwicklungs-, Nicht-Produktions- und Produktionsnetzwerken in Google Cloudbenö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 für ein anderes VPC-Netzwerk freizugeben. Alternativ können Sie Ihr lokales Netzwerk so konfigurieren, dass der Traffic von einerGoogle 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 annehmen, dass Sie das Kontingentlimit überschreiten werden, 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.

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 IhreGoogle 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 an 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,3389	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	Filter	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	all	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 UmgebungenGoogle 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	Eintragstyp	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 undGoogle Cloudempfehlen 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 undGoogle 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. Innerhalb jeder Metropolregion gibt es in der Colocation-Einrichtung zwei Zonen.
• Die Verbindungen werden in zwei Paare aufgeteilt, wobei jedes Paar mit einem separaten lokalen Rechenzentrum verbunden ist.
• VLAN-Anhänge werden verwendet, um die einzelnen Dedicated Interconnect-Instanzen mit Cloud Routern zu verbinden, die der Topologie für freigegebene VPC zugeordnet sind.
• 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 undGoogle Cloudzu konfigurieren. Der Terraform-Code im Blueprint konfiguriert automatischGoogle Cloud -Ressourcen, ändert jedoch keine Ihrer lokalen Netzwerkressourcen.

Einige der Komponenten für die Hybridkonnektivität von Ihrer lokalen Umgebung zuGoogle 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ürGoogle Cloud gebundene DNS-Lookups an die 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 Protokolle aus mehreren Quellen in mehreren Projekten in einem zentralen Protokoll-Sink zusammenfasst.

Das Diagramm beschreibt Folgendes:

• Logs werden am Organisationsknoten konfiguriert, um Logs aus allen Projekten in der Ressourcenhierarchie zu aggregieren.
• Es sind mehrere Logsenke konfiguriert, um Protokolle, die mit einem Filter übereinstimmen, an verschiedene Ziele für die Speicherung und Analyse zu senden.
• Das prj-c-logging-Projekt enthält alle Ressourcen für den Log-Speicher und die ‑Analyse.
• Optional können Sie zusätzliche Tools konfigurieren, um Protokolle in eine SIEM zu exportieren.

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

Logquelle	Beschreibung
Audit-Logs zur Administratoraktivität	Sie können Audit-Logs für 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, sie aber mit Ausschlussfiltern ausschließen.
Audit-Logs zum Datenzugriff	Standardmäßig sind in der Vorlage keine Protokolle zum Datenzugriff aktiviert, da das Volumen und die Kosten dieser Protokolle 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	Im Blueprint sind VPC-Fluss-Logs für jedes Subnetz aktiviert. Im Blueprint wird das Log-Sampling so konfiguriert, dass 50% der Logs abgetastet werden, um die Kosten zu senken. Wenn Sie zusätzliche Subnetze erstellen, müssen Sie dafür sorgen, dass VPC-Flusslogs für jedes Subnetz 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-Protokolle für verwaltete Zonen. Wenn Sie zusätzliche verwaltete Zonen erstellen, müssen Sie diese DNS-Protokolle aktivieren.
Audit-Logging von Google Workspace	Erfordert einen einmaligen Aktivierungsschritt, der nicht vom Blueprint automatisiert wird. Weitere Informationen finden Sie unter Daten fürGoogle Cloud -Dienste freigeben.
Access Transparency-Logs	Erfordert einen einmaligen Aktivierungsschritt, der nicht vom Blueprint automatisiert wird. Weitere Informationen finden Sie unter Access Transparency aktivieren.

In der folgenden Tabelle werden die Log-Sinks 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	Logs aktiv analysieren. Sie können Ad-hoc-Analysen mit dem Logs Explorer in der Konsole ausführen oder SQL-Abfragen, Berichte und Ansichten mit dem verknüpften BigQuery-Dataset schreiben.
sk-c-logging-bkt	An Cloud Storage weitergeleitete Protokolle	Logs langfristig zu Compliance-, Audit- und Vorfall-Tracking-Zwecken speichern. Wenn Sie Compliance-Anforderungen für die obligatorische Datenaufbewahrung haben, empfehlen wir Ihnen, zusätzlich die Bucket-Sperre zu konfigurieren.
sk-c-logging-pub	An Pub/Sub weitergeleitete Protokolle	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: Bei vielen Tools ist die Einbindung von Drittanbietern in Pub/Sub die bevorzugte Methode zum Aufnehmen von Protokollen. Bei Google Security Operations können Sie Google Cloud Daten in Google Security Operations aufnehmen, ohne zusätzliche Infrastruktur bereitzustellen. Für Splunk können Sie mit Dataflow Logs von Google Cloud nach Splunk streamen.

Eine Anleitung zum Aktivieren zusätzlicher Logtypen und zum Schreiben von Logsenkefiltern finden Sie im Logbereichstool.

Bedrohungsmonitoring mit Security Command Center

Wir empfehlen, Security Command Center Premium für Ihre Organisation zu aktivieren, 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 bei 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 Container-Laufzeitangriffe.
• Virtual Machine Threat Detection:Erkennt potenziell schädliche Anwendungen, die auf virtuellen Maschinen ausgeführt werden.
• Web Security Scanner:Scannt Ihre webbasierten Anwendungen in der Compute Engine, App Engine oder Google Kubernetes Engine auf die zehn wichtigsten OWASP-Sicherheitslücken.

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

Sie müssen 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. Mit dem Blueprint wird das prj-c-scc-Projekt mit einem Pub/Sub-Thema erstellt, 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 Google SecOps als SIEM verwenden, nehmen Sie Daten in Google SecOps auf Google Cloud .

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

Benutzerdefinierte Lösung für automatisierte Loganalyse

Möglicherweise müssen Sie Benachrichtigungen für Sicherheitsereignisse erstellen, die auf benutzerdefinierten Abfragen in Protokollen 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. Google Cloud

Der Blueprint unterstützt diese Loganalyse, indem eine zentrale Protokollquelle eingerichtet wird, die Sie mit einem verknüpften BigQuery-Dataset abfragen können. Wenn Sie diese Funktion automatisieren möchten, müssen Sie das Codebeispiel unter bq-log-alerting implementieren und die Foundation-Funktionen erweitern. Mit dem Beispielcode können Sie regelmäßig eine Protokollquelle abfragen und ein benutzerdefiniertes Ergebnis an das Security Command Center senden.

Das folgende Diagramm zeigt den Ablauf der automatisierten Protokollanalyse.

Das Diagramm zeigt die folgenden Konzepte der automatisierten Protokollanalyse:

• Logs aus verschiedenen Quellen werden in einem zentralen Logs-Bucket mit Log Analytics und einem verknüpften BigQuery-Dataset zusammengefasst.
• BigQuery-Ansichten sind so konfiguriert, dass Protokolle nach dem Sicherheitsereignis abgefragt werden, das Sie überwachen möchten.
• Cloud Scheduler überträgt alle 15 Minuten ein Ereignis an ein Pub/Sub-Thema und löst Cloud Run-Funktionen aus.
• Cloud Run-Funktionen fragen die Ansichten nach neuen Ereignissen ab. Wenn Ereignisse gefunden werden, werden sie als benutzerdefinierte Ergebnisse an das Security Command Center gesendet.
• Das Security Command Center veröffentlicht Benachrichtigungen zu neuen Ergebnissen in einem anderen Pub/Sub-Thema.
• Ein externes Tool wie ein SIEM abonniert das Pub/Sub-Thema, um neue Ergebnisse zu übernehmen.

Das Beispiel enthält mehrere Nutzungsfälle, um nach potenziell verdächtigem Verhalten zu suchen. 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. Sie können eigene Abfragen schreiben oder sich Sicherheitsprotokollanalysen ansehen, um eine Bibliothek mit SQL-Abfragen zur Analyse von Google Cloud Protokollen zu erhalten.

Benutzerdefinierte Lösung zur Reaktion auf Asset-Änderungen

Wenn Sie auf Ereignisse in Echtzeit reagieren möchten, empfehlen wir Ihnen, mit Cloud Asset Inventory 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 Run 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, durch die hochsensible Rollen wie „Organization Admin“, „Owner“ und „Editor“ hinzugefügt werden. Das folgende Diagramm beschreibt diese Lösung.

Das vorherige Diagramm zeigt diese Konzepte:

• An einer Zulassungsrichtlinie werden Änderungen 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 Run-Funktionen führen benutzerdefinierten Code aus, um Ihre Richtlinie durchzusetzen. Die Beispielfunktion enthält eine Logik, mit der geprüft wird, ob durch die Änderung einer Zulassungsrichtlinie die Rollen „Administrator für die Organisation“, „Inhaber“ oder „Bearbeiter“ hinzugefügt wurden. In diesem Fall erstellt die Funktion ein benutzerdefiniertes Sicherheitsergebnis und sendet es an das Security Command Center.
• Optional können Sie dieses Modell verwenden, um Maßnahmen zur Behebung von Problemen zu automatisieren. Sie können zusätzliche Geschäftslogik in Cloud Run-Funktionen schreiben, um automatisch Maßnahmen aufgrund des Ergebnisses zu ergreifen, z. B. die Zulassungsrichtlinie wieder in ihren vorherigen Zustand zu versetzen.

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 Kontrollen (nächstes Dokument in dieser Reihe) erfahren

Vorbeugende Kontrollen für akzeptable Ressourcenkonfigurationen

Wir empfehlen, Richtlinieneinschränkungen zu definieren, die akzeptable Ressourcenkonfigurationen erzwingen und riskante Konfigurationen verhindern. Der Blueprint verwendet eine Kombination aus Einschränkungen der Organisationsrichtlinien und 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 Steuerelemente schon früh beim Entwerfen und Erstellen Ihrer Arbeitslasten erzwingen, können Sie spätere Korrekturarbeiten 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 Steuerelemente von allen Ordnern und Projekten in der Organisation übernommen werden. Dieses Richtlinienpaket soll bestimmte Konfigurationen mit hohem Risiko verhindern, z. B. die Freigabe einer VM für das öffentliche Internet oder die Gewährung öffentlichen Zugriffs auf Speicher-Buckets, es sei denn, Sie erlauben bewusst eine Ausnahme von der Richtlinie.

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

Organisationsrichtlinie-Beschränkung	Beschreibung
compute.disableNestedVirtualization	Eine verschachtelte Virtualisierung auf Compute Engine-VMs kann bei unsachgemäßer Konfiguration Monitoring und andere Sicherheitstools für Ihre VMs umgehen. Diese Einschränkung verhindert das Erstellen einer verschachtelten Virtualisierung.
compute.disableSerialPortAccess	IAM-Rollen wie compute.instanceAdmin ermöglichen den privilegierten Zugriff auf den Seriellport 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 Firewallsteuerungen 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 das Erstellen externer IPv6-Subnetze.
compute.requireOsLogin	Das standardmäßige Verhalten beim Festlegen von SSH-Schlüsseln in Metadaten kann unbefugten Remotezugriff auf VMs ermöglichen, wenn Schlüssel offengelegt 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 erlaubt die VM-Protokollweiterleitung nur für interne Adressen.
compute.restrictXpnProjectLienRemoval	Das Löschen eines Hostprojekts einer freigegebenen VPC kann Auswirkungen auf alle Dienstprojekte haben, 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 sie die Dienstverfügbarkeit verringert. Durch diese Einschränkung wird die Verwendung der alten Einstellung verhindert.
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 das Erstellen des Standardnetzwerks und der Standard-VPC-Firewallregeln übersprungen.
compute.vmExternalIpAccess	Standardmäßig wird eine VM mit einer externen IPv4-Adresse erstellt, was zu nicht autorisierten Zugriffen aus dem Internet führen kann. Mit dieser Einschränkung wird eine leere Zulassungsliste mit externen 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 zu Ihrer Domain an jede andere Domain gesendet werden. Mit dieser Einschränkung wird festgelegt, 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 gewährt werden, einschließlich nicht verwalteter Konten und Konten externer Organisationen. 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 weitreichende Rollen zugewiesen. Diese Einschränkung verhindert die automatische Zuweisung von IAM-Rollen für Standarddienstkonten.
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. Durch diese Einschränkung wird das Erstellen von Dienstkontoschlüsseln verhindert.
iam.disableServiceAccountKeyUpload	Wenn Sie Dienstkontoschlüsselmaterial hochladen, kann das Risiko steigen, wenn das Schlüsselmaterial offengelegt wird. Durch diese Einschränkung wird das Hochladen von Dienstkontoschlüsseln verhindert.
sql.restrictAuthorizedNetworks	Cloud SQL-Instanzen können nicht authentifiziertem Internetzugriff ausgesetzt sein, 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 in 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 über Legacy-ACLs ist von der Einschränkung iam.allowedPolicyMemberDomains nicht betroffen. Durch diese Einschränkung wird erzwungen, dass der Zugriff nur über den einheitlichen Zugriff auf Bucket-Ebene von IAM konfiguriert werden kann, nicht über alte 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, die Zugriff auf allUsers und allAuthenticatedUsers gewähren.

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. In diesen Fällen ändern Sie die Organisationsrichtlinie auf Ordner- oder Projektebene, um eine eng gefasste Ausnahme zuzulassen. 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.

Vor der Bereitstellung Infrastruktur als Code validieren

Der Blueprint verwendet einen GitOps-Ansatz zur Verwaltung der Infrastruktur. Das bedeutet, dass alle Infrastrukturänderungen über versionierte Infrastructure as Code (IaC) implementiert werden und vor der Bereitstellung validiert werden können.

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

Informationen zur Verwendung von Pipelines und zur Durchsetzung von Kontrollen durch CI/CD-Automatisierung finden Sie unter Bereitstellungsmethodik.

Nächste Schritte

• Bereitstellungsmethode (nächstes Dokument in dieser Reihe)

Einrichtungsverfahren

Wir empfehlen die Verwendung einer deklarativen Infrastruktur, um Ihre Grundlage auf konsistente und steuerbare Weise bereitzustellen. Dieser Ansatz trägt zu einer einheitlichen Verwaltung bei, indem Richtlinienkontrollen für zulässige 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.

Das folgende Diagramm zeigt unser empfohlenes Modell für die Trennung von einer Basispipeline, einer Infrastrukturpipeline und einer Anwendungspipeline.

Das Diagramm zeigt die Pipelineebenen in diesem Modell:

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

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

Die Grundlagenpipeline

Die Grundlagenpipeline stellt die Grundlagenressourcen bereit. Außerdem wird die Infrastrukturpipeline eingerichtet, mit der die von Arbeitslasten verwendete Infrastruktur bereitgestellt wird.

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

Phase

Beschreibung

0-bootstrap

Führt das Bootstrapping einer Google Cloud -Organisation durch. In diesem Schritt wird auch eine CI/CD-Pipeline für den Blueprint-Code in den nachfolgenden Phasen konfiguriert. Das CI/CD-Projekt enthält die Cloud Build-Grundlagenpipeline zum Bereitstellen von Ressourcen. Das seed-Projekt enthält die Cloud Storage-Buckets, die den Terraform-Zustand der Grundlageninfrastruktur enthalten, sowie Dienstkonten mit umfangreichen Berechtigungen, die von der Grundlagenpipeline verwendet werden, um Ressourcen zu erstellen. Der Terraform-Zustand 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 Basispipeline in der Phase 0-bootstrap erstellt haben, werden in den folgenden Phasen Ressourcen in der Basispipeline bereitgestellt. Lesen Sie die Anleitungen in der README-Datei für jede Phase und implementieren Sie die einzelnen Phasen nacheinander.

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

Infrastrukturpipeline

Über die Infrastruktur-Pipeline werden die Projekte und die Infrastruktur (z. B. die VM-Instanzen und Datenbanken) bereitgestellt, die von Arbeitslasten verwendet werden. Mit der Basispipeline werden mehrere Infrastrukturpipelines bereitgestellt. Diese Trennung zwischen der Grundlagenpipeline und der Infrastrukturpipeline ermöglicht eine Trennung zwischen platformweiten und arbeitslastspezifischen Ressourcen.

Das folgende Diagramm zeigt, wie im Blueprint mehrere Infrastrukturpipelines konfiguriert werden, die von verschiedenen Teams verwendet werden sollen.

Das Diagramm beschreibt die folgenden wichtigen Konzepte:

• Mit jeder Infrastruktur-Pipeline werden Infrastrukturressourcen unabhängig von den Basisressourcen verwaltet.
• Jede Geschäftseinheit hat eine eigene Infrastrukturpipeline, die in einem speziellen Projekt im Ordner common verwaltet wird.
• Jede der Infrastrukturpipelines hat ein Dienstkonto, das die Berechtigung hat, 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 bevorzugen, die von einem einzigen Team mit einheitlichen 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 bereit und verwendet dabei die Infrastrukturpipeline als Beispiel.

Anwendungspipeline

Die Anwendungspipeline ist für das Bereitstellen von Anwendungsartefakten für jede einzelne Arbeitslast verantwortlich, z. B. für Images oder Kubernetes-Container, in denen die Geschäftslogik Ihrer Anwendung ausgeführt wird. 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. Eine Beispielanwendungspipeline 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
Separate Buildkonfigurationen zum Validieren des Codes vor der Bereitstellung	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 Open Policy Agent-Einschränkungen, die durch die Richtlinienüberprüfung in der Google Cloud CLI erzwungen werden. Diese Einschränkungen definieren die zulässigen Ressourcenkonfigurationen, die von Ihrer Pipeline bereitgestellt werden können. Wenn ein Build nicht den Richtlinien in der ersten Build-Konfiguration entspricht, werden mit der zweiten Build-Konfiguration keine Ressourcen bereitgestellt. Die im Blueprint erzwungenen Richtlinien sind von GoogleCloudPlatform/policy-library auf GitHub forken. 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 Foundation-Pipeline hat für jede Phase ein anderes Dienstkonto mit einer Zulassungsrichtlinie, die nur die Mindestanzahl an IAM-Rollen für diese Phase gewährt. Jeder Cloud Build-Trigger wird als das jeweilige Dienstkonto für diese Phase ausgeführt. Durch die Verwendung verschiedener Konten lässt sich das Risiko verringern, dass die Änderung eines Repositories sich auf die Ressourcen auswirkt, die von einem anderen Repository verwaltet werden. Informationen zu den einzelnen IAM-Rollen, die auf jedes Dienstkonto angewendet werden, finden Sie im sa.tf Terraform-Code in der Bootstrap-Phase.
Private Cloud Build-Pools	Der Blueprint verwendet private Cloud Build-Pools. Mit privaten Pools können Sie optional zusätzliche Steuerelemente erzwingen, z. B. den Zugriff auf öffentliche Repositories einschränken oder Cloud Build innerhalb eines VPC Service Controls-Perimeters ausführen.
Benutzerdefinierte Cloud Build-Builder	Der Blueprint erstellt einen eigenen benutzerdefinierten Builder, um Terraform auszuführen. Weitere Informationen finden Sie unter 0-bootstrap/Dockerfile. Mit dieser Einstellung wird sichergestellt, dass die Pipeline immer mit einer bekannten Gruppe von Bibliotheken in angepinnten Versionen ausgeführt wird.
Bereitstellungsgenehmigung	Optional können Sie Cloud Build eine Phase für die manuelle Genehmigung 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 entsprechendenGoogle Cloud -Umgebungen widerspiegeln. Es gibt auch mehrere sitzungsspezifische Feature-Zweige, die keinen Ressourcen entsprechen, die in IhrenGoogle 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 Fehlerbehebung arbeiten, erstellen Sie einen neuen Zweig, der auf dem Entwicklungszweig basiert. 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 Ausführung der Grundlagenpipeline aus, um terraform apply auszuführen und 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 die Betriebsabläufe (nächstes Dokument in dieser Reihe)

Best Practices für Vorgänge

In diesem Abschnitt werden Vorgänge vorgestellt, die Sie beim Bereitstellen und Ausführen zusätzlicher Arbeitslasten in Ihrer Google Cloud Umgebung berücksichtigen müssen. Dieser Abschnitt ist nicht als umfassender Leitfaden für alle Vorgänge in Ihrer Cloud-Umgebung gedacht. Er enthält jedoch Entscheidungen im Zusammenhang mit den architektonischen Empfehlungen und Ressourcen, die vom Blueprint bereitgestellt werden.

Ressourcen für die Stiftung aktualisieren

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

Wir empfehlen, alle Änderungen an Grundlagenressourcen ü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 den folgenden Punkten umfassen:

• Zu aktivierende Google Cloud APIs
• 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
• Welches Abrechnungskonto verwenden?
• 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 Liste der konfigurierbaren Attribute für jedes Projekt finden Sie in der Automatisierungspipeline unter Eingabevariablen für die Projekt-Factory.

Berechtigungen in großem Umfang verwalten

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

Wir empfehlen außerdem, den IAM Recommender zu verwenden, um Zulassungsrichtlinien zu identifizieren, die Rollen mit zu vielen Berechtigungen gewähren. Entwerfen Sie einen Prozess, um Empfehlungen regelmäßig zu überprüfen oder automatisch in Ihre Bereitstellungspipelines anzuwenden.

Änderungen zwischen dem Netzwerkteam und dem Anwendungsteam koordinieren

Bei den Netzwerktopologien, die mit dem Blueprint bereitgestellt werden, wird davon ausgegangen, dass Sie ein Team für die Verwaltung von Netzwerkressourcen und separate Teams für die Bereitstellung von Arbeitslastinfrastrukturressourcen haben. Beim Bereitstellen der Infrastruktur müssen die Arbeitslastteams Firewallregeln erstellen, um die vorgesehenen 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 zentralen Netzwerkressourcen zu koordinieren, die für die Bereitstellung von Anwendungen erforderlich sind. Sie könnten 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-Dienstportfolio,mit dem Empfehlungen zur Optimierung Ihrer Umgebung gegeben werden. So liefern beispielsweise Firewall-Erkenntnisse oder der Recommender für unbeaufsichtigte Projekte umsetzbare Empfehlungen, mit denen Sie Ihren Sicherheitsstatus verbessern können.

Entwerfen Sie einen Prozess, um Empfehlungen regelmäßig zu überprüfen oder automatisch in 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.

Beispielsweise erzwingt der Blueprint die Einschränkung iam.disableServiceAccountKeyCreation. 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 aufGoogle 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, sofern zusätzliche Kontrollmaßnahmen wie die 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 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.

Ressourcen mit VPC Service Controls schützen

Mit dem Blueprint können Sie Ihre Umgebung für VPC Service Controls vorbereiten, indem Sie das Basis- und das eingeschränkte Netzwerk voneinander trennen. Standardmäßig werden VPC Service Controls jedoch nicht durch den Terraform-Code aktiviert, da dies zu Unterbrechungen führen kann.

Ein Perimeter verwehrt Zugriff auf eingeschränkte Google Cloud Dienste durch Traffic, der außerhalb des Perimeters stammt. Dazu gehören die Konsole, Entwickler-Workstations und die Foundation-Pipeline, die zum Bereitstellen von Ressourcen verwendet wird. Wenn Sie VPC Service Controls verwenden, müssen Sie Ausnahmen für den Perimeter festlegen, 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 soll keine Allow-Richtlinien für die detaillierte Zugriffssteuerung auf einzelne Projekte oder Ressourcen ersetzen oder 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 entwerfen müssen, um den Dienstverkehr innerhalb Ihrer Google Cloud Organisation detailliert zu steuern, empfehlen wir Ihnen, die Bedrohungen, die durch eine komplexere Perimeterstruktur angegangen werden, und die Zugriffspfade zwischen den Perimetern, die für die beabsichtigten Vorgänge erforderlich sind, klar zu definieren.

Berücksichtigen Sie bei der Einführung von VPC Service Controls Folgendes:

• 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

• Informationen zum Entwerfen und Implementieren eines Perimeters mithilfe der Best Practices zum Aktivieren von VPC Service Controls

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 nie ohne Tests in der Produktion 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.

Fernzugriff 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, in denen ein Remotezugriff erforderlich ist, empfehlen wir, den Nutzerzugriff nach Möglichkeit mit OS Login zu verwalten. Bei diesem Ansatz werden verwaltete Google Cloud Dienste verwendet, um die Zugriffssteuerung, die Kontolebenszyklusverwaltung, die Bestätigung in zwei Schritten und die Protokollierung von Prüfungen durchzusetzen. 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 Cloudzu speichern.

In jedem Fall kann ein Nutzer mit SSH- oder RDP-Zugriff auf eine VM ein Risiko für die Eskalierung von Berechtigungen darstellen. Berücksichtigen Sie dies bei der Gestaltung Ihres Zugriffsmodells. Der Nutzer kann Code mit den Berechtigungen des zugehörigen Dienstkontos auf dieser VM ausführen oder den Metadatenserver abfragen, um das Zugriffstoken aufzurufen, das zur Authentifizierung von API-Anfragen verwendet wird. Dieser Zugriff kann dann eine Rechteausweitung darstellen, wenn Sie nicht beabsichtigt haben, dass der Nutzer mit den Berechtigungen des Dienstkontos arbeitet.

Budgetüberschreitungen durch Budgetbenachrichtigungen vermeiden

Der Blueprint implementiert Best Practices für die Kostenverwaltung, die im Google Cloud Architektur-Framework: Kostenoptimierung vorgestellt wurden. Dazu gehören:

• Verwenden Sie ein einzelnes Rechnungskonto für alle Projekte in der Enterprise Foundation.

• Weisen Sie jedem Projekt ein billingcode-Metadatenlabel zu, mit dem Kosten auf Kostenstellen verteilt werden.

• Legen Sie Budgets und Benachrichtigungsgrenzwerte fest.

Sie sind dafür verantwortlich, Budgets zu planen und Abrechnungsbenachrichtigungen zu konfigurieren. Mit dem Blueprint werden Budgetwarnungen für Arbeitslastprojekte erstellt, wenn die prognostizierten Ausgaben voraussichtlich 120% des Budgets erreichen. Mit diesem Ansatz kann ein zentrales Team Fälle mit erheblichen Mehrausgaben erkennen und beheben. Eine erhebliche und unerwartete Steigerung der Ausgaben ohne klaren Grund kann ein Indikator für einen Sicherheitsvorfall sein und sollte sowohl aus Kosten- als auch aus Sicherheitsperspektive untersucht werden.

Hinweis :Budgetbenachrichtigungen sind eine andere Art von Benachrichtigung als die Abrechnungskategorie in „Wichtige Kontakte“. Budgetbenachrichtigungen beziehen sich auf die Inanspruchnahme von Budgets, die Sie für jedes Projekt festlegen. 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 aller Projekte basiert, die mit einer bestimmten Kostenstelle in Verbindung stehen, anstatt detaillierte Budgets für jedes Projekt festzulegen. Wir empfehlen außerdem, die Budget- und Benachrichtigungseinstellungen an die Eigentümer der Arbeitslast zu delegieren, die für die tägliche Überwachung detailliertere Benachrichtigungsgrenzwerte festlegen können.

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

Kosten auf interne Kostenstellen verteilen

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

Die folgende SQL-Abfrage ist eine Beispielabfrage, mit der Sie die Kosten für alle Projekte ermitteln können, 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 nach BigQuery exportieren.

Wenn Sie eine interne Abrechnung oder eine Kostenaufschlüsselung zwischen Kostenstellen benötigen, müssen Sie die Daten aus dieser Abfrage in Ihre internen Prozesse einbinden.

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 Protokollvolumen und die Kosten zu hoch sind, können Sie Duplikate vermeiden, indem Sie Google Cloud -Protokolle und ‑Ergebnisse nur inGoogle Cloudaufbewahren. In diesem Fall müssen Ihre bestehenden Teams die richtigen Zugriffsrechte haben und geschult sein, um direkt inGoogle Cloudmit Protokollen und Ergebnissen 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 ihre Erweiterung für zusätzliche Anforderungen zusammengefasst:

Richtlinienkontrollen, die vom Blueprint erzwungen werden	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 Reihe empfohlener Einschränkungen für Organisationsrichtlinien fürGoogle Cloud -Dienste.	Sie können zusätzliche Einschränkungen aus der Liste der verfügbaren Einschränkungen erzwingen oder benutzerdefinierte Einschränkungen erstellen.
Mit der OPA-Richtlinie (Open Policy Agent) wird vor der Bereitstellung Code in der Foundation-Pipeline auf zulässige Konfigurationen geprüft.	Erstellen Sie zusätzliche Einschränkungen anhand der Anleitung unter GoogleCloudPlatform/policy-library.
Mit Benachrichtigungen über logbasierte Messwerte und Leistungsmesswerte werden logbasierte Messwerte so konfiguriert, dass Sie bei Änderungen an IAM-Richtlinien und Konfigurationen einiger sensibler Ressourcen benachrichtigt werden.	Erstellen Sie zusätzliche logbasierte Messwerte und Benachrichtigungsrichtlinien für Protokollereignisse, die in Ihrer Umgebung nicht auftreten sollten.
Eine benutzerdefinierte Lösung für die automatisierte Loganalyse sucht regelmäßig in Logs nach verdächtiger Aktivität und erstellt Security Command Center-Ergebnisse.	Erstellen Sie zusätzliche Abfragen, um Ergebnisse für Sicherheitsereignisse zu erstellen, die Sie überwachen möchten. Verwenden Sie dazu Sicherheitsprotokollanalysen 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 Run-Funktionen mit benutzerdefinierter Logik, um auf Richtlinienverstöße zu reagieren.

Diese Kontrollen können sich ändern, wenn sich Ihre Anforderungen und die Reife vonGoogle Cloud ä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 aufgrund einer Complianceanforderung Cloud KMS verwenden müssen, um Schlüssel selbst zu verwalten. 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 für die zentrale Verwaltung von Verschlüsselungsschlüsseln bereit. So kann ein zentrales Team Verschlüsselungsschlüssel prüfen und verwalten, die von Ressourcen in Arbeitslastprojekten verwendet werden, um rechtliche 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, sensible Secrets wie API-Schlüssel, Passwörter und private Zertifikate niemals in Quellcode-Repositories zu committen. Ü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 Fall darauf, dass Sie keinen Nutzern oder Gruppen IAM-Rollen zum Lesen dieser Geheimnisse gewähren.

Der Blueprint stellt ein einzelnes prj-c-secrets-Projekt im gemeinsamen Ordner und ein prj-{env}-secrets-Projekt in jedem Umgebungsordner für die zentrale Verwaltung von Secrets bereit. Mit diesem Ansatz kann ein zentrales Team von Entwicklern die von Anwendungen verwendeten Geheimnisse prüfen und verwalten, um rechtliche 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.

Notfallzugriff auf hoch privilegierte Konten 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 Ihnen, Notfallkonten (manchmal auch als Notfall- oder Wartungskonten bezeichnet) zu planen, die im Notfall oder bei Ausfällen der Automatisierungsprozesse einen hoch privilegierten Zugriff auf Ihre Umgebung haben.

In der folgenden Tabelle sind einige Beispiele für die Verwendung von Notfallkonten aufgeführt.

Zweck des Break-Glass-Zugriffs	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 Administrator der Organisation, die dann Zugriff auf jede andere IAM-Rolle in der Organisation gewähren kann.
Grundlagenpipeline-Administrator	Notfallzugriff zum Ändern der Ressourcen in Ihrem CI/CD-Projekt aufGoogle Cloud und in einem externen Git-Repository, falls die Automatisierung der Foundation-Pipeline ausfällt.
Betriebsabläufe oder SRE	Ein Operations- oder SRE-Team benötigt Berechtigungen, um auf Ausfälle oder Vorfälle reagieren zu können. Dazu gehören Aufgaben wie das Neustarten von VMs oder das Wiederherstellen von Daten.

Die Art und Weise, wie Sie den Notfallzugriff ermöglichen, hängt von den vorhandenen Tools und Verfahren ab. Beispiele für Mechanismen:

• 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. Die Entwicklerin Dana könnte beispielsweise die Identität [e-mail] für die tägliche Nutzung und [e-mail] für den Notfallzugriff 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 überlegen, wie Sie die folgenden Fragen operativ beantworten:

• Wie legen Sie den Umfang und die Detailgenauigkeit des Notfallzugriffs fest? Beispielsweise können Sie für unterschiedliche Geschäftseinheiten unterschiedliche Break-Glass-Mechanismen entwerfen, damit diese sich nicht gegenseitig stören.
• Wie verhindert Ihr Mechanismus Missbrauch? Benötige ich 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 benachrichtigen Sie bei einem Notfallzugriff? Sie können beispielsweise ein benutzerdefiniertes Modul für die Ereignisbedrohungserkennung konfigurieren, um eine Sicherheitsanfrage zu erstellen, wenn ein vordefiniertes Notfallkonto verwendet wird.
• Wie entfernen Sie den Notfallzugriff und nehmen Sie den normalen Betrieb wieder auf, nachdem der Vorfall vorbei ist?

Für häufige Aufgaben zur Berechtigungserweiterung und zum Zurückrollen von Änderungen empfehlen wir, automatisierte Workflows zu entwerfen, bei denen ein Nutzer die Aktion ausführen kann, ohne dass eine Berechtigungserweiterung für seine Nutzeridentität erforderlich ist. Dieser Ansatz kann dazu beitragen, 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 zu verwenden, um alle Produktionsänderungen mithilfe von Automatisierung, sicheren Proxys oder geprüften Notfallzugriffsmethoden vorzunehmen. Google stellt die SRE-Bücher für Kunden zur Verfügung, die den SRE-Ansatz von Google übernehmen 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

Wenn Sie Ihre eigene Unternehmensgrundlage gemäß den Best Practices und Empfehlungen aus diesem Blueprint bereitstellen möchten, folgen Sie den allgemeinen Aufgaben, die in diesem Abschnitt zusammengefasst sind. Die Bereitstellung erfordert eine Kombination aus erforderlichen Einrichtungsschritten, einer automatisierten Bereitstellung über die terraform-example-foundation auf GitHub und zusätzlichen Schritten, die manuell konfiguriert werden müssen, nachdem die erste Grundlagenbereitstellung abgeschlossen ist.

Prozess	Schritte
Voraussetzungen für die Bereitstellung der Foundation-Pipeline-Ressourcen	Führen Sie die folgenden Schritte aus, bevor Sie die Foundation-Pipeline bereitstellen: Erstellen Sie ein Cloud Identity-Konto und bestätigen Sie die Domaininhaberschaft. Wenden Sie sich an Ihr Google Cloud Vertriebsteam, um ein Selfservice-Rechnungskonto zu erstellen. Erzwingen Sie Best Practices für die Sicherheit von Administratorkonten. Prüfen Sie Probleme mit Privatnutzerkonten und gleichen Sie sie ab. Konfigurieren Sie Ihren externen Identitätsanbieter als „Source of Truth“, um Nutzerkonten und SSO zu synchronisieren. Stellen Sie die Gruppen für die Zugriffssteuerung bereit, die zum Ausführen des Blueprints erforderlich sind. Bestimmen Sie die Netzwerktopologie, die Sie verwenden werden. Wählen Sie ein Tool zur Quellcodeverwaltung aus. Die Anleitung für terraform-example-foundation wird in ein Git-Repository geschrieben, das in Cloud Source Repositories gehostet wird. Entscheiden Sie sich für Ihre CI/CD-Automatisierungstools. Die terraform-example-foundation bietet unterschiedliche Anleitungen für verschiedene Automatisierungstools. Wenn Sie eine Verbindung zu einer vorhandenen lokalen Umgebung herstellen möchten, müssen Sie Folgendes vorbereiten: Planen Sie die IP‑Adresszuweisung anhand der Anzahl und Größe der Bereiche, die gemäß dem Blueprint erforderlich sind. Bestellen Sie Ihre Dedicated Interconnect-Verbindungen.
Schritte zum Bereitstellen der terraform-example-foundation von GitHub	Folgen Sie der README-Anleitung für jede Phase, um die terraform-example-foundation von GitHub bereitzustellen: Implementieren Sie Phase 0-bootstrap zum Erstellen einer Grundlagenpipeline. Wenn Sie ein Selfservice-Abrechnungskonto verwenden, müssen Sie ein zusätzliches Projektkontingent anfordern, bevor Sie mit der nächsten Phase fortfahren können. Implementieren Sie Phase 1-org zum Konfigurieren von Ressourcen auf Organisationsebene. Implementieren Sie Phase 2-environments zum Erstellen von Umgebungen. Implementieren Sie Phase 3-networks-dual-svpc or 3-networks-hub-and-spoke, um Netzwerkressourcen in Ihrer bevorzugten Topologie zu erstellen. Implementieren Sie Phase 4-projects zum Erstellen einer Infrastrukturpipeline bereit. Optional können Sie für die Beispielnutzung der Infrastrukturpipeline Phase 5-app-infra implementieren.
Zusätzliche Schritte nach der IaC-Bereitstellung	Führen Sie nach der Bereitstellung des Terraform-Codes die folgenden Schritte aus: Führen Sie die Änderungen an der lokalen Konfiguration aus. Aktivieren Sie Security Command Center Premium. Exportieren Sie Cloud Billing-Daten nach BigQuery. Registrieren Sie sich für einen Cloud Customer Care-Tarif. Aktivieren Sie Access Transparency-Logs. Geben Sie Daten aus Cloud Identity für Google Cloud frei. Wenden Sie die Verwaltungsfunktionen für Cloud Identity an, die nicht durch das IaC-Deployment automatisiert werden. Prüfen Sie, welche der zusätzlichen Verwaltungsfunktionen für Kunden mit sensiblen Arbeitslasten für Ihren Anwendungsfall geeignet sind. Sehen Sie sich die Best Practices für den Betrieb an und planen Sie, wie Sie Ihre vorhandenen Abläufe und Funktionen mit den Foundation-Ressourcen verknüpfen.

Zusätzliche Verwaltungsfunktionen für Kunden mit sensiblen Arbeitslasten

Google Cloud bietet zusätzliche Verwaltungsfunktionen, mit denen Sie Ihre Sicherheits- und Compliance-Anforderungen 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 Foundation anwenden. Dieser Abschnitt ist nicht als vollständige Liste aller Sicherheitsmaßnahmen gedacht, die Sie auf bestimmte Arbeitslasten anwenden können. Weitere Informationen zu den Sicherheitsprodukten und ‑lösungen von Google finden Sie im Google Cloud Best Practices-Center für Sicherheit.

Bewerten Sie anhand Ihrer Compliance-Anforderungen, Ihrer Risikobereitschaft und der Vertraulichkeit der Daten, ob die folgenden Kontrollmaßnahmen für Ihre Stiftung geeignet sind.

Kontrolle	Beschreibung
Ressourcen mit VPC Service Controls schützen	Mit VPC Service Controls können Sie Sicherheitsrichtlinien definieren, die den Zugriff auf von Google verwaltete Dienste außerhalb eines vertrauenswürdigen Perimeters verhindern, den Zugriff auf Daten von nicht vertrauenswürdigen Standorten blockieren und das Risiko der Daten-Exfiltration verringern. VPC Service Controls kann jedoch dazu führen, dass vorhandene Dienste nur funktionieren, wenn Sie Ausnahmen definieren, um beabsichtigte Zugriffsmuster zuzulassen. Prüfen Sie, ob der Wert der Minderung des Risikos der Daten-Exfiltration die erhöhte Komplexität und den operativen Aufwand der Einführung von VPC Service Controls rechtfertigt. Der Blueprint bereitet eingeschränkte Netzwerke und optionale Variablen zur Konfiguration von VPC Service Controls vor. Der Perimeter wird jedoch erst aktiviert, wenn Sie zusätzliche Schritte zum Entwerfen und Aktivieren ausführen.
Ressourcenstandorte einschränken	Möglicherweise gelten für Sie behördliche Anforderungen, die vorschreiben, dass Cloud-Ressourcen nur an genehmigten Standorten bereitgestellt werden dürfen. Mit dieser Einschränkung der Organisationsrichtlinie wird erzwungen, dass Ressourcen nur an den von Ihnen definierten Standorten bereitgestellt werden können.
Assured Workloads aktivieren	Assured Workloads bietet zusätzliche Compliance-Kontrollen, mit denen Sie bestimmte Regulierungssysteme einhalten können. Der Blueprint bietet optionale Variablen in der Bereitstellungspipeline zur Aktivierung.
Datenzugriffslogs aktivieren	Möglicherweise müssen Sie jeden Zugriff auf bestimmte sensible Daten oder Ressourcen protokollieren. Bewerten Sie, wo Ihre Arbeitslasten sensible Daten verarbeiten, für die Datenzugriffslogs erforderlich sind, und aktivieren Sie die Logs für jeden Dienst und jede Umgebung, die mit sensiblen Daten arbeiten.
Zugriffsgenehmigung aktivieren	Durch die Zugriffsgenehmigung wird sichergestellt, dass Cloud Customer Care und Ingenieure immer Ihre explizite Genehmigung benötigen, wenn sie auf Ihre Daten zugreifen müssen. Prüfe den operativen Prozess, der für die Prüfung von Anfragen zur Zugriffsberechtigung erforderlich ist, um mögliche Verzögerungen bei der Behebung von Supportanfragen zu vermeiden.
Key Access Justifications aktivieren	Mit Key Access Justifications können Sie programmatisch steuern, ob Google auf Ihre Verschlüsselungsschlüssel zugreifen kann, auch für den Zugriff auf Ihre Kundeninhalte durch automatisierte Vorgänge und Cloud Customer Care. Bewerten Sie die Kosten und den operativen Overhead im Zusammenhang mit Key Access Justifications sowie die Abhängigkeit von Cloud External Key Manager (Cloud EKM).
Cloud Shell deaktivieren	Cloud Shell ist eine Online-Entwicklungsumgebung. Diese Shell wird auf einem von Google verwalteten Server außerhalb Ihrer Umgebung gehostet und unterliegt daher nicht den Kontrollen, die Sie möglicherweise auf Ihren eigenen Entwickler-Workstations implementiert haben. Wenn Sie genau steuern möchten, welche Workstations ein Entwickler verwenden kann, um auf Cloudressourcen zuzugreifen, deaktivieren Sie Cloud Shell. Sie können auch Cloud-Workstations als konfigurierbare Workstation-Option in Ihrer eigenen Umgebung verwenden.
Zugriff auf die Google Cloud Console beschränken	Google Cloud ermöglicht es Ihnen, den Zugriff auf die Google Cloud Console anhand von Attributen der Zugriffsebene wie Gruppenmitgliedschaft, vertrauenswürdige IP‑Adressbereiche und Geräteüberprüfung einzuschränken. Für einige Attribute ist ein zusätzliches Abo für Chrome Enterprise Premium erforderlich. Prüfen Sie die Zugriffsmuster, die Sie für den Nutzerzugriff auf webbasierte Anwendungen wie die Konsole als Teil einer größeren Zero-Trust-Bereitstellung vertrauenswürdig erachten.

Namenskonventionen

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

Ressource	Namenskonvention
Ordner	fldr-environment environment ist eine Beschreibung der Ressourcen auf Ordnerebene in der Google Cloud-Organisation. Beispiel: bootstrap, common, production, nonproduction, development oder network. Beispiel: fldr-production
Projekt-ID	prj-environmentcode-description-randomid environmentcode ist eine Kurzform des Umgebungsfelds (b, c, p, n, d oder net). Bei freigegebenen VPC-Hostprojekten wird die environmentcode der zugehörigen Umgebung verwendet. Für Projekte mit Netzwerkressourcen, die für mehrere Umgebungen freigegeben sind, wie das Projekt interconnect, wird der Umgebungscode net verwendet. description sind zusätzliche Informationen zum Projekt. Sie können kurze, visuell lesbare Abkürzungen verwenden. randomid ist ein zufälliges Suffix, um Konflikte bei Ressourcennamen zu vermeiden, die global eindeutig sein müssen, und um Angreifer abzuwehren, die Ressourcennamen erraten. Der Blueprint fügt automatisch eine zufällige vierstellige alphanumerische Kennung hinzu. Beispiel: prj-c-logging-a1b2
VPC-Netzwerk	vpc-environmentcode-vpctype-vpcconfig environmentcode ist eine Kurzform des Umgebungsfelds (wahlweise b, c, p, n, d oder net). vpctype ist wahlweise shared, float oder peer. vpcconfig ist entweder base oder restricted, um anzugeben, ob das Netzwerk mit VPC Service Controls verwendet werden soll oder nicht. Beispiel: vpc-p-shared-base
Subnetz	sn-environmentcode-vpctype-vpcconfig-region{-description} environmentcode ist eine Kurzform des Umgebungsfelds (wahlweise b, c, p, n, d oder net). vpctype ist wahlweise shared, float oder peer. vpcconfig ist entweder base oder restricted, um anzugeben, ob das Netzwerk mit VPC Service Controls verwendet werden soll oder nicht. region ist eine gültige Google CloudRegion, in der sich die Ressource befindet. Wir empfehlen, Bindestriche zu entfernen und einige Regionen und Richtungen abzukürzen, um die Zeichenbeschränkung nicht zu überschreiten. Beispiel: au (Australien), na (Nordamerika), sa (Südamerika), eu (Europa), se (Südosten) oder ne (Nordosten). description sind zusätzliche Informationen zum Subnetz. Sie können kurze, visuell lesbare Abkürzungen verwenden. Beispiel: sn-p-shared-restricted-uswest1
Firewallrichtlinien	fw-firewalltype-scope-environmentcode{-description} firewalltype ist hierarchical oder network. scope ist global oder die Google CloudRegion, in der sich die Ressource befindet. Wir empfehlen, Bindestriche zu entfernen und einige Regionen und Richtungen abzukürzen, um die Zeichenbeschränkung nicht zu überschreiten. Beispiel: au (Australien), na (Nordamerika), sa (Südamerika), eu (Europa), se (Südosten) oder ne (Nordosten). environmentcode ist eine Kurzform des Umgebungsfelds (wahlweise b, c, p, n, d oder net), das die Richtlinienressource besitzt. description sind zusätzliche Informationen zur hierarchischen Firewallrichtlinie. Sie können kurze, visuell lesbare Abkürzungen verwenden. Beispiel: fw-hierarchical-global-c-01 fw-network-uswest1-p-shared-base
Cloud Router	cr-environmentcode-vpctype-vpcconfig-region{-description} environmentcode ist eine Kurzform des Umgebungsfelds (wahlweise b, c, p, n, d oder net). vpctype ist wahlweise shared, float oder peer. vpcconfig ist entweder base oder restricted, um anzugeben, ob das Netzwerk mit VPC Service Controls verwendet werden soll oder nicht. region ist eine gültige Google CloudRegion, in der sich die Ressource befindet. Wir empfehlen, Bindestriche zu entfernen und einige Regionen und Richtungen abzukürzen, um die Zeichenbeschränkung nicht zu überschreiten. Beispiel: au (Australien), na (Nordamerika), sa (Südamerika), eu (Europa), se (Südosten) oder ne (Nordosten). description sind zusätzliche Informationen zum Cloud Router. Sie können kurze, visuell lesbare Abkürzungen verwenden. Beispiel: cr-p-shared-base-useast1-cr1
Cloud Interconnect-Verbindung	ic-dc-colo dc ist der Name Ihres Rechenzentrums, mit dem eine Cloud Interconnect-Verbindung verbunden ist. colo ist der Name der Colocations-Einrichtung, mit der die Cloud Interconnect-Verbindung aus dem lokalen Rechenzentrum verbunden ist. Beispiel: ic-mydatacenter-lgazone1
Cloud Interconnect-VLAN-Anhang	vl-dc-colo-environmentcode-vpctype-vpcconfig-region{-description} dc ist der Name Ihres Rechenzentrums, mit dem eine Cloud Interconnect-Verbindung verbunden ist. colo ist der Name der Colocations-Einrichtung, mit der die Cloud Interconnect-Verbindung aus dem lokalen Rechenzentrum verbunden ist. environmentcode ist eine Kurzform des Umgebungsfelds (wahlweise b, c, p, n, d oder net). vpctype ist wahlweise shared, float oder peer. vpcconfig ist entweder base oder restricted, um anzugeben, ob das Netzwerk mit VPC Service Controls verwendet werden soll oder nicht. region ist eine gültige Google CloudRegion, in der sich die Ressource befindet. Wir empfehlen, Bindestriche zu entfernen und einige Regionen und Richtungen abzukürzen, um die Zeichenbeschränkung nicht zu überschreiten. Beispiel: au (Australien), na (Nordamerika), sa (Südamerika), eu (Europa), se (Südosten) oder ne (Nordosten). description sind zusätzliche Informationen zum VLAN. Sie können kurze, visuell lesbare Abkürzungen verwenden. Beispiel: vl-mydatacenter-lgazone1-p-shared-base-useast1-cr1
Gruppe	[e-mail] Dabei steht description für zusätzliche Informationen zur Gruppe. Sie können kurze, visuell lesbare Abkürzungen verwenden. Beispiel: [e-mail]
Benutzerdefinierte Rolle	rl-description Dabei steht description für zusätzliche Informationen zur Rolle. Sie können kurze, visuell lesbare Abkürzungen verwenden. Beispiel: rl-customcomputeadmin
Dienstkonto	[e-mail] Dabei gilt: description sind zusätzliche Informationen zum Dienstkonto. Sie können kurze, visuell lesbare Abkürzungen verwenden. projectid ist die weltweit eindeutige Projekt-ID. Beispiel: [e-mail]
Storage-Bucket	bkt-projectid-description Dabei gilt: projectid ist die weltweit eindeutige Projekt-ID. description sind zusätzliche Informationen zum Speicher-Bucket. Sie können kurze, visuell lesbare Abkürzungen verwenden. Beispiel: bkt-prj-c-infra-pipeline-a1b2-app-artifacts

Alternativen zu Standardempfehlungen

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

Entscheidungsbereich	Mögliche Alternativen
Organisation:Im Blueprint wird eine einzelne Organisation als Stammknoten für alle Ressourcen verwendet.	Unter Ressourcenhierarchie für Ihre Google Cloud Landing-Zone festlegen werden Szenarien eingeführt, in denen Sie möglicherweise mehrere Organisationen bevorzugen, zum Beispiel: Ihre Organisation enthält Tochterunternehmen, die wahrscheinlich in Zukunft verkauft werden oder als vollständig separate Unternehmen geführt werden. Sie möchten in einer Sandbox-Umgebung experimentieren, die keine Verbindung zu Ihrer bestehenden Organisation hat.
Ordnerstruktur: Der Blueprint hat eine einfache Ordnerstruktur, bei der Arbeitslasten in der obersten Ebene in die Ordner production, non-production und development unterteilt sind.	Unter Ressourcenhierarchie für Ihre Google Cloud Landing-Zone festlegen werden andere Ansätze zum Strukturieren von Ordnern erläutert. Diese basieren darauf, wie Sie Ressourcen verwalten und Richtlinien übernehmen möchten, zum Beispiel: Ordner basierend auf Anwendungsumgebungen Ordner basierend auf regionalen Entitäten oder Tochtergesellschaften Ordner basierend auf einem Framework für Rechenschaftspflicht
Organisationsrichtlinien:Im Blueprint werden alle Einschränkungen für Organisationsrichtlinien am Organisationsknoten erzwungen.	Möglicherweise gelten für verschiedene Bereiche Ihres Unternehmens unterschiedliche Sicherheitsrichtlinien oder Arbeitsweisen. In diesem Szenario werden Einschränkungen der Organisationsrichtlinie auf einem niedrigeren Knoten in der Ressourcenhierarchie erzwungen. Lesen Sie die vollständige Liste der Einschränkungen für Organisationsrichtlinien, die dazu beitragen, Ihre Anforderungen zu erfüllen.
Tools für die Bereitstellungspipeline:Im Blueprint wird Cloud Build verwendet, um die Automatisierungspipeline auszuführen.	Sie bevorzugen möglicherweise andere Produkte für Ihre Bereitstellungspipeline, z. B. Terraform Enterprise, GitLab-Runners, GitHub Actions oder Jenkins Der Blueprint enthält alternative Anleitungen für jedes Produkt.
Code-Repository für die Bereitstellung:In der Vorlage wird Cloud Source Repositories als verwaltetes privates Git-Repository verwendet.	Verwenden Sie Ihr bevorzugtes Versionskontrollsystem zum Verwalten von Code-Repositories, z. B. GitLab, GitHub oder Bitbucket. Wenn Sie ein privates Repository verwenden, das in Ihrer lokalen Umgebung gehostet wird, konfigurieren Sie einen privaten Netzwerkpfad von Ihrem Repository zu Ihrer Google Cloud-Umgebung.
Identitätsanbieter:Der Blueprint setzt ein lokales Active Directory voraus und föderiert Identitäten mithilfe von Google Cloud Directory Sync mit Cloud Identity.	Wenn Sie bereits Google Workspace verwenden, können Sie die Google-Identitäten verwenden, die bereits in Google Workspace verwaltet werden. Wenn Sie noch keinen Identitätsanbieter haben, können Sie Nutzeridentitäten direkt in Cloud Identity erstellen und verwalten. Wenn Sie bereits einen Identitätsanbieter wie Okta, Ping oder Azure Entra ID haben, können Sie möglicherweise Nutzerkonten in Ihrem vorhandenen Identitätsanbieter verwalten und mit Cloud Identity synchronisieren. Wenn Sie Datenhoheits- oder Complianceanforderungen haben, die die Verwendung von Cloud Identity verhindern, und wenn Sie keine verwalteten Google-Nutzeridentitäten für andere Google-Dienste wie Google Ads oder die Google Marketing Platform benötigen, dann ziehen Sie möglicherweise die Mitarbeiteridentitätsföderation vor. Beachten Sie in diesem Szenario die Einschränkungen bei unterstützten Diensten.
Mehrere Regionen:Der Blueprint stellt regionale Ressourcen in zwei verschiedenen Google Cloud Regionen bereit, um ein Arbeitslastdesign mit Hochverfügbarkeit und Notfallwiederherstellungsanforderungen zu ermöglichen.	Wenn Sie Endnutzer an mehreren Standorten haben, können Sie weitere Google Cloud Regionen konfigurieren, um Ressourcen näher am Endnutzer mit geringerer Latenz zu erstellen. Wenn Sie Einschränkungen hinsichtlich der Datensouveränität haben oder Ihre Verfügbarkeitsanforderungen in einer einzelnen Region erfüllt werden können, können Sie nur eineGoogle Cloud -Region konfigurieren.
IP‑Adresszuweisung: Der Blueprint enthält eine Reihe von IP‑Adressbereichen.	Möglicherweise müssen Sie die spezifischen IP-Adressbereiche ändern, die auf der Verfügbarkeit der IP-Adresse in der vorhandenen Hybridumgebung basieren. Wenn Sie die IP-Adressbereiche ändern, verwenden Sie den Blueprint als Richtlinie für die Anzahl und Größe der benötigten Bereiche und prüfen Sie die gültigen IP-Adressbereiche für Google Cloud.
Hybridnetzwerk: Der Blueprint verwendet Dedicated Interconnect über mehrere physische Standorte undGoogle Cloud -Regionen hinweg für maximale Bandbreite und Verfügbarkeit.	Je nach Ihren Anforderungen an Kosten, Bandbreite und Zuverlässigkeit können Sie stattdessen Partner Interconnect oder Cloud VPN konfigurieren. Wenn Sie Ressourcen mit privater Verbindung bereitstellen müssen, bevor eine Dedicated Interconnect-Verbindung abgeschlossen werden kann, können Sie mit Cloud VPN beginnen und später zu Dedicated Interconnect wechseln. Wenn Sie keine lokale Umgebung haben, benötigen Sie möglicherweise kein hybrides Netzwerk.
VPC Service Controls-Perimeter:Im Blueprint wird ein einzelner Perimeter empfohlen, der alle Dienstprojekte umfasst, die mit einem eingeschränkten VPC-Netzwerk verknüpft sind. Projekte, die mit einem Basis-VPC-Netzwerk verknüpft sind, sind nicht im Perimeter enthalten.	Möglicherweise haben Sie einen Anwendungsfall, in dem mehrere Perimeter für eine Organisation erforderlich sind, oder Sie entschließen sich möglicherweise, VPC Service Controls überhaupt nicht zu verwenden. Weitere Informationen finden Sie unter Entscheiden, wie die Daten-Exfiltration über Google APIs minimiert werden soll.
Secret Manager: Der Blueprint stellt ein Projekt für die Verwendung von Secret Manager im Ordner common von organisationsweiten Secrets und ein Projekt in jedem Umgebungsordner für umgebungsspezifische Secrets bereit.	Wenn ein einzelnes Team für die Verwaltung und Prüfung vertraulicher Secrets in der gesamten Organisation verantwortlich ist, sollten Sie möglicherweise nur ein einziges Projekt zum Verwalten des Zugriffs auf Secrets verwenden. Wenn Sie es Arbeitslastteams ermöglichen, ihre eigenen Secrets zu verwalten, verwenden Sie möglicherweise kein zentrales Projekt zur Verwaltung des Zugriffs auf Secrets, sondern lassen Teams ihre eigenen Instanzen von Secret Manager in Arbeitslastprojekten verwenden.
Cloud KMS: Der Blueprint stellt ein Projekt für die Verwendung von Cloud KMS im Ordner common für organisationsweite Schlüssel und ein Projekt für jeden Umgebungsordner für Schlüssel in jeder Umgebung bereit.	Wenn ein einzelnes Team für die Verwaltung und Prüfung von Verschlüsselungsschlüsseln in der gesamten Organisation zuständig ist, sollten Sie für die Verwaltung des Zugriffs auf Schlüssel nur ein einziges Projekt verwenden. Mit einem zentralisierten Ansatz können Sie Compliance-Anforderungen wie PCI-Schlüssel-Custodians erfüllen. Wenn Sie es Arbeitslastteams ermöglichen, ihre eigenen Schlüssel zu verwalten, verwenden Sie möglicherweise kein zentrales Projekt zur Verwaltung des Zugriffs auf Schlüssel, sondern lassen Teams ihre eigenen Instanzen von Cloud KMS in Arbeitslastprojekten verwenden.
Zusammengefasste Logsenke:Mit dem Blueprint werden mehrere Logsenke am Organisationsknoten konfiguriert, damit ein zentrales Sicherheitsteam Audit-Logs aus der gesamten Organisation prüfen kann.	Möglicherweise verfügen Sie über verschiedene Teams, die für die Prüfung verschiedener Teile des Unternehmens zuständig sind, und diese Teams benötigen möglicherweise unterschiedliche Logs für ihre Aufgaben. Entwerfen Sie in diesem Szenario mehrere aggregierte Senken in den entsprechenden Ordnern und Projekten und erstellen Sie Filter, sodass jedes Team nur die erforderlichen Logs erhält. Sie können auch Logansichten für eine detaillierte Zugriffssteuerung auf einen gemeinsamen Log-Bucket erstellen.
Granularität von Infrastrukturpipelines: Der Blueprint verwendet ein Modell, bei dem jede Geschäftseinheit eine separate Infrastrukturpipeline zur Verwaltung ihrer Arbeitslastprojekte hat.	Sie könnten möglicherweise eine einzelne Infrastrukturpipeline bevorzugen, die von einem zentralen Team verwaltet wird, wenn Sie ein zentrales Team haben, das für die Bereitstellung aller Projekte und Infrastrukturen zuständig ist. Dieses zentrale Team kann Pull-Anfragen von Arbeitslastteams zur Prüfung und Genehmigung vor der Projekterstellung akzeptieren. Alternativ kann das Team die Pull-Anfrage selbst als Reaktion auf ein Ticketsystem erstellen. Detailliertere Pipelines eignen sich beispielsweise, wenn einzelne Arbeitslastteams ihre eigenen Pipelines anpassen können und Sie detailliertere privilegierte Dienstkonten für die Pipelines entwerfen möchten.
SIEM-Exporte:Der Blueprint verwaltet alle Sicherheitserkenntnisse im Security Command Center.	Entscheiden Sie, ob Sie Sicherheitsergebnisse aus Security Command Center in Tools wie Google Security Operations oder in Ihr vorhandenes SIEM exportieren möchten oder ob Teams die Sicherheitsergebnisse mit der Console ansehen und verwalten sollen. Sie können mehrere Exporte mit individuellen Filtern für verschiedene Teams mit unterschiedlichem Umfang und unterschiedlichen Verantwortlichkeiten konfigurieren.
DNS-Lookups für Google Cloud lokale Dienste: Der Blueprint konfiguriert einen eindeutigen Private Service Connect-Endpunkt für jede freigegebene VPC, der dazu beitragen kann, Designs mit mehreren VPC Service Controls-Perimetern zu aktivieren.	Möglicherweise benötigen Sie kein Routing von einer lokalen Umgebung zu Private Service Connect-Endpunkten auf diesem Detaillierungsgrad, wenn Sie nicht mehrere VPC Service Control-Perimeter benötigen. Anstatt lokale Hosts den Private Service Connect-Endpunkten nach Umgebung zuzuordnen, können Sie dieses Design vereinfachen, um einen einzelnen Private Service Connect-Endpunkt mit dem entsprechenden API-Bundle zu verwenden, oder die generischen Endpunkte für private.googleapis.com und restricted.googleapis.com nutzen.

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 Architecture 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 Run 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 auf eine Demoumgebung zugreifen möchten, kontaktieren Sie uns unter [e-mail].