Tillgänglighetsgrupper är fantastiska för lösningar med hög tillgänglighet/katastrofåterställning, och jag är säker på att andra DBA:er håller med mig. Det kommer dock att finnas tillfällen då vi måste överväga vissa försiktighetsåtgärder och extra steg noggrant för att undvika oönskade överraskningar. Till exempel blir vilken sekundär replik som helst den nuvarande primära repliken oavsett anledning, och vårt mål är att inte låta det hända.
Det finns två krypteringsalternativ som tillhandahålls av SQL:sql tde vs alltid krypterad. I den här artikeln kommer jag att visa upp ett scenario som kräver att DBA är extra uppmärksam på detaljer. Precis som rubriken säger, kommer den att guida dig genom det rätta sättet att hantera datakrypteringen i databaser som är en del av konfigurationen av AlwaysOn Availability Group.
Inledande överväganden
Jag kommer att använda Transparent Data Encryption (TDE) som teknik för att bygga mitt fall runt. Det gäller alla versioner av SQL Server som stöds. Det är viktigt att nämna att den här funktionen endast är tillgänglig inom följande SQL Server-versioner:
- SQL Server 2019 Evaluation, Standard, Developer, Enterprise
- SQL Server 2017 utvärdering, utvecklare, företag
- SQL Server 2016 utvärdering, utvecklare, företag
- SQL Server 2014 utvärdering, utvecklare, företag
- SQL Server 2012 utvärdering, utvecklare, företag
- SQL Server 2008R2 Datacenter, Evaluation, Developer, Enterprise
- SQL Server 2008 utvärdering, utvecklare, företag
Låt oss se hur vi kan använda TDE (Transparent Data Encryption) i SQL Server Standard Edition. Först och främst måste vi skapa en DMK (Database Master Key) för att kryptera data. Sedan skapar vi ett certifikat och en nyckel för att kunna dekryptera data medan vi kommer åt den. Glöm inte att säkerhetskopiera certifikatet och, slutligen, aktivera krypteringen.
Obs! TDE-funktionen stöds inte i SQL Server Express Edition.
Det här inlägget kommer inte att täcka stegen för att bygga en tillgänglighetsgrupp, och jag förlitar mig på den som redan har byggts för teständamål. Du kan läsa mer om hur du distribuerar SQL Server AlwaysOn-tillgänglighetsgrupper på Linux.
Miljön är Windows-baserad, men principerna kommer att vara väldigt lika om du använder olika plattformar (t.ex. SQL Server på Linux eller Azure SQL Managed Instances).
Vad är tillfällig datakryptering
Den främsta anledningen till att vi använder TDE är data- och loggfilers säkerhet för din SQL-databas. För att förhindra att dina personuppgifter blir stulna är det en bra idé att försvara dem, plus att denna krypteringsprocess är väldigt enkel. Innan sidan skrivs på disken krypteras filerna på sidnivå. Varje gång du vill komma åt din data dekrypteras den. Efter TDE-implementering behöver du ett specifikt certifikat och en nyckel för att återställa eller bifoga databasen. Det är vad en krypteringsalgoritm är.
Microsoft Exempel på SQL Server-tillgänglighetsgrupp
Min testtillgänglighetsgrupp består av 2 repliker, var och en i sin egen virtuella dator. Här är de grundläggande egenskaperna:
Som du kan se finns det inget fancy, bara ett par repliker som använder synkront commit-läge och i manuellt failover-läge.
Följande skärmdump visar en databas som heter "test". Den läggs till i SQL Server AlwaysOn Availability Group och den är i synkroniserat tillstånd.
Hur man aktiverar TDE i SQL Server
Här är stegen för att aktivera SQL Server TDE för "test"-databasen. Obs :vi kommer att utföra följande steg i den aktuella primära repliken.
Steg 1
Skapa en huvudnyckel i huvuddatabasen.
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';
Steg 2
Skapa ett certifikat som skyddas av huvudnyckeln.
CREATE CERTIFICATE TestCertificate WITH SUBJECT = 'My test Certificate';Steg 3
Skapa databaskrypteringsnyckeln (DEK) och skydda den med certifikatet som skapades i steg 2.
USE test;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE TestCertificate;
Steg 4
Ställ in "test"-databasen att använda kryptering.
ALTER DATABASE test
SET ENCRYPTION ON;
Hur kontrollerar jag om TDE är aktiverat?
När du är klar måste du bekräfta att Transparent Data Encryption i SQL Server är aktiverat för "test"-databasen.
I Databasegenskaper gå till Alternativ sida. Var uppmärksam på Staten område längst ner i fönstret. Encryption Enabled värdet måste vara True .
Du kan också köra följande TSQL-kod för att bekräfta den:
SELECT name,is_encrypted
FROM sys.databases
WHERE name = 'test'
Nyckelhantering och certifieringsproblem
Obs! Bli inte förvånad om du får reda på att tempdb också är krypterad. Det beror på att tempdb är där alla typer av operationer äger rum (t.ex. sortering, hash-kopplingar, etc.), med hjälp av data från alla databaser. Därför, om minst en användardatabas är krypterad, kan operationer från just den databasen gå in i tempdb som kommer att behöva returnera dessa data till användardatabasen. Därför skulle det vara problemet att skicka tillbaka okrypterad data.
Du kan läsa mer om säkerhetskopieringskryptering i SQL Server för att förbättra säkerheten för din databas.
Du kan använda följande TSQL-kod för att bekräfta att det finns en databashuvudnyckel för "test"-databasen som är krypterad av certifikatet (som exekveras i steg 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'
Så långt har det gått bra, åtminstone för den primära repliken. Men vad händer om vi frågar sys.databases systemvy för att bekräfta krypteringsstatusen för "test"-databasen i den sekundära repliken?
Tillgänglighetsgruppen replikerar allt relaterat till databasen från en replik till en annan. Den sekundära repliken anger dock tydligt att den inte är krypterad.
Låt oss kolla vår sekundära replika för några ledtrådar om det:
Databasens tillstånd är “Synkroniserar inte/misstänkt” – ser inte bra ut alls. Men efter att ha inspekterat felloggen för den sekundära repliken kan jag se följande:
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.
Huvudproblemet är att certifikatet som används för att kryptera databaskrypteringsnyckeln för "test"-databasen (steg 3) inte finns i den sekundära repliken.
Varför?
Eftersom tillgänglighetsgrupper inte replikerar data från systemdatabaser. Servercertifikatet som saknas finns i huvuddatabasen för primär replik.
Hur man kontrollerar och ställer in TDE-certifikat i SQL Server
Låt oss skapa en säkerhetskopia av servercertifikatet i huvuddatabasen för Primary Replica. Låt oss sedan återställa den i huvuddatabasen för den sekundära repliken.
Använd följande TSQL-kod för att skapa säkerhetskopian från den aktuella primära repliken som har "test"-databasen med TDE aktiverat:
USE master;
GO
BACKUP CERTIFICATE TestCertificate
TO FILE = 'C:\temp\TestCertificate.cer'
WITH PRIVATE KEY (file='C:\temp\TestCertificate.pvk',
ENCRYPTION BY PASSWORD='<YourStrongPasswordHere>');
Innan du försöker återställa certifikatet i den sekundära repliken, kontrollera först om databashuvudnyckeln finns i huvuddatabasen. Om inte, skapa det exakt som i steg 1.
Använd följande TSQL-kod för att återställa certifikatet i den sekundära repliken. Obs :Se till att kopiera .cer- och .pvk-filerna till målkatalogen först.
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>'
);
Även efter återställning av certifikatet i den sekundära repliken förblir tillståndet för "test"-databasen detsamma:
Eftersom datarörelsen för "test"-databasen är pausad, låt oss återuppta den manuellt för att se om vi har tur den här gången:
ja! Operationen lyckades. "Test"-databasen är inte bara helt synkroniserad och hälsosam utan också krypterad med TDE.
Dessutom, efter utförandet av den manuella failover för att byta roller för replikerna, fortsätter allt att fungera perfekt.
Slutsats
Den visade lösningen fungerade utmärkt. Men det kanske inte är idealiskt i alla fall, särskilt om du är en DBA som gillar att planera och göra saker på "rätt" sätt. Jag ser "korrekt" enligt följande:
- Ta bort databasen från tillgänglighetsgruppen
- Utför alla steg för att aktivera Transparent Data Encryption i repliken där databasen läses/skrivs.
- Säkerhetskopiera servercertifikatet från den primära repliken.
- Kopiera säkerhetskopian till platsen/platserna för de sekundära replikerna.
- Återställ certifikatet i huvuddatabasen.
- Lägg till databasen tillbaka till tillgänglighetsgruppen.
- Se till att operativa tillstånd för databasen är det korrekta och avsedda (beroende på din specifika inställning).
Jag slänger dubbla citattecken för "korrekt" eftersom jag på sättet jag presenterade lösningen fick databasen i den sekundära repliken markerad som misstänkt. Bara detta skulle förmodligen höja många oönskade flaggor/varningar/fingerpekande. Det är onödigt brus som du enkelt kan undvika genom att ta hänsyn till alla överväganden för att planera och korrekt implementera TDE i en Always On Availability Group-uppställning.
För att avsluta det här inlägget lämnar jag dig med den officiella krypteringshierarkin som används för TDE, som Microsoft har lagt ut på sin webbplats. Vad jag vill att du ska tänka på är var varje element skapas (antingen i huvud- eller användardatabasen), så att du kan övervinna eventuella problem/överraskningar med tillgänglighetsgrupper.
Om du inte är medveten om det kan SQL Complete i hög grad hjälpa dig att konfigurera Always Encrypted, vilket är en annan användbar teknik för att skydda känslig data.
Tänk på att du skulle behöva överväga detsamma som diskuteras i den här artikeln om du planerar att ta itu med Alltid krypterat i ett scenario med alltid tillgänglig grupp. Men funktioner som SQL Complete v6.7 introducerar är designade för att se till att du lyckas direkt.