Zéro internet, zéro compromis - accéder à Google Cloud en mode privé

Et si votre cloud n'avait jamais besoin d'internet ?

C'est une question qui surprend. Après tout, le cloud public, c'est Internet, non ? Pas forcément. Si HTTPS chiffre les données en transit, il ne dit rien sur le chemin emprunté par vos flux réseau, ni sur leur exposition potentielle à des acteurs tiers. Pour de nombreuses organisations, ce niveau de contrôle ne suffit plus.

Les entreprises traitant des données à caractère personnel sont soumises au RGPD. Celles qui opèrent dans des secteurs sensibles (finance, santé, défense, par exemple) doivent en plus répondre à des exigences encore plus strictes : PCI-DSS, HDS, DORA, NIS2... Autant de cadres réglementaires qui imposent de maîtriser non seulement le chiffrement des données, mais aussi de contrôler les flux réseau et de réduire la surface d'attaque potentielle. Dans le cadre de l'adoption d'un cloud "souverain", ce besoin fait d'autant plus S3ns...

La première réponse à ces exigences est connue : faire transiter le trafic à destination du cloud via des liens d'interconnexion dédiés plutôt que par l'Internet public. C'est un premier niveau de sécurité essentiel. Mais une question reste entière : qu'en est-il du trafic à destination des services managés du cloud provider lui-même ? Vos VMs, vos conteneurs, vos pipelines de données — sur GCP ou sur votre infrastructure on-premise — comment accèdent-ils à BigQuery, Cloud Storage ou Cloud SQL sans repasser par Internet ?

Sur Google Cloud, plusieurs mécanismes répondent à ce besoin : Private Google Access, Private Google Access for on-premises hosts, Private Service Connect, Private Services Access... Des noms proches, des concepts distincts, et une réelle complexité à distinguer le rôle de chacun.

L'objectif de cet article est de vous donner les clés pour comprendre, comparer et choisir la bonne approche selon votre contexte.

Pourquoi éviter internet dans une architecture cloud ?

Pourquoi les entreprises cherchent-elles à garder leurs flux réseau hors d'Internet lorsqu'elles consomment des services cloud ? Les raisons sont multiples, mais elles convergent toutes vers un même enjeu : maîtriser le risque.

Le risque financier d'abord. Une fuite de données — qu'il s'agisse de données clients, collaborateurs ou de propriété intellectuelle — peut se traduire par des sanctions réglementaires lourdes, une perte de confiance des clients et, finalement, un impact direct sur le chiffre d'affaires (le coût moyen mondial d'une fuite de données est de 4,4 millions de dollars selon le dernier IBM Data Breach Report 2025). Le risque réputationnel ensuite : dans un contexte où les cyberattaques font régulièrement la une de l'actualité, une exposition inutile des flux réseau devient une faute de gouvernance difficilement justifiable. Réduire la surface d'attaque, c'est réduire les opportunités offertes aux attaquants.

Ces enjeux, combinés aux contraintes réglementaires évoquées en introduction, poussent les DSI et les RSSI vers une nouvelle doctrine : le "private by design". Mais comment tenir cette promesse quand les besoins en infrastructure explosent ? À l'heure où les organisations s'appuient massivement sur le cloud pour leurs capacités de calcul, de stockage et leurs services d'intelligence artificielle, la question de la connectivité privée vers les services managés devient primordiale.

Pour une entreprise disposant de ses propres datacenters, la réponse commence par l'architecture de sa landing zone — cet environnement cloud socle, conçu dès le départ avec une approche security-first. Qu'elle opte pour un simple VPC, une topologie Hub & Spoke ou une architecture orientée services managés, la première brique incontournable reste la même : établir une interconnexion privée entre son réseau on-premises et celui de son cloud provider, via Cloud Interconnect ou Cloud VPN.

C'est le prérequis, mais ce n'est que le début. Car une fois ce tunnel établi, une nouvelle question se pose : comment les workloads déployés dans cette landing zone accèdent-ils aux APIs et services managés, en mode totalement privé ? Explorons les mécanismes permettant d'y arriver.

L'accès privé à GCP : qui fait quoi ?

Private Services Access (PSA)

C'est quoi ? Private Services Access est la fonctionnalité "legacy" proposée par Google Cloud pour accéder en IP privée à ses services managés — Cloud SQL, Memorystore, Vertex AI et autres. Il repose sur un appairage VPC (VPC Peering) entre votre réseau et le réseau interne de Google qui héberge ces services.

Comment ça marche ? Il est nécessaire d'avoir un sous-réseau dédié dans votre VPC et d'établir une connexion privée via l'API Service Networking de Google Cloud. Ce peering est géré côté Google dans un réseau que vous ne contrôlez pas et sur lequel vous n'avez aucune visibilité directe.

Limites ? La principale contrainte est inhérente au VPC Peering lui-même : il n'est pas transitif. Concrètement, si votre VPC A est appairé avec le VPC managé de Google (VPC B), un troisième VPC C appairé avec votre VPC A ne pourra pas accéder aux services hébergés dans VPC B. Dans une architecture Hub & Spoke ou multi-VPC, cette limitation devient rapidement bloquante.

Un retour d'expérience ? 💬 En pratique, nous avons rapidement été confrontés à la limitation de transitivité sur l'accès à des instances Cloud SQL : des workloads déployés dans d'autres réseaux interconnectés ne pouvaient tout simplement pas atteindre la base de données, malgré un peering correctement configuré avec le VPC hub. Le fonctionnement "boîte noire" du peering côté Google, sans visibilité sur le réseau producteur, complique également le diagnostic en cas d'incident.

Private Google Access (PGA)

C'est quoi ? Private Google Access permet aux ressources déployées dans votre landing zone Google Cloud — VMs, services managés — d'accéder aux APIs et services GCP en utilisant uniquement leurs adresses IP privées, sans jamais sortir du réseau Google. Pas d'IP publique requise, pas de transit par Internet.

Comment ça marche ? L'activation se fait via un simple toggle au niveau du sous-réseau — mais attention, c'est loin d'être suffisant ! Deux configurations complémentaires sont indispensables :

• Le routage : une route statique doit être créée dans le VPC pour diriger le trafic vers la default internet gateway de Google. Malgré ce nom qui peut prêter à confusion, le trafic ne sort pas sur Internet — il reste entièrement au sein du réseau backbone de Google.
• Le DNS : une zone DNS privée doit être configurée dans Cloud DNS pour le domaine googleapis.com, avec les enregistrements pointant vers l'un des deux domaines spéciaux de Google :
  • private.googleapis.com → pour accéder à l'ensemble des APIs Google Cloud
  • restricted.googleapis.com → à privilégier si vous utilisez VPC Service Controls, car il restreint l'accès aux seuls services compatibles avec ce périmètre de sécurité

Limites ? PGA est limité aux ressources déployées dans le VPC GCP — il ne couvre pas les hôtes on-premises (voir mécanisme suivant). Il n'est pas non plus adapté aux architectures nécessitant un contrôle fin des endpoints ou une centralisation des accès.

Retour d'expérience 💬 Un cas d'usage concret et souvent méconnu : lorsque vous routez le trafic sortant de votre landing zone vers un proxy d'entreprise, PGA permet de faire passer le trafic à destination des APIs GCP en dehors de ce proxy, évitant ainsi un volume de trafic inutile et une latence supplémentaire. Rapide à industrialiser avec Terraform, nous avons pu l'expérimenter avec succès.

Beaucoup pensent qu'il n'y a qu'à activer le toggle Enable Private Google Access sur le subnet : ne pas oublier de créer également les routes, les zones DNS et les enregistrements dédiés sinon cela ne fonctionnera pas

Private Google Access for on-premises hosts

C'est quoi ? Il s'agit de l'extension naturelle du PGA pour les hôtes on-premises, c'est-à-dire les serveurs et applications hébergés dans vos datacenters d'entreprise, connectés à GCP via Cloud Interconnect ou Cloud VPN.

Comment ça marche ? Le principe est identique au PGA, avec deux différences importantes dans l'implémentation :

• Le routage : les routes vers private.googleapis.com (ou restricted.googleapis.com) ne sont pas configurées statiquement côté on-premises, mais annoncées dynamiquement via BGP par le Cloud Router associé à votre interconnexion. Votre réseau on-prem apprend ainsi automatiquement comment joindre les APIs Google en mode privé.
• Le DNS : les zones et enregistrements DNS doivent cette fois être configurés sur votre serveur DNS interne (et non dans Cloud DNS), pour que vos hôtes résolvent correctement *.googleapis.com vers les bonnes adresses IP.

Limites ? Ce mécanisme est conçu exclusivement pour les flux depuis l'on-premises. Pour une couverture complète — à la fois depuis votre landing-zone cloud et depuis vos hôtes on-premises — il doit être combiné avec un PGA classique configuré sur vos subnets GCP.

Retour d'expérience 💬 Bien que nous n'ayons pas encore eu l'occasion de déployer ce mécanisme en production, il représente une alternative sérieuse à Private Service Connect dans les contextes où ce dernier n'est pas disponible. C'est notamment le cas sur des plateformes Cloud de Confiance comme S3NS Premi3ns, et sur laquelle certaines fonctionnalités avancées de GCP peuvent ne pas encore être disponibles.

Private Service Connect (PSC)

C'est quoi ? Private Service Connect est le mécanisme le plus puissant et le plus flexible de l'écosystème GCP pour l'accès privé. Il repose sur la création d'endpoints privés — des adresses IP internes à votre VPC — qui servent de points d'entrée vers :

• Les APIs et services managés Google (Cloud Storage, BigQuery, Vertex AI...)
• Des services tiers hébergés sur GCP (Snowflake, MongoDB...)
• Vos propres services et applications exposés entre VPCs ou entre organisations

C'est un modèle producteur / consommateur : le producteur publie un service, le consommateur y accède via un endpoint privé, sans jamais passer par Internet.

Comment ça marche ? La mise en place d'un endpoint PSC se déroule en trois temps :

1. Réservation d'une IP statique dans un subnet de votre VPC — c'est l'adresse qui sera utilisée par vos clients pour joindre les APIs Google
2. Création de l'endpoint PSC en ciblant le bundle souhaité :
   • all-apis → accès à l'ensemble des APIs Google Cloud
   • vpc-sc → accès restreint aux seuls services compatibles avec VPC Service Controls
3. Configuration DNS — et c'est là que PSC se distingue par sa flexibilité :
   • Option simple : un enregistrement wildcard CNAME *.googleapis.com pointant vers l'IP de votre endpoint couvre l'ensemble des APIs en une seule règle
   • Option granulaire : Google crée automatiquement via Service Directory des enregistrements DNS dans une zone p.googleapis.com pour les APIs les plus courantes (ex: storage.p.googleapis.com)

Limites ? La principale complexité de PSC réside dans sa richesse fonctionnelle elle-même : plus de flexibilité implique plus de choix de configuration. Dans une architecture multi-VPC ou hybride, la gestion des endpoints et des règles DNS peut nécessiter une bonne discipline d'organisation et d'automatisation. C'est pourquoi l'usage de Terraform est fortement recommandé pour industrialiser le déploiement.

PSC a un impact sur les coûts (facturation des endpoints et du trafic) à prendre en compte dans le dimensionnement de votre architecture.

Retour d'expérience 💬 PSC est clairement le mécanisme vers lequel toute architecture GCP mature devrait converger. Son atout majeur par rapport aux autres approches ? La transitivité : contrairement au VPC Peering utilisé par PSA, les routes PSC fonctionnent dans une topologie Hub & Spoke — vos VPCs spoke peuvent accéder aux endpoints PSC centralisés dans le hub, sans configuration supplémentaire. C'est exactement ce qui nous a manqué avec PSA sur Cloud SQL. PSC s'adapte à tous les contextes : accès depuis le cloud, depuis l'on-premises via Cloud Interconnect ou Cloud VPN, entre VPCs de projets différents, voire entre organisations distinctes.

Google recommande officiellement PSC comme successeur de PSA pour les nouveaux projets

Lequel choisir selon votre contexte ?

L'objectif n'est pas de désigner un gagnant mais de vous aider à faire le choix le plus approprié en fonction du contexte :

➡️ Private Google Access tire sa force de sa simplicité. Une fois les prérequis configurés — activation sur le subnet, zone DNS privée et routes statiques — l'accès à l'ensemble des APIs Google est opérationnel en mode privé. C'est la solution naturelle pour les architectures sans besoin de transitivité, ou comme première brique rapide à déployer. À noter cependant : dans une architecture qui évolue, chaque nouveau subnet devra faire l'objet de la même configuration. Et si vos hôtes on-premises doivent également accéder aux APIs GCP, une configuration complémentaire au niveau du Cloud Router sera nécessaire — les deux approches sont donc complémentaires plutôt qu'interchangeables.

Cas d'usage concret : Une entreprise industrielle qui migre vers GCP et veut accéder à BigQuery depuis son datacenter sans ouvrir internet (PGA for on-prem ou PSC peuvent répondre au besoin)

➡️ Private Service Connect s'impose comme le mécanisme de référence pour les architectures complexes : Hub & Spoke, hybrides, multi-projets ou multi-organisations. Sa capacité à centraliser les accès via un endpoint unique, à maîtriser l'IP de destination et à supporter la transitivité des routes en fait le choix le plus pérenne. Google le positionne d'ailleurs officiellement comme le successeur de PSA pour les nouveaux projets.

Cas d'usage concret : Une fintech qui déploie une landing zone Hub & Spoke et veut centraliser tous les accès aux APIs GCP

➡️Private Services Access reste fonctionnel mais doit être considéré comme une solution legacy. Son périmètre est limité aux services managés Google qui le supportent (Cloud SQL, Memorystore, Vertex AI...) et son usage depuis un VPC uniquement le rend moins polyvalent. Si vous l'utilisez aujourd'hui, une migration vers PSC mérite d'être envisagée — en gardant à l'esprit que cette migration n'est pas sans impact : pour Cloud SQL notamment, elle implique une interruption de service à planifier soigneusement.

Cas d'usage concret : Une équipe data qui déploie Cloud SQL et Memorystore et veut y accéder en privé depuis un VPC isolé

Choisir la bonne clé pour la bonne porte

Dans la pratique, ces mécanismes ne sont pas mutuellement exclusifs — bien au contraire. Une architecture mature combinera souvent PGA pour sa simplicité de déploiement sur les workloads standards, et PSC pour les cas nécessitant un contrôle fin ou une centralisation des accès dans un Hub. L'un n'empêche pas l'autre : ils se complètent pour couvrir l'ensemble des cas d'usage d'une landing zone hybride.

Dans un contexte sécurité nécessitant un contrôle renforcé des flux, le "private by default" s'impose progressivement comme une nouvelle norme dans les architectures cloud d'entreprise. Et ce n'est pas qu'une tendance : selon le Check Point Cloud Security Report 2024, 61% des organisations ont déclaré avoir subi un incident de sécurité cloud dans l'année, les mauvaises configurations réseau figurant parmi les principales causes. Privatiser ses flux réseau est l'une des réponses les plus directes à ce risque.

Mais privatiser l'accès aux APIs Google n'est que la première couche d'une stratégie de sécurité réseau complète sur GCP. D'autres mécanismes complémentaires méritent d'être explorés pour aller plus loin :

• 🔒 VPC Service Controls : là où PGA et PSC contrôlent comment vous accédez aux services Google, VPC Service Controls contrôle ce que vous pouvez faire avec ces services. Il crée un périmètre de sécurité logique autour de vos ressources GCP pour prévenir l'exfiltration de données — même en cas de credentials compromis. C'est une couche complémentaire de sécurité pour les environnements sensibles, à combiner avec PSC et restricted.googleapis.com.
  
• 🌐 Secure Web Proxy : pour les workloads qui ont besoin d'accéder à des ressources externes sur Internet, le Secure Web Proxy de GCP permet d'appliquer des politiques d'accès granulaires sur le trafic web sortant — par source, destination, identité ou type de requête. Une réponse concrète au principe de zero-trust appliqué au trafic egress.

Ces sujets feront l'objet de prochains articles. En attendant, n'hésitez pas à partager vos retours d'expérience sur la mise en place de ces mécanismes dans vos organisations — chaque architecture est unique, et les échanges de la communauté sont souvent la meilleure source d'apprentissage. 🚀