Share via

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

  • Статья

Применимо к:SQL Server

В этой статье вы устанавливаете и настраиваете Подключение or SQL Server для Azure Key Vault.

Примечание.

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

Расширяемое управление ключами с помощью Azure Key Vault (AKV) доступно для SQL Server на Linux сред, начиная с накопительного обновления 12 SQL Server 2022 (16.x). Выполните те же инструкции, но пропустите шаги 3 и 4.

Необходимые компоненты

Прежде чем приступить к использованию Azure Key Vault с экземпляром SQL Server, убедитесь, что выполнены следующие предварительные требования.

Шаг 1. Настройка субъекта-службы Microsoft Entra

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

  1. Войдите на портал Azure и выполните одно из следующих действий.

    • Нажмите кнопку идентификатора Microsoft Entra ID .

      Снимок экрана: область служб Azure.

    • Выберите "Дополнительные службы", а затем в области "Все службы" введите идентификатор Microsoft Entra.

  2. Зарегистрируйте приложение с помощью идентификатора Microsoft Entra, выполнив указанные ниже действия. Подробные пошаговые инструкции см . в разделе "Получение удостоверения" для раздела приложения записи блога Azure Key Vault, Azure Key Vault — пошаговые инструкции.

    1. В разделе "Управление" ресурса идентификатора Microsoft Entra выберите Регистрация приложений.

      Снимок экрана: страница обзора идентификатора Microsoft Entra в портал Azure.

    2. На странице Регистрация приложений выберите Новая регистрация.

      Снимок экрана: панель Регистрация приложений в портал Azure.

    3. На панели Зарегистрировать приложение введите имя приложения, доступное для пользователя, а затем выберите Зарегистрировать.

      Снимок экрана: панель

    4. В левой области выберите "Сертификаты и секреты" секретов >> клиента "Новый секрет клиента".

      Снимок экрана: область

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

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

    6. В области "Сертификаты и секреты" в разделе "Значение" нажмите кнопку "Копировать" рядом со значением секрета клиента, который будет использоваться для создания асимметричного ключа в SQL Server.

      Снимок экрана: значение секрета в портал Azure.

    7. В левой области выберите Обзор, а затем, в поле Идентификатор приложения (клиента), скопируйте значение, которое будет использоваться для создания асимметричного ключа в SQL Server.

      Снимок экрана: значение идентификатора приложения (клиента) на панели обзора.

Шаг 2. Создание хранилища ключей

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

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

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

  1. Создать группу ресурсов.

    Все ресурсы Azure, созданные с помощью портала Azure, должны содержаться в группе ресурсов, которая создается для размещения хранилища ключей. Имя ресурса в этом примере — DocsSampleRG. Выберите собственные имена для группы ресурсов и хранилища ключей. Имена всех хранилищ ключей должны быть глобально уникальными.

    На панели Создать группу ресурсов в разделе Сведения о проекте введите значения, а затем выберите Просмотр и создание.

    Снимок экрана: панель

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

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

    Снимок экрана: панель

  3. На вкладке "Конфигурация доступа" вы можете выбрать управление доступом на основе ролей Azure или политику доступа Хранилища. Мы рассмотрим оба варианта, но рекомендуется использовать параметр управления доступом на основе ролей Azure. Дополнительные сведения см. в обзоре модели Access.

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

  4. Выберите "Просмотр и создание хранилища ключей".

Управление доступом на основе ролей Azure

Рекомендуется использовать управление доступом на основе ролей Azure (RBAC) для назначения разрешений хранилищу ключей. Этот метод позволяет назначать разрешения пользователям, группам и приложениям на более детальном уровне. Вы можете назначить разрешения хранилищу ключей в плоскости управления (назначения ролей Azure) и на плоскости данных (политики доступа к хранилищу ключей). Если вы можете использовать только политику доступа, можно пропустить этот раздел и перейти к разделу политики доступа Хранилища. Дополнительные сведения о разрешениях RBAC в Azure Key Vault см. в статье о встроенных ролях Azure для операций плоскости данных Key Vault.

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

  2. Выберите Добавить>Добавить назначение ролей.

    Снимок экрана: кнопка

  3. Приложению EKM требуется роль пользователя шифрования шифрования службы шифрования Key Vault для выполнения операций упаковки и распаковки. Найдите пользователя шифрования службы шифрования key Vault и выберите роль. Выберите Далее.

    Снимок экрана: выбор назначения роли в портал Azure.

  4. На вкладке "Участники" выберите параметр "Выбрать участников", а затем найдите приложение Microsoft Entra, созданное на шаге 1. Выберите приложение и нажмите кнопку "Выбрать ".

    Снимок экрана: панель

  5. Нажмите кнопку "Проверить и назначить дважды", чтобы завершить назначение роли.

  6. Пользователь, создающий ключ, нуждается в роли key Vault Администратор istrator. Найдите Администратор istrator Key Vault и выберите роль. Выберите Далее.

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

Политика доступа к хранилищу

Примечание.

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

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

  2. На панели "Создание политики доступа" выберите "Получить и перечислить разрешения" в параметрах "Операции управления ключами". Выберите разрешения "Распаковывать ключ" и "Ключ оболочки" в параметрах "Операции шифрования". Выберите Далее

    Снимок экрана: ссылка

  3. На вкладке "Субъект" выберите приложение, созданное на шаге 1.

    Снимок экрана: поле поиска приложения на панели

  4. Нажмите кнопку "Далее" и "Создать".

Создание ключа

  1. В области Key Vault выберите "Ключи", а затем выберите параметр "Создать и импортировать". Откроется панель "Создание ключа ". Введите имя хранилища ключей. Выберите параметр "Создать" и введите имя ключа. Соединителю SQL Server требуется, чтобы имя ключа содержало только символы a–z, A–Z, 0–9 и "-" и имело длину не более 26 знаков.

  2. Используйте тип ключа RSA и размер ключа RSA как 2048. В настоящее время EKM поддерживает только ключ RSA. Задайте даты активации и окончания срока действия соответствующим образом и задайте значение"Да".

    Снимок экрана: панель

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

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

  • Создайте ключ шифрования локально, на локальном аппаратном модуле безопасности (HSM). Это должен быть асимметричный ключ RSA 2048 или 3072, так как SQL Server поддерживает только такие ключи.

  • Импортируйте ключ шифрования в Azure Key Vault. Этот процесс описан в последующих разделах.

  • Прежде чем впервые использовать ключ в хранилище ключей Azure, выполните резервное копирование ключей хранилища ключей Azure с помощью командлета Backup-AzureKeyVaultKey PowerShell.

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

    Примечание.

    Резервное копирование ключа из Azure Key Vault позволяет получить файл, который можно сохранить в любом расположении.

    Использование Подключение or SQL Server для Azure Key Vault за брандмауэром или прокси-сервером может повлиять на производительность, если трафик задерживается или блокируется. Ознакомьтесь с Доступом к Azure Key Vault за брандмауэром , чтобы убедиться, что правильные правила установлены.

Шаг 3. Установка Подключение sql Server

Скачайте Соединитель SQL Server из Центра загрузки Майкрософт. Скачивание должно выполняться администратором компьютера SQL Server.

Примечание.

  • Соединитель SQL Server версии 1.0.0.440 и более ранних версий были заменены и больше не поддерживаются в рабочих средах. Вместо них используются инструкции на странице Обслуживание и устранение неполадок соединителя SQL Server в разделе Обновление соединителя SQL Server.
  • Начиная с версии 1.0.3.0, соединитель SQL Server передает соответствующие сообщения об ошибках в журналы событий Windows для устранения неполадок.
  • Начиная с версии 1.0.4.0, поддерживается частные облака Azure, включая Azure, управляемые 21Vianet, Azure в Германии и Azure для государственных организаций.
  • В версии 1.0.5.0 внесено критическое изменение, касающееся алгоритма отпечатков. После обновления до версии 1.0.5.0 восстановление базы данных может завершаться сбоем. Дополнительные сведения см. в статье базы знаний 447099.
  • Начиная с версии 1.0.5.0 (TimeStamp: сентябрь 2020 г.), sql Server Подключение or поддерживает фильтрацию сообщений и логику повторных попыток сетевого запроса.
  • Начиная с обновленной версии 1.0.5.0 (Метка времени: ноябрь 2020 г.), sql Server Подключение or поддерживает ключи RSA 2048, RSA 3072, RSA-HSM 2048 и RSA-HSM 3072.
  • Начиная с обновленной версии 1.0.5.0 (TimeStamp: ноябрь 2020 г.), можно обратиться к определенной версии ключа в Azure Key Vault.

Снимок экрана: мастер установки Подключение sql Server.

По умолчанию Подключение or устанавливается в C:\Program Files\SQL Server Connector for Microsoft Azure Key Vault. Эту папку можно изменить во время установки. Если вы измените ее, измените сценарии в следующем разделе.

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

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

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

Шаг 4. Добавление раздела реестра для поддержки поставщика EKM

Предупреждение

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

  1. Убедитесь, что SQL Server установлен и запущен.

  2. Запустите regedit , чтобы открыть редактор реестра.

  3. SQL Server Cryptographic Provider Создайте раздел HKEY_LOCAL_MACHINE\SOFTWARE\Microsoftреестра в . Полный путь выглядит так: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider.

  4. Щелкните правой кнопкой SQL Server Cryptographic Provider мыши раздел реестра и выберите "Разрешения".

  5. Предоставьте разрешения на полный доступ к SQL Server Cryptographic Provider разделу реестра учетной записи пользователя, работающей в службе SQL Server.

    Снимок экрана: раздел реестра EKM в редакторе реестра.

  6. Нажмите кнопку Apply (Применить), а затем — ОК.

  7. Закройте редактор реестра и перезапустите службу SQL Server.

    Примечание.

    Если вы используете TDE с EKM или Azure Key Vault в экземпляре отказоустойчивого кластера, необходимо выполнить дополнительный шаг, чтобы добавить HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider в подпрограмму контрольной точки реестра кластера, чтобы реестр может синхронизироваться с узлами. Синхронизация упрощает восстановление базы данных после отработки отказа и смены ключа.

    Чтобы добавить раздел реестра в подпрограмму контрольной точки реестра кластера, выполните следующую команду в PowerShell:

    Add-ClusterCheckpoint -RegistryCheckpoint "SOFTWARE\Microsoft\SQL Server Cryptographic Provider" -Resourcename "SQL Server"

Шаг 5. Настройка SQL Server

Сведения о минимальном уровне разрешений для выполнения каждого из описанных здесь действий см. в разделе Б. Часто задаваемые вопросы.

master Настройка базы данных

  1. Запустите sqlcmd или откройте СРЕДУ SQL Server Management Studio.

  2. Настройте SQL Server для использования EKM, выполнив следующий скрипт Transact-SQL:

    -- Enable advanced options.
USE master;
GO

EXEC sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO

-- Enable EKM provider
EXEC sp_configure 'EKM provider enabled', 1;
GO
RECONFIGURE;

  3. Зарегистрируйте sql Server Подключение or в качестве поставщика EKM в SQL Server.

    Создайте поставщика шифрования с помощью Подключение or SQL Server, который является поставщиком EKM для Azure Key Vault. В этом примере имя поставщика — AzureKeyVault_EKM.

    CREATE CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM
FROM FILE = 'C:\Program Files\SQL Server Connector for Microsoft Azure Key Vault\Microsoft.AzureKeyVaultService.EKM.dll';
GO

    Примечание.

    Длина пути файла не может превышать 256 символов.

  4. Настройте учетные данные SQL Server для входа в SQL Server, чтобы использовать хранилище ключей.

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

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

    • Другие имена входа SQL Server, которые могут включать TDE или другие функции шифрования SQL Server.

    Между учетными данными и именами входа существует сопоставление "один к одному". То есть каждое имя входа должно иметь уникальные учетные данные.

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

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

    • Замените первую часть SECRET аргумента идентификатором клиента Microsoft Entra из шага 1. Настройка субъекта-службы Microsoft Entra. В этом примере идентификатором клиента является d956f6b9xxxxxxx.

      Внимание

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

    • Выполните вторую часть аргумента SECRET с помощью секрета клиента из шага 1. Настройка субъекта-службы Microsoft Entra. В этом примере секретом клиента является yrA8X~PldtMCvUZPxxxxxxxx. Последняя строка аргумента SECRET будет длинной последовательностью букв и чисел без дефисов (за исключением раздела секрета клиента, если секрет клиента содержит все дефисы).

      USE master;
CREATE CREDENTIAL sysadmin_ekm_cred
    WITH IDENTITY = 'DocsSampleEKMKeyVault',                            -- for public Azure
    -- WITH IDENTITY = 'DocsSampleEKMKeyVault.vault.usgovcloudapi.net', -- for Azure Government
    -- WITH IDENTITY = 'DocsSampleEKMKeyVault.vault.azure.cn',          -- for Microsoft Azure operated by 21Vianet
    -- WITH IDENTITY = 'DocsSampleEKMKeyVault.vault.microsoftazure.de', -- for Azure Germany
           --<----Application (Client) ID ---><--Microsoft Entra app (Client) ID secret-->
    SECRET = 'd956f6b9xxxxxxxyrA8X~PldtMCvUZPxxxxxxxx'
FOR CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM;

-- Add the credential to the SQL Server administrator's domain login
ALTER LOGIN [<domain>\<login>]
ADD CREDENTIAL sysadmin_ekm_cred;

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

  5. Откройте ключ Azure Key Vault в экземпляре SQL Server.

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

    Внимание

    Сначала выполните предварительные требования реестра для этого шага.

    • Замените EKMSampleASYKey именем, которым вы хотите, чтобы ключ был в SQL Server.
    • Замените ContosoRSAKey0 именем ключа в Azure Key Vault. Ниже приведен пример ключа без версии.
    CREATE ASYMMETRIC KEY EKMSampleASYKey
FROM PROVIDER [AzureKeyVault_EKM]
WITH PROVIDER_KEY_NAME = 'ContosoRSAKey0',
CREATION_DISPOSITION = OPEN_EXISTING;

    Начиная с обновленной версии 1.0.5.0 соединителя SQL Server, можно обратиться к определенной версии ключа в Azure Key Vault:

    CREATE ASYMMETRIC KEY EKMSampleASYKey
FROM PROVIDER [AzureKeyVault_EKM]
WITH PROVIDER_KEY_NAME = 'ContosoRSAKey0/1a4d3b9b393c4678831ccc60def75379',
CREATION_DISPOSITION = OPEN_EXISTING;

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

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

    --Create a Login that will associate the asymmetric key to this login
CREATE LOGIN TDE_Login
FROM ASYMMETRIC KEY EKMSampleASYKey;

  7. Создайте новое имя входа из асимметричного ключа в SQL Server. Удалите сопоставление учетных данных на шаге 5. Настройте SQL Server , чтобы учетные данные могли быть сопоставлены с новым именем входа.

    --Now drop the credential mapping from the original association
ALTER LOGIN [<domain>\<login>]
DROP CREDENTIAL sysadmin_ekm_cred;

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

    --Now add the credential mapping to the new Login
ALTER LOGIN TDE_Login
ADD CREDENTIAL sysadmin_ekm_cred;

Настройка шифрования пользовательской базы данных

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

    --Create a test database that will be encrypted with the Azure Key Vault key
CREATE DATABASE TestTDE;

  2. Создайте ключ шифрования базы данных с помощью ASYMMETRIC KEY (EKMSampleASYKey).

    USE <DB Name>;
--Create an ENCRYPTION KEY using the ASYMMETRIC KEY (EKMSampleASYKey)
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER ASYMMETRIC KEY EKMSampleASYKey;

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

    --Enable TDE by setting ENCRYPTION ON
ALTER DATABASE TestTDE
SET ENCRYPTION ON;

Сведения о реестре

  1. Выполните следующий запрос Transact-SQL в master базе данных, чтобы отобразить асимметричный ключ, используемый.

    SELECT name, algorithm_desc, thumbprint FROM sys.asymmetric_keys;

    Инструкция возвращает следующие данные:

    name            algorithm_desc    thumbprint
EKMSampleASYKey RSA_2048          <key thumbprint>

  2. В пользовательской базе данных (TestTDE) выполните следующий запрос Transact-SQL, чтобы отобразить используемый ключ шифрования.

    SELECT encryptor_type, encryption_state_desc, encryptor_thumbprint 
FROM sys.dm_database_encryption_keys
WHERE database_id = DB_ID('TestTDE');

    Инструкция возвращает следующие данные:

    encryptor_type encryption_state_desc encryptor_thumbprint
ASYMMETRIC KEY ENCRYPTED             <key thumbprint>

Очистка

  1. Очистите тестовые объекты. Удалите все объекты, созданные в этом тестовом сценарии.

    -- CLEAN UP
USE master;
GO
ALTER DATABASE [TestTDE] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DROP DATABASE [TestTDE];
GO

ALTER LOGIN [TDE_Login] DROP CREDENTIAL [sysadmin_ekm_cred];
DROP LOGIN [TDE_Login];
GO

DROP CREDENTIAL [sysadmin_ekm_cred];
GO

USE master;
GO
DROP ASYMMETRIC KEY [EKMSampleASYKey];
DROP CRYPTOGRAPHIC PROVIDER [AzureKeyVault_EKM];
GO

    Примеры сценариев см. в блоге Прозрачное шифрование данных и расширенное управление ключами SQL Server с помощью Azure Key Vault.

  2. Раздел SQL Server Cryptographic Provider реестра не очищается автоматически после удаления ключа или всех ключей EKM. Его необходимо очистить вручную. Очистка раздела реестра должна выполняться с крайней осторожностью, так как очистка реестра преждевременно может нарушить функциональные возможности EKM. Чтобы очистить раздел реестра, удалите SQL Server Cryptographic Provider раздел HKEY_LOCAL_MACHINE\SOFTWARE\Microsoftреестра.

Устранение неполадок

Если раздел HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider реестра не создан или необходимые разрешения не предоставлены, следующая инструкция DDL завершится ошибкой:

CREATE ASYMMETRIC KEY EKMSampleASYKey
FROM PROVIDER [AzureKeyVault_EKM]
WITH PROVIDER_KEY_NAME = 'ContosoRSAKey0',
CREATION_DISPOSITION = OPEN_EXISTING;

Msg 33049, Level 16, State 2, Line 65
Key with name 'ContosoRSAKey0' does not exist in the provider or access is denied. Provider error code: 2058.  (Provider Error - No explanation is available, consult EKM Provider for details)

Срок действия секретов клиента, срок действия которых истекает

Если учетные данные имеют секрет клиента, срок действия которого скоро истечет, учетным данным можно назначить новый секрет.

  1. Обновите секрет, созданный на шаге 1. Настройка субъекта-службы Microsoft Entra.

  2. Измените учетные данные с помощью того же удостоверения и нового секрета с помощью следующего кода. Замените <New Secret> новым секретом:

    ALTER CREDENTIAL sysadmin_ekm_cred
WITH IDENTITY = 'DocsSampleEKMKeyVault',
SECRET = '<New Secret>';

  3. Перезапустите службу SQL Server.

Примечание.

Если вы используете EKM в группе доступности (AG), необходимо изменить учетные данные и перезапустить службу SQL Server на всех узлах группы доступности.

Смена асимметричного ключа с новым ключом AKV или новой версией ключа AKV

Примечание.

  • При смене ключа AKV SQL Server поддерживает как ключ без версии AKV, так и ключ с версиями, и не требуется использовать другой ключ AKV.
  • Исходный ключ AKV можно повернуть, создав новую версию, которая может заменить предыдущий ключ, созданный в SQL Server.
  • Для смены ключей вручную необходимо создать новый асимметричный ключ SQL Server, ссылающийся на ключ без версий или ключ версии, который был повернут в AKV. Для нового асимметричного ключа SQL Server ключ AKV без версии будет автоматически выбран с помощью самой высокой версии ключа в AKV. Для ключа с версией необходимо указать самую высокую версию в AKV с помощью синтаксиса WITH PROVIDER_KEY_NAME = <key_name>/<version>. Ключ шифрования базы данных можно изменить для повторного шифрования с помощью нового асимметричного ключа. С политикой смены AKV можно использовать то же имя ключа (версия или версия без версии). Для ключа с версиями необходимо добавить текущую версию. Для ключа без версии используйте то же имя ключа.

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

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

    CREATE CREDENTIAL <new_credential_name>
    WITH IDENTITY = <key vault>,
    SECRET = 'existing/new secret'
    FOR CRYPTOGRAPHIC PROVIDER AzureKeyVault_EKM;

  2. Добавьте учетные данные в субъект:

    ALTER LOGIN [domain\userName];
ADD CREDENTIAL <new_credential_name>;

  3. Создайте асимметричный ключ на основе нового ключа (после поворота ключа). Новый ключ может быть ключом без версии (ContosoRSAKey0 в нашем примере) или ключом с версиями (ContosoRSAKey0/1a4d3b9b393c4678831ccc60def75379 где 1a4d3b9b393c4678831ccc60def75379 версия обновленного ключа в AKV):

    CREATE ASYMMETRIC KEY <new_ekm_key_name>
 FROM PROVIDER [AzureKeyVault_EKM]  
 WITH PROVIDER_KEY_NAME = <new_key_from_key_vault>,  
 CREATION_DISPOSITION = OPEN_EXISTING;

  4. Создайте новое имя входа из нового асимметричного ключа:

    CREATE LOGIN <new_login_name>
FROM ASYMMETRIC KEY <new_ekm_key_name>;

  5. Удалите учетные данные из субъекта:

    ALTER LOGIN [domain\username]
DROP CREDENTIAL <new_credential_name>;

  6. Сопоставление учетных данных AKV с новым именем входа:

    ALTER LOGIN <new_login_name>;
ADD CREDENTIAL <new_credential_name>;

  7. Измените ключ шифрования базы данных (DEK) для повторного шифрования с помощью нового асимметричного ключа:

    USE [databaseName];
GO
ALTER DATABASE ENCRYPTION KEY ENCRYPTION BY SERVER ASYMMETRIC KEY <new_ekm_key_name>;

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

    SELECT encryptor_type, encryption_state_desc, encryptor_thumbprint 
FROM sys.dm_database_encryption_keys 
WHERE database_id = DB_ID('databaseName');

    Этот отпечаток должен соответствовать разделу реестра по пути HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider\Azure Key Vault\<key_vault_url>\<thumbprint> и дать вам повернутый KeyUri ключ.

Внимание

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

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

Связанный контент