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

Применимо к:База данных SQL AzureУправляемый экземпляр SQL Azure

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

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

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

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

Примечание.

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

Управляемый клиентом ключ (CMK) и концепция "Принеси свой ключ" (BYOK)

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

  • Прозрачность использования предохранителя 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 protector, хранящийся в Azure Key Vault или Azure Managed HSM для защиты ключа шифрования базы данных (DEK).

Применяются следующие требования.

Поддерживаемые типы ключей и размеры

В зависимости от варианта Azure SQL и конфигурации TDE средство защиты TDE может использовать асимметричные или симметричные ключи, хранящиеся в Azure Key Vault или Azure Key Vault Managed HSM.

  • Асимметричные ключи (RSA или RSA HSM)

    • Поддерживается в Azure Key Vault и Azure Key Vault Managed HSM
    • Поддерживаемые размеры ключей: 2 048 и 3 072 бита
    • Поддерживается для База данных SQL Azure и Управляемый экземпляр SQL Azure

  • Симметричные ключи (AES)

    • Поддерживается в Azure Key Vault Premium (preview) и Azure Key Vault Managed HSM
    • Поддерживаемые размеры ключей: 128-битные, 192-битные и 256-битные
    • Поддерживается только для База данных SQL Azure, в настоящее время находится в публичном предварительном просмотре

Примечание.

прозрачное шифрование данных with symmetric keys (AES) сейчас находится в предварительном просмотре. Функции предпросмотра выпускаются с ограниченными возможностями, но Microsoft предоставляет их на основе предварительного просмотра, чтобы клиенты могли получить ранний доступ и дать обратную связь. Предварительные версии функций применяются к отдельным дополнительным условиям предварительного просмотра и не подпадают под действие соглашений об уровне обслуживания. Поддержка предоставляется в качестве наилучших усилий в некоторых случаях. Однако служба поддержки Майкрософт стремится получить отзывы о функциях предварительной версии и может обеспечить поддержку наилучших усилий в некоторых случаях. Предварительные версии функций могут иметь ограниченные или ограниченные функциональные возможности и могут быть доступны только в выбранных географических областях.

Поведение управления ключами для симметричных (AES) ключей

Вы можете использовать симметричные (AES) ключи, хранящиеся в Azure Key Vault Premium (предпросмотр) или Azure Key Vault Managed HSM, в качестве TDE-протектора. Чтобы начать с ключа из локального аппаратного модуля безопасности (HSM), импортируйте ключ в любой из сервисов. После первоначального импорта все текущие операции жизненного цикла ключа происходят в Azure Key Vault Premium (preview) или Azure Key Vault Managed HSM. Восстановление на определённый момент времени, географически распределённое аварийное восстановление и повторная проверка ключа — всё это зависит от того, что ключ остаётся там доступным. Поддерживайте локальные резервные копии импортированных ключей для поддержки сценариев восстановления и повторной валидации. Это поведение относится только к симметричным (AES) ключам, а не к асимметричным (RSA) ключам.

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

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

Требования к импорту ключей

Если вы импортируете существующий ключ в Azure Key Vault, предоставьте ключ в одном из следующих поддерживаемых форматов:

  • .pfx
  • .byok
  • .backup

Чтобы импортировать ключи, защищенные HSM, в управляемый HSM Azure, см. Импорт ключей, защищенных HSM, в управляемый HSM (BYOK).

Примечание.

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

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

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

    Дополнительные сведения о поведении регулирования см. в руководстве по регулированию Azure Key Vault.

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

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

    • Свяжите не более 500 баз данных общего назначения с одним Azure Key Vault.

    • Свяжите не более 200 баз данных для критически важных для бизнеса с одним Хранилищем ключей Azure.

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

      -- # of page servers (primary copies) for this database
SELECT COUNT(*) AS page_server_count
FROM sys.database_files
WHERE type_desc = 'ROWS';

      Не ассоциируйте более 500 серверов страниц с одним Azure Key Vault. По мере роста базы данных число серверов страниц увеличивается автоматически, поэтому важно регулярно отслеживать размер базы данных. Если количество серверов страниц превышает 500, используйте выделенный Azure Key Vault для каждой базы данных Hyperscale и не делитесь этим хранилищем с другими ресурсами Azure SQL.

    • Мониторинг и настройка оповещений Azure Key Vault. Дополнительные сведения о мониторинге и предупреждении см. в статье "Мониторинг Azure Key Vault " и "Настройка оповещений Azure Key Vault".

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

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

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

    Внимание

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

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

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

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

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

Подсказка

Использование версий и безверсийных ключей Azure Key Vault для TDE

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

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

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

Примеры:

  • Идентификатор ключа, включающий определенную версию

    https://<key-vault-name>.vault.azure.net/keys/<key-name>/<key-version>

  • Идентификатор ключа без версии

    https://<key-vault-name>.vault.azure.net/keys/<key-name>

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

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

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

  • Переход на новую версию того же ключа
  • Переключение на другой ключ
  • Переключение между поддерживаемыми типами ключей, например асимметричными (RSA) и симметричными ключами (AES)

Примечание.

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

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

Автоматическая ротация защитника TDE может быть включена при настройке защитника TDE для сервера. Автоматическая смена отключена по умолчанию. Если этот параметр включен, сервер постоянно проверяет хранилище ключей или управляемый 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". Для встроенного резервного копирования и восстановления в SQL Server с помощью Управляемого экземпляра базы данных SQL в Azure см. в разделе Краткое руководство: Восстановление базы данных в Управляемый экземпляр SQL Azure с помощью SSMS.

Еще одно замечание относительно файлов журналов: сохраненные резервные копии журналов остаются зашифрованными с помощью исходного предохранителя TDE, даже если он был заменен и база данных уже использует новый предохранитель TDE. Во время восстановления оба ключа необходимы для восстановления базы данных. Если файл журнала использует ключ защитника TDE, хранящийся в Azure Key Vault или Управляемом аппаратном модуле безопасности Azure (HSM), этот ключ необходим во время восстановления, даже если база данных была изменена для использования 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 под управлением клиента

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

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

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

При настройке активной гео-репликации или резервной группы в портале Azure применимы следующие соображения:

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

  • Зональная избыточность: Если эта функция доступна, зональная избыточность для База данных SQL Azure или Управляемый экземпляр SQL Azure обеспечивает дополнительную отказоустойчивость в пределах региона. Дополнительные сведения см. в статье Что такое зоны доступности Azure?.

  • Разрешения ключей: И первичный, и вторичный серверы должны иметь необходимые права на каждом Azure Key Vault или Azure Managed HSM, содержащем необходимый TDE-протектор.

  • Доступность ключей: Убедитесь, что необходимые ключи доступны как на основном, так и на вторичном серверах. Серверам не обязательно использовать одинаковые TDE-протекторы, но у каждого сервера должен быть одинаковый ключ. Вы можете добавить ключи на сервер, используя портал Azure, PowerShell, Azure CLI или Azure SQL REST API. Если необходимые ключи недоступны в момент аварийного переключения, база данных может оказаться недоступной.

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

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

Для получения информации о настройке ресурса гео-аварийного восстановления Azure SQL см. обзор и лучшие практикиактивной гео-репликации или резервных групп.

Внимание

Когда вы создаёте гео-репликационную ссылку или резервную группу, Azure SQL проверяет, что оба сервера могут получить доступ ко всем необходимым ключам, управляемым клиентом. Если ни один из серверов не может получить доступ к нужному ключу, операция создания неудачна. Например, если основной и вторичный серверы используют Ключ A и Ключ B соответственно, добавьте оба ключа к оба сервера перед созданием линии георепликации или группы резервирования.

Следующая диаграмма показывает георепликацию Azure SQL с группой аварийного переключения и межрегиональное аварийное переключение Azure Key Vault в конфигурации с парными регионами:

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

Поведение Azure Key Vault при отработке отказа

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

Восстановление после недоступного протектора TDE

Если база данных в активной гео-репликационной или резервной группе становится недоступной, управляющая плоскость Azure SQL разрывает связь и превращает базу данных в автономную базу данных.

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

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

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

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

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

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

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

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

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

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

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

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

Внимание

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

TDE in Azure Synapse Analytics

Для получения информации о TDE с ключами, управляемыми клиентом, в Azure Synapse Analytics, см. раздел TDE с ключами, управляемыми клиентом. Дополнительные сведения о восстановлении резервных копий для выделенных пулов SQL в Azure Synapse Analytics см. в статье "Восстановление выделенного пула SQL".

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

  • Последнее обновление: