White paper sulla sicurezza di Azure Synapse Analytics: controllo di accesso

  • Articolo

Nota

Questo articolo fa parte della serie di articoli del White paper sulla sicurezza di Azure Synapse Analytics. Per una panoramica della serie, vedere White paper sulla sicurezza di Azure Synapse Analytics.

A seconda del modo in cui i dati sono stati modellati e archiviati, la governance dei dati e il controllo di accesso potrebbero richiedere che gli sviluppatori e gli amministratori della sicurezza usino approcci diversi, o combinazione di tecniche, per implementare una solida base di sicurezza.

Azure Synapse supporta un'ampia gamma di funzionalità per controllare chi può accedere ai dati. Queste funzionalità sono basate su un set di funzionalità avanzate di controllo di accesso, tra cui:

Sicurezza a livello di oggetto

A ogni oggetto in un pool SQL dedicato sono associate autorizzazioni che possono essere concesse a un'entità di sicurezza. Nel contesto di utenti e account del servizio, questo è il modo in cui vengono protette le singole tabelle, viste, stored procedure e funzioni. Le autorizzazioni per gli oggetti, ad esempio SELECT, possono essere concesse agli account utente (account di accesso SQL, utenti o gruppi di Microsoft Entra) e ai ruoli del database, offrendo flessibilità per gli amministratori di database. Inoltre, le autorizzazioni concesse per tabelle e viste possono essere combinate con altri meccanismi di controllo di accesso (descritti di seguito), ad esempio la sicurezza a livello di colonna, la sicurezza a livello di riga e la maschera dati dinamica.

In Azure Synapse vengono concesse tutte le autorizzazioni a utenti e ruoli a livello di database. Inoltre, a tutti gli utenti a cui è stato concesso il ruolo di controllo degli accessi in base al ruolo di amministratore di Synapse predefinito a livello di area di lavoro viene concesso automaticamente l'accesso completo a tutti i pool SQL dedicati.

Oltre a proteggere le tabelle SQL in Azure Synapse, è possibile proteggere anche i pool SQL dedicati (in precedenza SQL Data Warehouse), il pool SQL serverless e le tabelle Spark. Per impostazione predefinita, gli utenti assegnati al ruolo Collaboratore ai dati dei BLOB di archiviazione dei data lake connessi all'area di lavoro dispongono delle autorizzazioni READ, WRITE ed EXECUTE per tutte le tabelle create da Spark quando gli utenti eseguono in modo interattivo il codice nel notebook. Si chiama pass-through Microsoft Entra e si applica a tutti i data lake connessi all'area di lavoro. Tuttavia, se lo stesso utente esegue lo stesso notebook tramite una pipeline, l'identità del servizio gestito dell'area di lavoro viene usata per l'autenticazione. Pertanto, per consentire alla pipeline di eseguire correttamente l'identità del servizio gestito dell'area di lavoro, deve appartenere anche al ruolo Collaboratore ai dati dei BLOB di archiviazione del data lake a cui si accede.

Sicurezza a livello di riga

La sicurezza a livello di riga consente agli amministratori della sicurezza di stabilire e controllare l'accesso con granularità fine a righe di tabella specifiche in base al profilo di un utente (o un processo) che esegue una query. Le caratteristiche del profilo o dell'utente possono fare riferimento all'appartenenza al gruppo o al contesto di esecuzione. La sicurezza a livello di riga consente di impedire l'accesso non autorizzato quando gli utenti eseguono query sui dati dalle stesse tabelle, ma devono visualizzare subset diversi di dati.

Nota

La sicurezza a livello di riga è supportata in Azure Synapse e nel pool SQL dedicato (in precedenza SQL Data Warehouse), ma non è supportata per il pool Apache Spark e il pool SQL serverless.

Sicurezza a livello di colonna

La sicurezza a livello di colonna consente agli amministratori della sicurezza di impostare autorizzazioni che limitano chi può accedere alle colonne sensibili nelle tabelle. Viene impostato a livello di database e può essere implementato senza la necessità di modificare la progettazione del modello di dati o del livello applicazione.

Nota

La sicurezza a livello di colonna è supportata in Azure Synapse, nelle viste del pool SQL serverless e nel pool SQL dedicato (in precedenza SQL Data Warehouse), ma non è supportata per le tabelle esterne del pool SQL serverless e il pool Apache Spark. In caso di una soluzione alternativa alle tabelle esterne del pool SQL serverless, è possibile creare una vista sopra una tabella esterna.

Maschera dati dinamica

La maschera dati dinamica consente agli amministratori della sicurezza di limitare l'esposizione dei dati sensibili mascherandoli in lettura agli utenti senza privilegi. Consente di impedire l'accesso non autorizzato ai dati sensibili consentendo agli amministratori di determinare la modalità di visualizzazione dei dati in fase di query. In base all'identità dell'utente autenticato e all'assegnazione del gruppo nel pool SQL, una query restituisce dati mascherati o non mascherati. La maschera viene sempre applicata indipendentemente dal fatto che i dati siano accessibili direttamente da una tabella o tramite una vista o una stored procedure.

Nota

La maschera dati dinamica è supportata in Azure Synapse e nel pool SQL dedicato (in precedenza SQL Data Warehouse), ma non è supportata per il pool Apache Spark e il pool SQL serverless.

Controllo degli accessi in base al ruolo di Synapse

Azure Synapse include anche ruoli di controllo degli accessi in base al ruolo di Synapse per gestire diversi aspetti di Synapse Studio. Sfruttare questi ruoli predefiniti per assegnare autorizzazioni a utenti, gruppi o altre entità di sicurezza per gestire chi può:

  • Pubblicare artefatti di codice ed elencare o accedere agli artefatti di codice pubblicati.
  • Eseguire il codice nei pool di Apache Spark e nei runtime di integrazione.
  • Accedere ai servizi collegati (dati) che sono protetti da credenziali.
  • Monitorare o annullare l'esecuzione di un processo, rivedere l'output del processo e i log di esecuzione.

Passaggi successivi

Nell'articolo successivo in questo white paper vengono fornite informazioni sull'autenticazione.