Netzwerksicherheit für verteilte Anwendungen im cloudübergreifenden Netzwerk

Last reviewed 2024-04-05 UTC

Dieses Dokument ist Teil einer Designanleitungsreihe für ein cloudübergreifendes Netzwerk. In diesem Teil wird die Netzwerksicherheitsebene untersucht.

Die Reihe besteht aus folgenden Teilen:

Sicherheitsoberflächen

Beim Entwerfen der Sicherheitsebene für das cloudübergreifende Netzwerk müssen Sie die folgenden Sicherheitsoberflächen berücksichtigen:

  • Arbeitslastsicherheit
  • Sicherheit für Domainperimeter

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

Die Perimetersicherheit ist an allen Netzwerkgrenzen erforderlich. Da der Perimeter in der Regel Netzwerke verbindet, die von verschiedenen Organisationen verwaltet werden, sind häufig strengere Sicherheitskontrollen erforderlich. Achten Sie darauf, dass die folgende Kommunikation über Netzwerke hinweg gesichert ist:

  • 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 die Google Cloud-Umgebung einzufügen, ist entscheidend, um die Anforderungen für die Perimetersicherheit über Hybridverbindungen zu erfüllen.

Arbeitslastsicherheit in der Cloud

Verwenden Sie Firewallrichtlinien in Google Cloud, um Arbeitslasten zu sichern und zustandsorientierte Firewallfunktionen bereitzustellen, die horizontal skalierbar sind und auf jede VM-Instanz angewendet werden. Dank der verteilten Natur von Google Cloud-Firewalls können Sie Sicherheitsrichtlinien für die Netzwerkmikrosegmentierung implementieren, ohne die Leistung Ihrer Arbeitslasten zu beeinträchtigen.

Verwenden Sie hierarchische Firewallrichtlinien, um die Verwaltung zu verbessern und die Compliance des Sicherheitsstatus für Ihre Firewallrichtlinien 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 in hierarchischen Firewallrichtlinien 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 unter anderem der Zugriff auf Bastion Hosts für Organisationen oder mit mehreren Projekten, die Aktivierung von zentralen Prüf- oder Systemdiagnosesystemen und die Erzwingung einer virtuellen Netzwerkgrenze für eine Organisation oder Gruppe von Projekten. Weitere Beispiele zur 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. IAM-gesteuerte Tags ermöglichen das Anwenden von Firewallregeln, die auf der Identität des Arbeitslasthosts anstatt auf der Host-IP-Adresse basieren, und funktionieren über VPC-Netzwerk-Peering. Mithilfe von Tags bereitgestellte Firewallregeln können eine Mikrosegmentierung innerhalb des Subnetzes mit Richtlinienabdeckung bereitstellen, die automatisch auf Arbeitslasten angewendet wird, wo sie bereitgestellt werden, unabhängig von der Netzwerkarchitektur.

Neben zustandsorientierten Inspektionsfunktionen und Tag-Unterstützung unterstützt Cloud Next Generation Firewall auch die Filterung von Threat Intelligence, FQDN und der 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 ist die Perimetersicherheit normalerweise in jedem Netzwerk implementiert. Das lokale Netzwerk hat beispielsweise eigene Perimeter-Firewalls, während jedes Cloud-Netzwerk separate Perimeter-Firewalls implementiert.

Da das cloudübergreifende Netzwerk als Hub für jede Kommunikation konzipiert ist, können Sie die Sicherheitskontrollen für die Perimeter vereinheitlichen und zentralisieren und eine einzige Gruppe von Perimeter-Firewalls in Ihrem cloudübergreifenden Netzwerk 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 Netzwerk-Schnittstellen in mehreren VPCs (Multi-NIC-Modus) bereitgestellt werden. Für ein cloudübergreifendes Netzwerk 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 verschiedenen VPC-Topologien bereitstellen
  • Aktivieren Sie Autoscaling für die NVAs.
  • Sie können im Laufe der Zeit auf viele VPCs skalieren, ohne erforderliche Änderungen an der Bereitstellung der NVA-Schnittstelle vornehmen zu müssen.

Wenn Ihr Design mehrere NICs erfordert, finden Sie die Empfehlungen unter NVA-Perimetersicherheit mit mehreren NICs.

Um die für die NVA-Bereitstellung erforderliche Trafficsteuerung zu erreichen, empfiehlt dieser Leitfaden die selektive Erzwingung richtlinienbasierter und statischer Routen in den VPC-Routingtabellen. Die richtlinienbasierten Routen sind flexibler als Standardrouten, da richtlinienbasierte Routen sowohl mit Quell- als auch mit Zielinformationen übereinstimmen. Diese richtlinienbasierten Routen werden auch nur an bestimmten Stellen in der Cloud-Netzwerktopologie erzwungen. Dank dieser Granularität lässt sich ein sehr spezifisches Verhalten der Trafficsteuerung für sehr spezifische Verbindungsflüsse definieren.

Darüber hinaus ermöglicht dieses Design die Ausfallsicherheitsmechanismen, die von den NVAs erforderlich sind. NVAs werden von einem internen TCP/UDP-Load-Balancer gesteuert, um NVA-Redundanz, Autoscaling für elastische Kapazität und Ablaufsymmetrie zu aktivieren, um eine zustandsorientierte bidirektionale Trafficverarbeitung zu unterstützen.

NVA-Perimetersicherheit mit einer einzigen 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.

Zum Einfügen von NVA-Insert-Anweisungen mit einer einzelnen NIC kombiniert dieses Design die folgenden zwei Muster:

  • NVAs in einen VPC-Netzwerk-Peering-Hub mit externen Hybridverbindungen einfügen
  • NVAs in einen 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 VPC-Netzwerk-Peering und HA VPN eingefügt wurden

Das obige Diagramm veranschaulicht ein kombiniertes Muster:

  • Eine Transit-VPC, die die Cloud Interconnect-VLAN-Anhänge hostet, die Hybrid- oder Multi-Cloud-Verbindungen bieten. 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 durch 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 auf den internen Load-Balancer zu leiten. Verwenden Sie auf diesen richtlinienbasierten Routen Quell- und Ziel-CIDR-Bereiche, die für Trafficsymmetrie sorgen.
  2. Wenn Sie eingehenden Traffic zum internen Passthrough-Network Load Balancer steuern möchten, 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 an die NVA weitergeleitet wird, legen Sie alle NVA-Schnittstellen als Ziel einer richtlinienbasierten Route fest, um andere richtlinienbasierte Routen zu überspringen. Routen. Der Traffic folgt dann der VPC-Routingtabelle, sobald er von den NVAs verarbeitet wurde.
  4. Um den Traffic zu den internen NVA-Load-Balancer in der Transit-VPC zu leiten, wenden Sie statische Routen auf die Anwendungs-VPCs an. Diese können mithilfe von Netzwerk-Tags regional festgelegt werden.

NVA-Perimetersicherheit 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, aktiviert das folgende Multi-NIC-Design die erforderliche externe Konnektivität. 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. Bei der NVA-Bereitstellung mit mehreren NICs wird dieses Design mithilfe von vertrauenswürdigen und nicht vertrauenswürdigen VPCs implementiert.

Für die interne Kommunikation kann die Firewall mithilfe eines Ein-NIC-Einfügungsmodells erzwungen werden, das einem CIDR-basierten Zonenmodell entspricht.

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 auf den internen Load-Balancer zu leiten. Verwenden Sie auf diesen richtlinienbasierten Routen Quell- und Ziel-CIDR-Bereiche, die für Trafficsymmetrie sorgen.
  2. Wenn Sie eingehenden Traffic zum internen Passthrough-Network Load Balancer leiten möchten, 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 weitergeleitet wird, legen Sie alle NVA-Schnittstellen als Ziel einer richtlinienbasierten Route fest, um andere richtlinienbasierte Routen zu überspringen. Routen. Der Traffic folgt dann der VPC-Routingtabelle, sobald er von den NVAs verarbeitet wurde.
  4. Um den Traffic zu den internen NVA-Load-Balancer in der vertrauenswürdigen VPC zu leiten, wenden Sie statische Routen auf die Anwendungs-VPCs an. Diese können mithilfe von Netzwerk-Tags regional festgelegt 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: