Utiliser des objets sécurisés pour contrôler l’accès aux données¶
Pour s’assurer que les données sensibles dans une base de données partagée ne sont pas exposées dans les comptes de consommateur, Snowflake recommande fortement de partager des vues et/ou des UDFs sécurisés au lieu de partager directement des tables.
De plus, pour des performances optimales, en particulier lors du partage de données dans de très grandes tables, nous recommandons de définir des clés de clustering sur la (les) table(s) de base pour vos objets sécurisés.
Ce chapitre décrit l’utilisation des clés de clustering dans des tables de base pour les objets sécurisés partagés et fournit des instructions étape par étape pour partager une vue sécurisée avec un compte de consommateur. Il fournit des exemples de scripts pour les fournisseurs et les consommateurs de données.
Note
Les instructions pour partager un objet sécurisé sont essentiellement les mêmes que pour partager une table, avec l’ajout des objets suivants :
Un schéma « privé » contenant la table de base et un schéma « public » contenant l’objet sécurisé. Seuls le schéma public et l’objet sécurisé sont partagés.
Une « table de mappage » (également dans le schéma « privé »), qui n’est nécessaire que si vous souhaitez partager les données de la table de base avec plusieurs comptes de consommateur et partager des lignes spécifiques de la table avec des comptes spécifiques.
Exemples de configuration et de tâches¶
Ces exemples d’instructions supposent qu’une base de données nommée mydb existe dans le compte du fournisseur de données et possède deux schémas : private et public. Si la base de données et les schémas n’existent pas, vous devez les créer avant de continuer.
Etape 1 : créer des données et des tables de mappage dans un schéma privé¶
Créez les deux tables suivantes dans le schéma mydb.private et remplissez-les de données :
sensitive_data — contient les données à partager, et une colonne access_id pour contrôler l’accès aux données par compte.sharing_access — utilise la colonne access_id pour mapper les données partagées et les comptes qui peuvent accéder aux données.Etape 2 : créer une vue sécurisée dans un schéma public¶
Créez la vue sécurisée suivante dans le schéma mydb.public :
paid_sensitive_data — affiche les données en fonction du compte.Notez que la colonne access_id de la table de base (sensitive_data) n’a pas besoin d’être incluse dans la vue.
Etape 3 : valider des tables et vues sécurisées¶
Validez les tables et les vues sécurisées pour vous assurer que les données sont filtrées correctement par compte.
Pour activer la validation des vues sécurisées qui seront partagées avec d’autres comptes, Snowflake fournit un paramètre de session, SIMULATED_DATA_SHARING_CONSUMER. Définissez ce paramètre de session sur le nom du compte de consommateur pour lequel vous souhaitez simuler l’accès. Vous pouvez alors interroger la vue et voir les résultats qu’un utilisateur du compte de consommateur verra.
Exemple de script¶
Le script suivant illustre l’exécution de toutes les tâches décrites dans la section précédente :
Créez deux tables dans le schéma « privé » et remplissez la première avec des données sur les actions de trois sociétés différentes (Apple, Microsoft et IBM). Vous alimenterez ensuite la seconde avec des données qui associent les données boursières aux comptes en particulier :
Créez une vue sécurisée dans le schéma « public ». Cette vue filtre les données boursières de la première table par compte, en utilisant les informations de mappage de la deuxième table :
Créez un partage en utilisant le rôle ACCOUNTADMIN.
Ajoutez les objets au partage. Vous pouvez choisir soit d’ajouter des privilèges sur ces objets à un partage via un rôle de base de données (option 1), soit d’accorder des privilèges sur les objets directement au partage (option 2) :
Ajoutez des comptes au partage.
Exemple de scénario (pour les consommateurs)¶
Le script suivant peut être utilisé par les consommateurs pour créer une base de données (à partir du partage créé dans le script ci-dessus) et interroger la vue sécurisée dans la base de données obtenue :
Faites entrer la base de données partagée dans votre compte en créant une base de données à partir du partage.
Accordez des privilèges sur la base de données à d’autres rôles de votre compte (par exemple, CUSTOM_ROLE1). L’instruction GRANT diffère selon que le consommateur de données a ajouté des objets au partage en utilisant des rôles de base de données (option 1) ou en accordant des privilèges sur les objets directement au partage (option 2) :
Utilisez le rôle CUSTOM_ROLE1 pour interroger la vue dans la base de données que vous avez créée. Notez qu’il doit y avoir un entrepôt actif utilisé dans la session pour effectuer des requêtes. Dans la commande USE WAREHOUSE, remplacez <nom_entrepôt> par le nom de l’un des entrepôts de votre compte. Le rôle CUSTOM_ROLE1 doit avoir le privilège USAGE sur l’entrepôt :