Прозрачное шифрование данных (TDE)

Область применения:SQL ServerБаза данных SQL AzureУправляемый экземпляр SQL AzureAzure Synapse Analytics

Прозрачное шифрование данных (TDE) шифрует файлы данных SQL Server, База данных SQL Azure и Azure Synapse Analytics. Это так называемое шифрование неактивных данных.

Чтобы обеспечить безопасность пользовательской базы данных, можно предпринять такие меры предосторожности, как:

• Разработка безопасной системы.
• Шифрование конфиденциальных ресурсов.
• Создание брандмауэра вокруг серверов баз данных.

Однако злоумышленник, который украл физические носители, такие как диски или лента резервного копирования, может восстановить или подключить базу данных и просмотреть свои данные.

Одним из решений может стать шифрование конфиденциальных данных в базе данных и использование сертификата для защиты ключей шифрования данных. Таким образом, пользователи без ключей не смогут использовать эти данные. Но этот тип защиты необходимо запланировать заранее.

TDE выполняет шифрование и дешифрование операций ввода-вывода в реальном времени для файлов данных и файлов журналов. Шифрование использует ключ шифрования базы данных (DEK). Загрузочная запись базы данных хранит ключ для доступности во время восстановления. DEK — это симметричный ключ, защищенный сертификатом, который хранится в базе данных сервера master или асимметричным ключом, защищенным модулем EKM.

TDE защищает данные в состоянии покоя, то есть файлы данных и журналов транзакций. Благодаря ей обеспечивается соответствие требованиям различных законов, постановлений и рекомендаций, действующих в разных отраслях. Это позволяет разработчикам программного обеспечения шифровать данные с помощью алгоритмов шифрования AES и 3DES, не меняя существующие приложения.

TDE не обеспечивает шифрование данных в каналах связи. Дополнительные сведения о том, как шифровать данные между каналами связи, см. в статье "Шифрование подключений к SQL Server путем импорта сертификата".

См. также:

• Прозрачное шифрование данных для Базы данных SQL, Управляемого экземпляра SQL и Azure Synapse Analytics
• Начало работы с прозрачным шифрованием данных (TDE) в Azure Synapse Analytics
• Перемещение защищенной базы данных TDE в другой SQL Server
• Включение TDE в SQL Server с помощью EKM
• Использование соединителя SQL Server с компонентами шифрования SQL
• Блог по безопасности SQL Server в TDE с вопросами и ответами

О TDE

Шифрование файлов базы данных выполняется на уровне страницы. Страницы в зашифрованной базе данных шифруются до записи на диск и дешифруются при чтении в память. TDE не увеличивает объём зашифрованной базы данных.

Сведения, применимые к База данных SQL

При использовании TDE в Базе данных SQL Azure База данных SQL автоматически создаёт сертификат уровня сервера, хранящийся в базе данных master. Чтобы переместить базу данных с TDE в SQL Database, не нужно расшифровывать её перед перемещением. Дополнительные сведения об использовании TDE с SQL Database см. в статье прозрачное шифрование данных в База данных SQL Azure.

Сведения, применимые к SQL Server

После защиты базы данных ее можно восстановить с помощью правильного сертификата. Дополнительные сведения о сертификатах см. в разделе SQL Server Certificates and Asymmetric Keys.

После включения TDE немедленно создайте резервную копию сертификата и связанного с ним закрытого ключа. Если сертификат становится недоступным или вы восстанавливаете или подключаете базу данных на другом сервере, вам потребуются резервные копии сертификата и закрытого ключа. В противном случае вы не сможете открыть базу данных. Сертификаты, хранящиеся в автономной системной базе данных , также должны быть резервированы.

Сохраните сертификат для шифрования, даже если вы отключили TDE для базы данных. Несмотря на то что база данных не зашифрована, части журнала транзакций могут оставаться защищенными. Вам также может потребоваться сертификат для некоторых операций, пока не будет выполнено полное резервное копирование базы данных.

Вы по-прежнему можете использовать сертификат, срок действия которого истёк, для шифрования и расшифровки данных с помощью TDE.

Иерархия средств шифрования

API защиты данных Windows (DPAPI) находится в корне дерева шифрования, защищает иерархию ключей на уровне компьютера и используется для защиты главного ключа службы (SMK) для экземпляра сервера базы данных. SMK защищает главный ключ базы данных (DMK), который хранится на уровне пользовательской базы данных и защищает сертификаты и асимметричные ключи. Эти ключи, в свою очередь, защищают симметричные ключи, которые защищают данные. TDE использует аналогичную иерархию до сертификата. При использовании TDE dmK и сертификат должны храниться в master базе данных. Новый ключ, используемый только для TDE и называемый ключом шифрования базы данных (DEK), создается и хранится в пользовательской базе данных.

На следующем рисунке показана архитектура шифрования TDE. Только элементы на уровне базы данных (ключ шифрования базы данных и компоненты ALTER DATABASE) могут настраиваться пользователем при использовании TDE в SQL Database.

Включение TDE

Чтобы использовать TDE, выполните следующие действия.

Область применения: SQL Server.

1. Создайте главный ключ.
2. Создайте или получите сертификат, защищенный главным ключом.
3. Создайте ключ шифрования базы данных и защитите его с помощью сертификата.
4. Задайте шифрование базы данных.

В следующем примере демонстрируется шифрование и дешифрование базы данных AdventureWorks2025 с помощью сертификата с именем MyServerCert, установленного на сервере.

USE master;
GO

CREATE MASTER KEY ENCRYPTION BY PASSWORD= '<password>';
GO

CREATE CERTIFICATE MyServerCert
    WITH SUBJECT = 'My DEK Certificate';
GO

USE AdventureWorks2022;
GO

CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256
    ENCRYPTION BY SERVER CERTIFICATE MyServerCert;
GO

ALTER DATABASE AdventureWorks2022
    SET ENCRYPTION ON;
GO

SQL Server планирует операции шифрования и расшифровки для выполнения в фоновых потоках. Состояние этих операций можно просмотреть в представлениях каталога и динамических административных представлениях в таблице далее в этой статье.

Команды и функции

Чтобы использовать следующие инструкции для приема сертификатов TDE, используйте главный ключ базы данных для шифрования. Если они зашифрованы только паролем, то они будут отклонены инструкциями как шифраторы.

В следующей таблице представлены ссылки и объяснения команд и функций TDE.

Представления каталога и динамические административные представления

В следующей таблице показаны представления каталога TDE и динамические административные представления (DMV).

Разрешения

Для каждой функции или команды TDE действуют отдельные требования к разрешениям, описанные в таблицах выше.

Для просмотра метаданных, связанных с TDE, требуется VIEW DEFINITION разрешение на сертификат.

Рекомендации

Во время проверки базы данных на повторное шифрование, выполняемой для операции шифрования, операции обслуживания базы данных отключаются. Для выполнения операции обслуживания базы данных можно использовать однопользовательский режим. Дополнительные сведения см. в разделе "Настройка базы данных в однопользовательском режиме".

Используйте динамическое sys.dm_database_encryption_keys представление управления, чтобы найти состояние шифрования базы данных. Дополнительные сведения см. в разделе "Представления каталога" и "Динамические административные представления " выше в этой статье.

В режиме TDE все файлы и файловые группы зашифрованы. Если любая файловая группа в базе данных помечена READ ONLY, операция шифрования базы данных завершается ошибкой.

Если база данных используется в зеркальном отображении базы данных или в доставке журналов, то зашифрованы будут обе базы данных. Транзакции журналов при передаче между ними будут передаваться в зашифрованном виде.

Ограничения

При первом шифровании базы данных, изменении ключа или дешифровании базы данных не допускаются следующие операции:

• удаление файла из файловой группы в базе данных;
• удаление базы данных;
• Перевод базы данных в автономный режим
• отсоединение базы данных;
• Перевод базы данных или файловой группы в состояние READ ONLY

Следующие операции запрещены в следующих операторах: CREATE DATABASE ENCRYPTION KEY, ALTER DATABASE ENCRYPTION KEY, DROP DATABASE ENCRYPTION KEY и ALTER DATABASE...SET ENCRYPTION.

• удаление файла из файловой группы в базе данных;
• удаление базы данных;
• Перевод базы данных в автономный режим
• отсоединение базы данных;
• Перевод базы данных или файловой группы в состояние READ ONLY
• Использование команды ALTER DATABASE
• запуск резервного копирования базы данных или файла базы данных;
• запуск восстановления базы данных или файла базы данных;
• Создание снимка

Следующие операции или условия не допускают использование операторов CREATE DATABASE ENCRYPTION KEY, ALTER DATABASE ENCRYPTION KEY, DROP DATABASE ENCRYPTION KEY и ALTER DATABASE...SET ENCRYPTION:

• база данных предназначена только для чтения или в ней есть файловые группы, доступные только для чтения;
• Выполняется команда ALTER DATABASE.
• выполняется операция резервного копирования;
• База данных находится в автономном режиме или в режиме восстановления.
• идет создание моментального снимка;
• выполняется задача обслуживания базы данных.

При создании файлов базы данных быстрая инициализация файлов недоступна при включенном TDE.

Чтобы зашифровать DEK с асимметричным ключом, асимметричный ключ должен находиться в расширяемом поставщике управления ключами.

Сканирование TDE

Чтобы включить TDE в базе данных, SQL Server должен выполнить проверку шифрования. Проверка считывает каждую страницу из файлов данных в буферный пул, а затем записывает зашифрованные страницы обратно на диск.

Чтобы обеспечить более широкий контроль над проверкой шифрования, SQL Server 2019 (15.x) представляет проверку TDE, которая имеет синтаксис приостановки и возобновления. Вы можете приостановить сканирование, когда рабочая нагрузка в системе будет очень высокой или в течение критически важного для бизнеса периода, а затем возобновить сканирование позже.

Чтобы приостановить сканирование шифрования TDE, используйте следующий синтаксис:

ALTER DATABASE <db_name> SET ENCRYPTION SUSPEND;

Подобным образом вы можете возобновить сканирование шифрования TDE с помощью следующего синтаксиса:

ALTER DATABASE <db_name> SET ENCRYPTION RESUME;

Столбец encryption_scan_state добавлен в динамическое sys.dm_database_encryption_keys представление управления. Он показывает текущее состояние сканирования шифрования. Кроме того, появился столбец encryption_scan_modify_date, который содержит дату и время последнего изменения состояния сканирования шифрования.

Если экземпляр SQL Server перезапускается во время приостановки проверки шифрования, во время запуска в журнал ошибок регистрируется сообщение. Сообщение указывает, что существующее сканирование приостановлено.

TDE и журналы транзакций

TDE защищает хранимые файлы данных и файлы журналов. Шифрование всей базы данных после включения TDE для ранее незашифрованной базы данных — это масштабная операция с данными, и время, которое она занимает, зависит от системных ресурсов, на которых работает эта база данных. Для определения состояния шифрования базы данных можно использовать sys.dm_database_encryption_keys DMV.

При включении TDE ядро СУБД принудительно создает новый журнал транзакций, который будет зашифрован ключом шифрования базы данных. Любой журнал, созданный предыдущими транзакциями или текущими длительными транзакциями, чередуемыми между изменением состояния TDE, не шифруется.

Журнал транзакций можно отслеживать с помощью DMV sys.dm_db_log_info, которое также показывает, зашифрован ли файл журнала, с помощью столбца vlf_encryptor_thumbprint, доступного в Azure SQL и SQL Server 2019 (15.x) и более поздних версиях. Чтобы найти состояние шифрования файла журнала с помощью encryption_state столбца в sys.dm_database_encryption_keys представлении, ниже приведен пример запроса:

USE AdventureWorks2022;
GO

/* The value 3 represents an encrypted state
   on the database and transaction logs. */
SELECT *
FROM sys.dm_database_encryption_keys
WHERE encryption_state = 3;
GO

Дополнительные сведения об архитектуре файла журнала SQL Server см. в разделе Журнал транзакций.

Перед изменением DEK предыдущий DEK шифрует все данные, записанные в журнал транзакций.

При двойном изменении deK необходимо создать резервную копию журнала, прежде чем снова изменить deK.

TDE и системная база данных tempdb

Системная tempdb база данных шифруется, если любая другая база данных в экземпляре SQL Server шифруется с помощью TDE. Это может влиять на производительность незашифрованных баз данных в том же экземпляре SQL Server. Дополнительные сведения о системной базе данных tempdbсм. в статье База данных tempdb.

TDE и репликация

При репликации данные из базы данных с включённым TDE не реплицируются автоматически в зашифрованном виде. Необходимо отдельно включить TDE, если нужно защитить базы данных распространителя и подписчика.

Репликация моментальных снимков может хранить данные в незашифрованных промежуточных файлах, таких как BCP-файлы. Это также возможно для начального распределения данных при транзакционной репликации и репликации слиянием. Во время такой репликации можно включить шифрование для защиты канала связи.

Дополнительные сведения см. в статье "Шифрование подключений к SQL Server путем импорта сертификата".

TDE и группы доступности

Вы можете добавить зашифрованную базу данных в группу доступности Always On.

Чтобы зашифровать базы данных, которые входят в группу доступности, создайте главный ключ и сертификаты или асимметричный ключ (EKM) во всех вторичных репликах перед созданием ключа шифрования базы данных на первичной реплике.

Если сертификат используется для защиты DEK, создайте резервную копию сертификата, созданного на первичной реплике, а затем создайте сертификат из файла на всех вторичных репликах перед созданием DEK на первичной реплике.

TDE и данные FILESTREAM

Данные FILESTREAM не шифруются, даже если включить TDE.

TDE и резервные копии

Сертификаты обычно используются в технологии прозрачного шифрования данных для защиты DEK. Сертификат должен быть создан в master базе данных. Резервные копии баз данных с включенным TDE также шифруются с помощью DEK. В результате при восстановлении из этих резервных копий сертификат, защищенный DEK, должен быть доступен. Это означает, что помимо резервного копирования базы данных необходимо поддерживать резервные копии сертификатов сервера, чтобы предотвратить потерю данных. Потеря данных возникает, если сертификат больше недоступен.

Удалить TDE

Удалите шифрование из базы данных с помощью инструкции ALTER DATABASE.

ALTER DATABASE <db_name> SET ENCRYPTION OFF;

Состояние базы данных можно просмотреть с помощью динамического административного представления sys.dm_database_encryption_keys.

Дождитесь завершения расшифровки перед удалением DEK с помощью DROP DATABASE ENCRYPTION KEY.

TDE и расширение буферного пула

Если вы шифруете базу данных с помощью TDE, файлы, касающиеся расширения буферного пула (BPE), не шифруются. Для этих файлов используйте средства шифрования на уровне файловой системы, такие как BitLocker или файловая система EFS.

TDE и OLTP в памяти

Вы можете включить TDE (прозрачное шифрование данных) для базы данных, содержащей объекты In-Memory OLTP. В SQL Server 2016 (13.x) и База данных SQL Azure записи журналов OLTP в памяти и данные шифруются при включении TDE. В SQL Server 2014 (12.x) записи журнала OLTP в памяти шифруются, если включить TDE, но файлы в файловой MEMORY_OPTIMIZED_DATA группе не шифруются.

Рекомендации по управлению сертификатами, используемыми в TDE

Необходимо создать резервную копию сертификата и главного ключа базы данных, если база данных включена для TDE и используется в доставке журналов или зеркальном отображении базы данных. Сертификаты, хранящиеся в автономной системной базе данных, также должны быть резервированы.

Сертификат, используемый для защиты DEK, никогда не должен быть удален из master базы данных. Это приводит к недоступности зашифрованной базы данных.

Сообщение, подобное следующему (ошибка 33091), появляется после выполнения CREATE DATABASE ENCRYPTION KEY, если сертификат, используемый в команде, еще не был сохранен в резервной копии.

Следующий запрос можно использовать для выявления сертификатов, используемых в TDE, резервные копии которых не создавались с момента их создания.

SELECT pvt_key_last_backup_date,
       Db_name(dek.database_id) AS encrypteddatabase,
       c.name AS Certificate_Name
FROM sys.certificates AS c
     INNER JOIN sys.dm_database_encryption_keys AS dek
         ON c.thumbprint = dek.encryptor_thumbprint;

Если столбец pvt_key_last_backup_date имеет значение NULL, то для базы данных, соответствующей этой строке, включено TDE, но для сертификата, используемого для защиты ее ключа шифрования базы данных (DEK), не была создана резервная копия. Дополнительные сведения о резервном копировании сертификата см. в статье BACKUP CERTIFICATE.

Связанный контент

• Безопасность ядра СУБД SQL Server и базы данных Azure SQL
• FILESTREAM (SQL Server)
• Шифрование SQL Server
• SQL Server и ключи шифрования базы данных (компонент ядро СУБД)