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

Статья
03/30/2023

Область применения: отдельный сервер Базы данных Azure для PostgreSQL

Внимание

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

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

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

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

Примечание.

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

Льготы

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

Полный контроль доступа к данным с возможностью удалить ключ и сделать базу данных недоступной.
Полный контроль жизненного цикла ключей, включая смену ключей в соответствии с корпоративными политиками.
Централизованное управление ключами и их организация в Azure Key Vault.
Включение шифрования не оказывает никакого дополнительного влияния на производительность независимо от использования ключа, управляемого клиентом (CMK), так как PostgreSQL полагается на уровень хранилища Azure для шифрования данных в обоих сценариях. Единственным отличием является использование CMK в качестве ключа шифрования службы хранилища Azure. В этом случае данные фактически зашифровываются с помощью CMK.
Возможность разделения обязанностей между специалистами по обеспечению безопасности, администраторами баз данных и системными администраторами.

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

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

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

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

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

Схема, на которой показан обзор подхода

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ограничения

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

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

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

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