Рекомендации ИБ: Этап 0 - Проектирование ML-системы
Рекомендации ИБ: Этап 0 - Проектирование ML-системы
Версия: 2.0 · Обновлено: 2026-04-23 · Теги: system design, PIA, data classification, threat modeling, STRIDE-AI, MITRE ATLAS · Tier: 1-4
TL;DR. Проектирование ML-системы с требованиями ИБ: Data Classification K0-K4, Privacy Impact Assessment, Tiering (Tier 1-4), Threat Model (STRIDE-AI + MITRE ATLAS) на входе в разработку. Этап 0 определяет 80% стоимости обеспечения безопасности на всём жизненном цикле: ошибка в дизайне дороже в 10-100 раз, чем её предотвращение до первой строчки кода.
Навигация по главе:
- Разделы 1-3: архитектурный фундамент и требования ИБ
- Раздел 4: шаблон Security Design Review (SDR)
- Разделы 5-6: чек-лист и типичные ошибки
- Раздел 7 (новый): интерактивные сценарии проектных атак
- Разделы 9-10: российская специфика, tier, PET, K0-K4
- Раздел 11 (новый): "С чего начать по вашей роли" - 7 ролей × Day 1 / Week 1 / Month 1
1. Краткое содержание этапа
Последовательность проектных артефактов
flowchart LR
BIZ["Бизнес-постановка<br/>задачи"] --> DC["Data Classification<br/>K0-K4"]
DC --> PIA["Privacy Impact<br/>Assessment"]
PIA --> TIER["Model Tier<br/>1-4"]
TIER --> TM["Threat Model<br/>STRIDE-AI / OWASP"]
TM --> ARCH["Архитектура<br/>+ topology + trust boundaries"]
ARCH --> SEC["Security requirements<br/>RBAC / encryption / logging"]
SEC --> POL["Политики<br/>IR / retention / use"]
POL --> GO{"Gate:<br/>готов к Stage 1?"}
GO -- yes --> S1[Data Ops]
GO -- no --> TM
Кто-с-кем-когда: диалог проектного контура
sequenceDiagram
participant PO as Product Owner
participant ML as ML-архитектор
participant SEC as SecOps
participant Юрист as Юрист
participant BOARD as AI Risk Committee
PO->>ML: Бизнес-задача + ожидания
ML->>SEC: Kick-off, запрос на Threat Model
SEC->>Юрист: Опрос по PII / K3-данным
Юрист-->>SEC: Правовой режим, требования DPIA
SEC->>ML: STRIDE-AI + MITRE ATLAS маппинг
ML->>ML: Выбор архитектуры (RAG / fine-tune / гибрид)
ML->>SEC: Draft SDR + data flow
SEC->>SEC: Security Review + gaps
SEC-->>ML: Recommendations + red flags
alt Tier 1-2
ML->>BOARD: Запрос на утверждение tier
BOARD-->>ML: Tier зафиксирован (signed)
BOARD->>Юрист: Инициирует DPIA
else Tier 3-4
ML->>SEC: Self-service approval
end
SEC->>PO: Gate 0 - passed / blocked
PO->>PO: Decision: proceed to Stage 1 or rework
Диаграмма показывает, что на этапе 0 нет одного «главного» документа - есть последовательность согласованных решений между бизнесом, инженерами, ИБ и регуляторной функцией. Пропустить любую стрелку нельзя: отсутствие Юрист на ранних шагах почти гарантированно приводит к переделке датасета после начала обучения.
Живая карта пути артефакта от бизнес-задачи до Gate 0
Этап 0 (ML System Design) является фундаментальным для обеспечения безопасности всего жизненного цикла ML-системы. На данном этапе закладываются архитектурные решения, определяются требования безопасности и формируются политики, которые будут действовать на протяжении всех последующих этапов - от сбора данных до вывода модели из эксплуатации.
Ключевые направления работы на этапе проектирования:
Моделирование угроз и оценка рисков. Определение специфических угроз для выбранного типа модели. Каждый тип модели имеет характерный профиль уязвимостей: LLM подвержены prompt injection и jailbreak-атакам, CNN уязвимы к adversarial examples и backdoor-атакам через отравление обучающих данных, рекомендательные системы - к data poisoning и model inversion.
Анализ и классификация данных. Систематическая оценка данных, используемых для обучения и инференса: выявление персональных данных (PII/PD), определение требований к шифрованию (at rest, in transit), обеспечение целостности датасетов, определение политик хранения и удаления.
Формирование требований безопасности и политик. Определение политик управления доступом (RBAC/ABAC), требований к шифрованию, стратегии мониторинга и логирования, процедур реагирования на инциденты (Incident Response), связанных с ML-компонентами.
Архитектура и выбор технологий. Проектирование архитектуры с учётом принципов изоляции (network segmentation, container isolation), безопасности цепочки поставок (supply chain security), управления секретами (HashiCorp Vault), версионирования экспериментов и моделей (MLflow).
Интеграция с CI/CD и MLOps. Встраивание проверок безопасности в пайплайны непрерывной интеграции и доставки: IaC-сканирование (Checkov), защита веток репозитория (protected branches), использование MLflow Tracking и Model Registry для обеспечения прослеживаемости.
Распределение ролей и ответственности. Чёткое определение зон ответственности между ML-архитекторами, DevOps/MLOps-инженерами, SecOps, Product Owner и Compliance-специалистами.
Почему этот этап критически важен для ИБ: ошибки, допущенные на этапе проектирования, многократно усиливаются на последующих этапах. Стоимость исправления уязвимости, заложенной в архитектуру, на порядки превышает стоимость её предотвращения на этапе дизайна. По аналогии с классической разработкой ПО, принцип «shift left» в ML-безопасности означает перенос максимального объёма проверок и решений на самый ранний этап.
2. Верификация фактов и инструментов
В данном разделе приведена верификация инструментов и методологий с точки зрения их актуальности и корректности применения.
2.1. Checkov (IaC Scanning)
| Параметр | Значение |
|---|---|
| Статус | Актуален, активно развивается |
| Лицензия | Apache License 2.0 |
| Встроенные политики | 750+ встроенных политик для Terraform, CloudFormation, Kubernetes, Helm, ARM templates, Serverless framework |
| Поддерживаемые платформы | AWS, Azure, GCP, Kubernetes, Docker, GitHub Actions |
| Применимость к ML | Подходит для сканирования IaC-конфигураций ML-инфраструктуры (кластеры GPU, хранилища данных, сетевые политики) |
| Рекомендация ИБ | Рекомендован к использованию. Следует дополнить кастомными политиками, специфичными для ML-инфраструктуры (например, проверка конфигурации GPU-инстансов, настроек объектного хранилища для датасетов) |
2.2. Методологии моделирования угроз
| Методология | Верификация |
|---|---|
| STRIDE | Корректная и широко применяемая методология для моделирования угроз. Для ML-систем рекомендуется расширенный вариант STRIDE-AI, учитывающий специфику ML (model evasion, data poisoning, model stealing) |
| MITRE ATLAS | Актуальная база знаний по тактикам и техникам атак на ML-системы. Версия 2025 года содержит обновлённый каталог техник, включая атаки на LLM и генеративные модели. Рекомендуется использовать совместно с MITRE ATT&CK для полноты покрытия |
| PASTA | Process for Attack Simulation and Threat Analysis - применима для ML-систем, особенно на этапе оценки бизнес-рисков |
| Attack Trees | Классическая методология, эффективна для визуализации сценариев атак на ML-пайплайны |
2.3. MLflow
| Параметр | Значение |
|---|---|
| Статус | Актуален, стабильная ветка 2.x |
| Компоненты | Tracking, Projects, Models, Model Registry |
| Применимость к ИБ | MLflow Tracking обеспечивает прослеживаемость экспериментов; Model Registry - контроль версий моделей и управление стадиями (Staging, Production, Archived) |
| Рекомендация ИБ | Рекомендован к использованию с обязательной настройкой аутентификации (MLflow 2.x поддерживает встроенную аутентификацию), шифрования хранилища артефактов и интеграцией с корпоративным IdP |
| Важные замечания | По умолчанию MLflow Tracking Server не требует аутентификации - это необходимо исправить при развёртывании. Рекомендуется использовать MLflow за reverse proxy с TLS |
2.4. Microsoft AI Security Risk Assessment
| Параметр | Значение |
|---|---|
| Статус | Обновлён в 2025 году |
| Назначение | Фреймворк для оценки рисков безопасности AI/ML-систем |
| Применимость | Рекомендуется использовать как дополнительный инструмент оценки рисков наряду с MITRE ATLAS. Полезен для структурирования диалога между командами ИБ и ML |
2.5. Дополнительные инструменты
| Инструмент | Верификация и рекомендация |
|---|---|
| pip-audit | Актуален, поддерживается Python Packaging Authority (PyPA). Проверяет зависимости Python по базе OSV. Рекомендован для ML-проектов на Python |
| Safety | Актуален (Safety CLI). Проверяет Python-зависимости по базе уязвимостей Safety DB. Рекомендуется использовать совместно с pip-audit для полноты покрытия |
| HashiCorp Vault | Актуален. Рекомендован для управления секретами в ML-пайплайнах (API-ключи к данным, креды к Model Registry, токены облачных провайдеров). Поддерживает динамические секреты, что критично для короткоживущих ML-задач |
| Prometheus + Grafana | Актуальный стек мониторинга. Для ML рекомендуется дополнить метриками специфичными для моделей (drift detection, prediction latency, confidence distribution) |
| ELK Stack | Актуален (Elasticsearch, Logstash, Kibana). Подходит для централизованного логирования ML-пайплайнов. Рекомендуется настроить индексы и дашборды, специфичные для ML-событий |
Дальше — практика и артефакты
Полная версия главы «Рекомендации ИБ: Этап 0 - Проектирование ML-системы» с готовыми артефактами, шаблонами, чек-листами и подробными процедурами доступна по подписке.
- Полный доступ ко всем главам и обновлениям 30 дней
- Готовые playbook'и, шаблоны и runbook'и под копирование
- Поддержка автора — paywall не для заработка, а для развития справочника
Можно отменить в любой момент. Возврат средств в первые 7 дней без вопросов.
Упоминается в (6)
- Рекомендации ИБ: Обзор и Архитектура ML SecOps
- Рекомендации ИБ: Этап 1 - Операции с данными (Data Operations)
- Governance: Model Risk Management, AI-BOM, AI Use Policy
- MLSec Recommendations. Индекс документов
- Российская специфика MLSec. Deep Dive
- Внедрение MLSec и AI Security в российских компаниях. Практический плейбук