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.
- 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:
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:
- Ein VPC pro Umgebung
- Eine zentrale Firewall der Anwendungsebene verwenden
- Verteilte Zero-Trust-Architektur für Mikrodienste
Eine VPC pro Umgebung
Die häufigsten Gründe für die Verwendung der 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.
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:
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.