Proteggere i dati
Ora che la rete e l'accesso alle identità sono configurati e protetti, l'argomento successivo da considerare è come proteggere i dati, se sono inattivi, in movimento o visualizzati da utenti e amministratori.
Crittografia dei dati
Le connessioni crittografate vengono forzate dal database SQL di Azure, con l'opzione di specificare anche la versione minima di TLS (Transport Layer Security) in ingresso (>1.0, >1.1, o >1.2) richiesta. È consigliabile forzare la crittografia sul client per evitare la negoziazione del server e non considerare attendibile il certificato del server come procedura consigliata.
Transparent Data Encryption
Transparent Data Encryption (TDE) fornisce la crittografia per i dati inattivi ed è attiva per impostazione predefinita per tutte le nuove istanze del database SQL di Azure. È possibile configurarla per tutte le opzioni di distribuzione con un'opzione nel portale di Azure, come illustrato di seguito:
A livello di server, è anche possibile scegliere di usare una chiave gestita dal servizio, oppure Bring Your Own Key (BYOK) usando l'opzione chiave gestita dal cliente L'impostazione predefinita è consentire al servizio di Azure di gestire la chiave. Azure genera automaticamente una chiave per crittografare i database e gestisce le rotazioni delle chiavi. Si è appreso come eseguire questa operazione con il portale di Azure, ma è anche possibile usare Azure PowerShell, l'interfaccia della riga di comando di Azure, Transact-SQL (T-SQL) o le API REST.
Chiavi gestite dal cliente con TDE
In alternativa, è possibile usare l'approccio Bring Your Own Key (BYOK) e sfruttare un insieme di credenziali delle chiavi di Azure. I vantaggi dell'uso delle chiavi gestite dal cliente sono:
- Controllo completo e granulare sull'utilizzo e sulla gestione della protezione TDE
- Trasparenza dell'utilizzo della protezione TDE
- Possibilità di implementare la separazione dei compiti nella gestione delle chiavi e dei dati all'interno dell'organizzazione
- L'amministratore dell'insieme di credenziali delle chiavi può revocare le autorizzazioni di accesso alle chiavi per rendere il database crittografato inaccessibile
- Gestione centralizzata delle chiavi in AKV
- Maggiore attendibilità dei clienti finali perché AKV è progettata in modo che Microsoft non possa visualizzare o estrarre chiavi di crittografia
È anche possibile sfruttare l'uso di un'identità gestita assegnata dall'utente (UMI)con chiavi gestite dal cliente per TDE, che:
- Consente di pre-autorizzare l'accesso all'insieme di credenziali delle chiavi per i server logici SQL di Azure creando un'identità gestita assegnata dall'utente e concedendole l'accesso all'insieme di credenziali delle chiavi, anche prima della creazione del server o del database.
- Consente la creazione di un server logico SQL di Azure con TDE e CMK abilitato.
- Consente di assegnare la stessa identità gestita assegnata dall'utente a più server, eliminando la necessità di attivare singolarmente l'identità gestita assegnata dal sistema per ogni server logico SQL di Azure e di fornire l'accesso all'insieme di credenziali delle chiavi.
- Offre la possibilità di applicare la chiave gestita dal cliente al momento della creazione del server con un criterio di Azure predefinito disponibile.
La rotazione automatica delle chiavi è stata introdotta per le chiavi gestite dal cliente usando TDE. Se abilitata, il server controlla continuamente l'insieme di credenziali delle chiavi per eventuali nuove versioni della chiave usate come protezione TDE. Se viene rilevata una nuova versione della chiave, la protezione TDE nel server viene ruotata automaticamente alla versione della chiave più recente entro 60 minuti.
Always Encrypted
È anche possibile usufruire della crittografia a livello di colonna, supportata in Azure SQL come in SQL Server. Questo processo prevede la crittografia lato client dei dati sensibili usando chiavi che non vengono mai fornite al sistema database. Inoltre, il driver client esegue in modo trasparente la crittografia dei parametri di query e decrittografa i risultati crittografati. Attualmente sono supportati i dati crittografati per il confronto di uguaglianza, inclusi gli operatori JOIN, GROUP BY e DISTINCT tramite crittografia deterministica.
Always Encrypted con enclave sicure espande le funzionalità di confidential computing di Always Encrypted abilitando la crittografia sul posto e query riservate più avanzate. La funzionalità Always Encrypted con le enclave sicure è ora disponibile per database SQL di Azure, ma non è ancora supportata per Istanza gestita di SQL di Azure.
Dynamic Data Masking
In alcuni casi, è necessario mascherare o modificare alcuni dati in modo che gli utenti senza privilegi non possano visualizzarli, ma che possano comunque eseguire query che li includono. Questa funzionalità è supportata esattamente come in SQL Server; tuttavia nel portale di Azure sono disponibili funzionalità e visualizzazioni aggiuntive che consentono di visualizzare le raccomandazioni dei campi da mascherare.
Verrà ora esaminato un esempio in cui i dati includono informazioni riservate, ad esempio nomi e indirizzi di posta elettronica. È possibile applicare una maschera a tali colonne nel portale di Azure selezionando il pannello Maschera dati dinamica nel menu Sicurezza nel riquadro di configurazione database SQL oppure usando i comandi T-SQL seguenti:
ALTER TABLE Data.Membership ALTER COLUMN FirstName
ADD MASKED WITH (FUNCTION = 'partial(1, "xxxxx", 1)')
ALTER TABLE Data.Membership ALTER COLUMN Email
ADD MASKED WITH (FUNCTION = 'email()')
ALTER TABLE Data.Membership ALTER COLUMN DiscountCode
ADD MASKED WITH (FUNCTION = 'random(1, 100)')
GRANT UNMASK to DataOfficers
Dai comandi precedenti si nota che è possibile applicare una maschera tramite funzioni in diversi modi.
Se, ad esempio, a un utente viene assegnato un ruolo come DataOfficers (solo un esempio, non un ruolo ufficiale), potrebbe essere necessario poter visualizzare i dati mascherati. È possibile concedere loro UNMASK privilegi con il comando T-SQL seguente:
GRANT UNMASK TO DataOfficers
A seconda dell'utente che esegue la query, i risultati sono i seguenti:
Con l'introduzione alle autorizzazioni granulari per la maschera dati dinamica, è possibile concedere o revocare UNMASK l'autorizzazione a livello di database, a livello di schema, a livello di tabella o a livello di colonna a un utente del database, a microsoft Entra identity, a Microsoft Entra group o a un ruolo del database.
Attività per la protezione dati
Per impostare e configurare la protezione dei dati, è necessario:
- Assicurarsi che le applicazioni impongano la crittografia delle connessioni e usino la versione TLS più elevata compatibile con l'applicazione, i client e i driver.
- Valutare e abilitare TDE. (impostazione predefinita per i nuovi database, ma se si esegue la migrazione potrebbe essere necessario abilitarla).
- Sfruttare i vantaggi di Dynamic Data Masking.
- Per la protezione avanzata, è possibile configurare la funzionalità Always Encrypted con enclave sicure.