Übersicht über Firewallregeln

Mit Google Cloud-Firewallregeln können Sie den Traffic zu und von Ihren VM-Instanzen (virtuelle Maschinen) mithilfe einer von Ihnen festgelegten Konfiguration zulassen oder ablehnen. Aktivierte Google Cloud-Firewallregeln werden immer durchgesetzt. Sie schützen Ihre Instanzen unabhängig von ihrer Konfiguration und ihrem Betriebssystem, selbst wenn sie nicht gestartet wurden.

Jedes VPC-Netzwerk (Virtual Private Cloud) fungiert im Prinzip als verteilte Firewall. Die Firewallregeln werden auf Netzwerkebene definiert, die Verbindungen aber pro Instanz zugelassen oder abgelehnt. Die Google Cloud-Firewall existiert also nicht nur zwischen Ihren Instanzen und anderen Netzwerken, sondern auch zwischen einzelnen Instanzen innerhalb des gleichen Netzwerks.

Weitere Informationen zu Firewalls finden Sie unter Firewall.

Firewallregeln in Google Cloud

Beim Erstellen einer Google Cloud-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, basierend auf dem Protokoll, den Ports, Quellen und Zielen des Traffics. Weitere Informationen finden Sie unter Komponenten von Firewallregeln.

Sie können Google Cloud-Firewallregeln über die Google Cloud Console, das gcloud-Befehlszeilentool und die REST API erstellen und ändern. Beim Erstellen oder Ändern einer Firewallregel geben Sie mit der Zielkomponente der Regel die Instanzen an, auf die sie angewendet werden soll.

Neben den von Ihnen erstellten Firewallregeln bietet Google Cloud noch weitere Regeln, die den eingehenden (ingress) und ausgehenden Traffic (egress) beeinflussen können:

  • Google Cloud lässt bestimmte IP-Protokolle wie GRE in einem VPC-Netzwerk nicht zu. Weitere Informationen finden Sie unter Permanent blockierter 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

Google Cloud-Firewallregeln haben folgende Merkmale:

  • Jede Firewallregel gilt entweder für eingehenden (ingress) oder für ausgehenden Traffic (egress), jedoch nicht für beide Richtungen. Weitere Informationen finden Sie unter Trafficrichtung.

  • Firewallregeln unterstützen nur IPv4-Traffic. Wenn Sie eine Quelle für eine Eingangsregel oder ein Ziel für eine Ausgangsregel durch eine IP-Adresse angeben, müssen Sie dafür eine IPv4-Adresse oder einen IPv4-Block in CIDR-Notation verwenden.

  • Die Aktion jeder Firewallregel ist allow oder deny. Die Regel gilt für den Traffic, 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.

  • Google Cloud-Firewallregeln sind zustandsorientiert. Nachdem eine Sitzung eingerichtet wurde, ermöglichen Firewallregeln die Kommunikation in beide Richtungen. Sie können eine Firewallregel nicht so konfigurieren, dass der zugehörige Antworttraffic abgelehnt wird. Google Cloud ordnet eingehende Pakete mithilfe einer Tabelle zum Nachverfolgen der Verbindung den entsprechenden ausgehenden Paketen zu. Google Cloud verfolgt Verbindungen unabhängig davon nach, 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.

  • Google Cloud-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:

    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 Firewallregeln. Folgende Regeln sind vorhanden, werden jedoch nicht in der Cloud Console angezeigt:

  • Implizierte 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 für den Internetzugang.

  • Implizierte Regel zum Ablehnen von eingehendem Traffic. Eine Regel für eingehenden Traffic mit der Aktion deny, der Quelle 0.0.0.0/0 und der niedrigsten Priorität (65535) schützt alle Instanzen, indem der eingehende Traffic blockiert wird. 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 eingehendem Traffic sind somit zugelassen.

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 eingehenden Traffic für Instanzen zulassen. Diese Regeln können nach Bedarf gelöscht oder geändert werden:

  • default-allow-internal
    Lässt eingehende Verbindungen für alle Protokolle und Ports zwischen den Netzwerkinstanzen zu. Diese Regel hat die zweitniedrigste Priorität von 65534 und erlaubt damit eingehende Verbindungen von anderen VM-Instanzen zu VM-Instanzen im selben Netzwerk.
  • default-allow-ssh
    Lässt eingehende Verbindungen auf TCP-Port 22 von jeder Quelle zu jeder Instanz im Netzwerk zu. Diese Regel hat die Priorität 65534.
  • default-allow-rdp
    Lässt eingehende Verbindungen auf TCP-Port 3389 von jeder Quelle zu jeder Instanz im Netzwerk zu. Diese Regel hat die Priorität 65534 und ermöglicht Verbindungen zu Instanzen, auf denen das Remotedesktopprotokoll (RDP) von Microsoft ausgeführt wird.
  • default-allow-icmp
    Lässt eingehenden ICMP-Traffic von jeder Quelle zu jeder Instanz im Netzwerk zu. Diese Regel hat die Priorität 65534 und ermöglicht die Verwendung von Tools wie ping.

Permanent blockierter Traffic

Google Cloud blockiert immer den in der folgenden Tabelle beschriebenen Traffic. Ihre Firewallregeln können nicht verwendet werden, um diesen Traffic zuzulassen.

Permanent blockierter Traffic Gilt für
GRE-Traffic Alle Quellen und Ziele, unabhängig davon, ob es sich bei der Quelle oder dem Ziel um eine interne oder eine externe IP-Adresse handelt.
Andere Protokolle als TCP, UDP, ICMP, AH, ESP und SCTP für externe IP-Adressen von Google Cloud-Ressourcen Der Ressourcentyp schränkt das Protokoll weiter ein. Netzwerk-TCP/UDP-Load-Balancing unterstützt beispielsweise nur TCP und UDP und eine Weiterleitungsregel für die Protokollweiterleitung verarbeitet nur ein einzelnes Protokoll.
Ausgehender Traffic an TCP-Zielport 25 (SMTP) Traffic von:
• Instanzen an externe IP-Adressen im Internet
• Instanzen an externe IP-Adressen der Instanzen

Permanent zugelassener Traffic

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:

Komponenten von Firewallregeln

Jede Firewallregel besteht aus den folgenden Konfigurationskomponenten:

  • Die Trafficrichtung: "ingress"-Regeln gelten für eingehende Verbindungen von angegebenen Quellen zu Google Cloud-Zielen und "egress"-Regeln gelten für Traffic von Zielen zu angegebenen Bestimmungsorten.

  • 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 den Traffic 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.

  • Eine Quelle für "ingress"-Regeln oder ein Bestimmungsort für "egress"-Regeln.

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

Zusammenfassung der Komponenten

Eingangsregel (Ingress)
Priorität Aktion Erzwingung Parameter "target" (definiert den Bestimmungsort) Quelle Protokolle und Ports
Ganzzahl von 0 bis einschließlich 65535; Standard: 1000
allow oder deny enabled (Standard) oder disabled Mit dem Parameter target wird der Bestimmungsort angegeben. Dies kann einer der folgenden Werte sein: Beispiele:
  • Bereich der IPv4-Adressen; Standard: beliebig (0.0.0.0/0)
  • Instanzen nach Netzwerktag
  • Instanzen nach Dienstkonto
Geben Sie ein Protokoll oder ein Protokoll und einen Port an.

Ist nichts festgelegt, gilt die Regel für alle Protokolle.
Ausgangsregel (Egress)
Priorität Aktion Erzwingung Parameter "target" (definiert die Quelle) Bestimmungsort Protokolle und Ports
Ganzzahl von 0 bis einschließlich 65535; Standard: 1000
allow oder deny enabled (Standard) oder disabled Mit dem Parameter target wird die Quelle angegeben. Dies kann einer der folgenden Werte sein:
  • Alle Instanzen im VPC-Netzwerk
  • Instanzen nach Netzwerktag
  • Instanzen nach Dienstkonto
Jedes Netzwerk oder ein bestimmter Bereich von IPv4-Adressen; Standard: beliebig (0.0.0.0/0). Geben Sie ein Protokoll oder ein Protokoll und einen Port an.

Ist nichts festgelegt, gilt die Regel für alle Protokolle.

Trafficrichtung

Die Richtung einer Firewallregel kann entweder ingress oder egress sein. Sie wird immer aus Sicht des Ziels definiert.

  • Die Richtung "ingress" beschreibt den von einer Quelle an ein Ziel gesendeten Traffic. Eingangsregeln gelten für Pakete für neue Sitzungen, bei denen das Ziel des Pakets das Ziel ist.

  • Die egress-Richtung beschreibt den von einem Ziel an ein anderes Ziel gesendeten Traffic. Ausgangsregeln gelten für Pakete für neue Sitzungen, bei denen die Quelle des Pakets das Ziel ist.

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

Nehmen Sie als Beispiel eine Verbindung zwischen zwei VMs im selben Netzwerk. In diesem Fall kann der Traffic von VM1 zu VM2 mit einer der folgenden Firewallregeln gesteuert werden:

  • Einer Eingangsregel mit dem Ziel "VM2" und der Quelle "VM1".

  • Einer Ausgangsregel mit dem Ziel "VM1" und einem Bestimmungsort "VM2".

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 ingress-Regel höherer Priorität für bestimmte Ports und Protokolle, die für alle Ziele gelten soll, eine ähnlich definierte Regel für dieselben Ports und Protokolle, die nur für bestimmte Ziele festgelegt ist.

  • Die Regel mit der höchsten Priorität, die für eine bestimmte Protokoll- und Portdefinition gilt, hat auch dann Vorrang, wenn die Protokoll- und Portdefinition allgemeinerer Art ist. Beispielsweise überschreibt eine Eingangsregel höherer Priorität, die den Traffic für alle Protokolle und Ports 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:

  • Es gibt eine Eingangsregel aus den Quellen 0.0.0.0/0 (beliebig) mit der Aktion deny und der Priorität 1000, die für alle Ziele, alle Protokolle und alle Ports gilt.

  • Es gibt eine Eingangsregel aus den Quellen 0.0.0.0/0 (beliebig) für Traffic an TCP-Port 80 mit der Aktion allow, die für bestimmte Ziele mit dem Tag webserver gilt.

Die Priorität der zweiten Regel bestimmt, ob TCP-Traffic an 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 Tag 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.

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.

Erzwingung

Sie können die Einstellung, ob eine Firewallregel erzwungen werden soll, ändern. Dazu legen Sie deren Zustand auf enabled oder disabled fest. Die Deaktivierung einer Regel ist für die Fehlerbehebung oder die Erteilung des temporären Zugriffs auf Instanzen nützlich. Es ist viel einfacher, eine Regel zu deaktivieren, zu testen und dann wieder zu aktivieren, als die Regel zu löschen und neu zu erstellen.

Sofern nicht anders angegeben, sind alle Firewallregeln bei der Erstellung aktiviert (enabled). Sie können auch eine Regel erstellen, die deaktiviert (disabled) ist.

Der Erzwingungszustand für Firewallregeln kann von enabled in disabled und wieder zurückgeändert werden, indem die Regel aktualisiert wird.

Sie können eine Firewallregel beispielsweise auch für die folgenden Situationen deaktivieren:

  • Für die Fehlerbehebung: Wenn Sie sich nicht sicher sind, ob eine Firewallregel Traffic blockiert oder zulässt, deaktivieren Sie sie vorübergehend. So können Sie ermitteln, welcher Zustand zutrifft. Dies ist hilfreich, um Probleme im Zusammenhang mit den Auswirkungen einer Regel in Kombination mit anderen Regeln zu beheben.
  • Für die Wartung: Durch die Deaktivierung von Firewallregeln können regelmäßige Wartungen vereinfacht werden. Angenommen, eine vorhandene Firewallregel blockiert eingehende SSH-Verbindungen an Ziele (z. B. Instanzen nach Zieltag) und diese Regel ist normalerweise aktiviert (enabled). Wenn eine Wartung ansteht, können Sie die Regel deaktivieren. Nach Abschluss dieses Vorgangs kann sie wieder aktiviert werden.

Ziel

Bei einer Eingangsregel (ingress) werden mit dem Parameter target die Bestimmungs-VMs festgelegt, einschließlich GKE-Cluster und Instanzen in der flexiblen App Engine-Umgebung. Bei einer Ausgangsregel (egress) wird die Quellinstanz über das Ziel festgelegt. Mit dem Parameter target werden also immer Google Cloud-Instanzen definiert. Ob diese jedoch Bestimmungsort oder Quelle des Traffics sind, hängt von der Richtung der Regel ab.

Ein Ziel definieren Sie mit einer der folgenden Optionen:

  • Alle Instanzen im Netzwerk: Die Firewallregel gilt für alle Instanzen im Netzwerk.

  • Instanzen nach Zieltags: Die Firewallregel gilt nur für Instanzen mit einem übereinstimmenden Netzwerktag.

  • Instanzen nach Zieldienstkonten. Die Firewallregel gilt nur für Instanzen, 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 Zieltags und Zieldienstkonten finden Sie unter Nach Dienstkonto oder Netzwerktag filtern.

Ziele und IP-Adressen

Das Ziel einer Firewallregel für eingehenden Traffic gilt für den gesamten eingehenden Traffic auf der Netzwerkschnittstelle (NIC) einer Instanz im VPC-Netzwerk, unabhängig davon, wie das Ziel angegeben ist. Eine Firewallregel für eingehenden Traffic gilt für Pakete, deren Ziele mit einer der folgenden IP-Adressen übereinstimmen:

  • Die primäre interne IP-Adresse, die der Netzwerkschnittstelle der Instanz im VPC-Netzwerk zugewiesen ist.

  • Alle konfigurierten Alias-IP-Bereiche auf der Netzwerkschnittstelle der Instanz im VPC-Netzwerk.

  • Die externe IP-Adresse, die der Netzwerkschnittstelle der Instanz im VPC-Netzwerk zugewiesen ist.

  • Eine interne oder externe IP-Adresse, die einer Weiterleitungsregel für das Load-Balancing oder die Protokollweiterleitung zugeordnet ist, wenn die Instanz ein Back-End für den Load-Balancer oder eine Zielinstanz für die Protokollweiterleitung ist

Das Ziel einer Firewallregel für ausgehenden Traffic gilt für den gesamten Traffic, der die Netzwerkschnittstelle (NIC) einer VM-Instanz im VPC-Netzwerk verlässt, unabhängig davon, wie das Ziel angegeben ist:

  • Die IP-Weiterleitung ist standardmäßig deaktiviert. Eine Firewallregel für ausgehenden Traffic gilt für Pakete, deren Quellen mit einem der folgenden Elemente übereinstimmen:
    • Die primäre interne IP-Adresse der NIC einer Instanz
    • Jeder konfigurierte Alias-IP-Bereich auf der NIC einer Instanz
    • Eine interne oder externe IP-Adresse, die einer Weiterleitungsregel für das Load-Balancing oder die Protokollweiterleitung zugeordnet ist, wenn die Instanz ein Back-End für den Load-Balancer oder eine Zielinstanz für die Protokollweiterleitung ist
  • Wenn die IP-Weiterleitung aktiviert ist, kann die VM Pakete mit einer beliebigen Quelle senden.

Quelle oder Ziel

In Abhängigkeit von der Richtung der von Ihnen erstellten Firewall geben Sie entweder eine Quelle oder einen Bestimmungsort an, aber nicht beides:

  • Bei Eingangsregeln (ingress) werden mit dem Parameter target die Bestimmungs-VMs für den Traffic angegeben. Sie können den Parameter destination nicht verwenden. Die Quelle wird mit dem Parameter source angegeben.

  • Bei Ausgangsregeln (egress) werden mit dem Parameter target die Quell-VMs für den Traffic angegeben. Sie können den Parameter source nicht verwenden. Der Bestimmungsort wird mit dem Parameter destination angegeben.

Quellen

Der Parameter source gilt nur für Eingangsregeln. Dieser muss einer der folgenden Werte sein:

  • Quell-IP-Bereiche: Sie können IP-Adressbereiche als Quellen für Pakete angeben. Die Bereiche können Adressen innerhalb und außerhalb Ihres VPC-Netzwerks umfassen. Mit Quell-IP-Bereichen lassen sich Quellen innerhalb und außerhalb von Google Cloud definieren.

  • Quelltags: Sie können die Quelle für Pakete als primäre interne IP-Adresse der Netzwerkschnittstelle von VM-Instanzen im selben VPC-Netzwerk definieren und diese Quellinstanzen anhand eines übereinstimmenden Netzwerktags identifizieren. Quelltags gelten nur für Traffic, der von der Netzwerkschnittstelle einer anderen entsprechenden Instanz in Ihrem VPC-Netzwerk gesendet wird. Ein Quelltag kann nicht zur Steuerung von Paketen verwendet werden, deren Quellen externe IP-Adressen sind, auch wenn die externen IP-Adressen zu Instanzen gehören. Die maximale Anzahl von Quelltags, die Sie pro Firewallregel anwenden können, finden Sie unter VPC-Ressourcenkontingente.

  • Quelldienstkonten: Sie können die Quelle für Pakete als primäre interne IP-Adresse der Netzwerkschnittstelle von Instanzen im selben VPC-Netzwerk definieren und diese Quellinstanzen anhand des von ihnen verwendeten Dienstkontos identifizieren. Quelldienstkonten gelten nur für Traffic, der von der Netzwerkschnittstelle einer anderen betroffenen Instanz in Ihrem VPC-Netzwerk gesendet wird. Ein Quelldienstkonto kann nicht zur Steuerung von Paketen verwendet werden, deren Quellen externe IP-Adressen sind, auch wenn die externen IP-Adressen zu Instanzen gehören. Die maximale Anzahl an Quelldienstkonten, die Sie pro Firewallregel verwenden können, finden Sie unter VPC-Ressourcenkontingente.

  • Sie können eine Kombination aus Quell-IP-Bereichen und Quelltags verwenden.

  • Sie können eine Kombination aus Quell-IP-Bereichen und Quelldienstkonten verwenden.

  • Wenn keine Quell-IP-Bereiche, Quelltags oder Quelldienstkonten angegeben werden, definiert Google Cloud die Quelle als beliebige IP-Adresse (0.0.0.0/0).

Quellen und IP-Adressen

Wenn Sie eine Quelle mit einer der folgenden Methoden angeben, betrachtet Google Cloud die Quelle nur als primäre interne IP-Adresse der Netzwerkschnittstelle der VM im VPC-Netzwerk:

  • Quelltags
  • Quelldienstkonten
  • Eine Quellspezifikation, die entweder Quelltags oder Quelldienstkonten enthält

Alias-IP-Bereiche für diese NIC und IP-Adressen für zugeordnete Weiterleitungsregeln sind bei Verwendung von Quelltags oder Quelldienstkonten nicht enthalten.

Wenn Sie die Alias-IP-Bereiche einer VM einschließen müssen, fügen Sie sie einer Quellbereichsliste für eine Eingangsregel hinzu. Sie können Quellbereiche und Quelltags zusammen verwenden. Sie können auch Quellbereiche und Quelldienstkonten zusammen verwenden.

Ziele

Der Parameter destination gilt nur für Ausgangsregeln. Der Parameter destination akzeptiert nur IP-Adressbereiche. Die Bereiche können Adressen innerhalb und außerhalb Ihres VPC-Netzwerks umfassen.

Wenn Sie keinen Bereich für den Bestimmungsort angeben, definiert Google Cloud den Bestimmungsort als alle IP-Adressen (0.0.0.0/0).

Protokolle und Ports

Durch Angabe von Protokollen oder Protokollen und Ports lässt sich der Umfang einer Firewallregel einschränken. Sie können ein Protokoll oder eine Kombination aus Protokollen und ihren Ports festlegen. Wenn Sie sowohl Protokolle als auch Ports weglassen, gilt die Firewallregel für den gesamten Traffic mit jedem Protokoll und auf jedem Port.

Damit Sie eine Firewallregel präzisieren können, müssen Sie zuerst ein Protokoll angeben. Wenn das Protokoll Ports unterstützt, können Sie optional eine Portnummer oder einen Portbereich festlegen. Allerdings unterstützen nicht alle Protokolle Ports. Beispielsweise gibt es Ports für TCP und UDP, nicht jedoch für ICMP. Das ICMP-Protokoll unterstützt verschiedene ICMP-Typen, wobei es sich jedoch nicht um Ports handelt.

Sie können ein Protokoll anhand seines Namens (tcp, udp, icmp, esp, ah, sctp, ipip) oder seiner dezimalen IP-Protokollnummer angeben.

Google Cloud-Firewallregeln verwenden Portinformationen, um auf den Bestimmungsport eines Pakets zu verweisen, nicht auf seinen Quellport:

  • Bei Firewallregeln für eingehenden Traffic (Ingress) stellen Zielports die Ports auf Systemen dar, die durch den Parameter target der Regel identifiziert werden. (Der Parameter target gibt für Eingangsregeln die Ziel-VMs für den Traffic an.)

  • Bei Firewallregeln für ausgehenden Traffic (Egress) stellen Zielports die Ports auf Systemen dar, die durch den Parameter destination der Regel identifiziert werden.

In der folgenden Tabelle finden Sie eine Zusammenfassung der gültigen Kombinationen von Protokoll- und Portspezifikationen 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 Ports.
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 Port angeben, gilt die Firewallregel für diesen Port 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 aus Protokollen und Ports angeben, für die die Firewallregel gilt. Weitere Informationen finden Sie unter Firewallregeln erstellen.

Quelle und Ziel nach Dienstkonto filtern

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 erstellt werden, bevor Sie eine Firewallregel erstellen, die darauf basiert.

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.

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 Zieltags und Quelltags:

  • Ein Netzwerktag ist ein beliebiges Attribut. Jedes Cloud IAM-Mitglied (Cloud Identity and Access Management), das die Berechtigung zum Bearbeiten einer Instanz hat, kann dieser Instanz ein oder mehrere Netzwerktags zuordnen. Diese Berechtigung für ein Projekt haben Cloud IAM-Mitglieder mit der Rolle Compute Engine-Instanzadministrator. Wenn Cloud IAM-Mitglieder 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 Cloud IAM-Mitglieder kontrollieren. Damit ein Cloud IAM-Mitglied eine Instanz mit einem Dienstkonto starten kann, muss das Mitglied mindestens die Rolle "Dienstkontonutzer" für dieses Dienstkonto sowie entsprechende Berechtigungen zum Erstellen von Instanzen haben (z. B. die Rolle "Compute Engine-Instanzadministrator" für das Projekt).

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

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

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

    Ziele Ungültige Quellen
    Zieltags Quelldienstkonten

    Kombination aus Quell-IP-Bereichen und Quelldienstkonten
    Zieldienstkonto Quelltags

    Kombination aus Quell-IP-Bereichen und Quelltags

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. Tags 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.

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-Adressen; Standardwert: beliebig (0.0.0.0/0)
  • Andere durch ein Dienstkonto identifizierte Instanzen in Ihrem VPC-Netzwerk
  • Andere durch Netzwerktags identifizierte Instanzen in Ihrem VPC-Netzwerk

Die Standardquelle ist eine beliebige IP-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 IPv4-Adressbereich im CIDR-Format.

Regeln für eingehenden Traffic mit der Aktion allow erlauben eingehenden Traffic anhand der anderen Komponenten der Regel. Über die Angabe der Quelle und des Ziels für die Regel hinaus können Sie die Regel auf bestimmte Protokolle und Ports beschränken. In ähnlicher Weise können Sie Eingangsregeln mit einer deny-Aktion zum Schutz von Instanzen verwenden und damit eingehenden Traffic anhand der Komponenten der Firewall blockieren.

Beispiele für eingehenden Traffic

Das folgende Diagramm 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.

Beispiel für Firewallregeln für eingehenden Traffic (zum Vergrößern klicken)
Beispiel für Firewallregeln für eingehenden Traffic (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 Quelle (0.0.0.0/0). TCP-Traffic von anderen Instanzen im VPC-Netzwerk ist zulässig, vorbehaltlich der geltenden Ausgangsregeln für diese Instanzen. 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.

  • 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 einzelnen Bestimmungsorten wie zu einem IPv4-Adressbereich für die von Ihnen angegebenen Protokolle und Ports zulassen. In gleicher Weise blockieren Ausgangsregeln mit einer deny-Aktion den Traffic anhand der anderen Komponenten der Regel.

Jede Ausgangsregel benötigt einen Bestimmungsort. Standardmäßig kann das eine beliebige IP-Adresse sein (0.0.0.0/0). Sie können den Bestimmungsort aber durch einen Bereich von IPv4-Adressen im CIDR-Format eingrenzen. Durch Festlegen eines Bereichs von IPv4-Adressen haben Sie die Möglichkeit, den Traffic zu Instanzen in Ihrem Netzwerk und zu Bestimmungsorten außerhalb Ihres Netzwerks, einschließlich Zielen im Internet, zu steuern.

Beispiele für ausgehenden Traffic

Das folgende Diagramm 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.

Beispiel für Firewallregeln für ausgehenden Traffic (zum Vergrößern klicken)
Beispiel für Firewallregeln für ausgehenden 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 Bestimmungsorten (0.0.0.0/0) abgelehnt. Ausgehender Traffic zu anderen Instanzen im VPC-Netzwerk wird unabhängig von den für diese Instanzen geltenden Eingangsregeln 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.

Weitere Informationen