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

Статья
02/04/2025

Применимо:База данных 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) с ключами, управляемыми клиентом, на уровне базы данных.

Примечание.

Информация в статье применима к Базе данных 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

Примечание.

В этой статье термины управляемый клиентом ключ (CMK) и использование собственного ключа (BYOK) используются взаимозаменяемо, но они имеют некоторые различия.

управляемый клиентом ключ (CMK) . Клиент управляет жизненным циклом ключа, включая создание ключей, смену и удаление. Ключ хранится в Azure Key Vault или управляемом HSM Azure Key Vault и он используется для шифрования ключа шифрования базы данных (DEK) в Azure SQL, SQL Server на виртуальной машине Azure и SQL Server в локальной среде.
Используйте собственный ключ (BYOK). Клиент безопасно передает или импортирует свой собственный ключ из локального аппаратного модуля безопасности (HSM) в Azure Key Vault или управляемый HSM Azure Key Vault. Такие импортированные ключи могут использоваться как любой другой ключ в Azure Key Vault, включая ключ, управляемый клиентом для шифрования DEK. Дополнительные сведения см. в разделе Импорт ключей, защищенных HSM, в управляемый HSM (BYOK).

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

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

Внимание

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

Как работает управляемый клиентом 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.

Примечание.

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

Примечание.

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

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

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

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

Примечание.

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

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

Примечание.

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

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

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

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

отзыв разрешений get, wrapKey, unwrapKey для хранилища ключей с сервера
удаление ключа;
удаление хранилища ключей;
изменение правил брандмауэра хранилища ключей
Удаление управляемого удостоверения сервера в идентификаторе Microsoft Entra

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

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

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

Наиболее распространенные причины отсутствия сетевого подключения к 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 службы автоматизации.

База данных `backup` и `restore` с управляемым клиентом 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

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

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

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

Примечание.

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

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

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

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

Существует несколько вариантов хранения ключа защиты TDE на основе требований клиентов:

Используйте Azure Key Vault и устойчивость собственного парного региона или непараллельного региона.
Используйте управляемый клиентом HSM и загружайте ключи в Azure Key Vault в отдельных AKV в разных регионах.
Используйте управляемый HSM и параметр репликации между регионами.
- Этот параметр позволяет клиенту выбрать нужный регион, в котором будут реплицироваться ключи.

На следующей схеме представлена конфигурация парного региона (основного и дополнительного) для перекрестной отработки отказа AKV с настройкой SQL Azure для георепликации с помощью группы отработки отказа:

Примечания Azure Key Vault для Geo-DR

Первичные и вторичные серверы в SQL Azure получают доступ к AKV в основном регионе.
Отработка отказа AKV инициируется службой AKV, а не клиентом.
В случае переключения AKV на резервный регион сервер в Azure SQL по-прежнему может получить доступ к тому же AKV. Хотя внутренне подключение AKV перенаправляется в AKV во вторичном регионе.
Новые возможности создания ключей, импорта и смены ключей возможны только в то время как AKV в первичном расположении доступен.
После активации аварийного режима смена ключей не допускается до тех пор, пока Хранилище Ключей Azure в первичном регионе связанной пары регионов снова не станет доступным.
Клиент не может вручную подключиться к дополнительному региону.
АКВ находится в режиме только для чтения, когда АКВ в основном регионе недоступен.
Клиент не может выбрать или проверить, в каком регионе сейчас находится AKV.
Для несопряжённого региона оба сервера SQL Azure обращаются к AKV в первом регионе (как указано на графе), а AKV использует хранилище с избыточностью между зонами для репликации данных в рамках независимых зон доступности этого же региона.

Дополнительные сведения см. в статьях о доступности и избыточности Azure Key Vault, парах регионов Azure и непарных регионах, а также о соглашениях об уровне обслуживания Azure Key Vault.

Примечания SQL Azure для Geo-DR

Используйте параметр с избыточностью по зонам для повышения отказоустойчивости в Azure SQL Managed Instance и Azure SQL Database. Дополнительные сведения см. в статье Что такое зоны доступности Azure?.
Используйте группы отработки отказа для Azure SQL MI и Azure SQL Database для аварийного восстановления в соседний регион. Дополнительные сведения см. в обзоре групп отработки отказа , рекомендации лучших практик &.
Для конфигурации может потребоваться более сложная зона DNS, если частные конечные точки используются в SQL Azure (например, не удается создать две частные конечные точки для одного ресурса в одной зоне DNS).
Убедитесь, что приложения используют логику повторных попыток.

Существует несколько сценариев, когда клиентам может потребоваться выбрать решение управляемых аппаратных модулей безопасности (HSM) через AKV:

Необходимость ручного подключения ко вторичному хранилищу.
Требование доступа на чтение к хранилищу даже в случае сбоя.
Гибкость выбора региона, в который реплицируется ключевой материал
- Требуется включить репликацию между регионами, которая создает второй управляемый пул HSM во втором регионе.
Использование управляемого модуля HSM позволяет клиентам создавать точную реплику для HSM, если исходный объект потерян или недоступен.
Использование управляемого модуля HSM для требований к безопасности или нормативным требованиям.
Возможность резервного копирования всего хранилища в отличие от резервного копирования отдельных ключей.

Дополнительные сведения см. в разделах Включение репликации в нескольких регионах на управляемом HSM Azure и Аварийное восстановление управляемого HSM.

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

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

Прозрачное шифрование данных 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

База данных `backup` и `restore` с управляемым клиентом TDE

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

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

Примечания Azure Key Vault для Geo-DR

Примечания SQL Azure для Geo-DR

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

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

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

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

Прозрачное шифрование данных 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

База данных backup и restore с управляемым клиентом TDE

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

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

Примечания Azure Key Vault для Geo-DR

Примечания SQL Azure для Geo-DR

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

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

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

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

База данных `backup` и `restore` с управляемым клиентом TDE