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

# Проверка и тестирование безопасности

{#security-testing}

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

## Подготовка области проверки {#test-preparation}

До начала проверки владелец предоставляет описание архитектуры из раздела [Введение](intro.md) с точными идентификаторами ресурсов, моделей, версий и субъектов. Отдельно прикладываются действующие исключения и разрешение на активные тесты, если они входят в область проверки.

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

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

## Порядок проверки одного требования {#single-requirement-check}

Проверяющий выполняет следующие действия:

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

Результат проверки требования фиксируется одним из статусов: «выполнено», «не выполнено», «не применимо» или «не проверено».

Статус «выполнено» допустим, только если наблюдаемое состояние совпадает с требуемым во всех применимых ветвях и нет необъясненного пути обхода, либо действует оформленное исключение по разделу [Исключения](intro.md#exceptions). Проверка части применимых ветвей не дает положительного вывода.

Требование не выполнено, если запрещенный субъект, поток или действие успешны, требуемая настройка отсутствует либо свидетельство относится не к тому ресурсу или версии.

Если хотя бы одна применимая ветвь осталась непроверенной, результат — «не проверено» с указанием непроверенной ветви и причины. Статус «не проверено» не засчитывается как выполнение и требует последующей проверки либо оформления исключения.

## Проверка конфигурации и IAM {#config-iam-check}

Конфигурационная проверка должна показывать фактические значения, а не только проектное описание. Для каждого профиля раздела [Профили реализации в Yandex Cloud](profiles.md) проверяются его десять полей, в том числе:

* активная версия, ревизия, дайджест образа, модельный комплект или индекс;
* публичность и конечные точки;
* VPC, подсети, группы безопасности, маршруты и сетевая политика, где они применимы;
* рабочий сервисный аккаунт;
* прямые и унаследованные привязки IAM;
* области API-ключа и срок или дата пересмотра;
* роли Kubernetes RBAC и внутренние права хранилища;
* ссылки на секреты без получения их значений;
* область трейла, фильтры сервисов, назначение журнала и срок хранения;
* правило алерта, канал уведомления и тест доставки.

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

Проверочные команды не должны изменять привязки, создавать ключи, развертывать ревизии или выводить секреты. Команда вроде `set-access-bindings`, которая заменяет весь набор привязок, не используется для диагностики.

## Проверка журналов и телеметрии {#logs-telemetry-check}

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

Минимальная запись результата содержит:

* идентификатор требования;
* дату и исполнителя проверки;
* точный ресурс и версию;
* проверенного субъекта;
* интерфейс или команду проверки;
* ожидаемый и наблюдаемый результат;
* ссылку на минимальное свидетельство;
* вывод с одним из статусов «выполнено», «не выполнено», «не применимо» или «не проверено» и, при необходимости, связанное исключение.

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

## Безопасные негативные и прикладные тесты {#negative-app-tests}

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

* вызов API без роли, с неподходящей областью ключа или от другого субъекта;
* разрешенная и запрещенная категория модерации и ошибка модератора по `AI-CONTENT1`;
* чтение загрузчиком утвержденного и постороннего источника, запись в промежуточную область и чужой индекс по `AI-RAG-INGEST1`;
* сопоставление прямых, групповых и унаследованных прав с датой и событием внепланового пересмотра по `AI-IAM5`;
* обращение к целевому сервису в обход API Gateway или MCP Gateway;
* сетевое соединение из запрещенного пространства имен или среды исполнения;
* RAG-поиск документа другой области доступа;
* прием набора с неверным объемом, метаданными, типом, чувствительным полем и его перевод в карантин или ручное рассмотрение по `AI-DATA-CHECK1`;
* модельный вывод с запрещенной командой или объектом;
* попытка через RAG-фрагмент или результат инструмента изменить цель агента;
* подмена пользователя, арендатора, ресурса или отозванной сессии в агентном делегировании по `AI-IAM-COMPROMISE1`;
* повтор межагентного сообщения, неизвестная версия схемы или бесконечный цикл;
* успешное и ошибочное защитное преобразование, попытка обхода и разделение обязанностей по `AI-COMPLY-PII3`;
* передача лишнего поля внешнему получателю;
* чтение отозванного секрета с учетом документированного кеша;
* закрытие старого эндпоинта, ключа и прямого пути после вывода из эксплуатации без удаления общих ресурсов.

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

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

## Активное тестирование (red teaming) {#red-teaming}

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

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

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

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

## Исправление, исключение и повторная проверка {#fix-exception-recheck}

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

Если исправление временно невозможно, применяется единый процесс исключения из раздела [Введение](intro.md). Исключение не меняет текст требования и не скрывает непроверенную ветвь.

Итоговый пакет проверки должен содержать:

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

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