Gatewaygesteuerter ausgehender Traffic

Last reviewed 2023-12-14 UTC

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.