Migliori pratiche per i segreti di Unity Catalog

Organizza i segreti di Unity Catalog in modo che ogni applicazione possa accedere solo ai propri segreti, la maggior parte delle entità usi un segreto senza leggerne il valore e tu controlli la chiave che cifra i valori. Per informazioni su come creare, concedere e leggere segreti, vedi Segreti in Unity Catalog.

Raggruppa i segreti in base a chi ne ha bisogno

Crea uno schema per ogni applicazione, ambiente o team, e concedi CREATE SECRET privilegi sullo schema invece che sul catalogo. Uno schema contiene fino a 1.000 segreti, e un metastore fino a 10.000.

• Grant su un singolo segreto: Un grant su uno spazio dei nomi si applica a ogni segreto in esso contenuto, inclusi quelli aggiunti successivamente. Quando un titolare ha bisogno di un solo segreto, concedere READ SECRET su quel segreto invece che sul suo schema.
• Dai ai segreti di produzione un proprio catalogo quando ne hai bisogno: Workspace binding e chiavi gestite dal cliente si applicano a un intero catalogo. Per tenere i segreti di produzione fuori dagli spazi di sviluppo o per criptarli con una propria chiave, inserili in un catalogo separato. Vedi Workspace-catalog binding e Crittografare i segreti gestiti da Azure Databricks con la propria chiave.

Per dare all'applicazione degli ordini un proprio schema e lasciare che un lavoro di reportistica legga solo uno dei suoi segreti, esegui quanto segue:

-- The application's service principal reads every secret in its schema
CREATE SCHEMA main.orders_app;
GRANT USE CATALOG ON CATALOG main TO `orders-service-principal`;
GRANT USE SCHEMA, READ SECRET ON SCHEMA main.orders_app TO `orders-service-principal`;

-- The reporting job reads only the warehouse password
GRANT USE CATALOG ON CATALOG main TO `reporting-service-principal`;
GRANT USE SCHEMA ON SCHEMA main.orders_app TO `reporting-service-principal`;
GRANT READ SECRET ON SECRET main.orders_app.warehouse_password TO `reporting-service-principal`;

Per i segreti supportati da Azure Key Vault, usa un Key Vault per ogni schema, con la propria credenziale di servizio e connessione. Le connessioni Key Vault non supportano i filtri tag, quindi il vault è il confine. Se un caveau contiene più di 1.000 segreti, il Catalogo Unity importa prima i più vecchi e salta il resto.

Non supportare uno schema a cui molte applicazioni possono accedere con un unico Key Vault condiviso.

Gestire i permessi per individuare, ruotare e leggere i secret separatamente

Ognuno di questi è un privilegio separato, quindi un'entità che aggiorna un segreto o lo trova in Catalog Explorer non deve vederne il valore:

Per lasciare un principale	Grant	Restituisce il valore
Trova segreti e richiedi l'accesso	BROWSE sul catalogo. Mostra i metadati di ogni segreto, come nome, proprietario e data di scadenza.	No
Ruota un segreto aggiornandone il valore	WRITE SECRET	No
Leggi il valore, ad esempio con dbutils.secrets in un processo	READ SECRET	Yes

Per l'elenco completo dei privilegi, vedi Concedere accesso ai secret.

Per permettere a tutti di trovare i segreti e richiedere l'accesso, e permettere a un lavoro di rotazione di aggiornare la password del data warehouse senza leggerla, esegui quanto segue:

GRANT BROWSE ON CATALOG main TO `account users`;

GRANT USE CATALOG ON CATALOG main TO `rotation-service-principal`;
GRANT USE SCHEMA ON SCHEMA main.orders_app TO `rotation-service-principal`;
GRANT WRITE SECRET ON SECRET main.orders_app.warehouse_password TO `rotation-service-principal`;

BROWSE mostra i commenti a chiunque ce l'ha. Usa il commento di un segreto per dire chi ne è il proprietario e come richiedere l'accesso. Non mettere mai un valore, o un indizio su di uno, in un commento.

Crittografa i segreti gestiti da Azure Databricks con la tua chiave

Le impostazioni della chiave gestita dal cliente (CMK) su un catalogo si applicano a ogni segreto gestito da Azure Databricks in esso. Per criptare i segreti di produzione con una chiave separata, inserili in un catalog dedicato. Per informazioni su come la CMK si applica ai segreti, vedi Crittografare i valori segreti con chiavi gestite dal cliente.

Ruota le credenziali all'origine

Per i segreti supportati da Azure Key Vault, ruota i valori in Azure Key Vault, ad esempio con una politica di rotazione di Key Vault. Non copiare i loro valori nei segreti gestiti da Azure Databricks, perché ogni copia è un valore da aggiornare periodicamente.

Per i segreti gestiti da Azure Databricks, aggiorna il valore in Catalog Explorer o con l'API REST. Imposta una data di scadenza in modo che Catalog Explorer mostri un avviso quando il segreto scade.

Il codice che già contiene un valore lo conserva finché non legge di nuovo il segreto. Nei lavori di lunga durata, leggi il segreto ogni volta che apri una connessione invece di solo all'avvio.

Lascia che i carichi di lavoro usino i secret senza leggerli

La maggior parte degli utenti che si affidano a un segreto non ha mai bisogno di vederne il valore. Un UDF del Catalogo Unity che dichiara un segreto lo legge con i permessi del proprietario, quindi i chiamanti devono disporre solo di EXECUTE sull'UDF, ad esempio per mascherare o hashare i dati personali. Al contrario, chiunque esegue una funzione SQL che chiama secret() su uno scope dei segreti del workspace ha bisogno di READ sullo scope, che espone ogni segreto al suo interno. Vedi Usa segreti negli UDF.

• Concedere READ SECRET solo ai service principal che gestiscono i processi, ai proprietari delle UDF che dichiarano il segreto e al piccolo gruppo che possiede i segreti.
• Fai di un gruppo o un'entità servizio il proprietario di ogni UDF che dichiara un segreto, così l'UDF non fallisce quando qualcuno lascia il team o l'organizzazione.
• Usa UDF con ambito di sessione solo quando ogni chiamante può già leggere il segreto. Leggono i secret con il permesso del chiamante.

Warning

Non restituire mai un valore segreto da un UDF. L'oscuramento non impedisce al codice UDF di restituire un valore nei risultati della query.

Un servizio provider di modelli può anche utilizzare un segreto di Unity Catalog come credenziale fornitore, quindi i chiamanti interrogano il modello senza vedere la chiave. Vedi una credenziale di fornitore con un segreto del catalogo Unity.

Controlla chi può concedere l'accesso e controllalo

• Assegna la proprietà dei segreti e dei loro schemi a un gruppo invece che a un individuo.
• Gli amministratori del metastore e i principal con MANAGE non possono leggere un valore, ma possono concedersi da soli READ SECRET. Limitate MANAGE a un piccolo gruppo.
• Rivedi le letture segrete e le autorizzazioni nella system.access.audit tabella del sistema. Vedi Controlla l'accesso ai segreti.

Risorse aggiuntive

Resource	Description
Catalogo Secrets in Unity	Crea, concedi e leggi i secret di Unity Catalog.
Gestione dei segreti	Confronta i secret di Unity Catalog con gli scope dei secret dello spazio di lavoro e vedi dove puoi usare ciascuno.