Управление доступом для управляемого устройства HSM

  • Статья

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

В этой статье описывается модель контроля доступа к Управляемому устройству HSM. Здесь приводится описание процессов аутентификации и авторизации, а также сведения о том, как защитить доступ к управляемым устройствам HSM.

Примечание.

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

Модель управления доступом

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

  • Плоскость управления
  • Плоскость данных

На плоскости управления вы управляете самим HSM. К операциям в этой плоскости относятся создание и удаление управляемых модулей HSM, а также получение их свойств.

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

Для доступа к управляемому модулю HSM в этих плоскостях у всех вызывающих объектов должна быть надлежащая проверка подлинности и авторизация. Проверка подлинности устанавливает удостоверение вызывающего объекта. Авторизация определяет, какие операции может выполнять вызывающий объект. Вызывающий объект может быть одним из субъектов безопасности, определенных в идентификаторе Microsoft Entra: пользователя, группы, субъекта-службы или управляемого удостоверения.

Оба самолета используют идентификатор Microsoft Entra для проверки подлинности. Для авторизации они используют разные системы:

  • В плоскости управления используется управление доступом на основе ролей Azure (Azure RBAC), система авторизации, созданная на основе Azure Resource Manager.
  • В плоскости данных используется управляемый RBAC уровня HSM (управляемый локальный RBAC HSM), система авторизации, реализованная и применяемая на управляемом уровне HSM.

При создании управляемого устройства HSM запрашивающий предоставляет список администраторов плоскости данных (поддерживаются все субъекты безопасности). Только эти администраторы могут получить доступ к управляемому плоскостю данных HSM для выполнения ключевых операций и управления назначениями ролей плоскости данных (управляемый HSM local RBAC).

Модели разрешений для обоих плоскостей используют один и тот же синтаксис, но они применяются на разных уровнях, а назначения ролей используют разные область. Плоскость управления Azure RBAC применяется Azure Resource Manager, а управляемый HSM управляемый HSM локальный RBAC уровня данных применяется самим управляемым HSM.

Важно!

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

Но есть исключение: члены роли Microsoft Entra Global Администратор istrator всегда могут добавлять пользователей в роль управляемого модуля HSM Администратор istrator для целей восстановления, например, если нет допустимых учетных записей управляемого модуля HSM Администратор istrator. Дополнительные сведения см. в рекомендациях по обеспечению безопасности роли глобального Администратор стратора Microsoft Entra ID.

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

Проверка подлинности Microsoft Entra

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

Приложение проходит проверку подлинности с помощью идентификатора Microsoft Entra перед вызовом любого уровня. Приложение может использовать любой поддерживаемый метод проверки подлинности в зависимости от типа приложения. Для получения доступа приложение запрашивает маркер для ресурса в плоскости. Ресурс — это конечная точка в плоскости управления или плоскости данных в зависимости от среды Azure. Приложение использует маркер и отправляет запрос REST API в конечную точку управляемого устройства HSM. Чтобы узнать больше, просмотрите весь поток проверки подлинности.

Использование одного механизма проверки подлинности для обоих плоскостей имеет несколько преимуществ:

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

Конечные точки ресурсов

Субъекты безопасности получают доступ к плоскостям через конечные точки. Элементы управления доступом для двух плоскостей работают независимо. Чтобы предоставить приложению доступ к использованию ключей в управляемом HSM, вы предоставляете доступ к плоскости данных с помощью управляемого HSM локального RBAC. Чтобы предоставить пользователю доступ к ресурсу Managed HSM для создания, чтения, удаления, перемещения управляемых HSM и редактирования других свойств и тегов, используйте Azure RBAC.

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

Плоскость доступа Конечные точки доступа Operations Механизм контроля доступа
Плоскость управления Международная контактная информация:
management.azure.com:443
 Создание, чтение, обновление, удаление и перемещение управляемых модулей HSM

Задание тегов управляемых модулей HSM		 Azure RBAC
Плоскость данных Международная контактная информация:
<hsm-name>.managedhsm.azure.net:443
 Ключи: расшифровка, шифрование,
unwrap, wrap, verify, sign, get, list, update, create, import, delete, restore, purge

Управление ролями плоскости данных (управляемое локальное RBAC управляемого модуля HSM): перечисление определений ролей, назначение ролей, удаление назначений ролей, определение настраиваемых ролей

Резервное копирование и восстановление: резервное копирование, восстановление, проверка состояние операций резервного копирования и восстановления

Домен безопасности: скачивание и отправка домена безопасности		 Локальная система RBAC управляемого модуля HSM

Плоскость управления и Azure RBAC

В плоскости управления используется Azure RBAC для авторизации операций, которые может выполнять вызывающий объект. В модели Azure RBAC каждая подписка Azure имеет экземпляр идентификатора Microsoft Entra. Вы можете предоставить доступ пользователям, группам и приложениям из этого каталога. Доступ предоставляется для управления ресурсами подписки, используюющими модель развертывания Azure Resource Manager. Чтобы предоставить доступ, используйте портал Azure, Azure CLI, Azure PowerShell или REST API Azure Resource Manager.

Вы создаете хранилище ключей в группе ресурсов и управляете доступом с помощью идентификатора Microsoft Entra. Можно предоставить пользователям или группе возможность управлять хранилищами ключей в группе ресурсов. Вы можете предоставить доступ в определенной области путем назначения соответствующих ролей Azure. Чтобы предоставить пользователю доступ к управлению хранилищами ключей, ему необходимо назначить предопределенную роль key vault Contributor в определенной области. Следующие уровни область можно назначить роли Azure:

  • Группа управления: роль Azure, назначенная на уровне подписки, применяется ко всем подпискам в этой группе управления.
  • Подписка: роль Azure, назначенная на уровне подписки, применяется ко всем группам ресурсов и ресурсам в рамках данной подписки.
  • Группа ресурсов: роль Azure, назначенная на уровне группы ресурсов, применяется ко всем ресурсам в этой группе ресурсов.
  • Определенный ресурс: роль Azure, назначенная для определенного ресурса, применяется к данному ресурсу. В этом случае ресурс является определенным хранилищем ключей.

Предопределено несколько ролей. Если заданные роли не соответствуют вашим потребностям, вы можете определить собственные. Дополнительные сведения см. в статье Azure RBAC: встроенные роли.

Плоскость данных и локальная система RBAC управляемого модуля HSM

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

  • /или /keys: область уровня HSM. Субъекты безопасности, которым назначена роль в этом область, могут выполнять операции, определенные в роли для всех объектов (ключей) в управляемом HSM.
  • /keys/<key-name>: область уровня ключа. Субъекты безопасности, которым назначена роль в этом область, могут выполнять операции, определенные в этой роли только для всех версий указанного ключа.

Следующие шаги