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 (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 visualiser et opérer sur tous les objets du compte, visualiser 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 de contrôle d’accès par défaut, les deux autres rôles d’administrateur appartiennent à ce rôle :

  • Le rôle d’administrateur de sécurité (SECURITYADMIN) inclut les privilèges pour créer et gérer les utilisateurs et les rôles.

  • 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 alimenté, 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 SECURITYADMIN. Tous les autres utilisateurs doivent être créés par le(s) utilisateur(s) ayant le rôle SECURITYADMIN.

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 de la hiérarchie des rôles et de l’héritage des privilèges 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 privilèges accordés aux rôles de niveau inférieur sont hérités des rôles de niveau supérieur.

Par exemple, supposons que deux bases de données, d1 et d2, contiennent les données requises par les analystes de votre entreprise. Selon leurs responsabilités fonctionnelles, les analystes débutant devraient avoir un accès en lecture seule à d1, tandis que l’accès à d2 devrait être limité aux analystes avancés. Une approche recommandée pour configurer la sécurité de ces bases de données consiste à créer une combinaison de rôles d’accès aux objets et de rôles de fonction métier pour un contrôle optimal.

Note

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

Pour configurer l’accès dans cet exemple :

  1. En tant qu’administrateur de sécurité (utilisateur doté du rôle SECURITYADMIN) ou d’un autre rôle doté du privilège CREATE ROLE sur le compte, créez des rôles analyst_basic et analyst_adv. 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 aux objets requis pour ces fonctions. Étant donné que les fonctions d’analyste de base sont également requises par les analystes avancés, attribuez le rôle analyst_basic au rôle analyst_adv.

    En suivant les bonnes pratiques relatives aux hiérarchies de rôles, attribuez analyst_adv 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.

    CREATE ROLE analyst_basic;
    CREATE ROLE analyst_adv;
    
    GRANT ROLE analyst_basic TO ROLE analyst_adv;
    GRANT ROLE analyst_adv TO ROLE sysadmin;
    
  2. En utilisant le même rôle qu’à l’étape 1, créez des rôles d’accès aux objets db1_read_only et db2_read_only, et attribuez ces rôles aux rôles de fonction métier qui en ont besoin. Dans ce cas, attribuez le rôle db1_read_only au rôle analyst_basic et le rôle db2_read_only au rôle analyst_adv.

    CREATE ROLE db1_read_only;
    CREATE ROLE db2_read_only;
    
    GRANT ROLE db1_read_only TO ROLE analyst_basic;
    GRANT ROLE db2_read_only TO ROLE analyst_adv;
    
  3. 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 l’accès en lecture seule db1_read_only et db2_read_only aux bases de données d1 et d2, respectivement. Pour plus d’informations, voir Création de rôles en lecture seule. Ces rôles définissent un ensemble d’attributions pour accéder aux objets de données.

    GRANT <privileges> TO ROLE db1_read_only;
    GRANT <privileges> TO ROLE db2_read_only;
    
  4. 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 de fonction métier aux utilisateurs exécutant ces fonctions :

    GRANT ROLE analyst_basic TO USER user1;
    GRANT ROLE analyst_adv TO USER user2;
    

Les privilèges accordés aux rôles d’accès d’objet de niveau inférieur (dans la hiérarchie des rôles) db1_read_only et db2_read_only sont hérités par les rôles de fonction métier de niveau supérieur analyst_basic et analyst_adv, respectivement. De plus, étant donné que analyst_basic est attribué à analyst_adv, tout privilège accordé à db1_read_only ou analyst_basic est hérité par analyst_adv.

../_images/role-hierarchy-practical.png

Les utilisateurs auxquels le rôle analyst_adv a été attribué peuvent accéder aux rôles db1 et db2. Cependant, les utilisateurs auxquels le rôle analyst_basic a été attribué ne peuvent accéder qu’à db1.

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.