Рафаэль Энджел, сооснователь и технический директор Akeyless – Интервью

Рафаэль Энджел, сооснователь и технический директор Akeyless, является лидером в области кибербезопасности и программной инженерии с обширным опытом в области облачной безопасности, шифрования, аутентификации машин и инфраструктуры предприятий. С момента основания Akeyless в 2018 году он помог построить компанию вокруг современного управления секретами и безопасности идентификации для облачных сред. До Akeyless он работал в качестве старшего инженера-программиста по безопасности в Intuit, где он разрабатывал системы для управления ключами шифрования в публичном облаке и аутентификации машин, получая практический опыт работы с AWS, Go, Python, Java, PHP, Bash, Linux, Git и Jenkins. Ранее в своей карьере Энджел занимал должности программного инженера в 3D Systems и Cimatron, разрабатывая приложения CAD/CAM и Windows с использованием C/C++, C#, WPF, MFC и объектно-ориентированных шаблонов проектирования.

Akeyless – это компания, специализирующаяся на безопасности идентификации, которая фокусируется на защите машин, агентов ИИ и людей посредством облачной платформы, построенной на основе криптографии с нулевым знанием. Ее платформа объединяет управление секретами, управление ключами шифрования, управление жизненным циклом сертификатов, привилегированный доступ и безопасность идентификации машин, предоставляя организациям унифицированный способ управления учетными данными, ключами, сертификатами и доступом в гибридных, многооблачных, DevOps и средах ИИ. Позиционирование компании отражает более широкий сдвиг в области кибербезопасности: по мере того, как рабочие нагрузки, сервисы и агенты ИИ все чаще выполняют доступ к системам без прямого участия человека, предприятиям необходимы более сильные контроли вокруг нечеловеческих идентификаций, кратковременных учетных данных, автоматического вращения и управления в режиме реального времени.

Вы стали сооснователем Akeyless в 2018 году после разработки систем управления ключами шифрования и аутентификации машин в Intuit. Какой пробел в облачной безопасности и управлении идентификацией убедил вас в необходимости создания Akeyless, и как ваше первоначальное видение эволюционировало с появлением агентов ИИ как нового класса цифровых идентификаций?

В Intuit я был частью команды, которая разрабатывала системы управления ключами шифрования и аутентификации машин в то время, когда Intuit была одной из первых крупных предприятий, перешедших в облако. Что стало для меня очевидным, было то, что каждая организация, принимающая облако, в конечном итоге столкнется с той же проблемой, которую мы решали внутри: как управлять секретами и ключами в распределенной, динамической инфраструктуре. Построение этого внутри потребует огромных инженерных ресурсов, и это не имеет смысла для каждой компании заново изобретать. Логичным ответом было модель SaaS.

Но была одна проблема – доверие. Это наиболее чувствительная информация, которой владеет предприятие, и ни одна серьезная организация не передаст третьей стороне возможность доступа к ней. Таким образом, требование было почти противоречивым: предоставить ее в виде SaaS для масштабируемости и простоты, но сделать ее архитектурно невозможной для поставщика увидеть данные клиента. Это напряжение является именно тем, что привело к появлению криптографии распределенных фрагментов (DFC). DFC позволяет нам запускать полностью управляемую контрольную плоскость SaaS, в то время как клиент держит фрагмент, который мы никогда не обладаем, поэтому мы математически не можем получить доступ к их ключам. Это стало основой модели SaaS плюс нулевое знание, на которой построен Akeyless.

Первоначальное видение было связано с безопасностью доступа человека и машины в облаке. Агенты ИИ – это естественное и наиболее крайнее расширение той же проблемы. Они являются нечеловеческими идентификациями, действующими в масштабе и скорости, для которых не был предназначен никакой каталог, и та же основа нулевого знания и идентификации теперь распространяется直接 на них.

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

Самой сложной частью было сделать “доверяй никому” практичным, а не академическим. Большинство схем разделения ключей или обмена секретами по-прежнему собирают полный ключ в какой-то момент, обычно внутри одного процесса, модуля безопасности или анклава в момент криптографической операции. Это кратковременное окно является именно тем, на что нацеливаются атакующие, злонамеренные внутренние лица и сценарии юридического принуждения.

С DFC ключ никогда не собирается, не при создании, не в состоянии покоя и не во время использования. Фрагменты генерируются независимо в отдельных доменах доверия, и криптографические операции выполняются как распределенный вычислитель, где каждый держатель фрагмента вычисляет свою долю локально, и обмениваются только частичными результатами. Инженерная задача заключалась в достижении этого с задержкой, пропускной способностью и надежностью, которые требуют крупные предприятия в производстве.

Вторая задача, и одна из наиболее значительных, заключалась в обеспечении непрерывного обновления фрагментов. Нам необходимо было иметь возможность заменить каждый фрагмент на новое математическое значение, в каждом месте, при этом мастер-ключ, представленный фрагментами, оставался неизменным, и криптографический процесс никогда не прерывался. Это добавило очень существенный слой безопасности к решению. Поскольку фрагмент, захваченный на прошлой неделе, математически не связан с фрагментами, которые существуют сегодня, он является шумом, а не началом. Чтобы узнать что-либо о ключе, злоумышленнику пришлось бы скомпрометировать каждый фрагмент одновременно, в течение одного окна обновления, и это требование становится экспоненциально более сложным по мере увеличения мест, доменов доверия и частоты обновления. В сочетании с порогом “все или ничего”, где 100 процентов фрагментов необходимы для раскрытия любой информации, а любая строгая подмножество не передает никакой информации, обновление преобразует модель безопасности из статического гарантии в ограниченную во времени.

Многие организации спешат развертывать агентов ИИ, но безопасность идентификации часто остается второстепенной. Какие наиболее распространенные ошибки совершают компании, когда предоставляют агентам ИИ доступ к системам и чувствительным данным предприятий?

Самой большой ошибкой является то, что агент behandelt как учетная запись сервиса и передает ему статический, долгосрочный ключ API. Этот учетный данный становится постоянным, собираемым активом, сидящим внутри неопределенного, инъектируемого промптом актора.

Другие общие ошибки, которые я вижу: предоставление постоянных привилегий вместо доступа только в режиме реального времени, полагание на грубые ролевые разрешения, которые описывают, что может достичь агент, но никогда не то, что он намерен сделать, предоставление агентам прямых сетевых путей к базам данных и API, так что компрометация становится боковым движением, и не имея цепочки аудита, которая связывает действие агента с человеческим промптом и запуском. Каждый из этих является попыткой переделать контроли эпохи человека на что-то, что не ведет себя как человек.

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

Основной ошибкой является то, что агенты ИИ рассматриваются как новый вид пользователя или даже новый вид учетной записи сервиса, и предполагается, что они могут быть интегрированы и управляемы как идентификации человека. Это категориальная ошибка, по нескольким связанным причинам.

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

Правильная якорь – это не агент, а идентификация рабочей нагрузки, которую ее runtime уже выдает, роль выполнения AWS, токен учетной записи сервиса Kubernetes, федерация OIDC и стандарты, такие как SPIFFE/SPIRE, которые уже доказали себя в производстве и являются кросс-субстратными. Идентификация уже существует, засвидетельствована платформой, на которой работает агент, и исчезает, когда агент исчезает. Поскольку идентификации являются эфемерными, единственными стабильными сущностями, между которыми можно написать политику, являются методы аутентификации и целевые системы, а не именованные идентификации и области.

И это то место, где существующие IAM и PAM ломаются наиболее решительно: статические RBAC и ABAC не могут содержать неопределенного актора. Агент с идеально ограниченным токеном и идеально обеспеченным TTL может все равно быть инъектируемым промптом, заявлять о разрушительном запросе или менять направление от задачи чтения к задаче записи в одной и той же сессии, без видимого нарушения политики на уровне аутентификации. RBAC и ABAC оцениваются на уровне аутентификации, а не после, потому что то, что происходит после, решается LLM, который смотрит на контекстное окно, которое автор политики не может увидеть.

Итак, агенты являются уникально трудными, потому что они являются эфемерными, неопределенными, многосубстратными и инъектируемыми промптом одновременно. Отсутствующий слой – это не лучший каталог. Это осведомленная о намерении реализация на каждом действии, посредством шлюза, который проверяет, что агент фактически делает, против того, что он сказал, что он сделает, прежде чем какая-либо учетная запись будет создана. Этот слой необходим.

Существует растущее обсуждение вокруг “безсекретных” архитектур для систем ИИ. Как вы определяете аутентификацию без секретов, и почему вы считаете, что статические учетные данные и ключи API становятся непригодными для использования в эпоху автономных агентов?

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

Статические учетные данные и ключи API становятся непригодными для использования по простой причине: секрет, который держит агент, является секретом, который может украсть злоумышленник. В мире, где актор, держащий учетные данные, может быть инъектируемым промптом или заявлять о разрушительном запросе, долгосрочный ключ становится утечкой ключа. Удаление учетных данных из агента и скомпрометированный агент не имеют ничего, чтобы утечь. Это является целью того, что мы называем SecretlessAI.

По мере того, как агенты ИИ получают возможность планировать, выполнять действия и взаимодействовать с несколькими системами самостоятельно, какие новые векторы атак вас больше всего беспокоят в течение следующих трех-пяти лет?

Векторы, которые меня больше всего беспокоят, все исходят из способности агентов планировать и действовать самостоятельно. Инъекция промпта, которая захватывает намерение агента в середине задачи, является наиболее очевидной, потому что идентификация остается действительной, даже если поведение становится злонамеренным. За пределами этого я беспокоюсь об агент-агентских передачах, где передается власть, без явной ответственности, боковом движении через агентов, которые имеют прямую сетевую доступность, и о выгрузке данных, где агент с чрезмерными полномочиями извлекает намного больше, чем это необходимо для его задачи.

Общая нить заключается в том, что учетная запись и роль могут быть идеально легитимными, в то время как действие не является таковым. Защиты, которые проверяют только разрешение, а не цель, не поймают ни один из этих векторов. Это именно почему осведомленная о намерении реализация на каждом действии, на шлюзе, является контролем, который, по моему мнению, будет иметь наибольшее значение.

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

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

Сдвиг приоритетов происходит от периодических, человеческих контролей к непрерывным, режим-реального-времени контролям в масштабе машин. Когда вы управляете миллионами нечеловеческих идентификаций, вы не можете полагаться на периодическую регистрацию, кампании сертификации и квартальные обзоры доступа. Вам необходима эфемерная идентификация, нулевые постоянные привилегии и политика, оцениваемая автоматически на каждом действии. Безопасность человеческих идентификаций не исчезает, но она становится меньшей частью поверхности, и архитектура должна быть построена для нечеловеческого большинства сначала.

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

Прежде чем любой агент будет работать автономно в производстве, я бы хотел иметь несколько вещей. Во-первых, никаких постоянных учетных данных на агенте, с только-в-режиме-реального-времени доступом, введенным для каждой сессии. Во-вторых, никаких прямых сетевых путей, так что каждое действие агента посредничествует через обязательную точку контроля, а не достигает баз данных и API напрямую. В-третьих, осведомленная о намерении политика реализации, которая оценивает цель запроса против его исходного промпта, прежде чем какая-либо учетная запись будет создана, так что агент, запрошенный для анализа дохода, не может выпустить разрушительную команду. В-четвертых, в-сессии инспекция и маскировка ответа, так что чувствительные данные, такие как PII и PHI, удаляются из контекстного окна агента. И, в-пятых, единственная неизменная запись аудита, связывающая человеческий промпт, классифицированное намерение, политическое решение, сессию и окончательное действие.

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

Отрасль часто фокусируется на безопасности модели, но меньше внимания уделяется идентификации, авторизации и контролю доступа. Почему вы считаете, что эти области станут одними из наиболее важных проблем безопасности в эпоху ИИ?

Безопасность модели получает заголовки, но идеально согласованная модель все равно должна действовать в реальном мире, и в момент, когда она действует, ей необходим доступ к системам и данным. Этот доступ – это место, где происходит реальный ущерб. Модель, которая никогда не трогает базу данных, не может ее экспортировать.

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

Оглядываясь вперед, считаете ли вы, что предприятия в конечном итоге потребуют специального слоя идентификации для агентов ИИ, аналогично тому, как поставщики идентификации стали необходимыми для человеческих пользователей, и как будет выглядеть эта будущая архитектура?

Да, но она не будет выглядеть как модель поставщика идентификации человека, просто ребрендинговая для агентов. Попытка построить каталог агентов – это построение каталога для призраков, идентификаций, которые исчезают, прежде чем вы закончите их регистрацию.

Слой идентификации агента, который я ожидаю, будет привязан к идентификации рабочей нагрузки, которую ее runtime уже выдает, облачной IAM, токену учетной записи сервиса Kubernetes, федерации OIDC и стандартам, таким как SPIFFE/SPIRE, которые уже доказали себя в производстве и являются кросс-субстратными. Авторизация будет выражена как отношения между методами аутентификации и целевыми системами, а не между именованными идентификациями и областями. И центр тяжести будет на плоскости реализации в режиме реального времени, шлюзе, который посредничает каждое действие, классифицирует намерение, вводит эфемерные учетные данные, маскирует чувствительные ответы и производит полную цепочку аудита. Идентификация все еще имеет значение, но она занимает место за реализацией, а не перед ней. Этот слой управления в режиме реального времени, сидящий на той же платформе, которая уже управляет человеческим и машинным доступом, является тем, что, по моему мнению, каждое предприятие, запускающее агентов в производстве, в конечном итоге будет нуждаться.

Спасибо за отличное интервью, читатели, которые хотят узнать больше, должны посетить Akeyless.