Chiffrement en transit pour Google Cloud

Ce contenu a été mis à jour pour la dernière fois en avril 2025 et représente le statu quo au moment de sa 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 circulent sur Internet, se déplacent dans 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 celles 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 dans les réseaux de Google. Ce document ne s'applique pas aux données en transit sur des interconnexions entre les réseaux de centres de données clients et les réseaux de centres de données de Google.

Le chiffrement en transit utilise diverses technologies pour protéger les données, y compris le protocole TLS (Transport Layer Security), BoringSSL, le protocole 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 que 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 applique les mesures de sécurité suivantes pour garantir l'authenticité, l'intégrité et la confidentialité des données en transit:

  • L'authentification vérifie l'identité d'un pair (humain ou processus) dans une connexion.
  • L'intégrité empêche la modification des données que vous envoyez pendant leur transit entre la source et la destination.
  • Le chiffrement utilise la cryptographie pour rendre vos données illisibles pendant leur transfert et les garder confidentielles.

Le chiffrement en transit permet de protéger vos données si des 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 transport.

Le chiffrement s'inscrit dans une stratégie de sécurité plus large. Le chiffrement en transit protège vos données contre d'éventuels pirates informatiques et élimine la nécessité pour Google, Google Cloud les clients ou les utilisateurs finaux de faire confiance aux couches inférieures du réseau.

Routage du trafic

Cette section décrit comment les requêtes d'un utilisateur final sont acheminées d'un utilisateur final vers le serviceGoogle Cloud ou l'application de client appropriés, et comment le trafic est acheminé entre les services.

Un serviceGoogle Cloud est un service cloud modulaire que nous proposons à nos clients. Ces services incluent le calcul, le stockage, l'analyse de données et le 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 cliente.

Le schéma suivant montre les chemins du trafic de l'utilisateur final à 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 de client hébergée surGoogle Cloud (libellé B dans le diagramme)
  • D'une machine virtuelle à une machine virtuelle (étiquette C sur le schéma)
  • Établir une connexion entre une machine virtuelle et Google Front End (GFE) (indiqué par le libellé D sur le diagramme)
  • GFE vers les API et services Google (indiqués par l'étiquette E dans le schéma)
  • Google Cloud de service à 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 requêtes de routage de l'utilisateur final présentées dans le schéma précédent.

Utilisateur final vers un Google Cloud service

Google Cloud Les services tels que Cloud Storage ou Compute Engine sont des services cloud que nous proposons à nos clients et que nous exécutons dans notre environnement de production.Google Cloud Ces services 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 pour les connexions HTTP(S), TCP et TLS entrantes, fournit des contre-mesures contre les attaques DDoS, achemine le trafic vers les servicesGoogle Cloud et en équilibre la charge. Les points de présence GFE existent dans le monde entier, avec des chemins annoncés à l'aide d'unicast ou d'Anycast.

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

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

Le GFE négocie avec le client les paramètres cryptographiques standards de l'industrie, y compris la négociation de clés sécurisées par transfert. Pour les clients plus anciens et moins performants, le GFE choisit les anciennes primitives cryptographiques les plus performantes proposées par le client.

Utilisateur final vers une application de client hébergée sur Google Cloud

Vous pouvez acheminer le trafic des utilisateurs finaux depuis Internet vers vos applications client hébergées sur Google Cloud à l'aide d'une connexion directe ou d'un équilibreur de charge. Lorsque le trafic est acheminé directement, il est acheminé 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 s'exécutant 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 par défaut à l'aide du protocole TLS (à condition que l'application cliente de l'utilisateur final soit compatible avec ce protocole). GFE interrompt les 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 page Présentation des certificats SSL. Pour activer le chiffrement entre l'équilibreur de charge et la VM qui héberge l'application du client, consultez la section Chiffrement entre l'équilibreur de charge et les backends.

Pour configurer l'authentification TLS mutuelle (mTLS), consultez la section Présentation de l'authentification TLS mutuelle. 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 nos certificats TLS gratuits et automatisés. Avec les domaines personnalisés Cloud Run, vous pouvez également fournir vos propres certificats SSL et utiliser un en-tête HTTP Strict Transport Security (HSTS).

Chiffrement en transit dans les réseaux Google

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

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

Le trafic via les 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 en intégrité et authentifie le trafic entre les VM.

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

Chaque paire d'hôtes qui communiquent établit une clé de session à l'aide d'un canal de contrôle protégé par ALTS pour les communications authentifiées, protégées en intégrité et chiffrées. 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 des réseaux VPC et les réseaux VPC appairés au sein du réseau de production de Google sont chiffrées et protégées en intégrité. Ces connexions incluent les connexions entre les VM clientes, ainsi qu'entre les VM clientes et celles gérées par Google, comme Cloud SQL. Le schéma de la section Routage du trafic illustre cette interaction (connexion C). Étant donné que Google active le chiffrement automatique basé sur l'utilisation d'adresses IP internes, les connexions entre les VM utilisant des adresses IP externes ne sont pas automatiquement chiffrées.

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

Les jetons de sécurité sont encapsulés dans un en-tête de tunnel contenant des informations d'authentification sur l'expéditeur et le destinataire. Le plan de contrôle de l'hôte émetteur 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 se composent d'un jeton (contenant les informations de l'expéditeur) et du code secret de l'hôte.

Connectivité aux API et services Google

La gestion du trafic varie en fonction de l'emplacement où le service Google Cloud est hébergé.

La plupart des API et des services Google sont hébergés sur des GFE. Le trafic entre les VM et les GFE se sert d'adresses IP externes pour atteindre les services Google Cloud , mais vous pouvez configurer un accès privé pour éviter d'utiliser des adresses IP externes. La connexion entre le 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 des clients 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 la section Google Cloud Authentification et chiffrement des réseaux virtuels.

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 avec un certificat provenant d'une autorité de certification Web (publique). Toutes les données que l'utilisateur envoie au GFE sont chiffrées en transit avec TLS ou QUIC. GFE négocie un protocole de chiffrement spécifique avec le client en fonction des protocoles qu'il accepte. Dans la mesure du possible, GFE négocie des protocoles de chiffrement plus modernes.

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 du GFE à un service Google Cloud , et d'un Google Cloud service à un autre. Google Cloud

Le système 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 qui valident leurs identités basées sur les services. Lors de la création ou de la réception de RPC d'autres services, un service s'authentifie à l'aide de ses identifiants. Le système ALTS vérifie que ces identifiants sont émis par l'autorité de certification interne de Google. L'autorité de certification interne de Google n'est pas liée à Certificate Authority Service.

Le système ALTS utilise le chiffrement et la protection de l'intégrité cryptographique pour le trafic qui achemine des données Google Cloud du GFE vers un service et entre des services exécutés dans l'environnement de production de Google.

Le système ALTS permet également d'encapsuler d'autres protocoles de couche 7, tels que HTTP, dans des mécanismes RPC pour le trafic entre les 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.

Chiffrement en transit

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

Chiffrement du réseau avec PSP

PSP est un protocole indépendant du transport qui permet une sécurité par connexion et permet le déchargement du chiffrement sur du matériel SmartNIC (Smart Network Interface Card). Chaque fois que des SmartNIC sont disponibles, le système 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 de Google utilise PSP pour chiffrer le trafic à l'intérieur et entre nos centres de données. 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)

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

  • Protocole de handshake:le client lance une courbe elliptique combinée à un échange de clés à sécurité quantique. À la fin du handshake, les services concernés s'authentifient mutuellement leurs identités en échangeant et en vérifiant des certificats signés, puis en calculant une clé de trafic partagée. ML-KEM (FIPS 203) fait partie des algorithmes pris en charge pour obtenir la clé de trafic partagée. Pour en savoir plus, consultez la section 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, le système ALTS utilise le chiffrement AES-128-GCM pour l'ensemble du trafic. Les données en transit dans le système de stockage de niveau le plus bas de Google utilisent le chiffrement AES-256, tandis qu'ALTS fournit une authentification AES des messages. Dans le système ALTS, le chiffrement est assuré par BoringSSL ou PSP. Ce chiffrement est certifié FIPS 140-2 niveau 1 ou FIPS 140-3 niveau 1.

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

Étape suivante