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

Статья
10/20/2023

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

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

Примечание.

Информация в статье применима к Базе данных SQL Azure, Управляемому экземпляру SQL Azure и Azure Synapse Analytics (выделенные пулы SQL, ранее — хранилище данных SQL). Сведения о прозрачном шифровании данных для выделенных пулов SQL в рабочих областях Azure Synapse см. в статье Шифрование в Azure Synapse Analytics.
Чтобы предоставить клиентам Azure SQL два уровня шифрования неактивных данных, необходимо развернуть шифрование инфраструктуры (с использованием алгоритма шифрования AES-256) с управляемыми платформой ключами. Это обеспечивает дополнительный уровень шифрования неактивных данных, а также прозрачное шифрование данных с управляемыми клиентом ключами, которое уже доступно. Для База данных SQL Azure и Управляемый экземпляр SQL Azure все базы данных, включая master базу данных и другие системные базы данных, будут зашифрованы при включении шифрования инфраструктуры. В настоящее время для использования этой возможности требуется запросить соответствующие права доступа. Если вы заинтересованы в этой возможности, обратитесь по адресу AzureSQLDoubleEncryptionAtRest@service.microsoft.com.

Примечание.

Идентификатор Microsoft Entra ранее был известен как Azure Active Directory (Azure AD).

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

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

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

Внимание

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

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

Настройка и работа управляемого клиентом прозрачного шифрования данных

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

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

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

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

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

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

Примечание.

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

Требования для настройки управляемого клиентом 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 необходимо включить параметр Allow Trusted службы Майкрософт для обхода брандмауэра. Дополнительные сведения см. в статье Настройка брандмауэров и виртуальных сетей 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).

Примечание.

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

Примечание.

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

Настройка TDE с помощью CMK с помощью ручной или автоматической смены ключей всегда будет использовать последнюю версию поддерживаемого ключа. Программа установки не позволяет использовать предыдущую или более раннюю версию ключей. Всегда использовать последнюю версию ключа соответствует политике безопасности SQL Azure, которая запрещает предыдущие версии ключей, которые могут быть скомпрометированы. Предыдущие версии ключа могут потребоваться для резервного копирования или восстановления базы данных, особенно в случае долгосрочных резервных копий, в которых должны быть сохранены старые версии ключей. Для настройки гео-реплика tion все ключи, необходимые исходному серверу, должны присутствовать на целевом сервере.

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

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

Примечание.

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

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

Примечание.

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

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

Недоступная база данных TDE BYOK

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

Внимание

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

Если ключ, необходимый для восстановления резервной копии, больше недоступен целевому серверу, то в попытке восстановления возвращается следующее сообщение об ошибке: "Целевой сервер <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

Даже в тех случаях, когда для сервера не настроена геоизбыточность, настоятельно рекомендуется настроить сервер на использование двух разных хранилищ ключей в двух разных регионах с одинаковыми данными ключей. Ключ в дополнительном хранилище ключей в другом регионе не должен быть помечен как предохранитель TDE, и, более того, это даже запрещено. Если происходит сбой, влияющий на хранилище первичных ключей, только тогда система автоматически переключается на другой связанный ключ с тем же отпечатком в хранилище вторичных ключей, если оно существует. Обратите внимание, что переключение не произойдет, если предохранитель TDE будет недоступен из-за отозванных прав доступа или удаления ключа или хранилища ключей, так как это может означать, что клиент намеренно хочет ограничить доступ к ключу. Чтобы предоставить одинаковые данные для двух хранилищ ключей в разных регионах, создайте ключ за пределами хранилища ключей и импортируйте его в оба хранилища.

Кроме того, эту операцию можно выполнить, создав ключ с помощью хранилища первичных ключей в том же регионе, что и сервер, и клонировав ключ в хранилище ключей в другом регионе Azure. Используйте командлет Backup-AzKeyVaultKey, чтобы извлечь из хранилища первичный ключ в зашифрованном формате, а затем выполните командлет Restore-AzKeyVaultKey, указав хранилище ключей во втором регионе, чтобы клонировать ключ. Кроме того, можно использовать портал Azure для резервного копирования и восстановления ключа. Операция резервного копирования и восстановления ключей разрешена только между хранилищами ключей в рамках одной подписки Azure и географии Azure.

Высокая доступность на одном сервере

Географическое аварийное восстановление и управляемый клиентом 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 завершится сбоем. Сведения об этом сбое будут зарегистрированы в журнале действий группы ресурсов.

Внимание

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

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

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

Дополнительно включите Microsoft Defender для SQL, чтобы защитить базы данных и их данные с помощью функций обнаружения и устранения потенциальных уязвимостей баз данных, а также обнаружения аномальных действий, которые могут свидетельствовать об угрозе базам данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обратная связь

Обратная связь

Дополнительные ресурсы