CREATE SESSION POLICY¶

Syntaxe¶

CREATE [OR REPLACE] SESSION POLICY [IF NOT EXISTS] <name>
  [ SESSION_IDLE_TIMEOUT_MINS = <integer> ]
  [ SESSION_UI_IDLE_TIMEOUT_MINS = <integer> ]
  [ ALLOWED_SECONDARY_ROLES = ( [ { 'ALL' | <role_name> [ , <role_name> ... ] } ] ) ]
  [ BLOCKED_SECONDARY_ROLES = ( [ { 'ALL' | <role_name> [ , <role_name> ... ] } ] ) ]
  [ COMMENT = '<string_literal>' ]

Paramètres requis¶

name

Identificateur de la politique de session ; doit être unique pour votre compte.

La valeur de l’identificateur doit commencer par un caractère alphabétique et ne peut pas contenir d’espaces ou de caractères spéciaux à moins que toute la chaîne d’identificateur soit délimitée par des guillemets doubles (p. ex. "My object"). Les identificateurs entre guillemets doubles sont également sensibles à la casse.

Pour plus de détails, voir Exigences relatives à l’identificateur.

Paramètres facultatifs¶

SESSION_IDLE_TIMEOUT_MINS = integer

Pour les clients Snowflake et les clients automatiques, le nombre de minutes pendant lesquelles une session peut être inactive avant que les utilisateurs ne doivent s’authentifier à nouveau dans Snowflake. Si une valeur n’est pas spécifiée, Snowflake utilise la valeur par défaut.

Peut être n’importe quel nombre entier compris entre 5 et 240.

Par défaut : 240 (4 heures)

SESSION_UI_IDLE_TIMEOUT_MINS = integer

Pour Snowsight, le nombre de minutes pendant lesquelles une session peut être inactive avant que les utilisateurs ne doivent s’authentifier à nouveau dans Snowflake. Si une valeur n’est pas spécifiée, Snowflake utilise la valeur par défaut.

Peut être n’importe quel nombre entier compris entre 5 et 240.

Par défaut : 240 (4 heures)

ALLOWED_SECONDARY_ROLES = ( [ { 'ALL' | role_name [ , role_name ... ] } ] )

Spécifie les rôles secondaires autorisés d’une stratégie de session, le cas échéant.

Les valeurs possibles pour la propriété sont :

()

Interdit les rôles secondaires.

('ALL')

Autorise tous les rôles secondaires.

( role_name [ , role_name ... ] )

Autorise les rôles spécifiés comme rôles secondaires. Les rôles secondaires peuvent être des rôles de compte définis par l’utilisateur ou des rôles système. Spécifiez le nom du rôle tel qu’il est stocké dans Snowflake. Pour plus de détails, voir Exigences relatives à l’identificateur.

Par défaut : ('ALL'). Si vous ne définissez pas la propriété lorsque vous créez une stratégie de session, tous les rôles secondaires sont autorisés.

BLOCKED_SECONDARY_ROLES = ( [ { 'ALL' | role_name [ , role_name ... ] } ] )

Spécifie les rôles secondaires bloqués pour une politique de session, le cas échéant. Les rôles secondaires bloqués ont la priorité sur les rôles secondaires autorisés.

Les valeurs possibles pour la propriété sont :

()

Autorise tous les rôles secondaires.

('ALL')

Interdit les rôles secondaires.

( role_name [ , role_name ... ] )

Bloque les rôles spécifiés comme rôles secondaires. Les rôles spécifiés et les rôles accordés à ces rôles ne peuvent pas être activés en tant que rôles secondaires. Les rôles bloqués peuvent être des rôles d’utilisateur définis par l’utilisateur ou des rôles système. Spécifiez le nom de rôle tel qu’il est stocké dans Snowflake. Pour des détails, consultez Exigences relatives à l’identificateur.

Par défaut : (). Si vous ne définissez pas la propriété lorsque vous créez une stratégie de session, tous les rôles secondaires sont autorisés.

COMMENT = 'string_literal'

Ajoute un commentaire ou remplace un commentaire existant pour la politique de session.

Exigences en matière de contrôle d’accès¶

Un rôle utilisé pour exécuter cette opération doit au minimum disposer des privilèges suivants :

Le privilège USAGE relatif à la base de données et au schéma parents est exigé pour effectuer des opérations sur tout objet d’un schéma. Notez qu’un rôle doté d’un privilège quelconque sur un schéma permet à ce rôle de résoudre le schéma. Par exemple, un rôle doté du privilège CREATE sur un schéma peut créer des objets sur ce schéma sans également avoir le privilège USAGE attribué sur ce schéma.

Pour obtenir des instructions sur la création d’un rôle personnalisé avec un ensemble spécifique de privilèges, voir Création de rôles personnalisés.

Pour des informations générales sur les rôles et les privilèges accordés pour effectuer des actions SQL sur des objets sécurisables, voir Aperçu du contrôle d’accès.

Pour plus de détails sur la DDL de politique de session et les privilèges, voir Gestion des politiques de session.

Notes sur l’utilisation¶

• Si vous souhaitez remplacer une politique de session existante et si vous avez besoin de voir la définition actuelle de cette politique, appelez la fonction GET_DDL ou exécutez la commande DESCRIBE SESSION POLICY.

• Concernant les métadonnées :

  Attention

  Les clients doivent s’assurer qu’aucune donnée personnelle (autre que pour un objet utilisateur), donnée sensible, donnée à exportation contrôlée ou autre donnée réglementée n’est saisie comme métadonnée lors de l’utilisation du service Snowflake. Pour plus d’informations, voir Champs de métadonnées dans Snowflake.

• Les clauses OR REPLACE et IF NOT EXISTS s’excluent mutuellement. Elles ne peuvent pas être utilisées dans la même instruction.

• Les instructions CREATE OR REPLACE <objet> sont atomiques. En d’autres termes, lorsqu’un objet est remplacé, l’ancien objet est supprimé et le nouvel objet est créé dans une seule transaction.

Exemples¶

Créez une politique de session pour votre compte actuel :

CREATE SESSION POLICY session_policy_prod_1
  SESSION_IDLE_TIMEOUT_MINS = 30
  SESSION_UI_IDLE_TIMEOUT_MINS = 30
  COMMENT = 'session policy for use in the prod_1 environment'
;

Copy