Voici le troisième livre blanc qui explique comment Google protège vos données à l'aide du chiffrement. Il décrit en détail le chiffrement en transit dans Google Cloud et Google Workspace.
Pour tous les produits Google, nous nous efforçons d'assurer la protection des données client et d'être aussi transparents que possible concernant la manière dont nous en assurons la sécurité.
Ce contenu a été mis à jour pour la dernière fois en septembre 2022, et correspond à l'état des connaissances à sa date de rédaction. Les règles et les systèmes de sécurité Google peuvent changer par la suite, car nous améliorons continuellement la protection de nos clients.
Résumé à l'intention des responsables informatiques
- Google met en œuvre différentes mesures de sécurité pour assurer l'authenticité, l'intégrité et la confidentialité des données en transit.
- Pour les cas d'utilisation abordés dans ce livre blanc, Google chiffre et authentifie les données en transit sur une ou plusieurs couches réseau lorsque des données sont transférées en dehors des limites physiques qui ne sont pas contrôlées par ou pour le compte de Google. Tout le trafic de VM à VM au sein d'un réseau VPC et de réseaux VPC appairés est chiffré.
- Selon le type de connexion, Google applique des protections par défaut aux données en transit. Par exemple, nous sécurisons les communications entre l'utilisateur et Google Front End (GFE) à l'aide de TLS.
- Les clients Google Cloud ayant des exigences plus élevées en termes de chiffrement des données WAN peuvent choisir de mettre en œuvre des protections supplémentaires lors des transferts de l'utilisateur vers une application, ou d'une machine virtuelle vers une autre machine virtuelle. Ces protections incluent les tunnels IPsec, Gmail S/MIME, les certificats SSL gérés et Istio.
- Google collabore activement avec le secteur pour mettre le chiffrement en transit à la portée de tous, partout dans le monde. Nous avons mis en place différents projets Open Source qui encouragent l'utilisation du chiffrement en transit et de la sécurité des données sur Internet, par exemple la transparence des certificats, les API Chrome et le protocole SMTP sécurisé.
- L'objectif de Google est de rester le leader du marché du chiffrement en transit. À cette fin, nous consacrons des ressources au développement et à l'amélioration de la technologie de chiffrement. Notre travail dans ce domaine inclut des innovations concernant la transparence des clés et la cryptographie post-quantique.
Présentation
La sécurité est souvent un facteur déterminant lors du choix d'un fournisseur de cloud public. Chez Google, il s'agit d'un facteur de la plus haute importance. Nous travaillons sans relâche pour protéger vos données, qu'elles passent sur Internet, migrent 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 notre approche du chiffrement en transit pour Google Cloud.
Pour des informations sur les données au repos, consultez la page Chiffrement au repos dans Google Cloud Platform. Pour obtenir une vision globale de la sécurité chez Google, consultez la page Présentation de la sécurité sur l'infrastructure de Google.
Audience : ce document est destiné aux RSSI et aux équipes chargées de gérer les opérations de sécurité qui utilisent ou envisagent d'utiliser Google Cloud.
Conditions préalables : en plus de cette présentation, 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 différentes mesures de sécurité pour assurer l'authenticité, l'intégrité et la confidentialité des données en transit.
- Authentification : nous vérifions la source des données (qu'il s'agisse d'un être humain ou d'un processus), ainsi que leur destination.
- Intégrité : nous nous assurons que les données que vous envoyez parviennent à destination sans subir la moindre altération.
- Chiffrement : nous rendons vos données illisibles pendant leur transit, afin qu'elles restent privées. Le chiffrement est le processus qui permet de transformer des données lisibles (texte brut) en données illisibles (texte chiffré). Ainsi, le texte brut n'est accessible qu'aux parties autorisées par le propriétaire des données. Les algorithmes utilisés dans le processus de chiffrement sont publics, mais la clé requise pour déchiffrer le texte chiffré est privée. Le chiffrement en transit exploite souvent l'échange de clés asymétriques (tel que l'échange de clés Diffie-Hellman basé sur les courbes elliptiques) pour établir une clé symétrique partagée servant à chiffrer des données. Pour en savoir plus sur le chiffrement, consultez l'article Introduction to Modern Cryptography (Introduction à la cryptographie moderne).
Le chiffrement permet de protéger les données dans trois états :
- Le chiffrement au repos chiffre les données stockées pour les protéger contre tout éventuel piratage du système ou exfiltration de données. La norme AES (Advanced Encryption Standard) est souvent utilisée pour le chiffrement des données au repos.
- 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 votre site et le fournisseur cloud, ou entre deux services. Cette protection est obtenue en chiffrant les données avant la transmission, en authentifiant des points de terminaison et, à l'arrivée, en déchiffrant et vérifiant que les données n'ont pas été modifiées. Par exemple, le protocole TLS (Transport Layer Security) est souvent employé pour chiffrer des données en transit afin d'assurer la sécurité des échanges, tandis que la norme S/MIME (Secure/Multipurpose Internet Mail Extensions) est généralement utilisée pour chiffrer des e-mails.
- Le chiffrement en cours d'utilisation chiffre les données lors de leur traitement pour protéger vos données en mémoire contre les piratages et l'exfiltration de données. Pour plus d'informations, consultez la page Informatique confidentielle.
Le chiffrement s'inscrit dans une stratégie de sécurité plus large. Une fois une connexion établie et authentifiée, le chiffrement en transit protège vos données contre des pirates potentiels en :
- supprimant la nécessité d'approuver les couches inférieures du réseau, qui sont généralement fournies par des tiers ;
- réduisant la surface d'attaque potentielle ;
- empêchant les pirates d'accéder aux données lorsque des communications sont interceptées.
Avec un niveau adéquat d'authentification, d'intégrité et de chiffrement, les données qui transitent entre plusieurs utilisateurs, appareils ou processus peuvent être protégées dans un environnement hostile. Le reste de ce document explique l'approche de Google concernant le chiffrement des données en transit et décrit dans quels cas il est appliqué.
Infrastructure réseau de Google
Limites physiques
Une limite physique est une barrière qui ceint un espace physique contrôlé par ou pour le compte de Google, dans lequel nous pouvons vérifier que des mesures de sécurité rigoureuses sont en place. L'accès physique à ces emplacements est restreint et fortement surveillé. Seul un faible nombre d'employés de Google a accès au matériel. Les données en transit dans ce périmètre physique sont généralement authentifiées, mais il est possible qu'elles ne soient pas chiffrées par défaut.
En raison de l'ampleur du réseau Internet mondial, nous ne pouvons pas mettre en place ces mêmes contrôles de sécurité physiques sur les liaisons par fibre optique de notre réseau étendu, ni ailleurs en dehors des limites physiques contrôlées par ou pour le compte de Google. C'est pourquoi nous appliquons automatiquement des protections supplémentaires en dehors de notre limite de confiance physique. Ces protections incluent le chiffrement des données en transit pour tout le trafic en dehors de nos limites physiques.
Routage du trafic
Pour bien comprendre le fonctionnement du chiffrement en transit chez Google, il est également nécessaire d'appréhender la façon dont le trafic est acheminé via Internet. Cette section décrit la manière dont les requêtes sont acheminées d'un utilisateur final à l'application de client ou au service Google Cloud concernés, et la façon dont le trafic est routé entre plusieurs services.
Un service 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. Ainsi, 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 sur Google Cloud ne sont pas considérées comme des services Google Cloud1. Ainsi, une application que vous créez à l'aide de Google App Engine, de Google Kubernetes Engine ou d'une VM dans Google Compute Engine est une application de client.
Les cinq types de requêtes de routage décrits ci-dessous sont présentés dans la figure 1. Cette figure montre les interactions entre les différents composants réseau et la sécurité appliquée pour chaque connexion.
Routage du trafic entre un utilisateur final (Internet) et un service Google Cloud
Les services Google Cloud acceptent des requêtes du monde entier grâce à un système distribué à l'échelle mondiale appelé Google Front End (GFE). GFE interrompt le trafic entrant de proxy HTTP(S), TCP et TLS, fournit des contre-mesures contre les attaques DDoS, et gère le routage et l'équilibrage de charge du trafic vers les services Google Cloud. GFE dispose de points de présence dans le monde entier, avec des routages unicast ou anycast.
Les serveurs GFE jouent le rôle de proxy pour le trafic vers les services Google Cloud. Ils acheminent la requête d'un utilisateur vers un service Google Cloud via notre réseau backbone. Lorsque les communications quittent une limite physique contrôlée par ou pour le compte de Google, la connexion est authentifiée et chiffrée depuis GFE jusqu'au service Google Cloud ou jusqu'à l'application du client. La figure 1 illustre cette interaction (connexion A).
Routage du trafic entre un utilisateur final (Internet) et une application de client hébergée sur Google Cloud
Le trafic Internet peut être acheminé de plusieurs manières vers une application de client hébergée sur Google Cloud. Cette manière dépend de votre configuration, comme expliqué ci-dessous. La figure 1 illustre cette interaction (connexion B).
Si vous utilisez un équilibreur de charge d'application externe ou un équilibreur de charge réseau proxy externe (avec un proxy SSL), consultez la section Chiffrement entre l'équilibreur de charge et les backends.
Routage du trafic entre plusieurs machines virtuelles
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 authentifiées et chiffrées. Cela inclut les connexions entre les VM clientes, et entre les VM gérées par le client et par Google, telles que Cloud SQL. La figure 1 illustre cette interaction (connexion C). Notez que les connexions de VM à VM qui utilisent des adresses IP externes ne sont pas chiffrées.
Connectivité aux API et services Google
La gestion du trafic varie en fonction de l'emplacement du service Google Cloud :
La plupart des API et des services Google sont hébergés sur Google Front End (GFE). Cependant, certains services sont hébergés sur des instances gérées par Google. Par exemple, l'accès aux services privés et les maîtres GKE pour les clusters privés sont hébergés sur des instances gérées par Google.
Avec l'accès privé à Google, les VM ne disposant pas d'adresse IP externe peuvent accéder aux API et services Google compatibles, y compris aux applications clientes hébergées sur App Engine. Pour en savoir sur l'accès aux API et services Google, consultez la section Options d'accès privé pour les services.
Si une instance de VM Compute Engine se connecte à l'adresse IP externe d'une autre instance de VM Compute Engine, le trafic reste sur le réseau de production de Google, mais n'est pas chiffré en raison de l'utilisation de l'adresse IP externe. Les systèmes qui se trouvent en dehors du réseau de production de Google et se connectent à une adresse IP externe d'une instance de VM Compute Engine voient leur trafic acheminé via Internet.
La figure 1 présente un chemin externe (connexion D). Voici des cas typiques de ce type de requête de routage :
- Depuis une VM Compute Engine vers Google Cloud Storage
- Depuis une VM Compute Engine vers une API de machine learning
De la VM au serveur GFE, les services Google Cloud peuvent protéger ces connexions à l'aide de TLS par défaut2. La connexion est authentifiée du serveur GFE jusqu'au service, et est chiffrée lorsqu'elle quitte une limite physique. En plus de ces protections par défaut, vous pouvez appliquer le chiffrement encapsulé. Pour en savoir plus, consultez la page Chiffrer vos données.
Routage du trafic entre plusieurs services Google Cloud
Le routage entre plusieurs services de production s'effectue sur notre réseau backbone et peut nécessiter un acheminement du trafic en dehors des limites physiques contrôlées par ou pour le compte de Google. La figure 1 illustre cette interaction (connexion E). Il pourrait par exemple s'agir d'un événement Google Cloud Storage déclenchant Google Cloud Functions. Les connexions entre plusieurs services de production sont authentifiées au sein de la limite physique et sont chiffrées lorsqu'elles quittent cette limite.
Figure 1 : Protection par défaut et options superposées sur un réseau VPC
Chiffrement en transit par défaut
Google emploie diverses méthodes de chiffrement par défaut et configurables par l'utilisateur pour les données en transit. Le type de chiffrement utilisé dépend de la couche OSI, du type de service et du composant physique de l'infrastructure. Les figures 2 et 3 ci-dessous présentent les protections facultatives et par défaut mises en place par Google Cloud au niveau des couches 3, 4 et 7.
Figure 2 : Protection par défaut et options au niveau des couches 3 et 4 sur Google Cloud
Figure 3 : Protection par défaut et options au niveau de la couche 7 sur Google Cloud3
Le reste de cette section décrit les protections par défaut qui permettent à Google de protéger les données en transit.
Chiffrement du trafic entre les utilisateurs et Google Front End
À l'heure actuelle, de nombreux systèmes exploitent le protocole HTTPS pour communiquer sur Internet. Il offre un haut niveau de sécurité grâce à l'utilisation d'une connexion TLS, qui garantit l'authenticité, l'intégrité et la confidentialité des requêtes et des réponses. Avant d'accepter des requêtes HTTPS, le destinataire demande une paire de clés publiques/privées et un certificat X.509 pour authentifier le serveur auprès d'une autorité de certification (CA). La paire de clés et le certificat aident à protéger les requêtes d'un utilisateur au niveau de la couche d'application (couche 7) en prouvant que le destinataire possède bien le nom de domaine auquel les requêtes sont adressées. Les sous-sections suivantes abordent les composants du chiffrement entre les utilisateurs et les serveurs GFE : TLS, BoringSSL et l'autorité de certification de Google. N'oubliez pas que les chemins d'accès des clients ne passent pas tous par des serveurs GFE. Ces serveurs permettent surtout d'acheminer le trafic d'un utilisateur jusqu'à un service Google Cloud, et d'un utilisateur jusqu'à une application de client hébergée sur Google Cloud qui utilise Google Cloud Load Balancing.
TLS (Transport Layer Security)
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 grâce au protocole HTTPS, à l'aide 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 (Transport Layer Security) 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 des protocoles de chiffrement plus récents.
Le chiffrement TLS adapté à GFE s'applique non seulement aux interactions des utilisateurs finaux avec Google, mais il facilite également les interactions des API avec Google via TLS, y compris Google Cloud. En outre, notre chiffrement TLS permet d'échanger des messages Gmail avec des serveurs de messagerie externes (consultez la section Exiger le chiffrement TLS dans Gmail pour en savoir plus).
Google est le leader du marché tant dans l'adoption du protocole TLS que dans le renforcement de sa mise en œuvre. Dans cette optique, nous avons activé par défaut un grand nombre des fonctionnalités de sécurité offertes par TLS. Nous utilisons par exemple la confidentialité persistante dans notre mise en œuvre de TLS depuis 2011. Cette confidentialité persistante garantit la non-persistance d'une clé protégeant une connexion. Ainsi, un pirate qui intercepte et consulte un message n'est pas en mesure d'accéder aux messages précédents.
BoringSSL
Gérée par Google et dérivée d'OpenSSL, BoringSSL est une mise en œuvre Open Source du protocole TLS qui est principalement compatible avec l'interface OpenSSL. Google a créé BoringSSL à partir d'OpenSSL afin de simplifier l'utilisation d'OpenSSL en interne et d'offrir une meilleure compatibilité avec les projets Open Source Chromium et Android. BoringCrypto, le module au cœur de BoringSSL, a obtenu le niveau 1 de la certification FIPS 140-2.
Le protocole TLS est mis en œuvre dans GFE à l'aide de BoringSSL. Le tableau 1 présente les protocoles de chiffrement compatible avec GFE lors de la communication avec les clients.
| Protocole | Authentification | Échange de clés | Chiffrement | Fonction de hachage |
|---|---|---|---|---|
| TLS 1.3 | RSA 2048 | Curve25519 | AES-128-GCM | SHA384 |
| TLS 1.2 | ECDSA P-256 | P-256 (NIST secp256r1) | AES-256-GCM | SHA256 |
| TLS 1.1 | AES-128-CBC | SHA17 | ||
| TLS 1.04 | AES-256-CBC | MD58 | ||
| QUIC5 | ChaCha20-Poly1305 | |||
| 3DES6 |
Tableau 1 : Chiffrement mis en œuvre dans Google Front End pour les services Google Cloud ainsi que dans la bibliothèque de cryptographie BoringSSL
Autorité de certification de Google
Le protocole TLS exige qu'un serveur prouve son identité à l'utilisateur lorsqu'il reçoit une requête de connexion. Cette validation d'identité est effectuée par le protocole TLS, qui demande au serveur de présenter un certificat contenant son identité déclarée. Le certificat comporte à la fois le nom d'hôte DNS du serveur et sa clé publique. Une fois présenté, il est signé par une autorité de certification (CA) émettrice approuvée par l'utilisateur qui demande à se connecter9. Ainsi, les utilisateurs qui demandent à se connecter au serveur ont seulement besoin d'approuver l'autorité de certification racine. Si un serveur doit être accessible par des utilisateurs où qu'ils se trouvent, l'autorité de certification racine doit être connue des appareils clients du monde entier. À l'heure actuelle, la plupart des navigateurs, ainsi que d'autres mises en œuvre clientes TLS, disposent de leur propre ensemble d'autorités de certification racine définies comme fiables dans leur "magasin racine".
À l'origine, Google exploitait sa propre autorité de certification émettrice permettant de signer des certificats pour les domaines Google. Nous ne gérions toutefois pas notre propre autorité de certification racine. Aujourd'hui, nos certificats CA sont signés par plusieurs autorités de certification racine distribuées mondialement, telles que DigiCert et des racines anciennement exploitées par GlobalSign ("GS Root R2" et "GS Root R4").
En juin 2017, nous avons annoncé une transition vers des autorités de certification racine appartenant à Google. Au fil du temps, nous prévoyons d'exploiter une autorité de certification racine distribuée mondialement, qui émettra des certificats pour les domaines Google et pour nos clients.
Migration des clés racine et rotation des clés
Les clés des autorités de certification racine ne sont pas souvent modifiées, car la migration vers une nouvelle autorité requiert l'approbation du certificat de la part de tous les navigateurs et appareils, ce qui prend beaucoup de temps. Par conséquent, et bien que Google exploite désormais ses propres autorités de certification racine, nous continuerons à compter sur plusieurs autorités de certification racine tierces pendant une période de transition, afin de tenir compte des appareils plus anciens au cours de notre migration.
Pour créer une clé d'autorité de certification racine, une cérémonie des clés est requise. Chez Google, ce processus exige qu'au moins 3 des 6 personnes autorisées se rassemblent physiquement et utilisent des clés matérielles stockées dans un coffre-fort. Elles se rencontrent alors dans une salle dédiée à l'abri de toute interférence électromagnétique et dotée d'un module de sécurité matériel (HSM) physiquement isolé pour générer un ensemble de clés et de certificats. Cette salle dédiée se situe dans un centre de données Google sécurisé. Des contrôles supplémentaires, tels que des mesures de sécurité physiques, des caméras et la présence d'autres observateurs humains, garantissent le bon déroulement du processus. Si la cérémonie réussit, le certificat généré ressemble à un exemple de certificat, bien que le nom de l'émetteur, la clé publique et la signature diffèrent. Le certificat CA racine obtenu est ensuite envoyé aux programmes racine des navigateurs et des appareils en vue d'être intégré. Ce processus vise à garantir la confidentialité et la sécurité des clés privées associées pour qu'elles puissent être utilisées pendant une dizaine d'années ou plus.
Comme décrit précédemment, les autorités de certification signent des certificats à l'aide de leurs clés privées. Ces certificats vérifient alors les identités au début d'un handshake TLS dans le cadre d'une session utilisateur. Les certificats des serveurs sont signés par des autorités de certification intermédiaire, qui sont créées presque de la même manière que les autorités de certification racine. Les certificats de l'autorité de certification intermédiaire sont distribués dans le cadre de la session TLS, ce qui facilite la migration vers une nouvelle autorité de certification intermédiaire. Cette méthode de distribution permet également à l'opérateur de l'autorité de certification de conserver le matériel clé de l'autorité de certification racine dans un état hors connexion.
La sécurité d'une session TLS dépend du niveau de protection de la clé du serveur. Pour réduire davantage le risque que les clés soient compromises, la durée de vie des certificats TLS de Google est limitée à environ trois mois et les certificats sont alternés toutes les deux semaines environ.
Un client qui s'est précédemment connecté à un serveur peut reprendre sa session précédente en utilisant une clé de ticket privée10 avec un handshake TLS abrégé. Ces tickets ont donc une grande valeur aux yeux des pirates. Google alterne les clés de ticket au moins une fois par jour et fait expirer les clés tous les trois jours pour toutes les propriétés. Pour en savoir plus sur la rotation des clés de ticket de session, consultez l'article Measuring the Security Harm of TLS Crypto Shortcuts (Mesurer les atteintes à la sécurité liées à une sécurité cryptographique TLS incomplète).
Chiffrement du trafic entre Google Front End et interfaces d'application
Dans certains cas, comme mentionné dans la section Routage du trafic, l'utilisateur se connecte à un serveur GFE au sein d'une limite physique différente de celle du service souhaité et de l'interface d'application associée. Dans ce cas, la requête de l'utilisateur et tout autre protocole de couche 7 (tel que HTTP) sont soit protégés par TLS, soit encapsulés dans un RPC protégé par le système de chiffrement ALTS (Application Layer Transport Security), décrit dans la section Authentification, intégrité et chiffrement entre plusieurs services. Ces RPC sont authentifiés et chiffrés.
Pour les services Google Cloud, les RPC sont protégés à l'aide d'ALTS. Lorsque le trafic de l'application Google Cloud d'un client est acheminé via Google Front End (à l'aide d'un équilibreur de charge Google Cloud, par exemple), le trafic vers la VM est protégé grâce au chiffrement du réseau virtuel de Google Cloud décrit dans la section suivante.
Chiffrement et authentification du réseau virtuel de Google Cloud
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 Cloud est effectué au niveau de la couche réseau.
Pour mettre en œuvre le chiffrement au niveau de la couche réseau, nous exploitons la norme AES (Advanced Encryption Standard) en mode GCM (Galois/Counter Mode) avec une clé de 128 bits (AES-128-GCM). Chaque paire d'hôtes qui émet et reçoit des données établit une clé de session via un canal de contrôle protégé par ALTS, ce qui donne lieu à des communications authentifiées et chiffrées. La clé de session permet de chiffrer toutes les communications de VM à VM entre ces hôtes, et les clés de session sont régulièrement alternées.
Au niveau de la couche réseau (couche 3), le réseau virtuel Google Cloud authentifie l'ensemble du trafic entre les VM. Cette authentification (assurée par des jetons de sécurité) protège un hôte compromis contre le spoofing de paquets sur le réseau.
Lors de l'authentification, 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ôle11 côté 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'une clé de jeton (contenant les informations de l'expéditeur) ainsi que du secret de l'hôte. Il existe un secret pour chaque paire source/destinataire de limites physiques contrôlées par ou pour le compte de Google.
La figure 4 montre comment les clés de jeton, les secrets de l'hôte et les jetons de sécurité sont créés.
Figure 4 : Jetons de sécurité
Le secret de la limite physique est un nombre pseudo-aléatoire de 128 bits, qui permet de générer les secrets de l'hôte à l'aide d'un algorithme HMAC-SHA1. Le secret de la limite physique est négocié par un handshake entre les plans de contrôle réseau d'une paire de limites physiques, puis est renégocié toutes les quelques heures. Les jetons de sécurité utilisés pour l'authentification individuelle entre des VM (dérivés de ces VM et d'autres entrées) sont des codes HMAC négociés pour une paire expéditeur/destinataire spécifique.
Chiffrement du trafic entre les machines virtuelles et Google Front End
Le trafic entre les VM et GFE atteint les services Google par le biais d'adresses IP externes, mais vous pouvez configurer la fonctionnalité d'accès privé pour n'utiliser que des adresses IP Google pour les requêtes.
Par défaut, nous acceptons le trafic TLS provenant d'une VM vers le serveur GFE. La connexion s'effectue de la même manière que toute autre connexion externe. Pour en savoir plus sur TLS, consultez la section TLS (Transport Layer Security).
Authentification, intégrité et chiffrement entre plusieurs services
Nous exploitons notre système de chiffrement ALTS (Application Layer Transport Security) au niveau de la couche d'application (couche 7) de l'infrastructure de Google pour assurer l'authentification, l'intégrité et le chiffrement des appels RPC Google entre un serveur GFE et un service, et entre plusieurs services.
ALTS utilise des comptes de service pour l'authentification. Chaque service s'exécutant sur l'infrastructure de Google agit en tant qu'identité de compte de service dotée d'identifiants cryptographiques associés. 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 les vérifie alors grâce à une autorité de certification interne.
Au sein d'une limite physique contrôlée par ou pour le compte de Google, ALTS assure l'authentification et l'intégrité des RPC en mode "authentification et intégrité". Pour le trafic WAN en dehors des limites physiques contrôlées par ou pour le compte de Google, ALTS applique automatiquement le chiffrement du trafic RPC d'infrastructure en mode "authentification, intégrité et confidentialité". Actuellement, l'ensemble du trafic vers les services Google, y compris les services Google Cloud, bénéficie de ces mêmes protections.
ALTS permet également d'encapsuler d'autres protocoles de couche 7 (tels que HTTP) dans les mécanismes RPC d'infrastructure pour le trafic circulant entre Google Front End et les interfaces d'application. Cette protection isole la couche d'application et supprime toute dépendance envers la sécurité du chemin réseau.
Les services d'infrastructure de sécurité n'acceptent et n'envoient des communications ALTS qu'en mode "authentification, intégrité et confidentialité", même au sein des limites physiques contrôlées par ou pour le compte de Google. C'est par exemple le cas de Keystore, qui stocke et gère les clés de chiffrement servant à protéger les données stockées au repos dans l'infrastructure de Google.
Chiffrement du réseau avec PSP
Le protocole de sécurité PSP (PSP) est indépendant du transport. Il 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, nous utilisons 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. Nous utilisons PSP pour chiffrer le trafic entrant et entre nos centres de données. La PSP est compatible avec les protocoles non TCP, tels que UDP, et utilise une clé de chiffrement pour chaque connexion de couche 4.
Pour en savoir plus sur l'utilisation de PSP, consultez la page Annoncer le déchargement matériel cryptographique de la PSP à grande échelle est désormais Open Source.
Protocole ALTS
Le système ALTS propose un protocole de handshake sécurisé semblable à l'authentification TLS mutuelle. Deux services qui souhaitent communiquer via ALTS peuvent exploiter ce protocole pour s'authentifier et négocier les paramètres de communication avant d'envoyer des informations sensibles. Ce protocole est composé de deux étapes :
- Étape 1 : handshake. Le client lance avec le serveur un handshake Diffie-Hellman basé sur les courbes elliptiques (ECDH) à l'aide de Curve25519. Le client et le serveur disposent chacun de paramètres publics certifiés ECDH dans le cadre de leur certificat, qui est utilisé lors d'un échange de clés Diffie-Hellman. Le handshake se termine par la création d'une clé de trafic commune disponible sur le client et sur le serveur. Les identités appairées des certificats sont transmises à la couche d'application et peuvent être utilisées lors de décisions concernant les autorisations.
- Étape 2 : chiffrement de l'enregistrement. Les données sont transmises du client jusqu'au serveur de manière sécurisée grâce à la clé de trafic commune de l'étape 1. Le chiffrement est mis en œuvre dans ALTS à l'aide de BoringSSL et d'autres bibliothèques de chiffrement. L'algorithme AES-128-GCM est le plus couramment utilisé, tandis que l'intégrité est assurée par le code GMAC de l'algorithme AES-GCM.
Le schéma suivant illustre le handshake ALTS en détail. Dans les nouvelles mises en œuvre, un assistant de processus effectue le handshake, mais les applications se chargent encore parfois de cette opération.
Figure 5 : Handshake ALTS
Comme décrit au début de la section Authentification, intégrité et chiffrement entre plusieurs services, ALTS utilise des comptes de service pour l'authentification, et chaque service s'exécutant sur l'infrastructure de Google agit en tant qu'identité de service dotée d'identifiants cryptographiques associés. Lors du handshake ALTS, l'assistant de processus accède aux clés privées et aux certificats correspondants que chaque paire client/serveur utilise dans ses communications. La clé privée et le certificat correspondant (tampon de protocole signé) ont été provisionnés pour l'identité du compte de service associé au service.
Certificats ALTS. Il existe plusieurs types de certificats ALTS :
- Les certificats de machine, qui fournissent une identité aux services principaux d'une machine spécifique. Ils sont alternés toutes les six heures environ.
- Les certificats utilisateur, qui fournissent une identité d'utilisateur final à un ingénieur Google qui développe du code. Ils sont alternés toutes les 20 heures environ.
- Les certificats de tâches Borg, qui fournissent une identité aux tâches en cours d'exécution dans l'infrastructure de Google. Ils sont alternés toutes les 48 heures environ.
La clé de signature de la certification racine est stockée dans l'autorité de certification (CA) interne de Google, qui n'est pas liée à notre autorité de certification externe.
Chiffrement dans ALTS
Le chiffrement dans ALTS peut être mis en œuvre à l'aide de plusieurs algorithmes, en fonction des machines utilisées. Par exemple, la plupart des services utilisent l'algorithme AES-128-GCM12. Pour en savoir plus sur le chiffrement ALTS, consultez le tableau 2.
| Machines | Chiffrement de message utilisé | |
|---|---|---|
| Machine la plus courante | AES-128-GCM | |
| Sandy Bridge ou architecture plus ancienne | AES-128-VCM | Exploite VMAC plutôt que GMAC et s'avère légèrement plus efficace sur ces anciennes machines. |
Tableau 2 : Chiffrement dans ALTS
La plupart des services Google utilisent ALTS, ou bien une encapsulation RPC qui emploie ALTS. Les services qui n'exploitent pas ALTS ont recours à d'autres protections. Exemple :
- Certains services d'amorçage et de gestion des machines de bas niveau utilisent SSH.
- Certains services de journalisation d'infrastructure de bas niveau utilisent TLS ou Datagram TLS (DTLS)13".
- Certains services exploitant des transports non-TCP utilisent d'autres protocoles cryptographiques ou protections au niveau du réseau au sein des limites physiques contrôlées par ou pour le compte de Google.
Les communications entre les VM et les services Google Cloud Platform interagissent avec Google Front End à l'aide de TLS plutôt qu'ALTS. Nous décrivons ces communications dans la section Chiffrement du trafic entre les machines virtuelles et Google Front End.
Configurer d'autres options de chiffrement en transit
Vous pouvez configurer des protections pour vos données lorsqu'elles sont en transit entre Google Cloud et vos centres de données, ou entre vos applications hébergées sur Google Cloud et des appareils des utilisateurs.
Si vous connectez votre centre de données à Google Cloud, tenez compte des points suivants :
- Utilisez TLS avec l'équilibreur de charge d'application externe ou l'équilibreur de charge réseau proxy externe pour vous connecter à votre service cloud. GFE met fin aux connexions TLS de vos utilisateurs à l'aide de certificats SSL que vous provisionnez et gérez. Pour en savoir plus sur la personnalisation de votre certificat, consultez la présentation des certificats SSL.
- Créez un tunnel IPsec à l'aide de Cloud VPN ou utilisez Cloud Interconnect pour connecter de manière sécurisée votre réseau sur site à votre réseau cloud privé virtuel. Pour en savoir plus, consultez la page Choisir un produit de connectivité réseau.
- Utilisez MACsec pour Cloud Interconnect afin de sécuriser le trafic entre votre routeur sur site et les routeurs périphériques de Google. Pour en savoir plus, consultez la page Présentation de MACsec pour Cloud Interconnect.
Si vous connectez vos appareils utilisateur à des applications exécutées dans Google Cloud, tenez compte des points suivants :
- Bénéficiez de la compatibilité de GFE avec TLS en configurant le certificat SSL que vous utilisez. Vous pouvez par exemple interrompre la session TLS dans votre application.
- Envisagez d'utiliser nos certificats SSL gratuits et automatisés, disponibles pour les domaines personnalisés Firebase Hosting et App Engine. Les domaines personnalisés App Engine vous permettent également de fournir vos propres certificats SSL et d'utiliser un en-tête HSTS (HTTP Strict Transport Security).
- Pour les charges de travail sur GKE et Compute Engine, envisagez d'utiliser GKE Enterprise Service Mesh afin de pouvoir utiliser l'authentification mTLS, qui garantit que toutes les communications TCP sont chiffrées en transit.
Si vous utilisez Google Workspace, configurez Gmail afin d'activer S/MIME pour les e-mails sortants, configurez des règles pour la conformité du contenu et des pièces jointes et créez des règles de routage pour les e-mails entrants et sortants.
Recherche et innovation pour le chiffrement en transit
Au fil des années, nous avons participé à plusieurs projets Open Source et à d'autres initiatives qui encouragent l'utilisation du chiffrement en transit sur Internet.
Ceci inclut les efforts suivants :
- Le projet de transparence des certificats a été lancé afin de permettre aux opérateurs de sites et aux propriétaires de domaines de détecter si une autorité de certification a émis des certificats non autorisés ou incorrects.
- Notre Transparence des informations HTTPS annuelle suit notre progression vers notre objectif de 100 % de chiffrement en transit pour toutes nos propriétés, y compris Google Cloud.
- Le développement de l'algorithme CECPQ2 (combined elliptic-curve and post-quantum), qui aide à protéger les connexions TLS contre les attaques générées par ordinateur quantique.
Pour en savoir plus sur nos contributions récentes, consultez la page Collaboration avec la communauté des chercheurs en sécurité.
Étapes suivantes
- Pour obtenir des informations générales sur la sécurité dans Google Cloud, y compris les bonnes pratiques, consultez la section "Sécurité" du site Web de Google Cloud.
- Pour en savoir plus sur la conformité de Google Cloud et les certifications de conformité, consultez la section "Conformité" du site Web de Google Cloud. Vous y trouverez le rapport d'audit SOC 3 public de Google.
- Pour découvrir les bonnes pratiques de sécurisation de vos données en transit, consultez les pages Plan de base de l'entreprise, Framework d'architecture de Google Cloud : sécurité, confidentialité et conformité et Comment satisfaire les exigences réglementaires de chiffrement en transit.