I gruppi di disponibilità sono fantastici per le soluzioni High Availability/Disaster Recovery e sono sicuro che gli altri DBA saranno d'accordo con me. Tuttavia, ci saranno momenti in cui dovremo considerare attentamente alcune precauzioni e passaggi aggiuntivi per evitare sorprese indesiderate. Ad esempio, qualsiasi replica secondaria diventa l'attuale replica primaria per qualsiasi motivo e il nostro obiettivo è impedire che accada.
Esistono due opzioni di crittografia fornite da SQL:sql tde vs sempre crittografato. In questo articolo, mostrerò uno scenario che richiede al DBA di prestare maggiore attenzione ai dettagli. Proprio come dice il titolo, ti guiderà attraverso il modo corretto per gestire la crittografia dei dati all'interno dei database che fanno parte della configurazione del gruppo di disponibilità AlwaysOn.
Considerazioni iniziali
Userò Transparent Data Encryption (TDE) come tecnologia su cui basare il mio caso. Si applica a tutte le versioni supportate di SQL Server. È importante ricordare che questa funzionalità è disponibile solo nelle seguenti edizioni di SQL Server:
- SQL Server 2019 Evaluation, Standard, Developer, Enterprise
- SQL Server 2017 Evaluation, Developer, Enterprise
- Valutazione, sviluppatore, azienda di SQL Server 2016
- Valutazione, sviluppatore, azienda di SQL Server 2014
- Valutazione, sviluppatore, impresa di SQL Server 2012
- Datacenter di SQL Server 2008R2, valutazione, sviluppatore, impresa
- Valutazione di SQL Server 2008, Sviluppatore, Impresa
Vediamo come possiamo utilizzare TDE (Transparent Data Encryption) in SQL Server Standard Edition. Prima di tutto, dobbiamo creare una DMK (Database Master Key) per crittografare i dati. Quindi, creiamo un certificato e una chiave per poter decrittare i dati durante l'accesso. Non dimenticare di eseguire il backup del certificato e, infine, abilitare la crittografia.
Nota: La funzionalità TDE non è supportata in SQL Server Express Edition.
Questo post non tratterà i passaggi per creare un gruppo di disponibilità e mi affido a quello già creato a scopo di test. Puoi leggere ulteriori informazioni su come distribuire i gruppi di disponibilità AlwaysOn di SQL Server in Linux.
L'ambiente è basato su Windows, ma i principi saranno molto simili se si utilizzano piattaforme diverse (ad es. SQL Server su Linux o Istanze gestite SQL di Azure).
Che cos'è la crittografia temporanea dei dati
Il motivo principale per cui utilizziamo TDE è la sicurezza dei dati e dei file di registro per il tuo database SQL. Per evitare che i tuoi dati personali vengano rubati, è una buona idea difenderli, inoltre questo processo di crittografia è molto semplice. Prima che la pagina venga scritta sul disco, i file vengono crittografati a livello di pagina. Ogni volta che vuoi accedere ai tuoi dati, questi vengono decifrati. Dopo l'implementazione di TDE, avrai bisogno di un certificato specifico e di una chiave per ripristinare o allegare il database. Ecco cos'è un algoritmo di crittografia.
Microsoft Esempio del gruppo di disponibilità di SQL Server
Il mio gruppo di disponibilità di test è costituito da 2 repliche, ciascuna nella propria VM. Ecco le proprietà di base:
Come puoi vedere, non c'è niente di speciale, solo un paio di repliche che utilizzano la modalità di commit sincrono e la modalità di failover manuale.
Lo screenshot seguente mostra un database chiamato "test". Viene aggiunto al gruppo di disponibilità AlwaysOn di SQL Server ed è nello stato sincronizzato.
Come abilitare TDE in SQL Server
Di seguito sono riportati i passaggi per abilitare SQL Server TDE per il database di "test". Nota :eseguiremo i seguenti passaggi nella replica primaria corrente.
Passaggio 1
Crea una chiave maestra nel database principale.
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';
Passaggio 2
Crea un certificato protetto dalla chiave master.
CREATE CERTIFICATE TestCertificate WITH SUBJECT = 'My test Certificate';Passaggio 3
Crea la chiave di crittografia del database (DEK) e proteggila con il certificato creato nel passaggio 2.
USE test;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE TestCertificate;
Passaggio 4
Imposta il database "test" per utilizzare la crittografia.
ALTER DATABASE test
SET ENCRYPTION ON;
Come verificare se TDE è abilitato?
Al termine, devi confermare che Transparent Data Encryption in SQL Server è abilitato per il database di "test".
Nelle Proprietà database sezione, vai a Opzioni pagina. Lì, presta attenzione allo Stato area nella parte inferiore della finestra. La Crittografia abilitata il valore deve essere True .
Puoi anche eseguire il seguente codice TSQL per confermarlo:
SELECT name,is_encrypted
FROM sys.databases
WHERE name = 'test'
Problema di gestione e certificazione delle chiavi
Nota: Non sorprenderti se scopri che anche tempdb è crittografato. È perché tempdb è il luogo in cui si svolgono tutti i tipi di operazioni (ad esempio ordinamento, hash join, ecc.), Utilizzando i dati di tutti i database. Pertanto, se almeno un database utente è crittografato, le operazioni da quel particolare database potrebbero entrare in tempdb che dovrà restituire quei dati al database utente. Pertanto, l'invio di dati non crittografati rappresenterebbe il problema.
Puoi leggere ulteriori informazioni sulla crittografia del backup in SQL Server per migliorare la sicurezza del tuo database.
Puoi utilizzare il seguente codice TSQL per confermare che sia presente una chiave master del database per il database "test" crittografato dal certificato (come eseguito nel passaggio 3):
SELECT
DB_NAME(database_id) AS DB,
create_date,
key_algorithm,
key_length,
encryptor_thumbprint,
encryptor_type
FROM sys.dm_database_encryption_keys
WHERE DB_NAME(database_id) = 'test'
Fin qui tutto bene, almeno per la replica primaria. Ma cosa succede se interroghiamo sys.databases vista di sistema per confermare lo stato di crittografia del database "test" nella replica secondaria?
Il gruppo di disponibilità replica tutto ciò che riguarda il database da una replica all'altra. Tuttavia, la replica secondaria afferma chiaramente che non è crittografata.
Controlliamo la nostra replica secondaria per eventuali indizi al riguardo:
Lo stato del database è "Non sincronizzato/Sospetto" – non sta affatto bene. Tuttavia, dopo aver esaminato il registro degli errori della replica secondaria, posso vedere quanto segue:
2021-04-10 00:40:55.940 spid39s Error: 33111, Severity: 16, State: 3.
2021-04-10 00:40:55.940 spid39s Cannot find server certificate with thumbprint '0xDF36E3D052086AA05BBB1C64A72A2CAB5A98F240'.
2021-04-10 00:40:55.950 spid39s Error: 33111, Severity: 16, State: 3.
2021-04-10 00:40:55.950 spid39s Cannot find server certificate with thumbprint '0xDF36E3D052086AA05BBB1C64A72A2CAB5A98F240'.
2021-04-10 00:40:55.950 spid39s Always On Availability Groups data movement for database 'test' has been suspended for the following reason: "system" (Source ID 2; Source string: 'SUSPEND_FROM_REDO'). To resume data movement on the database, you will need to resume the database manually. For information about how to resume an availability database, see SQL Server Books Online.
2021-04-10 00:40:55.950 spid39s Error: 3313, Severity: 21, State: 2.
2021-04-10 00:40:55.950 spid39s During redoing of a logged operation in database 'test', an error occurred at log record ID (34:743:1). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.
Il problema principale è che il certificato utilizzato per crittografare la chiave di crittografia del database del database "test" (Fase 3) non è presente nella replica secondaria.
Perché?
Perché i gruppi di disponibilità non replicano i dati dai database di sistema. Il certificato del server mancante risiede nel database principale della replica primaria.
Come controllare e configurare il certificato TDE in SQL Server
Generiamo un backup del certificato del server nel database master della replica primaria. Quindi ripristiniamolo nel database master della Replica Secondaria.
Utilizzare il seguente codice TSQL per generare il backup dalla replica primaria corrente che ha il database "test" con TDE abilitato:
USE master;
GO
BACKUP CERTIFICATE TestCertificate
TO FILE = 'C:\temp\TestCertificate.cer'
WITH PRIVATE KEY (file='C:\temp\TestCertificate.pvk',
ENCRYPTION BY PASSWORD='<YourStrongPasswordHere>');
Prima di tentare di ripristinare il certificato nella replica secondaria, verificare se la chiave master del database esiste all'interno del database master. In caso contrario, crealo esattamente come nel passaggio 1.
Utilizzare il codice TSQL seguente per ripristinare il certificato nella replica secondaria. Nota :assicurati di copiare prima i file .cer e .pvk nella directory di destinazione.
USE master;
GO
CREATE CERTIFICATE TestCertificate
FROM FILE = 'C:\temp\TestCertificate.cer'
WITH PRIVATE KEY (
FILE = N'C:\temp\TestCertificate.pvk',
DECRYPTION BY PASSWORD = '<YourStrongPasswordHere>'
);
Pertanto, anche dopo aver ripristinato il certificato nella Replica Secondaria, lo stato del database “test” rimane lo stesso:
Poiché lo spostamento dei dati per il database "test" è sospeso, riprendiamolo manualmente per vedere se questa volta siamo fortunati:
Sì! L'operazione ha avuto successo. Il database "test" non è solo completamente sincronizzato e integro, ma anche crittografato con TDE.
Inoltre, dopo l'esecuzione del failover manuale per scambiare i ruoli delle repliche, tutto continua a funzionare perfettamente.
Conclusione
La soluzione mostrata ha funzionato perfettamente. Tuttavia, potrebbe non essere l'ideale in tutti i casi, soprattutto se sei un DBA a cui piace pianificare e fare le cose nel modo "corretto". Vedo "corretto" come segue:
- Rimuovi il database dal gruppo di disponibilità
- Esegui tutti i passaggi per abilitare Transparent Data Encryption nella replica in cui viene letto/scritto il database.
- Esegui il backup del certificato del server dalla replica primaria.
- Copia il file di backup nelle posizioni delle repliche secondarie.
- Ripristina il certificato nel database principale.
- Aggiungi nuovamente il database al gruppo di disponibilità.
- Assicurati che lo stato operativo del database sia quello corretto e previsto (a seconda della tua configurazione particolare).
Sto lanciando virgolette per "corretto" perché nel modo in cui ho presentato la soluzione ho ottenuto il database nella replica secondaria contrassegnato come sospetto. Questo da solo probabilmente solleverebbe molte segnalazioni/avvisi/indicazioni con il dito indesiderati. È un rumore non necessario che puoi facilmente evitare tenendo conto di tutte le considerazioni per pianificare e implementare correttamente TDE in una configurazione del gruppo di disponibilità Always On.
Per concludere questo post, ti lascio con la gerarchia di crittografia ufficiale utilizzata per TDE, che Microsoft ha pubblicato sul proprio sito Web. Quello che vorrei che tu tenessi a mente è dove viene creato ogni elemento (nel database principale o utente), in modo da poter superare eventuali problemi/sorprese potenziali con i gruppi di disponibilità.
Nel caso non lo sapessi, SQL Complete può aiutarti notevolmente a configurare Always Encrypted, un'altra tecnologia utile per proteggere i dati sensibili.
Tieni presente che dovresti considerare lo stesso argomento discusso in questo articolo se hai intenzione di gestire Always Encrypted in uno scenario di gruppo di disponibilità Always On. Tuttavia, le funzionalità introdotte da SQL Complete v6.7 sono progettate per garantire il successo immediato.
