Rubriques de sécurité avancées au niveau des colonnes

Cette rubrique fournit une introduction à deux concepts avancés liés aux politiques de masquage dynamique des données :

  1. Utilisation de Fonctions contextuelles.

  2. Hiérarchie des rôles.

Sécurité au niveau des colonnes avec fonctions de contexte et hiérarchie des rôles

La sécurité au niveau des colonnes prend en charge l’utilisation de Fonctions contextuelles dans les conditions du corps de la politique de masquage pour vérifier si un utilisateur est autorisé à voir les données. Pour déterminer si un utilisateur peut voir les données dans une instruction SQL donnée, il est utile de considérer les points suivants :

La session en cours

Les conditions de la politique de masquage à l’aide de CURRENT_ROLE ciblent le rôle utilisé pour la session en cours.

Le rôle d’exécution

Les conditions de la politique de masquage à l’aide de INVOKER_ROLE ciblent le rôle d’exécution dans une instruction SQL.

Hiérarchie des rôles

Déterminez si un rôle spécifié dans une condition de politique de masquage (par exemple, un rôle personnalisé ANALYST) est un rôle de privilège inférieur dans la hiérarchie des rôles CURRENT_ROLE ou INVOKER_ROLE. Si tel est le cas, le rôle renvoyé par les fonctions CURRENT_ROLE ou INVOKER_ROLE hérite des privilèges du rôle spécifié. Pour plus d’informations sur la hiérarchie des rôles et l’héritage des privilèges, voir :

Le tableau suivant présente les fonctions de contexte courantes dans les politiques de masquage qui ciblent la session en cours, le rôle d’exécution et la hiérarchie des rôles.

Fonction contextuelle

Description

CURRENT_ROLE

Renvoie le nom du rôle utilisé pour la session en cours.

IS_ROLE_IN_SESSION

Renvoie TRUE si le nom de rôle validé dans l’argument est l’un des rôles activés dans la session (c’est-à-dire que le rôle renvoyé par la fonction CURRENT_ROLE hérite des privilèges du rôle spécifié).

INVOKER_ROLE

Renvoie le nom du rôle d’exécution.

IS_GRANTED_TO_INVOKER_ROLE

Renvoie TRUE si le rôle renvoyé par la fonction INVOKER_ROLE hérite des privilèges du rôle spécifié dans l’argument.

INVOKER_SHARE

Renvoie le nom du partage utilisé par le consommateur de données exécutant la requête.

Utilisation de CURRENT_ROLE et IS_ROLE_IN_SESSION

Une condition de politique de masquage utilisant CURRENT_ROLE cible la session en cours et n’est pas affectée par le contexte d’exécution de l’instruction SQL.

Considérez le corps de la politique de masquage suivant :

case
  when current_role() in ('ANALYST') then val
  else '********'
end;

Pour déterminer si un utilisateur donné a l’autorisation de voir des données dans une colonne où cette politique de masquage est définie sur cette colonne, procédez comme suit :

  1. Évaluez les conditions de la politique de masquage.

  2. Déterminez si le rôle spécifié se trouve dans la hiérarchie CURRENT_ROLE.

  3. Exécutez une requête de test pour vérifier.

Étape 1 : évaluez les conditions de la politique de masquage

Le tableau suivant résume les conséquences des conditions du corps de la politique de masquage.

Contexte

Voit les données non masquées

Voit les données masquées

CURRENT_ROLE = rôle personnalisé ANALYST.

CURRENT_ROLE se trouve dans le rôle personnalisé ANALYST dans la hiérarchie.

CURRENT_ROLE ne se trouve pas dans la hiérarchie des rôles personnalisés ANALYST.

Ensuite, évaluez la hiérarchie des rôles.

Étape 2 : déterminez si le rôle spécifié se trouve dans la hiérarchie CURRENT_ROLE

En supposant que CURRENT_ROLE n’est pas le rôle personnalisé ANALYST, déterminez si CURRENT_ROLE hérite des privilèges accordés au rôle personnalisé ANALYST.

Exécutez l’instruction suivante :

select is_role_in_session('ANALYST');

+-------------------------------+
| IS_ROLE_IN_SESSION('ANALYST') |
+-------------------------------+
| FALSE                         |
+-------------------------------+

Comme Snowflake renvoie FALSE, CURRENT_ROLE n’hérite pas des privilèges accordés au rôle personnalisé ANALYST. Par conséquent, en fonction du corps de la politique de masquage dans cet exemple, l’utilisateur doit voir une valeur de masque fixe.

Étape 3 : exécutez une requête de test pour vérifier

Exécutez une requête sur la colonne dont la politique de masquage dans cet exemple est appliquée à cette colonne pour vérifier que l’utilisateur voit une valeur masquée fixe.

use role ANALYST;

select <column> from <table_or_view>;

Utilisation de INVOKER_ROLE

Une condition de politique de masquage utilisant INVOKER_ROLE cible le contexte d’exécution de l’instruction SQL.

Le tableau suivant résume le contexte d’exécution et la valeur que INVOKER_ROLE renvoie dans une condition de politique de masquage :

Requête dans laquelle la politique de masquage s’applique

Valeur renvoyée par INVOKER_ROLE

Vue

Afficher le rôle du propriétaire.

UDF

Rôle du propriétaire de l’UDF.

Procédure stockée avec droit de l’appelant

CURRENT_ROLE.

Procédure stockée avec droit du propriétaire

Rôle du propriétaire de la procédure stockée.

Tâche

Rôle de propriétaire de tâche.

Flux

Rôle qui interroge un flux donné.

Considérez le corps de la politique de masquage suivant qui est appliqué à une seule vue sur une table :

case
  when invoker_role() in ('ANALYST') then val
  else '********'
end;

Pour déterminer si un utilisateur donné exécutant une requête sur la colonne a l’autorisation de voir les données, procédez comme suit :

  1. Évaluez les conditions de la politique de masquage.

  2. Déterminez si le rôle spécifié possède la vue.

  3. Exécutez une requête de test pour vérifier.

Étape 1 : évaluez les conditions de la politique de masquage

Le tableau suivant résume les conséquences des conditions du corps de la politique de masquage appliquées à une colonne de vue.

Contexte

Voit les données non masquées

Voit les données masquées

Le rôle personnalisé ANALYST est le rôle de propriétaire de la vue.

Le rôle personnalisé ANALYST n’est pas le rôle de propriétaire de la vue.

Ensuite, déterminez si le rôle personnalisé ANALYST possède la vue.

Étape 2 : déterminez si ANALYST est propriétaire de la vue

Pour déterminer si le rôle personnalisé ANALYST possède la vue, exécutez l’instruction suivante :

show grants to role analyst;

Si le rôle personnalisé ANALYST est propriétaire de la vue, une requête dans la colonne de vue doit générer des données non masquées.

Si le rôle personnalisé ANALYST ne possède pas la vue, les données masquées doivent être affichées.

Étape 3 : exécutez une requête de test pour vérifier

Exécutez une requête sur la colonne de vue pour déterminer si le rôle personnalisé ANALYST voit des données masquées ou non masquées.

use role ANALYST;

select <column> from <view_name>;

Utilisation de IS_GRANTED_TO_INVOKER_ROLE

La fonction IS_GRANTED_TO_INVOKER_ROLE peut être validée dans un corps de politique de masquage dans le cadre d’une condition. Lorsque la fonction correspond à TRUE, le rôle dans l’argument de la fonction se situe dans la hiérarchie INVOKER_ROLE.

Considérez le corps de la politique de masquage suivant qui est appliqué à une colonne de vue des numéros de sécurité sociale (SSNs) :

case
  when is_granted_to_invoker_role('PAYROLL') then val
  when is_granted_to_invoker_role('ANALYST') then regexp_replace(val, '[0-9]', '*', 7)
  else '*******'
end;

Pour déterminer si un utilisateur donné exécutant une requête sur la colonne de vue a l’autorisation de voir les données, procédez comme suit :

  1. Évaluez les conditions de la politique de masquage.

  2. Déterminez si le rôle spécifié se trouve dans la hiérarchie des rôles de propriétaire de la vue.

  3. Exécutez une requête de test pour vérifier.

Étape 1 : évaluez les conditions de la politique de masquage

Le tableau suivant résume les conséquences des conditions du corps de la politique de masquage appliquées à une colonne de vue et de l’affichage des données dans la colonne de vue.

Contexte

Données non masquées

Données partiellement masquées

Données masquées

Le rôle personnalisé PAYROLL se trouve dans la hiérarchie des rôles de propriétaire de la vue.

Le rôle personnalisé ANALYST se trouve dans la hiérarchie des rôles de propriétaire de la vue.

Ni les rôles personnalisés PAYROLL ni ANALYST . ne figurent dans la hiérarchie des propriétaires de vues.

Étape 2 : déterminez si le rôle spécifié se trouve dans la hiérarchie des rôles du propriétaire de la vue

Si les rôles personnalisés PAYROLL ou ANALYST se trouvent dans la hiérarchie du propriétaire de la vue, l’exécution d’une commande SHOW GRANTS sur le rôle du propriétaire de la vue peut vérifier la hiérarchie des rôles. Par exemple :

show grants to role <view_owner_role>;

Les sorties de l’instruction SQL indiqueront si le rôle de propriétaire de la vue a reçu les rôles personnalisés PAYROLL ou ANALYST.

Étape 3 : exécutez une requête de test pour vérifier

Exécutez une requête sur la colonne qui possède la politique de masquage de cet exemple appliquée à cette colonne pour vérifier comment l’utilisateur voit les données dans la colonne de vue.

use role PAYROLL;

select <column> from <view>;

use role ANALYST;

select <column> from <view>;