Dieses Dokument ist Teil einer Reihe, in der Netzwerk- und Sicherheitsarchitekturen für Unternehmen beschrieben werden, die Arbeitslasten von Rechenzentren zu Google Cloud migrieren.
Die Reihe besteht aus folgenden Dokumenten:
- Netzwerke für die Migration von Unternehmensarbeitslasten entwerfen: Architekturansätze
- Networking für sicheren Intra-Cloud-Zugriff: Referenzarchitekturen (dieses Dokument)
- Netzwerk für die Internetbereitstellung von Anwendungen: Referenzarchitekturen
- Netzwerke für Hybrid- und Multi-Cloud-Arbeitslasten: Referenzarchitekturen
Arbeitslasten für Intra-Cloud-Anwendungsfälle befinden sich in VPC-Netzwerken und müssen eine Verbindung zu anderen Ressourcen in Google Cloud herstellen. 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.
Firewall
Durch die Konfiguration von Firewallregeln können Sie einen sicheren Perimeter einrichten.
Sie können Netzwerk-Tags verwenden, um detaillierte Firewallregeln auf eine Sammlung von VMs anzuwenden. Ein Tag ist ein beliebiges Attribut, das aus einem Zeichenstring besteht, der dem Feld tags der VM zum Zeitpunkt der VM-Erstellung hinzugefügt wurde.
Ein Tag kann auch später durch Bearbeiten der VM zugewiesen werden. Implementierungsrichtlinien zum Verwalten von Traffic mit Google Cloud-Firewallregeln finden Sie unter Netzwerk-Firewallrichtlinien im Enterprise-Foundations-Blueprint.
Sie können auch das Firewall-Logging 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 VM-Tags den Traffic zwischen VMs in einem VPC-Netzwerk einschränken können.
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 mehreren Netzwerkschnittstellen. Über die NVA können Sie eine direkte Verbindung zu mehreren VPC-Netzwerken herstellen. Sicherheitsfunktionen wie Web Application Firewall (WAF) und Sicherheitsfirewalls auf Anwendungsebene können auf den VMs implementiert werden. Sie können NVAs verwenden, um Sicherheitsfunktionen für den Ost-West-Traffic zu implementieren, insbesondere wenn Sie eine Hub-Spoke-Konfiguration verwenden, wie in Abbildung 2 dargestellt.
Implementierungsrichtlinien zur Verwendung von NVAs in Google Cloud finden Sie unter Zentrale Netzwerkanwendungen in Google Cloud.
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 VPC-Netzwerk Cloud IDS-Endpunkte, die mit Ihrem Google Cloud-Projekt verknüpft sind. 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.
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.
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.
Es gibt zwei Modelle für die Verwendung von VPC-Netzwerk-Peering in einer Lift-and-Shift-Architektur. Eines hat eine „reine” Hub-and-Spoke-Architektur und die andere ist in einer Hub-and-Spoke-Architektur mit Transitivität, wobei der Traffic von einem Spoke einen anderen Spoke erreichen kann. In den folgenden Abschnitten erfahren Sie, wie VPC-Netzwerk-Peering mit diesen verschiedenen Architekturen verwendet wird.
Hub-and-Spoke-Architektur
Eine Hub-and-Spoke-Architektur ist ein beliebtes Modell für die VPC-Konnektivität mit VPC-Netzwerk-Peering. 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. In einem reinen Hub-and-Spoke-Modell ist der Trafficaustausch zwischen den Spokes (Transitive Traffic) nicht zulässig. Abbildung 4 zeigt eine reine Hub-and-Spoke-Architektur, bei der die Spokes mit VPC-Netzwerk-Peering mit dem Hub verbunden werden. Implementierungsrichtlinien zum Erstellen von Hub-and-Spoke-Netzwerken finden Sie unter Hub-and-Spoke-Netzwerktopologie im Enterprise-Foundations-Blueprint.
Wenn Sie jedoch keine Trennung auf VPC-Ebene benötigen, können Sie eine Architektur mit freigegebener VPC verwenden, die ein einfacheres Modell für einige Unternehmen ist, die noch am Anfang mit Google Cloud stehen.
Abbildung 4. Hub-and-Spoke-Netzwerkarchitektur mit VPC-Netzwerk-Peering für die Netzwerkisolation und nicht transitive Konnektivität.
Hub-and-Spoke mit Transitivität
Es gibt mehrere Ansätze für die Verwendung von VPC-Netzwerk-Peering, um Hub-and-Spoke mit Transitivität zu aktivieren (Traffic von einem Spoke kann andere Spokes über den Hub erreichen). Sie können das VPC-Netzwerk-Peering in einer vollständigen Mesh-Topologie verwenden, wobei jedes VPC-Netzwerk direkt mit jedem anderen VPC-Netzwerk verbunden ist, das es erreichen muss.
Alternativ können Sie einen NVA verwenden, um den Hub und die Spokes miteinander zu verbinden. Die NVA befindet sich dann hinter internen Load-Balancern, die als nächster Hop für Traffic aus den VPC-Spokes verwendet werden. Abbildung 5 zeigt beide Optionen.
Darüber hinaus können Sie VPNs verwenden, um eine Verbindung zwischen dem Hub und den Spoke-VPC-Netzwerken herzustellen. Diese Anordnung ermöglicht die Erreichbarkeit von Spoke-Spoke-Verbindungen, die eine Transitivität im Hub-VPC-Netzwerk bieten.
Abbildung 5. Hub-and-Spoke-Netzwerkkonfiguration mit Cloud VPN für Netzwerkisolation und transitive Konnektivität.
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.
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.
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.
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.
Abbildung 9. Screenshot: Private Service Connect-Konfiguration zum Veröffentlichen eines verwalteten Dienstes über einen Dienstanhang und zum Verarbeiten des Dienstes über einen Endpunkt.
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.
Abbildung 10. Konfiguration des Connectors für serverlosen VPC-Zugriff für den Zugriff auf serverlose Google Cloud-Umgebungen über interne IP-Adressen im VPC-Netzwerk.
Connectors für serverlosen VPC-Zugriff werden in jeder Region unterstützt, die Cloud Run, Cloud Functions 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.
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.
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.
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 Traffic Director und Anthos Service Mesh verwaltet werden.
Traffic Director
Traffic Director kann so konfiguriert werden, dass ein verteiltes Zero-Trust-Architektur-Mesh-Netzwerk in einem GKE-Cluster mit Dienstsicherheit bereitgestellt wird. In diesem Modell werden in GKE-Diensten mit Envoy-Sidecars oder proxylosem gRPC, Identität, Zertifikate und Autorisierungsrichtlinie von Traffic Director, Workload Identity,Certificate Authority Service und IAM verwaltet. Die Zertifikatsverwaltung und die sichere Benennung erfolgt über die Plattform. Die gesamte Dienstkommunikation unterliegt der mTLS-Transportsicherheit. Abbildung 13 zeigt einen Cluster mit dieser Konfiguration.
Abbildung 13. Verteiltes Zero-Trust-Architektur-Mesh-Netzwerk in einem einzelnen Cluster mit Traffic Director.
Eine Autorisierungsrichtlinie gibt an, wie ein Server eingehende Anfragen oder RPCs autorisiert. Die Autorisierungsrichtlinie kann so konfiguriert werden, dass eine eingehende Anfrage oder ein RPC basierend auf verschiedenen Parametern wie der Identität des Clients, der die Anfrage gesendet hat, dem Host, den Headern und anderen HTTP-Attributen zugelassen oder abgelehnt wird. Implementierungsrichtlinien sind für die Konfiguration von Autorisierungsrichtlinien für Mesh-Netzwerke basierend auf gRPC und Envoy verfügbar.
In Abbildung 13 hat die Architektur einen einzelnen Cluster und ein flaches Netzwerk (gemeinsamer IP-Adressbereich). In der verteilten Zero-Trust-Architektur wird für die Isolation, Position und Skalierung in der Regel mehrere Cluster verwendet.
In komplexeren Umgebungen können mehrere Cluster die verwaltete Identität gemeinsam nutzen, wenn die Cluster mithilfe von Flotten gruppiert werden. In diesem Fall können Sie die Netzwerkverbindung für unabhängige VPC-Netzwerke mit Private Service Connect konfigurieren. Dieser Ansatz ähnelt dem hybriden Arbeitslastenzugriff auf Multi-Cluster-Netzwerkkonnektivität, wie weiter unten in diesem Dokument beschrieben.
Informationen zur detaillierten Steuerung des Traffics mit Traffic Director finden Sie unter Erweiterte Trafficverwaltung.
Anthos Service Mesh
Anthos 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 Anthos 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 Virtualises oder GKE Multi-cloud geeignet ist. Anthos Service Mesh verwaltet die Identität und Zertifikate für Sie und stellt ein Istio-basiertes Autorisierungsrichtlinienmodell bereit.
Anthos Service Mesh nutzt Flotten für die Verwaltung der Konfiguration und Identität von Multicluster-Diensten. Wenn Ihre Arbeitslasten wie in Traffic Director 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 Anthos 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 Anthos Service Mesh sind dieselben wie in Best Practices für GKE-Netzwerke beschrieben.
Anthos 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 Anthos Service Mesh verwenden. Weitere Informationen finden Sie in der Dokumentation „Einzelne Projektinstallation in GKE” im Abschnitt Anforderungen.
Nächste Schritte
- Netzwerk für die Internetbereitstellung von Anwendungen: Referenzarchitekturen
- Netzwerke für Hybrid- und Multi-Cloud-Arbeitslasten: Referenzarchitekturen
- Die Migration zu Google Cloud kann Ihnen bei der Planung, Gestaltung und Implementierung der Migration Ihrer Arbeitslasten zu Google Cloud helfen.
- Das Design von Landing Zones in Google Cloud enthält eine Anleitung zum Erstellen eines Netzwerks für Landing Zones.
- Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.