Netzwerksicherheit für verteilte Anwendungen im Cross-Cloud Network

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
  • Domain-Perimetersicherheit

Die Arbeitslastsicherheit steuert die Kommunikation zwischen Arbeitslasten innerhalb der Virtual Private Cloud (VPC). Die Arbeitslastsicherheit verwendet Punkte für die Sicherheitsdurchsetzung, die sich in der Nähe der Arbeitslasten in der Architektur befinden. Wann immer möglich, bietet das cloudübergreifende Netzwerk eine Arbeitslastsicherheit mithilfe der Cloud Next Generation Firewall von Google Cloud.

Die Perimetersicherheit ist an allen Netzwerkgrenzen erforderlich. Da der Perimeter normalerweise Netzwerke miteinander verbindet, die von verschiedenen Organisationen verwaltet werden, sind häufig strengere Sicherheitskontrollen erforderlich. Die folgende netzwerkübergreifende Kommunikation muss gesichert sein:

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

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

Arbeitslastsicherheit in der Cloud

Mit Firewallrichtlinien inGoogle Cloud können Sie Arbeitslasten sichern und zustandsorientierte Firewallfunktionen bereitstellen, die horizontal skalierbar sind und auf jede VM-Instanz angewendet werden. Dank des verteilten Charakters von Google Cloud -Firewalls können Sie Sicherheitsrichtlinien für die Mikrosegmentierung von Netzwerken implementieren, ohne die Leistung Ihrer Arbeitslasten zu beeinträchtigen.

Mit hierarchischen Firewallrichtlinien können Sie die Verwaltung verbessern und die Einhaltung des Sicherheitsstatus 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 hierarchische Firewallrichtlinien der Organisation oder einzelnen Ordnern zuweisen. Darüber hinaus können Regeln in hierarchischen Firewallrichtlinien die Auswertung an untergeordnete Richtlinien (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 Organisations- oder Bastion-Hosts für mehrere Projekte, das Ermöglichen zentraler Prüf- oder Systemdiagnosesysteme und das Erzwingen einer virtuellen Netzwerkgrenze für eine Organisation oder eine Gruppe von Projekten. Weitere Beispiele zur Verwendung von hierarchischen Firewallrichtlinien finden Sie unter Beispiele für hierarchische Firewallrichtlinien.

Verwenden Sie globale und regionale Netzwerk-Firewallrichtlinien, um Regeln für ein einzelnes VPC-Netzwerk 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. Von IAM verwaltete Tags ermöglichen das Anwenden von Firewallregeln basierend auf der Identität des Arbeitslasthosts im Gegensatz zu der Host-IP-Adresse und funktionieren über VPC-Netzwerk-Peering. Firewallregeln, die mithilfe von Tags bereitgestellt werden, ermöglichen eine Mikrosegmentierung innerhalb von Subnetzen mit Richtlinienabdeckung, die automatisch auf Arbeitslasten angewendet wird, unabhängig von der Netzwerkarchitektur, unabhängig davon, wo sie bereitgestellt werden.

Zusätzlich zu den zustandsorientierten Inspektionsfunktionen und der Tag-Unterstützung unterstützt die Cloud Next Generation Firewall auch Threat Intelligence, FQDN und die Filterung nach Standortbestimmung.

Wir empfehlen die Migration von VPC-Firewallregeln zu Firewallrichtlinien. Verwenden Sie zur Unterstützung der Migration 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 normalerweise in jedem Netzwerk implementiert. Beispielsweise hat das lokale Netzwerk seine eigenen Perimeter-Firewalls, während jedes Cloud-Netzwerk separate Perimeter-Firewalls implementiert.

Da das cloudübergreifende Netzwerk als Hub für die gesamte Kommunikation konzipiert ist, können Sie die Perimeter-Sicherheitskontrollen vereinheitlichen und zentralisieren und eine einzelne Gruppe von Perimeter-Firewalls in Ihrem cloudübergreifenden Netzwerk bereitstellen. Für einen integrierten Perimetersicherheitsstack Ihrer Wahl bietet Cross-Cloud Network flexible Optionen zum Einfügen von NVAs.

In den in den Diagrammen gezeigten 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:

  • Fügen Sie die NVAs mit richtlinienbasierten Routen ein.
  • Vermeiden Sie starre Topologien.
  • In einer Vielzahl von Inter-VPC-Topologien bereitstellen
  • Autoscaling für NVAs aktivieren
  • Im Laufe der Zeit auf viele VPCs skalieren, ohne dass Änderungen an der Bereitstellung der NVA-Schnittstelle erforderlich sind.

Wenn Ihr Design mehrere NICs erfordert, finden Sie entsprechende Empfehlungen unter Multi-NIC-NVA-Perimetersicherheit.

In diesem Leitfaden wird die selektive Erzwingung von richtlinienbasierten und statischen Routen in den VPC-Routingtabellen empfohlen, um die für die NVA-Bereitstellung erforderliche Trafficsteuerung zu erreichen. Die richtlinienbasierten Routen sind flexibler als Standardrouten, da richtlinienbasierte Routen sowohl mit Quell- als auch Zielinformationen übereinstimmen. Diese richtlinienbasierten Routen werden außerdem nur an bestimmten Orten in der Cloud-Netzwerktopologie erzwungen. Dieser Detaillierungsgrad ermöglicht die Definition eines sehr spezifischen Traffic-Steuerverhaltens für sehr spezifische Verbindungsflüsse.

Darüber hinaus aktiviert dieses Design die von den NVAs erforderlichen Ausfallsicherheitsmechanismen. Im Vorfeld von NVAs befindet sich ein interner TCP/UDP-Load-Balancer, um NVA-Redundanz, Autoscaling für flexible Kapazität und Flusssymmetrie zur Unterstützung der zustandsorientierten bidirektionalen Trafficverarbeitung zu ermöglichen.

Single-NIC-NVA-Perimetersicherheit

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.

Zum Einfügen von NVA mit einer einzelnen NIC werden bei diesem Design die folgenden beiden Muster kombiniert:

  • NVAs in einen VPC-Netzwerk-Peering-Hub mit externen Hybridverbindungen einfügen
  • NVAs in einen HA VPN-VPC-Hub mit externen Hybridverbindungen einfügen

Im folgenden Diagramm sehen Sie, wie NVAs an den Hubs für VPC-Netzwerk-Peering und HA VPN eingefügt werden:

An den Hubs für VPC-Netzwerk-Peering und HA VPN eingefügte NVAs

Das obige Diagramm veranschaulicht ein kombiniertes Muster:

  • Eine Transit-VPC, die die Cloud Interconnect-VLAN-Anhänge hostet, die Hybrid- oder Multi-Cloud-Verbindungen 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 VPC für zentrale Dienste, die über HA VPN mit der Transit-VPC verbunden ist.

In diesem Design verwenden die über HA VPN verbundenen Spokes 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 gesteuert. Dazu wird die folgende Kombination aus Passthrough-Load-Balancing, statischen Routen und richtlinienbasierten Routen verwendet:

  1. Wenden Sie nicht getaggte richtlinienbasierte Routen auf die Transit-VPC an, um HA VPN-Traffic zum internen Load-Balancer zu steuern. Verwenden Sie für diese richtlinienbasierten Routen Quell- und Ziel-CIDR-Bereiche, die für Trafficsymmetrie sorgen.
  2. Wenden Sie richtlinienbasierte Routen auf die Cloud Interconnect-Verbindungen in der Transit-VPC an, um eingehenden Traffic zum internen Passthrough-Network Load Balancer zu steuern. Dies sind regionale Routen.
  3. Damit Traffic, der die NVA verlässt, nicht direkt an die NVA zurückgeleitet wird, legen Sie alle NVA-Schnittstellen als Ziel einer Richtlinie zum Überspringen von Richtlinien fest, um andere richtlinienbasierte Routen zu überspringen. Der Traffic folgt dann der VPC-Routingtabelle, sobald er von den NVAs verarbeitet wurde.
  4. Wenden Sie statische Routen auf die Anwendungs-VPCs an, um den Traffic zu den internen NVA-Load-Balancern in der Transit-VPC zu steuern. Diese können mithilfe von Netzwerk-Tags regional begrenzt werden.

Multi-NIC-NVA-Perimetersicherheit

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

Wenn schnittstellenbasierte Zonen in einer Firewall erforderlich sind, wird die erforderliche externe Konnektivität durch das folgende Design mit mehreren NICs aktiviert. Bei diesem Design werden den externen Netzwerken unterschiedliche Firewallschnittstellen zugewiesen. Die externen Netzwerke werden von Sicherheitsexperten als nicht vertrauenswürdige Netzwerke und die internen Netzwerke als vertrauenswürdige Netzwerke bezeichnet. Für die NVA-Bereitstellung mit mehreren NICs wird dieses Design mithilfe von vertrauenswürdigen und nicht vertrauenswürdigen VPCs implementiert.

Für die interne Kommunikation kann Firewalling mit einem Ein-NIC-Einfügungsmodell, das einem CIDR-basierten Zonenmodell entspricht, erzwungen werden.

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

  1. Wenden Sie nicht getaggte richtlinienbasierte Routen auf die vertrauenswürdige VPC an, um HA VPN-Traffic zum internen Load-Balancer zu steuern. Verwenden Sie für diese richtlinienbasierten Routen Quell- und Ziel-CIDR-Bereiche, die für Trafficsymmetrie sorgen.
  2. Um eingehenden Traffic zum internen Passthrough-Network Load Balancer zu steuern, 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 an die NVA zurückgeleitet wird, legen Sie alle NVA-Schnittstellen als Ziel einer Richtlinie zum Überspringen von Richtlinien fest, um andere richtlinienbasierte Routen zu überspringen. Der Traffic folgt dann der VPC-Routingtabelle, sobald er von den NVAs verarbeitet wurde.
  4. Wenden Sie statische Routen auf die Anwendungs-VPCs an, um den Traffic zu den internen NVA-Load-Balancern in der vertrauenswürdigen VPC zu steuern. Diese 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 wurden:

NVAs für die interne Kommunikation

Nächste Schritte

Beitragende

Autoren:

Weitere Beitragende: