Google PCNE: Connectivité privée vers Google et les services gérés — 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 connectivité privée aux services Google et aux services gérés englobe des modèles qui permettent aux charges de travail (workloads) de communiquer avec les API Google, les réseaux de producteurs gérés par Google et les services tiers sans utiliser d’adresses IP publiques. Les objectifs sont de réduire le risque d’exfiltration de données, de simplifier la conformité et d’améliorer la prévisibilité en maintenant le trafic sur des chemins privés. Les briques de base incluent Private Google Access (et les points de terminaison restreints), Private Services Access (pour les adresses IP privées vers les services gérés par Google), Private Service Connect (pour la publication et la consommation de services privés producteur-consommateur, y compris les API Google), VPC Service Controls (pour le périmètre de données), Cloud NAT (pour les sorties privées vers l’internet public) et le mappage DNS pour une sélection déterministe des points de terminaison.

La réussite de la conception repose sur trois décisions :

• Quel mécanisme d’accès privé correspond au service et au modèle de sécurité (PGA vs PSC pour les API Google, PSA vs PSC pour les services gérés ou partenaires).
• Comment le DNS doit résoudre les noms de service vers des cibles privées sans interrompre les services non pris en charge.
• Comment le routage et la politique de périmètre interagissent pour que le trafic reste privé de bout en bout en cas de défaillance ou de changement.

Les modes de défaillance proviennent généralement de la sélection de route, de l’ordre DNS, de la portée régionale des points de terminaison ou de règles de périmètre qui rejettent silencieusement les appels. Validez chaque couche : résolution de noms, route, pare-feu, état du point de terminaison et politique de service.

Private Google Access, points de terminaison restreints et sélection de point de terminaison

Private Google Access (PGA) permet aux VM et aux nœuds GKE sans adresse IP externe d’atteindre les API et services Google en utilisant les VIP anycast de Google via la passerelle Internet par défaut du VPC, et non via Cloud NAT. Il est activé par sous-réseau.

• Points de terminaison :

  • private.googleapis.com (199.36.153.8/30) : surface complète des API Google.
  • restricted.googleapis.com (199.36.153.4/30) : sous-ensemble d’API compatibles avec VPC Service Controls. Utilisez-le lorsque vous appliquez des périmètres de service.

• Approches de mappage DNS :

  • Conserver les noms publics par défaut et laisser les clients accéder au DNS public. Cela fonctionne si vous autorisez le trafic sortant via Cloud NAT, mais affaiblit les contrôles d’exfiltration de données.
  • Surcharger des noms d’hôte d’API spécifiques dans une zone privée Cloud DNS pour googleapis.com avec des CNAME vers restricted.googleapis.com (ou private.googleapis.com) pour forcer la résolution privée par service. Exemple : créer une zone privée googleapis.com et ajouter un CNAME storage.googleapis.com vers restricted.googleapis.com.

• Considérations sur le routage :

  • PGA nécessite une route vers la passerelle Internet par défaut. Si vous envoyez 0.0.0.0/0 vers un NGFW tiers, ajoutez des routes d’hôte explicites pour que les VIP des API Google utilisent la passerelle Internet par défaut :

undefined

• Mode de défaillance : Si ces routes d’hôte sont manquantes, les instances sans IP externe ne peuvent pas atteindre les API lorsqu’un saut suivant (next-hop) 0.0.0.0/0 est une instance de pare-feu.

• Configuration du sous-réseau :

undefined

Compromis :

• restricted.googleapis.com réduit le risque d’exfiltration, mais certaines API ne sont pas disponibles.
• Le trafic PGA contourne Cloud NAT, donc la journalisation NAT ne le montrera pas. Utilisez les VPC Flow Logs sur le sous-réseau.

Pour les clients sur site (on-prem), vous pouvez fournir un accès privé aux API Google soit en annonçant 199.36.153.4/30 et/ou 199.36.153.8/30 vers l’environnement sur site via Cloud VPN/Interconnect avec la passerelle Internet par défaut du VPC comme saut suivant, soit en exposant des points de terminaison PSC (voir ci-dessous) et en mappant le DNS sur site vers ces points de terminaison.

Private Services Access et Private Service Connect

Private Services Access (PSA) fournit une connectivité par IP privée aux réseaux de producteurs gérés par Google qui hébergent des services tels que Cloud SQL (IP privée) et Memorystore. Vous allouez une plage RFC1918 dans votre VPC que Google utilisera et établissez une connexion d’appairage (peering) avec le réseau du producteur de services.

• Modèle de configuration :
  • Réserver une plage d’adresses pour l’appairage VPC :

undefined

• Établir la connexion privée :

undefined

• Provisionner le service géré avec une IP privée.

• Notes opérationnelles :

  • La plage doit être suffisamment grande pour toutes les instances et ne doit pas chevaucher les plages existantes.
  • L’appairage n’est pas transitif ; le trafic doit provenir du VPC appairé (les environnements sur site peuvent y accéder via le VPC si le routage le permet).
  • Modifier ou réduire la plage ultérieurement est perturbateur ; planifiez la capacité.

Private Service Connect (PSC) étend la connectivité privée à :

• APIs Google (le consommateur crée des points de terminaison avec des IP privées dans un sous-réseau, et le DNS mappe les noms d’API sur ces IP).
• Services de partenaires et SaaS publiés via des rattachements de service (service attachments).
• Vos propres services publiés en privé pour d’autres projets ou organisations via des rattachements de service.

Modèle producteur-consommateur :

• Le producteur publie un rattachement de service dans une région, soutenu par un équilibreur de charge interne. Le producteur peut exiger des listes d’autorisation (allowlists) de projets/organisations consommateurs et spécifier des quotas de connexion.
• Le consommateur crée un point de terminaison PSC (règle de transfert) dans la même région, ciblant le rattachement de service du producteur. Le point de terminaison obtient une IP du sous-réseau choisi.

Contraintes de conception et compromis :

• PSC est régional ; déployez par région, à proximité des consommateurs. Utilisez des stratégies DNS ou des enregistrements pondérés pour diriger les clients proches et assurer le basculement (failover).
• Il n’y a pas de transitivité via PSC ; les consommateurs ne peuvent pas chaîner les services via un point de terminaison.
• L’IP source n’est pas préservée de bout en bout à travers PSC ; concevez les contrôles côté producteur en tenant compte de cela (par exemple, en vous basant sur l’identité ou l’autorisation au niveau de l’application).

Modes de défaillance courants :

• L’échec des vérifications de santé (health checks) de l’ILB du producteur entraîne le refus des connexions PSC.
• Point de terminaison consommateur créé dans une région différente de celle du rattachement de service.
• Une politique de refus (deny policy) du producteur ou une liste d’autorisation de projet manquante bloque les connexions.
• Le DNS ne pointe pas vers l’IP du point de terminaison, ou des zones privées qui se chevauchent se résolvent vers la mauvaise destination.

VPC Service Controls, périmètres, trafic entrant/sortant (ingress/egress) et mappage DNS

VPC Service Controls (VPC-SC) définit des périmètres de service autour des ressources gérées par Google pour atténuer l’exfiltration de données. À l’intérieur d’un périmètre, les requêtes vers les services protégés doivent provenir de projets inclus dans le périmètre et satisfaire tous les niveaux d’accès configurés.

• Périmètres :

  • Les périmètres standards protègent les projets hébergeant des données (par exemple, BigQuery, Cloud Storage).
  • Les ponts de périmètre (perimeter bridges) permettent une interaction limitée entre des périmètres autrement isolés.
  • Les règles d’entrée (ingress rules) accordent un accès spécifique depuis l’extérieur du périmètre (par exemple, depuis des projets de CI/CD ou de surveillance).
  • Les règles de sortie (egress rules) limitent les services externes ou les projets au sein de Google Cloud qui peuvent être appelés.

• Sélection du point de terminaison :

  • Utilisez restricted.googleapis.com pour limiter les appels d’API aux services compatibles avec VPC-SC et éviter les appels accidentels à des points de terminaison publics qui ne sont pas conscients du périmètre.
  • PSC pour les APIs Google offre un contrôle plus fort en maintenant le trafic sur des IP privées et en permettant une affinité régionale, mais nécessite toujours une configuration de périmètre pour l’autorisation.

• DNS et nommage :

  • Mettez en œuvre un DNS « split-horizon » avec les zones privées de Cloud DNS afin que les clients internes résolvent les noms d’API vers des cibles privées.
  • Préférez des enregistrements par service ou des CNAME vers restricted.googleapis.com plutôt que d’utiliser un caractère générique (wildcard) pour tout googleapis.com, ce qui peut perturber les services qui doivent rester publics.
  • Pour PSC, publiez des enregistrements A pointant vers l’IP de chaque point de terminaison. Utilisez des zones distinctes par environnement pour éviter une consommation accidentelle entre environnements.

Pièges à éviter :

• L’utilisation de Cloud NAT pour atteindre le service public googleapis.com peut contourner l’objectif de VPC-SC, à moins que des règles de périmètre ne contraignent explicitement la sortie ; associez NAT à un DNS restreint ou à PSC.
• Certaines APIs ont plusieurs noms d’hôte (par exemple, des points de terminaison JSON vs XML) ; assurez-vous que votre mappage DNS couvre tous les noms que vos clients utilisent.
• Une mauvaise configuration du périmètre entraîne un blocage par défaut (fail-closed) ; surveillez les journaux Access Transparency et VPC-SC pour détecter les refus.

Modèles de sortie, accès hybride et dépannage

Modèles de sortie pour les charges de travail privées :

• API Google uniquement : Activer PGA et mapper le DNS vers restricted.googleapis.com, ou déployer PSC pour les API Google et mapper le DNS vers les adresses IP du point de terminaison.
• Internet et SaaS : Utiliser Cloud NAT pour les instances sans adresses IP externes. Dimensionner NAT pour les pics de connexions et de ports simultanés ; surveiller l’épuisement des ports.
• Combinaison avec un NGFW tiers : Conserver le NGFW par défaut, mais ajouter des routes d’hôte spécifiques vers les VIP anycast des API Google pour s’assurer que PGA contourne le pare-feu. Pour les destinations non-Google, envoyer au NGFW ou à Cloud NAT selon la politique.

Clients hybrides (sur site ou autres clouds) :

• Pour consommer les API Google en privé :
  • Option A : Private Google Access pour les environnements sur site en annonçant 199.36.153.4/30 et/ou 199.36.153.8/30 depuis Cloud Router vers l’environnement sur site avec comme prochain saut la passerelle Internet par défaut dans le VPC ; mapper le DNS sur site vers restricted/private.googleapis.com selon les besoins.
  • Option B : Points de terminaison PSC pour les API Google dans votre VPC ; les exposer via Cloud VPN/Interconnect en routant vers les adresses IP des points de terminaison et en mappant le DNS sur site en conséquence.
• Pour atteindre les services gérés par Google avec des adresses IP privées (via PSA), établir la connectivité au VPC (Cloud VPN/Interconnect), s’assurer que les plages RFC1918 ne se chevauchent pas, propager les routes et autoriser les règles de pare-feu.

Dépannage et vérification :

• DNS : Utiliser dig ou nslookup sur le nom d’hôte de l’API depuis un client et vérifier qu’il se résout à l’adresse privée attendue (IP du point de terminaison PSC) ou aux VIP anycast restricted/private. Vérifier l’ordre des politiques Cloud DNS et les zones privées sur le VPC.
• Routage : Utiliser gcloud compute routes list et confirmer que la route la plus spécifique correspond au prochain saut attendu (passerelle Internet par défaut pour les VIP PGA, interne pour PSC).
• Pare-feu : Vérifier que les règles de sortie autorisent le TCP 443 vers les adresses IP cibles. Pour les producteurs à charge répartie derrière PSC, vérifier que les plages sources des vérifications de l’état (health check) sont autorisées.
• PGA : Confirmer que le paramètre du sous-réseau est activé et que les routes d’hôte pour 199.36.153.4/30 et/ou 199.36.153.8/30 existent si une route par défaut personnalisée est en place.
• PSA : Utiliser gcloud services vpc-peerings list pour confirmer que le peering servicenetworking est ACTIF et que la plage allouée est correcte et non utilisée ailleurs.
• PSC : Côté consommateur, décrire le point de terminaison pour voir l’état de la connexion ; côté producteur, vérifier les connexions en attente ou rejetées et l’état de l’ILB. Vérifier la liste d’autorisation des consommateurs (consumer allowlist) de l’attachement de service.
• Cloud NAT : Utiliser les journaux et les métriques de NAT pour confirmer les traductions, et vérifier l’allocation ou l’épuisement des ports. Si une instance a une adresse IP externe, elle contourne NAT par conception.

Scénario de problème pratique

Contoso Research exécute des analyses dans deux régions (us-east1, europe-west1). Les exigences de sécurité imposent qu’aucune VM n’ait d’adresse IP publique, que les API Google soient accessibles en privé et sous le contrôle de VPC Service Controls, que les utilisateurs sur site aient un accès privé à une instance Cloud SQL (adresse IP privée), et qu’un SaaS partenaire soit consommé en privé. Un NGFW tiers est le prochain saut de sortie par défaut.

1. Activer Private Google Access et les points de terminaison restreints

• Action : Activer Private Google Access sur tous les sous-réseaux d’analyse. Créer des zones privées Cloud DNS pour googleapis.com et ajouter des CNAME pour les API requises (BigQuery, Pub/Sub, Cloud Storage) vers restricted.googleapis.com. Ajouter des routes d’hôte pour 199.36.153.4/30 vers la passerelle Internet par défaut dans les deux régions.
• Justification : Garantit que le trafic VM vers API reste privé, est compatible avec VPC-SC, et contourne le NGFW sans créer une sortie Internet large.

2. Créer un périmètre VPC Service Controls

• Action : Placer les projets d’analyse et les projets de données à l’intérieur d’un périmètre de service. Ajouter des niveaux d’accès pour les réseaux d’entreprise de Contoso selon les besoins et autoriser explicitement les flux inter-projets requis via des règles d’entrée (ingress rules). Éviter les ponts de périmètre (perimeter bridges) sauf si cela est strictement justifié.
• Justification : Réduit le risque d’exfiltration de données depuis les services gérés par Google et s’aligne sur l’utilisation des points de terminaison restreints.

3. Provisionner Cloud SQL avec Private Services Access

• Action : Allouer un /24 pour PSA, connecter servicenetworking, et créer une instance Cloud SQL avec une adresse IP privée dans us-east1. Propager les routes du VPC vers l’environnement sur site via Interconnect et autoriser les règles de pare-feu.
• Justification : Fournit une accessibilité RFC1918 privée à la fois depuis les charges de travail du VPC et les clients sur site sans exposition publique.

4. Fournir un accès privé sur site aux API Google

• Action : Annoncer 199.36.153.4/30 depuis Cloud Router vers l’environnement sur site, avec comme prochain saut la passerelle Internet par défaut dans le VPC. Sur le DNS sur site, mapper les mêmes noms d’hôte d’API vers restricted.googleapis.com.
• Justification : Permet aux clients sur site d’utiliser le même chemin privé restreint, garantissant une application cohérente des politiques et minimisant la variance opérationnelle.

5. Consommer le SaaS partenaire via Private Service Connect

• Action : Le partenaire partage un attachement de service régional. Créer des points de terminaison PSC dans les sous-réseaux us-east1 et europe-west1 ciblant l’attachement. Publier des enregistrements A privés (saas.partner.contoso) pointant vers chaque point de terminaison régional ; utiliser le DNS pondéré (weighted DNS) pour privilégier l’accès régional.
• Justification : Maintient le trafic SaaS sur des adresses IP privées avec des listes d’autorisation de projet (project allowlists) appliquées par le producteur, améliore la latence via l’affinité régionale, et évite la sortie publique.

6. Conserver Cloud NAT pour la sortie Internet non-Google

• Action : Déployer des passerelles Cloud NAT par région, dimensionnées pour les flux de pointe. S’assurer que la route par défaut pointe toujours vers le NGFW, à l’exception des routes d’hôte spécifiques pour les VIP restreints.
• Justification : Permet une sortie contrôlée vers des destinations non-Google tout en garantissant que le trafic des API Google reste privé et que le NGFW conserve une visibilité centrale.

7. Valider et surveiller

• Action : Pour chaque type de client, vérifier la résolution DNS, la sélection de route et la connectivité TLS. Consulter les journaux de VPC-SC pour les refus, les journaux de NAT pour la sortie non-Google, et les états de connexion PSC. Ajouter des alertes de santé et de disponibilité pour les ILB derrière l’attachement de service du partenaire et pour Cloud SQL.
• Justification : Confirme que le chemin des données correspond à la conception et fait remonter les régressions rapidement, en particulier lorsque le DNS, les routes ou les périmètres changent.

← Cloud DNS · Tous les domaines · Routage →

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

Parcourir Google →