Remarques relatives au contrôle d’accès¶

Utilisation du rôle ACCOUNTADMIN¶

Le rôle d’administrateur de compte (c’est-à-dire les utilisateurs ayant le rôle 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 la sécurité (c’est-à-dire les utilisateurs ayant le rôle SECURITYADMIN) comprend le privilège global MANAGE GRANTS 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.

• Le rôle d’administrateur système (SYSADMIN) inclut les privilèges pour créer des entrepôts, des bases de données et tous les objets de 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 (c’est-à-dire les rôles de compte personnalisés), à l’exception de leur portée : pour autoriser 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 (par exemple, les tables ou les vues) ne peuvent pas être accordés aux rôles de base de données 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 autorisations à l’aide de schémas d’accès gérés¶

Avec des schémas standards (c’est-à-dire non gérés) dans une base de données, les propriétaires d’objets (rôles dotés du privilège OWNERSHIP sur un ou plusieurs objets) peuvent accorder l’accès de ces objets à d’autres rôles, avec la possibilité d’accorder à ces rôles la possibilité de gérer les octrois 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 (c’est-à-dire 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 (i.e. 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 (i.e. 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.