Облачные архитектуры, созданные для отражения атак человека, сталкиваются с новой угрозой: ИИ-агенты, переписывающие правила скорости и масштаба атак.
Недавний инцидент с OpenAI и Hugging Face — ранний пример того, как может выглядеть автономная атака ИИ: агент использует несколько уязвимостей для расширения доступа и перемещения по среде.
Многие организации заявляют о неуверенности в защите своих облачных сред: согласно Глобальному отчету NTT DATA по ИИ за 2026 год, лишь 38% респондентов высоко оценивают свою облачную безопасность.
Если раньше облачная архитектура была хрупкой, то с появлением агентов последствия наступают быстрее и в большем масштабе. Задача директоров по информационной безопасности (CISO) — защититься от агентов-противников, которые могут объединять уязвимости и выполнять атаки на машинной скорости.
Как агенты меняют модель облачных угроз
Атакующие на базе ИИ способны находить и использовать уязвимости облачной безопасности со скоростью и в масштабах, недоступных человеку.
«Что отличает агентов от атакующих-людей — это скорость и полнота охвата», — говорит Омаир Манзур, основатель и генеральный директор ioSENTRIX.
Тестирование показывает, как может развиваться атака: агент или злоумышленник получает идентификатор с низкими привилегиями, перечисляет политики управления идентификацией и доступом (IAM), выявляет излишне разрешительные роли и объединяет две-три неправильные конфигурации для доступа к критическим активам.
Удивительно, как быстро агент может проверить доступные пути.
«Если человек-тестировщик за день оценивает 50 путей повышения привилегий, то автономный агент может оценить тысячи за несколько минут, проверяя каждую комбинацию назначения роли, границ политик и доверительных отношений между учетными записями», — отмечает Манзур.
Облачная сложность расширяет поверхность атаки
Скорость имеет значение, потому что облачные среды стали сложными: множество идентификаторов, разрешений, API, рабочих нагрузок и доверительных связей. Эта сложность мешает защитникам понимать, как отдельные слабые места соединяются, и дает агентам больше связей для картографирования и тестирования.
По мере распространения агентов сетевые границы значат гораздо меньше, чем то, кто (или что) может получить доступ к вашему облаку, говорит Алисса Найт, основатель и генеральный директор Assail. «Периметр теперь — это граф идентификаторов, а не виртуальное частное облако», — утверждает Найт, у которой более 20 лет опыта в наступательной безопасности.
Одной аутентификации недостаточно для защиты от широкого проникновения. Найт видела приложения, созданные с помощью агентного ИИ, где пользователь мог аутентифицироваться с помощью MFA-кода без ввода имени пользователя, а код можно было многократно угадывать из-за отсутствия ограничения на число попыток.
Это подчеркивает важность авторизации, а не просто аутентификации. Подтверждение доступа к системе не обязательно означает, что идентификатор надлежащим образом ограничен после входа. Риск, по ее словам, в том, что организации могут подтвердить аутентификацию пользователя, но не контролировать должным образом, что ему разрешено делать внутри.
Чрезмерные разрешения и взаимосвязанные неправильные конфигурации — самые распространенные слабые места, которые Манзур находит при оценке облачных сред.
«Организации управляют разрешениями изолированно: у этой роли такие политики, у этого сервисного аккаунта — такой доступ. Но пути атаки в облаке — это не отдельные ошибки конфигурации. Это цепочки», — говорит он.
Он приводит пример S3-корзины с излишне широким доступом — отдельно это незначительная находка, но в сочетании с Lambda-функцией, у которой есть роль IAM, способная назначать административную роль другой учетной записи, это становится критическим путем к полной компрометации среды.
«Агентные системы автоматически выстроят эти цепочки. Большинство организаций сегодня не видят их даже при ручном анализе», — отмечает он.
Отдельные слабые места могут соединяться таким образом, что создают уязвимости, незаметные по отдельности. Данные Assail показали, что общие роли узлов и плоское доверие между учетными записями наносят больший ущерб, чем любая отдельная CVE в среде.
Когда ИИ может обнаруживать и соединять уязвимости со скоростью, недоступной командам безопасности, «вы имеете дело уже не с человеком-противником, — говорит Найт. — Вы имеете дело с противником, который использует ИИ против вас».
«Если нас взламывают с помощью ИИ, мы должны взламывать себя сами», — добавляет она, утверждая, что организациям необходимо использовать ИИ для выявления и тестирования тех путей атаки, которые может использовать противник на базе ИИ.
Адаптация операций облачной безопасности
Операции облачной безопасности должны перейти от выявления отдельных уязвимостей к непрерывной проверке того, остаются ли пути атаки эксплуатируемыми.
По мере того как агенты становятся новой внутренней угрозой, задача CISO — смотреть за пределы изолированных уязвимостей и понимать, как разрешения и неправильные конфигурации могут взаимосвязываться, образуя пути атаки, говорится в отчете CSA «Состояние облачной безопасности и безопасности ИИ».
Манзур видит устойчивый разрыв между обнаружением и архитектурной реальностью. «Организации развертывают инструменты CSPM, которые генерируют тысячи находок, но эти находки оцениваются по отдельности, а не как взаимосвязанные пути атаки», — говорит он.
«Агенту безразличны ваши отдельные находки. Ему важно, какая комбинация находок создает жизнеспособный путь к вашим данным. Подход к защите должен соответствовать этому — анализ экспозиции на основе графов, который картирует пути атаки в реальном времени, а не плоские списки неправильных конфигураций», — отмечает он.
Он называет три архитектурных принципа, которые организациям необходимо внедрить для подготовки к агентным угрозам:
- Используйте эфемерные учетные данные повсеместно. «Никакого постоянного доступа, никаких долгоживущих ключей — каждое разрешение выдается точно вовремя и автоматически истекает».
- Обеспечьте федеративную идентификацию рабочих нагрузок. «Аутентификация между сервисами, полностью исключающая общие секреты».
- Внедрите сегментацию на уровне учетных записей. Сдерживание радиуса взрыва требует сегментации на уровне учетных записей, а не только сетевой сегментации внутри одной учетной записи. «Необходимы жесткие границы между рабочими нагрузками, чтобы скомпрометированный агент в одном контексте не мог перейти в другой».
Найт согласна, что оценка серьезности угроз предполагает атакующего-человека с ограниченным терпением.
«Агент не сортирует по серьезности — он компонует», — говорит она.
Например, в собственной среде Ares компания Assail объединила раскрытие службы метаданных с ролью узла, а затем с учетной записью — три находки, каждая из которых по отдельности оценивалась как низкая или средняя.
Сканирование состояния на определенный момент времени рассчитано на темп атакующего-человека. Однако, когда агенты сжимают время атаки до минут, среднее время устранения может стать менее важным. Вместо этого сканирование состояния должно определять, достижим ли путь атаки.
«Это требует непрерывной проверки на противодействие, а не ежеквартального отчета», — говорит она.
Потребуются также изменения в учетных данных на основе идентификатора. Краткосрочные идентификаторы рабочих нагрузок могут убрать долгоживущие учетные данные с поверхности атаки, но это лишь часть проблемы.
Найт отмечает, что замена статического ключа на 15-минутный токен все равно несет ту же чрезмерно широкую политику и лишь сокращает окно. Радиус взрыва не меняется.
«Сокращение области действия — это контроль; ротация — гигиена», — резюмирует она.
Контрольный список для переосмысления облачной безопасности
В целом CISO необходимо изменить стратегический подход: от оценки уязвимостей к вопросу, могут ли агенты создавать пути атаки в их облачных системах и как быстро. Непрерывная проверка путей атаки, строго определенные средства управления идентификацией и авторизацией, а также развертывание наступательных агентов помогут защититься от атак во главе с агентами.
Учитывая это, вот четыре сдвига в облачной безопасности, которые стоит инициировать CISO:
- От управления уязвимостями к управлению путями атаки. Поймите, как соединяются идентификаторы, разрешения и неправильные конфигурации.
- От периметральной безопасности к архитектуре идентификаторов. Уделите приоритетное внимание машинным идентификаторам, делегированным разрешениям и повышению привилегий.
- От периодических проверок к непрерывной валидации. Управление облачной экспозицией становится непрерывным вместо запланированных проверок.
- От облачной сложности к облачной простоте. Архитектурная простота становится преимуществом безопасности, поскольку ИИ эксплуатирует сложность.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Rosalyn Page
