Среда исполнения, RAG-хранилища и вывод из эксплуатации

Среда исполнения определяет, какие процессы делят узлы и сеть, где хранится состояние, как приложение получает секрет и какие журналы создаются автоматически. Managed Service for Kubernetes, Serverless Containers, Cloud Functions, Compute Cloud, DataSphere и управляемые API имеют разные модели. Требование считается выполненным только для фактически используемой среды.

Владелец указывает применимую ветку:

• для управляемого API AI Studio не заявляется контроль ОС или узла; проверяются вызывающее приложение, его идентичность, вход/выход, данные и внешнее состояние;
• для DataSphere границами служат сообщество, проект, задание или узел, его сервисные идентичности, сеть и внешние ресурсы;
• для Managed Service for Kubernetes отдельно проверяются Identity and Access Management, Kubernetes RBAC, пространства имен, поды, узлы и сеть;
• для Serverless Containers и Cloud Functions учитываются соответственно ревизия или версия, рабочий сервисный аккаунт, повторное использование экземпляра и внешнее состояние;
• для Compute Cloud организация отвечает за ВМ, ОС, процесс, модельный загрузчик и агент телеметрии;
• для внешнего модельного API применяется профиль локальной среды исполнения вместе с отдельной границей исходящего трафика, внешними учетными данными и получателем.

Точные роли, объекты конфигурации и способы проверки приведены в разделе Профили реализации в Yandex Cloud.

Изоляция среды исполненияИзоляция среды исполнения

Независимые нагрузки и арендаторы изолированыНезависимые нагрузки и арендаторы изолированы

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

Требование

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

Реализация

В Managed Service for Kubernetes используются отдельные пространства имен и ресурсы типа ServiceAccount, Kubernetes RBAC, сетевая политика и ограничения подов. IAM-доступ к кластеру и Kubernetes RBAC являются разными слоями; рекомендации приведены в руководстве по безопасности Kubernetes и документации управления доступом.

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

Serverless Containers и Cloud Functions изолируют управляемую среду в пределах опубликованной модели, но код приложения по-прежнему отвечает за разделение данных арендаторов и состояние между запросами.

В Compute Cloud организация отвечает также за ОС, процессную изоляцию и доступ к метаданным ВМ.

Даже при одном арендаторе разделяются среды разработки, тестирования и продуктивной эксплуатации. Фактическая единица изоляции фиксируется явно: кластер, группа узлов или пространство имен, проект DataSphere, ресурс Function или Container, ВМ, каталог, сеть либо ресурс управляемого сервиса вместе с прикладным правилом для арендатора.

Проверка

1. Создайте два тестовых субъекта или арендатора и попытайтесь обратиться к файлу, секрету, кешу и эндпоинту другого.
2. Для Kubernetes дополнительно проверьте IAM, RoleBinding/ClusterRoleBinding, сетевую политику и размещение нагрузки.
3. Для бессерверной среды проверьте ключи разделения арендаторов в каждом внешнем хранилище.

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

Артефакт

• Тест доступа к чужому файлу, секрету, кешу, эндпоинту.
• Топология и карта ресурсов и арендаторов.

Состояние между независимыми задачами не сохраняется по умолчаниюСостояние между независимыми задачами не сохраняется по умолчанию

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

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

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

Требование

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

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

Serverless Containers и Cloud Functions предоставляют управляемый жизненный цикл экземпляров, но приложение не должно считать завершение отдельного запроса гарантированным уничтожением экземпляра. Для Kubernetes и Compute Cloud граница процесса, подов, ВМ или отдельного рабочего каталога определяется архитектурой. Завершение бессерверной ревизии или перезапуск подов сами по себе не доказывают очистку состояния приложения; состояния задания и ноутбука DataSphere различаются.

Проверка

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

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

Артефакт

• Синтетический маркер.
• Недоступность после завершения задачи.
• Карта состояния со сроками жизни.
• Событие очистки.

Исполнение кода, команд и динамических запросов ограниченоИсполнение кода, команд и динамических запросов ограничено

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

Требование

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

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

При отсутствии таких путей исполнения результат N/A допустим только вместе с инвентаризацией точек исполнения. Для SQL применяются параметризованные запросы и политика запросов.

Реализация

Для Kubernetes ограничения реализуются настройками безопасности пода и контейнера, RBAC, сетевой политикой и ресурсными лимитами в пределах руководства по безопасности Kubernetes.

Для Serverless Containers и Cloud Functions необходимо учитывать лимиты и свойства конкретной ревизии или версии из профиля Среда исполнения в Serverless Containers или Cloud Functions. Изоляция среды исполнения не заменяет проверку модельного вывода по AI-CONTENT2.

В Kubernetes нагрузка запускается не от root, с запретом повышения привилегий и пространств имен хоста, с ограничением томов и исходящего трафика; универсального переключателя изоляции исполняемого ИИ-кода в Yandex Cloud нет.

Ручная проверка

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

Ни одна попытка не должна выйти за утвержденные границы среды; после проверки подтвердите завершение процесса и очистку тестовых данных.

Артефакт

• Разрешенная операция.
• Тесты выхода за границы.
• Завершение процесса.
• Список разрешенных операций.
• Подтверждение отсутствия побочных эффектов.

Авторизация RAGАвторизация RAG

Право на документ проверяется до передачи фрагмента моделиПраво на документ проверяется до передачи фрагмента модели

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

Требование

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

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

После поиска идентификаторы возвращенных документов повторно проверяются до сборки контекста. Журналируются версия политики и идентификаторы возвращенных документов, но не закрытое содержимое.

Для Managed Service for OpenSearch облачные роли управляют ресурсом сервиса, но сами по себе не реализуют документную авторизацию конечного пользователя. Если архитектура использует внутренние роли или фильтры OpenSearch, их поддерживаемая семантика и отрицательные тесты фиксируются отдельно. Возможности ролей Yandex Cloud описаны в документации Managed Service for OpenSearch.

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

Для другого хранилища владелец должен документировать его собственную модель доступа.

Реализация

AI Search хранит метаданные Vector Store и поддерживает фильтрацию по атрибутам файлов в поисковом API, однако это не является готовой документной авторизацией.

Если требуемая область доступа не может быть надежно выражена и защищена фильтром, используются раздельные Vector Store либо прикладная авторизация до включения фрагмента в контекст. Фильтр становится частью контроля только когда приложение формирует его из подтвержденных прав и отклоняет подмену. Подробнее в статьях о Vector Store и параметрах поиска.

Проверка

1. Создайте документы как минимум двух областей доступа.
2. Выполните разрешенный поиск от каждого субъекта к собственным документам и попытку получить чужой документ или строку.
3. Проверьте не только выдачу, но и фактический контекст модельного запроса.

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

Артефакт

• Разрешенный поиск.
• Попытка получить чужой документ.
• Контекст модели.
• Версия политики.
• Манифест фактического контекста запроса.

Вывод из эксплуатацииВывод из эксплуатации

Компонент выводится из эксплуатации полностьюКомпонент выводится из эксплуатации полностью

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

Требование

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

Для каждого объекта выбирается удаление, передача, сохранение на утвержденный срок или режим запрета на удаление данных по правовым основаниям. Готовность процедуры требуется для каждого продуктивного компонента; результат N/A допустим для свидетельств фактического выполнения, но не для проверки готовности.

Реализация

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

Затем удаляются активные объекты и настраивается завершение жизненного цикла резервных копий и версий. Немедленное удаление может быть невозможно из-за Object Lock, утвержденных сроков хранения, резервных копий или особенностей KMS. Правовой запрет на удаление имеет приоритет.

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

Проверка

1. Попытайтесь вызвать компонент прежним способом, использовать отозванный ключ и прочитать активный объект.
2. Сопоставьте итог с инвентарем и событиями изменения.

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

Артефакт

• Версия инвентаря.
• Акт завершения.
• Тест вызова прежним способом.
• Инвентаризация до и после.
• Результат поиска остаточных объектов.