Microsoft Entra Agent ID чи service principals: що краще для ваших ШІ-агентів?
By Mirko Peters ·
Порівняння Microsoft Entra Agent ID і service principals. Дізнайтеся, чому ШІ-агентам потрібні окремі системи ідентифікації та управління через blueprint у M365.
Automatically translated with AI from the original post. Read the English original

Під час розгортання автономних ШІ-працівників у Microsoft 365 вибір правильної моделі ідентифікації має вирішальне значення. Традиційні service principals давно керують стандартними навантаженнями застосунків, але не справляються з короткочасними ШІ-агентами з високою швидкістю роботи. Microsoft Entra Agent ID пропонує окрему архітектуру, яка відокремлює керування обліковими даними від дозволів агентів, вирішуючи ключові проблеми безпеки та можливості аудиту.
Головне
- Service principals прив'язують облікові дані та дозволи безпосередньо до окремого застосунку, через що короткочасні ШІ-агенти з високою швидкістю роботи важко відстежувати й захищати.
- Microsoft Entra Agent ID відокремлює облікові дані, зберігаючи їх у централізованому blueprint, а окремим агентам-працівникам призначає унікальні ідентифікатори.
- Ідентифікатори агентів усувають локальні секрети на самому агенті, значно зменшуючи потенційну зону ураження, якщо компонент буде скомпрометовано.
- Blueprint дозволяють адміністраторам застосовувати масові політики, керувати циклом життя та слугувати абсолютним аварійним вимикачем для цілих груп ШІ-агентів.
- Керовані ідентифікатори залишаються ідеальним вибором для коду, розміщеного в Azure, тоді як Agent ID створені спеціально для автономних ШІ-агентів, які самостійно ухвалюють рішення під час виконання.
Розуміння розриву в ідентифікації ШІ-працівників
ШІ-агенти не вкладаються в традиційні корпоративні рамки ідентифікації. На відміну від звичайних користувачів, які автентифікуються паролями або кодами багатофакторної автентифікації, і на відміну від традиційних застосунків, що покладаються на сталі довготривалі службові облікові записи, ШІ-агенти працюють динамічно. Завантажений автоматизований процес може створити тисячі екземплярів агентів і знищити їх усі протягом одного робочого дня. Коли ці ефемерні агенти використовують спільні службові облікові записи або позичають облікові дані людей, ваші журнали аудиту швидко перетворюються на ненадійну вигадку.
Крім того, коли інцидент трапляється о другій ночі, ІТ-адміністраторам потрібно відповісти на два фундаментальні запитання: який саме агент виконав цю дію і хто за неї відповідає? Традиційні реєстрації застосунків і спільні service principals роблять відповідь на ці запитання майже неможливою без порушення роботи не пов'язаних із ними навантажень. Саме ця операційна сліпа зона спонукала Microsoft створити спеціалізовану систему для нелюдських працівників.
Service principals проти Agent ID: архітектурні відмінності
Щоб зрозуміти, чому Microsoft Entra Agent ID є справжнім зсувом парадигми, потрібно розуміти, чим він структурно відрізняється від звичайного service principal. Service principal є один до одного екземпляром об'єкта застосунку у вашому клієнті. Він має власні довготривалі секрети, клієнтські сертифікати та прямі призначення дозволів. Для стабільних, передбачуваних веб-застосунків і фонових демонів ця модель працює добре вже багато років.
Однак примусове використання стандартного service principal для ШІ-агента створює серйозні адміністративні труднощі:
- Розростання облікових даних: щоразу, коли автоматизований процес створює новий екземпляр агента, створення нового service principal залишає розсипані по середовищу клієнтські секрети.
- Проблеми з гранулярністю: щоб вимкнути один агент, що неправильно поводиться, доводиться перебирати сотні service principals, ризикуючи випадково зупинити критичні бізнес-процеси.
- Неоднозначність аудиту: спільні облікові записи застосунків приховують, який саме екземпляр робочого процесу звернувся до чутливих корпоративних даних.
На відміну від цього, модель Agent ID вводить зв'язок «батько–нащадок» через адміністративний шаблон (blueprint). Шаблон надійно зберігає облікові дані автентифікації та визначає дозволені області доступу, а окремі ідентичності агентів мають унікальні ідентифікатори і створюються динамічно. Сама ідентичність агента не містить пароля чи секрету, тож у середовищі виконання немає облікових даних, які може викрасти зловмисник.
Сила шаблонів в управлінні парком агентів
Ключова新 інновація Microsoft Entra Agent ID полягає в об'єкті blueprint. Уявіть шаблон як головний зразок, який керує парком пов'язаних ШІ-агентів. Наприклад, якщо ваша організація розгортає шаблон «Sales Assistant Agent», ви можете динамічно створити регіональні екземпляри для Північної Америки, Південної Америки та Європи на основі цього єдиного визначення.
Оскільки ці агенти використовують спільний шаблон, адміністратори отримують потужні можливості управління, які легко масштабуються:
- Централізоване застосування політик: Застосування політики умовного доступу або обмеження дозволів Microsoft Graph до шаблону автоматично охоплює кожен екземпляр агента, створений з нього, включно з майбутніми екземплярами.
- Остаточний аварійний вимикач: Якщо в певному класі агентів виявлено вразливість, вимкнення батьківського шаблону миттєво припиняє автентифікацію для кожної підлеглої ідентичності агента в усьому клієнті.
- Керування через призначених спонсорів: Для кожної ідентичності агента потрібен названий спонсор-людина. Якщо цей спонсор залишає організацію, Microsoft Entra автоматично передає спонсорство його безпосередньому керівнику, запобігаючи безнаглядній роботі «осиротілих» ШІ-навантажень.
Коли використовувати кожен тип ідентичності в архітектурі
Сучасним середовищам Microsoft 365 та Azure потрібен багатогранний підхід до несаморобних (non-human) ідентичностей. Правильний вибір механізму запобігає прогалинам у безпеці та зайвому адміністративному навантаженню.
Managed Identities для коду, розміщеного в Azure
Якщо ваш власний код, функції або мікросервіси працюють безпосередньо в інфраструктурі Azure, завжди обирайте Managed Identities. Azure автоматично керує життєвим циклом і ротацією облікових даних, тож немає жодних секретів, за якими команда мусить стежити або які можуть випадково потрапити до репозиторіїв вихідного коду.
Service Principals для традиційних застосунків
Продовжуйте використовувати стандартні service principals для усталених корпоративних застосунків, інтеграцій SaaS і довгоживучих фонових служб (daemon), яким потрібні постійні, виділені контексти застосунків і традиційні потоки облікових даних клієнта.
Agent ID для автономних ШІ-агентів
Звертайтеся до Microsoft Entra Agent ID саме тоді, коли розгортаєте ШІ-агентів, наприклад створених у Copilot Studio або власних фреймворках оркестрації, які динамічно оцінюють ситуації, ухвалюють автономні рішення та взаємодіють з даними Microsoft 365 від імені користувачів або робочих процесів.
Захист вашого хмарного майбутнього
Оскільки автономний штучний інтелект стає опорою цифрової трансформації, керування ШІ-агентами за допомогою застарілих сервісних облікових записів створює неприйнятний борг безпеки. Завдяки Microsoft Entra Agent ID ІТ-адміністратори можуть використовувати швидкість і масштаб сучасного ШІ, зберігаючи суворе управління, чіткі журнали аудиту та надійні обмеження за принципом найменших привілеїв. Щоб глибше зрозуміти, як ці механізми працюють усередині, слухайте повний епізод і долучайтеся до нашої розмови про захист хмари Microsoft.
Поширені запитання
Чи зберігають Microsoft Entra Agent ID паролі або секрети локально?
Ні. Ідентичності агентів спеціально створені без локальних облікових даних, секретів чи сертифікатів. Механізмами автентифікації надійно керує батьківський шаблон, що не дає зловмисникам витягти ключі із середовища виконання агента.
Як шаблони агентів працюють із розгортаннями в кількох клієнтах?
Шаблони можна публікувати для кількох організацій як багатоклієнтні шаблони. Однак коли клієнт розгортає шаблон у своєму клієнті, створені ідентичності агентів суворо однoклієнтські та локальні, що повністю обмежує зону ураження межами вашої організації.
Що станеться з ШІ-агентом, якщо його спонсор-людина залишить компанію?
Щоб ШІ-агенти-«сироти» не працювали безконтрольно, Microsoft Entra автоматично передає спонсорство ідентичності агента безпосередньому керівнику спонсора, що йде.
Чи можна застосовувати політики умовного доступу безпосередньо до ідентифікаторів агентів?
Так. Механізми умовного доступу оцінюють сигнали входу для ідентифікаторів агентів так само, як для звичайних користувачів. Крім того, якщо спрямувати політику на шаблон агента (blueprint), ці правила автоматично застосовуватимуться до всіх поточних і майбутніх екземплярів агентів, створених із цього шаблону.