Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Bonnes pratiques concernant les tags sécurisés dans Cloud NGFW

Ce document présente les bonnes pratiques architecturales pour concevoir, gérer et appliquer des tags sécurisés dans Cloud Next Generation Firewall (Cloud NGFW). Les tags sécurisés offrent une approche de la sécurité réseau basée sur l'identité. Ils associent l'évaluation des règles de pare-feu aux identités de charge de travail des machines virtuelles (VM) plutôt qu'aux adresses IP dynamiques. Les tags sécurisés sont une fonctionnalité de base incluse dans le niveau Cloud Next Generation Firewall Essentials et sont compatibles avec tous les niveaux Cloud NGFW. Ce guide s'adresse aux architectes réseau, aux administrateurs de sécurité et aux ingénieurs DevOps qui conçoivent et gèrent des règles de sécurité réseau dans le cloud.

Ce document organise les bonnes pratiques en quatre étapes clés du cycle de vie des balises sécurisées :

Concevez votre schéma de tags : alignez les tags sur les identités de charge de travail, configurez la microsegmentation et conservez des tags à granularité large pour éviter de dépasser les limites de quota de tags sécurisés.
Configurer le contrôle des accès et la gouvernance : établissez la séparation des tâches Identity and Access Management (IAM), choisissez les portées appropriées et appliquez les tags lors du provisionnement des VM.
Concevez des stratégies de pare-feu et une logique de règles : optimisez l'évaluation des règles, configurez des stratégies hiérarchiques et implémentez des règles de refus par défaut sécurisées.
Protéger, surveiller et auditer : empêchez les suppressions accidentelles grâce aux suspensions de tags, activez la journalisation du pare-feu et effectuez des audits d'accès réguliers.

Avant d'utiliser ce guide, assurez-vous de connaître la présentation des tags sécurisés pour les pare-feu et la présentation de Cloud NGFW.

Récapitulatif des bonnes pratiques

Le tableau suivant récapitule les bonnes pratiques de base tout au long du cycle de vie des balises sécurisées :

Étape du cycle de vie	Recommandation clé	Description
Conception du schéma de balises	Aligner les tags avec l'identité de charge de travail	Définissez des clés de tag par rôle de charge de travail (par exemple, `env/prod` ou `tier/database`), appliquez des valeurs mutuellement exclusives et conservez des tags à granularité large pour respecter les limites de quota.
Contrôle des accès et gouvernance	Appliquer la séparation des tâches	Accordez le rôle `roles/resourcemanager.tagAdmin` exclusivement aux équipes de sécurité, limitez le rôle `roles/resourcemanager.tagUser` aux pipelines de déploiement et choisissez le bon champ d'application (`organization=auto` ou `network`).
Provisionnement de VM	Appliquer des tags lors de la création	Associez des tags sécurisés aux interfaces réseau des VM lors du provisionnement et utilisez des règles d'administration pour exiger des tags sur toutes les nouvelles instances.
Architecture des règles	Spécifier des tags sécurisés cibles	Utilisez des tags sécurisés cibles dans les règles de pare-feu pour évaluer les performances statiques. Configurez des règles de refus par défaut dans les stratégies hiérarchiques pour protéger les ressources non taguées.
Sécurité multiréseau	Connectivité sécurisée entre les clouds privés virtuels (VPC)	Maintenez les limites d'identité dans les réseaux VPC appairés et les spokes Network Connectivity Center (NCC) sans gérer les blocs CIDR statiques.
Protection et surveillance	Protéger et surveiller les tags	Appliquez des mises en attente de tags pour éviter toute suppression accidentelle, activez la journalisation des règles de pare-feu pour le dépannage et auditez régulièrement les attributions IAM.

Concevoir votre schéma de balises

Un schéma de tag bien structuré simplifie les règles de pare-feu, rationalise les audits de sécurité et empêche les conflits de règles.

Aligner les tags avec Workload Identity

Concevez des clés de tag sécurisées autour de rôles de charge de travail, de niveaux d'application ou de classifications réglementaires distincts :

Niveau d'environnement : env/prod, env/staging, env/dev
Niveau d'application : tier/frontend, tier/backend, tier/database
État de conformité : scope/pci-dss, scope/hipaa

Exemple : microsegmentation d'une application à trois niveaux

Une application Web à trois niveaux typique se compose d'une interface Web, d'un backend d'application et d'une base de données. Pour protéger votre base de données contre les accès non autorisés, vous pouvez utiliser des tags sécurisés pour appliquer une microsegmentation du réseau. Ainsi, chaque niveau ne peut communiquer qu'avec le niveau adjacent :

[ Web Tier (tag: tier/frontend) ]
              |
              |  Allow port 8080 (Web can communicate with App)
              v
[ App Tier (tag: tier/backend) ]
              |
              |  Allow port 5432 (App can communicate with DB)
              v
[ Database Tier (tag: tier/database) ]

Pour appliquer ce flux, configurez deux règles de stratégie de pare-feu :

Règle 1 (Web vers application) : autoriser l'entrée sur le port 8080 lorsque le tag source est tier/frontend et le tag cible est tier/backend.
Règle 2 (application vers base de données) : autoriser l'entrée sur le port 5432 lorsque le tag source est tier/backend et le tag cible est tier/database.

Résultat : l'interface Web ne peut pas communiquer directement avec le niveau de base de données, car aucune règle de pare-feu n'autorise le trafic entre tier/frontend et tier/database. Cloud NGFW applique automatiquement cette limite, même si les instances de VM partagent le même sous-réseau IP.

Migration des tags réseau vers les tags sécurisés

Lorsque vous passez des tags réseau VPC aux tags sécurisés de pare-feu, tenez compte des différences d'architecture suivantes :

Capacité	Tags réseau (règles VPC)	Tags sécurisés (stratégies de pare-feu)
Spécification de la cible	`targetTags = ["web-tier"]`	`targetSecureTags = ["tagValues/1234567890"]`
Spécification de la source	`sourceTags = ["db-client"]`	`sourceSecureTags = ["tagValues/0987654321"]`
Champ d'application	Un seul réseau VPC	Entre les réseaux VPC appairés, les spokes NCC et les stratégies hiérarchiques
Prise en charge du calcul d'itinéraire	Vous pouvez utiliser des tags réseau comme sauts suivants pour les routes statiques (également appelés tags de route).	Vous ne pouvez pas utiliser de tags sécurisés pour le routage. Utilisez-les uniquement pour filtrer le trafic du pare-feu.
Access control (Contrôle des accès)	Aucune autorisation IAM sur les tags individuels	Resource Manager et les rôles IAM régissent strictement l'accès aux tags et leur association.

Appliquer des valeurs de tag uniques

Assurez-vous que les ressources reçoivent exactement une valeur par clé de tag. Par exemple, une instance de VM doit être associée à env/prod ou env/dev, mais jamais aux deux :

À faire : attribuez un seul tag d'environnement (env/prod) et autorisez l'accès aux services partagés par le biais de règles de pare-feu explicites faisant référence à des tags de destination (tels que env/shared-logging).
Ne empilez pas plusieurs tags d'environnement (env/prod et env/dev) sur la même VM. Cela permet à la VM de correspondre aux règles de pare-feu de développement, ce qui expose les ressources de production au trafic des développeurs.

Utilisez des tags généraux pour respecter les quotas

Regroupez les instances de VM similaires sous des valeurs de tag partagées au lieu de créer des tags uniques spécifiques aux instances. Le taggage à granularité large permet de gérer votre stratégie de sécurité et d'empêcher votre organisation de dépasser les limites de quota de tags sécurisés.

Lorsque vous planifiez votre schéma de balises, examinez les limites suivantes :

Utiliser des tags au lieu de comptes de service pour les VM à plusieurs cartes d'interface réseau

Nous vous recommandons d'utiliser des tags sécurisés plutôt que des comptes de service comme sources ou destinations dans les règles de pare-feu. Contrairement aux comptes de service, vous pouvez associer des tags sécurisés directement aux interfaces réseau individuelles (cartes d'interface réseau virtuelle) d'une VM multihébergée. Cette approche vous permet d'appliquer différentes règles réseau à chaque interface réseau.

Configurer le contrôle des accès et la gouvernance

IAM régit les tags sécurisés pour fournir un contrôle des accès strict et une séparation claire des responsabilités.

Séparer les tâches avec les rôles IAM

Établissez une limite opérationnelle entre les administrateurs qui créent des tags et les équipes qui provisionnent des charges de travail :

Administrateur de tags (roles/resourcemanager.tagAdmin) : rôle à accorder exclusivement aux administrateurs centraux du réseau et de la sécurité pour créer, modifier et supprimer des clés et des valeurs de tags.
Utilisateur de tags (roles/resourcemanager.tagUser) : accordez ce rôle aux comptes de service de provisionnement ou aux pipelines de déploiement CI/CD automatisés pour qu'ils puissent associer des tags aux interfaces réseau des VM dans des périmètres de projet ou de ressources spécifiques.
Lecteur de balises (roles/resourcemanager.tagViewer) : accordez ce rôle aux équipes opérationnelles et d'audit qui ont besoin d'une visibilité en lecture seule sur les configurations de balises.

Empêcher l'auto-taggage et l'élévation des privilèges

À faire : n'accordez roles/resourcemanager.tagUser qu'aux pipelines de déploiement Infrastructure as Code (IaC) audités (tels que les workflows Terraform google_tags_tag_binding) au niveau du projet ou de l'interface réseau.
À éviter : accorder roles/resourcemanager.tagUser de manière générale aux groupes de développeurs au niveau de l'organisation. Cela empêche les développeurs d'associer eux-mêmes des tags de production (tels que env/prod) à des charges de travail de développement non autorisées.

Définir correctement la portée des clés de tag

Définissez des clés de tag sécurisées au niveau de la hiérarchie des ressources qui correspond à votre gouvernance opérationnelle :

Tags à portée d'organisation (purpose-data=organization=auto) : définissez des clés au niveau de l'organisation ou du dossier pour une gouvernance de la sécurité centralisée sur plusieurs réseaux VPC, réseaux appairés et stratégies de pare-feu hiérarchiques.
Tags à portée réseau (purpose-data=network) : à utiliser uniquement pour l'isolation au niveau du projet, où les tags doivent être définitivement limités à un seul réseau VPC.

Appliquer l'attribution de tags lors de la création d'une VM

L'association de tags sécurisés aux interfaces réseau des VM au moment de la création garantit que les charges de travail sont protégées immédiatement lors de leur lancement.

Pour vous assurer que les utilisateurs et les pipelines automatisés ne peuvent pas provisionner d'instances sans les tags sécurisés requis, configurez une règle d'administration pour appliquer des tags lors de la création de ressources. Cette règle bloque la création d'instances de VM non taguées et non protégées.

Concevoir des stratégies de pare-feu et une logique de règles

Intégrez des tags sécurisés à vos stratégies de pare-feu pour optimiser l'évaluation des règles et assurer une protection cohérente.

Utiliser des stratégies de pare-feu hiérarchiques pour une application centralisée

Définissez des règles de pare-feu qui font référence à des tags sécurisés dans des stratégies de pare-feu hiérarchiques au niveau de l'organisation ou du dossier. Les règles hiérarchiques appliquent une gouvernance à l'échelle de l'organisation que les propriétaires de projets locaux ne peuvent pas remplacer.

Spécifier des tags sécurisés cibles pour plus d'efficacité

Lorsque vous créez des règles de stratégie de pare-feu, spécifiez des tags sécurisés cibles (targetSecureTags) dans la mesure du possible. Cloud NGFW évalue les tags cibles et les tags sources différemment :

Tags sécurisés cibles (correspondance statique) : les règles avec des tags cibles s'appliquent de manière statique uniquement aux instances de VM qui portent ces tags. Cela réduit le nombre de règles évaluées sur chaque VM et améliore les performances.
Tags sécurisés sources (correspondance dynamique par connexion) : les règles qui ne spécifient que des tags sources (sourceSecureTags) sans tags cibles sont évaluées de manière dynamique pour chaque connexion sur toutes les instances de VM du réseau, ce qui augmente la surcharge de traitement.

Implémenter des paramètres par défaut sécurisés avec le refus par défaut hiérarchique

Étant donné que les instances de VM n'héritent pas des tags sécurisés GCE_FIREWALL des dossiers ou organisations parents, protégez les ressources sans tag en définissant des règles de secours sécurisées dans les règles hiérarchiques :

Règle de refus par défaut : créez une règle de faible priorité (par exemple, priorité 65000) au niveau de l'organisation ou du dossier qui refuse tout le trafic par défaut.
Règles d'autorisation conditionnelle : créez des règles de priorité plus élevée qui autorisent le trafic uniquement entre des tags sécurisés spécifiques (par exemple, de tier/frontend à tier/backend).

Si une instance de VM est créée sans tags ou si ses tags sont détachés, la règle hiérarchique de refus par défaut bloque automatiquement le trafic vers et depuis l'instance.

Utiliser des tags sécurisés sur les réseaux appairés et NCC

Utilisez des tags sécurisés pour contrôler le trafic entre les réseaux VPC connectés à l'aide de l'appairage de réseaux VPC ou des spokes VPC NCC. Les tags sécurisés maintiennent des limites tenant compte de l'identité sur les réseaux connectés sans que vous ayez à gérer les blocs CIDR changeants.

Protéger, surveiller et auditer

Des contrôles opérationnels continus garantissent que vos configurations de tags sécurisées restent sécurisées et résilientes.

Protéger les valeurs de tag critiques avec des éléments TagHold

Évitez les pannes accidentelles qui se produisent lorsque vous supprimez des tags en cours d'utilisation :

Appliquez des éléments TagHold aux valeurs de tags sécurisés critiques pour éviter leur suppression.
Avant de dissocier le tag sécurisé des interfaces réseau de VM, vérifiez qu'aucune règle de pare-feu active ne s'appuie dessus. Vous devez supprimer toutes les liaisons de ressources (et toutes les retenues de tags) avant Google Cloud de pouvoir supprimer une valeur de tag sécurisée.

Activer la journalisation des règles de pare-feu

Activez la journalisation des règles de stratégie de pare-feu pour toutes les règles qui utilisent des tags sécurisés. Ces journaux enregistrent les hits de trafic correspondants pour vous aider à auditer les schémas d'accès, à vérifier la segmentation et à résoudre les problèmes de connectivité.

Auditez régulièrement les attributions de rôles IAM

Auditez régulièrement les attributions de comptes principaux pour roles/resourcemanager.tagAdmin et roles/resourcemanager.tagUser. Cet audit garantit que seules les pipelines autorisées disposent d'autorisations de liaison de tags, ce qui empêche l'élévation des privilèges et préserve l'isolation de l'environnement.