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

  • Статья
  • Чтение занимает 21 мин

Область применения: База данных SQL Azure Управляемый экземпляр SQL Azure Azure Synapse Analytics

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

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

Примечание

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

Важно!

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

Чтобы сервер Azure SQL использовал предохранитель TDE, хранящийся в AKV, для шифрования DEK, администратору хранилища ключей необходимо предоставить следующие права доступа к серверу, используя его уникальное удостоверение Azure Active Directory (Azure AD):

  • get для получения общедоступной части и свойств ключа в Key Vault.

  • wrapKey, чтобы обеспечить возможность защиты (шифрование) DEK.

  • unwrapKey, чтобы обеспечить снятие защиты (расшифровка) DEK.

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

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

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

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

Примечание

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

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

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

  • Хранилище ключей и база данных SQL или управляемый экземпляр должны принадлежать к одному и тому же клиенту Azure Active Directory. Взаимодействие между хранилищем ключей и сервером, размещенными в разных клиентах, не поддерживается. Чтобы затем переместить ресурсы, необходимо будет перенастроить TDE с Azure Key Vault. Дополнительные сведения о перемещении ресурсов.

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

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

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

  • При использовании брандмауэра с 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 теперь поддерживает использование ключа RSA, хранящегося в управляемом устройстве HSM в качестве предохранителя TDE. Управляемое устройство HSM в Azure Key Vault — это полностью управляемая высокодоступная одноклиентная соответствующая стандартам облачная служба, которая позволяет защищать криптографические ключи для облачных приложений, используя устройства HSM, отвечающие стандартам FIPS 140-2 уровня 3. Дополнительные сведения об управляемых HSM.

Примечание

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

Примечание

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

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

  • Если доступ к ключам будет вновь получен в течение 30 минут, база данных восстановится автоматически в течение часа.

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

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

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

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

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

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

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

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

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

  • удаление управляемого удостоверения сервера в Azure Active Directory.

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

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

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

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

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

Проверьте подключение из Управляемый экземпляр к Key Vault размещения предохранителя TDE. — Конечная точка — это полное доменное имя хранилища, например <vault_name.vault.azure.net> (без https://). — порт для тестирования — 443. — Результат для RemoteAddress должен существовать и быть правильным IP-адресом. Результат теста TCP должен быть tcpTestSucceededed: True.

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

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

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

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

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

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

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

Важно!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Группы отработки отказа и географическое аварийное восстановление

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

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

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

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

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

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

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

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

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

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

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

Важно!

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

Дальнейшие действия

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

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