Netzwerke für die Migration von Unternehmensarbeitslasten entwerfen: Architekturansätze

Last reviewed 2023-11-13 UTC

Mit diesem Dokument wird eine Reihe begonnen, die Netzwerk- und Sicherheitsarchitekturen für Unternehmen beschreibt, die Rechenzentrumsarbeitslasten zu Google Cloud migrieren. Diese Architekturen konzentrieren sich auf erweiterte Konnektivität, Zero-Trust-Sicherheitsgrundsätze und Verwaltungsmöglichkeiten in einer Hybridumgebung.

Wie im zugehörigen Dokument Architekturen zum Schutz von Cloud-Datenebenen beschrieben wird, stellen Unternehmen eine Vielzahl von Architekturen bereit, die Konnektivitäts- und Sicherheitsanforderungen in der Cloud berücksichtigen. Wir klassifizieren diese Architekturen in drei verschiedene Architekturmuster: Lift-and-Shift, Hybriddienste und verteiltes Zero-Trust. Im aktuellen Dokument werden verschiedene Sicherheitsansätze erläutert, je nachdem, welche Architektur ein Unternehmen ausgewählt hat. Außerdem wird beschrieben, wie diese Ansätze mithilfe der von Google Cloud bereitgestellten Bausteine umgesetzt werden können. Sie sollten diese Sicherheitsleitfäden in Verbindung mit anderen Architekturrichtlinien zu Zuverlässigkeit, Verfügbarkeit, Skalierung, Leistung und Governance verwenden.

Dieses Dokument unterstützt Systemarchitekten, Netzwerkadministratoren und Sicherheitsadministratoren, die lokale Arbeitslasten in die Cloud migrieren möchten. Dabei wird Folgendes vorausgesetzt:

  • Sie sind mit den Netzwerk- und Sicherheitskonzepten des Rechenzentrums vertraut.
  • Sie haben Arbeitslasten in Ihrem lokalen Rechenzentrum und sind mit ihrer Funktion und ihren Nutzern vertraut.
  • Sie haben zumindest einige Arbeitslasten, die Sie migrieren möchten.
  • Sie sind im Allgemeinen mit den Konzepten vertraut, die unter Architekturen zum Schutz von Cloud-Datenebenen beschrieben werden.

Die Reihe besteht aus folgenden Dokumenten:

In diesem Dokument werden die drei primären Architekturmuster zusammengefasst und die Ressourcenbausteine vorgestellt, mit denen Sie Ihre Infrastruktur erstellen können. Abschließend wird beschrieben, wie die Bausteine in einer Reihe von Referenzarchitekturen zusammengesetzt werden, die den Mustern entsprechen. Sie können diese Referenzarchitekturen als Orientierungshilfe für Ihre eigene Architektur verwenden.

In diesem Dokument werden virtuelle Maschinen (VMs) als Beispiele für Arbeitslastressourcen erwähnt. Die Informationen gelten für andere Ressourcen, die VPC-Netzwerke verwenden, z. B. Cloud SQL-Instanzen und Google Kubernetes Engine-Knoten.

Überblick über Architekturmuster

In der Regel konzentrieren sich Netzwerktechniker auf den Aufbau der physischen Netzwerkinfrastruktur und der Sicherheitsinfrastruktur in lokalen Rechenzentren.

Der Weg in die Cloud hat diesen Ansatz geändert, da Cloud-Netzwerkkonstrukte softwarebasiert sind. In der Cloud haben Anwendungsinhaber begrenzte Kontrolle über den zugrunde liegenden Infrastruktur-Stack. Sie benötigen ein Modell mit einem sicheren Perimeter, das ihre Arbeitslasten isoliert.

In dieser Reihe berücksichtigen wir drei gängige Architekturmuster. Diese Muster bauen aufeinander auf und können als Spektrum statt als strikte Auswahlmöglichkeiten betrachtet werden.

Lift-and-Shift-Muster

Im Lift-and-Shift-Architekturmuster migrieren Unternehmensanwendungsinhaber ihre Arbeitslasten in die Cloud, ohne diese Arbeitslasten zu refaktorieren. Netzwerk- und Sicherheitstechniker verwenden Ebene-3- und Ebene-4-Einstellungen, um Schutz durch eine Kombination aus virtuellen Netzwerk-Appliances zu gewährleisten, die lokale physische Geräte und Cloud-Firewallregeln im VPC-Netzwerk nachahmen. Arbeitslastinhaber stellen ihre Dienste in VPC-Netzwerken bereit.

Muster für Hybriddienste

Für Arbeitslasten, die per Lift-and-Shift erstellt werden, muss möglicherweise auf Cloud-Dienste wie BigQuery oder Cloud SQL zugegriffen werden. In der Regel befindet sich der Zugriff auf solche Cloud-Dienste auf Ebene 4 und Ebene 7. In diesem Kontext können Isolation und Sicherheit nicht streng auf Ebene 3 durchgeführt werden. Daher werden das Dienstnetzwerk und VPC Service Controls verwendet, um Konnektivität und Sicherheit basierend auf den Identitäten des Dienstes, auf den zugegriffen wird, und dem Dienst, der den Zugriff anfordert, bereitzustellen. In diesem Modell ist es möglich, umfassende Richtlinien für die Zugriffssteuerung auszudrücken.

Zero-Trust-Muster

In einer Zero-Trust-Architektur erweitern Unternehmensanwendungen die Sicherheitserzwingung über Perimetereinstellungen hinaus. Innerhalb des Perimeters können Arbeitslasten nur dann mit anderen Arbeitslasten kommunizieren, wenn ihre IAM-Identität über eine bestimmte Berechtigung verfügt, die standardmäßig verwehrt wird. In einer verteilten Zero-Trust-Architektur ist das Vertrauen identitätsbasiert und wird für jede Anwendung erzwungen. Arbeitslasten werden als Mikrodienste mit zentral ausgegebenen Identitäten erstellt. Auf diese Weise können Dienste ihre Aufrufer validieren und für jede Anfrage richtlinienbasierte Entscheidungen darüber treffen, ob dieser Zugriff akzeptabel ist. Diese Architektur wird häufig mithilfe von verteilten Proxys (einem Service Mesh) anstelle von zentralisierten Gateways implementiert.

Unternehmen können den Zero-Trust-Zugriff von Nutzern und Geräten auf Unternehmensanwendungen durchsetzen, indem sie Identity-Aware Proxy (IAP) konfigurieren. IAP bietet identitäts- und kontextbasierte Einstellungen für Nutzertraffic aus dem Internet oder Intranet.

Muster kombinieren

Unternehmen, die ihre Geschäftsanwendungen in der Cloud erstellen oder dorthin migrieren, nutzen in der Regel eine Kombination aller drei Architekturmuster.

Google Cloud bietet ein Portfolio von Produkten und Diensten als Bausteine für die Implementierung der Cloud-Datenebene, die den Architekturmustern zugrunde liegt. Diese Bausteine werden später in diesem Dokument erläutert. Die Kombination aus Einstellungen, die in der Cloud-Datenebene bereitgestellt werden, und administrativen Einstellungen zum Verwalten von Cloud-Ressourcen bilden die Grundlage für einen End-to-End-Sicherheitsperimeter. Mit dem Perimeter, der durch diese Kombination erstellt wird, können Sie Ihre Arbeitslasten in der Cloud steuern, bereitstellen und ausführen.

Ressourcenhierarchie und administrative Einstellungen

In diesem Abschnitt wird eine Zusammenfassung der administrativen Einstellungen vorgestellt, die Google Cloud als Ressourcencontainer bereitstellt. Die Einstellungen umfassen Google Cloud-Organisationsressourcen, Ordner und Projekte, mit denen Sie Cloud-Ressourcen gruppieren und hierarchisch organisieren können. Diese hierarchische Organisation bietet Ihnen eine Inhaberstruktur und Ankerpunkte für die Anwendung von Richtlinien und Einstellungen.

Eine Google-Organisationsressource ist der Stammknoten in der Hierarchie und bildet die Basis für das Erstellen von Bereitstellungen in der Cloud. Eine Organisationsressource kann Ordner und Projekte als untergeordnete Elemente haben. Ein Ordner enthält Projekte oder andere Ordner als untergeordnete Elemente. Alle anderen Cloud-Ressourcen sind Projekten untergeordnet.

Sie verwenden Ordner zum Gruppieren von Projekten. Projekte bilden die Grundlage zum Erstellen, Aktivieren und Verwenden aller Google Cloud-Dienste. Mit Projekten können Sie APIs verwalten, die Abrechnung aktivieren, Mitbearbeiter hinzufügen und entfernen und Berechtigungen verwalten.

Mit Identity and Access Management (IAM) von Google können Sie Rollen zuweisen und Zugriffsrichtlinien und Berechtigungen auf allen Ebenen der Ressourcenhierarchie definieren. IAM-Richtlinien werden von Ressourcen übernommen, die niedriger in der Hierarchie sind. Diese Richtlinien können nicht von Ressourceninhabern geändert werden, die sich niedriger in der Hierarchie befinden. In einigen Fällen wird die Identitäts- und Zugriffsverwaltung detaillierter bereitgestellt, z. B. im Bereich von Objekten in einem Namespace oder Cluster wie in Google Kubernetes Engine.

Überlegungen zum Design für Virtual Private Cloud-Netzwerke von Google

Wenn Sie eine Migrationsstrategie für die Cloud entwerfen, müssen Sie eine Strategie für die Verwendung von VPC-Netzwerken in Ihrem Unternehmen entwickeln. Ein VPC-Netzwerk lässt sich als virtuelle Version Ihres herkömmlichen physischen Netzwerks vorstellen. Es ist eine vollständig isolierte, private Netzwerkpartition. Standardmäßig können Arbeitslasten oder Dienste, die in einem VPC-Netzwerk bereitgestellt werden, nicht mit Jobs in einem anderen VPC-Netzwerk kommunizieren. VPC-Netzwerke ermöglichen daher die Isolation von Arbeitslasten, indem sie eine Sicherheitsgrenze bilden.

Da jedes VPC-Netzwerk in der Cloud ein vollständig virtuelles Netzwerk ist, hat jedes einen eigenen privaten IP-Adressbereich. Sie können daher dieselbe IP-Adresse ohne Konflikt in mehreren VPC-Netzwerken verwenden. Eine typische lokale Bereitstellung beansprucht möglicherweise einen großen Teil des privaten RFC 1918-IP-Adressbereichs. Wenn Sie jedoch Arbeitslasten lokal und in VPC-Netzwerken haben, können Sie dieselben Adressbereiche in verschiedenen VPC-Netzwerken wiederverwenden, solange diese Netzwerke nicht direkt verbunden oder durch Peering verbunden sind, sodass der IP-Adressbereich weniger schnell belegt wird.

VPC-Netzwerke sind global

VPC-Netzwerke in Google Cloud sind global. Das heißt, dass die Ressourcen, die in einem Projekt mit einem VPC-Netzwerk bereitgestellt werden, direkt über das private Backbone von Google miteinander kommunizieren können.

Wie Abbildung 1 zeigt, können Sie in Ihrem Projekt ein VPC-Netzwerk haben, das Subnetzwerke in verschiedenen Regionen enthält, die sich über mehrere Zonen erstrecken. Die VMs in jeder Region können über die lokalen VPC-Routen privat miteinander kommunizieren.

Implementierung des globalen Google Cloud-VPC-Netzwerks mit Subnetzwerken, die in verschiedenen Regionen konfiguriert sind.

Abbildung 1. Implementierung des globalen Google Cloud-VPC-Netzwerks mit Subnetzwerken, die in verschiedenen Regionen konfiguriert sind.

Netzwerk mithilfe einer freigegebenen VPC freigeben

Mit einer freigegebenen VPC kann eine Organisationsressource mehrere Projekte mit einem gemeinsamen VPC-Netzwerk verbinden. Dadurch können sie sicher über interne IP-Adressen aus dem freigegebenen Netzwerk miteinander kommunizieren. Netzwerkadministratoren für dieses freigegebene Netzwerk wenden die zentralisierte Steuerung von Netzwerkressourcen an und erzwingen diese.

Wenn Sie eine freigegebene VPC verwenden, legen Sie ein Projekt als Hostprojekt fest und fügen ihm ein oder mehrere Dienstprojekte hinzu. Die VPC-Netzwerke im Hostprojekt werden als freigegebene VPC-Netzwerke bezeichnet. Zulässige Ressourcen aus Dienstprojekten können Subnetze im freigegebenen VPC-Netzwerk verwenden.

Unternehmen verwenden in der Regel freigegebene VPC-Netzwerke, wenn die Netzwerk- und Sicherheitsadministratoren die Verwaltung von Netzwerkressourcen wie Subnetzen und Routen zentralisieren sollen. Gleichzeitig können freigegebene VPC-Netzwerke Anwendungs- und Entwicklungsteams ermöglichen, VM-Instanzen zu erstellen und zu löschen sowie Arbeitslasten in bestimmten Subnetzen mithilfe der Dienstprojekte bereitzustellen.

Umgebungen mithilfe von VPC-Netzwerken isolieren

Die Verwendung von VPC-Netzwerken zur Isolierung von Umgebungen hat eine Reihe von Vorteilen, aber Sie müssen auch einige Nachteile berücksichtigen. In diesem Abschnitt werden diese Kompromisse erläutert und gängige Muster zur Implementierung von Isolation beschrieben.

Gründe für die Isolation von Umgebungen

Da VPC-Netzwerke eine Isolationsdomain darstellen, verwenden viele Unternehmen sie, um Umgebungen oder Geschäftsbereiche in separaten Domains zu halten. Häufige Gründe für das Erstellen einer Isolation auf VPC-Ebene:

  • Ein Unternehmen möchte Kommunikation mit standardmäßiger Ablehnung zwischen einem VPC-Netzwerk und einem anderen einrichten, da diese Netzwerke organisatorisch sehr verschieden sind. Weitere Informationen finden Sie weiter unten in diesem Dokument unter Gängige Muster zur VPC-Netzwerkisolation.
  • Unternehmen müssen aufgrund bereits vorhandener lokaler Umgebungen, Akquisitionen oder Bereitstellungen in anderen Cloud-Umgebungen überlappende IP-Adressbereiche haben.
  • Ein Unternehmen möchte die vollständige administrative Kontrolle eines Netzwerks an einen Teil des Unternehmens delegieren.

Nachteile der Isolation von Umgebungen

Das Erstellen isolierter Umgebungen mit VPC-Netzwerken kann einige Nachteile haben. Wenn Sie mehrere VPC-Netzwerke haben, kann der Aufwand für die Verwaltung der Dienste, die sich über mehrere Netzwerke erstrecken, erhöht werden. In diesem Dokument werden Techniken erläutert, mit denen Sie diese Komplexität bewältigen können.

Gängige Muster zur VPC-Netzwerkisolation

Es gibt einige gängige Muster zum Isolieren von VPC-Netzwerken:

  • Entwicklungs-, Staging- und Produktionsumgebungen isolieren. Mit diesem Muster können Unternehmen ihre Entwicklungs-, Staging- und Produktionsumgebungen vollständig voneinander trennen. Im Prinzip werden bei dieser Struktur mehrere vollständige Kopien von Anwendungen verwaltet, wobei zwischen den Umgebungen ein gradueller Roll-out erfolgt. In diesem Muster werden VPC-Netzwerke als Sicherheitsgrenzen verwendet. Entwickler haben ein hohes Maß an Zugriff auf Entwicklungs-VPC-Netzwerke, um ihre tägliche Arbeit zu erledigen. Wenn die Entwicklung abgeschlossen ist, kann ein technisches Produktionsteam oder ein QA-Team die Änderungen in eine Staging-Umgebung migrieren, in der die Änderungen integriert getestet werden können. Wenn die Änderungen zur Bereitstellung bereit sind, werden sie an eine Produktionsumgebung gesendet.
  • Geschäftsbereiche isolieren. Einige Unternehmen möchten ein hohes Maß an Isolation zwischen Geschäftsbereichen erzwingen, insbesondere in Fällen, in denen Bereiche erworben wurden oder ein hohes Maß an Autonomie und Isolation erfordern. Bei diesem Muster erstellen Unternehmen häufig ein VPC-Netzwerk für jeden Geschäftsbereich und delegieren die Kontrolle über diese VPC an die Administratoren des Geschäftsbereichs. Das Unternehmen verwendet Verfahren, die weiter unten in diesem Dokument beschrieben werden, um Dienste bereitzustellen, die das gesamte Unternehmen umfassen, oder um für Nutzer sichtbare Anwendungen zu hosten, die mehrere Geschäftsbereiche umfassen.

Empfehlung zum Erstellen isolierter Umgebungen

Wir empfehlen, VPC-Netzwerke so zu gestalten, dass sie die umfassendste Domain haben, die mit den Verwaltungs- und Sicherheitsgrenzen Ihres Unternehmens vereinbar ist. Mit Sicherheitseinstellungen wie Firewalls können Sie eine zusätzliche Isolation zwischen Arbeitslasten erreichen, die im selben VPC-Netzwerk ausgeführt werden.

Weitere Informationen zum Entwerfen und Erstellen einer Isolationsstrategie für Ihr Unternehmen finden Sie unter Best Practices und Referenzarchitekturen für das VPC-Design und Netzwerk{/3 im Google Cloud Enterprise Foundations-Blueprint.

Bausteine für Cloud-Netzwerke

In diesem Abschnitt werden die wichtigen Bausteine für Netzwerkverbindungen, Netzwerksicherheit, Dienstnetzwerke und Dienstsicherheit erläutert. Abbildung 2 zeigt, wie diese Bausteine zueinander in Beziehung stehen. Sie können ein oder mehrere Produkte verwenden, die in einer bestimmten Zeile aufgeführt sind.

Bausteine für Konnektivität und Sicherheit in Cloud-Netzwerken.

Abbildung 2. Bausteine für Konnektivität und Sicherheit in Cloud-Netzwerken.

In den folgenden Abschnitten werden die einzelnen Bausteine erläutert und es wird beschrieben, welche Google Cloud-Dienste Sie für jeden dieser Bausteine verwenden können.

Netzwerkverbindung

Der Baustein für Netzwerkverbindungen befindet sich an der Basis der Hierarchie. Er ist für die Verbindung von Google Cloud-Ressourcen mit lokalen Rechenzentren oder anderen Clouds verantwortlich. Je nach Ihren Anforderungen benötigen Sie möglicherweise nur eines dieser Produkte oder Sie nutzen alle für verschiedene Anwendungsfälle.

Cloud VPN

Mit Cloud VPN können Sie Ihre Remote-Niederlassungen oder andere Cloud-Anbieter über eine IPsec-VPN-Verbindung mit VPC-Netzwerken von Google verbinden. Der Traffic zwischen den beiden Netzwerken wird durch ein VPN-Gateway verschlüsselt und wird anschließend von dem anderen VPN-Gateway wieder entschlüsselt, um die Daten bei der Übertragung über das Internet zu schützen.

Mit Cloud VPN können Sie die Konnektivität zwischen Ihrer lokalen Umgebung und Google Cloud aktivieren, ohne die physischen Verbindungen, die für Cloud Interconnect erforderlich sind, bereitstellen zu müssen. Dies wird im nächsten Abschnitt beschrieben. Sie können ein HA-VPN bereitstellen, um eine SLA-Anforderung von bis zu 99,99 % zu erfüllen, wenn Sie die konforme Architektur haben. Sie können die Verwendung von Cloud VPN in Betracht ziehen, wenn Ihre Arbeitslasten keine niedrige Latenz und keine hohe Bandbreite benötigen. Cloud VPN eignet sich beispielsweise gut für nicht geschäftskritische Anwendungsfälle oder für die Erweiterung der Konnektivität zu anderen Cloud-Anbietern.

Cloud Interconnect

Cloud Interconnect bietet für Unternehmen eine dedizierte Verbindung zu Google Cloud, die im Vergleich zur Verwendung von VPN oder eingehendem Traffic aus dem Internet einen höheren Durchsatz und eine zuverlässigere Netzwerkleistung bietet. Dedicated Interconnect stellt eine direkte physische Verbindung vom Google-Netzwerk zu Ihren Routern bereit. Partner Interconnect bietet dedizierte Verbindungen über ein großes Partnernetzwerk, das eine größere Reichweite oder mehr Bandbreitenoptionen bietet als Dedicated Interconnect. Cross-Cloud Interconnect bietet dedizierte direkte Verbindungen von Ihren VPC-Netzwerken zu anderen Cloud-Anbietern. Dedicated Interconnect erfordert, dass Sie eine Verbindung in einer Colocations-Einrichtung herstellen, in der Google eine Präsenz hat, Partner Interconnect erfordert dies jedoch nicht. Mit Cross Cloud Interconnect können Sie Standorte auswählen, die Ihren Anforderungen entsprechen, um die Verbindungen herzustellen. Cloud Interconnect sorgt dafür, dass der Traffic zwischen Ihrem lokalen Netzwerk oder einem anderen Cloud-Netzwerk und Ihrem VPC-Netzwerk nicht das öffentliche Internet durchläuft.

Sie können diese Cloud Interconnect-Verbindungen bereitstellen, um ein SLA mit einer Verfügbarkeit von bis zu 99,99 % zu erfüllen, wenn Sie die entsprechende Architektur bereitstellen. Sie können Cloud Interconnect in Betracht ziehen, um Arbeitslasten zu unterstützen, die eine niedrige Latenz, eine hohe Bandbreite und eine vorhersehbare Leistung erfordern, wobei der gesamte Traffic privat bleibt.

Network Connectivity Center für hybride Verbindungen

Das Network Connectivity Center bietet Site-to-Site-Verbindungen zwischen Ihren lokalen und anderen Cloud-Netzwerken. Dazu wird das Backbonenetzwerk von Google verwendet, um eine zuverlässige Konnektivität zwischen Ihren Standorten zu gewährleisten.

Außerdem können Sie Ihr vorhandenes SD-WAN-Overlay-Netzwerk auf Google Cloud erweitern. Konfigurieren Sie dazu eine VM oder eine Drittanbieters-Router-Appliance als logischen Spoke-Anhang.

Sie können über die Router-Appliance, das VPN oder das Cloud Interconnect-Netzwerk als Spoke-Anhänge auf Ressourcen in den VPC-Netzwerken zugreifen. Sie können Network Connectivity Center verwenden, um die Konnektivität zwischen Ihren lokalen Standorten, Ihren Präsenzen in anderen Clouds und Google Cloud zu konsolidieren und alles in einer einzigen Ansicht zu verwalten.

Network Connectivity Center für VPC-Netzwerke

Mit dem Network Connectivity Center können Sie auch ein Mesh-Netzwerk zwischen vielen VPC-Netzwerken erstellen. Sie können dieses Mesh-Netzwerk über Cloud VPN oder Cloud Interconnect mit lokalen oder anderen Clouds verbinden.

VPC-Netzwerk-Peering

Mit VPC-Netzwerk-Peering können Sie Google VPC-Netzwerke verbinden, sodass Arbeitslasten in verschiedenen VPC-Netzwerken intern kommunizieren können, unabhängig davon, ob sie zum selben Projekt oder zur selben Organisationsressource gehören. Der Traffic verbleibt im Google-Netzwerk und durchläuft nicht das öffentliche Internet.

Für das VPC-Netzwerk-Peering dürfen die Peering-Netzwerke keine überlappenden IP-Adressen haben.

Netzwerksicherheit

Der Baustein für Netzwerksicherheit befindet sich über dem Baustein für Netzwerkverbindungen. Er ist verantwortlich dafür, den Zugriff auf Ressourcen basierend auf den Eigenschaften von IP-Paketen zuzulassen oder zu verweigern.

VPC-Firewallregeln

VPC-Firewallregeln gelten für ein bestimmtes Netzwerk. Mit Firewallregeln können Sie den Traffic zu und von Ihren VM-Instanzen basierend auf einer von Ihnen festgelegten Konfiguration zulassen oder ablehnen. Aktivierte Firewallregeln werden immer erzwungen. Sie schützen Ihre Instanzen unabhängig von ihrer Konfiguration, vom Betriebssystem oder davon, ob die VMs vollständig gebootet wurden.

Jedes VPC-Netzwerk wirkt wie eine verteilte Firewall. Die Firewallregeln werden zwar auf Netzwerkebene definiert, die Verbindungen werden aber pro Instanz zugelassen oder abgelehnt. Die VPC-Firewallregeln werden dabei nicht nur zwischen Ihren Instanzen und anderen Netzwerken angewendet, sondern auch zwischen einzelnen Instanzen innerhalb eines Netzwerks.

Hierarchische Firewallrichtlinien

Mit hierarchischen Firewallrichtlinien können Sie eine konsistente Firewallrichtlinie für Ihr gesamtes Unternehmen erstellen und erzwingen. Diese Richtlinien enthalten Regeln, die Verbindungen explizit ablehnen oder zulassen. Sie können der Organisationsressource hierarchische Firewallrichtlinien als Ganzes oder für einzelne Ordner zuweisen.

Paketspiegelung

Bei der Paketspiegelung wird der Traffic bestimmter Instanzen in Ihrem VPC-Netzwerk geklont und zur Prüfung an Collectors weitergeleitet. Bei der Paketspiegelung werden alle Traffic- und Paketdaten erfasst, einschließlich Nutzlasten und Headern. Sie können die Spiegelung sowohl für eingehenden als auch für ausgehenden Traffic, nur für eingehenden Traffic oder nur für ausgehenden Traffic konfigurieren. Die Spiegelung erfolgt auf den VM-Instanzen, nicht im Netzwerk.

Virtuelle Netzwerk-Appliance

Mit virtuellen Netzwerk-Appliances können Sie auf das virtuelle Netzwerk Sicherheits- und Compliance-Einstellungen anwenden, die den Einstellungen in der lokalen Umgebung entsprechen. Dazu stellen Sie im Google Cloud Marketplace verfügbare VM-Images für VMs bereit, die mehrere Netzwerkschnittstellen haben, die jeweils mit einem anderen VPC-Netzwerk verknüpft sind. So können Sie verschiedene virtuelle Netzwerkfunktionen ausführen.

Typische Anwendungsfälle für virtuelle Appliances:

  • Firewalls der nächsten Generation (NGFWs) NGFWs bestehen aus einem zentralisierten Satz von Firewalls, die als VMs ausgeführt werden, die Features bereitstellen, die nicht in VPC-Firewallregeln verfügbar sind. Zu den typischen Features von NGFW-Produkten gehören DPI (Deep Packet Inspection) und Firewallschutz auf Anwendungsebene. Einige NGFWs bieten auch TLS/SSL-Traffic-Prüfung und andere Netzwerkfunktionen, wie weiter unten in dieser Liste beschrieben.
  • System zur Angriffserkennung (Intrusion Detection System, IDS/IPS): Ein netzwerkbasiertes IDS bietet Einblick in potenziell schädlichen Traffic. IPS-Geräte können ein Einbrechen verhindern, indem dafür gesorgt wird, dass schädlicher Traffic nicht sein Ziel erreicht.
  • Sicheres Web-Gateway (SWG). Mit einem SWG werden Bedrohungen aus dem Internet blockiert. Dazu können Unternehmen Unternehmensrichtlinien auf Traffic anwenden, der zum und vom Internet übertragen wird. Dies erfolgt mithilfe von URL-Filterung, Erkennung von schädlichem Code und Zugriffssteuerung.
  • NAT-Gateway (Network Address Translation): Ein NAT-Gateway übersetzt IP-Adressen und Ports. Mit dieser Übersetzung können beispielsweise überlappende IP-Adressen vermieden werden. Google Cloud bietet Cloud NAT als verwalteten Dienst. Dieser Dienst ist jedoch nur für Traffic zum Internet und nicht für Traffic zu lokalen Netzwerken oder zu anderen VPC-Netzwerken verfügbar.
  • Web Application Firewall (WAF). Eine WAF blockiert schädlichen HTTP(S)-Traffic, der an eine Webanwendung gesendet wird. Google Cloud bietet im Rahmen der Sicherheitsrichtlinien von Google Cloud Armor eine WAF-Funktion. Die genaue Funktionalität unterscheidet sich je nach WAF-Anbieter. Daher ist es wichtig zu bestimmen, was Sie benötigen.

Cloud IDS

Cloud IDS ist ein Einbruchserkennungsdienst, der Bedrohungserkennung bei Einbrüchen, Malware, Spyware und Command-and-Control-Angriffen in Ihrem Netzwerk bietet. Cloud IDS erstellt ein von Google verwaltetes Peering-Netzwerk, das VMs enthält, die gespiegelten Traffic empfangen. Der gespiegelte Traffic wird dann von den Bedrohungsschutztechnologien von Palo Alto Networks überprüft, um eine erweiterte Bedrohungserkennung zu ermöglichen.

Cloud IDS bietet vollständige Transparenz für den Traffic innerhalb des Subnetzes, sodass Sie die VM-zu-VM-Kommunikation überwachen und laterale Ausbreitung erkennen können.

Cloud NAT

Cloud NAT unterstützt vollständig verwaltete, softwaredefinierte Netzwerkadressübersetzung für Anwendungen. Es aktiviert die Quellnetzwerkadressübersetzung (Source NAT oder SNAT) für den Internet-Traffic von VMs, die keine externen IP-Adressen haben.

Firewall Insights

Firewall Insights hilft Ihnen, Ihre Firewallregeln zu verstehen und zu optimieren. Es enthält Daten zur Verwendung Ihrer Firewallregeln, zeigt Konfigurationsfehler auf und identifiziert Regeln, die strikter sein könnten. Außerdem nutzt es maschinelles Lernen, um die zukünftige Nutzung Ihrer Firewallregeln vorherzusagen. So können Sie fundierte Entscheidungen darüber treffen, ob Sie Regeln, die Ihnen zu moderat erscheinen, entfernen oder verschärfen sollten.

Netzwerk-Logging

Sie können mehrere Google Cloud-Produkte verwenden, um den Netzwerktraffic zu protokollieren und zu analysieren.

Durch das Logging der Firewallregeln können Sie deren Auswirkungen im Blick behalten, prüfen und analysieren. Sie können beispielsweise feststellen, ob eine Firewallregel, die Traffic abweisen soll, wie vorgesehen funktioniert. Logging von Firewallregeln ist auch nützlich, wenn Sie ermitteln müssen, wie viele Verbindungen von einer bestimmten Firewallregel betroffen sind.

Sie aktivieren das Logging von Firewallregeln für jede Firewallregel, deren Verbindungen Sie protokollieren möchten. Die Option des Loggings von Firewallregeln kann für jede Firewallregel unabhängig von der Aktion (zulassen oder ablehnen) oder der Richtung (eingehend oder ausgehend) genutzt werden.

VPC Flow Logs erfasst eine Stichprobe von Netzwerkflüssen, die von VM-Instanzen gesendet und empfangen werden, einschließlich Instanzen, die als GKE-Knoten (Google Kubernetes Engine) verwendet werden. Diese Logs können für Netzwerkmonitoring, Forensik, Echtzeit-Sicherheitsanalysen und Kostenoptimierung verwendet werden.

Dienstnetzwerk

Dienstnetzwerkblöcke sind dafür verantwortlich, Suchdienste bereitzustellen, die Dienste darüber informieren, wohin eine Anfrage gehen soll (DNS, Service Directory), sowie dafür, dass Anfragen zum richtigen Ort (Private Service Connect, Cloud Load Balancing) gelangen.

Cloud DNS

Arbeitslasten werden über Domainnamen aufgerufen. Cloud DNS bietet zuverlässige Übersetzung von Domainnamen mit niedriger Latenz in IP-Adressen, die sich irgendwo in der Welt befinden. Cloud DNS bietet sowohl öffentliche Zonen als auch private verwaltete DNS-Zonen. Eine öffentliche Zone ist im öffentlichen Internet sichtbar, eine private Zone hingegen nur in einem oder mehreren von Ihnen festgelegten Virtual Private Cloud-Netzwerken (VPC).

Cloud Load Balancing

Innerhalb von Google Cloud sind Load-Balancer eine wichtige Komponente. Sie leiten Traffic an verschiedene Dienste weiter, um Geschwindigkeit und Effizienz sowie die Sicherheit sowohl für internen als auch für externen Traffic global zu gewährleisten.

Mit unseren Load-Balancern kann der Traffic auch über mehrere Clouds oder Hybridumgebungen weitergeleitet und skaliert werden. Dadurch wird Cloud Load Balancing zur "Vordertür", über die jede Anwendung skaliert werden kann, unabhängig davon, wo sie sich befindet und an wie vielen Stellen sie gehostet wird. Google bietet verschiedene Arten des Load-Balancings: global und regional, extern und intern sowie Ebene 4 und Ebene 7.

Service Directory

Mit Service Directory können Sie Ihr Dienstinventar verwalten und einen einzigen sicheren Ort zum Veröffentlichen, Erkennen und Verbinden von Diensten bereitstellen. Alle Vorgänge werden durch die identitätsbasierte Zugriffssteuerung unterstützt. Sie können damit benannte Dienste und ihre Endpunkte registrieren. Die Registrierung kann entweder manuell oder mithilfe von Einbindungen in Private Service Connect, GKE und Cloud Load Balancing erfolgen. Service Discovery ist mithilfe von expliziten HTTP- und gRPC-APIs sowie mithilfe von Cloud DNS möglich.

Service Meshes: Cloud Service Mesh und Cloud Service Mesh

Sowohl Cloud Service Mesh als auch Cloud Service Mesh wurden entwickelt, um die Ausführung komplexer, verteilter Anwendungen zu vereinfachen. Dazu wird eine Vielzahl von Trafficverwaltungs- und Sicherheitsrichtlinien in Service-Mesh-Architekturen ermöglicht. Die Hauptunterschiede zwischen diesen Produkten befinden sich in den von ihnen unterstützten Umgebungen, in den Istio APIs für sie und in ihren globalen Load-Balancing-Funktionen.

Cloud Service Mesh ist ideal für Kubernetes-basierte regionale und globale Bereitstellungen, sowohl über Google Cloud als auch lokal, die von einem verwalteten Istio-Produkt profitieren.

Cloud Service Mesh ist ideal für Netzwerkanwendungsfälle, bei denen zustands- und lastbewusste Dienste in Google Cloud global bereitgestellt werden. Cloud Service Mesh verwaltet Arbeitslasten entweder mithilfe von Envoy-Proxys, die als Sidecars oder Gateways fungieren, oder mithilfe von proxylosen gRPC-Arbeitslasten.

In der folgenden Tabelle sind die Features von Cloud Service Meshy und Cloud Service Mesh aufgeführt.

Anthos Service Mesh Traffic Director
Art der Bereitstellung Kubernetes VM, Kubernetes
Umgebungen Google Cloud, lokal, Multi-Cloud Google Cloud, lokal, Multi-Cloud
Bereitstellungsbereich Regional und föderiert regional Global
API-Oberfläche Istio Dienstrouting (Kubernetes-Gateway-Modell)
Netzwerkverbindung Envoy-Sidecar Envoy-Sidecar, proxyloses gRPC
Globale Lastverteilung basierend auf dem Backend-Zustand Ja (basierend auf Kubernetes) Ja
Globale Lastverteilung basierend auf der Backend-Last Nein Ja
Verwaltete Identität für Arbeitslast-mTLS (Zero-Trust) Ja Ja (nur GKE)

Google hat genauer erläutert, wie eine verteilte Zero-Trust-Architekturumgebung mit der BeyondProd-Architektur erstellt werden kann. Neben der Authentifizierung und Autorisierung von Netzwerkperimetern und -diensten zeigt BeyondProd, wie vertrauenswürdige Computing-Umgebungen, die Codeherkunft und Bereitstellungs-Roll-outs eine Rolle bei der Gewährleistung einer sicheren verteilten Zero-Trust-Dienstarchitektur spielen. Wenn Sie einen Zero-Trust-Ansatz verfolgen, sollten Sie diese Punkte berücksichtigen, die über das Netzwerk hinausgehen.

Private Service Connect

Private Service Connect erstellt Dienstabstraktionen, indem Arbeitslasten mithilfe eines einzigen Endpunkts über VPC-Netzwerke hinweg zugänglich gemacht werden. So können zwei Netzwerke in einem Client-Server-Modell kommunizieren, das für den Nutzer nur den Dienst statt des gesamten Netzwerks oder der Arbeitslast selbst verfügbar macht. Bei einem dienstorientierten Netzwerkmodell können Netzwerkadministratoren über die Dienste nachdenken, die zwischen Netzwerken bereitgestellt werden, statt über Subnetze oder VPCs. Dadurch können die Dienste in einem Ersteller-Nutzer-Modell genutzt werden, sei es für ein Erstanbieter- oder Drittanbieterdienste (SaaS).

Mit Private Service Connect kann eine Nutzer-VPC eine private IP-Adresse verwenden, um eine Verbindung zu einer Google API oder einem Dienst in einer anderen VPC herzustellen.

Sie können Private Service Connect auf Ihr lokales Netzwerk erweitern, um auf Endpunkte zuzugreifen, die eine Verbindung zu Google APIs oder zu verwalteten Diensten in einem anderen VPC-Netzwerk herstellen. Private Service Connect ermöglicht die Nutzung von Diensten auf Ebene 4 oder Ebene 7.

Bei Ebene 4 muss der Ersteller ein oder mehrere Subnetze erstellen, die für Private Service Connect spezifisch sind. Diese Subnetze werden auch als NAT-Subnetze bezeichnet. Private Service Connect führt Quell-NAT mit einer IP-Adresse aus, die aus einem der Private Service Connect-Subnetze ausgewählt wurde, um die Anfragen an einen Dienstersteller weiterzuleiten. Bei diesem Ansatz können Sie sich überschneidende IP-Adressen zwischen Nutzern und Erstellern verwenden.

Auf Ebene 7 können Sie mithilfe eines internen Application Load Balancers ein Private Service Connect-Backend erstellen. Der interne Application Load Balancer ermöglicht Ihnen, mithilfe einer URL-Zuordnung auszuwählen, welche Dienste verfügbar sind. Weitere Informationen finden Sie unter Private Service Connect-Back-Ends.

Zugriff auf private Dienste

Zugriff auf private Dienste bietet eine private Verbindung zwischen Ihrem VPC-Netzwerk und einem Netzwerk von Google oder einem Drittanbieter. Google oder die Drittanbieter, die Dienste anbieten, werden als Dienstersteller bezeichnet. Der Zugriff auf private Dienste verwendet VPC-Netzwerk-Peering, um die Verbindung herzustellen. Außerdem müssen die VPC-Netzwerke der Ersteller und Nutzer per Peering miteinander verbunden sein. Dies unterscheidet sich von Private Service Connect, bei dem Sie eine einzelne private IP-Adresse in Ihr Subnetz projizieren können.

Die private Verbindung ermöglicht VM-Instanzen in Ihrem VPC-Netzwerk und den Diensten, auf die Sie zugreifen, ausschließlich über interne IP-Adressen zu kommunizieren. VM-Instanzen erfordern keinen Internetzugang und keine externen IP-Adressen, um Dienste zu erreichen, die über den Zugriff auf private Dienste verfügbar sind. Der Zugriff auf private Dienste kann auch mithilfe von Cloud VPN oder Cloud Interconnect auf das lokale Netzwerk erweitert werden, um den lokalen Hosts zu ermöglichen, das Netzwerk des Diensterstellers zu erreichen. Eine Liste der von Google verwalteten Dienste, die beim Zugriff auf private Dienste unterstützt werden, finden Sie in der Virtual Private Cloud-Dokumentation unter Unterstützte Dienste.

Serverloser VPC-Zugriff

Über den serverlosen VPC-Zugriff können Sie mit Diensten, die von serverlosen Umgebungen wie Cloud Run, App Engine oder Cloud Functions gehostet werden, eine direkte Verbindung zu Ihrem VPC-Netzwerk herstellen. Wenn Sie den serverlosen VPC-Zugriff konfigurieren, kann Ihre serverlose Umgebung über interne DNS- und interne IP-Adressen Anfragen an Ihr VPC-Netzwerk senden. Die Antworten auf diese Anfragen verwenden auch Ihr virtuelles Netzwerk.

Der serverlose VPC-Zugriff sendet nur dann internen Traffic von Ihrem VPC-Netzwerk an Ihre serverlose Umgebung, wenn der Traffic eine Antwort auf eine Anfrage ist, die von Ihrer serverlosen Umgebung über den Connector für serverlosen VPC-Zugriff gesendet wurde.

Der serverlose VPC-Zugriff bietet folgende Vorteile:

  • An Ihr VPC-Netzwerk gesendete Anfragen sind niemals über das Internet zugänglich.
  • Die Kommunikation über serverlosen VPC-Zugriff kann im Vergleich zur Kommunikation über das Internet eine geringere Latenz haben.

Dienstsicherheit

Die Dienstsicherheitsblöcke steuern den Zugriff auf Ressourcen basierend auf der Identität des Anfragestellers oder basierend auf dem übergeordneten Verständnis von Paketmustern statt nur anhand der Eigenschaften eines einzelnen Pakets.

Google Cloud Armor für DDoS/WAF

Google Cloud Armor ist eine Web-Application Firewall (WAF) und ein DDoS-Abwehrdienst (Distributed Denial of Service), mit dem Sie Ihre Webanwendungen und Dienste vor unterschiedlichen Arten von Bedrohungen schützen können. Dazu gehören DDoS-Angriffe, webbasierte Angriffe wie Cross-Site-Scripting (XSS) und SQL-Injection (SQLi) sowie Betrugsversuche und automatisierte Angriffe.

Google Cloud Armor prüft eingehende Anfragen am globalen Edge von Google. Es verfügt über einen integrierten Satz von WAF-Regeln, die nach gängigen Webangriffen suchen, sowie ein erweitertes ML-basiertes Angriffserkennungssystem, das ein Modell für guten Traffic erstellt und dann schlechten Traffic erkennt. Schließlich kann Google Cloud Armor in Google reCAPTCHA eingebunden werden, um ausgeklügelte Betrugsversuche und automatisierte Angriffe mithilfe von Endpunkt- und Cloud-Telemetrie zu erkennen und zu stoppen.

Identity-Aware Proxy (IAP)

Identity-Aware Proxy (IAP) bietet kontextsensitive Zugriffssteuerungen für cloudbasierte Anwendungen und VMs, die in Google Cloud ausgeführt werden oder die mit Google Cloud verbunden sind, und zwar mithilfe einer der Hybridnetzwerktechnologien. IAP prüft die Nutzeridentität und bestimmt anhand verschiedener Kontextattribute, ob die Nutzeranfrage von vertrauenswürdigen Quellen stammt. IAP unterstützt auch TCP-Tunneling für den SSH/RDP-Zugriff von Unternehmensnutzern.

VPC Service Controls

Mit VPC Service Controls können Sie das Risiko der Daten-Exfiltration aus Google Cloud-Diensten wie Cloud Storage und BigQuery verringern. Mithilfe von VPC Service Controls wird gewährleistet, dass Ihre Google Cloud-Dienste nur aus genehmigten Umgebungen genutzt werden.

Mit VPC Service Controls können Sie Perimeter erstellen, die die Ressourcen und Daten von Diensten schützen, die Sie angeben. Dazu beschränken Sie den Zugriff auf bestimmte cloudnative Identitätskonstrukte wie Dienstkonten und VPC-Netzwerke. Nachdem ein Perimeter erstellt wurde, wird der Zugriff auf die angegebenen Google-Dienste verweigert, sofern die Anfrage nicht aus dem Perimeter stammt.

Inhaltsübermittlung

Die Inhaltsübermittlungsblöcke steuern die Optimierung der Bereitstellung von Anwendungen und Inhalten.

Cloud CDN

Cloud CDN bietet statische Inhaltsbeschleunigung, da das globale Edge-Netzwerk von Google verwendet wird, um Inhalte an einem Punkt bereitzustellen, der dem Nutzer am nächsten ist. Dadurch wird die Latenz für Ihre Websites und Anwendungen reduziert.

Media CDN

Media CDN ist die Medienbereitstellungslösung von Google und wurde für Arbeitslasten mit hohem Durchsatz und ausgehendem Traffic entwickelt.

Beobachtbarkeit

Die Beobachtbarkeitsblöcke bieten Ihnen Einblicke in Ihr Netzwerk und in die Fehlerbehebung, Dokumentierung, Untersuchung von Problemen.

Network Intelligence Center

Das Network Intelligence Center besteht aus mehreren Produkten, die verschiedene Aspekte der Beobachtbarkeit des Netzwerks abdecken. Jedes Produkt hat einen anderen Fokus und bietet umfangreiche Informationen, um Administratoren, Architekten und Fachkräfte über den Netzwerkzustand und Probleme zu informieren.

Referenzarchitekturen

In den folgenden Dokumenten werden Referenzarchitekturen für verschiedene Arten von Arbeitslasten vorgestellt: Intra-Cloud, für das Internet sichtbar und Hybrid. Diese Arbeitslastarchitekturen basieren auf einer Cloud-Datenebene, die mithilfe der Bausteine und Architekturmuster realisiert wird, die in früheren Abschnitten dieses Dokuments beschrieben wurden.

Mithilfe der Referenzarchitekturen können Sie Möglichkeiten zum Migrieren oder Erstellen von Arbeitslasten in die Cloud entwerfen. Ihre Arbeitslasten werden dann von der Cloud-Datenebene unterstützt und verwenden die Architekturen. Die Dokumente enthalten keinen vollständigen Satz von Referenzarchitekturen, decken aber die gängigsten Szenarien ab.

Wie bei den Sicherheitsarchitekturmustern, die unter Architekturen zum Schutz von Cloud-Datenebenen beschrieben werden, können reale Dienste eine Kombination dieser Designs verwenden. In diesen Dokumenten werden die einzelnen Arbeitslasttypen und Überlegungen zu jeder Sicherheitsarchitektur erläutert.

Nächste Schritte