Оценка ИБ-зрелости ИИ-систем: чек-лист аудита

На прошлогоднем аудите ML-пайплайна одной финтех-компании с вполне зрелым SOC - SIEM настроен, EDR раскатан, IR-playbooks отработаны - я обнаружил, что write-доступ к S3-бакету с обучающими данными имели 14 сервисных аккаунтов. Три из них привязаны к Jenkins-нодам, удалённым полгода назад. Общая ИБ-зрелость по NIST CSF - уверенный уровень 3. ИБ-зрелость ИИ-контура - едва дотягивала до единицы. Между этими двумя цифрами - слепая зона, которую ни один классический аудит не закроет.

Почему классическая оценка ИБ-зрелости не покрывает ИИ-контур​

Стандартные модели зрелости - NIST CSF Tiers, C2M2, методика ФСТЭК - проектировались для IT-инфраструктуры с предсказуемыми потоками данных и фиксированным периметром. ИИ-контур ломает обе аксиомы. Подробнее - в нашем руководстве по безопасность llm приложений.

Обучающие данные текут в pipeline из десятков источников, включая внешние API и пользовательский ввод. Веса модели - исполняемый артефакт, который меняет поведение системы без изменения кода. Inference-эндпоинты принимают произвольный текст и возвращают результат, сгенерированный вероятностной моделью, а не детерминированной логикой. Ни одна из этих особенностей не укладывается в классическую триаду "конфиденциальность - целостность - доступность" без серьёзных дополнений.

CSA в рамках AI Security Maturity Model (AISMM) формулирует тезис прямо: действующие playbooks безопасности не транслируются на ИИ-контур один к одному. AISMM выделяет несколько доменов, специфичных для ИИ, включая Model Security - категорию, у которой нет прямого аналога ни в облачной, ни в инфраструктурной безопасности.

Ряд отраслевых моделей зрелости ИИ-безопасности (в частности, SANS AI Security Maturity Model) используют принцип governance ceiling: общий балл зрелости не может превышать оценку governance-компонента более чем на одну ступень, а самозаявленные оценки без документального подтверждения автоматически ограничиваются. Конкретные параметры этого механизма требуют верификации по первоисточнику. На практике это значит: без AI-специфичных политик и процессов все технические меры защиты ML-пайплайна формально не засчитываются. Можно обвешаться WAF-ами и Sigma-правилами, но если нет AI Security Policy - на бумаге вы на единице.

Оценка ИБ-зрелости ИИ-систем - отдельная дисциплина. NIST выпустил AI Risk Management Framework (AI RMF 1.0) как самостоятельный документ с четырьмя функциями - GOVERN, MAP, MEASURE, MANAGE - именно потому, что AI-риски не покрываются одним лишь CSF. Функция MAP требует документировать контекст использования данных и модели. MEASURE - определить методы и метрики для оценки рисков ИИ, включая калибровку, fairness-метрики и тесты на устойчивость к adversarial inputs. MANAGE - приоритизировать риски и зафиксировать решения (accept/transfer/avoid). Без прохождения по этим функциям любая "оценка зрелости ИИ" - упражнение на бумаге.

Модель угроз для ИИ-систем: маппинг на MITRE ATT&CK​

Прежде чем запускать аудит, нужно понимать, что именно атакуют и зачем. Модель угроз для ИИ-систем отличается от классической: помимо стандартных векторов появляются специфические - отравление данных, кража весов, prompt injection.

Бизнес-логика атаки: украденные веса модели - интеллектуальная собственность стоимостью в месяцы GPU-вычислений. Отравленные данные позволяют манипулировать выходом модели в production. Prompt injection на inference API даёт доступ к данным, которые модель "видит" через RAG-контур. Каждый из этих векторов монетизируется иначе, чем классический RCE или SQLi.

MITRE ATT&CK уже включает техники, применимые к ИИ-контуру:

Insider threat в ИИ-контуре​

Отдельная боль - привилегированные инсайдеры. Data scientist с доступом к raw training data, model registry и production inference - три зоны риска в одном аккаунте. В большинстве компаний, которые я аудитировал, Jupyter Hub работает с единым сервисным аккаунтом, а разграничение доступа между проектами отсутствует. Один скомпрометированный ноутбук - и атакующий получает:

• read/write к обучающим данным (включая PII, если они не обезличены)
• push-доступ к model registry (можно подменить веса)
• токены к inference API в переменных окружения

Это не теоретический вектор. T1552.001 (Credentials In Files, Credential Access) описывает именно этот сценарий: учётные данные хранятся в файлах и ноутбуках, доступных легитимному пользователю. Скомпрометированный хост data scientist'а - один из самых опасных плацдармов в ИИ-контуре. Я видел это неоднократно: .env с production-токенами прямо в рабочей директории Jupyter, без .gitignore, без ротации.

Безопасность данных для обучения моделей: аудит и detection​

Контроль доступа к обучающим данным​

Первый домен аудита - данные. Согласно NIST AI RMF (функция MAP), контекст использования данных должен быть задокументирован: откуда данные, кто их собрал, какие категории ПДн содержатся, как обеспечена прослеживаемость (data lineage). На практике я проверяю пять контрольных точек:

1. Инвентаризация хранилищ. Перечислите все бакеты и хранилища с training data. Если не можете сделать это за 10 минут - уровень 1. Без вариантов.
2. IAM-политики. Кто имеет read/write доступ? Проверка через aws s3api get-bucket-policy или аналог. Ожидание: только pipeline-сервисный аккаунт имеет write, data engineer'ы - read по принципу least privilege.
3. PII-сканирование. Обучающие данные проверяются на наличие персональных данных перед загрузкой в pipeline? Если ИИ-система обрабатывает данные, подпадающие под ФЗ-152 (ст. 5 - соответствие способов обработки целям, ст. 7 - конфиденциальность), то отсутствие обезличивания - прямое нарушение.
4. Версионирование и lineage. Можно ли восстановить, на каких именно данных обучена конкретная версия модели? Без этого невозможно провести расследование инцидента с отравлением.
5. Ротация доступов. Сервисные аккаунты с доступом к training data ревьюятся ежеквартально? Те самые три Jenkins-аккаунта из моего аудита - результат отсутствия ротации.

Правила корреляции для SIEM​

Для детектирования аномального доступа к обучающим данным я настраиваю Sigma-правило:
Правило срабатывает, когда один IAM-principal делает более 500 GET-запросов к бакету с обучающими данными за час. Порог калибруется под baseline: штатный pipeline делает bulk read раз в сутки при переобучении, не каждый час. Если прилетает ночью - точно не pipeline.

Второй обязательный алерт - доступ к training data с нового IP или из нового региона. Корреляция стандартная, но её нужно явно настроить для ML-хранилищ, а не только для production-баз. ML-бакеты обычно остаются вне радара SOC, потому что их заводила research-команда, а не инфраструктурщики.

Защита весов моделей: аудит ML моделей​

Целостность артефактов в model registry​

Веса модели - исполняемый артефакт. Подмена весов через supply chain меняет поведение production-системы без изменения кода и без срабатывания SAST/DAST. Согласно OWASP A06:2021 (Vulnerable and Outdated Components), использование компонентов с неверифицированной целостностью создаёт критический риск. По сути, model registry - тот же артефакт-сервер, и к нему применяются те же принципы контроля доступа, что к Docker Registry или Nexus. Но почему-то про это забывают.

Контрольные точки аудита ML моделей:

• Каждая версия модели в registry имеет SHA-256 хэш? Проверяется ли хэш при деплое?
• Используется ли Sigstore/cosign или аналог для криптографической подписи модельных артефактов?
• Кто может запушить новую версию? В MLflow по умолчанию write-доступ к tracking server не ограничен - любой с сетевым доступом способен зарегистрировать модель. Просто так. Без авторизации.
• Фиксируются ли все операции: регистрация модели, переход между стадиями (staging -> production), удаление версий?
• Предобученные модели загружаются из верифицированных источников? Целостность артефактов с Hugging Face Hub и других Model Zoo проверяется перед использованием?

Detection: несанкционированный доступ к весам​

Ключевой алерт: загрузка модельного артефакта аккаунтом, не входящим в CI/CD pipeline. Если модель скачивает не deployment-сервис, а учётка data scientist'а в нерабочее время - это потенциальная эксфильтрация интеллектуальной собственности.
Результат покажет, кто и когда запрашивал URI для скачивания весов. Аномалия - запросы от IP, не принадлежащих deployment-инфраструктуре. Этот вывод подключается к SIEM как дополнительный источник событий.

Чек-лист аудита ИИ-инфраструктуры​

Сетевая сегментация и IAM​

Аудит инфраструктуры ИИ-контура начинается с сегментации. GPU-кластер для обучения, inference-сервисы и data pipeline - три зоны, которые надо изолировать друг от друга и от корпоративной сети. В реальных проектах эти три зоны чаще всего сидят в одном VPC - потому что "так проще для разработки". Проще - до первого инцидента.

Контрольные точки:

Мониторинг и логирование ИИ-контура​

OWASP A09:2021 (Security Logging and Monitoring Failures) прямо указывает: без логирования нарушения не детектируются. Для ИИ-контура это означает:

• Логирование всех API-вызовов к inference-эндпоинтам, не только ошибок
• Логирование операций с model registry (push, pull, stage transition)
• Логирование доступа к training data хранилищам
• Мониторинг дрейфа модели (model drift) - резкое изменение распределения предсказаний может указывать на отравление данных
• Алерты на аномальное потребление GPU: cryptomining на training-кластере - не экзотика, а регулярная находка на аудитах

Baseline для мониторинга строится по NIST CSF DE.AE-01: "Baseline of network operations and expected data flows for users and systems is established and managed.""Установлены и находятся под контролем базовые показатели сетевых операций, а также ожидаемые потоки данных для пользователей и систем." Без baseline любой алерт - шум. Для ML-пайплайна baseline включает: типичное время и частоту обучения, объём данных в batch, список аккаунтов, взаимодействующих с registry, паттерн запросов к inference API.

Методика оценки ИБ ИИ: пять уровней зрелости​

Объединяя подходы CSA AISMM и SANS AI Security Maturity Model, я использую рабочую шкалу для оценки рисков ИИ-систем. Оценка проводится по трём доменам: данные, модели, инфраструктура.


По логике governance ceiling, если governance (политики, ответственные, процессы) на уровне 1, то технические меры уровня 4 формально не засчитываются. Governance ceiling - не бюрократия ради бюрократии, а фиксация факта: без AI Security Policy и назначенного ответственного за кибербезопасность машинного обучения вся техника держится на конкретных людях и разваливается при смене команды. NIST AI RMF функция GOVERN прямо требует: политики, процессы и процедуры по управлению AI-рисками должны быть утверждены на уровне руководства.

Российский регуляторный контекст​

Если ИИ-система обрабатывает персональные данные (а большинство ML-моделей обучаются на данных с ПДн), в методику оценки ИБ ИИ включаются требования ФЗ-152: согласие на обработку (ст. 9), принцип минимизации (ст. 5), обеспечение конфиденциальности (ст. 7). Для обучающих датасетов это означает: если PII попадает в training data без обезличивания, оператор нарушает закон вне зависимости от того, насколько хорошо защищён периметр. Периметр может быть идеальным - а нарушение уже внутри.

Если ИИ-система входит в состав объекта КИИ (финтех, здравоохранение, транспорт), применяются требования ФЗ-187 (ст. 11) и Приказа ФСТЭК №239 с группами мер ИАФ/УПД/АУД/РСБ, которые маппируются на компоненты ML-пайплайна. Приказ ФСТЭК №117 уже двигается от вопроса "есть ли у вас меры" к вопросу "насколько они эффективны и можете ли вы это доказать" - а это и есть логика оценки зрелости.

Экспресс-аудит ИИ-контура за 30 минут: сводный чек-лист​

Для быстрой оценки текущего уровня ответьте на вопросы по каждому домену. Три и более «нет» в одном домене - уровень 1-2.

Данные:

• Перечислите все хранилища с обучающими данными за 10 минут - получилось?
• PII-сканирование данных проводится перед загрузкой в pipeline?
• Есть data lineage: по какой версии данных обучена конкретная версия модели?
• IAM-политики на training data хранилища ревьюятся ежеквартально?
• Bulk-доступ к обучающим данным логируется с алертами в SIEM?

Модели:

• Model registry с RBAC развёрнут (не файловая шара, не общий NFS)?
• Модельные артефакты хэшируются при регистрации?
• Все операции с registry логируются (push, pull, stage transition)?
• Есть процедура верификации предобученных моделей из внешних источников?
• Мониторинг дрейфа модели настроен с алертами?

Инфраструктура:

• IMDS на GPU-нодах ограничен (v2 only, hop limit = 1)?
• Inference API защищён аутентификацией и rate limiting?
• WAF с правилами для prompt injection на inference-эндпоинтах настроен?
• Jupyter-серверы изолированы в отдельном сетевом сегменте?
• Baseline и алерты на аномальное потребление GPU есть?

Если на пять и более вопросов из пятнадцати ответ "нет" или "не знаю" - ИБ-зрелость ИИ-контура ниже уровня 3, и начинать стоит с инвентаризации хранилищ и ревизии IAM, а не с governance-документов.

Большинство российских компаний, внедряющих ML в production, находятся на уровне 1 AI-security maturity при общей ИБ-зрелости 2-3. Разрыв объясним: ML-команды формировались как research-подразделения, а не как часть IT-инфраструктуры, и ИБ-отдел узнаёт об очередном deployment модели постфактум. Мой опыт аудитов показывает: самая частая находка - не adversarial-атаки на модели, а банальщина. Открытые бакеты с обучающими данными. API-ключи в .env файлах Jupyter-ноутбуков. Model registry без аутентификации.

Это не вопрос AI security в академическом смысле - это базовая гигиена, которую ML-инфраструктура систематически пропускает. Data scientist'ы не думают категориями IAM и сегментации, а security-инженеры не понимают, что model registry - тот же артефакт-сервер. Начинать стоит не с adversarial testing и не с покупки AI-SPM - начинать стоит с aws s3api get-bucket-policy на бакете с training data. Результат этой единственной команды расскажет о зрелости ИИ-контура больше, чем любой опросник. На codeby.net держим тред по мониторингу ML-инфраструктуры и detection в ИИ-контурах - если начинаете выстраивать эту часть SOC, там разбираем конкретные правила корреляции и свежие кейсы.