Шифрование неактивных данных в Базе данных Azure для PostgreSQL

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

Шифрование неактивных данных с помощью службы (SMK) или управляемых клиентом ключей (CMK)

База данных Azure для PostgreSQL поддерживает два режима шифрования неактивных данных: ключи, управляемые службой (SMK) и управляемые клиентом ключи (CMK). Шифрование данных с помощью управляемых службой ключей — это режим по умолчанию для гибкого сервера Базы данных Azure для PostgreSQL. В этом режиме служба автоматически управляет ключами шифрования, используемыми для шифрования данных. Вам не нужно предпринимать никаких действий для включения или управления шифрованием в этом режиме.

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

Режим можно выбрать только во время создания сервера. Его нельзя изменить с одного режима на другой в течение всего времени существования сервера.

Чтобы обеспечить шифрование данных, База данных Azure для PostgreSQL использует шифрование службы хранилища Azure для неактивных данных. При использовании CMK клиент отвечает за предоставление ключей для шифрования и расшифровки данных в службах Хранилище BLOB-объектов и Файлы Azure. Эти ключи должны храниться в Azure Key Vault или управляемом аппаратном модуле безопасности Azure Key Vault (HSM). Дополнительные сведения см. в разделе "Ключи, управляемые клиентом" для шифрования службы хранилища Azure.

Преимущества, предоставляемые каждым режимом (SMK или CMK)

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

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

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

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

Требования CMK

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

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

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

Ниже приведен список требований к настройке шифрования данных для Базы данных Azure для PostgreSQL:

  • Для конфигураций CMK для одного арендатора Key Vault и экземпляр гибкого сервера База данных Azure для PostgreSQL должны принадлежать одному и тому же арендатору Microsoft Entra. Описание межтенантных сценариев см. в разделе Межтенантные ключи, управляемые клиентом. После перемещения ресурса Key Vault необходимо перенастроить шифрование данных.
  • Мы рекомендуем задать параметры "Дни", чтобы сохранить конфигурацию удаленных хранилищ для Key Vault до 90 дней. Если вы настроили существующий экземпляр Key Vault с меньшим значением, он по-прежнему будет считаться допустимым. Однако если вы хотите изменить этот параметр и увеличить значение, необходимо создать новый экземпляр Key Vault. После создания экземпляра невозможно изменить этот параметр.
  • Включите функцию обратимого удаления в Key Vault, чтобы помочь вам защититься от потери данных, если ключ или экземпляр Key Vault случайно удален. Key Vault сохраняет ресурсы, помеченные как обратимо удаленные, в течение 90 дней, если пользователь не восстановит или не удалит их безвозвратно за это время. Действия восстановления и очистки имеют свои собственные разрешения, связанные с ролью RBAC Key Vault или разрешением политики доступа. Функция мягкого удаления включена по умолчанию. Если у вас есть хранилище Key Vault, развернутое уже давно, возможно, в нём всё ещё отключено обратимое удаление. В этом случае его можно включить с помощью Azure CLI.
  • Включите защиту очистки для принудительного применения обязательного периода хранения для удаленных хранилищ и объектов хранилища.
  • Предоставьте управляемому удостоверению пользователя доступ к ключу для экземпляра гибкого сервера базы данных Azure для PostgreSQL.
  • Предпочтительный вариант: Azure Key Vault следует настроить с моделью разрешений RBAC, а управляемому удостоверению должна быть присвоена роль пользователя шифрования службы шифрования Key Vault.
  • Устаревшее: если в Azure Key Vault настроена модель разрешений политики доступа, предоставьте управляемой идентичности следующие разрешения:
  • get: Чтобы получить свойства и общедоступную часть ключа в Key Vault.
  • list: перечислять и перебирать ключи, хранящиеся в Key Vault.
  • wrapKey: шифрование ключа шифрования данных.
  • unwrapKey: для расшифровки ключа шифрования данных.
  • Ключ, используемый для шифрования ключа шифрования данных, может быть асимметричным, RSA или RSA-HSM. Поддерживаются ключевые размеры 2 048, 3 072 и 4096. Мы рекомендуем использовать 4096-разрядный ключ для повышения безопасности.
  • Дата и время активации ключа (если задано) должно находиться в прошлом. Дата и время окончания срока действия (если заданы) должны быть установлены на будущее время.
  • Ключ должен находиться в состоянии "Включено ".
  • Если вы импортируете существующий ключ в Key Vault, укажите его в поддерживаемых форматах файлов (.pfxили.byok.backup).

Обновления версий ключа CMK

CMK можно настроить для ручной ротации ключей и их обновления либо для автоматического обновления версий ключей после ручной или автоматической ротации ключей в Key Vault.

Дополнительные сведения см. в разделе "Настройка шифрования данных с помощью управляемого клиентом ключа во время подготовки сервера".

Это важно

При смене ключа на новую версию необходимо сохранить старый ключ доступным для успешного повторного шифрования. Хотя большинство повторной расшифровки должны выполняться в течение 30 минут, рекомендуется подождать не менее 2 часов, прежде чем отключить доступ к старой версии ключа.

Ручная смена ключей и обновление

При настройке CMK с обновлениями ключей вручную необходимо вручную обновить версию ключа в гибком экземпляре сервера Базы данных Azure для PostgreSQL после ручной или автоматической смены ключей в Key Vault. Сервер продолжает использовать старую версию ключа, пока не обновите ее. Вы подготавливаете этот режим, указав URI ключа, включая версию GUID в URI. Например: https://<keyvault-name>.vault.azure.net/keys/<key-name>/<key-version>. До недавнего времени это был единственный доступный вариант.

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

Автоматическое обновление версий ключей

Чтобы включить автоматическое обновление версии ключа, используйте URI ключа без указания версии. Этот подход устраняет необходимость обновления свойства версии CMK в экземпляре PostgreSQL после смены ключа. PostgreSQL автоматически выбирает новую версию ключа и повторно шифрует ключ шифрования данных. Это значительно упрощает управление жизненным циклом ключей, особенно в сочетании с авторотацией в Key Vault.

Чтобы реализовать использование Azure Resource Manager, Bicep, Terraform, Azure PowerShell или Azure CLI, опустите версию GUID из URI ключа.

В портале установите флажок, чтобы пользовательский интерфейс скрывал GUID-ы версий при интерактивном выборе и при проверке URI.

Recommendations

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

  • Чтобы предотвратить случайное или несанкционированное удаление этого критического ресурса, задайте блокировку ресурсов в Key Vault.
  • Включите аудит и отчеты обо всех ключах шифрования. Key Vault предоставляет журналы, которые легко внедрить в другие средства управления безопасностью и событиями (SIEM). Azure Monitor Logs — один из уже интегрированных сервисов.
  • Блокировка Key Vault путем отключения общедоступного доступа и разрешения доверенных служб Майкрософт для обхода этого брандмауэра.
  • Включите автоматические обновления версий ключей.

Замечание

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

  • Сохраните копию ключа, управляемого клиентом, в безопасном месте или передайте её на хранение в эскроу-службу.
  • Если Key Vault создает ключ, создайте резервную копию ключей перед первым использованием ключа. Резервную копию можно восстановить только в Key Vault.

Особые соображения

Случайный отзыв ключа доступа из Azure Key Vault

Кто-то с достаточными правами доступа к Key Vault может случайно отключить доступ к ключу:

  • Отмена назначения роли RBAC пользователя службы шифрования Key Vault Crypto Service или отмена разрешений для удостоверения, используемого для получения ключа в Key Vault.
  • удаление ключа;
  • Удаление экземпляра Key Vault.
  • Изменение правил брандмауэра Key Vault.
  • Удаление управляемой идентичности сервера в Microsoft Entra ID.

Мониторинг ключей, хранящихся в Azure Key Vault

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

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

Восстановление резервных копий сервера, настроенного с помощью управляемого клиентом ключа

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

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

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

Управляемые модули HSM

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

Управляемый HSM в Azure Key Vault — это полностью управляемая, высокодоступная, однотенантная и совместимая со стандартами облачная служба. Вы можете использовать его для защиты криптографических ключей для облачных приложений с помощью проверенных HSM FIPS 140-3.

При создании новых экземпляров гибкого сервера Базы данных Azure для PostgreSQL в портале Azure с ключом, управляемым клиентом, можно выбрать Managed HSM в Azure Key Vault в качестве хранилища ключей вместо Azure Key Vault. Предварительные требования с точки зрения определяемых пользователем удостоверений и разрешений совпадают с Azure Key Vault (как описано ранее в этой статье). Дополнительные сведения о создании управляемого экземпляра HSM, его преимуществах и отличиях от общего хранилища сертификатов на основе Key Vault и импорте ключей в управляемый HSM см. в статье "Что такое управляемый HSM Azure Key Vault?".

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

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

Некоторые из возможных причин, по которым состояние сервера может стать недоступным :

Причина Резолюция
Для одного из ключей шифрования, на которые ссылается сервер, были настроены дата и время истечения срока действия, и этот срок наступил. Необходимо продлить срок действия ключа. Затем необходимо подождать, пока служба перенастраит ключ и автоматически переместите состояние сервера в Ready. Только если сервер вернулся в состояние "Готово ", вы можете повернуть ключ на более новую версию или создать новый ключ, а затем обновить сервер таким образом, чтобы он ссылалась на эту новую версию того же ключа или на новый ключ.
Вы выполняете ротацию ключа и забываете обновить экземпляр База данных Azure для PostgreSQL — Flexible Server, чтобы он указывал на новую версию ключа. Старый ключ, на который указывает сервер, истекает срок действия и преобразует состояние сервера в недоступное. Чтобы избежать этой ситуации, каждый раз при ротации ключа обязательно обновляйте экземпляр сервера так, чтобы он указывал на новую версию. Для этого используйте az postgres flexible-server updateследующий пример, описывающий "Изменение ключа или удостоверения для шифрования данных. Шифрование данных не может быть включено после создания сервера, это обновляет только ключ или удостоверение. Если вы предпочитаете обновить его с помощью API, вы можете вызвать конечную точку Servers - Update службы.
Вы удаляете экземпляр Key Vault, гибкий экземпляр сервера Базы данных Azure для PostgreSQL не может получить доступ к ключу и перейти к недоступному состоянию. Восстановите экземпляр Key Vault и дождитесь, пока служба выполнит периодическую повторную проверку ключа и автоматически переведёт состояние сервера в Ready.
Вы удаляете из Microsoft Entra ID управляемый идентификатор, который используется для получения любого ключа шифрования, хранящегося в Key Vault. Восстановите удостоверение и подождите , пока служба выполнит периодическую повторную отмену ключа, а затем автоматически переместите состояние сервера в Готово.
Модель разрешений Key Vault настроена для использования управления доступом на основе ролей. Вы удаляете назначение роли RBAC Key Vault Crypto Service Encryption User из управляемых удостоверений, которые настроены для доступа к любым ключам. Снова назначьте роль RBAC для управляемой идентификации и дождитесь, пока служба выполнит периодическую повторную проверку ключа и автоматически переведет сервер в состояние Ready. Альтернативный подход состоит в предоставлении роли в Key Vault другому управляемому удостоверению и обновлении сервера таким образом, чтобы он использовал это другое управляемое удостоверение для доступа к ключу.
Модель разрешений Key Vault настроена для использования политик доступа. Вы отменяете политики доступа списка, получения, упаковки ключа или распаковки ключа от управляемых удостоверений, настроенных для получения любого из ключей. Повторно назначьте роль RBAC управляемой идентификации и дождитесь, пока служба выполнит периодическую повторную проверку ключа, после чего состояние сервера автоматически перейдет в Ready. Альтернативный подход состоит в предоставлении необходимых политик доступа в Key Vault другому управляемому удостоверению и обновлении сервера таким образом, чтобы он использовал это другое управляемое удостоверение для доступа к ключу.
Вы настраиваете слишком строгие правила брандмауэра Key Vault, чтобы гибкий экземпляр сервера Базы данных Azure для PostgreSQL не смог взаимодействовать с Key Vault для получения ключей. При настройке брандмауэра Key Vault убедитесь, что вы выбрали параметр, позволяющий доверенным службам Microsoft, чтобы гибкий экземпляр сервера базы данных Azure для PostgreSQL мог пройти через брандмауэр.

Замечание

Если ключ отключен, удален, истек или недоступен, сервер с данными, зашифрованными с этим ключом, становится недоступным, как указано ранее. Сервер не перейдет в состояние Ready снова, пока не сможет повторно проверить ключи шифрования.

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

Восстановление после удаления управляемой идентификации

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

  1. Восстановите удостоверение или создайте новое управляемое удостоверение Entra ID.
  2. Если вы создали новое удостоверение, даже если у него то же самое имя, что и до его удаления, обновите свойства экземпляра гибкого сервера в базе данных Azure, чтобы указать, что нужно использовать это новое удостоверение для доступа к ключу шифрования.
  3. Убедитесь, что это удостоверение имеет соответствующие разрешения для операций с ключом в Azure Key Vault (AKV).
  4. Подождите около одного часа, пока сервер не отменит ключ.

Это важно

Просто создание нового идентификатора Entra ID с таким же именем, как у удаленного удостоверения, не восстанавливает удаленное управляемое удостоверение.

Использование шифрования данных с управляемыми клиентом ключами и геоизбыточными функциями непрерывности бизнес-процессов

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

  • Ключ шифрования геоизбыточного резервного копирования необходимо создать в экземпляре Key Vault, который должен существовать в регионе, где хранится геоизбыточное резервное копирование.
  • Версия REST API Azure Resource Manager, поддерживающая серверы CMK с включённым геоизбыточным резервным копированием, — 2022-11-01-preview. Если вы хотите использовать шаблоны Azure Resource Manager для автоматизации создания серверов, использующих шифрование с помощью cmKs и функций геоизбыточного резервного копирования, используйте эту версию API.
  • Вы не можете использовать одно и то же удостоверение, управляемое пользователем, для аутентификации в экземпляре Key Vault основной базы данных и в экземпляре Key Vault, в котором хранится ключ шифрования для геоизбыточного резервного копирования. Чтобы обеспечить устойчивость регионов, рекомендуется создать управляемое пользователем удостоверение в том же регионе, что и геоизбыточные резервные копии.
  • Если при создании базы данных реплики для чтения настроить её шифрование с помощью CMK, ключ шифрования этой базы данных должен находиться в экземпляре Key Vault в том регионе, где размещена база данных реплики для чтения. Идентификатор, назначаемый пользователем, используемый для аутентификации в этом экземпляре Key Vault, необходимо создать в том же регионе.

Межтенантные ключи, управляемые клиентом (CMK) (предварительная версия)

Ключи, управляемые клиентом, позволяют использовать ключи шифрования, хранящиеся в Key Vault или управляемом экземпляре HSM, который принадлежит другому Microsoft Entra ID, чем экземпляр гибкого сервера База данных Azure для PostgreSQL. Настройка CMK между клиентами требует дополнительной настройки и координации между клиентами. В сценарии с несколькими клиентами ресурс База данных Azure для PostgreSQL находится в клиенте, управляемом независимым поставщиком программного обеспечения (ISV), который называется поставщиком услуг. Ключ, используемый для шифрования ресурса База данных Azure для PostgreSQL, находится в хранилище ключей в другом тенанте, которым управляет клиент.

Общие сведения о настройке

В клиенте ISV

На клиентском арендаторе

  1. Установка мультитенантного приложения

  2. Создайте или используйте существующее хранилище ключей или управляемый HSM и предоставьте мультитенантному приложению разрешения на доступ к ключам

    1. Создание нового или использование существующего ключа

    2. Получите ключ из Azure Key Vault или управляемого HSM Azure и запишите идентификатор ключа

В клиенте ISV

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

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

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

Используйте портал Azure

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

  1. В ресурсе создания База данных Azure для PostgreSQL на портале Azure portal выберите вкладку Security, а затем выберите Customer-managed key.

  2. Назначьте управляемую идентичность, назначаемую пользователем, созданную как управляемая идентичность, назначаемая пользователем.

  3. Назначьте мультитенантное приложение с помощью имени приложения.

  4. Введите идентификатор ключа в методе выбораключей с помощью идентификатора ключа клиента, полученного от клиента.

Используйте шаблоны JSON Azure Resource Manager и REST API

Разверните шаблон ARM со следующими параметрами:

Замечание

Если вы воссоздаете этот пример в одном из шаблонов Azure Resource Manager, используйте apiVersion2025-03-15-privatepreview или более новые версии.

Parameter Description Пример значения
primaryKeyUri Идентификатор ключа, управляемого клиентом, который находится в хранилище ключей поставщика услуг. https://my-vault.vault.azure.com/keys/my-key
primaryUserAssignedIdentity Объект, указывающий, что управляемая идентификация назначается экземпляру База данных Azure для PostgreSQL. "identity":{"type":"UserAssigned","userAssignedIdentities":{"/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/my-resource-group/providers/Microsoft.ManagedIdentity/userAssignedIdentities/my-identity":{}}}
primaryFederatedIdentityClientId Идентификатор клиента мультитенантного приложения Microsoft Entra. application-client-id

Ниже приведен пример REST API с тремя параметрами, настроенными:

PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{serverName}?api-version=2025-03-15-privatepreview

Пример текста запроса:

{
"location": "eastus2",
    "identity": {
        "type": "UserAssigned",
        "userAssignedIdentities": {
        "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>": {}
        }
    },
    "sku": {
        "name": "Standard_D2s_v3",
        "tier": "GeneralPurpose"
    },
    "properties": {
        "createMode": "Create",
        "version": "16",
        "minorVersion": "5",
        "storage": {
        "storageSizeGB": 32
        },
        "network": {
        "publicNetworkAccess": "Enabled"
        },
        "backup": {
        "backupRetentionDays": 7,
        "geoRedundantBackup": "Disabled"
        },
        "dataEncryption": {
        "type": "AzureKeyVault",
        "primaryUserAssignedIdentityId": "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>",
        "primaryKeyUri": "https://<customer-keyvault>.vault.azure.net/keys/<key-name>/<key-version>",
        "primaryFederatedIdentityClientId": "<application-client-id>"
        }
    }
}

Ниже приведен пример REST API для смены ключей. В примере PATCH обновляется только URI ключа CMK, чтобы выполнить ротацию ключа шифрования без повторного создания сервера.

PATCH https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBforPostgreSQL/flexibleServers/{serverName}?api-version=2025-03-15-privatepreview

Текст запроса (пример поворота ключа):

{
    "properties": {
        "dataEncryption": {
        "type": "AzureKeyVault",
        "primaryUserAssignedIdentityId": "/subscriptions/<subId>/resourceGroups/<rg>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<umi-name>",
        "primaryKeyUri": "https://<customer-keyvault>.vault.azure.net/keys/<key-name>/<new-key-version>",
        "primaryFederatedIdentityClientId": "<application-client-id>"
        }
    }
}

Это важно

Даже если вы обновляете только primaryKeyUri, необходимо указать все свойства шифрования данных в тексте запроса. Если в теле запроса не указан параметр primaryFederatedIdentityClientId, запрос будет рассматриваться как не межтенантная конфигурация CMK.

Ограничения предварительной версии межтенантных ключей, управляемых клиентом (CMK)

  • Эта функция пока не поддерживается в Azure PowerShell или Azure CLI.
  • Создание сервера с геоизбыточным резервным копированием и включение долгосрочного хранения резервных копий в настоящее время не поддерживаются.
  • Предварительная версия в настоящее время поддерживается только в следующих регионах:
    • Восток США 2
    • Западная часть США 2
    • Центральная часть США
    • Australia Southeast
    • Australia East
    • North Europe

Ограничения ключей, управляемых клиентом (CMK)

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

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

  • Last updated on