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

Вы можете использовать собственные ключи (BYOK) для шифрования данных на Azure Database для MySQL с управлением ключами пользователем, что позволяет внедрить разделение обязанностей в управлении ключами и данными для улучшенной защиты данных на стадии хранения. С помощью ключей управления, контролируемых клиентом (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/key/read, например "Пользователь шифрования криптослужбы Key Vault"
• Для управляемого устройства HSM назначьте роль пользователя шифрования управляемой криптослужбы HSM

Шифрование данных с помощью ключей, управляемых клиентом, задается на уровне сервера. Для данного сервера 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Непреднамеренный отзыв доступа к ключу из 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 на ключ.

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

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