Chiffrement des données avec des clés gérées par le client

Chiffrement des données avec des clés gérées par le client


La sécurité des données clients est la première priorité de Snowflake. Toutes les données des clients sont cryptées à l’aide de techniques standard de l’industrie telles que AES-256. Les clés de chiffrement sont organisées de manière hiérarchique, enracinées dans un module de sécurité matériel (HSM). Cela permet une isolation complète des données clients et réduit considérablement les vecteurs d’attaque.

Pour les clients ayant les exigences de sécurité les plus élevées, nous ajoutons un autre composant de sécurité : les clés gérées par le client. Avec les clés gérées par le client, le client gère la clé de chiffrement et la met à la disposition de Snowflake. Le client a le plein contrôle sur cette clé. Si le client désactive l’accès à la clé de chiffrement, Snowflake ne peut plus accéder aux données du client. Vos données. Vos clés de chiffrement.

Dans cet article de blog, nous expliquerons les avantages des clés gérées par le client et leur mise en œuvre dans l’entrepôt de données cloud Snowflake.

Avantages

Les clés gérées par le client offrent les avantages suivants :

Plus de contrôle sur l’accès aux données : Les clés gérées par le client empêchent Snowflake de se conformer aux demandes d’accès aux données client. Si les données sont chiffrées à l’aide de clés gérées par le client et que le client désactive l’accès à la clé de chiffrement, il est techniquement impossible pour Snowflake de déchiffrer les données. Il appartient donc au client de se conformer directement à ces demandes.

Arrêtez les violations de données : Si un client subit une violation de données, il peut désactiver l’accès des clés gérées par le client à Snowflake. Cela arrêtera toutes les requêtes en cours d’exécution dans Snowflake, y compris les requêtes susceptibles d’inspecter des données ou de décharger des données. La désactivation des clés gérées par le client permet aux clients d’arrêter l’exfiltration continue de leurs données.

Plus de contrôle sur le cycle de vie des données : La dernière raison pour laquelle les clients ont besoin de cette fonctionnalité est le manque de confiance avec un fournisseur de cloud. Les clients peuvent avoir des données sensibles qu’ils ne font pas confiance à Snowflake pour gérer eux-mêmes. À l’aide de clés gérées par le client, ces données sensibles sont finalement chiffrées avec la clé du client. Il est impossible pour Snowflake de décrypter ces données sans le consentement du client. Le client a un contrôle total sur le cycle de vie des données.

Mise en œuvre

Avant d’expliquer la mise en œuvre des clés gérées par le client, nous devons d’abord donner un aperçu de la hiérarchie des clés de Snowflake et du service de gestion des clés d’Amazon.

Contexte 1 : Hiérarchie des clés de Snowflake

Snowflake gère les clés de chiffrement de manière hiérarchique. Dans cette hiérarchie de clés, une clé parent crypte toutes ses clés enfants. Lorsqu’une clé chiffre une autre clé, cela s’appelle « wrapping ». Lorsque la clé est à nouveau déchiffrée, cela s’appelle « unwrapping ».

Hiérarchie des clés de chiffrement - Snowflake

Figure 1 : Hiérarchie des clés de chiffrement dans Snowflake.

La figure 1 montre la hiérarchie des clés de chiffrement de Snowflake. Les clés racine les plus hautes sont stockées dans un module de sécurité matériel (ou CloudHSM). Une clé racine encapsule les clés principales du compte. Chaque clé principale de compte correspond à un compte client dans Snowflake. Les clés principales de compte, à leur tour, encapsulent toutes les clés au niveau des données, y compris les clés principales de table, les clés principales d’étape et les clés principales de résultat. De plus, chaque fichier de données est crypté avec une clé distincte. Un aperçu détaillé de la gestion des clés de chiffrement de Snowflake est fourni dans cet article de blog.

Contexte 2 : Service de gestion des clés AWS

AWS Key Management Service (KMS) d’Amazon est un service permettant de stocker les clés de chiffrement et d’en contrôler étroitement l’accès. Amazon fournit un journal d’audit de toutes les opérations et interactions avec KMS à l’aide de CloudTrail. Cela permet aux clients de gérer leurs propres clés de chiffrement et de valider leur utilisation via le journal d’audit. KMS permet également aux clients de désactiver l’accès à toutes les clés à tout moment. La combinaison de KMS avec la hiérarchie des clés de chiffrement de Snowflake nous permet de mettre en œuvre des clés gérées par le client. Vous trouverez plus de détails sur AWS KMS sur le Site web d’Amazon.

Mise en œuvre des clés gérées par le client

La mise en œuvre des clés gérées par le client modifie la manière dont les clés principales de compte (AMK) sont stockées dans la hiérarchie des clés de chiffrement de Snowflake. Normalement, comme le montre la figure 1 ci-dessus, un AMK est encapsulé par la clé racine stockée dans CloudHSM. Pour les clés gérées par le client, cela n’est que partiellement vrai. Deux AMK sont impliqués : une première clé est encapsulée par la clé racine stockée dans le CloudHSM et une seconde clé est encapsulée par la clé client dans KMS. Le déballage et la combinaison de ces deux clés conduisent à la clé principale de compte composée, qui encapsule et déballe ensuite toutes les clés sous-jacentes dans la hiérarchie (clés principales de table, clés principales de résultat, etc.).

Clé principale de compte - Clés gérées par le client

Figure 2 : Clé principale de compte composée de AMK-S et AMK-C. AMK-C est enveloppé par KMS.

La figure 2 montre ce concept en détail. Avec les clés gérées par le client, l’AMK est composé de deux clés : AMK-S et AMK-C. AMK-S est une clé aléatoire de 256 bits qui est enveloppée avec la clé racine stockée dans HSM. AMK-C est une deuxième clé aléatoire de 256 bits qui est enveloppée avec la clé client stockée dans KMS. AMK-S et AMK-C sont complètement aléatoires et sans rapport. Les deux clés encapsulées sont stockées dans la hiérarchie des clés de chiffrement de Snowflake.

Encrypted keys blog

Figure 3 : Déballage et composition d’AMK.

Lorsque le client exécute une requête dans Snowflake qui nécessite l’accès aux données client, l’AMK composée est produite comme suit (voir Figure 3). Les deux clés enveloppées, AMK-S et AMK-C, sont extraites de la hiérarchie des clés de chiffrement. AMK-S est déballé à l’aide de la clé racine dans HSM. AMK-C est déballé à l’aide de la clé client dans KMS. Le journal d’audit KMS enregistre un événement d’accès à la clé client. Les deux clés non emballées sont combinées pour former l’AMK composé. L’AMK composée est ensuite utilisée pour déballer les clés principales de la table sous-jacente afin d’accéder aux données client.

L’AMK composé est mis en cache dans l’entrepôt de données Snowflake pour des raisons de performances. Ce cache a un délai d’expiration après lequel l’AMK mis en cache n’est plus accessible. Le cache est actualisé en arrière-plan de sorte que les requêtes continues ne soient pas affectées par une latence vers KMS. Si l’accès au KMS est révoqué, l’actualisation du cache échoue et l’AMK est immédiatement supprimé du cache. Toutes les requêtes en cours sont abandonnées. Les nouvelles requêtes ne démarrent pas car aucun AMK ne peut être composé. Les données du client ne peuvent plus être déchiffrées par le service Snowflake.

Sommaire

Les clés gérées par le client offrent un niveau de sécurité supplémentaire aux clients disposant de données sensibles. Avec cette fonctionnalité, le client gère lui-même la clé de chiffrement et la rend accessible à Snowflake. Si le client décide de désactiver l’accès, les données ne peuvent plus être déchiffrées. De plus, toutes les requêtes en cours sont abandonnées. Cela présente les avantages suivants pour les clients : (a) il est techniquement impossible pour Snowflake de se conformer aux demandes d’accès aux données client, (b) le client peut activement atténuer les violations de données et limiter l’exfiltration de données, et (c) cela donne au contrôle total du client sur le cycle de vie des données.

Disponibilité

Les clés gérées par le client sont un composant principal de Tri-Secret Secure, une fonctionnalité de l’édition Business Critical. Pour activer Tri-Secret Secure pour votre compte ESD, vous devez d’abord créer une clé dans AWS KMS (dans votre compte AWS), puis contacter Prise en charge des flocons de neige.

Remerciements

Nous tenons à remercier Difei Zhang pour sa contribution à ce projet.

Pour plus d’informations, n’hésitez pas à nous contacter au : [email protected] Nous serions ravis de vous aider dans votre voyage vers le cloud. Et gardez un œil sur ce blog ou suivez-nous sur Twitter (@flocondeneige) pour suivre toutes les actualités et tous les développements chez Snowflake Computing.

Laisser un commentaire

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