Поделиться через

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

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

Примечание.

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

Льготы

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

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

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

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

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

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

  • Получение доступа к публичной части и свойствам ключа в хранилище ключей.
  • Список: список версий ключа, хранящегося в Key Vault.
  • Оболочечный ключ: Чтобы иметь возможность зашифровать DEK. Зашифрованный deK хранится в База данных Azure для MySQL гибком экземпляре сервера.
  • Распаковка ключа: чтобы быть в состоянии расшифровать 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): ключ шифрования, используемый для шифрования ключей шифрования данных (DEK). Ключ 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 Insights.

Примечание.

Изменение разрешений может отразиться на хранилище ключей с задержкой до 10 минут. К ним относятся отмена разрешений доступа к предохранителю TDE в AKV, а пользователи в течение этого периода времени могут по-прежнему иметь разрешения на доступ.

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

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

  • Хранилище ключей и База данных Azure для MySQL гибкий экземпляр сервера должны принадлежать одному клиенту Microsoft Entra. Необходимо поддерживать межтенантное хранилище ключей и гибкое взаимодействие с сервером. При перемещении ресурсов Key Vault после выполнения настройки необходимо перенастроить шифрование данных.
  • Хранилище ключей и База данных Azure для MySQL гибкий экземпляр сервера должен находиться в одном регионе.
  • Включите функцию мягкого удаления в Хранилище ключей с периодом хранения, установленным на 90 дней, чтобы защититься от потери данных в случае случайного удаления ключа (или Хранилища ключей). Действия восстановления и очистки имеют собственные разрешения в политике доступа 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

Примечание.

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

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

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

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

Примечание.

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

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

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

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

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

Примечание.

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

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