Chiffrement au repos par défaut

Ce contenu a été mis à jour pour la dernière fois en mai 2024, 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.

Chez Google, notre stratégie complète de sécurité inclut le chiffrement au repos, qui contribue à protéger les données client contre les pirates informatiques. Nous chiffrons tous les contenus client au repos de Google, sans aucune action de votre part, à l'aide d'un ou plusieurs mécanismes de chiffrement. Ce document décrit notre approche du chiffrement au repos par défaut pour l'infrastructure Google et Google Cloud, ainsi que la façon dont nous l'utilisons pour sécuriser les contenus client.

Ce document est destiné aux architectes de sécurité et aux équipes de sécurité qui utilisent actuellement ou envisagent d'utiliser Google. Dans ce document, nous partons du principe que vous possédez des connaissances de base en chiffrement et en primitives cryptographiques. Pour en savoir plus sur la cryptographie, consultez l'article Introduction à la cryptographie moderne.

Le chiffrement au repos est un chiffrement utilisé pour protéger les données stockées sur un disque (y compris des disques durs SSD) ou des supports de sauvegarde. Toutes les données stockées par Google sont chiffrées au niveau de la couche de stockage à l'aide de l'algorithme AES (Advanced Encryption Standard) AES-256. Nous utilisons une bibliothèque de cryptographie commune, Tink, qui inclut notre module certifié FIPS 140-2 (nommé BoringCrypto) pour mettre en œuvre le chiffrement de manière cohérente dans Google Cloud

Nous possédons et gérons les clés utilisées pour le chiffrement au repos par défaut. Si vous utilisez Google Cloud, Cloud Key Management Service vous permet de créer vos propres clés de chiffrement grâce auxquelles vous pouvez ajouter le chiffrement encapsulé à vos données. Cloud KMS vous permet de créer, d'alterner, de suivre et de supprimer des clés. Pour en savoir plus, consultez la présentation détaillée de Cloud Key Management Service.

Comment le chiffrement au repos aide à sécuriser les données

Le chiffrement au repos est un élément d'une stratégie de sécurité plus large. Le chiffrement présente les avantages suivants :

  • Permet de s'assurer que si des données tombent entre les mains d'un pirate informatique, le pirate informatique ne peut pas lire les données sans avoir accès aux clés de chiffrement. Même si des pirates informatiques obtiennent les appareils de stockage contenant des données client, ils ne pourront pas les comprendre ni les déchiffrer.
  • Elle permet de réduire la surface d'attaque en supprimant les couches inférieures de la pile matérielle et logicielle.
  • Elle sert de goulot d'étranglement, car les clés de chiffrement gérées de manière centralisée créent un point d'accès unique et contrôlé aux données.
  • Elle permet de réduire la surface d'attaque, car au lieu de devoir protéger toutes les données, les entreprises peuvent se concentrer sur leurs stratégies de protection sur les clés de chiffrement.
  • Elle offre un mécanisme de confidentialité important à nos clients. Lorsque les données sont chiffrées au repos, elles limitent l'accès des systèmes et des ingénieurs aux données.

En quoi consistent les données client ?

Comme défini dans les Conditions d'utilisation de Google Cloud, les données client sont des données fournies par les clients ou les utilisateurs finaux à Google via les services dans le cadre de leur compte.

Les contenus client correspondent aux données que vous générez vous-même ou que vous nous fournissez, telles que les données stockées dans des buckets Cloud Storage, les volumes Persistent Disk et les instantanés de disque utilisés par Compute Engine. Ce document se concentre sur le chiffrement au repos par défaut pour ce type de données client.

Les métadonnées client sont des données sur vos contenus client et incluent des numéros de projet, des horodatages, des adresses IP, la taille en octets d'un objet dans Cloud Storage ou le type de machine dans Compute Engine générés automatiquement. Le niveau de protection des métadonnées client permet d'assurer la continuité des performances et des opérations. Ce document ne se concentre pas sur les protections liées aux métadonnées.

Les contenus et les métadonnées client constituent les données client.

Chiffrement par défaut des données au repos

Google chiffre tout le contenu client stocké au repos, sans aucune action de votre part, à l'aide d'un ou de plusieurs mécanismes de chiffrement. Les sections suivantes décrivent les mécanismes que nous utilisons pour chiffrer les contenus client.

Couches de chiffrement

Google assure la protection des données à l'aide de plusieurs couches de chiffrement. Ces différentes couches offrent une protection redondante des données et nous permettent de choisir l'approche la mieux adaptée aux exigences de l'application.

Le schéma suivant illustre les différentes couches de chiffrement généralement utilisées pour protéger les données utilisateur dans les centres de données de production de Google. Pour toutes les informations sur l'utilisateur, le chiffrement est instauré soit au niveau du système de fichiers distribués, soit au niveau de la base de données et du stockage de fichiers. Le chiffrement des appareils de stockage est également mis en place pour tous les centres de données de production Google.

Plusieurs couches de chiffrement

Chiffrement au niveau de la couche matérielle et de l'infrastructure

Tous les systèmes de stockage de Google utilisent une architecture de chiffrement similaire, bien que les détails de l'implémentation diffèrent d'un système à l'autre. Les données sont divisées en fragments de sous-fichiers pour le stockage, la taille de chaque fragment pouvant atteindre plusieurs gigaoctets. Chaque fragment est chiffré au niveau de l'espace de stockage à l'aide d'une clé de chiffrement de données individuelle (DEK). Les deux fragments ne peuvent pas avoir la même DEK, même s'ils appartiennent au même client ou sont stockés sur la même machine. (Un fragment de données dans Datastore, App Engine et Pub/Sub peut contenir les données de plusieurs clients.)

Si un fragment de données est mis à jour, il est chiffré avec une nouvelle clé plutôt qu'avec la clé existante. Ce partitionnement des données, utilisant chacun une clé différente, limite le risque de piratage éventuel de la clé de chiffrement des données à ce fragment de données uniquement.

Google chiffre les données avant qu'elles ne soient écrites sur un système de stockage de base de données ou un disque matériel. Plutôt que de l'ajouter ultérieurement, le chiffrement est inhérent à tous nos systèmes de stockage.

Chaque fragment de données possède un identifiant unique. Les listes de contrôle d'accès (LCA) permettent de s'assurer que chaque fragment ne peut être déchiffré que par les services Google fonctionnant avec des rôles autorisés, auxquels l'accès n'est accordé qu'à ce moment précis. Cette limitation d'accès permet d'empêcher l'accès aux données sans autorisation, ce qui renforce la sécurité et la confidentialité des données.

Chaque fragment est distribué sur nos différents systèmes de stockage et est répliqué sous forme chiffrée pour la sauvegarde et la reprise après sinistre. Un pirate informatique qui souhaite accéder aux données client devrait accéder et connaître deux choses : tous les fragments de stockage correspondant aux données qu'il convoite et toutes les clés de chiffrement correspondantes aux fragments.

Le schéma suivant montre comment les données sont importées dans notre infrastructure, puis divisées en fragments chiffrés pour le stockage.

Mode d'importation des données

Nous utilisons l'algorithme AES pour chiffrer les données au repos. Toutes les données au niveau de l'espace de stockage sont chiffrées par des DEK utilisant l'algorithme AES-256 par défaut, à l'exception d'un petit nombre de disques persistants créés avant 2015 qui utilisent l'algorithme AES-128. L'algorithme AES est largement utilisé, car les algorithmes AES-256 et AES-128 sont recommandés par le NIST (National Institute of Standards and Technology) pour le stockage à long terme. AES est aussi souvent inclus dans les exigences de conformité client.

Chiffrement au niveau de la couche de l'appareil de stockage

En plus du chiffrement au niveau du système de stockage, les données sont également chiffrées au niveau de l'appareil de stockage avec AES-256 pour les disques durs HDD et SSD,à l'aide d'une clé au niveau de l'appareil distincte (différente de la clé utilisée pour chiffrer les données au niveau de l'espace de stockage). Un petit nombre d'anciens disques durs utilisent l'algorithme AES128. Les disques durs SSD utilisés par Google appliquent l'algorithme AES-256 exclusivement pour les données utilisateur.

Chiffrement des sauvegardes

Notre système de sauvegarde garantit que les données restent chiffrées tout au long du processus de sauvegarde. Cette approche évite d'exposer inutilement des données en texte brut.

En outre, le système de sauvegarde chiffre la plupart des fichiers de sauvegarde de manière indépendante avec leur propre clé DEK. La DEK est dérivée d'une clé stockée dans Keystore et d'une valeur de départ générée de manière aléatoire pour chaque fichier au moment de la sauvegarde. Une autre DEK (également stockée dans Keystore) est utilisée pour toutes les métadonnées des sauvegardes.

Conformité FIPS pour les données au repos

Google utilise un module de chiffrement certifié FIPS 140-2 (certificat 4407) dans son environnement de production.

Gestion des clés

En raison de la nécessité d'une faible latence et d'une disponibilité élevée, ainsi que du grand nombre de clés chez Google, les DEK sont stockées à proximité des données qu'elles chiffrent. Les DEK sont chiffrées (encapsulées) à l'aide d'une clé de chiffrement de clé (KEK), selon une technique connue sous le nom de chiffrement encapsulé. Ces KEK ne sont pas spécifiques aux clients. À la place, il existe une ou plusieurs KEK pour chaque service.

Celles-ci sont stockées de manière centralisée dans Keystore, un dépôt conçu spécialement à cette fin. Le fait d'avoir un nombre de KEK inférieur à celui des DEK et d'utiliser un keystore central facilite la gestion du stockage et du chiffrement des données à notre échelle, ce qui nous permet de suivre et de contrôler l'accès aux données à partir d'un point central.

Dans Google Cloud, chaque client peut disposer de ressources partagées et non partagées. Une image de base partagée dans Compute Engine est un exemple de ressource partagée. Pour les ressources partagées, plusieurs clients font référence à une seule copie, qui est chiffrée par une seule clé DEK. Les ressources non partagées sont divisées en fragments de données et chiffrées à l'aide de clés distinctes de celles utilisées pour les autres clients. Ces clés diffèrent également de celles qui protègent les autres éléments de données appartenant à ce même client. Il existe des exceptions (Datastore, App Engine ou Pub/Sub, par exemple) où les données de plusieurs clients peuvent être chiffrées avec la même DEK.

Générer les DEK

Le système de stockage génère des DEK à l'aide de la bibliothèque de cryptographie commune de Google. En général, les DEK sont envoyées à Keystore pour être encapsulées avec la KEK de ce système de stockage. Les DEK encapsulées sont ensuite renvoyées au système de stockage pour être conservées avec les fragments de données. Lorsqu'un système de stockage doit récupérer des données chiffrées, il récupère la DEK encapsulée et la transmet à Keystore. Ce dernier vérifie que ce service est autorisé à utiliser la KEK et, le cas échéant, désencapsule la DEK et la lui renvoie en texte brut. Le service se sert ensuite de la DEK pour déchiffrer le fragment de données en texte brut et vérifier son intégrité.

Tous les systèmes de stockage Google Cloud respectent ce modèle de gestion des clés, mais la plupart des systèmes mettent également en œuvre des niveaux supplémentaires de KEK côté stockage pour créer une hiérarchie de clés. Cela permet aux systèmes de fournir une faible latence tout en utilisant la KEK la plus élevée (stockée dans Keystore) comme racine de confiance.

Générer des KEK

La plupart des KEK employées pour le chiffrement des fragments de données sont générées dans Keystore. Les autres sont générées au sein des services de stockage. Par souci de cohérence, toutes les KEK sont générées à l'aide de la bibliothèque de cryptographie commune de Google, grâce à un générateur de nombres aléatoires (GNA) élaboré par Google. Ce générateur repose sur le mécanisme CTR-DRBG de la recommandation 800-90Ar1 du NIST et génère une KEK AES-256. (Auparavant, le protocole utilisé était AES-128, et certaines de ces clés sont toujours actives pour le déchiffrement des données.)

Pour les processeurs Intel et AMD, le GNA provient des instructions RDRAND et du GNA du noyau Linux. À son tour, le GNA du noyau Linux provient de plusieurs sources d'entropie indépendantes, y compris la fonction RDRAND et les événements entropiques de l'environnement de centre de données (par exemple, des mesures ultraprécises des recherches disques et l'arrivée entre paquets). Pour les processeurs Arm, le GNA puise dans le GNA du noyau Linux.

Les DEK sont encapsulées avec des KEK utilisant l'algorithme AES-256 ou AES-128, selon le service Google Cloud. Nous travaillons actuellement à la mise à niveau vers AES-256 de toutes les KEK pour les services Google Cloud.

Gestion des KEK

Le Keystore a été créé uniquement dans le but de gérer les KEK. De par leur conception, les KEK utilisées par les systèmes de stockage ne peuvent pas être exportées depuis Keystore. Toutes les opérations de chiffrement et de déchiffrement avec ces clés doivent être effectuées au sein de Keystore. Cela évite les fuites et les utilisations abusives, et permet à Keystore de créer un journal d'audit en cas d'utilisation des clés.

Keystore peut effectuer une rotation automatique des KEK à intervalles réguliers, en générant de nouvelles clés à l'aide de la bibliothèque de cryptographie commune de Google. Bien que nous fassions souvent référence à une seule clé, les données sont en fait protégées à l'aide d'un ensemble de clés : une clé est active pour le chiffrement et un ensemble de clés historiques est actif pour le déchiffrement. Le nombre de clés historiques est déterminé par le calendrier de rotation des clés. Les KEK sont sauvegardées à des fins de reprise après sinistre et peuvent être récupérées indéfiniment.

L'utilisation des KEK est gérée par des LCA dans Keystore pour chaque clé, avec une règle par clé. Seuls les utilisateurs et services de Google autorisés ont accès à une clé. L'utilisation de chaque clé est suivie au niveau de l'opération individuelle nécessitant cette clé. Ainsi, chaque fois qu'un utilisateur se sert d'une clé, cette action fait l'objet d'une authentification et d'une journalisation. Tous les accès aux données par les utilisateurs peuvent être contrôlés dans le cadre des règles de sécurité et de confidentialité générales de Google.

Processus d'accès aux fragments de données chiffrés

Lorsqu'un service Google accède à un fragment de données chiffré, voici ce qui se produit :

  1. Le service demande au système de stockage les données dont il a besoin.
  2. Le système de stockage identifie les fragments dans lesquels ces données sont stockées (les ID de fragment) et leur emplacement.
  3. Le système de stockage extrait la DEK encapsulée stockée avec chaque fragment (dans certains cas, le service effectue cette opération) et l'envoie à Keystore pour qu'il la désencapsule.
  4. Le système de stockage vérifie que le job identifié est autorisé à accéder à ce fragment de données grâce à un identifiant de job et à l'ID du fragment. Keystore vérifie que le système de stockage est autorisé à utiliser la KEK associée au service et à désencapsuler cette DEK spécifique.
  5. Keystore effectue l'une des opérations suivantes :
    • Il renvoie la DEK désencapsulée au système de stockage, qui déchiffre le fragment de données et le transmet au service.
    • Dans de rares cas, elle transmet la DEK désencapsulée au service. Le système de stockage transmet alors le fragment de données chiffré au service, qui le déchiffre et l'utilise.

Ce processus est différent dans les appareils de stockage dédiés, dans lesquels la gestion et la protection de la DEK sont assurées au niveau de l'appareil.

Le schéma suivant illustre ce processus. Pour déchiffrer un fragment de données, le service de stockage appelle Keystore afin de récupérer la DEK désencapsulée correspondant à ce fragment.

Processus de chiffrement des fragments de données

Hiérarchie des clés de chiffrement et racine de confiance

Keystore est protégé par une clé racine appelée clé principale Keystore, qui encapsule l'ensemble des KEK de Keystore. Cette clé principale utilise l'algorithme AES-256 et est elle-même stockée dans un autre service de gestion des clés, nommé Root Keystore. (Auparavant, la clé principale eu Keystore était basée sur l'algorithme AES-128, et certaines de ces clés sont toujours actives pour le déchiffrement des données). Pour plus de sécurité, Root Keystore n'est pas exécuté sur les machines de production générale, mais seulement sur des machines dédiées dans chaque centre de données Google.

Root Keystore possède à son tour sa propre clé racine, appelée clé principale de Root Keystore, qui est également AES-256 et est stockée dans une infrastructure peer-to-peer, qui est appelée distributeur de clés principales de Root Keystore, qui réplique ces clés à l'échelle mondiale. (Auparavant, la clé principale de Root Keystore était AES-128, et certaines de ces clés sont toujours actives pour le déchiffrement des données). Ce distributeur ne garde les clés en mémoire RAM que sur les machines dédiées sur lesquelles Root Keystore est exécuté et vérifie par le biais de la journalisation que leur utilisation est appropriée.

Lorsqu'une nouvelle instance du distributeur de clés principales Root Keystore est démarrée, elle est configurée avec la liste des noms d'hôte exécutant déjà des instances du distributeur. Elle peut ensuite obtenir la clé principale Root Keystore auprès de ces autres instances en cours d'exécution. Outre les mécanismes de reprise après sinistre décrits sur la page Disponibilité et réplication globales, la clé principale Root Keystore n'existe que dans la mémoire RAM d'un nombre limité de machines spécialement sécurisées.

Dans l'éventualité où toutes les instances du distributeur de clés principales Root Keystore d'une région redémarreraient simultanément, la clé principale Root Keystore est également sauvegardée sur des périphériques matériels sécurisés stockés dans des coffres-forts physiques des zones sécurisées dans plusieurs zones géographiques. Cette sauvegarde n'est nécessaire qu'en cas d'arrêt simultané de toutes les instances du distributeur d'une région. Seuls quelques employés Google peuvent accéder à ces coffres-forts.

Le schéma suivant illustre la hiérarchie des clés de chiffrement. La hiérarchie des clés de chiffrement protège un fragment de données à l'aide d'une DEK encapsulée avec une KEK dans Keystore, qui à son tour est protégée par Root Keystore et le distributeur de clés principales Root Keystore.

Hiérarchie des clés de chiffrement

Récapitulatif de la gestion des clés

La liste suivante récapitule la gestion des clés chez Google :

  • Les données sont fragmentées et chiffrées à l'aide de DEK.
  • Les DEK sont chiffrées à l'aide de KEK.
  • Les KEK sont stockées dans Keystore.
  • Keystore est exécuté sur plusieurs machines situées dans des centres de données du monde entier.
  • Les clés Keystore sont encapsulées avec la clé principale Keystore, qui est stockée dans Root Keystore.
  • Root Keystore est beaucoup plus petit que Keystore et ne s'exécute que sur des machines dédiées dans chaque centre de données.
  • Les clés Root Keystore sont encapsulées avec la clé principale Root Keystore, qui est stockée dans le distributeur de clés principales Root Keystore.
  • Le distributeur de clés principales Root Keystore est une infrastructure peer-to-peer qui est exécutée simultanément dans la mémoire RAM sur des machines dédiées du monde entier. Chaque machine obtient son matériel de clé à partir d'autres instances en cours d'exécution dans la région.
  • En cas de panne de toutes les instances du distributeur d'une région, une clé principale est stockée sur un matériel sécurisé différent dans des coffres-forts physiques des emplacements Google limités.

Disponibilité mondiale et réplication

À chaque niveau, la haute disponibilité, une faible latence et un accès mondial aux clés sont essentiels. Ces caractéristiques sont nécessaires pour l'utilisation des services de gestion des clés dans Google.

Pour cette raison, Keystore est hautement évolutif et est répliqué des milliers de fois dans nos centres de données du monde entier. Il est mis en œuvre sur des machines standards dans notre parc de production, tandis que ses instances sont exécutées à l'échelle mondiale pour assurer les opérations de Google. Ainsi, toute opération impliquant une clé a une très faible latence.

Root Keystore est exécuté au sein de chaque centre de données, sur plusieurs machines dédiées aux opérations de sécurité. Le distributeur de clés principales Root Keystore est exécuté sur ces machines, parallèlement à Root Keystore. Le distributeur de clés principales Root Keystore fournit un mécanisme de distribution à l'aide d'un protocole de bogue. À intervalles fixes, chaque instance du distributeur sélectionne une autre instance de manière aléatoire pour comparer ses clés et rapproche les différences entre les versions de clé. Avec ce modèle, notre infrastructure ne dépend d'aucun nœud central. Cette méthode de distribution nous permet de gérer et de protéger le matériel de clé avec une haute disponibilité.

Bibliothèque de cryptographie commune de Google

Tink est la bibliothèque de cryptographie commune de Google. Elle inclut notre module certifié FIPS 140-2 BoringCrypto. Tous les développeurs Google y ont accès. L'utilisation systématique d'une bibliothèque commune signifie qu'une petite équipe de spécialistes du chiffrement peut assurer de manière adéquate la mise en œuvre de ce code étroitement contrôlé et révisé. Ainsi, toutes les équipes ne sont pas obligées de développer leur propre cryptographie. Une équipe de sécurité Google dédiée est ainsi chargée de la maintenance de la bibliothèque pour tous les produits.

La bibliothèque de cryptographie Tink accepte un large éventail de types et de modes de clés de chiffrement. Ceux-ci font l'objet d'un examen régulier afin de vérifier qu'ils sont efficaces contre les dernières attaques mises au point.

Actuellement, nous utilisons les algorithmes de chiffrement suivants pour le chiffrement au repos pour les DEK et les KEK. Ils sont susceptibles de changer à mesure que nous poursuivons nos efforts d'amélioration de nos fonctionnalités et de notre sécurité.

Primitive cryptographique Protocoles à privilégier Autres protocoles acceptés
Chiffrement symétrique AES-GCM (256 bits)
  • AES-CBC et AES-CTR (128 et 256 bits)
  • AES-EAX (128 et 256 bits)
Signatures symétriques (en cas d'utilisation avec les protocoles AES-CBC et AES-CTR ci-dessus pour l'authentification) HMAC-SHA256
  • HMAC-SHA512
  • HMAC-SHA1

D'autres protocoles cryptographiques existent dans la bibliothèque et étaient traditionnellement acceptés, mais ce tableau couvre les principales utilisations chez Google.

Recherche et innovation en matière de cryptographie

Pour rester en phase avec l'évolution du chiffrement, nous avons réuni une équipe composée des meilleurs ingénieurs en sécurité, qui est chargée de suivre, de développer et d'améliorer les technologies de chiffrement. Nos ingénieurs participent aux processus de normalisation et à la maintenance des logiciels de chiffrement couramment utilisés. Nous publions régulièrement nos études dans le domaine du chiffrement, afin que tout le monde, y compris le grand public, puisse en bénéficier.

Par exemple, dans la recherche sur la cryptographie post-quantique, nous travaillons dans les domaines suivants :

Notez que le chiffrement symétrique (à l'aide de l'algorithme AES-128 ou version ultérieure) reste résistant aux attaques quantiques.

Étapes suivantes