У хмарній екосистемі Microsoft Entra ID виявлено критичну уразливість, пов’язану з новою привілейованою роллю Agent ID Administrator. Помилка в її налаштуванні дозволяла атакувальнику переходити від керування ідентичностями AI-агентів до повного захоплення високопривілейованих service principal, що напряму створювало ризик ескалації привілеїв і компрометації ключових хмарних ресурсів організації.
Agent identity в Entra ID: навіщо потрібні ролі для AI-агентів
Microsoft розробила платформу agent identity для підтримки AI-агентів у Microsoft Entra ID. Йдеться про нефізичні ідентичності — програмні компоненти, сервіси та боти, які мають автентифікуватися, запитувати токени доступу й взаємодіяти з ресурсами всередині орендаря (tenant) без участі людини.
Для керування повним життєвим циклом таких агентських ідентичностей було запроваджено вбудовану роль Agent ID Administrator. Її завданням є створення й оновлення агентів, керування ключами й іншими обліковими даними. За дизайном scope цієї ролі мав обмежуватися винятково «агентськими» об’єктами.
Суть уразливості: надмірний scope та захоплення service principal
За результатами дослідження компанії Silverfort, у визначенні області дії ролі Agent ID Administrator була допущена помилка. Користувач із цією роллю фактично міг вийти за межі передбачених повноважень і працювати з довільними service principal, а не лише з AI-агентами.
Дослідник безпеки Ноа Аріель продемонстрував, що адміністратор агентів мав можливість призначити себе власником будь-якого service principal у каталозі, у тому числі такого, що взагалі не пов’язаний з AI-агентами. Після цього зловмисник міг додати власні ключі чи сертифікати для автентифікації від імені цього об’єкта, фактично здійснивши повний захоплення service principal.
Якщо скомпрометований service principal був включений до привілейованих ролей каталогу або мав високорівневі дозволи в Microsoft Graph (наприклад, на зміну конфігурації безпеки, роботу з поштою, файлами чи секретами), це відкривало атакувальнику канал для ескалації привілеїв та подальшого розширення контролю в орендарі.
Чому компрометація service principal є критичною
У сучасних хмарних середовищах service principal часто використовуються для CI/CD-пайплайнів, інтеграцій із SaaS-сервісами, резервного копіювання, управління інфраструктурою як кодом та інших критичних бізнес-процесів. Для стабільної роботи їм нерідко надають ширший набір прав, ніж окремим користувачам.
Захопивши такий об’єкт, зловмисник отримує доступ до всіх дій, дозволених легітимному застосунку: від читання й модифікації конфігурації каталогу до роботи з поштовими скриньками, календарями, файловими сховищами та секретами. У поєднанні з правами на зміну інших об’єктів ідентичностей це створює стійкий вектор для латерального переміщення інфраструктурою та довготривалого закріплення.
Дії Microsoft: виправлення ролі Agent ID Administrator
Компанія Silverfort відповідально повідомила Microsoft про уразливість 1 березня 2026 року. Після аналізу ризиків Microsoft розгорнула виправлення у всіх хмарних середовищах 9 квітня 2026 року, звузивши область дії ролі Agent ID Administrator до коректних кордонів.
Після оновлення будь-яка спроба призначити володіння неагентським service principal за допомогою цієї ролі тепер блокується. Адміністратор отримує помилку 403 Forbidden, що ефективно запобігає захопленню сторонніх об’єктів ідентичності.
Уроки для управління ролями та нефізичними ідентичностями
Цей інцидент наочно демонструє, наскільки критичною є точна валідація scope ролей і дозволів, особливо коли нові типи ідентичностей (наприклад, AI-агенти) будуються поверх уже наявних механізмів на кшталт service principal. Будь-яке «накладання» прав без жорсткого розмежування може призвести до ненавмисного розширення доступу.
Зростання кількості нефізичних ідентичностей — сервісних акаунтів, мікросервісів, контейнерів, роботизованих систем — перетворює їх на один із ключових векторів атак. Слабкий контроль над власниками таких об’єктів, їхніми секретами та ключами значно підсилює вплив подібних помилок у налаштуванні ролей.
Практичні рекомендації для захисту Microsoft Entra ID
1. Постійний моніторинг чутливих ролей. Організаціям варто налаштувати сповіщення на всі дії, пов’язані зі зміною власників service principal та оновленням їхніх облікових даних. Нестандартні операції (особливо від нетипових адміністраторів або з незвичних локацій) мають автоматично потрапляти до розслідування.
2. Жорсткий контроль власників service principal. Коло користувачів, які можуть ставати власниками критичних об’єктів, повинно бути максимально обмеженим. Регулярний перегляд списків власників допомагає виявляти аномальні або застарілі призначення.
3. Захист привілейованих service principal. Необхідно послідовно впроваджувати принцип найменших привілеїв, регулярно ревізувати ролі та дозволи, зберігати секрети в спеціалізованих сховищах (Secret Management, Key Vault) та мінімізувати термін дії ключів.
4. Аудит операцій із ключами та сертифікатами. Журнали автентифікації та змін у Microsoft Entra ID мають інтегруватися з SIEM-рішеннями, що дозволяє оперативно виявляти підозріле створення, обертання або відкликання облікових даних service principal і агентів.
Історія з роллю Agent ID Administrator показує, що кожна нова функція, пов’язана з AI-агентами та нефізичними ідентичностями, потребує не лише ретельного тестування з боку постачальника, а й додаткового рівня контролю з боку самої організації. Регулярна ревізія прав, прозорий моніторинг дій високопривілейованих об’єктів та культура «zero trust» у роботі з хмарними ідентичностями стають необхідною умовою для стійкої кібербезпеки в епоху автоматизації та штучного інтелекту.
