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

• Contrôle d’accès basé sur l’utilisateur (UBAC) : les privilèges d’accès sont attribués directement aux utilisateurs. Le contrôle d’accès prend en compte les privilèges attribués directement aux utilisateurs uniquement lorsque USE SECONDARY ROLE est défini sur ALL.

Pour plus d’informations sur les rôles secondaires, voir USE SECONDARY ROLES et Autorisation par le biais d’un rôle primaire et de rôles secondaires.

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

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

• 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 : identité d’un utilisateur reconnue par Snowflake, qu’elle soit associée à une personne ou à un service. Un utilisateur est également une entité à laquelle des privilèges peuvent être accordés.

Dans Snowflake, les privilèges attribués aux rôles ou aux utilisateurs permettent l’accès aux objets sécurisables. Les rôles peuvent être attribués à des utilisateurs ou à d’autres rôles. L’octroi d’un rôle à un autre rôle crée une hiérarchie des rôles, décrite plus en détail dans Hiérarchie des rôles et héritage des privilèges. En général, vous utilisez RBAC pour gérer l’accès aux objets sécurisables dans Snowflake.

Le diagramme suivant illustre la manière dont DAC, RBAC et UBAC prennent en charge l’attribution de privilèges appropriés sur différents objets sécurisables. Dans cet exemple, le rôle 1 dispose du privilège OWNERSHIP sur les objets 1 et 2. En d’autres termes, le rôle 1 est propriétaire des deux objets. Ceci illustre DAC.

Les privilèges sur l’objet 1 peuvent être accordés au rôle 2, qui peut ensuite être accordé à l’utilisateur 1 et à l’utilisateur 2. En d’autres termes, l’utilisateur 1 et l’utilisateur 2 ont accès à l’objet 1, limité par ces privilèges, parce que les deux utilisateurs se sont vu attribuer le rôle 2. Cette partie de la figure illustre RBAC.

Les privilèges sur l’objet 2 peuvent être accordés directement à l’utilisateur 3 et à l’utilisateur 4. Cette partie de la figure illustre la manière dont vous pouvez utiliser UBAC pour étendre le cadre du contrôle d’accès de Snowflake, en fournissant une part importante 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 (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 SQL des actions sur des objets est définie par les privilèges accordés au rôle actif dans une session utilisateur. Par exemple, si le rôle actif dans votre session s’est vu accorder les privilèges CREATE, USAGE, SELECT et WRITE dans un schéma de base de données Snowflake spécifique, vous pouvez créer un entrepôt, lister les tables qu’il contient et ajouter des données à une table de ce schéma.

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 des privilèges, voir Hiérarchie des rôles et héritage des privilèges.

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 (comme 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 les objets créés dans un schéma (par exemple, accorder le 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 suivantes :

• GRANT <privilèges> … TO ROLE

• REVOKE <privilèges> … FROM ROLE

• GRANT <privilèges> … TO USER

• REVOKE <privilèges> … FROM USER

Dans les schémas classiques (non gérés), l’utilisation de ces commandes est limitée au rôle propriétaire d’un objet (qui dispose du privilège OWNERSHIP sur l’objet), à tous les rôles ou utilisateurs qui disposent du privilège global MANAGE GRANTS pour 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é (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.

Pour obtenir des instructions sur la création d’une hiérarchie des rôles, voir Création d’une hiérarchie de rôles.

Autorisation par le biais d’un rôle primaire et de 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, lorsqu’un utilisateur se connecte à l’aide de JDBC/ODBC ou se connecte à l’interface Web de Snowflake), le rôle actuel est déterminé sur la base 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é.

Pour voir le rôle actuel d’une session, exécutez la fonction CURRENT_ROLE.

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, une session 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 est propriétaire d’un objet (a le privilège OWNERSHIP sur l’objet), les rôles secondaires autorisent l’exécution de toutes les actions DDL sur l’objet. Le rôle primaire et 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 définie par 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, vous pouvez exécuter la commande USE ROLE ou USE SECONDARY ROLES pour modifier les rôles primaires ou secondaires actuels, respectivement. Vous pouvez 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 octrois de ces privilèges.