Представлено Ping Identity
Компанії повинні розглядати архітектуру безпеки нульової довіри (zero trust) як нагальну вимогу для ШІ-агентів, а не як довгострокову мету. Про це заявив Андре Дюран, генеральний директор та засновник Ping Identity. Нульова довіра — це модель безпеки, що базується на припущенні, що жоден користувач, пристрій чи система не повинні мати автоматичної довіри. Вона вимагає постійної верифікації перед кожною дією, а не одноразової перевірки під час входу. Агентний штучний інтелект (AI) суттєво скоротив часові рамки ризиків, якими повинні керувати підприємства, вимагаючи оцінки рішень щодо дозволів у режимі реального часу.
Це скорочення проявляється у накопиченні дозволів. Кожного разу, коли співробітник схвалює запит ШІ-агента на доступ до корпоративного диска, бази даних або репозиторію коду, компанія передає крихту контролю, яка в ізоляції виглядає звичайною. Серед тисяч агентів, які роблять тисячі запитів, ці схвалення накопичуються, створюючи ризики, виміряти які більшість існуючих архітектур безпеки ніколи не були призначені.
«Зростання бажання використовувати агентів прямо зараз та швидкість агентного ШІ підкреслюють необхідність прискорити впровадження принципів нульової довіри, — каже Дюран. — Агенти просто працюють швидше, і крапка. Компрометація людини може вимірюватися хвилинами або годинами, іноді днями. З агентною швидкістю тисяча дій може відбутися за п’ять хвилин».
Чому нульова довіра тепер є нагальною для агентного ШІ
Ця різниця у швидкості змінює спосіб, яким підприємства повинні думати про дозволи. Важливими є дві змінні: площа доступу, надана агенту, та термін дії цього доступу. Традиційне керування ідентифікацією та доступом (IAM) має тенденцію надавати широкі дозволи та залишати сесії відкритими протягом тривалого часу, оскільки людина, яка їх використовує, рухається зі звичайною швидкістю. Нульова довіра, навпаки, одночасно скорочує обидві змінні, звужуючи доступ до того, що суворо необхідно, і постійно перевіряючи його, а не один раз під час входу.
«Нульова довіра насправді просто означає: достатньо, вчасно, — каже Дюран. — Нас хвилює ваша наступна дія. Ми переводимо ідентифікацію з ери, коли доступ був нашим контрольним пунктом виконання — тобто, чи були ви ввійшли, чи була у вас сесія — до рішення, яке стоїть за цим входом».
Чому агенти повинні розглядатися як повноцінні ідентичності
Цей перехід до контролю на основі рішень має прямі наслідки для того, як агенти повинні бути надані спочатку. Поширена практика дозволяти агенту працювати під клонованим логіном людини або спільного облікового запису сервісу не працює, каже Дюран.
«Кожен агент повинен мати власну ідентичність, — пояснює він. — Він не повинен видавати себе за людину. Він може діяти від імені людини, ми можемо явно делегувати повноваження агенту, але ми не хочемо розмивати межі між людиною, яка діє, та агентом, який діє».
І понад це є ще одна проблема: спільні секрети, зокрема ключі API, на які досі покладаються багато облікових записів сервісів. Наприклад, звичка вбудовувати ключі безпосередньо в вихідний код, де вони можуть бути випадково зафіксовані та розкриті, є зручним, але слабким патерном безпеки, який агентні робочі процеси роблять значно ризикованішим. Побудова архітектур облікових записів сервісів, які дозволяють агентам автентифікуватися без покладання на ці спільні облікові дані або інший довгостроковий постійний доступ, тепер є терміновим пріоритетом, а не довгостроковим проєктом з очищення.
Де підприємства можуть застосувати політики нульової довіри
Застосування будь-чого з цього на практиці вимагає визначення того, де політика може бути реально застосована. Кілька існуючих точок контролю, включаючи API-шлюзи та агентний шлюз, що знаходиться перед серверами MCP, пропонують практичні місця, де підприємства можуть перевіряти, що запитує агент, і застосовувати правила політики перед наданням доступу.
«Ці політики можуть використовувати сигнали ризику та шахрайства в реальному часі, а потім детерміновано застосовувати, що може робити агент при взаємодії з цими системами», — пояснює Дюран.
Мета — перенести авторизацію з одноразового рішення під час входу до оцінки в момент кожної значущої дії, наприклад, коли агент намагається зафіксувати код у репозиторії. Замість того, щоб мати постійний дозвіл на запис до GitHub, запит агента буде перевірятися на основі контексту та політики в конкретний момент, скорочуючи вікно довіри до обсягу однієї дії.
Зупинення ШІ-агентів від зміни власних дозволів
Ця модель стає особливо важливою, враховуючи, як агенти можуть поводитися, потрапивши до системи — наприклад, агенти для написання коду, які, будучи запитаними, визнали, що вони або ігнорують певну захисну планку, або намагаються змінити надані їм дозволи.
«Хто спостерігає за спостерігачем? Тут має застосовуватися нульова довіра, — каже Дюран. — Якщо генеративні системи ШІ дотримуються ваших інструкцій у 97% випадків, і ви просто просите у них пораду, це може бути нормально. Якщо ж вони відповідають за прийняття рішення про те, кого впускати, 97% — це недостатньо».
Як довіряти виводам, згенерованим ШІ, з агентною швидкістю
Відповіддю на цю прогалину є не усунення ШІ з процесу перегляду, а структурування переглядів таким чином, щоб судження жодного окремого агента не приймалося на віру. Оскільки людський перегляд не може масштабуватися до обсягу та швидкості виведення агентів без втрати переваг використання агентів взагалі, необхідна нова структура, щоб коли один агент створює роботу, наприклад, код, інші агенти оцінювали її, за умови, що агенти, які перевіряють, не мають права спілкуватися між собою або з тим, якого вони перевіряють. Це нова парадигма людина-ШІ, каже Дюран.
«Нам, ймовірно, доведеться розробити структури, яким ми довіряємо, не бачачи або не перевіряючи виведення безпосередньо, — пояснює він. — Це не означає, що ця конструкція на 100% безвідмовна. Однак, це найкраще, що ми можемо зробити, щоб рухатися з агентною швидкістю. Ми не можемо довіряти точному виведенню, але ми можемо довіряти структурі».
На практиці це означає поєднання автоматизованого перегляду з чіткою людською відповідальністю за рішення з вищим ризиком, а не розглядати виведення агента як самоперевірене.
Для традиційних аудиторів перегляд кожної транзакції окремо ніколи не є можливим, і статистично обґрунтована вибірка замінює повну перевірку. Те саме стосується накопичення ризиків: одна дія агента може нести невеликий ризик сама по собі, тоді як послідовність дій, що рухаються в одному напрямку, може перетнути поріг, що спрацьовує втручання, включаючи “вимкнення”, здатне зупинити агента до подальшої шкоди.
Що запитувати під час оцінки платформ ідентифікації агентів
Для керівників відділів безпеки, які оцінюють платформи ідентифікації для агентного ШІ, не існує вузького контрольного списку. Підприємства повинні оцінювати, як виглядає повний життєвий цикл управління агентами. Більшість підприємств одночасно керують агентами з двох фронтів: агенти, орієнтовані на клієнтів, що діють від імені зовнішніх користувачів, та внутрішні агенти, розгорнуті для автоматизації корпоративних процесів.
«Зупиніться на достатній час, щоб побачити повну картину того, що означає захист численних агентів, як тих, що взаємодіють з вами ззовні, так і тих, що розгорнуті всередині, — каже Дюран. — Нам потрібне виявлення та видимість усіх агентів, що працюють у нашому середовищі, місце для їх реєстрації, стандартний спосіб призначення відповідальних осіб та спосіб побудови та централізації політик, щоб безпека могла застосовувати їх у всій організації».
І хоча базові принципи безпеки були повністю зрозумілі ще до появи агентного ШІ, змінилося, каже Дюран, те, що вартість повільного руху нарешті наздогнала вартість недбалого руху, надаючи підприємствам вузьке вікно для побудови правильної архітектури, перш ніж широке впровадження агентів зробить переробку набагато дорожчою.
Спонсоровані статті — це контент, створений компанією, яка або платить за публікацію, або має ділові стосунки з VentureBeat, і вони завжди чітко позначені. Для отримання додаткової інформації звертайтеся за адресою [email protected].
Як захиститися (Порада ІТ-Блогу): Впроваджуйте принцип найменших привілеїв для всіх облікових записів, особливо для системних та агентних. Перевіряйте та регулярно оновлюйте дозволи, щоб вони відповідали виключно поточним завданням.
За даними порталу: venturebeat.com