Proteggere i dati sensibili nel database SQL con i criteri di protezione di Microsoft Purview
Si applica a:✅Database SQL in Microsoft Fabric
Microsoft Purview è una famiglia di soluzioni per la governance dei dati, la gestione del rischio e la conformità che possono aiutare l'organizzazione a controllare, proteggere e gestire il patrimonio di dati. Tra gli altri vantaggi, Microsoft Purview consente di etichettare gli elementi del database SQL con etichette di riservatezza e definire criteri di protezione che controllano l'accesso in base alle etichette di riservatezza.
Questo articolo illustra il funzionamento dei criteri di protezione di Microsoft Purview con i controlli di accesso di Microsoft Fabric e i controlli di accesso SQL nel database SQL in Microsoft Fabric.
Per informazioni generali sulle funzionalità di Microsoft Purview per Microsoft Fabric, incluso il database SQL, vedere gli articoli elencati in Contenuto correlato.
Funzionamento dei criteri di protezione nel database SQL
Ogni criterio di protezione per Microsoft Fabric è associato a un'etichetta di riservatezza. I criteri di protezione controllano l'accesso agli elementi con l'etichetta associata tramite due controlli di accesso:
Consenti agli utenti di mantenere l'accesso in lettura : se abilitata, consente agli utenti specificati (o agli utenti appartenenti ai gruppi specificati) di mantenere l'autorizzazione Lettura elemento per gli elementi etichettati se gli utenti specificati dispongono già dell'autorizzazione. Tutte le altre autorizzazioni per cui gli utenti specificati dispongono dell'elemento vengono rimosse. Nel database SQL è necessaria l'autorizzazione Lettura elemento per consentire a un utente di connettersi a un database. Pertanto, se un utente non è specificato in questo controllo di accesso, l'utente non può connettersi al database.
Consenti agli utenti di mantenere il controllo completo: se abilitata, consente agli utenti specificati (o agli utenti appartenenti ai gruppi specificati) di mantenere il controllo completo sull'elemento etichettato se gli utenti specificati lo hanno già o qualsiasi altra autorizzazione. Per gli elementi del database SQL, questo controllo consente agli utenti di conservare l'autorizzazione Scrittura elemento, ovvero l'utente mantiene l'accesso amministrativo completo all'interno del database. Se un utente non è specificato in questo controllo di accesso, l'autorizzazione Write item viene effettivamente rimossa dall'utente. Questo controllo non ha alcun effetto sulle autorizzazioni native SQL dell'utente nel database. Per altre informazioni, vedere l'esempio 4 e le limitazioni.
Esempi
Gli esempi in questa sezione condividono la configurazione seguente:
- Un'organizzazione ha un'area di lavoro di Microsoft Fabric, denominata Produzione.
- L'area di lavoro contiene un elemento di database SQL, denominato Sales, con l'etichetta Riservatezza riservata.
- In Microsoft Purview sono disponibili criteri di protezione applicabili a Microsoft Fabric. Il criterio è associato all'etichetta Riservatezza riservata.
Esempio 1
- Un utente è membro del ruolo Collaboratore per l'area di lavoro Produzione.
- L'opzione Consenti agli utenti di mantenere il controllo di accesso in lettura è abilitata, ma non include l'utente.
- Consenti agli utenti di mantenere il controllo di accesso con controllo completo è disabilitato/inattivo.
Il criterio rimuove l'autorizzazione Lettura elemento dell'utente, pertanto l'utente non può connettersi al database Sales. L'utente non può quindi leggere o accedere ai dati nel database.
Esempio 2
- Un utente dispone dell'autorizzazione Lettura elemento per il database Sales.
- L'utente è membro del ruolo a livello di database nativo di SQL db_owner nel database.
- L'opzione Consenti agli utenti di mantenere il controllo di accesso in lettura è abilitata, ma non include l'utente.
- Consenti agli utenti di mantenere il controllo di accesso con controllo completo è disabilitato/inattivo.
Il criterio rimuove l'autorizzazione Lettura elemento dell'utente, pertanto l'utente non può connettersi al database Sales, indipendentemente dalle autorizzazioni sql native dell'utente (concesse tramite l'appartenenza dell'utente al ruolo db_owner) nel database. L'utente non può quindi leggere o accedere ai dati nel database.
Esempio 3
- Un utente è membro del ruolo Collaboratore per l'area di lavoro Produzione.
- L'utente non dispone di autorizzazioni native SQL concesse nel database.
- L'opzione Consenti agli utenti di mantenere il controllo di accesso in lettura è abilitata e include l'utente.
- L'opzione Consenti agli utenti di mantenere il controllo di accesso completo è abilitata, ma non include l'utente.
Come membro del ruolo Collaboratore, l'utente ha inizialmente tutte le autorizzazioni per il database Sales, tra cui Read, ReadData e Write. Il criterio Consenti agli utenti di mantenere il controllo di accesso in lettura nei criteri consente all'utente di conservare le autorizzazioni Lettura e ReadData, tuttavia consenti agli utenti di mantenere il controllo di accesso completo rimuove l'autorizzazione di scrittura dell'utente. Di conseguenza, l'utente può connettersi al database e leggere i dati, ma l'utente perde l'accesso amministrativo al database, inclusa la possibilità di scrivere/modificare i dati.
Esempio 4
- Un utente dispone dell'autorizzazione Lettura elemento per il database Sales.
- L'utente è membro del ruolo a livello di database nativo di SQL db_owner nel database.
- L'opzione Consenti agli utenti di mantenere il controllo di accesso in lettura è abilitata e include l'utente.
- L'opzione Consenti agli utenti di mantenere il controllo di accesso completo è abilitata, ma non include l'utente.
Il criterio Consenti agli utenti di mantenere il controllo di accesso in lettura nei criteri consente all'utente di mantenere l'autorizzazione di lettura. Poiché l'utente non ha inizialmente accesso con controllo completo (autorizzazione Scrittura elemento), l'opzione Consenti agli utenti di mantenere il controllo di accesso con controllo completo non ha alcun effetto sull'autorizzazione dell'utente concessa in Microsoft Fabric. Consenti agli utenti di mantenere il controllo di accesso con controllo completo non influisce sull'autorizzazione sql nativa dell'utente nel database. Come membro del ruolo db_owner, l'utente continua ad avere accesso amministrativo al database. Vedere Limitazioni.
Limiti
- Consenti agli utenti di mantenere il controllo di accesso completo nei criteri di protezione di Microsoft Purview non ha alcun impatto sulle autorizzazioni native di SQL, concesse agli utenti in un database.