Общие сведения о шифровании данных

Статья
2025-02-19

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

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

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

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

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

С помощью ключа шифрования, управляемого клиентом, вы берете на себя всю ответственность. Поэтому необходимо развернуть собственный 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 обеспечивает следующие преимущества:

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

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

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

Требования

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

Хранилище ключей и гибкий сервер базы данных Azure для PostgreSQL должны принадлежать одному арендатору Microsoft Entra. Взаимодействие между ключевым хранилищем и сервером, размещенными в разных клиентах, не поддерживается. После перемещения ресурса Key Vault необходимо перенастроить шифрование данных.
Мы рекомендуем вам установить настройку Срок хранения удаленных хранилищ для Key Vault на 90 дней. Если вы настроили существующий экземпляр Key Vault с нижним значением, он по-прежнему должен быть допустимым. Однако если вы хотите изменить этот параметр и увеличить значение, необходимо создать новый экземпляр Key Vault. После создания экземпляра невозможно изменить этот параметр.
Включите функцию обратимого удаления в Key Vault, чтобы обеспечить защиту от потери данных, если ключ или экземпляр Key Vault случайно удален. Key Vault сохраняет обратимо удаленные ресурсы в течение 90 дней, если только пользователь не восстановит или не удалит их за это время. Действия восстановления и очистки имеют свои собственные разрешения, которые связаны с Key Vault, ролью RBAC или разрешением политики доступа. Функция обратимого удаления включена по умолчанию. Если у вас есть хранилище ключей, которое было развернуто давно, возможно, у него по-прежнему отключено мягкое удаление. В этом случае его можно включить с помощью 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).

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

Непреднамеренный отзыв доступа к ключу из 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 с помощью управляемого клиентом ключа, можно выбрать управляемый HSM в хранилище Azure Key Vault в качестве альтернативы для Azure Key Vault. Предварительные требования с точки зрения определяемых пользователем удостоверений и разрешений совпадают с Azure Key Vault (как описано ранее в этой статье). Дополнительные сведения о создании управляемого экземпляра HSM, его преимуществах и отличиях от общего хранилища сертификатов на основе Key Vault и импорте ключей в управляемый HSM см. в статье "Что такое управляемый HSM Azure Key Vault?".

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

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

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

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

Примечание.

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

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

Процесс восстановления управляемого удостоверения после его удаления

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

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

Внимание

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

Управляемые клиентом ключи без привязки к версии (предварительная версия)

Ключи без версий упрощают процесс ротации ключей. Использование автообновления в Key Vault без ключей без версий требует настройки автоматизации для обнаружения обновления и обновления CMK в PostgreSQL на новую версию ключа.

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

API не изменяется для ключей без версий. Вместо предоставления всего URI идентификатора ключа опустите часть версии идентификатора ключа. Это относится к API, Azure CLI, ARM и Bicep.

На портале Azure есть флажок, чтобы включить режим без версий. Этот флаг изменяет запись URI ключа так, чтобы версия не требовалась.

Ограничения

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

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

Настройте шифрование данных.