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

  • Статья

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

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

Льготы

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

  • Вы полностью управляете доступом к данным с помощью возможности удалить ключ и сделать базу данных недоступной.
  • Полный контроль над жизненным циклом ключа, включая смену ключа в соответствии с корпоративными политиками
  • Централизованное управление ключами и их организация в Azure Key Vault
  • Возможность реализации разделения обязанностей между сотрудниками службы безопасности, 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 для шифрования и расшифровки данных.

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

Ключ шифрования данных (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 в хранилище ключей для расшифровки при необходимости.

Diagram of how data encryption with a customer-managed key work.

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

Примечание.

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

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

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

  • Хранилище ключей и База данных 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).

Примечание.

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

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

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

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

Примечание.

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

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

Когда вы настроите в 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.

Примечание.

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

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