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

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для MySQL — гибкий сервер

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

Льготы

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

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

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

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

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

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

• Get: для получения общедоступной части и свойств ключа в хранилище ключей;
• List: для вывода списка версий ключа, хранимых в хранилище ключей;
• Wrap Key: для шифрования ключа DEK, Зашифрованный deK хранится в экземпляре гибкого сервера База данных Azure для MySQL.
• Unwrap Key: для расшифровки зашифрованного ключа DEK. База данных Azure для MySQL Гибкий сервер должен расшифровать deK для шифрования и расшифровки данных.

Если RBAC включен, UMI также должен быть назначена следующая роль:

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

Терминология и описание

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

Ключ шифрования ключей (KEK) — ключ шифрования, используемый для шифрования ключей. Ключ KEK, который всегда остается в Key Vault, позволяет шифровать и контролировать сами ключи DEK. Сущность, у которой есть доступ к ключу KEK, может отличаться от сущности, требующей ключа DEK. Так как KEK требуется для расшифровки деков, KEK фактически является единственной точкой, с помощью которой можно эффективно удалить пакеты DEK, удалив KEK. Ключи DEK, зашифрованные с помощью ключей KEK, хранятся отдельно. Расшифровать ключи DEK может только сущность с доступом к ключу KEK. Дополнительные сведения см. в статье Шифрование неактивных данных.

Принцип работы

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

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

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

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

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

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

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

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

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

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

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

• Если удалить хранилище ключей, экземпляр гибкого сервера База данных Azure для MySQL не сможет получить доступ к ключу и переместится в недоступное состояние. Восстановите хранилище ключей и обновите шифрование данных, чтобы сделать База данных Azure для MySQL гибким экземпляром сервера доступным.
• Если удалить ключ из хранилища ключей, экземпляр гибкого сервера База данных Azure для MySQL не сможет получить доступ к ключу и переместится в недоступное состояние. Восстановите ключ и обновите шифрование данных, чтобы сделать экземпляр гибкого сервера База данных Azure для MySQL доступным.
• Если срок действия ключа, хранящегося в Azure Key Vault, истекает, ключ станет недействительным, и экземпляр гибкого сервера База данных Azure для MySQL перейдет в недоступное состояние. Расширьте дату окончания срока действия ключа с помощью ИНТЕРФЕЙСА командной строки, а затем повторите шифрование данных, чтобы сделать экземпляр гибкого сервера доступным для База данных Azure для MySQL.

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

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

• отзыв выданных серверу разрешений get, list, wrap key или unwrap key для хранилища ключей;
• удаление ключа;
• удаление хранилища ключей;
• изменение правил брандмауэра для хранилища ключей;
• Удаление управляемого удостоверения пользователя, используемого для шифрования на гибком сервере с помощью управляемого клиентом ключа в идентификаторе 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 экземпляра гибкого сервера.
• На восстановленном сервере или сервере-реплике повторно выполните проверку ключа, управляемого клиентом, в интерфейсе настройки шифрования данных, чтобы удостоверению, управляемому пользователем, были предоставлены права Get, List, Wrap key и Unwrap key для ключа, хранящегося в Key Vault.

Следующие шаги

• Шифрование данных с помощью Azure CLI
• Шифрование данных с помощью портал Azure
• Безопасность шифрования неактивных данных
• Проверка подлинности Active Directory