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

Статья
04/27/2024

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

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

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

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

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

Льготы

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

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

Терминология

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

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

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

Как работает шифрование данных с помощью CMK

Схема, показывая обзор использования собственного ключа.

Управляемое удостоверение, назначаемое пользователем Microsoft Entra, используется для подключения и извлечения CMK. Чтобы создать удостоверение, следуйте инструкциям из этого руководства.

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

get: для получения общедоступной части и свойств ключа в Key Vault.
list: для перечисления и итерации ключей в Key Vault.
wrapKey: для шифрования DEK. Зашифрованный DEK хранится в База данных Azure для PostgreSQL.
unwrapKey: для расшифровки DEK. База данных Azure для PostgreSQL требуется расшифровка DEK для шифрования и расшифровки данных.

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

Внимание

Не предоставляя предыдущие права доступа управляемому удостоверению для доступа к Key Vault, может привести к сбою получения ключа шифрования и сбоя настройки функции CMK.

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

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

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

Key Vault и База данных Azure для PostgreSQL гибкий сервер должны принадлежать одному клиенту Microsoft Entra. Взаимодействие между Key Vault и сервером, размещенными в разных клиентах, не поддерживается. После перемещения ресурса Key Vault необходимо перенастроить шифрование данных.
Значение "Дни", чтобы сохранить удаленные хранилища для Key Vault, должно быть 90. Если вы настроили существующий экземпляр Key Vault с меньшим числом, необходимо создать новый экземпляр Key Vault, так как после создания не удается изменить экземпляр.
Рекомендуется задать для дней сохранение конфигурации удаленных хранилищ для Key Vault до 90 дней. Если вы настроили существующий экземпляр Key Vault с меньшим числом, он по-прежнему должен быть допустимым. Однако если вы хотите изменить этот параметр и увеличить значение, необходимо создать новый экземпляр Key Vault. После создания экземпляра невозможно изменить его конфигурацию.
Включите функцию обратимого удаления в Key Vault, чтобы помочь защититься от потери данных, если ключ или экземпляр Key Vault случайно удален. Key Vault сохраняет обратимо удаленные ресурсы в течение 90 дней, если пользователь не восстанавливает или не очищает их в то же время. Действия восстановления и очистки имеют собственные разрешения, связанные с политикой доступа Key Vault.

Функция обратимого удаления отключена по умолчанию, но ее можно включить с помощью PowerShell или Azure CLI. Вы не можете включить его через портал Azure.
Включите защиту очистки для принудительного применения обязательного периода хранения для удаленных хранилищ и объектов хранилища.
Предоставьте База данных Azure для PostgreSQL гибкий экземпляр сервера доступ к Key Vault с разрешениями get, list, wrapKey и unwrapKey с помощью уникального управляемого удостоверения.

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

КЛЮЧ CMK, используемый для шифрования DEK, может быть только асимметричным, RSA или RSA-HSM. Поддерживаются ключевые размеры 2 048, 3 072 и 4096.
Дата и время активации ключа (если задано) должно находиться в прошлом. Дата и время окончания срока действия (если задано) должно находиться в будущем.
Ключ должен находиться в *Enabled- состоянии.
Если вы импортируете существующий ключ в Key Vault, укажите его в поддерживаемых форматах файлов (.pfxили.byok.backup).

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

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

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

Мониторинг CMK в Key Vault

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

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

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

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

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

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

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

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

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

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

Недоступное условие CMK

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

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

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

Примечание.

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

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

Использование шифрования данных с пакетами УПРАВЛЕНИЯ и геоизбыточными функциями непрерывности бизнес-процессов

База данных 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, необходимо создать в том же регионе.

Ограничения

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

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

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

Узнайте о доменных службах Microsoft Entra.

Share via