Share via

Шифрование с ключами, управляемыми клиентом, в Microsoft Cloud for Sovereignty

  • Статья

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

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

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

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

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

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

Выбор функций шифрования данных

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

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

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

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

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

Выбор решений для управления ключами

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

Рабочие нагрузки, обрабатывающие конфиденциальные данные, могут получить выгоду от дополнительной гарантии, обеспечиваемой такими решениями, как управляемый модуль HSM Azure, включая проверенные аппаратные модули безопасности FIPS-140-2 уровня 3, которые оснащены дополнительными средствами управления безопасностью для защиты хранящихся криптографических материалов.

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

Операционные модели для управления ключами

Azure Key Vault реализует управление доступом на основе ролей по-разному, в зависимости от того, используете ли вы уровень Standard/Premium Azure Key Vault или управляемый модуль HSM Azure Key Vault. Эти различия в управлении доступом могут повлиять на то, как организация использует эти функции. В этом разделе описываются эти различия и то, как они могут повлиять на то, как организация выбирает свои операционные процессы для управления ключами в облаке.

Ограничения соответствия для проверки FIPS-140 уровня 3

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

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

Операции управления ключами в управляемом модуле HSM Azure Key Vault

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

Дополнительные сведения об управлении доступом в управляемом модуле HSM:

Организациям, планирующим использовать модуль Azure Key Vault HSM, следует просмотреть список встроенных ролей RBAC и разрешенные операции для управляемого модуля HSM и конкретно планировать решение для следующих сценариев эксплуатации:

  • Создание нового ключа в управляемом модуле HSM
  • Операции управления существующим ключом с использованием плоскости управления, такие как обновление ключа или ротация ключей
  • Использование плоскости данных существующего ключа приложением или службой

В настоящее время единственный способ назначить разрешения на создание нового ключа — это назначить роль, например Crypto User, что также включает в себя другие разрешения, такие как ротация и удаление ключей. В результате предоставление участнику рабочей группы приложения необходимых разрешений для создания собственных ключей в управляемом модуле HSM, вероятно, может нарушить принципы минимальных привилегий, поскольку этот пользователь также будет иметь административные разрешения для всех ключей в модуле HSM. Эту проблему можно решить, создав централизованную рабочую группу с повышенными разрешениями, которая может облегчить запросы на создание ключей, или внедрив автоматизацию, которая может облегчить запросы на создание новых ключей через процессы управления ИТ-услугами, которые используют API-интерфейс REST управляемого модуля HSM.

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