Netzwerksicherheit für verteilte Anwendungen im Cross-Cloud Network

Last reviewed 2025-01-30 UTC

Dieses Dokument ist Teil einer Designanleitungsreihe für Cross-Cloud Network. In diesem Teil wird die Netzwerksicherheitsebene behandelt.

Die Reihe besteht aus folgenden Teilen:

Sicherheitsoberflächen

Beim Entwerfen der Sicherheitsebene für das Cross-Cloud Network müssen Sie die folgenden Sicherheitsoberflächen berücksichtigen:

  • Arbeitslastsicherheit
  • Sicherheit des Domainperimeters

Die Arbeitslastsicherheit steuert die Kommunikation zwischen Arbeitslasten innerhalb der Virtual Private Cloud (VPC). Dabei werden Sicherheitsdurchsetzungspunkte verwendet, die sich in der Nähe der Arbeitslasten in der Architektur befinden. Wann immer möglich, bietet Cross-Cloud Network mit der Firewall der nächsten Generation von Google Cloud Arbeitslastsicherheit Google Cloud.

Perimetersicherheit ist an allen Netzwerkgrenzen erforderlich. Da der Perimeter in der Regel Netzwerke miteinander verbindet, die von verschiedenen Organisationen verwaltet werden, sind oft strengere Sicherheitskontrollen erforderlich. Sie müssen sicherstellen, dass die folgenden netzwerkübergreifenden Kommunikationen geschützt sind:

  • Kommunikation zwischen VPCs
  • Kommunikation über Hybridverbindungen zu anderen Cloud-Anbietern oder lokalen Rechenzentren
  • Kommunikation mit dem Internet

Die Möglichkeit, virtuelle Netzwerk-Appliances (NVAs) von Drittanbietern in die Google Cloud Umgebung einzufügen, ist von entscheidender Bedeutung, um die Anforderungen an die Perimetersicherheit in Hybridverbindungen zu erfüllen.

Arbeitslastsicherheit in der Cloud

Verwenden Sie Firewallrichtlinien in Google Cloud um Arbeitslasten zu schützen und zustandsorientierte Firewall funktionen bereitzustellen, die horizontal skalierbar sind und auf jede VM-Instanz angewendet werden. Die verteilte Natur von Google Cloud Firewalls hilft Ihnen, Sicherheits richtlinien für die Netzwerk-Mikrosegmentierung zu implementieren, ohne die Leistung Ihrer Arbeitslasten zu beeinträchtigen.

Verwenden Sie hierarchische Firewallrichtlinien, um die Verwaltbarkeit zu verbessern und die Einhaltung der Sicherheitskonfiguration für Ihre Firewall richtlinien zu erzwingen. Mit hierarchischen Firewallrichtlinien können Sie eine konsistente Firewallrichtlinie für Ihre gesamte Organisation erstellen und erzwingen. Sie können der Organisation oder einzelnen Ordnern hierarchische Firewallrichtlinien zuweisen. Darüber hinaus können die Regeln hierarchischer Firewallrichtlinien die Auswertung mit der Aktion goto_next an Richtlinien auf einer niedrigeren Ebene (globale oder regionale Netzwerk-Firewallrichtlinien) delegieren.

Regeln auf niedrigerer Ebene können keine Regeln von einer höheren Ebene in der Ressourcenhierarchie überschreiben. Mit dieser Regelstruktur können organisationsweite Administratoren obligatorische Firewallregeln an einem Ort verwalten. Häufige Anwendungsfälle für hierarchische Firewallrichtlinien sind der Zugriff auf Bastion-Hosts in Organisationen oder mehreren Projekten, die Zulassung zentralisierter Prüf- oder Systemdiagnosesysteme und die Erzwingung einer virtuellen Netzwerkgrenze in einer Organisation oder einer Gruppe von Projekten. Weitere Beispiele für die Verwendung hierarchischer Firewallrichtlinien finden Sie unter Beispiele für hierarchische Firewallrichtlinien.

Verwenden Sie globale und regionale Netzwerk Firewallrichtlinien, um Regeln für einzelne VPC-Netzwerke zu definieren, entweder für alle Regionen des Netzwerks (global) oder eine einzelne Region (regional).

Damit detailliertere Kontrollen auf VM-Ebene (virtuelle Maschinen) erzwungen werden, empfehlen wir die Verwendung der IAM-gesteuerten Tags (Identity and Access Management) auf Organisations- oder Projektebene. Mit IAM-gesteuerten Tags können Firewallregeln basierend auf der Identität des Arbeitslasthosts und nicht auf der Host-IP-Adresse angewendet werden. Sie funktionieren auch über VPC-Netzwerk-Peering hinweg. Mit Tags bereitgestellte Firewallregeln können eine Mikrosegmentierung innerhalb von Subnetzen mit einer Richtlinienabdeckung bieten, die automatisch auf Arbeitslasten angewendet wird, unabhängig davon, wo sie bereitgestellt werden und unabhängig von der Netzwerkarchitektur.

Neben zustandsorientierten Prüffunktionen und Tag-Unterstützung, die Firewall der nächsten Generation von Google Cloud unterstützt auch Threat Intelligence, FQDN- und Geolocation-Filterung.

Wir empfehlen, von VPC-Firewallregeln zu Firewallrichtlinien zu migrieren. Verwenden Sie dazu das Migrationstool, das eine globale Netzwerk-Firewallrichtlinie erstellt und vorhandene VPC-Firewallregeln in die neue Richtlinie konvertiert.

Perimetersicherheit in der Cloud

In einer Multi-Cloud-Netzwerkumgebung wird die Perimetersicherheit in der Regel in jedem Netzwerk implementiert. So hat das lokale Netzwerk beispielsweise eigene Perimeter-Firewalls, während jedes Cloud-Netzwerk separate Perimeter-Firewalls implementiert.

Da das Cross-Cloud Network als Hub für alle Kommunikationen konzipiert ist, können Sie die Kontrollen für die Perimetersicherheit vereinheitlichen und zentralisieren und einen einzigen Satz von Perimeter-Firewalls in Ihrem Cross-Cloud Network bereitstellen. Um einen integrierten Perimeter-Sicherheitsstack Ihrer Wahl bereitzustellen, bietet Cross-Cloud Network flexible Optionen zum Einfügen von NVAs.

In den in den Diagrammen dargestellten Designs können Sie NVAs von Drittanbietern in der Transit-VPC im Hub-Projekt bereitstellen.

NVAs können über eine einzelne Netzwerkschnittstelle (Einzel-NIC-Modus) oder über mehrere Netzwerkschnittstellen in mehreren VPCs (Multi-NIC-Modus) bereitgestellt werden. Für ein Cross-Cloud Network empfehlen wir eine Bereitstellung mit einer einzigen NIC für NVAs, da Sie mit dieser Option Folgendes tun können:

  • NVAs mit richtlinienbasierten Routen einfügen.
  • Starre Topologien vermeiden.
  • In einer Vielzahl von Inter-VPC-Topologien bereitstellen.
  • Autoscaling für die NVAs aktivieren.
  • Im Laufe der Zeit auf viele VPCs skalieren, ohne dass Änderungen an der NVA-Schnittstellenbereitstellung erforderlich sind.

Wenn Ihr Design mehrere NICs erfordert, finden Sie Empfehlungen unter Perimetersicherheit für NVAs mit mehreren NICs.

Um die für die NVA-Bereitstellung erforderliche Traffic-Steuerung zu erreichen, empfiehlt diese Anleitung die selektive Erzwingung richtlinienbasierter und statischer Routen in den VPC-Routingtabellen. Richtlinienbasierte Routen sind flexibler als Standardrouten, da sie sowohl mit Quell- als auch mit Zielinformationen übereinstimmen. Diese richtlinienbasierten Routen werden auch nur an bestimmten Stellen in der Cloud-Netzwerktopologie erzwungen. Diese Granularität ermöglicht die Definition eines sehr spezifischen Traffic-Steuerungsverhaltens für sehr spezifische Verbindungsflüsse.

Darüber hinaus ermöglicht dieses Design die für die NVAs erforderlichen Resilienzmechanismen. NVAs werden von einem internen TCP/UDP-Load Balancer unterstützt, um NVA-Redundanz, Autoscaling für elastische Kapazität und Flusssymmetrie zur Unterstützung der zustandsorientierten bidirektionalen Traffic-Verarbeitung zu ermöglichen.

Perimetersicherheit für NVAs mit einer einzelnen NIC

Im unter Inter-VPC-Konnektivität für zentralisierte Dienste beschriebenen Design fungiert die Transit-VPC als Hub für die Spoke-VPCs, die über Peering und HA VPN eines VPC-Netzwerks verbunden sind. Die Transit-VPC ermöglicht auch die Verbindung zwischen den externen Netzwerken und den Spoke-VPCs.

Für das Einfügen von NVAs mit einer einzelnen NIC kombiniert dieses Design die folgenden beiden Muster:

  • NVAs an einem VPC-Netzwerk-Peering-Hub mit externen Hybridverbindungen einfügen
  • NVAs an einem HA VPN-VPC-Hub mit externen Hybridverbindungen einfügen

Das folgende Diagramm zeigt NVAs, die an den Hubs für VPC-Netzwerk-Peering und HA VPN eingefügt wurden:

NVAs, die an den Hubs für VPC-Netzwerk-Peering und HA VPN eingefügt werden

Das obige Diagramm veranschaulicht ein kombiniertes Muster:

  • Eine Transit-VPC, die die Cloud Interconnect-VLAN-Anhänge hostet, die Hybrid- oder Multi-Cloud-Konnektivität bereitstellen. Diese VPC enthält auch die NVAs mit einer einzelnen Netzwerkkarte, die die Hybridverbindungen überwachen.
  • Anwendungs-VPCs, die über VPC-Netzwerk-Peering mit der Transit-VPC verbunden sind.
  • Eine zentrale Dienst-VPC, die über HA VPN mit der Transit-VPC verbunden ist.

In diesem Design verwenden die Spokes, die über HA VPN verbunden sind, die Transit-VPC, um mit den Spokes zu kommunizieren, die über VPC-Netzwerk-Peering verbunden sind. Die Kommunikation wird über die Firewalls von Drittanbietern gesteuert, indem die folgende Kombination aus Passthrough-Load-Balancing, statischen Routen und richtlinienbasierten Routen verwendet wird:

  1. Um HA VPN-Traffic an den internen Load-Balancer weiterzuleiten, wenden Sie nicht getaggte richtlinienbasierte Routen auf die Transit-VPC an. Verwenden Sie für diese richtlinienbasierten Routen Quell- und Ziel-CIDR-Bereiche, die für eine Traffic-Symmetrie sorgen.
  2. Um eingehenden Traffic an den internen Passthrough-Network-Load-Balancer weiterzuleiten, wenden Sie richtlinienbasierte Routen auf die Cloud Interconnect-Verbindungen in der Transit-VPC an. Dies sind regionale Routen.
  3. Damit Traffic, der die NVA verlässt, nicht direkt wieder an die NVA weitergeleitet wird, legen Sie alle NVA-Schnittstellen als Ziel einer richtlinienbasierten Route zum Überspringen fest, um andere richtlinienbasierte Routen zu überspringen. Der Traffic folgt dann der VPC-Routingtabelle, nachdem er von den NVAs verarbeitet wurde.
  4. Um Traffic an die internen Load-Balancer der NVA in der Transit-VPC weiterzuleiten, wenden Sie statische Routen auf die Anwendungs-VPCs an. Diese können mit Netzwerktags regional begrenzt werden.

Perimetersicherheit für NVAs mit mehreren NICs

Im Multi-NIC-Modus ist die Topologie statischer, da NVAs die Verbindung zwischen den verschiedenen VPCs überbrücken, in denen sich die verschiedenen Netzwerkschnittstellen befinden.

Wenn in einer Firewall schnittstellenbasierte Zonen erforderlich sind, ermöglicht das folgende Multi-NIC-Design die erforderliche externe Verbindung. Bei diesem Design werden den externen Netzwerken verschiedene Firewall-Schnittstellen zugewiesen. Externe Netzwerke werden von Sicherheitsexperten als nicht vertrauenswürdige Netzwerke bezeichnet, interne Netzwerke als vertrauenswürdige Netzwerke. Für die NVA-Bereitstellung mit mehreren NICs wird dieses Design mit vertrauenswürdigen und nicht vertrauenswürdigen VPCs implementiert.

Für die interne Kommunikation kann die Firewall mit einem Einfügemodell mit einer einzelnen NIC erzwungen werden, das einem CIDR-basierten Zonenmodell entspricht.

In diesem Design fügen Sie NVAs ein, indem Sie Folgendes konfigurieren:

  1. Um HA VPN-Traffic an den internen Load-Balancer weiterzuleiten, wenden Sie nicht getaggte richtlinienbasierte Routen auf die vertrauenswürdige VPC an. Verwenden Sie für diese richtlinienbasierten Routen Quell- und Ziel-CIDR-Bereiche, die für eine Traffic-Symmetrie sorgen.
  2. Um eingehenden Traffic an den internen Passthrough-Network-Load-Balancer weiterzuleiten, wenden Sie richtlinienbasierte Routen auf die Cloud Interconnect-Verbindungen in der nicht vertrauenswürdigen VPC an. Dies sind regionale Routen.
  3. Damit Traffic, der die NVA verlässt, nicht direkt wieder an die NVA weitergeleitet wird, legen Sie alle NVA-Schnittstellen als Ziel einer richtlinienbasierten Route zum Überspringen fest, um andere richtlinienbasierte Routen zu überspringen. Der Traffic folgt dann der VPC-Routingtabelle, nachdem er von den NVAs verarbeitet wurde.
  4. Um Traffic an die internen Load-Balancer der NVA in der vertrauenswürdigen VPC weiterzuleiten, wenden Sie statische Routen auf die Anwendungs-VPCs an. Diese können mit Netzwerktags regional begrenzt werden.

Das folgende Diagramm zeigt NVAs mit mehreren NICs, die zwischen den nicht vertrauenswürdigen und vertrauenswürdigen VPC-Netzwerken im Hub-Projekt eingefügt wurden:

NVAs für die interne Kommunikation

Nächste Schritte

Beitragende

Autoren:

Weitere Beitragende: