Рефаель Анджел, співзасновник і технічний директор Akeyless – Інтерв’ю

Рефаель Анджел, співзасновник і технічний директор Akeyless, є лідером у сфері кібербезпеки та програмної інженерії з великим досвідом у сфері безпеки хмарних технологій, шифрування, автентифікації машин та інфраструктури підприємств. З моменту заснування Akeyless у 2018 році він допоміг створити компанію навколо сучасного управління секретами та безпеки ідентифікації для хмарних середовищ. До Akeyless він працював старшим інженером з безпеки в Intuit (INTU ), де створив системи для управління шифруванням публічних хмар та автентифікації машин, здобувши практичний досвід у сфері AWS, Go, Python, Java, PHP, Bash, Linux, Git та Jenkins. Раніше в своїй кар’єрі Анджел обіймав посади програмної інженерії в 3D Systems (DDD ) та Cimatron, розробляючи програми CAD/CAM та Windows за допомогою C/C++, C#, WPF, MFC та об’єктно-орієнтованих моделей проектування.

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

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

У Intuit я був частиною команди, яка створювала системи управління шифруванням та автентифікацією машин у той час, коли Intuit була однією з перших великих підприємств, які перейшли на хмарні технології. Що стало зрозумілим для мене, було те, що кожна організація, яка приймає хмарні технології, врешті-решт зіткнеться з тією ж проблемою, яку ми вирішували внутрішньо: як керувати секретами та ключами у розподілених, динамічних інфраструктурах. Будування цього всередині підприємства потребує величезних інженерних ресурсів, і це не має сенсу для кожної компанії винаходити це знову. Логічний відповідь був модель SaaS.

Проблема полягала у довірі. Це найчутливіша інформація, яку володіє підприємство, і жодна серйозна організація не передасть третій стороні можливість доступу до неї. Тому вимога була майже протирічною: надати це як SaaS для масштабу та простоти, але зробити архітектурно неможливим для постачальника побачити дані клієнта. Це напруження саме і стало тим, що привело до появи Distributed Fragments Cryptography (DFC). DFC дозволяє нам керувати повністю керованим планом контролю SaaS, тоді як клієнт володіє фрагментом, який ми ніколи не володіємо, тому ми математично не можемо доступитися до їхніх ключів. Це стало основою моделі SaaS плюс нульове знання, на якій побудований Akeyless.

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

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

Найбільшою проблемою було зробити “довіряй нікому” практичним, а не академічним. Більшість схем розподілу ключів або спільного використання секретів все ще збирають повний ключ в якийсь момент, зазвичай всередині одного процесу, апарату HSM або анклаву в момент криптографічної операції. Ця коротка віконка саме і є тим, на що націлюються атакувальники, зловмисні внутрішні особи та юридично-обов’язкові сценарії.

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

Другою проблемою, і однією з найбільш значимих, було забезпечення безперервного оновлення фрагментів. Нам потрібно було能够 заміняти кожен фрагмент на нове математичне значення, у кожному місці, під час того, як основний ключ, який представляють фрагменти, залишається незмінним, і криптографічний процес ніколи не переривається. Це додало дуже суттєвий шар безпеки до рішення. Через оновлення атакувальник вже не може зібрати фрагменти терпляче протягом часу. Фрагмент, захоплений на минулому тижні, математично не пов’язаний з фрагментами, які існують сьогодні, тому це шум, а не крок вперед. Щоб дізнатися щось про ключ, нападнику потрібно буде скомпрометувати кожне місце фрагмента одночасно, протягом одного вікна оновлення, і ця вимога зростає експоненційно важче з місцями, довірчими областями та частотою оновлення. У поєднанні з порогом все-або-нічого, де 100 відсотків фрагментів потрібні для розкриття чогось, і будь-яка строга підмножина не витікає жодної інформації, оновлення перетворює модель безпеки з статичної гарантії у часо-зв’язану.

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

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

Інші поширені помилки, які я бачу: надання постійного доступу замість доступу just-in-time, використання грубих ролевих дозволів, які описують, до чого агент може дістатися, але ніколи не описують, що він намірений зробити, надання агентам прямого мережевого доступу до баз даних та API, так що компрометація стає латеральним рухом, і відсутність ланцюга аудиту, який пов’язує дію агента з людиною та підказкою, яка спровокувала його. Кожна з цих помилок є спробою адаптувати людські контролю до чогось, що не поводиться як людина.

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

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

Ідентифікатори агентів не перерахованими. Конкретна інстанс, яку ви хочете керувати, зазвичай не існує ще, і до того часу, як вона з’являється, вона вже зникла. Агент може запуститися на Lambda, виконати роботу протягом 800 мілісекунд і зникнути, перш ніж будь-який сканер помітить його, або породити ланцюжки субагентів по VM, контейнерах та серверних середовищах, які завершуються за секунди. Реєстрація цих ідентифікаторів у каталозі є тим, як поводитися з привидами як з мешканцями: до того часу, як запис буде зафіксований, сутність, яку він описував, зникла.

Правильна прив’язка тому не агент, а ідентифікатор робочого процесу, який вже видається його середовищем виконання, роль виконання AWS, токен сервісної облікового запису Kubernetes, токен OIDC федерації та стандарти, такі як SPIFFE/SPIRE, які вже довели свою придатність у виробництві та працюють у різних субстратах. Авторизація буде виражена як відносини між методами автентифікації та цільовими системами, а не між названими ідентифікаторами та областями. І центром тяжіння буде плановий рівень виконання, шлюз, який брокерує кожну дію, класифікує намір, ін’єктує ефемерні облікові дані, маскує чутливу відповідь та створює повний ланцюжок аудиту. Ідентифікатор усе ще важливий, але він займає місце позаду виконання, а не перед ним. Це плановий рівень виконання, який знаходиться на тій же платформі, що вже керує людським та машинним доступом, і це те, що, на мою думку, кожне підприємство, яке запускає агентів у виробництві, врешті-решт буде потребувати.

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

Автентифікація без секретів означає, що агент ніколи не володіє обліковим записом. Замість того, щоб надати агенту ключ, який він повинен зберігати та представляти, агент автентифікується через свій рідний ідентифікатор робочого процесу, і короткочасний, just-in-time обліковий запис ін’єктується у брокерську сесію в момент виконання, а потім знищується, коли сесія закінчується. Агент ніколи не бачить його.

Статичні облікові дані та API-ключі стають нестійкими з простої причини: секрет, який володіє агент, є секретом, який може бути викрадений атакувальником. У світі, де актор, який володіє обліковим записом, може бути ін’єктом або галюцинацією, довгостроковий ключ стає постійним, збираємим активом, який знаходиться всередині недетермінованого, ін’єкційного актора. Видалення облікового запису з агента означає, що скомпрометований агент нічого не витікає. Це саме є суть того, що ми називаємо SecretlessAI.

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

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

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

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

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

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

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

Перед тим, як будь-який агент буде працювати автономно у виробництві, я хотів би мати кілька речей на місці. По-перше, жодних постійних облікових даних на агенті, з just-in-time, короткочасним доступом, ін’єктом у брокерську сесію під час виконання, а потім знищеним, коли сесія закінчується. По-друге, жодного прямого мережевого шляху, так що кожна дія агента брокерується через обов’язковий пункт контролю, а не досягає баз даних та API напряму. По-третє, освідомлене виконання політики, яке оцінює мету запиту проти його походження підказки перед тим, як будь-який обліковий запис буде створений, так що агент, який запитаний про аналіз доходів, не може видати руйнівну команду. По-четверте, інспекція у сесії та маскування чутливої відповіді, так що конфіденційна інформація, така як особисті дані та дані про здоров’я, редагується перед тим, як вона потрапляє у вікно контексту агента. І, нарешті, єдина незмінна запис аудиту, яка пов’язує людську підказку, класифікований намір, політичну оцінку, сесію та кінцеву дію.

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

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

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

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

Шар ідентифікації агентів, який я очікую, буде прив’язаний до ідентифікатора робочого процесу, який видається його середовищем виконання, роль виконання AWS, токен сервісної облікової запису Kubernetes, токен OIDC федерації та стандарти, такі як SPIFFE/SPIRE, які вже довели свою придатність у виробництві та працюють у різних субстратах. Авторизація буде виражена як відносини між методами автентифікації та цільовими системами, а не між названими ідентифікаторами та областями. І центром тяжіння буде плановий рівень виконання, шлюз, який брокерує кожну дію, класифікує намір, ін’єктує ефемерні облікові дані, маскує чутливу відповідь та створює повний ланцюжок аудиту. Ідентифікатор усе ще важливий, але він займає місце позаду виконання, а не перед ним. Це плановий рівень виконання, який знаходиться на тій же платформі, що вже керує людським та машинним доступом, і це те, що, на мою думку, кожне підприємство, яке запускає агентів у виробництві, врешті-решт буде потребувати. Дякую за велике інтерв’ю, читачам, які бажають дізнатися більше, слід відвідати Akeyless.