Gestire le autorizzazioni utente nei pool SQL serverless di Azure Synapse
Per proteggere i dati, Archiviazione di Azure implementa un modello di controllo di accesso che supporta sia il controllo degli accessi in base al ruolo di Azure sia gli elenchi di controllo di accesso (ACL) come POSIX (Portable Operating System Interface for Unix)
È possibile associare un'entità di sicurezza con un livello di accesso per file e directory. Queste associazioni vengono acquisite in un elenco di controllo di accesso (ACL). Per ogni file e directory nell'account di archiviazione è presente un elenco di controllo di accesso. Quando un'entità di sicurezza tenta un'operazione su un file o una directory, un controllo dell'elenco di controllo di accesso determina se l'entità di sicurezza (utente, gruppo, entità servizio o identità gestita) ha il livello di autorizzazione corretto per eseguire l'operazione.
Esistono due tipi di elenco di controllo di accesso:
ACL di accesso
Controlla l'accesso a un oggetto. Sia i file che le directory hanno ACL di accesso.
ACL predefinito
Modello di ACL associato a una directory che determina gli ACL di accesso per tutti gli elementi figlio creati nella directory. I file non hanno ACL predefiniti.
Sia gli ACL di accesso che gli ACL predefiniti presentano la stessa struttura.
Le autorizzazioni per un oggetto contenitore sono lettura, scrittura ed esecuzione e possono essere usate per file e cartelle, come mostrato nella tabella seguente:
Livelli di autorizzazioni
Autorizzazione | file | Directory |
---|---|---|
Lettura (R) | È possibile leggere il contenuto di un file | Per elencare il contenuto della directory, sono necessarie le autorizzazioni di Lettura ed Esecuzione |
Scrittura (W) | È possibile scrivere o aggiungere in un file | Per creare elementi figlio in una directory, sono necessarie le autorizzazioni di Scrittura ed Esecuzione |
Esecuzione (X) | Nessun valore nel contesto di Data Lake Storage Gen2 | È necessaria per attraversare gli elementi figlio di una directory |
Linee guida per la configurazione degli elenchi di controllo di accesso
Usare sempre gruppi di sicurezza di Microsoft Entra come entità di sicurezza assegnata in una voce di elenco di controllo di accesso. Evitare di assegnare direttamente singoli utenti o entità servizio. L'uso di questa struttura consentirà di aggiungere e rimuovere utenti o entità servizio senza la necessità di riapplicare gli elenchi di controllo di accesso a un'intera struttura di directory. Al contrario, è possibile aggiungere o rimuovere utenti ed entità servizio nel gruppo di sicurezza di Microsoft Entra appropriato.
Esistono molti modi per configurare gruppi. Si supponga, ad esempio, una directory denominata /LogData che contiene i dati di log generati dal server. Azure Data Factory inserisce dati in questa cartella. Utenti specifici del team di progettazione dei servizi caricano i log e gestiscono altri utenti di questa cartella e diversi cluster Databricks analizzano i log dalla cartella.
Per consentire queste attività, è possibile creare un gruppo LogsWriter e un gruppo LogsReader. È quindi possibile assegnare le autorizzazioni in questo modo:
- Aggiungere il gruppo LogsWriter all'ACL della directory /LogData con autorizzazioni di lettura, scrittura ed esecuzione.
- Aggiungere il gruppo LogsReader all'ACL della directory /LogData con autorizzazioni di lettura ed esecuzione.
- Aggiungere l'oggetto entità servizio o l'identità del servizio gestita per Azure Data Factory al gruppo LogsWriters.
- Aggiungere gli utenti del team di progettazione dei servizi al gruppo LogsWriter.
- Aggiungere l'oggetto entità servizio o l'identità del servizio gestita per Databricks al gruppo LogsReader.
Se un utente del team di progettazione dei servizi lascia l'azienda, è possibile rimuoverlo semplicemente dal gruppo LogsWriter. Se l'utente non è stato aggiunto a un gruppo, ma è stata invece aggiunta una voce di elenco di controllo di accesso dedicata per l'utente, è necessario rimuovere la voce dalla directory /LogData. In questo caso, è anche necessario rimuovere la voce da tutti i file e le sottodirectory nell'intera gerarchia di directory della directory /LogData.
Ruoli necessari per utenti del pool SQL serverless
Per gli utenti che necessitano di accesso in sola lettura, è necessario assegnare un ruolo denominato Lettore dei dati dei BLOB di archiviazione.
Per gli utenti che necessitano di accesso in lettura/scrittura, è necessario assegnare un ruolo denominato Collaboratore ai dati dei BLOB di archiviazione. L'accesso in lettura/scrittura è necessario se l'utente deve poter eseguire l'istruzione CREATE EXTERNAL TABLE AS SELECT (CETAS).
Nota
Se l'utente ha un ruolo di proprietario o collaboratore, il ruolo non è sufficiente. Azure Data Lake Storage Gen2 include ruoli avanzati che devono essere assegnati.
Autorizzazione a livello di database
Per fornire un accesso più granulare all'utente, è necessario usare la sintassi Transact-SQL per creare account di accesso e utenti.
Per concedere a un utente l'accesso a un singolo database del pool SQL serverless, seguire la procedura di questo esempio:
CREATE LOGIN
use master CREATE LOGIN [alias@domain.com] FROM EXTERNAL PROVIDER;
CREATE USER
use yourdb -- Use your DB name CREATE USER alias FROM LOGIN [alias@domain.com];
Aggiungere USER ai membri del ruolo specificato
use yourdb -- Use your DB name alter role db_datareader Add member alias -- Type USER name from step 2 -- You can use any Database Role which exists -- (examples: db_owner, db_datareader, db_datawriter) -- Replace alias with alias of the user you would like to give access and domain with the company domain you are using.
Autorizzazione a livello di server
Per concedere a un utente l'accesso completo a tutti i database del pool SQL serverless, seguire la procedura di questo esempio:
CREATE LOGIN [alias@domain.com] FROM EXTERNAL PROVIDER; ALTER SERVER ROLE sysadmin ADD MEMBER [alias@domain.com];