Netzwerk für sicheren Intra-Cloud-Zugriff: Referenzarchitekturen

Last reviewed 2025-01-13 UTC

Dieses Dokument ist Teil einer Reihe, in der Netzwerk- und Sicherheitsarchitekturen für Unternehmen beschrieben werden, die Arbeitslasten von Rechenzentren zuGoogle Cloudmigrieren.

Die Reihe besteht aus folgenden Dokumenten:

Arbeitslasten für Intra-Cloud-Anwendungsfälle befinden sich in VPC-Netzwerken und müssen eine Verbindung zu anderen Ressourcen in Google Cloudherstellen. Vielleicht nutzen sie Dienste, die nativ in der Cloud bereitgestellt sind, z. B. BigQuery. Der Sicherheitsperimeter wird von einer Vielzahl von eigenen (1P) und Drittanbieterfunktionen (3P) wie Firewalls, VPC Service Controls und virtuellen Netzwerk-Appliances bereitgestellt.

In vielen Fällen umfassen diese Arbeitslasten mehrere Google Cloud VPC-Netzwerke und die Grenzen zwischen den VPC-Netzwerken müssen gesichert werden. In diesem Dokument werden diese Sicherheits- und Verbindungsarchitekturen ausführlich behandelt.

Lift-and-Shift-Architektur

Das erste Szenario für einen intra-cloud-Anwendungsfall ist eine Lift-and-Shift-Architektur, bei der bestehende Arbeitslasten in die Cloud verschoben werden.

Cloud NGFW

Durch die Konfiguration der Cloud Next Generation Firewall können Sie einen sicheren Perimeter einrichten. Sie können Tags, Dienstkonten und Netzwerk-Tags verwenden, um detaillierte Firewallregeln auf VMs anzuwenden. Implementierungsrichtlinien zum Verwalten von Traffic mit Firewallregeln Google Cloud finden Sie unter Netzwerk-Firewallrichtlinien im Enterprise-Foundations-Blueprint.

Sie können auch das Logging von Firewallregeln verwenden, um die Auswirkungen der Einstellung der Firewallregel zu prüfen.

Sie können VPC-Flusslogs für die Netzwerkforensik nutzen und die Logs streamen, um sie in SIEM zu integrieren. Dieses Gesamtsystem kann Echtzeitmonitoring, Korrelation von Ereignissen, Analysen und Sicherheitswarnungen ermöglichen.

Abbildung 1 zeigt, wie Firewallregeln mithilfe von Netzwerk-Tags den Traffic zwischen VMs in einem VPC-Netzwerk einschränken können.

Netzwerkfirewallkonfiguration mit Netzwerktags, um eine detaillierte Steuerung für ausgehenden Traffic anzuwenden.

Abbildung 1. Netzwerkfirewallkonfiguration mit Netzwerktags, um eine detaillierte Steuerung für ausgehenden Traffic anzuwenden.

Virtuelle Netzwerk-Appliance

Eine virtuelle Netzwerk-Appliance (NVA) ist eine VM mit Sicherheitsfunktionen wie Web Application Firewalls (WAF) oder Firewalls auf Anwendungsebene. NVAs mit mehreren Netzwerkschnittstellen können als Brücke zwischen VPC-Netzwerken verwendet werden. Sie können NVAs verwenden, um Sicherheitsfunktionen für den Traffic zwischen VPC-Netzwerken zu implementieren, insbesondere wenn Sie eine Hub-Spoke-Konfiguration verwenden, wie in Abbildung 2 dargestellt.

Screenshot: Zentralisierte Konfiguration der Netzwerk-Appliance in einem freigegebenen VPC-Netzwerk.

Abbildung 2. Zentralisierte Konfiguration der Netzwerk-Appliance in einem freigegebenen VPC-Netzwerk.

Cloud IDS

Mit Cloud Intrusion Detection System (Cloud IDS) können Sie native Sicherheitsprüfungen und Logging implementieren. Dazu spiegeln Sie Traffic aus einem Subnetz in Ihrem VPC-Netzwerk. Mit Cloud IDS können Sie eine Vielzahl von Bedrohungen auf Netzwerk- und Anwendungsebene prüfen und überwachen. Sie erstellen in Ihrem Google Cloud VPC-Netzwerk Cloud IDS-Endpunkte. Diese Endpunkte überwachen den ein- und ausgehenden Traffic zu und von diesem Netzwerk sowie den Intra-VPC-Netzwerktraffic mithilfe der Paketspiegelungsfunktion, die in den Google Cloud -Netzwerkstack integriert ist. Sie müssen den Zugriff auf private Dienste aktivieren, um eine Verbindung zum Diensterstellerprojekt (dem von Google verwalteten Projekt) herzustellen, das die Cloud IDS-Prozesse hostet.

Wenn Sie eine Hub-and-Spoke-Architektur haben, kann der Traffic von jedem der Spokes auf die Cloud IDS-Instanzen gespiegelt werden, wie in Abbildung 3 dargestellt.

Cloud IDS-Konfiguration, um VPC-Traffic mithilfe des Zugriffs auf private Dienste zu spiegeln.

Abbildung 3. Cloud IDS-Konfiguration, um VPC-Traffic mithilfe des Zugriffs auf private Dienste zu spiegeln.

Cloud IDS können in Ihrem VPC Service Controls-Dienstperimeter mit einem zusätzlichen Schritt gesichert werden. Weitere Informationen zur Unterstützung von VPC Service Controls finden Sie unter Unterstützte Produkte.

Network Connectivity Center

Network Connectivity Center ist ein Orchestrierungs-Framework, das Netzwerkverbindungen zwischen Ressourcen vereinfacht, die mit einer zentralen Verwaltungsressource verbunden sind, die als Hub bezeichnet wird. Network Connectivity Center unterstützt unter anderem die folgenden Netzwerktypen:

  • Google Cloud VPC-Netzwerke
  • Lokale und andere Cloud-Netzwerke mit Cloud Interconnect oder HA VPN
  • Verschlüsselte Verbindungen, die von VMs verankert sind

Network Connectivity Center ist die Steuerungsebene der Architektur. Verbindungen zu Netzwerken werden als Speichen bezeichnet. Mit dem Network Connectivity Center können Sie Netzwerke entweder in einer Full-Mesh- oder Hub-and-Spoke-Topologie miteinander verbinden.

VPC-Netzwerk-Peering

Für Anwendungen, die sich über mehrere VPC-Netzwerke erstrecken, unabhängig davon, ob sie zum selben Google Cloud Projekt oder zur selben Organisationsressource gehören, ermöglicht VPC-Netzwerk-Peering die Konnektivität zwischen VPC-Netzwerken. Mit dieser Verbindung kann der Traffic innerhalb des Google-Netzwerks bleiben, sodass er nicht das öffentliche Internet durchläuft.

Eine Hub-and-Spoke-Architektur ist ein beliebtes Modell für die VPC-Konnektivität. Dieses Modell ist nützlich, wenn ein Unternehmen verschiedene Anwendungen hat, die auf einen gemeinsamen Satz von Diensten wie Logging oder Authentifizierung zugreifen müssen. Das Modell ist auch nützlich, wenn das Unternehmen gemeinsame Sicherheitsrichtlinien für den Traffic implementieren muss, der das Netzwerk über den Hub verlässt. Eine Anleitung zum Einrichten einer Hub-and-Spoke-Architektur mit VPC-Netzwerk-Peering finden Sie unter Netzwerkverbindung zwischen VPCs in verschiedenen Clouds mit VPC-Netzwerk-Peering.

Freigegebene VPC

Mithilfe einer freigegebenen VPC können Sie die zentrale Steuerung von Netzwerkressourcen wie Subnetzen, Routen und Firewalls in Hostprojekten behalten. Auf diese Weise können Sie die bewährte Sicherheitsmethode der geringsten Berechtigung für Netzwerkverwaltung, -prüfung und Zugriffssteuerung implementieren, da Sie Netzwerkverwaltungsaufgaben an Netzwerk- und Sicherheitsadministratoren delegieren können. Sie können Instanzadministratoren die Möglichkeit geben, VMs mithilfe von Dienstprojekten zu erstellen und zu verwalten. Mit einem Dienstprojekt wird sichergestellt, dass die VM-Administratoren nur die Möglichkeit erhalten, Instanzen zu erstellen und zu verwalten, und dass sie keine Änderungen am Netzwerk im freigegebenen VPC-Netzwerk vornehmen dürfen.

Sie können beispielsweise mehr Isolation bereitstellen, indem Sie zwei VPC-Netzwerke definieren, die sich in zwei Hostprojekten befinden, und indem Sie jedem Netzwerk mehrere Dienstprojekte zuordnen, eines für die Produktion und eines für Tests. Abbildung 6 zeigt eine Architektur, in der eine Produktionsumgebung mithilfe separater Projekte von einer Testumgebung isoliert wird.

Mehr über Best Practices zum Erstellen von VPC-Netzwerken finden Sie unter Best Practices und Referenzarchitekturen für das VPC-Design.

Konfiguration des freigegebenen VPC-Netzwerks, das mehrere isolierte Hosts und Dienstprojekte (Test- und Produktionsumgebungen) verwendet.

Abbildung 6. Konfiguration des freigegebenen VPC-Netzwerks, das mehrere isolierte Hosts und Dienstprojekte (Test- und Produktionsumgebungen) verwendet.

Hybriddienstarchitektur

Die hybride Dienstarchitektur bietet zusätzliche cloudnative Dienste, mit denen Sie Dienste in einer Multi-VPC-Umgebung verbinden und schützen können. Diese cloudnativen Dienste ergänzen das, was in der Lift-and-Shift-Architektur verfügbar ist, und erleichtern die Verwaltung einer VPC-segmentierten Umgebung im großen Maßstab.

Private Service Connect

Mit Private Service Connect kann ein Dienst, der in einem VPC-Netzwerk gehostet wird, in einem anderen VPC-Netzwerk angezeigt werden. Es ist nicht erforderlich, dass die Dienste von derselben Organisationsressource gehostet werden, sodass Private Service Connect verwendet werden kann, um Dienste privat aus einem anderen VPC-Netzwerk zu nutzen, auch wenn sie mit einer anderen Organisationsressource verbunden sind.

Sie können Private Service Connect für den Zugriff auf Google-Dienste oder auf Dienste verwenden, die in anderen VPC-Netzwerken gehostet werden.

Private Service Connect für den Zugriff auf Google APIs verwenden

Wenn Sie Private Service Connect verwenden, können Sie Google APIs mithilfe eines Private Service Connect-Endpunkts verfügbar machen, der Teil Ihres VPC-Netzwerks ist, wie in Abbildung 7 dargestellt.

Private Service Connect-Konfiguration zum Senden von Traffic über einen Private Service Connect-Endpunkt, der in Ihrem VPC-Netzwerk privat ist, an Google APIs.

Abbildung 7. Private Service Connect-Konfiguration zum Senden von Traffic über einen Private Service Connect-Endpunkt, der in Ihrem VPC-Netzwerk privat ist, an Google APIs.

Arbeitslasten können Traffic über einen Private Service Connect-Endpunkt an ein Bundle von globalen Google APIs senden. Darüber hinaus können Sie ein Private Service Connect-Backend verwenden, um auf eine einzelne Google API zuzugreifen und die Sicherheitsfeatures von Load Balancern auf API-Dienste zu erweitern. Abbildung 8 zeigt diese Konfiguration.

Screenshot: Mit Private Service Connect können Sie Traffic über ein Private Service Connect-Backend an Google APIs senden.

Abbildung 8. Screenshot: Mit Private Service Connect können Sie Traffic über ein Private Service Connect-Backend an Google APIs senden.

Private Service Connect zwischen VPC-Netzwerken oder Entitäten verwenden

Mit Private Service Connect kann ein Dienstersteller auch einem Dienstnutzer in einem anderen VPC-Netzwerk entweder Dienste in derselben Organisationsressource oder in einer anderen anbieten. Ein VPC-Netzwerk des Diensterstellers kann mehrere Dienstnutzer unterstützen. Der Nutzer kann eine Verbindung zum Erstellerdienst herstellen, indem er Traffic an einen Private Service Connect-Endpunkt im VPC-Netzwerk des Nutzers sendet. Der Endpunkt leitet den Traffic an das VPC-Netzwerk weiter, das den veröffentlichten Dienst enthält.

Screenshot: Private Service Connect-Konfiguration zum Veröffentlichen und Verarbeiten verwalteter Dienste über einen Endpunkt.

Abbildung 9. Screenshot: Private Service Connect-Konfiguration zum Veröffentlichen eines verwalteten Dienstes über einen Dienstanhang und zum Verarbeiten des Dienstes über einen Endpunkt.

Zugriff auf private Dienste

Private Service Connect ist die empfohlene Methode, mit der ein Dienstersteller einem Dienstnutzer einen Dienst zur Verfügung stellen kann. Private Service Connect unterstützt jedoch nicht alle Dienste. Mit dem Zugriff auf private Dienste können Sie auf diese gelisteten Dienste zugreifen.

Connector für serverlosen VPC-Zugriff

Ein VPC-Connector für serverlosen Zugriff verarbeitet den Traffic zwischen Ihrer serverlosen Umgebung und Ihrem VPC-Netzwerk. Wenn Sie einen Connector in Ihrem Google Cloud-Projekt erstellen, hängen Sie ihn an ein bestimmtes VPC-Netzwerk und eine Region an. Anschließend konfigurieren Sie Ihre serverlosen Dienste so, dass sie diesen Connector für ausgehenden Netzwerktraffic verwenden. Sie können einen Connector mit einem Subnetz oder einem CIDR-Bereich angeben. Traffic, der über den Connector an das VPC-Netzwerk gesendet wird, stammt aus dem von Ihnen angegebenen Subnetz oder aus dem CIDR-Bereich, wie in Abbildung 10 dargestellt.

Konfiguration des Connectors für serverlosen VPC-Zugriff für den Zugriff auf serverlose Google Cloud -Umgebungen über interne IP-Adressen im VPC-Netzwerk.

Abbildung 10. Konfiguration des Connectors für serverlosen VPC-Zugriff für den Zugriff auf Google Cloud serverlose Umgebungen über interne IP-Adressen im VPC-Netzwerk.

Connectors für serverlosen VPC-Zugriff werden in jeder Region unterstützt, die Cloud Run, Cloud Run-Funktionen oder die App Engine-Standardumgebung unterstützt. Weitere Informationen finden Sie in der Liste der unterstützten Dienste und der unterstützten Netzwerkprotokolle für die Verwendung des VPC-Server-Zugriffsconnectors.

Ausgehender Direct VPC-Traffic

Mit ausgehendem Direct VPC-Traffic kann Ihr Cloud Run-Dienst Traffic an ein VPC-Netzwerk senden, ohne dass ein Connector für serverlosen VPC-Zugriff eingerichtet werden muss.

VPC Service Controls

Mit VPC Service Controls können Sie Daten-Exfiltration aus Diensten wie Cloud Storage oder BigQuery verhindern, indem autorisierte Zugriffe aus dem Internet oder von Projekten verhindert werden, die nicht Teil eines Sicherheitsperimeters sind. Stellen Sie sich beispielsweise ein Szenario vor, in dem menschliche Fehler oder eine falsche Automatisierung dazu führen, dass IAM-Richtlinien für einen Dienst wie Cloud Storage oder BigQuery falsch festgelegt werden. Daher sind die Ressourcen in diesen Diensten öffentlich zugänglich. In diesem Fall besteht ein Risiko der Datenfreigabe. Wenn Sie diese Dienste als Teil des VPC Service Controls-Perimeters konfiguriert haben, wird der eingehende Zugriff auf die Ressourcen blockiert, auch wenn IAM-Richtlinien den Zugriff zulassen.

VPC Service Controls kann Perimeter basierend auf Clientattributen wie Identitätstyp (Dienstkonto oder Nutzer) und Netzwerkherkunft (IP-Adresse oder VPC-Netzwerk) erstellen.

Mit VPC Service Controls können Sie die folgenden Sicherheitsrisiken mindern:

  • Zugriff aus nicht autorisierten Netzwerken mit gestohlenen Anmeldedaten
  • Daten-Exfiltration durch böswillige Insider oder manipulierten Code
  • Öffentliche Offenlegung privater Daten durch falsch konfigurierte IAM-Richtlinien

Abbildung 11 zeigt, wie Sie mit VPC Service Controls einen Dienstperimeter einrichten können, um diese Risiken zu verringern.

VPC-Dienstperimeter wurde auf Hybridumgebungen erweitert, die private Zugriffsdienste verwenden.

Abbildung 11. VPC-Dienstperimeter wurde auf Hybridumgebungen erweitert, die private Zugriffsdienste verwenden.

Mithilfe von Regeln für eingehenden und ausgehenden Traffic können Sie die Kommunikation zwischen zwei Dienstperimetern aktivieren, wie in Abbildung 12 dargestellt.

Regeln für eingehenden und ausgehenden Traffic für die Kommunikation zwischen Dienstperimetern konfigurieren.

Abbildung 12. Regeln für eingehenden und ausgehenden Traffic für die Kommunikation zwischen Dienstperimetern konfigurieren.

Ausführliche Empfehlungen für Deployment-Architekturen von VPC Service Controls finden Sie unter Dienstperimeter entwerfen und einrichten. Weitere Informationen zur Liste der Dienste, die von VPC Service Controls unterstützt werden, finden Sie unter Unterstützte Produkte und Einschränkungen.

Verteilte Zero-Trust-Architektur

Sicherheitskontrollen für die Netzwerkperimeter sind erforderlich, aber nicht ausreichend, um die Sicherheitsgrundsätze der geringsten Berechtigung und Verteidigung im Detail zu unterstützen. Zero-Trust-verteilte Architekturen basieren auf dem Netzwerk-Perimeterrand, aber verlassen sich nicht allein auf die Durchsetzung der Sicherheit. Als verteilte Architekturen bestehen sie aus Mikrodiensten mit einer Erzwingung der Sicherheitsrichtlinie pro Dienst, einer starken Authentifizierung und einer Workload Identity.

Sie können verteilte Zero-Trust-Architekturen als Dienste implementieren, die von Cloud Service Mesh verwaltet werden.

Cloud Service Mesh

Cloud Service Mesh bietet ein sofort einsatzbereites verteiltes Zero Trust Architecture-Mesh-Netzwerk mit mTLS, das auf Istio-Grundlagen basiert. Sie richten das Mesh-Netzwerk mit einem integrierten Ablauf ein. Verwaltetes Cloud Service Mesh mit von Google verwalteten Daten und Steuerungsebenen wird in GKE unterstützt. Außerdem steht eine Steuerungsebene im Cluster zur Verfügung, die für andere Umgebungen wie Google Distributed Cloud oder GKE Multi-Cloud geeignet ist. Cloud Service Mesh verwaltet die Identität und Zertifikate für Sie und stellt ein Istio-basiertes Autorisierungsrichtlinienmodell bereit.

Cloud Service Mesh nutzt Flotten für die Verwaltung der Konfiguration und Identität von Multicluster-Diensten. Wenn Ihre Arbeitslasten wie in Cloud Service Mesh in einer flachen (oder freigegebenen) VPC-Netzwerkkonnektivität ausgeführt werden, gibt es neben der Firewallkonfiguration keine besonderen Anforderungen an die Netzwerkkonnektivität. Wenn Ihre Architektur mehrere Cloud Service Mesh-Cluster in separaten VPC-Netzwerken oder Netzwerkumgebungen enthält, z. B. über eine Cloud Interconnect-Verbindung, benötigen Sie außerdem ein Ost-West-Gateway. Die Best Practices für Netzwerke für Cloud Service Mesh sind dieselben wie in Best Practices für GKE-Netzwerke beschrieben.

Cloud Service Mesh kann auch in Identity-Aware Proxy (IAP) eingebunden werden. Mit IAP können Sie detaillierte Zugriffsrichtlinien festlegen, um den Nutzerzugriff auf Basis von Attributen der ursprünglichen Anfrage wie Nutzeridentität, IP-Adresse und Gerätetyp steuern zu können. Diese Ebene der Steuerung ermöglicht eine End-to-End-Umgebung mit Zero-Trust.

Sie müssen die Anforderungen an GKE-Cluster berücksichtigen, wenn Sie Cloud Service Mesh verwenden. Weitere Informationen finden Sie in der Dokumentation „Einzelne Projektinstallation in GKE” im Abschnitt Anforderungen.

Nächste Schritte