Usare le tabelle di mapping per il controllo dinamico degli accessi

Questa esercitazione illustra come usare una tabella di mapping per controllare l'accesso a livello di riga e a livello di colonna senza gestire un numero elevato di gruppi. Una singola tabella di ricerca gestisce sia il filtro delle righe che il mascheramento delle colonne. Le modifiche di accesso richiedono solo un aggiornamento di riga. Non è necessario creare nuovi gruppi o riscrivere i criteri.

Questa esercitazione illustra anche la maschera condizionale: le colonne PII vengono mascherate in modo diverso a seconda del valore di un'altra colonna nella stessa riga. Gli ordini contrassegnati confidential hanno il loro PII completamente redatto indipendentemente dal livello di autorizzazione dell'utente.

Per indicazioni generali sulla progettazione di tabelle di mapping, vedere Usare tabelle di mapping per creare un elenco di controllo di accesso.

Prerequisiti

• Databricks Runtime 16.4 o versione successiva, oppure calcolo senza server.
• Autorizzazioni di amministratore dell'account o amministratore dell'area di lavoro (per creare tag regolamentati).
• MANAGE autorizzazione per il catalogo o lo schema di destinazione.
• EXECUTE nelle funzioni definite dall'utente.
• Un notebook SQL o un editor di query.

Scenario

L'organizzazione ha dipendenti in quattro aree (Stati Uniti orientali, Stati Uniti occidentali, UE, APAC) e quattro reparti. Ogni utente deve visualizzare solo le righe che corrispondono all'area e al reparto e le colonne PII devono essere mascherate in base a due fattori: il livello di distanza dell'utente (full, maskedo none) archiviato in una tabella di mapping e l'ordine order_priority.

Con un approccio basato su gruppi, è necessario un gruppo per ogni combinazione regione-reparto. Ad esempio, sono necessari 16 gruppi per quattro aree e quattro reparti. L'aggiunta di livelli di autorizzazione per le informazioni personali triplica quel conteggio. Ogni nuova area o reparto richiede nuovi gruppi e aggiornamenti dei criteri.

L'approccio alla tabella di mapping sostituisce questa operazione con una singola tabella di ricerca: una riga per utente, una colonna per ogni dimensione di accesso. Per modificare l'accesso di un utente, aggiornare una riga.

Passaggio 1: Creare tag regolamentati

Prima di eseguire qualsiasi SQL, creare i seguenti tag regolati nell'interfaccia utente di Catalog Explorer (Catalogo>Governare>Tag regolati>Crea un tag regolato):

I tag region e department indicano alla politica di filtro delle righe quali colonne passare alla UDF di filtro. Il pii tag indica ai criteri della maschera di colonna quali colonne mascherare e quale tipo di informazioni personali contengono. Il tag priority consente ai criteri di mascheramento della colonna di passare order_priority valore alla funzione definita dall'utente della maschera per la maschera condizionale.

Passaggio 2: Compilare dati di esempio

Creare una tabella catalogo, una tabella schema e una tabella ordini. La colonna order_priority guida la maschera condizionale: gli ordini contrassegnati confidential hanno il PII completamente oscurato, anche per gli utenti con elevato livello di autorizzazione.

CREATE CATALOG IF NOT EXISTS abac_tutorial;
USE CATALOG abac_tutorial;

CREATE SCHEMA IF NOT EXISTS mapping_demo;
USE SCHEMA mapping_demo;

CREATE OR REPLACE TABLE orders (
  order_id INT,
  customer_name STRING,
  customer_email STRING,
  sales_region STRING,
  dept STRING,
  amount DOUBLE,
  order_date DATE,
  order_priority STRING
);

INSERT INTO orders VALUES
  (1,  'Acme Corp',     'orders@acme.com',    'us_east', 'engineering', 50000,  '2025-01-15', 'standard'),
  (2,  'Beta Inc',      'sales@beta.com',     'us_east', 'sales',       75000,  '2025-02-01', 'confidential'),
  (3,  'Gamma LLC',     'info@gamma.com',     'us_west', 'engineering', 30000,  '2025-01-20', 'standard'),
  (4,  'Delta Co',      'deals@delta.com',    'us_west', 'sales',       95000,  '2025-03-01', 'confidential'),
  (5,  'Epsilon GmbH',  'kontakt@epsilon.de', 'eu',      'engineering', 45000,  '2025-02-15', 'standard'),
  (6,  'Zeta SA',       'contact@zeta.fr',    'eu',      'sales',       62000,  '2025-01-30', 'standard'),
  (7,  'Eta Ltd',       'hello@eta.sg',       'apac',    'marketing',   28000,  '2025-03-10', 'confidential'),
  (8,  'Theta Corp',    'biz@theta.com',      'us_east', 'marketing',   55000,  '2025-02-20', 'standard'),
  (9,  'Iota KK',       'info@iota.jp',       'apac',    'engineering', 41000,  '2025-01-25', 'standard'),
  (10, 'Kappa Inc',     'sales@kappa.com',    'us_west', 'marketing',   33000,  '2025-03-05', 'standard');

Passaggio 3: Applicare tag regolamentati

Contrassegna le colonne in modo che le politiche ABAC possano individuarle automaticamente. La colonna order_priority viene contrassegnata con il tag solo chiave priority in modo che i criteri delle maschere di colonne possano corrispondere ad esso tramite MATCH COLUMNS e passarne il valore alla UDF di mascheramento.

ALTER TABLE abac_tutorial.mapping_demo.orders
  ALTER COLUMN sales_region SET TAGS ('region' = '');
ALTER TABLE abac_tutorial.mapping_demo.orders
  ALTER COLUMN dept SET TAGS ('department' = '');
ALTER TABLE abac_tutorial.mapping_demo.orders
  ALTER COLUMN customer_name SET TAGS ('pii' = 'name');
ALTER TABLE abac_tutorial.mapping_demo.orders
  ALTER COLUMN customer_email SET TAGS ('pii' = 'email');
ALTER TABLE abac_tutorial.mapping_demo.orders
  ALTER COLUMN order_priority SET TAGS ('priority' = '');

Passaggio 4: Creare la tabella di mappatura

Invece di creare gruppi per ogni combinazione di aree, reparto e autorizzazione, si mantiene una tabella con una riga per utente. La pii_access colonna controlla la modalità di visualizzazione delle colonne PII:

• full — vedere il valore effettivo (per gli ordini con priorità standard)
• masked — vedere un valore parziale, quale A*** o o***@acme.com
• none — vedere ***REDACTED***

La expires_on colonna imposta una data di scadenza per ogni voce di accesso. Dopo questa data, la funzione UDF del filtro di riga smette di corrispondere alla voce e l'utente perde l'accesso automaticamente e senza notifica, senza alcuna revoca manuale necessaria. Ciò è utile per i terzisti, i contratti di condivisione dei dati temporanei o i progetti a tempo limitato.

Se un utente deve accedere a più combinazioni di aree e reparti, aggiungere altre righe.

CREATE OR REPLACE TABLE abac_tutorial.mapping_demo.user_access (
  user_email STRING,
  region STRING,
  department STRING,
  pii_access STRING,
  expires_on DATE
);

INSERT INTO abac_tutorial.mapping_demo.user_access VALUES
  (current_user(),      'us_east', 'engineering', 'masked', '2099-12-31'),
  ('bob@example.com',   'us_west', 'sales',       'full',   '2099-12-31'),
  ('carol@example.com', 'eu',      'engineering', 'none',   '2099-12-31'),
  ('david@example.com', 'apac',    'marketing',   'masked', '2099-12-31');

Passaggio 5: Creare la funzione filtro riga definita dall'utente

Questa funzione definita dall'utente riceve i valori sales_region e dept di una riga (passati dalla politica tramite corrispondenza tag), cerca l'utente corrente nella tabella di mappatura e restituisce TRUE solo se esiste una voce corrispondente e non è scaduta. Gli utenti non presenti nella tabella di mappatura o il cui accesso è scaduto, non visualizzano righe (design a chiusura in caso di errore).

CREATE OR REPLACE FUNCTION abac_tutorial.mapping_demo.access_filter(
  region_val STRING,
  dept_val STRING
)
RETURNS BOOLEAN
RETURN EXISTS (
  SELECT 1 FROM abac_tutorial.mapping_demo.user_access
  WHERE user_email = current_user()
    AND region = region_val
    AND department = dept_val
    AND expires_on >= current_date()
);

Passaggio 6: Creare la UDF per la maschera di colonna

Questa UDF (funzione definita dall'utente) controlla come vengono visualizzate le colonne PII. Accetta tre argomenti: il valore della colonna, il tipo PII ('name' o 'email') e il valore della order_priorityriga . La logica di maschera ha due livelli:

• Livello 1 (mascheramento condizionale): Se order_priority è confidential, le informazioni personali vengono sempre completamente oscurate indipendentemente dal livello di autorizzazione dell'utente.
• Livello 2 (autorizzazione utente): Per le righe standard, la tabella di mapping viene controllata dalla UDF per il livello utente pii_access e applica la maschera corrispondente. Se un utente dispone di più voci di tabella di mapping (accesso a più aree), viene applicata la spaziatura più elevata in tutte le righe.

CREATE OR REPLACE FUNCTION abac_tutorial.mapping_demo.pii_mask(
  val STRING,
  pii_type STRING,
  order_pri STRING
)
RETURNS STRING
RETURN CASE
  WHEN order_pri = 'confidential' THEN '***REDACTED***'
  WHEN EXISTS (
    SELECT 1 FROM abac_tutorial.mapping_demo.user_access
    WHERE user_email = current_user() AND pii_access = 'full'
  ) THEN val
  WHEN EXISTS (
    SELECT 1 FROM abac_tutorial.mapping_demo.user_access
    WHERE user_email = current_user() AND pii_access = 'masked'
  ) THEN
    CASE pii_type
      WHEN 'email' THEN CONCAT(LEFT(val, 1), '***@', SUBSTRING_INDEX(val, '@', -1))
      WHEN 'name'  THEN CONCAT(LEFT(val, 1), '***')
      ELSE CONCAT(LEFT(val, 1), '***')
    END
  ELSE '***REDACTED***'
END;

Passaggio 7: Creare i criteri

Creare tre criteri, tutti basati sulla stessa tabella di mapping. Entrambi i criteri della maschera di colonna usano la funzione pii_mask stessa. L'argomento pii_type indica alla funzione quale stile di maschera applicare, quindi non è necessaria una UDF separata per ogni tipo di colonna.

Il priority tag regolamentato viene utilizzato in MATCH COLUMNS per abbinare la order_priority colonna e trasferire il suo valore alla UDF di maschera come order_pri. Questo è il modo in cui viene implementato il mascheramento condizionale: la politica passa il valore di priorità della riga alla funzione definita dall'utente al momento della query.

CREATE POLICY user_access_filter
ON SCHEMA abac_tutorial.mapping_demo
ROW FILTER abac_tutorial.mapping_demo.access_filter
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag('region') AS r, has_tag('department') AS d
USING COLUMNS (r, d);

CREATE POLICY pii_mask_name
ON SCHEMA abac_tutorial.mapping_demo
COLUMN MASK abac_tutorial.mapping_demo.pii_mask
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'name') AS m,
  has_tag('priority') AS pri
ON COLUMN m
USING COLUMNS ('name', pri);

CREATE POLICY pii_mask_email
ON SCHEMA abac_tutorial.mapping_demo
COLUMN MASK abac_tutorial.mapping_demo.pii_mask
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'email') AS m,
  has_tag('priority') AS pri
ON COLUMN m
USING COLUMNS ('email', pri);

Passaggio 8: Verificare i risultati

La voce della tabella di mapping consente di accedere a us_east / engineering con l'autorizzazione masked. Eseguire la query seguente per verificare che venga visualizzato solo l'ordine 1, con informazioni personali parzialmente mascherate.

SELECT * FROM abac_tutorial.mapping_demo.orders;

L'ordine n. 1 ha order_priority = 'standard', quindi si applica l'autorizzazione masked .

Risultato previsto per l'utente:

Cosa vedono gli altri utenti:

Si noti che bob dispone di full autorizzazione ma vede ancora ***REDACTED*** perché l'ordine n. 4 è confidential. Questo è il mascheramento condizionale: il valore di priorità della riga sovrascrive l'autorizzazione dell'utente.

Passaggio 9: Aggiornare l'accesso in modo dinamico

Il vantaggio principale dell'approccio alla tabella di mapping consiste nel fatto che è possibile modificare l'accesso aggiornando le righe nella tabella. Non è necessario aggiornare politiche, funzioni definite dall'utente o appartenenze ai gruppi.

Riassegnarsi a un reparto diverso

Modificare il reparto da engineering a sales. Order #2 (Beta Inc) è un confidential ordine di vendita, quindi i suoi dati personali sono completamente rimossi anche con masked autorizzazione.

UPDATE abac_tutorial.mapping_demo.user_access
SET department = 'sales'
WHERE user_email = current_user();

Eseguire la query seguente per verificare. Verrà visualizzato l'ordine n. 2 con ***REDACTED*** informazioni personali.

SELECT * FROM abac_tutorial.mapping_demo.orders;

Ripristinare la modifica:

UPDATE abac_tutorial.mapping_demo.user_access
SET department = 'engineering'
WHERE user_email = current_user();

Aggiornare l'autorizzazione PII

Modificare l'autorizzazione da masked a full. Per le righe con priorità standard, vengono ora visualizzati i valori PII effettivi.

UPDATE abac_tutorial.mapping_demo.user_access
SET pii_access = 'full'
WHERE user_email = current_user();

Esegui la query seguente per verificare. L'ordine #1 ha standard priorità, quindi con full autorizzazione dovresti vedere Acme Corp e orders@acme.com.

SELECT * FROM abac_tutorial.mapping_demo.orders;

Ripristinare la modifica:

UPDATE abac_tutorial.mapping_demo.user_access
SET pii_access = 'masked'
WHERE user_email = current_user();

Concedere l'accesso a un'area aggiuntiva

Inserire una seconda riga per concedere l'accesso all'ingegneria dell'UE. Non sono necessari nuovi gruppi o criteri.

INSERT INTO abac_tutorial.mapping_demo.user_access
VALUES (current_user(), 'eu', 'engineering', 'masked', '2099-12-31');

Esegui la query seguente per verificare. Ora dovrebbero essere visualizzati sia l'ordine n. 1 (us_east, progettazione) che l'ordine n. 5 (eu, progettazione), con informazioni personali parzialmente mascherate.

SELECT * FROM abac_tutorial.mapping_demo.orders;

Rimuovere l'accesso aggiuntivo:

DELETE FROM abac_tutorial.mapping_demo.user_access
WHERE user_email = current_user() AND region = 'eu';

Scadenza dell'accesso

Impostare l'entry di accesso su una data precedente. La funzione definita dall'utente del filtro di riga controlla expires_on >= current_date(), quindi le voci scadute vengono ignorate automaticamente e l'accesso viene revocato automaticamente. Ciò è utile per i terzisti, i contratti di condivisione dei dati con una durata fissa o progetti limitati a tempo.

UPDATE abac_tutorial.mapping_demo.user_access
SET expires_on = current_date() - INTERVAL 1 DAY
WHERE user_email = current_user();

Esegui la query seguente affinché non vengano visualizzate righe.

SELECT * FROM abac_tutorial.mapping_demo.orders;

Ripristinare l'accesso con una data di scadenza futura:

UPDATE abac_tutorial.mapping_demo.user_access
SET expires_on = '2099-12-31'
WHERE user_email = current_user();

Eseguire la query seguente per verificare che l'accesso sia ripristinato.

SELECT * FROM abac_tutorial.mapping_demo.orders;

Sommario

Questa esercitazione ha illustrato tre modelli:

• Modello di tabella di mapping: una singola tabella di ricerca controlla sia il filtro delle righe che l'oscuramento delle colonne. Le modifiche di accesso vengono apportate aggiornando le righe, senza che siano necessarie modifiche ai criteri o ai gruppi.
• Maschera condizionale: la funzione di mascheramento definita dall'utente controlla la order_priority colonna in ogni riga per decidere come mascherare i dati personali. Le righe riservate vengono sempre completamente redatte indipendentemente dal livello di autorizzazione dell'utente, implementate tramite l'assegnazione di tag order_priority e il passaggio alla funzione definita dall'utente tramite MATCH COLUMNS.
• Scadenza dell'accesso: la tabella di mapping include una expires_on data. La funzione definita dall'utente del filtro di riga controlla questa data rispetto a current_date(), quindi le voci scadute vengono ignorate e l'accesso viene revocato automaticamente senza alcun intervento manuale.

Pulizia

Per rimuovere tutti gli oggetti creati in questa esercitazione, eseguire quanto segue.

DROP POLICY user_access_filter ON SCHEMA abac_tutorial.mapping_demo;
DROP POLICY pii_mask_name ON SCHEMA abac_tutorial.mapping_demo;
DROP POLICY pii_mask_email ON SCHEMA abac_tutorial.mapping_demo;
DROP FUNCTION IF EXISTS abac_tutorial.mapping_demo.access_filter;
DROP FUNCTION IF EXISTS abac_tutorial.mapping_demo.pii_mask;
DROP TABLE IF EXISTS abac_tutorial.mapping_demo.orders;
DROP TABLE IF EXISTS abac_tutorial.mapping_demo.user_access;
DROP SCHEMA IF EXISTS abac_tutorial.mapping_demo CASCADE;

Per rimuovere i tag region, department, pii e priority controllati, utilizzare l'interfaccia di Esplora Cataloghi.