Architekturmuster für Hybrid- und Multi-Cloud-Netzwerke

Last reviewed 2023-12-14 UTC

Dieses Dokument ist das dritte von drei Dokumenten in einer Reihe. Es werden Architekturmuster für Hybrid- und Multi-Cloud-Netzwerke behandelt. In diesem Teil werden mehrere gängige sichere Netzwerkarchitekturmuster erläutert, die Sie für Hybrid- und Multi-Cloud-Architekturen verwenden können. Es werden die Szenarien beschrieben, für die sich diese Netzwerkmuster am besten eignen, und Best Practices für die Implementierung mit Google Cloud.

Der Dokumentensatz für Hybrid- und Multi-Cloud-Architekturmuster besteht aus den folgenden Teilen:

  • Hybrid- und Multi-Cloud-Architekturen erstellen: Hier erfahren Sie, wie Sie eine Strategie für die Entwicklung einer Hybrid- und Multi-Cloud-Einrichtung mit Google Cloud planen.
  • Hybrid- und Multi-Cloud-Architekturmuster: Hier erfahren Sie mehr über gängige Architekturmuster, die Sie im Rahmen einer Hybrid- und Multi-Cloud-Strategie verwenden können.
  • Architekturmuster für Hybrid- und Multi-Cloud-Netzwerke: In diesem Dokument werden Architekturmuster für Hybrid- und Multi-Cloud-Netzwerke aus Netzwerkperspektive behandelt.

Die sichere und zuverlässige Verbindung privater Rechenumgebungen mit Google Cloud ist für eine erfolgreiche Hybrid- und Multi-Cloud-Architektur wichtig. Die für eine Hybrid- und Multi-Cloud-Einrichtung ausgewählte Hybrid-Netzwerkkonnektivität und Cloud-Netzwerkarchitektur muss die individuellen Arbeitslastanforderungen Ihres Unternehmens erfüllen. Außerdem muss sie zu den Architekturmustern passen, die Sie anwenden möchten. Auch wenn Sie jedes Design möglicherweise anpassen müssen, gibt es gängige Muster, die Sie als Blaupause verwenden können.

Die Netzwerkarchitekturmuster in diesem Dokument sollten nicht als Alternativen zum Design der Landing-Zone in Google Cloud betrachtet werden. Stattdessen sollten Sie die ausgewählten Architekturmuster als Teil des gesamten Google Cloud-Landingzone-Designs entwerfen und bereitstellen. Dieses Design umfasst die folgenden Bereiche:

  • Identitäten
  • Ressourcenverwaltung
  • Sicherheit
  • Netzwerk
  • Monitoring

Für verschiedene Anwendungen können unterschiedliche Netzwerkarchitekturmuster verwendet werden, die in die Landingzone-Architektur eingebunden sind. Bei einer Multi-Cloud-Umgebung sollten Sie für Konsistenz beim Design der Landingzone in allen Umgebungen sorgen.

Diese Reihe enthält die folgenden Seiten:

Beitragende

Autor: Marwan Al Shawi | Partner Customer Engineer

Weitere Beitragende:

Architekturmuster

In den Dokumenten dieser Reihe werden Netzwerkarchitekturmuster beschrieben, die auf den erforderlichen Kommunikationsmodellen zwischen Anwendungen in Google Cloud und anderen Umgebungen (lokal, in anderen Clouds oder in beiden) basieren.

Diese Muster sollten in die gesamte Landingzone-Architektur der Organisation einbezogen werden. Diese kann mehrere Netzwerkmuster enthalten, um die spezifischen Kommunikations- und Sicherheitsanforderungen verschiedener Anwendungen zu erfüllen.

In den Dokumenten dieser Reihe werden auch die verschiedenen Designvarianten erläutert, die mit jedem Architekturmuster verwendet werden können. Mit den folgenden Netzwerkmustern können Sie die Kommunikations- und Sicherheitsanforderungen für Ihre Anwendungen erfüllen:

Gespiegeltes Muster

Beim gespiegelten Muster wird das Design einer bestimmten vorhandenen Umgebung oder mehrerer vorhandener Umgebungen in einer neuen Umgebung oder mehreren neuen Umgebungen repliziert. Daher gilt dieses Muster hauptsächlich für Architekturen, die dem Umgebungshybrid-Muster folgen. Dabei werden Entwicklungs- und Testarbeitslasten in einer Umgebung und Staging- sowie Produktionsarbeitslasten in einer anderen Umgebung ausgeführt.

Beim gespiegelten Muster wird davon ausgegangen, dass Test- und Produktionsarbeitslasten nicht direkt miteinander kommunizieren sollen. Von Vorteil ist jedoch, wenn sich beide Arbeitslastgruppen konsistent verwalten lassen.

Wenn Sie dieses Muster verwenden, verbinden Sie die beiden Rechenumgebungen so, dass die folgenden Anforderungen erfüllt werden:

  • Mithilfe von Continuous Integration/Continuous Deployment (CI/CD) können Arbeitslasten in allen oder bestimmten Rechenumgebungen bereitgestellt und verwaltet werden.
  • Monitoring, Konfigurationsverwaltung und andere Verwaltungssysteme sollten in allen Rechenumgebungen funktionieren.
  • Arbeitslasten können nicht direkt zwischen Rechenumgebungen kommunizieren. Falls erforderlich, muss die Kommunikation detailliert und kontrolliert erfolgen.

Architektur

Das folgende Architekturdiagramm zeigt eine allgemeine Referenzarchitektur dieses Musters, die CI/CD, Monitoring, Konfigurationsverwaltung, andere Verwaltungssysteme und die Arbeitslastkommunikation unterstützt:

Datenfluss zwischen einer CI/CD- und einer Verwaltungs-VPC in Google Cloud und einer lokalen Produktionsumgebung. Daten fließen auch zwischen dem CI/CD-VPC und den Entwicklungs- und Testumgebungen in Google Cloud.

Die Beschreibung der Architektur im vorherigen Diagramm sieht so aus:

  • Arbeitslasten werden basierend auf den funktionalen Umgebungen (Entwicklung, Tests, CI/CD und Verwaltungstools) auf separate VPCs in Google Cloud verteilt.
  • Die freigegebene VPC wird für Entwicklungs- und Testarbeitslasten verwendet. Für CI/CD und Verwaltungstools wird eine zusätzliche VPC verwendet. Bei freigegebenen VPCs:
    • Die Anwendungen werden von verschiedenen Teams pro Umgebung und pro Dienstprojekt verwaltet.
    • Das Hostprojekt verwaltet und steuert die Netzwerkkommunikation und die Sicherheitskontrollen zwischen der Entwicklungs- und der Testumgebung sowie außerhalb der VPC.
  • Die CI/CD-VPC ist mit dem Netzwerk verbunden, in dem die Produktionsarbeitslasten in Ihrer privaten Rechenumgebung ausgeführt werden.
  • Firewallregeln erlauben nur zulässigen Traffic.
    • Sie können auch Cloud Next Generation Firewall Enterprise mit Intrusion Prevention Service (IPS) verwenden, um Deep Packet Inspection zur Bedrohungsprävention zu implementieren, ohne das Design oder Routing zu ändern. Cloud Next Generation Firewall Enterprise erstellt von Google verwaltete zonale Firewall-Endpunkte, die Technologie zum Abfangen von Paketen verwenden, um die Arbeitslasten transparent auf die konfigurierten Bedrohungssignaturen zu prüfen. Außerdem schützt es Arbeitslasten vor Bedrohungen.
  • Ermöglicht die Kommunikation zwischen den VPCs mit Peering über interne IP-Adressen.
    • Das Peering in diesem Muster ermöglicht es, Entwicklungs- und Testarbeitslasten auf CI/CD- und Verwaltungssystemen bereitzustellen und zu verwalten.
  • Beachten Sie die folgenden allgemeinen Best Practices.

Sie stellen diese CI/CD-Verbindung mit einer der oben beschriebenen Verbindungsoptionen für Hybrid- und Multi-Cloud-Netzwerke her, die Ihren Geschäfts- und Anwendungsanforderungen entspricht. Damit Sie Produktionsarbeitslasten bereitstellen und verwalten können, bietet diese Verbindung eine private Netzwerkerreichbarkeit zwischen den verschiedenen Rechenumgebungen. Alle Umgebungen sollten einen sich nicht überschneidenden IP-Adressbereich nach RFC 1918 haben.

Wenn die Instanzen in den Entwicklungs- und Testumgebungen Internetzugriff benötigen, können Sie die folgenden Optionen in Betracht ziehen:

  • Sie können Cloud NAT im selben Netzwerk des freigegebene VPC-Hostprojekts bereitstellen. Durch die Bereitstellung im selben Netzwerk des freigegebene VPC-Hostprojekts wird verhindert, dass diese Instanzen direkt über das Internet zugänglich sind.
  • Für ausgehenden Webtraffic können Sie den Sicheren Web-Proxy verwenden. Der Proxy bietet mehrere Vorteile.

Weitere Informationen zu den Google Cloud-Tools und ‑Funktionen, mit denen Sie in Google Cloud und in Hybrid- und Multi-Cloud-Umgebungen entwickeln, testen und bereitstellen können, finden Sie im Blogpost DevOps und CI/CD in Google Cloud.

Varianten

Das Architekturmuster gespiegelt bietet die folgenden Optionen, um verschiedene Designanforderungen zu erfüllen und gleichzeitig alle Kommunikationsanforderungen zu berücksichtigen:

Freigegebene VPC pro Umgebung

Die Designoption „Freigegebene VPC pro Umgebung“ ermöglicht eine Trennung auf Anwendungs- oder Dienstebene über Umgebungen hinweg, einschließlich CI/CD- und Verwaltungstools, die zur Erfüllung bestimmter organisatorischer Sicherheitsanforderungen erforderlich sein können. Diese Anforderungen beschränken die Kommunikation, die Verwaltungsdomain und die Zugriffssteuerung für verschiedene Dienste, die auch von verschiedenen Teams verwaltet werden müssen.

Bei diesem Design wird die Trennung durch eine Isolation auf Netzwerk- und Projektebene zwischen den verschiedenen Umgebungen erreicht. Dies ermöglicht eine detailliertere Kommunikation und Zugriffssteuerung durch die Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM).

Aus Sicht der Verwaltung und des Betriebs bietet dieses Design die Flexibilität, die von verschiedenen Teams erstellten Anwendungen und Arbeitslasten pro Umgebung und pro Dienstprojekt zu verwalten. VPC-Netzwerke und ihre Sicherheitsfunktionen können von Netzwerkteams basierend auf den folgenden möglichen Strukturen bereitgestellt und verwaltet werden:

  • Ein Team verwaltet alle Hostprojekte in allen Umgebungen.
  • Die Hostprojekte in den jeweiligen Umgebungen werden von verschiedenen Teams verwaltet.

Entscheidungen zur Verwaltung von Hostprojekten sollten auf der Teamstruktur, den Sicherheitsabläufen und den Zugriffsanforderungen der einzelnen Teams basieren. Sie können diese Designvariante auf die Designoption „Freigegebenes VPC-Netzwerk für jede Umgebung“ anwenden. Sie müssen jedoch die Kommunikationsanforderungen des gespiegelten Musters berücksichtigen, um zu definieren, welche Kommunikation zwischen den verschiedenen Umgebungen zulässig ist, einschließlich der Kommunikation über das Hybridnetzwerk.

Sie können auch ein freigegebene VPC-Netzwerk für jede Hauptumgebung bereitstellen, wie im folgenden Diagramm dargestellt:

Beim VPC-Peering in Google Cloud werden Daten zwischen Entwicklungs- und Testumgebungen sowie CI/CD- und Verwaltungssubnetzen freigegeben. Die Subnetze geben Daten zwischen Google Cloud und einer lokalen Umgebung frei.

Zentrale Firewall der Anwendungsebene

In einigen Fällen erfordern die Sicherheitsanforderungen die Berücksichtigung der Anwendungsschicht (Layer 7) und der detaillierten Paketprüfung mit erweiterten Firewallmechanismen, die über die Möglichkeiten der Cloud Next Generation Firewall hinausgehen. Um die Sicherheitsanforderungen und -standards Ihrer Organisation zu erfüllen, können Sie eine NGFW-Appliance verwenden, die in einer virtuellen Netzwerk-Appliance (NVA) gehostet wird. Mehrere Sicherheitspartner von Google Cloud bieten Optionen, die sich gut für diese Aufgabe eignen.

Wie im folgenden Diagramm dargestellt, können Sie die NVA mithilfe von mehreren Netzwerkschnittstellen in den Netzwerkpfad zwischen der Virtual Private Cloud und der privaten Rechenumgebung einfügen.

Beim VPC-Peering in Google Cloud werden Daten zwischen Entwicklungs- und Testumgebungen sowie CI/CD- und Verwaltungssubnetzen freigegeben. Die Subnetze teilen Daten über ein Transit-VPC-Netzwerk zwischen Google Cloud und einer lokalen Umgebung.

Dieses Design kann auch mit mehreren freigegebenen VPCs verwendet werden, wie im folgenden Diagramm dargestellt.

Beim VPC-Peering in Google Cloud werden Daten zwischen Entwicklungs- und Testumgebungen sowie CI/CD- und Verwaltungssubnetzen freigegeben. Die Subnetze verwenden eine NVA, um Daten über ein Transit-VPC-Netzwerk zwischen Google Cloud und einer lokalen Umgebung auszutauschen.

Die NVA in diesem Design dient als Perimeter-Sicherheitsschicht. Außerdem dient sie als Grundlage für die Aktivierung der Inline-Traffic-Prüfung und die Durchsetzung strenger Zugriffssteuerungsrichtlinien.

Für eine robuste mehrschichtige Sicherheitsstrategie, die VPC-Firewallregeln und Funktionen für den Dienst zur Einbruchsprävention umfasst, sollten Sie sowohl für Ost-West- als auch für Nord-Süd-Trafficflüsse weitere Traffic-Inspektionen und Sicherheitskontrollen einrichten.

Hub-and-Spoke-Topologie

Eine weitere mögliche Designvariante besteht darin, separate VPCs (einschließlich freigegebener VPCs) für die Entwicklung und verschiedene Testphasen zu verwenden. In dieser Variante, wie im folgenden Diagramm dargestellt, sind alle Staging-Umgebungen in einer Hub-and-Spoke-Architektur mit der CI/CD- und der Verwaltungs-VPC verbunden. Verwenden Sie diese Option, wenn Sie die Verwaltungsdomains und die Funktionen in jeder Umgebung trennen müssen. Das Hub-and-Spoke-Kommunikationsmodell kann bei den folgenden Anforderungen helfen:

  • Anwendungen müssen auf eine Reihe gängiger Dienste zugreifen können, z. B. auf Monitoring, Konfigurationsverwaltungstools, CI/CD oder Authentifizierung.
  • Gemeinsame Sicherheitsrichtlinien müssen zentral über den Hub auf eingehenden und ausgehenden Traffic angewendet werden.

Weitere Informationen zu Hub-and-Spoke-Designoptionen finden Sie unter Hub-and-Spoke-Topologie mit zentralisierten Appliances und Hub-and-Spoke-Topologie ohne zentralisierte Appliances.

Entwicklungs- und Testumgebungen geben Daten an eine CI/CD-Hub-VPC und eine Verwaltungs-VPC für eine lokale Umgebung weiter.

Wie im vorherigen Diagramm dargestellt, laufen die VPC-interne Kommunikation und die hybride Konnektivität alle über das Hub-VPC. Im Rahmen dieses Musters können Sie die Kommunikation im Hub-VPC steuern und einschränken, um sie an Ihre Konnektivitätsanforderungen anzupassen.

Im Rahmen der Hub-and-Spoke-Netzwerkarchitektur sind dies die wichtigsten Konnektivitätsoptionen (zwischen den Spoke- und Hub-VPCs) in Google Cloud:

  • VPC-Netzwerk-Peering
  • VPN
  • Virtuelle Netzwerk-Appliance (NVA) verwenden

Weitere Informationen dazu, welche Option Sie in Ihrem Design berücksichtigen sollten, finden Sie unter Hub-and-Spoke-Netzwerkarchitektur. Ein wichtiger Einflussfaktor für die Auswahl von VPN über VPC-Peering zwischen den Spokes und dem Hub-VPC ist, ob Traffic-Transitivit erforderlich ist. Die Traffic-Transitivität bedeutet, dass Traffic von einem Spoke andere Spokes über den Hub erreichen kann.

Verteilte Zero-Trust-Architektur für Mikrodienste

Für Hybrid- und Multi-Cloud-Architekturen können mehrere Cluster erforderlich sein, um die technischen und geschäftlichen Ziele zu erreichen. Dazu gehört auch die Trennung der Produktionsumgebung von der Entwicklungs- und Testumgebung. Daher sind Sicherheitskontrollen für den Netzwerkperimeter wichtig, insbesondere wenn sie zur Einhaltung bestimmter Sicherheitsanforderungen erforderlich sind.

Es reicht nicht aus, die Sicherheitsanforderungen der aktuellen cloudbasierten verteilten Mikrodienstarchitekturen zu erfüllen. Sie sollten auch verteilte Zero-Trust-Architekturen in Betracht ziehen. Die verteilte Zero-Trust-Architektur für Mikrodienste unterstützt Ihre Mikrodienstarchitektur mit Erzwingung von Sicherheitsrichtlinien, Authentifizierung und Arbeitslastidentität auf Mikrodienstebene. Das Vertrauen ist identitätsbasiert und wird für jeden Dienst erzwungen.

Mit einer verteilten Proxyarchitektur wie einem Service Mesh können Dienste Anrufer effektiv validieren und für jede Anfrage detaillierte Zugriffssteuerungsrichtlinien implementieren. So wird eine sicherere und skalierbarere Mikrodienstumgebung ermöglicht. Mit Cloud Service Mesh können Sie ein gemeinsames Mesh-Netzwerk verwenden, das sowohl Ihre Google Cloud-Bereitstellungen als auch lokale Bereitstellungen umfasst. Das Mesh verwendet Autorisierungsrichtlinien, um die Dienst-zu-Dienst-Kommunikation zu sichern.

Sie können auch den Apigee Adapter for Envoy, eine schlanke Apigee API-Gateway-Bereitstellung in einem Kubernetes-Cluster, in diese Architektur einbinden. Apigee Adapter for Envoy ist ein Open-Source-Edge- und -Dienstproxy, der für cloudbasierte Anwendungen entwickelt wurde.

Daten fließen zwischen Diensten in Google Cloud und einer lokalen Umgebung über eine verteilte Proxyarchitektur.

Weitere Informationen zu diesem Thema finden Sie in den folgenden Artikeln:

Best Practices für gespiegelte Muster

  • Die für die Bereitstellung oder Neukonfiguration von Produktionsbereitstellungen erforderlichen CI/CD-Systeme müssen hochverfügbar sein. Das bedeutet, dass alle Architekturkomponenten so konzipiert sein müssen, dass die erwartete Systemverfügbarkeit erreicht wird. Weitere Informationen finden Sie unter Zuverlässigkeit der Google Cloud-Infrastruktur.
  • Um Konfigurationsfehler bei wiederkehrenden Prozessen wie Codeaktualisierungen zu vermeiden, ist die Automatisierung zur Standardisierung Ihrer Builds, Tests und Bereitstellungen unerlässlich.
  • Die Integration zentralisierter NVAs in dieses Design erfordert möglicherweise die Einbindung mehrerer Segmente mit unterschiedlichen Sicherheitszugriffssteuerungen.
  • Beim Entwerfen einer Lösung mit NVAs ist es wichtig, die Hochverfügbarkeit (HA) der NVAs zu berücksichtigen, um einen einzelnen Fehlerpunkt zu vermeiden, der die gesamte Kommunikation blockieren könnte. Folgen Sie der Anleitung Ihres NVA-Anbieters für die HA- und Redundanz-Design- und -Implementierung.
  • Wenn Sie lokale IP-Routen nicht über VPC-Peering oder VPN in die VPC für Entwicklung und Tests exportieren, können Sie die Netzwerkerreichbarkeit von Entwicklungs- und Testumgebungen auf die lokale Umgebung beschränken. Weitere Informationen finden Sie unter Austausch benutzerdefinierter Routen beim VPC-Netzwerk-Peering.
  • Für Arbeitslasten mit privater IP-Adressierung, für die der Zugriff auf Google APIs erforderlich sein kann, können Sie Google APIs mithilfe eines Private Service Connect-Endpunkts in einem VPC-Netzwerk verfügbar machen. Weitere Informationen finden Sie in dieser Reihe unter Gated Ingress.
  • Lesen Sie die allgemeinen Best Practices für Hybrid- und Multi-Cloud-Netzwerkarchitekturmuster.

Mesh-Muster

Das Mesh-Muster basiert auf der Einrichtung einer Hybridnetzwerkarchitektur. Diese Architektur erstreckt sich über mehrere Rechenumgebungen. In diesen Umgebungen können alle Systeme miteinander kommunizieren und sind nicht auf eine Einwegkommunikation beschränkt, die auf den Sicherheitsanforderungen Ihrer Anwendungen basiert. Dieses Netzwerkmuster gilt hauptsächlich für mehrstufige Hybrid-, partitionierte Multi-Cloud- oder Bursting-Architekturen. Sie gilt auch für die Geschäftskontinuität, um eine Notfallwiederherstellungsumgebung (DR) in Google Cloud bereitzustellen. In allen Fällen müssen Sie die Rechenumgebungen so verbinden, dass die folgenden Kommunikationsanforderungen erfüllt werden:

  • Arbeitslasten können über Umgebungsgrenzen hinweg über private IP-Adressen nach RFC 1918 kommunizieren.
  • Die Kommunikation kann von beiden Seiten initiiert werden. Die Details des Kommunikationsmodells können je nach Anwendungen und Sicherheitsanforderungen variieren, z. B. die Kommunikationsmodelle, die in den folgenden Designoptionen beschrieben werden.
  • Die von Ihnen verwendeten Firewallregeln müssen den Traffic zwischen bestimmten IP-Adressquellen und -zielen gemäß den Anforderungen der Anwendung oder Anwendungen zulassen, für die das Muster entwickelt wurde. Idealerweise sollten Sie einen mehrschichtigen Sicherheitsansatz verwenden, um den Trafficfluss sowohl zwischen als auch innerhalb von Rechenzentren detailliert einzuschränken.

Architektur

Das folgende Diagramm zeigt eine allgemeine Referenzarchitektur des vermaschten Musters.

Daten in einer Hybridnetzwerkarchitektur fließen von zwei Subnetzen in Google Cloud zu einer Arbeitslast in einer lokalen Umgebung.

  • Alle Umgebungen sollten einen sich nicht überschneidenden IP-Adressbereich nach RFC 1918 verwenden.
  • In Google Cloud können Sie Arbeitslasten in einer oder mehreren freigegebenen oder nicht freigegebenen VPCs bereitstellen. Weitere mögliche Designoptionen dieses Musters finden Sie in den folgenden Designvarianten. Die ausgewählte Struktur Ihrer VPCs sollte mit den Projekten und dem Design der Ressourcenhierarchie Ihrer Organisation übereinstimmen.
  • Das VPC-Netzwerk von Google Cloud wird auf andere Rechenumgebungen ausgeweitet. Diese Umgebungen können lokal sein oder sich in einer anderen Cloud befinden. Verwenden Sie eine der Hybrid- und Multi-Cloud-Netzwerkverbindungsoptionen, die Ihren Geschäfts- und Anwendungsanforderungen entspricht.
  • Beschränken Sie die Kommunikation auf die zulässigen IP-Adressen Ihrer Quellen und Ziele. Verwenden Sie eine oder mehrere der folgenden Funktionen:

    • Firewallregeln oder Firewallrichtlinien.

    • Virtuelle Netzwerk-Appliance (NVA) mit Prüfungsfunktionen für Firewalls der nächsten Generation (NGFW), die im Netzwerkpfad platziert wird.

    • Cloud Next Generation Firewall Enterprise mit Intrusion Prevention Service (IPS) zur Implementierung von Deep Packet-Untersuchung zum Schutz vor Bedrohungen, ohne das Netzwerkdesign oder das Routing zu ändern.

Varianten

Das Architekturmuster Mesh kann mit anderen Ansätzen kombiniert werden, um verschiedene Designanforderungen zu erfüllen, die dennoch die Kommunikationsanforderungen dieses Musters berücksichtigen. Die Musteroptionen werden in den folgenden Abschnitten beschrieben:

Eine VPC pro Umgebung

Die häufigsten Gründe für die Option „Ein VPC pro Umgebung“ sind:

  • Die Cloud-Umgebung erfordert eine Trennung der VPC-Netzwerke und ‑Ressourcen auf Netzwerkebene, die dem Design der Ressourcenhierarchie Ihrer Organisation entspricht. Wenn eine administrative Domaintrennung erforderlich ist, kann sie auch mit einem separaten Projekt pro Umgebung kombiniert werden.
    • Wenn Sie Netzwerkressourcen zentral in einem gemeinsamen Netzwerk verwalten und die verschiedenen Umgebungen voneinander isolieren möchten, verwenden Sie ein freigegebenes VPC für jede Umgebung in Google Cloud, z. B. für Entwicklung, Tests und Produktion.
  • Skalierungsanforderungen, die möglicherweise über die VPC-Kontingente für eine einzelne VPC oder ein einzelnes Projekt hinausgehen

Wie im folgenden Diagramm dargestellt, kann jedes VPC bei einem Design mit einem VPC pro Umgebung direkt über VPNs oder ein Cloud Interconnect mit mehreren VLAN-Anhängen in die lokale Umgebung oder andere Cloud-Umgebungen eingebunden werden.

Daten in einer Hybridnetzwerkarchitektur mit einem VPC in jeder Umgebung fließen von zwei Subnetzwerken in Google Cloud zu einer Arbeitslast in einer lokalen Umgebung.

Das im vorherigen Diagramm dargestellte Muster kann auf eine Hub-and-Spoke-Netzwerktopologie in der Landing Zone angewendet werden. In dieser Topologie kann eine einzelne (oder mehrere) Hybridverbindung für alle Spoke-VPCs freigegeben werden. Sie wird freigegeben, indem sowohl die Hybridkonnektivität als auch die anderen Spoke-VPCs über ein Transit-VPC terminiert werden. Sie können dieses Design auch erweitern, indem Sie dem Transit-VPC eine NVA mit NGFW-Prüffunktionen hinzufügen, wie im nächsten Abschnitt „Eine zentrale Firewall der Anwendungsebene verwenden“ beschrieben.

Zentrale Firewall auf Anwendungsebene verwenden

Wenn Ihre technischen Anforderungen die Berücksichtigung der Anwendungsschicht (Layer 7) und eine detaillierte Paketprüfung mit erweiterten Firewallfunktionen erfordern, die über die Funktionen der Cloud Next Generation Firewall hinausgehen, können Sie eine NGFW-Appliance verwenden, die in einer NVA gehostet wird. Diese NVA muss jedoch die Sicherheitsanforderungen Ihres Unternehmens erfüllen. Dabei haben Sie die Möglichkeit, die Topologie zu erweitern, um den gesamten umgebungsübergreifenden Traffic wie im folgenden Diagramm über eine zentrale NVA-Firewall zu leiten.

Sie können das Muster im folgenden Diagramm auf das Landing-Zone-Design anwenden, indem Sie eine Hub-and-Spoke-Topologie mit zentralisierten Appliances verwenden:

Daten aus zwei freigegebenen VPCs in Google Cloud fließen über eine NVA zu einem Transit-VPC-Netzwerk und weiter zu einer Arbeitslast in einer lokalen Umgebung.

Wie im vorherigen Diagramm dargestellt, dient die NVA als Perimeter-Sicherheitsschicht und bildet die Grundlage für die Inline-Traffic-Prüfung. Außerdem werden strenge Zugriffssteuerungsrichtlinien erzwungen. Um sowohl Ost-West- als auch Nord-Süd-Trafficflüsse zu prüfen, kann das Design einer zentralen NVA mehrere Segmente mit unterschiedlichen Sicherheitszugriffssteuerungsebenen umfassen.

Verteilte Zero-Trust-Architektur für Mikrodienste

Bei der Verwendung von containerisierten Anwendungen gilt die im Abschnitt Gespiegeltes beschriebene verteilte Zero-Trust-Architektur für Mikrodienste auch für dieses Architekturmuster.

Der Hauptunterschied zwischen diesem Muster und dem gespiegelten Muster besteht darin, dass das Kommunikationsmodell zwischen Arbeitslasten in Google Cloud und anderen Umgebungen von beiden Seiten aus gestartet werden kann. Der Traffic muss basierend auf den Anwendungs- und Sicherheitsanforderungen mit Service Mesh gesteuert und detailliert überwacht werden.

Best Practices für Mesh-Muster

  • Bevor Sie etwas anderes tun, sollten Sie sich für ein Design der Ressourcenhierarchie und für das Design entscheiden, das für die Unterstützung von Projekten und VPCs erforderlich ist. So können Sie die optimale Netzwerkarchitektur auswählen, die zur Struktur Ihrer Google Cloud-Projekte passt.
  • Verwenden Sie eine Zero-Trust-verteilte Architektur, wenn Sie Kubernetes in Ihrer privaten Rechenzentrumsumgebung und in Google Cloud verwenden.
  • Wenn Sie in Ihrem Design zentralisierte NVAs verwenden, sollten Sie mehrere Segmente mit unterschiedlichen Sicherheitszugriffssteuerungen und Richtlinien für die Verkehrsprüfung definieren. Diese Steuerelemente und Richtlinien sollten auf den Sicherheitsanforderungen Ihrer Anwendungen basieren.
  • Beim Entwerfen einer Lösung mit NVAs ist es wichtig, die Hochverfügbarkeit (HA) der NVAs zu berücksichtigen, um einen einzelnen Fehlerpunkt zu vermeiden, der die gesamte Kommunikation blockieren könnte. Folgen Sie den Design- und Implementierungsrichtlinien für HA und Redundanz des Google Cloud-Sicherheitsanbieters, von dem Sie Ihre NVAs beziehen.
  • Um für mehr Datenschutz, Datenintegrität und ein kontrolliertes Kommunikationsmodell zu sorgen, stellen Sie Anwendungen über APIs mit API-Gateways wie Apigee und Apigee Hybrid mit End-to-End-mTLS bereit. Sie können auch eine gemeinsame VPC mit Apigee in derselben Organisationsressource verwenden.
  • Wenn für die Lösung eine Google Cloud-basierte Anwendung für das öffentliche Internet freigegeben werden muss, sollten Sie die Designempfehlungen unter Netzwerk für die Bereitstellung internetfähiger Anwendungen berücksichtigen.
  • Mit VPC Service Controls können Sie Dienstperimeter auf Projekt- oder VPC-Netzwerkebene angeben, um Google Cloud-Dienste in Ihren Projekten zu schützen und das Risiko einer Daten-Exfiltration zu minimieren. Außerdem können Sie Dienstperimeter über ein autorisiertes VPN oder Cloud Interconnect auf eine Hybridumgebung ausweiten. Weitere Informationen zu den Vorteilen von Dienstperimetern finden Sie unter VPC Service Controls.
  • Lesen Sie die allgemeinen Best Practices für Hybrid- und Multi-Cloud-Netzwerkmuster.

Wenn Sie eine strengere Isolation und einen detaillierteren Zugriff zwischen Ihren in Google Cloud gehosteten Anwendungen und anderen Umgebungen erzwingen möchten, können Sie eines der gated-Muster verwenden, die in den anderen Dokumenten dieser Reihe beschrieben werden.

Gateway-Muster

Das gated-Muster basiert auf einer Architektur, die ausgewählte Anwendungen und Dienste basierend auf bestimmten freigegebenen APIs oder Endpunkten zwischen den verschiedenen Umgebungen detailliert freigibt. In diesem Leitfaden wird dieses Muster in drei mögliche Optionen unterteilt, die jeweils vom jeweiligen Kommunikationsmodell abhängen:

Wie bereits in diesem Leitfaden erwähnt, können die hier beschriebenen Netzwerkarchitekturmuster an verschiedene Anwendungen mit unterschiedlichen Anforderungen angepasst werden. Um den spezifischen Anforderungen verschiedener Anwendungen gerecht zu werden, kann Ihre Haupt-Landingzone-Architektur ein Muster oder eine Kombination von Mustern gleichzeitig enthalten. Die spezifische Bereitstellung der ausgewählten Architektur wird durch die spezifischen Kommunikationsanforderungen der einzelnen Gated-Muster bestimmt.

In dieser Reihe werden die einzelnen Gated-Pattern und ihre möglichen Designoptionen erläutert. Eine gängige Designoption, die für alle ‑Gated-Muster gilt, ist jedoch die verteilte Zero-Trust-Architektur für containerisierte Anwendungen mit Mikrodienstarchitektur. Diese Option basiert auf Cloud Service Mesh, Apigee und Apigee Adapter for Envoy, einer schlanken Apigee-Gateway-Bereitstellung in einem Kubernetes-Cluster. Apigee Adapter for Envoy ist ein beliebter Open-Source-Edge- und -Dienstproxy, der für Cloud-first-Anwendungen entwickelt wurde. Diese Architektur steuert die zulässige sichere Kommunikation zwischen Diensten und die Kommunikationsrichtung auf Dienstebene. Richtlinien für die Traffic-Kommunikation können basierend auf dem ausgewählten Muster entworfen, optimiert und auf Dienstebene angewendet werden.

Mit Gated-Mustern können Sie Cloud Next Generation Firewall Enterprise mit Intrusion Prevention Service (IPS) implementieren, um eine Deep Packet Inspection zur Bedrohungsprävention ohne Design- oder Routingänderungen durchzuführen. Diese Prüfung hängt von den jeweiligen Anwendungen ab, auf die zugegriffen wird, vom Kommunikationsmodell und von den Sicherheitsanforderungen. Wenn die Sicherheitsanforderungen eine Layer-7- und Deep-Packet-Inspection mit erweiterten Firewallmechanismen erfordern, die über die Möglichkeiten der Cloud Next Generation Firewall hinausgehen, können Sie eine zentrale Next Generation Firewall (NGFW) verwenden, die in einer virtuellen Netzwerk-Appliance (NVA) gehostet wird. Mehrere Sicherheitspartner von Google Cloud bieten NGFW-Appliances an, die Ihre Sicherheitsanforderungen erfüllen können. Die Integration von NVAs in diese gesteuerten Muster kann die Einführung mehrerer Sicherheitszonen im Netzwerkdesign erfordern, die jeweils unterschiedliche Zugriffssteuerungsebenen haben.

Gatewaygesteuerter ausgehender Traffic

Die Architektur des Netzwerkmusters für gatewaygesteuerten ausgehenden Traffic basiert darauf, dass ausgewählte APIs aus der lokalen Umgebung oder einer anderen Cloud-Umgebung für Arbeitslasten verfügbar gemacht werden, die in Google Cloud bereitgestellt werden. Dies geschieht, ohne dass sie direkt von einer lokalen Umgebung oder einer anderen Cloud-Umgebung über das öffentliche Internet zugänglich sind. Sie können diese eingeschränkte Bereitstellung durch ein API-Gateway oder einen Proxy oder einen Load Balancer ermöglichen, der als Fassade für vorhandene Arbeitslasten dient. Sie können die API-Gateway-Funktionalität in einem isolierten Perimeter-Netzwerksegment wie einem Perimeternetzwerk bereitstellen.

Das Netzwerkmuster für gatewaygesteuerten ausgehenden Traffic gilt hauptsächlich für (ist aber nicht beschränkt auf) Muster für gestaffelte Anwendungsarchitektur und Muster für partitionierte Anwendungsarchitektur. Beim Bereitstellen von Back-End-Arbeitslasten in einem internen Netzwerk hilft das Netzwerk mit gatewaygesteuertem ausgehendem Traffic dabei, ein höheres Sicherheitsniveau in Ihrer lokalen Computing-Umgebung aufrechtzuerhalten. Das Muster erfordert, dass Sie die Rechenumgebungen so verbinden, dass die folgenden Kommunikationsanforderungen erfüllt werden:

  • Von Ihnen in Google Cloud bereitgestellte Arbeitslasten können mit dem API-Gateway oder dem Load Balancer (oder einem Private Service Connect-Endpunkt) kommunizieren, der die Anwendung über interne IP-Adressen bereitstellt.
  • Andere Systeme in der privaten Rechenumgebung sind nicht direkt innerhalb von Google Cloud erreichbar.
  • Die private Rechenumgebung darf nicht mit Arbeitslasten in Google Cloud kommunizieren.
  • Der Traffic zu den privaten APIs in anderen Umgebungen wird nur innerhalb der Google Cloud-Umgebung initiiert.

Der Schwerpunkt dieser Anleitung liegt auf Hybrid- und Multi-Cloud-Umgebungen, die über ein privates Hybridnetzwerk verbunden sind. Wenn die Sicherheitsanforderungen Ihrer Organisation es zulassen, können API-Aufrufe an Remote-Ziel-APIs mit öffentlichen IP-Adressen direkt über das Internet erreicht werden. Sie müssen jedoch die folgenden Sicherheitsmechanismen berücksichtigen:

  • API OAuth 2.0 mit Transport Layer Security (TLS).
  • Ratenbegrenzung.
  • Richtlinien für den Schutz vor Bedrohungen.
  • Gegenseitiges TLS, das für das Backend Ihrer API-Ebene konfiguriert ist.
  • Filterung der Zulassungsliste für IP-Adressen, die so konfiguriert ist, dass nur die Kommunikation mit vordefinierten API-Quellen und -Zielen von beiden Seiten zugelassen wird.

Zum Sichern eines API-Proxys sollten Sie diese anderen Sicherheitsaspekte berücksichtigen. Weitere Informationen finden Sie unter Best Practices zum Sichern Ihrer Anwendungen und APIs mit Apigee.

Architektur

Das folgende Diagramm zeigt eine Referenzarchitektur, die die Anforderungen an die Kommunikation unterstützt, die im vorherigen Abschnitt aufgeführt sind:

Daten fließen in eine Richtung von einem Hostprojekt in Google Cloud zu einer Arbeitslast in einer lokalen Umgebung.

Die Daten fließen so durch das vorherige Diagramm:

  • In Google Cloud können Sie Arbeitslasten in Virtual Private Clouds (VPCs) bereitstellen. Die VPCs können einfach oder mehrfach vorhanden sein (freigegeben oder nicht freigegeben). Die Bereitstellung sollte auf die Projekte und das Design der Ressourcenhierarchie Ihrer Organisation abgestimmt sein.
  • Die VPC-Netzwerke der Google Cloud-Umgebung werden auf andere Rechenumgebungen erweitert. Die Umgebungen können lokal sein oder sich in einer anderen Cloud befinden. Um die Kommunikation zwischen Umgebungen mithilfe interner IP-Adressen zu erleichtern, verwenden Sie eine geeignete Verbindung für Hybrid- und Multi-Cloud-Netzwerke.
  • Um den Traffic zu begrenzen, der von bestimmten VPC-IP-Adressen stammt und für Remote-Gateways oder Load Balancer bestimmt ist, verwenden Sie die Filterung der Zulassungsliste für IP-Adressen. Rücktraffic von diesen Verbindungen ist zulässig bei Verwendung zustandsorientierter Firewallregeln. Sie können eine beliebige Kombination der folgenden Funktionen verwenden, um die Kommunikation auf die einzigen zulässigen Quell- und Ziel-IP-Adressen zu sichern und zu beschränken:

  • Alle Umgebungen nutzen einen sich nicht überschneidenden IP-Adressbereich nach RFC 1918.

Varianten

Das Architekturmuster für gatewaygesteuerten ausgehenden Traffic kann mit anderen Ansätzen kombiniert werden, um verschiedene Designanforderungen zu erfüllen, die dennoch die Kommunikationsanforderungen dieses Musters berücksichtigen. Das Muster bietet folgende Optionen:

Google Cloud API-Gateway und globales Frontend verwenden

In Google Cloud fließen Daten von Apigee zur VPC eines Kundenprojekts und dann aus der Cloud in eine lokale Umgebung oder eine andere Cloud-Instanz.

Bei diesem Designansatz erfolgen API-Sichtbarkeit und -Verwaltung innerhalb von Google Cloud. Wie im obigen Diagramm dargestellt, können Sie dies durch die Implementierung von Apigee als API-Plattform erreichen. Die Entscheidung, ein API-Gateway oder einen Load Balancer in der Remote-Umgebung bereitzustellen, hängt von Ihren spezifischen Anforderungen und der aktuellen Konfiguration ab. Apigee bietet zwei Optionen für die Bereitstellung von Konnektivität:

  • Mit VPC-Peering
  • Ohne VPC-Peering

Globale Frontend-Funktionen von Google Cloud wie Cloud Load Balancing, Cloud CDN (bei Zugriff über Cloud Interconnect) und Cross-Cloud Interconnect verbessern die Geschwindigkeit, mit der Nutzer auf Anwendungen zugreifen können, deren Backends in lokalen Umgebungen und in anderen Cloud-Umgebungen gehostet werden.

Die Optimierung der Geschwindigkeit der Inhaltsübermittlung wird durch die Bereitstellung dieser Anwendungen aus Google Cloud-Points of Presence (PoP) erreicht. Google Cloud-PoPs sind auf mehr als 180 Internetplattformen und über 160 Interconnect-Einrichtungen weltweit präsent.

Unter Hochwertige APIs mit Apigee und Cloud CDN bereitstellen auf YouTube erfahren Sie, wie PoPs dazu beitragen, leistungsstarke APIs bereitzustellen, wenn Sie Apigee mit Cloud CDN für folgende Aufgaben verwenden:

  • Latenz reduzieren.
  • APIs global hosten.
  • Verfügbarkeit für Traffic-Spitzen erhöhen.

Das im vorherigen Diagramm dargestellte Designbeispiel basiert auf Private Service Connect ohne VPC-Peering.

Das Northbound-Netzwerk wird in diesem Design folgendermaßen aufgebaut:

  • Ein Load Balancer (LB im Diagramm), bei dem Clientanfragen enden, verarbeitet den Traffic und leitet ihn dann an ein Private Service Connect-Backend weiter.
  • Mit einem Private Service Connect-Backend kann ein Google Cloud-Load Balancer Clientanfragen über eine Private Service Connect-Verbindung senden, die mit einem Producer-Dienstanhang an den veröffentlichten Dienst verknüpft ist (Apigee-Laufzeitinstanz), und zwar mit Private Service Connect-Netzwerk-Endpunktgruppen (NEGs).

Das Southbound-Netzwerk wird so eingerichtet:

  • Ein Private Service Connect-Endpunkt, der auf einen Dienstanhang verweist, der mit einem internen Load Balancer (ILB im Diagramm) in der VPC des Kunden verknüpft ist.
  • Der ILB wird mit Hybridkonnektivitäts-Netzwerk-Endpunktgruppen (Hybridkonnektivitäts-NEGs) bereitgestellt.

  • Der Zugriff auf Hybriddienste erfolgt über die Hybridkonnektivitäts-NEG über eine Hybridnetzwerkverbindung wie VPN oder Cloud Interconnect.

Weitere Informationen finden Sie unter Regionalen internen Proxy-Network Load Balancer mit Hybridkonnektivität einrichten und Bereitstellungsmuster für Private Service Connect.

Remotedienste mit Private Service Connect verfügbar machen

Daten, die von Google Cloud in eine lokale Umgebung oder eine andere Cloud fließen, nachdem sie in einer Arbeitslast in einer VPC entstanden sind und durch Cloud Load Balancing, eine Hybridkonnektivitäts-NEG und ein Cloud VPN oder Interconnect geleitet werden.

Verwenden Sie die Option „Private Service Connect“, um Remotedienste für die folgenden Szenarien verfügbar zu machen:

  • Sie verwenden keine API-Plattform oder möchten aus den folgenden Gründen vermeiden, Ihr gesamtes VPC-Netzwerk direkt mit einer externen Umgebung zu verbinden:
    • Sie haben Sicherheitseinschränkungen oder Compliance-Anforderungen.
    • Sie haben eine IP-Adressbereichsüberschneidung, z. B. in einem Fusions- und Übernahmeszenario.
  • Um eine sichere unidirektionale Kommunikation zwischen Clients, Anwendungen und Diensten in allen Umgebungen zu ermöglichen, selbst bei kurzer Frist.
  • Möglicherweise müssen Sie eine Verbindung zu mehreren Nutzer-VPCs über eine Dienstersteller-VPC (Transit-VPC) bereitstellen, um hoch skalierbare Mehrmandanten- oder Ein-Mandanten-Dienstmodelle bereitzustellen, damit veröffentlichte Dienste in anderen Umgebungen erreicht werden.

Die Verwendung von Private Service Connect für Anwendungen, die als APIs genutzt werden, stellt eine interne IP-Adresse für die veröffentlichten Anwendungen bereit, wodurch ein sicherer Zugriff innerhalb des privaten Netzwerks über Regionen hinweg und über Hybridkonnektivität ermöglicht wird. Diese Abstraktion ermöglicht die Einbindung von Ressourcen aus verschiedenen Clouds und lokalen Umgebungen über ein Hybrid- und Multi-Cloud-Konnektivitätsmodell. Sie können die Einbindung von Anwendungen beschleunigen und Anwendungen sicher verfügbar machen, die sich in einer lokalen Umgebung oder einer anderen Cloud-Umgebung befinden, indem Sie Private Service Connect verwenden, um den Dienst mit detailliertem Zugriff zu veröffentlichen. In diesem Fall können Sie die folgende Option verwenden:

Im vorherigen Diagramm können die Arbeitslasten im VPC-Netzwerk Ihrer Anwendung die Hybriddienste, die in Ihrer lokalen Umgebung oder in anderen Cloud-Umgebungen ausgeführt werden, über den Private Service Connect-Endpunkt erreichen, wie im folgenden Diagramm dargestellt. Diese Designoption für die unidirektionale Kommunikation ist eine Alternative zum Peering mit einer Transit-VPC.

Daten, die durch mehrere VPCs innerhalb von Google Cloud fließen, bevor sie ein Cloud VPN oder Cloud Interconnect und eine lokale Umgebung oder eine andere Cloud verlassen.

Als Teil des Designs im vorherigen Diagramm können mehrere Frontends, Backends oder Endpunkte eine Verbindung zum selben Dienstanhang herstellen. Dadurch können mehrere VPC-Netzwerke oder mehrere Nutzer auf denselben Dienst zugreifen. Wie im folgenden Diagramm dargestellt, können Sie die Anwendung für mehrere VPCs zugänglich machen. Diese Barrierefreiheit kann bei Szenarien mit mandantenfähigen Dienste helfen, in denen Ihr Dienst von mehreren Nutzer-VPCs genutzt wird, auch wenn deren IP-Adressbereiche sich überschneiden.

Die IP-Adressüberschneidung ist eines der häufigsten Probleme bei der Integration von Anwendungen, die sich in verschiedenen Umgebungen befinden. Die Private Service Connect-Verbindung im folgenden Diagramm hilft, das Problem der IP-Adressüberschneidung zu vermeiden. Dies geschieht, ohne dass eine Bereitstellung oder Verwaltung von zusätzlichen Netzwerkkomponenten wie Cloud NAT oder NVA erforderlich ist, um die IP-Adressübersetzung auszuführen. Eine Beispielkonfiguration finden Sie unter Hybriden Dienst mithilfe von Private Service Connect veröffentlichen.

Das Design bietet folgende Vorteile:

  • Verhindert potenzielle Abhängigkeiten der gemeinsamen Skalierung und komplexe Verwaltung in großem Maßstab.
  • Verbessert die Sicherheit durch eine detailgenaue Verbindungssteuerung.
  • Verringert die IP-Adresskoordination zwischen dem Producer und dem Nutzer des Dienstes und der externen Remote-Umgebung.

Der Designansatz im vorherigen Diagramm kann später erweitert werden, um Apigee als API-Plattform zu integrieren. Dazu werden die zuvor beschriebenen Optionen für das Netzwerkdesign verwendet, einschließlich der Option „Private Service Connect“.

Sie können den Private Service Connect-Endpunkt über andere Regionen zugänglich machen, indem Sie Globaler Zugriff auf Private Service Connect verwenden.

Der Client, der eine Verbindung zum Private Service Connect-Endpunkt herstellt, kann sich in derselben Region wie der Endpunkt oder in einer anderen Region befinden. Dieser Ansatz kann verwendet werden, um Hochverfügbarkeit für Dienste bereitzustellen, die in mehreren Regionen gehostet werden, oder um auf Dienste zuzugreifen, die in einer einzelnen Region aus anderen Regionen verfügbar sind. Wenn Ressourcen, die in anderen Regionen gehostet werden, auf einen Private Service Connect-Endpunkt zugreifen, gelten interregionale Gebühren für ausgehenden Traffic für den Traffic für Endpunkte mit globalem Zugriff.

Best Practices

  • Die Verwendung von Apigee und Apigee Hybrid als API-Plattformlösung bietet mehrere Vorteile. Sie bietet eine Proxy-Ebene und eine Abstraktion bzw. Fassade für Ihre Backend-Dienst-APIs in Kombination mit Sicherheitsfunktionen, Ratenbegrenzung, Kontingenten und Analysen.
  • VPCs und das Projektdesign in Google Cloud sollten von Ihrer Ressourcenhierarchie und Ihren Anforderungen an das sichere Kommunikationsmodell bestimmt werden.
  • Wenn Sie APIs mit API-Gateways verwenden, sollten Sie auch eine Zulassungsliste für IP-Adressen verwenden. Eine Zulassungsliste beschränkt die Kommunikation auf die spezifischen IP-Adressquellen und -ziele der API-Nutzer und API-Gateways, die möglicherweise in verschiedenen Umgebungen gehostet werden.
  • Mithilfe von VPC-Firewallregeln oder Firewallrichtlinien können Sie den Zugriff auf Private Service Connect-Ressourcen über den Private Service Connect-Endpunkt steuern.
  • Wenn eine Anwendung über einen Application Load Balancer extern verfügbar gemacht wird, sollten Sie die Verwendung von Google Cloud Armor als zusätzliche Sicherheitsebene zum Schutz vor DDoS und Sicherheitsbedrohungen auf Anwendungsebene in Betracht ziehen.
  • Wenn Instanzen einen Internetzugang benötigen, verwenden Sie Cloud NAT in der Anwendungs-VPC (Nutzer-VPC), damit Arbeitslasten auf das Internet zugreifen können. Dadurch vermeiden Sie, dass VM-Instanzen mit externen öffentlichen IP-Adressen in Systemen zugewiesen werden, die hinter einem API-Gateway oder einem Load Balancer bereitgestellt werden.

  • Lesen Sie die allgemeinen Best Practices für Hybrid- und Multi-Cloud-Netzwerkmuster.

Gatewaygesteuerter eingehender Traffic

Die Architektur des Musters für gatewaygesteuerten eingehenden Traffic basiert darauf, dass ausgewählte APIs von Arbeitslasten, die in Google Cloud ausgeführt werden, in der privaten Rechenumgebung zur Verfügung gestellt werden, ohne dass diese über das öffentliche Internet zugänglich sind. Dieses Muster ist das Gegenstück zum Muster für gatewaygesteuerten ausgehenden Traffic und eignet sich gut für Edge-Hybrid-, gestufte Hybrid- und partitionierte Multi-Cloud- Szenarien.

Wie beim Muster Gated Egress können Sie diese eingeschränkte Bereitstellung durch ein API-Gateway oder einen Load Balancer ermöglichen, der als Fassade für vorhandene Arbeitslasten oder Dienste dient. Dadurch ist es für private Rechenumgebungen, lokale Umgebungen oder andere Cloud-Umgebungen zugänglich:

  • Arbeitslasten, die Sie in der privaten Rechenumgebung oder in anderen Cloud-Umgebungen bereitstellen, können über interne IP-Adressen mit dem API-Gateway oder dem Load Balancer kommunizieren. Andere in Google Cloud bereitgestellte Systeme sind nicht erreichbar.
  • Die Kommunikation von Google Cloud mit der privaten Rechenumgebung oder anderen Cloud-Umgebungen ist nicht zulässig. Der Traffic wird nur von der privaten Umgebung oder anderen Cloud-Umgebungen zu den APIs in Google Cloud initiiert.

Architektur

Das folgende Diagramm zeigt eine Referenzarchitektur, die die Anforderungen des Musters für den gesteuerten Eintritt erfüllt.

Daten, die in eine Richtung von einer lokalen Umgebung oder einer Cloud über ein Cloud VPN oder Cloud Interconnect in eine Google Cloud-Umgebung fließen und in einer Arbeitslast enden.

Die Beschreibung der Architektur im vorherigen Diagramm sieht so aus:

  • In Google Cloud stellen Sie Arbeitslasten in einer Anwendungs-VPC (oder mehreren VPCs) bereit.
  • Das Netzwerk der Google Cloud-Umgebung wird auf andere Rechenumgebungen (lokal oder in einer anderen Cloud) erweitert. Dazu wird eine Hybrid- oder Multi-Cloud-Netzwerkkonnektivität verwendet, um die Kommunikation zwischen den Umgebungen zu erleichtern.
  • Optional können Sie eine Übertragungs-VPC für Folgendes verwenden:
    • Bieten Sie zusätzliche Sicherheitsebenen für den Perimeter, um den Zugriff auf bestimmte APIs außerhalb Ihres Anwendungs-VPC zu ermöglichen.
    • Leiten Sie den Traffic an die IP-Adressen der APIs weiter. Sie können VPC-Firewallregeln erstellen, um zu verhindern, dass einige Quellen über einen Endpunkt auf bestimmte APIs zugreifen.
    • Prüfen Sie den Layer-7-Traffic im Transit-VPC, indem Sie eine virtuelle Netzwerk-Appliance (NVA) einbinden.
  • Greifen Sie über ein API-Gateway oder einen Load Balancer (Proxy- oder Anwendungs-Load Balancer) auf APIs zu, um eine Proxy-Ebene und eine Abstraktionsschicht oder Fassade für Ihre Dienst-APIs bereitzustellen. Wenn Sie Traffic auf mehrere API-Gateway-Instanzen verteilen möchten, können Sie einen internen Passthrough-Network Load Balancer verwenden.
  • Sie können einen eingeschränkten und detaillierten Zugriff auf einen veröffentlichten Dienst über einen Private Service Connect-Endpunkt gewähren, indem Sie einen Load Balancer über Private Service Connect verwenden, um eine Anwendung oder einen Dienst bereitzustellen.
  • Alle Umgebungen sollten einen sich nicht überschneidenden IP-Adressbereich nach RFC 1918 verwenden.

Das folgende Diagramm veranschaulicht das Design dieses Musters mit Apigee als API-Plattform.

Daten fließen in eine Google Cloud-Umgebung und werden über ein Cloud VPN oder Cloud Interconnect aus einer lokalen oder Cloud-Umgebung in ein Projekt in einer Apigee-Instanz übertragen.

Im vorherigen Diagramm bietet die Verwendung von Apigee als API-Plattform die folgenden Funktionen und Möglichkeiten, um das Gated Ingress-Muster zu aktivieren:

  • Gateway- oder Proxyfunktion
  • Sicherheitsfunktionen
  • Ratenbegrenzung
  • Analyse

Im Design:

  • Die Netzwerkverbindung in Richtung Norden (für Traffic aus anderen Umgebungen) führt über einen Private Service Connect-Endpunkt in Ihrer Anwendungs-VPC, der mit der Apigee-VPC verknüpft ist.
  • Im VPC der Anwendung wird ein interner Load Balancer verwendet, um die Anwendungs-APIs über einen Private Service Connect-Endpunkt bereitzustellen, der im Apigee-VPC angezeigt wird. Weitere Informationen finden Sie unter Architektur mit deaktiviertem VPC-Peering.
  • Konfigurieren Sie Firewallregeln und Traffic-Filterung im VPC der Anwendung. So wird ein detaillierter und kontrollierter Zugriff ermöglicht. Außerdem wird verhindert, dass Systeme Ihre Anwendungen direkt erreichen, ohne den Private Service Connect-Endpunkt und das API-Gateway zu passieren.

    Außerdem können Sie die Ankündigung des Subnetzes der internen IP-Adresse der Backend-Arbeitslast im Anwendungs-VPC auf das lokale Netzwerk beschränken, um eine direkte Erreichbarkeit zu vermeiden, ohne den Private Service Connect-Endpunkt und das API-Gateway zu passieren.

Bestimmte Sicherheitsanforderungen erfordern möglicherweise eine Perimetersicherheitsprüfung außerhalb des VPC der Anwendung, einschließlich des Traffics für die hybride Konnektivität. In solchen Fällen können Sie eine Transit-VPC einbinden, um zusätzliche Sicherheitsebenen zu implementieren. Diese Schichten, z. B. NVAs von Firewalls der nächsten Generation (NGFWs) mit mehreren Netzwerkschnittstellen oder Cloud Next Generation Firewall Enterprise mit Intrusion Prevention Service (IPS), führen eine Deep Packet Inspection außerhalb Ihres VPC für Anwendungen durch, wie im folgenden Diagramm dargestellt:

Daten fließen in eine Google Cloud-Umgebung und werden über ein Cloud VPN oder Cloud Interconnect von einer lokalen oder Cloud-Umgebung an eine Anwendung gesendet.

Wie im vorherigen Diagramm dargestellt:

  • Die Netzwerkverbindung in Richtung Norden (für Traffic aus anderen Umgebungen) führt über ein separates Transit-VPC zum Private Service Connect-Endpunkt im Transit-VPC, das mit dem Apigee-VPC verknüpft ist.
  • In der VPC der Anwendung wird ein interner Load Balancer (ILB im Diagramm) verwendet, um die Anwendung über einen Private Service Connect-Endpunkt in der Apigee-VPC bereitzustellen.

Sie können mehrere Endpunkte im selben VPC-Netzwerk bereitstellen, wie im folgenden Diagramm dargestellt. Um verschiedene Anwendungsfälle abzudecken, können Sie die verschiedenen möglichen Netzwerkpfade mithilfe von Cloud Router und VPC-Firewallregeln steuern. Wenn Sie Ihr lokales Netzwerk beispielsweise über mehrere Hybridnetzwerkverbindungen mit Google Cloud verbinden, können Sie einen Teil des Traffics von lokalen zu bestimmten Google APIs oder veröffentlichten Diensten über eine Verbindung und den Rest über eine andere Verbindung senden. Außerdem können Sie Globaler Zugriff auf Private Service Connect verwenden, um Failover-Optionen bereitzustellen.

Daten fließen in eine Google Cloud-Umgebung und werden über mehrere Private Service Connect-Endpunkte von einer lokalen oder Cloud-Umgebung über ein Cloud VPN oder Cloud Interconnect an mehrere VPCs des Diensterstellers gesendet.

Varianten

Das Architekturmuster für gatewaygesteuerten eingehenden Traffic kann mit anderen Ansätzen kombiniert werden, um verschiedene Designanforderungen zu erfüllen, die dennoch die Kommunikationsanforderungen dieses Musters berücksichtigen. Das Muster bietet folgende Optionen:

Auf Google APIs aus anderen Umgebungen zugreifen

Für Szenarien, in denen Zugriff auf Google-Dienste wie Cloud Storage oder BigQuery erforderlich ist, ohne Traffic über das öffentliche Internet zu senden, bietet Private Service Connect eine Lösung. Wie im folgenden Diagramm dargestellt, ermöglicht es die Erreichbarkeit der unterstützten Google APIs und ‑Dienste (einschließlich Google Maps, Google Ads und Google Cloud) von lokalen oder anderen Cloud-Umgebungen über eine hybride Netzwerkverbindung mithilfe der IP-Adresse des Private Service Connect-Endpunkts. Weitere Informationen zum Zugriff auf Google APIs über Private Service Connect-Endpunkte finden Sie unter Zugriff auf Google APIs über Endpunkte.

Daten fließen aus einer lokalen Umgebung zu Google-Diensten in einer Google Cloud-Umgebung.

Im vorherigen Diagramm muss Ihr lokales Netzwerk über Cloud VPN-Tunnel oder einen Cloud Interconnect-VLAN-Anhang mit dem VPC-Netzwerk des Transits (Nutzers) verbunden sein.

Der Zugriff auf Google APIs ist über Endpunkte oder Back-Ends möglich. Mit Endpunkten können Sie ein Bundle von Google APIs zum Ziel haben. Mit Back-Ends können Sie eine bestimmte regionale Google API anvisieren.

Anwendungs-Back-Ends mit Private Service Connect für andere Umgebungen verfügbar machen

In bestimmten Fällen, wie im gestaffelten Hybridmuster hervorgehoben, müssen Sie möglicherweise Back-Ends in Google Cloud bereitstellen und Front-Ends in privaten Rechenumgebungen beibehalten. Dieser Ansatz ist zwar weniger üblich, eignet sich aber für komplexe, monolithische Front-Ends, die möglicherweise auf älteren Komponenten basieren. Oder, was häufiger vorkommt, wenn Sie verteilte Anwendungen in mehreren Umgebungen verwalten, einschließlich lokal und in anderen Clouds, die eine Verbindung zu Back-Ends erfordern, die in Google Cloud über ein Hybridnetzwerk gehostet werden.

In einer solchen Architektur können Sie ein lokales API-Gateway oder einen Load Balancer in der privaten lokalen Umgebung oder in anderen Cloud-Umgebungen verwenden, um das Anwendungs-Frontend direkt für das öffentliche Internet verfügbar zu machen. Mit Private Service Connect in Google Cloud können Sie eine private Verbindung zu den Back-Ends herstellen, die über einen Private Service Connect-Endpunkt bereitgestellt werden. Idealerweise verwenden Sie dazu vordefinierte APIs, wie im folgenden Diagramm dargestellt:

Daten fließen aus einer lokalen Umgebung oder einer anderen Cloud-Umgebung in eine Google Cloud-Umgebung. Die Daten fließen durch eine Apigee-Instanz und einen Frontend-Dienst in der Umgebung außerhalb von Google Cloud und landen in der VPC einer Kundenprojektanwendung.

Im Design im vorherigen Diagramm wird eine Apigee Hybrid-Bereitstellung verwendet, die aus einer Verwaltungsebene in Google Cloud und einer Laufzeitebene besteht, die in Ihrer anderen Umgebung gehostet wird. Sie können die Laufzeitebene auf einem verteilten API-Gateway auf einer der unterstützten Kubernetes-Plattformen in Ihrer lokalen Umgebung oder in anderen Cloud-Umgebungen installieren und verwalten. Je nach Ihren Anforderungen an verteilte Arbeitslasten in Google Cloud und anderen Umgebungen können Sie Apigee in Google Cloud mit Apigee Hybrid verwenden. Weitere Informationen finden Sie unter Verteilte API-Gateways.

Mit einer Hub-and-Spoke-Architektur Anwendungs-Backends für andere Umgebungen freigeben

In bestimmten Fällen kann es erforderlich sein, APIs von in Google Cloud gehosteten Anwendungs-Back-Ends in verschiedenen VPC-Netzwerken bereitzustellen. Wie im folgenden Diagramm dargestellt, dient eine Hub-VPC als zentraler Verbindungspunkt für die verschiedenen VPCs (Spokes) und ermöglicht eine sichere Kommunikation über eine private Hybridkonnektivität. Optional können lokale API-Gateway-Funktionen in anderen Umgebungen wie Apigee Hybrid verwendet werden, um Clientanfragen lokal an dem Ort zu beenden, an dem das Anwendungs-Frontend gehostet wird.

Daten fließen zwischen einer Google Cloud-Umgebung und einer lokalen oder anderen Cloud-Umgebung und APIs von in Google Cloud gehosteten Anwendungs-Backends werden über verschiedene VPC-Netzwerke bereitgestellt.

Wie im vorherigen Diagramm dargestellt:

  • Um zusätzliche NGFW-Layer-7-Prüffunktionen bereitzustellen, kann die NVA mit NGFW-Funktionen optional in das Design eingebunden werden. Möglicherweise benötigen Sie diese Funktionen, um bestimmte Sicherheitsanforderungen und die Sicherheitsrichtlinienstandards Ihrer Organisation einzuhalten.
  • Bei diesem Design wird davon ausgegangen, dass für Spoke-VPCs keine direkte VPC-zu-VPC-Kommunikation erforderlich ist.

    • Wenn eine Kommunikation zwischen Zweigen erforderlich ist, können Sie die NVA verwenden, um diese Kommunikation zu ermöglichen.
    • Wenn Sie verschiedene Backends in verschiedenen VPCs haben, können Sie diese Backends mit Private Service Connect für die Apigee-VPC freigeben.
    • Wenn VPC-Peering für die Nord- und Südverbindung zwischen Spoke-VPCs und Hub-VPC verwendet wird, müssen Sie die Transitivitätsbeschränkung von VPC-Netzwerken über VPC-Peering berücksichtigen. Sie haben folgende Möglichkeiten, diese Einschränkung zu umgehen:
      • Verwenden Sie eine NVA, um die VPCs zu verbinden.
      • Berücksichtigen Sie gegebenenfalls das Private Service Connect-Modell.
      • Wenn Sie eine Verbindung zwischen der Apigee-VPC und Back-Ends in anderen Google Cloud-Projekten in derselben Organisation ohne zusätzliche Netzwerkkomponenten herstellen möchten, verwenden Sie Shared VPC.
  • Wenn NVAs für die Traffic-Prüfung erforderlich sind, einschließlich Traffic aus Ihren anderen Umgebungen, sollte die Hybridkonnektivität zu lokalen oder anderen Cloud-Umgebungen im Hybrid-Transit-VPC beendet werden.

  • Wenn das Design keine NVA enthält, können Sie die hybride Konnektivität am Hub-VPC beenden.

  • Wenn bestimmte Load Balancing-Funktionen oder Sicherheitsfunktionen erforderlich sind, z. B. der DDoS-Schutz oder die WAF von Google Cloud Armor, können Sie optional einen externen Application Load Balancer am Perimeter über ein externes VPC bereitstellen, bevor externe Clientanfragen an die Backends weitergeleitet werden.

Best Practices

  • Wenn Clientanfragen aus dem Internet lokal von einem Frontend empfangen werden müssen, das in einer privaten lokalen oder anderen Cloud-Umgebung gehostet wird, sollten Sie Apigee Hybrid als API-Gateway-Lösung verwenden. Dieser Ansatz ermöglicht auch eine nahtlose Migration der Lösung in eine vollständig in Google Cloud gehostete Umgebung, wobei die Konsistenz der API-Plattform (Apigee) beibehalten wird.
  • Verwenden Sie den Apigee-Adapter für Envoy mit einer Architektur für die Apigee-Hybrid-Bereitstellung mit Kubernetes, wenn dies für Ihre Anforderungen und die Architektur geeignet ist.
  • Das Design von VPCs und Projekten in Google Cloud sollte den Anforderungen an die Ressourcenhierarchie und das sichere Kommunikationsmodell entsprechen, die in diesem Leitfaden beschrieben werden.
  • Durch die Einbindung einer Transit-VPC in dieses Design können Sie zusätzliche Perimetersicherheitsmaßnahmen und eine hybride Konnektivität außerhalb der Arbeitslast-VPC bereitstellen.
  • Verwenden Sie Private Service Connect, um von lokalen Umgebungen oder anderen Cloud-Umgebungen aus über die interne IP-Adresse des Endpunkts über ein Netzwerk mit Hybridkonnektivität auf Google APIs und Dienste zuzugreifen. Weitere Informationen finden Sie unter Über lokale Hosts auf den Endpunkt zugreifen.
  • Mit VPC Service Controls können Sie Dienstperimeter auf Projekt- oder VPC-Netzwerkebene angeben, um Google Cloud-Dienste in Ihren Projekten zu schützen und das Risiko einer Daten-Exfiltration zu minimieren.
  • Mithilfe von VPC-Firewallregeln oder Firewallrichtlinien können Sie den Zugriff auf Private Service Connect-Ressourcen auf Netzwerkebene über den Private Service Connect-Endpunkt steuern. Beispielsweise können Firewallregeln für ausgehenden Traffic im VPC der Anwendung (Nutzer) den Zugriff von VM-Instanzen auf die IP-Adresse oder das Subnetz Ihrer Endpunkte einschränken. Weitere Informationen zu VPC-Firewallregeln im Allgemeinen finden Sie unter VPC-Firewallregeln.
  • Beim Entwerfen einer Lösung mit NVAs ist es wichtig, die Hochverfügbarkeit (HA) der NVAs zu berücksichtigen, um einen einzelnen Fehlerpunkt zu vermeiden, der die gesamte Kommunikation blockieren könnte. Folgen Sie der Anleitung Ihres NVA-Anbieters für die HA- und Redundanz-Design- und -Implementierung.
  • Um die Perimetersicherheit zu stärken und Ihr API-Gateway zu schützen, das in der jeweiligen Umgebung bereitgestellt wird, können Sie optional Load Balancing- und Webanwendungs-Firewall-Mechanismen in Ihrer anderen Rechenzentrumsumgebung (Hybrid- oder andere Cloud) implementieren. Implementieren Sie diese Optionen im Perimeternetzwerk, das direkt mit dem Internet verbunden ist.
  • Wenn Instanzen einen Internetzugang benötigen, verwenden Sie Cloud NAT in der Anwendungs-VPC, damit Arbeitslasten auf das Internet zugreifen können. Dadurch vermeiden Sie, dass VM-Instanzen mit externen öffentlichen IP-Adressen in Systemen zugewiesen werden, die hinter einem API-Gateway oder einem Load Balancer bereitgestellt werden.
  • Verwenden Sie für ausgehenden Webtraffic den Sicheren Web-Proxy. Der Proxy bietet mehrere Vorteile.
  • Lesen Sie die allgemeinen Best Practices für Hybrid- und Multi-Cloud-Netzwerkmuster.

Gatewaygesteuerter ausgehender und gatewaygesteuerter eingehender Traffic

Beim Muster Gated Egress und Gated Ingress wird eine Kombination aus Gated Egress und Gated Ingress für Szenarien verwendet, in denen ausgewählte APIs bidirektional zwischen Arbeitslasten verwendet werden müssen. Arbeitslasten können in Google Cloud, in privaten lokalen Umgebungen oder in anderen Cloud-Umgebungen ausgeführt werden. Bei diesem Muster können Sie API-Gateways, Private Service Connect-Endpunkte oder Load Balancer verwenden, um bestimmte APIs bereitzustellen und optional Authentifizierung, Autorisierung und Prüfungen von API-Aufrufen zu ermöglichen.

Der Hauptunterschied zwischen diesem Muster und dem Mesh-Muster besteht darin, dass es für Szenarien verwendet wird, in denen nur eine bidirektionale API-Nutzung oder Kommunikation mit bestimmten IP‑Adressenquellen und ‑zielen erforderlich ist, z. B. für eine Anwendung, die über einen Private Service Connect-Endpunkt veröffentlicht wird. Da die Kommunikation auf die freigegebenen APIs oder bestimmten IP-Adressen beschränkt ist, müssen die Netzwerke in den Umgebungen in Ihrem Design nicht übereinstimmen. Zu den gängigen Anwendungsfällen gehören unter anderem:

  • Fusionen und Übernahmen
  • Anwendungsintegrationen mit Partnern
  • Integrationen zwischen Anwendungen und Diensten einer Organisation mit verschiedenen Organisationseinheiten, die ihre eigenen Anwendungen verwalten und in verschiedenen Umgebungen hosten.

So funktioniert die Kommunikation:

  • Von Ihnen in Google Cloud bereitgestellte Arbeitslasten können über interne IP-Adressen mit dem API-Gateway (oder bestimmten Ziel-IP-Adressen) kommunizieren. Andere in der privaten Rechenumgebung bereitgestellte Systeme sind nicht erreichbar.
  • Umgekehrt können Arbeitslasten, die in anderen Rechenumgebungen bereitgestellt sind, über interne IP-Adressen mit dem API-Gateway von Google Cloud (oder einer bestimmten veröffentlichten Endpunkt-IP-Adresse) kommunizieren. Andere in Google Cloud bereitgestellte Systeme sind nicht erreichbar.

Architektur

Das folgende Diagramm zeigt eine Referenzarchitektur für das Muster „Gated Egress“ und „Gated Ingress“:

Ausgehender und eingehender Datenverkehr zwischen Google Cloud und einem lokalen Netzwerk oder einem anderen Cloud-Netzwerk.

Der Designansatz im vorherigen Diagramm umfasst die folgenden Elemente:

  • In Google Cloud stellen Sie Arbeitslasten in einer VPC (oder einer freigegebenen VPC) bereit, ohne sie direkt dem Internet zu präsentieren.
  • Das Netzwerk der Google Cloud-Umgebung wird auf andere Rechenumgebungen erweitert. Diese Umgebung kann lokal oder in einer anderen Cloud sein. Verwenden Sie zum Erweitern der Umgebung ein geeignetes Kommunikationsmuster für Hybrid- und Multi-Cloud-Konnektivität, um die Kommunikation zwischen den Umgebungen zu erleichtern, damit interne IP-Adressen verwendet werden können.
  • Optional können Sie mit einer Transit-VPC eine Perimeter-Sicherheitsebene außerhalb Ihrer Anwendungs-VPC hinzufügen, indem Sie den Zugriff auf bestimmte Ziel-IP-Adressen zulassen.
    • Sie können Cloud Next Generation Firewall oder Network Virtual Appliances (NVAs) mit Next Generation Firewalls (NGFWs) im Transit-VPC verwenden, um Traffic zu prüfen und den Zugriff auf bestimmte APIs aus bestimmten Quellen zuzulassen oder zu verweigern, bevor er Ihre Anwendungs-VPC erreicht.
  • Der Zugriff auf APIs sollte über ein API-Gateway oder einen Load Balancer erfolgen, um eine Proxy-Ebene und eine Abstraktion oder Fassade für Ihre Dienst-APIs bereitzustellen.
  • Für Anwendungen, die als APIs verwendet werden, können Sie auch Private Service Connect verwenden, um eine interne IP-Adresse für die veröffentlichte Anwendung anzugeben.
  • Alle Umgebungen nutzen einen sich nicht überschneidenden IP-Adressbereich nach RFC 1918.

Eine gängige Anwendung dieses Musters besteht darin, Anwendungs-Back-Ends (oder einen Teil der Anwendungs-Back-Ends) in Google Cloud bereitzustellen und andere Back-End- und Frontend-Komponenten in lokalen Umgebungen oder in anderen Clouds zu hosten (gestuftes Hybridmuster oder partitioniertes Multi-Cloud-Muster). Wenn sich Anwendungen weiterentwickeln und in die Cloud migrieren, entstehen häufig Abhängigkeiten und Präferenzen für bestimmte Cloud-Dienste.

Manchmal führen diese Abhängigkeiten und Präferenzen dazu, dass Anwendungen und Back-Ends auf verschiedene Cloud-Anbieter verteilt werden. Außerdem können einige Anwendungen mit einer Kombination aus Ressourcen und Diensten erstellt werden, die auf On-Premises-Umgebungen und mehreren Cloud-Umgebungen verteilt sind.

Bei verteilten Anwendungen können die Funktionen der externen Cloud Load Balancing-Hybrid- und Multi-Cloud-Konnektivität verwendet werden, um Nutzeranfragen zu beenden und an Front- oder Back-Ends in anderen Umgebungen weiterzuleiten. Dieses Routing erfolgt über eine Hybridnetzwerkverbindung, wie im folgenden Diagramm dargestellt. Diese Integration ermöglicht die schrittweise Bereitstellung von Anwendungskomponenten in verschiedenen Umgebungen. Anfragen vom Frontend an Backend-Dienste, die in Google Cloud gehostet werden, kommunizieren sicher über die eingerichtete Hybridnetzwerkverbindung, die von einem internen Load Balancer (ILB im Diagramm) unterstützt wird.

Datenfluss zwischen einem Anwendungs-Frontend in einer lokalen oder anderen Cloud-Umgebung und einem Anwendungs-Backend in einer Google Cloud-Umgebung. Die Daten fließen über einen internen Load Balancer (ILB) in Google Cloud.

Das Google Cloud-Design im vorherigen Diagramm bietet folgende Vorteile:

  • Ermöglicht die bidirektionale Kommunikation zwischen Google Cloud, lokalen und anderen Cloud-Umgebungen mithilfe vordefinierter APIs auf beiden Seiten, die dem Kommunikationsmodell dieses Musters entsprechen.
  • Wenn Sie globale Frontends für internetfähige Anwendungen mit verteilten Anwendungskomponenten (Frontends oder Backends) bereitstellen und die folgenden Ziele erreichen möchten, können Sie die erweiterten Load Balancing- und Sicherheitsfunktionen von Google Cloud nutzen, die an Points of Presence (PoPs) bereitgestellt werden:
  • Mit serverlosen verwalteten Diensten können Sie den Kapitalaufwand senken und den Betrieb vereinfachen.
  • Verbindungen zu Anwendungs-Backends global hinsichtlich Geschwindigkeit und Latenz optimieren.
    • Das cloudübergreifende Netzwerk von Google Cloud ermöglicht die Multi-Cloud-Kommunikation zwischen Anwendungskomponenten über optimale private Verbindungen.
  • Sie können statische Inhalte mit hoher Nachfrage im Cache speichern und die Anwendungsleistung für Anwendungen mit globalem Cloud Load Balancing verbessern, indem Sie Zugriff auf Cloud CDN gewähren.
  • Schützen Sie die globalen Frontends der Internetanwendungen mithilfe der Funktionen von Google Cloud Armor, die global verteilte Web Application Firewalls (WAFs) und DDoS-Abwehrdienste bereitstellen.
  • Optional können Sie Private Service Connect in Ihr Design einbinden. So wird ein privater, detaillierter Zugriff auf Google Cloud-Dienst-APIs oder Ihre veröffentlichten Dienste aus anderen Umgebungen ermöglicht, ohne das öffentliche Internet zu nutzen.

Varianten

Die Architekturmuster für gatewaygesteuerten ausgehenden und eingehenden Traffic können mit anderen Ansätzen kombiniert werden, um verschiedene Designanforderungen zu erfüllen, die dennoch die Kommunikationsanforderungen dieses Musters berücksichtigen. Die Muster bieten folgende Optionen:

Verteilte API-Gateways

In Szenarien wie dem, das auf dem Muster partitionierte Multi-Cloud basiert, können Anwendungen (oder Anwendungskomponenten) in verschiedenen Cloudumgebungen erstellt werden, einschließlich einer privaten lokalen Umgebung. In der Regel sollen Clientanfragen direkt an das Anwendungs-Frontend weitergeleitet werden, also an die Umgebung, in der die Anwendung (oder die Frontend-Komponente) gehostet wird. Für diese Art der Kommunikation ist ein lokaler Load Balancer oder ein API-Gateway erforderlich. Für diese Anwendungen und ihre Komponenten sind möglicherweise auch bestimmte API-Plattformfunktionen für die Integration erforderlich.

Das folgende Diagramm zeigt, wie Apigee und Apigee Hybrid mit einem lokalisierten API-Gateway in jeder Umgebung auf solche Anforderungen reagieren. Die API-Plattformverwaltung erfolgt zentral in Google Cloud. Dieses Design trägt dazu bei, strenge Zugriffssteuerungsmaßnahmen durchzusetzen, bei denen nur vorab genehmigte IP-Adressen (Ziel- und Ziel-APIs oder Private Service Connect-Endpunkt-IP-Adressen) zwischen Google Cloud und den anderen Umgebungen kommunizieren können.

Datenein- und ‑ausgang zwischen einer lokalen oder einer anderen Cloud-Umgebung und einer Google Cloud-Umgebung. Clientanfragen an das Anwendungs-Frontend werden direkt an die Umgebung gesendet, in der die Anwendung (oder die Frontend-Komponente) gehostet wird.

In der folgenden Liste werden die beiden verschiedenen Kommunikationspfade im vorherigen Diagramm beschrieben, die das Apigee API-Gateway verwenden:

  • Clientanfragen erreichen das Frontend der Anwendung direkt in der Umgebung, in der die Anwendung (oder die Frontendkomponente) gehostet wird.
  • API-Gateways und Proxys in jeder Umgebung verarbeiten Client- und Anwendungs-API-Anfragen in verschiedene Richtungen über mehrere Umgebungen hinweg.
    • Die API-Gateway-Funktion in Google Cloud (Apigee) stellt die Anwendungskomponenten (Frontend oder Backend) bereit, die in Google Cloud gehostet werden.
    • Die API-Gateway-Funktionen in einer anderen Umgebung (Hybrid) stellen die Frontend- (oder Backend-)Komponenten der Anwendung bereit, die in dieser Umgebung gehostet werden.

Alternativ können Sie eine Transit-VPC verwenden. Ein Transit-VPC kann Flexibilität bieten, um Bedenken zu trennen und Sicherheitsprüfungen und Hybridkonnektivität in einem separaten VPC-Netzwerk durchzuführen. Aus Sicht der Erreichbarkeit von IP-Adressen erfüllt ein Transit-VPC (an das die Hybridkonnektivität angeschlossen ist) die folgenden Anforderungen, um die End-to-End-Erreichbarkeit aufrechtzuerhalten:

  • Die IP-Adressen für Ziel-APIs müssen in den anderen Umgebungen beworben werden, in denen Clients/Anfragen gehostet werden.
  • Die IP-Adressen der Hosts, die mit den Ziel-APIs kommunizieren müssen, müssen in der Umgebung bekannt gemacht werden, in der sich die Ziel-API befindet. Dazu gehören beispielsweise die IP-Adressen des API-Anfragers (des Clients). Eine Ausnahme besteht, wenn die Kommunikation über einen Load Balancer, Proxy, Private Service Connect-Endpunkt oder eine NAT-Instanz erfolgt.

Um die Konnektivität mit der Remote-Umgebung zu erweitern, wird in diesem Design Direct VPC-Peering mit Kunden-Routen-Austausch verwendet. Das Design ermöglicht es, bestimmte API-Anfragen, die von Workloads stammen, die in der Google Cloud-Anwendungs-VPC gehostet werden, über die Transit-VPC zu leiten. Alternativ können Sie einen Private Service Connect-Endpunkt im VPC der Anwendung verwenden, der mit einem Load Balancer mit einem Hybrid-Netzwerk-Endpunktgruppen-Back-End im Transit-VPC verknüpft ist. Diese Einrichtung wird im nächsten Abschnitt beschrieben: Bidirektionale API-Kommunikation mit Private Service Connect.

Bidirektionale API-Kommunikation mit Private Service Connect

Manchmal müssen Unternehmen kein API-Gateway (z. B. Apigee) sofort verwenden oder möchten es später hinzufügen. Es kann jedoch geschäftliche Anforderungen geben, die die Kommunikation und Integration zwischen bestimmten Anwendungen in verschiedenen Umgebungen erfordern. Wenn Ihr Unternehmen beispielsweise ein anderes Unternehmen übernommen hat, müssen Sie möglicherweise bestimmte Anwendungen für dieses Unternehmen freigeben. Möglicherweise muss er Apps für Ihr Unternehmen freigeben. Beide Unternehmen haben möglicherweise jeweils eigene Arbeitslasten, die in verschiedenen Umgebungen gehostet werden (Google Cloud, lokal oder in anderen Clouds). Dabei muss eine Überschneidung von IP-Adressen vermieden werden. In solchen Fällen können Sie Private Service Connect verwenden, um eine effektive Kommunikation zu ermöglichen.

Für Anwendungen, die als APIs genutzt werden, können Sie auch Private Service Connect verwenden, um eine private Adresse für die veröffentlichten Anwendungen bereitzustellen. So wird ein sicherer Zugriff innerhalb des privaten Netzwerks über Regionen und über Hybridkonnektivität ermöglicht. Diese Abstraktion ermöglicht die Einbindung von Ressourcen aus verschiedenen Clouds und lokalen Umgebungen über ein Hybrid- und Multi-Cloud-Konnektivitätsmodell. Außerdem ermöglicht es die Zusammenstellung von Anwendungen in Multi-Cloud- und On-Premises-Umgebungen. So lassen sich unterschiedliche Kommunikationsanforderungen erfüllen, z. B. die Einbindung sicherer Anwendungen, bei denen kein API-Gateway verwendet wird oder verwendet werden soll.

Wenn Sie Private Service Connect mit Cloud Load Balancing kombinieren, wie im folgenden Diagramm dargestellt, können Sie zwei unterschiedliche Kommunikationspfade nutzen. Jeder Pfad wird aus einer anderen Richtung für einen separaten Verbindungszweck gestartet, idealerweise über API-Aufrufe.

  • Alle in diesem Leitfaden beschriebenen Designüberlegungen und Empfehlungen für Private Service Connect gelten für dieses Design.
  • Wenn eine zusätzliche Layer-7-Prüfung erforderlich ist, können Sie NVAs in dieses Design (im Transit-VPC) einbinden.
  • Dieses Design kann mit oder ohne API-Gateways verwendet werden.

Lokale oder andere Cloud-Umgebungen und eine Google Cloud-Umgebung kommunizieren Daten über verschiedene Pfade und verschiedene Load Balancer, VPC-Endpunkte und Subnetze.

Die beiden im vorherigen Diagramm dargestellten Konnektivitätspfade stellen unabhängige Verbindungen dar und zeigen keine Zwei-Wege-Kommunikation einer einzelnen Verbindung oder eines einzelnen Flusses.

Bidirektionale Kommunikation über Private Service Connect-Endpunkte und ‑Schnittstellen

Wie im Abschnitt zum Gated Ingress-Muster erläutert, besteht eine Möglichkeit zur Aktivierung der Client-Dienstkommunikation darin, einen Dienst in einem Ersteller-VPC über einen Private Service Connect-Endpunkt für ein Nutzer-VPC verfügbar zu machen. Diese Konnektivität kann über eine hybride Konnektivität auf eine lokale Umgebung oder sogar auf eine Umgebung eines anderen Cloud-Anbieters erweitert werden. In einigen Fällen kann für den gehosteten Dienst jedoch auch eine private Kommunikation erforderlich sein.

Für den Zugriff auf einen bestimmten Dienst, z. B. zum Abrufen von Daten aus Datenquellen, die innerhalb oder außerhalb der VPC des Nutzers gehostet werden können, kann diese private Kommunikation zwischen der VPC der Anwendung (Ersteller) und einer Remote-Umgebung wie einer lokalen Umgebung erfolgen.

In einem solchen Szenario ermöglichen Private Service Connect-Schnittstellen einer VM-Instanz eines Diensterstellers den Zugriff auf das Netzwerk eines Nutzers. Dazu wird eine Netzwerkschnittstelle gemeinsam genutzt, während die Rollen von Produzenten und Verbrauchern weiterhin getrennt bleiben. Über diese Netzwerkschnittstelle im Nutzer-VPC kann die Anwendungs-VM auf Nutzerressourcen zugreifen, als wären sie lokal im Ersteller-VPC vorhanden.

Eine Private Service Connect-Schnittstelle ist eine Netzwerkschnittstelle, die mit dem VPC des Nutzers (Transit-VPC) verbunden ist. Es ist möglich, externe Ziele zu erreichen, die über die VPC des Nutzers (Transit-VPC), an die die Private Service Connect-Schnittstelle angehängt ist, erreichbar sind. Daher kann diese Verbindung über eine hybride Konnektivität wie eine On-Premises-Umgebung auf eine externe Umgebung erweitert werden, wie im folgenden Diagramm dargestellt:

Datenausgang und ‑eingang zwischen einer Anwendung in Google Cloud und einer Arbeitslast in einem lokalen Netzwerk oder einem anderen Cloud-Netzwerk.

Wenn die VPC des Nutzers zu einer externen Organisation oder Entität wie einer Drittanbieterorganisation gehört, können Sie die Kommunikation mit der Private Service Connect-Benutzeroberfläche in der VPC des Nutzers in der Regel nicht schützen. In einem solchen Szenario können Sie Sicherheitsrichtlinien im Gastbetriebssystem der VM mit der Private Service Connect-Schnittstelle definieren. Weitere Informationen finden Sie unter Sicherheit für Private Service Connect-Schnittstellen konfigurieren. Sie können auch einen alternativen Ansatz in Betracht ziehen, wenn er nicht den Sicherheitsanforderungen oder -standards Ihrer Organisation entspricht.

Best Practices

  • Wenn Clientanfragen aus dem Internet lokal von einem Frontend empfangen werden müssen, das in einer privaten lokalen oder einer anderen Cloud-Umgebung gehostet wird, sollten Sie Hybrid als API-Gateway-Lösung verwenden.

    • Dieser Ansatz erleichtert auch die Migration der Lösung in eine vollständig in Google Cloud gehostete Umgebung, wobei die Konsistenz der API-Plattform (Apigee) beibehalten wird.
  • Um die Latenz zu minimieren und die Kosten für große Mengen an ausgehenden Datenübertragungen an Ihre anderen Umgebungen zu optimieren, wenn sich diese Umgebungen in langfristigen oder dauerhaften Hybrid- oder Multi-Cloud-Umgebungen befinden, sollten Sie Folgendes beachten:

    • Verwenden Sie Cloud Interconnect oder Cross-Cloud Interconnect.
    • Wenn Sie Nutzerverbindungen am Ziel-Frontend in der entsprechenden Umgebung beenden möchten, verwenden Sie Hybrid.
  • Verwenden Sie den Apigee-Adapter für Envoy mit einer Hybridbereitstellung mit Kubernetes, wenn dies für Ihre Anforderungen und die Architektur geeignet ist.

  • Bevor Sie die Konnektivitäts- und Routingpfade entwerfen, müssen Sie zuerst ermitteln, welche Traffic- oder API-Anfragen an ein lokales oder Remote-API-Gateway weitergeleitet werden müssen, sowie die Quell- und Zielumgebungen.

  • Verwenden Sie VPC Service Controls, um Google Cloud-Dienste in Ihren Projekten zu schützen und das Risiko einer Daten-Exfiltration zu minimieren. Geben Sie dazu Dienstperimeter auf Projekt- oder VPC-Netzwerkebene an.

  • Mithilfe von VPC-Firewallregeln oder Firewallrichtlinien können Sie den Zugriff auf Private Service Connect-Ressourcen über den Private Service Connect-Endpunkt auf Netzwerkebene steuern. Beispielsweise können Firewallregeln für ausgehenden Traffic im VPC der Anwendung (Nutzer) den Zugriff von VM-Instanzen auf die IP-Adresse oder das Subnetz Ihrer Endpunkte einschränken.

  • Wenn Sie eine Private Service Connect-Schnittstelle verwenden, müssen Sie die Kommunikation mit der Schnittstelle schützen, indem Sie die Sicherheit für die Private Service Connect-Schnittstelle konfigurieren.

  • Wenn eine Arbeitslast in einem privaten Subnetz Internetzugriff benötigt, verwenden Sie Cloud NAT, um der Arbeitslast keine externe IP-Adresse zuzuweisen und sie nicht dem öffentlichen Internet auszusetzen.

  • Lesen Sie die allgemeinen Best Practices für Hybrid- und Multi-Cloud-Netzwerkmuster.

Handover-Muster

Beim Handover-Muster basiert die Architektur auf der Verwendung von Speicherdiensten, die in Google Cloud bereitgestellt werden, um eine private Rechenumgebung mit Projekten in Google Cloud zu verbinden. Dieses Muster gilt hauptsächlich für Einrichtungen, die dem Architekturmuster der Hybrid-Multi-Cloud für Analysen folgen. Dabei gilt:

  • Von den in einer privaten Rechenumgebung oder in einer anderen Cloud ausgeführten Arbeitslasten werden Daten in freigegebene Speicher hochgeladen. Je nach Anwendungsfall können Daten in Bulk-Uploads oder in kleineren Schritten hochgeladen werden.
  • In Google Cloud gehostete Arbeitslasten oder andere Google-Dienste (z. B. Datenanalyse- und KI-Dienste) nutzen Daten von den freigegebenen Speicherorten und verarbeiten sie per Streaming oder Batch.

Architektur

Das folgende Diagramm zeigt eine Referenzarchitektur für das Handover-Muster.

Daten fließen von einer lokalen Umgebung zu einer in einer VPC gehosteten Arbeitslast und einem in einer Google Cloud-Umgebung gehosteten Dienst zur Datenanalyse.

Das obige Architekturdiagramm zeigt die folgenden Workflows:

  • In Google Cloud stellen Sie Arbeitslasten in einer Anwendungs-VPC bereit. Diese Arbeitslasten können Datenverarbeitungs-, Analyse- und analysebezogene Front-End-Anwendungen umfassen.
  • Frontend-Anwendungen können Nutzern mit Cloud Load Balancing oder API Gateway sicher zur Verfügung gestellt werden.
  • Mit einer Reihe von Cloud Storage-Buckets oder Pub/Sub-Warteschlangen werden Daten aus der privaten Rechenumgebung hochgeladen und für die weitere Verarbeitung durch Arbeitslasten zur Verfügung gestellt, die in Google Cloud ausgeführt werden. Mit IAM-Richtlinien (Identity and Access Management) können Sie den Zugriff auf vertrauenswürdige Arbeitslasten einschränken.
  • Verwenden Sie VPC Service Controls, um den Zugriff auf Dienste einzuschränken und das Risiko einer unrechtmäßigen Daten-Exfiltration aus Google Cloud-Diensten zu minimieren.
  • Bei dieser Architektur erfolgt die Kommunikation mit Cloud Storage-Buckets oder Pub/Sub über öffentliche Netzwerke oder über eine private Verbindung mit VPN, Cloud Interconnect oder Cross-Cloud Interconnect. Die Entscheidung, wie eine Verbindung hergestellt werden soll, hängt von mehreren Aspekten ab, wie zum Beispiel:
    • Voraussichtliches Traffic-Volumen
    • Ob es sich um eine vorübergehende oder dauerhafte Einrichtung handelt
    • Sicherheits- und Complianceanforderungen

Variante

Die Designoptionen, die im Muster für gatewaygesteuerten eingehenden Traffic beschrieben werden, das Private Service Connect-Endpunkte für Google APIs verwendet, können auch auf dieses Muster angewendet werden. Insbesondere bietet er Zugriff auf Cloud Storage, BigQuery und andere Google-Dienst-APIs. Dieser Ansatz erfordert private IP-Adressen über eine Hybrid- und Multi-Cloud-Netzwerkverbindung wie VPN, Cloud Interconnect und Cross-Cloud Interconnect.

Best Practices

  • Sperren Sie den Zugriff auf Cloud Storage-Buckets und Pub/Sub-Themen.
  • Verwenden Sie nach Möglichkeit Cloud-first-Lösungen für die Datenübertragung, z. B. die Google Cloud-Lösungen. Diese Lösungen sind so konzipiert, dass sie Daten effizient verschieben, einbinden und transformieren können, um Ihren Anwendungsfallanforderungen gerecht zu werden.
  • Bewerten Sie die verschiedenen Faktoren, die sich auf die Datenübertragungsoptionen auswirken, z. B. Kosten, erwartete Übertragungszeit und Sicherheit. Weitere Informationen finden Sie unter Übertragungsoptionen bewerten.

  • Ziehen Sie die Verwendung von Cloud Interconnect oder Cross-Cloud Interconnect in Betracht, um die Latenz zu minimieren und die Übertragung und Verschiebung großer Datenmengen über das öffentliche Internet zu verhindern, einschließlich des Zugriffs auf Private Service Connect-Endpunkte in Ihrer Virtual Private Cloud für Google APIs.

  • Verwenden Sie VPC Service Controls, um Google Cloud-Dienste in Ihren Projekten zu schützen und das Risiko einer Daten-Exfiltration zu minimieren. Mit diesen Dienststeuerungen können Dienstperimeter auf Projekt- oder VPC-Netzwerkebene angegeben werden.

  • Kommunikation mit öffentlich veröffentlichten Datenanalyse-Arbeitslasten, die auf VM-Instanzen über ein API-Gateway, einen Load Balancer oder eine virtuelle Netzwerk-Appliance gehostet werden. Verwenden Sie eine dieser Kommunikationsmethoden für zusätzliche Sicherheit und um zu vermeiden, dass diese Instanzen direkt vom Internet aus erreichbar sind.

  • Wenn ein Internetzugriff erforderlich ist, kann Cloud NAT in derselben VPC verwendet werden, um ausgehenden Traffic von den Instanzen zum öffentlichen Internet zu verarbeiten.

  • Lesen Sie die allgemeinen Best Practices für Hybrid- und Multi-Cloud-Netzwerktopologien.

Allgemeine Best Practices

Beachten Sie beim Entwerfen und Onboarding von Cloud-Identitäten, der Ressourcenhierarchie und Landing-Zone-Netzwerken die Designempfehlungen im Artikel Landing-Zone-Design in Google Cloud und die Google Cloud-Sicherheitsbest Practices im Enterprise Foundations-Blueprint. Prüfen Sie das ausgewählte Design anhand der folgenden Dokumente:

Beachten Sie außerdem die folgenden allgemeinen Best Practices:

  • Berücksichtigen Sie bei der Auswahl einer Option für die Hybrid- oder Multi-Cloud-Netzwerkkonnektivität Geschäfts- und Anwendungsanforderungen wie SLAs, Leistung, Sicherheit, Kosten, Zuverlässigkeit und Bandbreite. Weitere Informationen finden Sie unter Network Connectivity-Produkt auswählen und Muster zum Verbinden anderer Cloud-Dienstanbieter mit Google Cloud.

  • Verwenden Sie freigegebene VPCs in Google Cloud anstelle mehrerer VPCs, wenn dies angemessen und mit den Anforderungen Ihres Ressourcenhierarchie-Designs übereinstimmt. Weitere Informationen finden Sie unter Entscheiden, ob mehrere VPC-Netzwerke erstellt werden sollen.

  • Befolgen Sie die Best Practices für die Planung von Konten und Organisationen.

  • Richten Sie gegebenenfalls eine gemeinsame Identität zwischen Umgebungen ein, damit sich Systeme über Umgebungsgrenzen hinweg sicher authentifizieren können.

  • Wenn Sie Anwendungen in einer Hybridumgebung sicher für Unternehmensnutzer freigeben und den Ansatz auswählen möchten, der Ihren Anforderungen am besten entspricht, sollten Sie die empfohlenen Methoden zur Integration von Google Cloud in Ihr Identitätsverwaltungssystem befolgen.

  • Berücksichtigen Sie beim Entwerfen Ihrer lokalen und Cloud-Umgebungen frühzeitig die IPv6-Adressen und berücksichtigen Sie, welche Dienste diese unterstützen. Weitere Informationen finden Sie unter Einführung in IPv6 in Google Cloud. Dort werden die Dienste zusammengefasst, die zum Zeitpunkt der Veröffentlichung des Blogposts unterstützt wurden.

  • Beim Entwerfen, Bereitstellen und Verwalten Ihrer VPC-Firewallregeln haben Sie folgende Möglichkeiten:

    • Verwenden Sie die Filterung nach Dienstkonten und nicht nach Netzwerktags, wenn Sie eine strenge Kontrolle darüber benötigen, wie Firewallregeln auf VMs angewendet werden.
    • Verwenden Sie Firewallrichtlinien, wenn Sie mehrere Firewallregeln gruppieren, damit Sie sie alle gleichzeitig aktualisieren können. Sie können die Richtlinie auch hierarchisch gestalten. Details und Spezifikationen zu hierarchischen Firewallrichtlinien finden Sie unter Hierarchische Firewallrichtlinien.
    • Verwenden Sie Standortobjekte in der Firewallrichtlinie, wenn Sie externen IPv4- und externen IPv6-Traffic anhand bestimmter geografischer Standorte oder Regionen filtern möchten.
    • Verwenden Sie Threat Intelligence für Firewallregeln , wenn Sie Ihr Netzwerk schützen möchten, indem Sie Traffic basierend auf Threat Intelligence-Daten zulassen oder blockieren, z. B. bekannte schädliche IP-Adressen oder IP-Adressbereiche der öffentlichen Cloud. Sie können beispielsweise Traffic aus bestimmten öffentlichen Cloud-IP-Adressbereichen zulassen, wenn Ihre Dienste nur mit dieser öffentlichen Cloud kommunizieren müssen. Weitere Informationen finden Sie unter Best Practices für Firewallregeln.
  • Sie sollten Ihre Cloud- und Netzwerksicherheit immer mit einem mehrschichtigen Sicherheitsansatz entwerfen und dabei zusätzliche Sicherheitsebenen berücksichtigen, z. B.:

    Mit diesen zusätzlichen Schichten können Sie eine Vielzahl von Bedrohungen auf Netzwerk- und Anwendungsebene filtern, prüfen und überwachen, um sie zu analysieren und zu verhindern.

  • Bei der Entscheidung, wo die DNS-Auflösung in einer Hybridumgebung erfolgen soll, empfehlen wir, zwei autoritative DNS-Systeme für Ihre private Google Cloud-Umgebung und für Ihre lokalen Ressourcen zu verwenden, die von vorhandenen DNS-Servern in Ihrer lokalen Umgebung gehostet werden. Weitere Informationen finden Sie unter Ort der DNS-Auflösung auswählen.

  • Stellen Sie Anwendungen nach Möglichkeit immer über APIs mit einem API-Gateway oder Load Balancer bereit. Wir empfehlen eine API-Plattform wie Apigee. Apigee fungiert als Abstraktion oder Fassade für Ihre Back-End-Dienst-APIs in Kombination mit Sicherheitsfunktionen, Ratenbegrenzung, Kontingenten und Analysen.

  • Eine API-Plattform (Gateway oder Proxy) und ein Application Load Balancer schließen sich nicht gegenseitig aus. Manchmal ist die gemeinsame Verwendung von API-Gateways und Load Balancern eine robustere und sicherere Lösung für die Verwaltung und Verteilung von API-Traffic in großem Maßstab. Mit Cloud Load Balancing API-Gateways haben Sie folgende Möglichkeiten:

  • Um zu bestimmen, welches Cloud Load Balancing-Produkt verwendet werden soll, müssen Sie erst einmal festlegen, welche Art von Traffic Ihre Load-Balancer verarbeiten müssen. Weitere Informationen finden Sie unter Load-Balancer auswählen.

  • Wenn Cloud Load Balancing verwendet wird, sollten Sie gegebenenfalls die Funktionen zur Optimierung der Anwendungskapazität nutzen. Auf diese Weise können Sie einige der Kapazitätsprobleme bewältigen, die bei global verteilten Anwendungen auftreten können.

  • Während Cloud VPN den Traffic zwischen Umgebungen verschlüsselt, müssen Sie bei Cloud Interconnect entweder MACsec oder HA VPN über Cloud Interconnect verwenden, um Traffic während der Übertragung auf der Verbindungsebene zu verschlüsseln. Weitere Informationen finden Sie unter Wie kann ich Traffic über Cloud Interconnect verschlüsseln?

  • Wenn Sie über eine VPN-Hybridkonnektivität ein größeres Trafficvolumen benötigen, als ein einzelner VPN-Tunnel unterstützen kann, können Sie die Option Aktiv/Aktiv-HA VPN-Routing verwenden.

    • Für langfristige Hybrid- oder Multi-Cloud-Umgebungen mit hohem ausgehenden Datenübertragungsvolumen sollten Sie Cloud Interconnect oder Cross-Cloud Interconnect in Betracht ziehen. Mit diesen Konnektivitätsoptionen lässt sich die Konnektivitätsleistung optimieren und die Kosten für die ausgehende Datenübertragung senken, die bestimmte Bedingungen erfüllen. Weitere Informationen finden Sie unter Cloud Interconnect-Preise.
  • Wenn Sie eine Verbindung zu Google Cloud-Ressourcen herstellen und zwischen Cloud Interconnect, Direct Peering oder Carrier Peering wählen möchten, empfehlen wir Cloud Interconnect, es sei denn, Sie müssen auf Google Workspace-Anwendungen zugreifen. Weitere Informationen finden Sie im Vergleich der Funktionen von Direct Peering mit Cloud Interconnect und Carrier Peering mit Cloud Interconnect.

  • Reservieren Sie von Ihrem bestehenden IP-Adressbereich nach RFC 1918 einen ausreichend großen Adressbereich für Ihre in der Cloud gehosteten Systeme.

  • Wenn Sie aufgrund technischer Einschränkungen Ihren IP-Adressbereich beibehalten müssen, haben Sie folgende Möglichkeiten:

    • Verwenden Sie dieselben internen IP-Adressen für Ihre lokalen Arbeitslasten, während Sie sie mithilfe von Hybrid-Subnetzen zu Google Cloud migrieren.

    • Mit Eigene IP-Adresse verwenden (BYOIP) können Sie Ihre eigenen öffentlichen IPv4-Adressen für Google Cloud-Ressourcen bereitstellen und verwenden.

  • Wenn für das Design Ihrer Lösung eine Google Cloud-basierte Anwendung für das öffentliche Internet freigegeben werden muss, beachten Sie die Designempfehlungen unter Netzwerk für die Bereitstellung internetfähiger Anwendungen.

  • Verwenden Sie gegebenenfalls Private Service Connect-Endpunkte, um Arbeitslasten in Google Cloud, lokal oder in einer anderen Cloud-Umgebung mit Hybrid-Verbindung zu ermöglichen, privat über interne IP-Adressen auf Google APIs oder veröffentlichte Dienste zuzugreifen.

  • Wenn Sie Private Service Connect verwenden, müssen Sie Folgendes steuern:

    • Wer Private Service Connect-Ressourcen bereitstellen kann.
    • Ob Verbindungen zwischen Nutzern und Erstellern hergestellt werden können.
    • Welcher Netzwerkverkehr auf diese Verbindungen zugreifen darf.

    Weitere Informationen finden Sie unter Private Service Connect-Sicherheit.

  • So erreichen Sie eine robuste Cloud-Umgebung im Kontext einer Hybrid- und Multi-Cloud-Architektur:

    • Führen Sie eine umfassende Bewertung der erforderlichen Zuverlässigkeitsstufen der verschiedenen Anwendungen in verschiedenen Umgebungen durch. So können Sie Ihre Ziele in Bezug auf Verfügbarkeit und Ausfallsicherheit erreichen.
    • Informieren Sie sich über die Zuverlässigkeitsfunktionen und Designprinzipien Ihres Cloud-Anbieters. Weitere Informationen finden Sie unter Zuverlässigkeit der Google Cloud-Infrastruktur.
  • Transparenz und Monitoring des Cloud-Netzwerks sind entscheidend, um eine zuverlässige Kommunikation aufrechtzuerhalten. Das Network Intelligence Center bietet eine einzige Konsole zum Verwalten der Sichtbarkeit, Überwachung und Fehlerbehebung des Netzwerks.

Architekturmuster für sichere Hybrid- und Multi-Cloud-Netzwerke: Nächste Schritte