VPC-Firewallregeln

VPC-Firewallregeln (Virtual Private Cloud) gelten für ein bestimmtes Projekt und Netzwerk. Wenn Sie Firewallregeln auf mehrere VPC-Netzwerke in einer Organisation anwenden möchten, lesen Sie die Informationen unter Firewallrichtlinien. Im weiteren Verlauf dieser Seite werden nur VPC-Firewallregeln behandelt.

Mit VPC Firewallregeln können Sie Verbindungen zu oder von VM-Instanzen in Ihrem VPC-Netzwerk zulassen oder ablehnen. Aktivierte VCP-Firewallregeln werden immer erzwungen. Sie schützen Ihre Instanzen unabhängig von ihrer Konfiguration und ihrem Betriebssystem, selbst wenn sie nicht gestartet wurden.

Jedes VPC-Netzwerk wirkt wie eine verteilte Firewall. Die Firewallregeln werden auf Netzwerkebene definiert, die Verbindungen 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.

Hinweis: Diese Seite bietet eine Übersicht über Firewallregeln. Weitere Informationen zum Erstellen von Firewallregeln und zum Arbeiten damit finden Sie unter VPC-Firewallregeln verwenden.

Weitere Informationen zu Firewalls finden Sie unter Firewall.

Best Practices für Firewallregeln

Beachten Sie beim Entwerfen und Bewerten Ihrer Firewallregeln die folgenden Best Practices:

• Implementieren Sie die Prinzipien der geringsten Berechtigung. Blockieren Sie standardmäßig den gesamten Traffic und lassen Sie nur den erforderlichen Traffic zu. Dazu gehört auch, die Regel auf die benötigten Protokolle und Ports zu beschränken.
• Verwenden Sie hierarchische Firewallregeln, um Traffic zu blockieren, der auf Organisations- oder Ordnerebene nie zugelassen werden sollte.
• Beschränken Sie für "allow"-Regeln die Regeln auf bestimmte VMs, indem Sie das Dienstkonto der VMs angeben.
• Wenn Sie Regeln auf der Grundlage von IP-Adressen erstellen müssen, versuchen Sie, die Anzahl der Regeln zu minimieren. Es ist einfacher, eine Regel zu verfolgen, die Traffic zu einem Bereich von 16 VMs zulässt, als 16 separate Regeln zu verfolgen.
• Aktivieren Sie Logging von Firewallregeln und prüfen Sie mithilfe von Firewall Insights, ob Firewallregeln korrekt verwendet werden. Das Logging von Firewallregeln kann Kosten verursachen. Daher können Sie sie selektiv verwenden.

Firewallregeln in Google Cloud

Beim Erstellen einer VPC-Firewallregel geben Sie ein VPC-Netzwerk sowie eine Gruppe von Komponenten an, mit denen die Aktionen der Regel definiert werden. Mit den Komponenten können Sie auf bestimmte Arten von Traffic verweisen, anhand des Protokolls, der Ports sowie der Quellen und Ziele des Traffics. Weitere Informationen finden Sie unter Komponenten von Firewallregeln.

VPC-Firewallregeln werden mithilfe der Google Cloud Console, des Google Cloud CLI und der REST-API erstellt oder geändert. Beim Erstellen oder Ändern einer Firewallregel geben Sie mit dem Zielparameter der Regel die Instanzen an, auf die sie angewendet werden soll. Beispiele für Firewallregeln finden Sie unter Weitere Konfigurationsbeispiele.

Neben den von Ihnen erstellten Firewallregeln bietet Google Cloud noch weitere Regeln, die eingehende (ingress) oder ausgehende (egress) Verbindungen beeinflussen können:

• Google Cloud blockiert oder begrenzt einen bestimmten Traffic. Weitere Informationen finden Sie unter Blockierter und begrenzter Traffic.

• Google Cloud lässt die Kommunikation zwischen einer VM-Instanz und deren jeweiligem Metadatenserver unter 169.254.169.254 immer zu. Weitere Informationen finden Sie unter Permanent zugelassener Traffic.

• Für jedes Netzwerk gelten zwei implizierte Firewallregeln, die ausgehende Verbindungen zulassen und eingehende Verbindungen blockieren. Von Ihnen erstellte Firewallregeln können diese implizierten Regeln überschreiben.

• Das Standardnetzwerk „default“ verfügt bereits über vorkonfigurierte Firewallregeln, die Sie löschen oder bearbeiten können.

Spezifikationen

VPC-Firewallregeln haben folgende Eigenschaften:

• Jede Firewallregel gilt entweder für eingehende (ingress) oder für ausgehende Verbindungen (egress), jedoch nicht für beide Richtungen. Weitere Informationen finden Sie unter Verbindungsrichtung.

• Firewallregeln unterstützen IPv4-Verbindungen. IPv6-Verbindungen werden auch in VPC-Netzwerken unterstützt, für die IPv6 aktiviert ist. Wenn Sie eine Quelle oder ein Ziel für eine Regel für eingehenden oder ausgehenden Traffic in Form einer Adresse angeben, können Sie IPv4- oder IPv6-Adressen oder -Blöcke in CIDR-Notation angeben.

• Jede Firewallregel kann entweder IPv4- oder IPv6-Bereiche enthalten, jedoch nicht beides.

• Die Aktion jeder Firewallregel ist allow oder deny. Die Regel gilt für Verbindungen, solange ihre Anwendung erzwungen wird. Sie können eine Regel beispielsweise zu Fehlerbehebungszwecken deaktivieren.

• Beim Erstellen einer Firewallregel müssen Sie ein VPC-Netzwerk auswählen. Während die Regel auf Instanzebene erzwungen wird, ist ihre Konfiguration einem VPC-Netzwerk zugeordnet. Das heißt, dass Sie Firewallregeln nicht für mehrere VPC-Netzwerke gemeinsam verwenden können. Dies gilt auch für Netzwerke, die über VPC-Netzwerk-Peering verbunden sind, oder für die Verwendung von Cloud VPN-Tunneln.

• VPC-Firewallregeln sind zustandsorientiert:

  • Wenn eine Verbindung durch die Firewall in beide Richtungen zulässig ist, ist auch der mit dieser Verbindung übereinstimmende Traffic zulässig. Sie können eine Firewallregel nicht so konfigurieren, dass der zugehörige Antworttraffic abgelehnt wird.
  • Der zurückgegebene Traffic muss mit dem 5-Tupel (Quell-IP, Ziel-IP, Quellport, Zielport, Protokoll) des akzeptierten Anfragetraffics übereinstimmen, wobei die Quell- und Zieladressen sowie die Quell- und Zielports jedoch umgekehrt sind.
  • Google Cloud ordnet eingehende Pakete mithilfe einer Tabelle zum Tracking der Verbindung den entsprechenden ausgehenden Paketen zu. IPv4-Verbindungen unterstützen TCP-, UDP-, SCTP- und ICMP-Protokolle. IPv6-Verbindungen unterstützen TCP-, UDP-, SCTP- und ICMPv6-Protokolle.
  • Google Cloud implementiert Verbindungs-Tracking unabhängig davon, ob das Protokoll Verbindungen unterstützt. Wird eine Verbindung zwischen einer Quelle und einem Ziel (für eine Eingangsregel) oder zwischen einem Ziel und einem Bestimmungsort (für eine Ausgangsregel) zugelassen, ist der gesamte Antworttraffic zulässig, solange der Nachverfolgungsstatus der Firewall für die Verbindung aktiv ist. Der Nachverfolgungsstatus einer Firewallregel gilt als aktiv, wenn alle 10 Minuten mindestens ein Paket gesendet wird.
  • Wenn eine fragmentierte Verbindung über die Firewall zulässig ist, verwendet Google Cloud das Verbindungs-Tracking, um nur das erste Fragment des Rücktraffics zuzulassen. Damit nachfolgende Rückgabefragmente zugelassen werden, müssen Sie eine Firewallregel hinzufügen.
  • ICMP-Antworttraffic, wie z. B. „ICMP TYPE 3, DESTINATION UNREACHABLE“, der als Antwort auf eine zulässige TCP/UDP-Verbindung generiert wird, wird von der Firewall zugelassen. Dieses Verhalten entspricht RFC 792.

• VCP-Firewallregeln fügen fragmentierte TCP-Pakete nicht wieder zusammen. Somit wird eine Firewallregel für das TCP-Protokoll nur auf das erste Fragment angewendet, da dies den TCP-Header enthält. Für das TCP-Protokoll geltende Firewallregeln sind nicht auf nachfolgende TCP-Fragmente anwendbar.

• Die maximale Anzahl nachverfolgter Verbindungen in der Firewallregeltabelle hängt von der Anzahl der zustandsorientierten Verbindungen ab, die vom Maschinentyp der Instanz unterstützt werden: Wenn die maximale Anzahl nachverfolgter Verbindungen überschritten wird, wird das Tracking für die Verbindungen mit dem längsten Intervall der Inaktivität beendet, damit neue Verbindungen nachverfolgt werden können.

  Maschinentyp der Instanz	Maximale Anzahl an zustandsorientierten Verbindungen
  Maschinentypen mit gemeinsam genutztem Kern	130.000
  Instanzen mit 1–8 vCPUs	130.000 Verbindungen pro vCPU
  Instanzen mit mehr als acht vCPUs	1.040.000 (130.000 × 8) Verbindungen insgesamt

Implizierte Regeln

Jedes VPC-Netzwerk hat zwei implizierte IPv4-Firewallregeln. Wenn IPv6 in einem VPC-Netzwerk aktiviert ist, verfügt das Netzwerk außerdem über zwei implizite IPv6-Firewallregeln. Diese Regeln werden in der Google Cloud Console nicht angezeigt.

Die implizierten IPv4-Firewallregeln gelten für alle VPC-Netzwerke, unabhängig davon, wie die Netzwerke erstellt wurden und ob sie sich im automatischen oder benutzerdefinierten Modus befinden. Das Standardnetzwerk hat die gleichen implizierten Regeln.

• Implizierte IPv4-Regel zum Zulassen von ausgehendem Traffic. Eine Regel für ausgehenden Traffic mit der Aktion allow, dem Bestimmungsort 0.0.0.0/0 und der niedrigsten Priorität (65535) lässt jede Instanz Traffic an einen beliebigen Bestimmungsort senden, mit Ausnahme des Traffics, der von Google Cloud blockiert wird. Der ausgehende Zugriff kann über eine Firewallregel mit höherer Priorität eingeschränkt werden. Der Internetzugriff ist zulässig, wenn keine anderen Firewallregeln den ausgehenden Traffic ablehnen und wenn die Instanz eine externe IP-Adresse hat oder eine Cloud NAT-Instanz verwendet. Weitere Informationen finden Sie unter Anforderungen an den Internetzugang.

• Implizierte IPv4-Regel zum Ablehnen von eingehendem Traffic. Eine Eingangsregel mit der Aktion deny, der Quelle 0.0.0.0/0 und der niedrigsten Priorität (65535) schützt alle Instanzen, indem eingehende Verbindungen blockiert werden. Der eingehende Zugriff kann über eine Regel mit höherer Priorität zugelassen werden. Für das Standardnetzwerk "default" sind zusätzliche Regeln vorhanden, mit denen diese Regel überschrieben wird. Bestimmte Arten von eingehenden Verbindungen sind somit zugelassen.

Wenn IPv6 aktiviert ist, enthält das VPC-Netzwerk auch diese beiden implizierten Regeln:

• Implizierte IPv6-Regel zum Zulassen von ausgehendem Traffic. Eine Regel für ausgehenden Traffic mit der Aktion allow, dem Bestimmungsort ::/0 und der niedrigsten Priorität (65535) lässt jede Instanz Traffic an einen beliebigen Bestimmungsort senden, mit Ausnahme des Traffics, der von Google Cloud blockiert wird. Der ausgehende Zugriff kann über eine Firewallregel mit höherer Priorität eingeschränkt werden. Der Internetzugriff ist zulässig, wenn keine anderen Firewallregeln den ausgehenden Traffic ablehnen und wenn die Instanz eine externe IP-Adresse hat.

• Implizierte IPv6-Regel zum Ablehnen von eingehendem Traffic. Eine Eingangsregel mit der Aktion deny, der Quelle ::/0 und der niedrigsten Priorität (65535) schützt alle Instanzen, indem eingehende Verbindungen blockiert werden. Der eingehende Zugriff kann über eine Regel mit höherer Priorität zugelassen werden.

Die implizierten Regeln können nicht entfernt werden, haben aber die niedrigste Priorität. Dabei können Sie Regeln erstellen, die diese Regeln überschreiben, solange Ihre Regeln eine höhere Priorität haben (Prioritätswerte kleiner als 65535). Da deny-Regeln Vorrang vor allow-Regeln derselben Priorität haben, wird eine allow-Eingangsregel mit einer Priorität von 65535 niemals wirksam.

Vorkonfigurierte Regeln im Standardnetzwerk "default"

Das Standardnetzwerk "default" enthält vorkonfigurierte Firewallregeln, die eingehende Verbindungen für Instanzen zulassen. Diese Regeln können nach Bedarf gelöscht oder geändert werden:

Regelname	Richtung	Priorität	Quellbereiche	Aktion	Protokolle und Ports	Beschreibung
default-allow-internal	ingress	65534	10.128.0.0/9	allow	tcp:0-65535 udp:0-65535 icmp	Lässt eingehende Verbindungen von anderen Instanzen innerhalb desselben VPC-Netzwerks zu VM-Instanzen zu.
default-allow-ssh	ingress	65534	0.0.0.0/0	allow	tcp:22	Ermöglicht die Verbindung zu Instanzen mit Tools wie ssh, scp oder sftp.
default-allow-rdp	ingress	65534	0.0.0.0/0	allow	tcp:3389	Ermöglicht die Verbindung zu Instanzen mit dem Microsoft Remote Desktop Protocol (RDP).
default-allow-icmp	ingress	65534	0.0.0.0/0	allow	icmp	Ermöglicht die Verwendung von Tools wie ping.

Sie können ähnliche Firewallregeln für andere Netzwerke als das Standardnetzwerk erstellen. Weitere Informationen finden Sie unter Firewallregeln für gängige Anwendungsfälle konfigurieren.

Gesperrter und eingeschränkter Traffic

Getrennt von VPC-Firewallregeln und hierarchischen Firewallrichtlinien blockiert oder begrenzt Google Cloud bestimmten Traffic, wie in der folgenden Tabelle beschrieben.

Traffictyp	Details
Paketrate und Bandbreite Gilt für: Alle ausgehenden Pakete Alle eingehenden Pakete	Google Cloud berücksichtigt die Bandbreite pro VM-Instanz für jede Netzwerkschnittstelle (NIC) oder IP-Adresse. Der Maschinentyp einer VM definiert die maximal mögliche Rate für ausgehenden Traffic. Diese kann jedoch nur in bestimmten Situationen erreicht werden. Weitere Informationen finden Sie in der Compute Engine-Dokumentation unter Netzwerkbandbreite.
DHCP-Angebote und -Bestätigungen Gilt für: Eingehende Pakete an UDP-Port 68 (DHCPv4) Eingehende Pakete an UDP-Port 546 (DHCPv6)	Google Cloud blockiert eingehende DHCP-Angebote und Bestätigungen aus allen Quellen mit Ausnahme von DHCP-Paketen vom Metadatenserver.
Von externen Google Cloud-IP-Adressen unterstützte Protokolle Gilt für: Eingehende Pakete an externe IP-Adressen	Externe IPv4- und IPv6-Adressen akzeptieren nur TCP-, UDP-, ICMP-, IPIP-, AH-, ESP-, SCTP- und GRE-Pakete. Für Ressourcen, die externe IP-Adressen verwenden, gelten zusätzliche Protokolleinschränkungen: Weiterleitungsregeln für die Protokollweiterleitung, externe Application Load Balancer ,Externe Proxy Network Load Balancer undExterne Passthrough Network Load Balancer verarbeiten nur die Protokolle und Ports, die in der Weiterleitungsregel konfiguriert sind. Cloud VPN-Gateways akzeptieren nur VPN-Protokolle.
SMTP-Traffic (Port 25) Gilt für: Ausgehende Pakete zu externen IP-Adressen an TCP-Port 25	Standardmäßig blockiert Google Cloud ausgehende Pakete, die an den TCP-Zielport 25 einer externen IP-Adresse gesendet werden (einschließlich einer externen IP-Adresse einer anderen Google Cloud-Ressource). Dieser Traffic wird jedoch nicht in Projekten blockiert, die ausgewählten Google Cloud-Kunden gehören. In der Google Cloud Console wird auf der VPC-Netzwerkseite und der Firewallrichtlinienseite eine Meldung angezeigt, die angibt, ob SMTP-Port 25 in Ihrem Projekt zulässig ist oder nicht. Dieser Block gilt nicht für ausgehende Pakete, die an den TCP-Zielport 25 einer Internen IP-Adresse gesendet werden, einschließlich einer privat verwendeten öffentlichen IP-Adresse in einem VPC-Netzwerk oder einem lokalen Netzwerk. Wenn externer SMTP-Ausgang auf Port 25 in Ihrem Projekt zulässig ist und Sie diese Art von Traffic senden möchten, müssen die folgenden zusätzlichen Bedingungen erfüllt sein: Firewallregeln für ausgehenden Traffic im VPC-Netzwerk und hierarchische Firewallrichtlinien, die für das VPC-Netzwerk gelten, müssen ausgehenden Traffic zur externen IP-Adresse über TCP-Port 25 zulassen. Die implizierten Regeln zum Zulassen von ausgehendem Traffic erfüllen diese Anforderung, da sie den ausgehenden Traffic zu (und feststehende eingehende Antworten von) jeder IP-Adresse zulassen. Die anwendbare Route für das Ziel muss den nächsten Hop des Standard-Internetgateways verwenden. Die vom System generierten Standardrouten erfüllen diese Anforderung. Die Instanz, die Pakete an die externe IP-Adresse sendet, muss die Anforderungen für den Internetzugriff erfüllen. Sie können ausgehenden SMTP-Ausgang verhindern. Erstellen Sie dazu VPC-Firewallregeln für ausgehenden Traffic oder hierarchische Firewallrichtlinien.

Permanent zugelassener Traffic

Für VM-Instanzen gelten VPC-Firewallregeln und hierarchische Firewallrichtlinien nicht für Folgendes:

• Pakete, die an den Google Cloud-Metadatenserver gesendet und von diesem empfangen werden

• Pakete, die an eine IP-Adresse gesendet werden, die einer der Netzwerkschnittstellen (NICs) der Instanz zugewiesen ist, bei denen Pakete innerhalb der VM selbst verbleiben. IP-Adressen, die der NIC einer Instanz zugewiesen sind, sind:

  • Die primäre interne IPv4-Adresse der Netzwerkkarte
  • Jede interne IPv4-Adresse aus einem Alias-IP-Bereich der NIC
  • Beliebige von den der NIC zugewiesenen IPv6-Adressen, wenn IPv6 im Subnetz konfiguriert ist
  • Eine interne oder externe IPv4-Adresse, die einer Weiterleitungsregel für das Load-Balancing oder die Protokollweiterleitung zugeordnet ist, wenn die Instanz ein Backend für den Load-Balancer oder eine Zielinstanz für die Protokollweiterleitung ist
  • Loopback-Adressen
  • Adressen, die als Teil der Netzwerk-Overlay-Software konfiguriert wurden, die Sie in der Instanz selbst ausführen

Google Cloud-Metadatenserver

Google Cloud betreibt neben jeder Instanz unter 169.254.169.254 einen lokalen Metadatenserver. Dieser Server ist für den Betrieb der Instanz unerlässlich. Daher kann die Instanz unabhängig von den konfigurierten Firewallregeln darauf zugreifen. Der Metadatenserver stellt die folgenden grundlegenden Dienste für die Instanz bereit:

• DHCP
• DNS-Auflösung entsprechend der Reihenfolge der Namensauflösung für das VPC-Netzwerk.
• Instanzmetadaten
• Network Time Protocol (NTP)

Produktinteraktionen

In den folgenden Abschnitten wird beschrieben, wie Firewallregeln und hierarchische Firewallrichtlinien mit anderen Google Cloud-Produkten interagieren.

Firewallregeln und Passthrough LoadBalancer

VPC-Firewallregeln und hierarchische Firewallrichtlinien steuern, welche Protokolle und Ports der Weiterleitungsregel auf die Back-Ends des Passthrough Load Balancers zugreifen dürfen. Weitere Informationen finden Sie unter:

• Firewallregeln in der Dokumentation zum externen Passthrough Network Load Balancer
• Firewallregeln in der Dokumentation zum internen Passthrough Network Load Balancer

Firewallregeln und Proxy-Load-Balancer

Für externe Application Load Balancer, interne Application Load Balancer, interne Proxy Network Load Balancer und externe Proxy Network Load Balancer steuern VPC-Firewallregeln und hierarchische Firewallrichtlinien nicht, welche Protokolle und Ports von der IP-Adresse der Weiterleitungsregel des Proxy Load Balancers akzeptiert werden. Die Weiterleitungsregel allein bestimmt, welche Protokolle und Ports vom Proxy-Load-Balancer akzeptiert werden.

VPC-Firewallregeln und hierarchische Firewallrichtlinien steuern die Kommunikation dieser Proxy-Load-Balancer mit ihren Back-Ends. Weitere Informationen finden Sie unter:

• Firewallregeln in der Dokumentation zum externen Application Load Balancer
• Firewallregeln in der Dokumentation zum internen Application Load Balancer
• Firewallregeln in der Dokumentation zum internen Proxy Network Load Balancer
• Firewallregeln in der Dokumentation zum externen Proxy Network Load Balancer

Firewallregeln und Cloud VPN

Firewallregeln und hierarchische Firewallrichtlinien bestimmen nicht, welche Protokolle und Ports vom Cloud VPN-Gateway akzeptiert werden.

Cloud VPN-Gateways akzeptieren nur Pakete für die in den Cloud VPN-Spezifikationen beschriebenen Protokolle und Ports.

Firewallregeln und GKE

Google Kubernetes Engine erstellt und verwaltet Firewallregeln automatisch, wenn Sie einen Cluster oder Ressourcen im Cluster erstellen (einschließlich Dienste und Ingress-Instanzen). Weitere Informationen finden Sie in der Google Kubernetes Engine-Dokumentation unter Automatisch erstellte Firewallregeln.

Komponenten von Firewallregeln

Jede Firewallregel besteht aus den folgenden Konfigurationskomponenten:

• Eine Richtung aus der Perspektive des Ziels. Die Richtung kann entweder eingehend oder ausgehend sein.

• Eine numerische Priorität, die dafür ausschlaggebend ist, ob die Regel angewendet wird. Es wird nur die Regel mit der höchsten Priorität (niedrigste Prioritätsnummer) angewendet, wenn der Traffic mit ihren anderen Komponenten übereinstimmt. In Konflikt stehende Regeln mit niedrigerer Priorität werden ignoriert.

• Eine Aktion bei Übereinstimmung, entweder allow oder deny, die ausschlaggebend dafür ist, ob die Regel Verbindungen zulässt oder blockiert.

• Der Erzwingungsstatus der Firewallregel: Sie können Firewallregeln aktivieren und deaktivieren, ohne sie zu löschen.

• Ein Ziel, mit dem die Instanzen definiert werden, auf die die Regel angewendet wird, einschließlich der GKE-Cluster und der Instanzen in der flexiblen App Engine-Umgebung.

• Ein Quell- oder Zielfilter für Paketeigenschaften.

• Das Protokoll (z. B. TCP, UDP oder ICMP) und der Port.

• Eine boolesche Logoption, die Verbindungen, die der Regel entsprechen, in Cloud Logging protokolliert.

Zusammenfassung der Komponenten

Eingangsregel (Ingress)
Priorität	Aktion	Erzwingung	Zielparameter	Quell- und Zielfilter	Protokolle und Ports
Ganzzahl von 0 bis einschließlich 65535; Standard: 1000	allow oder deny	enabled (Standard) oder disabled	Gibt die Instanzen an, die Pakete empfangen.	Quellen für Regeln für eingehenden Traffic Ziele für Regeln für eingehenden Traffic	Geben Sie ein Protokoll oder ein Protokoll und einen Zielport an. Wenn nichts festgelegt ist, gilt die Regel für alle Protokolle und Zielports. Weitere Informationen finden Sie unter Protokolle und Ports.
Ausgangsregel (Egress)
Priorität	Aktion	Erzwingung	Zielparameter	Quell- und Zielfilter	Protokolle und Ports
Ganzzahl von 0 bis einschließlich 65535; Standard: 1000	allow oder deny	enabled (Standard) oder disabled	Gibt die Instanzen an, die Pakete senden.	Quellen für Regeln für ausgehenden Traffic Ziele für Regeln für ausgehenden Traffic	Geben Sie ein Protokoll oder ein Protokoll und einen Zielport an. Wenn nichts festgelegt ist, gilt die Regel für alle Protokolle und Zielports. Weitere Informationen finden Sie unter Protokolle und Ports.

Traffic-Richtung

Sie können Firewallregeln erstellen, die für eingehenden oder ausgehenden Traffic gelten. Eine einzelne Regel kann nicht sowohl für eingehenden als auch für ausgehenden Traffic gelten. Sie können jedoch mehrere Regeln erstellen, um den eingehenden und ausgehenden Traffic zu definieren, den Sie durch die Firewall zulassen oder ablehnen.

• Eingehender Traffic beschreibt Pakete, die in eine Netzwerkschnittstelle eines Ziels eintreten.

• Ausgehender Traffic beschreibt Pakete, die eine Netzwerkschnittstelle eines Ziels verlassen.

• Wenn Sie keine Richtung angeben, verwendet Google Cloud "ingress".

Priorität

Die Priorität einer Firewallregel wird als Ganzzahl von 0 bis einschließlich 65535 angegeben. Niedrigere Werte bedeuten eine höhere Priorität. Wenn Sie beim Erstellen einer Regel keine Priorität angeben, wird dieser die Priorität 1000 zugewiesen.

Die relative Priorität einer Firewallregel im Vergleich zu anderen Regeln ist ausschlaggebend dafür, ob sie angewendet wird. Die Auswertung erfolgt nach folgender Logik:

• Die Regel mit der höchsten Priorität, die für ein Ziel eines bestimmten Traffictyps gilt, hat Vorrang. Die festgelegten Ziele spielen dabei keine Rolle. Beispielsweise überschreibt eine Eingangsregel höherer Priorität für bestimmte Zielports und Protokolle, die für alle Ziele gelten soll, eine ähnlich definierte Regel mit niedrigerer Priorität für dieselben Zielports und Protokolle, die für bestimmte Ziele festgelegt ist.

• Die Regel mit der höchsten Priorität, die für eine bestimmte Protokoll- und Zielportdefinition gilt, hat auch dann Vorrang, wenn die Protokoll- und Zielportdefinition allgemeinerer Art ist. Beispielsweise überschreibt eine Eingangsregel höherer Priorität, die den Traffic für alle Protokolle und Zielports für bestimmte Ziele zulässt, eine Eingangsregel niedrigerer Priorität, die den TCP-Port 22 für die gleichen Ziele ausschließt.

• Eine Regel mit der Aktion deny überschreibt eine andere Regel mit der Aktion allow nur dann, wenn die beiden Regeln die gleiche Priorität haben. Durch Verwendung von relativen Prioritäten können Sie allow-Regeln erstellen, die deny-Regeln überschreiben, und deny-Regeln, die allow-Regeln überschreiben.

• Regeln mit derselben Priorität und derselben Aktion haben das gleiche Ergebnis. Die bei der Auswertung verwendete Regel ist jedoch unbestimmt. Normalerweise spielt es keine Rolle, welche Regel verwendet wird, es sei denn, Sie aktivieren das Logging von Firewallregeln. Wenn in den Logs Firewallregeln in einer einheitlichen und klar definierten Reihenfolge aufgeführt werden sollen, weisen Sie ihnen eindeutige Prioritäten zu.

Betrachten Sie das folgende Beispiel, das aus zwei Firewallregeln besteht:

• Eine Regel für eingehenden Traffic aus den Quellen 0.0.0.0/0 (beliebige IPv4-Adresse), die für alle Ziele, alle Protokolle und alle Zielports gilt und eine deny-Aktion sowie die Priorität 1000 hat.

• Eine Regel für eingehenden Traffic an TCP 80 aus den Quellen 0.0.0.0/0 (beliebige IPv4-Adresse), die für bestimmte Ziele mit dem Netzwerktag webserver gilt und eine allow-Aktion hat.

Die Priorität der zweiten Regel bestimmt, ob TCP-Traffic zu Port 80 für die webserver-Ziele zugelassen wird:

• Wenn für die Priorität der zweiten Regel eine Zahl größer als 1000 festgelegt ist, hat sie eine niedrigere Priorität. Es gilt dann die erste Regel, die den gesamten Traffic ablehnt.

• Wenn für die Priorität der zweiten Regel 1000 festgelegt ist, haben die beiden Regeln identische Prioritäten. Es gilt dann die erste Regel, die den gesamten Traffic ablehnt.

• Wenn für die Priorität der zweiten Regel eine Zahl kleiner als 1000 festgelegt ist, hat die Regel eine höhere Priorität. Dadurch wird Traffic an TCP 80 für die webserver-Ziele zugelassen. Ohne weitere Regeln lehnt die erste Regel weiterhin alle anderen Arten von Traffic zu den webserver-Zielen ab. Dies gilt auch für den gesamten Traffic (inklusive TCP 80) zu Instanzen ohne das Netzwerktag webserver.

Das vorherige Beispiel zeigt, wie Sie mithilfe von Prioritäten selektive allow-Regeln und globale deny-Regeln als Best Practice im Sicherheitsbereich nach dem Prinzip der geringsten Berechtigung implementieren können.

Hinweis: Für jedes Netzwerk gelten zwei implizierte Firewallregeln mit niedriger Priorität, die nicht entfernt werden können. Das Standardnetzwerk „default“ enthält zusätzliche Firewallregeln, die gelöscht werden können. Weitere Informationen finden Sie unter Implizierte Regeln und vorkonfigurierte Regeln.

Aktion bei Übereinstimmung

Die Aktionskomponente einer Firewallregel bestimmt, ob Traffic zugelassen oder blockiert wird, vorbehaltlich der anderen Komponenten der Regel:

• Die Aktion allow lässt Verbindungen zu, deren Komponenten den anderen angegebenen Komponenten entsprechen.

• Die Aktion deny blockiert Verbindungen, deren Komponenten den anderen angegebenen Komponenten entsprechen.

Hinweis: Für eine Firewallregel kann nur eine Aktionskomponente festgelegt werden. allow und deny können nicht in derselben Regel angegeben werden. Erstellen Sie separate Firewallregeln mit unterschiedlichen Prioritäten, um die Reihenfolge festzulegen, in der die Regeln angewendet werden sollen.

Erzwingung

Sie können wählen, ob eine Firewallregel erzwungen werden soll. Legen Sie dazu deren Zustand auf enabled oder disabled fest. Sie können den Erzwingungszustand festlegen, wenn Sie eine Regel erstellen oder eine Regel aktualisieren.

Wenn Sie beim Erstellen einer neuen Firewallregel keinen Erzwingungsstatus festlegen, lautet die Firewallregel automatisch enabled.

Anwendungsfälle

Das Deaktivieren und Aktivieren ist für die Fehlerbehebung und Wartung hilfreich. Sie können die Erzwingung einer Firewallregel in den folgenden Situationen ändern:

• Für die Fehlerbehebung: In Verbindung mit Logging von Firewallregeln können Sie eine Firewallregel vorübergehend deaktivieren, um festzustellen, ob die Regel für das Blockieren oder Zulassen von Traffic verantwortlich ist. Dies ist dann nützlich, wenn mehrere Firewallregeln für denselben Traffic gelten. Das Deaktivieren und Aktivieren von Regeln ist nützlicher als das Löschen und Neuerstellen von Regeln, da keine der anderen Komponenten der Regel verloren geht.

• Für die Wartung: Durch die Deaktivierung von Firewallregeln können regelmäßige Wartungen vereinfacht werden. Sie können beispielsweise eine Firewallregel für eingehenden Traffic aktivieren, die den SSH-Zugriff nur dann zulässt, wenn Sie Wartungen mit SSH ausführen müssen. Wenn Sie keine Wartung ausführen, können Sie die Regel deaktivieren.

Auswirkungen auf vorhandenen Traffic

Wenn Sie den Erzwingungsstatus einer Firewallregel ändern oder eine neue Regel mit dem Namen enforced erstellen, gilt die Änderung nur für neue Verbindungen. Vorhandene Verbindungen sind nicht von der Änderung betroffen.

Protokolle und Ports

Durch Angabe von Protokollen oder Protokollen und Zielports lässt sich der Umfang einer Firewallregel einschränken. Sie können ein Protokoll oder eine Kombination aus Protokollen und ihren Zielports festlegen. Wenn Sie weder Protokolle noch Ports angeben, gilt die Firewallregel für den gesamten Traffic mit jedem Protokoll und an allen Ports. Regeln für Quellports werden nicht unterstützt.

Nicht alle Protokolle unterstützen Ports. Beispielsweise gibt es Ports für TCP und UDP, nicht jedoch für ICMP. Das ICMP-Protokoll unterstützt verschiedene ICMP-Typen. Diese sind jedoch keine Ports und können nicht in einer Firewallregel angegeben werden.

Sie können die folgenden Protokollnamen in Firewallregeln verwenden: tcp, udp, icmp (für IPv4 ICMP), esp, ah, sctp und ipip. Für alle anderen Protokolle müssen Sie die IANA-Protokollnummern verwenden.

Viele Protokolle verwenden bei IPv4 und IPv6 denselben Namen und dieselbe Nummer, einige Protokolle wie ICMP jedoch nicht.

Das IPv6-Hop-by-Hop-Protokoll wird in Firewallregeln nicht unterstützt.

In der folgenden Tabelle finden Sie eine Zusammenfassung der gültigen Kombinationen von Protokollen und Zielports für Google Cloud-Firewallregeln.

Spezifikation	Beispiel	Erklärung
Weder Protokoll noch Port	–	Wenn Sie kein Protokoll angeben, gilt die Firewallregel für alle Protokolle und die zugehörigen Zielports.
Protokoll	tcp	Wenn Sie ein Protokoll ohne Portinformationen angeben, gilt die Firewallregel für dieses Protokoll und alle seine zugehörigen Ports.
Protokoll und einzelner Port	tcp:80	Wenn Sie ein Protokoll und einen einzelnen Zielport angeben, gilt die Firewallregel für diesen Zielport des Protokolls.
Protokoll und Portbereich	tcp:20-22	Wenn Sie ein Protokoll und einen Portbereich angeben, gilt die Firewallregel für den Portbereich des Protokolls.
Kombinationen	icmp,tcp:80 tcp:443 udp:67-69	Sie können verschiedene Kombinationen von Protokollen und Zielports angeben, für die die Firewallregel gelten soll. Weitere Informationen finden Sie unter Firewallregeln erstellen.

Wichtig: Ein Port kann nicht allein über die Portnummer festgelegt werden. Wenn Sie nur eine Nummer angeben, interpretiert Google Cloud diese als dezimales IP-Protokoll. Falls Sie beispielsweise lediglich 80 angeben, geht Google Cloud vom IP-Protokoll 80 (ISO-IP) aus, was nicht dasselbe ist wie der TCP-Port 80 (tcp:80).

Ziel, Quelle, Bestimmungsort

Ziele identifizieren die Netzwerkschnittstellen von Instanzen, für die die Firewallregel gilt.

Sie können sowohl Quellparameter als auch Zielparameter angeben, die für die Paketquellen oder Ziele für Firewallregeln für eingehenden und ausgehenden Traffic gelten. Die Richtung der Firewallregel bestimmt die möglichen Werte für die Quell- und Zielparameter.

Zielparameter

Der Zielparameter identifiziert die Netzwerkschnittstellen der Compute Engine-Instanzen, einschließlich GKE-Knoten und Instanzen der flexiblen App Engine-Umgebung.

Sie können die folgenden Ziele für Regeln für eingehenden oder ausgehenden Traffic definieren: Die Ziel- und Quellparameter arbeiten zusammen, wie unter Quelle, Bestimmungsort, Ziel beschrieben.

• Standardziel – alle Instanzen im VPC-Netzwerk. Wenn Sie eine Zielspezifikation weglassen, gilt die Firewallregel für alle Instanzen im VPC-Netzwerk.

• Instanzen nach Ziel-Netzwerktags. Die Firewallregel gilt nur für Instanzen im VPC-Netzwerk mit einem übereinstimmenden Netzwerktag. Die maximale Anzahl von Ziel-Netzwerktags, die Sie pro Firewallregel anwenden können, finden Sie unter VPC-Ressourcenkontingente.

• Instanzen nach Zieldienstkonten. Die Firewallregel gilt nur für Instanzen im VPC-Netzwerk, die ein bestimmtes Dienstkonto verwenden. Die maximale Anzahl an Zieldienstkonten, die Sie pro Firewallregel verwenden können, finden Sie unter VPC-Ressourcenkontingente.

Informationen zu den Vorteilen und Einschränkungen von Ziel-Netzwerktags und Zieldienstkonten finden Sie unter Nach Dienstkonto oder Netzwerktag filtern.

Ziele und IP-Adressen für Regeln für eingehenden Traffic

Die an die Netzwerkschnittstelle einer Ziel-VM weitergeleiteten Pakete werden gemäß den folgenden Bedingungen verarbeitet:

• Wenn die Firewallregel für eingehenden Traffic einen Ziel-IP-Adressbereich enthält, muss das Ziel des Pakets in einen der explizit definierten Ziel-IP-Adressbereiche passen.

• Wenn die Firewallregel für eingehenden Traffic keinen Ziel-IP-Adressbereich enthält, muss das Ziel des Pakets mit einer der folgenden IP-Adressen übereinstimmen:

  • Die primäre interne IPv4-Adresse, die der NIC der Instanz zugewiesen ist.

  • Alle konfigurierten Alias-IP-Bereiche auf der NIC der Instanz.

  • Die externe IPv4-Adresse, die der NIC der Instanz zugeordnet ist.

  • Beliebige IPv6-Adresse, die der NIC zugewiesenen ist, wenn IPv6 im Subnetz konfiguriert ist.

  • Eine interne oder externe IP-Adresse, die mit einer Weiterleitungsregel verbunden ist, die für das Passthrough Load-Balancing verwendet wird, wobei die Instanz ein Backend für einen internen Passthrough Network Load Balancer oder einen externen Passthrough Network Load Balancer ist.

  • Eine interne oder externe IP-Adresse, die einer Weiterleitungsregel für die Protokollweiterleitung zugeordnet ist, wobei auf die Instanz von einer Zielinstanz verwiesen wird.

  • Eine IP-Adresse im Zielbereich einer benutzerdefinierten statischen Route, die die Instanz als VM des nächsten Hops verwendet (next-hop-instance oder next-hop-address).

  • Eine IP-Adresse innerhalb des Zielbereichs einer benutzerdefinierten statischen Route, die einen internen Passthrough Network Load Balancer (next-hop-ilb) als nächsten Hop verwendet, wenn die VM ein Backend für diesen Load-Balancer ist.

Ziele und IP-Adressen für Regeln für ausgehenden Traffic

Die Verarbeitung von Paketen, die von der Netzwerkschnittstelle eines Ziels ausgegeben werden, hängt von der Konfiguration der IP-Weiterleitung auf der Ziel-VM ab. Die IP-Weiterleitung ist standardmäßig deaktiviert.

• Wenn für die Ziel-VM die IP-Weiterleitung deaktiviert ist, kann die VM Pakete mit den folgenden Quellen ausgeben:

  • Die primäre interne IPv4-Adresse der NIC einer Instanz.

  • Jeder konfigurierte Alias-IP-Bereich auf der NIC einer Instanz.

  • Beliebige IPv6-Adresse, die der NIC zugewiesenen ist, wenn IPv6 im Subnetz konfiguriert ist.

  • Eine interne oder externe IP-Adresse, die mit einer Weiterleitungsregel verbunden ist, für Passthrough Load-Balancing oder Protokollweiterleitung, wenn die Instanz ein Backend für einen internen Passthrough-Network Load Balancer oder einen externen Passthrough-Network Load Balancer ist oder von einer Zielinstanz referenziert wird.

  Wenn die Firewallregel für ausgehenden Traffic Quell-IP-Adressbereiche enthält, sind die Ziel-VMs weiterhin auf die zuvor erwähnten Quell-IP-Adressen beschränkt. Sie können diesen Satz jedoch mit dem Quellparameter verfeinern (Funktion in der Vorabversion). Wenn Sie einen Quellparameter verwenden, ohne die IP-Weiterleitung zu aktivieren, wird der Satz möglicher Paketquelladressen nicht erweitert.

  Wenn die Firewallregel für ausgehenden Traffic keinen Quell-IP-Adressbereich enthält, sind alle zuvor genannten Quell-IP-Adressen zulässig.

• Wenn für die Ziel-VM die IP-Weiterleitung aktiviert ist, kann die VM Pakete mit beliebigen Quelladressen ausgeben. Mit dem Quellparameter können Sie den Satz zulässiger Paketquellen genauer definieren.

Quellparameter

Die Werte der Quellparameter hängen von der Richtung der Firewallregel ab.

Quellen für Regeln für eingehenden Traffic

Sie können die folgenden Quellen für Firewallregeln für eingehenden Traffic verwenden:

• Standardquellbereich: Wenn Sie eine Quellspezifikation in einer Regel für eingehenden Traffic weglassen, verwendet Google Cloud den Standard-IPv4-Adressbereich 0.0.0.0/0 (beliebige IPv4-Adresse). Der Standardwert enthält keine IPv6-Quellen.

• IPv4-Quellbereiche: Eine Liste von IPv4-Adressen im CIDR-Format.

• IPv6-Quellbereiche: Eine Liste von IPv6-Adressen im CIDR-Format.

• Quell-Netzwerktags: Ein oder mehrere Netzwerktags, die Netzwerkschnittstellen von VM-Instanzen im selben VPC-Netzwerk wie die Firewallregel identifizieren. Die maximale Anzahl von Quell-Netzwerktags pro Firewallregel finden Sie unter VPC-Ressourcenkontingente. Weitere Informationen zu Paketquelladressen bei Verwendung dieser impliziten Quellspezifikation finden Sie unter Wie Quell-Netzwerktags und Quelldienstkonten Paketquellen implizieren.

• Quelldienstkonten: Ein oder mehrere Dienstkonten, die Netzwerkschnittstellen von VM-Instanzen im selben VPC-Netzwerk wie die Firewallregel identifizieren. Die maximale Anzahl von Quelldienstkonten pro Firewallregel finden Sie unter VPC-Ressourcenkontingente. Weitere Informationen zu Paketquelladressen bei Verwendung dieser impliziten Quellspezifikation finden Sie unter Wie Quell-Netzwerktags und Quelldienstkonten Paketquellen implizieren.

• Eine gültige Quellkombination: Bei allen folgenden Kombinationen ist der effektive Quellsatz die Vereinigung der IPv4- oder IPv6-Adressen, die explizit angegeben werden, und der IP-Adressbereiche, die durch das Quell-Netzwerktag oder das Quelldienstkonto impliziert werden:

  • Eine Kombination aus Quell-IPv4-Bereichen und Quell-Netzwerktags.
  • Eine Kombination aus Quell-IPv6-Bereichen und Quell-Netzwerktags.
  • Eine Kombination aus Quell-IPv4-Bereichen und Quelldienstkonten.
  • Eine Kombination aus Quell-IPv6-Bereichen und Quelldienstkonten.

Wichtig: Netzwerktags und Dienstkonten können nicht in derselben Firewallregel verwendet werden. Weitere Informationen finden Sie unter Nach Dienstkonto oder Netzwerktag filtern.

Wie Quell-Netzwerktags und Quelldienstkonten Paketquellen implizieren

Wenn eine Firewallregel für eingehenden Traffic ein Quell-Netzwerktag verwendet, müssen die Pakete von einer Netzwerkschnittstelle ausgegeben werden, die die folgenden Kriterien erfüllt:

• Die Netzwerkschnittstelle verwendet dasselbe VPC-Netzwerk wie die Firewallregel.
• Die Netzwerkschnittstelle ist einer VM zugeordnet, deren Netzwerktag mit dem Quell-Netzwerktag der Firewallregel übereinstimmt.

Wenn eine Firewallregel für eingehenden Traffic ein Quelldienstkonto verwendet, müssen die Pakete von einer Netzwerkschnittstelle ausgegeben werden, die die folgenden Kriterien erfüllt:

• Die Netzwerkschnittstelle verwendet dasselbe VPC-Netzwerk wie die Firewallregel.
• Die Netzwerkschnittstelle ist einer VM zugeordnet, deren Dienstkonto mit dem Quelldienstkonto der Firewallregel übereinstimmt.

Wenn eine Firewallregel für eingehenden Traffic entweder ein Quell-Netzwerktag oder ein Quelldienstkonto verwendet, muss nicht nur die Netzwerkschnittstelle angegeben werden, sondern die von der Netzwerkschnittstelle der VM ausgegebenen Pakete müssen auch eine der folgenden gültigen Quell-IP-Adressen verwenden:

• Die primäre interne IPv4-Adresse dieser Netzwerkschnittstelle.
• Alle IPv6-Adressen, die dieser Netzwerkschnittstelle zugewiesen sind.

Wenn eine Firewallregel für eingehenden Traffic auch Ziel-IP-Adressbereiche enthält, wird die an ein Netzwerk-Tag gebundene Netzwerkschnittstelle in dieselbe IP-Version aufgelöst wie der Ziel-IP-Bereich.

Bei Verwendung von Quell-Netzwerktags oder Quelldienstkonten werden keine anderen Paketquell-IP-Adressen impliziert. Beispielsweise werden Alias-IP-Bereiche und externe IPv4-Adressen, die der Netzwerkschnittstelle zugeordnet sind, ausgeschlossen. Wenn Sie Firewallregeln für eingehenden Traffic erstellen müssen, deren Quellen Alias-IP-Adressbereiche oder externe IPv4-Adressen enthalten, verwenden Sie IPv4-Quellbereiche.

Quellen für Regeln für ausgehenden Traffic

Sie können die folgenden Quellen für Firewallregeln für ausgehenden Traffic verwenden:

• Standard – durch Ziel impliziert. Wenn Sie den Quellparameter in einer Regel für ausgehenden Traffic weglassen, werden die Paketquellen implizit wie in Ziele und IP-Adressen für Regeln für ausgehenden Traffic beschrieben definiert.

• Quell-IPv4-Bereiche. Eine Liste von IPv4-Adressen im CIDR-Format.

• Quell-IPv6-Bereiche. Eine Liste von IPv6-Adressen im CIDR-Format.

Befolgen Sie diese Richtlinien, um Quell-IP-Adressbereiche für Regeln für ausgehenden Traffic hinzuzufügen:

• Wenn einer VM-Schnittstelle sowohl interne als auch externe IPv4-Adressen zugewiesen sind, wird nur die interne IPv4-Adresse während der Regelauswertung verwendet.

• Wenn Sie sowohl Quell- als auch Zielparameter in einer Regel für ausgehenden Traffic angeben, verwenden Sie für beide Parameter dieselbe IP-Version. Sie können entweder einen IPv4-Adressbereich oder einen IPv6-Adressbereich verwenden, aber nicht beides. Weitere Informationen finden Sie unter Ziele für Ausgangsregeln.

Bestimmungsortparameter

Ziele können mithilfe von IP-Adressbereichen angegeben werden, die sowohl von Regeln für eingehenden Traffic als auch von Regeln für ausgehenden Traffic unterstützt werden. Das Standardverhalten des Ziels hängt von der Richtung der Regel ab.

Ziele für Regeln für eingehenden Traffic

Sie können die folgenden Ziele für Firewallregeln für eingehenden Traffic verwenden:

• Standard – durch Ziel impliziert. Wenn Sie den Zielparameter in einer Regel für eingehenden Traffic weglassen, werden die Paketziele implizit definiert, wie unter Ziele und IP-Adressen für Regeln für eingehenden Traffic beschrieben.

• Ziel-IPv4-Bereiche. Eine Liste von IPv4-Adressen im CIDR-Format.

• Ziel-IPv6-Bereiche. Eine Liste von IPv6-Adressen im CIDR-Format.

Befolgen Sie diese Richtlinien, um Ziel-IP-Adressbereiche für Regeln für eingehenden Traffic hinzuzufügen:

• Wenn einer VM-Schnittstelle sowohl interne als auch externe IPv4-Adressen zugewiesen sind, wird nur die interne IPv4-Adresse während der Regelauswertung verwendet.

• Wenn Sie sowohl Quell- als auch Zielparameter in einer Regel für eingehenden Traffic angeben, werden die Quellparameter in dieselbe IP-Version wie der Ziel-IP-Adressbereich aufgelöst. Weitere Informationen zum Definieren von Quellen für Regeln für eingehenden Traffic finden Sie unter Quellen für Regeln für eingehenden Traffic.

Ziele für Regeln für ausgehenden Traffic

Sie können die folgenden Ziele für Firewallregeln für ausgehenden Traffic verwenden:

• Standardzielbereich. Wenn Sie in einer Regel für ausgehenden Traffic eine Zielspezifikation weglassen, verwendet Google Cloud den Standard-IPv4-Adressbereich 0.0.0.0/0 (beliebige IPv4-Adresse). Der Standardwert enthält keine IPv6-Ziele.

• Ziel-IPv4-Bereiche. Eine Liste von IPv4-Adressen im CIDR-Format.

• Ziel-IPv6-Bereiche. Eine Liste von IPv6-Adressen im CIDR-Format.

Quell- und Zielfilterung nach Dienstkonto

Mithilfe von Dienstkonten können Sie spezifischere Firewallregeln erstellen:

• Bei Eingangs- und Ausgangsregeln lassen sich mit Dienstkonten Ziele angeben.

• Bei Eingangsregeln können Sie die Quelle für eingehende Pakete als primäre interne IP-Adresse einer beliebigen VM in dem Netzwerk angeben, in dem die VM ein bestimmtes Dienstkonto verwendet.

Das Dienstkonto muss im selben Projekt wie die Firewallregel erstellt werden, bevor Sie eine Firewallregel erstellen, die darauf basiert. Das System hindert Sie nicht daran, eine Regel zu erstellen, die ein Dienstkonto aus einem anderen Projekt verwendet. Die Regel wird jedoch nicht erzwungen, wenn das Dienstkonto im Projekt der Firewallregel nicht vorhanden ist.

Hinweis: Sie können keine Workload Identity-Dienstkonten in den VPC-Firewallregeln für die Quell- und Zielfilterung verwenden.

Firewallregeln, die Instanzen anhand von Dienstkonten identifizieren, gelten für neue Instanzen, die mit dem Dienstkonto erstellt und diesem zugeordnet wurden, und für vorhandene Instanzen, deren Dienstkonten geändert wurden. Wenn Sie das einer Instanz zugeordnete Dienstkonto ändern, müssen Sie die Instanz beenden und neu starten. Sie können Dienstkonten einzelnen Instanzen und Instanzvorlagen zuordnen, die von verwalteten Instanzgruppen verwendet werden.

Hinweis: In Projekten mit einer eigenständigen VPC (VPC, die nicht Teil einer freigegebenen VPC ist), können Sie nur Dienstkonten aus diesem Projekt als Kriterien der Firewallregel verwenden. In Projekten mit freigegebener VPC können Sie Dienstkonten aus dem Hostprojekt oder einem beliebigen Dienstprojekt als Kriterium für die Firewallregel verwenden. Wenn Sie eine Firewallregel erstellen, die Dienstkonten verwendet, die nicht diesen beiden Szenarien entsprechen, wird die Firewallregel nicht erzwungen.

Nach Dienstkonto oder Netzwerktag filtern

Dieser Abschnitt beleuchtet wichtige Punkte, die Sie berücksichtigen sollten, wenn Sie sich beim Definieren von Zielen und Quellen für Eingangsregeln zwischen Dienstkonten und Netzwerktags entscheiden.

Wenn Sie strikte Kontrolle darüber benötigen, wie Firewallregeln auf VMs angewendet werden, verwenden Sie Zieldienstkonten und Quelldienstkonten anstelle von Ziel- und Quell-Netzwerktags:

• Ein Netzwerktag ist ein beliebiges Attribut. Jedes IAM-Hauptkonto (Identity and Access Management), das die Berechtigung zum Bearbeiten einer Instanz hat, kann einer Instanz ein oder mehrere Netzwerktags zuordnen. IAM-Hauptkonten mit der Rolle Compute Engine-Instanzadministrator für ein Projekt haben diese Berechtigung. Wenn IAM-Hauptkonten eine Instanz bearbeiten dürfen, können sie deren Netzwerktags ändern. Dies führt unter Umständen dazu, dass sich auch die geltenden Firewallregeln für diese Instanz ändern.

• Ein Dienstkonto steht für eine Identität, die einer Instanz zugeordnet ist. Einer Instanz kann nur ein einziges Dienstkonto zugeordnet werden. Sie steuern den Zugriff auf das Dienstkonto, indem Sie die Zuweisung der Rolle Dienstkontonutzer an andere IAM-Hauptkonten kontrollieren. Damit ein IAM-Hauptkonto eine Instanz über ein Dienstkonto starten kann, muss dieses Hauptkonto die Rolle "Dienstkontonutzer" oder zumindest dieses Dienstkonto haben, um entsprechende Instanzen zu erstellen (z. B. Rolle "Compute Engine-Instanzadministrator" hinzu.

Die Kombination von Dienstkonten und Netzwerktags in einer Firewallregel ist nicht möglich:

• Sie können Zieldienstkonten und Ziel-Netzwerktags nicht zusammen in einer Firewallregel für eingehenden oder ausgehenden Traffic verwenden.

• Wenn Sie Ziele nach Ziel-Netzwerktag oder Zieldienstkonto angeben, sind die folgenden Quellen für eingehende Firewallregeln ungültig.

  Ziele	Ungültige Quellen
  Ziel-Netzwerktags	Quelldienstkonten Kombination aus Quell-IP-Bereichen und Quelldienstkonten
  Zieldienstkonto	Quell-Netzwerktags Kombination aus Quell-IP-Bereichen und Quell-Netzwerktags

Folgende operativen Aspekte sollten Sie bei Dienstkonten und Netzwerktags berücksichtigen:

• Wenn Sie ein Dienstkonto für eine Instanz ändern möchten, müssen Sie diese beenden und dann neu starten. Netzwerktags können bei laufender Instanz hinzugefügt oder entfernt werden.

• Es gibt eine maximale Anzahl von Zieldienstkonten, Quelldienstkonten, Zielnetzwerktags und Quellnetzwerktags, die für Firewallregeln angegeben werden können. Weitere Informationen finden Sie unter VPC-Ressourcenkontingente.

• Wenn Sie Instanzen anhand des Netzwerktags identifizieren, gilt die Firewallregel für die primäre interne IP-Adresse der Instanz.

• Firewallregeln für Dienstkonten gelten für den GKE-Knoten, nicht für den GKE-Pod.

Rollen und Berechtigungen

In der folgenden Tabelle werden die IAM-Berechtigungen (Identity and Access Management) beschrieben, die Sie zur Verwendung von VPC-Firewallregeln benötigen.

Aufgabe	Erforderliche Berechtigung	Beispielrolle
Firewallregel erstellen	compute.firewalls.create	Compute-Sicherheitsadministrator (roles/compute.securityAdmin)
Firewallregel löschen	compute.firewalls.delete	Compute-Sicherheitsadministrator (roles/compute.securityAdmin)
Änderungen an Firewallregeln vornehmen	compute.firewalls.update	Compute-Sicherheitsadministrator (roles/compute.securityAdmin)
Details zu einer Firewallregel ansehen	compute.firewalls.get	Compute-Netzwerkbetrachter (roles/compute.networkViewer)
Liste der Firewallregeln aufrufen	compute.firewalls.list	Compute-Netzwerkbetrachter (roles/compute.networkViewer)

Anwendungsfälle

Anhand der folgenden Anwendungsfälle wird die Funktionsweise von Firewallregeln veranschaulicht. In diesen Beispielen sind alle Firewallregeln aktiviert.

Fälle für eingehenden Traffic

Firewallregeln für eingehenden Traffic steuern eingehende Verbindungen von einer Quelle zu Zielinstanzen in Ihrem VPC-Netzwerk. Für die Definition der Quelle einer Eingangsregel haben Sie folgende Möglichkeiten:

• Ein Bereich von IPv4- oder IPv6-Adressen; standardmäßig eine beliebige IPv4-Adresse (0.0.0.0/0)
• Andere durch Netzwerktags identifizierte Instanzen in Ihrem VPC-Netzwerk
• Andere durch ein Dienstkonto identifizierte Instanzen in Ihrem VPC-Netzwerk
• Andere Instanzen in Ihrem VPC-Netzwerk, die durch einen Bereich von IPv4- oder IPv6-Adressen und durch ein Netzwerktag identifiziert werden
• Andere Instanzen in Ihrem VPC-Netzwerk, die durch einen Bereich von IPv4- oder IPv6-Adressen und durch ein Dienstkonto identifiziert werden

Die Standardquelle ist eine beliebige IPv4-Adresse (0.0.0.0/0). Wenn Sie eingehende Verbindungen für Quellen außerhalb Ihres VPC-Netzwerks steuern möchten, einschließlich anderer Quellen im Internet, verwenden Sie einen IP-Adressbereich im CIDR-Format.

Regeln für eingehenden Traffic mit der Aktion allow erlauben eingehenden Traffic anhand der anderen Komponenten der Regel. Zusätzlich zur Angabe der Quelle und des Ziels für die Regel können Sie die Regel auf bestimmte Protokolle und Zielports beschränken. Ähnlich können Sie Eingangsregeln mit einer deny-Aktion zum Schutz von Instanzen verwenden und damit eingehenden Traffic auf der Grundlage der Komponenten der Firewallregel blockieren.

Achtung: Sie können auch Zieldienstkonten oder Ziel-Netzwerktags verwenden, um die Bestimmungsorte des eingehenden Traffics anzugeben. In diesem Fall beschränken Sie, wie die Quelle für die Regel angegeben werden kann. Weitere Informationen finden Sie unter Nach Dienstkonto oder Netzwerktag filtern.

Beispiele für eingehenden Traffic

Abbildung 1 zeigt einige Beispiele, in denen eingehende Verbindungen durch Firewallregeln gesteuert werden können. In den Beispielen wird der Parameter target in Regelzuweisungen verwendet, um Regeln auf bestimmte Instanzen anzuwenden.

Abbildung 1. In diesem Beispiel-VPC-Netzwerk überschreiben die Firewallregeln für eingehenden Traffic die implizierte Regel zum Ablehnen von eingehendem Traffic für einige VMs (zum Vergrößern klicken).

• Für VM 1 gilt eine Eingangsregel mit der Priorität 1000. Diese Regel erlaubt eingehenden TCP-Traffic von einer beliebigen IPv4-Quelle (0.0.0.0/0). TCP-Traffic von anderen Instanzen im VPC-Netzwerk ist zulässig, wobei die geltenden Regeln für ausgehenden Traffic für diese Instanzen zu berücksichtigen sind. VM 4 kann mit VM 1 über TCP kommunizieren, da VM 4 über keine Ausgangsregel verfügt, die eine solche Kommunikation blockiert. Es ist nur die implizierte Regel zum Zulassen von ausgehendem Traffic gültig. Da VM 1 eine externe IP-Adresse hat, erlaubt diese Regel auch eingehenden TCP-Traffic von externen Hosts im Internet und von VM 2 über externe IP-Adressen.

• Für VM 2 ist keine Firewallregel für eingehenden Traffic festgelegt, sodass die implizierte Regel zum Ablehnen von eingehendem Traffic zur Anwendung kommt. Verbindungen von anderen Netzwerkinstanzen werden unabhängig von den Ausgangsregeln für diese Instanzen blockiert. Da VM 2 über eine externe IP verfügt, ist ein Pfad von externen Hosts im Internet zu ihr vorhanden, die implizierte Ablehnungsregel blockiert jedoch auch den eingehenden externen Traffic.

• Für VM 3 gilt eine Eingangsregel mit der Priorität 1000. Diese Regel erlaubt TCP-Traffic von Netzwerkinstanzen mit dem Netzwerktag client, z. B. von VM 4. TCP-Traffic von VM 4 zu VM 3 ist zulässig, da VM 4 keine Ausgangsregel hat, die eine solche Kommunikation blockiert. (Es ist nur die implizierte Regel zum Zulassen von ausgehendem Traffic gültig.) Da VM 3 keine externe IP-Adresse hat, gibt es zu ihr keinen Pfad von externen Hosts im Internet.

Fälle für ausgehenden Traffic

Firewallregeln für ausgehenden Traffic steuern ausgehende Verbindungen von Zielinstanzen in Ihrem VPC-Netzwerk. Ausgangsregeln mit der Aktion allow erlauben Traffic von Instanzen anhand der anderen Komponenten der Regel. Beispielsweise können Sie ausgehenden Traffic zu bestimmten Zielen, wie zu einem IPv4-Adressbereich, für die von Ihnen angegebenen Protokolle und Ports zulassen. Ebenso blockieren Ausgangsregeln mit einer deny-Aktion den Traffic anhand der anderen Komponenten der Regel.

Jede Ausgangsregel benötigt einen Bestimmungsort. Standardmäßig kann dies eine beliebige IPv4-Adresse (0.0.0.0/0) sein. Sie können das Ziel aber durch einen Bereich von IPv4- oder IPv6-Adressen im CIDR-Format eingrenzen. Durch Festlegen eines IP-Adressbereichs haben Sie die Möglichkeit, den Traffic zu steuern und auf bestimmte Instanzen in Ihrem Netzwerk und auf Ziele außerhalb Ihres Netzwerks zu begrenzen, beispielsweise auch auf Ziele im Internet.

Beispiele für ausgehenden Traffic

Abbildung 2 zeigt einige Beispiele, in denen ausgehende Verbindungen durch Firewallregeln gesteuert werden können. In den Beispielen wird der Parameter target in Regelzuweisungen verwendet, um Regeln auf bestimmte Instanzen anzuwenden.

Abbildung 2. In diesem Beispiel-VPC-Netzwerk überschreiben die Firewallregeln zum Ablehnen von ausgehendem Traffic für einige VMs die implizierte Regel zum Zulassen von ausgehendem Traffic (zum Vergrößern klicken).

• Für VM 1 ist keine Firewallregel für ausgehenden Traffic festgelegt, sodass die implizierte Regel zum Zulassen von ausgehendem Traffic den Traffic zu jedem Bestimmungsort erlaubt. Verbindungen zu anderen Instanzen im VPC-Netzwerk sind zulässig, vorbehaltlich der geltenden Eingangsregeln für diese Instanzen. VM 1 kann Traffic an VM 4 senden, da für VM 4 eine Eingangsregel gilt, die eingehenden Traffic von beliebigen IP-Adressbereichen zulässt. Da VM 1 eine externe IP-Adresse hat, kann sie auch Traffic an externe Hosts im Internet senden. Eingehende Antworten auf Traffic, der von VM 1 gesendet wird, sind zulässig, da Firewallregeln zustandsorientiert sind.

• Für VM 2 gilt eine Ausgangsregel mit der Priorität 1000. Mit dieser Regel wird der gesamte ausgehende Traffic zu allen IPv4-Zielen (0.0.0.0/0) abgelehnt. Ausgehender Traffic zu anderen Instanzen im VPC-Netzwerk wird unabhängig von den für diese Instanzen geltenden Regeln für eingehenden Traffic blockiert. Obwohl VM 2 eine externe IP-Adresse hat, blockiert diese Firewallregel auch den ausgehenden Traffic zu externen Hosts im Internet.

• Für VM 3 gilt eine Ausgangsregel mit der Priorität 1000. Diese Regel blockiert den ausgehenden TCP-Traffic an einen beliebigen Bestimmungsort im IP-Bereich 192.168.1.0/24. Obwohl Eingangsregeln für VM 4 den gesamten eingehenden Traffic erlauben, kann VM 3 keinen TCP-Traffic an VM 4 senden. VM 3 kann jedoch UDP-Traffic an VM 4 senden, da die Ausgangsregel nur für das TCP-Protokoll gilt.

  VM 3 kann auch beliebigen Traffic an andere Instanzen im VPC-Netzwerk außerhalb des IP-Bereichs 192.168.1.0/24 senden, solange für diese Instanzen Eingangsregeln gelten, die einen solchen Traffic zulassen. Da sie keine externe IP-Adresse hat, gibt es keinen Pfad zum Senden von Traffic an Bestimmungsorte außerhalb des VPC-Netzwerks.

Nächste Schritte

• Informationen zum Erstellen von Firewallregeln und zum Arbeiten damit finden Sie unter VPC-Firewallregeln verwenden.

Überzeugen Sie sich selbst

Wenn Sie mit Google Cloud noch nicht vertraut sind, erstellen Sie ein Konto, um die Leistungsfähigkeit von Cloud NGFW in der Praxis sehen und bewerten zu können. Neukunden erhalten außerdem ein Guthaben von 300 $, um Arbeitslasten auszuführen, zu testen und bereitzustellen.

Cloud NGFW kostenlos testen