Beschikbaarheidsgroepen zijn fantastisch voor High Availability/Disaster Recovery-oplossingen, en ik weet zeker dat andere DBA's het met mij eens zullen zijn. Er zullen echter momenten zijn waarop we bepaalde voorzorgsmaatregelen en extra stappen zorgvuldig moeten overwegen om ongewenste verrassingen te voorkomen. Elke secundaire replica wordt bijvoorbeeld om welke reden dan ook de huidige primaire replica, en ons doel is om dit niet te laten gebeuren.
SQL biedt twee versleutelingsopties:sql tde versus altijd versleuteld. In dit artikel ga ik één scenario laten zien waarvoor de DBA extra aandacht moet besteden aan details. Zoals de titel al zegt, zal het u begeleiden bij de juiste manier om om te gaan met de gegevenscodering binnen databases die deel uitmaken van de AlwaysOn-beschikbaarheidsgroepconfiguratie.
Eerste overwegingen
Ik zal Transparante gegevenscodering (TDE) gebruiken als de technologie om mijn zaak rond te bouwen. Het is van toepassing op alle ondersteunde versies van SQL Server. Het is belangrijk te vermelden dat deze functie alleen beschikbaar is in de volgende SQL Server-edities:
- SQL Server 2019 Evaluatie, Standaard, Ontwikkelaar, Enterprise
- SQL Server 2017 Evaluatie, Ontwikkelaar, Enterprise
- SQL Server 2016 Evaluatie, Ontwikkelaar, Enterprise
- SQL Server 2014 Evaluatie, Ontwikkelaar, Enterprise
- SQL Server 2012 evaluatie, ontwikkelaar, onderneming
- SQL Server 2008R2 Datacenter, Evaluatie, Ontwikkelaar, Enterprise
- SQL Server 2008 evaluatie, ontwikkelaar, onderneming
Laten we eens kijken hoe we TDE (Transparent Data Encryption) kunnen gebruiken in SQL Server Standard Edition. Allereerst moeten we een DMK (Database Master Key) maken om de gegevens te versleutelen. Vervolgens maken we een certificaat en een sleutel om de gegevens te kunnen ontsleutelen terwijl we er toegang toe hebben. Vergeet niet een back-up van het certificaat te maken en tot slot de codering in te schakelen.
Opmerking: De TDE-functie wordt niet ondersteund in SQL Server Express Edition.
Dit bericht behandelt niet de stappen om een Beschikbaarheidsgroep te bouwen, en ik vertrouw op de groep die al is gebouwd voor testdoeleinden. U kunt meer lezen over het implementeren van SQL Server AlwaysOn-beschikbaarheidsgroepen op Linux.
De omgeving is gebaseerd op Windows, maar de principes zullen zeer vergelijkbaar zijn als u verschillende platforms gebruikt (bijv. SQL Server op Linux of Azure SQL Managed Instances).
Wat is tijdelijke gegevenscodering
De belangrijkste reden waarom we TDE gebruiken, is de beveiliging van gegevens en logbestanden voor uw SQL-database. Om te voorkomen dat uw persoonlijke gegevens worden gestolen, is het een goed idee om deze te verdedigen, en dit versleutelingsproces is heel eenvoudig. Voordat de pagina naar de schijf wordt geschreven, worden bestanden op paginaniveau versleuteld. Elke keer dat u toegang wilt tot uw gegevens, wordt deze gedecodeerd. Na de implementatie van TDE hebt u een specifiek certificaat en een sleutel nodig om de database te herstellen of te koppelen. Dat is wat een versleutelingsalgoritme is.
Microsoft Voorbeeld van SQL Server-beschikbaarheidsgroep
Mijn testbeschikbaarheidsgroep bestaat uit 2 replica's, elk in een eigen VM. Dit zijn de basiseigenschappen:
Zoals je kunt zien, is er niets bijzonders, slechts een paar replica's die de synchrone commit-modus gebruiken en in de handmatige failover-modus.
De volgende schermafbeelding toont een database met de naam "test". Het is toegevoegd aan de SQL Server AlwaysOn-beschikbaarheidsgroep en heeft de gesynchroniseerde status.
TDE inschakelen in SQL Server
Hier zijn de stappen om SQL Server TDE in te schakelen voor de "test" -database. Opmerking :we voeren de volgende stappen uit in de huidige primaire replica.
Stap 1
Maak een hoofdsleutel in de hoofddatabase.
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';
Stap 2
Maak een certificaat dat wordt beschermd door de hoofdsleutel.
CREATE CERTIFICATE TestCertificate WITH SUBJECT = 'My test Certificate';Stap 3
Maak de Database Encryption Key (DEK) en beveilig deze met het certificaat dat in stap 2 is gemaakt.
USE test;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE TestCertificate;
Stap 4
Stel de "test"-database in om encryptie te gebruiken.
ALTER DATABASE test
SET ENCRYPTION ON;
Hoe te controleren of TDE is ingeschakeld?
Nadat u klaar bent, moet u bevestigen dat transparante gegevenscodering in SQL Server is ingeschakeld voor de "test" -database.
In de Database-eigenschappen sectie, ga naar de Opties bladzijde. Let daar op de Status gebied aan de onderkant van het venster. De Encryptie ingeschakeld waarde moet Waar zijn .
U kunt ook de volgende TSQL-code uitvoeren om het te bevestigen:
SELECT name,is_encrypted
FROM sys.databases
WHERE name = 'test'
Sleutelbeheer en certificeringsprobleem
Opmerking: Wees niet verbaasd als je erachter komt dat tempdb ook versleuteld is. Het is omdat tempdb de plaats is waar allerlei soorten bewerkingen plaatsvinden (bijvoorbeeld sorteren, hash-joins, enz.), waarbij de gegevens uit alle databases worden gebruikt. Daarom, als ten minste één gebruikersdatabase is gecodeerd, kunnen bewerkingen van die specifieke database naar tempdb gaan, waardoor die gegevens naar de gebruikersdatabase moeten worden geretourneerd. Daarom zou het terugsturen van niet-versleutelde gegevens het probleem zijn.
U kunt meer lezen over back-upversleuteling in SQL Server om de beveiliging van uw database te verbeteren.
U kunt de volgende TSQL-code gebruiken om te bevestigen dat er een databasehoofdsleutel aanwezig is voor de "test"-database die is versleuteld door het certificaat (zoals uitgevoerd in stap 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'
Tot nu toe zo goed, in ieder geval voor de primaire replica. Maar wat gebeurt er als we de sys.databases . opvragen? systeemweergave om de coderingsstatus van de "test"-database in de secundaire replica te bevestigen?
De Beschikbaarheidsgroep repliceert alles met betrekking tot de database van de ene replica naar de andere. De secundaire replica geeft echter duidelijk aan dat deze niet versleuteld is.
Laten we onze secundaire replica eens bekijken voor aanwijzingen daarover:
De status van de database is “Niet synchroniseren/verdacht” – helemaal niet goed uit. Echter, na inspectie van het foutenlogboek van de secundaire replica, kan ik het volgende zien:
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.
Het grootste probleem is dat het certificaat dat wordt gebruikt om de databasecoderingssleutel van de "test" -database (stap 3) te coderen, niet aanwezig is in de secundaire replica.
Waarom?
Omdat beschikbaarheidsgroepen geen gegevens uit systeemdatabases repliceren. Het ontbrekende servercertificaat bevindt zich in de hoofddatabase van de primaire replica.
Het TDE-certificaat controleren en instellen in SQL Server
Laten we een back-up maken van het servercertificaat in de hoofddatabase van de primaire replica. Laten we het dan herstellen in de hoofddatabase van de secundaire replica.
Gebruik de volgende TSQL-code om de back-up te genereren van de huidige primaire replica met de "test"-database met TDE ingeschakeld:
USE master;
GO
BACKUP CERTIFICATE TestCertificate
TO FILE = 'C:\temp\TestCertificate.cer'
WITH PRIVATE KEY (file='C:\temp\TestCertificate.pvk',
ENCRYPTION BY PASSWORD='<YourStrongPasswordHere>');
Voordat u probeert het certificaat in de secundaire replica te herstellen, moet u eerst controleren of de databasehoofdsleutel in de hoofddatabase bestaat. Zo niet, maak het dan precies zoals in stap 1.
Gebruik de volgende TSQL-code om het certificaat in de secundaire replica te herstellen. Opmerking :zorg ervoor dat u eerst de .cer- en .pvk-bestanden naar de doelmap kopieert.
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>'
);
Dus zelfs na het herstellen van het certificaat in de secundaire replica, blijft de status van de "test"-database hetzelfde:
Aangezien de gegevensverplaatsing voor de "test" -database is onderbroken, laten we deze handmatig hervatten om te zien of we deze keer geluk hebben:
Ja! De operatie is geslaagd. De "test"-database is niet alleen volledig gesynchroniseerd en gezond, maar ook versleuteld met TDE.
Trouwens, na het uitvoeren van de handmatige failover om de rollen van de replica's te verwisselen, blijft alles perfect werken.
Conclusie
De getoonde oplossing werkte prima. Het is echter misschien niet in alle gevallen ideaal, vooral als u een DBA bent die graag dingen op de "juiste" manier plant en doet. Ik zie "correct" als volgt:
- Verwijder de database uit de Beschikbaarheidsgroep
- Voer alle stappen uit om transparante gegevenscodering in te schakelen in de replica waar de database wordt gelezen/geschreven.
- Maak een back-up van het servercertificaat van de primaire replica.
- Kopieer het back-upbestand naar de locatie(s) van de secundaire replica('s).
- Herstel het certificaat in de hoofddatabase.
- Voeg de database weer toe aan de Beschikbaarheidsgroep.
- Zorg ervoor dat de operationele status van de database correct en bedoeld is (afhankelijk van uw specifieke configuratie).
Ik gooi dubbele aanhalingstekens voor "juist" omdat ik in de manier waarop ik de oplossing presenteerde, de database in de secundaire replica als verdacht heb gemarkeerd. Dit alleen al zou waarschijnlijk veel ongewenste vlaggen/waarschuwingen/vingerwijzen oproepen. Het is onnodige ruis die u eenvoudig kunt vermijden door rekening te houden met alle overwegingen om TDE in een Always On Availability Group-opstelling te plannen en correct te implementeren.
Om dit bericht af te sluiten, laat ik je achter met de officiële versleutelingshiërarchie die wordt gebruikt voor TDE, die Microsoft op hun website heeft geplaatst. Wat ik graag wil dat u in gedachten houdt, is waar elk element wordt gemaakt (in de hoofd- of gebruikersdatabase), zodat u eventuele problemen/verrassingen met Beschikbaarheidsgroepen kunt oplossen.
Als u het niet weet, kan SQL Complete u enorm helpen bij het configureren van Always Encrypted, een andere nuttige technologie om gevoelige gegevens te beschermen.
Houd er rekening mee dat u hetzelfde moet overwegen als in dit artikel wordt besproken als u van plan bent om te gaan met Always Encrypted in een Always On Availability Group-scenario. De functies die SQL Complete v6.7 introduceert, zijn echter ontworpen om ervoor te zorgen dat u meteen slaagt.