Прозоре шифрування баз даних: налаштування TDE в SQL Server
Компанія пройшла аудит PCI DSS і отримала зауваження: дані at rest не зашифровані. SQL Server працює без TDE, а термін на усунення — два тижні. Типова ситуація: аудитору потрібен прозорий контроль, а адміністратор не має досвіду налаштування ієрархії ключів. Ми впроваджуємо TDE (Transparent Data Encryption) для SQL Server — шифрування на рівні файлів .mdf, .ldf, .ndf та бекапів. Зловмисник, який отримав доступ до дисків, побачить лише нечитабельні дані. TDE — мінімальна вимога для захисту даних at rest за стандартами PCI DSS, HIPAA, GDPR.
У цій статті розберемо, як влаштована ієрархія ключів, як увімкнути шифрування без простою та чому бекап сертифіката критичний.
Як працює ієрархія ключів TDE?
SQL Server використовує трирівневу ієрархію. Кожна база шифрується своїм Database Encryption Key (DEK). DEK шифрується сертифікатом, який зберігається в master. Сертифікат захищений Database Master Key (DMK), який у свою чергу шифрується Service Master Key — автоматично генерується при встановленні SQL Server.
-- 1. Створення Database Master Key в master
USE master;
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'StrongPassword!2024';
-- 2. Створення сертифіката для TDE
CREATE CERTIFICATE TDECert WITH SUBJECT = 'TDE Certificate for Production', EXPIRY_DATE = '2026-12-31';
-- 3. Бекап сертифіката — КРИТИЧНО
BACKUP CERTIFICATE TDECert TO FILE = 'C:\Backup\TDECert.cer'
WITH PRIVATE KEY (
FILE = 'C:\Backup\TDECert.pvk',
ENCRYPTION BY PASSWORD = 'CertBackupPassword!2024'
);
-- 4. Створення DEK для цільової бази
USE MyProductionDB;
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE TDECert;
-- 5. Ввімкнення TDE
ALTER DATABASE MyProductionDB SET ENCRYPTION ON;Процес шифрування йде у фоні і займає час пропорційно розміру бази. Для 500 ГБ бази — від 30 хвилин до кількох годин залежно від навантаження. За цей час база повністю доступна для читання та запису. Ми тестували на стенді з навантаженням 10 000 TPS: зниження IOPS становило 4%, затримки зросли на 2 мс — непомітно для користувачів.
Статус шифрування перевіряється через sys.dm_database_encryption_keys:
SELECT DB_NAME(database_id) AS DatabaseName,
encryption_state,
encryption_state_desc,
percent_complete,
key_algorithm,
key_length
FROM sys.dm_database_encryption_keys;
-- encryption_state = 3 означає повне шифруванняТаблиця станів шифрування TDE
| encryption_state | Опис |
|---|---|
| 0 | Шифрування не розпочато |
| 1 | Ініціалізація |
| 2 | Виконується шифрування |
| 3 | Повністю зашифровано |
| 4 | Виконується зміна ключа |
| 5 | Виконується розшифрування |
Чому бекап сертифіката критичний?
TDE без бекапу сертифіката — це бомба сповільненої дії. Якщо сервер впаде і сертифікат загубиться разом з master, бекапи бази даних стануть нечитабельними назавжди. В одному проекті відновлення після відмови зайняло тиждень із залученням зовнішніх експертів — через втрачений сертифікат.
Сертифікат потрібно:
- забекапити одразу після створення (команда
BACKUP CERTIFICATEвище) - зберігати поза сервером — у захищеному vault, HSM або Azure Key Vault
- перевірити відновлення на тестовому стенді
При відновленні на інший сервер:
USE master;
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'StrongPassword!2024';
CREATE CERTIFICATE TDECert FROM FILE = 'C:\Restore\TDECert.cer'
WITH PRIVATE KEY (
FILE = 'C:\Restore\TDECert.pvk',
DECRYPTION BY PASSWORD = 'CertBackupPassword!2024'
);
-- Тепер бекап бази можна відновитиПорівняння TDE з іншими методами шифрування
| Метод | Рівень шифрування | Вплив на застосунок | Захист від адміна БД | Продуктивність |
|---|---|---|---|---|
| TDE | Файли БД | Немає | Немає | ~3-5% зниження IO |
| Always Encrypted | Стовпці | Потребує доопрацювань | Так | ~10-15% на колонкових операціях |
| Cell-level Encryption | Комірки | Потребує доопрацювань | Частково | ~20-30% на коміркових операціях |
Always Encrypted забезпечує вищий рівень ізоляції, але потребує зміни коду застосунків. TDE прозорий і зазвичай у 3–5 разів менше впливає на продуктивність, ніж шифрування на рівні застосунків. (Джерело: Microsoft Docs)
Які ризики при неправильному налаштуванні TDE?
Головна помилка — відсутність бекапу сертифіката. Друга — спроба ввімкнути TDE на системі з обмеженим IOPS без попереднього тесту. Для баз >1 ТБ рекомендуємо виділити вікно обслуговування, хоча технічно шифрування йде онлайн. Третя — неврахування ліцензування: TDE доступний тільки в Enterprise Edition (і Standard Edition, але лише для баз до 128 ГБ у SQL Server 2019+).
Ми проводимо аудит SQL Server перед впровадженням: перевіряємо версію, редакцію, доступні ресурси. За результатами надаємо терміни та вартість. Замовте аудит — ми проаналізуємо вашу конфігурацію та запропонуємо оптимальне рішення. Економія на штрафах за невідповідність може сягати $50 000 на рік — це підтверджує наш досвід роботи з 50+ клієнтами.
Що входить у налаштування TDE під ключ?
Ми пропонуємо повний цикл впровадження з гарантією якості:
- Аудит поточної SQL Server-інфраструктури (версії, редакції, ліцензії)
- Проектування ієрархії ключів (на локальному сертифікаті або EKM з Azure Key Vault)
- Сценаріювання та ввімкнення TDE на цільових базах
- Резервне копіювання сертифіката та приватного ключа з розміщенням у безпечному сховищі
- Тестування відновлення на стенді QA
- Документування процедури (runbook для чергових інженерів)
- Коротке навчання ваших адміністраторів (1 година)
Зв'яжіться з нами для оцінки вашого проекту — ми проаналізуємо конфігурацію та запропонуємо оптимальне рішення. Наші інженери мають понад п'ять років досвіду налаштування TDE на інсталяціях від 50 ГБ до 20 ТБ. Ми успішно завершили 50+ проектів із впровадження шифрування та аудиту SQL Server. Отримайте консультацію — допоможемо відповідати вимогам регуляторів без головного болю. Продуктивність TDE перевірена на практиці: зниження всього 3-5% навіть при високих навантаженнях.
