Microsoft Entra Agent ID и сервисные принципалы: что выбрать для ваших AI-агентов?

By Mirko Peters · 2026-10-26

Сравнение Microsoft Entra Agent ID и сервисных принципалов. Разбираем, зачем AI-агентам нужны выделенные фреймворки идентификации и управление через блупринты в M365.

Automatically translated with AI from the original post. Read the English original

При развёртывании автономных AI-агентов в Microsoft 365 выбор модели идентификации имеет решающее значение. Традиционные сервисные принципалы долгое время управляли стандартными прикладными нагрузками, но плохо справляются с кратковременными высокоскоростными AI-агентами. Microsoft Entra Agent ID вводит выделенную архитектуру, которая отделяет управление учётными данными от разрешений агентов и решает серьёзные задачи безопасности и аудита.

Главное

• Сервисные принципалы привязывают учётные данные и разрешения непосредственно к отдельному приложению, из-за чего высокоскоростных и short-lived AI-агентов сложно отслеживать и защищать.
• Microsoft Entra Agent ID отделяет учётные данные, храня их в центральном блупринте, и назначает уникальные идентификаторы отдельным агентам.
• Идентификаторы агентов исключают локальные секреты на самом агенте, значительно уменьшая потенциальную зону поражения при компрометации компонента.
• Блупринты позволяют администраторам применять массовые политики, управлять жизненным циклом и использовать как абсолютный аварийный выключатель для целых семейств AI-агентов.
• Управляемые идентификаторы остаются оптимальным выбором для кода, размещённого в Azure, тогда как Agent ID создан специально для автономных AI-агентов, которые принимают самостоятельные решения во время выполнения.

Понимание разрыва в идентификации для AI-агентов

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

Кроме того, когда инцидент случается в два часа ночи, ИT-администраторам нужно ответить на два фундаментальных вопроса: какой именно агент выполнил это действие и кто за него отвечает? Традиционные регистрации приложений и общие сервисные принципалы делают ответ на эти вопросы почти невозможным без риска нарушить работу не связанных с ними нагрузок. Именно этот операционный слепой пятно и стало причиной, по которой Microsoft разработала специализированный фреймворк для нечеловеческих «работников».

Сервисные принципалы и Agent ID: архитектурные различия

Чтобы понять, почему Microsoft Entra Agent ID — это смена парадигмы, нужно разобраться, чем он структурно отличается от стандартного сервисного принципала. Сервисный принципал — это экземпляр объекта приложения «один к одному» в вашем клиенте. Он содержит собственные долгоживущие секреты, клиентские сертификаты и прямые назначения разрешений. Для стабильных предсказуемых веб-приложений и фоновых демонов эта модель работает годами.

Однако принуждение AI-агента использовать стандартный сервисный принципал создаёт серьёзные административные трудности:

• Разрастание учётных данных: каждый раз, когда автоматизированный процесс запускает новый экземпляр агента, создание свежего сервисного принципала оставляет разбросанные клиентские секреты по всей среде.
• Проблемы с гранулярностью: отключение одного некорректно работающего агента требует просмотра сотен сервисных принципалов с риском случайно остановить критически важные бизнес-процессы.
• Неоднозначность аудита: общие учётные записи приложений скрывают, какой именно экземпляр рабочего процесса обратился к конфиденциальным корпоративным данным.

В отличие от этого, модель Agent ID вводит отношение «родитель-потомок» через административный шаблон (blueprint). Шаблон надежно хранит учетные данные для аутентификации и определяет допустимые области доступа (scopes), а отдельные идентификаторы агентов получают уникальные идентификаторы и создаются динамически. Сам идентификатор агента не содержит пароля или секрета, поэтому у злоумышленника нет учетных данных, которые можно было бы извлечь из среды выполнения.

Сила blueprint-шаблонов в управлении парком агентов

Ключевая инновация Microsoft Entra Agent ID заключается в объекте blueprint. Представьте blueprint как главный шаблон, который управляет парком связанных ИИ-агентов. Например, если в вашей организации развернут шаблон «Sales Assistant Agent», из этого единственного описания можно динамически создать региональные экземпляры для Северной Америки, Южной Америки и Европы.

Поскольку эти агенты используют общий blueprint, администраторы получают мощные возможности управления, которые легко масштабируются:

• Централизованное применение политик: Применение политики условного доступа или ограничения разрешений Microsoft Graph к blueprint автоматически распространяется на каждый экземпляр агента, созданный из него, включая будущие экземпляры.
• Главный аварийный выключатель: Если в конкретном классе агентов обнаружена уязвимость, отключение родительского blueprint немедленно останавливает аутентификацию для всех связанных идентификаторов агентов во всем клиенте.
• Управление через назначенного спонсора: Для каждого идентификатора агента требуется назначенный спонсор-человек. Если этот спонсор покидает организацию, Microsoft Entra автоматически передает спонсорство его руководителю, не позволяя «бесхозным» ИИ-нагрузкам работать без контроля.

Когда использовать каждый тип идентификаторов в вашей архитектуре

Современные среды Microsoft 365 и Azure требуют комплексного подхода к нечеловеческим идентификаторам. Правильный выбор механизма позволяет избежать брешей в безопасности и лишней административной нагрузки.

Управляемые идентификаторы для кода, размещенного в Azure

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

Service Principals для традиционных приложений

Продолжайте использовать стандартные service principals для стабильных корпоративных приложений, интеграций SaaS и долгоживущих фоновых служб, которым нужен постоянный выделенный контекст приложения и традиционные потоки client credentials.

Agent ID для автономных ИИ-агентов

Обращайтесь к Microsoft Entra Agent ID именно тогда, когда развертываете ИИ-агентов, например созданных в Copilot Studio или в собственных фреймворках оркестрации, которые динамически оценивают ситуацию, принимают автономные решения и взаимодействуют с данными Microsoft 365 от имени пользователей или рабочих процессов.

Безопасное облачное будущее

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

Часто задаваемые вопросы

Хранят ли Microsoft Entra Agent ID пароли или секреты локально?

Нет. Идентификаторы агентов намеренно не содержат локальных учетных данных, секретов или сертификатов. Механизмы аутентификации надежно управляются родительским blueprint, что не позволяет злоумышленникам извлекать ключи из среды выполнения агента.

Как blueprint-шаблоны работают в развертываниях с несколькими клиентами?

Blueprint можно публиковать в организациях как шаблоны для нескольких клиентов. Однако когда клиент развертывает blueprint в своем клиенте, создаваемые идентификаторы агентов строго однoклиентские и локальные, что гарантирует полную изоляцию зоны поражения в границах вашей организации.

Что происходит с ИИ-агентом, если его спонсор-человек покидает компанию?

Чтобы «бесхозные» ИИ-агенты не работали бесконтрольно, Microsoft Entra автоматически передает спонсорство идентификатора агента прямому руководителю уходящего спонсора.

Можно ли применять политики условного доступа напрямую к идентификаторам агентов?

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