Модели шифрования данных

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

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

• Шифрование на стороне сервера с помощью ключей, управляемых платформой (по умолчанию)

  • Поставщики ресурсов Azure выполняют операции шифрования и расшифровки.
  • Корпорация Майкрософт автоматически управляет ключами.
  • Включен по умолчанию без требуемой конфигурации.
  • Полная облачная функциональность.

• Шифрование на стороне сервера с помощью ключей, управляемых клиентом, в Azure Key Vault (необязательно)

  • Поставщики ресурсов Azure выполняют операции шифрования и расшифровки.
  • Ключи управляются с помощью Azure Key Vault.
  • Требуется конфигурация и управление со стороны клиента.
  • Полная облачная функциональность.

• Шифрование на стороне сервера с помощью ключей, управляемых клиентом, на оборудовании, управляемом клиентом (расширенный вариант)

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

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

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

Для шифрования на стороне клиента рекомендуется:

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

Поддерживаемые модели шифрования в Azure разделяются на две основные группы: шифрование клиентов и шифрование на стороне сервера. Независимо от используемой модели шифрования службы Azure всегда рекомендуют использовать безопасный транспорт, например TLS или HTTPS. Поэтому шифрование в транспорте должно решаться протоколом транспорта и не должно быть основным фактором в определении используемой модели шифрования.

Модель шифрования клиентом

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

Шифрование на стороне сервера с помощью ключей, управляемых платформой (по умолчанию)

Для большинства клиентов основное требование — убедиться, что данные шифруются в состоянии покоя. Шифрование на стороне сервера с помощью ключей, управляемых платформой (ранее называемых ключами, управляемыми службой), выполняет это требование, предоставляя автоматическое шифрование по умолчанию. Этот подход позволяет шифрование на месте без необходимости чтобы пользователи настраивали или управляли ключами шифрования, оставляя все аспекты управления ключами, такие как выдача ключей, смена и резервное копирование, на Microsoft.

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

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

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

Доступ к ключам

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

Преимущества

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

Рекомендации

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

Шифрование на стороне сервера с помощью ключей, управляемых клиентом, в Azure Key Vault и Управляемом HSM Azure (необязательно)

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

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

Потеря ключей шифрования ключей означает потерю данных. По этой причине не удаляйте ключи. Всегда резервное копирование ключей при создании или смене ключей. При смене KEK служба повторно упаковывает ключи шифрования данных с новой версией ключа — базовые данные не шифруются повторно. Старые и новые версии ключей должны оставаться включенными до тех пор, пока все ключи шифрования данных не будут перепакованы. Чтобы защититься от случайного или преднамеренного криптографического удаления, необходимо включить функцию мягкого удаления (Soft-Delete) и защиту от удаления в любом хранилище, в котором хранятся ключи шифрования ключей. Вместо удаления ключа установите для ключа шифрования значение параметра "enabled" в "false". Используйте элементы управления доступом для отзыва доступа к отдельным пользователям или службам в Azure Key Vault или управляемом HSM.

Предупреждение

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

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

Примечание.

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

Доступ к ключам

В модели шифрования на стороне сервера с хранением в Azure Key Vault ключей, управляемых пользователем, служба при необходимости получает доступ к ключам для шифрования и расшифровки. Вы делаете ключи шифрования данных на месте доступными для службы через политику управления доступом. Эта политика предоставляет службе доступ на основе удостоверения для получения ключа. Службу Azure, работающую от связанной подписки, можно настроить с идентификатором в этой подписке. Служба может выполнять проверку подлинности Microsoft Entra и получать маркер проверки подлинности, определяющий себя как эта служба, выступающая от имени подписки. Затем служба представляет токен в Key Vault, чтобы получить ключ, к которому открыт доступ.

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

Чтобы получить ключ для шифрования или расшифровки данных, находящихся в состоянии покоя, идентификатор службы, от имени которого выполняется экземпляр службы Resource Manager, должен иметь UnwrapKey (для получения ключа для расшифровки) и WrapKey (для вставки ключа в хранилище ключей при создании нового ключа).

Примечание.

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

Преимущества

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

Недостатки

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

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

Некоторые службы Azure позволяют использовать модель управления ключами Host Your Own Key (HYOK) для организаций с специализированными требованиями к безопасности. Этот режим управления полезен в строго регулируемых сценариях, когда требуется шифровать данные в состоянии покоя и управлять ключами в собственном репозитории полностью вне контроля Microsoft, за пределами защиты, управляемой платформой по умолчанию, и необязательных ключей, управляемых клиентом, в Azure Key Vault.

В этой модели служба должна использовать ключ из внешнего сайта для расшифровки ключа шифрования данных (DEK). Затронуты гарантии производительности и доступности, а конфигурация значительно сложнее. Кроме того, так как служба не имеет доступа к DEK во время операций шифрования и расшифровки, общие гарантии безопасности этой модели похожи на то, когда ключи управляются клиентом в Azure Key Vault. В результате эта модель не подходит для большинства организаций, если они не имеют очень конкретных нормативных требований или требований безопасности, которые не могут быть выполнены с ключами, управляемыми платформой, или ключами, управляемыми клиентом, в Azure Key Vault. Из-за этих ограничений большинство служб Azure не поддерживают шифрование на стороне сервера с помощью ключей, управляемых клиентом, в оборудовании, управляемом клиентом. Один из двух ключей в шифровании двойных ключей следует этой модели.

Доступ к ключам

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

Преимущества

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

Недостатки

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

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

• Службы, поддерживающие cmKs в Azure Key Vault и Управляемом HSM Azure
• Использование шифрования в Azure
• Двойное шифрование