Hierarchische Firewallrichtlinien

Mit hierarchischen Firewallrichtlinien können Sie eine konsistente Firewallrichtlinie für Ihre gesamte Organisation erstellen und erzwingen. Sie können der Organisation hierarchische Firewallrichtlinien als Ganzes oder für einzelne Ordner zuweisen. Diese Richtlinien enthalten Regeln, die Verbindungen explizit ablehnen oder zulassen, wie VPC-Firewallregeln (Virtual Private Cloud). Darüber hinaus können die Regeln einer hierarchischen Firewallrichtlinie die Auswertung an Richtlinien auf einer niedrigeren Ebene oder VPC-Netzwerk-Firewallregeln mit der Aktion goto_next delegieren.

Regeln auf niedrigerer Ebene können keine Regeln von einer höheren Ebene in der Ressourcenhierarchie überschreiben. Auf diese Weise können organisationsweite Administratoren kritische Firewallregeln an einem Ort verwalten.

Spezifikationen

Hierarchische Firewallrichtlinien werden in Organisations- und Ordnerknoten erstellt. Beim Erstellen einer Richtlinie werden die Regeln nicht automatisch auf den Knoten angewendet.
Nach dem Erstellen können Richtlinien auf alle Knoten in der Organisation (verknüpft) angewendet werden.
Hierarchische Firewallrichtlinien sind Container für Firewallregeln. Wenn Sie eine Richtlinie mit der Organisation oder einem Ordner verknüpfen, werden alle Regeln sofort angewendet. Sie können Richtlinien für einen Knoten austauschen, wodurch alle Firewallregeln, die auf VM-Instanzen unter diesem Knoten angewendet werden, atomar ausgetauscht werden.
Die Regelauswertung ist entsprechend der Ressourcenhierarchie hierarchisch. Alle Regeln, die dem Organisationsknoten zugeordnet sind, werden ausgewertet, gefolgt von den Regeln der obersten Ordnerebene usw.
Regeln in hierarchischen Firewallrichtlinien haben eine neue goto_next-Aktion, mit der Sie die Auswertung der Verbindung an niedrigere Hierarchieebenen delegieren können.
Regeln für hierarchische Firewallregeln lassen sich auf bestimmte VPC-Netzwerke und VMs ausrichten. Dabei werden Zielressourcen für Netzwerke und Zieldienstkonten für VMs verwendet. Damit können Sie Ausnahmen für Gruppen von VMs erstellen. Die Konfiguration von hierarchischen Firewallregeln unterstützt kein Targeting nach Instanztags.
Jede hierarchische Firewallrichtlinienregel kann entweder IPv4- oder IPv6-Bereiche enthalten, aber nicht beides.
Zur Unterstützung bei der Compliance und Fehlerbehebung können Firewallregeln, die auf eine VM-Instanz angewendet werden, über die Seite „VPC-Netzwerkdetails“ und die Detailseite zur Netzwerkschnittstelle der VM-Instanz überprüft werden.

Ressourcenhierarchie

Firewallrichtlinien werden als separate Schritte erstellt und angewendet. Sie können Firewallrichtlinien auf den Organisations- oder Ordnerknoten der Ressourcenhierarchie erstellen und anwenden. Mit Firewallregeln können Sie Verbindungen blockieren, Verbindungen zulassen oder die Auswertung von Firewallregeln auf untergeordnete Ordner oder VPC-Firewallregeln einschränken, die in VPC-Netzwerken definiert sind.

Organisation ist der Knoten auf oberster Ebene in der Ressourcenhierarchie in Google Cloud, auf der Sie hierarchische Firewallrichtlinien erstellen oder verknüpfen können. Diese Richtlinie wird von allen Ordnern und VPC-Netzwerken in der Organisation übernommen.
Ordner sind Knoten auf der mittleren Ebene in der Google Cloud-Ressourcenhierarchie zwischen der Organisation und Projekten. Sie können hierarchische Firewallrichtlinien in Ordnern erstellen oder zuweisen. Die zugehörige Richtlinie wird für alle Ordner und VPC-Netzwerke in einem Ordner übernommen.
Ein Projekt befindet sich in einem Ordner oder der Organisation. Sie können Projekte zwischen Knoten in einer Organisation verschieben. Projekte enthalten VPC-Netzwerke. Hierarchische Firewallrichtlinien können nicht Projekten zugewiesen werden, sondern nur der Organisation oder den Ordnern.
Ein VPC-Netzwerk ist die Google Cloud-Partition für die isolierte Kommunikation innerhalb eines IP-Bereichs. Auf dieser Ebene werden Routen und herkömmliche VPC-Firewallregeln angegeben und angewendet. Regeln in hierarchischen Firewallrichtlinien können Netzwerk-Firewallregeln überschreiben oder die Auswertung der Verbindung an sie delegieren.

Standardmäßig werden alle Regeln in hierarchischen Firewallrichtlinien auf alle VMs in allen Projekten innerhalb der Organisation oder dem Ordner angewendet, dem die Richtlinie zugeordnet ist. Sie können jedoch einschränken, welche VMs eine bestimmte Regel erhalten, indem Sie Zielnetzwerke oder Zieldienstkonten angeben.

Die Hierarchieebenen, auf denen Firewallregeln jetzt angewendet werden können, sind im folgenden Diagramm dargestellt. Die gelben Felder stellen hierarchische Firewallrichtlinien dar, die Firewallregeln enthalten. Die weißen Felder hingegen stellen VPC-Firewallregeln dar.

Hierarchische Firewallrichtlinien, die Regeln (gelbe Kästchen) auf der Organisations- und der Ordnerebene und VPC-Firewallregeln auf der VPC-Netzwerkebene enthalten — Hierarchische Firewallrichtlinien mit Regeln (gelbe Kästchen) werden auf Organisations- und Ordnerebene angewendet. VPC-Firewallregeln werden auf VPC-Netzwerkebene angewendet.

Regelauswertung

Regeln hierarchischer Firewallrichtlinien werden auf VM-Ebene erzwungen, genauso wie Regeln von VPC-Firewalls. Das heißt, sie werden nicht wie herkömmliche Firewalls im Edge-Netzwerk angewendet.

Google Cloud wertet die Regeln hierarchischer Firewalls und die Regeln von VPC-Firewalls in dieser Reihenfolge aus:

Wenn eine Firewallrichtlinie einer Organisation zugeordnet ist, wertet Google Cloud die Regeln der Richtlinie aus, die auf die VM angewendet werden. Jede Regel führt dazu, dass Verbindungen zugelassen oder abgelehnt werden. Die Regel kann die Firewallauswertung auch dazu veranlassen, zur nächsten Hierarchieebene zu wechseln, also zu einem Ordner oder einem VPC-Netzwerk.
Google Cloud wertet die mit den einzelnen Ordnern verknüpften Richtlinienregeln aus, beginnend mit dem obersten Ordner unter der Organisation bis hin zu den untergeordneten Ordnern, sofern vorhanden.

Die Auswertung jeder Regel führt dazu, dass Verbindungen zugelassen oder abgelehnt werden. Alternativ kann die Regel die Firewallauswertung anweisen, zur nächsten Hierarchieebene zu wechseln, also entweder zu einem anderen Ordner oder einem VPC-Netzwerk.
Zuletzt werden VPC-Firewallregeln ausgewertet. VPC-Firewallregeln können Verbindungen zulassen oder ablehnen.

Ablauf der Auflösung von Firewallregeln — Auflösung von Firewallregeln

Hierarchische Firewallrichtlinien

Regeln hierarchischer Firewallrichtlinien werden in einer Firewallrichtlinienressource definiert, die als Container für Firewallregeln dient. Die in einer Firewallrichtlinie definierten Regeln werden erst erzwungen, wenn die Richtlinie mit einem Knoten (einer Organisation oder einem Ordner) verknüpft ist.

Eine einzelne Richtlinie kann mit mehreren Knoten verknüpft sein. Wenn Sie eine Regel in einer Richtlinie ändern, gilt diese Regel für alle derzeit verknüpften Knoten.

Es kann immer nur eine Firewallrichtlinie mit einem Knoten verknüpft werden. Hierarchische Firewallregeln und VPC-Firewallregeln werden in einer festgelegten Reihenfolge ausgewertet.

Eine Firewallrichtlinie, die keinem Knoten zugeordnet ist, ist eine nicht verknüpfte hierarchische Firewallrichtlinie.

Richtliniennamen

Wenn Sie eine neue Richtlinie erstellen, generiert Google Cloud automatisch eine ID für die Richtlinie. Geben Sie außerdem einen Kurznamen für die Richtlinie an. Wenn Sie eine vorhandene Richtlinie mit der gcloud-Schnittstelle aktualisieren, können Sie entweder auf die vom System generierte ID oder eine Kombination aus dem Kurznamen und der Organisations-ID verweisen. Wenn Sie die API zum Aktualisieren der Richtlinie verwenden, müssen Sie die vom System generierte ID angeben.

Regeln in hierarchischen Firewallrichtlinien

Hierarchische Firewallregeln enthalten Regeln, die im Allgemeinen so wie VPC-Firewallregeln funktionieren, es gibt jedoch einige Unterschiede.

Eingangsregel (Ingress)
Priorität	Aktion	Erzwingung	Parameter "target" (definiert den Bestimmungsort)	Quellfilter	Protokolle und Ports
Ganzzahl von `0` bis einschließlich `65535`	`allow`, `deny` oder `goto_next`	`enabled` (Standard) oder `disabled`	Mit dem Parameter target wird der Bestimmungsort angegeben. Dies kann einer der folgenden Werte sein: Alle Instanzen in allen VPC-Netzwerken in allen Projekten in den jeweiligen Knotenpunkten Instanzen nach Dienstkonto Instanzen nach angegebener Liste von Netzen	Beispiele: Bereich von IPv4-Adressen Bereich von IPv6-Adressen Wenn keine Quelle angegeben ist, wird der IPv4-Bereich `0.0.0.0/0` verwendet.	Geben Sie ein Protokoll oder ein Protokoll und einen Zielport an. Wenn nichts festgelegt ist, gilt die Regel für alle Protokolle und Zielports.
Ausgangsregel (Egress)
Priorität	Aktion	Erzwingung	Parameter "target" (definiert die Quelle)	Zielfilter	Protokolle und Ports
Ganzzahl von `0` bis einschließlich `65535`	`allow`, `deny` oder `goto_next`	`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 Dienstkonto Instanzen nach angegebener Liste von Netzen	Folgende Einstellungen sind möglich: Bereich von IPv4-Adressen Bereich von IPv6-Adressen Wenn kein Ziel angegeben ist, wird der IPv4-Bereich `0.0.0.0/0` verwendet.	Geben Sie ein Protokoll oder ein Protokoll und einen Zielport an. Wird nichts festgelegt, gilt die Regel für alle Protokolle und Zielports.

Priorität

Im Gegensatz zu VPC-Firewallregeln, bei denen mehrere Regeln dieselbe Priorität haben können, muss für Regeln in hierarchischen Firewallrichtlinien eine Priorität angegeben sein und jede Priorität innerhalb einer Firewallrichtlinie muss eindeutig sein.
Hierarchische Firewallrichtlinienregeln haben keine Namen. Stattdessen hat die Firewallrichtlinie selbst eine ID und einen Namen. Jede Regel darin hat eine eindeutige Prioritätsnummer.
Innerhalb einer hierarchischen Firewallrichtlinie werden die Firewallregeln nach Priorität ausgewertet, beginnend mit der Regel mit der höchsten Priorität (niedrigste Zahl). Somit überschreibt eine Regel mit der Priorität 0 in einer Richtlinie, die dem Organisationsknoten zugewiesen ist, alle anderen Regeln in der Organisation. Es empfiehlt sich, Regeln Prioritätsnummern zuzuweisen, die ein späteres Einfügen ermöglichen (z. B. 100, 200, 300).

Aktion bei Übereinstimmung

allow
Die allow-Regel einer hierarchischen Firewallrichtlinie überschreibt alle deny-Regeln mit einer niedrigeren Priorität bzw. auf einer niedrigeren Ebene in der Hierarchie. Verwenden Sie allow-Regeln in einer Organisation- oder Ordnerrichtlinie, um bestimmte Arten von Verbindungen zu allen VMs unter diesem Knoten in der Hierarchie bedingungslos zuzulassen.

Wenn Sie beispielsweise zentral verwaltete Prober haben, die alle VMs in Ihrer Organisation überwachen, können Sie eine allow-Regel auf Organisationsebene erstellen. Damit vermeiden Sie, dass Anfragen von den IP-Adressen der Prober durch ein beliebiges Netzwerk in einem beliebigen Projekt blockiert werden.
deny
Die deny-Regel einer hierarchischen Firewallrichtlinie überschreibt alle allow-Regeln mit einer niedrigeren Priorität bzw. auf einer niedrigeren Ebene in der Hierarchie.

Wenn Sie beispielsweise den Zugriff auf die VMs in Ihrer Organisation über einen bestimmten IP-Bereich verhindern möchten, können Sie eine deny-Regel für diesen Bereich erstellen.
goto_next
Weist die Firewall an, die Firewallauswertung auf die nächst niedrigere Hierarchieebene zu übertragen. Damit können Sie das Verwalten bestimmter Arten von Verbindungen an niedrigere Ebenen delegieren.

Ziele

Sie können angeben, für welche Zielnetzwerke und Zieldienstkonten die Regel einer hierarchischen Firewallrichtline gilt.

Zielnetzwerke (Zielressourcen)

Sie können Zielnetzwerke angeben, um eine hierarchische Firewallrichtlinienregel auf VMs in den angegebenen Netzwerken einzuschränken. Wenn Sie VPC-Netzwerke in der Regel angeben, können Sie steuern, welche Netzwerke mit dieser Regel konfiguriert werden.

In Kombination mit goto_next oder allow können Sie durch Angabe von Zielnetzwerken Ausnahmen für bestimmte Netzwerke erstellen, wenn Sie eine ansonsten restriktive Richtlinie definieren möchten.

Zieldienstkonten

Sie können Ziel-Dienstkonten angeben, um die Regel einer hierarchischen Firewallrichtlinie für VMs einzuschränken, die mit Zugriff auf die angegebenen Dienstkonten ausgeführt werden.

Die Richtung der Regel bestimmt, ob die Regelziele Quell- oder Zielinstanzen sind. Instanzen umfassen VM-Instanzen, GKE-Cluster und Instanzen der flexiblen App Engine-Umgebung.

Wenn die Regelrichtung „eingehend“ ist, definiert das Ziel die Zielinstanzen.
Wenn die Regelrichtung „ausgehend“ ist, definiert das Ziel die Quellinstanzen.

Die Angabe von Zielnetzwerken und Zieldienstkonten ist optional:

Wenn keine Zielnetzwerke angegeben sind, gilt die Regel für alle VPC-Netzwerke unter dem Knoten, mit dem die Richtlinie verknüpft ist.
Wenn keine Zieldienstkonten angegeben sind, gilt die Regel für alle VM-Instanzen unter dem Knoten, mit dem die Richtlinie verknüpft ist.
Wenn sowohl Zielnetzwerke als auch Zieldienstkonten angegeben sind, gilt die Regel nur für VM-Instanzen, die beide Zielkriterien erfüllen.

Protokolle und Ports

Ähnlich wie bei Regeln von VPC-Firewallregeln müssen Sie beim Erstellen einer Regel eine oder mehrere Protokoll- und Porteinschränkungen angeben. Beim Angeben von TCP oder UDP in einer Regel können Sie das Protokoll, das Protokoll und einen Zielport oder das Protokoll und einen Zielportbereich angeben. Sie können nicht nur einen Port oder Portbereich angeben. Außerdem können Sie nur Zielports angeben. Regeln für Quellports werden nicht unterstützt.

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

Viele Protokolle verwenden bei IPv4 und IPv6 denselben Namen und dieselbe Nummer, einige Protokolle wie ICMP jedoch nicht. Verwenden Sie icmp oder die Protokollnummer 1, um IPv4 ICMP anzugeben. Verwenden Sie für IPv6 ICMP die Protokollnummer 58.

Firewallregeln unterstützen nicht die Angabe von ICMP-Typen und -Codes, sondern nur das Protokoll.

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

Logging

Das Logging für Regeln von hierarchischen Firewallrichtlinien funktioniert genauso wie das Logging von Regeln in VPC-Firewalls, mit folgenden Ausnahmen:

Das Referenzfeld enthält die Firewallrichtlinien-ID und eine Zahl, die die hierarchische Ebene des Knotens angibt, mit dem die Richtlinie verknüpft ist. 0 bedeutet beispielsweise, dass die Richtlinie auf eine Organisation angewendet wird, und 1, dass die Richtlinie auf einen Ordner auf oberster Ebene unter der Organisation angewendet wird.
Logs für Regeln hierarchischer Firewallrichtlinien enthalten ein target_resource-Feld, das die VPC-Netzwerke angibt, auf die die Regel angewendet wird.

Logging kann nur für allow- und deny-Regeln aktiviert werden, nicht jedoch für goto_next-Regeln.

Vordefinierte Regeln

Alle hierarchischen Firewallrichtlinien haben vier vordefinierte goto_next-Regeln mit der niedrigsten Priorität. Diese Regeln werden auf alle Verbindungen angewendet, die nicht mit einer explizit definierten Regel in der Richtlinie übereinstimmen, sodass solche Verbindungen an untergeordnete Richtlinien oder Netzwerkregeln weitergegeben werden.

IPv4-Regeln:

Eine Regel für ausgehenden Traffic mit dem Ziel 0.0.0.0/0, die eine sehr niedrige Priorität (2147483646) hat und die die Verarbeitung der Verbindung an die nächste niedrigere Auswertungsebene (goto_next) sendet.
Eine Regel für eingehenden Traffic mit der Quelle 0.0.0.0/0 mit einer sehr niedrigen Priorität (2147483647), die die Verarbeitung der Verbindung an die nächste niedrigere Auswertungsebene (goto_next) sendet.

IPv6-Regeln:

Eine Regel für ausgehenden Traffic mit dem Ziel ::/0, die eine sehr niedrige Priorität (2147483644) hat und die die Verarbeitung der Verbindung an die nächste niedrigere Auswertungsebene (goto_next) sendet.
Eine Regel für eingehenden Traffic mit der Quelle ::/0 mit einer sehr niedrigen Priorität (2147483645), die die Verarbeitung der Verbindung an die nächste niedrigere Auswertungsebene (goto_next) sendet.

Diese vordefinierten Regeln sind sichtbar, können aber nicht geändert oder gelöscht werden. Diese Regeln unterscheiden sich von den impliziten und bereits ausgefüllten Regeln eines VPC-Netzwerks.

IAM-Rollen (Identity and Access Management, Identitäts- und Zugriffsverwaltung)

IAM-Rollen regeln die folgenden Aktionen in Bezug auf hierarchische Firewallrichtlinien:

Richtlinie erstellen, die in einem bestimmten Knoten enthalten ist
Richtlinie mit einem bestimmten Knoten verknüpfen
Vorhandene Richtlinie ändern
Aktive Firewallregeln für ein bestimmtes Netzwerk oder eine bestimmte VM aufrufen

In der folgenden Tabelle wird beschrieben, welche Rollen für die einzelnen Schritte erforderlich sind:

Funktion	Erforderliche Rolle
Neue hierarchische Firewall-Richtlinie erstellen	Rolle compute.orgFirewallPolicyAdmin für den Knoten, auf dem die Richtlinie ausgeführt wird
Richtlinie mit einem Knoten verknüpfen	compute.orgSecurityResourceAdmin für den Zielknoten und entweder compute.orgFirewallPolicyAdmin oder compute.orgFirewallPolicyUser für die Richtlinie selbst oder den Knoten, auf dem die Richtlinie ausgeführt wird
Richtlinie durch Hinzufügen, Aktualisieren oder Löschen von Richtlinien-Firewallregeln ändern	Rolle compute.orgFirewallPolicyAdmin für den Knoten, auf dem die Richtlinie ausgeführt wird, oder für die Richtlinie selbst
Richtlinie löschen	Rolle compute.orgFirewallPolicyAdmin für den Knoten, auf dem die Richtlinie ausgeführt wird, oder für die Richtlinie selbst
Gültige Firewallregeln für ein VPC-Netzwerk aufrufen	Eine der folgenden Rollen für das Netzwerk: compute.networkAdmin compute.networkViewer compute.securityAdmin compute.securityReadOnly compute.viewer
Gültige Firewallregeln für eine VM in einem Netzwerk aufrufen	Eine der folgenden Rollen für die VM: compute.instanceAdmin compute.securityAdmin compute.securityReadOnly compute.viewer

Die folgenden Rollen sind für hierarchische Firewallrichtlinien relevant.

Rollenname	Beschreibung
compute.orgFirewallPolicyAdmin	Kann für einen Knoten oder für eine einzelne Richtlinie gewährt werden. Wenn sie auf einem Knoten gewährt wird, können Nutzer hierarchische Firewallrichtlinien und ihre Regeln erstellen, aktualisieren und löschen. Wenn sie einer einzelnen Richtlinie gewährt wird, kann der Nutzer die Richtlinienregeln aktualisieren, die Richtlinie jedoch nicht erstellen oder löschen. Mit dieser Rolle kann der Nutzer auch eine Richtlinie mit einem Knoten verknüpfen, wenn er auch die Rolle `compute.orgSecurityResourceAdmin` für diesen Knoten hat.
compute.orgSecurityResourceAdmin	Wird auf der Organisationsebene oder einem Ordner gewährt; ermöglicht Administratoren auf der Ordnerebene, eine Richtlinien mit diesem Knoten zu verknüpfen. Administratoren müssen außerdem für den Knoten, dem die Richtlinie gehört, die Rolle `compute.orgFirewallPolicyUser` oder `compute.orgFirewallPolicyAdmim` haben, um die Richtlinie nutzen zu können.
compute.orgFirewallPolicyUser	Wird sie einem Knoten oder einer einzelnen Richtlinie zugewiesen, können Administratoren die jeweilige Richtlinie oder die mit dem Knoten verknüpften Richtlinien verwenden. Nutzer müssen außerdem die Rolle `compute.orgSecurityResourceAdmin` für den Zielknoten haben, um eine Richtlinie mit diesem Knoten zu verknüpfen.
compute.securityAdmin compute.viewer compute.networkUser compute.networkViewer	Nutzer können die Firewallregeln sehen, die auf das Netzwerk oder die Instanz angewendet werden. Enthält die Berechtigung `compute.networks.getEffectiveFirewalls` für Netzwerke und die Berechtigung `compute.instances.getEffectiveFirewalls` für Instanzen.

Im folgenden Beispiel kann Joe alle hierarchischen Firewallrichtlinien im Ordner policies erstellen, ändern und löschen. Er kann die hierarchische Firewallrichtlinie aber keinem Ordner hinzufügen, da er für keinen Ordner die Rolle orgSecurityResourceAdmin hat.

Da Joe jedoch Mary die Berechtigung zur Verwendung von policy-1 gewährt hat, kann sie diese hierarchische Firewallrichtlinie auflisten und mit dem Ordner dev-projects oder einem seiner untergeordneten Elemente verknüpfen. Die Rolle orgFirewallPolicyUser gewährt keine Berechtigung zum Verknüpfen der Richtlinien mit Ordnern. Der Nutzer muss auch die Rolle orgSecurityResourceAdmin für den Zielordner haben.

Ressourcen hierarchischer Firewallrichtlinien verwalten

Mit einer hierarchischen Firewallrichtlinie wird lediglich ein Satz Firewallregeln definiert, jedoch nicht angegeben, wo sie angewendet werden. Daher können Sie diese Ressourcen in einem anderen Teil der Hierarchie als den Knoten erstellen, auf die sie angewendet werden. Dadurch können Sie eine einzelne hierarchische Firewallrichtlinienressource mit mehreren Ordnern in der Organisation verknüpfen.

Im folgenden Beispiel wird policy-1 auf die Ordner dev-projects und corp-projects angewendet und für alle Projekte in diesen Ordnern erzwungen.

Speicherort und Verknüpfung von Richtlinien

Regeln einer Richtlinie ändern

Sie können Regeln einer Richtlinie hinzufügen, daraus entfernen und ändern. Jede Änderung wird einzeln durchgeführt. Es gibt keinen Mechanismus für Regeln für die Batch-Aktualisierung in einer Richtlinie. Änderungen werden ungefähr in der Reihenfolge angewendet, in der die Befehle ausgeführt werden. Dies ist jedoch nicht garantiert.

Wenn Sie umfangreiche Änderungen an einer hierarchischen Firewallrichtlinie vornehmen und dafür sorgen möchten, dass sie gleichzeitig angewendet werden, können Sie die Richtlinie in eine temporäre Richtlinie klonen und die temporäre Richtlinie den gleichen Knoten zuweisen. Sie können dann Änderungen am Original vornehmen und das Original dann wieder den Knoten zuweisen. Die dafür erforderlichen Schritte finden Sie unter Regeln von einer Richtlinie in eine andere klonen.

Im folgenden Beispiel ist policy-1 mit dem Ordner dev-projects verknüpft. Sie möchten mehrere Änderungen vornehmen, die atomar angewendet werden. Erstellen Sie eine neue Richtlinie mit dem Namen scratch-policy und kopieren Sie dann alle vorhandenen Regeln von policy-1 nach scratch-policy, um sie zu bearbeiten. Kopieren Sie nach Abschluss der Bearbeitung alle Regeln von scratch-policy zurück nach policy-1.

Richtlinie verschieben

Hierarchische Firewallrichtlinien wie Projekte sind einem Ordner oder einer Organisationsressource untergeordnet. Bei einer Weiterentwicklung des Ordnerschemas müssen Sie möglicherweise eine hierarchische Firewallrichtlinie in einen neuen Ordner verschieben, z. B. vor dem Löschen eines Ordners. Richtlinien eines Ordners werden gelöscht, wenn der Ordner gelöscht wird.

Das folgende Diagramm zeigt Verknüpfungen zum Verschieben einer Richtlinie zwischen Knoten oder die Auswertung von Regeln in der Richtlinie.

Hierarchische Firewallrichtlinie mit einem Ordner verknüpfen

Eine hierarchische Firewallrichtlinie wird nur erzwungen, wenn sie mit einem Organisations- oder Ordnerknoten verknüpft ist. Nachdem sie verknüpft wurde, wird sie auf alle VMs in allen Netzwerken unter dieser Organisation oder diesem Ordner angewendet.

Änderungen an der Ressourcenhierarchie

Es kann einige Zeit dauern, bis Änderungen an der Ressourcenhierarchie im System wirksam werden. Sie sollten gleichzeitige Aktualisierungen an den Zuordnungen von hierarchischen Firewallrichtlinien und der Ressourcenhierarchie vermeiden. Der Grund hierfür ist, dass die am neuen Speicherort in der Hierarchie definierte hierarchische Firewallrichtlinie möglicherweise nicht sofort von Netzwerken übernommen werden kann.

Wenn Sie beispielsweise den Ordner dept-A aus dem Ordner dev-projects in den Ordner eng-projects verschieben und policy-1 mit eng-projects statt dev-projects verknüpfen, heben Sie die Verknüpfung von policy-1 nicht gleichzeitig von dev-projects auf. Wenn der Ordner dev-projects seine Verknüpfung der hierarchischn Firewallrichtlinien verliert, bevor die Herkunft für alle ihm untergeordneten VPC-Netzwerke aktualisiert wurde, sind diese VPC-Netzwerke für kurze Zeit nicht durch policy-1 geschützt.

Hierarchische Firewallrichtlinien mit freigegebener VPC verwenden

In Szenarien mit freigegebenen VPCs gelten für eine VM-Schnittstelle, die mit einem Hostprojekt-Netzwerk verbunden ist, die hierarchischen Firewallregeln des Hostprojekts und nicht des Dienstprojekts.

Auch wenn sich die Dienstprojekte in einem anderen Ordner als dem Hostprojekt befinden, übernehmen die VM-Schnittstellen im freigegebenen Netzwerk die Einstellungen aus den Ordnerregeln des Hostprojekts.

Dienstprojekt-VMs übernehmen Regeln vom Hostprojekt

Hierarchische Firewallrichtlinien mit VPC-Netzwerk-Peering verwenden

In Szenarien für VPC-Netzwerk-Peering werden die Richtlinien in der Hierarchie der entsprechenden VPC-Netzwerke von der VM-Schnittstelle übernommen, die den einzelnen VPC-Netzwerken zugeordnet ist. Im Folgenden finden Sie ein Beispiel für VPC-Netzwerk-Peering, bei dem die VPC-Peering-Netzwerke verschiedenen Organisationen angehören.

VMs übernehmen Richtlinien von entsprechenden Netzwerken

Gültige Firewallregeln

Da Verbindungen sowohl Richtlinien aus hierarchischen Firewallregeln als auch aus VPC-Firewallregeln unterliegen, ist es hilfreich, alle Firewallregeln aufzurufen, die sich auf ein einzelnes Netzwerk oder eine einzelne VM-Schnittstelle auswirken.

Administratoren auf Projektebene haben möglicherweise nicht die Berechtigung, Regeln in hierarchischen Firewallrichtlinien aufzurufen, die sich auf ihre VMs auswirken. Wenn ein Nutzer jedoch die Berechtigungen hat, Firewallregeln für ein Netzwerk aufzurufen, kann er alle Regeln sehen, die für das Netzwerk gelten. Dies ist auch dann der Fall, wenn die Regeln von einem Ordner oder der Organisation übernommen werden.

Netzwerk-gültige Firewallrichtlinie

Sie können alle Firewallregeln aufrufen, die auf ein VPC-Netzwerk angewendet werden. Die Liste enthält alle Regeln, die von hierarchischen Firewallrichtlinien übernommen werden, sowie alle aus dem VPC-Netzwerk angewendeten Regeln.

Instanz-gültige Firewallregeln

Sie können alle Firewallregeln aufrufen, die auf die Netzwerkschnittstelle einer VM angewendet werden. Die Liste enthält alle Regeln, die von hierarchischen Firewallrichtlinien übernommen werden, sowie alle Regeln, die vom VPC-Netzwerk der Schnittstelle angewendet werden.

Die Regeln werden angefangen bei der Organisationsebene bis zu den VPC-Regeln sortiert. Es werden nur Regeln angezeigt, die für die VM-Schnittstelle gelten. Regeln in anderen Richtlinien werden nicht angezeigt. Nutzer können die allgemeine Firewallrichtlinie der Organisation also nicht sehen.

Nächste Schritte

Informationen zum Erstellen und Ändern von hierarchischen Firewallrichtlinien und -regeln finden Sie unter Hierarchische Firewallrichtlinien verwenden.
Beispiele für die Implementierung hierarchischer Firewallrichtlinien finden Sie unter Beispiele für hierarchische Firewallrichtlinien.