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 opérer sur tous les objets du compte, voir et gérer les données de facturation et de crédit de Snowflake, et arrêter les instructions SQL en cours.

Dans la hiérarchie du contrôle d’accès par défaut, 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.

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.

Évitez 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.

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

Autorisations

Description

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;
    
  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;
    
  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;
    
  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;
    
  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;
    

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.

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.

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.