Кількість агентів ШІ зростає швидше, ніж більшість організацій може відстежувати, не кажучи вже про управління ними. За прогнозами IDC, до 2028 року їхня кількість сягне 1,3 мільярда.
Кожна команда, яка впроваджує агента, також часто ненавмисно створює новий обліковий запис. Цей обліковий запис може отримувати доступ до систем, переміщувати дані та діяти від чийогось імені. Зараз головне завдання – взяти ситуацію під контроль, перш ніж вона стане некерованою, і перший крок полягає у відповіді на базове запитання: чия це зона відповідальності?
Чи це юридичний відділ, оскільки хтось має розробити правила обробки даних агентом? Чи це команда управління обліковими записами, яка спостерігає за зростанням їхньої кількості, доки співробітники розгортають агентів без подання запитів на доступ? Або ж це керівник, команда якого створила агента, спираючись на теорію, що той, хто зробив його, має нести відповідальність?
Якщо чітко вказати на когось неможливо, чесною відповіддю, найімовірніше, буде «ніхто». Така неоднозначність призводить до того, що доступ не перевіряється, дозволи залишаються активними після виконання свого призначення, а агенти без відповідальних продовжують функціонувати.
За даними дослідження Cloud Security Alliance, лише 15% організацій мають чітко визначених відповідальних за 76–100% своїх агентів ШІ. Водночас у 34% організацій відповідальність встановлена лише для 26–50% агентів. Ці результати свідчать про суттєвий розрив між темпами впровадження агентів ШІ та здатністю організацій забезпечити належний контроль за ними. Такі наслідки виникають, коли позиція «хтось повинен за це відповідати» не трансформується в чіткий розподіл: «ця конкретна посада відповідає за це, і ось як можна буде дізнатися, що ця функція більше не виконується».
Закріплення статусу відповідального – це формальність. Фактична відповідальність – це робочий процес
Відповідь на питання «за ким закріплено цього агента» не обмежується лише особою. Це також процес, який періодично перевіряє доступ, скасовує його в разі втрати доцільності та фіксує ці події. За відсутності такого процесу статус відповідального перетворюється на фікцію: це лише найменування без фактичної підзвітності. Відповідальність не можна делегувати одноразово й залишити без нагляду. Вона потребує систематичного підтвердження через робочий процес, що діє навіть тоді, коли первинний відповідальний не слідкує за ситуацією.
Наслідки відсутності такого механізму
Прикладом можуть слугувати розробники, які запускають автономні агенти для написання коду на власних кінцевих точках: відділ IT ніколи не погоджував використання цих інструментів і часто навіть не бачить їх. Проте першою реакцією не має бути їхнє блокування. Натомість необхідно розробити робочий процес, який відповідатиме реальним умовам виконання роботи.
На практиці це означає одноразову авторизацію, прив’язану до конкретної особи, що поєднується з регулярним циклом повторної атестації. Розпочинати впровадження варто із 30-денного циклу повторного підтвердження. Цей період є достатньо коротким, щоб після завершення проєкту доступ не зберігався протягом цілого кварталу. Це вимагає від відповідальної особи підтвердження того, що доступ досі є обґрунтованим, замість припущення, що дозвіл минулого кварталу залишається чинним.
Такий самий підхід застосовується до управління схемами розподілу відповідальності. У схемі вказується ім’я відповідального. Цикл перевіряє, чи це ім’я досі відповідає дійсності, і відкликає доступ, якщо це не так.
Як Netwrix Identity Manager перетворює призначеного відповідального на фактично підтвердженого
Netwrix Identity Manager – це рішення для управління обліковими записами та їх адміністрування, яке керує non-human identities з 2018 року, задовго до того, як ШІ-агенти стали проблемою. Воно застосовує до агентів таку саму модель сертифікації та життєвого циклу, як і до сервісних та машинних облікових записів.
Identity Manager реалізує це через автоматичне скасування доступу на основі сертифікації. Доступ, наданий ШІ-агенту, підлягає періодичній сертифікації за розкладом, так само як і доступ користувача-людини. Якщо проєкт завершився, відповідальний залишив посаду або доступ більше не є обґрунтованим, сертифікатор не затвердить його повторно, а Identity Manager автоматично відкличе дозвіл замість того, щоб залишати його активним. Не має значення, чи закріплено ім’я за 100% агентів, якщо немає механізму, який вимагає повторної перевірки цього імені. Неперевірений або покинутий агент втрачає доступ самостійно.
Закріплення відповідальних за ШІ-агентами
Сертифікація дозволів за допомогою запланованих кампаній
Підсумок
Кожен ШІ-агент необхідно включити до програми управління обліковими записами та закріпити за ним відповідального, який зможе перевіряти його доступ. Після цього слід запланувати кампанії із сертифікації, що вимагатимуть від цього відповідального проведення повторної сертифікації із заданою періодичністю. У випадках, коли відповідальному потрібна додаткова інформація, варто активувати функцію делегування, щоб він міг отримувати рекомендації від залучених до процесу співробітників, не знімаючи із себе відповідальності.
Відповідальний і надалі погоджує права, а доступ усе одно перевіряється особою, яка ухвалює рішення про його збереження, виключаючи автоматичне подовження.
Призначення відповідального розв’язує питання лише одноразово. Управління ж забезпечує безперервний контроль, тому відповідальність зберігається ще довго після зміни організаційної структури.
