Grupy dostępności są fantastyczne w przypadku rozwiązań wysokiej dostępności/odzyskiwania po awarii i jestem pewien, że inni administratorzy baz danych zgodzą się ze mną. Jednak będą chwile, kiedy będziemy musieli ostrożnie rozważyć pewne środki ostrożności i dodatkowe kroki, aby uniknąć niechcianych niespodzianek. Na przykład każda replika drugorzędna staje się z jakiegokolwiek powodu obecną repliką główną, a naszym celem jest, aby do tego nie dopuścić.
Istnieją dwie opcje szyfrowania udostępniane przez SQL:sql tde vs zawsze szyfrowane. W tym artykule przedstawię jeden scenariusz, który wymaga od administratora zwracania większej uwagi na szczegóły. Tak jak mówi tytuł, poprowadzi Cię przez właściwy sposób radzenia sobie z szyfrowaniem danych w bazach danych, które są częścią konfiguracji AlwaysOn Availability Group.
Rozważania wstępne
Będę używał przezroczystego szyfrowania danych (TDE) jako technologii do budowania mojej sprawy. Dotyczy wszystkich obsługiwanych wersji SQL Server. Należy wspomnieć, że ta funkcja jest dostępna tylko w następujących wersjach SQL Server:
- Ocena SQL Server 2019, Standard, Developer, Enterprise
- Ocena SQL Server 2017, programista, Enterprise
- Ocena SQL Server 2016, programista, Enterprise
- Ocena SQL Server 2014, programista, przedsiębiorstwa
- Ocena SQL Server 2012, programista, przedsiębiorstwo
- Centrum danych SQL Server 2008R2, ewaluacyjne, programistyczne, korporacyjne
- Ocena SQL Server 2008, programista, przedsiębiorstwo
Zobaczmy, jak możemy wykorzystać TDE (Transparent Data Encryption) w SQL Server Standard Edition. Przede wszystkim musimy utworzyć DMK (Database Master Key), aby zaszyfrować dane. Następnie tworzymy certyfikat i klucz, aby móc odszyfrować dane podczas uzyskiwania do nich dostępu. Nie zapomnij wykonać kopii zapasowej certyfikatu i na koniec włączyć szyfrowanie.
Uwaga: Funkcja TDE nie jest obsługiwana w SQL Server Express Edition.
W tym poście nie zostaną omówione kroki związane z tworzeniem grupy dostępności i polegam na tej już zbudowanej do celów testowych. Możesz przeczytać więcej o tym, jak wdrożyć grupy dostępności SQL Server AlwaysOn w systemie Linux.
Środowisko jest oparte na systemie Windows, ale zasady będą bardzo podobne, jeśli użyjesz różnych platform (np. SQL Server w systemie Linux lub Azure SQL Managed Instances).
Co to jest tymczasowe szyfrowanie danych
Głównym powodem, dla którego używamy TDE, jest bezpieczeństwo danych i plików dziennika dla Twojej bazy danych SQL. Aby zapobiec kradzieży danych osobowych, dobrze jest je chronić, a proces szyfrowania jest bardzo łatwy. Zanim strona zostanie zapisana na dysku, pliki są szyfrowane na poziomie strony. Za każdym razem, gdy chcesz uzyskać dostęp do swoich danych, zostają one odszyfrowane. Po wdrożeniu TDE będziesz potrzebować określonego certyfikatu i klucza do przywrócenia lub dołączenia bazy danych. Tym właśnie jest algorytm szyfrowania.
Microsoft Przykład grupy dostępności serwera SQL
Moja testowa grupa dostępności składa się z 2 replik, z których każda znajduje się na osobnej maszynie wirtualnej. Oto podstawowe właściwości:
Jak widać, nie ma nic wymyślnego, tylko kilka replik korzystających z trybu synchronicznego zatwierdzania i w trybie ręcznego przełączania awaryjnego.
Poniższy zrzut ekranu przedstawia bazę danych o nazwie „test”. Jest dodawany do grupy dostępności AlwaysOn programu SQL Server i znajduje się w stanie zsynchronizowanym.
Jak włączyć TDE w SQL Server
Oto kroki, aby włączyć SQL Server TDE dla „testowej” bazy danych. Uwaga :w obecnej replice podstawowej wykonamy następujące kroki.
Krok 1
Utwórz klucz główny w głównej bazie danych.
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';
Krok 2
Utwórz certyfikat chroniony kluczem głównym.
CREATE CERTIFICATE TestCertificate WITH SUBJECT = 'My test Certificate';Krok 3
Utwórz klucz szyfrowania bazy danych (DEK) i chroń go za pomocą certyfikatu utworzonego w kroku 2.
USE test;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE TestCertificate;
Krok 4
Ustaw „testową” bazę danych tak, aby używała szyfrowania.
ALTER DATABASE test
SET ENCRYPTION ON;
Jak sprawdzić, czy TDE jest włączone?
Po zakończeniu musisz potwierdzić, że przezroczyste szyfrowanie danych w SQL Server jest włączone dla „testowej” bazy danych.
W Właściwościach bazy danych przejdź do sekcji Opcje strona. Tam zwróć uwagę na stan obszar na dole okna. Włączone szyfrowanie wartość musi być prawda .
Możesz również uruchomić następujący kod TSQL, aby to potwierdzić:
SELECT name,is_encrypted
FROM sys.databases
WHERE name = 'test'
Problem z zarządzaniem kluczami i certyfikacją
Uwaga: Nie zdziw się, jeśli dowiesz się, że tempdb również jest zaszyfrowany. Dzieje się tak dlatego, że tempdb to miejsce, w którym odbywają się wszelkiego rodzaju operacje (np. sortowanie, łączenia haszujące itp.), wykorzystujące dane ze wszystkich baz danych. W związku z tym, jeśli co najmniej jedna baza danych użytkownika jest zaszyfrowana, operacje z tej konkretnej bazy danych mogą przejść do tempdb, która będzie musiała zwrócić te dane do bazy danych użytkownika. Dlatego odesłanie niezaszyfrowanych danych stanowiłoby problem.
Możesz przeczytać więcej o szyfrowaniu kopii zapasowych w SQL Server, aby zwiększyć bezpieczeństwo bazy danych.
Możesz użyć następującego kodu TSQL, aby potwierdzić, że istnieje główny klucz bazy danych dla „testowej” bazy danych, która jest zaszyfrowana przez certyfikat (jak wykonano w kroku 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'
Jak dotąd tak dobrze, przynajmniej jak na replikę podstawową. Ale co się stanie, jeśli zapytamy sys.databases widok systemu, aby potwierdzić stan szyfrowania „testowej” bazy danych w replice wtórnej?
Grupa dostępności replikuje wszystko, co jest związane z bazą danych, z jednej repliki do drugiej. Jednak replika wtórna wyraźnie stwierdza, że nie jest zaszyfrowana.
Sprawdźmy naszą replikę drugorzędną pod kątem jakichkolwiek wskazówek na ten temat:
Stan bazy danych to „Brak synchronizacji / Podejrzany” – w ogóle nie wygląda dobrze. Jednak po sprawdzeniu dziennika błędów repliki wtórnej widzę, co następuje:
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.
Główny problem polega na tym, że certyfikat używany do szyfrowania klucza szyfrowania bazy danych „testowej” bazy danych (krok 3) nie występuje w replice wtórnej.
Dlaczego?
Ponieważ grupy dostępności nie replikują danych z systemowych baz danych. Brakujący certyfikat serwera znajduje się w głównej bazie danych repliki podstawowej.
Jak sprawdzić i skonfigurować certyfikat TDE na serwerze SQL
Wygenerujmy kopię zapasową certyfikatu serwera w bazie danych mastera Primary Replica. Następnie przywróćmy go w głównej bazie danych repliki wtórnej.
Użyj następującego kodu TSQL, aby wygenerować kopię zapasową z bieżącej repliki podstawowej, która ma „testową” bazę danych z włączonym TDE:
USE master;
GO
BACKUP CERTIFICATE TestCertificate
TO FILE = 'C:\temp\TestCertificate.cer'
WITH PRIVATE KEY (file='C:\temp\TestCertificate.pvk',
ENCRYPTION BY PASSWORD='<YourStrongPasswordHere>');
Przed próbą przywrócenia certyfikatu w replice pomocniczej najpierw sprawdź, czy główny klucz bazy danych istnieje w bazie danych master. Jeśli nie, utwórz go dokładnie tak, jak w kroku 1.
Użyj następującego kodu TSQL, aby przywrócić certyfikat w replice pomocniczej. Uwaga :Najpierw skopiuj pliki .cer i .pvk do katalogu docelowego.
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>'
);
Dlatego nawet po przywróceniu certyfikatu w replice wtórnej stan bazy danych „testowej” pozostaje taki sam:
Ponieważ przenoszenie danych dla „testowej” bazy danych zostało wstrzymane, wznówmy ją ręcznie, aby sprawdzić, czy tym razem mamy szczęście:
Tak! Operacja zakończyła się sukcesem. „Testowa” baza danych jest nie tylko w pełni zsynchronizowana i zdrowa, ale także zaszyfrowana za pomocą TDE.
Poza tym po wykonaniu ręcznego przełączania awaryjnego w celu zamiany ról replik wszystko nadal działa idealnie.
Wniosek
Prezentowane rozwiązanie zadziałało idealnie. Jednak może to nie być idealne we wszystkich przypadkach, zwłaszcza jeśli jesteś DBA, który lubi planować i robić rzeczy we „właściwy” sposób. Widzę „poprawne” w następujący sposób:
- Usuń bazę danych z grupy dostępności
- Wykonaj wszystkie kroki, aby włączyć przezroczyste szyfrowanie danych w replice, w której baza danych jest odczytywana/zapisywana.
- Utwórz kopię zapasową certyfikatu serwera z repliki podstawowej.
- Skopiuj plik kopii zapasowej do lokalizacji replik pomocniczych.
- Przywróć certyfikat w głównej bazie danych.
- Dodaj bazę danych z powrotem do grupy dostępności.
- Upewnij się, że stan operacyjny bazy danych jest prawidłowy i zamierzony (w zależności od konkretnej konfiguracji).
Wrzucam podwójne cudzysłowy dla „poprawne”, ponieważ w sposób w jaki przedstawiłem rozwiązanie dostałem bazę w Secondary Replica oznaczoną jako Podejrzany. Samo to prawdopodobnie wywołałoby wiele niechcianych flag/alertów/wskazań palcem. Jest to niepotrzebny hałas, którego można łatwo uniknąć, biorąc pod uwagę wszystkie kwestie związane z planowaniem i prawidłowym wdrożeniem TDE w konfiguracji Always On Availability Group.
Podsumowując ten post, zostawiam cię z oficjalną hierarchią szyfrowania używaną dla TDE, którą Microsoft opublikował na swojej stronie internetowej. To, o czym chciałbym, abyś pamiętał, to miejsce, w którym tworzony jest każdy element (w głównej bazie danych lub w bazie danych użytkownika), dzięki czemu możesz przezwyciężyć wszelkie potencjalne problemy/niespodzianki za pomocą grup dostępności.
Jeśli nie wiesz, SQL Complete może bardzo pomóc w konfiguracji Always Encrypted, która jest kolejną przydatną technologią do ochrony poufnych danych.
Pamiętaj, że musisz wziąć pod uwagę to samo, co omówiono w tym artykule, jeśli planujesz zająć się zawsze szyfrowaniem w scenariuszu zawsze włączonej grupy dostępności. Jednak funkcje wprowadzone w SQL Complete v6.7 mają na celu zapewnienie natychmiastowego sukcesu.
