Google PCNE: Règles de pare-feu, Cloud Armor et sécurité réseau — Guide d'étude

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Fait partie du Google Professional Cloud Network Engineer — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Google, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

La politique de pare-feu, Cloud Armor et la sécurité réseau sur Google Cloud fournissent ensemble des contrôles en couches pour la segmentation, la réduction de la surface d’attaque, la résilience DDoS et l’observabilité. Les conceptions efficaces combinent un ciblage basé sur l’identité, une application hiérarchique, des entrées et sorties de moindre privilège, et des protections en périphérie liées aux équilibreurs de charge mondiaux de Google. Le succès opérationnel dépend de la compréhension de l’évaluation des règles, des comportements implicites, du périmètre de journalisation et de l’origine réelle du trafic pour les différents modes d’équilibrage de charge.

Règles de pare-feu VPC et ciblage basé sur l’identité

Les règles de pare-feu VPC sont stateful et évaluées par réseau, direction et priorité.

• Direction et règles implicites :
  • L’entrée (ingress) est évaluée pour le trafic entrant sur une carte réseau (NIC) de VM ; la sortie (egress) pour le trafic qui en part.
  • Deux règles implicites existent dans chaque VPC : une règle implicite de refus total en entrée et une règle implicite d’autorisation totale en sortie. Celles-ci ne peuvent pas être modifiées et ne produisent pas de journaux. Le réseau par défaut crée également plusieurs règles permissives, ce que ne font pas les VPC personnalisés.
• Priorité et évaluation :
  • Les priorités vont de 0 à 65535, les plus basses étant évaluées en premier. La première règle correspondante détermine entièrement l’action.
  • Si plusieurs règles de même priorité correspondent, la plage d’adresses IP la plus spécifique l’emporte ; en cas de spécificité égale et d’actions contradictoires, le refus l’emporte. Évitez les chevauchements de règles de même priorité.
• Cibles et sources :
  • Les cibles définissent à quelles VM la règle s’applique : tags réseau, comptes de service de VM ou tags sécurisés. Les sources/destinations sont des CIDR IP ; pour l’entrée, vous pouvez également spécifier des comptes de service ou des tags source pour les sources du même VPC.
  • Les tags réseau sont des métadonnées de VM configurables par les utilisateurs du projet ; ils sont simples mais moins contrôlés. Les comptes de service permettent un ciblage basé sur l’identité, lié à l’identité de la charge de travail et à IAM, ce qui les rend plus difficiles à utiliser à mauvais escient. Les tags sécurisés (tags du gestionnaire de ressources au niveau de l’organisation liés via IAM) permettent aux équipes de sécurité de contrôler quelles VM une règle peut cibler, sans autoriser les développeurs à s’auto-attribuer des tags qui contournent la protection ; utilisez-les pour une gouvernance plus forte.
• Journalisation :
  • Activez la journalisation des règles de pare-feu règle par règle pour capturer les connexions autorisées ou refusées qui correspondent à cette règle. Les refus implicites ne sont pas journalisés ; si vous avez besoin de journaux de refus, ajoutez une règle de refus explicite à haute priorité avec la journalisation activée.
  • Les journaux incluent la référence de la règle, l’action, le 5-tuple, les octets, et peuvent être exportés pour une analyse forensique.

Conception et opérations :

• Entrée de moindre privilège : Préférez un refus par défaut en utilisant des refus explicites à haute priorité, puis ajoutez des autorisations ciblées par compte de service ou tag sécurisé. Pour les groupes d’instances derrière un équilibreur de charge, n’autorisez que le trafic provenant des plages d’adresses IP de l’équilibreur de charge ou de la vérification de l’état qui sont la source réelle du trafic.
• Sortie de moindre privilège : Remplacez l’autorisation implicite par une règle explicite de refus total en sortie à haute priorité, complétée par des autorisations ciblées (pour les plages d’adresses IP du NAT, les adresses IP des partenaires ou les API Google via Private Google Access). Faites attention à ne pas interrompre les flux de retour ; le caractère stateful permet les réponses aux connexions autorisées sans règles supplémentaires.
• Ciblage basé sur l’identité :
  • Utilisez les comptes de service pour une politique de type « qui peut parler à qui », indépendamment de la mobilité des adresses IP.
  • Utilisez les tags sécurisés pour empêcher les développeurs de s’auto-attribuer des tags réseau permissifs.
• Pièges courants et modes de défaillance :
  • Identité source de l’équilibreur de charge : Pour les équilibreurs de charge HTTP(S) externes, les backends voient les connexions provenant des proxys Google Front End, et non des adresses IP des clients. Utilisez Cloud Armor pour autoriser/refuser les adresses IP des clients ; utilisez le pare-feu VPC pour autoriser les plages de sortie des GFE et de vérification de l’état. Pour les équilibreurs de charge réseau TCP/UDP, les backends voient l’adresse IP du client ; les listes d’autorisation du pare-feu pour les adresses IP des clients s’appliquent directement.
  • Absence de journaux de refus : Les refus provenant des règles implicites ne sont pas journalisés. Ajoutez une règle de refus explicite avec la journalisation activée pour observer le trafic bloqué.
  • Contournement du NAT : Si une VM a une adresse IP externe, elle l’utilisera pour le trafic de sortie et contournera Cloud NAT. Supprimez l’adresse IP externe pour forcer l’utilisation du NAT.
  • Diagnostic de non-concordance de règle : Confirmez la direction, l’identité de la cible (tag/compte de service/tag sécurisé), la priorité et les filtres de source. Si les journaux ne montrent aucune correspondance, le trafic n’atteint pas la règle que vous attendez.

Exemple court, autorisation d’entrée basée sur l’identité avec journalisation :

• Cible : compte de service sa: web-backend@project.iam.gserviceaccount.com
• Plages sources : plages des proxys GFE + vérifications de l’état Google
• Priorité : 100
• Action : autoriser tcp:80,443
• Journalisation : activée

Stratégie de pare-feu hiérarchique, segmentation et périmètres de service

Les stratégies de pare-feu hiérarchiques appliquent des règles à l’échelle de l’organisation ou du dossier avant toute règle de niveau VPC. Utilisez-les pour garantir des garde-fous (par exemple, « refuser tout le trafic entrant depuis Internet vers les VM sans équilibreur de charge » ou « refuser RDP/SSH depuis 0.0.0.0/0 »). Les règles VPC de niveau inférieur ne peuvent pas remplacer une règle de refus (deny) au niveau de l’organisation/du dossier qui a déjà correspondu.

Stratégie de segmentation :

• Segmentation du trafic entrant (ingress) :
  • Stratégie d’organisation/de dossier : règles de refus (deny) à haute priorité pour les ports à risque et un refus par défaut, sauf pour les points d’entrée autorisés. Autorisez les plages de vérification de l’état (health check) de Google si nécessaire.
  • Règles VPC : autorisations (allow) spécifiques aux charges de travail (workloads) ciblées par compte de service ou tag sécurisé. Pour les services internes, utilisez Private Service Connect ou l’équilibrage de charge interne pour l’accès est-ouest avec des règles restreintes.
• Segmentation du trafic sortant (egress) :
  • Remplacez la règle implicite autorisant tout le trafic sortant (allow-all egress) par une règle de refus de tout le trafic sortant (deny-all egress) à haute priorité au niveau de l’organisation/du dossier ou du VPC, puis n’ouvrez que ce qui est nécessaire :
    • Trafic sortant vers Internet via Cloud NAT ou des pare-feu de sortie approuvés.
    • API Google via Private Google Access et les points de terminaison private.googleapis.com ou restricted.googleapis.com. Le point de terminaison restreint s’associe à VPC Service Controls pour empêcher l’exfiltration de données vers des identités ou des projets non autorisés.
    • Pour les architectures qui dirigent 0.0.0.0/0 à travers un pare-feu tiers mais nécessitent toujours un accès direct aux API Google sans effet de « hairpinning », ajoutez des routes statiques pour les blocs VIP des API Google vers la passerelle Internet par défaut et activez Private Google Access sur les sous-réseaux. Cela préserve les contrôles de sécurité tout en réduisant la latence et la dépendance à l’égard du dispositif tiers pour les services internes (first-party).

Interactions avec les périmètres de service :

• VPC Service Controls définit des périmètres autour des projets et des API Google compatibles pour atténuer l’exfiltration de données. Lorsque les périmètres sont activés :
  • Préférez restricted.googleapis.com pour que les appels d’API restent dans le contexte du périmètre.
  • Assurez-vous que le DNS pointe les domaines pertinents vers les points de terminaison restreints ou privés et que les routes ne retournent pas vers des dispositifs de sortie non approuvés.
  • Combinez la stratégie de périmètre avec des listes d’autorisation (allowlists) de pare-feu de sortie pour éviter les fuites accidentelles vers des points de terminaison hors périmètre.

Compromis :

• Les refus (deny) au niveau de l’organisation simplifient la gestion des risques mais peuvent bloquer des expérimentations légitimes si le contrôle des changements est lent ; déléguez les exceptions à l’aide de tags sécurisés et de flux de demande documentés.
• Des refus de sortie (egress deny) agressifs réduisent le « blast radius » (rayon de l’impact) mais nécessitent une découverte de services et un contrôle des changements robustes pour éviter les pannes.

Cloud Armor, WAF et protections en périphérie du réseau mondial (edge)

Cloud Armor associe des stratégies de sécurité aux équilibreurs de charge HTTP(S) externes et Proxy TCP/SSL externes pour assurer une protection en périphérie du réseau (edge).

• Règles WAF :
  • Utilisez des règles préconfigurées pour le Top 10 de l’OWASP et les CVE courants, ainsi que des règles personnalisées utilisant un langage d’expression pour faire correspondre les en-têtes, les adresses IP, les pays, les URI, etc.
  • Attachez-les par service de backend et ordonnez les règles par priorité. Les actions incluent autoriser (allow), refuser (deny) avec des réponses spécifiques, ou rediriger pour le HTTP(S).
• Limitation de débit :
  • Appliquez des quotas par clé (par exemple, par adresse IP client, en-tête ou cookie) avec des fenêtres glissantes et des contrôles de rafale (burst). Les bannissements basés sur le débit ajoutent automatiquement des refus temporaires pour les sources abusives.
• Adaptive Protection :
  • La détection d’anomalies basée sur le ML apprend les modèles de requêtes normaux et signale les attaques DDoS de couche 7 ou les abus. Elle peut suggérer ou générer automatiquement des règles candidates ; déployez-les d’abord en mode prévisualisation (preview).
• Mode prévisualisation (preview) :
  • Évaluez les nouvelles règles sans impacter le trafic. Les résultats de la prévisualisation sont journalisés, ce qui permet un ajustement à faible risque. Passez en mode d’application (enforced) après vérification.

Défense DDoS et contrôles de l’équilibreur de charge mondial :

• Le réseau en périphérie (edge) anycast mondial de Google absorbe les attaques volumétriques de couche 3/4 ; la validation SYN/ACK, le traitement des paquets malformés et la capacité de mise à l’échelle automatique en périphérie sont intégrés à la plateforme pour les équilibreurs de charge HTTP(S) externes et Proxy TCP/SSL.
• Combinez-le avec Cloud Armor pour atténuer les inondations de couche 7 (L7 floods), le « credential stuffing » et l’abus applicatif.
• Appliquez des stratégies TLS, des chiffrements modernes et, si nécessaire, le mTLS client au niveau de l’équilibreur de charge. Pour les exigences IPv6, utilisez un équilibreur de charge mondial externe HTTP(S) ou Proxy TCP/SSL avec des adresses IP virtuelles (VIP) IPv6.
• Pour mettre sur liste d’autorisation (allowlisting) des adresses IP clientes spécifiques pour une application derrière un équilibreur de charge :
  • Si vous utilisez HTTP(S), préférez les listes d’autorisation (allowlists) de Cloud Armor basées sur l’adresse IP du client et limitez les règles de pare-feu du backend aux sources GFE et de vérification de l’état (health check).
  • Si vous utilisez un équilibreur de charge réseau (Network Load Balancer) TCP/UDP, les backends voient l’adresse IP réelle du client ; appliquez les listes d’autorisation (allowlists) du pare-feu VPC directement aux instances ciblées (par tag sécurisé ou compte de service) et incluez les adresses IP de vérification de l’état de Google.

Précautions opérationnelles :

• Les règles sont évaluées en périphérie du réseau (edge) ; des listes d’autorisation (allowlists) incorrectes peuvent provoquer instantanément des pannes mondiales. Utilisez la prévisualisation et les déploiements progressifs (staged rollouts), et surveillez les journaux de Cloud Armor ainsi que les métriques de l’équilibreur de charge.
• Les besoins en affinité de session varient : pour des protocoles mixtes (par exemple, HTTP et TFTP provenant du même client vers le même pool de backends), l’affinité par adresse IP client sur l’équilibreur de charge préserve la persistance de session (« stickiness ») entre les ports.

Visibilité, inspection et réponse aux incidents

Observabilité :

• Les VPC Flow Logs fournissent des enregistrements de flux 5-uplets échantillonnés par sous-réseau avec un échantillonnage, un enrichissement des métadonnées et des intervalles d’agrégation configurables. Utilisez-les pour l’analyse comparative des performances et la détection d’anomalies.
• La journalisation des règles de pare-feu capture les autorisations et les refus par connexion pour les règles spécifiques où la journalisation est activée ; créez des règles de refus explicites pour journaliser les blocages qui, autrement, correspondraient à des refus implicites.
• Les journaux de requêtes et les résultats de prévisualisation de Cloud Armor montrent les correspondances de règles, les décisions d’action et les résultats de la limitation de débit en périphérie (edge).

Inspection et détection :

• Packet Mirroring copie le trafic vers un collecteur dans la même région pour une inspection approfondie des paquets (DPI) ou un IDS. Limitez la portée de la mise en miroir par sous-réseau, tag ou compte de service pour limiter la surcharge. La mise en miroir de paquets est hors bande (out-of-band) et non bloquante ; utilisez-la avec Cloud IDS ou des capteurs tiers.
• L’inspection L7 en ligne (inline) nécessite un modèle d’appliance à 2 NIC et un routage à travers celle-ci. Concevez pour un routage symétrique et une haute disponibilité (HA) ; tenez compte des domaines de panne régionaux et des goulots d’étranglement potentiels du débit. Les dispositifs en ligne augmentent le périmètre de l’impact (blast radius) en cas de défaillance ; déployez des groupes d’instances gérés et des modèles de basculement de route avec vérification de l’état (health-checked) le cas échéant.

Pratiques de réponse aux incidents :

• Centralisez les journaux dans un projet de sécurité, construisez des détections pour les pics soudains de refus, la création de nouvelles règles à haute priorité ou les déclenchements de limitation de débit de Cloud Armor. Utilisez BigQuery ou des intégrations SIEM pour l’investigation.
• Assurez le moindre privilège IAM : le rôle Network Admin est insuffisant pour modifier les politiques de pare-feu dans un VPC partagé (Shared VPC) où le rôle Security Admin est requis ; séparez les tâches entre les équipes réseau et sécurité.
• Lorsque vous avez besoin d’un accès d’urgence (break-glass) SSH et que les clés ne sont pas pré-provisionnées, utilisez

undefined

depuis Cloud Shell pour pousser une clé éphémère via les métadonnées de l’instance si cela est autorisé par les paramètres IAM et les métadonnées de l’instance.

• Pour dépanner les scénarios « sans journaux » : vérifiez la règle et la direction, souvenez-vous que les refus implicites ne sont pas journalisés, et vérifiez les politiques hiérarchiques qui auraient pu correspondre plus tôt.

Scénario de problème pratique

Contoso Retail exploite une plateforme web multi-niveaux sur Google Cloud. Le trafic frontend est servi par un équilibreur de charge HTTP(S) externe mondial ; les VM applicatives s’exécutent dans plusieurs régions sans adresses IP externes. Le trafic de sortie (egress) doit passer en épingle à cheveux (hairpin) par un NGFW tiers, à l’exception des API Google (BigQuery et Pub/Sub). L’équipe de sécurité souhaite des garde-fous à l’échelle de l’organisation, des listes d’autorisation d’IP client pour un projet pilote avec un partenaire, et un risque minimal lors du test d’un client suspecté d’être malveillant.

Approche :

1. Établir des garde-fous hiérarchiques

   • Créez une politique de pare-feu hiérarchique au niveau de l’organisation qui refuse tout le trafic d’entrée (ingress) depuis 0.0.0.0/0 vers les cibles de VM ne possédant pas le tag sécurisé env=public-entry, et qui refuse les ports administratifs (SSH, RDP) depuis Internet.
   • Justification : Empêche l’exposition non sécurisée à l’échelle mondiale ; les développeurs ne peuvent pas s’auto-attribuer le tag sécurisé en raison des permissions IAM sur les tags.

2. Ciblage des charges de travail basé sur l’identité

   • Attribuez des comptes de service distincts aux niveaux frontend, applicatif et base de données. Référencez ces comptes de service dans les règles de pare-feu au niveau du VPC pour n’autoriser que les flux est-ouest requis (par exemple, frontend→app tcp:443, app→db tcp:5432).
   • Justification : Lie la politique à l’identité de la charge de travail et résiste à une mauvaise utilisation accidentelle des tags.

3. Autorisations d’entrée (ingress) pour les backends à charge équilibrée

   • Sur les VM applicatives, créez une règle d’autorisation d’entrée (ingress) à haute priorité ciblant le compte de service de l’application, avec des plages sources égales aux proxys Google Front End et aux plages de vérification de l’état (health check) de Google ; activez la journalisation.
   • Justification : Pour le trafic HTTP(S) L7, les backends ne devraient accepter que les connexions provenant des adresses IP des GFE et des vérifications de l’état ; les listes d’autorisation d’IP client sont appliquées en périphérie (edge).

4. Politique de périmètre (edge) Cloud Armor

   • Attachez une politique Cloud Armor au service de backend de l’équilibreur de charge HTTP(S) externe :
     • Ajoutez une règle de liste d’autorisation pour les adresses IP du client partenaire.
     • Activez les règles WAF préconfigurées pour le Top 10 de l’OWASP.
     • Configurez une limitation de débit basée sur l’adresse IP du client avec des seuils conservateurs.
   • Justification : Applique les restrictions de source client et les protections de la couche applicative là où l’adresse IP du client est visible et avant que le trafic n’atteigne le VPC.

5. Protection adaptative et tests sécurisés

   • Activez Adaptive Protection et créez une règle de refus pour l’adresse IP du client suspect en mode prévisualisation (preview).
   • Justification : La prévisualisation permet de vérifier le comportement sans impacter les utilisateurs réels ; les journaux confirment si le client est malveillant avant d’appliquer la règle.

6. Segmentation de la sortie (egress) avec Private Google Access

   • Conservez une route 0.0.0.0/0 vers le NGFW tiers. Ajoutez des routes statiques personnalisées pour les VIP des API Google vers la passerelle Internet par défaut et activez Private Google Access sur les sous-réseaux. Ajoutez une règle explicite de refus total de sortie (egress) à haute priorité, puis des autorisations spécifiques pour le saut suivant (next-hop) du NGFW et les API Google ; activez la journalisation.
   • Justification : Force le trafic de sortie Internet général à passer par le NGFW tout en permettant d’atteindre BigQuery et Pub/Sub de manière privée sans routage en épingle à cheveux (hairpinning) inutile.

7. Contrôles NAT et des adresses IP externes

   • Utilisez Cloud NAT pour les instances qui nécessitent une sortie Internet mais n’ont pas d’adresses IP externes. Auditez et supprimez toutes les adresses IP externes sur les instances de calcul qui doivent utiliser le NAT.
   • Justification : Empêche le contournement du NAT et préserve une posture de sortie unique.

8. Inspection et surveillance

   • Activez Packet Mirroring dans chaque région pour le niveau applicatif, en ciblant le compte de service de l’application, et envoyez le trafic mis en miroir à un collecteur IDS régional. Activez les VPC Flow Logs et la journalisation des règles de pare-feu pour les règles clés ; exportez les journaux de Cloud Armor et du VPC vers un projet de sécurité central et BigQuery.
   • Justification : Fournit une visibilité approfondie pour la recherche de menaces (threat hunting) et les analyses comparatives de performance sans latence sur le chemin du trafic.

9. Opérations prêtes pour les incidents

   • Mettez en place des alertes sur les pics de refus de Cloud Armor, les journaux de refus du pare-feu ou les modifications des politiques hiérarchiques. Documentez une procédure SSH d’urgence (break-glass) utilisant gcloud compute ssh depuis Cloud Shell pour un accès d’urgence contrôlé.
   • Justification : Détecte rapidement les abus actifs et préserve une voie opérationnelle sécurisée pour la remédiation.

10. Sécurité des changements et restauration (rollback)

• Mettez en place les changements de Cloud Armor en mode prévisualisation (preview), puis appliquez-les. Pour les changements de pare-feu, utilisez des priorités à plus faible risque et des projets canaris avant de propager à la politique au niveau de l’organisation.
• Justification : Minimise le risque de pannes globales dues à des erreurs de politique tout en maintenant une posture de sécurité solide.

← Architecture VPC · Tous les domaines · Connectivité hybride →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Google →