Mit Cloud Run-Funktionen eine sichere serverlose Architektur bereitstellen

Last reviewed 2023-08-06 UTC

Mit serverlosen Architekturen können Sie Software und Dienste entwickeln, ohne Server bereitstellen oder verwalten zu müssen. Sie können serverlose Architekturen verwenden, um Anwendungen für eine Vielzahl von Diensten zu erstellen.

In diesem Dokument wird erläutert, wie DevOps-Entwickler, Sicherheitsarchitekten und Anwendungsentwickler serverlose Anwendungen schützen, die Cloud Run Functions (2. Generation) verwenden. Das Dokument ist Teil eines Sicherheits-Blueprints, das aus folgenden Komponenten besteht:

  • Einem GitHub-Repository, das eine Reihe von Terraform-Konfigurationen und -Skripts enthält.
  • Einer Anleitung zu den Architektur-, Design- und Sicherheitskontrollen, die Sie mit diesem Blueprint implementieren (dieses Dokument).

Sie können diesen Blueprint auch bereitstellen, ohne zuvor den Google Cloud-Unternehmensgrundlagen-Blueprint bereitzustellen. In diesem Dokument wird jedoch davon ausgegangen, dass Sie bereits einen grundlegenden Satz von Sicherheitskontrollen konfiguriert haben, wie im Google Cloud-Unternehmensgrundlagen-Blueprint. Mit der in diesem Dokument beschriebenen Architektur können Sie weitere Kontrollen zum Schutz Ihrer serverlosen Anwendungen hinzufügen.

Zur Definition wichtiger Sicherheitskontrollen im Zusammenhang mit serverlosen Anwendungen hat die Cloud Security Alliance (CSA) eine Liste der 12 größten Risiken für serverlose Anwendungen veröffentlicht. Die in diesem Blueprint verwendeten Sicherheitskontrollen wurden für die Risiken entwickelt, die für die verschiedenen in diesem Dokument beschriebenen Anwendungsfälle relevant sind.

Serverlose Anwendungsfälle

Dieser Blueprint unterstützt die folgenden Anwendungsfälle:

Zu den Unterschieden zwischen Cloud Run-Funktionen und Cloud Run gehören:

  • Cloud Run-Funktionen werden durch Ereignisse ausgelöst, z. B. Änderungen an Daten in einer Datenbank oder der Empfang einer Nachricht von einem Nachrichtensystem wie Pub/Sub. Cloud Run wird durch Anfragen ausgelöst, z. B. HTTP-Anfragen.
  • Cloud Run-Funktionen sind auf eine Gruppe von unterstützten Laufzeiten beschränkt. Sie können Cloud Run mit jeder Programmiersprache verwenden.
  • Cloud Run Functions verwaltet Container und die Infrastruktur, die den Webserver oder die Sprachlaufzeit steuert, sodass Sie sich auf Ihren Code konzentrieren können. Cloud Run bietet Ihnen die Flexibilität, diese Dienste selbst auszuführen, sodass Sie die Kontrolle über die Containerkonfiguration haben.

Weitere Informationen zu den Unterschieden zwischen Cloud Run und Cloud Run-Funktionen finden Sie unter Google Cloud-Computing-Option auswählen.

Architektur

Dieser Entwurf verwendet eine Architektur mit freigegebener VPC, in der Cloud Run-Funktionen in einem Dienstprojekt bereitgestellt werden und auf Ressourcen zugreifen können, die sich in anderen VPC-Netzwerken befinden.

Im folgenden Diagramm ist eine allgemeine Architektur dargestellt, die in den folgenden Beispielarchitekturen weiter beschrieben wird.

Architektur für den serverlosen Blueprint mit Cloud Run-Funktionen

Die Architektur im obigen Diagramm verwendet eine Kombination aus den folgenden Google Cloud-Diensten und -Features:

  • Mit Cloud Run-Funktionen können Sie Funktionen als Dienst ausführen und die Infrastruktur in Ihrem Namen verwalten. Standardmäßig werden bei dieser Architektur Cloud Run-Funktionen nur mit einer internen IP-Adresse und ohne Zugriff auf das öffentliche Internet bereitgestellt.
  • Das auslösende Ereignis ist das Ereignis, das Cloud Run-Funktionen auslöst. Wie in den Beispielarchitekturen weiter beschrieben, kann dies ein Cloud Storage-Ereignis, ein geplantes Intervall oder eine Änderung in BigQuery sein.
  • Artifact Registry speichert die Quellcontainer für Ihre Cloud Run Functions-Anwendung.
  • Mit der freigegebenen VPC können Sie den Connector für Serverloser VPC-Zugriff in Ihrem Dienstprojekt mit dem Hostprojekt verbinden. Sie stellen für jede Umgebung (Produktion, Nicht-Produktion und Entwicklung) ein separates freigegebenes VPC-Netzwerk bereit. Dieses Netzwerkdesign bietet eine Netzwerkisolation zwischen den verschiedenen Umgebungen. Mit einem freigegebenen VPC-Netzwerk können Sie Netzwerkressourcen in einem gemeinsamen Netzwerk zentral verwalten und gleichzeitig administrative Aufgaben für das Dienstprojekt delegieren.

  • Der Connector für serverlosen VPC-Zugriff verbindet Ihre serverlose Anwendung über den serverlosen VPC-Zugriff mit Ihrem VPC-Netzwerk. Der serverlose VPC-Zugriff sorgt dafür, dass Anfragen von Ihrer serverlosen Anwendung an das VPC-Netzwerk nicht über das Internet zugänglich sind. Über den Serverloser VPC-Zugriff können Cloud Run-Funktionen mit anderen Diensten, Speichersystemen und Ressourcen kommunizieren, die VPC Service Controls unterstützen.

    Sie können den serverlosen VPC-Zugriff im freigegebenen VPC-Hostprojekt oder in einem Dienstprojekt konfigurieren. Standardmäßig wird mit diesem Blueprint serverloser VPC-Zugriff im freigegebenen VPC-Hostprojekt bereitgestellt, um dem freigegebenen VPC-Modell der Zentralisierung von Netzwerkkonfigurationsressourcen zu entsprechen. Weitere Informationen finden Sie unter Vergleich der Konfigurationsmethoden.

  • VPC Service Controls erstellt einen Sicherheitsbereich, der Ihre Cloud Run-Dienste und -Ressourcen isoliert, indem die Autorisierung, die Zugriffssteuerung und der sichere Datenaustausch eingerichtet werden. Dieser Perimeter dient dazu, Ihre Anwendung und die verwalteten Dienste zu isolieren. Dazu werden zusätzliche Zugriffssteuerungen und Monitoring eingerichtet und Ihre Governance von Google Cloud von der Anwendung getrennt. Die Governance umfasst die Schlüsselverwaltung und das Logging.

  • Der Nutzerdienst ist die Anwendung, mit der Cloud Run-Funktionen interagieren. Der Nutzerdienst kann ein interner Server oder ein anderer Google Cloud-Dienst wie Cloud SQL sein. Je nach Anwendungsfall befindet sich dieser Dienst möglicherweise hinter Cloud Next Generation Firewall, in einem anderen Subnetz, im selben Dienstprojekt wie Cloud Run-Funktionen oder in einem anderen Dienstprojekt.

  • Der sichere Webproxy wurde entwickelt, um den ausgehenden Webtraffic bei Bedarf zu sichern. Der Dienst ermöglicht flexible und detaillierte Richtlinien basierend auf Cloud Identity und Webanwendungen. Dieser Blueprint verwendet Secure Web Proxy für detaillierte Zugriffsrichtlinien für ausgehenden Webtraffic während der Build-Phase von Cloud Run-Funktionen. Der Blueprint fügt der Gateway Security Policy Rule eine zulässige Liste von URLs hinzu.

  • Cloud NAT stellt bei Bedarf eine ausgehende Verbindung zum Internet her. Cloud NAT unterstützt die Quellnetzwerkadressübersetzung (SNAT, Source Network Address Translation) für Rechenressourcen ohne öffentliche IP-Adressen. Eingehende Antwortpakete verwenden die Zieladressübersetzung (Destination Network Address Translation, DNAT). Sie können Cloud NAT deaktivieren, wenn Cloud Run-Funktionen keinen Zugriff auf das Internet benötigen. Cloud NAT implementiert die Richtlinie für ausgehenden Netzwerktraffic, die mit Secure Web Proxy verknüpft ist.

  • Der Cloud Key Management Service (Cloud KMS) speichert die vom Kunden verwalteten Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEKs), die von den Diensten in diesem Blueprint verwendet werden, einschließlich Ihrer serverlosen Anwendung, Artifact Registry und Cloud Run-Funktionen.

  • Secret Manager speichert die Secrets der Cloud Run-Funktionen. Der Blueprint stellt Secrets als Volume bereit, um eine höhere Sicherheit zu bieten als die Übergabe von Secrets als Umgebungsvariablen.

  • Mit Identity and Access Management (IAM) und Resource Manager können Sie den Zugriff einschränken und Ressourcen isolieren. Die Zugriffssteuerung und die Ressourcenhierarchie folgen dem Prinzip der geringsten Berechtigung.

  • Cloud Logging erfasst alle Logs aus Google Cloud-Diensten zum Speichern und Abrufen durch Ihre Analyse- und Prüftools.

  • Cloud Monitoring erfasst und speichert Leistungsinformationen und Messwerte zu Google Cloud-Diensten.

Beispielarchitektur für eine serverlose Anwendung mit Cloud Storage

Das folgende Diagramm zeigt, wie Sie eine serverlose Anwendung ausführen können, die auf einen internen Server zugreift, wenn ein bestimmtes Ereignis in Cloud Storage auftritt.

Beispiel für eine serverlose Architektur mit Cloud Storage

Zusätzlich zu den in Architektur beschriebenen Diensten verwendet diese Beispielarchitektur eine Kombination aus den folgenden Google Cloud-Diensten und -Features:

  • Cloud Storage gibt ein Ereignis aus, wenn eine Cloud-Ressource, Anwendung oder ein Nutzer ein Webobjekt in einem Bucket erstellt.
  • Eventarc leitet Ereignisse aus verschiedenen Ressourcen weiter. Eventarc verschlüsselt Ereignisse bei der Übertragung und im inaktiven Zustand.
  • Pub/Sub stellt Ereignisse in eine Warteschlange, die als Eingabe und Trigger für Cloud Run-Funktionen verwendet werden.
  • VPC-Firewallregeln (Virtual Private Cloud) steuern den Datenfluss in das Subnetz, das Ihre Ressourcen hostet, z. B. einen internen Server.
  • Der interne Server wird in Compute Engine oder Google Kubernetes Engine ausgeführt und hostet Ihre interne Anwendung. Wenn Sie das Beispiel für sichere Cloud Run-Funktionen mit internem Server bereitstellen, stellen Sie einen Apache-Server mit der HTML-Seite Hello World bereit. In diesem Beispiel wird der Zugriff auf eine interne Anwendung simuliert, die VMs oder Container ausführt.

Beispielarchitektur mit Cloud SQL

Das folgende Diagramm zeigt, wie Sie eine serverlose Anwendung ausführen, die in regelmäßigen Abständen, die in Cloud Scheduler definiert ist, auf einen von Cloud SQL gehosteten Dienst zugreift. Sie können diese Architektur verwenden, wenn Sie Logs erfassen, Daten aggregieren müssen usw.

Beispiel für eine serverlose Architektur mit Cloud SQL

Zusätzlich zu den in Architektur beschriebenen Diensten verwendet diese Beispielarchitektur eine Kombination aus den folgenden Google Cloud-Diensten und -Features:

Beispielarchitektur für das BigQuery-Data Warehouse

Das folgende Diagramm zeigt, wie Sie eine serverlose Anwendung ausführen können, die ausgelöst wird, wenn ein Ereignis in BigQuery auftritt (z. B. Daten werden hinzugefügt oder eine Tabelle erstellt).

Beispiel für eine serverlose Architektur mit BigQuery

Zusätzlich zu den in Architektur beschriebenen Diensten verwendet diese Beispielarchitektur eine Kombination aus den folgenden Google Cloud-Diensten und -Features:

Organisationsstruktur

Mit Resource Manager können Sie Ressourcen logisch nach Projekt, Ordner und Organisation gruppieren.

Das folgende Diagramm zeigt eine Ressourcenhierarchie mit Ordnern, die verschiedene Umgebungen darstellen, z. B. Bootstrap-, gemeinsame, Produktions-, Nicht-Produktions- (oder Test-) und Entwicklungsumgebungen. Diese Ressourcenhierarchie basiert auf der Hierarchie, die im Unternehmensgrundlagen-Blueprint beschrieben ist. Sie stellen die vom Blueprint angegebenen Projekte in den folgenden Ordnern bereit: Common, Production, Non-production und Dev.

Organisationsstruktur für den Blueprint für serverlose Anwendungen.

In den folgenden Abschnitten wird dieses Diagramm genauer beschrieben.

Ordner

Mithilfe von Ordnern isolieren Sie Ihre Produktionsumgebung und Governance-Dienste von Ihren Nicht-Produktionsumgebungen und Testumgebungen. In der folgenden Tabelle werden die Ordner aus dem Unternehmensgrundlagen-Blueprint beschrieben, die von diesem Blueprint verwendet werden

Ordner Beschreibung
Bootstrap Enthält Ressourcen, die zum Bereitstellen des Unternehmensgrundlagen-Blueprints erforderlich sind.
Common Enthält zentralisierte Dienste für die Organisation, z. B. das Sicherheitsprojekt.
Production Enthält Projekte mit Cloud-Ressourcen, die getestet wurden und bereit für die Verwendung durch Kunden sind. In diesem Blueprint enthält der Ordner Production das Dienstprojekt und das Hostprojekt.
Non-production Enthält Projekte mit Cloud-Ressourcen, die derzeit getestet und zur Veröffentlichung bereitgestellt werden. In diesem Blueprint enthält der Ordner Non-production das Dienstprojekt und das Hostprojekt.
Development Enthält Projekte mit Cloud-Ressourcen, die derzeit entwickelt werden. In diesem Blueprint enthält der Ordner Development das Dienstprojekt und das Hostprojekt.

Sie können die Namen dieser Ordner an die Ordnerstruktur Ihrer Organisation anpassen. Wir empfehlen jedoch, eine ähnliche Struktur beizubehalten. Weitere Informationen finden Sie unter Organisationsstruktur. Informationen zu anderen Ordnerstrukturen finden Sie unter Ressourcenhierarchie für Ihre Google Cloud-Landing-Zone festlegen.

Projekte

Sie isolieren Ressourcen in Ihrer Umgebung mithilfe von Projekten. In der folgenden Tabelle werden die Projekte beschrieben, die innerhalb der Organisation benötigt werden. Sie können die Namen dieser Projekte ändern. Wir empfehlen jedoch, eine ähnliche Projektstruktur beizubehalten.

Projekt Beschreibung
Freigegebenes VPC-Hostprojekt

Dieses Projekt enthält die Firewallregeln für eingehenden Traffic und alle Ressourcen mit internen IP-Adressen (siehe Verbindung zu einem VPC-Netzwerk herstellen). Wenn Sie eine freigegebene VPC verwenden, bestimmen Sie ein Projekt zum Hostprojekt und fügen ihm ein oder mehrere Dienstprojekte hinzu.

Wenn Sie den Terraform-Code anwenden, geben Sie den Namen dieses Projekts an. Der Blueprint stellt den Connector für serverlosen VPC-Zugriff, Cloud NAT und den Cloud Secure Web Proxy bereit.
Dienstprojekt mit freigegebener VPC

Dieses Projekt umfasst Ihre serverlose Anwendung, Cloud Run-Funktionen und den Connector für Serverloser VPC-Zugriff. Hängen Sie das Dienstprojekt an das Hostprojekt an, damit das Dienstprojekt am freigegebenen VPC-Netzwerk teilnehmen kann.

Wenn Sie den Terraform-Code anwenden, geben Sie den Namen dieses Projekts an. Mit dem Blueprint werden Cloud Run-Funktionen und -Dienste bereitgestellt, die für Ihren Anwendungsfall erforderlich sind, z. B. Cloud SQL, Cloud Scheduler, Cloud Storage oder BigQuery.

Wenn Sie den Terraform-Code anwenden, geben Sie den Namen dieses Projekts an. Der Blueprint stellt Cloud KMS bereit. Wenn Sie das Modul Secure Serverless Harness im serverlosen Blueprint für Cloud Run-Funktionen verwenden, wird auch Artifact Registry bereitgestellt.
Sicherheitsprojekt

Dieses Projekt enthält Ihre sicherheitsspezifischen Dienste wie Cloud KMS und Secret Manager.

Der Standardname des Sicherheitsprojekts ist prj-bu1-p-sec. Wenn Sie diesen Blueprint nach der Bereitstellung des Sicherheitsgrundlagen-Blueprints bereitstellen, wird das Sicherheitsprojekt zusätzlich zum Secrets-Projekt des Unternehmens-Blueprints (prj-bu1-p-env-secrets) erstellt. Weitere Informationen zu den Projekten des Unternehmens-Blueprints finden Sie unter Projekte.

Wenn Sie mehrere Instanzen dieses Blueprints ohne den Untenehmensgrundlagen-Blueprint bereitstellen, hat jede Instanz ein eigenes Sicherheitsprojekt.

Rollen und Gruppen Projekten zuordnen

Sie müssen verschiedenen Nutzergruppen in Ihrer Organisation Zugriff auf die Projekte der serverlosen Architektur gewähren. In der folgenden Tabelle werden die Blueprint-Empfehlungen für Nutzergruppen und Rollenzuweisungen in den von Ihnen erstellten Projekten beschrieben. Sie können die Gruppen an die vorhandene Struktur Ihrer Organisation anpassen. Wir empfehlen jedoch, eine ähnliche Aufgabentrennung und Rollenzuweisung beizubehalten.

Gruppe Projekt Rollen
Serverloser Administrator
grp-gcp-serverless-admin@example.com		 Dienstprojekt
Serverloser Sicherheitsadministrator
grp-gcp-serverless-security-admin@example.com		 Sicherheitsprojekt
Cloud Run-Entwickler
grp-gcp-secure-cloud-run-developer@example.com		 Sicherheitsprojekt
Cloud Run-Nutzer
grp-gcp-secure-cloud-run-user@example.com		 Dienstprojekt mit freigegebener VPC

Sicherheitskontrollen

In diesem Abschnitt werden die Sicherheitskontrollen in Google Cloud erläutert, mit denen Sie Ihre serverlose Architektur schützen können. Dies sind die wichtigsten Sicherheitsgrundsätze, die zu berücksichtigen sind:

  • Sichern Sie den Zugriff nach dem Prinzip der geringsten Berechtigung und gewähren Sie Hauptkonten nur die Berechtigungen, die zum Ausführen von Aufgaben erforderlich sind.
  • Sichern Sie die Netzwerkverbindungen durch das Design der Vertrauensgrenze, das Netzwerksegmentierung, Organisationsrichtlinien und Firewallrichtlinien umfasst.
  • Sichern Sie die Konfiguration für jeden Dienst.
  • Identifizieren Sie alle Compliance- oder behördlichen Anforderungen für die Infrastruktur, in der serverlose Arbeitslasten gehostet werden, und weisen Sie eine Risikostufe zu.
  • Konfigurieren Sie ein ausreichendes Monitoring und Logging, um Audit-Trails für Sicherheitsvorgänge und Vorfallmanagement zu unterstützen.

Build-Systemkontrollen

Wenn Sie Ihre serverlose Anwendung bereitstellen, speichern Sie die Container-Images und Binärdateien mit Artifact Registry. Artifact Registry unterstützt CMEK, sodass Sie das Repository mit Ihren eigenen Verschlüsselungsschlüsseln verschlüsseln können.

Netzwerk- und Firewallregeln

VPC-Firewallregeln (Virtual Private Cloud) steuern den Datenfluss in die Perimeter. Sie erstellen Firewallregeln, die den gesamten ausgehenden Traffic ablehnen, mit Ausnahme bestimmter TCP-Port-443-Verbindungen von speziellen Domainnamen (restricted.googleapis.com). Die Verwendung der Domain "restricted.googleapis.com" hat folgende Vorteile:

  • Sie reduziert die Netzwerkangriffsfläche durch Verwendung des privaten Google-Zugriffs, wenn Arbeitslasten mit Google APIs und Diensten kommunizieren.
  • Sie sorgt dafür, dass nur Dienste verwendet werden, die VPC Service Controls unterstützen.

Außerdem erstellen Sie einen DNS-Eintrag, um *.googleapis.com in restricted.googleapis.com aufzulösen.

Weitere Informationen finden Sie unter Privaten Google-Zugriff konfigurieren.

Perimetersteuerungen

Wie im Abschnitt Architektur dargestellt, platzieren Sie die Ressourcen für die serverlose Anwendung in einem separaten VPC Service Controls-Sicherheitsperimeter. Dieser Perimeter trägt dazu bei, die Auswirkungen eines Systems oder Dienstes manipuliert zu haben. Dieser Sicherheitsbereich gilt jedoch nicht für den Build-Prozess von Cloud Run-Funktionen, wenn Cloud Build Ihren Code automatisch in ein Container-Image einfügt und dieses Image per Push an Artifact Registry überträgt. Erstellen Sie in diesem Szenario eine Regel für eingehenden Traffic für das Cloud Build-Dienstkonto im Dienstperimeter.

Zugriffsrichtlinie

Damit nur bestimmte Hauptkonten (Nutzer oder Dienste) auf Ressourcen und Daten zugreifen können, aktivieren Sie IAM-Gruppen und -Rollen.

Damit nur bestimmte Ressourcen auf Ihre Projekte zugreifen können, aktivieren Sie eine Zugriffsrichtlinie für Ihre Google-Organisation. Weitere Informationen finden Sie unter Zugriffsebenenattribute.

Dienstkonten und Zugriffssteuerung

Dienstkonten sind Konten für Anwendungen oder Computing-Arbeitslasten anstelle von einzelnen Endnutzern. Um das Prinzip der geringsten Berechtigung und das Prinzip der Aufgabentrennung zu implementieren, erstellen Sie Dienstkonten mit detaillierten Berechtigungen und eingeschränktem Zugriff auf Ressourcen. Es sind folgende Dienstkonten vorhanden:

Schlüsselverwaltung

Zur Validierung der Integrität und zum Schutz inaktiver Daten verwenden Sie CMEKs mit Artifact Registry, Cloud Run Functions, Cloud Storage und Eventarc. Mit CMEKs haben Sie mehr Kontrolle über Ihren Verschlüsselungsschlüssel. Die folgenden CMEKs werden verwendet:

  • Einen Softwareschlüssel für Artifact Registry, der den Code für Ihre serverlose Anwendung bestätigt.
  • Einen Verschlüsselungsschlüssel zum Verschlüsseln der Container-Images, die von Cloud Run-Funktionen bereitgestellt werden.
  • Ein Verschlüsselungsschlüssel für Eventarc-Ereignisse, der den inaktiven Messaging-Kanal verschlüsselt.
  • Ein Verschlüsselungsschlüssel zum Schutz der Daten in Cloud Storage.

Wenn Sie die Terraform-Konfiguration anwenden, geben Sie den CMEK-Standort an, der den geografischen Speicherort bestimmt, an dem die Schlüssel gespeichert sind. Sie müssen darauf achten, dass sich Ihre CMEKs in derselben Region wie Ihre Ressourcen befinden. Standardmäßig werden CMEKs alle 30 Tage rotiert.

Secret-Verwaltung

Cloud Run-Funktionen unterstützen Secret Manager zum Speichern der Secrets, die Ihre serverlose Anwendung möglicherweise benötigt. Diese Secrets können API-Schlüssel sowie Datenbank-Nutzernamen und Passwörter enthalten. Verwenden Sie die service_configs-Objektvariablen im Hauptmodul, um das Secret als bereitgestelltes Volume verfügbar zu machen.

Wenn Sie diesen Blueprint mit dem Untenehmensgrundlagen-Blueprint bereitstellen, müssen Sie Ihre Secrets dem Secret-Projekt hinzufügen, bevor Sie den Terraform-Code anwenden. Durch den Blueprint wird dem Cloud Run-Dienstkonto die Secret Manager Secret Assessor (roles/secretmanager.secretAccessor)-Rolle zugewiesen. Weitere Informationen finden Sie unter Secrets verwenden.

Organisationsrichtlinien

Dieser Blueprint fügt den Einschränkungen für Organisationsrichtlinien Einschränkungen hinzu, die vom Unternehmensgrundlagen-Blueprint verwendet werden. Weitere Informationen zu den vom Unternehmensgrundlagen-Blueprint verwendeten Einschränkungen finden Sie unter Einschränkungen für Organisationsrichtlinien.

In der folgenden Tabelle werden die zusätzlichen Einschränkungen der Organisationsrichtlinie beschrieben, die im Modul Secure Cloud Run functions Security dieses Blueprints definiert sind.

Richtlinieneinschränkung Beschreibung Empfohlener Wert
Erlaubte Einstellungen für ausgehenden Traffic (Cloud Run-Funktionen) constraints/cloudfunctions.allowedIngressSettings

Eingehenden Traffic nur von internen Diensten oder dem externen HTTP(S)-Load-Balancer zulassen.

Der Standardwert ist ALLOW_ALL.

 ALLOW_INTERNAL_ONLY
VPC-Connector erforderlich (Cloud Run-Funktionen) constraints/cloudfunctions.requireVPCConnector

Sie müssen bei der Bereitstellung einer Funktion einen Connector für serverlosen VPC-Zugriff angeben. Wenn diese Einschränkung erzwungen wird, müssen die Funktionen einen Connector für serverlosen VPC-Zugriff angeben.

Der Standardwert ist false.

 true
Erlaubte Einstellungen für ausgehenden Traffic des VPC-Connectors (Cloud Run-Funktionen) cloudfunctions.allowedVpcConnectorEgressSettings

Fordern Sie den gesamten ausgehenden Traffic für Cloud Run-Funktionen an, um einen Connector für Serverloser VPC-Zugriff zu verwenden.

Der Standardwert ist PRIVATE_RANGES_ONLY.

 ALL_TRAFFIC

Operative Steuerungen

Sie können Logging und Security Command Center-Features der Premium-Stufe wie Sicherheitsstatusanalysen und Bedrohungserkennung aktivieren. Mit diesen Steuerungen können Sie Folgendes tun:

  • Datenzugriff überwachen.
  • Für eine ordnungsgemäße Prüfung sorgen.
  • Unterstützung für Sicherheitsvorgänge und Vorfallmanagementfunktionen Ihrer Organisation.

Logging

Damit Sie die Prüfungsanforderungen erfüllen und Informationen zu Ihren Projekten erhalten können, konfigurieren Sie Google Cloud Observability mit Datenlogs für Dienste, die Sie verfolgen möchten. Stellen Sie Cloud Logging in den Projekten bereit, bevor Sie den Terraform-Code anwenden, damit der Blueprint das Logging für die Firewall, den Load Balancer und das VPC-Netzwerk konfigurieren kann.

Nachdem Sie den Blueprint bereitgestellt haben, sollten Sie Folgendes konfigurieren:

Achten Sie darauf, dass Ihre Logs für alle Dienste in den Projekten Informationen zu Datenschreibvorgängen und Administratorzugriff enthalten. Weitere Informationen zu Best Practices für das Logging finden Sie unter Erkennungsfunktionen.

Monitoring und Warnungen

Nachdem Sie den Blueprint bereitgestellt haben, können Sie Benachrichtigungen einrichten, um Ihr Sicherheitscenter zu informieren, dass ein Sicherheitsereignis aufgetreten ist. Sie können beispielsweise Benachrichtigungen verwenden, um Ihre Sicherheitsanalysten zu informieren, wenn sich eine Berechtigung in einer IAM-Rolle geändert hat. Weitere Informationen zum Konfigurieren von Security Command Center-Benachrichtigungen finden Sie unter Ergebnisbenachrichtigungen einrichten.

Mit dem Monitoring-Dashboard für Cloud Run-Funktionen können Sie die Leistung und den Zustand Ihrer Cloud Run-Funktionen überwachen. Es bietet eine Vielzahl von Messwerten und Logs, mit denen Sie Probleme identifizieren und beheben können. Das Dashboard bietet auch eine Reihe von Features, mit denen Sie die Leistung Ihrer Funktionen verbessern können, z. B. das Festlegen von Benachrichtigungen und Kontingenten.

Weitere Informationen finden Sie unter Cloud Run-Funktionen beobachten.

Informationen zum Exportieren von Benachrichtigungen finden Sie in den folgenden Dokumenten:

Debugging und Fehlerbehebung

Sie können das Modul Konnektivitätstests ausführen, um Probleme bei der Netzwerkkonfiguration zwischen Cloud Run-Funktionen und den Ressourcen in Ihrem Subnetz zu beheben. Konnektivitätstests simuliert den erwarteten Pfad eines Pakets und liefert Details zur Konnektivität, einschließlich der Konnektivitätsanalyse von Ressource zu Ressource.

Konnektivitätstests wird vom Terraform-Code nicht aktiviert. Sie müssen es separat einrichten. Weitere Informationen finden Sie unter Konnektivitätstests erstellen und ausführen.

Terraform-Bereitstellungsmodi

In der folgenden Tabelle wird beschrieben, wie Sie diesen Blueprint bereitstellen können und welche Terraform-Module für jeden Bereitstellungsmodus gelten.

Bereitstellungsmodus Terraform-Module

Stellen Sie diesen Blueprint nach der Bereitstellung des Untenehmensgrundlagen-Blueprints bereit (empfohlen).

Diese Option stellt die Ressourcen für diesen Blueprint im selben VPC Service Controls-Perimeter bereit, der vom Untenehmensgrundlagen-Blueprint verwendet wird. Weitere Informationen finden Sie unter Foundation v3.0.0 für die sichere Cloud Run-Bereitstellung anpassen.

Diese Option verwendet auch das Secrets-Projekt, das Sie beim Bereitstellen des Unternehmensgrundlagen-Blueprints erstellt haben.

 Verwenden Sie die folgenden Terraform-Module:

Installieren Sie diesen Blueprint, ohne den Sicherheitsgrundlagen-Blueprint zu installieren.

Für diese Option müssen Sie einen VPC Service Controls-Perimeter erstellen.

 Verwenden Sie die folgenden Terraform-Module:

Zusammenfassung

So implementieren Sie die in diesem Dokument beschriebene Architektur:

  1. Lesen Sie die README-Datei für den Blueprint und achten Sie darauf, dass Sie alle Voraussetzungen erfüllen.
  2. Stellen Sie eines der Beispiele in Ihrer Testumgebung bereit, um den Blueprint in Aktion zu sehen. Diese Beispiele entsprechen den Architekturbeispielen, die unter Architektur beschrieben werden. Erwägen Sie im Rahmen des Testverfahrens Folgendes:
    1. Verwenden Sie Security Command Center, um die Projekte auf allgemeine Compliance-Anforderungen zu prüfen.
    2. Ersetzen Sie die Beispielanwendung durch eine echte Anwendung (z. B. 1) und führen Sie ein typisches Bereitstellungsszenario aus.
    3. Arbeiten Sie mit den Entwicklern und Betriebsteams der Anwendung in Ihrem Unternehmen zusammen, um ihren Zugriff auf die Projekte zu testen und zu prüfen, ob sie mit der Lösung wie erwartet interagieren können.
  3. Stellen Sie den Blueprint in Ihrer Umgebung bereit.

Nächste Schritte