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

Проверка подлинности в Azure Key Vault

Аутентификация с помощью Key Vault работает вместе с Microsoft Entra ID, который отвечает за аутентификацию любого заданного субъекта безопасности.

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

  • Субъект безопасности user определяет человека, имеющего профиль в Microsoft Entra ID.

  • Субъект безопасности group определяет набор пользователей, созданных в Microsoft Entra ID. Все роли или разрешения, назначенные группе, предоставляются всем пользователям в группе.

  • Субъект-служба представляет собой тип субъекта безопасности, который идентифицирует приложение или службу, то есть часть кода, а не пользователя или группу. Идентификатор объекта субъекта-службы действует как имя пользователя; Секрет клиента субъекта-службы действует как пароль.

Для приложений существует два способа получения служебного принципала:

  • Рекомендуется: включить управляемое удостоверение , назначаемое системой для приложения.

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

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

  • Если вы не можете использовать управляемое удостоверение, вместо этого зарегистрируйте приложение в вашем клиенте Microsoft Entra, как описано в Quickstart: Register an application with the Azure identity platform. Регистрация также создает второй объект приложения, который идентифицирует приложение во всех арендаторах.

сценарии проверки подлинности Key Vault

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

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

  • Только пользователь: пользователь обращается к ключевому сейфу из любого приложения, зарегистрированного в арендаторе. Примеры этого типа доступа включают Azure PowerShell и портал Azure. Чтобы этот сценарий работал при использовании политик доступа (устаревших), идентификатор пользователя objectId должен быть указан в политике доступа, а applicationIdне должен быть указан или должен быть null. При использовании Azure RBAC назначьте соответствующие роли пользователю.

  • Приложение-пользователь (иногда называется составным идентификатором): пользователю необходимо получить доступ к хранилищу ключей из конкретного приложения , и приложение должно использовать поток аутентификации от имени (OBO) для имитации пользователя. Чтобы этот сценарий работал с политиками доступа (устаревшими версиями), в политике доступа должны быть указаны оба элемента applicationId и objectId. Определяет applicationId необходимое приложение и objectId идентифицирует пользователя. В настоящее время этот параметр недоступен для плоскости данных Azure RBAC.

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

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

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

Настройка брандмауэра Key Vault

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

Дополнительные сведения смотрите в разделе Доступ к Azure Key Vault за брандмауэром.

Поток выполнения операций запроса в Key Vault с проверкой подлинности

Аутентификация Key Vault происходит при каждом запросе на Key Vault. После получения токена его можно использовать повторно для последующих вызовов. Пример потока проверки подлинности:

  1. Запрос токена для проверки подлинности с помощью Microsoft Entra ID, например:

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

  2. Если проверка подлинности с помощью Microsoft Entra ID выполнена успешно, субъект безопасности получает маркер OAuth.

  3. Вызов REST API хранилища ключей через его конечную точку (URI).

  4. Key Vault Брандмауэр проверяет следующие критерии. Если любое из них соблюдается, вызов разрешается. Иначе вызов блокируется и возвращается запрещённый ответ.

    • Брандмауэр отключен, а общедоступная конечная точка Key Vault доступна из публичного Интернета.
    • Вызывающий объект является доверенной службой Key Vault, что позволяет обойти брандмауэр.
    • Абонент указан в брандмауэре по IP-адресу, виртуальной сети или точке подключения к службе.
    • Вызывающий может получить доступ к Key Vault через настроенное подключение приватного соединения.

  5. Если брандмауэр разрешает вызов, Key Vault вызывает Microsoft Entra ID для валидации токена доступа учетной записи безопасности.

  6. Key Vault проверяет, имеет ли субъект безопасности необходимые разрешения для запрошенной операции. В противном случае служба Key Vault возвращает ответ «доступ запрещен».

  7. Key Vault выполняет запрошенную операцию и возвращает результат.

На следующей схеме показан процесс вызова приложения, вызывающего API Key Vault Get Secret:

Процесс проверки подлинности в Azure Key Vault

Замечание

Key Vault клиенты SDK для секретов, сертификатов и ключей делают дополнительный вызов Key Vault без токена доступа, что приводит к 401 ошибке при попытке получить информацию о клиенте. Дополнительные сведения см. в разделе "Проверка подлинности", "Запросы и ответы"

Проверка подлинности для Key Vault в коде приложения

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

Клиентские библиотеки Azure для идентификации

.NET Python Java JavaScript
Azure SDK для удостоверений .NET Пакет SDK Azure Identity для Python пакет SDK для удостоверения личности Azure Identity Java Azure Identity SDK для JavaScript

Дополнительную информацию о лучших практиках и примерах для разработчиков см. в статье Аутентификация в Key Vault в коде

Дальнейшие шаги

  • Last updated on