Utilisation des politiques d’accès aux lignes

Cette rubrique présente une introduction à l’implémentation de politiques d’accès aux lignes.

Dans ce chapitre :

Mise en œuvre des politiques d’accès aux lignes

Les étapes suivantes constituent un guide représentatif pour configurer les privilèges de politiques d’accès aux lignes et ajouter des politiques d’accès aux lignes aux tables et aux vues.

Ces étapes reposent sur les hypothèses suivantes :

  • L’approche de gestion est centralisée.

    Si le cas d’utilisation de la politique d’accès aux lignes comprend une approche de gestion hybride ou décentralisée, voir Gestion des politiques d’accès aux lignes pour une distribution représentative des rôles et des privilèges.

  • Une table de mappage est nécessaire, similaire à la table Cas d’utilisation représentatif : Utiliser une table de mappage pour filtrer le résultat de la requête.

    Les étapes suivantes utilisent la fonction de contexte CURRENT_ROLE pour déterminer si les utilisateurs voient des lignes dans le résultat d’une requête, tandis que le cas d’utilisation représentatif se concentre sur le prénom de l’utilisateur (c’est-à-dire CURRENT_USER).

    Le processus global de mise en œuvre d’une politique d’accès aux lignes avec des tables de mappage reste le même, même si les fonctions contextuelles sont différentes.

  • Le rôle système SECURITYADMIN accorde des privilèges aux rôles personnalisés pour gérer et mettre en œuvre les politiques d’accès aux lignes.

    Si vous ne souhaitez pas utiliser des rôles à privilèges plus élevés (c’est-à-dire SECURITYADMIN ou ACCOUNTADMIN) dans un environnement de production en faveur de rôles personnalisés moins privilégiés (par exemple database_admin, finance_admin), vérifiez que les rôles moins privilégiés disposent des privilèges nécessaires pour gérer et mettre en œuvre les politiques d’accès aux lignes.

    Pour plus d’informations, voir Privilèges de la politique d’accès aux lignes et Résumé des commandes, opérations et privilèges DDL.

Étape 1 : Créer une table pour les données

Créez une table pour les données de ventes.

create table sales (
  customer   varchar,
  product    varchar,
  spend      decimal(20, 2),
  sale_date  date,
  region     varchar
);

Etape 2 : Créez une table de mappage, un rôle personnalisé et accordez le privilège SELECT

Dans le schéma security, créez une table de mappage comme indiqué dans l’exemple représentatif. Cette table définit les lignes de la table sales que les responsables des ventes peuvent voir.

create table security.salesmanagerregions (
  sales_manager varchar,
  region        varchar
);

Ensuite, un administrateur de sécurité crée le rôle personnalisé mapping_role et accorde le privilège SELECT au rôle personnalisé. Cette autorisation permet aux utilisateurs ayant le rôle personnalisé d’interroger la table de mappage.

use role securityadmin;

create role mapping_role;

grant select on table security.salesmanagerregions to role mapping_role;

Étape 3 : Créer une politique d’accès aux lignes

En utilisant le rôle de propriétaire de schéma, créez une politique d’accès aux lignes avec les deux conditions suivantes :

  1. Les utilisateurs ayant le rôle personnalisé sales_executive_role peuvent voir toutes les lignes.

  2. Les utilisateurs ayant le rôle personnalisé sales_manager peuvent visualiser les lignes basées sur la table de mappage salesmanagerregions .

Notez que le rôle de propriétaire de schéma se voit automatiquement accorder le privilège CREATE ROW ACCESS POLICY. Si d’autres rôles doivent pouvoir créer des politiques d’accès aux lignes, le rôle de propriétaire du schéma peut accorder le privilège de politique CREATE ROW ACCESS à d’autres rôles.

use role <schema_owner_role>;

create or replace row access policy security.sales_policy as (sales_region varchar) returns boolean ->
  'sales_executive_role' = current_role()
      or exists (
            select 1 from salesmanagerregions
              where sales_manager = current_role()
                and region = sales_region
          )
;

Où :

security.sales_policy

Le nom de la politique d’accès aux lignes dans le schéma Security .

as (sales_region varchar)

La signature de la politique d’accès aux lignes.

Une signature spécifie l’attribut de la table de mappage et le type de données. La valeur renvoyée détermine si l’utilisateur a accès à une ligne donnée de la table ou de la vue à laquelle la politique d’accès aux lignes est ajoutée.

returns boolean ->

Spécifie l’application de la politique d’accès aux lignes.

Notez que les <expression> de la politique d’accès aux lignes suivent immédiatement la flèche de droite (c’est-à-dire ->).

L’expression peut être n’importe quelle expression SQL à valeur booléenne. Snowflake prend en charge les expressions qui appellent des UDFs, des fonctions externes et des expressions qui utilisent des sous-requêtes.

'sales_executive_role' = current_role()

La première condition de l’expression de la politique d’accès aux lignes qui permet aux utilisateurs ayant le rôle personnalisé sales_executive_role de visualiser les données.

or exists (select 1 from salesmanagerregions where sales_manager = current_role() and region = sales_region)

La deuxième condition de l’expression de la politique d’accès aux lignes qui utilise une sous-requête.

La sous-requête exige que CURRENT_ROLE soit le rôle personnalisé sales_manager et que la requête exécutée sur les données spécifie une région répertoriée dans la table de mappage {salesmanagerregions} .

Étape 4 : accorder des privilèges aux rôles personnalisés

En utilisant le rôle système SECURITYADMIN, exécutez les deux instructions suivantes :

grant ownership on row access policy security.sales_policy to mapping_role;

grant apply on row access policy security.sales_policy to role sales_analyst_role;

Ces deux instructions GRANT <privileges> … TO ROLE ont les effets suivants :

  • La propriété de la politique n’appartient pas au rôle système SECURITYADMIN . Au moment de l’exécution de la requête, Snowflake utilise les privilèges accordés au rôle personnalisé, car les politiques sont exécutées avec les droits du propriétaire, et non avec le rôle système SECURITYADMIN, plus privilégié. Cette approche soutient le principe du moindre privilège.

  • Le rôle personnalisé sales_analyst_role peut ajouter ou détruire la politique d’accès aux lignes d’une table selon les besoins.

Étape 5 : ajouter la politique d’accès aux lignes à une table

Toute table ou vue dans Snowflake peut prendre en charge jusqu’à une politique d’accès aux lignes à la fois.

Ajoutez (c’est-à-dire liez) la politique d’accès aux lignes à la colonne région dans la table de données Sales .

use role securityadmin;

alter table sales add row access policy security.sales_policy on (region);

Étape 6 : autoriser un rôle à interroger les données de la table protégée

Accordez le privilège SELECT sur les données protégées sales au rôle personnalisé sales_manager_role .

grant select on table sales to role sales_manager_role;

Étape 7 : tester la politique

Une fois que les données de vente ont rempli les données Sales , testez la politique d’accès aux lignes.

use role sales_manager_role;
select product, sum(spend)
from sales
where year(sale_date) = 2020
group by product;