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 le compte client, dans lequel résident les objets USER, ROLE, WAREHOUSE et DATABASE. Tous les autres objets sécurisables (par exemple TABLE, FUNCTION, FILE, FORMAT, STAGE, SEQUENCE, etc.) sont contenus dans un objet SCHEMA à l’intérieur d’une DATABASE. Cette hiérarchie d’objets et de conteneurs est illustrée ci-dessous :

Hierarchy of securable database objects

Chaque objet sécurisable est détenu par un rôle unique qui correspond généralement 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 sécurisable. 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.

L’accès aux objets est défini par les privilèges accordés aux rôles. Voici des exemples de privilèges 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.

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.

Il y a un petit nombre de rôles définis par le système dans un compte Snowflake. Les utilisateurs disposant d’un accès approprié peuvent modifier les rôles définis par le système et peuvent également créer des rôles personnalisés.

Rôles définis par le système

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 et gérer des utilisateurs et des rôles dans le compte (en supposant que la propriété de ces rôles ou utilisateurs n’a pas été transférée à un autre rôle).

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 les rôles SECURITYADMIN ainsi que par tout rôle auquel le privilège CREATE ROLE a été accordé. Par défaut, le 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 dans le système, nous vous recommandons 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 aux rôles SECURITYADMIN ou ACCOUNTADMIN.

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é (généralement uniquement le rôle SECURITYADMIN) verront les objets et pourront modifier leurs droits d’accè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 le privilège SELECT sur toutes les nouvelles tables créées dans le schéma myschema.

Les privilèges sont gérés à l’aide des commandes GRANT et REVOKE.

  • 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 aux rôles qui ont le privilège global MANAGE GRANTS sur l’objet (généralement, le rôle SECURITYADMIN).

  • Dans les schémas d’accès géré, les propriétaires d’objets perdent la capacité de prendre des décisions d’attribution. Seul le propriétaire du schéma ou un rôle disposant 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 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

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

Chaque session utilisateur active possède un « rôle actuel ». 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 éléments 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é.

Au cours d’une session, l’utilisateur peut utiliser la commande USE ROLE pour modifier le rôle actuel. Si le rôle se voit accorder d’autres rôles, la session de l’utilisateur dispose de privilèges égaux à la somme des privilèges du rôle actuel et de tous les privilèges des rôles accordés au rôle actuel dans la hiérarchie des rôles.

Lorsqu’un utilisateur tente d’exécuter une action sur un objet, Snowflake compare les privilèges disponibles dans la session de l’utilisateur aux privilèges requis sur l’objet pour cette action. Si la session possède les privilèges requis sur l’objet, 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.