Chiffrement des données

La protection des données des clients est l’une des priorités numéro une de Snowflake. Par défaut, Snowflake chiffre l’ensemble des données des clients à l’aide des dernières normes de sécurité, et ce sans frais supplémentaires. Snowflake offre la gestion de clés la plus aboutie de sa catégorie, et celle-ci est entièrement transparente pour les clients. Cela fait de Snowflake l’un des entrepôts de données les plus faciles à utiliser et les plus sécurisés.

Dans ce chapitre :

Chiffrement de bout en bout

Le chiffrement de bout en bout (E2EE) est une forme de communication dans laquelle personne d’autre que l’utilisateur final ne peut lire les données. Dans Snowflake, cela signifie que seuls un client et les composants d’exécution peuvent lire les données. Aucune tierce partie, y compris la plateforme Cloud de Snowflake ou tout ISP, ne peut voir les données en clair.

E2EE minimise la surface d’attaque. En cas de faille de sécurité au niveau de la plateforme Cloud, les données sont protégées car elles sont chiffrées en permanence, que la faille expose indirectement les identifiants d’accès ou directement les fichiers de données, que ce soit par un pirate interne ou externe.

E2EE in Snowflake

La figure illustre le système E2EE dans Snowflake. Le système comprend les composants suivants :

  • Le client Snowflake dans un réseau d’entreprise.

  • Une zone de préparation de fichier de données.

  • Snowflake exécuté dans un Cloud privé virtuel sécurisé (VPC).

Snowflake prend en charge les zones de préparation internes et externes des fichiers de données. Snowflake fournit des zones de préparation internes où vous pouvez télécharger et regrouper vos fichiers de données avant de charger les données dans des tables (option B). Les zones de préparation fournies par le client sont des conteneurs ou des répertoires dans une plateforme de stockage Cloud prise en charge (c-à-d. Amazon S3) que vous possédez et gérez (option A). Les zones de préparation fournies par le client sont une option intéressante pour les clients qui possèdent déjà des données stockées sur ces plateformes et qu’ils souhaitent copier vers Snowflake. Snowflake prend en charge E2EE pour les deux types de zones de préparation.

Snowflake fonctionne dans un seul VPC sécurisé sur la plateforme Cloud.

Le débit de E2EE dans Snowflake est le suivant (voir la figure dans cette section) :

  1. Un utilisateur télécharge un ou plusieurs fichiers de données vers une zone de préparation. Si la zone de préparation est un conteneur géré par le client dans un service de stockage Cloud (option A), l’utilisateur peut chiffrer les fichiers de données en utilisant le chiffrement côté client (voir Chiffrement côté client pour plus d’informations). Nous recommandons le chiffrement côté client pour les fichiers de données préparés à l’extérieur de Snowflake. Mais si les données ne sont pas chiffrées, Snowflake chiffre immédiatement les données lorsqu’elles sont chargées vers une table.

    S’il s’agit d’une zone de préparation interne (p. ex. Snowflake) (option B), les fichiers de données sont automatiquement chiffrés par le client sur la machine locale avant d’être transmis à la zone de préparation interne.

  2. L’utilisateur charge les données depuis la zone de préparation vers une table. Les données sont transformées dans le format de fichier propriétaire de Snowflake et stockées dans un conteneur de stockage Cloud (« données au repos »). Dans Snowflake, toutes les données au repos sont chiffrées en permanence.

  3. Les résultats de la requête peuvent être déchargés vers une zone de préparation. Les résultats sont chiffrés en option à l’aide du chiffrement côté client lorsqu’ils sont déchargés vers une zone de préparation gérée par le client, et sont automatiquement chiffrés lorsqu’ils sont déchargés dans une zone de préparation fournie par Snowflake.

  4. L’utilisateur télécharge les fichiers de données de la zone de préparation, et décrypte les données du côté client.

Dans toutes ces étapes, tous les fichiers de données sont chiffrés. Seuls l’utilisateur et les composants d’exécution Snowflake peuvent lire les données. Les composants d’exécution déchiffrent les données en mémoire pour le traitement des requêtes. Aucun service tiers ne peut voir les données en clair.

Chiffrement côté client

Le chiffrement côté client fournit un système sécurisé pour la gestion des données dans le stockage Cloud. Le chiffrement côté client signifie qu’un utilisateur chiffre les données avant de les charger vers Snowflake. Le service de stockage Cloud ne stocke que la version chiffrée des données et n’inclut jamais aucune donnée en clair.

Uploading data to cloud storage using client-side encryption

Le chiffrement côté client suit un protocole spécifique défini par le service de stockage Cloud. Le service SDK et les outils tiers implémentent ce protocole. Le protocole de chiffrement côté client fonctionne comme suit (voir la figure dans cette section) :

  1. Le client Snowflake crée une clé maîtresse secrète qui reste chez le client.

  2. Le client (fourni par le service de stockage Cloud) génère une clé de chiffrement aléatoire et chiffre le fichier avant de le télécharger vers le stockage Cloud. La clé de chiffrement aléatoire, à son tour, est chiffrée avec la clé maîtresse du client.

  3. Le fichier chiffré et la clé aléatoire chiffrée sont téléchargés vers le service de stockage Cloud. La clé aléatoire chiffrée est stockée avec les métadonnées du fichier.

Lors du téléchargement des données, le client télécharge à la fois le fichier chiffré et la clé aléatoire chiffrée. Le client déchiffre la clé aléatoire chiffrée à l’aide de la clé maîtresse du client. Ensuite, le client déchiffre le fichier chiffré à l’aide de la clé aléatoire maintenant déchiffrée. Le chiffrement et le déchiffrement se font du côté du client. À aucun moment le service de stockage Cloud ou tout autre tiers (tel qu’un ISP) ne voit les données en clair. Les clients peuvent télécharger des données chiffrées côté client à l’aide de tout client ou outil qui prend en charge le chiffrement côté client.

Intégration de données chiffrées côté client dans Snowflake

Snowflake prend en charge le protocole de chiffrement côté client à l’aide d’une clé maîtresse côté client lors de la lecture ou de l’écriture de données entre une zone de préparation de service de stockage Cloud et Snowflake.

Ingesting client-Side encrypted data into Snowflake

Pour charger des données chiffrées côté client à partir d’une zone de préparation fournie par le client, vous créez un objet de zone de préparation nommée avec un paramètre MASTER_KEY supplémentaire en utilisant CREATE STAGE, puis chargez les données de la zone de préparation vers vos tables Snowflake. Le paramètre MASTER_KEY nécessite une clé de chiffrement avancée standard 256 bits (AES) codée en Base64.

Un objet de zone de préparation nommé stocke les paramètres liés à une zone de préparation, et fournit un moyen pratique de charger ou de décharger des données entre Snowflake et un conteneur spécifique dans le stockage Cloud. L’extrait SQL suivant crée un objet de zone de préparation Amazon S3 d’exemple dans Snowflake qui prend en charge le chiffrement côté client :

-- create encrypted stage
create stage encrypted_customer_stage
url='s3://customer-bucket/data/'
credentials=(AWS _KEY_ID='ABCDEFGH' AWS_SECRET_KEY='12345678')
encryption=(MASTER_KEY='eSxX0jzYfIamtnBKOEOxq80Au6NbSgPH5r4BDDwOaO8=');

La clé maîtresse spécifiée dans cette commande SQL est la chaîne codée en Base64 de la clé maîtresse secrète du client. Comme pour toutes les autres informations d’identification, cette clé est transmise via le « Transport Layer Security » (HTTPS) à Snowflake, et est stockée dans des métadonnées de stockage tout en étant chiffrée. Seuls le client et les composants de traitement des requêtes de Snowflake sont exposés à la clé maîtresse, et sont donc en mesure de déchiffrer les données stockées dans la zone de préparation.

L’un des avantages des objets de zone de préparation nommés est qu’ils peuvent être accordés à d’autres utilisateurs d’un compte Snowflake sans révéler à ces utilisateurs leurs identifiants d’accès ou leurs clés de chiffrement côté client. Les utilisateurs disposant des privilèges de contrôle d’accès appropriés se réfèrent simplement à l’objet de zone de préparation nommé lors du chargement ou du déchargement des données.

Les commandes SQL suivantes créent une table nommée USERS et copient les données de la zone de préparation chiffrée dans la table USERS :

-- create table and ingest data from stage
CREATE TABLE users (id bigint, name varchar(500), purchases int);
COPY INTO users FROM @encrypted_customer_stage/users;

Les données sont maintenant prêtes à être analysées à l’aide de Snowflake.

Vous pouvez également décharger les données vers la zone de préparation. La commande SQL suivante crée une table MOST_PURCHASES et la remplit avec les résultats d’une requête qui trouve les 10 premiers utilisateurs avec le plus d’achats, puis décharge les données de la table vers la zone de préparation :

-- find top 10 users by purchases, unload into stage
CREATE TABLE most_purchases as select * FROM users ORDER BY purchases desc LIMIT 10;
COPY INTO @encrypted_customer_stage/most_purchases FROM most_purchases;

Snowflake chiffre les fichiers de données copiés dans la zone de préparation du client à l’aide de la clé maîtresse stockée dans l’objet de zone de préparation. Snowflake adhère au protocole de chiffrement côté client pour le service de stockage Cloud. Un client peut télécharger les fichiers de données chiffrés à l’aide de n’importe quel client ou outil qui prend en charge le chiffrement côté client.

Gestion des clés de chiffrement

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.

Pour plus d’informations sur le chiffrement Snowflake, consultez notre livre blanc sur la sécurité.

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 pour les clés de niveau compte, de niveau table et de niveau fichier.

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 maîtresses 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 de compte et de table maîtresses 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 l’expéditeur. Lorsqu’elle est retirée, la clé sert uniquement à déchiffrer les données et n’est disponible que pour le destinataire. 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.

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

Cette figure montre la rotation des clés pour une clé de table maîtresse (TMK) :

  • 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 maîtresse. 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. Si la re-saisie périodique est activée, 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;

Tandis que la rotation de clé garantit qu’une clé est transférée de son état actif (utilisation par l’initiateur) à un état retiré (utilisation par le destinataire), la re-saisie garantit qu’une clé est transférée de son état retiré à un état détruit.

Rekeying one table master key (TMK) after one year

Dans cette figure, la clé de table maîtresse (TMK) d’une table individuelle fait l’objet d’une rotation mensuelle. La figure montre les rotations de clé en avril, mai et juin (TMK v1, v2 et v3) :

  • 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 chiffres à 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 opérations 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 que les fichiers de données avec l’ancienne clé sur S3 sont déjà protégés par Fail-safe, et les fichiers de données avec la nouvelle clé sur 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 :

  • Les clés les plus élevées dans la hiérarchie de clés ne quittent jamais le HSM. Toutes les opérations de chiffrement sont effectuées dans les modules de sécurité eux-mêmes.

  • Les clés de niveau inférieur englobées dans la hiérarchie des clés ne peuvent pas être « libérées » sans un accès autorisé aux périphériques HSM.

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

Snowflake utilise la configuration haute disponibilité HSM avec sauvegarde pour réduire la possibilité de pannes, et pour ne pas perdre les clés les plus importantes dans la hiérarchie.

Key hierarchy rooted in Hardware Security Module

Tri-Secret Secure et clés gérées par le client

Tri-Secret Secure vous permet de contrôler l’accès à vos données à l’aide d’une clé de chiffrement maîtresse que vous gérez dans le service de gestion de clés du fournisseur Cloud qui héberge votre compte Snowflake :

Avec Tri-Secret Secure activé pour votre compte, Snowflake combine votre clé avec une clé gérée par Snowflake pour créer une clé maîtresse composite. Cette clé maîtresse composite est ensuite utilisée pour chiffrer toutes les données de votre compte. Si l’une des clés de la clé maîtresse composite est révoquée, vos données ne peuvent pas être déchiffrées, ce qui assure un niveau de sécurité et de contrôle supérieur à celui du chiffrage 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.

Pour plus de détails sur la mise en œuvre des clés gérées par le client, consultez cet article de blog (qui fait référence à AWS, bien que les principes généraux s’appliquent quel que soit le service Cloud).

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

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

  • Un contrôle de l’accès aux données : vous avez un contrôle total sur votre clé maîtresse 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é.

  • La possibilité de désactiver l’accès en cas d’atteinte à la protection 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.

  • La 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.

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é. 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, et HIPAA.

Activation de Tri-Secret Secure

Pour activer Snowflake Tri-Secret Secure pour votre compte Business Critical, veuillez contacter le support Snowflake.