Джейкоб Идеског, технический директор Curity – серия интервью

Якоб Идеског Он является специалистом по идентификации и техническим директором в компании Curity. Большую часть времени он посвящает работе с решениями в области безопасности API и веб-технологий. Он занимался проектированием и внедрением решений OAuth и OpenID Connect как для крупных корпоративных развертываний, так и для небольших стартапов.

любопытство Это современная платформа управления идентификацией и доступом (IAM), построенная на базе Curity Identity Server — стандартизированного решения, предназначенного для обеспечения безопасной аутентификации и авторизации приложений, API и цифровых сервисов в масштабе предприятия. Она поддерживает такие протоколы, как OAuth 2.0 и OpenID Connect, для централизации процессов входа в систему, обеспечения детальной политики доступа и выдачи защищенных токенов как для пользователей, так и для машинных клиентов, включая API и сервисы. Платформа разработана с учетом гибкости и масштабируемости, позволяя организациям развертывать ее в облачных, гибридных или локальных средах, интегрироваться с существующими системами и обеспечивать безопасный и бесперебойный пользовательский опыт без необходимости использования собственной инфраструктуры безопасности.

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

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

С массовым внедрением агентного ИИ эта проблема усугубляется. Их поведение больше не регламентируется строго по сценарию, и они работают с уровнем автономности, невиданным ранее предприятиями. Агенты ИИ принимают решения, вызывают API и объединяют действия в рамках различных систем — часто без прямого контроля со стороны человека. Такое поведение создает проблемы идентификации и доступа, которые принципиально отличаются от проблем, возникающих при использовании традиционного программного обеспечения.

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

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

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

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

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

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

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

Компания Curity давно работает со стандартами, такими как OAuth и OpenID Connect. Насколько важны открытые стандарты идентификации для обеспечения совместимости и безопасности агентного ИИ в сложных корпоративных средах?

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

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

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

Ключевое отличие современных агентов ИИ от более старых нечеловеческих идентификаторов (НЧИ) заключается в автономности. Традиционная служебная учетная запись делает именно то, что ей предписывает код, строго придерживаясь своей задачи. Агент ИИ интерпретирует инструкции, адаптирует свое поведение и выполняет действия, которые никогда не были явно запрограммированы, — все это увеличивает потенциальную опасность, если нет соответствующих механизмов защиты.

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

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

Журналы аудита не должны быть просто «желательной» функцией. Их необходимо внедрять с самого начала. В регулируемых средах от организаций ожидается ответ на простые, но критически важные вопросы: к чему получил доступ этот агент, когда это произошло и кто дал на это разрешение?

Журналирование на основе идентификационных данных — единственный надежный способ обеспечить такой уровень подотчетности. Оно также играет ключевую роль в реагировании на инциденты. Без четкого контекста идентификации практически невозможно определить, возникла ли проблема из-за некорректной работы агента, компрометации идентификационных данных или просто неправильного запроса.

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

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

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

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

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

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

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

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

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

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

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

Какой совет вы бы дали руководителям в области безопасности и разработки, которые хотят внедрить агентный ИИ, но обеспокоены вопросами управления и рисками при планировании своей стратегии?

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

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