Профили реализации в Yandex Cloud
- Управляемый инференс через AI Studio
- RAG через AI Search
- RAG через собственное хранилище
- Агент с MCP Gateway и инструментами
- Обучение и эксперименты в DataSphere
- Среда исполнения в Managed Service for Kubernetes
- Среда исполнения в Serverless Containers или Cloud Functions
- Среда исполнения на Compute Cloud с самостоятельно размещенной моделью
- Вызов внешнего модельного API из Yandex Cloud
- Границы общих средств защиты
Профиль связывает требования с конкретным путем запроса и объектами Yandex Cloud. Профили не вводят новых требований — они показывают ресурсы, настройки и свидетельства для требований разделов:
- Безопасная архитектура и разработка ИИ-приложений
- Данные, обучение, модели и выпуски
- IAM, сеть, шифрование, секреты и аудит
- Среда исполнения, RAG-хранилища и вывод из эксплуатации
- Мониторинг и реагирование на инциденты
- Агенты, инструменты, MCP и агентный RAG
- Цепочка поставок
- Соответствие требованиям и обработка персональных и регулируемых данных
В одной системе могут одновременно применяться несколько профилей: например, приложение в Managed Service for Kubernetes вызывает AI Studio
Следующая таблица связывает каждое требование с применимыми профилями Yandex Cloud и указывает, что именно проверять и каким артефактом подтверждать результат. Для требований, не привязанных к конкретному сервису, указан общий принцип проверки; отсутствие профиля не отменяет само требование.
Номера профилей в таблице являются примерами реализации, а не ограничением применимости. Применимость требования определяется условием архитектуры: контроли регулируемых данных действуют в любом профиле с потоком таких данных, проверки образов — во всех контейнерных средах исполнения, защита публичного периметра — в любом профиле с публичным HTTP(S)-входом.
|
Идентификатор требования |
Применимые профили |
Что проверить |
Артефакт |
|
|
Все профили |
Описание архитектуры, границы доверия, связь рисков с мерами |
Описание архитектуры, диаграмма потоков данных, сопоставление с фактическими ресурсами, разница версий инвентаря, записи тестов, документ согласования |
|
|
Любой профиль с публичным HTTP(S)-входом, например: |
Прикладная валидация ввода до вызова модели; API Gateway + Smart Web Security при публичном входе |
Записи отказов, конфигурация и хеш спецификации OpenAPI, идентификатор профиля Smart Web Security, тестовые запросы и их результат, подтверждение отсутствия последующего вызова |
|
|
Guardrails как объект конфигурации, роль |
Версия и выгруженная конфигурация правила, идентификаторы экземпляра модели и Guardrail, тест блокирования, событие управления или прикладная запись |
|
|
|
Детерминированный валидатор вывода, отклонение запрещенного действия |
Тестовые ответы модели, записи отклонения, код валидатора, хеш схемы и версия политики, подтверждение отсутствия вызова целевой системы |
|
|
|
Отдельное хранение системных инструкций, версии, субъекты чтения/записи |
Активная версия конфигурации, история изменений, результат теста подмены, хеш артефакта инструкций, событие развертывания, журнал действующей версии |
|
|
|
Отделение данных от инструкций, отказобезопасность, связь с источником |
Тестовый документ с инструкцией, трассировка решения политики, идентификаторы результатов поиска, запись о карантине или переиндексации |
|
|
|
Утвержденные эндпоинты, рабочая идентичность, маршрут, таймауты, журнал |
Конфигурация прокси и межсетевого экрана, запись разрешенного и запрещенного вызова, идентификатор секрета, корреляционный журнал вызова |
|
|
|
Любой профиль с публичным HTTP(S)-входом, например: |
Домен, маршрут, аутентификация, лимиты, связь с бэкендом |
OpenAPI-спецификация, запросы без учетных данных, тест обхода бэкенда, идентификаторы спецификации и профиля Smart Web Security, привязки, результаты HTTP-тестов |
|
|
Реестр источника, владельца, назначения, связи с моделью или индексом |
Запись реестра, прослеживание до объекта и версии, версия карточки, версия или хеш объекта, согласующий |
|
|
|
Разграничение загрузчика, промежуточная область, целевой индекс |
Успешная загрузка утвержденного объекта, отказ для неутвержденного источника, версия загрузчика, события принятия и отклонения, запись о переиндексации |
|
|
|
Разделение стадий, права записи, правила продвижения |
Политики доступа к бакетам/префиксам, тест записи из рабочей среды, схема стадий, версии входа и выхода, журнал перехода |
|
|
|
Классификация, минимизация, обратимость, ключи или таблица соответствия |
Схема полей, выборка после преобразования, отказ загрузки запрещенных полей, карта полей по назначениям, запись об удалении копий |
|
|
|
Входные версии, метрики, пороги, разделение выборок |
Сохраненный отчет с версией, критериями и результатом, версия кода проверок и тестов, хеши набора, независимый проверяющий |
|
|
|
Контрольные суммы, доверенная идентичность, процедура допуска |
Связь версии с источником, тест обхода проверки, манифест выпуска с хешами, событие изменения, тест восстановления |
|
|
|
Регистрация генератора, доля, отдельная оценка |
Запись о синтетической части, отчет с долей и контрольной выборкой, версия генератора, результат теста на отклонение немеченых данных |
|
|
|
Разделение проектов, идентичностей, хранилищ, сетевых путей |
Сопоставление контуров, тест чтения чужого секрета и записи в продуктив, хеши входных и выходных объектов задачи |
|
|
|
Источник, версия, контрольная сумма, статус допуска |
Запись происхождения, сопоставление с работающим экземпляром, карточка модели, хеши и версии объектов в хранилище |
|
|
|
Формат, загрузчик, изолированный запуск, контрольная сумма |
Результат изолированного запуска, наблюдение за действиями, версии формата и загрузчика, конфигурация изолированной среды, решение о допуске |
|
|
|
Все профили |
Точные версии данных, модели, инструкций, конфигурации, образа |
Решение о выпуске, сопоставление с продуктивной ревизией, хеш манифеста выпуска, событие развертывания |
|
|
Все профили |
Совместимость, порядок замены, критерии отката, способ отзыва |
Тест замены и отката, журнал инициатора, недоступность отозванной версии, идентификаторы целей отката, согласование возврата |
|
|
Все профили |
Разрешенные входящие, исходящие, межкомпонентные соединения |
Диаграмма потоков, правила групп безопасности, разрешенное и запрещенное соединение, результаты соединений из разрешенного и запрещенного источников |
|
|
Все профили |
Усиленная аутентификация привилегированных пользователей |
Перечень привилегированных ролей и групп, выгрузка эффективных прав, подтверждение состояния MFA или федеративной политики, срок исключения |
|
|
Среда исполнения на Compute Cloud с самостоятельно размещенной моделью и любые профили с ВМ-компонентами |
Отключение серийной консоли по умолчанию, аварийное включение только по исключению |
Конфигурация ВМ или политики серийной консоли, отказ доступа, заявка и срок аварийного включения при наличии, события включения и отключения, журналы ОС или компенсирующий журнал |
|
|
Все профили |
Отдельная рабочая идентичность, минимальная роль, область назначения |
Эффективные прямые и унаследованные права, сопоставление роли с операцией, матрица |
|
|
IAM-токен или API-ключ, роль, области действия, срок или пересмотр |
Метаданные ключа без значения, сопоставление с владельцем и API, привязки сервисного аккаунта, жизненный цикл ключа в Audit Trails, результаты разрешенного и запрещенного вызовов |
|
|
|
Все профили |
Периодичность пересмотра, охват прямых, групповых, унаследованных прав |
Датированная запись пересмотра, решения по избыточным правам, происхождение прав, срок исключения, повторный отрицательный тест |
|
|
Публичность хранилищ, точные идентификаторы, субъекты, сетевой путь |
Эффективные привязки, ACL, тест чтения от разрешенного и неразрешенного субъекта, конфигурация публичного доступа и сети |
|
|
|
Режим шифрования, ключ, права на ключ, тест чтения штатной средой |
Конфигурация шифрования, разрешенное чтение и отказ без права, идентификатор и привязки ключа, репетиция восстановления |
|
|
|
Все профили |
Владелец, идентификатор, версия, потребители, доставка, срок, замена и отзыв |
Сопоставление секрета с потребителем, тест отзыва и замены, привязки IAM и KMS, событие получения значения в Audit Trails, запись о ротации |
|
|
Все профили |
Перечень операций, источник события, область трейла, фильтры |
Конфигурация трейла, безопасное тестовое действие и найденная запись, карта событий, спецификация трейла, тест отсутствующего события |
|
|
Все профили |
Удаление или преобразование секретов и ПДн до записи |
Схема журналирования, выборка записей, подтверждение цели хранения, тестовые события с синтетическими маркерами, привязки читателей журналов |
|
|
Разделение идентичностей, сетевых путей, состояния, прав |
Тест доступа к чужому файлу, секрету, кешу, эндпоинту, топология и карта ресурсов и арендаторов |
|
|
|
Создание и очистка временного состояния, граница процесса или экземпляра |
Синтетический маркер, недоступность после завершения задачи, карта состояния со сроками жизни, событие очистки |
|
|
|
Отдельная среда, минимальная идентичность, лимиты, контроль сети |
Разрешенная операция, тесты выхода за границы, завершение процесса, список разрешенных операций, подтверждение отсутствия побочных эффектов |
|
|
|
Документная авторизация до передачи фрагмента модели |
Разрешенный поиск, попытка получить чужой документ, контекст модели, версия политики, манифест фактического контекста запроса |
|
|
|
Все профили |
Полный инвентарь активных и резервных объектов, способ вывода |
Версия инвентаря, акт завершения, тест вызова прежним способом, инвентаризация до и после, результат поиска остаточных объектов |
|
|
Все профили |
Сигналы, источник, окно, канал, действие |
Конфигурация алерта, тест доставки, регистрация действия ответственного, идентификаторы дашборда и оповещения, временная шкала события, тикет реагирования |
|
|
Все профили |
Идентификатор корреляции, идентичность, версия модели, решение политики, инструмент |
Сквозная трассировка от входа до результата, отсутствие секретов, сопоставление идентификаторов платформы и приложения |
|
|
Идентификаторы задачи и сессии, шаг, инструмент, результат |
Трассировка многошагового сценария с успешным и отклоненным вызовом, версия конечного автомата задачи, запись подтверждения, событие целевой системы |
|
|
|
Все профили |
Состав, цель, срок, место, владелец, круг читателей |
Сохраненная сессия, тест разрешенного и запрещенного чтения, область дела, результат удаления или запрета на удаление |
|
|
Все профили |
Отделение от рабочих администраторов, разделение прав, целостность |
Права на журналы, тест изменения единственной копии, конфигурация бакета, политик, ACL, версионирования, блокировки и шифрования, версия и хеш объекта |
|
|
Перечень инструментов, данных, получателей, максимальные последствия |
Реестр возможностей, сопоставление с конфигурацией, версия реестра, тестовые события |
|
|
|
Лимиты, точка контроля, безопасное состояние, условия остановки |
Тест циклического ответа, повторяющейся ошибки, исчерпания лимита, версия политики и конфигурация счетчиков, итоговая причина остановки |
|
|
|
Доверенный источник цели, разделение фактов, предложений, инструкций |
Тест расширения цели через пользователя, RAG, инструмент, версия цели и делегирование, подтверждение отсутствия вызова целевой системы |
|
|
|
Отдельная идентичность инструмента, минимальные права, проверка бэкендом |
Сопоставление бэкенда, сервисного аккаунта, ролей, тест подмены, матрица по инструментам, идентификаторы секретов |
|
|
|
Проверка пользователя, сессии, арендатора, контекст делегирования |
Тест подмены пользователя, арендатора, отзыва сессии, запись делегирования, метаданные токена без секрета, событие отзыва |
|
|
|
Действия с существенными последствиями, показ цели и параметров |
Тест действия без подтверждения, изменение параметра после подтверждения, идентификатор и хеш подтверждения, событие целевой системы |
|
|
|
Вызов, управление, привязки, сервисный аккаунт, целевой сервис |
Конфигурация Gateway, разрешенный и запрещенный вызов, обход бэкенда, результат get и привязки шлюза, полная спецификация инструментов, состояние публичного доступа, область действия ключа API |
|
|
|
Проверяемый отправитель, версия схемы, срок, защита от повтора |
Тесты с неверной схемой, истекшим сроком, повтором, подменой отправителя, идентичность и привязка отправителя, версии схемы и политики |
|
|
|
Источник, автор, дата, версия, условия, контрольная сумма |
Запись приемки, повторное получение и сопоставление суммы, исходный и внутренний хеши, тест карантина |
|
|
|
Автоматические и ручные проверки, карантин, ручное решение |
Тестовый набор с ошибками, связь отчета с входной версией, версии валидаторов, подтверждение отсутствия объекта в индексе |
|
|
|
Источник, контрольные суммы, формат, загрузчик, изолированный запуск |
Комплект с источником, наблюдение за действиями при загрузке, конфигурация среды первичной проверки |
|
|
|
Заявка, проверка источника, целостность, поведенческие тесты, решение |
Запись приемки, тест подмены контрольной суммы, пакет приемки и его хеш, подтверждение или исключение |
|
|
|
Все контейнерные среды исполнения: |
Перечень зависимостей, сведения об уязвимостях, срок исправления |
Дайджест образа, актуальные результаты сканирования, тест выпуска, отчет о зависимостях, событие повторного развертывания |
|
|
Все контейнерные среды исполнения: |
SBOM или манифест, состав, контрольные суммы |
Сохраненный манифест, сравнение с фактическими объектами, хеш манифеста, карточки компонентов |
|
|
Все профили |
Каналы уведомлений, процедура определения затронутых выпусков |
Тестовое уведомление, поиск систем, решение об ограничении, затронутые манифесты выпусков, тикет |
|
|
Все профили |
Утвержденное решение, охват всех типов данных и получателей |
Правовое решение и решение о соответствии требованиям, реестр сценариев, диаграмма потоков данных, идентификаторы потоков, пример трассировки |
|
|
Все профили |
Карта жизненного цикла, компоненты, регионы, копии, получатели |
Карта потоков, реестр компонентов, инвентаризация ресурсов, тест неучтенной копии, выгрузки ресурсов, запись о миграции или удалении |
|
|
Получатель, юрисдикция, эндпоинт, объем, условия, срок |
Реестр получателей, конфигурация gateway, тест запрещенной передачи, идентификатор секрета, свидетельства провайдера, тест перенаправления |
|
|
|
Решение уполномоченных представителей, сопоставление с ресурсами и маршрутами |
Правовая оценка и оценка соответствия требованиям, реестр потоков, архитектурная схема, идентификаторы решений, отказ неизвестного ребра |
|
|
|
Любой профиль с потоком регулируемых данных, например: |
Обнаружение и преобразование до границы, обратимость, безопасное поведение |
Политики преобразования, тест границы доверия, права на обратное преобразование, тип и версия преобразования, тесты остаточных полей и недоступности |
|
|
Любой профиль с потоком регулируемых данных, например: |
Средства обнаружения, версионирование, тестовые наборы, мониторинг |
Конфигурация DSPM/DLP, версии правил, результаты оценки качества, правила управления набором, версии детектора |
|
|
Любой профиль с защитным преобразованием регулируемых данных, например: |
Минимальные привилегии, разделение обязанностей, журналирование без ПДн |
IAM-политики, журналы преобразования, тесты отказоустойчивости, схема события, тесты недоступности и обхода |
Управляемый инференс через AI Studio
Применимость и статус
Профиль применяется к управляемому API AI Studio
Поток и границы доверия
пользователь → приложение или среда исполнения → AI Studio API → модель → приложение. Ввод и ответ пересекают прикладную границу проверки; файлы, инструменты Responses и Guardrails образуют отдельные ветви.
Рабочая идентичность и аутентификация
Среда исполнения использует отдельный сервисный аккаунт и документированный для выбранного API IAM-токен либо API-ключ. Для управления MCP Hub поддерживается IAM-токен, а не API-ключ. Способы и заголовки приведены в документации аутентификации
Роли и область назначения
Для генерации текста проверяется ai.languageModels.user; для Responses — ai.assistants.editor вместе с ai.languageModels.user; для Realtime — ai.models.user. Назначения проверяются на поддерживаемом уровне организации, облака или каталога. Роль одного API не переносится на другой; семантика ролей берется из модели доступа AI Studio
Сеть
Фиксируются фактический управляемый эндпоинт и исходный путь среды исполнения. Если для Responses используется политика авторизации IAM, проверяются шаблон aistudio.responses.restrictNetworkAccess, allowed_src_ips, allowed_vpc_network_ids и разрешенный и запрещенный источники. Политика ограничивает уже выданное право и не создает приватный эндпоинт.
Секреты и учетные данные
Для API-ключа фиксируются идентификатор, сервисный аккаунт-владелец, области действия, срок или дата пересмотра и путь доставки из профиля среды исполнения. Значение ключа не включается в конфигурационное свидетельство. Для IAM-токена фиксируется рабочая идентичность и способ получения.
Объекты конфигурации
Идентификатор каталога, модель и API-возможность, сервисный аккаунт, привязки, идентификатор и области API-ключа, версия прикладной конфигурации; при использовании — идентификатор и версия Guardrails и политика авторизации IAM.
Телеметрия и слепые зоны
Используются только опубликованные события Audit Trails для AI Studio
Положительная и отрицательная проверки
- Выполните разрешенный вызов. Проверьте отказ без роли, отказ с отозванным или неподходящим ключом и корреляцию с прикладной записью.
- Для политики авторизации IAM проверьте разрешенный и запрещенный сетевой источник.
- Для Guardrails проверьте разрешенную категорию, блокирование и ошибку модератора.
Что необходимо для реализации профиля
- Архитектура: API, модель, среда исполнения и ветви данных.
- Политика: IAM-токен или API-ключ, срок ключа, сетевые ограничения, правила и состав журналов.
- Правовое решение: допустимые категории данных, цель, получатели и срок хранения.
RAG через AI Search
Применимость и статус
Профиль применяется, если RAG использует файлы и Vector Store AI Studio. Web Search фиксируется отдельной внешней ветвью; свойства AI Search не переносятся на произвольное векторное хранилище.
Поток и границы доверия
утвержденный источник → загрузчик → файл → Vector Store → поиск приложения → разрешенные фрагменты → контекст модели. Граница допуска находится до публикации файла, а граница документной авторизации — до передачи фрагмента модели.
Рабочая идентичность и аутентификация
Идентичности загрузки и поиска разделяются, если совмещение не обосновано. Каждая использует IAM-токен или API-ключ в соответствии с конкретным API и профилем среды исполнения.
Роли и область назначения
ai.assistants.editor управляет файлами и Vector Store; ai.assistants.viewer позволяет читать их и выполнять поиск. Для последующей генерации текста используется ai.languageModels.user; для Responses — ai.assistants.editor вместе с ai.languageModels.user. Пример одной операции и ее область API-ключа не считаются универсальной комбинацией; актуальная семантика берется из модели доступа AI Studio
Сеть
Используется управляемый эндпоинт AI Studio; наличие VPC у загрузчика не создает отдельную сетевую границу Vector Store. Для Web Search фиксируются разрешенные домены и внешняя граница. Недокументированный приватный эндпоинт не заявляется.
Секреты и учетные данные
Учетные данные загрузчика и поисковой среды доставляются по профилям их среды исполнения. В карточке корпуса хранятся идентификатор и области ключа, но не значение. Секрет источника данных отделяется от учетных данных поиска.
Объекты конфигурации
Источник и версия, идентификаторы файлов и Vector Store, параметры разбиения и токенизации, атрибуты файлов, идентичности загрузки и поиска, состояние жизненного цикла и связь с выпуском. Возможности и метаданные описаны в Vector Store
Телеметрия и слепые зоны
Каталог событий AI Studiosearchindex.CreateSearchIndex, searchindex.UploadFilesToSearchIndex, searchindex.DeleteFilesFromSearchIndex и searchindex.DeleteSearchIndex. Отдельное событие изменения индекса и событие каждого поискового запроса в этом перечне не заявлены; права конечного пользователя и трассировку поиска с идентификаторами источников и решением авторизации записывает приложение.
Положительная и отрицательная проверки
- Загрузите разрешенный объект. Проверьте отклонение неразрешенного источника и записи в чужой Vector Store.
- Выполните поиск от двух субъектов, подмените атрибут фильтра и подтвердите отсутствие закрытого фрагмента в модельном контексте.
- Удалите тестовый файл и проверьте прекращение выдачи.
Что необходимо для реализации профиля
- Архитектура: корпус, идентичности загрузки и поиска и модель документного доступа.
- Политика: правила приемки, разбиения, переиндексации и срока жизни.
- Правовое решение: допустимость источников, категорий данных и Web Search. Авторизация через фильтр применяется только после подтверждения ее точной прикладной семантики; иначе используются раздельные Vector Store или авторизация до поиска.
RAG через собственное хранилище
Свойства Managed Service for OpenSearch и YDB различаются, поэтому они образуют два профиля. Для другого продукта владелец составляет отдельный профиль по тем же десяти полям; универсальная строка «иное хранилище» не является свидетельством.
Managed Service for OpenSearch
Применимость и статус
Профиль применяется, если Managed Service for OpenSearch является поисковым хранилищем RAG.
Поток и границы доверия
источник → среда загрузки → кластер и индекс; отдельно среда поиска → OpenSearch-эндпоинт → результат → модель. Прикладная документная авторизация находится перед выдачей фрагмента.
Рабочая идентичность и аутентификация
Identity and Access Management управляет ресурсом сервиса, а подключение к контуру данных использует внутреннего пользователя OpenSearch и его пароль. IAM-привязка сама по себе не аутентифицирует поисковый запрос. Пользователь, пароль и внутренние сопоставления ролей проверяются отдельно по инструкции управления пользователями.
Роли и область назначения
managed-opensearch.user используется для работы с кластером; managed-opensearch.auditor и managed-opensearch.viewer — для чтения доступной конфигурации; managed-opensearch.editor — для изменения ресурса; managed-opensearch.admin дополнительно управляет доступом.
Если при создании или восстановлении кластера выбран пользовательский KMS-ключ, выполняющему эту операцию субъекту дополнительно назначается kms.keys.user или более высокая роль на конкретный ключ согласно документации хранилища. Точная операция сверяется с моделью доступа.
Эти роли не заменяют внутренние права индекса и авторизацию конечного пользователя.
Сеть
Фиксируются VPC, подсети, группы хостов, группы безопасности, FQDN и признак публичного доступа. Подключение выполняется по TLS в соответствии с инструкцией сервиса; широкое правило 0.0.0.0/0 из примера не является нормативным разрешением.
Секреты и учетные данные
Пароль внутреннего пользователя хранится в Lockbox или другом утвержденном хранилище и доставляется по профилю среды исполнения. В свидетельстве указываются идентификатор секрета и версии, пользователь и потребитель, но не значение.
Объекты конфигурации
Идентификатор кластера, группы хостов и роли узлов, сеть и группы безопасности, признак публичного доступа, FQDN, внутренние пользователи и сопоставления ролей, индексы, псевдонимы и правила фильтрации, а также KMS-ключ при выбранном и документированном режиме шифрования хранилища.
Телеметрия и слепые зоны
Используются только события из справочника Audit Trails для OpenSearch. Они могут показывать операции и ошибки привилегий, но не доказывают корректность прикладного ACL и полноту контекста конечного пользователя.
Положительная и отрицательная проверки
- Выполните разрешенный поиск и поиск чужого документа.
- Выполните прямой запрос в обход приложения, вход неверным внутренним пользователем и соединение из запрещенной сети.
- Свяжите прикладной идентификатор запроса с доступным событием сервиса.
Что необходимо для реализации профиля
- Архитектура: индексы, среды загрузки и поиска и место документного ACL.
- Политика: публичность, внутренние роли, KMS и сроки журналов.
- Правовое решение: категории документов и допустимые получатели.
YDB
Применимость и статус
Профиль применяется, если YDB является хранилищем документов, метаданных или поисковых результатов RAG.
Поток и границы доверия
среда исполнения → эндпоинт и путь базы данных → таблицы и индексы → строки → контекст модели. Авторизация пользователя на документ или строку остается прикладной границей.
Рабочая идентичность и аутентификация
Клиент YDB SDK или CLI использует IAM-токен либо документированный поставщик учетных данных, который получает IAM-токены из авторизованного ключа доступа или сервиса метаданных среды исполнения. Выбор библиотеки и поставщика фиксируется по инструкции подключения YDB.
Для прямого обращения к API управления передается только IAM-токен в схеме Bearer согласно справочнику аутентификации API; авторизованный ключ доступа не заявляется как прямые учетные данные Bearer.
Роли и область назначения
ydb.auditor используется для подключения и метаданных в пределах документации; ydb.viewer — для чтения; ydb.editor — для чтения, записи и изменения схемы; ydb.admin — для управления доступом. Роли назначаются на конкретную базу, когда это поддерживает требуемую операцию. Они не являются готовым списком управления доступом на уровне строк или документов. Подробнее в описании модели доступа YDB.
Сеть
Фиксируются бессерверный или выделенный режим, эндпоинт, путь базы данных и фактический сетевой путь. Для выделенной базы официальная инструкция подключения требует входящий и исходящий TCP-трафик на порт 2135; источник и назначение правила ограничиваются фактической средой приложения, а не примером 0.0.0.0/0. Для бессерверной базы используются выданные сервисом эндпоинт grpcs и путь; схема группы безопасности выделенной базы на нее не переносится.
Секреты и учетные данные
При IAM-токене из сервиса метаданных долгоживущий секрет отсутствует, что отмечается как N/A с указанием рабочей идентичности. Файл авторизованного ключа доступа для SDK или CLI хранится и доставляется по AI-SECRET1; получаемый через него IAM-токен не подменяет учет ключа.
Объекты конфигурации
Идентификатор и режим базы, эндпоинт и путь базы данных, IAM-привязки, таблицы, индексы, схема, способ аутентификации, группы безопасности для выделенной базы данных, прикладная схема арендатора и списки управления доступом на уровне документов.
Телеметрия и слепые зоны
Справочник Audit Trails YDB описывает события уровня управления. Он не является журналом чтения и изменения каждой строки; эти операции и решение прикладного ACL записывает приложение или утвержденный слой запросов.
Положительная и отрицательная проверки
- Выполните разрешенное чтение и запрос чужого арендатора или строки.
- Выполните прямой запрос в обход API поиска и вызов с отозванными учетными данными.
- Отдельно покажите событие управления и прикладную трассировку запроса уровня данных.
Что необходимо для реализации профиля
- Архитектура: режим базы, схема, индексы и ACL.
- Политика: способ аутентификации, правила запросов и срок журналов.
- Правовое решение: категории данных. Настройка KMS не заявляется без официального подтверждения для выбранной конфигурации YDB.
Агент с MCP Gateway и инструментами
Применимость и статус
Профиль применяется, если агент вызывает MCP Gateway или управляется через MCP Hub. Публичность Gateway, доступ к внешнему или шаблонному MCP-серверу и подтверждение действия являются независимыми свойствами.
Поток и границы доверия
пользователь → приложение → агент → MCP Gateway → HTTP-бэкенд инструмента → целевой ресурс. Отдельно проверяются вход Gateway, сервисный аккаунт Gateway, авторизация бэкенда и права на целевой ресурс.
Рабочая идентичность и аутентификация
Разделяются вызывающая и управляющая идентичности, сервисный аккаунт Gateway и учетные данные бэкенда. Для управления MCP Hub используется IAM-токен. Вызывающая среда получает IAM-токен своего сервисного аккаунта; API-ключ с областью yc.serverless.mcpGateways.invoke используется только в документированном сценарии вызова и доставляется по профилю этой среды.
Роли и область назначения
serverless.mcpGateways.invoker разрешает вызов, serverless.mcpGateways.editor — изменение Gateway, serverless.mcpGateways.admin — управление привязками.
Дополнительная serverless.mcpGateways.anonymousInvoker назначается для документированных внешних MCP-серверов и серверов из шаблона; это назначение не заменяет и не доказывает настройку публичности Gateway.
Субъекту, создающему Gateway, назначаются serverless.mcpGateways.editor и iam.serviceAccounts.user на каталог согласно инструкции создания
Семантика остальных ролей берется из модели доступа AI Studio
Сеть
Фиксируются public, IAM-привязки, облачные сети VPC при использовании и достижимость бэкенда. public=true означает неаутентифицированный доступ агентов; роль serverless.mcpGateways.anonymousInvoker относится к документированной ветви внешних и шаблонных серверов и не является эквивалентом этого флага. Ни одна из ветвей не доказывает авторизацию целевого сервиса.
Секреты и учетные данные
При useServiceAccount Gateway использует привязанный сервисный аккаунт, поэтому долгоживущий секрет бэкенда отмечается как N/A; права аккаунта на целевой ресурс проверяются отдельно.
Если бэкенд требует bearer-токен или учетные данные в пользовательском заголовке, до допуска должен быть назван поддерживаемый механизм хранения, передачи в Gateway и ротации. Текущая ссылка на создание Gateway не подтверждает нативную ссылку на Lockbox, поэтому необоснованное размещение значения в конфигурации не считается допустимым путем.
Разрешенные для пересылки заголовки задаются явным списком; значения секретов не включаются в схему инструмента или свидетельство.
Объекты конфигурации
Gateway, каталог и идентификаторы сервисных аккаунтов, public, облачная сеть, лог-группа и уровень, список инструментов, URL и метод, версия inputJsonSchema, тело, заголовки, параметры запроса и режим авторизации и пересылки заголовков. Поддерживаемые поля сверяются с инструкцией создания Gateway
Ограничение размера параметров и подтверждение действия человеком реализуются приложением или оркестратором агента по AI-AGENT-HITL1 и не являются документированными полями конфигурации MCP Gateway.
Телеметрия и слепые зоны
Cloud Logging включается конфигурацией Gateway. События AI Studiomcp_hub.InvokeMcpTool, не доказывают полноту авторизации бэкенда, эффект на целевом ресурсе и содержимое ответа. Эти части связывает прикладная трассировка и журнал целевого сервиса.
Положительная и отрицательная проверки
Синтаксис диагностических команд берется из CLI-справочника MCP Gateway.
- Выполните
list,get,list-access-bindings,list-operations. - Проверьте вызов private Gateway с IAM-токеном или API-ключом и отказ без
invoker. - Проверьте доступ к выбранному внешнему или шаблонному серверу с требуемой дополнительной ролью и отказ без нее.
- Для
public=trueпроверьте неаутентифицированный вызов и его запрет после отключения публичности. - Дополнительно проверьте управляющую операцию из рабочей среды, превышение размера или схемы, прямой обход бэкенда, подтверждаемое действие и остановку цикла.
Что необходимо для реализации профиля
- Архитектура: инструменты, бэкенды, целевые ресурсы и схема делегирования.
- Политика: public/anonymous, approval, заголовки, размеры и лимиты цикла.
- Правовое решение: внешние бэкенды и передаваемые категории данных.
Обучение и эксперименты в DataSphere
Применимость и статус
Профиль применяется к ноутбукам, заданиям, узлам и опубликованным ресурсам DataSphere. Управляемая среда не заменяет учет происхождения данных, приемку модели и решение о выпуске.
Поток и границы доверия
пользователь или CI → сообщество и проект → ноутбук/задание/узел → хранилища и внешние сервисы → модельный артефакт → выпуск. Членство в проекте, рабочая идентичность задания и доступ к внешнему ресурсу являются разными границами.
Рабочая идентичность и аутентификация
Разделяются пользователь проекта, связанный сервисный аккаунт проекта и сервисный агент сообщества. Для запуска заданий от сервисного аккаунта он добавляется в проект; его права на внешние ресурсы назначаются отдельно.
В документированной ветви задания с сервисным агентом его токен сохраняется в файл, путь к которому задание получает через SA_TOKEN_FILENAME. Официальная инструкция не определяет права этого файла или изоляцию процессов: владелец задания отдельно задает доступ к пути средствами выбранного образа и не переносит токен в параметры задания, журналы или свидетельство.
Роли и область назначения
Для проекта используются datasphere.community-projects.viewer, datasphere.community-projects.developer, datasphere.community-projects.editor и datasphere.community-projects.admin в зависимости от требуемой операции. Для сообщества отдельно используются datasphere.communities.viewer, datasphere.communities.developer, datasphere.communities.editor и datasphere.communities.admin.
Для задания от сервисного аккаунта проверяется datasphere.community-projects.developer на проект; широкая роль на облако не заменяет доступ к проекту.
Если сервисный агент задания читает Lockbox, ему назначается lockbox.payloadViewer на конкретный секрет, а для секрета с пользовательским KMS-ключом — kms.keys.encrypterDecrypter на этот ключ согласно модели доступа Lockbox.
Актуальные операции и наследование DataSphere сверяются с моделью доступа сервиса.
Сеть
Фиксируется подсеть по умолчанию либо пользовательская подсеть, VPC, группы безопасности и исходящий путь. Проект в служебной подсети имеет документированный интернет-доступ; пользовательская подсеть без настроенного NAT его не получает.
Для пользовательской подсети сервисному аккаунту проекта требуется vpc.user; если интернет-доступ сохраняется через NAT-шлюз, дополнительно требуется vpc.gateways.user согласно настройкам проекта. Роли назначаются на фактически выбранную сеть или gateway, а не на все облако.
Для notebook и заданий прямой вход в подсеть не заявляется. Если публикуется узел или алиас, фиксируются эндпоинт и public/private; документация DataSphere указывает, что публичный алиас доступен всем аутентифицированным пользователям Yandex Cloud, а private требует описанных проектных прав. При отсутствии узла или алиаса эта входная ветвь отмечается как N/A.
Секреты и учетные данные
Для секрета проекта указываются ID, владелец и область предоставления, но не значение.
Для задания, обращающегося к Lockbox, фиксируются сервисный агент, конкретный секрет, привязки lockbox.payloadViewer и применимого KMS-права, а также имя переменной SA_TOKEN_FILENAME по официальной инструкции. Выбранный образ и спецификация задания должны отдельно ограничивать потребителей пути; значение токена и содержимое секрета в свидетельство не включаются.
Объекты конфигурации
Идентификаторы сообществ и проектов, участники и роли, сервисный аккаунт проекта и сервисный агент сообщества, облачные сети, подсети, группы безопасности, NAT-шлюзы, SA_TOKEN_FILENAME без значения токена и выбранное ограничение доступа к пути, лимиты, идентификатор и спецификация задания, срок данных задания, секреты, датасеты, файлы, артефакты, узел и алиас.
Телеметрия и слепые зоны
Audit Trails DataSphere покрывает опубликованные операции уровня управления. Метрики узлов и алиасов показывают эксплуатационное состояние, но не исполнение ячейки, содержимое данных, журнал промпта или полную цепочку происхождения; их закрывают журналы процесса и карточка происхождения.
Положительная и отрицательная проверки
- Выполните запуск от имени разрешенного и постороннего пользователя или сервисного аккаунта. Проверьте доступ задания к разрешенному и запрещенному ресурсу.
- Для ветви сервисного агента проверьте успешный API-вызов с токеном из
SA_TOKEN_FILENAME, отказ после отзыва роли и отсутствие значения токена в параметрах и журналах. - Проверьте исходящий путь пользовательской подсети, видимость секрета, срок данных задания и событие управления, не выводя токен или значение секрета.
- Проследите набор и модельный комплект до выпуска.
Что необходимо для реализации профиля
- Архитектура: проекты, типы нагрузок, сеть, источники и получатели.
- Политика: роли, лимиты, TTL, совместный доступ и выход в интернет.
- Правовое решение: обучающие данные и права использования. Если понадобится недокументированная телеметрия операций с данными, ее нельзя заявлять до появления официального источника; до этого она остается прикладной слепой зоной.
Среда исполнения в Managed Service for Kubernetes
Применимость и статус
Профиль применяется, если ИИ-компонент выполняется в Managed Service for Kubernetes.
Поток и границы доверия
вход → сервис → под → AI/RAG/MCP-зависимости; отдельно рассматриваются Kubernetes API, узлы и рабочие нагрузки. Identity and Access Management управляет ресурсами Yandex Cloud, Kubernetes RBAC — объектами Kubernetes API, прикладная авторизация — данными пользователя.
Рабочая идентичность и аутентификация
Разделяются:
- сервисный аккаунт кластера;
- сервисный аккаунт групп узлов;
- ресурс типа
ServiceAccountнагрузки в Kubernetes и связанный с ним сервисный аккаунт IAM; - пользователь Kubernetes API.
Если нагрузка не обращается к Yandex Cloud API, облачные учетные данные для нее отмечаются как N/A.
Для прямого доступа нагрузки к API без авторизованного ключа может применяться документированная федерация сервисных аккаунтов: OIDC-токен ресурса ServiceAccount в Kubernetes обменивается на IAM-токен связанного сервисного аккаунта IAM. Для External Secrets Operator остается отдельный путь с заданным ключом.
Использование нагрузкой токена сервисного аккаунта узла через сервис метаданных является общей идентичностью узла и допускается только после явного ограничения прав и обоснования; иначе доступ пода к метаданным блокируется.
Роли и область назначения
- Субъекту, создающему кластер и группу узлов, назначаются
k8s.editorили выше иiam.serviceAccounts.userна выбранные сервисные аккаунты; для создания с публичным доступом ему дополнительно требуетсяvpc.publicAdmin. - Сервисный аккаунт кластера получает минимум
k8s.clusters.agent; для публичного доступа он также получаетvpc.publicAdmin, а при VPC из другого каталога —vpc.privateAdmin,vpc.userиvpc.bridgeAdminна каталог этой сети. - Сервисный аккаунт группы узлов получает
container-registry.images.pullerна выбранный Container Registry либоcloud-registry.artifacts.pullerна выбранный Cloud Registry; для иного реестра эти роли не назначаются автоматически. - Для пользовательского доступа к облачному API и Kubernetes API отдельно используются
k8s.viewer,k8s.editor,k8s.cluster-api.viewer,k8s.cluster-api.editor,k8s.cluster-api.adminиk8s.cluster-api.cluster-adminв зависимости от требуемой операции. Внутри кластера применяютсяRole/RoleBindingв области пространства имен;ClusterRoleBindingобосновывается отдельно.
Границы субъектов и ролей сверяются с моделью доступа Kubernetes.
Сеть
Фиксируются CIDR кластера, узлов и подов, публичность master-эндпоинта, группы безопасности, ingress-контроллер, сервис и сетевая политика.
Для рабочих пространств применяется запрет по умолчанию с разрешением нужных направлений. Доступ пода к 169.254.169.254 блокируется, если токен метаданных узла не нужен.
Если для обращения к Yandex Cloud API используется федерация сервисных аккаунтов, узлам обеспечивается исходящий путь через публичный IP, NAT-шлюз либо NAT-инстанс и разрешенные исходящие правила группы безопасности согласно инструкции интеграции; это условие не требует назначения публичного IP-адреса каждому узлу, если выбран NAT.
Секреты и учетные данные
В федерации сервисных аккаунтов авторизованный ключ отсутствует: фиксируются сервисный аккаунт IAM, федерация, привязка в федерации сервисных аккаунтов и точный субъект system:serviceaccount:<пространство_имен>:<имя_ServiceAccount>.
Отдельная документированная интеграция External Secrets Operator использует авторизованный ключ сервисного аккаунта в Kubernetes Secret и lockbox.payloadViewer на конкретный секрет. Этот путь с ключом не считается бесключевой Workload Identity: ключ, SecretStore, ExternalSecret, целевой Secret, ротация и потребитель учитываются по AI-SECRET1.
Объекты конфигурации
Идентификатор кластера и групп узлов, сервисные аккаунты, пространства имен, ресурсы типа ServiceAccount в Kubernetes, развертывания, задания, Role/ClusterRole и bindings, сетевые политики, объекты Ingress и Service, группы безопасности, контекст безопасности пода, лимиты ресурсов, SecretStore/ExternalSecret/Secret и дайджест образа.
Для федерации сервисных аккаунтов дополнительно фиксируются: включение функции у кластера и группы узлов, URL эмитента и JWKS URL, идентификаторы федерации сервисных аккаунтов и привязки в ней, идентификатор сервисного аккаунта IAM, аннотация yandex.cloud/federated-yc-service-account-id и внешний субъект — ресурс ServiceAccount в Kubernetes.
Для аудита фиксируются master-logging.enabled, audit-enabled, log-group-id либо folder-id и роль logging.writer сервисного аккаунта для ресурсов.
Телеметрия и слепые зоны
Аудит Kubernetes API доставляется в Cloud Logging только при включенных master-logging.enabled и audit-enabled и настроенном назначении log-group-id либо folder-id; параметры приведены в инструкции изменения кластера. Состав записей ограничен опубликованной политикой аудита.
Журналы узла, подов и приложения и прикладная трассировка агента являются отдельными источниками; аудит уровня управления не доказывает их полноту.
Положительная и отрицательная проверки
- Проверьте IAM и RBAC отдельно и выполните разрешенное и запрещенное действие API.
- Для федерации сервисных аккаунтов проверьте обмен токена разрешенного ресурса
ServiceAccountв Kubernetes, отказ для другого пространства имен или ресурсаServiceAccountи отказ при удаленном исходящем маршруте или правиле к Yandex Cloud API. - Проверьте запрос между пространствами имен, сетевую политику с запретом по умолчанию и эндпоинт метаданных.
- Проверьте получение и отзыв тестового секрета без вывода значения и дайджест образа.
- Проверьте событие аудита и корреляцию с журналом пода или приложения.
Что необходимо для реализации профиля
- Архитектура: топология, входной путь, рабочие идентичности и зависимости.
- Политика: RBAC, исходящий трафик, настройки защиты пода, лимиты и срок хранения.
- Правовое решение: хранимые и обучающие данные.
Среда исполнения в Serverless Containers или Cloud Functions
Serverless Containers и Cloud Functions проверяются раздельно: ревизия контейнера и версия функции, роли управления, триггеры и журналы не взаимозаменяемы.
Serverless Containers
Применимость и статус
Профиль применяется, если среда исполнения — Serverless Containers.
Поток и границы доверия
HTTPS/триггер/API Gateway → публичный API сервиса → активная ревизия → целевые ресурсы. Управляемый экземпляр не принимает произвольное входящее соединение напрямую.
Рабочая идентичность и аутентификация
Для непубличного контейнера вызывающая среда получает IAM-токен своей рабочей идентичности и имеет serverless-containers.containerInvoker. Публичная ветвь существует только при привязке этой роли к системной группе system:allUsers; тогда запрос не содержит заголовок авторизации. Привязка и отсутствие учетных данных проверяются по инструкции публичного контейнера.
Сервисный аккаунт ревизии обращается к целевым ресурсам и получает краткоживущий IAM-токен через сервис метаданных GCE по официальной инструкции. Эти субъекты и их права разделяются.
Роли и область назначения
Для вызова используется serverless-containers.containerInvoker; управление контейнером выполняет serverless-containers.editor, а управление его правами доступа — serverless-containers.admin только в зависимости от требуемой операции.
Субъект, создающий ревизию с сервисным аккаунтом, отдельно имеет iam.serviceAccounts.user на этот аккаунт.
Сервисный аккаунт ревизии получает точные роли на целевые ресурсы и, если образ находится в непубличном Container Registry, container-registry.images.puller на выбранный реестр или репозиторий. Семантика и уровни назначения сверяются с моделью доступа Containers.
Сеть
Даже при подключении пользовательской сети контейнер вызывается через публичный API сервиса. Фиксируются режим входного доступа, облачная сеть, подсеть и исходящий путь; пользовательская сеть открывает доступ к ее ресурсам, а сеть по умолчанию использует документированный NAT. Подробнее в описании сетевой модели.
Секреты и учетные данные
Интеграция Container + Lockbox находится на стадии Preview. Сервисный аккаунт получает lockbox.payloadViewer на конкретный секрет и kms.keys.encrypterDecrypter на ключ, если секрет зашифрован пользовательским KMS-ключом. Ссылка входит в новую ревизию; значение может кешироваться до пяти минут после отзыва.
Объекты конфигурации
Идентификаторы контейнеров и ревизий, активная ревизия, дайджест образа, сервисный аккаунт, режим доступа, CPU, память, параллельная обработка запросов, таймаут, переменные окружения и ссылки на секреты, облачная сеть, лог-группа и права доступа.
Телеметрия и слепые зоны
Cloud Logging получает журнал запросов и stdout/stderr по модели логов; запросы связываются через X-Request-Id. Audit Trails показывает опубликованные операции управления, но не каждый invoke и не прикладное решение.
Положительная и отрицательная проверки
- Выполните вызов с ролью и без нее.
- Проверьте активную и предыдущую ревизии и операцию с целевым ресурсом от минимальной роли.
- Проверьте получение и отзыв тестового секрета с учетом кеша.
- Проверьте журнал запросов и откат.
Что необходимо для реализации профиля
- Архитектура: триггер, входной режим, сеть и целевые ресурсы.
- Политика: публичность, масштабирование, таймаут, редактирование содержимого журналов и срок хранения.
- Правовое решение: содержимое запросов и журналы.
Cloud Functions
Применимость и статус
Профиль применяется, если среда исполнения — Cloud Functions.
Поток и границы доверия
HTTPS/триггер/API Gateway → публичный API сервиса → версия или тег → целевые ресурсы. Триггер, Gateway и прямой вызывающий субъект рассматриваются отдельно.
Рабочая идентичность и аутентификация
Для непубличной функции вызывающая среда получает IAM-токен своей рабочей идентичности и имеет functions.functionInvoker. Публичная ветвь существует только при привязке этой роли к системной группе system:allUsers; тогда запрос не содержит заголовок авторизации. Привязка и отсутствие учетных данных проверяются по инструкции публичной функции.
Сервисный аккаунт версии получает доступ к целевым ресурсам, а его краткоживущий IAM-токен доступен через контекст обработчика или сервис метаданных GCE по официальной инструкции. Сервисные аккаунты триггера и API Gateway проверяются отдельно и также должны иметь право вызова непубличной функции.
Роли и область назначения
functions.functionInvoker разрешает вызов; functions.editor управляет функциями, версиями и связанными объектами; functions.admin дополнительно управляет доступом.
Субъекту, который привязывает сервисный аккаунт к версии, триггеру или API Gateway, назначается iam.serviceAccounts.user на этот аккаунт; это право используется при развертывании и не определяет права функции во время выполнения. Точная операция и область сверяются с моделью доступа Cloud Functions.
Сеть
Функция вызывается через публичный API сервиса; произвольное входящее соединение к экземпляру не поддерживается. Фиксируются API Gateway, триггер, пользовательская сеть или сеть по умолчанию и фактический исходящий путь согласно сетевой модели Cloud Functions.
Секреты и учетные данные
Интеграция Cloud Functions и Lockbox находится на стадии Preview. Ссылка на секрет создает новую версию, а значение может кешироваться до пяти минут после отзыва. Проверяются lockbox.payloadViewer на секрет, kms.keys.encrypterDecrypter на пользовательский KMS-ключ при его использовании и точная версия секрета.
Объекты конфигурации
Идентификатор, версия и тег функции, среда исполнения, точка входа, хеш кода, память, таймаут, облачная сеть, сервисный аккаунт, ссылки на секреты, лог-группа, масштабирование, триггер и API Gateway.
Телеметрия и слепые зоны
Логи Cloud Functions содержат идентификатор запроса и stdout/stderr. Аудитные логи Cloud Functions относятся к опубликованным операциям управления и не являются data-plane журналом каждого вызова.
Положительная и отрицательная проверки
- Выполните разрешенный и запрещенный вызов.
- Проверьте идентичность триггера, переключение версии и тега и отказ целевого ресурса.
- Проверьте получение и отзыв тестового секрета.
- Проверьте корреляцию идентификатора запроса и откат версии.
Что необходимо для реализации профиля
- Архитектура: триггер, Gateway, версия и целевые ресурсы.
- Политика: доступ, масштабирование, таймаут, редактирование содержимого журналов и срок хранения.
- Правовое решение: содержимое вызова и журналов.
Среда исполнения на Compute Cloud с самостоятельно размещенной моделью
Применимость и статус
Профиль применяется, если модель или среда исполнения ИИ размещены на ВМ или группе ВМ. Организация отвечает за образ, ОС, обновления, процесс, модельный загрузчик и прикладные журналы.
Поток и границы доверия
вход/балансировщик нагрузки/API Gateway → ВМ и процесс → модель → диск/Object Storage/внешние сервисы. Отдельно рассматриваются облачная конфигурация ВМ, ОС, процесс и модельный комплект.
Рабочая идентичность и аутентификация
К ВМ привязывается сервисный аккаунт; приложение получает краткоживущий IAM-токен через сервис метаданных.
Субъект, создающий или изменяющий ВМ, отдельно имеет iam.serviceAccounts.user на выбранный сервисный аккаунт согласно инструкции привязки. Это право развертывания не является рабочей ролью приложения.
Облачная идентичность ВМ и пользователи ОС не смешиваются. Способ получения токена описан в инструкции аутентификации внутри ВМ.
Роли и область назначения
- Управление ВМ.
compute.operatorразрешает запуск, остановку и перезапуск, но не создание или изменение ВМ; для управления используетсяcompute.editorпо задаче. Развертывающей идентичности отдельно назначаетсяiam.serviceAccounts.userна привязанный сервисный аккаунт. Для публичного IP-адреса проверяется требуемое право VPC, включаяvpc.publicAdminтам, где оно необходимо. - KMS и Lockbox. Если используется пользовательский KMS-ключ, субъектам, которые создают зашифрованный диск или ВМ, подключают такой диск либо запускают или перезапускают ВМ, назначается
kms.keys.userна конкретный ключ согласно документации шифрования Compute Cloud;kms.adminне требуется как базовая роль. При получении значения из Lockbox сервисному аккаунту ВМ назначаетсяlockbox.payloadViewerна конкретный секрет, а для секрета с пользовательским KMS-ключом —kms.keys.encrypterDecrypterна этот ключ. Сервисный аккаунт ВМ не получает иных ролей, кроме необходимых целевым хранилищам и API. - OS Login. Пользователю или сервисному аккаунту назначается
compute.osLoginлибоcompute.osAdminLoginиresource-manager.auditorили выше на каталог ВМ;compute.operatorдобавляется только при подключении черезyc compute ssh. Роли и способ подключения сверяются с инструкцией OS Login. - SSH-ключи в метаданных. Если организация оставляет ветвь SSH-ключей в метаданных экземпляра, она фиксирует субъектов, ключи, процедуру отзыва и обоснование политики, не выдавая эту ветвь за OS Login.
Общая модель облачных ролей приведена в документации Compute Cloud.
Сеть
Фиксируются VPC, подсеть, группы безопасности, публичный IP, маршруты, NAT, балансировщики нагрузки и исходящий путь.
Сервис метаданных находится на 169.254.169.254. Получение токена через Amazon EC2 IMDSv1 отключается параметром aws-v1-http-token=DISABLED согласно требованию IAM 16 базового стандарта безопасности Yandex Cloud. Если приложению нужен IAM-токен сервисного аккаунта ВМ, используются метаданные GCE с gce-http-endpoint=enabled, gce-http-token=enabled и обязательным заголовком Metadata-Flavor: Google; если не нужен, эти две возможности отключаются. Подробнее в описании метаданных ВМ.
Секреты и учетные данные
В документированном пути ВМ + Lockbox user-data содержит только идентификатор секрета, IAM-токен берется из сервиса метаданных, а значение запрашивается через API сервисным аккаунтом ВМ с lockbox.payloadViewer на конкретный секрет. Для секрета с пользовательским KMS-ключом дополнительно проверяется kms.keys.encrypterDecrypter на ключ по модели доступа Lockbox.
Значение секрета не помещается в метаданные или образ.
Объекты конфигурации
Идентификаторы ВМ, диска, образа диска и снимка диска, ключ KMS, сервисный аккаунт, флаги метаданных, группы безопасности и публичные IP-адреса, маршруты, балансировщики нагрузки, cloud-init, ОС, среда исполнения, диспетчер процессов и идентификатор и хеш модельного комплекта.
Для административного доступа фиксируются режимы OS Login организации, значение serial_port_settings.ssh_authorization (OS_LOGIN или INSTANCE_METADATA) и, для существующей ВМ с вручную установленным агентом, enable-oslogin; значения и режимы сверяются с настройкой OS Login организации и инструкцией для существующей ВМ.
KMS-шифрование диска, образа или снимка выбирается при создании по документации Compute Cloud.
Телеметрия и слепые зоны
Audit Trails Compute Cloud покрывает опубликованные облачные операции, но не ОС и модельный процесс. Метрики Monitoring требуют доступной сервисной метрики, Yandex Unified Agent или прикладной инструментации; журналы ОС и приложения доставляются отдельно.
Положительная и отрицательная проверки
- Проверьте IAM, группы безопасности, маршруты, публичные IP-адреса,
aws-v1-http-token=DISABLED, выбранные флаги метаданных GCE и шифрование. Запрос токена безMetadata-Flavor: Googleдолжен завершиться отказом. - Для OS Login проверьте разрешенный вход с
compute.osLoginилиcompute.osAdminLogin, отказ после отзыва роли и отсутствие лишнегоcompute.operatorпри подключении не через CLI. - Для ветви
INSTANCE_METADATAпроверьте точный состав SSH-ключей и отзыв тестового ключа. - Выполните разрешенный и запрещенный сетевой/IAM-запрос.
- Получите и отзовите тестовый секрет. Проверьте отсутствие значения в образе и
user-data. - Сопоставьте событие управления, лог ОС или приложения и идентификатор корреляции.
- Проверьте восстановление или откат.
Что необходимо для реализации профиля
- Архитектура: входной путь, GPU/CPU, среда исполнения, процессная изоляция и хранилища.
- Политика: настройки защиты и обновления ОС, метаданные, KMS, резервные копии и срок хранения.
- Правовое решение: данные, модель и лицензия.
Вызов внешнего модельного API из Yandex Cloud
Применимость и статус
Профиль применяется, если запрос покидает Yandex Cloud и направляется поставщику модели или AI API. IAM не управляет учетной записью поставщика.
Поток и границы доверия
среда исполнения в Yandex Cloud → NAT/прокси/межсетевой экран → DNS/TLS эндпоинт поставщика → внешний API → ответ. Граница передачи данных находится до исходящего запроса, а ответ снова считается недоверенным.
Рабочая идентичность и аутентификация
Сервисный аккаунт Yandex Cloud получает внешние учетные данные из утвержденного хранилища. Учетная запись поставщика, ее роли и отзыв проверяются в системе поставщика по утвержденным договорным и техническим материалам, а не в IAM.
Роли и область назначения
Для среды исполнения указываются только роли Yandex Cloud на Lockbox, журнал, прокси и другие используемые ресурсы Yandex Cloud. Полномочия внешнего ключа документируются отдельно по операциям и модели поставщика.
Сеть
Фиксируются маршрут VPC, NAT, прокси или межсетевой экран, DNS и проверяемая конечная точка TLS. Маршрутизация VPC подтверждает следующий узел, но не список разрешенных FQDN или содержимого. Ограничение получателя реализуется фактическим прокси, межсетевым экраном или прикладным средством и проверяется отрицательным запросом.
Секреты и учетные данные
API-ключ, mTLS-ключ или иные учетные данные хранятся в Lockbox либо другом утвержденном специализированном хранилище. При использовании Lockbox применяется документированный путь доставки выбранной среды исполнения из ее профиля. Фиксируются владелец, идентификатор и версия секрета, срок, ротация и отзыв без значения.
Объекты конфигурации
Поставщик и эндпоинт модели, DNS/TLS, маршрут через прокси или межсетевой экран, схема передаваемых полей, ссылка на учетные данные, таймаут, повторы, механизм прерывания запросов (circuit breaker), квота, идентификатор корреляции, заявленные регион обработки, срок хранения и субподрядчики.
Телеметрия и слепые зоны
Журналы приложения и прокси вместе с Monitoring покрывают наблюдаемый клиентский путь. Audit Trails показывает только связанные операции Yandex Cloud, например доступ к секрету или изменение маршрута, но не обработку запроса внутри поставщика.
Положительная и отрицательная проверки
- Выполните разрешенный запрос на синтетических данных.
- Выполните запрос на неутвержденное имя хоста и вызов с отозванными учетными данными. Проверьте отказ DNS/TLS.
- Проверьте поведение при повторных ошибках или превышении лимита и при отправке лишнего поля.
- Свяжите записи приложения и прокси, не приписывая внешний отзыв IAM.
Что необходимо для реализации профиля
- Архитектура: поставщик, эндпоинт, среда исполнения, маршрут и резервный путь.
- Политика: список разрешенных получателей, таймауты, повторы, квоты и журналируемые поля.
- Правовое решение: правовое основание, персональные данные, срок и место хранения, трансграничная передача и субподрядчики.
Границы общих средств защиты
| Средство | Проверяемое состояние | За пределами средства |
|---|---|---|
| Smart Web Security | Документированные HTTP(S)-, WAF-, bot-правила и ограничение частоты | Семантическая проверка промпта и документная авторизация |
| Guardrails |
Модерация поддерживаемого входа и выхода; функция на стадии Preview | Схема ответа, IAM, маскирование или правовое основание |
| Audit Trails | Опубликованные события выбранных сервисов и операций | Полная прикладная трассировка и недокументированные события уровня данных |
| Cloud Logging | Прием и хранение отправленных записей с настроенным доступом и сроком | Универсальное удаление секретов и персональных данных из содержимого приложения |
| Monitoring | Метрика, условие алерта и уведомление | Автоматическая остановка опасной нагрузки |
| Сканер уязвимостей Container Registry | Уязвимости Docker-образа в пределах сканера | Поведение модели, веса, датасет, полный SBOM и происхождение выпуска |
| DSPM | Обнаружение поддерживаемых категорий в подключенных источниках | Преобразование исходных данных и правовой вывод |
| CIEM | Просмотр прямых, групповых и унаследованных назначений и отзыв доступа в пределах опубликованных ограничений; весь CIEM находится на стадии Preview | Решение, какое право избыточно по политике организации, и гарантированная доступность Preview-функции |
| YCDR | Сигналы сервиса Preview после одобрения доступа, установки отдельного коллектора для облака и настройки источников; для работы с расследованиями требуется ycdr.admin |
Гарантированная доступность и полнота телеметрии |
Сервисному аккаунту сканирования DSPM назначается dspm.worker и, для бакета с пользовательским KMS-ключом, kms.keys.decrypter согласно инструкции сканирования. Если доступ к бакету регулирует политика доступа, отдельно проверяются разрешение опубликованных IP-адресов Security Deck и успешное сканирование.
Для просмотра прав в CIEM требуется organization-manager.viewer на организацию или более широкая документированная роль; отзыв проверяется отдельно по документированным ролям и ограничениям.
Свидетельство YCDR включает одобрение доступа, конфигурацию отдельного коллектора для каждого облака, успешную передачу тестового события по TLS и привязку ycdr.admin; подробнее в обзоре YCDR и описании модели доступа.
Условия CIEM и YCDR не переносятся на весь Security Deck или его Alerts.