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

Применимо к:SQL Server База данных SQL Azure Управляемый экземпляр SQL Azure Azure Synapse Analytics AnalyticsPlatform System (PDW)

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

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

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

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

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

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

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

Примечание.

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

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

См. также:

Сведения о прозрачном шифровании данных (TDE)

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

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

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

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

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

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

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

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

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

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

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

Diagram showing the transparent data encryption architecture.

Включение TDE

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

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

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

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

USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';
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 также шифруются с помощью DEK. В результате при восстановлении этих резервных копий сертификат, который защищает DEK, должен быть доступен. Следовательно, в дополнение к резервному копированию базы данных обязательно сохраняйте резервные копии сертификатов сервера. Если сертификат станет недоступным, это приведет к потере данных.

Дополнительные сведения см. в статье SQL Server Certificates and Asymmetric Keys.

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

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

Важно!

Если защищать сертификаты паролем после того, как TDE использует их, база данных станет недоступной после перезагрузки.

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

Команда или функция Характер использования
CREATE DATABASE ENCRYPTION KEY Создает ключ, который шифрует базу данных.
ALTER DATABASE ENCRYPTION KEY Изменяет ключ, который шифрует базу данных.
DROP DATABASE ENCRYPTION KEY Удаляет ключ, который шифрует базу данных.
Параметры ALTER DATABASE SET Объясняет параметр, используемый ALTER DATABASE для включения TDE

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

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

Представление каталога или динамическое административное представление Характер использования
sys.databases Представление каталога со сведениями о базе данных
sys.certificates Представление каталога с сертификатами из базы данных
sys.dm_database_encryption_keys Динамическое административное представление со сведениями о ключах шифрования базы данных и состоянии шифрования базы данных

Разрешения

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

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

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

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

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

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

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

Важно!

Полнотекстовые индексы будут шифроваться после включения шифрования базы данных. Такие индексы, созданные в SQL Server 2005 (9.x) и более ранних версиях, импортируются в базу данных SQL Server 2008 (10.0.x) и более поздних версий и шифруются TDE.

Совет

Чтобы отслеживать изменения состояния TDE базы данных, используйте аудит SQL Server или База данных SQL Azure аудит. Для SQL Server TDE отслеживается в группе DATABASE_OBJECT_CHANGE_GROUPдействий аудита, которую можно найти в группах действий и действиях аудита SQL Server.

Ограничения

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

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

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

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

Следующие операции или условия препятствуют выполнению инструкций CREATE DATABASE ENCRYPTION KEY, ALTER DATABASE ENCRYPTION KEYDROP 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 в настоящее время недоступна в База данных SQL Azure, Управляемый экземпляр SQL Azure и Azure Synapse Analytics.

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

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

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

Журналы транзакций можно отслеживать с помощью sys.dm_db_log_info DMV, который также показывает, зашифрован ли файл журнала или не использует vlf_encryptor_thumbprint столбец, доступный в SQL Azure, и 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.

Важно!

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

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

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

TDE и выполняющаяся в памяти OLTP

Прозрачное шифрование данных можно включить в базе данных, которая содержит объекты 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 c
INNER JOIN sys.dm_database_encryption_keys dek
    ON c.thumbprint = dek.encryptor_thumbprint;

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