Chiffrement en transit dans Google Cloud

Voici le troisième livre blanc qui vous explique comment Google protège vos données à l'aide du chiffrement. Nous avons également publié Chiffrement au repos dans Google Cloud Platform, ainsi qu'un document sur le chiffrement dans G Suite. N'hésitez pas à les consulter si vous souhaitez en savoir plus sur l'utilisation du chiffrement chez Google. Le présent livre blanc décrit en détail le chiffrement en transit dans Google Cloud, y compris dans Google Cloud Platform et G Suite.

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é.

Le contenu du présent livre blanc est réputé correct et représente l'état des connaissances à sa date de rédaction, soit décembre 2017. Les règles et les systèmes de sécurité de Google Cloud peuvent changer par la suite, car nous améliorons continuellement la protection de nos clients.

Bouton de lecture

Chiffrement en transit dans Google Cloud

Résumé au niveau CIO

  • 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.
  • Google chiffre et authentifie toutes 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. Les données en transit à l'intérieur d'une limite physique contrôlée par ou pour le compte de Google sont généralement authentifiées, mais pas nécessairement chiffrées.
  • Selon la connexion établie, 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 supplémentaires en matière de chiffrement des données WAN peuvent choisir d'implémenter des protections de données supplémentaires lors du transfert 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 permettre au chiffrement en transit d'être à la portée de tous, partout dans le monde. Nous avons plusieurs projets Open Source qui encouragent l'utilisation du chiffrement en transit et de la sécurité des données sur Internet, y compris la transparence des certificats, les API Chrome et le protocole SMTP sécurisé.
  • Google prévoit 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 dans les domaines de la transparence des clés et de 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 documentation sur le chiffrement au repos dans Google Cloud Platform. Pour obtenir une vision globale de la sécurité chez Google, consultez la présentation de la sécurité sur l'infrastructure de Google.

Audience : ce document est destiné aux RSSI et aux équipes chargées de la gestion de la 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 matière de chiffrement et de 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 inintelligibles 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.

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. Pour offrir cette protection, les données sont chiffrées avant leur envoi, les points de terminaison sont authentifiés, et les données sont déchiffrées et vérifiées à leur destination. 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 protéger des e-mails.
  • Le chiffrement en cours d'utilisation protège vos données lorsque des serveurs effectuent des opérations basées sur celles-ci (telles que le chiffrement homomorphe).

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 du réseau de Google

Google protège les données en transit de diverses façons lorsqu'elles sont transmises en dehors d'une limite physique contrôlée par ou pour le compte de Google. 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 au sein de ces limites physiques sont généralement authentifiées, mais peuvent ne pas être chiffrées par défaut. Vous pouvez choisir d'appliquer des mesures de sécurité supplémentaires en fonction de votre modèle de gestion des menaces.

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.

Routage du trafic

Dans la section précédente, nous vous avons parlé de la limite physique du réseau de Google et expliqué comment nous appliquons différentes protections aux données transmises en dehors de cette limite. 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 parviennent d'un utilisateur final à l'application du client ou au service Google Cloud concerné, et la façon dont le trafic est acheminé 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. Par exemple, Google Cloud Storage et Gmail sont tous deux des services 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 vous 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 proxy HTTP(S), TCP et TLS entrant, fournit des contre-mesures contre les attaques DDoS, achemine le trafic vers les services Google Cloud eux-mêmes et en équilibre la charge. 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).

  • À l'aide d'un équilibreur de charge externe Google Cloud basé sur un proxy HTTP(S) ou TCP/SSL : une application de client hébergée sur des VM Google Compute Engine peut interrompre des connexions HTTP(S), TLS ou TCP, ainsi que mettre en proxy, acheminer et distribuer le trafic vers leurs VM à l'aide d'un équilibreur de charge Google Cloud (GCLB). Ces services d'équilibrage de charge sont mis en œuvre par des serveurs GFE, de la même manière que ceux-ci interrompent et acheminent le trafic associé aux services Google Cloud. Lorsqu'un équilibreur de charge Google Cloud achemine le trafic entre plusieurs serveurs GFE, les connexions sont authentifiées et chiffrées quand le trafic quitte une limite physique contrôlée par ou pour le compte de Google. Lorsqu'un équilibreur de charge Google Cloud achemine le trafic entre un serveur GFE et un ordinateur physique hébergeant la VM d'un client, ce trafic est authentifié et chiffré quand il quitte une limite physique contrôlée par ou pour le compte de Google. Pour les équilibreurs de charge HTTPS, les connexions entre les utilisateurs finaux et les serveurs GFE sont chiffrées et authentifiées grâce au protocole TLS ou QUIC, à l'aide de certificats fournis par les clients. Pour les équilibreurs de charge HTTP, les connexions entre les utilisateurs finaux et les serveurs GFE ne sont ni chiffrées, ni authentifiées. Pour les équilibreurs de charge SSL, les connexions entre les utilisateurs finaux et les serveurs GFE sont chiffrées grâce au protocole TLS, également à l'aide de certificats fournis par les clients. Pour les équilibreurs de charge TCP, les connexions entre les utilisateurs finaux et les serveurs GFE ne sont pas chiffrées. L'application du client peut toutefois utiliser son propre chiffrement entre l'utilisateur final et les VM.
  • À l'aide d'une connexion directe à une VM via une adresse IP externe ou une adresse IP d'équilibreur de charge réseau : si vous vous connectez via l'adresse IP externe de la VM ou via une adresse IP d'équilibreur de charge réseau, la connexion ne passe pas par un serveur GFE. Elle n'est pas chiffrée par défaut et sa sécurité est assurée à la discrétion de l'utilisateur.
  • À l'aide de Cloud VPN : si vous vous connectez à une VM Google Cloud à partir d'un hôte local via un VPN, la connexion circule depuis/vers votre hôte local, vers le VPN sur site, vers le VPN Google et vers la VM Google Cloud. Elle ne passe pas par un serveur GFE et est protégée par le protocole IPsec, depuis le VPN sur site jusqu'au VPN Google. La connexion entre le VPN Google et la VM Google Cloud est authentifiée et chiffrée lorsque les communications quittent une limite physique contrôlée par ou pour le compte de Google.
  • À l'aide de l'interconnexion dédiée Cloud : si vous vous connectez via l'interconnexion dédiée, la connexion circule directement depuis/vers votre hôte local et ne passe pas par un serveur GFE. Elle n'est pas chiffrée par défaut et sa sécurité est assurée à la discrétion de l'utilisateur. Le protocole cryptographique de couche 7 de TLS (Transport Layer Security) peut vous permettre de chiffrer le trafic des applications via une interconnexion dédiée.

Routage du trafic entre plusieurs machines virtuelles

Sur notre réseau backbone, le routage entre plusieurs VM à l'aide d'adresses IP privées RFC 1918 peut nécessiter un acheminement du trafic en dehors des limites physiques contrôlées par ou pour le compte de Google. Voici des exemples de routage entre plusieurs VM :

  • Des VM Compute Engine s'envoyant mutuellement des requêtes
  • Une VM de client se connectant à une VM gérée par Google, telle que Cloud SQL

Les connexions entre plusieurs VM sont authentifiées au sein de la limite physique et sont chiffrées lorsqu'elles quittent cette limite. Le trafic entre plusieurs VM à l'aide d'adresses IP publiques n'est pas chiffré par défaut et sa sécurité est assurée à la discrétion de l'utilisateur. La figure 1 illustre cette interaction (connexion C).

Routage du trafic entre une machine virtuelle et un service Google Cloud

Lorsqu'une VM achemine une requête vers un service Google Cloud, celle-ci transite par un serveur GFE (sauf si le service Google Cloud est en cours d'exécution sur une VM gérée par Google, comme indiqué ci-dessus). Le serveur GFE reçoit la requête, puis l'achemine de la même manière qu'une requête provenant d'Internet. Ainsi, le trafic entre une VM et un service Google Cloud est acheminé via des chemins d'accès Google privés, vers les mêmes adresses IP publiques que pour les serveurs GFE. L'accès privé à Google permet aux VM sans adresse IP publique d'accéder à certains services Google Cloud et applications de clients hébergées sur Google App Engine. (Sachez que si une VM se connecte à une application de client hébergée sur Google Compute Engine ou Google Kubernetes Engine, le trafic est acheminé de la même manière qu'une requête provenant d'Internet, via des chemins externes.) La figure 1 illustre cette interaction (connexion D). Ce type de requête de routage peut par exemple s'effectuer entre une VM Compute Engine et Google Cloud Storage ou une API de machine learning. Les services Google Cloud peuvent protéger par défaut ces connexions à l'aide du chiffrement TLS2. Cette protection est en place depuis la VM jusqu'au serveur GFE. La connexion est authentifiée du serveur GFE jusqu'au service, et est chiffrée lorsqu'elle quitte une limite physique.

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 disponibles sur le réseau de Google

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 dans Google Cloud

Figure 3 : Protection par défaut et options au niveau de la couche 7 dans 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. HTTPS offre un haut niveau de sécurité grâce à la redirection du protocole vers une connexion TLS, ce 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 des utilisateurs et des serveurs GFE, soit TLS, BoringSSL et de l'autorité de certification de Google. N'oubliez pas que les chemins d'accès des clients ne sont pas tous acheminés via des serveurs GFE. Ces serveurs permettent notamment 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 l'équilibrage de charge Google Cloud.

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 non seulement s'applique aux interactions des utilisateurs finaux avec Google, mais facilite également les interactions des API avec Google via TLS, y compris Google Cloud. En outre, notre chiffrement TLS permet aux utilisateurs 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 ce dernier à la fois pour un usage interne et pour 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.34 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 SHA18
TLS 1.05     AES-256-CBC MD59
QUIC6     ChaCha20-Poly1305  
      3DES7  

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 vérification 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 connecter10. Ainsi, les utilisateurs qui demandent à se connecter au serveur ont seulement besoin d'approuver l'autorité de certification racine. Si un serveur a besoin d'ê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, tels que Symantec ("GeoTrust") 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 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édiaires, qui sont créées quasiment 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ée11 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.

Chiffrement du trafic entre Google Front End et les 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) est soit protégé par TLS, soit encapsulé 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 par défaut à 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 de réseau virtuel de Google Cloud décrit dans la section suivante.

Chiffrement et authentification de réseau virtuel de Google Cloud

L'infrastructure de réseau virtuel de Google Cloud permet de chiffrer des données lorsque le trafic quitte les limites physiques du réseau. Le chiffrement s'effectue au niveau de la couche réseau et s'applique au trafic IP privé au sein du même cloud privé virtuel (VPC) ou sur tous les réseaux VPC appairés.

Nous partons du principe que tout réseau franchissant une limite physique non contrôlée par ou pour le compte de Google peut être compromis par un adversaire actif, qui est alors en mesure d'espionner ou d'altérer le trafic sur le réseau. Nous garantissons l'intégrité et la confidentialité des communications en chiffrant les données lorsqu'elles sont transférées en dehors des limites physiques que nous contrôlons.

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ôle12 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 code secret de l'hôte. Il existe un code 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 codes secrets de l'hôte et les jetons de sécurité sont créés.

Figure 4 : Jetons de sécurité

Le code secret de la limite physique est un nombre pseudo-aléatoire de 128 bits, qui permet de générer les codes secrets de l'hôte à l'aide d'un algorithme HMAC-SHA1. Le code 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.

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 à la sécurité du chemin réseau.

Les services peuvent être configurés pour n'accepter et n'envoyer 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 du service de gestion de clés interne de Google, 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.

Protocole ALTS

Le système ATLS propose un protocole de handshake sécurisé semblable à l'authentification TLS mutuelle. Deux services qui souhaitent communiquer via ALTS peuvent exploiter ce protocole de handshake pour s'authentifier et négocier des 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 relatives aux 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 fournie par le code GMAC de l'algorithme AES-GCM.

La figure 5 ci-dessous décrit 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-GCM13. Pour en savoir plus sur le chiffrement ALTS, consultez le tableau 2.

Machine Chiffrement de message utilisé  
Machine 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 : Par 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)14.
  • 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.

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é à Google pour n'utiliser que des adresses IP Google pour les requêtes.

Comme pour les requêtes entre un utilisateur externe et Google, le trafic TLS est compatible par défaut entre une VM et un 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).

Options configurables par l'utilisateur pour le chiffrement en transit

La section Chiffrement en transit par défaut décrit les protections par défaut mises en place par Google concernant les données en transit. La présente section décrit les configurations que nos utilisateurs peuvent appliquer à ces protections par défaut.

Transit entre un centre de données sur site et Google Cloud

TLS avec des équilibreurs de charge externes Google Cloud

Si votre service cloud utilise un équilibreur de charge externe proxy SSL ou HTTPS Google, GFE interrompt les 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 page Créer et utiliser des certificats SSL.

Tunnel IPsec avec Google Cloud VPN

En tant que client Google Cloud, vous pouvez recourir à Google Cloud VPN pour connecter de façon sécurisée votre réseau sur site à votre réseau privé virtuel (VPC) Google Cloud Platform via une connexion VPN IPsec (couche 3). Le trafic échangé entre les deux réseaux est chiffré par une passerelle VPN et déchiffré par l'autre passerelle VPN, ce qui permet de protéger vos données sur Internet. En outre, vous pouvez configurer divers tunnels à équilibrage de charge via plusieurs passerelles VPN. Google Cloud VPN protège vos données de la manière suivante :

  • Les paquets entre vos VM et Cloud VPN demeurent au sein du réseau de Google. Ils sont chiffrés par le réseau virtuel de Google Cloud lorsqu'ils circulent en dehors des limites physiques contrôlées par ou pour le compte de Google.
  • Les paquets entre Cloud VPN et votre VPN sur site sont chiffrés et authentifiés à l'aide d'un tunnel IPsec.
  • Les paquets entre votre VPN sur site et vos hôtes locaux sont protégés par les contrôles que vous avez mis en place sur votre réseau.

Pour configurer un VPN, créez une passerelle Cloud VPN et établissez un tunnel sur le réseau VPC du service hébergé, puis autorisez le trafic entre les réseaux. Vous pouvez également configurer un VPN entre deux VPC.

Vous pouvez personnaliser davantage votre réseau en spécifiant la version IKE (Internet Key Exchange)15 de votre tunnel VPN. Vous avez le choix entre deux versions : IKEv1 et IKEv2, qui sont compatibles avec des algorithmes de chiffrement différents. Si vous spécifiez IKEv1, Google chiffre les paquets à l'aide de l'algorithme AES-128-CBC et assure l'intégrité via SHA-1 HMAC16. La version IKEv2 est quant à elle compatible avec un certain nombre d'algorithmes de chiffrement. Dans tous les cas, Google Cloud VPN négocie le protocole commun le plus sécurisé compatible avec les appareils appairés. Pour en savoir plus sur la configuration d'un VPN, consultez notre documentation Choisir une option de routage VPN.

L'interconnexion dédiée Google Cloud constitue une alternative au tunnel IPsec. Elle fournit des connexions physiques directes ainsi qu'une communication RFC 1918 entre votre réseau sur site et le réseau de Google. Les données qui transitent par cette connexion NE SONT PAS chiffrées par défaut et doivent donc être sécurisées au niveau de la couche d'application, à l'aide du protocole TLS par exemple. Google Cloud VPN et l'interconnexion Google Cloud partagent le même point de rattachement pour que vous puissiez utiliser le chiffrement VPN IPsec avec l'interconnexion dédiée. Pour y parvenir, toutefois, vous devez exploiter une solution tierce. La norme MACsec (protection de la couche 2) n'est actuellement pas compatible.

Transit entre un utilisateur et Google Front End

Certificats SSL gérés : gratuits et automatisés

Lors de la création d'une application sur Google Cloud, vous pouvez exploiter 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. Ce processus est différent de l'interruption TLS décrite dans la section TLS avec des équilibreurs de charge externes Google Cloud.

Google fournit également des certificats SSL gratuits et automatisés dans les domaines personnalisés Firebase Hosting et Google App Engine. Ces certificats ne sont disponibles que pour les propriétés hébergées par Google. Les domaines personnalisés Google App Engine vous permettent également de fournir vos propres certificats SSL et d'utiliser un en-tête HSTS (HTTPS Strict Transport Protocol).

Une fois que votre domaine pointe vers l'infrastructure de Google, nous demandons et obtenons un certificat pour ce domaine afin de permettre des communications sécurisées. Nous gérons les clés privées de serveur TLS, qui sont des clés secp256r1 ECC ou RSA 2048 bits, et renouvelons les certificats pour le compte de nos clients.

Exiger le chiffrement TLS dans Gmail

Comme indiqué dans la section TLS (Transport Layer Security), Gmail utilise le chiffrement TLS par défaut. Le service enregistre le dernier saut effectué par un e-mail et indique s'il a eu lieu dans une session TLS17. Lorsque deux utilisateurs Gmail échangent des e-mails, ceux-ci sont protégés par TLS ou, dans certains cas, envoyés directement au sein de l'application. Dans ce cas, les RPC utilisés par l'application Gmail sont protégés par ALTS, comme décrit dans la section Authentification, intégrité et chiffrement entre plusieurs services. Pour les messages entrants provenant d'autres fournisseurs de messagerie, Gmail n'applique pas le chiffrement TLS. Cela dit, les administrateurs peuvent configurer Gmail pour qu'il exige une connexion TLS sécurisée pour tous les e-mails entrants et sortants.

Gmail S/MIME

S/MIME (Secure/Multipurpose Internet Mail Extensions) est une norme de sécurité de messagerie qui fournit des fonctionnalités d'authentification, d'intégrité et de chiffrement. La mise en œuvre de la norme S/MIME exige que les certificats associés aux utilisateurs qui envoient des e-mails soient hébergés au sein d'une autorité de certification publique.

En tant qu'administrateur, vous pouvez configurer Gmail afin d'activer S/MIME pour les e-mails sortants, définir des règles de conformité relatives au contenu et aux pièces jointes, et créer des règles de routage pour les e-mails entrants et sortants. Une fois le service configuré, vous devez importer les certificats publics des utilisateurs dans Gmail à l'aide de l'API Gmail. Pour des communications entre des utilisateurs externes et Gmail, un message initial signé S/MIME doit être échangé afin de définir S/MIME comme norme par défaut.

Chiffrement entre plusieurs services et VM

Istio est un service "mesh" (ou maillage de services) Open Source développé par Google, IBM, Lyft et d'autres entreprises afin de simplifier la découverte et la connectivité des services. L'authentification Istio fournit un chiffrement automatique des données en transit entre les services, ainsi qu'une gestion des clés et des certificats associés. Istio est disponible dans Google Kubernetes Engine et Google Compute Engine.

Si vous souhaitez mettre en œuvre une authentification et un chiffrement mutuels pour les charges de travail, vous pouvez utiliser l'authentification Istio. Plus précisément, dans le cas de charges de travail Kubernetes, l'authentification Istio permet à une autorité de certification au niveau du cluster de générer et de distribuer des certificats, qui sont ensuite utilisés par le protocole mTLS (mutual Transport Layer Security) entre plusieurs pods.

Comment Google aide Internet à chiffrer les données en transit

Les sections Chiffrement en transit par défaut et Options configurables par l'utilisateur pour le chiffrement en transit vous ont décrit les protections par défaut et personnalisables mises en place par Google Cloud concernant les données client en transit. En outre, Google travaille sur plusieurs projets Open Source et sur d'autres initiatives qui encouragent l'utilisation du chiffrement en transit et la sécurité des données sur Internet en général.

Transparence des certificats

Comme indiqué dans la section Chiffrement du trafic entre les utilisateurs et Google Front End, un site doit d'abord obtenir un certificat auprès d'une autorité de certification Web (publique) approuvée pour pouvoir offrir le protocole HTTPS. L'autorité de certification doit alors vérifier que le demandeur est autorisé par le propriétaire du domaine, et s'assurer que toute autre information comprise dans le certificat est exacte.Ce certificat est ensuite présenté au navigateur afin d'authentifier le site auquel l'utilisateur essaie d'accéder. Pour garantir que le protocole HTTPS est correctement authentifié, il est important de vérifier que les autorités de certification n'émettent que des certificats autorisés par le propriétaire du domaine.

Le projet de transparence des certificats lancé par Google en mars 2013 permet 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. Le système fournit pour cela un mécanisme qui permet aux propriétaires de domaines, aux autorités de certification et au public de consigner les certificats approuvés qu'ils voient (ou émettent, dans le cas des autorités de certification) dans des journaux infalsifiables, en mode ajout uniquement et publiquement vérifiables. Les certificats contenus dans ces journaux peuvent être examinés par n'importe quel utilisateur pour s'assurer que les informations sont correctes, exactes et autorisées.

La première version du projet de transparence des certificats a été spécifiée dans une RFC expérimentale de l'IETF : RFC 6962. Au cours du développement de cette initiative, Google a mis un certain nombre d'outils Open Source à disposition de la communauté, dont un serveur de journalisation Open Source capable de consigner des certificats, ainsi que des outils permettant de créer des journaux de transparence des certificats. En outre, Google Chrome exige la divulgation publique de certains certificats, tels que les certificats EV (Extended Validation) ou les certificats émis par des autorités de certification ayant déjà délivré des certificats de manière inadaptée. À partir de 2018, Chrome exigera la divulgation de tous les nouveaux certificats publiquement approuvés.

En tant qu'opérateur de site, vous pouvez exploiter la transparence des certificats afin de détecter si des certificats non autorisés ont été émis pour votre site Web. Un certain nombre d'outils gratuits permettent de faciliter cette opération, tels que le rapport de transparence des certificats de Google, la recherche de certificats ou les outils de Facebook. Même si vous n'utilisez pas la transparence des certificats, un certain nombre de navigateurs examinent désormais régulièrement cette fonctionnalité pour garantir que les autorités de certification que vos utilisateurs approuvent afin d'accéder à votre site Web respectent les exigences et les bonnes pratiques du secteur, réduisant ainsi le risque d'émission de certificats frauduleux.

Démocratiser l'utilisation du protocole HTTPS

Comme décrit dans la section Chiffrement du trafic entre les utilisateurs et Google Front End, nous mettons tout en œuvre pour garantir que nos sites et services fournissent le protocole HTTPS moderne par défaut. Nous cherchons en effet à proposer un chiffrement intégral pour l'ensemble de nos produits et services. C'est pourquoi nous publions chaque année un rapport sur la transparence HTTPS qui suit notre progression vers cet objectif pour toutes les propriétés, y compris Google Cloud. Nous continuons à surmonter les obstacles techniques qui entravent la compatibilité du chiffrement dans certains de nos produits, tels que les solutions destinées aux navigateurs ou à d'autres clients qui n'acceptent pas le protocole HSTS (HTTPS Strict Transport Protocol)18. Nous exploitons HSTS sur certains de nos sites, y compris la page d'accueil google.com, pour permettre aux utilisateurs de ne se connecter à un serveur que via HTTPS.

Nous savons que le reste d'Internet œuvre à la transition vers HTTPS. Nous essayons de faciliter ce processus de différentes manières :

En 2016, nous avons commencé à publier des statistiques sur l'utilisation du protocole HTTPS sur Internet pour le top 100 des sites Internet indépendants de Google. Grâce à elles, nous espérons sensibiliser les internautes et faire d'Internet un lieu plus sûr. En octobre 2017, Chrome a officiellement renouvelé son soutien financier à Let's Encrypt en tant que sponsor Platinum.

Démocratiser l'utilisation du protocole SMTP sécurisé : indicateurs Gmail

La plupart des e-mails sont échangés à l'aide du protocole SMTP (Simple Mail Transfer Protocol) qui, par défaut, envoie des e-mails sans appliquer le moindre chiffrement. Pour chiffrer un e-mail, le fournisseur de messagerie doit mettre en œuvre des contrôles de sécurité tels que TLS.

Comme indiqué dans la section Chiffrement du trafic entre les utilisateurs et Google Front End, Gmail utilise le chiffrement TLS par défaut. En outre, la section Exiger le chiffrement TLS dans Gmail décrit comment les administrateurs Gmail peuvent appliquer la protection TLS pour les e-mails entrants et sortants. À l'instar des initiatives de Google concernant la transparence HTTPS, Gmail fournit des données sur l'utilisation de TLS pour les e-mails entrants. Ces données sont présentées dans notre rapport de transparence pour des e-mails plus sécurisés.

Google, en partenariat avec l'IETF et d'autres acteurs clés du secteur, mène le développement du protocole SMTP STS. Ce protocole est comparable à HSTS pour HTTPS, ne forçant l'utilisation de SMTP que sur les canaux chiffrés.

API Chrome

En février 2015, Chrome a annoncé le lancement exclusif de puissantes fonctionnalités pour les origines sécurisées19. Elles incluent le traitement des informations privées et l'accès aux capteurs de l'appareil d'un utilisateur. Nous avons également commencé à abandonner ces fonctionnalités pour les origines non sécurisées, en commençant par la géolocalisation de Chrome 50.

Innovation constante du chiffrement en transit

Expérience utilisateur de la sécurité Chrome

Google Chrome apparaît comme un leader du marché grâce à son interface utilisateur qui fournit aux internautes des informations liées à la sécurité et leur permet d'identifier rapidement la fiabilité de leur connexion à un site. À l'aide de ces informations, les utilisateurs peuvent prendre des décisions avisées concernant le partage de leurs données. Chrome effectue des recherches approfondies sur les utilisateurs, disponibles dans des articles examinés par des pairs.

Pour protéger davantage ses utilisateurs, Chrome a annoncé que toutes les connexions HTTP seront identifiées comme non sécurisées d'ici fin 2017. À partir de Chrome 56, les utilisateurs recevront un message d'avertissement sur les pages HTTP qui comprennent un formulaire demandant un mot de passe ou incluent des champs de carte de crédit. Avec Chrome 62, un message d'avertissement s'affichera lorsqu'un utilisateur saisira des données sur une page HTTP, ainsi que sur toutes les pages HTTP visitées en mode navigation privée. À terme, Chrome affichera un message d'avertissement sur toutes les pages desservies par le protocole HTTP.

Pour découvrir la façon dont les configurations particulières apparaissent aux utilisateurs dans Chrome, vous pouvez utiliser l'outil BadSSL.

Transparence des clés

La difficulté liée à l'échange de clés publiques dissuade fortement l'adoption globale du chiffrement des messages : comment puis-je trouver de manière fiable la clé publique d'un nouvel utilisateur avec lequel je communique ? Pour aider à résoudre ce problème, Google a annoncé la transparence des clés en janvier 2017. Il s'agit d'un framework ouvert qui offre la possibilité de distribuer des clés publiques de manière générique, sécurisée et contrôlable. Ce framework évite aux utilisateurs d'avoir à effectuer une vérification manuelle des clés. La transparence des clés cible principalement la distribution des clés publiques des utilisateurs dans les communications (par exemple, le chiffrement des e-mails de bout en bout et OpenPGP). La conception de la transparence des clés constitue une nouvelle approche en matière de récupération et de distribution des clés, et se base sur les renseignements obtenus grâce à la transparence des certificats et à CONIKS.

Le framework de transparence des clés est développé en Open Source et mis en œuvre à l'aide d'un arbre de Merkle à grande échelle. La vérification de la transparence des clés permet aux propriétaires de comptes d'identifier les clés associées à leurs comptes et de savoir depuis combien de temps un compte est actif et stable. L'objectif à long terme du travail de transparence des clés de Google est de permettre à tous les utilisateurs d'exécuter un serveur de transparence des clés et d'en faciliter l'intégration dans autant d'applications que l'on souhaite.

Cryptographie post-quantique

Google prévoit de rester le leader du marché du chiffrement en transit. À cette fin, nous avons commencé à œuvrer dans le domaine de la cryptographie post-quantique. Ce type de cryptographie nous permet de remplacer les primitives cryptographiques existantes vulnérables aux attaques quantiques efficaces par des candidats post-quantiques considérés comme plus résistants. En juillet 2016, nous avons annoncé avoir testé la faisabilité du déploiement d'un tel algorithme à l'aide de l'algorithme de cryptographie post-quantique New Hope dans la version développeur de Chrome. En plus de ce travail, les chercheurs de Google ont publié des articles sur d'autres protocoles pratiques d'échange de clés post-quantiques.

Annexe

Apprenez-en davantage au sujet de la sécurité Google Cloud et consultez la présentation de la sécurité de notre infrastructure. Obtenez également plus d'informations sur la conformité Google Cloud et prenez connaissance du rapport d'audit public SOC 3.

Notes de bas de page

1 Les solutions partenaires incluent à la fois des solutions proposées dans Cloud Launcher et des produits conçus en collaboration avec des partenaires, tels que Cloud Dataprep.
2 Vous pouvez toujours désactiver ce chiffrement, par exemple pour accéder aux buckets Google Cloud Storage via HTTP.
3 Les communications entre les VM et les services de production qui ne sont pas protégées au niveau de la couche 7 restent protégées au niveau des couches 3 et 4.
4 TLS 1.3 n'est pas encore finalisé. La version préliminaire n'est disponible que pour certains domaines Google tels que Gmail, à des fins de test.
5 Google est compatible avec TLS 1.0, pour les navigateurs qui utilisent toujours cette version du protocole. Veuillez noter que les sites Google traitant des informations de carte de crédit n'accepteront plus TLS 1.0 d'ici juillet 2018. Cette version sera en effet abandonnée dans le cadre de la conformité à la norme PCI (Payment Card Industry).
6 Pour en savoir plus sur le protocole QUIC, consultez la page [https://www.chromium.org/quic](https://www.chromium.org/quic).
7, 8, 9 Pour assurer la rétrocompatibilité avec certains systèmes d'exploitation plus anciens, nous acceptons les algorithmes 3DES, SHA1 et MD5.
10 Dans le cas des certificats en chaîne, l'autorité de certification est approuvée de manière transitoire.
11 Il peut s'agir d'un ticket de session ([RFC 5077](https://tools.ietf.org/html/rfc5077)) ou d'un ID de session ([RFC 5246](https://tools.ietf.org/html/rfc5246)).
12 Le plan de contrôle est la partie du réseau qui signale le trafic et se charge du routage.
13 D'autres protocoles étaient auparavant utilisés, mais ils sont désormais obsolètes. Moins de 1 % des tâches exploitent ces anciens protocoles.
14 DTLS (Datagram TLS) assure la sécurité des applications basées sur des datagrammes en leur permettant de communiquer de manière à empêcher l'écoute et la falsification.
15 Le protocole IKE (Internet Key Exchange) sert à configurer une association de sécurité dans la suite de protocoles IPsec.
16 L'algorithme HMAC-SHA-1 n'est pas rompu par une [collision SHA-1] (https://shattered.io/), telle que la collision SHAttered identifiée par les chercheurs de Google.
17 Dans G Suite Enterprise, cette information n'apparaît pas dans l'interface utilisateur. Les administrateurs de domaine peuvent examiner les données de leur domaine à l'aide de la [recherche dans le journal des e-mails] (https://support.google.com/a/answer/2604578).
18 Le protocole HSTS (HTTPS Strict Transport Protocol) est un mécanisme qui permet aux sites Web de ne se déclarer accessibles que via des connexions sécurisées. Grâce à lui, les utilisateurs peuvent également rediriger leurs user-agents pour qu'ils n'interagissent avec des sites spécifiques que via des connexions sécurisées.
19 Les origines sécurisées sont des connexions qui correspondent à certains [modèles] de schéma, d'hôte ou de port (https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features).
Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…