Esercitazione: Configurare il controllo degli accessi basato sugli attributi con SQL

Questa esercitazione illustra come configurare i criteri di filtro di riga e maschera di colonna per il controllo degli accessi basato sugli attributi (ABAC) nel Unity Catalog usando SQL. Per la versione basata sull'interfaccia utente di Esplora cataloghi, vedere Esercitazione: Configurare il controllo degli accessi basato su attributi (ABAC).

In questo esempio, un team di analisi non può accedere ai record dei clienti dell'UE e le SSN sono sempre mascherate. I clienti che hanno acconsentito alla condivisione dei dati hanno visualizzato il messaggio di posta elettronica completo. Altri visualizzano solo una versione mascherata.

Questa esercitazione include i passaggi seguenti:

  1. Creare tag regolamentati
  2. Creare un catalogo, uno schema e una tabella di Unity Catalog
  3. Applicare tag regolati alle colonne
  4. Creare una funzione definita dall'utente per rilevare gli indirizzi UE
  5. Creare una politica di filtro di riga
  6. Testare il filtro di riga
  7. Creare una funzione definita dall'utente per mascherare i numeri di previdenza sociale
  8. Creare una politica per la mascheratura delle colonne
  9. Eseguire il test sulla maschera di colonna

Dopo aver completato questi passaggi, è possibile estendere l'esercitazione con mascheramento condizionale della posta elettronica (passaggi da 10 a 12).

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.

Le risorse di calcolo che eseguono runtime meno recenti non possono accedere alle tabelle protette dal controllo degli accessi basato sugli attributi (ABAC).

Passaggio 1: Creare tag regolamentati

I tag gestiti sono coppie chiave-valore definite a livello di account. Le politiche ABAC le usano per individuare le colonne da filtrare o mascherare. In questa esercitazione vengono creati due tag regolamentati:

  • Tag pii con tre valori consentiti: ssn, addresse email
  • Tag consent di sola chiave (nessun valore consentito) per identificare le colonne di consenso

Per creare un tag regolamentato, è necessario disporre dell'autorizzazione CREATE tag regolamentata a livello di account. Gli amministratori dell'account e dell'area di lavoro hanno CREATE per impostazione predefinita.

  1. Nell'area di lavoro di Azure Databricks fare clic sull'icona Dati.Catalogo.
  2. Fare clic sull'icona Scudo.il pulsante Govern.
  3. Nel menu a discesa fare clic su Tag gestiti.
  4. Fare clic su Crea tag regolamentato.
  5. Per la chiave del tag immettere pii.
  6. Immettere una descrizione per il tag regolamentato.
  7. Per i valori consentiti, immettere: ssn, addresse email. Solo questi valori possono essere assegnati a questa chiave di tag.
  8. Fare clic su Crea.
  9. Ripetere i passaggi da 4 a 8 per creare un secondo tag regolato con la chiave consent. Lasciare vuoti i valori consentiti (tag di sola chiave).

Avvertimento

I dati dei tag vengono archiviati come testo normale e possono essere replicati a livello globale. Non usare nomi, valori o descrittori di tag che potrebbero compromettere la sicurezza delle risorse. Ad esempio, non usare nomi di tag, valori o descrittori che contengono informazioni personali o riservate.

Passaggio 2: Creare la tabella clienti

Creare un catalogo, uno schema e una tabella con i profili cliente. La colonna has_consent verrà usata successivamente per il mascheramento condizionale delle email. I clienti che hanno dato il consenso (TRUE) hanno visualizzato il messaggio di posta elettronica completo.

Eseguire i comandi seguenti in un notebook collegato al calcolo in Databricks Runtime 16.4 o versione successiva:

-- Create catalog (if not already exists)
CREATE CATALOG IF NOT EXISTS abac_tutorial;
USE CATALOG abac_tutorial;

-- Create schema
CREATE SCHEMA IF NOT EXISTS customers;
USE SCHEMA customers;
CREATE OR REPLACE TABLE profiles (
    first_name STRING,
    last_name STRING,
    email STRING,
    phone_number STRING,
    home_address STRING,
    ssn_number STRING,
    has_consent BOOLEAN
);
INSERT INTO profiles (first_name, last_name, email, phone_number, home_address, ssn_number, has_consent)
VALUES
('John', 'Doe', 'john.doe@example.com', '123-456-7890', '123 Main St, NY', '123-45-6789', TRUE),
('Jane', 'Smith', 'jane.smith@example.com', '234-567-8901', '456 Oak St, CA', '234-56-7890', FALSE),
('Alice', 'Johnson', 'alice.j@example.com', '345-678-9012', '789 Pine St, TX', '345-67-8901', TRUE),
('Bob', 'Brown', 'bob.brown@example.com', '456-789-0123', '321 Maple St, FL', '456-78-9012', FALSE),
('Charlie', 'Davis', 'charlie.d@example.com', '567-890-1234', '654 Cedar St, IL', '567-89-0123', TRUE),
('Emily', 'White', 'emily.w@example.com', '678-901-2345', '987 Birch St, WA', '678-90-1234', FALSE),
('Frank', 'Miller', 'frank.m@example.com', '789-012-3456', '741 Spruce St, WA', '789-01-2345', TRUE),
('Grace', 'Wilson', 'grace.w@example.com', '890-123-4567', '852 Elm St, NV', '890-12-3456', TRUE),
('Hank', 'Moore', 'hank.moore@example.com', '901-234-5678', '963 Walnut St, CO', '901-23-4567', FALSE),
('Ivy', 'Taylor', 'ivy.taylor@example.com', '012-345-6789', '159 Aspen St, AZ', '012-34-5678', TRUE),
('Liam', 'Connor', 'liam.c@example.com', '111-222-3333', '12 Abbey Street, Dublin, Ireland EU', '111-22-3333', TRUE),
('Sophie', 'Dubois', 'sophie.d@example.com', '222-333-4444', '45 Rue de Rivoli, Paris, France Europe', '222-33-4444', FALSE),
('Hans', 'Müller', 'hans.m@example.com', '333-444-5555', '78 Berliner Str., Berlin, Germany E.U.', '333-44-5555', TRUE),
('Elena', 'Rossi', 'elena.r@example.com', '444-555-6666', '23 Via Roma, Milan, Italy Europe', '444-55-6666', FALSE),
('Johan', 'Andersson', 'johan.a@example.com', '555-666-7777', '56 Drottninggatan, Stockholm, Sweden EU', '555-66-7777', TRUE);

Passaggio 3: Aggiungere tag regolamentati alle colonne

Contrassegna le colonne ssn_number, home_address e email con il tag pii governato. Le politiche ABAC corrispondono alle colonne per tag, non per nome.

La has_consent colonna è contrassegnata con il consent tag regolamentato. Questa operazione è necessaria per la politica di mascheramento consapevole del consenso nel passaggio 11, che passa has_consent alla funzione definita dall'utente tramite USING COLUMNS.

ALTER TABLE abac_tutorial.customers.profiles
ALTER COLUMN ssn_number
SET TAGS ('pii' = 'ssn');

ALTER TABLE abac_tutorial.customers.profiles
ALTER COLUMN home_address
SET TAGS ('pii' = 'address');

ALTER TABLE abac_tutorial.customers.profiles
ALTER COLUMN email
SET TAGS ('pii' = 'email');

ALTER TABLE abac_tutorial.customers.profiles
ALTER COLUMN has_consent
SET TAGS ('consent' = '');

Passaggio 4: Creare una UDF per rilevare gli indirizzi UE

Questa funzione definita dall'utente viene passata al valore di ogni colonna contrassegnata pii = address e restituisce:

  • FALSE se l'indirizzo contiene EU, E.U.o Europe , la riga è nascosta.
  • TRUE in caso contrario, la riga viene visualizzata.
CREATE OR REPLACE FUNCTION is_not_eu_address(address STRING)
RETURNS BOOLEAN
RETURN (
    SELECT CASE
        WHEN LOWER(address) LIKE '%eu%'
          OR LOWER(address) LIKE '%e.u.%'
          OR LOWER(address) LIKE '%europe%'
        THEN FALSE
        ELSE TRUE
    END
);

Annotazioni

Si tratta di un controllo semplificato a scopo dimostrativo. Nell'ambiente di produzione, usare un metodo più affidabile, ad esempio una colonna di codice paese o una tabella di ricerca per determinare l'area.

Passaggio 5: Creare un criterio di filtro di riga

Per creare una politica, è necessario avere MANAGE sull'oggetto o esserne il proprietario. Per aggiungere un UDF a una policy, è necessario disporre della UDF EXECUTE.

CREATE POLICY hide_eu_customers
ON SCHEMA abac_tutorial.customers
ROW FILTER is_not_eu_address
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'address') AS addr_col
USING COLUMNS (addr_col);

È anche possibile creare criteri tramite l'interfaccia utente di Esplora cataloghi. Per informazioni dettagliate, vedere Creare e gestire i criteri di controllo degli accessi basati su attributi.

Passaggio 6: Testare il filtro di riga

Eseguire la query seguente per verificare che i criteri di filtro delle righe funzionino.

SELECT * FROM abac_tutorial.customers.profiles;

Vengono restituite solo le 10 righe di non residenti nell'UE. I cinque clienti dell'UE (Liam, Sophie, Hans, Elena e Johan) sono nascosti.

Passaggio 7: Creare una funzione definita dall'utente per mascherare i numeri di previdenza sociale

Questa funzione definita dall'utente restituisce un segnaposto completamente modificato per qualsiasi valore SSN passato.

CREATE OR REPLACE FUNCTION redact_ssn(ssn STRING)
RETURNS STRING
RETURN '***-**-****';

Passaggio 8: Creare un criterio di mascheramento delle colonne

Creare un criterio che si applichi a tutte le colonne contrassegnate pii = ssn e alla funzione redact_ssn per ognuna di esse.

CREATE POLICY redact_ssn_policy
ON SCHEMA abac_tutorial.customers
COLUMN MASK redact_ssn
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'ssn') AS ssn_col
ON COLUMN ssn_col;

Passaggio 9: Testare la maschera di colonna

Eseguire la query seguente per verificare che sia il filtro di riga che la maschera di colonna siano attivi.

SELECT * FROM abac_tutorial.customers.profiles;

I numeri di previdenza sociale ora restituiscono come ***-**-****. Vengono restituiti solo i residenti non-UE, perché il filtro di riga è anche attivo.

Estensione: mascheramento condizionale della posta elettronica

I passaggi seguenti estendono l'esercitazione con il mascheramento della posta elettronica consapevole del consenso. I clienti che hanno acconsentito (has_consent = TRUE) hanno il loro indirizzo email completo visualizzato; altri visualizzano solo il primo carattere e il dominio.

Questa funzione definita dall'utente accetta due argomenti:

  • email: valore effettivo del messaggio di posta elettronica dalla colonna corrispondente
  • consent: valore della has_consent colonna nella stessa riga
CREATE OR REPLACE FUNCTION mask_email_by_consent(email STRING, consent BOOLEAN)
RETURNS STRING
RETURN CASE
  WHEN consent = TRUE THEN email
  ELSE CONCAT(LEFT(email, 1), '***@', SUBSTRING_INDEX(email, '@', -1))
END;

Passaggio 11: Creare i criteri di mascheramento della posta elettronica condizionale

Questa politica è destinata alle colonne contrassegnate pii = email e passa la colonna has_consent alla funzione definita dall'utente.

Annotazioni

La has_consent colonna è stata contrassegnata con il consent tag regolamentato nel passaggio 3. Questa operazione è necessaria perché USING COLUMNS può fare riferimento solo alle colonne corrispondenti tramite MATCH COLUMNS. Anche se has_consent non è mascherato, deve essere contrassegnato in modo che il criterio possa passare il relativo valore alla funzione definita dall'utente.

CREATE POLICY mask_email_by_consent_policy
ON SCHEMA abac_tutorial.customers
COLUMN MASK mask_email_by_consent
TO `account users`
FOR TABLES
MATCH COLUMNS has_tag_value('pii', 'email') AS email_col,
  has_tag('consent') AS consent_col
ON COLUMN email_col
USING COLUMNS (consent_col);

Passaggio 12: Testare la maschera della posta elettronica condizionale

Eseguire la query seguente per verificare che tutti e tre i criteri funzionino insieme.

SELECT * FROM abac_tutorial.customers.profiles;

I clienti con has_consent = TRUE hanno la loro email completa visualizzata. I clienti con has_consent = FALSE visualizzano una versione mascherata. Le SSN rimangono completamente mascherate e vengono restituiti solo i clienti non UE.

first_name ha_consenso posta elettronica ssn_number
John VERO john.doe@example.com ***-**-****
Jane FALSE j***@example.com ***-**-****
Alice VERO alice.j@example.com ***-**-****
Bob FALSE b***@example.com ***-**-****
Charlie VERO charlie.d@example.com ***-**-****
Emily FALSE e***@example.com ***-**-****
Franco VERO frank.m@example.com ***-**-****
Grazia VERO grace.w@example.com ***-**-****
Hank FALSE h***@example.com ***-**-****
Edera VERO ivy.taylor@example.com ***-**-****

Sommario

Questa esercitazione ha illustrato tre modelli di controllo degli accessi in base al ruolo:

  • Filtro delle righe: nascondere le righe in base ai valori di colonna corrispondenti ai tag regolati
  • Maschera di colonna: mascherare le colonne corrispondenti ai tag regolati
  • Maschera condizionale: mascherare una colonna in base al valore di un'altra colonna nella stessa riga, contrassegnando la colonna di contesto e passandola alla UDF tramite USING COLUMNS

Pulizia

Per rimuovere tutti gli oggetti creati in questa esercitazione, eseguire quanto segue. Se sono stati ignorati i passaggi di mascheramento della posta elettronica condizionale, le istruzioni DROP POLICY mask_email_by_consent_policy e DROP FUNCTION mask_email_by_consent hanno esito negativo, come previsto.

DROP POLICY hide_eu_customers ON SCHEMA abac_tutorial.customers;
DROP POLICY redact_ssn_policy ON SCHEMA abac_tutorial.customers;
DROP POLICY mask_email_by_consent_policy ON SCHEMA abac_tutorial.customers;
DROP FUNCTION IF EXISTS abac_tutorial.customers.is_not_eu_address;
DROP FUNCTION IF EXISTS abac_tutorial.customers.redact_ssn;
DROP FUNCTION IF EXISTS abac_tutorial.customers.mask_email_by_consent;
DROP TABLE IF EXISTS abac_tutorial.customers.profiles;
DROP SCHEMA IF EXISTS abac_tutorial.customers CASCADE;

Per rimuovere i tag regolamentati pii e consent, usare l'interfaccia utente di Catalog Explorer.