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

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

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

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

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

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

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

Примечание.

Информация в статье применима к Базе данных SQL Azure, Управляемому экземпляру SQL Azure и Azure Synapse Analytics (выделенные пулы SQL, ранее — хранилище данных SQL). Сведения о прозрачном шифровании данных для выделенных пулов SQL в рабочих областях Azure Synapse см. в статье Шифрование в Azure Synapse Analytics.

Примечание.

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

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

Примечание.

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

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

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

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

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

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

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

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

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

Внимание

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

Разрешения на настройку управляемого клиентом TDE

Схема, показывающая настройку и функционирование управляемого клиентом TDE.

Выберите тип Azure Key Vault, который вы хотите использовать.

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

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

Примечание.

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

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

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

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

  • Включите аудит и отчеты обо всех ключах шифрования: Azure Key Vault предоставляет журналы, которые легко внедрить в другие средства управления безопасностью и событиями. Примером службы, которая уже интегрирована, является Operations Management Suite Log Analytics.

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

Примечание.

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

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

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

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

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

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

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

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

Вращение защитного устройства TDE

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

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

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

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

Примечание.

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

Учитываемые факторы георепликации при настройке автоматической ротации защитника TDE

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

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

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

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

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

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

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

Недоступное состояние

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

Если сервер теряет доступ к управляемому клиентом средству защиты TDE в Azure Key Vault или Управляемом HSM Azure из-за какой-либо ошибки Azure Key Vault (например, ошибки 4XX), база данных будет перемещена в недоступное состояние через 30 минут.

Восстановление доступа к базе данных после ошибки Azure Key Vault или Azure Managed HSM

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

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

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

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

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

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

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

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

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

  • удаление хранилища ключей или управляемого модуля HSM

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

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

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

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

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

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

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

Проверьте подключение из Управляемого экземпляра SQL к Azure Key Vault или Управляемому HSM Azure, где размещен предохранитель TDE.

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

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

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

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

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

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

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

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

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

Внимание

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

Если ключ, необходимый для восстановления резервной копии, больше недоступен целевому серверу, то в попытке восстановления возвращается следующее сообщение об ошибке: "Целевой сервер <Servername> не имеет доступа ко всем URI AKV, созданным между <меткой времени #1> и <меткой времени #2>. Повторите операцию после восстановления всех URI AKV. (Целевой сервер не имеет доступа ко всем 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 или управляемом HSM Azure, этот ключ необходим во время восстановления, даже если база данных была изменена на использование TDE, управляемого службой.

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

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

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

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

Примечание.

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

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

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

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

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

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

  • Используйте Azure Key Vault и устойчивость собственного парного региона или непараллельного региона.

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

  • Используйте управляемый HSM Azure и параметр репликации между регионами.

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

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

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

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

  • Первичные и вторичные серверы в Azure SQL получают доступ к Azure Key Vault в основном регионе.

  • Переключение на резервное хранилище Azure Key Vault инициируется службой Azure Key Vault, а не клиентом.

  • В случае переключения Azure Key Vault на резервный регион, сервер в Azure SQL по-прежнему может получить доступ к тому же Хранилищу ключей Azure. Хотя в системе подключение к Azure Key Vault перенаправляется в Azure Key Vault в вторичном регионе.

  • Новые создания ключей, импорта и смены ключей возможны только в то время как Azure Key Vault в основном доступно.

  • После отработки отказа смена ключей не допускается до тех пор, пока Azure Key Vault в основном регионе парного региона снова не будет доступен.

  • Клиент не может вручную подключиться к дополнительному региону.

  • Azure Key Vault находится в состоянии только для чтения, пока Azure Key Vault в основном регионе недоступен

  • Клиент не может выбрать или проверить регион, в который сейчас находится Azure Key Vault.

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

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

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

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

  • Убедитесь, что приложения используют логику повторных попыток.

Существует несколько сценариев, когда клиентам может потребоваться выбрать Azure Managed HSM вместо Azure Key Vault.

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

  • Требование доступа на чтение к хранилищу, даже если происходит сбой.

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

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

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

  • Использование управляемого устройства HSM Azure для соответствия требованиям безопасности или нормативным требованиям.

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

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

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

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

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

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

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

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

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

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

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

Внимание

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

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