Eseguire la migrazione al summit per l'innovazione:
Informazioni su come la migrazione e la modernizzazione in Azure possono migliorare le prestazioni, la resilienza e la sicurezza dell'azienda, consentendo di adottare completamente l'intelligenza artificiale.Iscriviti subito
Questo browser non è più supportato.
Esegui l'aggiornamento a Microsoft Edge per sfruttare i vantaggi di funzionalità più recenti, aggiornamenti della sicurezza e supporto tecnico.
database SQL di Azure, database SQL in Microsoft Fabric, Istanza gestita di SQL di Azure e Azure Synapse Analytics supportano la maschera dati dinamica (DDM). La funzione Maschera dati dinamica limita l'esposizione dei dati sensibili, nascondendoli agli utenti senza privilegi.
Dynamic Data Masking contribuisce a evitare l’accesso non autorizzato ai dati sensibili consentendo ai clienti di definire la quantità di dati sensibili da rivelare, in modo da avere un effetto minimo sul livello dell'applicazione. Si tratta di una funzionalità di sicurezza basata su criteri che consente di nascondere i dati sensibili nel set di risultati di una query in campi del database designati, senza modificare i dati contenuti nel database.
Ad esempio, un addetto all'assistenza di un call center potrebbe identificare una persona che chiama confermando alcuni caratteri del suo indirizzo e-mail, ma l'indirizzo e-mail completo non dovrebbe essere rivelato all'addetto all'assistenza. È possibile definire una regola di mascheramento che maschera tutti gli indirizzi e-mail nel set di risultati di qualsiasi query. Come altro esempio, è possibile definire una maschera dati appropriata per proteggere i dati personali, in modo che uno sviluppatore possa eseguire query negli ambienti di produzione per la risoluzione dei problemi senza violare le normative di conformità.
Nozioni fondamentali su Dynamic Data Masking
Per database SQL di Azure, è possibile configurare un criterio di maschera dati dinamica nel portale di Azure selezionando il riquadro Maschera dati dinamica in Sicurezza nel riquadro di configurazione database SQL.
Questa funzionalità non può essere impostata usando il portale di Azure per Istanza gestita di SQL o il database SQL in Fabric. Usare invece T-SQL, come nell'esempio Dynamic Data Masking in questo articolo. Per altre informazioni, vedere Dynamic Data Masking.
Criteri di mascheramento dei dati dinamici
Utenti SQL esclusi dalla maschera: un insieme di utenti SQL, che può includere identità di Microsoft Entra ID (in precedenza Azure Active Directory) che ricevono dati senza maschera nei risultati delle query SQL. Gli utenti con diritti amministrativi come l'amministratore del server, l'amministratore di Microsoft Entra e il ruolo db_owner possono visualizzare i dati originali senza maschera. Nota: si applica anche al ruolo amministratore di sistema in SQL Server.
Regole di mascheramento: un insieme di regole che definisce i campi designati a cui applicare la maschera e la funzione di mascheramento da usare. I campi designati possono essere definiti tramite uno schema, un nome di tabella e un nome di colonna del database.
Funzioni di mascheramento: un insieme di metodi che consente di controllare l'esposizione dei dati per scenari diversi.
Funzione di mascheramento
Logica di mascheramento
Predefinita
Mascheramento completo in base ai tipi di dati dei campi designati
* Usare XXXX (o meno) se le dimensioni del campo sono inferiori a 4 caratteri per i dati di tipo stringa (nchar, ntext, nvarchar). * Usare un valore uguale a zero per i tipi di dati numerici (bigint, bit, decimal, int, money, numeric, smallint, smallmoney, tinyint, float, real). * Usare 1900-01-01 per i tipi di dati di data/ora (date, datetime2, datetime, datetimeoffset, smalldatetime, time). * Per sql_variant, viene usato il valore predefinito del tipo corrente. * Per XML viene usato il documento <masked />. * Usare un valore vuoto per tipi di dati speciali (timestamp, table, HierarchyID, uniqueidentifier, binary, image, varbinary e tipi spaziali).
Carta di credito
Metodo di mascheramento che espone le ultime quattro cifre dei campi designati e aggiunge una stringa costante come prefisso sotto forma di carta di credito.
XXXX-XXXX-XXXX-1234
E-mail
Metodo di mascheramento che rende visibile la prima lettera e sostituisce il dominio con XXX.com usando un prefisso stringa costante sotto forma di indirizzo di posta elettronica.
aXX@XXXX.com
Numero casuale
Metodo di mascheramento che genera un numero casuale secondo i limiti selezionati e i tipi di dati effettivi. Se i limiti designati sono uguali, la funzione maschera è un numero costante.
Testo personalizzato
Metodo di mascheramento che rende visibile il primo e l'ultimo carattere e aggiunge una stringa di riempimento personalizzata al centro. Se la stringa originale è più corta del prefisso e del suffisso visibili, viene usata solo la stringa di riempimento.
prefix[padding]suffix
Campi consigliati a cui applicare la maschera
Il motore di raccomandazioni DDM evidenzia determinati campi del database come potenzialmente sensibili e quindi come ottimi candidati per l'applicazione della maschera. Nel riquadro Dynamic Data Masking nel portale sono visibili le colonne consigliate per il proprio database. Selezionare Aggiungi maschera per una o più colonne, quindi selezionare la funzione di maschera appropriata e selezionare Salva per applicare la maschera per questi campi.
Configurare la maschera dati dinamica per il database usando l'API REST
È possibile usare l'API REST per gestire a livello programmatico i criteri e le regole di maschera dati. L'API REST pubblicata supporta le operazioni seguenti:
Criteri di maschera dati
Crea o aggiorna: consente di creare o aggiornare un criterio di maschera dati del database.
Ottieni: consente di ottenere un criterio di maschera dati del database.
Regole di maschera dati
Crea o aggiorna: consente di creare o aggiornare una regola di maschera dati del database.
Elenco per database: consente di ottenere un elenco di regole di maschera dati del database.
Autorizzazioni
Questi sono i ruoli predefiniti per configurare la maschera dati dinamica:
Per altre informazioni sulle autorizzazioni quando si usa la maschera dati dinamica con il comando T-SQL, vedere Autorizzazioni.
Esempio di autorizzazione granulare
Impedire l'accesso non autorizzato ai dati sensibili e ottenere il controllo mascherandolo a un utente non autorizzato a livelli diversi del database. È possibile concedere o revocare le autorizzazioni UNMASK a livello di database, a livello di schema, a livello di tabella o a livello di colonna a qualsiasi utente o ruolo del database. In combinazione con l'autenticazione a Microsoft Entra, le autorizzazioni UNMASK possono essere gestite per utenti, gruppi e applicazioni mantenute all'interno dell'ambiente Azure. L'autorizzazione UNMASK offre un modo granulare per controllare e limitare l'accesso non autorizzato ai dati archiviati nel database e migliorare la gestione della sicurezza dei dati.
Creare uno schema per contenere le tabelle utente:
CREATEUSER ServiceAttendant WITHOUT LOGIN;
GO
CREATEUSER ServiceLead WITHOUT LOGIN;
GO
CREATEUSER ServiceManager WITHOUT LOGIN;
GO
CREATEUSER ServiceHead WITHOUT LOGIN;
GO
Concedere autorizzazioni di lettura agli utenti nel database:
Concedere autorizzazioni UNMASK diverse agli utenti:
SQL
--Grant column level UNMASK permission to ServiceAttendantGRANT UNMASK ON Data.Membership(FirstName) TO ServiceAttendant;
-- Grant table level UNMASK permission to ServiceLeadGRANT UNMASK ON Data.Membership TO ServiceLead;
-- Grant schema level UNMASK permission to ServiceManagerGRANT UNMASK ONSCHEMA::DataTO ServiceManager;
GRANT UNMASK ONSCHEMA::Service TO ServiceManager;
--Grant database level UNMASK permission to ServiceHead;GRANT UNMASK TO ServiceHead;
Eseguire query sui dati nel contesto dell'utente ServiceLead ServiceAttendant:
SQL
EXECUTEASUSER = 'ServiceAttendant';
SELECT MemberID, FirstName, LastName, Phone, Email, BirthDay
FROM Data.Membership;
SELECT MemberID, Feedback, Rating
FROM Service.Feedback;
REVERT;
Eseguire query sui dati nel contesto dell'utente ServiceLead ServiceLead:
SQL
EXECUTEASUSER = 'ServiceLead';
SELECT MemberID, FirstName, LastName, Phone, Email, BirthDay
FROM Data.Membership;
SELECT MemberID, Feedback, Rating
FROM Service.Feedback;
REVERT;
Eseguire query sui dati nel contesto dell'utente ServiceLead ServiceManager:
SQL
EXECUTEASUSER = 'ServiceManager';
SELECT MemberID, FirstName, LastName, Phone, Email, BirthDay
FROM Data.Membership;
SELECT MemberID, Feedback, Rating
FROM Service.Feedback;
REVERT;
Eseguire query sui dati nel contesto dell'utente ServiceHead
SQL
EXECUTEASUSER = 'ServiceHead';
SELECT MemberID, FirstName, LastName, Phone, Email, BirthDay
FROM Data.Membership;
SELECT MemberID, Feedback, Rating
FROM Service.Feedback;
REVERT;
Per revocare autorizzazioni UNMASK, usare le istruzioni T-SQL seguenti:
SQL
REVOKE UNMASK ON Data.Membership(FirstName) FROM ServiceAttendant;
REVOKE UNMASK ON Data.Membership FROM ServiceLead;
REVOKE UNMASK ONSCHEMA::DataFROM ServiceManager;
REVOKE UNMASK ONSCHEMA::Service FROM ServiceManager;
REVOKE UNMASK FROM ServiceHead;
Amministrare un'infrastruttura di database SQL Server per database relazionali, ibridi, locali e cloud con le offerte di database relazionali Microsoft PaaS.
La sicurezza a livello di colonna consente ai clienti di controllare l'accesso alle colonne della tabella di database in base al contesto di esecuzione o all'appartenenza ai gruppi dell'utente, semplificando la progettazione e la codifica della sicurezza nell'applicazione e consentendo di implementare restrizioni per l'accesso alle colonne.
In questo episodio di Data Exposed con David Trigano e David Brookler, scopri come sfruttare le nuove funzionalità in Dynamic Data Masking, aiutare l'organizzazione a impedire l'accesso non autorizzato ai dati sensibili e ottenere il controllo mascherandolo a un utente senza privilegi a diversi livelli del database. [01:45] Informazioni sulla maschera dati dinamica[02:14] Demo con il portale di Azure[04:01] Demo con SQL Server Management Studio (SSMS) Risorse:Maschera dati dinamica &nbs
Usare il portale di Azure per sospendere l'esecuzione delle risorse di calcolo per un pool SQL dedicato per risparmiare sui costi. Riprendere il calcolo quando si è pronti a usare il data warehouse.
Dimensionare le risorse di calcolo in un pool SQL dedicato (in precedenza SQL Data Warehouse) tramite T-SQL e SQL Server Management Studio (SSMS), aumentandone il numero per ottenere prestazioni migliori o riducendolo per diminuire i costi.