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

Статья
06/01/2023

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

Внимание

База данных Azure для MySQL один сервер находится на пути выхода на пенсию. Настоятельно рекомендуется выполнить обновление до База данных Azure для MySQL гибкого сервера. Дополнительные сведения о миграции на гибкий сервер База данных Azure для MySQL см. в статье "Что происходит с одним сервером База данных Azure для MySQL?"

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

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

Key Vault — это облачная внешняя система управления ключами. Он высокодоступен и предоставляет масштабируемое, безопасное хранилище для криптографических ключей RSA, при необходимости поддерживаемое FIPS 140 проверенными аппаратными модулями безопасности (HSM). Эта система запрещает прямой доступ к хранящемуся ключу, но предоставляет авторизованным сущностям службы шифрования и расшифровки. Key Vault может создать ключ, импортировать его или передать с локального устройства HSM.

Примечание.

Эта функция поддерживается только в хранилище общего назначения версии 2 (поддержка до 16 ТБ), доступном для ценовых категорий "Общее назначение" и "Оптимизированные для операций в памяти". Дополнительные сведения см. в статье Основные понятия службы хранилища. Другие ограничения описаны в этом разделе.

Льготы

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

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

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

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

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

Ключи DEK, зашифрованные с помощью ключей KEK, хранятся отдельно. Расшифровать ключи DEK может только сущность с доступом к ключу KEK. Дополнительные сведения см. в статье Шифрование неактивных данных.

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

Diagram that shows an overview of Bring Your Own Key

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

get: для получения общедоступной части и свойств ключа в хранилище ключей.
wrapKey: для шифрования DEK. Зашифрованный ключ DEK хранится в Базе данных Azure для MySQL.
unwrapKey: Чтобы быть в состоянии расшифровать DEK. Службе "База данных Azure для MySQL" требуются расшифрованные ключи DEK для шифрования и расшифровки данных.

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

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

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

Ниже приведены требования к настройке Key Vault.

Key Vault и База данных Azure для MySQL должны принадлежать одному клиенту Microsoft Entra. Взаимодействие между Key Vault и сервером, размещенными в разных клиентах, не поддерживается. При последующем перемещении ресурса Key Vault требуется перенастроить шифрование данных.
В хранилище ключей следует включить функцию обратимого удаления с периодом хранения 90 дней, чтобы избежать потери данных в случае непреднамеренного удаления ключа (или Key Vault). Ресурсы с обратимым удалением по умолчанию хранятся в течение 90 дней, если срок хранения установлен меньше или равным 90 дней. С действиями "Восстановить" и "Удалить" связаны отдельные разрешения в политике доступа хранилища ключей. Функция обратимого удаления отключена по умолчанию, но ее можно включить с помощью PowerShell или Azure CLI (обратите внимание, что ее нельзя включить на портале Azure).
Включите функцию защиты от очистки в хранилище ключей, задав период хранения в 90 дней. Защиту от удаления можно включить только после включения обратимого удаления. Ее можно включить с помощью Azure CLI или PowerShell. Если защита от удаления включена, хранилище или объект в удаленном состоянии нельзя удалить безвозвратно, пока не пройдет период хранения. Безопасно удаленные хранилища и объекты по-прежнему можно восстановить с гарантированным соблюдением политики хранения.
Предоставьте отдельной Базе данных Azure для MySQL доступ к хранилищу ключей с разрешениями get, wrapKey и unwrapKey, используя его уникальное управляемое удостоверение. Это уникальное удостоверение службы автоматически создается на портале Azure при включении шифрования данных в MySQL. Подробные пошаговые инструкции по использованию портала Azure см. в статье о настройке шифрования данных для MySQL.

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

Управляемый клиентом ключ, используемый для шифрования ключа DEK, может быть только асимметричным 2048-битным ключом RSA.
Дата активации ключа (если задана) должна быть датой и временем в прошлом. Дата окончания срока действия не задана.
Ключ должен находиться в состоянии Включено.
Для ключа должно быть настроено обратимое удаление с периодом хранения в 90 дней. Это неявно задает для ключевого атрибута recoveryLevel необходимое значение "Recoverable". Если задан период хранения < 90 дней, для ключевого атрибута recoveryLevel устанавливается значение CustomizedRecoverable, которое не соответствует требованиям. Поэтому убедитесь в том, что задан период хранения 90 дней.
Для ключа должна быть включена защита от очистки.
Если вы импортируете существующий ключ в хранилище ключей, обязательно укажите его в поддерживаемом формате файла (.pfx, .byok, .backup).

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

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

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

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

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

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

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

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

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

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

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

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

Запустите процесс восстановления или создания реплики чтения в исходной Базе данных Azure для MySQL.
Оставьте созданный сервер (восстановленный сервер или сервер-реплику) в недоступном состоянии, так как его уникальному удостоверению еще не предоставлены разрешения для Key Vault.
На восстановленном сервере или сервере-реплике повторно проверьте ключ, управляемый клиентом, в параметрах шифрования данных, чтобы созданному серверу были предоставлены разрешения на упаковку и распаковку ключа, хранящегося в Key Vault.

Ограничения

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

Поддержка этой функции ограничена ценовыми категориями Общего назначения и Оптимизированная для операций в памяти.
Эта функция доступна только для регионов и серверов, поддерживающих хранилище общего назначения версии 2 (до 16 ТБ). Список регионов Azure, поддерживающих хранилище объемом до 16 ТБ, см. в документации в разделе о хранилищах.
Примечание.
- Для всех новых серверов MySQL, созданных в регионах Azure, поддерживающих хранилище общего назначения версии 2, доступно шифрование данных с использованием ключей, управляемых клиентом. Сервер, восстановленный до точки во времени (PITR), или реплика чтения не считаются новыми, хотя теоретически они таковыми являются.
- Чтобы проверить, поддерживает ли подготовленный сервер хранилище общего назначения версии 2, перейдите в колонку ценовой категории на портале и посмотрите на максимальный размер хранилища, поддерживаемый подготовленным сервером. Если ползунок можно переместить максимум до 4 ТБ, сервер включен в хранилище общего назначения версии 1 и не будет поддерживать шифрование с использованием ключей, управляемых клиентом. Тем не менее данные все время шифруются с помощью управляемых службой ключей. Если у вас возникнут вопросы или вам понадобится помощь, напишите по адресу AskAzureDBforMySQL@service.microsoft.com.
Шифрование поддерживается только с использованием криптографического ключа RSA 2048.

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

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

Share via