За підтримки JumpCloud
Практична структура для безпечного керування всіма ідентичностями сучасних працівників — як людьми, так і системами.
Ваша організація вже має чіткий процес управління ідентичностями співробітників. Нові працівники проходять онбординг, отримують посаду, набір прав доступу та призначеного керівника, відповідального за їхні повноваження. При звільненні їхні облікові дані анулюються, а доступ припиняється. Це добре відомий IT-процес: кожна робоча ідентичність, що має доступ до ваших систем, повинна бути відомою, мати визначені межі повноважень та нести відповідальність з моменту свого входження до вашого світу і до моменту завершення роботи.
Але сьогодні у тих самих системах працюють AI-агенти. Вони отримують доступ до Salesforce, створюють заявки в Jira, надають інфраструктуру, обробляють фінансові операції та спілкуються від імені ваших команд. За всіма важливими показниками вони є членами вашої робочої сили, за винятком того, що в більшості організацій вони ніколи не проходили онбординг, не мають призначеного власника та процесу виведення з експлуатації після завершення своєї місії.
Дослідження JumpCloud за 3 квартал 2026 року виявило, що нелюдські ідентичності зараз переважають над користувачами-людьми в 83% організацій, і лише 21% впровадили механізми контролю саме для них. Наведена нижче структура призначена для усунення цього розриву.
Етап 1: Виявлення всіх агентів, що працюють у вашому середовищі
Управління починається з точного обліку, а більшість організацій працюють з неповними даними. AI-агенти розгортаються командами розробки продуктів, керівниками операцій та окремими співробітниками, які мають як інструменти, так і мотивацію для швидких дій. IT-відділ перебирає на себе відповідальність за управління вже після факту, часто не знаючи повного обсягу розгорнутих рішень.
Практичним наслідком цього є “тіньовий ШІ”: агенти, що працюють у виробничих середовищах без офіційної реєстрації, без визначеного власника та без систематичного способу їх зупинити у разі виникнення проблем. Виявлення вашої популяції агентів — це безперервний процес, а не одноразовий аудит. Створіть інвентаризацію для кожного середовища, де можуть працювати агенти: хмарні платформи, керовані пристрої, SaaS-інтеграції та локальні системи. Для кожного агента документуйте, до чого він має доступ, які робочі процеси він впливає, та що запускає його дії. Цей інвентарний список є основою для всього іншого у цій структурі.
Етап 2: Реєстрація кожного агента як формальної ідентичності з призначеним власником
Кожен агент, що працює у вашому середовищі, повинен існувати як формальна ідентичність у вашій директорії, з тими ж основними атрибутами, що й будь-який співробітник: визначена мета, межі авторизованих дій та призначений власник-людина, який несе відповідальність за його поведінку.
Це архітектурне рішення, яке відрізняє організації, здатні керувати своїми агентами, від тих, які ні. Агенти, зареєстровані як належні ідентичності, можуть отримувати права доступу, підпадати під дію політик умовного доступу та включатися до переглядів доступу. Агенти, що існують лише як обхідні шляхи для облікових записів служб або як ключі API в змінних середовища, не можуть бути керовані жодним систематичним способом.
Реєстрація також є механізмом для боротьби з “зомбі-агентами”: агентами, які пережили свою початкову мету, але продовжували працювати, отримувати доступ до систем та накопичувати повноваження. Коли кожен агент матиме призначеного власника, відповідального за його поновлення, агенти без активного власника природно втратять доступ, коли цей власник припинить свою діяльність. Процес виведення з експлуатації відбувається як наслідок процесу, а не як реактивний захід після того, як щось пішло не так.
Етап 3: Керування доступом агентів за принципом найменших привілеїв та без постійних облікових даних
Зареєстровані агенти потребують доступу для виконання своїх завдань. Керівним принципом такого доступу є найменші привілеї: кожен агент повинен мати права доступу, чітко визначені згідно з його призначенням, з доступом, що є обмеженим у часі, де це можливо, та може бути негайно відкликаний, якщо поведінка агента зміниться.
Постійні облікові дані в змінних середовища є постійною вразливістю. Статичні ключі API, які ніколи не змінюються, є постійною вразливістю. На практиці безпечне керування доступом агентів означає надання облікових даних “just-in-time” для привілейованих операцій, створення робочих процесів затвердження, які вимагають схвалення людиною перед тим, як агенти отримають доступ до конфіденційних систем, та підтримку механізмів екстреного вимкнення, що працюють зі швидкістю, необхідною для ситуації.
Для агентів, яким потрібен доступ до привілейованих веб-додатків, SSH-серверів або баз даних, шифрування облікових даних є додатковою вимогою: агент повинен мати можливість виконати своє завдання без того, щоб базові облікові дані взагалі потрапляли до моделі, яка ним керує. Кожен привілейований сеанс повинен бути записаний та доступний для аудиту.
Етап 4: Безперервне управління поведінкою агентів, а не лише під час розгортання
Перші три етапи встановлюють контроль. Управління — це те, що підтримує їх актуальність. Це безперервна практика перевірки відповідності фактичних дій агентів їхнім авторизованим діям та коригування курсу, коли виникають розбіжності.
Кожна дія агента повинна бути зареєстрована. Перегляд доступу повинен відбуватися регулярно, оцінюючи, чи залишаються права доступу кожного агента відповідними його поточній меті. Коли поведінка агента відхиляється від його визначеної сфери, аномалія повинна бути виявлена до того, як вона переросте в інцидент. Коли мета агента завершується, відкликання доступу має бути процедурним кроком, а не реактивним заходом, спричиненим чимось, що пішло не так.
Управління також означає підтримку аудиторського сліду, необхідного для відповіді на питання про відповідальність: до чого мав доступ цей агент, які дії він здійснив, хто його авторизував і яким був результат? Організації, які не можуть відтворити цей ланцюжок для будь-якого конкретного агента, насправді не керують своїми агентами. Вони розгорнули їх і сподівалися на краще.
Фундамент, що лежить в основі всіх чотирьох етапів
Кожен етап цієї структури стає значно складнішим для виконання, коли базове IT-середовище фрагментоване. Ідентичність, доступ, управління пристроями та засоби безпеки, рознесені по різних disconnected системах, створюють прогалини, через які провалюється управління агентами, і організації застосовують різні політики в різних місцях, замість послідовного управління всюди.
Дослідження JumpCloud показало, що організації, які працюють у повністю уніфікованих IT-середовищах, у п’ять разів частіше розгортають агентів у критично важливих для бізнесу робочих процесах, ніж ті, що використовують фрагментовані стеки. Саме від того, наскільки злагодженим є рівень контролю для одночасного застосування послідовних політик до людей, пристроїв та агентів, залежить, чи буде управління масштабуватися разом із впровадженням ШІ, чи відставатиме від нього.
Це головна передумова Agentic IAM (управління ідентичністю для агентів): управління людьми, пристроями та агентами через єдиний злагоджений рівень контролю робить вищезазначену структуру реалізованою у масштабі, а не лише бажаною.
Забезпечення безпеки кожної ідентичності, як людської, так і нелюдської, є операційною основою, яка робить ШІ безпечним для масштабування. Організації, які побудують її зараз, не тільки зменшать ризики. Вони розширять застосування ШІ на більше робочих процесів, рухатимуться швидше і робитимуть це з впевненістю, яка походить від знання того, що кожна ідентичність у їхньому середовищі відома, керована та підзвітна.
Звіт JumpCloud “Q3 2026 IT Trends Research” (n=800 IT-лідерів, США + Великобританія) доступний тут. Структура життєвого циклу Agentic IAM, згадана у цій статті, розроблена JumpCloud та доступна тут.
Грег Келлер — CTO та співзасновник JumpCloud.
Спонсоровані статті — це контент, створений компанією, яка або оплачує публікацію, або має ділові стосунки з VentureBeat, і вони завжди чітко позначені. Для отримання додаткової інформації звертайтеся за адресою [email protected].
Дізнатися більше на: venturebeat.com