Gestion des clés de chiffrement dans l’entrepôt de données Snowflake

Gestion des clés de chiffrement dans l’entrepôt de données Snowflake

Le chiffrement des données est l’un des piliers des offres de services dans le cloud. Les clients exigent, et parfois exigent, que leurs données soient entièrement cryptées à l’aide des dernières normes de sécurité. Chez Snowflake, toutes les données client de notre service d’entrepôt de données en nuage est crypté par défaut, en utilisant les dernières normes de sécurité et les meilleures pratiques, sans frais supplémentaires. Dans cet article de blog, nous approfondissons un domaine des pratiques de sécurité de l’entrepôt de données de Snowflake : la gestion des clés de chiffrement au sein du Cadre de sécurité Snowflake.

Comprendre comment les données sont chiffrées dans un entrepôt de données permet aux clients de mieux évaluer différents produits et d’établir la confiance entre le client et le fournisseur d’entrepôt de données. Comme indiqué dans notre livre blanc sur la sécuritéSnowflake utilise un cryptage AES 256 bits puissant avec un modèle de clé hiérarchique enraciné dans AWS CloudHSM. Les clés font l’objet d’une rotation automatique et régulière par le service Snowflake, et les données peuvent être automatiquement rechiffrées (« rekeyed ») de manière régulière. Le chiffrement des données et la gestion des clés sont entièrement transparents pour le client et ne nécessitent aucune configuration ni gestion.

Pour mieux comprendre comment l’entrepôt de données Snowflake chiffre les données client, nous expliquons en détail trois aspects importants de la gestion des clés de chiffrement de Snowflake :

  1. Modèle de clé hiérarchique
  2. Rotation des clés
  3. ressaisie

Nous conclurons en montrant comment AWS CloudHSM s’intègre dans ce tableau et pourquoi il complète la gestion des clés de chiffrement de Snowflake.

Modèle de clé hiérarchique

Un modèle de clé hiérarchique est la pierre angulaire de la gestion des clés de chiffrement de Snowflake. Une hiérarchie de clés comporte plusieurs couches de clés où chaque couche de clés (les clés parentes) crypte la couche inférieure (les clés enfants). Lorsqu’une clé crypte une autre clé, les experts en sécurité l’appellent « wrapping ». En d’autres termes, une clé parent dans une hiérarchie de clés encapsule toutes ses clés enfants.

clés1
Figure 1 : Modèle de clé hiérarchique de Snowflake.

Le modèle de clé hiérarchique de Snowflake se compose de quatre niveaux de clés : la clé racine, les clés principales de compte, les clés principales de table et les clés de fichier (Figure 1). Chaque clé principale de compte correspond à un compte client dans Snowflake. Chaque clé principale de table correspond à une table de base de données dans une base de données. Cela signifie que chaque compte et chaque table sont chiffrés avec une clé distincte. De même, chaque fichier de données est chiffré avec une clé distincte.

Un modèle de clé hiérarchique offre plus de sécurité aux clients dans un service cloud mutualisé. Avec un tel modèle, tous les comptes clients sont isolés les uns des autres car chaque compte possède une clé principale de compte distincte. Nous avons conçu ce modèle explicitement pour isoler les comptes clients dans notre entrepôt de données multi-tenant. Notez que cette couche d’isolation est utilisée en plus de la couche de contrôle d’accès, qui sépare et isole le stockage des données client chez Snowflake.

Les modèles de clés hiérarchiques sont une bonne pratique en général car chaque couche de clés réduit la portée de leur applicabilité. Par exemple, les clés principales de table réduisent la portée de leur applicabilité à des tables uniques ; les clés de fichier réduisent davantage la portée de l’applicabilité aux fichiers uniques. Ainsi, un modèle de clé hiérarchique est essentiel pour limiter la quantité de données que chaque clé protège et la durée pendant laquelle elle est utilisable (voir la section suivante).

Rotation des clés de chiffrement

Les clés de chiffrement passent par différents états au cours de leur cycle de la vie. Dans l’état actif, la clé est utilisée pour chiffrer les données ; il est disponible pour être utilisé par l’expéditeur. Dans l’état retiré, la clé n’est utilisée que pour déchiffrer les données ; il est disponible pour une utilisation par le destinataire. Lorsqu’une clé est détruite, elle n’est utilisée ni pour le chiffrement ni pour le déchiffrement. La rotation des clés garantit que les clés passent de l’état actif à l’état retiré dans ce cycle de vie pendant une période de temps limitée.

La rotation des clés crée de nouvelles versions des clés de niveau supérieur à intervalles réguliers. Après un intervalle de temps spécifique, une nouvelle version d’une clé est créée et la version précédente de cette clé est retirée. La nouvelle version de la clé est utilisée pour chiffrer les données. La version précédente de la clé est retirée et n’est utilisée que pour déchiffrer les données. Lors de l’encapsulation des clés enfants dans la hiérarchie des clés ou lors de l’insertion de données dans une table, seule la clé active actuelle est utilisée pour chiffrer les données. En d’autres termes, avec la rotation des clés, « les nouvelles données obtiennent de nouvelles clés ».

clé2
Figure 2 : Rotation de clé d’une clé principale de table (TMK) sur une période de trois mois.

La figure 2 illustre la rotation des clés d’une clé principale de table (TMK). Une clé principale de table protège une seule table dans l’entrepôt de données Snowflake. Dans la figure 2, le TMK avec la version 1 est actif en avril. Les données insérées dans cette table en avril sont protégées par cette TMK v1. En mai, TMK v1 est mis en rotation : TMK v1 est retiré et un nouveau TMK v2 est créé, une clé aléatoire entièrement nouvelle. La version 1 n’est désormais utilisée que pour déchiffrer les données d’avril. Les nouvelles données insérées dans la table sont chiffrées à l’aide de TMK v2. En juin, TMK v2 est mis en rotation : TMK v2 est retiré et un nouveau TMK v3 est créé. TMK v1 est utilisé pour déchiffrer les données d’avril, TMK v2 est utilisé pour déchiffrer les données de mai et TMK v3 est utilisé lors du chiffrement de nouvelles données.

L’avantage de la rotation des clés est de limiter la durée pendant laquelle une clé est activement utilisée pour chiffrer les données. En plus du modèle de clé hiérarchique, cela limite davantage la quantité de données qu’une clé protège. Limiter la durée de vie d’une clé est un Pratique recommandée par le NIST pour améliorer la sécurité.

ressaisie

La reconfiguration est une fonctionnalité de sécurité supplémentaire fournie par Snowflake. Le rekeying est le processus de rechiffrement des données avec de nouvelles clés. Après un intervalle de temps spécifique, les données chiffrées avec une ancienne clé sont à nouveau chiffrées avec une nouvelle clé. Ceci est indépendant et complètement orthogonal à la rotation des clés. Alors que la rotation des clés garantit qu’une clé est transférée de son état actif (utilisation de l’expéditeur) à l’état retiré (utilisation du destinataire), la recréation garantit qu’une clé est transférée de son état retiré à sa destruction. Autrement dit:

  • Rotation des clés = « les nouvelles données obtiennent de nouvelles clés »
  • Rekeying = « les anciennes données obtiennent de nouvelles clés »

Le renouvellement des clés complète donc le cycle de vie des clés en garantissant que les clés peuvent être détruites.

clé3
Figure 3 : Re-saisie d’une clé principale de table (TMK) après un an.

La figure 3 illustre la ressaisie en combinaison avec la rotation des clés. Le TMK dans cette figure est tourné chaque mois, comme expliqué dans la section précédente. De plus, le TMK de la figure 3 est réinitialisé après un an. C’est-à-dire qu’en avril 2015, TMK v1 est réinitialisé. Une nouvelle génération 2 de TMK v1 est créée, une toute nouvelle clé aléatoire. Les fichiers de données protégés par TMK v1, génération 1 sont déchiffrés et chiffrés avec TMK v1, génération 2. Étant donné que tous les fichiers de données sont désormais protégés par une nouvelle TMK, l’ancienne TMK v1, génération 1 peut être détruite ; il n’est plus utilisé. Dans cet exemple, le cycle de vie d’une clé est limité à une durée totale d’un an.

L’avantage de la ressaisie est qu’elle limite la durée totale pendant laquelle une clé est utilisée par le destinataire. Ceci, encore une fois, augmente la sécurité comme recommandé par le NIST. De plus, lors de la ressaisie des données, il est possible d’augmenter la taille des clés de cryptage et d’utiliser de meilleurs algorithmes de cryptage qui pourraient être inventés et normalisés à l’avenir. La reconfiguration garantit donc que toutes les données client, nouvelles et anciennes, sont cryptées avec les dernières technologies de sécurité.

La capacité unique de Snowflake permet de ressaisir les fichiers de données en ligne, en arrière-plan, sans aucun impact sur les charges de travail des clients en cours d’exécution. Les données qui sont ressaisies sont toujours disponibles pour le client. Aucun temps d’arrêt du service n’est nécessaire pour ressaisir les données et aucun impact sur les performances n’est observé sur la charge de travail du client. Il s’agit d’une fonctionnalité unique du service Snowflake et d’un résultat direct de l’architecture de Snowflake consistant à séparer les ressources de stockage et de calcul.

Amazon CloudHSM

Pour compléter la gestion des clés de chiffrement de Snowflake, nous utilisons AWS CloudHSM (modules de sécurité matérielle en ligne) comme moyen inviolable et hautement sécurisé de générer, stocker et utiliser les clés racine de la hiérarchie des clés (Figure 4). L’utilisation de CloudHSM offre les avantages de sécurité suivants :

  • Les clés les plus hautes de la hiérarchie des clés ne quittent jamais le HSM. Toutes les opérations cryptographiques sont effectuées dans les modules de sécurité eux-mêmes.
  • Les clés de niveau inférieur encapsulées dans la hiérarchie des clés ne peuvent pas être désencapsulées sans un accès autorisé aux appareils HSM.
  • Enfin, en plus de générer de nouvelles clés de chiffrement lors de la création de nouveaux comptes et de nouvelles tables, CloudHSM génère des clés de chiffrement sécurisées et aléatoires lors de la rotation et de la ressaisie des clés.

Nous utilisons la configuration haute disponibilité de CloudHSM avec un périphérique de sauvegarde hors ligne supplémentaire pour réduire la possibilité d’interruptions de service et être à l’abri de perdre les clés les plus importantes de la hiérarchie.

clé4
Figure 4 : Hiérarchie des clés enracinée dans Amazon CloudHSM.

Sécurité des données – en tant que service

Ces composants de gestion et d’utilisation des clés de chiffrement ne constituent qu’une partie d’une stratégie de sécurité globale. Si vous deviez gérer vous-même tous les différents composants et processus, ce serait un fardeau important pour votre équipe déjà surchargée.

Chez Snowflake, nous avons adopté l’approche consistant à mettre en œuvre et à maintenir une gamme complète de fonctionnalités et de contrôles de sécurité dans le cadre de notre service d’entreposage de données. Nos clients peuvent être assurés que leurs données sont sécurisées en utilisant les meilleures approches pour le cryptage des données, la gestion des clés, l’authentification, le contrôle d’accès, etc.

Comme nous l’avons détaillé ci-dessus, Snowflake fournit la meilleure gestion des clés de sa catégorie dans le cadre de notre service – un modèle de clé hiérarchique enraciné dans AWS CloudHSM, une rotation automatique des clés et même une nouvelle clé. Tout cela est entièrement transparent pour le client et ne nécessite aucune configuration, gestion ou temps d’arrêt. C’est la sécurité des données en tant que service.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.