Мы много писали о роли ИИ в аналитике и разработке ПО. Теперь решили выпустить несколько материалов о том, как ИИ меняет кибербезопасность — вместе с нашей Red Team / pentest‑командой. Начинаем с перевода The Cybersecurity Industry Is Entering Its Third Era. При этом руководитель нашей Red Team на вопрос о главном изменении последних лет отвечает ещё короче: скорость. Но об этом в следующем материале.
Я помню, как на обсуждении архитектуры безопасности можно было целый час спорить об одном: куда поставить межсетевой экран.
Сейчас это звучит почти старомодно. У сети были внутренняя и внешняя стороны. Приложения работали на серверах, которые стояли в конкретном месте в серверной в офисе. Пользователи подключались через корпоративные сети. Команды ИБ выстраивали вокруг этой инфраструктуры уровни защиты и подолгу решали, какие порты открыть, каким сетям разрешить обмен трафиком и кого пускать удалённо.
Потом пришли облака. Разработчики получили возможность разворачивать приложения без покупки серверов, без собственного железа. Приложения превратились в наборы API, контейнеров, бессерверных функций, управляемых баз данных и SaaS‑сервисов, распределённых по регионам и аккаунтам. Инфраструктура стала кодом, развёртывание стало непрерывным, а ошибка в политике IAM могла оказаться важнее целой стойки межсетевых экранов.
Информационной безопасности пришлось пересобрать себя. И, думаю, скоро придётся сделать это снова.
На мой взгляд, современную историю отрасли можно условно разделить на три эпохи: инфраструктурную, облачную и наступающую эпоху ИИ‑агентов.
ИИ‑агенты меняют сразу несколько вещей: системы, которые мы защищаем, противников, от которых защищаемся, и всё чаще саму работу специалистов по информационной безопасности.
Именно сочетание этих изменений придаёт переходу такой масштаб.
Первая эпоха: инфраструктура
Для специалистов, которые начинали карьеру в девяностые или в начале двухтысячных, информационная безопасность в основном строилась вокруг инфраструктуры: сетей, серверов, рабочих станций, баз данных и корпоративных дата‑центров. Мы возводили вокруг них стены.
Архитектуру было относительно легко представить. Есть внутренняя сеть и внешняя. Между ними стоит межсетевой экран. Сотрудники подключаются удалённо через VPN. На конечных устройствах работает антивирус. Системы обнаружения и предотвращения вторжений, IDS и IPS, следят за сетевым трафиком. Специалисты по безопасности разбирались в межсетевых экранах, VPN, сегментации сети, Active Directory, управлении обновлениями и обнаружении вторжений.
В основе лежала защита периметра: удерживать атакующих снаружи, защищать доверенные системы внутри и контролировать всё, что пересекает границу. На практике всё всегда было сложнее, но сама модель была понятной. Потом приложения переехали, и модель начала ломаться.
Вторая эпоха: облака
Облака изменили подход к проектированию приложений. Одной заменой физических серверов на виртуальные дело не ограничилось.
Раньше типовое приложение могло состоять из веб‑сервера, который обращался к серверу приложений, а тот обращался к базе данных. Приложения, спроектированные для облака, стали сочетать балансировщики нагрузки, API, бессерверные функции (типа AWS Lambda), контейнеры, кластеры Kubernetes, управляемые базы данных, очереди, объектные хранилища, сервисы управления секретами и сторонние SaaS‑платформы.
Приложения превратились в распределённые системы. Разработчики могли создавать инфраструктуру за минуты. Инфраструктура стала программируемой. Развёртывание стало непрерывным.
Появились и новые проблемы безопасности. Неверно настроенная роль IAM ((роль управления доступом)) могла открыть доступ к среде вообще без участия межсетевого экрана. Публичный S3 бакет (облачное хранилище) мог стать причиной утечки миллионов записей. Взломанный конвейер CI/CD мог дать прямой путь в продакшен. Долгоживущий API‑ключ мог превратиться в универсальную отмычку.
Управление идентичностями фактически стало частью периметра.
Специалистам по безопасности пришлось осваивать новый словарь: IAM, управление ключами KMS, инфраструктуру как код, контейнеры, Kubernetes, CI/CD, Zero Trust, DevSecOps, контроль состояния безопасности облачной инфраструктуры, управление секретами и идентичности рабочих нагрузок.
Команды ИБ уже не могли подключаться только в конце процесса развёртывания и проверять то, что построили инженеры. Безопасность пришлось встроить в жизненный цикл приложения. Инженеры по безопасности начали писать код. Разработчики включились в работу над безопасностью. Облачные архитекторы стали критически важны для её обеспечения. Средствами защиты начали управлять через API, а политики всё чаще описывали кодом.
Этот переход породил многие привычные сегодня роли: инженер по облачной безопасности, DevSecOps‑инженер, инженер по безопасности продукта, инженер по безопасности приложений и архитектор облачной безопасности. Двадцать лет назад некоторых из этих названий не существовало. Потом они появились в вакансиях, вошли в организационные структуры, программы сертификации, учебные курсы и запросы предложений от заказчиков. Отметим, что формальное обучение почти всегда догоняет уже произошедшие технологические изменения.
Думаю, с ИИ‑агентами мы сейчас находимся как раз на этом этапе.
Третья эпоха: ИИ‑агенты
Организации используют ИИ уже много лет, но только сейчас ИИ‑системы начинают действовать самостоятельно.
ИИ‑ассистент отвечает на вопрос. ИИ‑агент выполняет действия. Он читает документы, делает запросы к базам данных, вызывает API, пишет код, меняет конфигурации, создаёт задачи, использует инструменты. И всё чаще сам определяет, какая последовательность действий нужна для достижения поставленной цели.
Так возникает ситуация, с которой информационная безопасность прежде редко сталкивалась в таком масштабе: программа интерпретирует намерение и самостоятельно решает, как достичь цели.
Традиционные приложения в основном детерминированы. Если в коде написано, что при событии X нужно выполнить действие Y, обычно так и происходит. Традиционные средства защиты столь же предсказуемы. Если правило межсетевого экрана блокирует порт 22, он будет заблокирован. Если политика IAM запрещает вызов API, этот вызов будет отклонён.
Агент ведёт себя иначе.
Двум агентам можно поставить одну цель и получить разные последовательности действий. Агент может неверно понять инструкцию, довериться вредоносным данным, выбрать неподходящий инструмент или раскрыть конфиденциальную информацию, пытаясь выполнить вполне законную задачу. Он может принять текст внутри документа за инструкцию. Может обратиться к другой системе с правами, которых никогда не было у общающегося с ним человека. И, пожалуй, самое опасное: после этого он может завершить задачу и сообщить, что всё прошло успешно. Задача безопасности меняется.
Безопасность теперь касается и решений
В инфраструктурную эпоху один из главных вопросов звучал так: может ли эта машина связаться с той? В облачную эпоху критически важным стал вопрос: может ли эта учётная запись выполнить это действие над этим ресурсом? Эпоха ИИ‑агентов добавляет третий: стоит ли вообще разрешать этой системе принимать такое решение?
Возьмём агента для управления уязвимостями. Он обнаруживает уязвимость, определяет затронутое приложение, выбирает способ исправления, меняет код, запускает тесты, создаёт pull request и, возможно, развёртывает исправление.
Звучит прекрасно до тех пор, пока агент не примет неверное решение. Или в описании уязвимости не окажутся вредоносные инструкции. Или агент не изменит посторонний компонент. Или его тесты не пропустят регрессию. Или другой агент не использует ошибочный результат и автоматически не выполнит следующее действие.
Одна ошибка теперь может запустить цепную реакцию.
Мы десятилетиями обсуждаем избыточные права. ИИ‑агенты добавляют ещё одно понятие, которое может оказаться столь же важным: избыточная автономность.
Принцип минимальных привилегий никуда не исчезает. Но, полагаю, архитектура безопасности всё чаще будет строиться вокруг сочетания: минимальные привилегии + минимально необходимая автономность + максимальная наблюдаемость. Давайте агенту только нужные права. Разрешайте лишь ту самостоятельность, которая действительно требуется. Обеспечивайте возможность проследить важные решения. По возможности делайте разрушительные действия обратимыми.
Средства защиты тоже изменятся
Сегодня средства защиты в основном обеспечивают соблюдение правил. Завтра им, возможно, всё чаще придётся интерпретировать происходящее, взаимодействовать друг с другом и вмешиваться. Представьте несколько агентов внутри центра мониторинга и реагирования на инциденты, SOC. Один обнаруживает подозрительную активность. Второй расследует её. Третий запрашивает сведения об угрозах. Четвёртый изолирует конечное устройство. Пятый регистрирует инцидент. Шестой готовит сообщения. Седьмой начинает собирать цифровые доказательства.
Эти системы взаимодействуют и принимают решения, выходя за рамки выполнения статичных правил. Значит, они могут расходиться во мнениях, неверно понимать друг друга или распространять ошибочную информацию. Архитектуре безопасности придётся отвечать на вопросы, которые раньше почти не возникали. Какому агенту может доверять другой агент? Как агент проходит аутентификацию? Может ли он делегировать свои права? Может ли динамически получать дополнительные возможности? Что произойдёт, если в его контекст внедрят вредоносные данные? Как проверить его реальные действия независимо от собственного отчёта? Сможем ли мы потом восстановить, как было принято решение?
Эти вопросы изменят профессии в информационной безопасности так же, как это сделали облака.
Как изменятся роли
Аналитики SOC, вероятно, столкнутся с одним из самых заметных сдвигов. Работа первой линии включает сбор логов, проверку IP‑адресов, сопоставление событий и определение того, указывает ли срабатывание на реальную угрозу. Агенты как раз учатся хорошо выполнять такую повторяющуюся работу по расследованию. Потребность в аналитике сохраняется, но часть его нынешних обязанностей исчезает. Всё чаще аналитик будет проектировать процесс расследования, проверять выводы агентов, разбирать неоднозначные случаи, которые не удаётся автоматизировать, и выяснять, почему агент ошибся в прошлый вторник. Если ваша работа почти целиком сводится к наблюдению за очередью и выполнению готового плейбука, я бы стремился выйти за её пределы.
Инженеров по безопасности ждёт похожий сдвиг. Написание отдельных скриптов и ручная настройка защитных продуктов отчасти теряют ценность, когда модель за секунды может выдать правдоподобный вариант. При этом сохраняется ценность решений о том, как всё связано: где допустимо автоматическое принятие решений, под какими учётными записями работают агенты, до каких систем могут добраться, что происходит при сбое и где обязательно участие человека.
Значимость инженера по безопасности может сохраняться, а область его ответственности перемещается на более высокий уровень в проектирвоание. Самые большие изменения могут произойти в GRC (Governance, Risk and Compliance — работе с управлением, рисками и соответствием требованиям). Огромная часть этой работы по‑прежнему состоит из таблиц, опросников, сбора подтверждающих материалов, сопоставления мер контроля с требованиями и ручной проверки этих мер. Такие задачи хорошо поддаются автоматизации. Представьте агентов, которые непрерывно собирают данные о конфигурациях, сверяют техническое состояние систем с политиками, сопоставляют меры контроля с требованиями стандартов, находят пробелы и готовят доказательную базу для аудита. Сохранит ценность специалист GRC, который проектирует систему непрерывного подтверждения соответствия. Одного ведения матрицы контролей будет недостаточно.
Дальше возникает ещё одна задача: управление самими агентами. Какие решения им разрешено принимать? Какие подтверждающие материалы они обязаны сохранять? Как продемонстрировать контроль со стороны человека? Кто отвечает за ошибочное решение автономной системы? Что вы покажете аудитору? Эта роль гораздо более техническая, чем та, на которую изначально приходили многие специалисты GRC.
Архитекторы тоже поднимаются на уровень выше. В архитектуре к сетям, приложениям и идентичностям добавляются автономные участники, принимающие решения. Может ли агент выполнять команды? Может ли затрагивать продакшен? Может ли общаться с другим агентом? Имеет ли доступ к конфиденциальным данным? Что произойдёт, если кто‑то внедрит вредоносные данные в его контекст? Как проверить результат одного агента до того, как другой начнёт на его основе действовать? Где нужно одобрение человека?
Часть этих вопросов техническая, часть касается допустимой автономности. Хорошие архитекторы всё больше становятся стратегами в области рисков: людьми, которые глубоко понимают технологию и способны определить, какие решения можно доверить машинам и где это недопустимо.
Если вы только пришли в профессию
Новичкам сейчас продают много информационного шума, не пропускайте основы ради модной надстройки.
Без понимания IAM, сетей и аутентификации невозможно толком оценить масштаб возможного ущерба от действий агента. Без понимания API нельзя разобраться в злоупотреблении инструментами. Без знания того, как работают идентичности и токены, нельзя понять злоупотребление учётными данными.
Каждая эпоха становится основанием для следующей. С вашими знаниями происходит то же самое. Изучите сети. Изучите Linux. Разберитесь с IAM. Освойте API. Как следует изучите одну облачную платформу. Затем надстраивайте над этой базой знания об агентах.
Но у нынешнего перехода есть ещё одно важное отличие от предыдущих. Чтобы получить опыт, вам не нужно ждать, пока подтянется индустрия обучения. Когда облачная безопасность только появилась, люди часто попадали в знакомую ловушку: для устройства на работу нужен опыт работы с облаками, а получить его негде. ИИ‑агенты дают необычную возможность. Технология достаточно доступна, чтобы значительную часть этого опыта вы могли получить самостоятельно.
Не ждите появления сертификата специалиста по безопасности ИИ‑агентов. Не ждите пятидневного семинара, на котором вам покажут, как выглядит ИИ‑агент. Не ждите, пока работодатель разрешит вам экспериментировать. Соберите агента сами. Создайте простого агента с двумя‑тремя инструментами. Пусть он читает файл, вызывает публичный API и, возможно, пишет в трекер задач. Дайте ему учётную запись с заведомо избыточными правами и посмотрите, что произойдёт. Поместите вредоносные инструкции в документ, который он читает. Попробуйте повлиять на выбор инструмента. Проверьте, сможете ли вы заставить его раскрыть информацию или выполнить действие, которого вы не планировали.
Затем защитите его. Ограничьте права, добавьте этапы согласования действий, доработайте модель идентификации, включите журналирование и проведите моделирование угроз для архитектуры. Теперь у вас есть результат, который гораздо ценнее строчки об участии в семинаре по безопасности ИИ. Вы можете объяснить, что построили, как атаковали, что сломалось и как вы это защитили. Выложите код на GitHub. Напишите об эксперименте в LinkedIn. Подготовьте короткую статью. Расскажите о нём на собеседовании.
Возможно, вы никогда не занимали должность инженера по безопасности ИИ. Но вы уже защитили реальную ИИ‑систему. На нынешнем этапе рынка эта разница имеет значение. Сертификации появятся. Учебные компании подготовят курсы. Вендоры придумают значки. Со временем в этой области сложатся признанные карьерные траектории. Но всё это почти всегда появляется после практиков. Сейчас вы можете стать одним из них.
Читайте первоисточники
При этом не стройте своё понимание целиком на постах в соцсетях и обзорах вендоров. Читайте исходные материалы. Изучайте работы OWASP по безопасности LLM и агентов. Разбирайтесь с подменой цели агента, злоупотреблением инструментами, идентичностями и привилегиями, а также с рисками цепочки поставок агентных систем. Читайте рекомендации государственных органов и отраслевых организаций. Прочитайте спецификацию MCP, чтобы понимать, как именно инструменты становятся доступны моделям.
Затем проверяйте эти идеи собственными экспериментами. Сочетание фундаментальных знаний, первоисточников и практической разработки гораздо сложнее имитировать, чем коллекцию сертификатов. А если выбираете между ролями, ищите работу, связанную с созданием систем. Позиции, сводящиеся к наблюдению за срабатываниями, особенно уязвимы перед автоматизацией. Работа, в которой вы проектируете, строите, тестируете, интегрируете или взламываете системы, заметно устойчивее.
Если у вас уже десять или двадцать лет опыта
Если вы уже провели в информационной безопасности десять или двадцать лет, ваш опыт даёт вам серьёзное преимущество. Навыки моделирования угроз применимы напрямую. Понимание границ доверия применимо напрямую. Знание того, почему мера защиты прекрасно выглядит в PowerPoint, но разваливается в продакшене, применимо напрямую. Понимание того, как организации ведут себя в действительности, тоже.
Труднее может оказаться тем, чья экспертиза в основном сводится к конкретному продукту: глубокому знанию интерфейса определённой консоли, с которой модель вскоре, возможно, будет работать не хуже.Применяйте накопленный опыт на следующем уровне. Начните с инвентаризации того, что у вас уже есть. В организации могут работать агенты, которые служба безопасности никогда официально не учитывала: помощники для программирования внутри жизненного цикла разработки, агентные функции SaaS‑платформ, ИИ‑системы, подключённые к корпоративным базам знаний, или чья‑то полезная автоматизация с долгоживущим API‑токеном.
Спросите у команды разработки, какие агенты для программирования используются, какие работают внутри CI/CD, какими учётными данными располагают и до каких систем могут добраться. Такой разговор обычно многое проясняет. Затем оцените развёрнутых агентов с помощью простых архитектурных вопросов. Есть ли у агента доступ к закрытым данным? Может ли он получать недоверенные входные данные? Есть ли у него канал передачи информации наружу? Когда присутствуют все три условия, риск становится гораздо серьёзнее.
По возможности уберите одно из звеньев этой комбинации. Не рассчитывайте, что очередной фильтр промптов решит проблему. Архитектурные меры защиты обычно надёжнее очередной инструкции модели вести себя правильно. Управлению доступом агентов нужно уделить отдельное внимание. Не давайте агентам использовать пользовательские учётные данные. Создавайте для них отдельные сервисные учётные записи, выдавайте только необходимые права и используйте короткоживущие токены. По возможности проверяйте авторизацию каждого запроса.
Возможно, это одна из наименее эффектных частей безопасности ИИ‑агентов. И одновременно одна из самых важных. Мы уже проходили этот урок в облаках: сервисные учётные записи, роли IAM, идентичности рабочих нагрузок. Не стоит повторять ошибку и давать автономной системе чей‑то администраторский токен только потому, что так проще собрать прототип.
Оценивайте совокупность возможностей агента
Организациям тоже нужно выйти за рамки отдельных инструментов и смотреть на безопасность агентов через их возможности. Может ли агент читать данные из аналитического хранилища? Создавать задачи? Менять исходный код? Отправлять письма внешним адресатам? Развёртывать изменения в продакшене?
Решения о таких полномочиях стоит принимать один раз, а затем последовательно обеспечивать их соблюдение. Если согласовывать инструменты по отдельности, однажды можно обнаружить, что агент для закупок одновременно получил доступ к финансовым системам, договорам и почте. Опасность редко заключается в одном инструменте. Её создаёт сочетание возможностей. Такая же осторожность нужна со списками разрешённых действий и другими мерами, которые мы привычно считаем безопасными. Агентные системы дают атакующим новые способы использовать внешне доверенные действия. Если агент автоматически одобряет определённые команды или операции, у атакующего появляется стимул выяснить, как провести вредоносную задачу через эти разрешённые пути. Список разрешённых действий по‑прежнему полезен, но сам по себе безопасность не доказывает.
Измените подход к тестированию
Традиционное функциональное тестирование проверяет, выполнила ли система задачу. Для агента этого недостаточно. Агент, поведение которого перехватил атакующий, может безупречно выполнить запрошенную задачу и по пути сделать что‑то вредоносное. Поэтому при проверке безопасности агента нужно исследовать и результат, и путь к нему. Проверяйте устойчивость к внедрению инструкций, prompt injection. Изучайте вызовы инструментов. Ищите подозрительные последовательности действий. Наблюдайте за агентом независимо от его собственных отчётов. Фиксируйте, к чему он обращался. Проверяйте, можно ли было достичь той же цели с меньшими привилегиями. Мы переходим от проверки результатов к проверке решений и действий.
Возьмите эту работу на себя, пока её не взял кто‑то другой
Возможно, это самая большая возможность для опытных специалистов по информационной безопасности. Вам необязательно ждать вакансии с названием «Архитектор безопасности ИИ‑агентов». Не нужно ждать, пока работодатель оплатит дорогую сертификацию или рынок обучения определится с официальной программой. Возможно, самый быстрый способ освоить новую область состоит в том, чтобы взять на себя эту задачу в своей нынешней организации. Выясните, где внедряются агенты. Составьте реестр. Подготовьте требования безопасности. Определите типовые подходы к управлению идентичностями. Разработайте модели угроз. Установите уровни автономности. Создайте стандарты тестирования. Вместе с GRC проработайте правила управления. Определите, какая телеметрия нужна SOC.
Если ваша организация пока почти не работает с агентами, самостоятельно соберите небольшой внутренний прототип. Получайте опыт на практике. Не ждите, пока кто‑нибудь официально подтвердит, что вы готовы его получать. В большинстве организаций за эту область пока никто полноценно не отвечает. Спрос уже виден, технология быстро развивается, и вы можете учиться, решая реальную бизнес‑задачу. Редкое сочетание.
Появление ИИ‑агентов не делает межсетевые экраны ненужными, как и облака не заставили сети исчезнуть. Каждая предыдущая эпоха становится частью фундамента для следующей. Нам по‑прежнему нужны сетевая безопасность, IAM, шифрование, управление уязвимостями и безопасная разработка, но над ними формируется ещё один уровень. Инфраструктурная эпоха научила нас защищать машины и сети. Облачная эпоха научила защищать приложения, распределённые системы и идентичности. Эпоха ИИ‑агентов заставит нас защищать системы, которые принимают решения.
Возможно, это самый масштабный переход, с которым информационная безопасность сталкивалась до сих пор. Системы, которые мы защищаем, будут интерпретировать инструкции, выбирать действия, использовать инструменты, взаимодействовать с другими системами и иногда принимать решения, которые никто явно не закладывал в программу. Организации, которые раньше это осознают, перестроят архитектуру безопасности с учётом этой реальности. Специалисты, которые раньше это осознают, получат огромные возможности. Прежние подходы сохраняют пользу, но их уже недостаточно. И, пожалуй, главный урок облачной эпохи не ждите, пока названия должностей, сертификаты и учебные программы сообщат вам о наступлении следующей эпохи. К тому моменту у тех, кто начал строить раньше, уже будет опыт. К вопросу «Как мне использовать ИИ?» у специалистов по информационной безопасности теперь добавляется — Как должна быть устроена безопасность, если защищаемая система способна действовать самостоятельно?
Это и есть третья эпоха.
И она уже начинается.
