Comprendre la gestion des clés de chiffrement dans Snowflake

Cette rubrique présente les concepts relatifs aux clés gérées par Snowflake, aux clés gérées par les clients et à Tri-Secret Secure.

Dans ce chapitre :

Vue d’ensemble

Snowflake gère les clés de chiffrement des données pour protéger les données des clients. Cette gestion se fait automatiquement, sans qu’aucune intervention du client ne soit nécessaire.

Les clients peuvent utiliser le service de gestion des clés dans la plateforme Cloud qui héberge leur compte Snowflake pour maintenir leur propre clé de chiffrement supplémentaire.

Lorsqu’elle est activée, la combinaison d’une clé gérée par Snowflake et d’une clé gérée par le client crée une clé master composite pour protéger les données Snowflake. C’est ce qu’on appelle le Tri-Secret Secure.

Clés gérées par Snowflake

Toutes les données des clients de Snowflake sont chiffrées par défaut en utilisant les dernières normes de sécurité et sur la base de pratiques recommandées. Snowflake utilise un puissant chiffrement AES 256 bits avec un modèle de clé hiérarchique intégré dans un module de sécurité matérielle.

Le service Snowflake effectue automatiquement une rotation régulière des clés, et les données peuvent être automatiquement de nouveau chiffrées régulièrement. Le chiffrement des données et la gestion des clés sont entièrement transparents et ne nécessitent aucune configuration ou gestion.

Modèle de clé hiérarchique

Un modèle de clé hiérarchique fournit une structure de gestion de clé de chiffrement de Snowflake. La hiérarchie est composée de plusieurs couches de clés dans lesquelles chaque couche de clés supérieure (clés parent) chiffre la couche inférieure (clés enfant). Dans le langage de la sécurité, une clé parent chiffrant l’ensemble des clés enfant est ce qu’on appelle un « wrapping ».

Le modèle de clé hiérarchique de Snowflake se compose de quatre niveaux de clé :

  • La clé racine.

  • Les clés de compte maîtresses.

  • Les clés de table maîtresses.

  • Les clés de fichier.

Chaque compte client possède une hiérarchie de clés distincte composée de clés de niveau compte, de niveau table et de niveau fichier, comme le montre l’image suivante :

Snowflake's hierarchical key model

Dans un service Cloud à plusieurs locataires comme Snowflake, le modèle de clé hiérarchique isole chaque compte à l’aide de clés master de compte séparées. Outre le modèle de contrôle d’accès qui sépare le stockage des données client, le modèle de clé hiérarchique fournit une autre couche d’isolation de compte.

Un modèle de clé hiérarchique réduit le périmètre de chaque couche de clés. Par exemple, une clé de table maîtresse chiffre une seule table. Une clé de fichier chiffre un seul fichier. Un modèle de clé hiérarchique limite la quantité de données que chaque clé protège, et la durée pendant laquelle elle est utilisable.

Rotation de clé de chiffrement

Les clés gérées par Snowflake font automatiquement l’objet d’une rotation par Snowflake lorsqu’elles ont plus de 30 jours. Les clés actives expirent, et de nouvelles clés sont créées. Lorsque Snowflake détermine que la clé retirée n’est plus nécessaire, la clé est automatiquement détruite. Lorsqu’elle est active, une clé est utilisée pour chiffrer des données et peut être utilisée par le client. Lorsqu’elle est retirée, la clé sert uniquement à déchiffrer les données et n’est disponible que pour accéder aux données.

Lors du « wrapping » des clés enfant dans la hiérarchie des clés ou lors de l’insertion de données dans une table, seule la clé active en cours est utilisée pour chiffrer les données. Lorsqu’une clé est détruite, elle n’est utilisée ni pour le chiffrement ni pour le déchiffrement. La rotation régulière des clés limite le cycle de vie des clés à une période de temps limitée.

L’image suivante illustre la rotation des clés pour une clé master de table (TMK) sur une période de trois mois :

Key rotation of one table master key (TMK) over a time period of three months.

La rotation TMK fonctionne comme suit :

  • La version 1 de la TMK est active en avril. Les données insérées dans cette table en avril sont protégées par TMK v1.

  • En mai, cette TMK fait l’objet d’une rotation : TMK V1 expire et une nouvelle clé complètement aléatoire, TMK v2, est créée. TMK v1 est maintenant utilisée uniquement pour déchiffrer les données du mois d’avril. Les nouvelles données insérées dans la table sont chiffrées à l’aide de TMK v2.

  • En juin, la TMK fait de nouveau l’objet d’une rotation : TMK V2 expire et une nouvelle TMK, v3, est créée. TMK v1 est utilisée pour déchiffrer les données d’avril, TMK v2 est utilisée pour déchiffrer les données de mai et TMK v3 est utilisée pour chiffrer et déchiffrer les nouvelles données insérées dans la table en juin.

Comme indiqué précédemment, la rotation de la clé limite la durée pendant laquelle une clé est activement utilisée pour chiffrer des données. En conjonction avec le modèle de clé hiérarchique, la rotation de la clé limite davantage la quantité de données qu’une version de clé protège. La limitation de la durée de vie d’une clé est recommandée par le National Institute of Standards and Technology (NIST) afin de renforcer la sécurité.

Resaisie périodique

Cette section poursuit l’explication du cycle de vie de la clé de compte et de table master. Rotation de clé de chiffrement décrit la rotation de clé, qui remplace périodiquement les clés actives par de nouvelles clés et retire les anciennes clés. La re-saisie périodique des données complète le cycle de vie.

Tandis que la rotation de clé garantit qu’une clé est transférée de son état actif à un état retiré, la re-saisie garantit qu’une clé est transférée de son état retiré à un état détruit.

Si la re-saisie périodique est activée, alors lorsque la clé de chiffrement retirée d’une table date de plus d’un an, Snowflake crée automatiquement une nouvelle clé de chiffrement et chiffre à nouveau toutes les données précédemment protégées par la clé retirée en utilisant la nouvelle clé. La nouvelle clé est utilisée pour déchiffrer ultérieurement les données de la table.

Note

Pour les comptes Enterprise Edition, les utilisateurs ayant le rôle ACCOUNTADMIN (c’est-à-dire vos administrateurs de compte) peuvent activer la re-saisie en utilisant ALTER ACCOUNT et le paramètre PERIODIC_DATA_REKEYING :

ALTER ACCOUNT SET PERIODIC_DATA_REKEYING = true;

L’image suivante illustre la re-saisie périodique pour un TMK pour une seule table :

Rekeying one table master key (TMK) after one year

La re-saisie périodique fonctionne comme suit :

  • En avril de l’année suivante, après que TMK v1 a été retirée pendant une année entière, elle est re-saisie (génération 2) en utilisant une clé aléatoire entièrement nouvelle.

    Les fichiers de données protégés par TMK v1 génération 1 sont déchiffrés et à nouveau chiffrés avec TMK v1 génération 2. N’ayant plus d’autre utilité, TMK v1 génération 1 est détruite.

  • En mai, Snowflake effectue le même processus de re-saisie sur les données de table protégées par TMK v2.

  • Et ainsi de suite.

Dans cet exemple, le cycle de vie d’une clé est limité à une durée totale d’un an.

La nouvelle saisie limite la durée totale d’utilisation d’une clé par le destinataire, selon les recommandations du NIST. De plus, lorsque vous re-saisissez des données, Snowflake peut augmenter la taille des clés de chiffrement et utiliser de meilleurs algorithmes de chiffrement qui peuvent avoir été normalisés depuis la création de la génération de clés précédente.

La re-saisie garantit donc que toutes les données des clients, nouvelles et anciennes, sont chiffrées à l’aide des dernières technologies de sécurité.

Snowflake re-saisit les fichiers de données en ligne, en arrière-plan, sans aucun impact sur les charges de travail client en cours d’exécution. Les données en cours de re-saisie sont toujours à votre disposition. Aucun temps d’arrêt de service n’est nécessaire pour re-saisir des données, et il n’y a aucune conséquence sur la performance de vos opérations. Cet avantage est le résultat direct de l’architecture de Snowflake qui sépare les ressources de stockage et de calcul.

Conséquences de la re-saisie sur Time Travel et Fail-safe

Les périodes de conservation Time Travel et Fail-safe ne sont pas touchées par la re-saisie. La re-saisie est transparente pour les deux fonctions. Toutefois, certains frais de stockage supplémentaires sont associés à la re-saisie de nouvelles données en mode Fail-safe (voir section suivante).

Conséquences de la re-saisie sur l’utilisation de stockage

Les clients Snowflake se voient facturer du stockage supplémentaire pour la protection Fail-safe des fichiers de données qui ont été re-saisis. Pour ces fichiers, 7 jours de protection Fail-safe sont facturés.

C’est-à-dire, par exemple, que les fichiers de données avec l’ancienne clé sur Amazon S3 sont déjà protégés par Fail-safe, et les fichiers de données avec la nouvelle clé sur Amazon S3 sont également ajoutés à Fail-safe, ce qui entraîne une deuxième facturation, mais seulement pour la période de 7 jours.

Module de sécurité matérielle

Snowflake s’appuie sur l’un des nombreux services de module de sécurité matérielle Cloud (HSM) pour générer, stocker et utiliser les clés racine de la hiérarchie de clés de manière hautement sécurisée et inviolable. L’utilisation d’un HSM offre les avantages de sécurité suivants :

  • Le HSM est conçu pour que les clés ne quittent jamais le HSM et pour que toutes les opérations de chiffrement soient effectuées à l’intérieur du HSM.

  • Toutes les clés de la hiérarchie des clés nécessitent HSM pour être déballées.

  • En plus de générer de nouvelles clés de chiffrement lors de la création de nouveaux comptes et tables, le HSM génère des clés de chiffrement aléatoires et sécurisées lors de la rotation et de la re-saisie des clés.

    Notez que ce comportement est vrai pour AWS et Microsoft Azure, mais pas pour Google Cloud Platform.

Snowflake utilise la configuration haute disponibilité HSM avec sauvegarde pour réduire la possibilité de pannes de services en raison de l’indisponibilité des clés de chiffrement, et pour ne pas perdre les clés les plus importantes dans la hiérarchie.

L’image suivante montre la relation entre le HSM, les clés master de compte, les clés master de table et les clés de fichier :

Key hierarchy rooted in Hardware Security Module

Clés gérées par le client

Une clé gérée par le client est une clé de chiffrement master que le client conserve dans le service de gestion des clés du fournisseur de services Cloud qui héberge votre compte Snowflake. Les services de gestion des clés pour chaque plate-forme sont les suivants :

La clé gérée par le client peut ensuite être combinée avec une clé gérée par Snowflake pour créer une clé master composite. Lorsque cela se produit, Snowflake parle de Tri-Secret Secure. (dans cette rubrique).

Important

Snowflake ne prend pas en charge la rotation des clés pour les clés gérées par le client et ne recommande pas la mise en œuvre d’une politique de rotation automatique des clés sur la clé gérée par le client.

La raison de cette recommandation est que la rotation des clés peut entraîner une perte de données si la clé tournée est supprimée, car Snowflake ne sera pas en mesure de déchiffrer les données. Pour plus d’informations, voir Tri-Secret Secure (dans ce chapitre).

Avantages des clés gérées par le client

Les avantages des clés gérées par le client incluent :

Contrôle de l’accès aux données

Vous avez un contrôle total sur votre clé master dans le service de gestion de clés et, par conséquent, sur vos données dans Snowflake. Il est impossible de déchiffrer les données stockées dans votre compte Snowflake sans libérer cette clé.

Désactiver l’accès en raison d’une violation des données

Si vous subissez une atteinte à la sécurité, vous pouvez désactiver l’accès à votre clé et arrêter toutes les opérations de données en cours dans votre compte Snowflake.

Propriété du cycle de vie des données

À l’aide de clés gérées par le client, vous pouvez aligner vos exigences en matière de protection des données sur vos processus métier. Le contrôle explicite de votre clé offre des garanties tout au long du cycle de vie des données, de leur création à leur suppression.

Exigences importantes pour les clés gérées par le client

Les clés gérées par le client offrent d’importants avantages sur le plan de la sécurité, mais elles ont aussi des exigences fondamentales et cruciales que vous devez respecter en permanence pour protéger votre clé maîtresse :

Confidentialité

Vous devez garder votre clé sécurisée et confidentielle en tout temps.

Intégrité

Vous devez vous assurer que votre clé est protégée contre toute modification ou suppression inappropriée.

Disponibilité

Pour exécuter des requêtes et accéder à vos données, vous devez vous assurer que votre clé est accessible en permanence par Snowflake.

De par sa conception, une clé invalide ou non disponible entraînera une interruption de vos opérations de données Snowflake jusqu’à ce qu’une clé valide soit de nouveau disponible pour Snowflake.

Cependant, Snowflake est conçu pour traiter les problèmes de disponibilité temporaire (jusqu’à 10 minutes) causés par des problèmes courants, tels que les pannes de communication réseau. Après 10 minutes, si la clé reste indisponible, toutes les opérations de données dans votre compte Snowflake cessent complètement. Une fois l’accès à la clé restauré, les opérations de données peuvent être relancées.

Le non-respect de ces exigences peut compromettre considérablement l’intégrité de vos données, de l’inaccessibilité temporaire de vos données jusqu’à leur désactivation permanente. De plus, Snowflake ne peut être tenu responsable des problèmes tiers qui surviennent ou des incidents administratifs causés par votre organisation dans le cadre de l’entretien de votre clé.

Par exemple, si un problème avec le service de gestion de clés entraîne l’indisponibilité de votre clé, vos opérations de données seront affectées. Ces problèmes doivent être résolus entre vous et l’équipe de support du service de gestion de clés. De même, si votre clé est modifiée ou détruite, toutes les données existantes dans votre compte Snowflake deviendront illisibles jusqu’à ce que la clé soit restaurée.

Tri-Secret Secure

Tri-Secret Secure est la combinaison d’une clé maintenue par Snowflake et d’une clé gérée par le client dans la plateforme du fournisseur Cloud qui héberge votre compte Snowflake afin de créer une clé master composite pour protéger vos données Snowflake. La clé master composite fait office de clé master de compte et englobe toutes les clés de la hiérarchie ; toutefois, la clé master composite ne chiffre jamais les données brutes.

Si la clé gérée par le client dans la hiérarchie des clés master composites est révoquée, vos données ne peuvent plus être déchiffrées par Snowflake, offrant ainsi un niveau de sécurité et de contrôle supérieur au chiffrement standard de Snowflake. Ce modèle de chiffrement à double clé, associé à l’authentification utilisateur intégrée de Snowflake, permet les trois niveaux de protection des données offerts par Tri-Secret Secure.

Attention

Avant de vous engager avec Snowflake pour activer Tri-Secret Secure pour votre compte, nous vous conseillons d’évaluer votre responsabilité concernant la gestion de votre clé, comme mentionné dans la section Clés gérées par le client (dans cette rubrique). Si vous avez des questions ou des doutes, nous serons heureux d’en discuter avec vous.

Notez que Snowflake assume également la même responsabilité pour les clés que nous gérons. Comme pour tous les aspects liés à la sécurité de notre service, nous traitons cette responsabilité avec le plus grand soin et la plus grande vigilance.

Toutes nos clés sont gérées selon des politiques strictes qui nous ont permis d’obtenir les accréditations de sécurité les plus élevées, y compris SOC type 2 II, PCI-DSS, HIPAA et HITRUST CSF.

Activation de Tri-Secret Secure

Pour activer Snowflake Tri-Secret Secure pour votre compte Business Critical (ou supérieur), veuillez contacter le support Snowflake.

Revenir au début