Übersicht über das Sicherheitsdesign

Erfahren Sie, wie Cloud Run Best Practices für die Sicherheit zum Schutz Ihrer Daten implementiert und wie Sie diese Features verwenden können, um Ihre Sicherheitsanforderungen zu erfüllen.

Architektur

Cloud Run wird auf Borg in derselben Umgebung ausgeführt, in der Google Milliarden von Containern pro Woche bereitstellt und einige der größten Websites der Welt hostet, einschließlich Gmail und YouTube. Da Cloud Run-Komponenten dieselbe Infrastruktur haben, sind sie nach den gleichen Sicherheitsstandards wie andere Google-Dienste aufgebaut.

Weitere Informationen zu unserem Sicherheitsansatz finden Sie im Whitepaper Google-Sicherheit.

Die Cloud Run-Architektur enthält viele verschiedene Infrastrukturkomponenten. Das folgende Diagramm zeigt, wie diese Komponenten auf Anfragen an Ihren Dienst und Aufrufe der Cloud Run Admin API reagieren:

Diagramm der Cloud Run-Infrastrukturkomponenten
Abbildung 1. Diagramm der Cloud Run-Infrastrukturkomponenten.

Anfragen an Ihren Dienst

Wenn eine Anfrage an Ihren Cloud Run-Dienst entweder über Ihre benutzerdefinierte Domain oder direkt an die URL run.app gesendet wird, wird die Anfrage von den folgenden Komponenten verarbeitet:

  • Google Front End (GFE): Der globale Infrastrukturdienst von Google, der TLS-Verbindungen beendet und Schutz vor DoS anwendet, wenn senden Sie eine Anfrage an die URL run.app. Cloud Run ist ein regionaler Dienst. Wenn eine Anfrage über die URL run.app aufgerufen wird, leitet das GFE die Anfrage an Cloud Run in der entsprechenden Region weiter.
  • Google Cloud-Load-Balancer: Wenn Sie Cloud Load Balancing für Ihre benutzerdefinierte Domain einrichten, enthält es die zuvor erwähnten GFE-Funktionen. Sie können Google Cloud-Load-Balancer auch so konfigurieren, dass zusätzliche Funktionen wie Trafficverwaltung und Zugriffssteuerung ausgeführt werden.
  • HTTP-Proxy: eine zonale Komponente, die eingehende HTTP-Anfragen an die Instanzen Ihrer in einer Sandbox ausgeführten Anwendungen verteilt.
  • Scheduler: wählt die Anwendungsserver aus, um Instanzen Ihrer in einer Sandbox ausgeführten Anwendungen zu hosten.
  • Anwendungsserver: Ein zonaler und mehrmandantenfähiger Computing-Knoten, der die Sandboxes erstellt und verwaltet, die die Instanzen des Containers jeder Anwendung ausführen.
  • Sandbox: Nutzercode wird vom System und anderen Kunden isoliert. Weitere Informationen finden Sie im folgenden Abschnitt zur Compute-Sicherheit.
  • Storage: Stellt eine Dateiserverschnittstelle für Container-Images bereit, die aus unterstützten Container-Registries importiert wurden.
  • Metadatenserver: Stellt Sandbox-spezifische Anmeldedaten und Metadaten bereit.
  • Ausgehendes Netzwerk: verwaltet ausgehenden Traffic, der von der Sandbox initiiert wird.

Cloud Run Admin API-Aufrufe

Wenn eine Anfrage an die Cloud Run Admin API gesendet wird, wird sie von den folgenden Komponenten verarbeitet:

  • Google Front End (GFE): Der globale Infrastrukturdienst von Google, der TLS-Verbindungen beendet und Schutz vor DoS-Angriffen anwendet.
  • Steuerungsebene: Validiert und schreibt die Anwendungskonfigurationen in den Speicher.
  • Config Storage: speichert Anwendungskonfigurationen in Spanner und in Bigtable für den Zugriff durch andere Komponenten wie den Anwendungsserver Planer und Netzwerkelemente.

Rechensicherheit

Cloud Run-Komponenten werden im Container-Verwaltungssystem Google Borg ausgeführt. Für Ihre Container bietet Cloud Run zwei Ausführungsumgebungen:

  • Erste Generation: Diese Option basiert auf der Containersicherheitsplattform gVisor und hat eine kleine Codebasis, die eine kleinere Angriffsfläche bietet. Jede Änderung wird sicherheitshalber überprüft und die meisten Änderungen werden speichersicher geschrieben. Eine weitere Härtung wird mithilfe des Seccomp-Systemaufrufs (Secure Computing Mode) erreicht.

  • Zweite Generation: Diese Option basiert auf Linux-Mikro-VMs und bietet mehr Kompatibilität und Leistung für benutzerdefinierte Arbeitslasten. Weitere Härtung wird durch Verwendung von seccomp-Systemaufruffilterung und Sandbox2-Linux-Namespaces erreicht.

Beide Ausführungsumgebungen verwenden zwei Sandbox-Ebenen, die aus einer hardwaregestützten Ebene bestehen, die einzelnen VMs entspricht (x86-Virtualisierung) und einer Software-Kernel-Ebene, wie im folgenden Diagramm dargestellt:

In beiden Ausführungsumgebungen ist der Nutzercontainer durch andere Sandbox-Ebenen von anderen Arbeitslasten isoliert.
Abbildung 2. In beiden Ausführungsumgebungen ist der Nutzercontainer durch andere Sandbox-Ebenen von anderen Arbeitslasten isoliert.

Wenn Ihr Dienst die Infrastruktur eines Drittanbieters zum Sichern von Containern verwendet, verwenden Sie die Ausführungsumgebung der zweiten Generation.

Datenverschlüsselung und -speicherung

Cloud Run-Instanzen sind zustandslos. Das Beenden einer Instanz verwirft ihren Status. Daher werden alle neuen Instanzen mit einem sauberen Slate gestartet.

Wenn Sie zustandsorientierte Daten haben, können Sie Ihre Daten so verwalten:

Darüber hinaus lässt sich Cloud Run in viele andere Google Cloud-Systeme einbinden, um Ihre Daten auf folgende Weise zu verwalten und aufzurufen:

In Google Cloud werden alle inaktiven Daten verschlüsselt.

Cloud Run erfüllt die Google Cloud-weiten Initiativen für Datenschutz und Transparenz, einschließlich Access Transparency und Datenstandort.

Netzwerksicherheit

Cloud Run und alle anderen Google Cloud-Dienste verschlüsseln den gesamten Traffic bei der Übertragung. Sie können sowohl Steuerelemente für ausgehenden als auch eingehenden Traffic in Ihre Cloud Run-Dienste oder -Jobs einbinden, um eine zusätzliche Einschränkungsebene zu erstellen. Organisationsadministratoren können auch ausgehenden und eingehenden Traffic durch die Festlegung von Organisationsrichtlinien erzwingen.

Ausgehender Traffic

Ausgehender Traffic, der von Cloud Run beendet wird, wird als Transportebene 4 (TCP und UDP) behandelt.

Standardmäßig verwendet der ausgehende Traffic einen der folgenden Pfade, wenn er Cloud Run verlässt:

  • Zielort befindet sich im VPC-Netzwerk: Der Traffic wird über die direkte Weiterleitung von ausgehendem Traffic an VPC oder einen Connector für serverlosen VPC-Zugriff weitergeleitet. Der Connector ist eine regionale Ressource, die sich direkt im VPC-Netzwerk befindet.
  • Zielort befindet sich nicht im VPC-Netzwerk: Traffic wird direkt zum Zielort im Google-Netzwerk oder im öffentlichen Internet weitergeleitet.
Diagramm der Cloud Run-Infrastrukturkomponenten
Abbildung 3. Ausgehender Traffic kann über einen Connector an ein VPC-Netzwerk weitergeleitet werden. Er kann auch direkt zu einem VPC- oder zu einem Nicht-VPC-Netzwerk weitergeleitet werden (Vorschau).

Ausgehenden Traffic steuern

Verwenden Sie die Einstellung für ausgehenden VPC-Traffic, um den ausgehenden Traffic noch genauer zu steuern und den gesamten Traffic über die direkte Weiterleitung von ausgehendem Traffic an VPC oder Connectors an Ihr VPC-Netzwerk weiterzuleiten.

Sobald er sich im VPC-Netzwerk befindet, können Sie ihn mithilfe von VPC-Tools verwalten. Beispiel:

Organisationsadministratoren können ausgehenden Traffic auch durch Festlegen der Listeneinschränkung Erlaubte Einstellungen für ausgehenden VPC-Traffic (Cloud Run) erzwingen.

Eingehender Traffic

Im Gegensatz zu ausgehendem Traffic befindet sich der eingehende Cloud Run-Traffic auf Anwendungsebene 7 (HTTP).

Cloud Run akzeptiert eingehenden Traffic aus den folgenden Quellen:

  • Öffentliches Internet: Anfragen werden direkt von öffentlichen Quellen an Ihre Cloud Run-Dienste weitergeleitet. Optional können Sie den Traffic über einen externen HTTP(S)-Load-Balancer weiterleiten.

  • VPC-Netzwerk: Sie können Traffic von einem VPC-Netzwerk an Cloud Run-Dienste weiterleiten. Dazu verwenden Sie den privaten Google-Zugriff,Private Service Connect oder einen internen Application Load Balancer. Zugriffe dieses Typs bleiben immer im Google-Netzwerk.

  • Google Cloud-Dienste: Der Traffic wird von anderen Google Cloud-Diensten wie BigQuery oder sogar Cloud Run selbst direkt zu Cloud Run weitergeleitet. In einigen Fällen können Sie diese Dienste auch so konfigurieren, dass sie ein VPC-Netzwerk durchlaufen. Zugriffe dieses Typs bleiben immer im Google-Netzwerk.

Diagramm der Cloud Run-Infrastrukturkomponenten
Abbildung 4. Eingehender Layer-7-HTTP-Traffic an Cloud Run.

Das Netzwerksicherheitsmodell von Cloud Run enthält die folgenden Attribute des eingehenden Traffics:

  • Direkter Traffic zur run.appURL: Die URL run.app erfordert immer HTTPS für den Traffic in Cloud Run. Die Frontend-Infrastrukturinfrastruktur von Google beendet TLS und leitet den Traffic dann über einen verschlüsselten Kanal an Cloud Run und an Ihren Container weiter.
  • Traffic zu einer benutzerdefinierten Domain, die mit Ihrem Google Cloud-Load-Balancer verknüpft ist: Bei HTTPS-Traffic beenden interne und externe Load-Balancer von Google Cloud TLS und leiten Traffic über einen verschlüsselten Kanal an Cloud Run und Ihren Container weiter. Mit Google Cloud-Load-Balancern können Sie auch zusätzliche Sicherheitsfeatures wie IAP, Google Cloud Armor und SSL-Richtlinien anwenden.

Weitere Informationen zum Konfigurieren von VPC-Netzwerktraffic zu Cloud Run finden Sie unter Anfragen von VPC-Netzwerken empfangen.

Eingehenden Traffic steuern

Mit den Steuerelementen für eingehenden Traffic von Cloud Run wird festgelegt, welcher Traffic in Cloud Run gelangt. So wird sichergestellt, dass der Traffic nur aus vertrauenswürdigen Quellen stammt.

Bei Cloud Run-Diensten, die nur interne Clients bedienen, können Sie die Einstellung "intern" so konfigurieren, dass nur Traffic aus den folgenden internen Quellen in Cloud Run gelangen kann:

  • VPC-Netzwerke in Ihrem Projekt oder VPC Service Controls-Perimeter, einschließlich Cloud Run-Diensten, die ihren gesamten Traffic über das VPC-Netzwerk weiterleiten.
  • Das freigegebene VPC-Netzwerk, mit dem der Cloud Run-Dienst verknüpft ist.
  • Einige Google Cloud-Dienste wie BigQuery, die sich in Ihrem Projekt oder VPC Service Controls-Perimeter befinden.
  • Traffic von lokalen Clients, die Ihr VPC-Netzwerk durchqueren, um Cloud Run zu erreichen.

Organisationsadministratoren können eingehenden Traffic auch durch Festlegen von Organisationsrichtlinien erzwingen.

Weitere Informationen zur Steuerung von Ingress finden Sie unter Eingehenden Traffic für Cloud Run einschränken.

Zugriffssteuerung

Mit Zugriffssteuerungen wird der Zugriff auf Ihre Cloud Run-Dienste und -Jobs eingeschränkt.

Wer kann Ihren Dienst oder Job verwalten?

Um zu steuern, wer Ihren Cloud Run-Dienst oder -Job verwaltet, verwendet Cloud Run IAM zum Autorisieren von Nutzern und Dienstkonten.

Worauf Ihr Dienst oder Job zugreifen kann

Wenn Sie steuern möchten, was Ihre Cloud Run-Arbeitslasten über das Netzwerk erreichen können, können Sie den gesamten Traffic über das VPC-Netzwerk erzwingen und VPC-Firewallregeln anwenden, wie zuvor unter Netzwerksicherheit beschrieben.

Wenn Sie die direkte Weiterleitung von ausgehendem Traffic an VPC verwenden, können Sie Netzwerk-Tags an die Cloud Run-Ressource anhängen und auf die Netzwerk-Tags in der Firewallregel verweisen. Wenn Sie den „Serverloser VPC-Zugriff“ verwenden, können Sie Firewallregeln auf die Connector-Instanzen anwenden.

Mit IAM steuern, auf welche Ressourcen Ihr Cloud Run-Dienst oder -Job zugreifen kann Dienste und Jobs verwenden standardmäßig das Compute Engine-Standarddienstkonto. Verwenden Sie für vertrauliche Arbeitslasten ein dediziertes Dienstkonto, damit Sie nur die Berechtigungen erteilen können, die die Arbeitslast für ihre Arbeit benötigt. Mehr zum Verwenden der Identität pro Dienst zum Verwalten eines dedizierten Dienstkontos erfahren Informationen dazu, wie Cloud Run Nutzer daran erinnert, ein dediziertes Dienstkonto zu erstellen, finden Sie unter Cloud Run-Dienste mit Recommender schützen.

Wer kann Ihren Dienst aufrufen oder den Job ausführen?

Cloud Run bietet verschiedene Optionen zum Steuern, wer Ihren Dienst aufruft oder den Job ausführt.

Steuerelemente für eingehenden Traffic

Informationen zum Verwalten des eingehenden Traffics von Cloud Run-Diensten auf Netzwerkebene finden Sie im vorherigen Abschnitt unter Eingehenden Traffic steuern.

Cloud Run-Jobs verarbeiten keine Anfragen und verwenden daher beim Ausführen von Jobs keine Steuerelemente für eingehenden Traffic.

IAM für Ihren Dienst

Cloud Run führt für jede Anfrage eine IAM-Prüfung durch.

Mit der Berechtigung run.routes.invoke können Sie so konfigurieren, wer auf Ihren Cloud Run-Dienst zugreifen kann:

  • Erteilen Sie die Berechtigung zum Auswählen von Dienstkonten oder Gruppen, um den Zugriff auf den Dienst zu ermöglichen. Alle Anfragen müssen einen HTTP-Autorisierungs-Header enthalten, der ein von Google für ein autorisiertes Dienstkonto signiertes OpenID Connect-ID-Token enthält.

  • Erteilen Sie allen Nutzern die Berechtigung, den nicht authentifizierten Zugriff zuzulassen.

Damit nur Mitglieder Ihrer Organisation einen Cloud Run-Dienst aufrufen können, kann ein Organisationsadministrator die Organisationsrichtlinie Domaineingeschränkte Freigabe festlegen. Organisationsadministratoren können auch bestimmte Cloud Run-Dienste deaktivieren. Öffentliche Cloud Run-Dienste erstellen, wenn die Freigabe der Domain beschränkt ist

Weitere Informationen zu häufigen Anwendungsfällen für die Authentifizierung und zur Verwendung der Zugriffssteuerung mit IAM durch Cloud Run

Load-Balancer-Sicherheitsfeatures für Ihren Dienst

Wenn Sie einen Cloud Run-Dienst als Backend für einen Google Cloud-Load-Balancer konfiguriert haben, sichern Sie diesen Pfad mit den folgenden Methoden:

IAM für Ihren Job

Mit der Berechtigung run.jobs.run können Sie so konfigurieren, wer Ihren Cloud Run-Job ausführen kann:

  • Erteilen Sie die Berechtigung zum Auswählen von Dienstkonten oder Gruppen, um den Zugriff auf den Job zu ermöglichen. Wenn der Job durch einen anderen Dienst wie Cloud Scheduler ausgelöst wird, muss das verwendete Dienstkonto die Berechtigung run.jobs.run für den Job haben.

  • Erteilen Sie dem angemeldeten Nutzer die Berechtigung, einen Job über die Google Cloud Console auszuführen. Wenn der Job von einem anderen Dienst ausgelöst wird, z. B. Cloud Scheduler, muss das verwendete Dienstkonto oder die verwendete Gruppe die Berechtigung run.jobs.run für den Job haben.

Damit nur Mitglieder Ihrer Organisation einen Cloud Run-Job ausführen können, kann ein Organisationsadministrator die Einschränkung Domaineingeschränkte Freigabe festlegen. Organisationsadministratoren können auch bestimmte Cloud Run-Jobs deaktivieren.

VPC Service Controls

Ihre Cloud Run-Dienste können Teil eines VPC Service Controls-Perimeters sein, sodass Sie VPC Service Controls nutzen können, um den Zugriff zu steuern und das Risiko der Daten-Exfiltration zu minimieren. VPC Service Controls verwenden

Lieferkettensicherheit

Mit Buildpacks verwaltete Basis-Images von Google Cloud

Aus dem Quellcode mithilfe von Buildpacks von Google Cloud bereitgestellte Dienste werden mit von Google bereitgestellten Basis-Images erstellt. Google verwaltet diese Basis-Images und stellt wöchentlich Routine-Patches bereit. Bei Notfallsituationen mit kritischen Sicherheitslücken können wir Patches innerhalb von Stunden zur Verfügung stellen.

Sicherheit der internen Cloud Run-Lieferkette

Da Cloud Run auf Borg ausgeführt wird, ist die gleiche Lieferkettensicherheit wie bei Google-Diensten wie Gmail und YouTube implementiert. Weitere Informationen zu internen Lieferkettenpraktiken von Google finden Sie in den Whitepapern BeyondProd und Binary Authorization for Borg.

Binärautorisierung

Cloud Run bietet integrierte Unterstützung für die Binärautorisierung, damit nur vertrauenswürdige Container-Images in Cloud Run bereitgestellt werden. Weitere Informationen finden Sie unter Übersicht über Cloud Run einrichten.

Software Delivery Shield

Mit Software Delivery Shield können Cloud-Administratoren Sicherheitsinformationen über die Lieferkette ihrer bereitgestellten Container direkt über ein Steuerfeld in der Google Cloud Console aufrufen. Weitere Informationen finden Sie unter Details zu Software Delivery Shield ansehen.

Sicherheit der Ausführungsumgebung

Cloud Run unterstützt automatische Basis-Image-Aktualisierungen mit kompatiblen Containern. Sicherheitsupdates werden ohne Ausfallzeit für den Dienst angewendet, indem ein Rebasing auf dem Container-Basis-Image ausgeführt wird.

Dienste, die aus der Quelle bereitgestellt werden, einschließlich Cloud Run, nutzen die Buildpacks von Google Cloud und sind mit automatischen Sicherheitsupdates kompatibel.

Dienste mit aktivierten automatischen Sicherheitsupdates werden mit von Google bereitgestellten Basis-Images bereitgestellt. Google verwaltet diese Basis-Images und stellt nach einem Zeitraum der Stabilitätstests Routine-Patches bereit. Bei Notfallsituationen mit kritischen Sicherheitslücken können wir Patches innerhalb von Stunden zur Verfügung stellen.

Weitere Informationen zu Sicherheitsupdates für die Ausführungsumgebung finden Sie unter Sicherheitsupdates konfigurieren.

Nächste Schritte

Eine Schritt-für-Schritt-Anleitung zum Einrichten von Netzwerken finden Sie im Leitfaden zu serverlosen Netzwerken von Cloud Run.