Proteggere i dati con la crittografia

Completato

La crittografia dei dati costituisce la base della sicurezza del database. Anche se gli utenti malintenzionati ottengono l'accesso all'archiviazione sottostante, la crittografia mantiene le informazioni riservate illeggibili. Le piattaforme SQL di Microsoft offrono più opzioni di crittografia, dalla protezione dei dati inattivi alla protezione dei dati durante l'elaborazione.

Comprendere quando usare ogni metodo consente di bilanciare la protezione con le prestazioni. Verranno ora esaminate le tecnologie di crittografia disponibili nei database SQL Server, SQL di Azure e SQL in Microsoft Fabric.

Informazioni sui livelli di crittografia

La crittografia del database opera a livelli diversi, risolvendo ogni problema specifico. Transparent Data Encryption (TDE) crittografa i dati inattivi—immagina che protegga i tuoi file di database su disco. La crittografia a livello di colonna è destinata a colonne sensibili specifiche, mentre Always Encrypted continua a proteggere i dati durante il ciclo di vita, anche durante l'elaborazione delle query.

Quando si abilita TDE, SQL Server crittografa automaticamente i file di database, i log delle transazioni e i backup. Le applicazioni non necessitano di modifiche al codice. La crittografia avviene in modo trasparente in background. TDE usa una chiave di crittografia del database protetta da un certificato archiviato nel master database.

La crittografia a livello di colonna funziona in modo diverso. È possibile crittografare e decrittografare in modo esplicito i dati nel codice o nell'applicazione T-SQL, offrendo un controllo granulare sulle colonne che contengono dati sensibili e su chi può decrittografarli.

Always Encrypted adotta un altro approccio mantenendo completamente le chiavi di crittografia al di fuori del motore di database. Il database non vede mai i dati in testo non crittografato, il che significa che anche gli amministratori di database con accesso di alto livello non possono visualizzare le informazioni protette.

Configurare Always Encrypted

Always Encrypted garantisce che il motore di database non elabori mai valori di testo non crittografato. Le applicazioni client contengono le chiavi di crittografia e gestiscono tutta la crittografia e la decrittografia. Questa separazione significa che anche un utente con accesso amministrativo al database non può visualizzare i dati protetti.

Per iniziare a usare Always Encrypted, occorre prima creare una chiave master della colonna che protegge le chiavi di crittografia della colonna. Archiviare il CMK in un sistema di gestione delle chiavi sicuro, come Azure Key Vault, l’archivio certificati di Windows o un modulo di sicurezza hardware.

L'istruzione T-SQL seguente crea una voce di metadati che punta alla tua chiave in Azure Key Vault. Il materiale effettivo della chiave rimane nell'insieme di credenziali delle chiavi, mai archiviato nel database.

CREATE COLUMN MASTER KEY MyCMK
WITH (
    KEY_STORE_PROVIDER_NAME = 'AZURE_KEY_VAULT',
    KEY_PATH = 'https://mykeyvault.vault.azure.net/keys/MyCMK/abc123'
);

Quindi, crea una chiave di crittografia di colonna (CEK) protetta dalla chiave master di colonna.

CREATE COLUMN ENCRYPTION KEY MyCEK
WITH VALUES (
    COLUMN_MASTER_KEY = MyCMK,
    ALGORITHM = 'RSA_OAEP',
    ENCRYPTED_VALUE = 0x01700000016C006F00...
);

Si noti che la chiave cek stessa viene archiviata in formato crittografato. Quando l'applicazione deve lavorare con i dati crittografati, recupera questo valore e usa la chiave cmk per decrittografarla localmente.

Quando si creano o modificano tabelle, si specifica il tipo di crittografia per le colonne sensibili:

CREATE TABLE Employees (
    EmployeeID int PRIMARY KEY,
    SSN char(11) COLLATE Latin1_General_BIN2
        ENCRYPTED WITH (
            ENCRYPTION_TYPE = DETERMINISTIC,
            ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256',
            COLUMN_ENCRYPTION_KEY = MyCEK
        ),
    Salary money
        ENCRYPTED WITH (
            ENCRYPTION_TYPE = RANDOMIZED,
            ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256',
            COLUMN_ENCRYPTION_KEY = MyCEK
        )
);

Sono disponibili due tipi di crittografia tra cui scegliere. Usa deterministico quando è necessario eseguire confronti di uguaglianza, join o filtri con clausole WHERE: lo stesso testo in chiaro produce sempre lo stesso testo cifrato. Usare randomizzato per una maggiore sicurezza quando non sono necessarie quelle operazioni di query.

Implementare la crittografia a livello di colonna

La crittografia a livello di colonna che usa funzioni T-SQL offre un'alternativa quando è necessario un maggiore controllo sul processo di crittografia o quando Always Encrypted non è la scelta appropriata. Con questo approccio si gestiscono chiavi simmetriche o asimmetriche archiviate all'interno del database.

Per iniziare, creare una chiave master e un certificato del database:

CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'StrongPassword123!';

CREATE CERTIFICATE SensitiveDataCert
WITH SUBJECT = 'Certificate for sensitive data encryption';

Creare una chiave simmetrica protetta dal certificato:

CREATE SYMMETRIC KEY SensitiveDataKey
WITH ALGORITHM = AES_256
ENCRYPTION BY CERTIFICATE SensitiveDataCert;

Per crittografare i dati, aprire la chiave simmetrica e usare la ENCRYPTBYKEY funzione :

OPEN SYMMETRIC KEY SensitiveDataKey
DECRYPTION BY CERTIFICATE SensitiveDataCert;

INSERT INTO CustomerData (CustomerID, CreditCardNumber)
VALUES (1, ENCRYPTBYKEY(KEY_GUID('SensitiveDataKey'), '4111-1111-1111-1111'));

CLOSE SYMMETRIC KEY SensitiveDataKey;

La decrittografia segue un modello simile usando DECRYPTBYKEY:

OPEN SYMMETRIC KEY SensitiveDataKey
DECRYPTION BY CERTIFICATE SensitiveDataCert;

SELECT CustomerID, 
       CONVERT(varchar(20), DECRYPTBYKEY(CreditCardNumber)) AS CardNumber
FROM CustomerData;

CLOSE SYMMETRIC KEY SensitiveDataKey;

Sì, questo approccio richiede più lavoro, ovvero si gestiscono le chiavi in modo esplicito nel codice. Ma questa complessità è dotata di flessibilità. È possibile concedere o negare le autorizzazioni alla chiave simmetrica, offrendo un controllo preciso su chi può decrittografare i dati.

Scegliere l'approccio di crittografia corretto

Quale metodo di crittografia è necessario usare? Dipende dai requisiti di sicurezza e dai vincoli dell'applicazione.

TDE è la scelta migliore quando è necessario proteggere i dati inattivi senza toccare il codice dell'applicazione. È ideale per i requisiti di conformità che impongono la crittografia dei file di database e dei backup. Tenere presente, tuttavia, che TDE non protegge i dati dagli utenti che possono connettersi al database con le autorizzazioni appropriate.

Always Encrypted brilla quando è necessario proteggere i dati dagli amministratori di database o quando i dati sensibili devono rimanere crittografati anche durante l'elaborazione delle query. Il compromesso? È necessario il supporto dei driver client e si è limitati alle operazioni che è possibile eseguire sulle colonne crittografate.

La crittografia a livello di colonna funziona correttamente quando è necessario un controllo granulare sulla crittografia e la decrittografia o quando si desidera crittografare colonne specifiche senza l'overhead dell'infrastruttura di Always Encrypted. Richiede più lavoro di sviluppo, ma si ottiene la massima flessibilità nella gestione delle chiavi.

Suggerimento

È possibile combinare i metodi di crittografia. Ad esempio, abilitare TDE per la protezione di base dei dati inattivi, quindi aggiungere Always Encrypted per le colonne più sensibili.

Per i database SQL in Microsoft Fabric, TDE è abilitato per impostazione predefinita e gestito automaticamente. Concentrarsi sulle decisioni di progettazione della crittografia sulla protezione a livello di colonna usando Always Encrypted o la crittografia con chiave simmetrica in base ai requisiti dell'applicazione.