Всем привет! Меня зовут Денис Панков, я занимаюсь R&D исследованиями по направлению ИБ . Помню, когда поступал на ИБ направление, сложно было представить, что рост отрасли будет настолько стремительным.
Хотелось бы выделить несколько точек, которые так сфокусировали развитие современного ПО. ИБ я рассматриваю как часть ИТ, сейчас отрицать это бессмысленно, особенно с ростом количества инструментов LLM.
Во-первых, в ИТ появилась классическая книга Роберта Мартина, подход Clean Architecture повлиял на качество кода и легкость в тестировании. Далее блокчейн, который во много повлиял на организацию децентрализованных вычислений. В ИТ-системах было множество попыток выполнить ряд операций с помощью реестров, выполняемых на клиентской стороне и Web3-проекты, а также как автономная система логирования. Многие подходы Web3 росли вместе с ИИ.
Затем следует отметить появлении современного ИИ и мультиагентного подхода. Когда появились LLM, стандарты и требования для их применения отсутствовали. Отсюда возникло множество вариантов эксплуатации свойств, к котором были применимы старые виды уязвимостей, а при объединении с новыми вычислительными системами возникали проблемы, которые им были ранее не свойственны (свойство эмерджентности). Давайте представим, что ИБ департаменту дали зада��ие защитить систему, которая будет работать примерно так, как представлено на следующей картинке...
Причем интересно то, что рост использования непосредственно в ИБ был экспоненциальным как для Red Team, так и защищающихся. И вот сейчас большая часть приложений (не важно, работает ли ваши сервисы в микросервисном окружении, роботе ли во встроенном ПО автомобиля или автономном дроне) нуждается в новой концепции, которая сможет обеспечить архитектуру приложения необходимой защитой, которая актуально дешевле, чем устранение проблем проявления уязвимостей.
На Offzone 2025 был хороший доклад ребят из команды Т-Банка (https://offzone.moscow/program/pentest-by-a-click-it-s-already-real/), где проводится пентестинг с помощью LLM-инструментов, где генерация тестов дополнена с помощью ИИ. И это явно отдельная область, но по идее этот инструмент должен быть включен как часть проектируемой программно-аппаратной системы. И на это должен ответить ряд архитектурных требований, который появится в стандартах новый мультиагентных систем.
Поэтому есть мысль, что скачок развития LLM, наконец должно привести к Clean Architecture в области AI Safety - должен появится единый подход проектирования, целью которого будет привести угрозы ИБ к виду, который будет Secure by Design для систем с интеграцией AI-компонентов. Сейчас же сам термин AI Safety применим только как узкая часть безопасности самой LLM и передачи данных в ней. Это понятие гораздо шире.
Сейчас основной трэд развития технологий заключается в автоматизации рутины с помощью ИИ, но дать ей возможность использования в содержащих, например, пользовательские данных достаточно опасно для бизнеса. Автоматизировать работу call-центра – да, а вот отдать на откуп более сложные операции – больше проблем.
С другой стороны, опытные специалисты в своей деятельности вовсю используют такие инструменты, снабдив RAG-предметной областью инструмент или выполнив fine-tuning готовой модели.
Как построить Secure by Design для систем с интеграцией AI-компонентов на сегодня я не отвечу, но поставлю вопрос на его формирование. Отдельно для LLM вышло сразу несколько технических документов из ведущих российских разработчиков, которые описали классификацию проблем AI-приложений, с которыми они столкнулись.
Конечно, мировое ИБ сообщество, сразу попыталось осмыслить риски применения AI-приложений, что в свою очередь способствовало созданию новых фреймворков для проведения атак согласно этому списку (OWASP TOP 10 LLM).
Во-первых, следует отметить, что безопасно можно сделать либо саму LLM, что известно как архитектура, построенная в Anthropic. И второй вариант, когда сама LLM не является доверенной, а клиент LLM является доверенным приложением, в который встроена фильтрация за счет применения SOC-средств (например LLMATOR).
Далее, векторов атаки на приложения с LLM настолько много, что OWASP выпустило 10 классов уязвимостей, а Сбер 5 видов и всего 70 разнообразных вариантов атак. Рассмотрим простой вариант атаки чисто на LLM (далее приведем маленькую симпатичную табличку сравнения). А перед этим - как исследователь безопасности ее тестит.
Поскольку развитие не стоит на месте, то появились мультиагентные системы, где точек входа использования LLM может быть очень много. Отсюда возникает вопрос, который изначально подразумевается в начале статьи. Какой же должна быть современная архитектура программно-аппаратных систем, которые используют LLM в множественном и единственном числе и где границы применимости систем с точки зрения стандартных векторов атак? Этот вопрос, цель статьи - над ним подумать всем вместе.
Когда мультиагентные системы стали популярны, одну из которых придумал Antropic для управления компом (AI Agent for Computer Control). Агент, конечно, работает в песочнице, но не мне объяснять хакерам, что привилегии можно повысить)
Anthropic разрабатывает агенты, которые могут выполнять задачи на уровне операционной системы, взаимодействуя с приложениями, файлами и интерфейсами. Это достигается за счёт:
Интеграции с API операционной системы (например, Windows, macOS, Linux).
Автоматизации действий через скрипты, эмуляцию клавиатуры/мыши или специализированные инструменты.
Использования LLM (Large Language Models) для интерпретации команд пользователя и преобразования их в действия.
Использование автономных виртуальных помощников в данной области добавит сумбура в ИБ направлении. Что делать, если его хакнут и заставят работать против его программы?
Весьма удачная попытка упорядочить, введя классификацию угроз моделей была сделана Yandex и Сбером на основе своих исследований, а также общемировых. Из размещенных в открытом доступе информации получается следующая сравнительная характеристика типов атак. Сравнение «Модели угроз для кибербезопасности AI» от Сбера и фреймворка «AI Secure Agentic Framework Essentials» (AI-SAFE) от Яндекса позволяет выделить два различных, но взаимодополняющих подхода к защите интеллектуальных систем.
В этой табличке я сделал сравнение для этим двух таких не похожих, но в целом интересных модели классификации угроз
Параметр сравнения | Модель угроз Сбера | Модель AI-SAFE Яндекса |
Основной фокус | Весь жизненный цикл ИИ-решений от сбора данных до эксплуатации | Проактивные и автономные мультиагентные системы |
Структура классификации | Группировка по этапам и типам: данные , инфраструктура, модель, приложение, агенты | 5 уровней архитектуры: интерфейс, инструменты, инфраструктура, ядро/логика, данные |
Количество угроз | Детальный перечень из 70 специфицированных угроз | Системный обзор рисков с акцентом на агентный цикл и инструменты исполнения |
Свойства информации | Традиционная триада (КЦД) + Достоверность | Упор на проактивность, автономность и механизмы обратной связи для стабильности систем |
Целевая аудитория | Разработчики, архитекторы, ИБ-специалисты и руководители рисков | ИБ-профессионалы (CISO, DevSecOps), инженеры данных и ML-архитекторы |
Анализ модели Сбера: Процессный подход
Модель Сбера является более «энциклопедичной» и фокусируется на последовательности создания ИИ. Она разделяет системы на PredAI (предикативный ИИ) и GenAI (генеративный ИИ), что позволяет точно определять релевантность угроз для конкретных бизнес-задач. У Сбера преимуществом является формализация свойства «Достоверность» как отсутствия субъективизма и галлюцинаций, что критично для финансового сектора.
Анализ модели Яндекса (AI-SAFE): Архитектурный подход
Яндекс делает ставку на агентность — способность ИИ не просто генерировать текст, а самостоятельно планировать задачи и использовать внешние инструменты (API, протоколы MCP).
Архитектурные уровни: AI-SAFE делит угрозы на уровни, от интерфейса взаимодействия до ядра логики и планирования.
Исполнение и инструменты: Особое внимание уделяется рискам на «Уровне 2», где агент выполняет действия в реальной цифровой среде. Это включает сценарии, когда агент может быть использован как инструмент атаки (например, запуск сканеров уязвимостей).
Компоненты агента: Яндекс детально описыва��т структуру агента, выделяя «Модуль агентного цикла», который управляет авторизацией и логикой взаимодействия, что в модели Сбера рассматривается в более общем контексте приложений.
Несмотря на разницу в методологии, обе модели демонстрируют единство российской экспертизы в следующих аспектах:
Глобальная синхронизация: Оба документа базируются на актуальных мировых стандартах 2025 года, включая OWASP Top 10 for LLM Applications, MITRE ATLAS и рекомендации NIST.
Защита цепочки поставок: Обе компании выделяют использование open-source компонентов и сторонних библиотек как критический вектор атаки (Supply Chain Security).
Борьба с инъекциями: Промпт-инъекции (прямые и непрямые) признаются главной угрозой прикладного уровня в обеих моделях.
Модель Сбера лучше подходит для построения комплексной системы ИБ в организации «с нуля» по всем этапам разработки. Модель Яндекса (AI-SAFE) незаменима при проектировании сложных автономных систем и мультиагентных сред, где на первый план выходят риски неконтролируемого планирования и исполнения действий агентами.
Интересно, а как устроена обратная сторона?
Интерфейсы таких утилит как правило похожи на ChatGPT, но используют примеры, обученные на атакующих наборах по различным типам уязвимостей (например, на базе Mistal)
Для автоматизации проведения комплексных атак на AI приложения (естественно, в научных целях) известны несколько фреймворков. В этой табличке самые интересные Hack-решения, которые можно опробовать.
AI Tools for Hackers – Таблица
Инструмент | Основное назначение | Ключевые возможности | Для кого |
NeuroSploitV2 | AI-пентестинг с использованием LLM | Сканирование уязвимостей в AI-системах, промпт-инъекции, мультимодальные атаки, интеграция с Metasploit | Специалисты по AI-безопасности, пентестеры |
Strix | Автоматизированный пентестинг | Сканирование веб-приложений, API, облачных инфраструктур, CI/CD интеграция | Разработчики, DevOps |
PentestGPT | Генерация тестовых сценариев с использованием GPT | Интерактивный помощник, анализ уязвимостей, интеграция с Metasploit, Burp Suite | Этичные хакеры, пентестеры |
Reaper | Поиск сложных и zero-day уязвимостей | Глубокое сканирование сетей, анализ веб-приложений и API, обнаружение аномалий | Корпоративные команды безопасности |
PENTAGI | Комплексный пентестин�� | Мультивекторное сканирование, SOAR, интеграция с SIEM, соответствие стандартам ISO 27001, NIST | Крупные организации, аудиторы |
Cybersecurity AI | Мониторинг угроз в реальном времени | UEBA, SOAR, анализ логов, обнаружение ransomware и APT-атак, интеграция с Palo Alto, Fortinet | SOC, предприятия |
Эти инструменты помогают:
Ускорить процесс тестирования за счёт автоматизации пентестинга.
Повысить точность обнаружения уязвимостей благодаря машинному обучению.
Сократить риски за счёт проактивного мониторинга и реагирования на угрозы.
Для защиты есть очень интересные решения, которые оборачивают обращение к LLM-среде и контролируют ее выполнение. Какой может быть clean architecture для AI приложений? Скоро увидим. Если бы решение попросили дать студента, то он бы нарисовал примерно такую картинку. Но в проде сложнее.
А на деле пользователи Reddit обсуждают ее merge с другими вариантами архитектур, в том числе DDD
А что говорят стандарты?
Сейчас ряд технических комитетов пытается решить задачу осмысления (пока с переменным успехом), наибольший вклад на мой субъективный взгляд вносит ряд компаний, в том числе Swordfish Security. У них есть неплохой отчет, из которого возьму картинку для демонстрации текущего положения вещей (с безопасностью ИИ есть вопросы).
Заключение
Я наблюдаю за решением «технарей» в крупных компаниях с криками «давай прикрутим еще одну штуку – будет круто», на что данная картинка и принципы системного анализа говорят, что решение задачи лежит в правильной постановке.
Cогласно формируемой базе ГОСТ по РБПО:
"посредством проведения мероприятий по обеспечению защиты информации при использовании для функционирования информационных систем искусственного интеллекта должна быть обеспечена возможность исключения несанкционированного доступа к информации или воздействия на информационные системы, а также использования информационных систем не по их назначению за счет воздействия на наборы данных, применяемые модели искусственного интеллекта и их параметры, процессы и сервисы по обработке данных и поиску решений" - а как это сделать, вопрос.
Я бы сформулировал так и попросил поправить, ведь спор - путь к истине:
На основе системного анализа, подходов Clean Archiecture, Secure by Design, MultiAgent Architecture спроектировать классы приложений по сферам применения с использованием ИИ (где атомная станция и ИИ на разных полюсах).
Определить список рисков, выявленный натурными испытаниям на стендовых полигонах, а не просто «цифрами — эксперты так придумали».
Ввести постоянный мониторинг R&D в области AI и технологий атак для оперативного отслеживания изменений в данной отрасли. И написать правильные стандарты, пока машины не захватили мир. AGI ведь не за горами)
Список источников
Хорошего времени суток и жду ваших мнений.
