Інтерв’ю
Якоб Ідеског, CTO компанії Curity – Серія інтерв’ю
Якоб Ідеског є спеціалістом з ідентифікації та технічним директором компанії Curity. Більшість його часу зайнята розробкою рішень з безпеки в сфері API та веб-технологій. Він працював над розробкою та впровадженням рішень OAuth та OpenID Connect для великих підприємств та малих стартапів.
Curity – це сучасна платформа управління ідентифікацією та доступом (IAM), побудована навколо сервера ідентифікації Curity, стандартного рішення, призначеного для забезпечення безпеки автентифікації та авторизації для додатків, API та цифрових сервісів у великих масштабах. Вона підтримує протоколи, такі як OAuth 2.0 та OpenID Connect, для централізації потоків входу, забезпечення детального контролю доступу та видачі безпечних токенів як для людей, так і для клієнтів-машин, включаючи API та сервіси. Платформа розроблена з урахуванням гнучкості та масштабованості, що дозволяє організаціям розгортати її в хмарі, гібридних чи локальних середовищах, інтегрувати з існуючими системами та забезпечувати безпечний та безперебійний досвід користувачів без використання спеціально розробленої безпеки інфраструктури.
Ви провели більшу частину своєї кар’єри, будуючи системи ідентифікації та безпеки API, від співзаснування Curity до керівництва компанією як технічний директор під час зростання хмарних технологій та现在 штучного інтелекту. Як це вплинуло на вашу думку про те, що агенти штучного інтелекту повинні розглядатися як першокласні цифрові ідентифікатори, а не просто як ще один шматок програмного забезпечення?
По всім галузям технологій, над якими я працював, одна проблема постійно повторюється. Чи це хмарні обчислення, чи зараз штучний інтелект, якщо програмне забезпечення діє від імені людини або іншої системи, у вас є проблема ідентифікації.
З масовим впровадженням агентів штучного інтелекту ця проблема посилюється. Їх поведінка вже не строго скриптована, і вони діють з рівнем автономності, який підприємства раніше не бачили. Агенти штучного інтелекту приймають рішення, викликають API та ланцюжки дій у різних системах – часто без безпосереднього нагляду людини. Це поведінка створює проблеми ідентифікації та доступу, які фундаментально відрізняються від традиційного програмного забезпечення.
Розгляд агентів штучного інтелекту як першокласних цифрових ідентифікаторів – це єдиний спосіб правильно звернутися до цієї проблеми. Якщо організації розглядають їх просто як ще один процес або сервісний аккаунт, вони швидко втрачають видимість та контроль – і це рецепт безпеки кризи.”
Багато підприємств зацікавлені в агентах штучного інтелекту, але залишаються в експериментальній фазі. З того, що ви бачите в реальних розгортаннях, які найпоширеніші пробіли в ідентифікації та управлінні, що перешкоджають організаціям масштабувати агентів безпечно?
Більшість експериментів відбувається в ізольованих пісочницях, які ігнорують те, що відбувається у великих масштабах. Під час ранніх пілотних проєктів команди часто надають агентам широкі ключі API, спільні облікові дані або загальні дозволи в хмарі просто для того, щоб запустити все.
Цей підхід розраховується на те, що агенти розгортаються за межами пілотних проєктів. Це відбувається тому, що команди з безпеки не можуть бачити, які дані агент отримав доступ, його дії чи чи він може чи вже перевищив свій передбачуваний обсяг; випадково чи зловмисно. Ці сліпі плями роблять неможливим безпечне управління агентами, тому багато організацій борються з переходом за межі пілотних проєктів.”
Ви стверджували, що суворі обмеження необхідні для агентів штучного інтелекту. Як виглядає “хороша” ідентифікаційна конструкція для агентів штучного інтелекту на практиці, і де компанії зазвичай помиляються?
Хороша ідентифікаційна конструкція починається з принципу мінімальних привілеїв та дозволів, пов’язаних з явною метою. Кожному агенту штучного інтелекту повинен бути присвоєний свій власний ідентифікатор, вузькі дозволи та чітко визначені довірчі відносини (явні правила для систем, з якими йому дозволено взаємодіяти). Засадniczo, доступ повинен бути прив’язаний до мети, обмежений у часі та легко скасовуватися.
Де компанії помиляються, так це в повторному використанні існуючих сервісних аккаунтів або припущенні, що внутрішні агенти безпечні за замовчуванням. Це припущення не витримує реальних загроз. Зловмисні актори активно шукають саме ці слабкі місця, а агенти штучного інтелекту драматично збільшують потенційний радіус ураження, коли конструкція ідентифікації погана.”
Curity вже довгий час працює з такими стандартами, як OAuth та OpenID Connect. Наскільки критично відкриті стандарти ідентифікації для забезпечення взаємодії та безпеки агентів штучного інтелекту в складних підприємствах?
Відкриті стандарти абсолютно критичні. Підприємства вже використовують складні тканини ідентифікації, що охоплюють хмарні платформи, сервіси SaaS та внутрішні API. Агенти штучного інтелекту тільки додають ще більше складності.
Без стандартів кожен агент стає своєю власною інтеграцією та постійною виключенням з безпеки. З стандартами, такими як OAuth та OpenID Connect, агентів можна автентифікувати, авторизувати та аудітувати так само, як і будь-яке інше навантаження. Це єдиний підхід, який може забезпечити безпечне масштабування в реальних підприємствах.”
Нелюдські ідентифікатори стають все більш поширеними, від сервісних аккаунтів до ідентифікаторів машин. Що робить агентів штучного інтелекту фундаментально відмінними від попередніх нелюдських ідентифікаторів з точки зору безпеки?
Ключова різниця між сучасними агентами штучного інтелекту та старішими нелюдськими ідентифікаторами (НХІ) полягає в автономності. Традиційний сервісний аккаунт робить саме те, що йому каже його код, строго прив’язаний до своєї задачі. Агент штучного інтелекту інтерпретує інструкції, адаптує свою поведінку та здійснює дії, які ніколи не були явно прописані – все це збільшує потенційну небезпеку, якщо немає відповідних обмежень.
Маленька помилка в ідентифікації або доступі може швидко перетворитися на катастрофу, оскільки агент може діяти з швидкістю та в різних системах. З точки зору безпеки це представляє великий ризик.”
Як важливі аудитні сліди та ідентифікаційна реєстрація для управління агентами штучного інтелекту, особливо в регульованих галузях?
Аудитні сліди не повинні бути “бажаним”. Вони повинні бути закладені з самого початку. У регульованих середовищах організації очікується, що вони зможуть відповісти на прості, але критичні питання: що агент отримав доступ, коли це відбулося, і хто це авторизував?
Ідентифікаційна реєстрація – це єдиний надійний спосіб отримати такий рівень підзвітності. Вона також відіграє ключову роль у реагуванні на інциденти. Без чіткого контексту ідентифікації майже неможливо знати, чи проблема виникла через агента, який поводився неправильно, скомпрометовану ідентифікацію чи просто поганий запит.”
Які реальні ризики ви бачите, що виникають, коли організації розгортають агентів штучного інтелекту з надмірними привілеями або погано контролюють їх у виробництві?
Одним з поширених ризиків є тихе збирання даних. Агент з надмірними привілеями може витягнути чутливі дані з різних систем (записи клієнтів, внутрішні документи, журнали) та потім розкрити ці дані через запити, резюме чи зовнішні інтеграції.
Іншим ризиком є агенти з адміністративним доступом, які здійснюють великі зміни з швидкістю машин, що спричиняє набагато більше шкоди, ніж людина могла б за короткий період часу. Це може включати зміну хмарних ресурсів, відключення засобів безпеки чи активацію автоматизованих робочих процесів без нагляду.
Ці інциденти можуть бути зловмисними, але вони не повинні бути. Агент з надмірними привілеями або погано контрольований агент може просто діяти на основі застарілих або неправильних припущень, посилюючи помилки в різних системах, перш ніж хто-небудь помітить.”
Для компаній, які переходять від пілотних проєктів до реальних розгортань агентів штучного інтелекту, які рішення щодо ідентифікації та доступу повинні бути прийняті на ранній стадії, щоб уникнути дорогих переробок пізніше?
Організації повинні вирішити на ранній стадії, як агентам видаються ідентифікатори, як дозволи затверджуються та як доступ переглядається з часом, визначаючи межі ідентифікації заздалегідь.
Введення контролю ідентифікації ретроспективно майже завжди проблематично. Агенти часто глибоко вплетені у робочі процеси за допомогою спільних облікових даних або широких ролей, тому звуження доступу після факту порушує припущення, на яких система спирається. Це в кінцевому підсумку призводить до того, що робочі процеси виходять з ладу та підірвають довіру до технології. Це значно дешевше, не кажучи вже про безпечніше, спроєктувати правильні ідентифікатори, області та межі доступу з самого початку.”
Де інтеграція ідентифікації найчастіше стає瓶нем при розгортанні агентів штучного інтелекту, і які найкращі практики допомагають зменшити тертя?
Управління ідентифікацією може стати瓶нем, але тільки тоді, коли його розглядають як післяthought. Команди зосереджуються на будівництві вражаючих можливостей агентів спочатку, тільки щоб пізніше зрозуміти, що їм потрібно інтегруватися з системами IAM, брамами API та платформами реєстрації, щоб бути真正ньо безпечними.
Найкращий підхід – почати з чіткого розуміння та правильної реалізації платформ ідентифікації, а потім спроєктувати агентів так, щоб вони поміщалися всередину них. Організації повинні повторно використовувати існуючі стандарти та інфраструктуру, а не обходити їх; обрізання цього кута в кінцевому підсумку спричинить проблеми пізніше. Коли ідентифікація закладена з самого початку, вона прискорює розгортання замість того, щоб сповільнювати його.”
Для керівників безпеки та інженерних керівників, які хочуть прийняти агентів штучного інтелекту, але стурбовані управлінням та ризиком, яку пораду ви дали б їм під час планування своєї дорожньої карти?
Затримайтеся досить, щоб зробити основу правильною. Агентів штучного інтелекту потрібно розглядати як ідентифікатори та застосовувати той же контроль, який ви очікуєте для людей, і наполягати на видимості з самого початку. Якщо організація робить це, то масштабування агентів штучного інтелекту стає вправою з безпеки, а не сліпим та ризикованим стрибком віри.”
Дякуємо за велике інтерв’ю, читачам, які хочуть дізнатися більше, повинні відвідати Curity.
