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.
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.
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:
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.
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:
Anwendungs-Endpunkte mit Private Service Connect für andere Umgebungen verfügbar machen
Mit einer Hub-and-Spoke-Architektur Anwendungs-Backends für andere Umgebungen freigeben
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.
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:
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.
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, wie in diesem Leitfaden beschrieben.
- 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.
- Bei Bedarf können Sie Dienstperimeter über ein VPN oder Cloud Interconnect auf eine Hybridumgebung ausweiten. Weitere Informationen zu den Vorteilen von Dienstperimetern finden Sie unter VPC Service Controls.
- 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.