Contrôle de l’accès aux tables dynamiques¶

Ce sujet traite des privilèges nécessaires pour effectuer des opérations sur les tables dynamiques, telles que la création, la requête, la modification, la vue et la suppression.

Pour plus d’informations sur le modèle de privilèges Snowflake, consultez Aperçu du contrôle d’accès et Privilèges de contrôle d’accès.

Transfert de la propriété¶

Pour accorder à un utilisateur un accès complet à une table dynamique, vous pouvez procéder de l’une des manières suivantes :

Lors de l’assignation d’attributions, veillez à spécifier le type d’objet DYNAMIC TABLE, car les tables dynamiques disposent d’un ensemble de privilèges différent de celui des tables ordinaires.

Pour accorder le privilège OWNERSHIP sur les tables dynamiques, assurez-vous que le rôle de réception dispose du privilège USAGE sur les éléments suivants. Dans le cas contraire, les actualisations programmées ultérieures échouent.

La base de données et le schéma qui contient la table dynamique.
L’entrepôt utilisé pour rafraîchir la table.

Pour transférer la propriété d’une table dynamique, vous pouvez utiliser la commande GRANT OWNERSHIP ou Snowsight.

L’exemple suivant utilise la commande GRANT OWNERSHIP pour octroyer des privilèges de propriété sur my_dynamic_table au rôle budget_admin.

GRANT OWNERSHIP ON DYNAMIC TABLE my_dynamic_table TO ROLE budget_admin;

Copy

L’exemple suivant utilise la commande GRANT OWNERSHIP pour accorder au rôle budget_admin des privilèges de propriété sur toutes les futures tables dynamiques créées dans le schéma mydb.myschema.

GRANT OWNERSHIP ON FUTURE DYNAMIC TABLES IN SCHEMA mydb.myschema TO ROLE budget_admin;

Copy

Pour en savoir plus sur le modèle de privilèges Snowflake, voir Aperçu du contrôle d’accès et Privilèges de contrôle d’accès.

Actualiser des tables dynamiques avec des privilèges utilisateur et des rôles secondaires spécifiques¶

Les tables dynamiques peuvent être configurées pour s’actualiser avec les privilèges d’un utilisateur spécifique, en plus des privilèges du rôle de propriétaire. Les tables dynamiques qui spécifient EXECUTE AS USER s’exécutent pour le compte de l’utilisateur nommé, au lieu du service système.

Par exemple, vous pouvez accorder à un utilisateur un rôle principal qui donne accès à une table et un rôle secondaire qui donne accès à un entrepôt virtuel. L’utilisateur peut alors créer une table dynamique qui opère avec les privilèges combinés des deux rôles, simplifiant la gestion des privilèges et améliorant la flexibilité de vos opérations de données.

Alors que l’option EXECUTE AS USER permet aux tables dynamiques de s’actualiser sous le rôle de l’utilisateur, toutes les autres opérations sur ces tables dynamiques respectent le modèle de privilège standard.

Cas d’utilisation clés¶

Gérer les privilèges multi-rôles : dans les cas où les utilisateurs disposent de rôles secondaires, ils peuvent créer et actualiser une table dynamique en utilisant les privilèges combinés de leurs rôles principal et secondaire. Cette configuration garantit que l’utilisateur qui actualise la table dynamique dispose des autorisations nécessaires pour accéder à toutes les ressources requises, tout en maintenant la cohérence avec les contrôles d’accès existants basés sur les rôles.
Contrôles de gouvernance et de sécurité granulaires : les utilisateurs peuvent configurer des mesures de sécurité facultatives avec des options supplémentaires telles que REQUIRE USER, où une table dynamique ne peut être exécutée que si un utilisateur est spécifié.
Comptabilité de toutes les opérations : toutes les actualisations sur un table dynamique EXECUTE AS USER sont attribuées à l’utilisateur configuré au lieu de l’utilisateur SYSTEM. Cette attribution permet de maintenir une trace d’audit claire pour toutes les opérations.

Contrôle d’accès¶

Le rôle de propriétaire de la table dynamique doit se voir attribuer le privilège IMPERSONATE sur l’utilisateur spécifié par EXECUTE AS USER, et l’utilisateur spécifié doit se voir attribuer le rôle de propriétaire de la table dynamique. Si le privilège IMPERSONATE est révoqué, l’actualisation de la table dynamique échouera et la table dynamique peut être suspendue automatiquement.

Lorsque la table dynamique est actualisée, le rôle principal de la session d’actualisation est le rôle de propriétaire de la table dynamique et les rôles secondaires par défaut de l’utilisateur sont activés. Les utilisateurs peuvent changer de rôle principal à l’aide de la commande USE ROLE et modifier les rôles secondaires lors de la session d’actualisation à l’aide de la commande USE SECONDARY ROLES.

Considérations relatives aux produits croisés¶

Politiques de masquage des données et d’accès aux lignes : les politiques, par exemple, celles qui utilisent CURRENT_USER(), sont évaluées en fonction de l’utilisateur et des rôles spécifiés plutôt que de l’utilisateur SYSTEM.
Réplication et basculement : le nom de l’utilisateur et le nom du rôle sont répliqués vers les déploiements secondaires.

Si un utilisateur ou un rôle n’est pas disponible sur le déploiement secondaire, l’utilisateur est marqué comme INVALID et les actualisations échoueront jusqu’à ce que le problème soit résolu.

Les rôles secondaires non valides sont ignorés lors de l’exécution si les rôles restants fournissent des privilèges suffisants.

Exemples¶

Configurer une table dynamique pour exécuter des actualisations en tant qu’utilisateur¶

L’exemple suivant crée une table dynamique qui exécute les actualisations en tant qu’utilisateur spécifié, avec le rôle principal défini sur le rôle de propriétaire de la table dynamique. Les actualisations s’exécutent avec tous les paramètres de lignée de l’utilisateur que celui-ci a définis.

Si aucune option pour les rôles secondaires n’est explicitement spécifiée, l’actualisation correspond par défaut au paramètre de session actuel de l’utilisateur.

CREATE DYNAMIC TABLE my_dynamic_table
  [ EXECUTE AS USER my_user_name
    [ USE SECONDARY ROLES { ALL | NONE | (<role1>, <role2>, ... ) } ]
  ]

Copy

Définir un rôle secondaire pour une table dynamique existante¶

L’exemple suivant configure une table dynamique pour qu’elle s’exécute en tant qu’utilisateur spécifié. Si aucun rôle secondaire spécifique n’est sélectionné, le processus d’actualisation prend par défaut les rôles secondaires actifs de la session en cours. Si la table dynamique est déjà configurée pour être exécutée en tant qu’utilisateur spécifique, cette commande mettra à jour la configuration pour qu’elle s’exécute en tant qu’utilisateur exécutant la commande ALTER DYNAMIC TABLE.

L’exécution de cette commande nécessite le privilège OWNERSHIP sur la table dynamique.

ALTER DYNAMIC TABLE my_dynamic_table SET
  EXECUTE AS USER my_user_name
  [ USE SECONDARY ROLES { ALL | NONE | (<role1>, <role2>, ... ) } ]

Copy

Configurer une table dynamique pour qu’elle s’exécute sous l’utilisateur SYSTEM¶

L’exemple suivant rétablit une table dynamique pour qu’elle s’exécute sous l’utilisateur SYSTEM à l’aide du rôle de propriétaire de la table dynamique.

L’exécution de cette commande nécessite le privilège OWNERSHIP sur la table dynamique.

ALTER DYNAMIC TABLE my_dynamic_table UNSET EXECUTE AS USER;

Copy

Privilèges permettant de créer une table dynamique¶

Pour pouvoir créer une table dynamique, vous devez utiliser un rôle disposant des privilèges suivants :

Privilège	Objet
CREATE DYNAMIC TABLE	Schéma dans lequel vous prévoyez de créer la table dynamique.
SELECT	Tables et vues existantes que vous envisagez d’interroger pour la nouvelle table dynamique.
USAGE	Base de données et schéma que vous prévoyez d’utiliser pour la nouvelle table dynamique. Entrepôt que vous prévoyez d’utiliser pour actualiser la table. Note Même si vous pouvez exécuter `CREATE DYNAMIC TABLE ... INITIALIZE = ON_SCHEDULE` avec un rôle secondaire disposant du privilège USAGE, la table dynamique ne s’actualisera pas si le rôle principal ne dispose pas de ce privilège, et ne sera donc pas initialisée.

Privilège

Objet

CREATE DYNAMIC TABLE

Schéma dans lequel vous prévoyez de créer la table dynamique.

SELECT

Tables et vues existantes que vous envisagez d’interroger pour la nouvelle table dynamique.

USAGE

Base de données et schéma que vous prévoyez d’utiliser pour la nouvelle table dynamique.

Entrepôt que vous prévoyez d’utiliser pour actualiser la table.

Note

Même si vous pouvez exécuter CREATE DYNAMIC TABLE ... INITIALIZE = ON_SCHEDULE avec un rôle secondaire disposant du privilège USAGE, la table dynamique ne s’actualisera pas si le rôle principal ne dispose pas de ce privilège, et ne sera donc pas initialisée.

Pour créer une table dynamique qui dépend d’une autre table dynamique, vous devez utiliser un rôle qui dispose des privilèges suivants :

Privilège	Objet
SELECT	Table dynamique que vous prévoyez d’interroger pour créer la nouvelle table dynamique.
OPERATE	Toutes les tables dynamiques en amont dont dépend la nouvelle table dynamique. Nécessaire uniquement si vous avez configuré la table dynamique de sorte qu’elle soit actualisée de manière synchrone lors de sa création.

Privilèges permettant d’interroger une table dynamique¶

Pour interroger une table dynamique, vous pouvez utiliser un rôle doté des privilèges permettant de créer une table dynamique. Pour les scénarios dans lesquels un utilisateur ne doit interroger qu’une table dynamique (par exemple, un analyste de données), utilisez un rôle doté des privilèges suivants :

Privilège	Objet
USAGE	Base de données et schéma contenant la table dynamique. Entrepôt utilisé pour exécuter la requête.
SELECT	Table dynamique interrogée.

Privilège

Objet

USAGE

Base de données et schéma contenant la table dynamique.

Entrepôt utilisé pour exécuter la requête.

SELECT

Table dynamique interrogée.

Privilèges permettant de modifier une table dynamique¶

Pour modifier une table dynamique, vous devez utiliser un rôle qui dispose du privilège OWNERSHIP ou OPERATE sur cette table dynamique.

Si vous disposez du privilège OPERATE sur une table dynamique, vous pouvez effectuer les opérations suivantes à l’aide de la commande ALTER DYNAMIC TABLE :

Suspendre une table dynamique via ALTER … SUSPEND.
Reprendre une table dynamique via ALTER … RESUME.
Actualiser une table dynamique via ALTER … REFRESH.
Définir ou modifier l’entrepôt et/ou la latence cible via ALTER … SET.

Si vous disposez du privilège OWNERSHIP sur une table dynamique, vous pouvez effectuer les opérations suivantes en plus de celles énumérées ci-dessus :

Paramétrez ou annulez un commentaire en utilisant ALTER … SET | UNSET COMMENT.
Renommez une table dynamique en utilisant ALTER … RENAME TO.
Remplacement d’une table dynamique par une autre en utilisant ALTER … SWAP WITH
Définition d’un nouveau paramètre à l’aide de ALTER … SET
Spécifiez ou supprimez des clés de clustering. Voir Actions de clustering (clusteringAction).
Modifiez les politiques de gouvernance. Voir Politique de gouvernance des données et actions de balises (dataGovnPolicyTagAction).
Modifiez l’optimisation de la recherche. Voir Actions d’optimisation de la recherche (searchOptimizationAction).

Privilèges permettant d’afficher les métadonnées d’une table dynamique¶

Pour afficher les métadonnées, vous devez utiliser un rôle titulaire du privilège MONITOR sur cette table dynamique.

Pour les scénarios où l’utilisateur n’a besoin que de voir les métadonnées et l’Information Schema d’une table dynamique (par exemple, les rôles détenus par les scientifiques des données), utilisez un rôle qui a le privilège MONITOR sur cette table dynamique. Bien que le privilège OPERATE accorde cet accès, il inclut également la capacité de modifier les tables dynamiques, ce qui fait de MONITOR l’option la plus appropriée pour les scénarios dans lesquels un utilisateur n’a pas besoin de modifier une table dynamique.

Si vous disposez du privilège MONITOR sur une table dynamique, vous pouvez effectuer les opérations suivantes :

Utilisez la commande DESCRIBE DYNAMIC TABLE et la page de détails des tables dynamiques Snowsight pour afficher les détails spécifiques d’une table dynamique. Les champs suivants sont masqués si vous ne disposez que du privilège SELECT sur une table dynamique : text, warehouse, scheduling_state, last_suspended_on et suspend_reason_code (UIuniquement).
Utilisez la commande SHOW DYNAMIC TABLES pour voir à quelles tables dynamiques vous avez accès.
Appelez la fonction de table DYNAMIC_TABLE_GRAPH_HISTORY pour afficher l’historique du graphique.
Appelez la fonction de table DYNAMIC_TABLE_REFRESH_HISTORY pour afficher l’historique d’actualisation.

Privilèges permettant de supprimer une table dynamique¶

Pour supprimer une table dynamique, vous devez utiliser un rôle titulaire du privilège OWNERSHIP sur cette table dynamique.

Privilèges d’utilisation des entrepôts doubles¶

Toutes les exigences de privilèges pour l’utilisation de l’INITIALIZATION_WAREHOUSE sont identiques à l’WAREHOUSE.

Fonctionnement	Privilège
CREATE DYNAMIC TABLE à l’aide de l’INITIALIZATION_WAREHOUSE	CREATE DYNAMIC TABLE et USAGE sur les deux entrepôts, l’WAREHOUSE et l’INITIALIZATION_WAREHOUSE.
ALTER DYNAMIC TABLE … SET / UNSET INITIALIZATION_WAREHOUSE	OWNERSHIP ou OPERATE sur la table dynamique et USAGE sur l’entrepôt concerné.
ALTER DYNAMIC TABLE … REFRESH sur une table dynamique qui utilise l’INITIALIZATION_WAREHOUSE	OPERATE sur la table dynamique et USAGE sur l’entrepôt concerné.

Pour plus d’informations, voir Comprendre l’utilisation de l’entrepôt pour les tables dynamiques.