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 de l'organisation et du dossier. La création d'une stratégie n'applique pas automatiquement les règles à l'organisation ou au dossier.
- Une fois créées, les stratégies peuvent être appliquées (associées) à toutes les ressources 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 une ressource, 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 cette ressource.
- L'évaluation des règles est hiérarchique, en fonction de la hiérarchie des ressources. Toutes les règles associées à l'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_nextque 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 utilisées pour configurer l'inspection de couche 7 du trafic correspondant, telle que le service de prévention des intrusions.
Vous créez une règle de stratégie de pare-feu à l'aide de l'action
apply_security_profile_groupet du nom du groupe de profils de sécurité. Le trafic correspondant à la règle de stratégie de pare-feu est intercepté et transféré de manière transparente vers le point de terminaison de pare-feu pour l'inspection de couche 7, puis renvoyé. Pour en savoir plus sur la création d'une règle de stratégie de pare-feu, consultez la section Créer des règles de pare-feu.
- 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 de l'organisation ou du 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 la ressource 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 ressources 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'une ressource à une 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, les stratégies de pare-feu réseau 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 ou déléguer l'évaluation des connexions aux stratégies et règles de pare-feu réseau au niveau mondial.
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.
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 à une ressource (une organisation ou un dossier).
Une même stratégie peut être associée à plusieurs ressources. Si vous modifiez une règle d'une stratégie, cette modification s'applique à toutes les ressources associées.
Vous ne pouvez pas associer plusieurs stratégies de pare-feu à une ressource. 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 à aucune ressource 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 règles des stratégies de pare-feu hiérarchiques fonctionnent de la même manière que les règles de stratégie de pare-feu et les règles de pare-feu VPC, à quelques différences près :
Les stratégies de pare-feu hiérarchiques sont compatibles avec les réseaux cibles, contrairement aux stratégies de pare-feu de réseau au niveau mondial. Vous pouvez spécifier des réseaux cibles pour limiter une règle de pare-feu 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_nextouallow, 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.Les stratégies de pare-feu hiérarchiques ne disposent pas d'une intégration sécurisée des tags.
Les stratégies de pare-feu hiérarchiques sont des ressources au niveau de l'organisation, tandis que les stratégies de pare-feu de réseau au niveau mondial sont des ressources au niveau du projet.
Règles prédéfinies
Lorsque vous créez une stratégie de pare-feu hiérarchique, Cloud Next Generation Firewall ajoute des règles prédéfinies avec la priorité la plus basse à la stratégie. 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 stratégies de niveau inférieur ou à des règles de réseau.
Pour en savoir plus sur les différents types de règles prédéfinies et leurs caractéristiques, consultez la section Règles prédéfinies.
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 une ressource spécifique
- Associer une stratégie à une ressource spécifique
- 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 la ressource sur laquelle la stratégie va résider |
| Associer une stratégie à une ressource | Rôle compute.orgSecurityResourceAdmin sur la ressource cible, et le rôle compute.orgFirewallPolicyAdmin ou compute.orgFirewallPolicyUser sur la ressource où se trouve la stratégie, ou sur la stratégie elle-même |
| 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 la ressource hébergeant la stratégie ou sur la stratégie elle-même |
| Supprimer la stratégie | rôle compute.orgFirewallPolicyAdmin sur la ressource 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 | L'un des rôles suivants pour le réseau : compute.networkAdmin compute.networkViewer compute.securityAdmin compute.viewer |
| Afficher les stratégies de pare-feu efficaces pour une VM dans un réseau | L'un des rôles suivants pour la VM : compute.instanceAdmin compute.securityAdmin 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 une ressource ou sur une stratégie individuelle. Si cette autorisation est accordée à une ressource, 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 à une ressource s'il possède également le rôle compute.orgSecurityResourceAdmin sur cette ressource. |
| 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 à cette ressource. Les administrateurs doivent également disposer du rôle compute.orgFirewallPolicyUser ou compute.orgFirewallPolicyAdmin sur la ressource qui possède la règle ou sur la règle elle-même pour pouvoir l'utiliser. |
| compute.orgFirewallPolicyUser | Accordé sur une ressource ou sur une stratégie individuelle, ce rôle permet aux administrateurs d'utiliser la ou les stratégies individuelles associées à la ressource. Les utilisateurs doivent également disposer du rôle compute.orgSecurityResourceAdmin sur la ressource cible pour associer une stratégie à cette ressource. |
|
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.
Gérer les ressources de stratégies de pare-feu hiérarchiques
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 ressources auxquelles 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.
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 ressources. Vous pouvez ensuite apporter des modifications à la stratégie d'origine, puis la réattribuer aux ressources. 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.
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 ressources ou l'évaluation des règles de la 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 à une organisation ou à un dossier. Une fois associée, elle est appliquée à toutes les VM de tous les réseaux de cette organisation ou de ce dossier.
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.
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.
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.
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.
Étapes suivantes
- Consultez la page Utiliser des stratégies de pare-feu hiérarchiques pour en savoir plus sur la création et la modification des règles et des stratégies de pare-feu hiérarchiques.
- Pour consulter des exemples d'implémentations de stratégies de pare-feu hiérarchiques, consultez la section Exemples de stratégies de pare-feu hiérarchiques.