Présentation des stratégies de pare-feu hiérarchiques

Les stratégies de pare-feu hiérarchiques vous permettent de créer et d'appliquer une stratégie de pare-feu cohérente dans votre organisation. Vous pouvez attribuer des stratégies de pare-feu hiérarchiques à l'organisation dans son ensemble ou à des dossiers individuels. Ces stratégies contiennent des règles qui peuvent explicitement refuser ou autoriser des connexions, tout comme les règles de pare-feu du cloud privé virtuel (VPC). En outre, les règles des stratégies de pare-feu hiérarchiques peuvent déléguer l'évaluation à des stratégies de niveau inférieur ou à des règles de pare-feu de réseau VPC avec une action goto_next.

Les règles de niveau inférieur ne peuvent pas remplacer une règle de niveau supérieur dans la hiérarchie des ressources. Cela permet aux administrateurs d'organisation de gérer les règles de pare-feu critiques de manière centralisée.

Spécifications

  • Les stratégies de pare-feu hiérarchique sont créées au niveau des nœuds d'organisation et de dossiers. La création d'une stratégie n'applique pas automatiquement les règles au nœud.
  • Une fois créées, les stratégies peuvent être appliquées (associées) à tous les nœuds de l'organisation.
  • Les stratégies de pare-feu hiérarchiques sont des conteneurs pour les règles de pare-feu. Lorsque vous associez une stratégie à l'organisation ou à un dossier, toutes les règles sont immédiatement appliquées. Vous pouvez échanger des stratégies pour un nœud, ce qui permet d'échanger de manière atomique toutes les règles de pare-feu appliquées aux instances de machine virtuelle (VM) sous ce nœud.
  • L'évaluation des règles est hiérarchique, en fonction de la hiérarchie des ressources. Toutes les règles associées au nœud d'organisation sont évaluées, suivies de celles du premier niveau des dossiers, etc.
  • Les règles des stratégies de pare-feu hiérarchiques comportent une nouvelle action goto_next que vous pouvez utiliser pour déléguer l'évaluation des connexions à des niveaux inférieurs de la hiérarchie.
  • Les règles des stratégies de pare-feu hiérarchiques peuvent être ciblées sur des réseaux VPC et des VM spécifiques en utilisant des ressources cibles pour les réseaux et des comptes de service cibles pour les VM. Cela vous permet de créer des exceptions pour des groupes de VM. Les règles des stratégies de pare-feu hiérarchiques ne sont pas compatibles avec le ciblage par tags d'instance.
  • Chaque règle de stratégie de pare-feu hiérarchique peut inclure des plages IPv4 ou IPv6, mais pas les deux.
  • Pour faciliter la conformité et le débogage, il est possible de vérifier les règles de pare-feu appliquées à une instance de VM à l'aide de la page des détails du réseau VPC et de la page des détails de l'interface réseau de l'instance de VM.

Hiérarchie des ressources

Vous créez et appliquez des stratégies de pare-feu en tant qu'étapes distinctes. Vous pouvez créer et appliquer des stratégies de pare-feu au niveau des nœuds d'organisation ou de dossier de la hiérarchie des ressources. Une règle de stratégie de pare-feu peut bloquer les connexions, autoriser les connexions ou reporter l'évaluation des règles de pare-feu aux dossiers de niveau inférieur ou aux règles de pare-feu VPC définies dans les réseaux VPC.

  • L'organisation est le nœud de premier niveau de la hiérarchie des ressources dans Google Cloud, où vous pouvez créer ou associer des stratégies de pare-feu hiérarchiques. Tous les dossiers et réseaux VPC de l'organisation héritent de cette stratégie.

  • Les dossiers sont des nœuds de niveau intermédiaire dans la hiérarchie des ressources Google Cloud, entre l'organisation et les projets, dans lesquels vous pouvez créer ou attribuer des stratégies de pare-feu hiérarchiques. Tous les dossiers et réseaux VPC d'un dossier héritent de la stratégie associée.

  • Un projet réside dans un dossier ou dans l'organisation. Vous pouvez déplacer des projets d'un nœud à un autre au sein d'une même organisation. Les projets contiennent des réseaux VPC. Les stratégies de pare-feu hiérarchiques ne peuvent pas être attribuées à des projets. Elle ne peuvent être affectées qu'à l'organisation ou à des dossiers.

  • Un réseau VPC est la partition Google Cloud utilisée pour la communication avec l'espace d'adressage IP interne isolé. Il s'agit du niveau auquel les routes et les règles de pare-feu VPC traditionnelles sont spécifiées et appliquées. Les règles des stratégies de pare-feu hiérarchiques peuvent remplacer les règles de pare-feu du réseau ou leur déléguer l'évaluation de la connexion.

Par défaut, toutes les règles des stratégies de pare-feu hiérarchiques s'appliquent à toutes les VM de tous les projets de l'organisation ou du dossier auquel la stratégie est associée. Toutefois, vous pouvez restreindre les VM qui reçoivent une règle donnée en spécifiant des réseaux cibles ou des comptes de service cibles.

Les niveaux de la hiérarchie auxquels les règles de pare-feu peuvent désormais être appliquées sont représentés dans le schéma suivant. Les cadres jaunes représentent les stratégies de pare-feu hiérarchiques qui contiennent des règles de pare-feu, tandis que les cadres blancs représentent les règles de pare-feu VPC.

Stratégies de pare-feu hiérarchiques contenant des règles (cadres jaunes) au niveau de l'organisation et des dossiers ainsi que des règles de pare-feu VPC au niveau du réseau VPC
Les stratégies de pare-feu hiérarchiques contenant des règles (zones jaunes) sont appliquées au niveau de l'organisation et du dossier. Les règles de pare-feu VPC sont appliquées au niveau du réseau VPC.

Évaluation des règles

Les règles des stratégies de pare-feu hiérarchiques sont appliquées au niveau de la VM, tout comme les règles de pare-feu VPC. Autrement dit, elles ne sont pas appliquées au réseau périphérique, comme les pare-feu traditionnels.

Google Cloud évalue les règles des stratégies de pare-feu hiérarchiques et les règles de pare-feu VPC dans l'ordre suivant :

  1. Si une stratégie de pare-feu est associée à une organisation, Google Cloud évalue les règles de cette stratégie appliquées à la VM. Chaque règle entraîne l'autorisation ou le refus des connexions ; la règle peut également demander à l'évaluation du pare-feu d'accéder au niveau suivant de la hiérarchie, à savoir un dossier ou un réseau VPC.
  2. Google Cloud évalue les règles des stratégies associées à chaque dossier, en commençant par le dossier supérieur de l'organisation et en parcourant les dossiers enfants, le cas échéant.

    L'évaluation de chaque règle entraîne l'autorisation ou le refus des connexions ; la règle peut également demander à l'évaluation du pare-feu d'accéder au niveau suivant de la hiérarchie, à savoir un autre dossier ou un réseau VPC.

  3. Enfin, les règles de pare-feu VPC sont évaluées. Les règles de pare-feu VPC autorisent ou refusent les connexions.

Flux de résolution des règles de pare-feu
Flux de résolution des règles de pare-feu

Détails des stratégies de pare-feu hiérarchiques

Les règles des stratégies de pare-feu hiérarchiques sont définies dans une ressource de stratégie de pare-feu qui agit comme un conteneur pour les règles de pare-feu. Les règles définies dans une stratégie de pare-feu ne sont pas appliquées tant que la stratégie n'est pas associée à un nœud (une organisation ou un dossier).

Une même stratégie peut être associée à plusieurs nœuds. Si vous modifiez une règle d'une stratégie, cette modification s'applique à tous les nœuds actuellement associés.

Vous ne pouvez pas associer plusieurs stratégies de pare-feu à un nœud. Les règles des stratégies de pare-feu hiérarchiques et les règles de pare-feu VPC sont évaluées dans un ordre bien défini.

Une stratégie de pare-feu qui n'est associée à aucun nœud est une stratégie de pare-feu hiérarchique non associée.

Noms des stratégies

Lorsque vous créez une stratégie, Google Cloud génère automatiquement un ID pour cette stratégie. En outre, vous spécifiez également un nom court pour la stratégie. Lorsque vous utilisez l'interface gcloud pour mettre à jour une stratégie existante, vous pouvez référencer l'ID généré par le système ou une combinaison du nom court et de votre ID d'organisation. Lorsque vous utilisez l'API pour mettre à jour la stratégie, vous devez fournir l'ID généré par le système.

Détails des règles des stratégies de pare-feu hiérarchiques

Les stratégies de pare-feu hiérarchiques contiennent des règles qui fonctionnent généralement de la même manière que les règles de pare-feu VPC, à quelques différences près.

Priorité

  • Contrairement aux règles de pare-feu VPC, dans lesquelles plusieurs règles peuvent avoir la même priorité, les règles des stratégies de pare-feu hiérarchiques doivent avoir une priorité spécifiée, et chaque priorité doit être unique au sein d'une stratégie de pare-feu.

  • Les règles des stratégies de pare-feu hiérarchiques n'ont pas de nom. Au lieu de cela, la stratégie de pare-feu elle-même possède un ID et un nom, et chaque règle comporte un numéro de priorité unique.

  • Dans une stratégie de pare-feu hiérarchique, les règles de pare-feu sont évaluées par ordre de priorité, en commençant par la règle de priorité la plus élevée (nombre le plus faible). Ainsi, une règle dont la priorité est 0 dans une stratégie attribuée au nœud de l'organisation remplace toute autre règle de l'organisation. Une bonne pratique consiste à attribuer aux règles des numéros de priorité qui permettront l'insertion ultérieure (par exemple, 100, 200, 300).

Action en cas de correspondance

  • allow
    Une règle allow dans une stratégie de pare-feu hiérarchique remplace toute règle deny ayant une priorité inférieure ou un niveau inférieur dans la hiérarchie. Utilisez des règles allow dans une stratégie d'organisation ou de dossier pour autoriser certains types de connexions à toutes les VM situées sous ce nœud dans la hiérarchie.

    Par exemple, si vous disposez de vérificateurs gérés de manière centralisée qui surveillent toutes les VM de votre organisation, vous pouvez créer une règle allow au niveau de l'organisation pour vous assurer que les requêtes des adresses IP des vérificateurs ne sont bloquées par aucun réseau dans aucun projet.

  • deny
    Une règle deny dans une stratégie de pare-feu hiérarchique remplace toute règle allow ayant une priorité inférieure ou un niveau inférieur dans la hiérarchie.

    Par exemple, si vous souhaitez vous assurer qu'aucune des VM de votre organisation n'est accessible depuis une plage d'adresses IP spécifique, vous pouvez créer une règle deny pour cette plage.

  • goto_next
    Ordonne au pare-feu de déplacer l'évaluation du pare-feu vers le niveau inférieur de la hiérarchie. Vous pouvez utiliser ce paramètre pour déléguer des types spécifiques de connexions que les niveaux inférieurs doivent gérer.

Cibles

Vous pouvez spécifier les réseaux cibles et les comptes de service cibles auxquels une règle de pare-feu hiérarchique s'applique.

Réseaux cibles (ressources cibles)

Vous pouvez spécifier des réseaux cibles pour limiter une règle de pare-feu hiérarchique aux VM des réseaux spécifiés. La spécification de réseaux VPC dans la règle vous permet de contrôler les réseaux configurés avec cette règle.

Combiné avec goto_next ou allow, le fait de spécifier des réseaux cibles vous permet de créer des exceptions pour des réseaux spécifiques lorsque vous souhaitez définir une règle restrictive.

Comptes de service cibles

Vous pouvez spécifier des comptes de service cibles pour limiter une règle de pare-feu hiérarchique aux VM en cours d'exécution qui ont accès aux comptes de service spécifiés.

Le sens de la règle détermine si les cibles de la règle sont des instances sources ou de destination. Les instances incluent des instances de VM, des clusters GKE et des instances de l'environnement flexible App Engine.

  • Pour une règle d'entrée, la cible définit les instances de destination.

  • Pour une règle de sortie, la cible définit les instances de source.

La spécification de réseaux cibles et de comptes de service cibles est facultative :

  • Si aucun réseau cible n'est spécifié, la règle s'applique à tous les réseaux VPC sous le nœud auquel la règle est associée.

  • Si aucun compte de service cible n'est spécifié, la règle s'applique à toutes les instances de VM sous le nœud auquel la règle est associée.

  • Si les réseaux cibles et les comptes de service cibles sont spécifiés, la règle s'applique uniquement aux instances de VM qui répondent aux deux critères cibles.

Protocoles et ports

Comme pour les règles de pare-feu VPC, vous devez spécifier une ou plusieurs contraintes de protocole et de port au moment de la création d'une règle. Lorsque vous indiquez TCP ou UDP dans une règle, vous pouvez spécifier le protocole, le protocole et un port de destination, ou le protocole et une plage de ports de destination. Vous ne pouvez pas spécifier uniquement un port ou une plage de ports. De plus, vous ne pouvez spécifier que des ports de destination. Les règles basées sur les ports sources ne sont pas acceptées.

Pour le protocole ICMP IPv4, spécifiez icmp. Les règles de pare-feu ne permettent pas de spécifier des types et des codes ICMP.

Vous pouvez utiliser les noms de protocoles suivants dans les règles de pare-feu : tcp, udp, icmp (pour IPv4 ICMP), esp, ah, sctp et ipip. Pour tous les autres protocoles, utilisez les numéros de protocole IANA.

De nombreux protocoles ont les mêmes nom et numéro dans IPv4 et IPv6, ce qui n'est pas le cas de certains protocoles comme ICMP.

Le protocole IPv6 Hop-by-Hop n'est pas compatible avec les règles de pare-feu.

Logging

La journalisation des règles des stratégies de pare-feu hiérarchiques fonctionne de la même manière que la journalisation des règles de pare-feu VPC, à l'exception des éléments suivants :

  • Le champ de référence inclut l'ID de la stratégie de pare-feu ainsi qu'un numéro indiquant le niveau hiérarchique du nœud auquel la stratégie est associée. Par exemple, 0 signifie que la stratégie est appliquée à une organisation et 1 signifie qu'elle est appliquée à un dossier de premier niveau sous l'organisation.

  • Les journaux des règles des stratégies de pare-feu hiérarchiques incluent un champ target_resource qui identifie les réseaux VPC auxquels la règle s'applique.

La journalisation ne peut être activée que pour les règles allow et deny. Elle ne peut pas être activée pour les règles goto_next.

Règles prédéfinies

Toutes les stratégies de pare-feu hiérarchiques disposent de deux règles goto_next prédéfinies avec la priorité la plus basse. Ces règles sont appliquées à toutes les connexions qui ne correspondent pas à une règle définie explicitement dans la stratégie, ce qui entraîne leur transmission à des règles de niveau inférieur ou à des règles de réseau.

Règles IPv4 :

  • Une règle de sortie dont la destination est 0.0.0.0/0, avec une priorité très faible (2147483646), qui envoie le traitement de la connexion au niveau d'évaluation inférieur (goto_next).

  • Une règle d'entrée dont la source est 0.0.0.0/0, avec une priorité très faible (2147483647), qui envoie le traitement de la connexion au niveau d'évaluation inférieur (goto_next).

Règles IPv6 :

  • Une règle de sortie dont la destination est ::/0, avec une priorité très faible (2147483644), qui envoie le traitement de la connexion au niveau d'évaluation inférieur (goto_next).

  • Une règle d'entrée dont la source est ::/0, avec une priorité très faible (2147483645), qui envoie le traitement de la connexion au niveau d'évaluation inférieur (goto_next).

Ces règles prédéfinies sont visibles, mais elles ne peuvent pas être modifiées ni supprimées. Elles sont différentes des règles implicites et préremplies d'un réseau VPC.

Rôles IAM (Identity and Access Management)

Les rôles IAM régissent les actions suivantes en ce qui concerne les stratégies de pare-feu hiérarchiques :

  • Créer une stratégie qui réside sur un nœud particulier
  • Associer une stratégie à un nœud particulier
  • Modifier une stratégie existante
  • Afficher les stratégies de pare-feu en vigueur pour un réseau ou une VM spécifique

Le tableau suivant décrit les rôles nécessaires pour chaque étape :

Aptitude Rôle nécessaire
Créer une stratégie de pare-feu hiérarchique Rôle compute.orgFirewallPolicyAdmin sur le nœud sur lequel la stratégie va résider
Associer une stratégie à un nœud compute.orgSecurityResourceAdmin sur le nœud cible _and_ compute.orgFirewallFirewallAdmin _or_ compute.orgFirewallFirewallPolicy sur la stratégie elle-même ou sur le nœud où réside la stratégie
Modifier la stratégie en ajoutant, en mettant à jour ou en supprimant des règles de stratégie de pare-feu rôle compute.orgFirewallPolicyAdmin sur le nœud hébergeant la stratégie ou sur la stratégie elle-même
Supprimer la stratégie rôle compute.orgFirewallPolicyAdmin sur le nœud hébergeant la stratégie ou sur la stratégie elle-même
Afficher les stratégies de pare-feu efficaces pour un réseau VPC Tous les rôles suivants pour le réseau :
compute.networkAdmin
compute.networkViewer
compute.securityAdmin
compute.securityReadOnly
compute.viewer
Afficher les stratégies de pare-feu efficaces pour une VM dans un réseau Tous les rôles suivants pour la VM :
compute.instanceAdmin
compute.securityAdmin
compute.securityReadOnly
compute.viewer

Les rôles suivants sont pertinents pour les stratégies de pare-feu hiérarchiques.

Nom de rôle Description
compute.orgFirewallPolicyAdmin Peut être accordé sur un nœud ou sur une stratégie individuelle. Si cette autorisation est accordée à un nœud, les utilisateurs peuvent créer, mettre à jour et supprimer des stratégies de pare-feu hiérarchiques, ainsi que leurs règles. Si elle est accordée à une stratégie individuelle, elle permet à l'utilisateur de mettre à jour les règles des stratégies, mais pas de créer ni de supprimer la stratégie. Ce rôle permet également à l'utilisateur d'associer une stratégie à un nœud s'il possède également le rôle compute.orgSecurityResourceAdmin sur ce nœud.
compute.orgSecurityResourceAdmin Accordé au niveau de l'organisation ou à un dossier, ce rôle permet aux administrateurs au niveau du dossier d'associer une stratégie à ce nœud. Les administrateurs doivent également disposer du rôle compute.orgFirewallPolicyUser ou compute.orgFirewallPolicyAdmim sur le nœud qui possède la règle ou sur la règle elle-même pour pouvoir l'utiliser.
compute.orgFirewallPolicyUser Accordé sur un nœud ou sur une stratégie individuelle, ce rôle permet aux administrateurs d'utiliser la ou les stratégies individuelles associées au nœud. Les utilisateurs doivent également disposer du rôle compute.orgSecurityResourceAdmin sur le nœud cible pour associer une stratégie à ce nœud.
compute.securityAdmin
compute.viewer
compute.networkUser
compute.networkViewer
Permet aux utilisateurs d'afficher les règles de pare-feu appliquées au réseau ou à l'instance.
Fournit l'autorisation compute.networks.getEffectiveFirewalls pour les réseaux et l'autorisation compute.instances.getEffectiveFirewalls pour les instances.

Dans l'exemple suivant, Jean peut créer, modifier et supprimer une stratégie de pare-feu hiérarchique dans le dossier policies, mais il ne peut pas associer la stratégie de pare-feu hiérarchique à un dossier, car il ne dispose du rôle orgSecurityResourceAdmin sur aucun dossier.

Cependant, comme Jean a accordé à Marie l'autorisation d'utiliser policy-1, elle peut répertorier et associer cette stratégie de pare-feu hiérarchique au dossier dev-projects ou à l'un de ses descendants. Le rôle orgFirewallPolicyUser n'accorde pas l'autorisation d'associer les stratégies à des dossiers. Pour cela, l'utilisateur doit également disposer du rôle orgSecurityResourceAdmin sur le dossier cible.

Exemple de stratégie 1
Exemple de stratégie 1

Gérer les ressources de stratégie de pare-feu hiérarchique

Comme une stratégie de pare-feu hiérarchique ne définit qu'un ensemble de règles de pare-feu et non l'emplacement où elles agissent, vous pouvez créer ces ressources dans une partie de la hiérarchie différente des nœuds auxquels elles s'appliquent. Cela vous permet d'associer une même ressource de stratégie de pare-feu hiérarchique à plusieurs dossiers de l'organisation.

Dans l'exemple suivant, la stratégie policy-1 est appliquée aux dossiers dev-projects et corp-projects. Elle est donc active dans tous les projets de ces dossiers.

Emplacement et association des stratégies
Emplacement et association des stratégies

Modifier les règles d'une stratégie

Vous pouvez ajouter, supprimer et modifier des règles dans une stratégie. Chaque modification est effectuée individuellement. Il n'existe pas de mécanisme de mise à jour groupée des règles d'une stratégie. Les modifications sont plus ou moins appliquées dans l'ordre dans lequel les commandes sont exécutées, bien que cela ne soit pas garanti.

Si vous apportez des modifications importantes à une stratégie de pare-feu hiérarchique et que vous devez vous assurer qu'elles sont appliquées en même temps, vous pouvez cloner la stratégie sur une stratégie temporaire, puis attribuer cette dernière aux mêmes nœuds. Vous pouvez ensuite apporter des modifications à la stratégie d'origine, puis la réattribuer aux nœuds. Pour connaître la procédure à suivre, consultez la section Cloner des règles d'une stratégie à une autre.

Dans l'exemple suivant, policy-1 est associé au dossier dev-projects et vous souhaitez apporter plusieurs modifications qui s'appliquent de manière atomique. Créez une stratégie nommée scratch-policy, puis copiez toutes les règles existantes de policy-1 vers scratch-policy pour les modifier. Une fois les modifications terminées, copiez toutes les règles de scratch-policy dans policy-1.

Modifier une stratégie
Modifier une stratégie

Déplacer une stratégie

Tout comme les projets, les stratégies de pare-feu hiérarchiques ont comme parent un dossier ou une ressource d'organisation. À mesure que votre schéma de dossiers évolue, vous devrez peut-être déplacer une stratégie de pare-feu hiérarchique vers un nouveau dossier, avant une suppression de dossier, par exemple. Les stratégies appartenant à un dossier sont supprimées en cas de suppression du dossier.

Le schéma suivant illustre le transfert d'une stratégie entre des nœuds ou l'évaluation des règles de la stratégie.

Déplacer une stratégie
Déplacer une stratégie

Associer une stratégie de pare-feu hiérarchique à un dossier

Une stratégie de pare-feu hiérarchique n'est appliquée que si elle est associée à un nœud d'organisation ou de dossier. Une fois associée, elle est appliquée à toutes les VM de tous les réseaux de cette organisation ou de ce dossier.

Associer une stratégie
Associer une stratégie

Modifications apportées à la hiérarchie des ressources

Les modifications apportées à la hiérarchie des ressources peuvent prendre un certain temps pour se propager dans le système. Nous vous recommandons d'éviter les mises à jour simultanées des rattachements de stratégies de pare-feu hiérarchiques et de la hiérarchie des ressources, car les réseaux peuvent ne pas hériter immédiatement de la stratégie de pare-feu hiérarchique définie au nouvel emplacement de la hiérarchie.

Déplacer une stratégie
Déplacer une stratégie

Par exemple, si vous déplacez le dossier dept-A du dossier dev-projects vers le dossier eng-projects et remplacez l'association de policy-1 par eng-projects au lieu de dev-projects, assurez-vous de ne pas dissocier policy-1 de dev-projects en même temps. Si le dossier dev-projects perd son association de stratégie de pare-feu hiérarchique avant que tous les ancêtres des réseaux VPC situés en dessous ne soient mis à jour, ces réseaux VPC ne seront pas protégés par policy-1 pendant une courte période.

Utiliser des stratégies de pare-feu hiérarchiques avec un VPC partagé

Dans les scénarios de VPC partagé, une interface de VM connectée à un réseau du projet hôte est régie par les règles de stratégies de pare-feu hiérarchiques du projet hôte, et non par le projet de service.

VM dans un VPC partagé
VM dans un VPC partagé

Même si les projets de service se trouvent dans un dossier différent du projet hôte, les interfaces de VM du réseau partagé héritent toujours des règles du dossier du projet hôte.

Les VM de projet de service héritent des règles du projet hôte
Les VM de projet de service héritent des règles du projet hôte

Utiliser des stratégies de pare-feu hiérarchiques avec l'appairage de réseaux VPC

Dans les scénarios d'appairage de réseaux VPC, l'interface de VM associée à chacun des réseaux VPC hérite des stratégies de la hiérarchie des réseaux VPC respectifs. Voici un exemple d'appairage de réseaux VPC dans lequel les réseaux appairés VPC appartiennent à différentes organisations.

Les VM héritent de leurs réseaux respectifs
Les VM héritent de leurs réseaux respectifs

Règles de pare-feu efficaces

Étant donné que les connexions sont régies par des règles de stratégies de pare-feu hiérarchiques et des règles de pare-feu VPC, il est utile d'avoir une visibilité sur l'intégralité des règles de pare-feu qui affectent un réseau individuel ou une interface de VM individuelle.

Les administrateurs au niveau du projet peuvent ne pas être autorisés à afficher les règles dans les stratégies de pare-feu hiérarchiques qui affectent leurs VM. Toutefois, si un utilisateur est autorisé à afficher les règles de pare-feu pour un réseau, il peut consulter toutes les règles qui s'appliquent au réseau, même si celles-ci sont héritées d'un dossier ou de l'organisation.

Stratégie de pare-feu efficace du réseau

Vous pouvez afficher toutes les règles de pare-feu appliquées à un réseau VPC. La liste inclut toutes les règles héritées des stratégies de pare-feu hiérarchiques et toutes les règles appliquées à partir du réseau VPC.

Règles de pare-feu efficaces pour l'instance

Vous pouvez afficher toutes les règles de pare-feu appliquées à l'interface réseau d'une VM. La liste inclut toutes les règles héritées des stratégies de pare-feu hiérarchiques et toutes les règles appliquées à partir du réseau VPC de l'interface.

Les règles sont triées en commençant par le niveau de l'organisation pour finir par le niveau des règles de VPC. Seules les règles qui s'appliquent à l'interface de la VM s'affichent. Les règles des autres stratégies ne sont pas affichées. Un utilisateur ne peut donc pas voir la stratégie de pare-feu globale de l'organisation.

Étape suivante