Aperçu du contrôle d’accès

Les privilèges de contrôle d’accès déterminent qui peut accéder et effectuer des opérations sur des objets spécifiques dans Snowflake.

Dans ce chapitre :

Structure du contrôle d’accès

L’approche de Snowflake en matière de contrôle d’accès combine les aspects des deux modèles suivants :

  • Contrôle d’accès discrétionnaire (DAC) : chaque objet a un propriétaire qui peut à son tour accorder l’accès à cet objet.

  • Contrôle d’accès basé sur les rôles (RBAC) : les privilèges d’accès sont assignés aux rôles, qui sont à leur tour assignés aux utilisateurs.

Les concepts clés pour comprendre le contrôle d’accès dans Snowflake sont les suivants :

  • Objet sécurisable : une entité à laquelle l’accès peut être accordé. À moins qu’une attribution ne le permette, l’accès sera refusé.

  • Rôle : une entité à laquelle des privilèges peuvent être accordés. Les rôles sont à leur tour assignés aux utilisateurs. Notez que les rôles peuvent également être affectés à d’autres rôles, créant ainsi une hiérarchie des rôles.

  • Privilège : un niveau défini d’accès à un objet. Plusieurs privilèges distincts peuvent être utilisés pour contrôler la granularité de l’accès accordé.

  • Utilisateur : une identité d’utilisateur reconnue par Snowflake, qu’elle soit associée à une personne ou à un programme.

Dans le modèle Snowflake, l’accès aux objets sécurisables est permis via des privilèges affectés à des rôles, qui sont à leur tour affectés à d’autres rôles ou utilisateurs. En outre, chaque objet sécurisable a un propriétaire qui peut autoriser l’accès à d’autres rôles. Ce modèle est différent d’un modèle de contrôle d’accès basé sur les utilisateurs, dans lequel les droits et privilèges sont attribués à chaque utilisateur ou groupe d’utilisateurs. Le modèle Snowflake est conçu pour offrir un degré important de contrôle et de flexibilité.

Access control relationships

Objets sécurisables

Chaque objet sécurisable réside dans un conteneur logique dans une hiérarchie de conteneurs. Le conteneur le plus haut est l’organisation client. Les objets sécurisables tels que les tables, les vues, les fonctions et les zones de préparation sont contenus dans un objet schéma, qui est à son tour contenu dans une base de données. Toutes les bases de données de votre compte Snowflake sont contenues dans l’objet de compte. Cette hiérarchie d’objets et de conteneurs est illustrée ci-dessous :

Hierarchy of securable database objects

Posséder un objet signifie qu’un rôle possède le OWNERSHIP privilège sur cet objet. Chaque objet sécurisable est détenu par un rôle unique qui correspond par défaut au rôle utilisé pour créer l’objet. Lorsque ce rôle est attribué aux utilisateurs, ils ont effectivement un contrôle partagé sur l’objet. Dans un schéma standard, le rôle de propriétaire possède tous les privilèges sur l’objet par défaut, y compris la possibilité d’accorder ou de révoquer des privilèges sur l’objet à d’autres rôles. De plus, la propriété peut être transférée d’un rôle à un autre. Cependant, 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.

La possibilité d’effectuer des actions SQL sur des objets est définie par les privilèges accordés au rôle actif dans une session utilisateur. Voici des exemples d’actions SQL disponibles sur divers objets dans Snowflake :

  • Possibilité de créer un entrepôt.

  • Possibilité de répertorier les tables contenues dans un schéma.

  • Possibilité d’ajouter des données à une table.

Rôles

Les rôles sont les entités auxquelles des privilèges sur des objets sécurisables peuvent être accordés et révoqués. Des rôles sont attribués aux utilisateurs pour leur permettre d’effectuer les actions requises pour les fonctions de l’entreprise dans leur organisation. Un utilisateur peut se voir attribuer plusieurs rôles. Cela permet aux utilisateurs de changer de rôle (c.-à-d. de choisir le rôle actif dans la session Snowflake en cours) pour effectuer différentes actions en utilisant des ensembles de privilèges distincts.

Il y a un petit nombre de rôles définis par le système dans un compte Snowflake. Les rôles définis par le système ne peuvent pas être détruits. En outre, les privilèges accordés à ces rôles par Snowflake ne peuvent pas être révoqués.

Les utilisateurs qui se sont vu attribuer un rôle avec les privilèges nécessaires peuvent créer des rôles personnalisés pour répondre à des besoins commerciaux et des besoins de sécurité spécifiques.

Les rôles peuvent également être attribués à d’autres rôles, créant ainsi une hiérarchie des rôles. Les privilèges associés à un rôle sont hérités par tous les rôles situés au-dessus de ce rôle dans la hiérarchie. Pour plus d’informations sur les hiérarchies de rôles et l’héritage de privilèges, consultez Hiérarchie des rôles et héritage des privilèges (dans ce chapitre).

Bien que des privilèges supplémentaires puissent être accordés aux rôles définis par le système, ce n’est pas recommandé. Les rôles définis par le système sont créés avec des privilèges liés à la gestion des comptes. Nous déconseillons de mélanger les privilèges de gestion de compte et les privilèges spécifiques à l’entité dans le même rôle. Si des privilèges supplémentaires sont nécessaires, Snowflake recommande d’accorder ces privilèges à un rôle personnalisé et d’affecter ce rôle personnalisé au rôle défini par le système.

Rôles définis par le système

ORGADMIN

(alias Administrateur de l’organisation)

Rôle qui gère les opérations au niveau de l’organisation. Plus précisément, ce rôle :

ACCOUNTADMIN

(alias Administrateur de compte)

Rôle qui encapsule les rôles définis par le système SYSADMIN et SECURITYADMIN. Il s’agit du rôle de premier niveau dans le système et ne devrait être accordé qu’à un nombre limité/contrôlé d’utilisateurs dans votre compte.

SECURITYADMIN

(alias Administrateur de sécurité)

Rôle qui peut gérer globalement n’importe quelle attribution d’objet, ainsi que créer, surveiller et gérer des utilisateurs et des rôles. Plus précisément, ce rôle :

  • Obtient le privilège de sécurité MANAGE GRANTS pour pouvoir modifier n’importe quelle autorisation, y compris la révoquer.

  • Hérite des privilèges du rôle USERADMIN via la hiérarchie des rôles système (par exemple, le rôle USERADMIN est accordé à SECURITYADMIN).

USERADMIN

(alias Administrateur d’utilisateurs et de rôles)

Rôle dédié uniquement à la gestion des utilisateurs et des rôles. Plus précisément, ce rôle :

  • Obtient les privilèges de sécurité CREATE USER et CREATE ROLE.

  • Peut créer des utilisateurs et des rôles dans le compte.

    Ce rôle peut également gérer les utilisateurs et les rôles qui lui appartiennent. Seul le rôle doté du privilège OWNERSHIP sur un objet (c’est-à-dire l’utilisateur ou le rôle), ou un rôle supérieur, peut modifier les propriétés de l’objet.

SYSADMIN

(alias Administrateur système)

Rôle qui a les privilèges pour créer des entrepôts et des bases de données (et d’autres objets) dans un compte.

Si, en tant que recommandé, vous créez une hiérarchie de rôles qui affecte tous les rôles personnalisés au rôle SYSADMIN , ce rôle a également la possibilité d’accorder des privilèges sur les entrepôts, les bases de données et d’autres objets à d’autres rôles.

PUBLIC

Pseudo-rôle qui est automatiquement attribué à chaque utilisateur et à chaque rôle de votre compte. Le rôle PUBLIC peut posséder des objets sécurisables, comme n’importe quel autre rôle. Cependant, les objets appartenant au rôle sont, par définition, disponibles pour tous les autres utilisateurs et rôles dans votre compte.

Ce rôle est généralement utilisé dans les cas où un contrôle d’accès explicite n’est pas nécessaire et où tous les utilisateurs sont considérés comme égaux en ce qui concerne leurs droits d’accès.

Rôles personnalisés

Les rôles personnalisés (c’est-à-dire les rôles autres que les rôles définis par le système) peuvent être créés par le rôle USERADMIN (ou un rôle supérieur) ainsi que par tout rôle auquel le privilège CREATE ROLE a été accordé. Par défaut, un rôle nouvellement créé n’est affecté à aucun utilisateur ni accordé à aucun autre rôle.

Lorsque vous créez des rôles qui serviront de propriétaires d’objets sécurisables dans le système, Snowflake recommande de créer une hiérarchie des rôles personnalisés, en attribuant le rôle personnalisé le plus élevé au rôle système SYSADMIN. Cette structure de rôles permet aux administrateurs système de gérer tous les objets du compte, tels que les entrepôts et les objets de base de données, tout en limitant la gestion des utilisateurs et des rôles au rôle USERADMIN.

Inversement, si un rôle personnalisé n’est pas affecté à SYSADMIN via une hiérarchie de rôles, les administrateurs système ne pourront pas gérer les objets appartenant au rôle. Seuls les rôles auxquels le privilège MANAGE GRANTS a été accordé (uniquement le rôle SECURITYADMIN par défaut) peuvent visualiser les objets et modifier leurs droits d’accès.

Pour des instructions sur la création de rôles personnalisés, voir Création de rôles personnalisés.

Privilèges

Pour chaque objet sécurisable, il existe un ensemble de privilèges qui peuvent lui être accordés. Pour les objets existants, des privilèges doivent être accordés sur des objets individuels (par exemple, le privilège SELECT sur la table mytable). Pour simplifier la gestion des autorisations, les autorisations futures permettent de définir un ensemble initial de privilèges sur des objets créés dans un schéma (c’est-à-dire l’octroi du privilège SELECT sur toutes les nouvelles tables créées dans le schéma myschema à un rôle spécifié).

Les privilèges sont gérés à l’aide des commandes GRANT <privileges> … TO ROLE et REVOKE <privileges> … FROM ROLE.

  • Dans des schémas classiques (c’est-à-dire non gérés), l’utilisation de ces commandes est limitée au rôle qui possède un objet (c’est-à-dire qui a le privilège OWNERSHIP sur l’objet) ou à tout rôle ayant le privilège global MANAGE GRANTS sur l’objet (uniquement le rôle SECURITYADMIN par défaut).

  • Dans les schémas d’accès gérés, les propriétaires d’objet ne peuvent plus prendre de décision. Seuls le propriétaire du schéma ou un rôle disposant du privilège MANAGE GRANTS peuvent 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 de détails, voir Privilèges de contrôle d’accès.

Hiérarchie des rôles et héritage des privilèges

Le schéma suivant illustre la hiérarchie des rôles définis par le système ainsi que la structure recommandée pour les rôles personnalisés supplémentaires définis par l’utilisateur :

../_images/system-role-hierarchy.png

Note

ORGADMIN est un rôle système distinct qui gère les opérations au niveau de l’organisation. Ce rôle n’est pas inclus dans la hiérarchie des rôles du système.

Pour un exemple plus spécifique de hiérarchie des rôles et d’héritage des privilèges, imaginez le scénario suivant :

  • Le rôle 3 a été attribué au rôle 2.

  • Le rôle 2 a été attribué au rôle 1.

  • Le rôle 1 a été attribué à l’utilisateur 1.

Privilege inheritance for granted roles

Dans ce scénario :

  • Le rôle 2 hérite du privilège C.

  • Le rôle 1 hérite des privilèges B et C.

  • L’utilisateur 1 a les trois privilèges.

Modèle d’application : le rôle primaire et les rôles secondaires

Chaque session d’utilisateur active possède un « rôle actuel », également appelé rôle primaire. Lorsqu’une session est lancée (par exemple, un utilisateur se connecte via JDBC/ODBC ou se connecte à l’interface Web de Snowflake), le rôle actuel est déterminé en fonction des critères suivants :

  1. Si un rôle a été spécifié comme faisant partie de la connexion et que ce rôle est un rôle qui a déjà été accordé à l’utilisateur qui se connecte, le rôle spécifié devient le rôle actuel.

  2. Si aucun rôle n’a été spécifié et qu’un rôle par défaut a été défini pour l’utilisateur qui se connecte, ce rôle devient le rôle actuel.

  3. Si aucun rôle n’a été spécifié et qu’aucun rôle par défaut n’a été défini pour l’utilisateur connecté, le rôle système PUBLIC est utilisé.

En outre, un ensemble de rôles secondaires peut être activé dans une session utilisateur. Un utilisateur peut effectuer des actions SQL sur des objets dans une session en utilisant l’ensemble des privilèges accordés aux rôles primaire et secondaire. Les rôles doivent être accordés à l’utilisateur avant de pouvoir être activés dans une session. Notez que si une session doit avoir exactement un rôle primaire actif à la fois, on peut activer un nombre quelconque de rôles secondaires en même temps.

L’autorisation d’exécuter les instructions CREATE <objet> provient uniquement du rôle primaire. Lorsqu’un objet est créé, son propriétaire est le rôle primaire actif actuel. Cependant, pour toute autre action SQL, toute autorisation accordée à tout rôle primaire ou secondaire actif peut être utilisée pour autoriser l’action. Par exemple, si un rôle dans une hiérarchie de rôles secondaires possède un objet (c’est-à-dire qu’il a le privilège OWNERSHIP sur cet objet), les rôles secondaires autoriseront l’exécution de toute action DDL sur cet objet. Le rôle primaire ainsi que tous les rôles secondaires héritent des privilèges de tous les rôles inférieurs dans leurs hiérarchies de rôles.

Primary and Secondary Role Operations

Pour les organisations dont le modèle de sécurité comprend un grand nombre de rôles, chacun avec une granularité fine d’autorisation via des autorisations, l’utilisation de rôles secondaires simplifie la gestion des rôles. Tous les rôles qui ont été accordés à un utilisateur peuvent être activés dans une session. Les rôles secondaires sont particulièrement utiles pour les opérations SQL telles que les jointures entre bases de données qui, autrement, nécessiteraient la création d’un rôle parent des rôles qui ont les autorisations d’accéder aux objets de chaque base de données.

Au cours d’une session, l’utilisateur peut utiliser la commande USE ROLE ou USE SECONDARY ROLES pour modifier le rôle primaire actuel ou les rôles secondaires, respectivement. L’utilisateur peut utiliser la fonction CURRENT_SECONDARY_ROLES pour afficher tous les rôles secondaires actifs pour la session en cours.

Lorsqu’un utilisateur tente de créer un objet, Snowflake compare les privilèges disponibles pour le rôle actuel dans la session de l’utilisateur avec les privilèges requis pour créer l’objet. Pour toute autre action SQL tentée par l’utilisateur, Snowflake compare les privilèges disponibles pour les rôles primaires et secondaires actuels aux privilèges requis pour exécuter l’action sur les objets cibles. Si la session possède les privilèges requis sur les objets, l’action est autorisée.

Note

Il n’existe pas de concept de « super utilisateur » ou de « super rôle » dans Snowflake qui puisse contourner les contrôles d’autorisation. Tout accès nécessite des privilèges d’accès correspondants.