Поделиться через

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

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

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

Примечание.

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

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

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

  • Контрольная плоскость
  • Плоскость данных

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

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

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

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

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

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

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

Это важно

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

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

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

Аутентификация Microsoft Entra

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

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

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

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

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

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

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

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

Настройка тегов управляемого модуля HSM		 Azure RBAC
Плоскость данных Международная контактная информация:
<hsm-name>.managedhsm.azure.net:443
 Ключи: шифрование, расшифровка,
разархивировать, архивировать, проверить, подписать, получить, перечислить, обновить, создать, импортировать, удалить, сделать резервную копию, восстановить, очистить

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

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

Домен безопасности: скачивание и отправка домена безопасности		 Управляемый HSM с локальным RBAC

Контрольная плоскость и 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>: область уровня ключа. Субъекты безопасности, которым назначена роль в этой области, могут выполнять операции, определенные в этой роли для всех версий указанного ключа.

Управляемый HSM: локальный RBAC имеет несколько встроенных ролей для решения различных сценариев управления доступом. Полный список ролей и их разрешений см. в разделе «Встроенные роли локального RBAC для управляемого HSM».

Microsoft Entra управление привилегированными пользователями (PIM)

Чтобы повысить безопасность административных ролей, используйте Microsoft Entra Privileged Identity Management (PIM). PIM обеспечивает доступ по требованию (JIT), что снижает риск наличия постоянных административных привилегий. Он также обеспечивает видимость назначений ролей и применяет рабочие процессы утверждения для управления повышенным доступом.

Разделение обязанностей и управление доступом

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

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

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

Этим концептуальным ролям следует предоставлять только те разрешения, которые необходимы для выполнения их обязанностей. Реализация разделения обязанностей требует назначения ролей на уровне плоскости управления (Azure RBAC) и плоскости данных (управляемый HSM с локальным RBAC).

Подробное руководство по реализации разделения обязанностей с конкретными примерами и командами Azure CLI см. в статье "Безопасный доступ к управляемым HSM".

Дальнейшие действия

  • Last updated on