[Документация Yandex Cloud](../../index.md) > [Безопасность в Yandex Cloud](../index.md) > Стандарт безопасности для внедрения и эксплуатации ИИ-систем в Yandex Cloud, версия 1.0.0 > Мониторинг и реагирование на инциденты

# Мониторинг и реагирование на инциденты

{#monitoring-incident-response}

Наблюдаемость ИИ-системы состоит из трех слоев: облачные события управления и отдельных операций, эксплуатационные метрики среды исполнения и прикладная трассировка модельного или агентного запроса. Их связь и сигналы для расследования проверяются по `AI-MON-ANOMALY2` и `AI-MON-TRACE1`.

## Сигналы и оповещения {#signals-alerts}

### Нетипичное использование API и ресурсов обнаруживается {#atypical-api-resource-usage-detected}

{#ai-mon-anomaly2-id}

Идентификатор требования: `AI-MON-ANOMALY2`

{#ai-mon-anomaly2-requirement}

**Требование**

Организация должна определить наблюдаемые признаки злоупотребления для своего сценария: всплеск вызовов модели или инструментов, необычный расход, повторяющиеся отказы политик, изменение объема исходящего трафика, исчерпание ресурсов, нетипичную активность GPU или резкое изменение ошибок и задержки. Для каждого сигнала задаются источник, окно наблюдения, ответственный канал и ожидаемое действие.

Для агентного слоя дополнительно наблюдаются решения по извлечению данных и инструментам, сессии MCP и длительность работы инструментов.

Для каждого правила фиксируются точная метрика или событие, метки ресурса, запрос и порог, назначение и владелец.

{#ai-mon-anomaly2-implementation}

**Реализация**

Yandex Monitoring позволяет строить запросы и алерты по доступным метрикам; [алерт](../../monitoring/concepts/alerting/alert.md) оценивает условие и отправляет уведомление, но сам по себе не останавливает нагрузку. [Бюджеты Yandex Cloud Billing](../../billing/operations/budgets.md) могут дополнять контроль расходов, но не показывают число и характер модельных вызовов.

Yandex Cloud Detection and Response находится на стадии Preview; доступ к разделу в Security Deck предоставляется после одобрения запроса. Сервис может использоваться как дополнительный источник, если доступ получен, для облака развернут отдельный коллектор и нужный сигнал действительно поступает по документированному TLS-пути. Условия и архитектура описаны в [документации YCDR](../../ycdr/concepts/index.md).

Семейство сервисных ролей `ycdr.admin` — единственное документированное для YCDR; оно не назначается шире необходимого.

{#ai-mon-anomaly2-check}

**Проверка**

Для каждого правила сформируйте безопасный тестовый сигнал и подтвердите срабатывание алерта, доставку в нужный канал и регистрацию действия ответственного. Значения порогов и периодичность утверждает организация; стандарт не задает универсальных чисел. Оповещение должно прийти владельцу с идентификаторами ресурса и корреляции. Отдельная отрицательная проверка подтверждает, что отсутствующий или отключенный маршрут оповещения обнаруживается.

{#ai-mon-anomaly2-artifacts}

**Артефакт**

* Конфигурация алерта.
* Тест доставки.
* Регистрация действия ответственного.
* Идентификаторы дашборда и оповещения.
* Временная шкала события.
* Тикет реагирования.

## Сквозная прикладная трассировка {#end-to-end-trace}

### Модельный и агентный запрос прослеживается без избыточного содержимого {#model-agent-request-traced-no-excess-content}

{#ai-mon-trace1-id}

Идентификатор требования: `AI-MON-TRACE1`

{#ai-mon-trace1-requirement}

**Требование**

Приложение должно присваивать запросу идентификатор корреляции (correlation ID). Общая запись содержит время, проверенную идентичность или обезличенный идентификатор субъекта, рабочую идентичность вызывающего компонента, целевой ресурс или эндпоинт, версию модели и конфигурации, идентификаторы RAG-источников, результат входной и выходной политики, технический исход, код ошибки и длительность.

Для агента дополнительно записываются шаг, выбранный инструмент, проверка полномочий, запрос подтверждения человека и результат бэкенда.

Идентификаторы платформенных запросов сопоставляются с прикладным идентификатором в карточке корреляции и не считаются тождественными ему.

Полные промпты, ответы, диалоги и скрытые рассуждения модели не являются обязательным минимумом и не должны собираться только ради соответствия. Если облачный сервис не публикует нужное событие уровня данных, приложение обязано сформировать запись само. Cloud Functions и Serverless Containers передают журналы запросов и stdout/stderr в Cloud Logging в пределах документированной модели: [логи Cloud Functions](../../functions/concepts/logs.md), [логи Serverless Containers](../../serverless-containers/concepts/logs.md).

{#ai-mon-trace1-check}

**Проверка**

Выполните запрос, включающий RAG и вызов тестового инструмента, и восстановите путь от входа до результата. В трассировке должны быть видны решения политики и технические исходы, но отсутствовать секреты и неутвержденные данные. Отдельный отрицательный тест: пропавший или неверно сопоставленный идентификатор делает проверку покрытия невыполненной.

{#ai-mon-trace1-artifacts}

**Артефакт**

* Сквозная трассировка от входа до результата.
* Отсутствие секретов.
* Сопоставление идентификаторов платформы и приложения.

### Каждая итерация агентного цикла связана с задачей и действием {#agent-loop-iteration-linked-to-task-action}

{#ai-mon-trace2-id}

Идентификатор требования: `AI-MON-TRACE2`

{#ai-mon-trace2-applicability}

**Применимость**

Требование применяется, если система выполняет многошаговый агентный цикл.

{#ai-mon-trace2-requirement}

**Требование**

Для каждой итерации сохраняются идентификаторы задачи и сессии, номер шага, выбранный инструмент, параметры, переданные после редактирования, проверка полномочий, результат или код ошибки и решение продолжить, остановить либо запросить подтверждение. Если оркестратор сам создает план или подцель, записываются их идентификатор и версия; стандарт не требует сохранять скрытые рассуждения модели.

При использовании MCP элементы Responses `mcp_call`, `mcp_approval_request` и `mcp_approval_response` связываются с событиями Audit Trails `mcp_hub.StartMcpSession`, `mcp_hub.ListMcpTools` и `mcp_hub.InvokeMcpTool` и с отдельным событием целевой системы; ни одна из этих записей сама по себе не доказывает побочный эффект в целевой системе, а отдельное событие подтверждения в справочнике Audit Trails не опубликовано.

При наличии доступных метрик можно дополнительно записывать время и расход ресурсов шага. Запись должна быть связана с `AI-MON-TRACE1`, но не содержать секреты, полные регулируемые данные или неутвержденное содержимое.

{#ai-mon-trace2-check}

**Проверка**

1. Выполните сценарий из нескольких шагов с одним успешным и одним отклоненным вызовом инструмента.
1. Восстановите порядок действий, активную версию плана при ее наличии, решение авторизации, ошибку и условие остановки по единому идентификатору задачи.

Отсутствие итерации или подтверждения эффекта в целевой системе означает невыполнение.

{#ai-mon-trace2-artifacts}

**Артефакт**

* Трассировка многошагового сценария с успешным и отклоненным вызовом.
* Версия конечного автомата задачи.
* Запись подтверждения.
* Событие целевой системы.

## Сохранность материалов расследования {#forensic-preservation}

### Архив содержимого диалога имеет утвержденный объем и контролируемый доступ {#dialog-archive-approved-scope-controlled-access}

{#ai-forensic2-id}

Идентификатор требования: `AI-FORENSIC2`

{#ai-forensic2-applicability}

**Применимость**

Требование применяется, если полное или частичное содержимое диалога сохраняется для расследования, качества, поддержки или иной утвержденной цели. Если сохраняются только минимальные криминалистические события без содержимого, для ветви необработанного содержимого результат `N/A` допустим со ссылкой на решение.

{#ai-forensic2-requirement}

**Требование**

Решение о хранении должно определить состав сообщений и изменений контекста, цель, правовое основание, срок, место хранения, владельца и круг читателей. Архив отделяется от обычных прикладных журналов, шифруется средствами выбранного хранилища и не используется как обязательный источник там, где достаточно метаданных из `AI-MON-TRACE1`.

Чтение и экспорт архива должны фиксироваться сервисом или приложением в пределах доступной телеметрии.

По умолчанию архив содержит идентификаторы, версии и решения, а не содержимое; глобальный сбор диалогов на случай возможного будущего инцидента не включается. Архив изолируется по делу, а читатели продуктивных журналов и расследователи разделяются.

{#ai-forensic2-check}

**Проверка**

1. Сопоставьте одну сохраненную сессию с утвержденным составом и сроком.
1. Выполните разрешенное и запрещенное чтение, проверьте событие чтения или прикладную запись и удаление тестовой сессии по окончании срока.

Если платформа не публикует событие чтения, эта слепая зона и компенсирующая запись должны быть указаны явно. Расследователь другого дела не должен получить доступ к объекту проверяемого дела.

{#ai-forensic2-artifacts}

**Артефакт**

* Сохраненная сессия.
* Тест разрешенного и запрещенного чтения.
* Область дела.
* Результат удаления или запрета на удаление.

### Материалы расследования защищены от незаметного изменения {#forensic-materials-protected-from-tampering}

{#ai-forensic3-id}

Идентификатор требования: `AI-FORENSIC3`

{#ai-forensic3-requirement}

**Требование**

Журналы и выгрузки, используемые для расследования, должны храниться отдельно от рабочих администраторов исследуемой системы. Права записи, чтения и удаления разделяются; время, источник и целостность записи должны проверяться. Срок хранения устанавливается утвержденной политикой и правовыми требованиями.

{#ai-forensic3-implementation}

**Реализация**

Для защищенного назначения Audit Trails можно использовать рекомендации [по журналам аудита](../standard/audit-logs.md).

В Object Storage версионирование и [Object Lock](../../storage/concepts/object-lock.md) могут поддерживать неизменяемость при корректной настройке, но бессрочное удержание и срок хранения требуют отдельного управления.

Идентичности записи и чтения разделяются; манифест хешей и выгрузка ссылаются на точную версию объекта. Object Lock включается только после согласования хранения: защищенные им данные могут стать неудаляемыми.

{#ai-forensic3-check}

**Проверка**

Выберите сохраненный инцидент, проверьте цепочку от исходной записи до архива, эффективные права и возможность обнаружить изменение. Рабочий администратор приложения не должен единолично изменять или удалять единственную копию. Разрешенная попытка изменить или удалить защищенный синтетический объект должна вести себя согласно режиму блокировки; восстановленная версия сверяется по хешу.

{#ai-forensic3-artifacts}

**Артефакт**

* Права на журналы.
* Тест изменения единственной копии.
* Конфигурация бакета, политик, ACL, версионирования, блокировки и шифрования.
* Версия и хеш объекта.

## Порядок реагирования {#response-procedure}

Для выполнения `AI-MON-ANOMALY2` и `AI-FORENSIC3` используется следующий порядок:

1. Установить затронутые модели, данные, идентичности, инструменты и получателей.
1. Ограничить последствия — остановить опасный маршрут или инструмент, отозвать ключ, сузить привязку либо перевести конечную точку в безопасный режим.
1. Сохранить минимально необходимые материалы расследования.
1. Устранить причину в данных, политике, конфигурации, коде или доступах.
1. Повторить исходную и связанную негативную проверку.
1. Вернуть сервис только после документированного решения.

Действия должны учитывать риск потери данных и возможность отката. Изоляция инцидента не должна без проверки уничтожать единственные материалы расследования.