Customer-managed TDE for Azure Synapse Analytics

Применимо к: Выделенные SQL-пулы Azure Synapse Analytics (ранее — "SQL Data Warehouse")

Tip

Microsoft Fabric Data Warehouse — это реляционное хранилище корпоративного масштаба на основе озера данных, с архитектурой, готовой к будущему, встроенным ИИ и новыми функциями. Если вы не знакомы с хранилищем данных, начните с Fabric Data Warehouse. Существующие рабочие нагрузки выделенных пулов SQL могут быть обновлены до Fabric для доступа к новым возможностям в области науки о данных, аналитики в реальном времени и создания отчётов.

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

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

Note

В этой статье рассматриваются отдельные выделенные SQL-пулы (ранее SQL DW).

  • Для выделенных SQL-пулов Azure Synapse Analytics (ранее SQL DW) установите TDE-протектор на уровне сервера. Все зашифрованные базы данных, связанные с этим сервером, наследуют TDE-протектор.
  • Шифруйте данные в выделенных SQL-пулах и бессерверных SQL-пулах в рабочем пространстве Synapse, используя ключ, управляемый клиентом, настроенный на уровне рабочего пространства. Дополнительные сведения о прозрачном шифровании данных для выделенных пулов SQL в рабочих областях Synapse см. в статье о шифровании Azure Synapse Analytics.

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

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

  • Ключ, управляемый клиентом (CMK) — вы управляете жизненным циклом ключа, включая создание, ротацию и удаление ключа. Храните ключ в Azure Key Vault или Azure Managed HSM и используйте его для шифрования ключа шифрования базы данных (DEK).

  • Bring Your Own Key (BYOK) — вы безопасно переносите или импортируете свой ключ из локального аппаратного модуля безопасности (HSM) в Azure Key Vault. Такие импортированные ключи могут использоваться как любой другой ключ в Azure Key Vault, включая ключ, управляемый клиентом, для шифрования DEK. Дополнительные сведения см. в разделе Импорт ключей, защищенных HSM, в управляемый HSM (BYOK).

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

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

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

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

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

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

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

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

Important

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

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

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

Чтобы логический SQL-сервер в 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 см. Set up SQL Server TDE Extensible Key Management by using Azure Key Vault. Дополнительные сведения о моделях доступа см. в статье "Безопасность Azure Key Vault".

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

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

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

Аудиторы могут использовать Azure Monitor для просмотра логов AuditEvent ключевых хранилищ, если логирование включено.

Note

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

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

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

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

Основные требования для настройки защиты TDE

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

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

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

Протектор TDE может быть защищен асимметричными ключами, хранящимися в Azure Key Vault. Поддерживаемые размеры ключей — 2 048 и 3 072 бита.

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

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

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

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

  • .pfx
  • .byok
  • .backup

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

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

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

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

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

      -- # 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.

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

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

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

Рекомендации по настройке защиты TDE

  • Храните копию протектора TDE в надёжном месте или передайте его на хранение эскроу-сервису.

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

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

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

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

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

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

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

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

  • Переход на новую версию того же ключа
  • Переключение на другой ключ

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

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

Note

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

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

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

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

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

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

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

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

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

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

Ниже приведено представление дополнительных шагов, необходимых на портале для возврата недоступной базы данных в режим "в сети".

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

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

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

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

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

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

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

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

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

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

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

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

  • Неправильное разрешение DNS, например, если хранилище ключей или полное доменное имя HSM не разрешено или не разрешается в недопустимый IP-адрес.

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

  • Конечная точка — это полное доменное имя вашего хранилища, например <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, Voice, Logic App, Webhook, ITSM или Automation Runbook.

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

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

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

Important

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

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

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

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

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

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

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

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

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

Связанные материалы

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