Netzwerksicherheit für verteilte Anwendungen im Cross-Cloud Network

Last reviewed 2024-04-05 UTC

Dieses Dokument ist Teil einer Designanleitungsreihe für Cross-Cloud Network. In diesem Teil geht es um die Netzwerksicherheitsschicht.

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). Bei der Arbeitslastsicherheit werden Sicherheitsempfehlungen an Punkten angewendet, 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.

Eine Perimetersicherheit ist an allen Netzwerkgrenzen erforderlich. Da der Perimeter in der Regel Netzwerke verbindet, die von verschiedenen Organisationen verwaltet werden, sind oft strengere Sicherheitskontrollen erforderlich. Sie müssen dafür sorgen, dass die folgenden Netzwerkkommunikationen gesichert sind:

  • Kommunikation über 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 Firewallfunktionen bereitzustellen, die horizontal skalierbar sind und auf jede VM-Instanz angewendet werden. Die verteilte Struktur von Google Cloud-Firewalls hilft Ihnen, Sicherheitsrichtlinien für die Netzwerkmikrosegmentierung zu implementieren, ohne die Leistung Ihrer Arbeitslasten zu beeinträchtigen.

Mit hierarchischen Firewallrichtlinien können Sie die Verwaltungsfreundlichkeit verbessern und die Einhaltung der Sicherheitsanforderungen für Ihre Firewallrichtlinien 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 einer hierarchischen Firewallrichtlinie die Auswertung an Richtlinien auf einer niedrigeren Ebene (globale oder regionale Netzwerk-Firewallrichtlinien) mit der Aktion goto_next 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. Gängige Anwendungsfälle für hierarchische Firewallrichtlinien sind der Zugriff auf Bastion Hosts für Organisationen oder mehrere Projekte, die Zulassung zentralisierter Prüf- oder Systemdiagnosesysteme und die Durchsetzung einer virtuellen Netzwerkgrenze für eine Organisation oder eine 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-verwalteten Tags können Firewallregeln basierend auf der Identität des Arbeitslast-Hosts anstelle der Host-IP-Adresse angewendet werden. Diese Funktion funktioniert auch für VPC-Netzwerk-Peering. Mithilfe von Tags bereitgestellte Firewallregeln können eine Mikrosegmentierung innerhalb eines Subnetzes mit Richtlinienabdeckung bieten, die unabhängig von der Netzwerkarchitektur automatisch auf Arbeitslasten angewendet wird, unabhängig davon, wo sie bereitgestellt werden.

Neben den Funktionen für zustandsabhängige Prüfung und Tag-Unterstützung unterstützt die Cloud Next Generation Firewall auch Threat Intelligence, FQDN- und Geolokalisierungsfilter.

Wir empfehlen Ihnen, von VPC-Firewallregeln zu Firewallrichtlinien zu migrieren. Verwenden Sie das Migrationstool, um die Migration zu unterstützen. Damit wird eine globale Netzwerk-Firewallrichtlinie erstellt und vorhandene VPC-Firewallregeln in die neue Richtlinie umgewandelt.

Perimetersicherheit in der Cloud

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

Da das Cross-Cloud Network als Hub für die gesamte Kommunikation konzipiert ist, können Sie die Sicherheitskontrollen für den Perimeter vereinheitlichen und zentralisieren und eine einzige Gruppe von Perimeter-Firewalls in Ihrem Cross-Cloud Network bereitstellen. Cross-Cloud Network bietet flexible Optionen zum Einfügen von NVAs, um einen integrierten Perimeter-Sicherheitsstack bereitzustellen.

In den in den Diagrammen gezeigten Designs können Sie NVAs von Drittanbietern im 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:

  • Fügen Sie die NVAs mit richtlinienbasierten Routen ein.
  • Vermeiden Sie starre Topologien.
  • Bereitstellung in einer Vielzahl von VPC-zu-VPC-Topologien
  • Aktivieren Sie das Autoscaling für die NVAs.
  • Im Laufe der Zeit auf viele VPCs skalieren, ohne Änderungen an der Bereitstellung der NVA-Schnittstelle

Wenn für Ihr Design mehrere NICs erforderlich sind, finden Sie unter Perimetersicherheit mit mehreren NICs und NVAs entsprechende Empfehlungen.

Für die für die NVA-Bereitstellung erforderliche Traffic-Steuerung wird in diesem Leitfaden die selektive Erzwingung von richtlinienbasierten und statischen Routen in den VPC-Routingtabellen empfohlen. Richtlinienbasierte Routen sind flexibler als Standardrouten, da sie sowohl anhand von Quell- als auch Zielinformationen abgeglichen werden. Diese richtlinienbasierten Routen werden auch nur an bestimmten Stellen in der Cloud-Netzwerktopologie erzwungen. Diese Detaillierung ermöglicht die Definition eines sehr spezifischen Traffic-Steering-Verhaltens für sehr spezifische Konnektivitätsflüsse.

Darüber hinaus ermöglicht dieses Design die Ausfallsicherheitsmechanismen, die von den NVAs benötigt werden. Vor den NVAs befindet sich ein interner TCP/UDP-Load Balancer, um NVA-Redundanz, automatische Skalierung für elastische Kapazität und Flusssymmetrie zur Unterstützung der zustandsorientierten bidirektionalen Trafficverarbeitung zu ermöglichen.

Perimetersicherheit von NVAs mit einer 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 eine Verbindung zwischen den externen Netzwerken und den Spoke-VPCs.

Für die Einfügung einer NVA mit einer einzelnen NIC werden in diesem Design die folgenden beiden Muster kombiniert:

  • NVAs in einen VPC-Netzwerk-Peering-Hub mit externen Hybridverbindungen einfügen
  • NVAs in 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 werden:

NVAs, die an den Hubs für das 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 eine hybride oder Multi-Cloud-Verbindung bereitstellen. Diese VPC enthält auch die NVAs mit einer einzelnen NIC, 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 NVA-Firewalls von Drittanbietern geleitet. Dabei wird die folgende Kombination aus Passthrough-Load Balancing, statischen Routen und richtlinienbasierten Routen verwendet:

  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 Traffic-Symmetrie sorgen.
  2. Um eingehenden Traffic an den internen Passthrough-Network Load Balancer weiterzuleiten, wenden Sie richtlinienbasierte Routen auf die Cloud Interconnect-Verbindungen im Transit-VPC an. Das sind regionale Routen.
  3. Damit Traffic, der die NVA verlässt, nicht direkt zurück zur NVA weitergeleitet wird, müssen alle NVA-Schnittstellen das Ziel einer richtlinienbasierten Route mit Überspringung sein, um andere richtlinienbasierte Routen zu überspringen. Nachdem der Traffic von den NVAs verarbeitet wurde, folgt er der VPC-Routingtabelle.
  4. Wenn Sie den Traffic an die internen Load Balancer der NVA in der Transit-VPC weiterleiten möchten, wenden Sie statische Routen auf die Anwendungs-VPCs an. Sie können mithilfe von Netzwerk-Tags regional begrenzt werden.

Perimetersicherheit mit mehreren NICs für NVAs

Im Multi-NIC-Modus ist die Topologie statisch, da NVAs die Konnektivität zwischen den verschiedenen VPCs herstellen, 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 Konnektivität. Bei diesem Design werden den externen Netzwerken unterschiedliche Firewall-Schnittstellen zugewiesen. Die externen Netzwerke werden von Sicherheitsexperten als nicht vertrauenswürdige Netzwerke bezeichnet und die internen Netzwerke als vertrauenswürdige Netzwerke. Bei der Bereitstellung von NVAs 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ügungsmodell für eine einzelne NIC erzwungen werden, das einem CIDR-basierten Zonenmodell entspricht.

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

  1. Wenn Sie HA VPN-Traffic an den internen Load Balancer weiterleiten möchten, wenden Sie nicht getaggte richtlinienbasierte Routen auf das vertrauenswürdige VPC an. Verwenden Sie für diese Richtlinienbasierten Routen Quell- und Ziel-CIDR-Bereiche, die für Traffic-Symmetrie sorgen.
  2. Wenn Sie eingehenden Traffic an den internen Passthrough-Network Load Balancer weiterleiten möchten, wenden Sie richtlinienbasierte Routen auf die Cloud Interconnect-Verbindungen im nicht vertrauenswürdigen VPC an. Das sind regionale Routen.
  3. Damit Traffic, der die NVA verlässt, nicht direkt zurück zur NVA weitergeleitet wird, müssen alle NVA-Schnittstellen das Ziel einer richtlinienbasierten Route mit Überspringung sein, um andere richtlinienbasierte Routen zu überspringen. Nachdem der Traffic von den NVAs verarbeitet wurde, folgt er der VPC-Routingtabelle.
  4. Wenn Sie den Traffic an die internen Load Balancer der NVA im vertrauenswürdigen VPC weiterleiten möchten, wenden Sie statische Routen auf die Anwendungs-VPCs an. Sie können mithilfe von Netzwerk-Tags 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 werden:

NVAs für die interne Kommunikation

Nächste Schritte

Beitragende

Autoren:

Weitere Beitragende: