Skupiny dostupnosti jsou fantastické pro řešení High Availability/Disaster Recovery a jsem si jistý, že kolegové DBA se mnou budou souhlasit. Vyskytnou se však chvíle, kdy musíme pečlivě zvážit určitá opatření a další kroky, abychom se vyhnuli nechtěným překvapením. Například jakákoli sekundární replika se z jakéhokoli důvodu stane aktuální primární replikou a naším cílem je nedopustit, aby se to stalo.
SQL poskytuje dvě možnosti šifrování:sql tde vs vždy šifrováno. V tomto článku předvedu jeden scénář, který vyžaduje, aby DBA věnoval zvláštní pozornost detailům. Jak název napovídá, provede vás správným způsobem, jak se vypořádat s šifrováním dat v databázích, které jsou součástí nastavení AlwaysOn Availability Group.
Počáteční úvahy
Jako technologii budu používat Transparent Data Encryption (TDE). Platí pro všechny podporované verze SQL Serveru. Je důležité zmínit, že tato funkce je dostupná pouze v následujících edicích SQL Server:
- Hodnocení SQL Server 2019, Standard, Developer, Enterprise
- Hodnocení SQL Server 2017, vývojář, podnik
- Hodnocení SQL Server 2016, vývojář, podnik
- Hodnocení SQL Server 2014, vývojář, podnik
- Hodnocení SQL Server 2012, vývojář, podnik
- Datové centrum SQL Server 2008R2, hodnocení, vývojář, podnik
- Hodnocení SQL Server 2008, vývojář, podnik
Podívejme se, jak můžeme použít TDE (Transparent Data Encryption) v SQL Server Standard Edition. Nejprve musíme vytvořit DMK (Database Master Key) pro šifrování dat. Poté vytvoříme certifikát a klíč, abychom mohli data při přístupu k nim dešifrovat. Nezapomeňte si zálohovat certifikát a nakonec povolit šifrování.
Poznámka: Funkce TDE není podporována v SQL Server Express Edition.
Tento příspěvek se nebude týkat kroků k vytvoření skupiny dostupnosti a spoléhám se na tu již vytvořenou pro testovací účely. Můžete si přečíst více o tom, jak nasadit skupiny dostupnosti SQL Server AlwaysOn v systému Linux.
Prostředí je založené na Windows, ale principy budou velmi podobné, pokud používáte různé platformy (např. SQL Server na Linuxu nebo Azure SQL Managed Instance).
Co je to dočasné šifrování dat
Hlavním důvodem, proč používáme TDE, je zabezpečení dat a log souborů pro vaši SQL databázi. Abyste zabránili odcizení vašich osobních údajů, je dobré je bránit, navíc je tento proces šifrování velmi snadný. Před zapsáním stránky na disk jsou soubory zašifrovány na úrovni stránky. Pokaždé, když chcete získat přístup ke svým datům, jsou dešifrována. Po implementaci TDE budete potřebovat konkrétní certifikát a klíč k obnovení nebo připojení databáze. To je šifrovací algoritmus.
Microsoft Příklad skupiny dostupnosti serveru SQL
Moje testovací skupina dostupnosti se skládá ze 2 replik, každá ve svém vlastním virtuálním počítači. Zde jsou základní vlastnosti:
Jak můžete vidět, není tu nic přepychového, jen pár replik využívajících režim synchronního odevzdání a v režimu ručního převzetí služeb při selhání.
Následující snímek obrazovky ukazuje databázi s názvem „test“. Je přidán do skupiny SQL Server AlwaysOn Availability Group a je v synchronizovaném stavu.
Jak povolit TDE v SQL Server
Zde jsou kroky, jak povolit SQL Server TDE pro „testovací“ databázi. Poznámka :v aktuální primární replice provedeme následující kroky.
Krok 1
Vytvořte hlavní klíč v hlavní databázi.
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';
Krok 2
Vytvořte certifikát chráněný hlavním klíčem.
CREATE CERTIFICATE TestCertificate WITH SUBJECT = 'My test Certificate';Krok 3
Vytvořte šifrovací klíč databáze (DEK) a chraňte jej pomocí certifikátu vytvořeného v kroku 2.
USE test;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE TestCertificate;
Krok 4
Nastavte „testovací“ databázi pro použití šifrování.
ALTER DATABASE test
SET ENCRYPTION ON;
Jak zkontrolovat, zda je TDE povoleno?
Až budete hotovi, musíte potvrdit, že je pro „testovací“ databázi povoleno Transparent Data Encryption na serveru SQL Server.
V části Vlastnosti databáze přejděte do části Možnosti strana. Tam věnujte pozornost státu oblast ve spodní části okna. Šifrování povoleno hodnota musí být True .
Pro potvrzení můžete také spustit následující kód TSQL:
SELECT name,is_encrypted
FROM sys.databases
WHERE name = 'test'
Problém se správou klíčů a certifikací
Poznámka: Nebuďte překvapeni, když zjistíte, že tempdb je také šifrována. Je to proto, že tempdb je místo, kde probíhají všechny druhy operací (např. řazení, spojení hash atd.), využívající data ze všech databází. Pokud je tedy alespoň jedna uživatelská databáze zašifrována, operace z této konkrétní databáze mohou přejít do databáze tempdb, která bude muset vrátit tato data do databáze uživatelů. Problém by tedy představovalo odesílání nešifrovaných dat zpět.
Můžete si přečíst více o šifrování záloh na serveru SQL, abyste zvýšili zabezpečení vaší databáze.
Následující kód TSQL můžete použít k potvrzení, že existuje hlavní klíč databáze pro „testovací“ databázi, která je zašifrována certifikátem (jak bylo provedeno v 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'
Zatím je to dobré, alespoň pro Primární repliku. Co se ale stane, když se dotazujeme na sys.databases systémové zobrazení pro potvrzení stavu šifrování „testovací“ databáze v sekundární replice?
Skupina dostupnosti replikuje vše, co souvisí s databází, z jedné repliky do druhé. Sekundární replika však jasně uvádí, že není šifrována.
Podívejme se na naši sekundární repliku, abychom o tom věděli:
Stav databáze je „Nesynchronizuje se / Podezřelý“ – nevypadá vůbec dobře. Po kontrole protokolu chyb sekundární repliky však vidím následující:
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.
Hlavním problémem je, že certifikát použitý k zašifrování šifrovacího klíče databáze „testovací“ databáze (krok 3) není přítomen v sekundární replice.
Proč?
Protože skupiny dostupnosti nereplikují data ze systémových databází. Chybějící certifikát serveru se nachází v hlavní databázi primární repliky.
Jak zkontrolovat a nastavit certifikát TDE na serveru SQL
Vygenerujeme zálohu certifikátu serveru v hlavní databázi Primary Replica. Poté jej obnovíme v hlavní databázi sekundární repliky.
Pomocí následujícího kódu TSQL vygenerujte zálohu z aktuální primární repliky, která má „testovací“ databázi s povoleným 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>');
Před pokusem o obnovení certifikátu v sekundární replice nejprve zkontrolujte, zda v hlavní databázi existuje hlavní klíč databáze. Pokud ne, vytvořte jej přesně jako v kroku 1.
K obnovení certifikátu v sekundární replice použijte následující kód TSQL. Poznámka :Nejprve zkopírujte soubory .cer a .pvk do cílového adresáře.
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>'
);
I po obnovení certifikátu v sekundární replice tedy zůstává stav „testovací“ databáze stejný:
Vzhledem k tomu, že přesun dat pro „testovací“ databázi je pozastaven, pojďme jej ručně obnovit, abychom zjistili, zda máme tentokrát štěstí:
Ano! Operace byla úspěšná. „Testovací“ databáze je nejen plně synchronizovaná a zdravá, ale také šifrovaná pomocí TDE.
Kromě toho po provedení ručního převzetí služeb při selhání za účelem výměny rolí replik vše nadále funguje naprosto v pořádku.
Závěr
Prezentované řešení fungovalo perfektně. Nemusí to však být ideální ve všech případech, zvláště pokud jste DBA, který rád plánuje a dělá věci „správným“ způsobem. „Správně“ vidím takto:
- Odeberte databázi ze skupiny dostupnosti
- Proveďte všechny kroky k povolení transparentního šifrování dat v replice, kde se databáze čte/zapisuje.
- Zálohujte certifikát serveru z primární repliky.
- Zkopírujte záložní soubor do umístění sekundárních replik.
- Obnovte certifikát v hlavní databázi.
- Přidejte databázi zpět do skupiny dostupnosti.
- Ujistěte se, že provozní stav databáze je správný a zamýšlený (v závislosti na vašem konkrétním nastavení).
Házím dvojité uvozovky pro „správné“, protože způsobem, jakým jsem prezentoval řešení, jsem dostal databázi v sekundární replice označenou jako Podezřelý. To samo o sobě by pravděpodobně vyvolalo mnoho nechtěných vlajek/upozornění/ukazování prstem. Je to zbytečný hluk, kterému se můžete snadno vyhnout tím, že vezmete v úvahu všechny aspekty plánování a správné implementace TDE v nastavení skupiny Always On Availability Group.
Abych zakončil tento příspěvek, nechávám vám oficiální hierarchii šifrování používanou pro TDE, kterou Microsoft zveřejnil na svých webových stránkách. Rád bych, abyste měli na paměti, kde je každý prvek vytvořen (buď v hlavní nebo uživatelské databázi), abyste mohli překonat případné problémy/překvapení se skupinami dostupnosti.
V případě, že si nejste vědomi, SQL Complete vám může velmi pomoci nakonfigurovat Always Encrypted, což je další užitečná technologie pro ochranu citlivých dat.
Mějte na paměti, že byste měli zvážit totéž, co je diskutováno v tomto článku, pokud se plánujete vypořádat s Always Encrypted ve scénáři Always On Availability Group. Funkce, které SQL Complete v6.7 zavádí, jsou však navrženy tak, aby zajistily, že uspějete hned na začátku.