Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
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:
- Creare tag regolamentati
- Creare un catalogo, uno schema e una tabella di Unity Catalog
- Applicare tag regolati alle colonne
- Creare una funzione definita dall'utente per rilevare gli indirizzi UE
- Creare una politica di filtro di riga
- Testare il filtro di riga
- Creare una funzione definita dall'utente per mascherare i numeri di previdenza sociale
- Creare una politica per la mascheratura delle colonne
- 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).
-
MANAGEautorizzazione per il catalogo o lo schema di destinazione. -
EXECUTEnelle 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
piicon tre valori consentiti:ssn,addresseemail - Tag
consentdi 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.
- Nell'area di lavoro di Azure Databricks fare clic
Catalogo.
- Fare clic
il pulsante Govern.
- Nel menu a discesa fare clic su Tag gestiti.
- Fare clic su Crea tag regolamentato.
- Per la chiave del tag immettere
pii. - Immettere una descrizione per il tag regolamentato.
- Per i valori consentiti, immettere:
ssn,addresseemail. Solo questi valori possono essere assegnati a questa chiave di tag. - Fare clic su Crea.
- 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:
-
FALSEse l'indirizzo contieneEU,E.U.oEurope, la riga è nascosta. -
TRUEin 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.
Passaggio 10: Creare una funzione definita dall'utente per il mascheramento dell'email con riconoscimento del consenso
Questa funzione definita dall'utente accetta due argomenti:
-
email: valore effettivo del messaggio di posta elettronica dalla colonna corrispondente -
consent: valore dellahas_consentcolonna 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.