ИИ-агенты переписывают правила безопасности. Успеет ли за ними ваш уровень данных?
При поддержке Google Cloud
Злоумышленники используют автономных агентов, чтобы находить уязвимости и проводить атаки при минимальном участии человека. Это означает, что время от обнаружения уязвимости до её эксплуатации теперь слишком мало, чтобы традиционные методы — сигнатурное обнаружение и установка исправлений — справлялись в одиночку. Командам безопасности нужно выявлять аномальное поведение с машинной скоростью.
Эти изменения делают уровень данных важнее, чем когда-либо. Командам безопасности необходимо принимать огромные объёмы данных об активности, включая действия внутренних агентов, и в реальном времени связывать их с корпоративным контекстом. Большинство архитектур данных не создавались для такой работы.
Новый тип данных безопасности
Сегодня анализ угроз должен глубже вникать в то, что на самом деле делают приложения и агенты. Агентные системы добавляют новые данные, требующие мониторинга, — например, действия и траектории самих агентов. Поскольку агенты работают с машинной скоростью, объём этих данных растёт быстрее, чем всё, с чем командам безопасности приходилось иметь дело прежде.
Каждое действие агента порождает запись в журнале или трассировку, но простое агрегирование журналов само по себе мало что скажет. Командам безопасности нужно привязывать эти записи к траектории каждого агента, чтобы восстановить последовательность событий и понять, что произошло и какие системы были затронуты.
В результате профиль нагрузки при анализе угроз становится похож на наблюдаемость (observability): журналы колоссального масштаба, непрерывный приём данных, потоковая обработка и сортировка. Журналы, трассировки и метрики, которые команды SRE используют для поддержания работы сервисов, могут также выявлять признаки компрометации или злого умысла.
Ключевые требования к уровню данных безопасности
Оценка рисков требует привязки сырой телеметрии к бизнес-контексту. Аномалия в тестовой среде менее срочна, чем та, что затрагивает производственную базу данных, и командам безопасности нужно уметь проводить это различие практически в реальном времени.
Для таких решений необходим доступ ко всем данным, где бы они ни находились, и получение этого доступа не должно зависеть от длительного проекта миграции. Это одна из причин, по которой появляется концепция «лейкхауса без границ», дающая командам безопасности и агентам прямой доступ к данным в нескольких облаках, базах данных и SaaS-инструментах без необходимости их перемещать.
Важную роль в этом сдвиге играют открытые форматы, такие как Apache Iceberg. Когда данные безопасности хранятся в открытых форматах, с ними могут работать разные движки — будь то SQL в больших масштабах или программа на Python, которую агент пишет на лету. Развиваются и SIEM-системы. Чтобы обеспечить командам безопасности максимальную совместимость и доступ к данным, SIEM должны поддерживать открытые платформы данных и работать с федеративными данными на месте, без предварительного приёма.
Такая гибкость порождает собственную проблему безопасности. Когда данные остаются на месте, там же остаются и регулирующие их права доступа, а управлять ими централизованно невозможно. Дублирование и синхронизация правил по всем источникам не масштабируется на тысячи агентов, а перекладывание авторизации на конечных пользователей создаёт новые риски — например, prompt injection или утечку учётных данных. Решение — детализированные средства контроля вплоть до строк и столбцов, которые задаются один раз и применяются в момент выполнения запроса, в том числе к таблицам в открытых форматах. Каждый запрос должен передавать реальную личность пользователя через краткосрочные учётные данные с ограниченной областью действия, чтобы агенты не могли превысить полномочия человека, который ими управляет.
Когда появляется сигнал угрозы, задача смещается от поиска нужных журналов к анализу последствий. Обработка графов позволяет связать изолированное событие с окружающими активами и помогает командам безопасности отследить любое горизонтальное перемещение. Каталог знаний добавляет ещё один уровень контекста, предоставляя агентам и аналитикам-людям карту информационных активов организации, чтобы они знали, где искать.
Контроль затрат в машинном масштабе
Большие языковые модели хорошо анализируют записи журналов, но их запуск на петабайтах телеметрии безопасности быстро становится дорогим. Уровень данных должен сужать объём обрабатываемой информации ещё до того, как к работе приступят модели.
Это можно делать поэтапно. Потоковые запросы отслеживают события по мере поступления и помечают подозрительные. Второй проход сверяет их с историческими данными, ещё больше сокращая список. Только после этого к расследованию подключается агент.
Некоторые базовые модели предварительно обучены на миллиардах временных рядов — например, на сетевом трафике или активности входа в систему во времени, — поэтому уже знают, как выглядят нормальные закономерности. Это позволяет им выявлять необычную активность на ранних стадиях без специального обучения. Для более простых задач, таких как сортировка записей журнала на «опасные» и «безобидные», платформа данных может на лету создать небольшую специализированную модель, что дешевле, чем прогонять каждую запись через большую.
Расследования, проводимые агентами, также делают спрос непредсказуемым. Когда агенты начинают искать по историческим журналам, объём запросов может резко вырасти и так же быстро упасть. Аппаратные решения и заранее выделенные облачные мощности не рассчитаны на такую картину. Платформе данных нужно бессерверное масштабирование, которое расширяется и сжимается по мере необходимости, чтобы команды безопасности платили только за то, что используют, с посекундной точностью.
Наблюдение за собственными агентами
Агенты также создают новые риски безопасности внутри компании. Передавая работу агенту, компания должна решить, к чему ему разрешено прикасаться, — так же, как в случае нового сотрудника.
Традиционное ПО работает предсказуемо, а агенты — нет. Их поведение вероятностно, поэтому им нужны собственные идентификаторы с ограничениями на доступ к данным, документам и системам, даже если у человека, который ими управляет, более широкие права.
Prompt injection делает эти ограничения ещё важнее. Если раньше злоумышленники применяли SQL-инъекции против баз данных, то теперь они могут прятать инструкции в данных, которые читает агент. Всё, что попадает в контекст агента, может повлиять на его дальнейшие действия, поэтому командам безопасности нужно контролировать, что каждый агент может читать, записывать и отправлять. Любое внешнее подключение — потенциальный канал утечки данных.
Даже авторизованный агент может совершить последовательность по отдельности допустимых действий, которые в совокупности становятся опасными. Но за собственными агентами и следить проще. Агенты злоумышленника проявляются лишь как аномалии, а ваши оставляют полную запись своих действий. Анализ этой записи в машинном масштабе позволяет командам безопасности заметить агента, сбившегося с курса.
От пассивного архива к активной защите
По мере того как агенты берут на себя всё больше работы, меняется и роль аналитика по безопасности. Вместо того чтобы вручную выполнять запросы и сортировать оповещения, аналитики будут больше времени тратить на определение приоритетов и проверку находок агентов — так же, как разработчики сейчас проверяют планы кода, написанного агентами, вместо чтения каждой строки. Это работает, только если агенты могут показать ход своей работы. Аналитикам нужно видеть, какие данные изучал агент, какие шаги предпринял и как пришёл к выводу.
Это меняет роль уровня данных в безопасности. Раньше там хранились события, к которым обращались постфактум. Теперь он стал частью того, как команды безопасности понимают события в момент их возникновения. Ваша архитектура данных должна дать агентам и командам безопасности скорость, контекст и масштаб, чтобы остановить атаку до того, как она нанесёт вред.
Чтобы узнать больше, присоединяйтесь к нашему предстоящему виртуальному мероприятию Trusted Agents, Real Outcomes. Скачайте это руководство по защите автономных сред с помощью Agentic Data Cloud от Google и созданию основы платформы данных для безопасности на базе BigQuery.
Томас Талиус — вице-президент по инженерным разработкам Google BigQuery в Google Cloud.
Спонсорские статьи — это материалы, созданные компанией, которая либо оплачивает публикацию, либо имеет деловые отношения с VentureBeat; они всегда чётко помечены. За дополнительной информацией обращайтесь по адресу sales@venturebeat.com.
