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

Шифрование данных

  • Статья

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

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

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

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

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

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

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

Требования

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

  • Key Vault и База данных Azure для PostgreSQL гибкий сервер должны принадлежать одному клиенту Microsoft Entra. Взаимодействие между Key Vault и сервером, размещенными в разных клиентах, не поддерживается. После перемещения ресурса 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).

Рекомендации

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

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

Примечание.

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

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

Примечания

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

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

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

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

  • Если вы смените ключ и забыли обновить экземпляр База данных Azure для PostgreSQL гибкого сервера, чтобы он указывает на новую версию ключа. Старый ключ, на который указывает экземпляр, в конечном итоге истекает и преобразует состояние сервера в недоступное. Чтобы избежать этого, при каждом повороте ключа убедитесь, что вы также обновляете экземпляр сервера, чтобы указать новую версию. Для этого можно использовать следующий az postgres flexible-server updateпример, описывающий "Изменение ключа или удостоверения для шифрования данных. Шифрование данных не может быть включено после создания сервера, это приведет только к обновлению ключа или удостоверения". В качестве альтернативы можно вызвать серверы — обновить REST API службы.
  • При удалении экземпляра Key Vault База данных Azure для PostgreSQL гибкий экземпляр сервера не может получить доступ к ключу и перейти в недоступное состояние. Чтобы сделать сервер доступным, восстановите экземпляр Key Vault и обновите шифрование данных.
  • При удалении ключа из Key Vault База данных Azure для PostgreSQL гибкий экземпляр сервера не может получить доступ к ключу и перейти в недоступное состояние. Чтобы сделать сервер доступным, восстановите ключ и обновите шифрование данных.
  • При удалении из идентификатора Microsoft Entra управляемое удостоверение, используемое для получения ключа из Key Vault, или путем удаления назначения ролей Azure RBAC с помощью пользователя шифрования шифрования службы шифрования key Vault. База данных Azure для PostgreSQL гибкий экземпляр сервера не может получить доступ к ключу и перейти к недоступному состоянию. Чтобы сделать сервер доступным, восстановите удостоверение и повторное шифрование данных.
  • Если вы отменяете список Key Vault, получает, упаковываете и отменяете политики доступа к ключу из управляемого удостоверения, используемого для получения ключа из Key Vault, База данных Azure для PostgreSQL гибкий экземпляр сервера не может получить доступ к ключу и перейти к недоступномусостоянию. Добавьте необходимые политики доступа в удостоверение в Key Vault.
  • Если вы настроили слишком строгие правила брандмауэра Key Vault, База данных Azure для PostgreSQL гибкий сервер не может взаимодействовать с Key Vault для получения ключей. При настройке брандмауэра Key Vault обязательно выберите параметр, позволяющий доверенным службы Майкрософт обойти брандмауэр.

Примечание.

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

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

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

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

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

Внимание

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

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

База данных 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 гибком сервере:

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