Tilgængelighedsgrupper er fantastiske til High Availability/Disaster Recovery-løsninger, og jeg er sikker på, at andre DBA'er vil være enige med mig. Der vil dog være tidspunkter, hvor vi skal overveje visse forholdsregler og ekstra trin nøje for at undgå uønskede overraskelser. For eksempel bliver enhver sekundær replika den nuværende primære replika uanset årsagen, og vores mål er ikke at lade det ske.
Der er to krypteringsmuligheder leveret af SQL:sql tde vs altid krypteret. I denne artikel vil jeg fremvise et scenarie, der kræver, at DBA er ekstra opmærksom på detaljer. Ligesom titlen siger, vil den guide dig gennem den korrekte måde at håndtere datakryptering i databaser, der er en del af AlwaysOn Availability Group-opsætningen.
Indledende overvejelser
Jeg vil bruge Transparent Data Encryption (TDE) som teknologien til at bygge min sag op omkring. Det gælder for alle understøttede versioner af SQL Server. Det er vigtigt at nævne, at denne funktion kun er tilgængelig i følgende SQL Server-udgaver:
- SQL Server 2019 Evaluering, Standard, Udvikler, Enterprise
- SQL Server 2017 Evaluering, Udvikler, Enterprise
- SQL Server 2016 Evaluering, Udvikler, Enterprise
- SQL Server 2014 Evaluering, Udvikler, Enterprise
- SQL Server 2012 Evaluering, Udvikler, Enterprise
- SQL Server 2008R2 Datacenter, Evaluering, Udvikler, Enterprise
- SQL Server 2008 Evaluering, Udvikler, Enterprise
Lad os se, hvordan vi kan bruge TDE (Transparent Data Encryption) i SQL Server Standard Edition. Først og fremmest skal vi oprette en DMK (Database Master Key) for at kryptere dataene. Derefter opretter vi et certifikat og en nøgle for at kunne dekryptere dataene, mens vi får adgang til dem. Glem ikke at sikkerhedskopiere certifikatet og til sidst aktivere krypteringen.
Bemærk: TDE-funktionen understøttes ikke i SQL Server Express Edition.
Dette indlæg vil ikke dække trinene til at opbygge en tilgængelighedsgruppe, og jeg er afhængig af den, der allerede er bygget til testformål. Du kan læse mere om, hvordan du implementerer SQL Server AlwaysOn tilgængelighedsgrupper på Linux.
Miljøet er Windows-baseret, men principperne vil være meget ens, hvis du bruger forskellige platforme (f.eks. SQL Server på Linux eller Azure SQL Managed Instances).
Hvad er midlertidig datakryptering
Hovedårsagen til, at vi bruger TDE, er data- og logfilersikkerhed for din SQL-database. For at forhindre, at dine personlige data bliver stjålet, er det en god idé at forsvare dem, og denne krypteringsproces er meget nem. Før siden skrives på disken, krypteres filerne på sideniveau. Hver gang du vil have adgang til dine data, bliver de dekrypteret. Efter TDE-implementering skal du bruge et specifikt certifikat og en nøgle for at gendanne eller vedhæfte databasen. Det er, hvad en krypteringsalgoritme er.
Microsoft Eksempel på SQL Server Tilgængelighedsgruppe
Min testtilgængelighedsgruppe består af 2 replikaer, hver i sin egen VM. Her er de grundlæggende egenskaber:
Som du kan se, er der ikke noget fancy, bare et par replikaer, der bruger synkron commit-tilstand og under manuel failover-tilstand.
Følgende skærmbillede viser en database kaldet "test." Den er føjet til SQL Server AlwaysOn Availability Group, og den er i synkroniseret tilstand.
Sådan aktiverer du TDE i SQL Server
Her er trinene til at aktivere SQL Server TDE for "test"-databasen. Bemærk :Vi udfører følgende trin i den nuværende primære replika.
Trin 1
Opret en hovednøgle i masterdatabasen.
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';
Trin 2
Opret et certifikat, der er beskyttet af hovednøglen.
CREATE CERTIFICATE TestCertificate WITH SUBJECT = 'My test Certificate';Trin 3
Opret databasekrypteringsnøglen (DEK) og beskyt den med certifikatet oprettet i trin 2.
USE test;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE TestCertificate;
Trin 4
Indstil "test"-databasen til at bruge kryptering.
ALTER DATABASE test
SET ENCRYPTION ON;
Hvordan kontrollerer man, om TDE er aktiveret?
Når du er færdig, skal du bekræfte, at Transparent Data Encryption i SQL Server er aktiveret for "test"-databasen.
I Databaseegenskaber sektionen, skal du gå til Indstillinger side. Der skal du være opmærksom på Staten område i bunden af vinduet. Kryptering aktiveret værdien skal være sand .
Du kan også køre følgende TSQL-kode for at bekræfte det:
SELECT name,is_encrypted
FROM sys.databases
WHERE name = 'test'
Nøglestyring og certificeringsproblem
Bemærk: Bliv ikke overrasket, hvis du finder ud af, at tempdb også er krypteret. Det er fordi tempdb er der, hvor alle former for operationer finder sted (f.eks. sortering, hash joins osv.), ved hjælp af data fra alle databaser. Derfor, hvis mindst én brugerdatabase er krypteret, kan operationer fra den pågældende database gå ind i tempdb, som vil skulle returnere disse data til brugerdatabasen. Derfor vil det repræsentere problemet at sende ukrypterede data tilbage.
Du kan læse mere om backup-kryptering i SQL Server for at øge sikkerheden i din database.
Du kan bruge følgende TSQL-kode til at bekræfte, at der er en database-masternøgle til stede for "test"-databasen, som er krypteret af certifikatet (som udført i trin 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å langt så godt, i det mindste for den primære replika. Men hvad sker der, hvis vi forespørger i sys.databases systemvisning for at bekræfte krypteringsstatussen for "test"-databasen i den sekundære replika?
Tilgængelighedsgruppen replikerer alt relateret til databasen fra en replika til en anden. Den sekundære replika siger dog tydeligt, at den ikke er krypteret.
Lad os tjekke vores sekundære replika for eventuelle spor om det:
Status for databasen er “Ikke synkroniserer / mistænkelig” – ser slet ikke godt ud. Men efter at have inspiceret fejlloggen for den sekundære replika, kan jeg se følgende:
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.
Hovedproblemet er, at certifikatet, der bruges til at kryptere databasekrypteringsnøglen til "test"-databasen (trin 3), ikke findes i den sekundære replika.
Hvorfor?
Fordi tilgængelighedsgrupper ikke replikerer data fra systemdatabaser. Det manglende servercertifikat ligger i den primære replika-masterdatabase.
Sådan kontrolleres og konfigureres TDE-certifikat i SQL Server
Lad os generere en sikkerhedskopi af servercertifikatet i den primære replika-masterdatabase. Lad os derefter gendanne den i masterdatabasen for den sekundære replika.
Brug følgende TSQL-kode til at generere sikkerhedskopien fra den aktuelle primære replika, der har "test"-databasen med TDE aktiveret:
USE master;
GO
BACKUP CERTIFICATE TestCertificate
TO FILE = 'C:\temp\TestCertificate.cer'
WITH PRIVATE KEY (file='C:\temp\TestCertificate.pvk',
ENCRYPTION BY PASSWORD='<YourStrongPasswordHere>');
Før du forsøger at gendanne certifikatet i den sekundære replika, skal du først kontrollere, om databasenøglen findes i masterdatabasen. Hvis ikke, opret det nøjagtigt som i trin 1.
Brug følgende TSQL-kode til at gendanne certifikatet i den sekundære replika. Bemærk :Sørg for at kopiere .cer- og .pvk-filerne til målmappen 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>'
);
Selv efter gendannelse af certifikatet i den sekundære replika, forbliver tilstanden af "test"-databasen den samme:
Da databevægelsen for "test"-databasen er sat på pause, lad os genoptage den manuelt for at se, om vi er heldige denne gang:
Ja! Operationen lykkedes. "Test"-databasen er ikke kun fuldt synkroniseret og sund, men også krypteret med TDE.
Desuden, efter udførelsen af den manuelle failover for at udskifte replikaernes roller, fortsætter alt med at fungere perfekt.
Konklusion
Den fremviste løsning fungerede perfekt. Det er dog måske ikke ideelt i alle tilfælde, især hvis du er en DBA, der kan lide at planlægge og gøre tingene på den "korrekte" måde. Jeg ser "korrekt" som følger:
- Fjern databasen fra tilgængelighedsgruppen
- Udfør alle trinene for at aktivere Transparent Data Encryption i replikaen, hvor databasen læses/skrives.
- Sikkerhedskopier servercertifikatet fra den primære replika.
- Kopiér sikkerhedskopifilen til placeringen(e) af de(n) sekundære replika(er).
- Gendan certifikatet i masterdatabasen.
- Tilføj databasen tilbage til tilgængelighedsgruppen.
- Sørg for, at databasens driftstilstand er den korrekte og tilsigtede (afhængigt af din specifikke opsætning).
Jeg smider dobbelte anførselstegn for "korrekt", fordi jeg på den måde, jeg præsenterede løsningen på, fik databasen i den sekundære replika markeret som suspekt. Alene dette ville sandsynligvis rejse mange uønskede flag/advarsler/fingerpegning. Det er unødvendig støj, som du nemt kan undgå ved at tage alle hensyn til at planlægge og implementere TDE korrekt i en Always On Availability Group-opsætning.
For at afslutte dette indlæg, efterlader jeg dig med det officielle krypteringshierarki, der bruges til TDE, som Microsoft har lagt ud på deres hjemmeside. Det, jeg gerne vil have dig til at huske på, er, hvor hvert element er oprettet (enten i master- eller brugerdatabasen), så du kan overvinde eventuelle potentielle problemer/overraskelser med tilgængelighedsgrupper.
Hvis du ikke er klar over det, kan SQL Complete i høj grad hjælpe dig med at konfigurere Always Encrypted, som er en anden nyttig teknologi til at beskytte følsomme data.
Husk, at du skal overveje det samme, som diskuteres i denne artikel, hvis du planlægger at beskæftige dig med Always Encrypted in a Always On Availability Group-scenarie. Funktioner, som SQL Complete v6.7 introducerer, er dog designet til at sikre, at du får succes med det samme.