Implémenter le masquage de colonne multi-domaine avec des niveaux de sensibilité

Ce tutoriel montre comment implémenter le masquage de colonne sensible au domaine avec des niveaux de sensibilité, combiné au filtrage de ligne basé sur la région. Vous utilisez des conditions ET dans MATCH COLUMNS pour cibler les colonnes par domaine et par niveau de sensibilité, et EXCEPT clauses pour exempter le groupe propriétaire de chaque domaine de la politique de masquage correspondante.

Prérequis

• Databricks Runtime 16.4 ou version supérieure, ou compute serverless.
• Autorisations d'administrateur de compte ou d'administrateur de Workspace (pour créer des tags gouvernés).
• MANAGE autorisation sur le catalogue ou le schéma cible.
• EXECUTE sur les UDF.
• Groupes de comptes : hr_team, finance_team, marketing_team, us_team, eu_team.

Pour créer les groupes requis, accédez à **Paramètres du Workspace** > **Identité et accès** > **Groupes**, cliquez sur **Ajouter un groupe**, puis créez chacun d’entre eux. Ajoutez-vous à au moins hr_team et us_team pour suivre la perspective RH + US à l'étape 7.

Scénario

Votre organisation gère une table employee_records centrale partagée entre les RH, les services financiers et le Marketing. Chaque équipe possède certaines colonnes et devrait voir ses propres données non masquées, mais ne devrait pas voir les données sensibles des autres équipes.

Le tutoriel utilise un tag gouverné appelé domain pour représenter l'équipe propriétaire de chaque colonne. Le nom est arbitraire. Vous pouvez également utiliser team, department, ou business_unit. L'idée principale est que chaque colonne est attribuée à un seul groupe propriétaire, et qu'un second tag sensitivity contrôle le degré de masquage des données pour les utilisateurs extérieurs à ce groupe.

Colonne	domain Tag	sensitivity Tag	Groupe autorisé
employee_name	hr	internal	hr_team
ssn	hr	confidential	hr_team
email	marketing	internal	marketing_team
customer_list	marketing	confidential	marketing_team
cost_center	finance	internal	finance_team
salary_band	finance	confidential	finance_team

Colonne	domain Tag	sensitivity Tag	Groupe autorisé
employee_name	hr	internal	hr_team
ssn	hr	confidential	hr_team
email	marketing	internal	marketing_team
customer_list	marketing	confidential	marketing_team
cost_center	finance	internal	finance_team
salary_band	finance	confidential	finance_team

Le comportement de masquage dépend du niveau de sensibilité :

• **Interne** : les utilisateurs extérieurs au groupe propriétaire voient un masque *** partiel (premier caractère +).
• Confidentiel : les utilisateurs extérieurs au groupe propriétaire voient ***REDACTED***.

Les utilisateurs de plusieurs groupes de domaines voient toutes les colonnes de leurs domaines démasquées.

Étape 1 : Créer des balises gouvernées.

Créez les tags gouvernés suivants dans l'interface utilisateur du Catalog Explorer ( Catalogue > Gouvernance > Tags gouvernés > Créer un tag gouverné ) :

Clé de tag	Valeurs autorisées
region	(balise à clé uniquement)
domain	hr, finance, marketing
sensitivity	internal, confidential

Clé de tag	Valeurs autorisées
region	(balise à clé uniquement)
domain	hr, finance, marketing
sensitivity	internal, confidential

attention

Les données des tags sont stockées en texte brut et peuvent être répliquées à l’échelle mondiale. N’utilisez pas de noms de tags, de valeurs ou de descripteurs qui pourraient compromettre la sécurité de vos ressources. Par exemple, n’utilisez pas de noms de tags, de valeurs ou de descripteurs contenant des informations personnelles ou sensibles.

Étape 2 : Créez des exemples de données.

Créez une seule table employee_records partagée entre les RH, les finances et le Marketing. Chaque colonne sensible sera taguée à la fois d'un niveau domain et d'un niveau sensitivity à l'étape suivante.

SQL

CREATE CATALOG IF NOT EXISTS abac_tutorial;
USE CATALOG abac_tutorial;

CREATE SCHEMA IF NOT EXISTS domain_demo;
USE SCHEMA domain_demo;

SQL

CREATE OR REPLACE TABLE employee_records (
  id INT,
  employee_name STRING,
  ssn STRING,
  email STRING,
  customer_list STRING,
  cost_center STRING,
  salary_band STRING,
  emp_region STRING,
  department STRING
);

INSERT INTO employee_records VALUES
  (1, 'Alice Johnson',  '123-45-6789', 'alice@acme.com',  'Tier-1 Enterprise', 'CC-4010', 'Band 7', 'us', 'Engineering'),
  (2, 'Bob Smith',      '234-56-7890', 'bob@acme.com',    'SMB Accounts',      'CC-3020', 'Band 5', 'us', 'Sales'),
  (3, 'Carol White',    '345-67-8901', 'carol@acme.com',  'Tier-1 Enterprise', 'CC-5010', 'Band 8', 'eu', 'Engineering'),
  (4, 'David Lee',      '456-78-9012', 'david@acme.com',  'Growth Segment',    'CC-2010', 'Band 4', 'eu', 'Marketing'),
  (5, 'Eva Martinez',   '567-89-0123', 'eva@acme.com',    'Mid-Market',        'CC-4020', 'Band 6', 'us', 'HR');

Étape 3 : Appliquer des tags gouvernés

Marquez chaque colonne sensible avec ses valeurs domain et sensitivity. Ces deux balises permettent ensemble à chaque politique de cibler une combinaison spécifique de domaine et de sensibilité en utilisant des conditions ET dans MATCH COLUMNS. La colonne emp_region obtient une balise region à clé unique car la politique doit uniquement identifier la colonne plutôt que de vérifier une valeur spécifique.

SQL

-- HR domain
ALTER TABLE employee_records
  ALTER COLUMN employee_name SET TAGS ('domain' = 'hr', 'sensitivity' = 'internal');
ALTER TABLE employee_records
  ALTER COLUMN ssn SET TAGS ('domain' = 'hr', 'sensitivity' = 'confidential');

-- Marketing domain
ALTER TABLE employee_records
  ALTER COLUMN email SET TAGS ('domain' = 'marketing', 'sensitivity' = 'internal');
ALTER TABLE employee_records
  ALTER COLUMN customer_list SET TAGS ('domain' = 'marketing', 'sensitivity' = 'confidential');

-- Finance domain
ALTER TABLE employee_records
  ALTER COLUMN cost_center SET TAGS ('domain' = 'finance', 'sensitivity' = 'internal');
ALTER TABLE employee_records
  ALTER COLUMN salary_band SET TAGS ('domain' = 'finance', 'sensitivity' = 'confidential');

-- Region tag for row filtering
ALTER TABLE employee_records
  ALTER COLUMN emp_region SET TAGS ('region' = '');

Étape 4 : créer les UDF

L'UDF de filtre de ligne accepte la valeur de région de la ligne et une région autorisée comme argument statique, et renvoie TRUE lorsqu'elles correspondent. Transmettre la région autorisée comme constante permet de garder l'UDF simple et réutilisable. Chaque politique de filtre de ligne cible un groupe et transmet la région que ce groupe est autorisé à voir.

SQL

CREATE OR REPLACE FUNCTION abac_tutorial.domain_demo.region_filter(region_val STRING, allowed_region STRING)
RETURNS BOOLEAN
RETURN region_val = allowed_region;

Créez une UDF de masque partiel pour les colonnes internes et une UDF de rédaction complète pour les colonnes confidentielles.

SQL

CREATE OR REPLACE FUNCTION abac_tutorial.domain_demo.partial_mask(val STRING)
RETURNS STRING
RETURN CONCAT(LEFT(val, 1), '***');

CREATE OR REPLACE FUNCTION abac_tutorial.domain_demo.redact(val STRING)
RETURNS STRING
RETURN '***REDACTED***';

Étape 5 : Créez les politiques de filtre de lignes

Créez une politique de filtre de lignes par région. Chaque politique cible un groupe spécifique et transmet la région autorisée comme constante via USING COLUMNS.

SQL

CREATE POLICY region_filter_us
ON SCHEMA abac_tutorial.domain_demo
ROW FILTER abac_tutorial.domain_demo.region_filter
TO `us_team`
FOR TABLES
MATCH COLUMNS has_tag('region') AS region_col
USING COLUMNS (region_col, 'us');

CREATE POLICY region_filter_eu
ON SCHEMA abac_tutorial.domain_demo
ROW FILTER abac_tutorial.domain_demo.region_filter
TO `eu_team`
FOR TABLES
MATCH COLUMNS has_tag('region') AS region_col
USING COLUMNS (region_col, 'eu');

remarque

Une alternative consiste à intégrer la logique de groupe dans la UDF à l'aide de fonctions d'identité telles que is_account_group_member(). Cette approche utilise une politique unique sans valeurs statiques, mais déplace le mappage groupe-région dans la UDF. Utilisez celui qui convient le mieux à votre organisation.

Étape 6 : Créer les stratégies de masquage de colonne de domaine

Créez une politique par combinaison de domaine et de sensibilité. Chaque politique utilise ET pour faire correspondre les colonnes avec un niveau domain ET sensitivity spécifique, et EXCEPT pour exempter le groupe de domaine propriétaire.

	interne (partial_mask)	confidentiel (redact)
RH	mask_internal_hr	mask_confidential_hr
Finance	mask_internal_finance	mask_confidential_finance
Marketing	mask_internal_marketing	mask_confidential_marketing

	interne (partial_mask)	confidentiel (redact)
RH	mask_internal_hr	mask_confidential_hr
Finance	mask_internal_finance	mask_confidential_finance
Marketing	mask_internal_marketing	mask_confidential_marketing

Étant donné que chaque colonne possède exactement une valeur domain et une valeur sensitivity, chaque colonne est mise en correspondance par exactement une seule politique par utilisateur. Il n'y a pas de conflits.

Colonnes internes (masque partiel)

Appliquer un masque partiel aux colonnes de niveau interne pour les utilisateurs extérieurs au domaine propriétaire.

SQL

CREATE POLICY mask_internal_hr
ON SCHEMA abac_tutorial.domain_demo
COLUMN MASK abac_tutorial.domain_demo.partial_mask
TO `account users` EXCEPT `hr_team`
FOR TABLES
MATCH COLUMNS (
  has_tag_value('domain', 'hr')
  AND has_tag_value('sensitivity', 'internal')
) AS m
ON COLUMN m;

CREATE POLICY mask_internal_finance
ON SCHEMA abac_tutorial.domain_demo
COLUMN MASK abac_tutorial.domain_demo.partial_mask
TO `account users` EXCEPT `finance_team`
FOR TABLES
MATCH COLUMNS (
  has_tag_value('domain', 'finance')
  AND has_tag_value('sensitivity', 'internal')
) AS m
ON COLUMN m;

CREATE POLICY mask_internal_marketing
ON SCHEMA abac_tutorial.domain_demo
COLUMN MASK abac_tutorial.domain_demo.partial_mask
TO `account users` EXCEPT `marketing_team`
FOR TABLES
MATCH COLUMNS (
  has_tag_value('domain', 'marketing')
  AND has_tag_value('sensitivity', 'internal')
) AS m
ON COLUMN m;

Colonnes confidentielles (rédaction complète)

Supprimez entièrement les colonnes de niveau confidentiel pour les utilisateurs extérieurs au domaine propriétaire.

SQL

CREATE POLICY mask_confidential_hr
ON SCHEMA abac_tutorial.domain_demo
COLUMN MASK abac_tutorial.domain_demo.redact
TO `account users` EXCEPT `hr_team`
FOR TABLES
MATCH COLUMNS (
  has_tag_value('domain', 'hr')
  AND has_tag_value('sensitivity', 'confidential')
) AS m
ON COLUMN m;

CREATE POLICY mask_confidential_finance
ON SCHEMA abac_tutorial.domain_demo
COLUMN MASK abac_tutorial.domain_demo.redact
TO `account users` EXCEPT `finance_team`
FOR TABLES
MATCH COLUMNS (
  has_tag_value('domain', 'finance')
  AND has_tag_value('sensitivity', 'confidential')
) AS m
ON COLUMN m;

CREATE POLICY mask_confidential_marketing
ON SCHEMA abac_tutorial.domain_demo
COLUMN MASK abac_tutorial.domain_demo.redact
TO `account users` EXCEPT `marketing_team`
FOR TABLES
MATCH COLUMNS (
  has_tag_value('domain', 'marketing')
  AND has_tag_value('sensitivity', 'confidential')
) AS m
ON COLUMN m;

Étape 7 : Vérifier les résultats

Les sept politiques (deux filtres de ligne et six masques de colonne) sont maintenant actives. Exécutez la query suivante et vérifiez que les résultats correspondent à ce que votre appartenance au groupe permet.

SQL

SELECT * FROM abac_tutorial.domain_demo.employee_records;

Membre de l'équipe RH dans la région des États-Unis (hr_team + us_team) :

| ID | nom de l'employé | numéro de sécurité sociale | e-mail | liste de clients | centre de coûts | fourchette salariale | région d'emploi | département | | -- | ---------------- | -------------------------- | -------- | ---------------- | --------------- | -------------------- | --------------- | ----------- | | 1 | Alice Johnson | 123-45-6789 | a*** | ***REDACTED*** | C*** | ***REDACTED*** | us | Ingénierie | | 2 | Bob Smith | 234-56-7890 | b*** | ***REDACTED*** | C*** | ***REDACTED*** | us | Ventes | | 5 | Eva Martinez | 567-89-0123 | e*** | ***REDACTED*** | C*** | ***REDACTED*** | us | RH |

Les colonnes RH (employee_name, ssn) sont démasquées. Marketing interne (email) est partiellement masqué et confidentiel (customer_list) est expurgé. Finance interne (cost_center) est partiellement masqué et confidentiel (salary_band) est expurgé.

Membre de l'équipe financière de la région UE (finance_team eu_team+) :

| id | nom de l'employé | ssn | e-mail | liste des clients | centre de coûts | bande salariale | région de l'employé | département | | -- | -------------- | -------------------- | ------ | -------------------- | ------------ | ------------ | ----------- | ----------- | | 3 | C*** | ***REDACTED*** | c*** | ***REDACTED*** | CC-5010 | Band 8 | eu | Data Engineering | | 4 | D*** | ***REDACTED*** | d*** | ***REDACTED*** | CC-2010 | Band 4 | eu | Marketing |

Les colonnes Finance (cost_center, salary_band) sont démasquées. Toutes les autres colonnes de domaine sont masquées ou expurgées.

Utilisateur dans hr_team + marketing_team + us_team:

| ID | Nom de l'employé | SSN | E-mail | Liste de clients | Centre de coûts | Fourchette de salaire | Région de l'employé | Département | | -- | -------------- | ----------- | ---------------------------------------- | ----------------- | ------------ | -------------------- | ----------- | ----------- | | 1 | Alice Johnson | 123-45-6789 | alice@acme.com | Tier-1 Enterprise | C*** | ***REDACTED*** | États-Unis | Data Engineering |

Les colonnes RH et Marketing sont toutes deux non masquées car l'utilisateur appartient aux deux groupes. Les colonnes Finance restent masquées.

Pourquoi ce modèle fonctionne

Chaque colonne a exactement une valeur domain et une valeur sensitivity, de sorte que chaque colonne correspond à exactement une politique par utilisateur. Il n'y a pas de conflits de politique.

La clause EXCEPT est la clé. Chaque politique s'applique à account users, à l'exception du groupe de domaines qui possède ces colonnes. Si vous faites partie du groupe propriétaire, la politique ne s'applique pas et vous voyez les données brutes. Si vous ne l'êtes pas, la politique s'applique et les données sont masquées. Les utilisateurs multi-groupes en bénéficient naturellement : un utilisateur à la fois dans hr_team et marketing_team est exclu des deux ensembles de politiques RH et Marketing.

L’ajout d’un nouveau domaine (par exemple, juridique) nécessite :

1. Un nouveau groupe (legal_team).
2. Une nouvelle valeur autorisée legal pour le tag domain.
3. Deux nouvelles politiques (mask_internal_legal, mask_confidential_legal).
4. Tags sur les nouvelles colonnes.

Aucune politique existante n'a besoin d'être modifiée.

Nettoyer

Pour supprimer tous les objets créés dans ce tutoriel, exécutez ce qui suit.

SQL

DROP POLICY region_filter_us ON SCHEMA abac_tutorial.domain_demo;
DROP POLICY region_filter_eu ON SCHEMA abac_tutorial.domain_demo;
DROP POLICY mask_internal_hr ON SCHEMA abac_tutorial.domain_demo;
DROP POLICY mask_internal_finance ON SCHEMA abac_tutorial.domain_demo;
DROP POLICY mask_internal_marketing ON SCHEMA abac_tutorial.domain_demo;
DROP POLICY mask_confidential_hr ON SCHEMA abac_tutorial.domain_demo;
DROP POLICY mask_confidential_finance ON SCHEMA abac_tutorial.domain_demo;
DROP POLICY mask_confidential_marketing ON SCHEMA abac_tutorial.domain_demo;
DROP FUNCTION IF EXISTS abac_tutorial.domain_demo.region_filter;
DROP FUNCTION IF EXISTS abac_tutorial.domain_demo.partial_mask;
DROP FUNCTION IF EXISTS abac_tutorial.domain_demo.redact;
DROP TABLE IF EXISTS abac_tutorial.domain_demo.employee_records;
DROP SCHEMA IF EXISTS abac_tutorial.domain_demo CASCADE;

Pour supprimer les tags régis region, domain et sensitivity, ainsi que les groupes de comptes (hr_team, finance_team, marketing_team, us_team, eu_team), utilisez respectivement l’interface utilisateur de Catalog Explorer et les paramètres du workspace.