Der Inhalt dieses Dokuments wurde im März 2023 zum letzten Mal aktualisiert und stellt den Stand zum Zeitpunkt der Erstellung dar. Die Sicherheitsrichtlinien und -systeme von Google können sich aber in Zukunft ändern, da wir den Schutz unserer Kunden kontinuierlich verbessern.
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 finden Sie DevOps-Entwickler, Sicherheitsarchitekten und Anwendungsentwickler, die Ihnen zeigen, wie Sie serverlose Anwendungen, die Cloud Run verwenden, schützen können. 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:
- Serverlose Architektur mit Cloud Run bereitstellen (dieses Dokument)
- Serverlose Architektur mit Cloud Functions bereitstellen
Zu den Unterschieden zwischen Cloud Functions und Cloud Run gehören:
- Cloud Functions 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 Functions ist auf eine Gruppe von unterstützten Laufzeiten beschränkt. Sie können Cloud Run mit jeder Programmiersprache verwenden.
- Cloud 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 Functions finden Sie unter Google Cloud-Computing-Option auswählen.
Architektur
Mit diesem Blueprint können Sie serverlose Anwendungen in Cloud Run mit freigegebener VPC ausführen. Wir empfehlen die Verwendung einer freigegebenen VPC, da sie die Netzwerkrichtlinie und -steuerung für alle Netzwerkressourcen zentralisiert. Darüber hinaus wird eine freigegebene VPC im Unternehmensgrundlagen-Blueprint bereitgestellt.
Empfohlene Architektur: Cloud Run mit einem freigegebenen VPC-Netzwerk
Die folgende Abbildung zeigt, wie Sie Ihre serverlosen Anwendungen in einem freigegebenen VPC-Netzwerk ausführen können.
Die Architektur im obigen Diagramm verwendet eine Kombination aus den folgenden Google Cloud-Diensten und -Features:
- Ein externer Application Load Balancer empfängt die Daten, die serverlose Anwendungen aus dem Internet benötigen, und leitet sie an Cloud Run weiter. Der externe Application Load Balancer ist ein Layer-7-Load Balancer.
- Google Cloud Armor fungiert als Web Application Firewall, um Ihre serverlosen Anwendungen vor DoS- (Denial of Service) und Webangriffen zu schützen.
- Mit Cloud Run können Sie Anwendungscode in Containern ausführen und die Infrastruktur in Ihrem Namen verwalten lassen. In diesem Blueprint wird durch die Einstellung für internen und Cloud-Load-Balancing-Ingress der Zugriff auf Cloud Run eingeschränkt, sodass Cloud Run nur Anfragen vom externen Application Load Balancer akzeptiert.
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 serverlosen VPC-Zugriff kann Cloud Run mit anderen Diensten, Speichersystemen und Ressourcen kommunizieren, die VPC Service Controls unterstützen.
Standardmäßig erstellen Sie den Connector für serverlosen VPC-Zugriff im Dienstprojekt. Sie können den Connector für serverlosen VPC-Zugriff im Hostprojekt erstellen. Geben Sie dazu bei der Ausführung des Moduls Secure Cloud Run Network
truefür die Eingabevariableconnector_on_host_projectan. Weitere Informationen finden Sie unter Vergleich der Konfigurationsmethoden.VPC-Firewallregeln (Virtual Private Cloud) steuern den Datenfluss in das Subnetz, das Ihre Ressourcen hostet, z. B. einen in Compute Engine gehosteten Unternehmensserver oder Unternehmensdaten, die in Cloud Storage gespeichert sind.
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 wurde entwickelt, um eingehende Inhalte zu schützen, Ihre Anwendung durch die Einrichtung von Monitoring und zusätzlichen Zugriffssteuerungen zu isolieren und die Governance von Google Cloud von der Anwendung zu trennen. Die Governance umfasst die Schlüsselverwaltung und das Logging.
Mit der freigegebenen VPC können Sie den Connector für serverlosen VPC-Zugriff in Ihrem Dienstprojekt mit dem Hostprojekt verbinden.
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.
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.
Alternative Architektur: Cloud Run ohne freigegebenes VPC-Netzwerk
Wenn Sie kein freigegebenes VPC-Netzwerk verwenden, können Sie Cloud Run und Ihre serverlose Anwendung in einem VPC Service Control-Perimeter ohne ein freigegebenes VPC-Netzwerk bereitstellen. Sie können diese alternative Architektur implementieren, wenn Sie eine Hub-and-Spoke-Topologie verwenden.
In der folgenden Abbildung sehen Sie, wie Sie Ihre serverlosen Anwendungen ohne freigegebene VPC ausführen können.
Die im vorherigen Diagramm dargestellte Architektur verwendet eine Kombination aus Google Cloud-Diensten und -Features, die im vorherigen Abschnitt Empfohlene Architektur: Cloud Run mit einer freigegebenen VPC beschrieben werden.
Organisationsstruktur
Sie gruppieren Ihre Ressourcen, damit Sie sie verwalten und Ihre Entwicklungs- und Testumgebungen von der Produktionsumgebung trennen können. 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.
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 zur Verwendung durch Kunden bereit 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. |
Dev
|
Enthält Projekte mit Cloud-Ressourcen, die derzeit entwickelt werden. In diesem Blueprint enthält der Ordner Dev 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 |
|---|---|
| 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 die Dienste bereit. |
| Dienstprojekt | Dieses Projekt umfasst Ihre serverlose Anwendung, Cloud Run und den Connector für serverlosen 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. Der Blueprint stellt Cloud Run, Google Cloud Armor, den Connector für serverlosen VPC-Zugriff und den Load-Balancer bereit. |
| Sicherheitsprojekt | Dieses Projekt enthält Ihre sicherheitsspezifischen Dienste wie Cloud KMS und Secret Manager. Wenn Sie den Terraform-Code anwenden, geben Sie den Namen dieses Projekts an. Der Blueprint stellt Cloud KMS bereit. Wenn Sie das Modul Secure Cloud Run Harness verwenden, wird Artifact Registry ebenfalls bereitgestellt. Wenn Sie diesen Blueprint nach der Bereitstellung des Sicherheitsgrundlagen-Blueprints bereitstellen, ist dieses Projekt das Secrets-Projekt, das vom Untnehmensgrundlagen-Blueprint erstellt wird. Weitere Informationen zu den Blueprint-Projekten der Unternehmensgrundlagen finden Sie unter Projekte. Wenn Sie mehrere Instanzen dieses Blueprints ohne den Unternehmensgrundlagen-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 Functions-Entwickler grp-gcp-secure-cloud-run-developer@example.com |
Sicherheitsprojekt | |
| Cloud Functions-Nutzer grp-gcp-secure-cloud-run-user@example.com |
Dienstprojekt |
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 erteilen Sie Entitäten nur die Berechtigungen, die für die Ausführung ihrer Aufgaben erforderlich sind.
- Sichern Sie Netzwerkverbindungen durch Segmentierungsdesign, Organisationsrichtlinien und Firewallrichtlinien.
- Sichern Sie die Konfiguration für jeden Dienst.
- Informationen zu den Risikostufen und Sicherheitsanforderungen für die Umgebung, in der Ihre serverlosen Arbeitslasten gehostet werden.
- Konfigurieren Sie ein ausreichendes Monitoring und Logging, um Erkennung, Untersuchung und Reaktion zu ermöglichen.
Sicherheitskontrollen für serverlose Anwendungen
Sie können Ihre serverlosen Anwendungen mit Kontrollen schützen, die den Traffic im Netzwerk schützen, den Zugriff steuern und Daten verschlüsseln.
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.
SSL-Traffic
Zur Unterstützung von HTTPS-Traffic zu Ihrer serverlosen Anwendung konfigurieren Sie ein SSL-Zertifikat für den externen Application Load Balancer. Standardmäßig verwenden Sie ein selbst signiertes Zertifikat, das Sie nach dem Anwenden des Terraform-Codes in ein verwaltetes Zertifikat ändern können. Weitere Informationen zum Installieren und Verwenden von verwalteten Zertifikaten finden Sie unter Von Google verwaltete SSL-Zertifikate verwenden.
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.
Weitere Informationen finden Sie unter Privaten Google-Zugriff konfigurieren.
Perimetersteuerungen
Wie im Diagramm der empfohlenen Architektur gezeigt, platzieren Sie die Ressourcen für die serverlose Anwendung in einem separaten Perimeter. Dieser Perimeter trägt dazu bei, die serverlose Anwendung vor unbeabsichtigten Zugriffen und Daten-Exfiltration zu schützen.
Zugriffsrichtlinie
Damit nur bestimmte Identitäten (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.
Identity and Access Proxy
Wenn Ihre Umgebung bereits Identity and Access Proxy (IAP) enthält, können Sie den externen Application Load Balancer so konfigurieren, dass IAP den Traffic für Ihre serverlose Anwendung autorisiert. Mit IAP können Sie eine zentrale Autorisierungsebene für Ihre serverlose Anwendung einrichten, damit Sie anstelle von Firewalls auf Netzwerkebene Zugriffssteuerungen auf Anwendungsebene verwenden können.
Setzen Sie in der Datei loadbalancer.tf die Option iap_config.enable auf true, um IAP für Ihre Anwendung zu aktivieren.
Weitere Informationen zu IAP finden Sie in der Übersicht über Identity-Aware Proxy.
Dienstkonten und Zugriffssteuerung
Dienstkonten sind Identitäten, mit denen Google Cloud API-Anfragen in Ihrem Namen ausführen kann. Zum Implementieren der Aufgabentrennung können Sie Dienstkonten erstellen, die unterschiedliche Rollen für bestimmte Zwecke haben. Es sind folgende Dienstkonten vorhanden:
Ein Cloud Run-Dienstkonto (
cloud_run_sa) mit den folgenden Rollen:roles/run.invokerroles/secretmanager.secretAccessor
Weitere Informationen finden Sie unter Cloud Run-Zugriff auf Secret gewähren.
Ein Konto für den Connector für serverlosen VPC-Zugriff (
gcp_sa_vpcaccess) mit der Rolleroles/compute.networkUser.Ein zweites Konto für den Connector für serverlosen VPC-Zugriff (
cloud_services) mit der Rolleroles/compute.networkUser.Diese Dienstkonten für den Connector für serverlosen VPC-Zugriff sind erforderlich, damit der Connector die Firewallregeln für eingehenden und ausgehenden Traffic im Hostprojekt erstellen kann. Weitere Informationen finden Sie unter Berechtigungen für Dienstkonten in Dienstprojekten gewähren.
Eine Dienstidentität zum Ausführen von Cloud Run (
run_identity_services) mit der Rolleroles/vpcaccess.user.Einen Dienst-Agent für die Google APIs (
cloud_services_sa) mit der Rolleroles/editor. Mit diesem Dienstkonto kann Cloud Run mit dem Connector für serverlosen VPC-Zugriff kommunizieren.Eine Dienstidentität für Cloud Run (
serverless_sa) mit der Rolleroles/artifactregistry.reader. Dieses Dienstkonto bietet Zugriff auf Artifact Registry sowie CMEK-Schlüssel zum Verschlüsseln und Entschlüsseln.
Schlüsselverwaltung
Sie verwenden die CMEK-Schlüssel, um Ihre Daten in Artifact Registry und in Cloud Run zu schützen. Sie verwenden folgende Verschlüsselungsschlüssel:
- 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 bereitgestellt werden.
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 dafür sorgen, dass sich Ihre CMEK-Schlüssel in derselben Region wie Ihre Ressourcen befinden. Standardmäßig werden CMEK-Schlüssel alle 30 Tage rotiert.
Secret-Verwaltung
Cloud Run unterstützt 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 Variablen volume_mounts und volumes im Hauptmodul, um das Secret als bereitgestelltes Volume verfügbar zu machen.
Wenn Sie diesen Blueprint mit dem Unternehmensgrundlagen-Blueprint bereitstellen, müssen Sie Ihre Secrets dem Secret-Projekt hinzufügen, bevor Sie den Terraform-Code anwenden. Der Blueprint weist dem Cloud Run-Dienstkonto die Rolle "Zugriffsfunktion für Secret Manager-Secret" zu. Weitere Informationen finden Sie unter Secrets verwenden.
Organisationsrichtlinien
Mit diesem Blueprint werden den Einschränkungen für Organisationsrichtlinien Einschränkungen hinzugefügt. 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 Security definiert sind.
| Richtlinieneinschränkung | Beschreibung | Empfohlener Wert |
|---|---|---|
constraints/run.allowedIngress |
Lassen Sie eingehenden Traffic nur von internen Diensten oder dem externen Application Load Balancer zu. |
internal-and-cloud-load-balancing
|
constraints/run.allowedVPCEgress |
Erfordern, dass die Überarbeitungen eines Cloud Run-Dienstes einen Connector für serverlosen VPC-Zugriff verwenden, und darauf achten, dass in den VPC-Einstellungen für ausgehenden Traffic nur private Bereiche zulässig sind. |
private-ranges-only
|
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:
- Überwachen, wer auf Ihre Daten zugreift.
- Für eine ordnungsgemäße Prüfung sorgen.
- Dem Vorfallsmanagement und den operativen Teams die Reaktion auf mögliche Probleme ermöglichen.
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:
- Aggregierte Logsenke für alle Projekte erstellen
- Geeignete Region zum Speichern der Logs auswählen
- CMEKs zur Logging-Senke hinzufügen
Achten Sie bei allen Diensten innerhalb der Projekte darauf, dass Ihre Logs Informationen zu Datenlese- und -schreibvorgängen und den Ressourcen umfassen, auf die Administratoren zugreifen. Weitere Informationen zu den Best Practices für das Logging finden Sie unter Erkennungskontrollen.
Monitoring und Warnungen
Nachdem Sie den Blueprint bereitgestellt haben, können Sie Benachrichtigungen einrichten, um das Sicherheitscenter über mögliche Sicherheitsvorfälle zu informieren. 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.
Das Cloud Run Monitoring-Dashboard, das Teil der Beispiel-Dashboard-Bibliothek ist, stellt Ihnen die folgenden Informationen bereit:
- Anzahl der Anfragen
- Anfragelatenz
- Abrechenbare Instanzzeit
- Container-CPU-Zuweisung
- Speicherbelegung des Containers
- Container-CPU-Auslastung
- Container-Speicherauslastung
Eine Anleitung zum Importieren des Dashboards finden Sie unter Beispiel-Dashboards installieren. 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 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.
Aufdeckungskontrollen
In diesem Abschnitt werden die im Blueprint enthaltenen Aufdeckungskontrollen beschrieben.
Google Cloud Armor und WAF
Sie verwenden einen externen Application Load Balancer und Google Cloud Armor, um DDoS-Schutz (Distributed Denial of Service) für Ihre serverlose Anwendung bereitzustellen. Google Cloud Armor ist die Web Application Firewall (WAF), die in Google Cloud enthalten ist.
Sie konfigurieren die in der folgenden Tabelle beschriebenen Google Cloud Armor-Regeln zum Schutz der serverlosen Anwendung. Die Regeln sollen Ihnen helfen, die OWASP-Top-10-Risiken zu mindern.
| Name der Google Cloud Armor-Regel | Name der ModSecurity-Regel |
|---|---|
| Codeausführung per Fernzugriff |
rce-v33-stable
|
| Lokale Datei einschließen |
lfi-v33-stable
|
| Protokollangriff |
protocolattack-v33-stable
|
| Remote-Datei einschließen |
rfi-v33-stable
|
| Scannererkennung |
scannerdetection-v33-stable
|
| Sitzungsfixierungsangriff |
sessionfixation-v33-stable
|
| SQL-Injection |
sqli-v33-stable
|
| Cross-Site-Scripting |
xss-v33-stable
|
Wenn diese Regeln aktiviert sind, lehnt Google Cloud Armor automatisch den gesamten Traffic ab, der mit der Regel übereinstimmt.
Weitere Informationen zu diesen Regeln finden Sie unter Vorkonfigurierte WAF-Regeln von Google Cloud Armor optimieren.
Erkennung von Sicherheitsproblemen in Cloud Run
Mit Recommender können Sie potenzielle Sicherheitsprobleme in Cloud Run erkennen. Recommender kann folgende Sicherheitsprobleme erkennen:
- API-Schlüssel oder Passwörter, die in Umgebungsvariablen und nicht in Secret Manager gespeichert sind.
- Container, die hartcodierte Anmeldedaten anstelle von Dienstidentitäten enthalten.
Etwa einen Tag nach der Bereitstellung von Cloud Run beginnt Recommender mit der Bereitstellung der Ergebnisse und Empfehlungen. Recommender zeigt die Ergebnisse und empfohlenen Korrekturmaßnahmen in der Liste der Cloud Run-Dienste oder im Recommendation Hub an.
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 Unternehmensgrundlagen-Blueprint verwendet wird. Weitere Informationen finden Sie unter Foundation V2.3.1 für die sichere serverlose Bereitstellung anpassen. Diese Option verwendet auch das Secrets-Projekt, das Sie beim Bereitstellen des Unternehmensgrundlagen-Blueprints erstellt haben. |
Verwenden Sie diese Terraform-Module: |
| Installieren Sie diesen Blueprint, ohne den Unternehmensgrundlagen-Blueprint zu installieren. Für diese Option müssen Sie einen VPC Service Controls-Perimeter erstellen. |
Verwenden Sie diese Terraform-Module: |
Zusammenfassung
So implementieren Sie die in diesem Dokument beschriebene Architektur:
- Lesen Sie die README-Datei für den Blueprint und achten Sie darauf, dass Sie alle Voraussetzungen erfüllen.
- Erstellen Sie ein SSL-Zertifikat für die Verwendung mit dem externen Application Load Balancer.
Wenn Sie diesen Schritt nicht ausführen, verwendet der Blueprint ein selbstsigniertes Zertifikat, um den Load-Balancer bereitzustellen. Im Browser werden Warnungen zu unsicheren Verbindungen angezeigt, wenn Sie versuchen, auf die serverlose Anwendung zuzugreifen. - Stellen Sie in Ihrer Testumgebung das Beispiel zum Sichern von Secure Cloud bereit, um den Blueprint in Aktion zu sehen. Erwägen Sie im Rahmen des Testverfahrens Folgendes:
- Verwenden Sie Security Command Center, um die Projekte auf allgemeine Compliance-Anforderungen zu prüfen.
- Ersetzen Sie die Beispielanwendung durch eine echte Anwendung und führen Sie ein typisches Bereitstellungsszenario durch.
- 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.
- Stellen Sie den Blueprint in Ihrer Umgebung bereit.
Compliance-Zuordnungen
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 helfen Ihnen, die meisten dieser Risiken zu beheben, wie in der folgenden Tabelle beschrieben.
| Risiko | Blueprint-Risikominderung | Ihre Verantwortung |
|---|---|---|
| 1. Einschleusung von Funktionsereignisdaten | Google Cloud Armor und externe Application Load Balancer bieten Schutz vor OWASP Top 10, wie unter OWASP Top 10 2021 – Optionen zur Risikominimierung in Google Cloud beschrieben. | Sichere Codierungsverfahren wie Ausnahmebehandlung, wie in den OWASP Secure Coding Practices und Supplychain Levels for Software Artifacts (SLSA) beschrieben. |
| 2. Fehlerhafte Authentifizierung | Keine | IAP und die Identity Platform zur Authentifizierung von Nutzern beim Dienst |
| 3. Unsichere Konfiguration einer serverlosen Bereitstellung | CMEK mit Cloud KMS |
Verwaltung eigener Verschlüsselungsschlüssel |
| 4. Überprivilegierte Funktionsberechtigungen und -rollen |
|
Keine |
| 5. Unzureichendes Funktionsmonitoring und -Logging | Cloud Logging | Cloud Monitoring-Dashboards und Benachrichtigungsstruktur |
| 6. Unsichere Abhängigkeiten von Drittanbietern | Keine | Die CI/CD-Pipeline mit Codescans und Analysen vor der Bereitstellung schützen |
| 7. Unsichere Speicherung von Anwendungs-Secrets | Secret Manager | Secret-Verwaltung im Anwendungscode |
| 8. Denial of Service und Erschöpfung von Finanzressourcen |
|
Keine |
| 9. Bearbeitung von serverloser Geschäftslogik | VPC Service Controls zum Begrenzen des Google Cloud API-Zugriffs (über den Unternehmensgrundlagen-Blueprint bereitgestellt) | Keine |
| 10. Unangemessene Ausnahmebehandlung und ausführliche Fehlermeldungen | Keine | Best Practices für eine sichere Programmierung |
| 11. Veraltete Funktionen, Cloudressourcen und Ereignistrigger | Verwenden Sie Überarbeitungen zum Minimieren der Angriffsfläche. Mithilfe von Überarbeitungen können Sie die Wahrscheinlichkeit verringern, dass ein vorheriger, veralteter Durchlauf eines Dienstes versehentlich aktiviert wird. Überarbeitungen helfen Ihnen auch, den Sicherheitsstatus einer neuen Überarbeitung mit A/B-Tests sowie Monitoring- und Logging-Tools zu testen. |
|
| 12. Persistenz ausführungsübergreifender Daten | Keine | Keine |
Wie geht es weiter?
- Eine grundlegende sichere Umgebung finden Sie im Blueprint zu Google Cloud-Unternehmensgrundlagen.
- Die Details des Entwurfs, der in diesem Dokument beschrieben wird, finden Sie in der README-Datei der Terraform-Konfiguration.
Informationen zu Best Practices für Sicherheit und Compliance finden Sie unter Google Cloud-Architektur-Framework: Sicherheit, Datenschutz und Compliance.
Weitere Best Practices und Blueprints finden Sie im Center für Sicherheits-Best-Practices.