Sirius Argus: безопасность внутри ML-пайплайна
Мой архитектурный вклад в Sirius Argus: жизненный цикл ML-модели, единая точка выпуска, ручной гейт и реальные экраны публичного проекта.
Задача
Sirius Argus начался как финальный командный проект программы «Безопасность технологий ИИ: от разработки до эксплуатации» Сириус × Альфа-Банк. Работу над кейсом начали 1 июня 2026 года; финальная защита прошла 6 июня.
Задача — связать безопасность с жизненным циклом модели: подготовкой данных, обучением, хранением артефактов, выпуском и эксплуатацией. Набор отдельных сканеров сам по себе не даёт ответа, какую модель можно выпускать и кто за это решение отвечает.
В учебном кейсе рассматривали закрытый контур банка и поступление внешней модели, например с Hugging Face. Архитектурная цель — проверить артефакт до выпуска, связать находки с решением об одобрении и сохранить контроль при дальнейшей работе с моделью.
Ключевой вопрос для меня был таким: если модель прошла проверку, как убедиться, что в эксплуатацию отправили именно этот артефакт, а решение принял человек с подходящими полномочиями? Это связывает ML security с обычными задачами backend: идентичностью объектов, авторизацией действий и историей изменений.
Архитектурная идея
В основе Argus — единая точка управления выпуском. Модель проходит через контрольную плоскость, где проверяются доступ, результаты проверок и условия релиза.
Защита распределена по четырём направлениям: обнаружение активов, безопасность цепочки поставок, валидация модели и контроль в эксплуатации.
В текущем публичном проекте центральный сервис связывает версии, результаты сканов и решения о выпуске. Реестр и объектное хранилище находятся за ним; долгие проверки вынесены в очередь. Это позволяет подключать отдельные инструменты и сохранять общий контракт действий. Обзор проекта.
| Компонент | Ответственность |
|---|---|
| Control plane на FastAPI | Проверка прав, управление гейтами и реестрами, общий интерфейс |
| MLflow и MinIO | Версии моделей и хранение артефактов |
| PostgreSQL | Связи активов, находки, решения и аудит |
| Redis | Очередь сканирования и доставка событий |
Разделение компонентов и сетевые границы описаны в архитектуре проекта.
Моя роль
Мой вклад в команде был сосредоточен на архитектурном предложении:
- концепция Zero Trust и единой точки входа;
- ролевая модель и разграничение доступа по чувствительности данных;
- подход к аудиту моделей и анализу угроз;
- помощь с презентацией и координация предзащит.
Предлагал рассматривать контур разработки и контур эксплуатации отдельно: у них разные пользователи, активы и способы воздействия на модель. При этом между ними должен быть проверяемый переход с контролем версии и прав доступа.
Архитектуру обсуждали с куратором и уточняли к защите. 1 июня начали работу над кейсом, 3 июня провели первую предзащиту, 5 июня — вторую, 6 июня — финальную. Техническая реализация платформы — общий результат команды.
Как проверки связаны с выпуском
Реестр хранит модели, версии и связанные активы. Сканирование создаёт находки, привязанные к этим активам. Перед выпуском система проверяет политики; для критичных версий требуется решение человека.
Так можно проследить путь конкретного артефакта: от поступления и проверки до одобрения и развёртывания. Важна и связь решения с версией модели: разрешение на один артефакт не должно автоматически разрешать другой.
В публичной реализации для критичной версии проверяются модель-карта, воспроизводимость, подпись и открытые критические находки. Одобрение выполняет другой специалист MLSecOps: автор запроса не должен сам разрешать свой выпуск. Решение связано с хешем артефакта. Сценарии проверки ручного гейта.
Подпись подтверждает происхождение и целостность артефакта. Поведенческие свойства модели требуют своих проверок: даже корректно подписанная версия может содержать нежелательную логику. Поэтому подпись используется вместе со сканированием и валидацией. Это различие закреплено в решении о подписи и провенансе.
Как показать работу защиты
Для демонстрации важен наблюдаемый результат: отказ операции, находка, запись аудита и изменение состояния версии. В проекте такие ожидания оформлены как сценарии.
| Проверка | Ожидаемое поведение |
|---|---|
| Опасный сериализованный артефакт | Блокируется до десериализации, создаётся критическая находка |
| Критичная версия без одобрения | Выпуск остаётся заблокирован |
| Действие вне полномочий роли | Отказ в доступе и запись события |
| Серия запросов, похожая на extraction | Ограничение запросов и находка в общем контуре |
Эти случаи описаны в каталоге BDD-сценариев. Они дают проверяемые условия для конкретных угроз, но не обещают обнаружение любой атаки.
Для проверки контур поднимается локально через Docker Compose. make demo прогоняет отдельные защитные сценарии, а make pipeline ведёт одну модель через приём, сканирование, согласование, выпуск, рантайм-проверку и вывод из эксплуатации. Команды и условия запуска приведены в руководстве проверяющему.
Результат и дальнейшая работа
Командный проект был защищён в Сириусе. Сейчас его устройство и продолжение разработки доступны в публичном репозитории Sirius Argus.
После учебной защиты разработка продолжилась в публичном репозитории. В демо используются три негенеративные sklearn-модели на наборе iris. Подробнее о текущем состоянии — в README.
Этот опыт связал для меня backend, архитектуру доступа и ML security: безопасность стала частью процесса принятия решений о модели.
Отбор и программа MLSecOps · Сертификат ДПО
Материалы: программа в ГУАП · фотоальбом Киберполигона ГУАП · карта пайплайна · ручной гейт из репозитория Георгия Мамарина (dmagog).
