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

Статья
02/04/2025

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

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

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

Примечание.

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

Примечание.

Microsoft Entra ID ранее был известен как 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 может отозвать разрешения на доступ к ключам, чтобы сделать зашифрованную базу данных недоступной;
централизованное управление ключами в AKV
более высокий уровень доверия от конечных клиентов, так как служба AKV спроектирована таким образом, что корпорация Майкрософт не может просматривать и извлекать ключи шифрования.

Внимание

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

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

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

Управление доступом на основе ролей Azure (RBAC) — используйте Azure RBAC, чтобы предоставить пользователю, группе или приложению доступ к хранилищу ключей. Этот метод рекомендуется для обеспечения гибкости и детализации. Роль Key Vault Crypto Service Encryption User необходима для идентификации сервера, чтобы иметь возможность использовать ключ для операций шифрования и дешифрования.
Политика доступа к хранилищу. Используйте политику доступа к хранилищу ключей, чтобы предоставить серверу доступ к хранилищу ключей. Этот метод проще и более прямолинейный, но менее гибкий. Удостоверение сервера должно иметь следующие разрешения в хранилище ключей:
- get для получения общедоступной части и свойств ключа в 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

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

Необходимо активировать функции мягкого удаления и защиты от окончательного удаления в хранилище ключей, чтобы защитить от потери данных из-за случайного удаления ключа или самого хранилища ключей.
Предоставьте серверу или управляемому экземпляру доступ к хранилищу ключей (get, wrapKey, unwrapKey) с использованием удостоверения Microsoft Entra. Удостоверение сервера может быть управляемым удостоверением, назначаемым системой, или управляющим удостоверением, которое назначено пользователем серверу. При использовании портала Azure удостоверение Microsoft Entra создается автоматически при создании сервера. При использовании PowerShell или Azure CLI идентификация Microsoft Entra должна быть явно создана и следует проверить. Подробные пошаговые инструкции по настройке TDE с поддержкой BYOK с помощью PowerShell см. в этой статье, а по настройке TDE с поддержкой BYOK для управляемого экземпляра SQL — в этой.
- В зависимости от модели разрешений для хранилища ключей (политика доступа или RBAC Azure) доступ к хранилищу ключей может быть предоставлен путем создания политики доступа для хранилища ключей или создания нового назначения роли RBAC Azure с ролью Пользователь службы шифрования хранилища ключей.
При использовании брандмауэра с 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 на существующем сервере или во время создания сервера, Azure SQL проверяет, что используемое хранилище ключей включает мягкое удаление и защиту от окончательного удаления. Если мягкое удаление и защита от очистки не включены в хранилище ключей, настройка защитника TDE завершается ошибкой. В этом случае необходимо сначала включить обратимое удаление и очистку в хранилище ключей, а затем выполнить настройку защиты TDE.

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

Предохранителем TDE может быть только асимметричный ключ, ключ RSA или ключ RSA HSM. Поддерживаемые длины ключей — 2048 битов и 3072 бита.
Дата активации ключа (если задана) должна быть датой и временем в прошлом. Дата истечения срока действия (если задана) должна быть датой и временем в будущем.
Ключ должен находиться в состоянии Включено.
Если вы импортируете существующий ключ в хранилище ключей, обязательно укажите его в поддерживаемом формате файла (.pfx, .byok или .backup).

Примечание.

Поддержка Azure SQL и 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 на основном или вторичном сервере важно следовать этим правилам при настройке георепликации:

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

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

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

Примечание.

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

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внимание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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