Comprendre la gestion des clés de chiffrement dans Snowflake¶

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 :

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 :

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é.

Periodic Rekeying¶

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.

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

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.

Module de sécurité matérielle¶

Snowflake s’appuie sur des HSMs (Hardware Security Module) hébergés dans le Cloud pour garantir la sécurité du stockage et de l’utilisation des clés. Chaque plateforme Cloud a des services HSM différents. Cela affecte la façon dont Snowflake utilise le service HSM sur chaque plateforme :

• Sur AWS et Azure, Snowflake utilise le HSM pour créer et stocker la clé racine.

• Sur Google Cloud, le service HSM est mis à disposition par l’intermédiaire de l’API Cloud KMS (Key Management Service) de Google. Snowflake utilise Cloud KMS de Google pour créer et stocker la clé racine dans des partitions HSM à plusieurs locataires.

Pour toutes les plateformes dans le Cloud et toutes les clés dans la hiérarchie des clés, une clé qui est stockée dans le HSM est utilisée pour désencapsuler une clé dans la hiérarchie. Par exemple, pour déchiffrer la clé principale de la table, la clé du HSM désencapsule la clé principale du compte. Ce processus se déroule dans leHSM. À l’issue de ce processus, une opération logicielle permet de déchiffrer la clé maître de la table avec la clé maître du compte.

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 :

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.

Activation de Tri-Secret Secure¶

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