Meilleures pratiques liées au contrôle d’accès¶

Utilisation du rôle ACCOUNTADMIN¶

Le rôle d’administrateur de compte (utilisateurs ayant le rôle système ACCOUNTADMIN) est le rôle le plus puissant du système. Seul ce rôle est responsable de la configuration des paramètres au niveau du compte. Les utilisateurs ayant le rôle ACCOUNTADMIN peuvent voir et gérer les données de facturation et de crédit de Snowflake, et arrêter les instructions SQL en cours.

Notez que ACCOUNTADMIN n’est pas un rôle de superutilisateur. Ce rôle ne permet de visualiser et de gérer les objets du compte que si ce rôle, ou un rôle inférieur dans une hiérarchie de rôles, dispose de privilèges suffisants sur les objets.

Dans la hiérarchie des rôles système, les autres rôles d’administrateur sont les enfants de ce rôle :

• Le rôle d’administrateur des utilisateurs (USERADMIN) comprend les privilèges permettant de créer et de gérer des utilisateurs et des rôles (en supposant que la propriété de ces rôles ou de ces utilisateurs n’a pas été transférée à un autre rôle).

• Le rôle d’administrateur de sécurité (SECURITYADMIN défini par le système) comprend le privilège global MANAGE GRANTS permettant d’accorder ou de révoquer des privilèges sur les objets du compte. Le rôle USERADMIN est un enfant de ce rôle dans la hiérarchie de contrôle d’accès par défaut. Pour plus d’informations sur les rôles définis par le système pour les enfants, voir Rôles définis par le système.

• Le rôle d’administrateur système (SYSADMIN) comprend les privilèges permettant de créer des entrepôts, des bases de données et tous les objets de la base de données (schémas, tables, etc.).

Accès aux objets de base de données¶

Tous les objets de base de données pouvant être sécurisés (tels que TABLE, FUNCTION, FILE FORMAT, STAGE, SEQUENCE, etc.) sont contenus dans un objet SCHEMA dans une DATABASE. Par conséquent, pour accéder aux objets de base de données, en plus des privilèges sur les objets de base de données spécifiques, les utilisateurs doivent se voir accorder le privilège USAGE sur la base de données et le schéma de conteneur.

Par exemple, supposons que mytable soit créé dans mydb.myschema. Pour pouvoir interroger mytable, un utilisateur doit avoir au minimum les privilèges suivants :

Base de données:

USAGE sur mydb

Schéma:

USAGE sur myschema

Table:

SELECT sur mytable

Gestion des rôles personnalisés¶

Lorsqu’un rôle personnalisé est créé pour la première fois, il existe de manière isolée. Le rôle doit être affecté à tous les utilisateurs qui utiliseront les privilèges d’objet associés au rôle. Le rôle personnalisé doit également être attribué à tous les rôles qui gèrent les objets créés par le rôle personnalisé.

Pour obtenir des instructions de création d’une hiérarchie de rôles, voir Création d’une hiérarchie de rôles.

Alignement de l’accès aux objets avec les fonctions métier¶

Profitez des hiérarchies de rôle pour aligner l’accès aux objets de base de données avec les fonctions métier de votre entreprise. Dans une hiérarchie des rôles, les rôles sont attribués à d’autres rôles pour former une relation d’héritage. Les autorisations accordées aux rôles de niveau inférieur sont hérités des rôles de niveau supérieur.

Pour une flexibilité optimale dans le contrôle de l’accès aux objets de base de données, créez une combinaison de rôles d’accès aux objets avec différentes autorisations sur les objets et attribuez-les comme il convient aux rôles fonctionnels :

• Accordez des autorisations sur les objets de la base de données ou les objets du compte (tels que les entrepôts) aux rôles d’accès.

• Accordez des rôles d’accès aux rôles fonctionnels afin de créer une hiérarchie de rôles. Ces rôles correspondent aux fonctions métier de votre entreprise et servent d’éléments « fourre-tout » pour tous les rôles d’accès requis pour ces fonctions.

  Le cas échéant, accordez des rôles fonctionnels de niveau inférieur à des rôles fonctionnels de niveau supérieur dans le cadre d’une relation parent-enfant où les rôles parents correspondent à aux fonctions métier qui doivent englober les autorisations des rôles enfants.

  En suivant les bonnes pratiques pour les hiérarchies de rôles, accordez les rôles fonctionnels de plus haut niveau dans une hiérarchie de rôles au rôle d’administrateur système (SYSADMIN). Les administrateurs système peuvent alors accorder des privilèges sur les objets de base de données à n’importe quel rôle dans cette hiérarchie.

Exemple¶

À titre d’exemple simple, supposons que deux bases de données d’un compte, fin et hr, contiennent respectivement les données relatives aux salaires et aux employés. Les comptables et les analystes de votre organisation ont besoin de différentes autorisations sur les objets de ces bases de données afin d’exécuter leurs fonctions métier. Les comptables doivent avoir un accès en lecture-écriture à fin mais peuvent n’avoir besoin que d’un accès en lecture seule à hr car le personnel des ressources humaines gère les données de cette base de données. Les analystes pourraient exiger un accès en lecture seule aux deux bases de données.

Les autorisations sur les objets de base de données existants sont accordées via la hiérarchie suivante de rôles d’accès et de rôles fonctionnels :

Note

Lorsque de nouveaux objets sont ajoutés dans chaque base de données, envisagez d’accorder automatiquement des privilèges sur ces objets à des rôles basés sur le type d’objet (par exemple, schémas, tables ou vues). Pour plus d’informations, voir Simplifier la gestion des autorisations à l’aide des autorisations futures (dans ce chapitre).

Rôle personnalisé	Description	Privilèges
db_hr_r	Rôle d’accès qui permet un accès en lecture seule aux tables de la base de données hr.	USAGE sur la base de données hr. USAGE sur tous les schémas de la base de données hr. SELECT sur toutes les tables de la base de données hr.
db_fin_r	Rôle d’accès qui permet un accès en lecture seule aux tables de la base de données fin.	USAGE sur la base de données fin. USAGE sur tous les schémas de la base de données fin. SELECT sur toutes les tables de la base de données fin.
db_fin_rw	Rôle d’accès qui permet un accès en lecture-écriture aux tables de la base de données fin.	USAGE sur la base de données fin. USAGE sur tous les schémas de la base de données fin. SELECT, INSERT, UPDATE, DELETE sur toutes les tables de la base de données fin.
accountant	Rôle fonctionnel pour les comptables dans votre organisation.	N/A
analyst	Rôle fonctionnel pour les analystes dans votre organisation.	N/A

Le diagramme suivant montre la hiérarchie des rôles pour cet exemple :

Pour configurer le contrôle d’accès pour cet exemple :

1. En tant qu’administrateur des utilisateurs (utilisateur doté du rôle USERADMIN) ou d’un autre rôle doté du privilège CREATE ROLE sur le compte, créez les rôles d’accès et les rôles fonctionnels dans cet exemple :

   CREATE ROLE db_hr_r;
   CREATE ROLE db_fin_r;
   CREATE ROLE db_fin_rw;
   CREATE ROLE accountant;
   CREATE ROLE analyst;
   

   Copy

2. En tant qu’administrateur de sécurité (utilisateur doté du rôle SECURITYADMIN) ou d’un autre rôle doté du privilège MANAGE GRANTS sur le compte, accorez les autorisations minimum nécessaires à chacun des rôles d’accès :

   -- Grant read-only permissions on database HR to db_hr_r role.
   GRANT USAGE ON DATABASE hr TO ROLE db_hr_r;
   GRANT USAGE ON ALL SCHEMAS IN DATABASE hr TO ROLE db_hr_r;
   GRANT SELECT ON ALL TABLES IN DATABASE hr TO ROLE db_hr_r;
   
   -- Grant read-only permissions on database FIN to db_fin_r role.
   GRANT USAGE ON DATABASE fin TO ROLE db_fin_r;
   GRANT USAGE ON ALL SCHEMAS IN DATABASE fin TO ROLE db_fin_r;
   GRANT SELECT ON ALL TABLES IN DATABASE fin TO ROLE db_fin_r;
   
   -- Grant read-write permissions on database FIN to db_fin_rw role.
   GRANT USAGE ON DATABASE fin TO ROLE db_fin_rw;
   GRANT USAGE ON ALL SCHEMAS IN DATABASE fin TO ROLE db_fin_rw;
   GRANT SELECT,INSERT,UPDATE,DELETE ON ALL TABLES IN DATABASE fin TO ROLE db_fin_rw;
   

   Copy

3. En tant qu’administrateur de sécurité (utilisateur avec le rôle SECURITYADMIN) ou un autre rôle avec le privilège MANAGE GRANTS sur le compte, accordez le rôle d’accès db_fin_rw au rôle fonctionnel accountant, et accordez les rôles d’accès db_hr_r db_fin_r au rôle fonctionnel analyst :

   GRANT ROLE db_fin_rw TO ROLE accountant;
   GRANT ROLE db_hr_r TO ROLE analyst;
   GRANT ROLE db_fin_r TO ROLE analyst;
   

   Copy

4. En tant qu’administrateur de sécurité (utilisateur doté du rôle SECURITYADMIN) ou d’un autre rôle doté du privilège MANAGE GRANTS sur le compte, accordez les rôles analyst et accountant au rôle d’administrateur système (SYSADMIN) :

   GRANT ROLE accountant,analyst TO ROLE sysadmin;
   

   Copy

5. En tant qu’administrateur de sécurité (utilisateur ayant le rôle SECURITYADMIN) ou ayant un autre rôle avec le privilège MANAGE GRANTS sur le compte, attribuez les rôles fonctionnels métier aux utilisateurs exécutant ces fonctions métier dans votre organisation. Dans cet exemple, le rôle fonctionnel analyst est accordé à l’utilisateur user1, et le rôle fonctionnel accountant est accordé à l’utilisateur user2.

   GRANT ROLE accountant TO USER user1;
   GRANT ROLE analyst TO USER user2;
   

   Copy

Gestion de l’accès aux objets de la base de données à l’aide des rôles de la base de données¶

Les rôles de base de données sont essentiellement les mêmes que les rôles traditionnels créés au niveau du compte (rôles de compte personnalisés), à l’exception de leur champ d’application : pour permettre des actions SQL sur des objets au sein d’une base de données, des privilèges peuvent être accordés à un rôle de base de données dans la même base de données.

Les rôles de base de données sont destinés à satisfaire les cas d’utilisation suivants :

Facilité de gestion:

Les propriétaires de bases de données peuvent gérer de manière indépendante l’accès aux objets sécurisables au sein de leurs propres bases de données. Les propriétaires de la base de données peuvent effectuer les actions suivantes :

• Créer et gérer les rôles de la base de données.

• Accorder des privilèges aux rôles de la base de données.

  Les privilèges sur les objets accordés aux rôles de base de données doivent s’appliquer aux objets contenus dans la base de données où le rôle existe. Les privilèges sur les objets d’une base de données (tels que les tables ou les vues) ne peuvent pas être accordés aux rôles d’une autre base de données.

  Tout privilège, y compris OWNERSHIP, peut être accordé aux rôles de base de données sur les objets d’une base de données. Notez que seul un rôle de compte peut détenir le privilège OWNERSHIP sur la base de données elle-même.

• Créer ou étendre les hiérarchies de rôles. Accorder des rôles de base de données à d’autres rôles de base de données dans la même base de données, puis accorder les rôles de base de données de plus haut niveau dans une base de données à des rôles de compte. Pour plus d’informations, voir Hiérarchie des rôles et héritage des privilèges.

  Notez que l’octroi d’un rôle de base de données à un rôle de compte accorde implicitement le privilège USAGE sur la base de données qui contient le rôle de base de données à ce rôle de compte. Il n’est pas nécessaire d’accorder explicitement le privilège USAGE sur la base de données.

Partage de données:

Les fournisseurs de données dans Secure Data Sharing de Snowflake peuvent segmenter les objets sécurisables dans un partage en créant plusieurs rôles de base de données dans une base de données à partager et en accordant des privilèges sur un sous-ensemble d’objets de la base de données à chaque rôle de base de données. Après avoir créé une base de données à partir d’un partage qui inclut des rôles de base de données, les consommateurs de données accordent chaque rôle de base de données partagée à un ou plusieurs rôles de niveau compte dans leur propre compte.

Sans les rôles de base de données, les administrateurs de comptes de consommateurs de données accordent un privilège unique, IMPORTED PRIVILEGES, aux rôles pour permettre à leurs utilisateurs d’accéder à toutes les bases de données et à tous les objets de base de données (tables, vues sécurisées, etc.) d’un partage. Il n’y a pas d’option pour permettre à différents groupes d’utilisateurs dans un compte de consommateur de données d’accéder à un sous-ensemble d’objets partagés. Cette approche du tout ou rien oblige les fournisseurs de données à créer plusieurs partages pour accorder l’accès à différents objets dans les mêmes bases de données.

Notez que les rôles de base de données ne peuvent pas être activés directement dans une session. Accordez des rôles de base de données aux rôles de compte, qui peuvent être activés dans une session.

Centralisation de la gestion des subventions à l’aide de schémas d’accès gérés¶

Avec les schémas classiques (non gérés) d’une base de données, les propriétaires d’objets (rôles disposant du privilège OWNERSHIP sur un ou plusieurs objets) peuvent accorder l’accès à ces objets à d’autres rôles, avec la possibilité d’accorder en outre à ces rôles la capacité de gérer les autorisations d’objets.

Pour renforcer la sécurité des objets, envisagez d’utiliser des schémas d’accès gérés. Dans un schéma d’accès géré, les propriétaires d’objets perdent la capacité de prendre des décisions d’octroi. Seul le propriétaire du schéma (le rôle doté du privilège OWNERSHIP sur le schéma) ou un rôle doté du privilège MANAGE GRANTS peut octroyer des privilèges sur les objets du schéma, notamment des autorisations futures, centralisant ainsi la gestion des privilèges.

Notez qu’un rôle qui détient le privilège global MANAGE GRANTS peut accorder des privilèges supplémentaires au rôle actuel (concédant).

Pour plus d’informations sur les schémas d’accès gérés, voir Création de schémas d’accès gérés.

Simplifier la gestion des autorisations à l’aide des autorisations futures¶

Les autorisations futures permettent de définir un ensemble initial de privilèges sur des objets d’un certain type (par exemple, des tables ou des vues) dans un schéma spécifié. Lors de la création de nouveaux objets, les privilèges définis sont automatiquement attribués à un rôle, ce qui simplifie la gestion des autorisations.

Considérez le scénario suivant, dans lequel un privilège SELECT est attribué à un rôle particulier sur toutes les nouvelles tables créées dans le schéma. À une date ultérieure, il est décidé de révoquer le privilège de ce rôle et de lui attribuer un rôle différent. En utilisant les mots clés ON FUTURE pour les nouvelles tables et le mot clé ALL pour les tables existantes, quelques instructions SQL sont nécessaires pour accorder et révoquer des privilèges sur les tables nouvelles et existantes. Par exemple :

-- Grant the SELECT privilege on all new (future) tables in a schema to role R1
GRANT SELECT ON FUTURE TABLES IN SCHEMA s1 TO ROLE r1;

-- / Create tables in the schema /

-- Grant the SELECT privilege on all new tables in a schema to role R2
GRANT SELECT ON FUTURE TABLES IN SCHEMA s1 TO ROLE r2;

-- Grant the SELECT privilege on all existing tables in a schema to role R2
GRANT SELECT ON ALL TABLES IN SCHEMA s1 TO ROLE r2;

-- Revoke the SELECT privilege on all new tables in a schema (future grant) from role R1
REVOKE SELECT ON FUTURE TABLES IN SCHEMA s1 FROM ROLE r1;

-- Revoke the SELECT privilege on all existing tables in a schema from role R1
REVOKE SELECT ON ALL TABLES IN SCHEMA s1 FROM ROLE r1;

Pour plus d’informations sur les autorisations futures, voir Attribution d’autorisations futures sur des objets.

Affichage des résultats de requête¶

Un utilisateur ne peut pas afficher les résultats d’une requête exécutée par un autre utilisateur. Ce comportement est intentionnel. Pour des raisons de sécurité, seul l’utilisateur qui a exécuté une requête peut accéder aux résultats de la requête.

Comprendre les objets clonés et les privilèges accordés¶

Le clonage d’une base de données, d’un schéma ou d’une table crée une copie de l’objet source. L’objet cloné inclut une image des données présentes dans l’objet source lorsque le clone a été créé.

Un objet cloné est considéré comme un nouvel objet dans Snowflake. Tous les privilèges accordés sur l’objet source ne sont pas transférés vers l’objet cloné. Cependant, un objet de conteneur cloné (une base de données ou un schéma) conserve tous les privilèges accordés sur les objets contenus dans l’objet source. Par exemple, un schéma cloné conserve tous les privilèges accordés sur les tables, les vues, les UDFs et les autres objets du schéma source.

Pour plus de détails sur le clonage, voir Remarques relatives au clonage et CREATE <objet> … CLONE.

Comparaison et mise en contraste de RBAC avec UBAC¶

Le contrôle d’accès basé sur le rôle (RBAC) est la base du contrôle d’accès dans Snowflake. RBAC fournit, de par sa conception, une évolutivité et un contrôle centralisé. En utilisant RBAC, vous accordez des privilèges à des rôles, puis vous affectez des utilisateurs à ces rôles, ce qui simplifie l’administration, garantit la cohérence et facilite l’accès aux audits. RBAC est généralement recommandé pour les environnements de production et la gouvernance au niveau de l’entreprise. Le contrôle d’accès basé sur l’utilisateur (UBAC) est destiné à des cas d’utilisation tels que le développement privé et la collaboration.

Vous devriez envisager d’utiliser UBAC pour des scénarios collaboratifs, tels que la création d’applications Streamlit. Au cours d’un processus de développement collaboratif, le propriétaire d’un bien peut vouloir contrôler l’accès au bien avant de le partager avec un public plus large. UBAC complète RBAC en offrant la possibilité d’accorder des privilèges directement à des utilisateurs individuels. UBAC est particulièrement utile dans les scénarios qui bénéficient d’un modèle de contrôle d’accès plus granulaire.

UBAC ne confère pas de nouveaux niveaux de privilèges aux propriétaires d’objets. Si vous faites actuellement confiance aux propriétaires d’objets pour gérer l’accès à leurs objets à l’aide de rôles dans RBAC, l’utilisation d’UBAC ne modifie pas fondamentalement ce niveau de confiance. Les propriétaires d’objets ont déjà la possibilité d’accorder l’accès à n’importe quel rôle, y compris des rôles largement accessibles tels que PUBLIC. UBAC permet aux propriétaires d’objets d’accorder l’accès directement à des utilisateurs spécifiques. UBAC n’a pas d’incidence sur la performance des requêtes.

Éviter la prolifération des autorisations lors de l’utilisation d’UBAC¶

Pour empêcher les propriétaires d’objets d’accorder l’accès à ces derniers sans discernement, utilisez les schémas d’accès gérés. Les schémas d’accès gérés suppriment la possibilité pour les propriétaires d’objets d’accorder l’accès à d’autres rôles ou utilisateurs. Seuls les propriétaires de schémas ou un rôle disposant du privilège MANAGE GRANTS peuvent accorder des privilèges sur les objets d’un schéma d’accès géré. La prolifération des autorisations peut se produire lors de l’utilisation d’UBAC ou de RBAC. En dehors des schémas d’accès gérés, les propriétaires d’objets peuvent accorder l’accès à n’importe quel rôle d’un compte via RBAC, tout comme ils peuvent accorder des privilèges à n’importe quel utilisateur via UBAC.

Surveillance des privilèges de contrôle d’accès à votre compte¶

Vous pouvez contrôler les privilèges accordés aux rôles, aux utilisateurs et aux applications à l’aide de la vue GRANTS_TO_ROLES dans ACCOUNT_USAGE. Pour plus d’informations, voir Vue GRANTS_TO_ROLES.

Vous pouvez également surveiller les privilèges de contrôle d’accès de votre compte comme suit :

• Vue des autorisations directes accordées à tous les utilisateurs

• Affichage des autorisations directes à des utilisateurs spécifiques

• Vue de l’ensemble actuel des privilèges accordés sur un objet

• Vue des autorisations actuelles sur un schéma

• Vue des privilèges sur un schéma de base de données

• Vue de l’ensemble actuel des privilèges accordés à un rôle ou à un utilisateur

Par exemple, pour voir les autorisations directes accordées à tous les utilisateurs, exécutez la requête suivante :

SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.GRANTS_TO_ROLES
  WHERE granted_to = 'USER';

Par exemple, pour afficher les autorisations directes accordées à des utilisateurs spécifiques :

1. Exécutez la commande suivante pour afficher toutes les autorisations accordées à un utilisateur spécifique :

   SHOW GRANTS TO USER <user_name>;
   

   Copy

2. Filtrez le résultat de l’étape précédente pour n’afficher que les privilèges accordés directement à l’utilisateur, et non par l’intermédiaire de rôles :

   SELECT * FROM TABLE(RESULT_SCAN(LAST_QUERY_ID())
    WHERE "role" is null;
   

   Copy

Par exemple, pour voir l’ensemble actuel des privilèges accordés à un objet, vous pouvez exécuter la commande SHOW GRANTS.

Par exemple, pour afficher les autorisations actuelles sur un schéma, exécutez la commande suivante :

SHOW GRANTS ON SCHEMA <database_name>.<schema_name>;

Par exemple, pour voir les privilèges sur database_a.schema_1 qui ont été accordés dans Création de rôles personnalisés, exécutez la commande suivante :

SHOW GRANTS ON SCHEMA database_a.schema_1;

Snowflake renvoie les résultats suivants :

+-------------------------------+-----------------------+------------+----------------------+------------+--------------------------+--------------+---------------+
| created_on                    | privilege             | granted_on | name                 | granted_to | grantee_name             | grant_option | granted_by    |
|-------------------------------+-----------------------+------------+----------------------+------------+--------------------------+--------------+---------------|
| 2022-03-07 09:04:23.635 -0800 | USAGE                 | SCHEMA     | database_a.schema_1  | ROLE       | R1                       | false        | SECURITYADMIN |
+-------------------------------+-----------------------+------------+----------------------+------------+--------------------------+--------------+---------------+

Vous pouvez également exécuter la commande SHOW GRANTS pour voir l’ensemble actuel des privilèges accordés à :

• un rôle :

  SHOW GRANTS TO ROLE <role_name>;
  

  Copy

  par exemple, exécutez la commande suivante pour voir les privilèges accordés au rôle r1, créé en tant que rôle personnalisé :

  SHOW GRANTS TO ROLE r1;
  

  Copy

  Snowflake renvoie les résultats suivants :

  +-------------------------------+-----------+------------+----------------------+------------+--------------+--------------+---------------+
  | created_on                    | privilege | granted_on | name                 | granted_to | grantee_name | grant_option | granted_by    |
  |-------------------------------+-----------+------------+----------------------+------------+--------------+--------------+---------------|
  | 2022-03-07 09:08:43.773 -0800 | USAGE     | DATABASE   | D1                   | ROLE       | R1           | false        | SECURITYADMIN |
  | 2022-03-07 09:08:55.253 -0800 | USAGE     | SCHEMA     | D1.S1                | ROLE       | R1           | false        | SECURITYADMIN |
  | 2022-03-07 09:09:07.206 -0800 | SELECT    | TABLE      | D1.S1.T1             | ROLE       | R1           | false        | SECURITYADMIN |
  | 2022-03-07 09:08:34.838 -0800 | USAGE     | WAREHOUSE  | W1                   | ROLE       | R1           | false        | SECURITYADMIN |
  +-------------------------------+-----------+------------+----------------------+------------+--------------+--------------+---------------+
  

• un utilisateur :

  SHOW GRANTS TO USER <user_name>;
  

  Copy

  par exemple, exécutez la commande suivante pour voir les privilèges accordés à l’utilisateur user1 :

  SHOW GRANTS TO USER user1;
  

  Copy

  Snowflake renvoie les résultats suivants :

  +-------------------------------+-----------+------------+---------------------------+-----------+------------+--------------+--------------+---------------+
  | created_on                    | privilege | granted_on | name                      |  role     | granted_to | grantee_name | grant_option | granted_by    |
  |-------------------------------+-----------+------------+---------------------------+-----------+------------+--------------+------------------------------|
  | 2025-05-07 09:08:43.773 -0800 | USAGE     | DATABASE   | test_db                   | null      | USER       | user1        | false        | SECURITYADMIN |
  | 2025-05-07 09:08:55.253 -0800 | USAGE     | SCHEMA     | test_db.test_sch          | null      | USER       | user1        | false        | SECURITYADMIN |
  | 2025-05-07 09:08:55.253 -0800 | SELECT    | TABLE      | test_db.test_sch.test_tbl | null      | USER       | user1        | false        | SECURITYADMIN |
  | 2025-05-07 09:08:34.838 -0800 | USAGE     | WAREHOUSE  | test_wh                   | null      | USER       | user1        | false        | SECURITYADMIN |
  +-------------------------------+-----------+------------+---------------------------+-----------+------------+--------------+--------------+---------------+