прозрачное шифрование данных.

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

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

Важно!

TDE не предоставляет шифрование для перемещения данных между клиентом и PDW. Дополнительные сведения о том, как шифровать данные между клиентом и SQL Server PDW, см. в разделе "Подготовка сертификата".

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

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

Примечание.

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

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

На следующем рисунке показана иерархия ключей для шифрования TDE:

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

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

1. Создайте главный ключ в базе данных master.

2. Используйте sp_pdw_database_encryption для включения TDE в PDW SQL Server. Эта операция изменяет временные базы данных, чтобы обеспечить защиту будущих временных данных и завершится ошибкой при попытке при наличии активных сеансов с временными таблицами. sp_pdw_database_encryption включает маскирование данных пользователей в системных журналах PDW. (Дополнительные сведения о маскировке данных пользователей в системных журналах PDW см. в sp_pdw_log_user_data_masking.)

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

4. В базе данных master создайте сертификат, защищенный главным ключом.

5. Резервное копирование сертификата в общую папку хранения.

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

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

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

Сначала включите TDE в PDW SQL Server. Это действие необходимо только один раз.

USE master;  
GO  
  
-- Create a database master key in the master database  
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';  
GO  
  
-- Enable encryption for PDW  
EXEC sp_pdw_database_encryption 1;  
GO  
  
-- Add a credential that can write to the share  
-- A credential created for a backup can be used if you wish  
EXEC sp_pdw_add_network_credentials 'SECURE_SERVER', '<domain>\<Windows_user>', '<password>';  

Во-вторых: создание и резервное копирование сертификата в базе данных master. Это действие требуется только один раз. Вы можете иметь отдельный сертификат для каждой базы данных (рекомендуется) или защитить несколько баз данных с помощью одного сертификата.

-- Create certificate in master  
CREATE CERTIFICATE MyServerCert WITH SUBJECT = 'My DEK Certificate';  
GO  
  
-- Back up the certificate with private key  
BACKUP CERTIFICATE MyServerCert   
    TO FILE = '\\SECURE_SERVER\cert\MyServerCert.cer'  
    WITH PRIVATE KEY   
    (   
        FILE = '\\SECURE_SERVER\cert\MyServerCert.key',  
        ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>'   
    )   
GO  

Последнее: создайте deK и используйте ALTER DATABASE для шифрования пользовательской базы данных. Это действие повторяется для каждой базы данных, защищенной TDE.

USE AdventureWorksPDW2012;  
GO  
  
CREATE DATABASE ENCRYPTION KEY  
WITH ALGORITHM = AES_128  
ENCRYPTION BY SERVER CERTIFICATE MyServerCert;  
GO  
  
ALTER DATABASE AdventureWorksPDW2012 SET ENCRYPTION ON;  
GO  

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

Внимание

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

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

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

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

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

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

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

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

Разрешения

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

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

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

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

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

Ограничения

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

• Удаление базы данных.

• ALTER DATABASE Использование команды.

• Запуск резервной копии базы данных.

• Запуск восстановления базы данных.

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

• Выполняется ALTER DATABASE команда.

• выполняется какая-либо операция резервного копирования;

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

Области, не защищенные TDE

TDE не защищает внешние таблицы.

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

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

База данных master не защищена TDE. Хотя база данных master не содержит пользовательских данных, она содержит такие сведения, как имена входа.

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

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

WITH dek_encryption_state AS   
(  
    SELECT ISNULL(db_map.database_id, dek.database_id) AS database_id, encryption_state  
    FROM sys.dm_pdw_nodes_database_encryption_keys AS dek  
        INNER JOIN sys.pdw_nodes_pdw_physical_databases AS node_db_map  
           ON dek.database_id = node_db_map.database_id AND dek.pdw_node_id = node_db_map.pdw_node_id  
        LEFT JOIN sys.pdw_database_mappings AS db_map  
            ON node_db_map .physical_name = db_map.physical_name  
        INNER JOIN sys.dm_pdw_nodes AS nodes  
            ON nodes.pdw_node_id = dek.pdw_node_id  
    WHERE dek.encryptor_thumbprint <> 0x  
)  
SELECT TOP 1 encryption_state  
       FROM dek_encryption_state  
       WHERE dek_encryption_state.database_id = DB_ID('AdventureWorksPDW2012 ')  
       ORDER BY (CASE encryption_state WHEN 3 THEN -1 ELSE encryption_state END) DESC;  

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

Журналы действий PDW

SQL Server PDW поддерживает набор журналов, предназначенных для устранения неполадок. (Обратите внимание, что это не журнал транзакций, журнал ошибок SQL Server или журнал событий Windows.) Эти журналы действий PDW могут содержать полные инструкции в виде четкого текста, некоторые из которых могут содержать пользовательские данные. Типичными примерами являются инструкции INSERT и UPDATE . Маскирование пользовательских данных можно явно включить или отключить с помощью sp_pdw_log_user_data_masking. Включение шифрования в SQL Server PDW автоматически включает маскирование данных пользователей в журналах действий PDW, чтобы защитить их. sp_pdw_log_user_data_masking также можно использовать для маскирования инструкций при не использовании TDE, но это не рекомендуется, так как это значительно снижает способность команды служба поддержки Майкрософт анализировать проблемы.

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

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

Управление ключами

Ключ шифрования базы данных (DEK) защищен сертификатами, хранящимися в базе данных master. Эти сертификаты защищены главным ключом базы данных (DMK) базы данных master. DmK должен быть защищен главным ключом службы (SMK), чтобы использовать для TDE.

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

При перемещении базы данных из одной (модуль) в другую сертификат, используемый для защиты его deK, необходимо сначала восстановить на целевом сервере. Затем базу данных можно восстановить как обычно. Дополнительные сведения см. в стандартной документации ПО SQL Server на странице "Перемещение защищенной базы данных TDE на другой SQL Server".

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

Восстановление базы данных master

Базу данных master можно восстановить с помощью DWConfig в рамках аварийного восстановления.

• Если узел управления не изменился, то есть если база данных master восстанавливается в одной и той же и неизменной (модуль), из которой была выполнена резервная копия базы данных master, dmK и все сертификаты будут доступны для чтения без дополнительных действий.

• Если база данных master восстанавливается в другой (модуль) или если узел управления был изменен с момента резервной копии базы данных master, для повторного создания интеллектуального анализа данных потребуется выполнить дополнительные действия.

  1. Откройте DMK:

     OPEN MASTER KEY DECRYPTION BY PASSWORD = '<password>';  
     

  2. Добавьте шифрование с помощью SMK:

     ALTER MASTER KEY   
         ADD ENCRYPTION BY SERVICE MASTER KEY;  
     

  3. Перезапустите устройство.

Обновление и замена Виртуальные машины

Если dmK существует на (модуль), на которой выполнено обновление или замена виртуальной машины, в качестве параметра необходимо указать пароль DMK.

Пример действия обновления. Замените ********** паролем DMK.

setup.exe /Action=ProvisionUpgrade ... DMKPassword='**********'

Пример действия для замены виртуальной машины.

setup.exe /Action=ReplaceVM ... DMKPassword='**********'

При обновлении, если пользовательская база данных зашифрована и пароль DMK не указан, действие обновления завершится ошибкой. При замене, если правильный пароль не указан при наличии dmK, операция пропустит шаг восстановления DMK. Все остальные шаги будут выполнены в конце действия замены виртуальной машины, однако действие сообщит о сбое в конце, чтобы указать, что необходимы дополнительные шаги. В журналах установки (расположено в папке \ProgramData\Microsoft\Microsoft SQL Server Parallel Data Warehouse\100\Logs\Setup\\<time-stamp>\Detail-Setup), следующее предупреждение будет отображаться ближе к концу.

*** WARNING \*\*\* DMK is detected in master database, but could not be recovered automatically! The DMK password was either not provided or is incorrect!

Выполните эти инструкции вручную в PDW и перезапустите (модуль) после этого, чтобы восстановить dmK:

OPEN MASTER KEY DECRYPTION BY PASSWORD = '<DMK password>';  
ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY;  

Выполните действия, описанные в разделе "Восстановление абзаца базы данных master", чтобы восстановить базу данных, а затем перезапустить (модуль).

Если dmK существовал до, но не был восстановлен после действия, при запросе базы данных возникает следующее сообщение об ошибке.

Msg 110806;  
A distributed query failed: Database '<db_name>' cannot be opened due to inaccessible files or insufficient memory or disk space. See the SQL Server errorlog for details.

Влияние на производительность

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

См. также

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

• Шифрование SQL Server

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

• Ключи шифрования SQL Server и базы данных

См. также

ALTER DATABASE
CREATE MASTER KEY
CREATE DATABASE ENCRYPTION KEY
BACKUP CERTIFICATE
sp_pdw_database_encryption
sp_pdw_database_encryption_regenerate_system_keys
sp_pdw_log_user_data_masking
sys.certificates
sys.dm_pdw_nodes_database_encryption_keys