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 das Design der Geschäftskontinuität, um eine Notfallwiederherstellungsumgebung (DR) in Google Cloudbereitzustellen. 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. in Bezug auf 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 zulassen, für die das Muster entwickelt wurde. Idealerweise sollten Sie einen mehrstufigen Sicherheitsansatz verwenden, um den Trafficfluss sowohl zwischen als auch innerhalb von Rechenzentren detailliert einzuschränken.
Architektur
Das folgende Diagramm zeigt eine allgemeine Referenzarchitektur des Mesh-Musters.
- Alle Umgebungen sollten einen sich nicht überschneidenden IP-Adressbereich nach RFC 1918 verwenden.
- In der 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:
Virtuelle Netzwerk-Appliance (NVA) mit Untersuchungsfunktionen für Firewalls der nächsten Generation (NGFW), die im Netzwerkpfad platziert werden.
Cloud Next Generation Firewall Enterprise mit Intrusion Prevention Service (IPS) zur Implementierung von Deep Packet Inspection zum Schutz vor Bedrohungen, ohne das Netzwerkdesign oder das Routing zu ändern.
Varianten
Das Mesh-Architekturmuster kann mit anderen Ansätzen kombiniert werden, um verschiedene Designanforderungen zu erfüllen, die dennoch die Kommunikationsanforderungen des Musters berücksichtigen. Die Musteroptionen werden in den folgenden Abschnitten beschrieben:
- Eine VPC pro Umgebung
- Zentrale Firewall auf Anwendungsebene verwenden
- Verteilte Zero-Trust-Architektur für Mikrodienste
Eine VPC pro Umgebung
Die häufigsten Gründe für die Option „Eine 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 eine freigegebene VPC für jede Umgebung in Google Cloud, z. B. für Entwicklung, Tests und Produktion.
- Skalieren Sie Anforderungen, die möglicherweise über die VPC-Kontingente für eine einzelne VPC oder ein einzelnes Projekt hinausgehen.
Wie im folgenden Diagramm dargestellt, kann jede VPC bei einem Design mit einer VPC pro Umgebung direkt über VPNs oder Cloud Interconnect mit mehreren VLAN-Anhängen in die lokale Umgebung oder andere Cloud-Umgebungen eingebunden werden.
Das im vorherigen Diagramm dargestellte Muster kann auf eine Hub-and-Spoke-Netzwerktopologie in der Landingzone 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 beendet werden. Sie können dieses Design auch erweitern, indem Sie der Transit-VPC eine NVA mit NGFW-Prüffunktionen hinzufügen, wie im nächsten Abschnitt „Zentrale Firewall auf Anwendungsebene verwenden“ beschrieben.
Zentrale Firewall auf Anwendungsebene verwenden
Wenn Ihre technischen Anforderungen die Berücksichtigung der Anwendungsschicht (Layer 7) und eine Deep Packet Inspection 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 Landingzone-Design anwenden, indem Sie eine Hub-and-Spoke-Topologie mit zentralisierten Appliances verwenden:
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 Ebenen für die Sicherheitszugriffssteuerung umfassen.
Verteilte Zero-Trust-Architektur für Mikrodienste
Bei der Verwendung containerisierter Anwendungen gilt die im Abschnitt gespiegeltes Muster 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 verteilte Zero-Trust-Architektur, wenn Sie Kubernetes in Ihrer privaten Rechenumgebung und inGoogle Cloudverwenden.
- Wenn Sie in Ihrem Design zentralisierte NVAs verwenden, sollten Sie mehrere Segmente mit unterschiedlichen Ebenen von Sicherheitszugriffssteuerungen und Richtlinien für die Trafficprüfung definieren. Diese Steuerungen 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 Single Point of Failure 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 mithilfe von API-Gateways wie Apigee und Apigee Hybrid mit End-to-End-mTLS bereit. Sie können auch eine freigegebene 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 Internetbereitstellung von 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 Cloudgehosteten Anwendungen und anderen Umgebungen erzwingen möchten, können Sie eines der Gateway-Muster verwenden, die in den anderen Dokumenten dieser Reihe beschrieben werden.