Авторизация в Microsoft Entra Agent ID

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

Идентификатор агента Microsoft Entra был создан для устранения этого пробела. Созданная на платформе идентификатора Microsoft Entra ID, она предоставляет выделенную платформу проверки подлинности и авторизации для агентов искусственного интеллекта, которые позволяют им безопасно получать доступ к службам и API, предоставляя администраторам центральный способ мониторинга и управления ими. Короче говоря, удостоверения агентов позволяют организациям обнаруживать, управлять и защищать агентов ИИ, работающих в арендаторе, с соответствующим применением политики, вместо того чтобы рассматривать агентов как пользователей или общие приложения.

В этой статье объясняется, как авторизация в идентификаторе агента Microsoft Entra Agent работает для агентов ИИ, предоставляя сведения о ролях, элементах управления разрешениями и рекомендациях по управлению доступом к агенту.

Почему авторизация удостоверений агента важна

Агенты ИИ могут быстро выполнять задачи и масштабироваться. Многие функции с высоким уровнем привилегий в Microsoft Entra ID (например, возможность управления пользователями или ролями) предполагают, что администратор действует с осторожностью и намерением. Неуправляемый агент с высокими привилегиями может выполнять непредвиденные административные задачи с большим влиянием (например, удаление пользователей или изменение параметров безопасности).

По этой причине сервис Microsoft Entra ID ограничивает функции идентичностей агента. Например, Microsoft Entra блокирует агентов от получения высокопривилегированных ролей или разрешений. Пользователи и администраторы не могут согласиться с этими мощными разрешениями для агента. Эта конструкция признает, что агенты должны работать с минимальными привилегиями. Предотвращая получение конфиденциальных привилегий агентами, система сводит к минимуму риск того, что агент ИИ может повысить доступ. Список разрешенных ролей и разрешений будет развиваться со временем.

Назначения ролей Microsoft Entra для удостоверений агента

С точки зрения авторизации, удостоверение агента в некотором роде ведёт себя как приложение или пользователь с дополнительными мерами безопасности. У каждого удостоверения агента есть субъект-служба или пользователь в идентификаторе Microsoft Entra ID, и его можно назначить определенным ролям Microsoft Entra.

Например, удостоверение агента можно назначить роль Microsoft Entra, чтобы предоставить ему права администратора, но для агентов заблокированы многие роли каталогов с высоким уровнем привилегий. Роли, такие как глобальный администратор, администратор привилегированных ролей или администратор пользователей, не могут быть назначены учетным записям агентов. Можно назначить агенту только более низкие привилегированные роли (например, роль читателя). Вы не можете назначать настраиваемые роли идентификаторам агента. Кроме того, удостоверения агента не могут быть членами групп с назначаемыми ролями.

Корпорация Майкрософт создала роли администратора идентификатора агента и разработчика идентификаторов агента для управления и создания самих агентов.

Роли Microsoft Entra, доступные для агентов

Ниже представлен список ролей Microsoft Entra, которые могут быть назначены учетным записям агентов.

• Администратор ИИ
• Автор атакующего кода
• Администратор симуляции атаки
• Читатель назначения атрибутов
• Читатель определения атрибутов
• Администратор журнала атрибутов
• Читатель журналов атрибутов
• Администратор Azure DevOps
• Администратор Azure Information Protection
• Администратор политики IEF B2C
• Администратор выставления счетов
• Администратор Cloud App Security
• Администратор соответствия требованиям
• Администратор данных соответствия требованиям
• Лицо, утверждающее доступ к защищенному хранилищу
• Администратор Аналитики компьютеров
• Читатели каталогов
• Учетные записи синхронизации службы каталогов
• Администратор Dynamics 365
• Администратор Dynamics 365 Business Central
• Администратор Microsoft Edge
• Администратор Exchange
• Администратор получателей в Exchange
• Администратор пользователей расширенного каталога
• Администратор потоков пользователей с внешним идентификатором
• Администратор атрибутов потоков пользователей с внешним идентификатором
• Администратор Фабрики
• Глобал Ридер
• Средство чтения журналов глобального безопасного доступа
• Администратор Insights
• Аналитика аналитики
• Аналитика для руководителей компаний
• Администратор устройств Интернета вещей
• Администратор Kaizala
• Администратор знаний
• Диспетчер знаний
• Администратор лицензий
• Читатель конфиденциальности данных Центра сообщений
• Читатель центра сообщений
• Администратор резервного копирования Microsoft 365
• Администратор миграции Microsoft 365
• Локальный администратор устройства, присоединенного к Microsoft Entra
• Администратор подключения к данным Microsoft Graph
• Администратор гарантии оборудования Майкрософт
• Специалист по гарантии оборудования Майкрософт
• Администратор сети
• Администратор приложений Office
• Администратор фирменной символики организации
• Администратор источника данных организации
• Утверждающий организационные сообщения
• Запись сообщений организации
• Администратор пользователей
• Администратор мест
• Администратор Power Platform
• Администратор принтера
• Специалист по принтеру
• Просмотрщик отчетов
• Администратор поиска
• Редактор поиска
• Администратор службы поддержки
• Администратор SharePoint
• Администратор SharePoint Embedded
• Администратор Skype для бизнеса
• Администратор Microsoft Teams
• Администратор по коммуникациям в Teams
• Инженер службы поддержки коммуникаций Teams
• Специалист службы поддержки связи Teams
• Администратор устройств Teams
• Читатель Teams
• Администратор телефонии Teams
• Создатель клиента
• Средство чтения сводки об использовании
• Диспетчер успешных операций с пользовательским интерфейсом
• Администратор виртуальных посещений
• Администратор клиента Viva Glint
• Администратор целей Viva
• Администратор Viva Pulse
• Администратор Windows 365
• Администратор развертывания Центра обновления Windows
• Администратор Yammer

Разрешения Microsoft Graph для идентификаторов агентов

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

Однако набор разрешений API Microsoft Graph с высоким риском явно блокируется для агентов. Например, агенту не удается предоставить следующие разрешения:

Заблокированное разрешение	Примечания.
Application.ReadWrite.All	Позволяет управлять всеми приложениями.
RoleManagement.ReadWrite.All	Включает полный контроль над пользователями, группами, ролями, параметрами каталога и другими критически важными операциями.
User.ReadWrite.All	Предоставляет полный контроль над всеми учетными записями пользователей.
Directory.AccessAsUser.All	Предоставляет доступ к информации в каталоге в качестве пользователя, вошедшего в систему. Гарантирует, что агент не может обойти безопасность, запрашивая широкий доступ к Microsoft Graph, даже администратор не может предоставить агенту эти разрешения.

Идентификаторам агентов по-прежнему могут быть предоставлены разрешения с более низким уровнем привилегий в соответствующих случаях. Например, если агенту нужно прочитать почтовый ящик пользователя или файл OneDrive от имени этого пользователя, он может запросить делегированное разрешение, например Mail.Read , или Files.Read пользователь (или администратор) может предоставить согласие. Они не считаются высокими привилегиями в смысле на уровне клиента; Они привязаны к данным этого пользователя.

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

Использование ролей Azure, ролей Microsoft Entra или разрешений Microsoft Graph

В зависимости от того, что нужно сделать агенту, администраторы могут предоставлять доступ по-разному, чтобы обеспечить соответствующую область. Это включает назначение ролей Azure, ролей Microsoft Entra, разрешений OAuth, включая разрешения Graph, назначения ролей приложения, назначения пакетов доступа и членства в группах.

Роли в Azure

Если агенту требуется доступ к ресурсам Azure: назначьте роли Azure для этих конкретных ресурсов. Например, чтобы разрешить агенту читать Azure Key Vault, назначьте его учетной записи роль чтения Key Vault Reader в этом хранилище. Это позволяет ограничить область (только этот ресурс или группу ресурсов) и использовать наименьшие привилегии. Дополнительные сведения см. в разделе Назначение ролей Azure с помощью портала Azure.

Роли Microsoft Entra

Если агенту необходимо выполнить действия на уровне каталога: используйте роли Microsoft Entra только в том случае, если существует подходящая более низкая привилегированная роль. Например, если агенту нужно только считывать основные сведения о каталоге, можно использовать роль типа читателя каталогов. Если необходимо предоставить агенту доступ на запись, тщательно изучите последствия и выберите роль с минимальными привилегиями. Возможно, не существует соответствующей встроенной роли, которая не заблокирована. В этих случаях вы можете использовать разрешения Microsoft Graph вместо этого (с пониманием их ограничений). Дополнительные сведения см. в разделе Назначение ролей Microsoft Entra.

Делегированные разрешения Microsoft Graph

Если агент действует от имени пользователя (пользовательские сценарии): используйте делегированные разрешения Microsoft Graph. Этот параметр требует интерактивного согласия пользователя, но гарантирует, что агент не может превышать доступ этого пользователя. Например, агент планирования собраний для Алисы будет использовать делегированные разрешения API календаря; Алиса дает согласие, и агент может управлять только календарем Алисы (так же, как Алиса может самостоятельно). Дополнительные сведения см. в разделе "Обзор разрешений и согласия" на платформе удостоверений Майкрософт.

Разрешения приложения Microsoft Graph

Если агент работает автономно в пределах клиента (сценарии службы): следует использовать разрешения приложений Microsoft Graph экономно. Предоставляйте только те разрешения приложению, которые действительно необходимы, и только если они не требуют высокого уровня привилегий. Например, агент, создающий организационные диаграммы, может нуждаться в разрешении User.Read.All для чтения всех профилей, что может быть приемлемым (и не находится в списке заблокированных), в то время как User.ReadWrite.All будет отклонён.

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