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

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

Подготовка области проверкиПодготовка области проверки

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

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

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

Порядок проверки одного требованияПорядок проверки одного требования

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

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

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

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

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

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

Проверка конфигурации и IAMПроверка конфигурации и IAM

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

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

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

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

Проверка журналов и телеметрииПроверка журналов и телеметрии

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

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

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

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

Безопасные негативные и прикладные тестыБезопасные негативные и прикладные тесты

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

• вызов 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)

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

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

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

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

Исправление, исключение и повторная проверкаИсправление, исключение и повторная проверка

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

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

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

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

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