Chiffrement au repos dans Google Cloud Platform

Le contenu du présent document est correct et représente le statu quo au mois d'avril 2017. Les règles et les systèmes de sécurité de Google Cloud Platform peuvent changer par la suite, car nous améliorons continuellement la protection de nos clients.

Bouton de lecture

Chiffrement au repos dans Google Cloud

Résumé à l'intention des responsables informatiques

  • Google utilise plusieurs niveaux de chiffrement pour protéger les données client au repos dans les produits Google Cloud Platform.
  • Google Cloud Platform chiffre automatiquement les contenus client stockés au repos à l'aide d'une ou de plusieurs méthodes. Il existe toutefois quelques petites exceptions mentionnées plus loin dans ce document.
  • Les données stockées sont divisées en fragments, et chacun d'entre eux est chiffré avec une clé de chiffrement unique. Les clés de chiffrement sont quant à elles stockées avec les données, et chiffrées (ou "encapsulées") à l'aide de clés de chiffrement de clés. Ces dernières sont stockées et utilisées exclusivement dans le service Key Management Service central de Google, qui est redondant et distribué à l'échelle mondiale.
  • Les données stockées dans Google Cloud Platform sont chiffrées au niveau du stockage à l'aide de l'algorithme AES256 ou AES128.
  • Tink, une bibliothèque de cryptographie commune, permet à Google de mettre en œuvre le chiffrement de manière cohérente dans presque tous les produits Google Cloud Platform. Grâce à la diffusion à grande échelle de cette bibliothèque, la mise en œuvre et la gestion de ce code étroitement contrôlé et révisé sont assurées de manière adéquate par seulement quelques spécialistes du chiffrement.

Présentation

Pour beaucoup de particuliers et d'entreprises, la sécurité est un critère décisif dans le choix d'un fournisseur de cloud public. Chez Google, il s'agit d'un facteur de la plus haute importance. Nous prenons la sécurité et la confidentialité au sérieux, et assurons sans relâche la protection de vos données, qu'elles circulent sur Internet, migrent entre nos centres de données ou soient stockées sur nos serveurs.

Le chiffrement des données en transit et au repos est au cœur de notre stratégie globale de sécurité, garantissant ainsi que seuls les services et rôles autorisés peuvent consulter les données, avec un accès contrôlé aux clés de chiffrement. Ce document décrit l'approche adoptée par Google en matière de chiffrement au repos pour Google Cloud Platform, ainsi que la façon dont elle permet d'améliorer la sécurité de vos informations.

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 Platform. Hormis dans cette introduction, le présent document suppose que vous disposiez des connaissances de base en matière de chiffrement et de primitives cryptographiques.

Qu'est-ce que le chiffrement ?

Le chiffrement est un processus qui prend comme entrée des données lisibles (souvent appelées "texte brut"). Il les transforme ensuite en une sortie (ou "texte chiffré") révélant peu d'informations, voire aucune, sur le texte brut. L'algorithme de chiffrement utilisé est public, par exemple AES (Advanced Encryption Standard), mais l'exécution repose sur une clé gardée secrète, qui est obligatoire pour déchiffrer le texte et rétablir sa forme d'origine. Chez Google, nous associons généralement le chiffrement à la protection de l'intégrité. En effet, une personne ayant accès au texte chiffré doit nécessairement connaître la clé pour pouvoir le comprendre ou le modifier. Si vous souhaitez obtenir plus d'informations sur la cryptographie, Introduction to Modern Cryptography constitue une bonne source de référence.

Dans ce livre blanc, nous nous concentrons sur le chiffrement au repos. Par là, nous entendons le chiffrement mis en place pour protéger les données stockées sur des disques (y compris des disques durs SSD) ou des supports de sauvegarde.

Pourquoi le chiffrement permet-il de protéger les données client ?

Le chiffrement, qui s'inscrit dans une stratégie de sécurité plus large, ajoute un niveau de défense en profondeur en matière de protection des données. Ainsi, si celles-ci tombent accidentellement entre de mauvaises mains, il est impossible d'y accéder sans disposer des clés de chiffrement. Même si un pirate informatique entre en possession des appareils de stockage, il ne peut pas comprendre ni déchiffrer vos données.

Le chiffrement au repos limite la surface d'attaque en "coupant" efficacement les couches inférieures de la pile matérielle et logicielle. Avec la mise en place du chiffrement adéquat, même si la sécurité de ces couches est compromise (par exemple, par un accès physique aux appareils), celle des données est assurée. Le chiffrement fait également office de "point névralgique" : 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.

Le chiffrement constitue un mécanisme important dans la manière dont Google garantit la confidentialité des données client. Il permet aux systèmes de manipuler les données, par exemple à des fins de sauvegarde, et aux ingénieurs d'effectuer l'assistance de notre infrastructure, sans donner accès aux contenus.

Notre conception des données client

Comme défini dans les Conditions d'utilisation de Google Cloud Platform, le terme données client fait référence aux contenus fournis à Google par un client Google Cloud Platform (ou fournis sur ses instructions), directement ou non, via les services Google Cloud Platform qu'il utilise sur son compte. Les données client incluent les contenus et les métadonnées client.

Les contenus client correspondent aux données que les clients de Google Cloud Platform génèrent eux-mêmes ou fournissent à Google. Il s'agit par exemple des données stockées dans Google Cloud Storage, des instantanés de disque utilisés par Google Compute Engine et des stratégies Cloud IAM. Ce livre blanc met l'accent sur le chiffrement au repos des contenus client.

Les métadonnées client constituent le reste des données client et font référence à toutes les données qui ne peuvent pas être classées en tant que contenus client. Cela peut comprendre les numéros de projet, les horodatages et les adresses IP générés automatiquement, ainsi que la taille en octets d'un objet dans Google Cloud Storage ou le type de machine dans Google Compute Engine. Le niveau de protection des métadonnées permet d'assurer la continuité des performances et des opérations.

Chiffrement par défaut de Google

Chiffrement des données au repos

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.

Graphique sur les couches de chiffrement

Figure 1 : Les données stockées dans Google Cloud Platform sont protégées à l'aide de plusieurs couches de chiffrement. Soit le chiffrement du système de fichiers distribués, soit le chiffrement de la base de données et du stockage de fichiers est instauré pour presque tous les fichiers. Le chiffrement des appareils de stockage est mis en place pour pratiquement tous les fichiers.

Chiffrement au niveau de la couche du système de stockage

Pour comprendre le fonctionnement spécifique du chiffrement Google Cloud Storage, il est important de savoir comment Google stocke les données client. 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 du stockage à l'aide d'une clé de chiffrement individuelle. Deux fragments n'ont pas la même clé de chiffrement, même s'ils font partie du même objet Google Cloud Storage, appartiennent au même client ou sont stockés sur la même machine1. Si un fragment de données est mis à jour, il est chiffré avec une nouvelle clé plutôt qu'avec la clé existante. Ce type de partition, où les données utilisent des clés différentes, limite le risque à ce seul fragment de données en cas de piratage éventuel de la clé de chiffrement de données.

Google chiffre les données avant leur écriture sur le disque. Plutôt que de l'ajouter ultérieurement, Google intègre dès le départ le chiffrement à tous ses systèmes de stockage.

Chaque fragment de données possède un identifiant unique. Les listes de contrôle d'accès (LCA) garantissent que chaque fragment ne peut être déchiffré que par les services Google dotés des rôles autorisés, auxquels l'accès est accordé à ce moment précis. Cela empêche tout accès non autorisé aux données, renforçant ainsi à la fois la sécurité et la confidentialité des données.

Chaque fragment est distribué sur les différents systèmes de stockage de Google, et est répliqué sous forme chiffrée pour la sauvegarde et la reprise après sinistre. Un individu malveillant qui souhaiterait accéder aux données client devrait non seulement connaître (1) tous les fragments de stockage correspondant aux données qu'il convoite et (2) les clés de chiffrement correspondant à ces fragments, mais également y avoir accès.

Diagramme des données stockées dans des fragments chiffrés

Figure 2 : Chez Google, les données sont divisées en fragments chiffrés pour le stockage.

Google chiffre les données au repos à l'aide de l'algorithme AES (Advanced Encryption Standard). Son utilisation est très répandue, car (1) AES256 et AES128 sont recommandés par le NIST (National Institute of Standards and Technology) pour le stockage à long terme (depuis novembre 2015), et (2) AES fait souvent partie des exigences des clients en matière de conformité.

Dans presque tous les cas, les données stockées dans Google Cloud Storage sont chiffrées au niveau du stockage à l'aide d'AES, en mode GCM (Galois/Counter Mode). AES est d'ailleurs mis en œuvre dans la bibliothèque BoringSSL gérée par Google. Cette bibliothèque est un dérivé d'OpenSSL, créé pour un usage interne après la découverte de nombreuses failles dans OpenSSL. Dans certains cas, AES est utilisé en mode CBC (Cipher Block Chaining) avec un code d'authentification de message par hachage (HMAC, Hashed Message Authentication Code) pour l'authentification. Pour certains fichiers répliqués, AES est utilisé en mode CTR (Counter) avec un HMAC. (De plus amples détails sur les algorithmes sont fournis plus loin dans ce document.) Dans d'autres produits de Google Cloud Platform, AES est employé de diverses manières.

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

En plus du chiffrement au niveau du système de stockage décrit précédemment, un chiffrement des données au niveau de l'appareil de stockage est également mis en place dans la plupart des cas. Au minimum, les disques durs font l'objet d'un chiffrement AES128 et les nouveaux disques SSD d'un chiffrement AES256, à l'aide d'une clé de niveau appareil distincte (différente de celle permettant de chiffrer les données au niveau du stockage). À mesure que les anciens appareils sont remplacés, AES256 est appelé à devenir le seul algorithme de chiffrement de niveau appareil.

Chiffrement des sauvegardes

Le système de sauvegarde de Google 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 chaque fichier de sauvegarde de manière indépendante avec sa propre clé de chiffrement de données (DEK, Data Encryption Key), dérivée d'une clé stockée dans le service Key Management Service (KMS) de Google 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 est utilisée pour toutes les métadonnées des sauvegardes, qui sont également stockées dans le service KMS de Google. (La gestion des clés fait l'objet d'une description détaillée dans une section ultérieure.)

Arrive-t-il que les données ne soient pas chiffrées au repos ?

Google Cloud Platform chiffre les contenus client stockés au repos à l'aide d'un ou de plusieurs mécanismes, hormis dans les cas mentionnés ci-après :

  • Journaux de la console série générés à partir de machines virtuelles dans Google Compute Engine (correction en cours)
  • Fichiers de vidage principaux écrits sur des disques locaux, en cas d'échec inattendu d'un processus (correction en cours)
  • Journaux de débogage écrits sur le disque local (correction en cours)
  • Fichiers temporaires utilisés par des systèmes de stockage (correction en cours)
  • Certains journaux pouvant inclure des contenus client, ainsi que des métadonnées client (correction planifiée)

Le reste de l'infrastructure de sécurité de Google offre cependant une protection étendue à ces données qui, dans presque tous les cas, font l'objet d'un chiffrement au niveau du stockage.

Gestion des clés

Clés de chiffrement de données, clés de chiffrement de clés et service Key Management Service de Google

Les données d'un fragment sont chiffrées à l'aide d'une clé de chiffrement de données (DEK). 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, ces clés sont stockées à proximité des données qu'elles chiffrent. Les DEK sont elles-mêmes chiffrées (ou "encapsulées") à l'aide d'une clé de chiffrement de clés (KEK, Key Encryption Key). Chaque service Google Cloud Platform peut posséder une ou plusieurs KEK. Celles-ci sont stockées de manière centralisée dans le service Key Management Service (KMS) de Google, 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 service KMS central permet de gérer le stockage et le chiffrement des données à l'échelle de Google, ainsi que de centraliser le suivi et le contrôle de l'accès aux données.

Les ressources non partagées2 de chaque client Google Cloud Platform sont toutes divisées en fragments de données et chiffrées à l'aide de clés différentes de celles des autres clients3. Ces DEK sont également différentes de celles qui protègent les autres éléments de données appartenant à ce même client.

Les DEK sont générées par le système de stockage à l'aide de la bibliothèque de cryptographie commune de Google. Elles sont ensuite envoyées à KMS pour être encapsulées avec la KEK de ce système de stockage, puis 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 à KMS. Ce dernier vérifie que ce système est autorisé à utiliser la KEK et, le cas échéant, désencapsule la DEK et la lui renvoie en texte brut. Le système se sert ensuite de la DEK pour déchiffrer le fragment de données en texte brut et vérifier son intégrité.

La plupart des KEK employées pour le chiffrement des fragments de données sont générées dans KMS. 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 AES2564. Ce GNA puise dans le GNA du noyau Linux, qui lui-même puise dans plusieurs sources d'entropie indépendantes. Cela inclut les événements entropiques de l'environnement de centre de données, tels que les mesures ultra-précises des accès disques et les temps d'arrivée entre les paquets, ainsi que les instructions RDRAND d'Intel, lorsqu'elles sont disponibles (sur Ivy Bridge et les nouveaux processeurs).

Comme décrit précédemment, les données stockées dans Google Cloud Platform sont chiffrées avec des DEK utilisant l'algorithme AES256 ou AES128. Les nouvelles données chiffrées sur des disques persistants dans Google Compute Engine sont chiffrées à l'aide d'AES256. Les DEK sont encapsulées avec des KEK utilisant l'algorithme AES256 ou AES128, selon le service Google Cloud Platform. Nous travaillons actuellement à la mise à niveau vers AES256 de toutes les KEK pour les services Cloud.

Le service KMS de Google gère les KEK et a été créé uniquement à cette fin. Il a été pensé dans un esprit de sécurité. Les KEK sont conçues de façon à rendre impossible leur exportation à partir du service KMS de Google. Toute opération de chiffrement et de déchiffrement avec ces clés doit être effectuée au sein de KMS. Cela évite les fuites et les utilisations abusives, et permet à KMS d'émettre un journal d'audit en cas d'utilisation des clés.

KMS 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 bel et bien protégées à l'aide d'un ensemble de clés : une clé active pour le chiffrement et un ensemble de clés historiques pour le déchiffrement, dont le nombre est déterminé par le calendrier de rotation des clés. Le calendrier de rotation réel d'une KEK varie selon les services, mais la période de rotation standard est de 90 jours. Google Cloud Storage, en particulier, procède à la rotation de ses KEK tous les 90 jours et peut en stocker jusqu'à 20 versions, ce qui nécessite de rechiffrer les données au moins une fois tous les cinq ans (dans la pratique, le rechiffrement des données intervient beaucoup plus fréquemment). Les clés détenues par KMS sont sauvegardées à des fins de reprise après sinistre et peuvent être récupérées indéfiniment.

L'utilisation de chaque KEK est gérée sur une base individuelle par des LCA dans KMS. 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'une personne se sert d'une clé, cette action fait l'objet d'une authentification et d'une journalisation. Tous les accès aux données humaines peuvent être contrôlés dans le cadre des règles de sécurité et de confidentialité générales de Google.

Lorsqu'un service Google Cloud Platform 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 à KMS pour qu'il la désencapsule.
  4. Le système de stockage vérifie que la tâche identifiée est autorisée à accéder à ce fragment de données grâce aux ID de la tâche et du fragment. KMS vérifie que le système de stockage est autorisé à utiliser la KEK associée au service et à désencapsuler la DEK concernée.
  5. KMS applique l'une des deux méthodes 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) Il 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, tels que les disques durs SSD locaux, dans lesquels la gestion et la protection de la DEK sont assurées au niveau de l'appareil.

Diagramme du déchiffrement des fragments de données

Figure 3 : Pour déchiffrer un fragment de données, le service de stockage appelle le service Key Management Service (KMS) de Google afin de récupérer la clé de chiffrement de données (DEK) désencapsulée correspondante.

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

Le service KMS de Google est protégé par une clé racine appelée clé principale KMS qui encapsule l'ensemble des KEK de KMS. Cette clé principale utilise l'algorithme AES2564 et est elle-même stockée dans un autre service de gestion des clés, nommé Root KMS, qui stocke un nombre bien moins élevé de clés (environ une douzaine). Pour plus de sécurité, Root KMS 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 KMS possède lui aussi sa propre clé racine, appelée clé principale Root KMS, qui utilise également l'algorithme AES2564. Elle est stockée dans une infrastructure poste à poste, le distributeur de clés principales Root KMS, qui réplique ces clés à l'échelle mondiale. Ce distributeur ne garde les clés en mémoire RAM que sur les machines dédiées sur lesquelles Root KMS est exécuté et vérifie que leur utilisation est appropriée au moyen de la journalisation. Une instance du distributeur de clés principales Root KMS est exécutée par instance de Root KMS. (Ce distributeur est déployé progressivement, afin de remplacer un système qui fonctionnait de manière similaire, mais n'était pas de type poste à poste.)

Lorsqu'une nouvelle instance du distributeur de clés principales Root KMS 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 KMS auprès de ces autres instances en cours d'exécution. Outre les mécanismes de reprise après sinistre décrits ci-après, la clé principale Root KMS n'existe que dans la mémoire RAM d'un nombre limité de machines spécialement sécurisées.

Si toutes les instances du distributeur de clés principales Root KMS venaient à redémarrer simultanément, sachez que la clé principale Root KMS serait également sauvegardée sur des appareils sécurisés stockés dans des coffres-forts physiques, au sein de zones hautement sécurisées situées dans deux locaux Google distincts dans le monde. Cette sauvegarde n'est nécessaire qu'en cas d'arrêt simultané de toutes les instances du distributeur, par exemple lors d'un redémarrage global. Moins de 20 employés de Google sont habilités à accéder à ces coffres-forts.

Diagramme de la hiérarchie de chiffrement de Google

Figure 4 : 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 KMS, lui-même protégé par Root KMS et le distributeur de clés principales Root KMS.

En résumé

  • 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 KMS.
  • KMS est exécuté sur plusieurs machines situées dans des centres de données du monde entier.
    • Les clés KMS sont encapsulées avec la clé principale KMS, qui est stockée dans Root KMS.
  • Root KMS est d'une taille bien inférieure à celle de KMS et n'est exécuté que sur des machines dédiées dans chaque centre de données.
    • Les clés Root KMS sont encapsulées avec la clé principale Root KMS, qui est stockée dans le distributeur de clés principales Root KMS.
  • Le distributeur de clés principales Root KMS est une infrastructure poste à poste qui est exécutée simultanément dans la mémoire RAM sur des machines dédiées du monde entier, chacune obtenant son matériel de clé d'autres instances en cours d'exécution.
    • Si toutes les instances du distributeur s'arrêtent (totalement), une clé principale est stockée dans du matériel sécurisé (différent), conservé à l'intérieur de coffres-forts (physiques) dans des locaux Google auxquels l'accès est limité.
    • Le distributeur de clés principales Root KMS est actuellement déployé afin de remplacer un système qui fonctionnait de manière similaire, mais n'était pas de type poste à poste.

Disponibilité mondiale et réplication

L'utilisation des services de gestion des clés dans Google dépend de caractéristiques essentielles à tous les niveaux, à savoir une haute disponibilité, une faible latence et un accès mondial aux clés.

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

Root KMS 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 KMS est lui aussi exécuté sur ces machines, parallèlement à Root KMS. Ce distributeur fournit un mécanisme de distribution via un protocole de bavardage. À intervalles fixes, chacune de ses instances choisit de manière aléatoire une autre instance avec laquelle comparer ses clés et élimine les différences entre les versions de clés. Avec ce modèle, l'infrastructure de Google ne dépend d'aucun nœud central. Cela permet à Google de gérer et de protéger le matériel de clé avec une haute disponibilité.

Bibliothèque de cryptographie commune de Google

Tink5 est la bibliothèque de cryptographie commune de Google et met en œuvre des algorithmes cryptographiques utilisant BoringSSL6. Tous les développeurs Google y ont accès. Grâce à la diffusion à grande échelle de cette bibliothèque, la mise en œuvre de ce code étroitement contrôlé et révisé est assurée de manière adéquate par seulement quelques spécialistes du chiffrement. Ainsi, toutes les équipes ne sont pas obligées de développer leur propre cryptographie. Une équipe de sécurité Google spéciale est 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.

Au moment de la publication du présent document, Google procède au chiffrement au repos des DEK et des KEK à l'aide des algorithmes indiqués ci-après. 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és7
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

Granularité du chiffrement dans chaque produit Google Cloud Platform

Chaque service Google Cloud Platform divise les données à un niveau de granularité différent pour le chiffrement.

  Service Google Cloud Platform Granularité du chiffrement des données client8 (taille des données chiffrées avec une seule DEK)
Stockage Cloud Bigtable Par fragment de données (plusieurs par table)
Cloud Datastore Par fragment de données9
Cloud Spanner Par fragment de données (plusieurs par table)
Cloud SQL
  • Deuxième génération : par instance, comme dans Google Compute Engine (chaque instance pourrait contenir plusieurs bases de données)
  • Première génération : par instance
Cloud Storage Par fragment de données (généralement de 256 Ko à 8 Mo)
Calcul App Engine10 Par fragment de données9
Cloud Functions11 Par fragment de données9
Compute Engine
  • Plusieurs par disque
  • Par groupe d'instantanés, avec des plages d'instantanés individuelles dérivées de la clé principale du groupe d'instantanés
  • Par image
Kubernetes Engine Plusieurs par disque, pour les disques persistants
Container Registry Stockage dans Google Cloud Storage, par fragment de données
Big data BigQuery Plusieurs par ensemble de données
Cloud Dataflow Stockage dans Google Cloud Storage, par fragment de données
Cloud Datalab Stockage dans Cloud Bigtable, par fichier notebook
Cloud Dataproc Stockage dans Google Cloud Storage, par fragment de données
Cloud Pub/Sub Par heure, pour un maximum de 1 000 000 de messages12

Options de chiffrement supplémentaires pour les clients Cloud

En plus de fournir un chiffrement par défaut dans Google Cloud Platform, nous travaillons également à mettre au point des options de chiffrement et de gestion des clés supplémentaires pour que nos clients bénéficient d'un meilleur contrôle.

Nous voulons que les clients de Google Cloud Platform puissent :

  • assurer la protection absolue de leurs données, et contrôler l'accès à ces données et leur utilisation au niveau de granularité le plus fin, afin d'en garantir la sécurité et la confidentialité ;
  • gérer le chiffrement de leurs données hébergées dans le cloud de la même manière qu'ils le font actuellement sur site ou, dans l'idéal, de façon plus efficace ;
  • disposer d'une racine de confiance vérifiable et contrôlable sur leurs ressources ;
  • séparer et isoler davantage leurs données, en plus d'utiliser des LCA.

Les clients peuvent utiliser les clés de chiffrement existantes, qu'ils gèrent avec Google Cloud Platform à l'aide de la fonctionnalité de clés de chiffrement fournie. Cette fonctionnalité est disponible pour Google Cloud Storage et pour Google Compute Engine à des fins de chiffrement de la couche de stockage.

Les clients ont également la possibilité de gérer leurs propres clés de chiffrement sur Google Cloud Platform à l'aide du service Google Cloud Key Management Service (Cloud KMS). Ce produit permet d'effectuer un chiffrement de la couche d'application géré par le client.

Recherche et innovation en matière de cryptographie

Pour rester en phase avec l'évolution du chiffrement, Google a réuni une équipe composée des meilleurs ingénieurs en sécurité, chargés de suivre, de développer et d'améliorer la technologie 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. Ainsi, en 2014, nous avons mis au jour une faille importante dans le chiffrement SSL 3.0 (connue sous le nom de POODLE) et, en 2015, nous avons identifié une faille à haut risque dans OpenSSL.

Google prévoit de rester le leader du marché du chiffrement pour les services cloud. En ce qui concerne le développement, la mise en œuvre et la recherche de nouvelles techniques de chiffrement, nos équipes travaillent actuellement dans les domaines suivants :

  • La cryptographie partiellement homomorphe, qui permet d'effectuer certaines opérations sur les données alors qu'elles sont chiffrées, de sorte que les données en texte brut ne sont jamais visibles dans le cloud, même en mémoire. Cette technologie est par exemple utilisée dans le cadre de notre client BigQuery chiffré expérimental, qui est disponible publiquement.
  • La cryptographie conservant le format et l'ordre, qui permet d'effectuer certaines opérations de comparaison et de classement sur des données chiffrées.
  • La cryptographie post-quantique, qui 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 contre de telles attaques. L'accent est principalement mis sur la recherche et le prototypage de la cryptographie à clé publique basée sur les réseaux, y compris les recommandations du NIST sur les algorithmes post-quantiques. Actuellement, la cryptographie basée sur les réseaux est considérée comme l'une des techniques de chiffrement les plus susceptibles d'être utilisées dans un monde post-quantique. Nous n'en sommes toutefois qu'aux prémices en matière de développement d'algorithmes optimaux, de paramètres concrets et de cryptanalyse en vue d'appliquer la cryptographie basée sur les réseaux. Bien que le chiffrement par clé symétrique et les MAC perdent du terrain face aux algorithmes quantiques connus, ils peuvent toujours être mis à niveau vers des éléments de sécurité similaires dans un monde post-quantique, ceci en doublant la taille des clés.

Autres références

La sécurité sur Google Cloud Platform

Des informations générales sur la sécurité dans Google Cloud Platform sont disponibles dans la section "Sécurité" du site Web de Google Cloud Platform.

La conformité sur Google Cloud Platform

Pour en savoir plus sur la conformité de Google Cloud Platform et les certifications de conformité, consultez la section Normes, réglementations et certifications du site Web de Google Cloud Platform. Vous y trouverez le rapport d'audit SOC3 public de Google.

La sécurité dans G Suite

Pour obtenir plus d'informations sur le chiffrement et la gestion des clés dans G Suite, consultez le livre blanc sur le chiffrement dans G Suite. Ce livre blanc couvre une grande partie du contenu abordé dans le présent document, mais seulement du point de vue de G Suite. Pour toutes les solutions G Suite, 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é. De plus amples informations sur la sécurité générale dans G Suite sont disponibles dans le livre blanc sur la sécurité et la conformité dans G Suite.

Notes de bas de page

1 Les fragments de données dans Cloud Datastore, App Engine et Cloud Pub/Sub peuvent contenir les données de deux clients. Consultez la section relative à la granularité du chiffrement des données par service.
2 Une image de base partagée dans Google Compute Engine est un exemple de ressource partagée (où cette séparation ne s'applique pas). Naturellement, plusieurs clients font référence à une seule copie, qui est chiffrée par une DEK unique.
3 À l'exception des données stockées dans Cloud Datastore, App Engine et Cloud Pub/Sub, où les données de plusieurs clients peuvent être chiffrées avec la même DEK. Consultez la section relative à la granularité du chiffrement des données par service.
4 Auparavant, le protocole utilisé était AES128, et certaines de ces clés sont toujours actives pour le déchiffrement des données.
5 Google utilise également deux bibliothèques : Keymaster et CrunchyCrypt. Keymaster partage le code de cryptographie le plus récent en commun avec Tink, mais met en œuvre différemment la gestion des versions de clés et accepte une plus grande variété d'anciens algorithmes. CrunchyCrypt est en train d'être fusionné avec Tink.
6 OpenSSL est également utilisé en certains points de Google Cloud Storage.
7 D'autres protocoles cryptographiques existent dans la bibliothèque et étaient traditionnellement acceptés, mais cette liste couvre les principales utilisations dans Google Cloud Platform.
8 Fait référence à la granularité du chiffrement pour les contenus client. Cela n'inclut pas les métadonnées client, telles que les noms de ressources. Dans certains services, l'ensemble des métadonnées est chiffré à l'aide d'une seule DEK.
9 Ceci n'est pas propre à un seul client.
10 Inclut le code et les paramètres de l'application. Les données utilisées dans App Engine sont stockées dans Cloud Datastore, Cloud SQL ou Cloud Storage selon la configuration du client.
11 Inclut le code de fonction, les paramètres et les données d'événement. Les données d'événement sont stockées dans Cloud Pub/Sub.
12 Cloud Pub/Sub effectue une rotation de la DEK employée pour chiffrer les messages toutes les heures, ou avant en cas de chiffrement de 1 000 000 de messages. Ceci n'est pas propre à un seul client.
Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…