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

Cette rubrique fournit des informations sur les principales rubriques de contrôle d’accès 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 est 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 utilisateurs ou d’autres rôles. L’attribution d’un rôle à un autre rôle crée une hiérarchie des rôles, qui est expliquée dans la section Hiérarchie des rôles et héritage des privilèges (dans cette rubrique).

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

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 :

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. La commande GRANT OWNERSHIP vous permet de transférer la propriété d’un objet d’un rôle à un autre, y compris à des rôles de base de données. Cette commande spécifie également les objets sécurisables dans chaque conteneur.

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

Note

Le propriétaire d’un rôle (c’est-à-dire le rôle qui a le privilège OWNERSHIP sur le rôle) n’hérite pas des privilèges du rôle possédé. L’héritage des privilèges n’est possible qu’au sein d’une hiérarchie de rôles.

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.

Types de rôles¶

Les types de rôles suivants varient dans leur portée, ce qui permet aux administrateurs d’autoriser et de restreindre l’accès aux objets de votre compte.

Note

Sauf indication contraire dans la documentation du produit, le terme rôle fait référence à l’un ou l’autre type.

Rôles des comptes:

Pour autoriser des actions SQL sur tout objet de votre compte, accordez des privilèges sur l’objet à un rôle de compte.

Rôles de base de données:

Pour limiter les actions SQL à une seule base de données, ainsi qu’à tout objet de cette base de données, accordez des privilèges sur l’objet à un rôle de base de données dans la même base 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.

Pour plus d’informations sur les rôles de la base de données, reportez-vous à :

Hiérarchie des rôles et héritage des privilèges (dans cette rubrique)
Rôles et hiérarchies des rôles dans les bases de données (dans cette rubrique)
Gestion de l’accès aux objets de la base de données à l’aide des rôles de la base de données
Rôles de base de données dans la base de données partagée SNOWFLAKE.
CREATE <objet> … CLONE

Rôles des instances:

Pour autoriser l’accès à une instance d’une classe, accordez un rôle d’instance à un rôle de compte.

Une classe peut avoir un ou plusieurs rôles de classe avec des privilèges différents accordés à chaque rôle. Lorsqu’une instance d’une classe est créée, le(s) rôle(s) d’instance peut (peuvent) être attribué(s) à des rôles de compte afin d’accorder l’accès aux méthodes d’instance.

Notez que les rôles d’instances ne peuvent pas être activés directement dans une session. Accordez des rôles d’instances aux rôles de compte, qui peuvent être activés dans une session.

Pour plus d’informations, consultez Rôles des instances.

Rôles des applications:

Pour permettre aux consommateurs d’accéder aux objets d’une Snowflake Native App, le fournisseur crée le rôle d’application et lui accorde des privilèges dans le script de configuration.

Cependant, pour prendre en charge des fonctionnalités spécifiques à une fonction particulière, comme l’accès aux objets dont Snowflake est le propriétaire, Snowflake peut fournir un ou plusieurs rôles d’application système. Vous pouvez, à votre discrétion, attribuer des rôles d’application du système à des comptes.

Les rôles d’application du système sont abordés dans le contexte d’une fonction spécifique parce que cette fonction spécifique est le seul endroit où vous pouvez utiliser le(s) rôle(s) d’application système. Par exemple :

Budgets : Rôles d’application pour gérer le budget du compte.
Qualité des données et fonctions de métrique des données (DMFs) : Afficher les résultats de la DMF.

Rôles des services:: Pour permettre à un rôle d’accéder aux points de terminaison de service, attribuez-lui le rôle de service. Vous pouvez attribuer un rôle de service à un rôle de compte, à un rôle d’application ou à un rôle de base de données. Pour plus d’informations, voir Gestion de l’accès aux points de terminaison de service.

Rôles actifs¶

Les rôles actifs servent de source d’autorisation pour toute action entreprise par un utilisateur dans une session. Le rôle primaire et les rôles secondaires peuvent tous deux être activés dans une session utilisateur.

Un rôle devient un rôle actif de l’une des manières suivantes :

Lorsqu’une session est établie pour la première fois, le rôle par défaut et les rôles secondaires par défaut de l’utilisateur sont activés en tant que rôles primaire et secondaire de la session, respectivement.

Notez que les propriétés de connexion du client utilisées pour établir la session peuvent remplacer explicitement le rôle principal ou les rôles secondaires à utiliser.
L’exécution d’une instruction USE ROLE ou USE SECONDARY ROLES active un rôle primaire ou des rôles secondaires différents, respectivement. Ces rôles peuvent changer au cours d’une session si l’une ou l’autre commande est exécutée à nouveau.

Rôles définis par le système¶

GLOBALORGADMIN:

(alias Administrateur de l’organisation dans un compte organisation)

Rôle qui gère les opérations d’une organisation à comptes multiples au niveau de l’organisation, y compris la gestion du cycle de vie des comptes et l’affichage des informations d’utilisation au niveau de l’organisation.

ORGADMIN:

(alias Administrateur de l’organisation dans un compte classique)

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

Peut créer des comptes dans l’organisation.
Peut afficher tous les comptes de l’organisation (en utilisant SHOW ACCOUNTS) ainsi que toutes les régions activées pour l’organisation (en utilisant SHOW REGIONS).
Peut afficher les informations sur l’utilisation dans toute l’organisation.

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 de compte personnalisés 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é.

Les rôles de base de données personnalisés peuvent être créés par le propriétaire de la base de données (c’est-à-dire le rôle qui dispose du privilège OWNERSHIP sur la base de données).

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 peuvent 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¶

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. 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 <privilèges> et REVOKE <privilèges>.

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 diagramme suivant illustre la hiérarchie des rôles définis par le système, ainsi que la structure recommandée pour les rôles supplémentaires de compte définis par l’utilisateur et les rôles de base de données. Le rôle de base de données de plus haut niveau dans la hiérarchie de l’exemple est accordé à un rôle de compte personnalisé (c’est-à-dire défini par l’utilisateur). À son tour, ce rôle est accordé à un autre rôle personnalisé dans une structure recommandée qui permet au rôle SYSADMIN défini par le système d’hériter des privilèges des rôles de compte personnalisés et des rôles de base de données :

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.

Héritage de privilèges pour les rôles accordés

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.

Rôles et hiérarchies des rôles dans les bases de données¶

Les limitations suivantes s’appliquent actuellement aux rôles de bases de données :

Si un rôle de base de données est accordé à un partage, aucun autre rôle de base de données ne peut être accordé à ce rôle de base de données. Par exemple, si le rôle de base de données d1.r1 est accordé à un partage, la tentative d’accorder le rôle de base de données d1.r2 à d1.r1 est bloquée.

En outre, si un rôle de base de données est accordé à un autre rôle de base de données, le rôle de base de données du bénéficiaire ne peut pas être accordé à un partage.

Les rôles de base de données qui sont accordés à un partage peuvent être accordés à d’autres rôles de base de données, ainsi qu’à des rôles de compte.
Les rôles de compte ne peuvent pas être accordés aux rôles de base de données dans une hiérarchie de rôles.

Modèle d’application avec rôle principal et 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 :

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

Note

Un rôle de base de données ne peut être ni un rôle primaire ni un rôle secondaire. Pour assumer les privilèges accordés à un rôle de base de données, accordez le rôle de base de données à un rôle de compte. Seuls les rôles de compte peuvent être activés dans une session.

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.

Opérations de rôles principaux et secondaires

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.

Lorsque vous créez un objet dont l’utilisation nécessite un ou plusieurs privilèges, seuls le rôle principal et les rôles dont il hérite directement ou indirectement sont pris en compte lors de la recherche des attributions de ces privilèges.

Pour toute autre instruction nécessitant un ou plusieurs privilèges (par exemple, l’interrogation d’une table nécessite le privilège SELECT sur une table avec le privilège USAGE sur la base de données et le schéma), le rôle principal, les rôles secondaires et tous les autres rôles hérités sont pris en compte lors de la recherche des attributions de ces privilèges.

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.