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

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

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.

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 :

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.

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

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.

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.