Chiffrement en transit pour Google Cloud

Ce contenu a été mis à jour pour la dernière fois en avril 2025, et correspond à l'état des connaissances à sa date de rédaction. Il est possible que les règles et les systèmes de sécurité de Google changent par la suite, car nous améliorons continuellement la protection de nos clients.

Chez Google, nos contrôles de sécurité contribuent à protéger vos données, qu'elles passent sur Internet, circulent au sein de l'infrastructure de Google ou soient stockées sur nos serveurs. L'authentification, l'intégrité et le chiffrement sont des éléments centraux de la stratégie de sécurité de Google, tant pour les données au repos que pour les données en transit. Ce document décrit comment nous avons conçuGoogle Cloud pour chiffrer les données en transit depuis Internet et les données en transit au sein des réseaux de Google. Ce document ne s'applique pas aux données en transit sur les interconnexions entre les réseaux de centres de données des clients et les réseaux de centres de données de Google.

Le chiffrement en transit utilise différentes technologies pour protéger les données, y compris le protocole TLS (Transport Layer Security), BoringSSL, ALTS (Application Layer Transport Security) et le protocole de sécurité PSP. En plus de la protection par défaut fournie par Google, vous pouvez renforcer la protection des données en ajoutant des options de chiffrement telles qu'IPsec, les certificats TLS gérés et Cloud Service Mesh.

Ce document est destiné aux RSSI et aux équipes chargées des opérations de sécurité qui utilisent ou envisagent d'utiliser Google Cloud. Dans ce document, nous partons du principe que vous possédez des connaissances de base en chiffrement et en primitives cryptographiques.

Authentification, intégrité et chiffrement

Google met en œuvre les mesures de sécurité suivantes pour assurer l'authenticité, l'intégrité et la confidentialité des données en transit :

  • L'authentification vérifie l'identité d'un pair (qu'il s'agisse d'un être humain ou d'un processus) dans une connexion.
  • L'intégrité empêche les données que vous envoyez d'être modifiées lors de leur transfert entre la source et la destination.
  • Le chiffrement utilise la cryptographie pour rendre vos données illisibles pendant leur transit et préserver leur confidentialité.

Le chiffrement en transit permet de protéger vos données si les communications sont interceptées au moment où ces données se déplacent entre l'utilisateur final et Google Cloud , ou entre deux services. Le chiffrement en transit authentifie les points de terminaison et chiffre les données avant leur transmission. À l'arrivée, le destinataire déchiffre les données et vérifie qu'elles n'ont pas été modifiées pendant le transfert.

Le chiffrement s'inscrit dans une stratégie de sécurité plus large. Le chiffrement en transit protège vos données contre les pirates potentiels et évite à Google, aux clients ou aux utilisateurs finaux d'avoir à contrôler les couches inférieures du réseau. Google Cloud

Routage du trafic

Cette section décrit la manière dont les requêtes sont acheminées d'un utilisateur final à l'application de client ou au serviceGoogle Cloud concernés, et la façon dont le trafic est routé entre plusieurs services.

Un Google Cloud est un service cloud modulaire que nous proposons à nos clients. Nous offrons par exemple des services de calcul, de stockage, d'analyse et de machine learning. Par exemple, Cloud Storage est un service Google Cloud .

Une application de client est une application hébergée sur Google Cloud que vous pouvez, en tant que client Google, créer et déployer à l'aide des services Google Cloud. Les applications de clients ou les solutions partenaires hébergées surGoogle Cloud ne sont pas considérées comme des services Google Cloud . Par exemple, une application que vous créez à l'aide de Cloud Run, de Google Kubernetes Engine ou d'une VM dans Compute Engine est une application de client.

Le schéma suivant illustre les chemins de trafic de l'utilisateur final vers Google, les chemins au sein du réseau de Google et la sécurité de chaque connexion. Les chemins de trafic suivants sont affichés :

  • Utilisateur final sur Internet vers un service Google Cloud (libellé A dans le schéma)
  • Utilisateur final sur Internet vers une application client hébergée surGoogle Cloud (libellée B dans le schéma)
  • D'une machine virtuelle à une autre (libellé C dans le schéma)
  • Machine virtuelle vers Google Front End (GFE) (D sur le schéma)
  • GFE vers les API et services Google (libellé E dans le schéma)
  • Google Cloud service vers Google Cloud service (libellé F dans le schéma)

Chemins de trafic pour Google.

Chiffrement en transit entre l'utilisateur final et Google

Les sections suivantes fournissent plus de détails sur les demandes de routage des utilisateurs finaux qui sont présentées dans le schéma précédent.

Utilisateur final vers un service Google Cloud

Les servicesGoogle Cloud , tels que Cloud Storage ou Compute Engine, sont des services cloud que nous proposons aux clients et qui s'exécutent dans notre environnement de production. Les servicesGoogle Cloud acceptent les requêtes du monde entier à l'aide d'un système distribué à l'échelle mondiale appelé Google Front End (GFE). GFE interrompt le trafic des connexions HTTP(S), TCP et TLS entrantes, fournit des contre-mesures contre les attaques DDoS, et gère le routage et l'équilibrage de charge du trafic vers les servicesGoogle Cloud . GFE dispose de points de présence dans le monde entier, avec des chemins annoncés à l'aide d'unicast ou d'anycast.

Le GFE achemine le trafic d'un utilisateur final sur le réseau Google vers un serviceGoogle Cloud , et d'un utilisateur final vers une application client hébergée sur Google Cloud et utilisant Cloud Load Balancing.

Les requêtes que les clients envoient à un service Google Cloud via HTTPS, HTTP/2 ou HTTP/3 sont sécurisées avec TLS. Le protocole TLS est mis en œuvre dans GFE à l'aide de BoringSSL, une implémentation Open Source du protocole TLS gérée par Google. BoringCrypto, le module au cœur de BoringSSL, a obtenu le niveau 1 de la certification FIPS 140-3.

Le serveur GFE négocie des paramètres cryptographiques standards avec le client, y compris la négociation de clés avec confidentialité persistante. Pour les clients plus anciens et moins performants, le GFE choisit les primitives cryptographiques anciennes les plus puissantes proposées par le client.

Routage du trafic entre un utilisateur final et une application cliente hébergée sur Google Cloud

Vous pouvez acheminer le trafic des utilisateurs finaux depuis Internet vers vos applications clientes hébergées sur Google Cloud à l'aide d'une connexion directe ou via un équilibreur de charge. Lorsque le trafic est acheminé directement, il est dirigé vers l'adresse IP externe du serveur de VM qui héberge l'application.

Vous pouvez utiliser TLS avec l'équilibreur de charge d'application externe ou l'équilibreur de charge réseau proxy externe pour vous connecter à votre application exécutée sur Google Cloud. Lorsque vous utilisez un équilibreur de charge de couche 7, la connexion entre l'utilisateur final et l'équilibreur de charge est chiffrée à l'aide de TLS par défaut (à condition que l'application cliente de l'utilisateur final soit compatible avec TLS). GFE met fin aux connexions TLS de vos utilisateurs finaux à l'aide de certificats TLS autogérés ou gérés par Google. Pour en savoir plus sur la personnalisation de votre certificat, consultez la présentation des certificats SSL. Pour activer le chiffrement entre l'équilibreur de charge et la VM qui héberge l'application client, consultez Chiffrement entre l'équilibreur de charge et les backends.

Pour configurer le protocole TLS mutuel (mTLS), consultez Présentation du protocole TLS mutuel. Pour les charges de travail sur GKE et Compute Engine, envisagez d'utiliser Cloud Service Mesh afin de pouvoir utiliser mTLS pour l'authentification mutuelle (client et serveur) et chiffrer les communications en transit à l'aide de certificats que vous gérez.

Pour Firebase Hosting et les domaines personnalisés Cloud Run, envisagez d'utiliser nos certificats TLS sans frais et automatisés. Les domaines personnalisés Cloud Run vous permettent également de fournir vos propres certificats SSL et d'utiliser un en-tête HSTS (HTTP Strict Transport Security).

Chiffrement en transit dans les réseaux Google

Google Cloud chiffre les données client en transit sur les réseaux de Google, sauf indication contraire dans cette section.

Les interconnexions spécialisées à très hautes performances qui connectent les TPU ou les GPU dans les superordinateurs d'IA de Google sont distinctes des réseaux décrits dans ce document. Dans Google Cloud, ces interconnexions ultra-performantes sont ICI pour les TPU et NVLink pour les GPU. Pour en savoir plus, consultez Architecture des TPU et Types de machines GPU.

Le trafic des connexions aux VM utilisant des adresses IP externes quitte les réseaux de Google. Vous êtes responsable de la configuration de votre propre chiffrement pour ces connexions.

Google Cloud Authentification et chiffrement du réseau virtuel

Le réseau virtuel deGoogle Cloudchiffre, protège l'intégrité et authentifie le trafic entre les VM.

Le chiffrement du trafic IP privé au sein du même VPC ou entre réseaux VPC appairés dans le réseau virtuel de Google Cloudest effectué au niveau de la couche réseau.

Chaque paire d'hôtes qui émet et reçoit des données établit une clé de session à l'aide d'un canal de contrôle protégé par ALTS, ce qui donne lieu à des communications authentifiées, chiffrées et dont l'intégrité est protégée. La clé de session permet de chiffrer les communications de VM à VM entre ces hôtes, et les clés de session sont régulièrement alternées.

Les connexions entre plusieurs VM au sein de réseaux VPC et de réseaux VPC appairés sur le réseau de production de Google sont protégées contre l'altération et chiffrées. Ces connexions incluent les connexions entre les VM clientes, et entre les VM gérées par le client et par Google, telles que Cloud SQL. Le schéma de la section Comment le trafic est-il acheminé ? illustre cette interaction (connexion C). Notez que, comme Google active le chiffrement automatique en fonction de l'utilisation d'adresses IP internes, les connexions entre les VM utilisant des adresses IP externes ne sont pas chiffrées automatiquement.

Le réseau virtuel deGoogle Cloudauthentifie tout le trafic entre les VM. Cette authentification, assurée par des jetons de sécurité, empêche un hôte compromis d'usurper des paquets sur le réseau.

Les jetons de sécurité sont encapsulés dans un en-tête de tunnel qui contient des informations d'authentification sur l'expéditeur et sur le destinataire. Le plan de contrôle sur l'hôte expéditeur définit le jeton, tandis que l'hôte destinataire le valide. Les jetons de sécurité sont prégénérés pour chaque flux et sont composés d'un jeton (contenant les informations de l'expéditeur) ainsi que du code secret de l'hôte.

Connectivité aux API et services Google

La gestion du trafic varie en fonction de l'emplacement d'hébergement du service Google Cloud .

La plupart des API et des services Google sont hébergés sur des GFE. Le trafic entre les VM et GFE atteint les services Google Cloud par le biais d'adresses IP externes, mais vous pouvez configurer l'accès privé pour éviter d'utiliser des adresses IP externes. La connexion entre le serveur GFE et le service est authentifiée et chiffrée.

Certains services, tels que Cloud SQL, sont hébergés sur des instances de VM gérées par Google. Si les VM clientes accèdent aux services hébergés sur des instances de VM gérées par Google à l'aide d'adresses IP externes, le trafic reste sur le réseau de production de Google, mais n'est pas automatiquement chiffré en raison de l'utilisation des adresses IP externes. Pour en savoir plus, consultez Authentification et chiffrement du réseau virtuelGoogle Cloud .

Lorsqu'un utilisateur envoie une requête à un service Google Cloud , nous sécurisons les données en transit (en fournissant l'authentification, l'intégrité et le chiffrement) à l'aide du protocole HTTPS et d'un certificat émis par une autorité de certification Web (publique). Toutes les données que l'utilisateur envoie aux serveurs GFE sont chiffrées en transit à l'aide du protocole TLS ou QUIC. GFE négocie un protocole de chiffrement spécifique avec le client en fonction des protocoles qu'il accepte. Si possible, GFE choisit les protocoles de chiffrement les plus récents.

Authentification, intégrité et chiffrement entre plusieurs services

L'infrastructure de Google utilise ALTS pour l'authentification, l'intégrité et le chiffrement des connexions entre le GFE et un service Google Cloud , et entre un service Google Cloud et un autre service Google Cloud .

ALTS utilise des identités basées sur les services pour l'authentification. Les services exécutés dans l'environnement de production de Google reçoivent des identifiants attestant de leur identité basée sur les services. Lors de la création ou de la réception de RPC à partir d'autres services, un service s'authentifie à l'aide de ses identifiants. ALTS vérifie que ces identifiants ont été émis par l'autorité de certification interne de Google. L'autorité de certification interne de Google n'est pas liée au Certificate Authority Service et est indépendante de celui-ci.

ALTS utilise le chiffrement et la protection de l'intégrité cryptographique pour le trafic qui transporte des données Google Cloud du GFE vers un service et entre les services qui s'exécutent dans l'environnement de production de Google.

ALTS permet également d'encapsuler d'autres protocoles de couche 7 (tels que HTTP) dans les mécanismes RPC pour le trafic entre les serveurs GFE et les services Google Cloud. Cette protection permet d'isoler la couche d'application et de supprimer toute dépendance à la sécurité du chemin réseau.

Méthodes de chiffrement en transit

Les sections suivantes décrivent certaines des technologies que Google utilise pour chiffrer les données en transit.

Chiffrement du réseau avec PSP

PSP est un protocole indépendant du transport qui active la sécurité par connexion et autorise le déchargement du chiffrement sur le matériel de type carte d'interface réseau connectée (SmartNIC). Chaque fois que des cartes d'interface réseau connectées (SmartNIC) sont disponibles, ALTS utilise PSP pour chiffrer les données en transit sur notre réseau.

PSP est conçu pour répondre aux exigences du trafic des centres de données à grande échelle. L'infrastructure Google utilise PSP pour chiffrer le trafic dans et entre nos centres de données. La PSP est également compatible avec les protocoles non TCP, tels que UDP, et utilise une clé de chiffrement unique pour chaque connexion.

Application Layer Transport Security (ALTS)

ALTS est un système d'authentification mutuelle et de chiffrement développé par Google. ALTS assure l'authentification, la confidentialité et l'intégrité des données en transit entre les services exécutés dans l'environnement de production de Google. ALTS se compose des protocoles suivants :

  • Protocole de handshake : le client lance un échange de clés combiné à courbe elliptique et à sécurité quantique. À la fin de l'établissement de la liaison, les services concernés authentifient mutuellement leurs identités en échangeant et en vérifiant des certificats signés, et calculent une clé de trafic partagée. L'algorithme post-quantique ML-KEM (FIPS 203) du NIST fait partie des algorithmes compatibles pour dériver la clé de trafic partagée. Pour en savoir plus, consultez Cryptographie post-quantique.

  • Protocole d'enregistrement : les données de service à service sont chiffrées en transit à l'aide de la clé de trafic partagée. Par défaut, ALTS utilise le chiffrement AES-128-GCM pour tout le trafic. Les données en transit dans le système de stockage de niveau le plus bas de Google utilisent le chiffrement AES-256, et ALTS fournit l'authentification des messages AES. Le chiffrement dans ALTS est fourni par BoringSSL ou PSP. Ce chiffrement est validé au niveau 1 de la certification FIPS 140-2 ou FIPS 140-3.

Les clés de signature racine des certificats ALTS sont stockées dans l'autorité de certification interne de Google.

Étapes suivantes