Якоб Ідеског, технічний керівник Curity – Серія інтерв’ю

Якоб Ідеског – спеціаліст з ідентифікації та технічний керівник компанії Curity. Більшу частину свого часу він присвячує роботі над рішеннями безпеки в сфері API та веб-технологій. Він працював над розробкою та впровадженням рішень OAuth та OpenID Connect для великих підприємств та малих стартапів.

Curity – це сучасна платформа управління ідентифікацією та доступом (IAM), побудована навколо сервера ідентифікації Curity, який є стандартним рішенням для забезпечення безпеки автентифікації та авторизації для додатків, API та цифрових сервісів у великих масштабах. Вона підтримує протоколи, такі як OAuth 2.0 та OpenID Connect, для централізації потоків входу, забезпечення детальної політики доступу та видачі безпечних токенів як для людей, так і для клієнтів-машин, включаючи API та сервіси. Платформа розроблена з урахуванням гнучкості та масштабованості, що дозволяє організаціям розгортати її в хмарі, гібридних або локальних середовищах, інтегрувати з існуючими системами та забезпечувати безпечний та безперебійний досвід користувачів без використання саморобної безпеки.

Ви провели більшу частину своєї кар’єри, будуючи системи ідентифікації та безпеки API, від співзаснування Curity до керівництва компанією на посаді технічного директора під час зростання хмарних технологій та现在 штучного інтелекту. Як це вплинуло на вашу думку про те, що агентні штучні інтелекти повинні бути behandelt як першокласні цифрові ідентифікатори, а не просто як ще один шматок програмного забезпечення?

На кожному етапі моєї кар’єри в галузі технологій одна проблема постійно виникає. Чи то хмарні обчислення, чи зараз штучний інтелект, якщо програмне забезпечення діє від імені людини або іншої системи, виникає проблема ідентифікації.

З масовим впровадженням агентних штучних інтелектів ця проблема посилюється. Їх поведінка вже не суворо скриптована, і вони діють з певним рівнем автономності, якого підприємства раніше не бачили. Агентні штучні інтелекти приймають рішення, викликають API та ланцюжки дій у різних системах – часто без прямого нагляду людини. Така поведінка створює проблеми ідентифікації та доступу, які фундаментально відрізняються від традиційного програмного забезпечення.

Відноситися до агентних штучних інтелектів як до першокласних цифрових ідентифікаторів – це єдиний спосіб правильно вирішити цю проблему. Якщо організації вважають їх просто ще одним процесом або сервісним обліковим записом, вони швидко втрачають видимість та контроль – і це рецепт безпеки.

Багато підприємств зацікавлені в агентних штучних інтелектах, але залишаються на етапі експериментів. З чого ви бачите в реальних розгортаннях, які найбільш поширені пробіли в ідентифікації та управлінні, що перешкоджають організаціям масштабувати агентів безпечно?

Більшість експериментів проводиться в ізольованих пісочницях, які ігнорують те, що відбувається у великих масштабах. На ранніх етапах пілотних проектів команди часто надають агентам широкі ключі API, спільні облікові дані або широкі дозволи хмарних сервісів, просто щоб запустити все.

Цей підхід руйнується, коли агенти розгортаються за межами пілотних проектів. Це відбувається тому, що команди з безпеки не можуть побачити, які дані агент отримав, його дії чи чи він перевищив свій передбачуваний обсяг; або випадково, або зловмисно. Ці сліпі плями роблять неможливим безпечне управління агентами, тому багато організацій борються з переходом за межі пілотних проектів.

Ви стверджували, що суворі обмеження необхідні для агентних штучних інтелектів. Як виглядає “хороший” дизайн ідентифікації для агентних штучних інтелектів на практиці, і де компанії зазвичай помиляються?

Хороший дизайн ідентифікації починається з принципу мінімальних привілеїв та дозволів, пов’язаних з явною метою. Кожному агентному штучному інтелекту повинен бути присвоєний свій власний ідентифікатор, вузькі дозволи та чітко визначені довірчі відносини (явні правила для систем, з якими йому дозволено взаємодіяти). Засадnicньо, доступ повинен бути прив’язаний до мети, обмежений у часі та легко скасовуваний.

Компанії помиляються, повторно використовуючи існуючі сервісні облікові записи або припускаючи, що внутрішні агенти безпечні за замовчуванням. Це припущення не витримує реальних загроз. Зловмисні актори активно шукають саме ці слабкі місця, а агентні штучні інтелекти суттєво збільшують потенційний вплив у випадку поганого дизайну ідентифікації.

Curity вже давно працює з відкритими стандартами, такими як OAuth та OpenID Connect. Наскільки критично важливі відкриті стандарти ідентифікації для забезпечення сумісності та безпеки агентних штучних інтелектів у складних корпоративних середовищах?

Відкриті стандарти абсолютно критично важливі. Підприємства вже використовують складні тканини ідентифікації, що охоплюють хмарні платформи, сервіси SaaS та внутрішні API. Агентні штучні інтелекти додають ще більше складності.

Без стандартів кожен агент стає окремою інтеграцією та постійною винятком з безпеки. З відкритими стандартами, такими як OAuth та OpenID Connect, агенти можуть бути автентифіковані, авторизовані та аудитовані так само, як і будь-яка інша робоча нагрузка. Це єдиний підхід, який може забезпечити безпечне масштабування у реальних корпоративних середовищах.

Нелюдські ідентифікатори стають все більш поширеними, від сервісних облікових записів до ідентифікаторів машин. Що робить агентних штучних інтелектів фундаментально різними від попередніх нелюдських ідентифікаторів з точки зору безпеки?

Ключова різниця між сучасними агентними штучними інтелектами та старішими нелюдськими ідентифікаторами (НХІ) полягає в автономності. Традиційний сервісний обліковий запис робить саме те, що йому наказано його кодом, строго обмежений своєю задачею. Агентний штучний інтелект інтерпретує інструкції, адаптує свою поведінку та здійснює дії, які ніколи не були явно прописані – все це збільшує потенційну небезпеку, якщо немає відповідних обмежень.

Маленька помилка в ідентифікації чи доступі може швидко перерости у катастрофу, оскільки агент може діяти з великою швидкістю та у декількох системах. З точки зору безпеки це представляє великий ризик.

Наскільки важливі аудитні сліди та ідентифікаційна реєстрація для управління агентними штучними інтелектами, особливо в регульованих галузях?

Аудитні сліди не повинні бути “бажаними”. Вони повинні бути закладені з самого початку. У регульованих середовищах організаціям очікується, що вони зможуть відповісти на прості, але критичні питання: що зробив цей агент, коли це відбулося, і хто його авторизував?

Ідентифікаційна реєстрація є єдиним надійним способом отримати такий рівень підзвітності. Вона також грає ключову роль у реагуванні на інциденти. Без явного контексту ідентифікації майже неможливо знати, чи проблема виникла через агента, скомпрометовану ідентифікацію чи просто поганий запит.

Які реальні ризики ви бачите, коли організації розгортають агентних штучних інтелектів з надмірними привілеями або погано контролюють їх у виробництві?

Одним із поширених ризиків є безшумна агрегація даних. Агент з надмірними привілеями може витягнути чутливі дані з декількох систем (записи клієнтів, внутрішні документи, журнали) та потім розкрити ці дані через запити, підсумки або зовнішні інтеграції.

Іншим ризиком є агенти з адміністративним доступом, які здійснюють значні зміни з великою швидкістю, завдаючи значно більше шкоди, ніж людина могла б за короткий період часу. Це може включати зміну хмарних ресурсів, відключення засобів безпеки чи активацію автоматизованих робочих процесів без нагляду.

Ці інциденти можуть бути зловмисними, але вони не повинні бути. Агент з надмірними привілеями або погано контрольований може просто діяти на основі застарілих або неправильних припущень, посилюючи помилки у декількох системах, перш ніж хтось це помітить.

Але з точки зору нападника, скомпрометована ідентифікація агента надзвичайно цінна. Вона дозволяє рухатися по боках API та сервісів, часто з рівнем доступу, який жоден користувач не отримав би. Без сильного контролю ідентифікації та моніторингу організації часто виявляють ці збої лише після реальної шкоди.

Для компаній, які переходять від пілотних проектів до реальних розгортань агентних штучних інтелектів, які рішення щодо ідентифікації та доступу повинні бути прийняті на ранньому етапі, щоб уникнути дорогих переробок пізніше?

Організаціям слід визначити на ранньому етапі, як агентам видаються ідентифікатори, як затверджуються дозволи та як доступ переглядається з часом, визначаючи межі ідентифікації заздалегідь.

Введення контролю ідентифікації ретроспективно майже завжди проблематично. Агенти часто глибоко вплетені у робочі процеси, використовуючи спільні облікові дані або широкі ролі, тому обмеження доступу після факту порушує припущення, на яких системі довіряється. Це в кінцевому підсумку призводить до того, що робочі процеси припиняються, а довіра до технології підкріплюється. Натомість значно дешевше та безпечніше проектувати правильні ідентифікатори, області та межі доступу з самого початку.

Де інтеграція ідентифікації найчастіше стає瓶нем при розгортанні агентних штучних інтелектів, і які найкращі практики допомагають зменшити тертя?

Управління ідентифікацією може стати瓶нем, але тільки тоді, коли його розглядають як післяthought. Команди зосереджуються на побудові вражаючих можливостей агентів спочатку, а потім пізніше усвідомлюють, що їм потрібно інтегрувати їх з системами IAM, брамами API та платформами реєстрації, щоб вони були真正 безпечними.

Найкращий підхід полягає в тому, щоб почати з чіткого розуміння та правильної реалізації платформ ідентифікації, а потім проектувати агентів так, щоб вони поміщалися в них. Організації повинні повторно використовувати існуючі стандарти та інфраструктуру, а не обходити їх; обрізка цього кута в кінцевому підсумку призведе до проблем пізніше. Коли ідентифікація закладена з самого початку, вона прискорює розгортання, а не сповільнює його.

Для керівників з безпеки та інженерних керівників, які хочуть прийняти агентних штучних інтелектів, але стурбовані управлінням та ризиками, яку пораду ви дали б їм при плануванні їхньої дорожньої карти?

Затримайтеся досить, щоб закладені основи правильно. Агентним штучним інтелектам слід ставитися як ідентифікаторам, і вам потрібно застосовувати той же контроль, який ви очікуєте від людей, і наполягати на видимості з самого початку. Якщо організація робить це, то масштабування агентних штучних інтелектів стає завданням безпеки, а не сліпим та ризикованим стрибком віри.

Дякую за велике інтерв’ю, читачам, які бажають дізнатися більше, слід відвідати Curity.