Поделиться через

Использование Соединителя SQL Server с компонентами шифрования SQL

  • Статья

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

Распространенные действия шифрования SQL Server с использованием асимметричного ключа, защищенного Azure Key Vault, включают следующие три области.

  • Прозрачное шифрование данных с помощью асимметричного ключа из хранилища ключей Azure

  • Шифрование резервных копий с помощью асимметричного ключа из хранилища ключей

  • Шифрование данных на уровне столбца с помощью асимметричного ключа из хранилища ключей

Перед выполнением описанных здесь инструкций выполните части с I по IV в статье Этапы настройки расширенного управления ключами с использованием хранилища ключей Azure.

Примечание.

Версии 1.0.0.440 и старше были заменены и больше не поддерживаются в рабочих средах. Выполните обновление до версии 1.0.1.0 или более поздней, посетив Центр загрузки Майкрософт и используя инструкции на странице Обслуживание соединителя SQL Server и устранение неполадок в разделе "Обновление соединителя SQL Server".

Примечание.

Идентификатор Microsoft Entra ранее был известен как Azure Active Directory (Azure AD).

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

После выполнения частей с I по IV, описанных в статье "Этапы настройки расширенного управления ключами с использованием хранилища ключей Azure", используйте хранилище ключей Azure для шифрования ключа шифрования базы данных с помощью TDE. Дополнительные сведения о смене ключей с помощью PowerShell см. в статье Смена средства защиты прозрачного шифрования данных (TDE) с помощью PowerShell.

Внимание

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

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

Схема иерархии ключа шифрования при использовании Azure Key Vault.

  1. Создание учетных данных SQL Server для ядро СУБД, используемых для TDE

    Ядро СУБД использует учетные данные приложения Microsoft Entra для доступа к Key Vault во время загрузки базы данных. Мы рекомендуем создать другой идентификатор клиента и секрет, как описано на шаге 1, для ядро СУБД, чтобы ограничить предоставленные разрешения Key Vault.

    Измените приведенный ниже скрипт Transact-SQL следующим образом:

    • Измените аргумент IDENTITY (ContosoDevKeyVault), чтобы он указывал на хранилище ключей Azure.

      • Если вы используете глобальную службу Azure, замените аргумент IDENTITY на имя вашего хранилища Azure Key Vault из части II.
      • Если вы используете частное облако Azure (например, Azure для государственных организаций, Azure под управлением 21Vianet или Azure в Германии), замените IDENTITY аргумент URI хранилища, возвращаемый в части II, шаг 3. Не включайте https:// в URI хранилища.

    • Замените первую часть SECRET аргумента идентификатором клиента приложения Microsoft Entra на шаге 1. В этом примере идентификатором клиента является EF5C8E094D2A4A769998D93440D8115D.

      Внимание

      Необходимо удалить дефисы из идентификатора клиента.

    • Дополните вторую часть аргумента SECRETсекретом клиента из части I. В этом примере секрет клиента из части I имеет значение ReplaceWithAADClientSecret.

    • Окончательная строка аргумента SECRET будет представлять собой длинную последовательность букв и цифр без дефисов.

    USE master;  
CREATE CREDENTIAL Azure_EKM_TDE_cred   
    WITH IDENTITY = 'ContosoDevKeyVault', -- for global Azure
    -- WITH IDENTITY = 'ContosoDevKeyVault.vault.usgovcloudapi.net', -- for Azure Government
    -- WITH IDENTITY = 'ContosoDevKeyVault.vault.azure.cn', -- for Microsoft Azure operated by 21Vianet
    -- WITH IDENTITY = 'ContosoDevKeyVault.vault.microsoftazure.de', -- for Azure Germany   
    SECRET = 'EF5C8E094D2A4A769998D93440D8115DReplaceWithAADClientSecret'   
FOR CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM_Prov;

  2. Создание имени входа SQL Server для ядро СУБД для TDE

    Создайте имя входа SQL Server и добавьте в него учетные данные из шага 1. В этом примере Transact-SQL используется тот же ключ, который был импортирован ранее.

    USE master;  
-- Create a SQL Server login associated with the asymmetric key   
-- for the Database engine to use when it loads a database   
-- encrypted by TDE.  
CREATE LOGIN TDE_Login   
FROM ASYMMETRIC KEY CONTOSO_KEY;  
GO   

-- Alter the TDE Login to add the credential for use by the   
-- Database Engine to access the key vault  
ALTER LOGIN TDE_Login   
ADD CREDENTIAL Azure_EKM_TDE_cred ;  
GO

  3. Создание ключа шифрования базы данных (DEK)

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

    USE ContosoDatabase;  
GO  

CREATE DATABASE ENCRYPTION KEY   
WITH ALGORITHM = AES_256   
ENCRYPTION BY SERVER ASYMMETRIC KEY CONTOSO_KEY;  
GO

  4. Включение кэша TDE

    -- Alter the database to enable transparent data encryption.  
ALTER DATABASE ContosoDatabase   
SET ENCRYPTION ON;  
GO

    С помощью Management Studio убедитесь, что TDE включен, подключившись к базе данных с помощью обозреватель объектов. Щелкните правой кнопкой мыши базу данных, наведите указатель на пункт Задачи, а затем щелкните Управление шифрованием в базе данных.

    Снимок экрана: обозреватель объектов с выбранным параметром

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

    Снимок экрана: диалоговое окно

    Кроме того, можно выполнить следующий скрипт Transact-SQL. Состояние шифрования 3 указывает на зашифрованную базу данных.

    USE MASTER  
SELECT * FROM sys.asymmetric_keys  

-- Check which databases are encrypted using TDE  
SELECT d.name, dek.encryption_state   
FROM sys.dm_database_encryption_keys AS dek  
JOIN sys.databases AS d  
     ON dek.database_id = d.database_id;

    Примечание.

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

Шифрование резервных копий с помощью асимметричного ключа из хранилища ключей

Зашифрованные резервные копии поддерживаются начиная с SQL Server 2014 (12.x). В следующем примере создается и восстанавливается резервная копия, зашифрованная ключом шифрования данных, который защищен асимметричным ключом в хранилище ключей.
Ядро СУБД использует учетные данные приложения Microsoft Entra для доступа к Key Vault во время загрузки базы данных. Мы рекомендуем создать другой идентификатор клиента и секрет, как описано на шаге 1, для ядро СУБД, чтобы ограничить предоставленные разрешения Key Vault.

  1. Создание учетных данных SQL Server для ядра СУБД, которые будут использоваться при шифровании резервной копии

    Измените приведенный ниже скрипт Transact-SQL следующим образом:

    • Измените аргумент IDENTITY (ContosoDevKeyVault), чтобы он указывал на хранилище ключей Azure.

      • Если вы используете глобальную службу Azure, замените аргумент IDENTITY на имя вашего хранилища Azure Key Vault из части II.
      • Если вы используете частное облако Azure (например, Azure для государственных организаций, Microsoft Azure, управляемый 21Vianet или Azure Germany), замените IDENTITY аргумент URI хранилища, возвращаемый в части II, шаг 3. Не включайте https:// в URI хранилища.

    • Замените первую часть SECRET аргумента идентификатором клиента приложения Microsoft Entra на шаге 1. В этом примере идентификатором клиента является EF5C8E094D2A4A769998D93440D8115D.

      Внимание

      Необходимо удалить дефисы из идентификатора клиента.

    • Дополните вторую часть аргумента SECRETсекретом клиента из части I. В этом примере секрет клиента из части I имеет значение Replace-With-AAD-Client-Secret. Окончательная строка аргумента SECRET будет представлять собой длинную последовательность букв и цифр без дефисов.

      USE master;  

CREATE CREDENTIAL Azure_EKM_Backup_cred   
    WITH IDENTITY = 'ContosoDevKeyVault', -- for global Azure
    -- WITH IDENTITY = 'ContosoDevKeyVault.vault.usgovcloudapi.net', -- for Azure Government
    -- WITH IDENTITY = 'ContosoDevKeyVault.vault.azure.cn', -- for Microsoft Azure operated by 21Vianet
    -- WITH IDENTITY = 'ContosoDevKeyVault.vault.microsoftazure.de', -- for Azure Germany   
    SECRET = 'EF5C8E094D2A4A769998D93440D8115DReplace-With-AAD-Client-Secret'   
FOR CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM_Prov;

  2. Создание имени входа SQL Server для ядро СУБД для шифрования резервных копий

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

    Внимание

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

    В этом примере используется асимметричный ключ CONTOSO_KEY_BACKUP из хранилища ключей, который мог быть импортирован или создан ранее для базы данных master на этапе 5 в части IV.

    USE master;  

-- Create a SQL Server login associated with the asymmetric key   
-- for the Database engine to use when it is encrypting the backup.  
CREATE LOGIN Backup_Login   
FROM ASYMMETRIC KEY CONTOSO_KEY_BACKUP;  
GO   

-- Alter the Encrypted Backup Login to add the credential for use by   
-- the Database Engine to access the key vault  
ALTER LOGIN Backup_Login   
ADD CREDENTIAL Azure_EKM_Backup_cred ;  
GO

  3. Резервное копирование базы данных

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

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

    USE master;  

BACKUP DATABASE [DATABASE_TO_BACKUP]  
TO DISK = N'[PATH TO BACKUP FILE]'   
WITH FORMAT, INIT, SKIP, NOREWIND, NOUNLOAD,   
ENCRYPTION(ALGORITHM = AES_256,   
SERVER ASYMMETRIC KEY = [CONTOSO_KEY_BACKUP]);  
GO

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

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

    • Если исходный асимметричный ключ, используемый для TDE, больше не находится в Key Vault, восстановите резервную копию ключа Key Vault или повторно импортируйте ключ из локального модуля HSM. Важно! Чтобы отпечаток ключа совпал с записанным в резервной копии базы данных, ключ должен иметь исходное имя ключа Key Vault.

    • Примените шаги 1 и 2 к целевому экземпляру SQL Server.

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

    Пример кода восстановления:

    RESTORE DATABASE [DATABASE_TO_BACKUP]  
FROM DISK = N'[PATH TO BACKUP FILE]'   
    WITH FILE = 1, NOUNLOAD, REPLACE;  
GO

    Дополнительные сведения о параметрах резервного копирования см. в статье BACKUP (Transact-SQL).

Шифрование данных на уровне столбца с помощью асимметричного ключа из хранилища ключей

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

Внимание

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

В этом примере используется асимметричный ключ CONTOSO_KEY_COLUMNS из хранилища ключей, который мог быть импортирован или создан ранее, как описано в этапе 3 раздела 3 статьи Этапы настройки расширенного управления ключами с использованием хранилища ключей Azure. Для использования асимметричного ключа в базе данных ContosoDatabase необходимо выполнить инструкцию CREATE ASYMMETRIC KEY еще раз, чтобы предоставить базе данных ContosoDatabase ссылку на ключ.

USE [ContosoDatabase];  
GO  
  
-- Create a reference to the key in the key vault  
CREATE ASYMMETRIC KEY CONTOSO_KEY_COLUMNS   
FROM PROVIDER [AzureKeyVault_EKM_Prov]  
WITH PROVIDER_KEY_NAME = 'ContosoDevRSAKey2',  
CREATION_DISPOSITION = OPEN_EXISTING;  
  
-- Create the data encryption key.  
-- The data encryption key can be created using any SQL Server   
-- supported algorithm or key length.  
-- The DEK will be protected by the asymmetric key in the key vault  
  
CREATE SYMMETRIC KEY DATA_ENCRYPTION_KEY  
    WITH ALGORITHM=AES_256  
    ENCRYPTION BY ASYMMETRIC KEY CONTOSO_KEY_COLUMNS;  
  
DECLARE @DATA VARBINARY(MAX);  
  
--Open the symmetric key for use in this session  
OPEN SYMMETRIC KEY DATA_ENCRYPTION_KEY   
DECRYPTION BY ASYMMETRIC KEY CONTOSO_KEY_COLUMNS;  
  
--Encrypt syntax  
SELECT @DATA = ENCRYPTBYKEY  
    (  
    KEY_GUID('DATA_ENCRYPTION_KEY'),   
    CONVERT(VARBINARY,'Plain text data to encrypt')  
    );  
  
-- Decrypt syntax  
SELECT CONVERT(VARCHAR, DECRYPTBYKEY(@DATA));  
  
--Close the symmetric key  
CLOSE SYMMETRIC KEY DATA_ENCRYPTION_KEY;

См. также

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