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

Статья
04/15/2014

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

Функция прозрачного шифрования данных (TDE) выполняет в реальном времени шифрование и дешифрование файлов данных и журналов в операциях ввода-вывода. При шифровании используется ключ шифрования базы данных (DEK), который хранится в загрузочной записи базы данных для доступности при восстановлении. Ключ шифрования базы данных является симметричным ключом, защищенным сертификатом, который хранится в базе данных master на сервере, или асимметричным ключом, защищенным модулем расширенного управления ключами. Функция прозрачного шифрования данных защищает «неактивные» данные, то есть файлы данных и журналов. Она дает возможность обеспечивать соответствие требованиям многих законов, постановлений и рекомендаций, действующих в разных отраслях. Это позволяет разработчикам программного обеспечения шифровать данные с помощью алгоритмов шифрования AES и 3DES, не меняя существующие приложения.

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

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

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

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

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

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

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

Показывает иерархию, описанную в этом разделе.

Использование прозрачного шифрования данных

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

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

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

USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';
go
CREATE CERTIFICATE MyServerCert WITH SUBJECT = 'My DEK Certificate';
go
USE AdventureWorks2012;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_128
ENCRYPTION BY SERVER CERTIFICATE MyServerCert;
GO
ALTER DATABASE AdventureWorks2012
SET ENCRYPTION ON;
GO

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

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

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

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

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

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

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

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

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

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

Представление каталога или динамическое административное представление	Назначение
sys.databases (Transact-SQL)	Представление каталога со сведениями о базе данных.
sys.certificates (Transact-SQL)	Представление каталога с сертификатами из базы данных.
sys.dm_database_encryption_keys (Transact-SQL)	Динамическое административное представление со сведениями о ключах шифрования, используемых в базе данных, и состоянии шифрования базы данных.

Разрешения

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

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

Замечания

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

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

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

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

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

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

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

Ограничения

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

удаление файла из файловой группы в базе данных;
удаление базы данных;
перевод базы данных в режим «вне сети»;
отсоединение базы данных;
перевод базы данных или файловой группы в состояние 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.

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

Прозрачное шифрование данных и журналы транзакций

Включение TDE в базе данных приводит к «обнулению» оставшейся части виртуального журнала транзакций и принудительному началу нового виртуального журнала транзакций. Это гарантирует, что после включения шифрования базы данных в журналах транзакций не останется простого текста. Состояние шифрования файла журнала можно определить, просмотрев столбец encryption_state в представлении sys.dm_database_encryption_keys, как показано в примере:

USE AdventureWorks2012;
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 см. в разделе Журнал транзакций (SQL Server).

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

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

Прозрачное шифрование данных и системная база данных tempdb

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

Прозрачное шифрование данных и репликация

Репликация данных не выполняется автоматически в зашифрованном виде из базы данных с включенным TDE. Необходимо отдельно включить TDE, если нужно защитить базы данных распространителя и подписчика. При репликации моментальных снимков и начальном распределении данных для репликации транзакций и репликации слиянием данные могут храниться в незашифрованных промежуточных файлах, например файлах BCP. Во время репликации транзакций или репликации слиянием шифрование можно включить для защиты каналов связи. Дополнительные сведения см. в разделе Включение шифрования соединений в ядре СУБД (диспетчер конфигурации SQL Server).