Sessions Snowflake et politiques de session

Cette rubrique décrit les sessions Snowflake et les politiques de session et fournit des instructions pour configurer les politiques de session au niveau du compte ou de l’utilisateur.

Dans ce chapitre :

Sessions Snowflake

Une session commence lorsqu’un utilisateur se connecte à Snowflake et réussit à s’authentifier en utilisant un client automatique Snowflake, Snowsight, ou l”Classic Console. Une session est indépendante de la session d’un fournisseur d’identité (c’est-à-dire IdP). Si la session Snowflake expire mais que la session IdP reste active, un utilisateur peut se connecter à Snowflake sans saisir à nouveau ses identifiants de connexion (authentification silencieuse).

Avec une activité continue de l’utilisateur, une session client est maintenue indéfiniment. Après une période d’inactivité de la session, connue sous le nom de expiration de session inactive, l’utilisateur doit s’authentifier à nouveau auprès de Snowflake. Le délai d’expiration d’une session inactive a une valeur maximale de quatre heures et une politique de session peut modifier le délai d’expiration d’une session inactive. Le délai d’expiration d’une session inactive s’applique aux éléments suivants :

Snowflake recommande de réutiliser les sessions existantes lorsque cela est possible et de fermer la connexion à Snowflake lorsqu’une session n’est plus nécessaire.

Sessions Snowsight

Snowflake crée une nouvelle session pour chaque feuille de calcul dans Snowsight. Une session de feuille de calcul applique la politique de session qui s’applique à l’utilisateur qui crée la feuille de calcul.

Prudence

Les requêtes actives ne sont pas annulées lorsque la session se termine et que l’utilisateur est déconnecté, même si le paramètre ABORT_DETACHED_QUERY est fixé sur true.

Sessions Console classique

Dans l’onglet Worksheets Onglet Feuille de calcul Snowflake crée une nouvelle session chaque fois qu’une nouvelle feuille de calcul est créée. Chaque feuille de calcul est limitée à un maximum de 4 heures d’inactivité, et le délai d’inactivité de chaque feuille de calcul est suivi séparément.

Lorsqu’une feuille de calcul est fermée, la session de l’utilisateur pour cette feuille de calcul se termine.

Après l’expiration du délai de 4 heures pour toute feuille de calcul ouverte Snowflake déconnecte l’utilisateur de l’interface Web.

Note

Notez que les comportements passifs tels que le défilement du jeu de résultats d’une requête ou le tri d’un ensemble de données ne remettent pas à zéro le suivi du délai d’expiration d’une session inactive.

Pour éviter de fermer une session trop tôt et d’être déconnecté de l”Classic Console, enregistrez toutes les instructions SQL nécessaires dans un fichier local et fermez toutes les feuilles de calcul ouvertes qui ne sont pas utilisées.

Politiques de la session

Une politique de session définit le délai d’expiration d’une session inactive en minutes et offre la possibilité de remplacer la valeur par défaut du délai d’inactivité de 4 heures.

La politique de session peut être définie pour un compte ou un utilisateur avec des délais d’expiration en cas d’inactivité configurables pour répondre à des exigences de conformité. Si un utilisateur est associé à la fois à une politique de session de compte et de niveau utilisateur, la politique de session de niveau utilisateur a la priorité. Une fois la politique de session définie pour le compte ou l’utilisateur, Snowflake l’applique.

Il existe deux propriétés qui régissent le comportement de la politique de session :

  • SESSION_IDLE_TIMEOUT_MINS pour les clients automatiques et les clients Snowflake.

  • SESSION_UI_IDLE_TIMEOUT_MINS pour l”Classic Console et Snowsight.

Le délai d’expiration commence dès que l’authentification à Snowflake a réussi. Si une politique de session n’est pas définie, Snowflake utilise une valeur par défaut de 240 minutes (c’est-à-dire 4 heures). La valeur minimale configurable du délai d’expiration d’une session inactive pour une politique de session est de 5 minutes. Lorsque la session expire, l’utilisateur doit s’authentifier à nouveau auprès de Snowflake. Cependant, Snowflake n’applique pas les paramètres définis par le Point de terminaison de déconnexion personnalisé.

Pour plus d’informations, voir :

Considérations

  • Si un client prend en charge l’option CLIENT_SESSION_KEEP_ALIVE et que l’option est définie sur TRUE, le client préserve la session Snowflake indéfiniment tant que la connexion à Snowflake est active. Sinon, si l’option a pour valeur FALSE, la session se termine après 4 heures. Dans la mesure du possible, évitez d’utiliser cette option, car elle peut entraîner l’ouverture de nombreuses sessions et une plus grande demande de ressources, ce qui peut entraîner une dégradation des performances.

  • Vous pouvez utiliser le paramètre CLIENT_SESSION_KEEP_ALIVE_HEARTBEAT_FREQUENCY pour spécifier le nombre de secondes entre les tentatives du client pour mettre à jour le jeton pour la session. La session de l’interface Web peut être actualisée au fur et à mesure que des objets Snowflake continuent d’être utilisés, comme l’exécution des instructions DDL et DML. Snowflake vérifie ce comportement toutes les 30 secondes.

  • La création d’une nouvelle feuille de calcul ou l’ouverture d’une feuille de calcul existante continue à utiliser la session utilisateur établie, mais avec un délai d’expiration de session inactive réinitialisé à 0.

  • Suivi de l’utilisation de la politique de session :

    • Interrogez la vue Account Usage SESSION_POLICIES pour obtenir une ligne pour chaque politique de session dans votre compte Snowflake.

    • Utilisez la fonction de table Information Schema POLICY_REFERENCES pour renvoyer une ligne pour chaque utilisateur affecté à la politique de session spécifiée et une ligne pour la politique de session affectée au compte Snowflake.

      Actuellement, seule la syntaxe suivante est prise en charge pour les politiques de session :

      POLICY_REFERENCES( POLICY_NAME => '<session_policy_name>' )
      
      Copy

      session_policy_name est le nom entièrement qualifié de la politique de session.

      Par exemple, exécutez la requête suivante pour renvoyer une ligne pour chaque utilisateur auquel est attribuée la politique de session nommée session_policy_prod_1, qui est stockée dans la base de données nommée my_db et le schéma nommé my_schema :

      SELECT *
      FROM TABLE(
        MY_DB.INFORMATION_SCHEMA.POLICY_REFERENCES(
          POLICY_NAME => 'my_db.my_schema.session_policy_prod_1'
        )
      );
      
      Copy

Limitations

Autorisations futures:

Les autorisations futures de privilèges sur les politiques de session ne sont pas prises en charge.

Comme solution de contournement, accordez le privilège APPLYSESSION POLICY à un rôle personnalisé pour lui permettre d’appliquer des politiques de session à un utilisateur ou au compte Snowflake.

Mise en œuvre d’une politique de session

Les étapes suivantes constituent un guide représentatif de la mise en œuvre d’une politique de session.

Ces étapes supposent une approche de gestion centralisée dans laquelle un rôle personnalisé nommé policy_admin possède la politique de session (c’est-à-dire qu’il dispose du privilège OWNERSHIP sur la politique de session) et est chargé de définir la politique de session sur un compte ou un utilisateur (c’est-à-dire qu’il dispose du privilège APPLY SESSION POLICY sur ACCOUNT ou du privilège APPLY SESSION POLICY ON USER).

Note

Pour définir une politique sur un compte, le rôle personnalisé policy_admin doit avoir les permissions suivantes :

  • USAGE sur la base de données et le schéma qui contiennent la politique de session.

  • CREATE SESSION POLICY sur le schéma qui contient la politique de session.

Suivez ces étapes pour mettre en œuvre une politique de session.

Étape 1 : créer le rôle personnalisé POLICY_ADMIN

Créez un rôle personnalisé qui permet à des utilisateurs de créer et de gérer des politiques de session. Dans cette rubrique, l’exemple de rôle personnalisé est nommé policy_admin, bien que le rôle puisse avoir n’importe quel nom approprié.

Si le rôle personnalisé existe déjà, passez à l’étape suivante.

Sinon, créez le rôle personnalisé POLICY_ADMIN.

USE ROLE USERADMIN;

CREATE ROLE policy_admin;
Copy

Étape 2 : accorder des privilèges au rôle personnalisé POLICY_ADMIN

Si le rôle personnalisé POLICY_ADMIN ne dispose pas déjà des privilèges suivants, accordez ces privilèges comme indiqué ci-dessous :

  • USAGE sur la base de données et le schéma qui contiendront la politique de session.

  • CREATE SESSION POLICY sur le schéma qui contiendra la politique de session.

  • APPLY SESSION POLICY sur le compte.

  • APPLY SESSION POLICY sur chaque utilisateur, si vous prévoyez de définir des politiques de session au niveau de l’utilisateur.

USE ROLE SECURITYADMIN;

GRANT USAGE ON DATABASE mydb TO ROLE policy_admin;

GRANT USAGE, CREATE SESSION POLICY ON SCHEMA mydb.policies TO ROLE policy_admin;

GRANT APPLY SESSION POLICY ON ACCOUNT TO ROLE policy_admin;
Copy

Si vous associez une politique de session à un utilisateur individuel :

GRANT APPLY SESSION POLICY ON USER jsmith TO ROLE policy_admin;
Copy

Pour plus d’informations, voir Résumé des commandes, des opérations et des privilèges DDL.

Étape 3 : créer une nouvelle politique de session

En utilisant le rôle personnalisé POLICY_ADMIN , créez une nouvelle politique de session où la valeur du délai d’expiration en cas d’inactivité pour les clients automatiques, les clients Snowflake et l’interface Web est de 60 minutes pour chacun. Pour plus d’informations, voir CREATE SESSION POLICY.

USE ROLE POLICY_ADMIN;

CREATE SESSION POLICY mydb.policies.session_policy_prod_1
  SESSION_IDLE_TIMEOUT_MINS = 60
  SESSION_UI_IDLE_TIMEOUT_MINS = 60
  COMMENT = 'Session policy for the prod_1 environment'
;
Copy

Où :

mydb.policies.session_policy_prod_1

Le nom entièrement qualifié de la politique de session.

session_idle_timeout_mins = 60

Le délai d’expiration en cas d’inactivité en minutes pour les clients Snowflake et les clients automatiques.

session_ui_idle_timeout_mins = 30

Le délai d’expiration en cas d’inactivité en minutes pour l’interface Web de Snowflake.

comment = 'Session policy for the prod_1 environment'

Un commentaire spécifiant l’objectif de la politique de session.

Étape 4 : définir la politique de session sur un compte ou un utilisateur

En utilisant le rôle personnalisé POLICY_ADMIN, définissez la politique sur un compte avec la commande ALTER ACCOUNT ou sur un utilisateur (par exemple, le nom d’utilisateur jsmith) avec la commande ALTER USER.

USE ROLE policy_admin;

ALTER ACCOUNT SET SESSION POLICY mydb.policies.session_policy_prod_1;

ALTER USER jsmith SET SESSION POLICY my_database.my_schema.session_policy_prod_1_jsmith;
Copy

Important

Pour remplacer une politique de session déjà définie pour un compte ou un utilisateur, il faut d’abord la désactiver, puis définir la nouvelle politique pour le compte ou l’utilisateur. Par exemple :

ALTER ACCOUNT UNSET session policy;

ALTER ACCOUNT SET SESSION POLICY mydb.policies.session_policy_prod_2;
Copy

Étape 5 : Répliquer la politique de session vers un compte cible

Une politique de session et ses références (c’est-à-dire les affectations à un utilisateur ou au compte) peuvent être répliquées du compte source au compte cible en utilisant la réplication de base de données et la réplication de compte. Pour plus de détails, reportez-vous à :

Gestion des politiques de session

Référence des privilèges de la politique de session

Snowflake prend en charge les privilèges de politique de session suivants pour déterminer si les utilisateurs peuvent créer, définir et posséder des balises de session.

Notez que l’exploitation d’un objet dans un schéma requiert également le privilège USAGE sur la base de données et le schéma parents.

Privilège

Utilisation

CREATE

Permet de créer une nouvelle politique de session dans un schéma.

APPLY SESSION POLICY

Permet d’appliquer une politique de session au niveau du compte ou de l’utilisateur.

OWNERSHIP

Permet d’accorder un contrôle total sur la politique de session. Nécessaire pour modifier la plupart des propriétés d’une politique de session.

Résumé des commandes, des opérations et des privilèges DDL

Le tableau suivant résume la relation entre les opérations DDL de politique de session et leurs privilèges nécessaires.

Fonctionnement

Privilège requis

Créer une politique de session

Un rôle avec le privilège CREATE SESSION POLICY sur le schéma.

Modifier une politique de session

Un rôle avec le privilège OWNERSHIP sur la politique de session.

Détruire la politique de session

Un rôle avec le privilège OWNERSHIP sur la politique de session.

Décrire la politique de session

Un rôle avec le privilège OWNERSHIP sur la politique de session ou . le privilège APPLY SESSION POLICY sur le compte.

Afficher les politiques de session

Un rôle avec le privilège OWNERSHIP sur la politique de session ou . le privilège APPLY SESSION POLICY sur le compte.

Définir et annuler une politique de session

Pour les comptes, un rôle avec le privilège APPLY SESSION POLICY sur le compte et le privilège OWNERSHIP sur la politique de session, ou un rôle avec le privilège APPLY SESSION POLICY sur le compte et le privilège APPLY ON SESSION POLICY sur une politique de session spécifique.

Pour les utilisateurs, un rôle avec le privilège APPLY SESSION POLICY sur USER <nom_utilisateur>.

Référence DDL de politique de session

Snowflake fournit les commandes DDL suivantes pour gérer les objets de politique de session.

Pour définir ou désactiver une politique de session sur le compte, exécutez la commande ALTER ACCOUNT comme indiqué ci-dessous.

ALTER ACCOUNT SET SESSION POLICY mydb.policies.session_policy_prod_1;
Copy
ALTER ACCOUNT UNSET SESSION POLICY;
Copy

Pour définir ou désactiver une politique de session au niveau de l’utilisateur, exécutez la commande ALTER USER comme indiqué ci-dessous.

ALTER USER jsmith SET SESSION POLICY mydb.policies.session_policy_prod_1_jsmith;
Copy
ALTER USER jsmith UNSET SESSION POLICY;
Copy

Dépannage des politiques de session

  • Si une politique de session est affectée à un compte ou à un utilisateur et que la base de données ou le schéma qui contient la politique de session est détruit, puis qu’une nouvelle politique de session est affectée au compte ou à l’utilisateur, l’utilisateur ne sera pas tenu de respecter la ou les valeurs du délai d’expiration d’une session inactive de la nouvelle politique de session.

    La solution de contournement consiste à annuler la politique de session d’origine du compte à l’aide d’une commande ALTER ACCOUNT ou de l’utilisateur à l’aide d’une commande ALTER USER comme indiqué dans ce chapitre.

  • Le tableau suivant résume certains messages d’erreur qui peuvent se produire avec les politiques de session.

    Comportement

    Message d’erreur

    Action de dépannage

    Impossible de créer une politique de session.

    Impossible d’exécuter CREATE SESSION POLICY. Cette session ne dispose pas d’une base de données actuelle. Appelez « USE DATABASE » ou utilisez un nom qualifié.

    Spécifiez une base de données avant d’exécuter CREATE SESSION POLICY ou utilisez le nom d’objet entièrement qualifié dans l’instruction CREATE SESSION POLICY.

    Impossible de créer une politique de session.

    Erreur de contrôle d’accès SQL : privilèges insuffisants pour effectuer des opérations sur le schéma « <nom_schéma> »

    Vérifiez que le rôle qui exécute l’instruction CREATE SESSION POLICY possède le privilège CREATE SESSION POLICY sur SCHEMA.

    Impossible de créer une politique de session.

    Erreur de compilation SQL : la base de données « <nom_base_de_données> » n’existe pas ou n’est pas autorisée.

    Vérifiez que la base de données existe et que le rôle qui exécute l’instruction CREATE SESSION POLICY possède le privilège USAGE sur le schéma dans lequel la politique de session doit exister.

    Impossible d’exécuter une instruction de description.

    Erreur de compilation SQL : le schéma « <nom_schéma> » n’existe pas ou n’est pas autorisé.

    Vérifiez que le rôle qui exécute l’instruction DESC SESSION POLICY possède le privilège OWNERSHIP sur la politique de session ou le privilège APPLY sur la politique de session.

    Impossible de détruire une politique de session.

    Erreur de compilation SQL : la politique de session « <nom_politique> » n’existe pas ou n’est pas autorisée.

    Vérifiez que le rôle qui exécute l’instruction DROP SESSION POLICY possède le privilège OWNERSHIP sur la politique de session.

    Impossible de détruire une politique de session.

    La politique de session <nom_politique> ne peut pas être détruite, car elle est associée à un compte.

    Annulez la politique de session du compte avec une instruction ALTER ACCOUNT et relancez l’instruction de suppression.

    Impossible de définir une politique de session sur un compte.

    La politique de session « <nom_politique> » est déjà associée au compte « <nom_compte> ».

    Un compte ne peut avoir qu’une seule politique de session active. Déterminez quelle politique de session doit être définie pour le compte. . Si nécessaire, annulez la politique de session actuelle du compte avec une commande ALTER ACCOUNT ; puis définissez l’autre politique de session sur le compte avec une autre commande ALTER ACCOUNT.

    Impossible de définir une valeur de délai d’expiration.

    Erreur de compilation SQL : valeur non valide « <entier> » pour la propriété « session_idle_timeout_mins ».

    La valeur du délai d’attente de la session, en minutes, doit être un nombre entier compris entre 5 et 240, inclus. . Choisissez un nombre entier valide pour le délai d’expiration de session et exécutez à nouveau l’instruction CREATE ou ALTER SESSION POLICY.

    Impossible de mettre à jour une politique de session existante.

    Erreur de compilation SQL : la politique de session « <nom_politique> » n’existe pas ou n’est pas autorisée.

    Vérifiez le nom de la politique de session, la syntaxe de la commande ALTER SESSION POLICY et les privilèges permettant d’agir sur la politique de session, la base de données et le schéma.