Настройка прозрачного шифрования данных с использованием Azure Key Vault для SQL Server

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

В этой статье описана установка и настройка соединителя SQL Server для Azure Key Vault, а затем настройка прозрачное шифрование данных (TDE) с помощью ключа в Azure Key Vault.

Prerequisites

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

Note

Начиная с SQL Server 2022 (16.x) CU 12, SQL Server в Linux поддерживает TDE с расширяемым управлением ключами (EKM) с использованием Azure Key Vault. Шаги 3 и 4 в этом руководстве не требуются для SQL Server на Linux.

Быстрый поток

  1. Выберите модель проверки подлинности на шаге 1. Настройка модели проверки подлинности.
  2. Создайте хранилище ключей и ключ на этапе Шаг 2: Создание хранилища ключей.
  3. Установите соединитель на шаге 3. Установите соединитель SQL Server.
  4. Настройте предварительное требование к реестру на этапе 4: добавьте ключ реестра для поддержки поставщика EKM.
  5. Настройте SQL Server и проверьте шифрование на шаге 5. Настройка SQL Server.

Шаг 1. Настройка модели проверки подлинности

Important

Выберите модель проверки подлинности, прежде чем продолжить:

  • Используйте вкладку субъекта-службы для SQL Server локальной среды.
  • Используйте вкладку "Управляемое удостоверение" для SQL Server на виртуальных машинах Azure или SQL Server, включенных Azure Arc, где поддерживается управляемое удостоверение.

Матрица поддержки модели проверки подлинности:

Модель проверки подлинности версия SQL Server Где выполняется SQL Server Поддерживается
Сервис-принципал Поддерживаемые версии, описанные в этой статье Локальная среда, виртуальная машина Azure, SQL Server с поддержкой Azure Arc Да
Манажируемая идентичность SQL Server 2022 CU17 и более поздние версии виртуальная машина Azure Да
Манажируемая идентичность SQL Server 2025 и более поздних версий SQL Server, управляемый с помощью Azure Arc Да
Манажируемая идентичность Any On-premises Нет

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

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

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

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

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

  2. Зарегистрируйте приложение с помощью Microsoft Entra ID, выполнив следующие действия. Подробные пошаговые инструкции смотрите в разделе Получение удостоверения для приложения записи блога 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. Создание хранилища ключей

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

Note

Поддерживаются только Azure Key Vault и Azure Key Vault Managed HSM. Azure Cloud HSM не поддерживается.

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

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

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

Используйте Azure управление доступом на основе ролей (RBAC) для управления доступом к Azure Key Vault. Не используйте устаревшие политики доступа. Устаревшие политики доступа имеют известные уязвимости безопасности, не поддерживают управление привилегированными пользователями (PIM) и не должны использоваться для критически важных данных и рабочих нагрузок. Дополнительные сведения о разрешениях RBAC в Azure Key Vault см. в статье встроенные роли Azure для операций с плоскостью данных в Key Vault.

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

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

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

  3. Приложению EKM или управляемому удостоверению личности требуется роль Пользователь шифрования криптографической службы Key Vault для выполнения операций обёртывания и развёртывания. Найдите Key Vault Crypto Service Encryption User и выберите роль. Нажмите кнопку Далее.

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

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

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

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

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

Пользователю, который создает ключ, необходима роль Key Vault Administrator. Как и в предыдущих шагах, добавьте участника для создания ключа и назначьте роль.

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

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

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

Настройте управляемый HSM в Azure Key Vault (необязательно)

Управляемый HSM Azure Key Vault (аппаратный модуль безопасности) поддерживает SQL Server и SQL Server на виртуальных машинах Azure (VM) при использовании последней версии SQL Server Connector, а также Azure SQL. Управляемый HSM — это полностью управляемая, высокодоступная, однотенантная служба HSM. Управляемый модуль HSM обеспечивает безопасную основу для криптографических операций и хранилища ключей. Управляемый модуль HSM предназначен для удовлетворения самых строгих требований к безопасности и соответствию требованиям.

На шаге 2 показано, как создать хранилище ключей и ключ в Azure Key Vault. При необходимости можно использовать управляемый модуль HSM Azure Key Vault для хранения или создания ключа для соединителя SQL Server. Выполните следующие действия:

  1. Создайте управляемый модуль HSM Azure Key Vault с помощью портала Azure, Azure CLI, PowerShell или шаблона ARM.

  2. Активация управляемого модуля HSM. Только назначенные администраторы, назначенные во время создания, могут активировать его. В портале Azure выберите ресурс управляемого HSM, а затем выберите Скачать домен безопасности в меню Обзор. Воспользуйтесь одним из кратких руководств, чтобы активировать управляемый модуль HSM.

  3. Предоставьте разрешения субъекту-службе Microsoft Entra или управляемому удостоверению для доступа к управляемому HSM. Роль администратора управляемого HSM не предоставляет разрешения на создание ключа. Как и на шаге 2, приложению EKM или управляемому удостоверению необходима роль Managed HSM Crypto User или Managed HSM Crypto Service Encryption User для выполнения операций wrap и unwrap. Дополнительные сведения см. в статье о встроенных ролях локального RBAC для управляемого устройства HSM.

  4. В меню службы управляемого HSM в Azure Key Vault в разделе "Параметры" выберите "Ключи". В окне "Ключи" выберите "Создать/импортировать и восстановить резервную копию", чтобы создать ключ или импортировать существующий ключ.

    Note

    Алгоритмы RSA-HSM_2048 и RSA-HSM_3072 поддерживаются начиная с накопительного обновления 13 SQL Server 2022 г. (16.x).

    Azure Key Vault Managed HSM поддерживает автоматическую смену ключей. Дополнительные сведения см. в разделе "Настройка автоматического поворота ключей" в управляемом HSM Azure.

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

Шаг 3. Установка соединителя SQL Server

Попросите администратора SQL Server скачать последнюю версию коннектора SQL Server для Microsoft Azure Key Vault из Центра загрузки Майкрософт и запустить установщик.

Снимок экрана мастера установки соединителя SQL Server.

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

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

Установщик также предлагает примеры скриптов для шифрования SQL Server.

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

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

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

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

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

  2. SQL Server Cryptographic Provider Создайте раздел реестра по адресуHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider.

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

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

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

  5. Выберите Применить, а затем ОК.

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

    Note

    Если вы используете 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

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

Этап 1. Настройка поставщика шифрования и учетных данных в 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 в качестве поставщика EKM в SQL Server.

    Создайте криптографического провайдера с помощью соединителя 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

    Note

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

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

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

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

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

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

      Important

      Удалите дефисы из идентификатора приложения (клиента).

    • Заполните вторую часть аргумента SECRET, используя секрет клиента из шага 1. Последняя строка представляет собой длинную последовательность букв и чисел без дефисов (за исключением дефисов в самом секрете клиента).

    USE master;
CREATE CREDENTIAL sysadmin_ekm_cred
   -- Set IDENTITY to the vault name (public Azure) or full vault hostname without https:// (sovereign clouds / Managed HSM)
   -- See https://learn.microsoft.com/azure/key-vault/general/about-keys-secrets-certificates#dns-suffixes-for-base-url
   WITH IDENTITY = 'DocsSampleEKMKeyVault',
         --<----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.

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

    Независимо от того, создали ли вы новый ключ или импортировали асимметричный ключ на шаге 2. Создайте хранилище ключей, откройте ключ в SQL Server с помощьюCREATE ASYMMETRIC KEY.

    Important

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

    В следующих примерах:

    • Замените EKMSampleASYKey именем, которое вы хотите использовать в SQL Server.
    • Замените ContosoRSAKey0 на имя своего ключа в Azure Key Vault или управляемом модуле HSM.

    Используйте имя ключа без указания версии (рекомендуется для большинства сценариев):

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

    Используйте конкретную версию ключа, если нужно привязать операции к одной версии:

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

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

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

    -- Create a login that associates the asymmetric key with this login
CREATE LOGIN TDE_Login
    FROM ASYMMETRIC KEY EKMSampleASYKey;

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

    SQL Server использует имя входа, созданное из асимметричного ключа (TDE_Login) для операций EKM. Чтобы SQL Server мог получать доступ к Azure Key Vault во время операций шифрования и восстановления, сопоставьте учетные данные с TDE_Login, а не с исходной учетной записью входа, созданной при установке.

    -- Remove the service principal credential from the original setup login
ALTER LOGIN [<domain>\<login>]
   DROP CREDENTIAL sysadmin_ekm_cred;

-- Map the service principal credential to the login created from the asymmetric key
ALTER LOGIN TDE_Login
   ADD CREDENTIAL sysadmin_ekm_cred;

Этап 2. Шифрование и проверка пользовательской базы данных

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

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

    -- Create a test database for the TDE example.
CREATE DATABASE TestTDE;

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

    USE TestTDE;
-- Create a DEK protected by the EKM asymmetric key.
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER ASYMMETRIC KEY EKMSampleASYKey;

  3. Включите TDE в базе данных, задав параметр ENCRYPTION ON.

    -- Enable TDE for the database.
ALTER DATABASE TestTDE
    SET ENCRYPTION ON;

Проверка использования ключа и состояния шифрования

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

    SELECT name,
       algorithm_desc,
       thumbprint
FROM sys.asymmetric_keys;

    Инструкция возвращает результат, аналогичный приведённому ниже:

    name            algorithm_desc    thumbprint
EKMSampleASYKey RSA_2048          <key thumbprint>

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

    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>

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

Очистка

Используйте шаги очистки, соответствующие настроенной модели проверки подлинности.

  1. Очистите тестовые объекты, созданные в этой процедуре.

    -- CLEAN UP: shared objects + service principal credential
USE master;
GO
ALTER DATABASE [TestTDE] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DROP DATABASE [TestTDE];
GO

DROP LOGIN [TDE_Login];
GO

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

DROP CREDENTIAL [sysadmin_ekm_cred];
GO

  2. Проверьте, следует ли удалить раздел реестра SQL Server Cryptographic Provider.

    Important

    Раздел SQL Server Cryptographic Provider реестра не удаляется автоматически после удаления ключей EKM.

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

    Путь к реестру: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SQL Server Cryptographic Provider

Ротация асимметричных ключей для TDE в Azure Key Vault

Используйте выделенное рабочее руководство для этапов смены ключей, включая сценарии, проверки подлинности и проверки безопасности:

Important

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

Связанные материалы

  • Last updated on