Best Practices und Referenzarchitekturen für das VPC-Design

In dieser Anleitung werden Best Practices und typische Unternehmensarchitekturen für das Design von Virtual Private Clouds (VPCs) mit Google Cloud vorgestellt. Diese Anleitung richtet sich an Cloudnetzwerk- und Systemarchitekten, die bereits mit Google Cloud-Netzwerkkonzepten vertraut sind.

Allgemeine Grundsätze und erste Schritte

Entscheidungsträger, Zeitpläne und Vorarbeiten ermitteln

Als ersten Schritt bei der Gestaltung Ihres VPC-Netzwerks sollten Sie die Entscheidungsträger, Zeitpläne und Vorarbeiten ermitteln, um sicherzustellen, dass Sie die Anforderungen der Beteiligten erfüllen können.

Zu den Interessengruppen zählen möglicherweise Anwendungsinhaber, Sicherheitsarchitekten, Lösungsarchitekten und Betriebsleiter. Abhängig davon, ob Sie das VPC-Netzwerk für ein Projekt, einen Geschäftsbereich oder die gesamte Organisation planen, können die Beteiligten variieren.

Zu den Vorarbeiten zählt unter anderem, das Team mit Konzepten und Begriffen rund um das VPC-Netzwerkdesign vertraut zu machen. Nützliche Dokumentationen:

• Dokumentation zu Resource Manager
• Dokumentation zu Cloud Identity and Access Management
• Virtual Private Cloud-Dokumentation

Frühzeitig VPC-Netzwerkdesign in Betracht ziehen

Planen Sie das VPC-Netzwerkdesign bereits früh während des Entwurfs der organisatorischen Einrichtung. Es kann Ihre Organisation beeinträchtigen, wenn Sie später grundlegende Dinge ändern müssen, z. B. die Segmentierung Ihres Netzwerks oder den Standort Ihrer Arbeitslasten.

VPC-Netzwerkkonfigurationen können erhebliche Auswirkungen auf das Routing, die Skalierung und die Sicherheit haben. Eine sorgfältige Planung und ein eingehendes Verständnis Ihrer jeweiligen Ziele erleichtern es, eine solide architektonische Grundlage für inkrementelle Arbeitslasten zu schaffen.

Weniger ist oft mehr

Halten Sie das Design der VPC-Netzwerktopologie einfach, um eine möglichst gut verwaltbare, zuverlässige und einfach verständliche Architektur zu gewährleisten.

Klare Namenskonventionen verwenden

Achten Sie auf einfache, intuitive und konsistente Namenskonventionen. Wichtig ist, dass die Administratoren und Endnutzer den Zweck jeder Ressource verstehen und wissen, wo sie diese finden und wie sie sich von anderen Ressourcen unterscheidet.

Verwenden Sie für lange Wörter gängige Abkürzungen. Vertraute Begriffe verbessern außerdem die Lesbarkeit.

Erwägen Sie beim Festlegen Ihrer Namenskonventionen die nachfolgend aufgeführten Komponenten:

• Name des Unternehmens: Acme Unternehmen: acmeco
• Geschäftseinheit: Personalabteilung: hr
• Anwendungscode: Vergütungssystem: comp
• Regionscode: nordamerica-northeast1: na-ne1, europe-west1: eu-we1
• Umgebungscodes: dev, test, uat, stage, prod

In diesem Beispiel heißt die Entwicklungsumgebung für das Vergütungssystem der Personalabteilung acmeco-hr-comp-eu-we1-dev.

Berücksichtigen Sie für andere gängige Netzwerkressourcen die folgenden Muster:

• Syntax für VPC-Netzwerk
  : {company name}-{description(App or BU)-label}-{environment-label}-{seq#}
  Beispiel: acmeco-hr-dev-vpc-1

• Subnetz
  Syntax: {company-name}-{description(App or BU)-label}-{region-label}-{environment-label}-{subnet-label}
  Beispiel: acmeco-hr-na-ne1-dev-vpc-1-subnet-1
  Hinweis: Wenn das Subnetz nur Ressourcen in einer Zone enthält, können Sie anstelle von „region-label“ auch „zone-label“ verwenden.

• Syntax der Firewallregel
  : {company-name}-{description(App or BU)-label}{source-label}-{dest-label}-{protocol}-{port}-{action}
  Beispiel: acmeco-hr-internet-internal-tcp-80-allow-rule

• Syntax der IP-Route
  : {priority}-{VPC-label}-{tag}-{next hop}
  Beispiel: 1000-acmeco-hr-dev-vpc-1-int-gw

Adressen und Subnetze

VPC-Netzwerke im benutzerdefinierten Modus verwenden

Für den Start Ihres ersten Projekts beginnen Sie mit dem Standardnetzwerk, einem VPC-Netzwerk im automatischen Modus namens default. Netzwerke im automatischen Modus erstellen automatisch Subnetze und entsprechende Subnetzrouten. Deren primäre IP-Bereiche sind /20-CIDRs in jeder Google Cloud-Region, bei Verwendung eines vorhersagbaren Satzes von RFC 1918-Adressbereichen. Das Netzwerk default enthält außerdem einige automatisch vorkonfigurierte Firewallregeln.

Während VPC-Netzwerke im automatischen Modus für eine erste Erkundung hilfreich sein können, sind für die meisten Produktionsumgebungen VPC-Netzwerke im benutzerdefinierten Modus besser geeignet.

Wir empfehlen Unternehmen aus folgenden Gründen, von Beginn an VPC-Netzwerke im benutzerdefinierten Modus zu verwenden:

• VPC-Netzwerke lassen sich im benutzerdefinierten Modus einfacher in vorhandene IP-Adressverwaltungsschemas einbinden. Da alle Netzwerke im automatischen Modus die gleichen internen IP-Bereiche verwenden, können sich die IP-Bereiche im automatischen Modus überschneiden, wenn die Netzwerke mit Ihren lokalen Unternehmensnetzwerken verbunden werden.
• Zwei VPC-Netzwerke im automatischen Modus lassen sich nicht mit VPC-Netzwerk-Peering miteinander verbinden, da ihre Subnetze identische primäre IP-Bereiche nutzen.
• Subnetze im automatischen Modus haben alle den gleichen Namen wie das Netzwerk. Sie können für Subnetze im benutzerdefinierten Modus eindeutige, beschreibende Namen verwenden, um die VPC-Netzwerke leichter verständlich und verwaltbar zu machen.
• Wenn eine neue Google Cloud-Region eingeführt wird, erhalten VPC-Netzwerke im automatischen Modus automatisch ein neues Subnetz in dieser Region. VPC-Netzwerke im benutzerdefinierten Modus erhalten nur dann neue Subnetze, wenn Sie sie angeben. Dies kann sowohl aus Gründen der Souveränität als auch von IP-Adressverwaltung wichtig sein.

Wenn keine Ressourcen vorhanden sind, können Sie das default-Netzwerk löschen. Sie können ein VPC-Netzwerk erst löschen, wenn zuvor alle davon abhängigen Ressourcen, einschließlich VM-Instanzen, entfernt wurden.

Ausführliche Informationen zu den Unterschieden zwischen VPC-Netzwerken im automatischen und benutzerdefinierten Modus finden Sie im Überblick zum VPC-Netzwerk.

Anwendungen in weniger Subnetzen mit größeren Adressbereichen gruppieren

Unternehmensnetzwerke sind mitunter aus verschiedenen Gründen in viele kleine Adressbereiche unterteilt. Dies kann beispielsweise der Fall sein, wenn eine Anwendung identifiziert oder isoliert oder die Broadcast-Domain klein gehalten werden soll.

Es wird jedoch empfohlen, Anwendungen desselben Typs in den Regionen, in denen Sie arbeiten möchten, in weniger, leichter verwaltbare Subnetze mit größeren Adressbereichen zu gruppieren.

Im Gegensatz zu anderen Netzwerkumgebungen, in denen eine Subnetzmaske verwendet wird, ermöglicht Google Cloud dank eines softwarebasierten Netzwerks (SDN) die uneingeschränkte Erreichbarkeit zwischen allen VMs im globalen VPC-Netzwerk. Die Anzahl der Subnetze hat keinen Einfluss auf das Routingverhalten.

Sie können mithilfe von Dienstkonten oder Netzwerktags spezielle Routingrichtlinien oder Firewallregeln anwenden. Die Identität in Google Cloud beruht nicht ausschließlich auf der IP-Adresse des Subnetzes.

Bestimmte VPC-Features wie Cloud NAT, Privater Google-Zugriff, VPC-Flusslogs und Alias-IP-Bereiche werden pro Subnetz konfiguriert. Wenn Sie diese Features präziser steuern möchten, verwenden Sie zusätzliche Subnetze.

Einzelnes VPC-Netzwerk und freigegebene VPC

Für Ressourcen mit gängigen Anforderungen mit einem einzelnen VPC-Netzwerk beginnen

In vielen einfachen Anwendungsfällen reichen die Features eines einzelnen VPC-Netzwerks aus. Sie sind im Vergleich zu den komplexeren Alternativen leichter erstellbar, verwaltbar und verständlich. Wenn Sie Ressourcen mit gemeinsamen Anforderungen und Merkmalen in einem VPC -Netzwerk gruppieren, können Sie mögliche Probleme auf die jeweilige VPC eingrenzen.

Ein Beispiel für diese Konfiguration finden Sie in der Referenzarchitektur unter Ein Projekt, ein VPC-Netzwerk.

Zu den Faktoren, die Sie zum Erstellen zusätzlicher VPC-Netzwerke führen können, gehören Skalierung, Netzwerksicherheit, finanzielle Überlegungen, Betriebsanforderungen sowie Identitäts- und Zugriffsverwaltung (IAM).

Zur Verwaltung mehrerer Arbeitsgruppen eine freigegebene VPC verwenden

Freigegebene VPCs ermöglichen es Organisationen mit mehreren Teams, die architektonische Einfachheit eines einzelnen VPC-Netzwerks effektiv auf mehrere Arbeitsgruppen auszudehnen. Im einfachsten Szenario stellen Sie ein freigegebenes VPC-Hostprojekt mit einem einzelnen freigegebenen VPC-Netzwerk bereit. Anschließend hängen Sie Teamdienstprojekte an das Hostprojektnetzwerk an.

In dieser Konfiguration sind die Netzwerkrichtlinie und -steuerung für alle Netzwerkressourcen zentralisiert und einfach verwaltbar. Die für die Dienstprojekte zuständigen Teams können Ressourcen konfigurieren und verwalten, die keine Netzwerkressourcen sind. Dadurch lassen sich die Verantwortlichkeiten der verschiedenen Teams der Organisation klar trennen.

Die Ressourcen dieser Projekte können mithilfe interner IP-Adressen sicher und effizient über Projektgrenzen hinweg miteinander kommunizieren. Freigegebene Netzwerkressourcen wie Subnetze, Routen und Firewalls lassen sich von einem zentralen Hostprojekt aus verwalten, um konsistente Netzwerkrichtlinien für alle Projekte zu erzwingen.

Als Beispiel für diese Konfiguration dient die unter Ein Hostprojekt, mehrere Dienstprojekte, eine freigegebene VPC erläuterte Referenzarchitektur.

Rolle "Netzwerknutzer" auf Subnetzebene zuweisen

Der Administrator der zentralen freigegebenen VPC kann IAM-Mitgliedern die Rolle des Netzwerknutzers (networkUser) entweder für eine spezifische Dienstprojektautorisierung auf der Subnetzebene oder für alle Subnetze auf der Hostprojektebene zuweisen.

Gemäß dem Prinzip der geringsten Berechtigungen wird empfohlen, die Netzwerknutzerrolle den erforderlichen Nutzern, Dienstkonten oder Gruppen auf der Subnetzebene zuzuweisen.

Da Subnetze regional sind, können Sie mit dieser detaillierten Steuerung angeben, welche Regionen jedes Dienstprojekt verwenden darf.

Die Architektur freigegebener VPCs bietet Ihnen außerdem die Flexibilität, mehrere freigegebene VPC-Hostprojekte in Ihrer Organisation bereitzustellen. Jedes freigegebene VPC-Hostprojekt kann dann ein oder mehrere freigegebene VPC-Netzwerke aufnehmen. In dieser Konfiguration können in unterschiedlichen Umgebungen leicht unterschiedliche Richtlinien erzwungen werden.

Weitere Informationen finden Sie unter IAM-Rollen für netzwerkbezogene Jobfunktionen.

Nur ein Hostprojekt verwenden, wenn Ressourcen mehrere Netzwerkschnittstellen erfordern

Wenn im Rahmen eines Dienstprojekts Ressourcen für mehrere isolierte VPC-Netzwerke bereitzustellen sind, muss das Hostprojekt alle VPC-Netzwerke enthalten, in denen die Dienste bereitgestellt werden. Dies ist beispielsweise bei VM-Instanzen mit mehreren Netzwerkschnittstellen der Fall. Der Grund dafür ist, dass pro Hostprojekt nur ein Dienstprojekt angehängt werden darf.

Mehrere Hostprojekte verwenden, wenn Ressourcenanforderungen das Kontingent eines einzelnen Projekts überschreiten

Wenn die aggregierten Ressourcenanforderungen aller VPC-Netzwerke nicht innerhalb des Kontingents eines Projekts erfüllt werden können, ist eine Architektur mit mehreren Hostprojekten mit einem freigegebenen VPC-Netzwerk pro Hostprojekt gegenüber einem einzelnen Hostprojekt mit mehreren freigegebenen VPC-Netzwerken vorzuziehen. Dabei ist wichtig, die Skalierungsanforderungen zu bewerten, da für eine solche Architektur mehrere VPC-Netzwerke im Hostprojekt erforderlich sind und Kontingente auf Projektebene erzwungen werden.

Ein Beispiel für diese Konfiguration finden Sie in der Referenzarchitektur unter Mehrere Hostprojekte, mehrere Dienstprojekte und mehrere freigegebene VPCs.

Mehrere Hostprojekte verwenden, wenn Sie separate Verwaltungsrichtlinien für jedes VPC-Netzwerk benötigen

Da Projekte jeweils ein eigenes Kontingent haben, empfiehlt sich zum Aggregieren der Ressourcen, für jedes VPC-Netzwerk ein separates, freigegebenes VPC-Hostprojekt zu verwenden. Auf diese Weise erhält jedes VPC-Netzwerk separate IAM-Berechtigungen für die Netzwerk- und Sicherheitsverwaltung, da IAM-Berechtigungen ebenfalls auf Projektebene implementiert werden. Wenn Sie beispielsweise zwei VPC-Netzwerke (VPC-Netzwerk A und VPC-Netzwerk B) in demselben Hostprojekt bereitstellen, gilt die Netzwerkadministratorrolle (networkAdmin) für beide VPC-Netzwerke.

Entscheiden, ob mehrere VPC-Netzwerke erstellt werden sollen

Einzelnes VPC-Netzwerk pro Projekt erstellen, um VPC-Ressourcenkontingente zu Projekten zuzuordnen

Kontingente sind auf Projekt- oder Netzwerkebene angewendete Einschränkungen. Alle Ressourcen haben ein anfängliches Standardkontingent, das Sie vor einer unerwarteten Ressourcennutzung schützen soll. Es gibt jedoch zahlreiche Gründe, warum Ihr Kontingent erhöht werden sollte. Für die meisten Ressourcen können Sie zusätzliche Kontingente anfordern.

Wenn Sie die standardmäßigen VPC-Ressourcenkontingente voraussichtlich überschreiten werden, empfiehlt es sich, jeweils nur ein VPC-Netzwerk pro Projekt zu erstellen. So ist es einfacher, Kontingenterhöhungen auf Projektebene den jeweiligen VPC-Netzwerken zuzuordnen, als wenn Sie mehrere VPC-Netzwerke innerhalb eines Projekts haben.

Limits schützen Systemressourcen insgesamt. Limits lassen sich im Allgemeinen nicht einfach erhöhen. Das Support- oder Vertriebsteam von Google Cloud kann auf Anfrage aber unter Umständen trotzdem bestimmte Limits erhöhen, falls die Situation dies erfordert.

Die aktuellen Kontingente und Limits für VPC-Ressourcen finden Sie hier.

Das Google-Supportteam kann bestimmte Skalierungslimits erhöhen. Mitunter müssen Sie jedoch mehrere VPCs erstellen, um Ihre Skalierungsanforderungen zu erfüllen. Wenn Ihr VPC-Netzwerk über die Grenzen hinaus skaliert werden muss, besprechen Sie Ihren Fall mit den Vertriebs- und Supportteams von Google Cloud, um den besten Ansatz für Ihre Anforderungen zu finden.

VPC-Netzwerk für jedes autonome Team mit freigegebenen Diensten in einem gemeinsamen VPC-Netzwerk erstellen

Bei einigen großen Unternehmens-Deployments sind autonome Teams involviert, die jeweils die vollständige Kontrolle über ihre VPC-Netzwerke benötigen. Damit Sie diese Anforderung erfüllen, erstellen Sie für jede Geschäftseinheit eine VPC mit freigegebenen Diensten in einer gemeinsamen VPC (z. B. Analysetools, CI/CD-Pipeline, Build-Maschinen, DNS-/Verzeichnisdienste). Weitere Informationen zum Erstellen eines gemeinsamen VPC-Netzwerks für freigegebene Dienste finden Sie im Abschnitt für freigegebene Dienste.

VPC-Netzwerke in unterschiedlichen Projekten für unabhängige IAM-Steuerelemente erstellen

Ein VPC-Netzwerk ist eine Ressource auf Projektebene mit detaillierten IAM-Steuerelementen (Identity and Access Management) auf Projektebene, einschließlich der folgenden Rollen:

• networkAdmin
• securityAdmin
• networkUser
• networkViewer

Standardmäßig werden IAM-Steuerelemente auf Projektebene bereitgestellt und jede IAM-Rolle gilt für alle VPCs innerhalb des Projekts.

Wenn Sie unabhängige IAM-Steuerelemente pro VPC-Netzwerk benötigen, erstellen Sie Ihre VPC-Netzwerke in verschiedenen Projekten.

Wenn Sie IAM-Rollen für Compute Engine-Ressourcen wie VM-Instanzen, Laufwerke und Images benötigen, verwenden Sie IAM-Richtlinien für Compute Engine-Ressourcen.

Sensible Daten im jeweiligen VPC-Netzwerk isolieren

Für Unternehmen, die mit Complianceinitiativen, sensiblen oder streng regulierten Daten zu tun haben, die Compliancestandards wie HIPAA oder PCI-DSS unterliegen, sind häufig weitere Sicherheitsmaßnahmen sinnvoll. Eine Methode zur Verbesserung der Sicherheit und zum leichteren Nachweis der Compliance besteht darin, jede der Umgebungen in einem eigenen VPC-Netzwerk zu isolieren.

Mehrere VPC-Netzwerke verbinden

VPC-Verbindungsmethode entsprechend Ihrem Budget sowie Ihren Leistungs- und Sicherheitsanforderungen auswählen

Der nächste Schritt nach der Entscheidung, mehrere VPC-Netzwerke zu implementieren, besteht darin, diese VPC-Netzwerke zu verbinden. VPC-Netzwerke sind isolierte Mandantenbereiche innerhalb des Andromeda-SDN von Google, aber es gibt mehrere Möglichkeiten, die Kommunikation zwischen ihnen zu ermöglichen. In den folgenden Abschnitten finden Sie Best Practices zur Auswahl der geeigneten VPC-Verbindungsmethode.

Die jeweiligen Vor- und Nachteile sind unten in der Tabelle zusammengefasst. In den weiteren Abschnitten folgen die Best Practices für die Auswahl einer VPC-Verbindungsmethode.

	Vorteile	Nachteile
VPC-Netzwerk-Peering	Einfach zu konfigurieren. Geringer Verwaltungsaufwand. Hohe Bandbreite. Niedrige Gebühren für ausgehenden Traffic (wie bei einem einzelnen VPC-Netzwerk). Jedes VPC-Netzwerk hat eine eigene verteilte Firewall. Jedes VPC-Netzwerk hat eigene IAM-Konten und -Berechtigungen.	Nicht transitiv. Skalierungszahlen sind an die aggregierte Gruppe von Peering-VPC-Netzwerken gebunden. Dazu gehören die Anzahl der VMs, Routen und internen Weiterleitungsregeln. Erfordert einen sich nicht überschneidenden Adressbereich. Statische und dynamische Routen werden nicht weitergegeben. Quelltags und Quelldienstkonten der sendenden VM werden nicht über das VPC-Netzwerk-Peering weitergegeben.
Externes Routing (öffentliche IP oder NAT-Gateway)	Keine Konfiguration erforderlich. Vollständige Isolierung zwischen VPC-Netzwerken. Sich überschneidende IP-Adressbereiche sind zulässig. Hohe Bandbreite.	Gebühren für ausgehenden Traffic für VMs innerhalb derselben Zone sind höher als für andere Optionen, z. B. VPC-Netzwerk-Peering. VMs müssen mit externen IP-Adressen bereitgestellt werden. Keine Firewalls mit privaten IP-Adressen. Statische und dynamische Routen werden nicht weitergegeben. Quelltags und Quelldienstkonten der sendenden VM werden von Peering-Netzwerken nicht berücksichtigt.
Cloud VPN	Cloud VPN ermöglicht transitive Topologien für Hub-and-Spoke. Mit ECMP skalierbar. SLA für 99,99 % Dienstverfügbarkeit für Hochverfügbarkeits-VPN.	Hoher Verwaltungsaufwand. Abrechnung gemäß Preisen für ausgehenden Internettraffic. Geringfügig höhere Latenz. Durchsatz auf ~ 3 Gbit/s pro Tunnel begrenzt. Niedrigere MTU aufgrund von zusätzlicher Tunnelkapselung. Quelltags und Quelldienstkonten der sendenden VM gehen im Tunnel verloren.
Cloud Interconnect – Dedicated oder Partner	Unterstützte SLAs basierend auf Redundanz beim Deployment: 99,99 % (siehe Details) 99,9 % (siehe Details) Jeder Link einer Dedicated Interconnect-Verbindung ist eine 10-Gbit / s- oder 100-Gbit / s-Verbindung. Zur Durchsatzsteigerung können mehrere Interconnect-Verbindungen gebündelt werden. Pro Dedicated Interconnect-Verbindung sind maximal acht Netzwerkverbindungen mit 10 Gbit/s (80 Gbit/s) oder zwei Netzwerkverbindungen mit 100 Gbit/s (200 Gbit/s) möglich. ECMP kann zur Durchsatzerhöhung über mehrere Interconnect-Verbindungen verwendet werden.	Zusätzliche Kosten und Gebühren für ausgehenden Traffic zwischen VPC-Netzwerken über eine Interconnect-Verbindung. Traffic ist nicht verschlüsselt. Zusätzliche Latenz bei Cloudlösungen. Zusätzliche Hardwaregeräte im Pfad können ausfallen.
Mehrere Netzwerkschnittstellen (NICs)	Durch verwaltete Instanzgruppen und instanzübergreifende ECMP-Routen skalierbar. Für einzelne VMs gelten [Bandbreitenlimits](/compute/docs/network-bandwidth).	Maximal acht Schnittstellen pro Instanz. Der interne Passthrough-Network Load Balancer unterstützt das Senden von Traffic an [eine beliebige Schnittstelle](/load-balancing/docs/internal#backend-service-multi-nic) der VM. Andere Load-Balancer unterstützen nur die Standard-Netzwerkschnittstelle (nic0) einer VM.

VPC-Netzwerk-Peering verwenden, wenn Sie innerhalb der Ressourcenlimits bleiben

Wenn eine freigegebene VPC nicht ausreicht und Sie VPCs vernetzen müssen, empfehlen wir das VPC-Netzwerk-Peering. Die Gesamtzahl der für alle direkt verbundenen Peers erforderlichen Ressourcen darf jedoch nicht die Limits für VM-Instanzen, die Peering-Anzahl und die internen Weiterleitungsregeln überschreiten.

Mit VPC-Netzwerk-Peering können zwei VPC-Netzwerke intern über das SDN von Google miteinander verbunden werden, unabhängig davon, ob sie zum selben Projekt oder zur selben Organisation gehören. Mit dem VPC-Netzwerk-Peering werden die Steuerungsebene und die Datenflussverteilung zwischen Peers zusammengeführt. Sie profitieren dadurch von denselben Weiterleitungseigenschaften, wie wenn sich alle VMs in derselben VPC befinden. Beim Peering von VPC-Netzwerken kann auf alle Subnetze, Alias-IP-Bereiche und internen Weiterleitungsregeln zugegriffen werden. Außerdem hat jedes VPC-Netzwerk ihre eigene verteilte Firewall. Das VPC-Netzwerk-Peering ist nicht transitiv.

VPC-Netzwerk-Peering ist aus folgenden Gründen die bevorzugte Methode zum Verbinden von VPC-Netzwerken:

• Kein Gateway-Engpass: Traffic wird über Peers weitergeleitet, als ob sich die VMs in demselben VPC-Netzwerk befinden.
• Abrechnung: Es fallen keine zusätzlichen Kosten an. Die Abrechnung erfolgt, als ob sich die VMs in demselben VPC-Netzwerk befinden.

Externes Routing verwenden, wenn keine Kommunikation mit privaten IP-Adressen erforderlich ist

Wenn keine Kommunikation mit privaten IP-Adressen erforderlich ist, können Sie ein externes Routing mit externen IP-Adressen oder ein NAT-Gateway verwenden.

Wenn ein VPC-Netzwerk bereitgestellt wird, wird eine Route zum Standard-Internetgateway von Google mit der Priorität 1.000 bereitgestellt. Wenn diese Route vorhanden ist und einer VM eine externe IP-Adresse zugewiesen wird, können VMs ausgehenden Traffic über das Internetgateway von Google senden. Sie können Dienste auch hinter einer der zahlreichen öffentlichen Load-Balancing-Lösungen von Google bereitstellen, mit denen die Dienste extern erreichbar sind.

Extern adressierte VMs kommunizieren unabhängig von Region und Network Service Tiers privat über das Google-Backbonenetzwerk. Verwenden Sie Google Cloud-Firewallregeln, um extern eingehenden Traffic zu Ihren VMs zu steuern.

Externes Routing eignet sich gut zu Skalierungszwecken. Wichtig zu wissen ist jedoch, welche Kosten durch das öffentliche Routing anfallen. Weitere Informationen finden Sie in der Netzwerkpreisdokumentation.

VPC-Netzwerke mithilfe von Cloud VPN vernetzen, die sonst aggregierte Peering-Gruppen-Limits überschreiten würden

HA VPN bietet einen verwalteten Dienst zum Verbinden von VPC-Netzwerken. Dazu werden IPsec-Tunnel zwischen Endpunktgruppen erstellt. Wenn Sie Ihre Cloud Router mit benutzerdefiniertem Route Advertisement-Modus konfigurieren, können Sie das transitive Routing zwischen VPC-Netzwerken und Hub-and-Spoke-Topologien aktivieren, wie weiter unten in diesem Dokument beschrieben. Mit dem Network Connectivity Center können Sie HA VPN-Tunnel als Transitnetzwerk zwischen lokalen Netzwerken verwenden, wie in der Cloud VPN-Dokumentation erläutert.

Cloud VPN unterstützt keine großen MTUs. Weitere Informationen finden Sie unter Überlegungen zur MTU.

Mit Cloud Interconnect Traffic zwischen VPC-Netzwerken über ein lokales Gerät steuern

Cloud Interconnect erweitert Ihr lokales Netzwerk über eine hochverfügbare Verbindung mit niedriger Latenz auf das Google-Netzwerk. Die Verbindung zu Google kann direkt über Dedicated Interconnect oder über Partner Interconnect und einen unterstützten Dienstanbieter hergestellt werden.

Dedicated Interconnect bietet einen L2-Hochgeschwindigkeitsdienst zwischen Google und einem Colocation-Anbieter oder einem lokalen Standort. Dies ermöglicht Ihnen die Nutzung lokaler Geräte für das Routing, um Traffic zwischen VPC-Netzwerken und bestehenden lokalen Sicherheits- und Inspektionsservices zu routen und so allen Traffic zwischen VPC-Netzwerken zu filtern. Sämtlicher Traffic zwischen den beiden VPC-Netzwerken weist eine zusätzliche Latenz auf, da ein weiterer Durchlauf durch das lokale System erfolgt.

Partner Interconnect bietet ähnliche Funktionen sowie die Möglichkeit des direkten Peerings mit einem L3-Anbieter. Der Anbieter kann ein Routing zwischen VPC-Netzwerken einrichten. Dies ermöglicht den Zugriff auf interne IP-Adressen in Ihrem lokalen Netzwerk sowie in VPC-Netzwerken von Google Cloud ohne NAT-Gerät oder VPN-Tunnel.

Da viele Sicherheitsanwendungen für Unternehmen in Google Cloud mit VMs mit mehreren Netzwerkschnittstellen verwendet werden können, ist die Verwendung von Cloud Interconnect zum Weiterleiten des Traffics zwischen VPC-Netzwerken nicht erforderlich, es sei denn, der gesamte Traffic muss aufgrund von Unternehmensrichtlinien durch eine lokale Appliance fließen.

Traffic zwischen VPC-Netzwerken über ein Cloud-Gerät mithilfe von virtuellen Appliances steuern

VMs mit mehreren Netzwerkschnittstellen sind für VPC-Netzwerke gängig, für deren Kommunikation untereinander erhöhte Sicherheit oder zusätzliche Dienste erforderlich sind. Der Grund dafür ist, dass die Kommunikation zwischen VPC-Netzwerken mit diesen VM-Instanzen überbrückt werden kann.

Eine VM darf pro verbundenem VPC-Netzwerk nur eine Schnittstelle haben. Zum Bereitstellen einer VM in mehreren VPC-Netzwerken benötigen Sie die entsprechende IAM-Berechtigung für jedes VPC-Netzwerk, zu dem die VM eine Verbindung herstellt.

Beachten Sie beim Bereitstellen einer VM mit mehreren NICs Folgendes:

• Eine VM mit mehreren NICs kann maximal acht Schnittstellen haben.
• Die Subnetz-IP-Bereiche der Schnittstellen dürfen sich nicht überschneiden.

VPC mit freigegebenen Diensten erstellen, wenn mehrere VPC-Netzwerke auf gemeinsame Ressourcen zugreifen müssen, aber keinen Zugriff untereinander benötigen

Ein VPC-Netzwerk bietet vollständige globale Erreichbarkeit. Daher sind für freigegebene Dienste und kontinuierlich integrierte Pipelines innerhalb desselben VPC-Netzwerks keine speziellen Konnektivitätskonfigurationen erforderlich. Sie sind von Natur aus erreichbar. Bei freigegebenen VPCs können freigegebene Dienste außerdem in einem isolierten Projekt vorhanden sein und trotzdem Konnektivität zu anderen Diensten oder Nutzern bieten.

Zu den Ansätzen für freigegebene Dienste gehören Private Service Connect, VPC-Netzwerk-Peering und Cloud VPN. Verwenden Sie Private Service Connect, es sei denn, das ist nicht möglich. Sie können mit VPC-Netzwerk-Peering eine Verbindung zu einem VPC-Netzwerk mit freigegebenen Diensten herstellen, wenn Sie nicht die aggregierten Ressourcenlimits überschreiten und nicht für jeden Dienst Endpunkte einrichten möchten. Mit Cloud VPN können Sie auch VPC-Netzwerke von freigegebenen Diensten verbinden, die andernfalls die Gesamtbeschränkungen von Peering-Gruppen überschreiten würden.

Mit Private Service Connect können Sie einen in einem Netzwerk gehosteten Dienst für VMs in einem anderen Netzwerk zur Verfügung stellen. Dazu erstellen Sie einen speziellen Endpunkt im Nutzernetzwerk. Die Private Service Connect-Konfiguration leitet dann den Traffic für diesen Dienst zwischen den beiden Netzwerken weiter.

Nutzer können ihre eigenen internen IP-Adressen für den Zugriff auf Dienste verwenden, ohne ihre VPC-Netzwerke zu verlassen oder externe IP-Adressen zu verwenden. Der Traffic verbleibt vollständig in Google Cloud. Private Service Connect bietet dienstorientierten Zugriff zwischen Nutzern und Erstellern. Sie können genau steuern, wie auf Dienste zugegriffen wird.

Im VPC-Netzwerk-Peering-Modell wird zwischen jedem VPC-Netzwerk eine Peering-Beziehung zu einem gemeinsamen VPC-Netzwerk mit freigegebenen Diensten aufgebaut, um die Erreichbarkeit zu gewähren. Beim VPC-Netzwerk-Peering sind jedoch Skalierungslimits zu berücksichtigen, da die aggregierte Ressourcennutzung aller Peers begrenzt ist.

Das VPC-Netzwerk-Peering kann auch in Verbindung mit dem Zugriff auf private Dienste und mit der Service Networking API verwendet werden. Über die Service Networking API können Sie Kunden im selben Unternehmen oder in einem anderen Unternehmen einen von Ihnen bereitgestellten Dienst zur Verfügung stellen und ihnen dabei aber die Auswahl des IP-Adressbereichs überlassen, mit dem die Verbindung über das VPC-Netzwerk-Peering hergestellt wird.

Cloud VPN ist eine weitere Alternative. Da Cloud VPN für die Erreichbarkeit verwaltete IPsec-Tunnel verwendet, gelten nicht die aggregierten Limits des VPC-Netzwerk-Peerings. Die Konnektivität wird in Cloud VPN über ein VPN-Gateway bereitgestellt, ohne die aggregierte Ressourcennutzung des IPsec-Peers zu berücksichtigen. Nachteilig bei Cloud VPN sind die erhöhten Kosten (für VPN-Tunnel und ausgehenden Traffic), der Verwaltungsaufwand für die Tunnelwartung sowie der Leistungsaufwand von IPsec.

Hybrides Design: Lokale Umgebung vernetzen

Wenn Hybridkonnektivität erforderlich ist und Sie entsprechend Ihren Bandbreiten-, Leistungs- und Sicherheitsanforderungen eine Lösung ausgewählt haben, folgt die Überlegung, wie Sie die Lösung in Ihr VPC-Design einbinden.

Mithilfe einer freigegebenen VPC erübrigt sich die Replikation derselben Lösung für jedes Projekt. Wenn Sie beispielsweise eine Cloud Interconnect-Lösung in eine freigegebene VPC einbinden, können alle VMs – unabhängig von der Region oder vom Dienstprojekt – auf die Cloud Interconnect-Verbindung zugreifen.

Dynamisches Routing

Dynamisches Routing ist für alle Hybridlösungen verfügbar, einschließlich Hochverfügbarkeits-VPN, klassisches VPN, Dedicated Interconnect und Partner Interconnect. Beim dynamischen Routing wird der Cloud Router von Google als BGP-Speaker (Border Gateway Protocol) für ein dynamisches eBGP-Routing (externes BGP) verwendet.

Der Cloud Router befindet sich nicht auf der Datenebene, sondern erstellt nur Routen im SDN.

Beim dynamischen Routing werden keine Tags verwendet. Außerdem bewirbt der Cloud Router gelernte Präfixe nicht wieder.

Sie können für jedes VPC-Netzwerk wahlweise den regionalen oder globalen Cloud Router-Modus aktivieren. Beim regionalen Routing bewirbt der Cloud Router nur Subnetze, die sich in derselben Region wie der Cloud Router befinden. Beim globalen Routing hingegen werden alle Subnetze des angegebenen VPC-Netzwerks unabhängig von der Region beworben. Für außerhalb der Region beworbene und erkannte Routen werden jedoch Strafen auferlegt. Dies erhält die Symmetrie innerhalb der Region aufrecht, da lokale Verbindungen immer bevorzugt werden. Zur Berechnung wird ein Strafmesswert (MED) addiert, der 200 + TTL in Millisekunden zwischen Regionen entspricht.

Statisches Routing

Statisches Routing ist nur im klassischen VPN verfügbar. Damit kann in einem Cloud VPN-Tunnel ein Routenpunkt als nächster Hop festgelegt werden.

Standardmäßig gilt eine statische Route unabhängig von der Region für alle VMs im Netzwerk. Beim statischen Routing können Netzwerkadministratoren mithilfe von Instanztags auch gezielt festlegen, für welche VMs die Route gilt. Die Tags können Sie bei der Routenerstellung angeben.

Statische Routen gelten global im VPC-Netzwerk mit derselben Routenpriorität. Wenn Sie also mehrere Tunnel in mehreren Regionen mit demselben Präfix und derselben Priorität haben, verwendet eine VM in allen Tunneln einen Hash-basierten ECMP mit fünf Tupeln. Zur Optimierung können Sie eine bevorzugte Route innerhalb der Region erstellen. Referenzieren Sie hierfür Instanztags für jede Region und erstellen Sie bevorzugte Routen.

Wenn ausgehender Traffic nicht über das Standard-Internetgateway von Google geleitet werden soll, können Sie eine bevorzugte statische Standardroute festlegen, um den gesamten Traffic lokal über einen Tunnel zurückzusenden.

Ein VPC-Verbindungsnetzwerk verwenden, um eine Hub-and-Spoke-Architektur mit mehreren VPC-Netzwerken zu skalieren

Wenn Sie eine Hub-and-Spoke-Architektur mit mehreren VPC-Netzwerken skalieren müssen, konfigurieren Sie eine zentralisierte Hybridkonnektivität in einem dedizierten VPC-Netzwerk und verbinden Sie sich mithilfe benutzerdefinierter Routen mit anderen Projekten. Statische oder dynamisch erkannte Routen lassen sich dadurch in Peering-VPC-Netzwerken exportieren. Sie können Ihr VPC-Netzwerkdesign auf diese Weise zentralisiert konfigurieren und skalieren.

Im Gegensatz dazu werden beim herkömmlichen Deployment von Hybridkonnektivität in jedem VPC-Netzwerk ein VPN-Tunnel oder VLAN-Anhänge verwendet.

Das folgende Diagramm zeigt die zentralisierte Hybridkonnektivität mit VPC-Netzwerk-Peering-Routen:

Netzwerksicherheit

Google Cloud bietet für die Infrastruktur und Dienste robuste Sicherheitsfunktionen, angefangen beim physischen Schutz der Rechenzentren und speziell angefertigter Sicherheitshardware bis hin zu dedizierten Sicherheitsteams. Die Sicherung Ihrer Google Cloud-Ressourcen ist jedoch eine Aufgabe, die in gemeinsamer Verantwortung gelöst werden muss. Sie sind für den Schutz Ihrer Anwendungen und Daten durch geeignete Maßnahmen zuständig.

Klare Sicherheitsziele identifizieren

Bevor Sie cloudnative oder cloudfähige Sicherheitskontrollen bewerten, sollten Sie eine Reihe klarer Sicherheitsziele des Produkts vorgeben, die von allen Beteiligten als grundlegender Bestandteil anerkannt werden. Bei diesen Zielen sollten die Erreichbarkeit, Dokumentation und Iteration im Vordergrund stehen und während der gesamten Entwicklung berücksichtigt und optimiert werden.

Externen Zugriff beschränken

Wenn Sie eine Google Cloud-Ressource erstellen, die ein VPC-Netzwerk verwendet, wählen Sie ein Netzwerk und ein Subnetz aus, in dem sich die Ressource befindet. Der Ressource wird eine interne IP-Adresse aus einem der IP-Bereiche zugewiesen, die dem Subnetz zugeordnet sind. Ressourcen in einem VPC-Netzwerk können über interne IP-Adressen miteinander kommunizieren, sofern die Firewallregeln dies zulassen.

Beschränken Sie den Internetzugriff auf wirklich erforderliche Ressourcen. Ressourcen, die nur eine private, interne IP-Adresse haben, können über Private Service Connect oder den privaten Google-Zugriff dennoch auf viele Google APIs und Google-Dienste zugreifen. Ein privater Zugriff ermöglicht Ressourcen die Interaktion mit wichtigen Google- und Google Cloud-Diensten, ohne die Isolation vom öffentlichen Internet aufzuheben.

Außerdem können Sie die Organisationsrichtlinien verwenden, um einzuschränken, welche Ressourcen externe IP-Adressen verwenden dürfen.

Erwägen Sie vor dem Sperren des Internetzugriffs jedoch, wie sich dies auf Ihre VM-Instanzen auswirkt. Durch das Blockieren des Internetzugriffs kann das Risiko einer Daten-Exfiltration verringert werden. Zum Teil werden dadurch aber auch legitime Zugriffe wie etwa wichtiger Traffic für Softwareupdates sowie APIs und Dienste von Drittanbietern blockiert. Ohne Internetzugriff können Sie auf Ihre VM-Instanzen nur über ein lokales Netzwerk zugreifen, das über einen Cloud VPN-Tunnel, eine Cloud Interconnect-Verbindung oder einen Identity-Aware Proxy verbunden ist. Mit Cloud NAT können virtuelle Maschinen für bestimmten wichtigen Traffic ausgehende Verbindungen zum Internet initiieren, ohne öffentliche eingehende Verbindungen zuzulassen.

Dienstperimeter für sensible Daten definieren

Bei Arbeitslasten, die sensible Daten involvieren, können Sie mithilfe von VPC Service Controls Dienstperimeter für Ihre VPC-Ressourcen und die von Google verwalteten Dienste konfigurieren und Datenbewegungen über die Perimetergrenze hinweg steuern. VPC Service Controls bietet Ihnen die Möglichkeit, Projekte und Ihr lokales Netzwerk innerhalb eines Perimeters zusammenzufassen, um den Datenzugriff über von Google verwaltete Dienste zu verhindern. Innerhalb von Dienstperimetern können sich keine Projekte anderer Organisationen befinden. Die Projekte und Dienste in unterschiedlichen Dienstperimetern können jedoch über Perimeter-Bridges miteinander kommunizieren.

Traffic nach Möglichkeit mit nativen Google Cloud-Firewallregeln verwalten

Die Google Cloud-VPC enthält eine zustandsorientierte L3-/L4-Firewall, die horizontal skalierbar ist und auf alle VMs verteilt angewendet wird. Diese Firewall wird mit hierarchischen Firewallrichtlinien, globalen und regionalen Netzwerk-Firewallrichtlinien und VPC-Firewallregeln konfiguriert. Weitere Informationen finden Sie in der Übersicht zu Cloud Firewall.

Der Google Cloud Marketplace bietet eine große Auswahl an Lösungen von Drittanbietern, einschließlich VMs, die Folgendes bieten: erweiterte Sicherheit wie Schutz vor Informationslecks, Exploits von Anwendungen und Eskalation von Berechtigungen, Erkennung bekannter und unbekannter Bedrohungen und Anwendung von URL-Filterung. Die Richtlinienimplementierung eines einzigen Anbieters für Cloud-Dienstanbieter und lokale Umgebungen bietet auch operative Vorteile.

Die für die Weiterleitung des Traffics an diese VMs festgelegten Routen haben in der Regel entweder dieselbe Priorität, um den Traffic mit einem 5-Tupel-Hash zu verteilen, oder unterschiedliche Prioritäten, um einen redundanten Pfad zu erstellen. Im folgenden Diagramm sehen Sie, dass mehrere Pfade zum Dev-Subnetz (Dev-subnet) führen.

Für die meisten Lösungen sind mehrere VMs mit Netzwerkschnittstelle erforderlich. Da eine VM nicht mehr als eine Schnittstelle pro VPC-Netzwerk haben kann, muss jede Schnittstelle beim Erstellen einer VM mit mehreren Schnittstellen an ein separates VPC-Netzwerk angehängt werden.

Auch die Skalierung spielt aus folgenden Gründen eine wichtige Rolle beim Deployment von Drittanbieterlösungen in Ihrem VPC-Netzwerk:

• Limits: Die meisten VM-basierten Appliances müssen in den Datenpfad eingefügt werden. Dies erfordert eine VM mit mehreren Netzwerkschnittstellen, die mehrere VPC-Netzwerke verbindet, die sich im selben Projekt befinden. Da VPC-Ressourcenkontingente auf Projektebene festgelegt werden, ist die aggregierte Ressourcennutzung in allen VPC-Netzwerken begrenzt.
• Leistung: Die vollständige horizontale Skalierbarkeit einer VPC durch einen einzelnen VM-basierten Engpass einzuschränken widerspricht den Methoden für das Clouddesign. Um dies zu vermeiden, können Sie mehrere virtuelle Appliances für Netzwerke in einer verwalteten Instanzgruppe hinter einem internen Passthrough-Network Load Balancer platzieren.

Sie können diese Faktoren in Architekturen mit umfangreichen Anforderungen berücksichtigen. Übertragen Sie hierfür Sicherheitskontrollen an Ihre Endpunkte. Härten Sie zuerst Ihre VMs und wenden Sie Google Cloud-Firewallregeln an. Sie können zu diesem Zweck auch hostbasierte Agents für die Endpunktüberprüfung nutzen, mit denen die Weiterleitungsarchitektur Ihres VPC-Netzwerks über VMs mit mehreren Netzwerkschnittstellen beibehalten wird.

Ein weiteres Beispiel für diese Konfiguration finden Sie in der Referenzarchitektur unter Zustandsorientierte L7-Firewall zwischen VPCs.

Nach Möglichkeit weniger, aber dafür umfassendere Firewallregelsätze verwenden

Auf einer beliebigen VM kann nur eine bestimmte Anzahl von Regeln programmiert werden. Sie haben jedoch die Möglichkeit, mehrere Regeln in einer komplexen Regeldefinition zu kombinieren. Wenn beispielsweise alle VMs im VPC-Netzwerk zehn eingehende TCP-Ports explizit zulassen müssen, haben Sie zwei Möglichkeiten: Sie schreiben zehn separate Regeln, die jeweils einen einzelnen Port definieren, oder eine einzelne Regel, die alle zehn Ports enthält. Effizienter ist es, eine Regel für alle zehn Ports zu definieren.

Erstellen Sie einen generischen Regelsatz für das gesamte VPC-Netzwerk und wenden Sie dann für kleinere Gruppen von VMs mithilfe von Zielen speziellere Regelsätze an. Beginnen Sie also mit allgemeineren Regeln und definieren Sie dann schrittweise spezifischere Regeln:

1. Wenden Sie Firewallregeln an, die für alle VMs im VPC-Netzwerk gelten.
2. Wenden Sie Firewallregeln an, die für mehrere VMs, wie etwa eine Dienstinstanzgruppe oder ein Subnetz, gelten.
3. Wenden Sie Firewallregeln auf einzelne VMs an, wie etwa ein NAT-Gateway oder einen Bastion Host.

VMs nach Möglichkeit mithilfe von Dienstkonten isolieren

Viele Organisationen haben Umgebungen, in denen für eine Teilmenge der VMs in einem VPC-Netzwerk bestimmte Regeln erforderlich sind. Hierfür bietet sich wahlweise die Subnetzisolierung oder die Zielfilterung an.

Subnetzisolierung

Bei der Subnetzisolierung bildet das Subnetz die Sicherheitsgrenze, auf die Google Cloud-Firewallregeln angewendet werden. Dieser Ansatz ist in lokalen Netzwerkkonstrukten üblich. Er gilt auch, wenn IP-Adressen und die Netzwerkplatzierung Teil der VM-Identität sind.

Sie können die VMs in einem bestimmten Subnetz mithilfe eines eindeutigen Tags, eines Netzwerktags oder eines Dienstkontos auf diese Instanzen identifizieren. Dies ermöglicht Ihnen, Firewallregeln zu erstellen, die nur für die VMs in einem Subnetz gelten – denen ein Netzwerktag oder ein Dienstkonto zugewiesen wurde. Sie können beispielsweise eine Firewallregel erstellen, die die gesamte Kommunikation zwischen VMs in einem Subnetz zulässt. Hierfür konfigurieren Sie die Regel auf der Seite "Firewallregeln" in folgender Weise:

• Ziele: Specified target tags
• Zieltags: subnet-1
• Quellfilter: Subnets
• Subnetze: Subnetz nach Name auswählen, z. B. subnet-1

Zielfilterung

Bei der Zielfilterung befinden sich alle VMs entweder im selben Subnetz oder sind Teil einer beliebigen Gruppe von Subnetzen. Die Subnetzmitgliedschaft wird bei diesem Ansatz nicht als Teil der Instanzidentität für Firewallregeln betrachtet. Stattdessen können Sie den Zugriff zwischen VMs im selben Subnetz mit Tags, Netzwerktags oder Dienstkonten einschränken. Auf jede Gruppe von VMs, die dieselben Firewallregeln verwenden, wird dasselbe Netzwerktag angewendet.

Stellen Sie sich zur Veranschaulichung eine dreistufige Anwendung (Web, Anwendung, Datenbank) vor, für die alle Instanzen im selben Subnetz bereitgestellt werden. Die Webebene kann mit Endnutzern und der Anwendungsebene und die Anwendungsebene mit der Datenbankebene kommunizieren. Ansonsten ist keine Kommunikation zwischen Ebenen zulässig. Die Instanzen, auf denen die Webebene ausgeführt wird, haben das Netzwerktag web, die Instanzen, auf denen die Anwendungsebene ausgeführt wird, haben das Netzwerktag app und die Instanzen, auf denen die Datenbankebene ausgeführt wird, haben das Netzwerktag db.

Dieser Ansatz wird durch die folgenden Firewallregeln implementiert:

Regel 1: Endnutzer zulassen → Webebene	Ziele: Angegebene Zieltags Zieltags: web Quellfilter: IP-Bereiche Quell-IP-Bereiche: 0.0.0.0/0
Regel 2: Webebene zulassen → Anwendungsebene	Ziele: Angegebene Zieltags Zieltags: app Quellfilter: Quelltags Quelltags: web
Regel 3: Anwendungsebene zulassen → Datenbankebene	Ziele: Angegebene Zieltags Zieltags: db Quellfilter: Quelltags Quelltags: app

Obwohl Tags auf diese Weise für die Zielfilterung verwendet werden können, empfehlen wir nach Möglichkeit die Verwendung von Tags oder Dienstkonten. Zieltags sind nicht zugriffsgesteuert und können von einem Nutzer während der Ausführung von VMs mit der Rolle instanceAdmin geändert werden. Tags und Dienstkonten sind zugriffsgesteuert. Dies bedeutet, dass ein Nutzer ausdrücklich zur Verwendung eines Dienstkontos berechtigt sein muss. Jede Instanz kann nur ein Dienstkonto, aber mehrere Tags haben. Außerdem können die einer VM zugewiesenen Dienstkonten nur geändert werden, wenn die VM angehalten wird.

Bei Verwendung von Tags Sicherheitsrichtlinien automatisch überwachen

Denken Sie bei der Verwendung von Netzwerktags daran, dass diese von Instanzadministratoren geändert werden können. Dies ermöglicht ein Umgehen der Sicherheitsrichtlinien. Wenn Sie Netzwerktags in einer Produktionsumgebung verwenden, sollten Sie daher als Ausgleich für fehlende IAM-Governance hinsichtlich der Netzwerktags ein Automatisierungsframework verwenden.

Anwendungen mit zusätzlichen Tools sichern und schützen

Verwenden Sie neben den Firewallregeln die folgenden zusätzlichen Tools, um Ihre Anwendungen zu sichern und zu schützen:

• Verbessern Sie mit einem globalen HTTP(S)-Load-Balancer für Google Cloud die Hochverfügbarkeit und Protokollnormalisierung.
• Binden Sie Google Cloud Armor in den HTTP(S)-Load-Balancer ein, um DDoS-Schutz bereitzustellen und IP-Adressen am Netzwerkrand zu blockieren oder zuzulassen.
• Mithilfe von IAP (IAP) können Sie den Anwendungszugriff steuern. Prüfen Sie hierfür die Nutzeridentität und den Kontext von Anfragen und bestimmen Sie, ob einem Nutzer Zugriff gewährt werden soll.
• Stellen Sie mit Security Command Center eine zentrale Oberfläche bereit, über die Sie den Sicherheitsstatus prüfen sowie Anomalien und Sicherheitslücken erkennen können.

Netzwerkdienste: NAT und DNS

Für feste externe IP-Adressen Cloud NAT verwenden

Wenn Sie feste externe IP-Adressen aus einem Bereich von VMs benötigen, verwenden Sie Cloud NAT. Feste ausgehende IP-Adressen können beispielsweise erforderlich sein, wenn ein Drittanbieter Anfragen von bestimmten externen IP-Adressen zulässt. Mit Cloud NAT können Sie für die ausgehende Kommunikation eine kleine Anzahl von NAT-IP-Adressen pro Region verwenden.

Cloud NAT lässt auch zu, dass die VM-Instanzen ohne eigene externe IP-Adresse über das Internet kommunizieren. Google Cloud-Firewallregeln sind zustandsorientiert. Wenn eine Verbindung zwischen einer Quelle und einem Ziel oder einem Ziel und einem anderen Ziel zugelassen wird, ist somit der gesamte Traffic in beide Richtungen zulässig, solange die Verbindung aktiv ist. Dies bedeutet, dass Firewallregeln eine bidirektionale Kommunikation erlauben, sobald eine Sitzung eingerichtet wurde.

Für die Namensauflösung private DNS-Zonen verwenden

Verwenden Sie private Zonen in Cloud DNS, damit Ihre Dienste mit DNS innerhalb Ihres VPC-Netzwerks unter Verwendung ihrer internen IP-Adressen aufgelöst werden können, ohne dass diese Zuordnung nach außen erfolgt.

Verwenden Sie Split-Horizon-DNS, um Dienste anderen IP-Adressen von innerhalb des VPC-Netzwerks anstatt von außerhalb zuzuordnen. Sie können beispielsweise einen Dienst aus dem öffentlichen Internet mithilfe von Netzwerk-Load-Balancing bereitstellen lassen und denselben Dienst gleichzeitig durch internes Load-Balancing mit demselben DNS-Namen innerhalb des VPC-Netzwerks bereitstellen.

API-Zugriff für von Google verwaltete Dienste

Nach Möglichkeit das Standard-Internetgateway verwenden

Der Zugriff von Ressourcen innerhalb des VPC-Netzwerks auf Google APIs erfolgt über den nächsten Standard-Internetgateway. Trotz des Namens des Gateways für den nächsten Hop bleibt der Trafficpfad von Instanzen zu den Google APIs im Google-Netzwerk.

Standardmäßig können nur VM-Instanzen mit einer externen IP-Adresse mit Google APIs und Diensten kommunizieren. Wenn Sie Zugriff von Instanzen ohne externe IP-Adresse benötigen, richten Sie Private Service Connect-Endpunkte ein oder verwenden Sie für jedes Subnetz den privaten Google-Zugriff. Die Kommunikationsgeschwindigkeit von Google APIs bleibt dabei erhalten.

In Google Kubernetes Engine (GKE) wird der private Google-Zugriff in Subnetzen, in denen Knoten bereitgestellt werden, automatisch aktiviert. Alle Knoten in diesen Subnetzen ohne externe IP-Adresse können auf von Google verwaltete Dienste zugreifen.

Explizite Routen für Google APIs hinzufügen, wenn Sie die Standardroute ändern müssen

Wenn Sie die Standardroute ändern müssen, fügen Sie explizite Routen für Google API-Ziel-IP-Bereiche hinzu.

Konfigurieren Sie in Umgebungen, in denen die Standardroute (0.0.0.0/0) nicht das Standard-Internetgateway für den nächsten Hop verwendet, explizite Routen für die von Google APIs verwendeten Ziel-IP-Adressbereiche. Legen Sie als nächsten Hop der expliziten Routen das Standard-Internetgateway fest. Dies ist beispielsweise empfehlenswert, wenn Sie den gesamten Traffic auf einem lokalen Gerät prüfen möchten.

Instanzen bereitstellen, die im selben Subnetz Google APIs verwenden

Stellen Sie Instanzen bereit, die Zugriff auf Google APIs und Dienste im selben Subnetz benötigen. Aktivieren Sie für Instanzen ohne externe IP-Adressen den privaten Google-Zugriff. Alternativ können Sie Private Service Connect-Endpunkte einrichten.

Wenn Sie von Ihrer lokalen Umgebung aus über den privaten Google-Zugriff auf Google APIs zugreifen, verwenden Sie Privaten Google-Zugriff für lokale Hosts konfigurieren, um über private IP-Adressbereiche auf einige Google-Dienste zuzugreifen. Prüfen Sie vor dem Aktivieren dieses Features, welche Dienste unterstützt werden, da über die von diesem Dienst bereitgestellten IP-Adressen nicht auf andere Google APIs zugegriffen werden kann. Zum Aktivieren dieses Features kann eine zusätzliche DNS-Konfiguration, etwa der DNS-Ansichten, erforderlich sein.

Wenn Sie von Ihrer lokalen Umgebung über Private Service Connect-Endpunkte auf Google APIs zugreifen, finden Sie weitere Informationen unter Über lokale Hosts auf den Endpunkt zugreifen.

Logging, Monitoring und Sichtbarkeit

Logging für bestimmte Anwendungsfälle und vorgesehene Zielgruppen anpassen

Verwenden Sie VPC-Flusslogs für die Netzwerküberwachung, die Forensik, Echtzeit-Sicherheitsanalysen und die Kostenoptimierung. Sie können VPC-Flusslogs auf der VPC-Subnetzebene aktivieren oder deaktivieren. Wenn für ein Subnetz VPC-Flusslogs aktiviert sind, werden Daten von allen VM-Instanzen in diesem Subnetz erfasst.

In diesen Logs wird eine Stichprobe der von VM-Instanzen gesendeten und empfangenen Netzwerkflüsse aufgezeichnet. Anhand Ihrer Logging-Anwendungsfälle können Sie feststellen, für welche Subnetze ein Logging erforderlich ist und wie lange.

Flusslogs werden nach Verbindung in 5-Sekunden-Intervallen von Compute Engine-VMs aggregiert und in Echtzeit exportiert. Sie können Flusslogs in Cloud Logging anzeigen und an ein beliebiges Ziel exportieren, das vom Cloud Logging-Export unterstützt wird.

In Logging wird auf der Seite "Logs injection" (Logaufnahme) das Logvolumen in Ihrem Projekt verfolgt. Außerdem können Sie hier alle Logaufnahmen deaktivieren oder für Sie irrelevante Logeinträge ausschließen bzw. verwerfen. Dadurch minimieren Sie die Kosten für Logs über Ihr monatliches Kontingent hinaus.

Logs sind für den Betrieb und die Sicherheit wichtig. Sie sind jedoch nur nützlich, wenn sie auch geprüft werden, um gegebenenfalls Maßnahmen ergreifen zu können. Passen Sie Logs zur Optimierung des Betriebs und der Sicherheit Ihrer VPC-Netzwerke für die gewünschte Zielgruppe an.

Weitere Informationen finden Sie unter VPC-Flusslogs verwenden.

Intervall der Logaggregation für VPC-Netzwerke mit lang andauernden Verbindungen erhöhen

Legen Sie für VPC-Netzwerke mit meist langlebigen Verbindungen das Logaggregationsintervall auf 15 Minuten fest, um die Anzahl der generierten Logs erheblich zu reduzieren und eine schnellere und einfachere Analyse zu ermöglichen.

Ein Beispiel für einen Workflow, für den das Logaggregationsintervall verlängert werden kann, ist die Netzwerküberwachung. Diese beinhaltet die folgenden Aufgaben:

• Netzwerkdiagnose ausführen
• Flusslogs nach VMs und Anwendungen filtern, um Trafficänderungen zu verstehen
• Trafficanstieg zur Vorhersage der Kapazität analysieren

Volumen durch VPC-Flusslog-Sampling reduzieren

Reduzieren Sie durch das VPC-Flusslog-Sampling das Volumen der VPC-Flusslogs. Sie können dennoch weiter detaillierte Beispiele und allgemeine Zusammenfassungen ansehen.

Ein Beispiel für einen Workflow, bei dem sich durch Sampling das Volumen reduzieren lässt, ist das Untersuchen der Netzwerkauslastung und die Kostenoptimierung des Netzwerkverkehrs. Dieser Workflow beinhaltet die folgenden Aufgaben:

• Traffic zwischen Regionen und Zonen schätzen
• Internettraffic in bestimmte Länder schätzen
• Top Talkers identifizieren

Zusätzliche Metadaten entfernen, wenn Sie nur IP- und Portdaten benötigen

Wenn Sie hinsichtlich der Sicherheit nur an IP-Adressen und Ports interessiert sind, entfernen Sie die zusätzlichen Metadaten, um das Datenvolumen in Cloud Logging zu reduzieren.

Ein Beispiel für einen Workflow, bei dem Metadaten entfernt werden können, ist die Netzwerkforensik. Diese beinhaltet die folgenden Aufgaben:

• Ermitteln, welche IP-Adressen mit wem und wann kommuniziert haben
• Manipulierte IP-Adressen identifizieren, die durch Analysieren von Netzwerkflüssen ermittelt wurden

Referenzarchitekturen

In diesem Abschnitt werden zur Veranschaulichung einiger der Best Practices in diesem Dokument verschiedene Architekturen vorgestellt.

Einzelnes Projekt und einzelnes VPC-Netzwerk

Diese anfängliche Referenzarchitektur umfasst alle Komponenten, die für das Deployment hochverfügbarer Architekturen in mehreren Regionen erforderlich sind. Sie bietet eine Isolierung auf Subnetzebene sowie eine SLA mit 99,99 % Verfügbarkeit für die Verbindung zu Ihren lokalen Rechenzentren.

Einzelnes Hostprojekt, mehrere Dienstprojekte, einzelne freigegebene VPC

Diese Architektur baut auf der anfänglichen Referenzarchitektur auf. Über freigegebene VPC-Hostprojekte und Projekte mit mehreren Diensten können Administratoren Verwaltungsaufgaben wie das Erstellen und Verwalten von Instanzen an Dienstprojektadministratoren delegieren, ohne die zentrale Steuerung von Netzwerkressourcen wie Subnetzen, Routen und Firewalls aus der Hand zu geben.

Mehrere Hostprojekte, mehrere Dienstprojekte, mehrere freigegebene VPCs

Das folgende Diagramm zeigt eine Architektur für die VPC-Isolierung, die auf unserem Hochverfügbarkeitsdesign aufbaut und gleichzeitig die Produktion von anderen Projekten trennt. Es gibt viele Gründe, die VPC-Isolierung in Betracht zu ziehen, wie etwa Überprüfungsanforderungen (z. B. PCI), zwischen Umgebungen erforderliche Kontingente oder einfach eine weitere logische Isolierungsebene. Für die Redundanz benötigen Sie pro Standort nur zwei Interconnect-Verbindungen. Sie können jedoch mehreren VPC-Netzwerken oder Regionen davon diverse Interconnect-Anhänge hinzufügen.

Durch die Isolierung kann abhängig davon, wo Kerndienste wie Proxys, Authentifizierung und Verzeichnisdienste platziert werden sollen, auch eine Replikation erforderlich sein. Die Verwendung eines VPC-Netzwerks für freigegebene Dienste kann dazu beitragen, diese Replikation zu vermeiden. Außerdem können Sie diese Dienste über VPC-Netzwerk-Peering für andere VPC-Netzwerke freigeben und gleichzeitig die Verwaltung und Bereitstellung zentralisieren.

Zustandsorientierte L7-Firewall zwischen VPC-Netzwerken

Diese Architektur verfügt über mehrere VPC-Netzwerke, die von einer L7-Firewall-Appliance der nächsten Generation (NGFW) überbrückt werden, die als Multi-NIC-Brücke zwischen VPC-Netzwerken fungiert.

Ein nicht vertrauenswürdiges, externes VPC-Netzwerk wird eingeführt, um Hybridverbindungen und internetbasierte Verbindungen zu beenden, die zur Prüfung am Außenabschnitt der L7 NGFW enden. Dieses Design gibt es in zahlreichen Varianten. Das Hauptprinzip besteht jedoch darin, den Traffic durch die Firewall zu filtern, bevor er vertrauenswürdige VPC-Netzwerke erreicht.

Bei diesem Design muss sich jedes VPC-Netzwerk in dem Projekt befinden, in das Sie die VM-basierte NGFW einfügen. Da Kontingente auf Projektebene erzwungen werden, müssen Sie die Summe aller VPC-Ressourcen berücksichtigen.

Nächste Schritte

• VPC Deep Dive and Best Practices (Cloud NEXT' 18 Video)
• Hybrid- und Multi-Cloud-Netzwerktopologien
• Ressourcenhierarchie für Ihre Google Cloud-Landing-Zone festlegen
• Best Practices für die Auswahl der Region in Compute Engine
• Google Cloud für Rechenzentrumsexperten: Netzwerk
• Virtual Private Cloud-Dokumentation
• GKE-Netzwerkübersicht
• Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center