Шифрование MS SQL Server TDE: настройка и управление ключами
Компания прошла аудит 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 раз меньше влияет на производительность, чем шифрование на уровне приложений.
Какие риски при неверной настройке TDE?
Главная ошибка — отсутствие бэкапа сертификата. Вторая — попытка включить TDE на системе с ограниченным IOPS без предварительного теста. Для баз >1 ТБ рекомендуем выделить окно обслуживания, хотя технически шифрование идёт онлайн. Третья — неучёт лицензирования: TDE доступен только в Enterprise Edition (и Standard Edition, но только для баз до 128 ГБ в SQL Server 2019+).
Мы проводим аудит перед внедрением: проверяем версию, редакцию, доступные ресурсы. По результатам выдаём сроки и стоимость. Закажите аудит — мы проанализируем вашу конфигурацию и предложим оптимальное решение.
Что входит в настройку TDE под ключ?
Мы предлагаем полный цикл внедрения:
- Аудит текущей SQL Server-инфраструктуры (версии, редакции, лицензии)
- Проектирование иерархии ключей (на локальном сертификате или EKM с Azure Key Vault)
- Скриптирование и включение TDE на целевых базах
- Резервное копирование сертификата и приватного ключа с размещением в безопасном хранилище
- Тестирование восстановления на стенде QA
- Документирование процедуры (runbook для дежурных инженеров)
- Краткое обучение ваших администраторов (1 час)
Свяжитесь с нами для оценки вашего проекта — мы проанализируем конфигурацию и предложим оптимальное решение. Наши инженеры имеют более пяти лет опыта настройки TDE на инсталляциях от 50 ГБ до 20 ТБ. Мы успешно завершили 50+ проектов по внедрению шифрования и аудиту SQL Server. Получите консультацию — поможем соответствовать требованиям регуляторов без головной боли.
