Прозрачное шифрование данных Azure SQL с ключом, управляемым клиентом

Применимо: База данных SQL Azure Управляемый экземпляр SQL Azure Azure Synapse Analytics (только выделенные пулы SQL)

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

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

Для базы данных SQL Azure и Azure Synapse Analytics предохранитель TDE настраивается на уровне сервера и наследуется всеми зашифрованными базами данных, связанными с этим сервером. Для управляемого экземпляра SQL Azure предохранитель TDE настраивается на уровне экземпляра и наследуется всеми зашифрованными базами данных этого экземпляра. В рамках этого документа, если не указано иное, термин сервер относится к серверу в базе данных SQL и Azure Synapse, а также к управляемому экземпляру в управляемом экземпляре SQL.

Управление защитой TDE на уровне базы данных в База данных SQL Azure доступно. Дополнительные сведения см. в разделе Прозрачное шифрование данных (TDE) с ключами, управляемыми клиентом, на уровне базы данных.

Преимущества управляемого клиентом TDE

Управляемый клиентом TDE предоставляет клиенту следующие преимущества:

• полный и детализированный контроль над использованием и управлением предохранителем TDE;

• прозрачность использования предохранителя TDE;

• возможность реализовать в организации разделение обязанностей в управлении ключами и данными;

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

• централизованное управление ключами в Azure Key Vault;

• более высокий уровень доверия от конечных клиентов, так как служба AKV спроектирована таким образом, что корпорация Майкрософт не может просматривать и извлекать ключи шифрования.

Как работает управляемый клиентом TDE

Чтобы логический сервер в Azure использовал средство защиты TDE, хранящееся в AKV для шифрования DEK, администратор Хранилища ключей должен предоставить права доступа к серверу с помощью уникального удостоверения Microsoft Entra. Существует две модели доступа для предоставления серверу доступа к хранилищу ключей:

• Управление доступом на основе ролей Azure (RBAC) — используйте Azure RBAC, чтобы предоставить пользователю, группе или приложению доступ к хранилищу ключей. Этот метод рекомендуется для обеспечения гибкости и детализации. Роль пользователя шифрования службы шифрования key Vault необходима для удостоверения сервера, чтобы использовать ключ для операций шифрования и расшифровки.

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

  • get для получения общедоступной части и свойств ключа в Key Vault.
  • wrapKey, чтобы обеспечить возможность защиты (шифрование) DEK.
  • unwrapKey, чтобы обеспечить снятие защиты (расшифровка) DEK.

В меню конфигурации access портал Azure хранилища ключей можно выбрать политику доступа на основе ролей Azure или политику доступа Хранилища. Пошаговые инструкции по настройке конфигурации доступа к Azure Key Vault для TDE см. в статье Настройка управления расширяемыми ключами SQL Server TDE с помощью Azure Key Vault. Дополнительные сведения о моделях доступа см. в статье "Безопасность Azure Key Vault".

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

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

При необходимости сервер отправляет защищенный ключ DEK в хранилище ключей для расшифровки.

Если включено ведение журнала, аудиторы могут использовать Azure Monitor для просмотра журналов AuditEvent Key Vault.

Требования для настройки управляемого клиентом TDE

Требования для настройки Azure Key Vault

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

• Предоставьте серверу или управляемому экземпляру доступ к хранилищу ключей (get, wrapKey, unwrapKey) с помощью удостоверения Microsoft Entra. Удостоверение сервера может быть назначенным серверу управляемым удостоверением, назначаемым системой, или управляемым удостоверением, назначаемым пользователем. При использовании портала Azure удостоверение Microsoft Entra создается автоматически при создании сервера. При использовании PowerShell или Azure CLI удостоверение Microsoft Entra нужно создать явно и проверить. Подробные пошаговые инструкции по настройке TDE с поддержкой BYOK с помощью PowerShell см. в этой статье, а по настройке TDE с поддержкой BYOK для управляемого экземпляра SQL — в этой.

  • В зависимости от модели разрешений для хранилища ключей (политика доступа Azure RBAC) доступ к хранилищу ключей может быть предоставлен путем создания политики доступа для хранилища ключей или создания назначения роли RBAC с ролью Пользователь службы шифрования хранилища ключей.

• При использовании брандмауэра с AKV необходимо включить параметр Разрешить доверенным службы Майкрософт обойти брандмауэр, если вы не используете частные конечные точки для AKV. Дополнительные сведения см. в статье Настройка брандмауэров и виртуальных сетей Azure Key Vault.

Включение обратимого удаления и защиты от очистки для Azure Key Vault

Обратимое удаление и защита от очистки — это важные возможности Azure Key Vault, которые позволяют восстанавливать удаленные хранилища и объекты в них. Это снижает риск случайного или вредоносного удаления ключа или хранилища ключей.

• Обратимо удаленные ресурсы хранятся в течение 90 дней, если только они не будут восстановлены или очищены клиентом. С действиями Восстановить и Удалить связаны отдельные разрешения в политике доступа хранилища ключей. Возможность обратимого удаления включена по умолчанию для новых хранилищ ключей и может быть включена вручную с помощью портала Azure, PowerShell или Azure CLI.

• Защиту от очистки можно включить с помощью Azure CLI или PowerShell. Если защита от очистки включена, хранилище или объект в удаленном состоянии нельзя очистить, пока не истечет период хранения. Срок хранения по умолчанию составляет 90 дней, но его можно изменить на портале Azure на значение от 7 до 90 дней.

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

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

Требования для настройки предохранителя TDE

• Предохранителем TDE может быть только асимметричный ключ, ключ RSA или ключ RSA HSM. Поддерживаемые длины ключей — 2048 битов и 3072 бита.

• Дата активации ключа (если задана) должна быть датой и временем в прошлом. Дата истечения срока действия (если задана) должна быть датой и временем в будущем.

• Ключ должен находиться в состоянии Включено.

• Если вы импортируете существующий ключ в хранилище ключей, обязательно укажите его в поддерживаемом формате файла (.pfx, .byok или .backup).

Рекомендации по настройке TDE, управляемого клиентом

Рекомендации по настройке Azure Key Vault

• Подключайте до 500 баз данных общего назначения или до 200 критически важных для бизнеса баз данных в хранилище ключей в одной подписке, чтобы обеспечить высокий уровень доступности при доступе сервера к предохранителю TDE в хранилище ключей. Эти числа основаны на опыте и описаны в статье по ограничениям службы Azure Key Vault. Цель состоит в том, чтобы предотвратить проблемы после отработки отказа сервера, так как он активирует столько ключевых операций в хранилище, сколько баз данных на этом сервере.

• Установите блокировку ресурсов в хранилище ключей, чтобы управлять правами на удаление этого критически важного ресурса и предотвратить случайное или несанкционированное удаление. Дополнительные сведения о блокировке ресурсов.

• Включите аудит и отчеты для всех ключей шифрования. Хранилище ключей предоставляет журналы, которые легко можно передать в любые средства управления информационной безопасностью и событиями безопасности. Например, они уже интегрированы в службу Log Analytics из Operations Management Suite.

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

Рекомендации по настройке предохранителя TDE

• Храните копию предохранителя TDE в надежном месте или передайте ее в службу депонирования.

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

• Создавайте новую резервную копию ключа при каждом изменении в его параметрах (например, ключевых атрибутов, меток, ACL).

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

• Сохраняйте все ранее использовавшиеся ключи в Azure Key Vault даже после переключения на ключи, управляемые службой. Это обеспечит возможность восстановить резервные копии баз данных с помощью предохранителей TDE, хранящихся в Azure Key Vault. Предохранители TDE, созданные в Azure Key Vault, следует хранить до тех пор, пока сохраняются созданные с их помощью резервные копии. Создайте восстанавливаемые резервные копии этих ключей с помощью командлета Backup-AzKeyVaultKey.

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

Смена предохранителя TDE

Смена предохранителя TDE для сервера означает переключиться на новый асимметричный ключ, который защищает базы данных на сервере. Смена ключей — это онлайн-операция, и она должна занять всего несколько секунд. Операция расшифровывает и повторно шифрует ключ шифрования базы данных, а не всю базу данных.

Поворот защиты TDE можно выполнить вручную или с помощью функции автоматического поворота.

Автоматическая смена предохранителя TDE может быть включена при настройке предохранителя TDE для сервера. Автоматическая смена отключена по умолчанию. При включении сервер постоянно проверяет хранилище ключей для любых новых версий ключа, используемых в качестве средства защиты TDE. Если обнаружена новая версия ключа, средство защиты TDE на сервере или базе данных будет автоматически поворачиваться на последнюю версию ключа в течение 24 часов.

При использовании с автоматической сменой ключей в Azure Key Vault эта функция обеспечивает сквозную смену нулевого касания для защиты TDE на База данных SQL Azure и Управляемый экземпляр SQL Azure.

Рекомендации по георепликации при настройке автоматической смены предохранителя TDE

Чтобы избежать проблем при установке или во время георепликации, при автоматическом повороте защиты TDE на основном или вторичном сервере важно следовать этим правилам при настройке георепликации:

• Как первичные, так и вторичные серверы должны иметь разрешения Get, wrapKey и unwrapKey для хранилища ключей сервера-источника (хранилище ключей, которое содержит ключ защиты TDE основного сервера).

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

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

• Поддерживаются сценарии георепликации с использованием ключей, управляемых клиентом (CMK) для TDE. TDE с автоматической сменой ключей необходимо настроить на всех серверах, если вы настраиваете TDE в портал Azure. Дополнительные сведения о настройке автоматической смены ключей для конфигураций георепликации с помощью TDE см. в статье "Автоматическая смена ключей" для конфигураций георепликации.

Недоступный предохранитель TDE

Если TDE настроено для использования ключа, управляемого клиентом, для работы базы данных в оперативном режиме требуется постоянный доступ к предохранителю TDE. Если сервер теряет доступ к управляемому клиентом предохранителю TDE в AKV, то в течение 10 минут база данных начинает запрещать все подключения с соответствующим сообщением об ошибке и изменять состояние на недоступное. Единственным действием, разрешенным для базы данных в недоступном состоянии, является ее удаление.

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

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

Случайный отзыв доступа предохранителя TDE

Возможно, кто-то с достаточными правами доступа к хранилищу ключей случайно отключает доступ к ключу:

• отзыв разрешений get, wrapKey, unwrapKey для хранилища ключей с сервера

• удаление ключа;

• удаление хранилища ключей;

• изменение правил брандмауэра хранилища ключей

• Удаление управляемого удостоверения сервера в идентификаторе Microsoft Entra

Дополнительные сведения об основных причинах, по которым база данных становится недоступной.

Блокировка подключения между Управляемый экземпляр SQL и Key Vault

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

Наиболее распространенные причины отсутствия сетевого подключения к Key Vault перечислены ниже:

• Key Vault предоставляется через частную конечную точку, а частный IP-адрес службы AKV не допускается правилами исходящего трафика группы безопасности сети, связанной с подсетью управляемого экземпляра.
• Недопустимое разрешение DNS, например, если полное доменное имя хранилища ключей не разрешено или не разрешается в недопустимый IP-адрес.

Проверьте подключение от Управляемый экземпляр SQL к Key Vault, в котором размещается средство защиты TDE.

• Конечная точка — это полное доменное имя хранилища, например <vault_name.vault.azure.net> (без https://).
• Для тестирования следует использовать порт 443.
• Результат для RemoteAddress должен существовать и быть правильным IP-адресом
• Результат TCP-теста должен иметь формат TcpTestSucceeded : True.

Если тест возвращает TcpTestSucceeded: False, просмотрите конфигурацию сети:

• Проверьте разрешенный IP-адрес и убедитесь, что он правильный. Отсутствие значения указывает на то, что возникли проблемы с разрешением DNS.
  • Убедитесь, что группа безопасности сети в управляемом экземпляре имеет правило исходящего трафика , которое охватывает разрешенный IP-адрес через порт 443, особенно если разрешенный адрес принадлежит частной конечной точке хранилища ключей.
  • Проверьте другие конфигурации сети, такие как таблица маршрутов, существование виртуального устройства и его конфигурации и т. д.

Мониторинг управляемого клиентом TDE

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

• Работоспособность ресурсов Azure. Недоступная база данных, которая потеряла доступ к предохранителю TDE, отображается как недоступная после отклонения первого подключения к базе данных.
• Журнал действий. В случае сбоя доступа к предохранителю TDE в управляемом клиентом хранилище ключей в журнал действий добавляются записи. Создание оповещений для этих событий позволяет как можно скорее восстановить доступ.
• Можно настроить группы действий для отправки уведомлений и оповещений на основе ваших предпочтений, например по электронной почте, в виде SMS, push-уведомлений или голосовых сообщений, с использованием приложения логики, веб-перехватчика, ITSM или runbook службы автоматизации.

Резервное копирование и восстановление базы данных с помощью управляемого клиентом TDE

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

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

Если ключ, необходимый для восстановления резервной копии, больше недоступен целевому серверу, то в попытке восстановления возвращается следующее сообщение об ошибке: "Целевой сервер <Servername> не имеет доступа ко всем URI AKV, созданным между <меткой времени #1> и <меткой времени #2>. Retry operation after restoring all AKV Uris" (Целевой сервер не имеет доступа ко всем URI AKV, созданным с <метка времени №1> по <метка времени №2>. Повторите операцию после восстановления всех URI AKV).

Чтобы устранить эту проблему, запустите командлет Get-AzSqlServerKeyVaultKey для целевого сервера или Get-AzSqlInstanceKeyVaultKey для целевого управляемого экземпляра, чтобы получить список доступных ключей и найти недостающие. Чтобы убедиться, что все резервные копии можно восстановить, сохраняйте доступ целевого сервера для восстановления ко всем необходимым ключам. Эти ключи не обязательно должны быть помечены как предохранитель TDE.

Дополнительные сведения о восстановлении резервной копии для Базы данных SQL см. в этой статье. Дополнительные сведения о восстановлении резервных копий для выделенных пулов SQL в Azure Synapse Analytics см. в статье "Восстановление выделенного пула SQL". Сведения о собственном резервном копировании и восстановлении SQL Server с помощью Управляемый экземпляр SQL см. в кратком руководстве по восстановлению базы данных в Управляемый экземпляр SQL.

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

Высокий уровень доступности при использовании управляемого клиентом TDE

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

Несколько уровней избыточности AKV обеспечивают доступ к ключам, даже если отдельные компоненты службы завершаются сбоем или регионами Или зонами доступности Azure. Дополнительные сведения см. в статье Доступность и избыточность хранилища ключей Azure.

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

• Репликация данных
• Отработка отказа в регионе
• Отработка отказа между регионами

Географическое аварийное восстановление и управляемый клиентом TDE

Как в сценарии активной георепликации, так и в сценарии групп отработки отказа затрагиваемые сервер-источник и сервер-получатель можно связать с одним и тем же хранилищем ключей (в любом регионе) или с отдельными хранилищами ключей. Если отдельные хранилища ключей связаны с первичным и вторичным серверами, Клиент несет ответственность за поддержание согласованности данных ключей в хранилищах ключей, чтобы вторичная геореплика была синхронизирована и могла использовать тот же ключ из своего связанного хранилища ключей, если первичный ключ станет недоступным из-за сбоя в регионе и активации отработки отказа. Можно настроить до четырех вторичных реплик, но цепочки (вторичные реплики вторичных реплик) не поддерживаются.

Во избежание проблем из-за неполных данных ключей при установке или во время георепликации важно соблюдать следующие правила при настройке управляемого клиентом TDE (если для первичного и вторичного серверов используются отдельные хранилища ключей):

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

• Все задействованные хранилища ключей должны содержать одинаковые данные ключей. Он применяется не только к текущему предохранителю TDE, но и ко всем предыдущим предохранителям TDE, которые могут использоваться в файлах резервной копии.

• Начальную настройку и смену предохранителя TDE необходимо сначала выполнять на вторичной реплике и только потом на первичной.

Чтобы протестировать отработку отказа, выполните действия, описанные в статье Общие сведения об активной георепликации. Тестирование отработки отказа должно выполняться регулярно, чтобы убедиться, что в Базе данных SQL хранится разрешение на доступ к обоим хранилищам ключей.

сервер База данных SQL Azure и Управляемый экземпляр SQL в одном регионе теперь можно связать с хранилищем ключей в любом другом регионе. Сервер и хранилище ключей не должны находиться в одном регионе. Для простоты сервер-источник и сервер-получатель могут быть подключены к одному и тому же хранилищу ключей (в любом регионе). Это помогает избежать сценариев, когда материал ключа может быть не синхронизирован, если отдельные хранилища ключей используются для обоих серверов. Azure Key Vault имеет несколько слоев избыточности, чтобы ключи и хранилища ключей оставались доступными в случае сбоев служб или регионов. Доступность и избыточность хранилища ключей Azure

Политика Azure для TDE, управляемого клиентом

Политику Azure можно использовать для применения TDE, управляемого клиентом, при создании или обновлении сервера Базы данных SQL Azure или Управляемого экземпляра SQL Azure. Если эта политика активирована, все попытки создать или обновить логический сервер в Azure или управляемый экземпляр завершатся сбоем, если он не настроен с использованием ключа, управляемого клиентом. Политику Azure можно применить ко всей подписке Azure или только в пределах группы ресурсов.

Дополнительные сведения о Политике Azure см. в статьях Что такое служба "Политика Azure"? и Структура определения Политики Azure.

Для TDE, управляемого клиентом, Политика Azure поддерживает две следующие встроенные политики:

• Серверы SQL должны использовать управляемые клиентом ключи для шифрования неактивных данных
• Управляемые экземпляры должны использовать ключи, управляемые клиентом, для шифрования неактивных данных

Чтобы управлять политикой TDE, управляемой клиентом, с поддержкой только Azure AD, перейдите на портал Azure и выполните поиск службы Политика. В области Определения найдите ключ, управляемый клиентом.

У этих политик есть три варианта применения:

• Аудит. Параметр по умолчанию, согласно которому журналы действий Политики Azure охватывают только отчет об аудите.
• Запрет. Препятствует созданию или обновлению логического сервера либо управляемого экземпляра без настройки ключа, управляемого клиентом.
• Отключено. Политика отключается, и пользователи могут создать или обновить логический сервер либо управляемый экземпляр без включения управляемого клиентом TDE.

Если для политики TDE, управляемого клиентом, в Политике Azure задан параметр Запрет, создание логического сервера или управляемого экземпляра SQL Azure завершится сбоем. Сведения об этом сбое будут зарегистрированы в журнале действий группы ресурсов.

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

• Смена прозрачного предохранителя шифрования данных для База данных SQL
• Удаление предохранителя прозрачного шифрования данных (TDE) для Базы данных SQL
• Управление прозрачным шифрованием данных в Управляемом экземпляре SQL с использованием собственных ключей с помощью PowerShell
• Microsoft Defender для SQL