Групите за наличност са фантастични за решения за висока наличност/възстановяване при бедствия и съм сигурен, че колегите администратори на администриране на администраторите ще се съгласят с мен. Въпреки това ще има моменти, когато трябва внимателно да обмислим някои предпазни мерки и допълнителни стъпки, за да избегнем нежелани изненади. Например, всяка вторична реплика става текущата първична реплика по някаква причина и нашата цел е да не позволим това да се случи.
Има две опции за криптиране, предоставени от SQL:sql tde срещу винаги криптиран. В тази статия ще покажа един сценарий, който изисква от DBA да обърне допълнително внимание на детайлите. Точно както казва заглавието, то ще ви преведе през правилния начин за справяне с криптирането на данни в базите данни, които са част от настройката на AlwaysOn Availability Group.
Първоначални съображения
Ще използвам прозрачно криптиране на данни (TDE) като технология за изграждане на моя случай. Прилага се за всички поддържани версии на SQL Server. Важно е да се спомене, че тази функция е достъпна само в следните издания на SQL Server:
- SQL Server 2019 Оценка, стандарт, разработчик, предприятие
- SQL Server 2017 оценка, разработчик, предприятие
- SQL Server 2016 оценка, разработчик, предприятие
- SQL Server 2014 Оценка, разработчик, предприятие
- SQL Server 2012 Оценка, разработчик, предприятие
- SQL Server 2008R2 център за данни, оценка, разработчик, предприятие
- SQL Server 2008 оценка, разработчик, предприятие
Нека видим как можем да използваме TDE (Прозрачно криптиране на данни) в SQL Server Standard Edition. На първо място, трябва да създадем DMK (главен ключ на базата данни), за да криптираме данните. След това създаваме сертификат и ключ, за да можем да декриптираме данните, докато осъществяваме достъп до тях. Не забравяйте да архивирате сертификата и накрая да активирате криптирането.
Забележка: Функцията TDE не се поддържа в SQL Server Express Edition.
Тази публикация няма да обхваща стъпките за изграждане на група за наличност и аз разчитам на вече изградената за целите на тестването. Можете да прочетете повече за това как да разположите SQL Server AlwaysOn групи за наличност в Linux.
Средата е базирана на Windows, но принципите ще бъдат много сходни, ако използвате различни платформи (напр. SQL Server на Linux или Azure SQL управлявани инстанции).
Какво е временно криптиране на данни
Основната причина, поради която използваме TDE, е сигурността на данните и регистрационните файлове за вашата SQL база данни. За да предотвратите кражба на вашите лични данни, е добра идея да ги защитите, освен това този процес на криптиране е много лесен. Преди страницата да бъде записана на диска, файловете се криптират на ниво страница. Всеки път, когато искате да получите достъп до вашите данни, те се декриптират. След внедряването на TDE ще ви трябва конкретен сертификат и ключ за възстановяване или прикачване на базата данни. Това е алгоритъмът за криптиране.
Microsoft Пример за група за наличност на SQL сървър
Моята тестова група за наличност се състои от 2 реплики, всяка в своя собствена VM. Ето основните свойства:
Както можете да видите, няма нищо фантастично, само няколко реплики, използващи режим на синхронно записване и в режим на ръчно преминаване при отказ.
Следната екранна снимка демонстрира база данни, наречена „тест“. Той е добавен към SQL Server AlwaysOn Availability Group и е в синхронизирано състояние.
Как да активирате TDE в SQL Server
Ето стъпките за активиране на SQL Server TDE за „тестовата“ база данни. Забележка :ще изпълним следните стъпки в текущата основна реплика.
Стъпка 1
Създайте главен ключ в основната база данни.
USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';
Стъпка 2
Създайте сертификат, защитен с главния ключ.
CREATE CERTIFICATE TestCertificate WITH SUBJECT = 'My test Certificate';Стъпка 3
Създайте ключа за криптиране на базата данни (DEK) и го защитете със сертификата, създаден в стъпка 2.
USE test;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE TestCertificate;
Стъпка 4
Задайте „тестовата“ база данни да използва криптиране.
ALTER DATABASE test
SET ENCRYPTION ON;
Как да проверя дали TDE е активиран?
След като приключите, трябва да потвърдите, че прозрачното криптиране на данни в SQL Server е активирано за „тестовата“ база данни.
В Свойства на базата данни раздел, отидете на Опции страница. Там обърнете внимание наДържавата зона в долната част на прозореца. Шифроването е активирано стойността трябва да е True .
Можете също да изпълните следния TSQL код, за да го потвърдите:
SELECT name,is_encrypted
FROM sys.databases
WHERE name = 'test'
Проблем с управлението на ключове и сертифицирането
Забележка: Не се изненадвайте, ако разберете, че tempdb също е криптиран. Това е така, защото tempdb е мястото, където се извършват всички видове операции (например сортиране, хеш обединения и т.н.), като се използват данните от всички бази данни. Следователно, ако поне една потребителска база данни е криптирана, операциите от тази конкретна база данни може да отидат в tempdb, който ще трябва да върне тези данни в потребителската база данни. Следователно изпращането на некриптирани данни обратно би представлявало проблема.
Можете да прочетете повече за криптирането на архивиране в SQL Server, за да подобрите сигурността на вашата база данни.
Можете да използвате следния TSQL код, за да потвърдите, че има главен ключ на базата данни за „тестовата“ база данни, която е криптирана от сертификата (както се изпълнява в стъпка 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'
Дотук добре, поне за основната реплика. Но какво ще стане, ако потърсим sys.databases системен изглед, за да потвърдите състоянието на криптиране на „тестовата“ база данни във вторичната реплика?
Групата за наличност репликира всичко, свързано с базата данни, от една реплика в друга. Въпреки това, вторичната реплика ясно посочва, че не е криптирана.
Нека проверим нашата вторична реплика за някакви улики за това:
Състоянието на базата данни е „Не се синхронизира/Подозрително“ – изобщо не изглежда добре. Въпреки това, след проверка на регистрационния файл за грешки на вторичната реплика, мога да видя следното:
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.
Основният проблем е, че сертификатът, използван за криптиране на ключа за криптиране на базата данни на „тестовата“ база данни (стъпка 3), не присъства във вторичната реплика.
Защо?
Тъй като групите за наличност не репликират данни от системни бази данни. Липсващият сертификат на сървъра се намира в основната база данни на Primary Replica.
Как да проверите и настроите TDE сертификат в SQL Server
Нека генерираме резервно копие на сертификата на сървъра в основната база данни на Primary Replica. След това нека го възстановим в главната база данни на вторичната реплика.
Използвайте следния TSQL код, за да генерирате архива от текущата първична реплика, която има „тестовата“ база данни с активиран 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>');
Преди да се опитате да възстановите сертификата във вторичната реплика, първо проверете дали главният ключ на базата данни съществува в главната база данни. Ако не, създайте го точно както в стъпка 1.
Използвайте следния TSQL код, за да възстановите сертификата във вторичната реплика. Забележка :Не забравяйте първо да копирате .cer и .pvk файловете в целевата директория.
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>'
);
По този начин, дори след възстановяване на сертификата във вторичната реплика, състоянието на базата данни „тест“ остава същото:
Тъй като движението на данните за „тестовата“ база данни е поставено на пауза, нека го възобновим ръчно, за да видим дали този път имаме късмет:
Да! Операцията беше успешна. „Тестовата“ база данни е не само напълно синхронизирана и изправна, но и криптирана с TDE.
Освен това, след изпълнението на ръчното преминаване при отказ за размяна на ролите на репликите, всичко продължава да работи перфектно.
Заключение
Представеното решение работи перфектно. Въпреки това, може да не е идеално във всички случаи, особено ако сте DBA, който обича да планира и прави нещата по „правилния“ начин. Виждам „правилно“ както следва:
- Премахнете базата данни от групата за наличност
- Изпълнете всички стъпки, за да активирате прозрачно криптиране на данни в репликата, където базата данни се чете/записва.
- Архивирайте сертификата на сървъра от основната реплика.
- Копирайте архивния файл в местоположението(ата) на вторичното(ите) копие(а).
- Възстановете сертификата в основната база данни.
- Добавете базата данни обратно към групата за наличност.
- Уверете се, че работното състояние на базата данни е правилното и предвидено (в зависимост от конкретната ви настройка).
Хвърлям двойни кавички за „правилно“, защото по начина, по който представих решението, получих базата данни във вторичната реплика, маркирана като заподозрян. Само това вероятно би предизвикало много нежелани знамена/предупреждения/посочване с пръст. Това е ненужен шум, който можете лесно да избегнете, като вземете предвид всички съображения за планиране и правилно прилагане на TDE в настройка на Always On Availability Group.
За да завършим тази публикация, ви оставям с официалната йерархия на криптиране, използвана за TDE, която Microsoft е публикувала на своя уебсайт. Това, което бих искал да имате предвид, е къде се създава всеки елемент (в главната или в потребителската база данни), за да можете да преодолеете евентуални проблеми/изненади с групите за наличност.
В случай, че не сте наясно, SQL Complete може значително да ви помогне да конфигурирате Always Encrypted, което е друга полезна технология за защита на чувствителни данни.
Имайте предвид, че ще трябва да вземете предвид същото, което се обсъжда в тази статия, ако планирате да се справите със сценарий „Винаги шифровани“ в сценарий на групата за винаги на разположение. Въпреки това функциите, които въвежда SQL Complete v6.7, са предназначени да гарантират, че ще успеете веднага.
