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érarchiques peuvent être spécifiées au niveau des nœuds d'organisation et de dossier.
  • 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 cibler des réseaux VPC et des VM spécifiques à l'aide de ressources cibles. Cela vous permet de créer des exceptions pour des groupes de VM.
  • Une nouvelle fonctionnalité vous permet de voir quelles règles de pare-feu sont réellement appliquées à un réseau ou à une interface de VM spécifique, ce qui facilite la mise en conformité et le débogage.

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 limiter les VM qui reçoivent une règle donnée en spécifiant un réseau cible ou un compte de service cible.

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

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

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 à afficher 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 à afficher 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.

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.

Réseaux cibles

Vous pouvez limiter une règle de stratégie de pare-feu hiérarchique aux VM des réseaux spécifiés. La spécification du réseau cible dans la règle vous permet de contrôler les réseaux VPC configurés avec cette règle. Si ce paramètre est associé à goto_next ou allow, il vous permet de créer des exceptions pour des réseaux spécifiques lorsque vous souhaitez définir une stratégie autrement restrictive.

Comptes de service cibles

Vous pouvez spécifier un compte de service cible pour une règle. Ces règles ne s'appliquent qu'aux VM appartenant au compte de service spécifié. Les règles des stratégies de pare-feu hiérarchiques ne sont pas compatibles avec le ciblage par tags d'instance.

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, ou le protocole et une plage de ports. Vous ne pouvez pas spécifier uniquement un port ou une plage de ports. Pour ICMP, spécifiez icmp. Les règles de pare-feu ne permettent pas de spécifier des types et des codes ICMP.

Journalisation

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 sécurité 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.

  • Une règle de sortie 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 avec une priorité très faible (2147483647) 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 suivants sont pertinents pour les stratégies de pare-feu hiérarchiques.

Nom de rôle Description
compute.orgSecurityPolicyAdmin Accordé au niveau de l'organisation ou à un dossier, ce rôle permet aux utilisateurs de créer, mettre à jour et supprimer des stratégies de sécurité hiérarchiques et leurs règles. Ce rôle permet également à l'administrateur d'associer une stratégie à un nœud s'il dispose également du 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.orgSecurityPolicyUser sur le nœud propriétaire de la stratégie pour pouvoir l'utiliser.
compute.orgSecurityPolicyUser Accordé au niveau de l'organisation ou à un dossier, ce rôle permet aux administrateurs d'utiliser des stratégies associées à l'organisation ou au dossier. 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.securityReadOnly
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 orgSecurityPolicyUser 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 Copier 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 sécurité réseau efficace

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 sécurité globale de l'organisation.

Étapes suivantes