Remarques relatives au contrôle d’accès

Ce chapitre fournit des pratiques exemplaires et des remarques importantes sur la gestion des accès sécurisés à votre compte Snowflake et aux données stockées sur votre compte. Plus particulièrement, il fournit des conseils généraux pour configurer le contrôle d’accès basé sur les rôles, ce qui limite l’accès aux objets en fonction du rôle de l’utilisateur.

Dans ce chapitre :

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.).

Attention

Par défaut, lorsque votre compte est en service, le premier utilisateur se voit attribuer le rôle ACCOUNTADMIN . Cet utilisateur doit ensuite créer un ou plusieurs utilisateurs supplémentaires auxquels est attribué le rôle USERADMIN. Tous les autres utilisateurs doivent être créés par le(s) utilisateur(s) ayant le rôle USERADMIN ou un autre rôle qui détient le privilège global CREATE USER.

Contrôle de l’attribution du rôle ACCOUNTADMIN à des utilisateurs

Nous recommandons fortement les précautions suivantes lors de l’attribution du rôle ACCOUNTADMIN aux à des utilisateurs :

  • Affectez ce rôle uniquement à un nombre sélectionné/limité de personnes dans votre entreprise.

  • Tous les utilisateurs auxquels le rôle ACCOUNTADMIN a été attribué doivent également être tenus d’utiliser l’authentification multifactorielle (MFA) pour se connecter (pour plus de détails, voir Configuration du contrôle d’accès).

  • Affectez ce rôle à au moins deux utilisateurs. Nous appliquons des procédures de sécurité strictes pour réinitialiser un mot de passe oublié ou perdu pour les utilisateurs ayant le rôle ACCOUNTADMIN. Ces procédures peuvent prendre jusqu’à deux jours ouvrables. Assigner le rôle ACCOUNTADMIN à plus d’un utilisateur évite d’avoir à passer par ces procédures car les utilisateurs peuvent réinitialiser leur mot de passe respectif.

Astuce

Il est également utile d’associer l’adresse e-mail d’une personne réelle aux utilisateurs ACCOUNTADMIN afin que l’assistance Snowflake sache qui contacter en cas d’urgence.

Éviter d’utiliser le rôle ACCOUNTADMIN pour créer des objets

Le rôle ACCOUNTADMIN est destiné à exécuter les tâches de configuration initiale dans le système et à gérer les objets et les tâches au niveau du compte de manière quotidienne. Dès lors, il ne doit pas être utilisé pour créer des objets dans votre compte, sauf si vous avez absolument besoin que ces objets aient le plus haut niveau d’accès sécurisé. Si vous créez des objets avec le rôle ACCOUNTADMIN et que vous voulez que les utilisateurs aient accès à ces objets, vous devez explicitement accorder des privilèges sur les objets aux rôles pour ces utilisateurs.

Au lieu de cela, nous vous recommandons de créer une hiérarchie de rôles alignés sur les fonctions de votre organisation et d’attribuer ces rôles au rôle SYSADMIN. Pour plus d’informations, voir Alignement de l’accès aux objets avec les fonctions métier dans cette rubrique.

Astuce

Pour empêcher les administrateurs de compte d’utiliser par inadvertance le rôle ACCOUNTADMIN pour créer des objets, attribuez-leur des rôles supplémentaires et désignez l’un de ces rôles par défaut (c’est-à-dire ne faites pas de ACCOUNTADMIN le rôle par défaut pour les utilisateurs du système).

Cela ne les empêche pas d’utiliser le rôle ACCOUNTADMIN pour créer des objets, mais cela les force à changer explicitement leur rôle à ACCOUNTADMIN chaque fois qu’ils se connectent. Cela peut les aider à prendre conscience de l’objet/la fonction des rôles dans le système et les encourager à adopter le rôle approprié pour exécuter une tâche donnée, en particulier lorsqu’ils ont besoin d’exécuter des tâches d’administrateur de compte.

Éviter d’utiliser le rôle ACCOUNTADMIN pour les scripts automatisés

Nous recommandons d’utiliser un rôle autre que ACCOUNTADMIN pour les scripts automatisés. Si, comme recommandé, vous créez une hiérarchie de rôles sous le rôle SYSADMIN, toutes les opérations sur les objets d’entrepôt et de base de données peuvent être effectuées à l’aide du rôle SYSADMIN ou des rôles inférieurs dans la hiérarchie. Les seules limitations que vous pouvez rencontrer est la création ou la modification d’utilisateurs ou de rôles. Ces opérations doivent être effectuées par un utilisateur ayant le rôle SECURITYADMIN ou un autre rôle avec suffisamment de privilèges d’objet.

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é.

Important

Par défaut, même le rôle ACCOUNTADMIN ne peut pas modifier ou détruire des objets créés par un rôle personnalisé. Le rôle personnalisé doit être attribué directement au rôle ACCOUNTADMIN ou, de préférence, à un autre rôle dans une hiérarchie avec le rôle SYSADMIN comme parent. Le rôle SYSADMIN est géré par le rôle ACCOUNTADMIN.

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.

Note

Il n’y a pas de différence technique entre un rôle d’accès aux objets et un rôle fonctionnel dans Snowflake. La différence réside dans la façon dont ils sont utilisés logiquement pour assembler et attribuer des ensembles d’autorisations à des groupes d’utilisateurs.

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 :

Example: Hierarchy of access and functional roles

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érarchie des rôles et héritage des privilèges. 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;
Copy

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.

Note

Ce comportement n’est pas connecté au modèle de contrôle d’accès Snowflake pour les objets. Même un utilisateur ayant le rôle ACCOUNTADMIN ne peut pas afficher les résultats d’une requête exécutée par un autre utilisateur.

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.