Поделиться через

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

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

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

Recommendations

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

  • Чтобы предотвратить случайное или несанкционированное удаление этого критического ресурса, задайте блокировку ресурсов в Key Vault.
  • Включите аудит и отчеты обо всех ключах шифрования. Key Vault предоставляет журналы, которые легко внедрить в другие средства управления безопасностью и событиями (SIEM). Журналы Azure Monitor — это один из примеров службы, которая уже интегрирована.
  • Блокировка 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.

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

Ограничения

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

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

  • Last updated on