Расширенное управление ключами с помощью хранилища ключей Azure (SQL Server)

Соединитель SQL Server для Microsoft Azure Key Vault позволяет шифрованию SQL Server использовать службу azure Key Vault в качестве поставщика расширенного управления ключами (EKM) для защиты ключей шифрования.

Разделы данной темы

Использование расширенного управления ключами

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

Соединитель SQL Server для Azure Key Vault позволяет SQL Server использовать масштабируемую, высокопроизводительную и высокодоступную службу хранилища ключей в качестве поставщика расширенного управления ключами для защиты ключей шифрования. Службу хранилища ключей можно использовать с SQL Server установками в Microsoft Azure Виртуальные машины и для локальных серверов. Служба хранилища ключей также предоставляет возможность использовать жестко контролируемые и отслеживаемые аппаратные модули безопасности (HSM) для обеспечения более высокого уровня защиты асимметричных ключей шифрования. Дополнительные сведения о хранилище ключей см. в статье Хранилище ключей Azure.

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

SQL Server расширенного управления ключами с помощью Key Vault Azure

Шаг 1. Настройка хранилища ключей для использования в SQL Server

Выполните следующие действия, чтобы настроить хранилище ключей для использования с SQL Server Компонент Database Engine для защиты ключей шифрования. Организация может уже использовать хранилище. Если хранилище не существует, администратор Azure в вашей организации, которому назначено управление ключами шифрования, может создать хранилище, создать асимметричный ключ в хранилище, а затем авторизовать SQL Server для использования ключа. Ознакомьтесь со службой хранилища ключей, изучив статью Приступая к работе с хранилищем ключей Azure, и справочником по командлетам PowerShell для работы с хранилищем ключей Azure .

Важно!

Если у вас несколько подписок Azure, необходимо использовать подписку, содержащую SQL Server.

  1. Создание хранилища. Создайте хранилище, следуя инструкциям в разделе Создание хранилища ключей статьи Приступая к работе с хранилищем ключей Azure. Запишите имя хранилища. В этом разделе используется имя ContosoKeyVault .

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

    Существует несколько способов создания асимметричного ключа и сохранения его в хранилище. Можно создать ключ извне и импортировать его в хранилище в виде PFX-файла. Или можно создать ключ непосредственно в хранилище с помощью API хранилища ключей.

    Соединитель SQL Server требует, чтобы асимметричные ключи были 2048-разрядными RSA, а имя ключа может использовать только символы "a-z", "A-Z", "0-9" и "-". В этом документе имя асимметричного ключа — ContosoMasterKey. Замените его на уникальное имя ключа.

    Важно!

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

    Важно!

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

    Дополнительные сведения о том, как импортировать ключ в хранилище ключей или создать ключ в хранилище ключей (не рекомендуется для рабочей среды), см. в разделе Добавление ключа или секретного кода в хранилище ключей статьи Приступая к работе с хранилищем ключей Azure.

  3. Получение субъектов-служб Azure Active Directory для SQL Server. Когда организация регистрируется в облачной службе Майкрософт, она получает Azure Active Directory. Создайте субъекты-службы в Azure Active Directory, чтобы SQL Server использовать (для проверки подлинности в Azure Active Directory) при доступе к хранилищу ключей.

    • Администратору SQL Server потребуется один субъект-служба для доступа к хранилищу при настройке SQL Server для использования шифрования.

    • Еще один субъект-служба потребуется SQL Server Компоненту Database Engine для доступа к хранилищу для распакуивания ключей, используемых при шифровании SQL Server.

    Дополнительные сведения о регистрации приложения и создании субъекта-службы см. в разделе Регистрация приложения в Azure Active Directory статьи Приступая к работе с хранилищем ключей Azure. Процесс регистрации возвращает идентификатор приложения (также известный как идентификатор клиента) и ключ проверки подлинности (также известный как секрет) для каждого субъекта-службыAzure Active Directory. При использовании в инструкции CREATE CREDENTIAL дефис необходимо удалить из идентификатора КЛИЕНТА. Запишите их для использования в следующих скриптах.

    • Субъект-служба для имени входа sysadmin : CLIENTID_sysadmin_login и SECRET_sysadmin_login

    • Субъект-служба для ядра СУБД SQL Server: CLIENTID_DBEngine и SECRET_DBEngine.

  4. Предоставление субъекту-службе разрешений для доступа к хранилищу ключей. Субъектам-службам CLIENTID_sysadmin_login и CLIENTID_DBEngine необходимы разрешения get, list, wrapKey, и unwrapKey в хранилище ключей. Если вы планируете создавать ключи с помощью SQL Server необходимо также предоставить разрешение на создание в хранилище ключей.

    Важно!

    У пользователей должны быть по крайней мере операции wrapKey и unwrapKey для хранилища ключей.

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

    Ссылки на документацию по хранилищу ключей Azure

Этап 2. Установка соединителя SQL Server

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

По умолчанию соединитель устанавливается в папку C:\Program Files\Соединитель SQL Server для Microsoft Azure Key Vault. Эту папку можно изменить во время установки. (В этом случае измените и следующие скрипты.)

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

  • Microsoft.AzureKeyVaultService.EKM.dll. Это библиотека DLL поставщика криптографического расширенного управления ключами, которую необходимо зарегистрировать в SQL Server с помощью инструкции CREATE CRYPTOGRAPHIC PROVIDER.

  • Соединитель SQL Server для хранилища ключей Azure— это служба Windows, которая позволяет поставщику EKM взаимодействовать с хранилищем ключей.

Установка Соединителя SQL Server также позволяет при необходимости скачать примеры скриптов для шифрования SQL Server.

Шаг 3. Настройка SQL Server для использования поставщика EKM для хранилища ключей

Разрешения

Для завершения всего процесса требуется разрешение CONTROL SERVER или членство в предопределенной роли сервера sysadmin . Для определенных действий необходимы следующие разрешения.

  • Для создания поставщика служб шифрования требуется разрешение CONTROL SERVER или членство в предопределенной роли сервера sysadmin .

  • Для изменения параметра конфигурации и выполнения инструкции RECONFIGURE должно быть предоставлено разрешение ALTER SETTINGS на уровне сервера. Разрешение ALTER SETTINGS неявным образом предоставлено предопределенным ролям сервера sysadmin и serveradmin .

  • Для создания учетных данных требуется разрешение ALTER ANY CREDENTIAL.

  • Для добавления учетных данных необходимо разрешение ALTER ANY LOGIN.

  • Для создания асимметричного ключа требуется разрешение CREATE ASYMMETRIC KEY.

Настройка SQL Server для использования поставщика служб шифрования

  1. Настройте ядро СУБД для использования расширенного управления ключами и зарегистрируйте (создайте) поставщик шифрования с помощью SQL Server.

    -- Enable advanced options.
    USE master;
    GO
    
    sp_configure 'show advanced options', 1 ;
    GO
    RECONFIGURE ;
    GO
    -- Enable EKM provider
    sp_configure 'EKM provider enabled', 1 ;
    GO
    RECONFIGURE ;
    GO
    
    -- Create a cryptographic provider, using the SQL Server Connector
    -- which is an EKM provider for the Azure Key Vault. This example uses 
    -- the name AzureKeyVault_EKM_Prov.
    
    CREATE CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM_Prov 
    FROM FILE = 'C:\Program Files\SQL Server Connector for Microsoft Azure Key Vault\Microsoft.AzureKeyVaultService.EKM.dll';
    GO
    
  2. Настройте учетные данные SQL Server для входа администратора SQL Server, чтобы использовать хранилище ключей, чтобы настроить сценарии шифрования SQL Server и управлять ими.

    Важно!

    Для аргумента CREATE CREDENTIALIDENTITY требуется имя хранилища ключей. Аргумент CREATE CREDENTIALSECRET требует<, чтобы идентификатор> клиента (без дефисов) и <секрет> передавались вместе без пробела между ними.

    В следующем примере идентификатор клиента (EF5C8E09-4D2A-4A76-9998-D93440D8115D) удаляется из дефисов и вводится в качестве строки EF5C8E094D2A4A769998D93440D8115D , а секрет представлен строкой SECRET_sysadmin_login.

    USE master;
    CREATE CREDENTIAL sysadmin_ekm_cred 
        WITH IDENTITY = 'ContosoKeyVault', 
        SECRET = 'EF5C8E094D2A4A769998D93440D8115DSECRET_sysadmin_login' 
    FOR CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM_Prov ;
    
    -- Add the credential to the SQL Server administrators domain login 
    ALTER LOGIN [<domain>/<login>]
    ADD CREDENTIAL sysadmin_ekm_cred;
    

    Пример использования переменных для CREATE CREDENTIAL аргументов и программного удаления дефисов из идентификатора клиента см. в разделе CREATE CREDENTIAL (Transact-SQL).

  3. Если вы импортировали асимметричный ключ, как описано выше в шаге 1 раздела 3, откройте ключ, указав имя ключа в следующем примере.

    CREATE ASYMMETRIC KEY CONTOSO_KEY 
    FROM PROVIDER [AzureKeyVault_EKM_Prov]
    WITH PROVIDER_KEY_NAME = 'ContosoMasterKey',
    CREATION_DISPOSITION = OPEN_EXISTING;
    

    Хотя это не рекомендуется для рабочей среды (поскольку ключ не может быть экспортирован), асимметричный ключ можно создать непосредственно в хранилище из SQL Server. Если вы не импортировали ключ ранее, создайте асимметричный ключ в хранилище для тестирования с помощью следующего скрипта. Выполните скрипт, используя имя входа, предоставленное в учетных данных sysadmin_ekm_cred .

    CREATE ASYMMETRIC KEY CONTOSO_KEY 
    FROM PROVIDER [AzureKeyVault_EKM_Prov]
    WITH ALGORITHM = RSA_2048,
    PROVIDER_KEY_NAME = 'ContosoMasterKey';
    

Совет

Пользователи, получающие ошибку Не удается экспортировать открытый ключ от поставщика. Код ошибки поставщика: 2053. должны проверка разрешения get, list, wrapKey и unwrapKey в хранилище ключей.

Дополнительные сведения см. в следующих разделах:

Примеры

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

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

Для шифрования базы данных требуется разрешение CONTROL в базе данных.

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

    Важно!

    Для аргумента CREATE CREDENTIALIDENTITY требуется имя хранилища ключей. Аргумент CREATE CREDENTIALSECRET требует<, чтобы идентификатор> клиента (без дефисов) и <секрет> передавались вместе без пробела между ними.

    В следующем примере из идентификатора клиента (EF5C8E09-4D2A-4A76-9998-D93440D8115D) удаляются дефисы. Идентификатор клиента вводится как строка EF5C8E094D2A4A769998D93440D8115D , а секрет представляется строкой SECRET_DBEngine.

    USE master;
    CREATE CREDENTIAL Azure_EKM_TDE_cred 
        WITH IDENTITY = 'ContosoKeyVault', 
        SECRET = 'EF5C8E094D2A4A769998D93440D8115DSECRET_DBEngine' 
        FOR CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM_Prov ;
    
  2. Создайте имя входа SQL Server, которое будет использоваться компонентом Компонент Database Engine для TDE, и добавьте в него учетные данные. В этом примере используется асимметричный ключ CONTOSO_KEY из хранилища ключей, который был импортирован или создан ранее для базы данных master, как описано в шаге 3 раздела 3 выше.

    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 можно создать, используя любой поддерживаемый алгоритм SQL Server или длину ключа. Ключ DEK будет защищен асимметричным ключом в хранилище ключей.

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

    USE ContosoDatabase;
    GO
    
    CREATE DATABASE ENCRYPTION KEY 
    WITH ALGORITHM = AES_128 
    ENCRYPTION BY SERVER ASYMMETRIC KEY CONTOSO_KEY;
    GO
    
    -- Alter the database to enable transparent data encryption.
    ALTER DATABASE ContosoDatabase 
    SET ENCRYPTION ON ;
    GO
    

    Дополнительные сведения см. в следующих разделах:

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

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

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]);
GO

Образец кода восстановления.

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

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

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

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

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

USE [ContosoDatabase];
GO

-- Create a reference to the key in the key vault
CREATE ASYMMETRIC KEY CONTOSO_KEY 
FROM PROVIDER [AzureKeyVault_EKM_Prov]
WITH PROVIDER_KEY_NAME = 'ContosoMasterKey',
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;

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;

--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;

См. также:

CREATE CRYPTOGRAPHIC PROVIDER (Transact-SQL)CREATE CREDENTIAL (Transact-SQL)CREATE ASYMMETRIC KEY (Transact-SQL)CREATE SYMMETRIC KEY (Transact-SQL)Расширенное управление ключами (EKM)Включение TDE с помощьюшифрования резервного копирования расширенного управления ключами Создание зашифрованной резервной копии