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

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

Si l’activation des rôles et la hiérarchie des rôles sont nécessaires dans les conditions de la politique, utilisez IS_ROLE_IN_SESSION.

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

CREATE OR REPLACE MASKING POLICY mask_string AS
(val string) RETURNS string ->
CASE
  WHEN CURRENT_ROLE() IN ('ANALYST') THEN val
  ELSE '********'
END;

Copy

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.

USE ROLE analyst;

SELECT * FROM mydb.mysch.mytable;

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

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

CREATE OR REPLACE MASKING POLICY mask_string AS
(val string) RETURNS string ->
CASE
  WHEN INVOKER_ROLE() IN ('ANALYST') THEN val
  ELSE '********'
END;

Copy

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.

SHOW GRANTS OF ROLE analyst;

USE ROLE analyst;

SELECT * FROM mydb.mysch.myview;

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

CREATE OR REPLACE MASKING POLICY mask_string AS
(val string) RETURNS string ->
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 de rôles de l’invocateur. Par exemple, si la stratégie est définie sur une vue, le rôle spécifié doit faire partie de la hiérarchie de rôles du propriétaire de la vue pour renvoyer TRUE. Pour plus de détails, voir les notes sur l’utilisation.

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

USE ROLE payroll;

SELECT * FROM mydb.mysch.myview;

USE ROLE analyst;

SELECT * FROM mydb.mysch.myview;

Fonctions de hachage, de cryptage et de chiffrement dans les politiques de masquage¶

Le hachage et Cryptographique/Somme de contrôle peuvent être utilisés dans les politiques de masquage pour masquer les données sensibles.

Avant de mettre en œuvre l’une de ces fonctions dans une politique de masquage, il est important d’examiner si votre cas d’utilisation de ces fonctions implique des opérations JOIN. Dans le cadre de certaines mises en œuvre de la politique de masquage, des opérations JOIN créatives faisant intervenir des tables et des vues peuvent conduire à une rétroingénierie de la valeur masquée à sa valeur réelle en fonction de la limitation suivante :

• Il est possible que des collisions se produisent parce qu’il peut ne pas y avoir de représentation exactes (1:1) de la valeur réelle (c’est-à-dire de l’entrée) et de la valeur hachée, cryptographique ou de la somme de contrôle basée sur le nombre total de valeurs (c’est-à-dire la sortie, la plage de valeurs) à transformer.

Une représentation exacte (1:1) est plus susceptible de se produire jusqu’à ce que le nombre total de valeurs d’entrée atteigne la racine carrée des valeurs de sortie à transformer.

Par exemple, si les valeurs de sortie à hacher sont 144, il est raisonnable de s’attendre à ce que les 12 premières valeurs (c’est-à-dire 144^(1/2) – la racine carrée de 144) soient uniques et que des collisions puissent se produire pour les 132 valeurs restantes. Cette limitation et ses conséquences étant possibles, il est conseillé de ne jamais utiliser de fonctions de hachage, de cryptographie ou de somme de contrôle dans les politiques de masquage dont les valeurs peuvent être utilisées dans les opérations JOIN.