Шифрование данных в Базе данных Azure для MySQL с помощью портала Azure
ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для MySQL — отдельный сервер
Внимание
База данных Azure для MySQL один сервер находится на пути выхода на пенсию. Настоятельно рекомендуется выполнить обновление до База данных Azure для MySQL гибкого сервера. Дополнительные сведения о миграции на гибкий сервер База данных Azure для MySQL см. в статье "Что происходит с одним сервером База данных Azure для MySQL?"
Узнайте, как использовать портал Azure, чтобы настроить шифрование данных в Базе данных Azure для MySQL и управлять им.
Необходимые условия для Azure CLI
Подписка Azure и права администратора для нее.
В Azure Key Vault создайте хранилище ключей и ключ, который будет использоваться для ключа, управляемого клиентом.
Чтобы использовать ключ, управляемый клиентом, хранилище ключей должно иметь следующие свойства:
-
az resource update --id $(az keyvault show --name \ <key_vault_name> -o tsv | awk '{print $1}') --set \ properties.enableSoftDelete=true
-
az keyvault update --name <key_vault_name> --resource-group <resource_group_name> --enable-purge-protection true
Заданный период удержания — 90 дней
az keyvault update --name <key_vault_name> --resource-group <resource_group_name> --retention-days 90
-
Чтобы использовать ключ в качестве управляемого клиентом, он должен иметь следующие атрибуты:
- без даты окончания срока действия;
- не отключено;
- Выполните операции get, wrap и unwrap
- Для атрибута "recoverylevel" задано значение Восстанавливаемый (для этого требуется включить обратимое удаление с периодом удержания 90 дней)
- Защита от очистки включена
Вы можете проверить атрибуты ключа, описанные выше, с помощью следующей команды:
az keyvault key show --vault-name <key_vault_name> -n <key_name>
У Базы данных Azure для MySQL отдельный сервер должен быть общего назначения или ценовой категории с оптимизацией для операций в памяти, а хранилище — категории общего назначения версии 2. Прежде чем продолжить, ознакомьтесь с ограничениями шифрования данных с помощью ключей, управляемых клиентом.
Задайте правильные разрешения для операций с ключами.
В Key Vault выберите Политики доступа>Добавить политику доступа.
Нажмите Разрешения ключей и выберите Get, Wrap, Unwrap и Субъект — это имя сервера MySQL. Если субъект сервера не найден в списке существующих субъектов, его необходимо зарегистрировать. Вам будет предложено зарегистрировать субъект сервера, если не удастся настроить шифрование данных с первой попытки.
Выберите Сохранить.
Настройка шифрования данных в Базе данных Azure для MySQL
В Базе данных Azure для MySQL выберите Шифрование данных, чтобы настроить ключ, управляемый клиентом.
Можно выбрать хранилище ключей и пару ключей или ввести идентификатор ключа.
Выберите Сохранить.
Чтобы все файлы (включая временные) были полностью зашифрованы, перезапустите сервер.
Использование шифрования данных для серверов восстановления или реплик
После шифрования Базы данных Azure для MySQL с помощью управляемого ключа клиента, хранящегося в Key Vault, все создаваемые копии сервера также шифруются. Новую копию можно создать с помощью операции локального восстановления или геовосстановления либо с помощью операции реплики (локальной или между регионами). Чтобы создать зашифрованный восстановленный сервер, для зашифрованного сервера MySQL можно выполнить следующие действия.
На сервере выберите Обзор>Восстановление.
Или в случае сервера с поддержкой репликации в разделе Параметры выберите Репликация.
После завершения операции восстановления новый сервер будет зашифрован с помощью ключа главного сервера. Однако возможности и параметры на сервере отключены и сервер недоступен. Операции с данными выполнять невозможно, так как удостоверению нового сервера еще не было предоставлено разрешение на доступ к хранилищу ключей.
Чтобы сделать сервер доступным, выполните повторную проверку ключа на восстановленном сервере. Выберите Шифрование данных>Повторная проверка ключа.
Примечание.
Первая попытка повторной проверки будет неудачной, так как субъекту-службе нового сервера необходимо предоставить доступ к хранилищу ключей. Чтобы создать субъект-службу, выберите пункт Повторная проверка ключа, при этом появляется сообщение об ошибке, но создается субъект-служба. После этого вернитесь к шагам, описанным в начале этой статьи.
Необходимо предоставить хранилищу ключей доступ к новому серверу. Подробнее см. в статье Назначение политики доступа Key Vault.
После регистрации субъекта-службы снова выполните повторную проверку ключа, и сервер возобновит нормальную работу.
Следующие шаги
Обратная связь
https://aka.ms/ContentUserFeedback.
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделеОтправить и просмотреть отзыв по