Database
 sql >> Database >  >> RDS >> Database

Crittografia dei dati trasparente e sempre crittografata

Se devi archiviare dati riservati nel tuo database, puoi utilizzare la crittografia dei dati . SQL Server supporta la crittografia con chiavi simmetriche, chiavi asimmetriche, certificati e frasi password. Presumo che tu, lettore, abbia già familiarità con questi termini. In questo articolo, mi concentrerò su due delle molte opzioni di crittografia fornite da SQL Server:

  • Crittografia dei dati trasparenti (TDE)
  • Sempre crittografato (AE)

Crittografia dati trasparenti

La Crittografia dei dati trasparenti (TDE) protegge i dati inattivi quando non vengono utilizzati. Quando i dati vengono utilizzati, SQL Server li decrittografa automaticamente. È possibile utilizzare il TDE per la crittografia e la decrittografia in tempo reale dei dati e dei file di registro. Crittografa i dati con la chiave di crittografia del database (DEK) , che è una chiave simmetrica. Viene memorizzato nel record di avvio del database ed è quindi disponibile già durante il processo di ripristino del database. Proteggi il DEK con un certificato nel database principale. Puoi anche utilizzare una chiave asimmetrica al posto del certificato; tuttavia, la chiave asimmetrica deve essere memorizzata in un modulo EKM. TDE utilizza solo le crittografie AES e Triple DES. TDE è stato implementato per la prima volta in SQL Server con la versione 2012.

È possibile utilizzare TDE solo sui database degli utenti. Non è possibile esportare la chiave di crittografia del database. Questa chiave viene utilizzata solo da Motore di database di SQL ServerSQL Server Database Engine. Gli utenti finali non lo usano mai. Anche se cambi il proprietario del database, non è necessario rigenerare il DEK.

TDE crittografa i dati a livello di pagina. Inoltre, crittografa anche il registro delle transazioni. È necessario eseguire il backup del certificato utilizzato per proteggere la DEK e la chiave privata utilizzata per proteggere il certificato subito dopo aver abilitato TDE. Se è necessario ripristinare o collegare il database crittografato a un'altra istanza di SQL Server, è necessario ripristinare sia il certificato che la chiave privata, altrimenti non è possibile aprire il database. Nota ancora che non esporti il ​​DEK, poiché fa parte del database stesso. È necessario conservare e mantenere il certificato utilizzato per proteggere il DEK anche dopo aver disabilitato il TDE sul database. Ciò è dovuto al fatto che parti del registro delle transazioni potrebbero essere ancora crittografate. Il certificato è necessario fino a quando non esegui il backup completo del database.

Sempre crittografato

SQL Server 2016 Enterprise Edition introduce un nuovo livello di crittografia, ovvero Always Encrypted (AE) caratteristica. Questa funzione consente lo stesso livello di protezione dei dati della crittografia dei dati nell'applicazione client. In realtà, sebbene si tratti di una funzionalità di SQL Server, i dati vengono crittografati e decrittografati sul lato client. Le chiavi di crittografia non vengono mai rivelate al Motore di database di SQL ServerSQL Server Database Engine. In questo modo, anche un DBA non può vedere i dati sensibili senza le chiavi di crittografia, semplicemente disponendo delle autorizzazioni di amministratore di sistema sull'istanza di SQL Server con i dati crittografati. In questo modo, AE separa gli amministratori che gestiscono i dati e gli utenti che possiedono i dati.

Chiavi AE

Sono necessarie due chiavi per Always Encrypted. Innanzitutto, crei la chiave principale della colonna (CMK) . Quindi crei la chiave di crittografia della colonna (CEK) e proteggilo con il CMK. Un'applicazione utilizza il CEK per crittografare i dati. SQL Server archivia solo dati crittografati e non può decrittografarli. Ciò è possibile perché le chiavi master della colonna non sono realmente archiviate in un database di SQL Server. Nel database, SQL Server archivia solo il collegamento a tali chiavi. Le chiavi master della colonna sono archiviate all'esterno di SQL Server, in una delle seguenti posizioni possibili:

  • Archivio certificati di Windows per l'utente corrente
  • Archivio certificati di Windows per il computer locale
  • Servizio Azure Key Vault
  • Un modulo di sicurezza hardware (HSM) , che supporta Microsoft CryptoAPI o Cryptography API:Next Generation

Le chiavi di crittografia della colonna sono archiviate nel database. All'interno di un database di SQL Server, viene archiviata solo la parte crittografata dei valori delle chiavi di crittografia delle colonne, insieme alle informazioni sulla posizione delle chiavi master delle colonne. I CEK non vengono mai archiviati come testo normale in un database. Le CMK sono, come accennato, effettivamente archiviate in archivi di chiavi attendibili esterni.

Utilizzo dei tasti AE

Un'applicazione può utilizzare le chiavi AE e la crittografia utilizzando un driver abilitato AE, come .NET Framework Data Provider per SQL Server versione 4.6 o successiva, Microsoft JDBC Driver per SQL Server 6.0 o versione successiva o Windows ODBC driver per SQL Server versione 13.1 o successiva più alto. L'applicazione deve inviare query parametrizzate a SQL Server. Il driver abilitato per AE interagisce con il Motore di database di SQL Server per determinare quali parametri devono essere crittografati o decrittografati. Per ogni parametro che deve essere crittografato o decrittografato, il driver ottiene i metadati necessari per la crittografia dal Motore di database, inclusi l'algoritmo di crittografia, la posizione della CMK corrispondente e il valore crittografato per la CEK corrispondente. Quindi il driver contatta l'archivio CMK, recupera il CMK, decrittografa il CEK e utilizza il CEK per crittografare o decrittografare il parametro. Quindi il driver memorizza nella cache il CEK, per accelerare il successivo utilizzo dello stesso CEK. La figura seguente mostra il processo graficamente.

La figura rappresenta l'intero processo in fasi:

  1. L'applicazione client crea una query parametrizzata
  2. L'applicazione client invia la query parametrizzata al driver abilitato AE
  3. Il driver abilitato per AE contatta SQL Server per determinare quali parametri necessitano di crittografia o decrittografia, la posizione della CMK e il valore crittografato della CEK
  4. Il driver abilitato AE recupera la CMK e decritta la CEK
  5. Il driver abilitato AE crittografa i parametri
  6. Il driver invia la query al Motore di database
  7. Il Motore di database recupera i dati e invia il set di risultati al driver
  8. Il driver esegue la decrittazione, se necessario, e invia il set di risultati all'applicazione client

Tipi di crittografia AE

Il Motore di database non opera mai sui dati di testo normale archiviati nelle colonne crittografate. Tuttavia, sono possibili alcune query sui dati crittografati, a seconda del tipo di crittografia. Esistono due tipi di crittografia:

  • Crittografia deterministica , che genera sempre lo stesso valore crittografato per lo stesso valore di input. Con questa crittografia, puoi indicizzare la colonna crittografata e utilizzare ricerche di punti, join di uguaglianza ed espressioni di raggruppamento nella colonna crittografata. Tuttavia, un utente malintenzionato potrebbe tentare di indovinare i valori analizzando i modelli dei valori crittografati. Ciò è particolarmente pericoloso quando l'insieme dei possibili valori per una colonna è discreto, con un numero ridotto di valori distinti.
  • Crittografia randomizzata , che crittografa i dati in modo imprevedibile.

AE Demo:creazione degli oggetti

È ora di mostrare come funziona AE attraverso un codice demo. Per prima cosa, creiamo e utilizziamo un database demo.

USE master;
IF DB_ID(N'AEDemo') IS NULL
   CREATE DATABASE AEDemo;
GO
USE AEDemo;
GO

Quindi, crea la CMK nella GUI di SSMS. In Esplora oggetti, aggiornare la cartella Database per visualizzare il database AEDemo. Espandi questa cartella del database, espandi la sottocartella Sicurezza, quindi la sottocartella Chiavi sempre crittografate e fai clic con il pulsante destro del mouse sulla sottocartella Chiave master della colonna e seleziona l'opzione Nuova chiave master della colonna dal menu a comparsa. Nella casella di testo Nome, scrivi AE_ColumnMasterKey e assicurati di selezionare l'opzione Windows Certificate Store – Local Machine nell'elenco a discesa Key Store, come mostra la figura seguente.

Puoi verificare se la CMK è stata creata correttamente con la seguente query.

SELECT * 
FROM sys.column_master_keys;

Successivamente, crei il CEK. In SSMS, in Esplora oggetti, fare clic con il pulsante destro del mouse sulla sottocartella Chiavi di crittografia della colonna proprio sotto la sottocartella Chiave principale della colonna e selezionare l'opzione Nuova chiave di crittografia della colonna dal menu a comparsa. Assegna un nome a CEK AE_ColumnEncryptionKey e utilizza AE_ColumnMasterKey CMK per crittografarlo. Puoi verificare se la creazione della CEK è andata a buon fine con la seguente query.

SELECT * 
FROM sys.column_encryption_keys;

Attualmente, solo le nuove regole di confronto binarie, le regole di confronto con BIN2 suffisso, sono supportati per AE. Pertanto, creiamo una tabella con regole di confronto appropriate per le colonne dei caratteri.

CREATE TABLE dbo.Table1
(id INT,
 SecretDeterministic NVARCHAR(10) COLLATE Latin1_General_BIN2 
  ENCRYPTED WITH (COLUMN_ENCRYPTION_KEY = AE_ColumnEncryptionKey,
   ENCRYPTION_TYPE = DETERMINISTIC,
   ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256') NULL,
 SecretRandomized NVARCHAR(10) COLLATE Latin1_General_BIN2
  ENCRYPTED WITH (COLUMN_ENCRYPTION_KEY = AE_ColumnEncryptionKey,
   ENCRYPTION_TYPE = RANDOMIZED,
   ALGORITHM = 'AEAD_AES_256_CBC_HMAC_SHA_256') NULL
);

AE Demo:inserimento dei dati

Ora puoi provare a inserire una riga di dati con la seguente istruzione.

INSERT INTO dbo.Table1
 (id, SecretDeterministic, SecretRandomized)
VALUES (1, N'DeterSec01', N'RandomSec1');

Viene visualizzato l'errore 206, testo di errore:"Clash tipo operando:nvarchar è incompatibile con nvarchar(4000) crittografato con (tipo_crittografia ='DETERMINISTIC', nome_algoritmo_crittografia ='AEAD_AES_256_CBC_HMAC_SHA_256', nome_chiave_encryption_colonna ='AE_ColumnEncryptionKey', nome_crittografia_colonna_EDemo_colonna)" ' . SQL Server non può crittografare o decrittografare i dati. È necessario modificare i dati da un'applicazione client. È possibile eseguire un insieme limitato di operazioni sulla tabella da SQL Server. Ad esempio, puoi utilizzare l'istruzione TRUNCATE TABLE su una tabella con colonne AE.

Ho creato un'applicazione client Windows Console molto semplice in Visual C#. L'applicazione in realtà recupera solo le chiavi e inserisce una singola riga nella tabella creata con il codice sopra. Ecco il codice C#.

using System;
using System.Collections.Generic;
using System.Data;
using System.Data.SqlClient;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace AEDemo
{
    class Program
    {
        static void Main(string[] args)
        {
            string connectionString = "Data Source=localhost; “ +
              “Initial Catalog=AEDemo; Integrated Security=true; ” +
              “Column Encryption Setting=enabled";
            SqlConnection connection = new SqlConnection(connectionString);
            connection.Open();
            if (args.Length != 3)
            {
                Console.WriteLine("Please enter a numeric “ + 
                                  “and two string arguments.");
                return;
            }
            int id = Int32.Parse(args[0]);
            {
                using (SqlCommand cmd = connection.CreateCommand())
                {
                    cmd.CommandText = @"INSERT INTO dbo.Table1 “ +
                        “(id, SecretDeterministic, SecretRandomized)" +
                        " VALUES (@id, @SecretDeterministic, @SecretRandomized);";

                    SqlParameter paramid= cmd.CreateParameter();
                    paramid.ParameterName = @"@id";
                    paramid.DbType = DbType.Int32;
                    paramid.Direction = ParameterDirection.Input;
                    paramid.Value = id;
                    cmd.Parameters.Add(paramid);

                    SqlParameter paramSecretDeterministic = cmd.CreateParameter();
                    paramSecretDeterministic.ParameterName = 
                      @"@SecretDeterministic";
                    paramSecretDeterministic.DbType = DbType.String;
                    paramSecretDeterministic.Direction = ParameterDirection.Input;
                    paramSecretDeterministic.Value = "DeterSec1";
                    paramSecretDeterministic.Size = 10;
                    cmd.Parameters.Add(paramSecretDeterministic);

                    SqlParameter paramSecretRandomized = cmd.CreateParameter();
                    paramSecretRandomized.ParameterName =
                      @"@SecretRandomized";
                    paramSecretRandomized.DbType = DbType.String;
                    paramSecretRandomized.Direction = ParameterDirection.Input;
                    paramSecretRandomized.Value = "RandomSec1";
                    paramSecretRandomized.Size = 10;
                    cmd.Parameters.Add(paramSecretRandomized);

                    cmd.ExecuteNonQuery();
                }
            }
            connection.Close();
            Console.WriteLine("Row inserted successfully");            
        }
    }
}

È possibile eseguire il codice C# da Visual Studio in modalità di debug o compilare l'applicazione. Quindi puoi eseguire l'applicazione AEDemo.exe dal prompt dei comandi o da SSMS in modalità SQMCMD.

Demo AE:lettura dei dati

Dopo aver eseguito l'applicazione, dovresti provare a leggere i dati della stessa sessione in SSMS che hai utilizzato per creare la tabella.

SELECT *
FROM dbo.Table1;

Puoi vedere solo dati crittografati. Ora apri una seconda finestra di query in SSMS. Fare clic con il pulsante destro del mouse in questa finestra e scegliere Connessione, quindi Modifica connessione. Nella finestra di dialogo Connessione, fai clic sul pulsante Opzioni in basso. Digitare AEDemo per il nome del database, quindi fare clic sulla scheda Parametri di connessione aggiuntivi. Nella casella di testo, inserisci "Column Encryption Setting=enabled" (senza virgolette). Quindi fare clic su Connetti.

Riprova a inserire una riga da SSMS. Usa la seguente query.

INSERT INTO dbo.Table1
 (id, SecretDeterministic, SecretRandomized)
VALUES (2, N'DeterSec2', N'RandomSec2');

Ho ricevuto di nuovo un errore. Questa versione SSMS che sto usando non è ancora in grado di parametrizzare gli inserti ad hoc. Tuttavia, proviamo a leggere i dati con la seguente query.

SELECT * 
FROM dbo.Table1;

Questa volta, la query funziona e ottieni il seguente risultato:

Id SecretDeterministic SecretRandomized

— ——————– —————-

1 DeterSec1 RandomSec1

2 DeterSec2 RandomSec2

Limiti AE

Hai già visto alcune limitazioni di Always Encrypted, tra cui:

  • Solo le regole di confronto BIN2 sono supportate per le stringhe
  • Puoi indicizzare solo colonne con crittografia deterministica e utilizzare un insieme limitato di operazioni T-SQL su tali colonne
  • Non puoi indicizzare colonne con crittografia randomizzata
  • AE è limitato alle sole edizioni Enterprise e Developer
  • Lavorare con AE in SSMS può essere doloroso

Fare riferimento alla documentazione in linea per un elenco più dettagliato delle limitazioni AE. Tuttavia, si prega di notare anche i punti di forza di AE. È semplice da implementare perché non necessita di modifiche in un'applicazione, tranne la modifica delle stringhe di connessione. I dati vengono crittografati end-to-end, dalla memoria del client attraverso la rete all'archiviazione del database. Anche i DBA non possono visualizzare i dati solo all'interno di SQL Server; anche i DBA devono accedere all'archiviazione delle chiavi all'esterno di SQL Server per leggere la CMK. AE e altre opzioni di crittografia in SQL Server offrono una serie completa di possibilità e spetta a te e al problema aziendale che stai risolvendo selezionare il metodo appropriato.

Conclusione

Transparent Data Encryption è estremamente semplice da usare. Tuttavia, la protezione dei dati è molto limitata. TDE protegge solo i dati inattivi. Tuttavia, Always Encrypted è davvero una funzionalità potente. Non è ancora troppo complesso da implementare e i dati sono completamente protetti. Nemmeno un DBA può vederlo senza avere accesso alle chiavi di crittografia. Si spera che le limitazioni per AE, in particolare la limitazione delle regole di confronto, vengano rimosse nelle versioni future di SQL Server.