Шифрование данных с помощью ключей, управляемых клиентом для Базы данных Azure для MySQL

Используя шифрование данных с помощью управляемых клиентом ключей в База данных Azure для MySQL, можно использовать свой ключ (BYOK) для защиты данных при хранении, чтобы разделить обязанности по управлению ключами и данными. При использовании управляемых клиентом ключей (CMKs) вы управляете:

  • Управление жизненным циклом ключей, включая создание ключей, отправку, смену и удаление
  • Разрешения на использование ключей
  • Аудит операций с ключами

Преимущества управляемых клиентом ключей (CMK)

Шифрование данных с помощью управляемых клиентом ключей для Базы данных Azure для MySQL обеспечивает следующие преимущества:

  • Вы полностью управляете доступом к данным, удаляя ключ и делая базу данных недоступной.
  • У вас есть полный контроль над жизненным циклом ключа, включая смену ключа в соответствии с корпоративными политиками.
  • Вы можете централизованно управлять ключами и упорядочивать их в Azure Key Vault или управляемом HSM.
  • Вы можете реализовать разделение обязанностей между сотрудниками службы безопасности, DBA и системными администраторами.

Как работает шифрование данных с помощью управляемого клиентом ключа?

Управляемые удостоверения в Microsoft Entra ID обеспечивают более безопасный способ аутентификации клиентов в службах. Шифрование CMK использует управляемое удостоверение сервера Базы данных Azure для MySQL для подключения к Azure Key Vault, в котором хранится CMK. База данных Azure для MySQL в настоящее время поддерживает только назначаемое пользователем управляемое удостоверение (UAMI) для доступа к Key Vault. Дополнительные сведения см. в разделе Типы управляемых удостоверений в Azure.

Чтобы настроить CMK для База данных Azure для MySQL, свяжите UAMI с сервером и укажите Azure Key Vault и ключ для использования.

UAMI должен иметь следующий доступ к хранилищу ключей:

  • Получение доступа к публичной части и свойствам ключа в хранилище ключей.
  • Список: перечисление версий ключа, хранящегося в Key Vault.
  • Ключ оболочки: для шифрования DEK. Зашифрованный DEK хранится в экземпляре гибкого сервера База данных Azure для MySQL.
  • Ключ развёртывания: для расшифровки DEK. Для База данных Azure для MySQL требуется расшифрованный DEK для шифрования или расшифровки данных.

Если включена Azure RBAC, назначьте роли UAMI вместо отдельного доступа.

  • Пользователь для шифрования в криптографическом сервисе Key Vault или роль с разрешениями:
    • Microsoft.KeyVault/vaults/keys/wrap/action
    • Microsoft.KeyVault/vaults/keys/unwrap/action
    • Microsoft.KeyVault/vaults/keys/read, например "Пользователь службы шифрования Key Vault"
  • Для управляемого устройства HSM назначьте роль пользователя шифрования управляемой криптослужбы HSM

Задайте шифрование данных с помощью cmKs на уровне сервера. Для данного сервера используйте CMK, называемый ключом шифрования ключей (KEK), для шифрования ключа шифрования данных службы (DEK). KEK — это асимметричный ключ, хранящийся в экземпляре Azure Key Vault, управляемом клиентом. Key Vault — это высокодоступное и масштабируемое безопасное хранилище для криптографических ключей RSA, при необходимости поддерживаемое FIPS 140 проверенными аппаратными модулями безопасности (HSM). Key Vault не предоставляет прямой доступ к сохранённому ключу, а вместо этого предоставляет авторизованным объектам службы шифрования и дешифрования с использованием этого ключа. Хранилище ключей может создать ключ или передать его в хранилище ключей с локального устройства HSM.

При настройке гибкого сервера для использования CMK, хранящегося в хранилище ключей, сервер отправляет DEK в хранилище ключей для шифрования. Key Vault возвращает зашифрованный deK, хранящийся в пользовательской базе данных. Аналогичным образом гибкий сервер отправляет защищенный deK в хранилище ключей для расшифровки при необходимости.

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

После включения ведения журнала аудиторы могут использовать Azure Monitor для проверки журналов событий аудита Key Vault. Чтобы включить ведение журнала событий аудита Key Vault, см. раздел о мониторинге службы хранилища ключей с помощью Key Vault Insights.

Note

Изменение разрешений может отразиться на хранилище ключей с задержкой до 10 минут.

Требования к настройке шифрования данных для Базы данных Azure для MySQL

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

  • Хранилище ключей и экземпляр гибкого сервера База данных Azure для MySQL должны принадлежать одному и тому же арендатору Microsoft Entra. Необходимо поддерживать межтенантное хранилище ключей и гибкое взаимодействие с сервером. При перемещении Key Vault ресурсов после выполнения настройки необходимо перенастроить шифрование данных.
  • Хранилище ключей и экземпляр гибкого сервера База данных Azure для MySQL должны находиться в одном регионе.
  • Включите функцию мягкого удаления для хранилища ключей.
  • Включите защиту очистки.
  • Задайте срок хранения 90 дней.
    • Действия восстановления и очистки имеют собственные разрешения в политике доступа Key Vault.
    • Функция обратимого удаления отключена по умолчанию.

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

  • Управляемый клиентом ключ для шифрования DEK может быть асимметричным, RSA\RSA-HSM(Vaults with Premium SKU) 2048, 3072 или 4096.
  • Дата активации ключа (если задана) должна быть датой и временем в прошлом. Дата окончания срока действия не задана.
  • Ключ должен находиться в состоянии Включено.
  • Ключ должен иметь обратимое удаление с периодом хранения, равным 90 дней. Этот параметр неявно задает обязательный ключевой атрибут recoveryLevelRecoverable.
  • Ключ должен иметь включенную защиту очистки.
  • Если вы импортируете существующий ключ в хранилище ключей, обязательно предоставьте его в поддерживаемых форматах файлов (.pfx, .byok, ). .backup

Note

Подробные пошаговые инструкции по настройке шифрования данных см. в статье "Шифрование данных для Базы данных Azure для MySQL" с помощью портала Azure или шифрования данных для Базы данных Azure для MySQL — гибкий сервер с помощью Azure CLI.

Рекомендации по настройке шифрования данных

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

  • Установите блокировку ресурсов в Key Vault, чтобы управлять правами на удаление этого критически важного ресурса и предотвратить случайное или несанкционированное удаление.
  • Включите аудит и отчеты обо всех ключах шифрования. Key Vault предоставляет журналы, которые можно легко передать в любые средства управления информационной безопасностью и событиями безопасности.
  • Храните копию ключа, управляемого клиентом, в надежном месте или передайте ее в службу депонирования.
  • Если ключ создается в Key Vault, создайте резервную копию ключа перед его первым использованием. Резервную копию можно восстановить только в Key Vault. Дополнительные сведения о команде резервного копирования см. в разделе Backup-AzKeyVaultKey.

Note

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

Состояние недоступности ключа, управляемого клиентом

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

Если удалить хранилище ключей, экземпляр гибкого сервера База данных Azure для MySQL не сможет получить доступ к ключу и перейдет в состояние Inaccessible. Чтобы сделать экземпляр Availableсервера:

Если удалить ключ из хранилища ключей, экземпляр гибкого сервера База данных Azure для MySQL не сможет получить к нему доступ и перейдет в состояние Inaccessible. Чтобы сделать экземпляр Availableсервера:

  • Восстановите ключ.
  • Повторная проверка шифрования данных.

Note

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

Непреднамеренный отзыв доступа к ключу из Key Vault

Кто-то с достаточными правами доступа для Key Vault может случайно отключить гибкий доступ к ключу:

  • Отмена разрешений ключевого хранилища на получение, перечисление, заворачивание и разворачивание ключа на сервере.
  • удаление ключа;
  • удаление хранилища ключей;
  • изменение правил брандмауэра для хранилища ключей;
  • Удаление управляемого удостоверения пользователя, используемого для шифрования на гибком сервере с помощью управляемого клиентом ключа в идентификаторе Microsoft Entra

Мониторинг управляемого клиентом ключа в Key Vault

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

  • Журнал действий: Если доступ к ключу клиента в управляемом клиентом Key Vault не удается, записи добавляются в журнал действий. Создав правила генерации оповещений для таких событий, вы сможете максимально быстро восстанавливать доступ.
  • Группы действий. Определите эти группы для отправки уведомлений и оповещений на основе ваших предпочтений.

Реплика с ключом, управляемым клиентом, в Key Vault

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

Восстановление с использованием сохраненного в Key Vault ключа, управляемого клиентом

При восстановлении гибкого экземпляра сервера База данных Azure для MySQL выберите управляемое пользователем удостоверение и ключ для шифрования сервера восстановления. Если экземпляр гибкого сервера База данных Azure для MySQL настроен на использование геоизбыточного резервного копирования, необходимо настроить сервер, на который выполняется восстановление, с управляемой идентификацией и ключом, к которым эта идентификация имеет доступ и которые находятся в геопарном регионе сервера.

При восстановлении или создании реплики для чтения выполните следующие действия на исходном и восстановленном серверах или на сервере реплики:

  • Запустите процесс восстановления или создания реплики чтения для исходного экземпляра гибкого сервера База данных Azure для MySQL.
  • На восстановленном сервере или на сервере-реплике повторно выполните проверку CMK в параметрах шифрования данных, чтобы проверить наличие у UAMI разрешений на доступ к ключу.

Note

При восстановлении не нужно использовать то же удостоверение (UAMI) и ключ, что и на исходном сервере.

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

  • Last updated on