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

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

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

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

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

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

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

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

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

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

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

Сценарии проверки подлинности 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. Приложение использует любой поддерживаемый метод проверки подлинности на основе типа приложения. Приложение получает маркер ресурса в плоскости для предоставления доступа. Ресурс — это конечная точка в плоскости управления или данных на основе среды Azure. Приложение использует маркер и отправляет запрос REST API в Key Vault. Чтобы узнать больше, просмотрите весь поток проверки подлинности.

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

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

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

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

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

Поток операций запроса в Key Vault с аутентификацией

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

1. Например, токен запрашивает аутентификацию с использованием Microsoft Entra ID:

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

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

3. Вызов REST API Key Vault через его адрес (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:

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

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

Клиентские библиотеки Azure Identity

Дополнительные сведения о рекомендациях и примерах разработчиков см. в статье "Проверка подлинности в Key Vault" в коде

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

• Руководство разработчика Key Vault

• Назначение политики доступа Key Vault с помощью портала Azure

• Назначьте роль Azure RBAC для Key Vault

• Устранение неполадок политики доступа Key Vault

• Коды ошибок REST API Key Vault

• Что такое управление доступом на основе ролей в Azure (RBAC)?