Yandex Cloud
Поиск
Связаться с экспертомПопробовать бесплатно
  • Кейсы
  • Документация
  • Блог
  • Все сервисы
    • Cloud Interconnect
    • Cloud Backup
    • Cloud Registry
    • Yandex AI Studio
    • Compute Cloud
    • Object Storage
    • Managed Service for Kubernetes®
    • Yandex BareMetal
    • Smart Web Security
    • Security Deck
    • Managed Service for PostgreSQL
    • Managed Service for ClickHouse®
    • Monium
    • Cloud CDN
    • Network Load Balancer
    • Virtual Private Cloud
    • Cloud DNS
    • Application Load Balancer
    • Yandex Cloud Video
    • Stackland
    • Yandex Cloud Router
    • Yandex Managed Service for Trino
    • Managed Service for MySQL®
    • Managed Service for Valkey™
    • Managed Service for Apache Spark™
    • Yandex StoreDoc
    • Managed Service for OpenSearch
    • Managed Service for Apache Kafka®
    • Data Transfer
    • Yandex MPP Analytics Engine for PostgreSQL
    • Yandex Managed Service for Apache Airflow®
    • Data Processing
    • Yandex MetaData Hub
    • Managed Service for YDB
    • Managed Service for Sharded PostgreSQL
    • Managed Service for YTsaurus
    • Yandex WebSQL
    • DataLens
    • Yandex Search API
    • SpeechSense
    • SpeechKit
    • DataSphere
    • Vision OCR
    • Translate
    • Yandex Neurosupport
    • VibeCraft
    • Yandex Cloud Detection and Response
    • Yandex Identity Hub
    • Key Management Service
    • Certificate Manager
    • Yandex Lockbox
    • Audit Trails
    • SmartCaptcha
    • Cloud Desktop
    • GOST Gateway
    • Yandex SIEM
    • SourceCraft Code Assistant
    • Container Registry
    • Managed Service for GitLab
    • SourceCraft
    • Managed Service for Prometheus®
    • Cloud Functions
    • API Gateway
    • Yandex Cloud Postbox
    • Message Queue
    • Serverless Integrations
    • IoT Core
    • Data Streams
    • Serverless Containers
    • Cloud Notification Service
    • Yandex Query
    • Identity and Access Management
    • Yandex Cloud Console
    • Resource Manager
    • Yandex Cloud Billing
    • Yandex Cloud Quota Manager
    • Cloud Apps
  • Статус работы сервисов
  • Marketplace
    • Популярные
    • Инфраструктура и сеть
    • Платформа данных
    • Искусственный интеллект
    • Безопасность
    • Инструменты DevOps
    • Бессерверные вычисления
    • Управление ресурсами
  • Все решения
    • По отраслям
    • По типу задач
    • Экономика платформы
    • Yandex Cloud Trust
    • Техническая поддержка
    • Каталог партнёров
    • Обучение и сертификация
    • Облако для стартапов
    • Облако для крупного бизнеса
    • Центр технологий для общества
    • Облако для интеграторов
    • Поддержка IT-бизнеса
    • Облако для фрилансеров
    • Обучение и сертификация
    • Блог
    • Документация
    • Контент-программа
    • Мероприятия и вебинары
    • Контакты, чаты и сообщества
    • Идеи
    • Калькулятор цен
    • Тарифы
    • Акции и free tier
  • Кейсы
  • Документация
  • Блог
Создавайте контент и получайте гранты!Готовы написать своё руководство? Участвуйте в контент-программе и получайте гранты на работу с облачными сервисами!
Подробнее о программе
Проект Яндекса
© 2026 ООО «Яндекс.Облако»
Безопасность в Yandex Cloud
  • Ключевые принципы безопасности
  • Разделение ответственности за обеспечение безопасности
  • Соответствие требованиям
  • Меры безопасности на стороне Yandex Cloud
  • Средства защиты, доступные пользователям облачных сервисов
    • Все разделы на одной странице
    • Введение
    • Безопасная архитектура и разработка ИИ-приложений
    • Данные, обучение, модели и выпуски
    • IAM, сеть, шифрование, секреты и аудит
    • Среда исполнения, RAG-хранилища и вывод из эксплуатации
    • Мониторинг и реагирование на инциденты
    • Агенты, инструменты, MCP и агентный RAG
    • Цепочка поставок
    • Профили реализации в Yandex Cloud
    • Соответствие требованиям и обработка персональных и регулируемых данных
    • Проверка и тестирование безопасности
    • Метрики внедрения и контроля стандарта
    • Безопасность систем искусственного интеллекта для финтех-организаций
  • Фреймворк безопасной работы с агентами AI-SAFE
  • Политика поддержки пользователей при проведении проверки уязвимостей
  • Бюллетени безопасности
  • Диапазоны публичных IP-адресов

В этой статье:

  • Управляемый инференс через AI Studio
  • RAG через AI Search
  • RAG через собственное хранилище
  • Managed Service for OpenSearch
  • YDB
  • Агент с MCP Gateway и инструментами
  • Обучение и эксперименты в DataSphere
  • Среда исполнения в Managed Service for Kubernetes
  • Среда исполнения в Serverless Containers или Cloud Functions
  • Serverless Containers
  • Cloud Functions
  • Среда исполнения на Compute Cloud с самостоятельно размещенной моделью
  • Вызов внешнего модельного API из Yandex Cloud
  • Границы общих средств защиты
  1. Стандарт безопасности для внедрения и эксплуатации ИИ-систем в Yandex Cloud, версия 1.0.0
  2. Профили реализации в Yandex Cloud

Профили реализации в Yandex Cloud

Статья создана
Yandex Cloud
Обновлена 16 сентября 2026 г.
Открыть в Markdown
  • Управляемый инференс через AI Studio
  • RAG через AI Search
  • RAG через собственное хранилище
    • Managed Service for OpenSearch
    • YDB
  • Агент с MCP Gateway и инструментами
  • Обучение и эксперименты в DataSphere
  • Среда исполнения в Managed Service for Kubernetes
  • Среда исполнения в Serverless Containers или Cloud Functions
    • Serverless Containers
    • Cloud Functions
  • Среда исполнения на Compute Cloud с самостоятельно размещенной моделью
  • Вызов внешнего модельного API из Yandex Cloud
  • Границы общих средств защиты

Профиль связывает требования с конкретным путем запроса и объектами Yandex Cloud. Профили не вводят новых требований — они показывают ресурсы, настройки и свидетельства для требований разделов:

  • Безопасная архитектура и разработка ИИ-приложений
  • Данные, обучение, модели и выпуски
  • IAM, сеть, шифрование, секреты и аудит
  • Среда исполнения, RAG-хранилища и вывод из эксплуатации
  • Мониторинг и реагирование на инциденты
  • Агенты, инструменты, MCP и агентный RAG
  • Цепочка поставок
  • Соответствие требованиям и обработка персональных и регулируемых данных

В одной системе могут одновременно применяться несколько профилей: например, приложение в Managed Service for Kubernetes вызывает AI Studio, использует AI Search и обращается к инструментам через MCP Gateway. Проверяющий объединяет профили по фактической архитектуре, не перенося свойства одного сервиса на другой.

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

Номера профилей в таблице являются примерами реализации, а не ограничением применимости. Применимость требования определяется условием архитектуры: контроли регулируемых данных действуют в любом профиле с потоком таких данных, проверки образов — во всех контейнерных средах исполнения, защита публичного периметра — в любом профиле с публичным HTTP(S)-входом.

Идентификатор требования

Применимые профили

Что проверить

Артефакт

AI-SDLC1

Все профили

Описание архитектуры, границы доверия, связь рисков с мерами

Описание архитектуры, диаграмма потоков данных, сопоставление с фактическими ресурсами, разница версий инвентаря, записи тестов, документ согласования

AI-APP-WAF1

Любой профиль с публичным HTTP(S)-входом, например:

  • Управляемый инференс через AI Studio
  • Среда исполнения в Serverless Containers или Cloud Functions
  • Среда исполнения на Compute Cloud с самостоятельно размещенной моделью

Прикладная валидация ввода до вызова модели; API Gateway + Smart Web Security при публичном входе

Записи отказов, конфигурация и хеш спецификации OpenAPI, идентификатор профиля Smart Web Security, тестовые запросы и их результат, подтверждение отсутствия последующего вызова

AI-CONTENT1

Управляемый инференс через AI Studio

Guardrails как объект конфигурации, роль ai.guardrails.editor, статус incomplete/content_filter

Версия и выгруженная конфигурация правила, идентификаторы экземпляра модели и Guardrail, тест блокирования, событие управления или прикладная запись

AI-CONTENT2

  • Управляемый инференс через AI Studio
  • Агент с MCP Gateway и инструментами
  • Среда исполнения в Managed Service for Kubernetes
  • Среда исполнения в Serverless Containers или Cloud Functions
  • Среда исполнения на Compute Cloud с самостоятельно размещенной моделью

Детерминированный валидатор вывода, отклонение запрещенного действия

Тестовые ответы модели, записи отклонения, код валидатора, хеш схемы и версия политики, подтверждение отсутствия вызова целевой системы

AI-CORE5

  • Управляемый инференс через AI Studio
  • RAG через AI Search
  • Среда исполнения на Compute Cloud с самостоятельно размещенной моделью

Отдельное хранение системных инструкций, версии, субъекты чтения/записи

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

AI-APP-INJECT1

  • Управляемый инференс через AI Studio
  • RAG через AI Search
  • Агент с MCP Gateway и инструментами

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

Тестовый документ с инструкцией, трассировка решения политики, идентификаторы результатов поиска, запись о карантине или переиндексации

AI-NET3

Вызов внешнего модельного API из Yandex Cloud

Утвержденные эндпоинты, рабочая идентичность, маршрут, таймауты, журнал

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

AI-NET7

Любой профиль с публичным HTTP(S)-входом, например:

  • Управляемый инференс через AI Studio
  • Среда исполнения в Serverless Containers или Cloud Functions
  • Среда исполнения на Compute Cloud с самостоятельно размещенной моделью

Домен, маршрут, аутентификация, лимиты, связь с бэкендом

OpenAPI-спецификация, запросы без учетных данных, тест обхода бэкенда, идентификаторы спецификации и профиля Smart Web Security, привязки, результаты HTTP-тестов

AI-DATA1

  • RAG через AI Search
  • RAG через собственное хранилище
  • Обучение и эксперименты в DataSphere

Реестр источника, владельца, назначения, связи с моделью или индексом

Запись реестра, прослеживание до объекта и версии, версия карточки, версия или хеш объекта, согласующий

AI-RAG-INGEST1

  • RAG через AI Search
  • RAG через собственное хранилище

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

Успешная загрузка утвержденного объекта, отказ для неутвержденного источника, версия загрузчика, события принятия и отклонения, запись о переиндексации

AI-DATA3

  • RAG через AI Search
  • RAG через собственное хранилище
  • Обучение и эксперименты в DataSphere
  • Среда исполнения на Compute Cloud с самостоятельно размещенной моделью

Разделение стадий, права записи, правила продвижения

Политики доступа к бакетам/префиксам, тест записи из рабочей среды, схема стадий, версии входа и выхода, журнал перехода

AI-DATA4

  • RAG через AI Search
  • Обучение и эксперименты в DataSphere
  • Вызов внешнего модельного API из Yandex Cloud

Классификация, минимизация, обратимость, ключи или таблица соответствия

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

AI-DATA5

  • RAG через AI Search
  • Обучение и эксперименты в DataSphere

Входные версии, метрики, пороги, разделение выборок

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

AI-DATA6

  • RAG через AI Search
  • RAG через собственное хранилище
  • Обучение и эксперименты в DataSphere

Контрольные суммы, доверенная идентичность, процедура допуска

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

AI-DATA7

Обучение и эксперименты в DataSphere

Регистрация генератора, доля, отдельная оценка

Запись о синтетической части, отчет с долей и контрольной выборкой, версия генератора, результат теста на отклонение немеченых данных

AI-TRAIN1

  • Обучение и эксперименты в DataSphere
  • Среда исполнения в Managed Service for Kubernetes
  • Среда исполнения на Compute Cloud с самостоятельно размещенной моделью

Разделение проектов, идентичностей, хранилищ, сетевых путей

Сопоставление контуров, тест чтения чужого секрета и записи в продуктив, хеши входных и выходных объектов задачи

AI-MODEL1

  • Управляемый инференс через AI Studio
  • Обучение и эксперименты в DataSphere
  • Среда исполнения на Compute Cloud с самостоятельно размещенной моделью

Источник, версия, контрольная сумма, статус допуска

Запись происхождения, сопоставление с работающим экземпляром, карточка модели, хеши и версии объектов в хранилище

AI-MODEL2

  • Обучение и эксперименты в DataSphere
  • Среда исполнения на Compute Cloud с самостоятельно размещенной моделью

Формат, загрузчик, изолированный запуск, контрольная сумма

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

AI-REL1

Все профили

Точные версии данных, модели, инструкций, конфигурации, образа

Решение о выпуске, сопоставление с продуктивной ревизией, хеш манифеста выпуска, событие развертывания

AI-REL2

Все профили

Совместимость, порядок замены, критерии отката, способ отзыва

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

AI-NET2

Все профили

Разрешенные входящие, исходящие, межкомпонентные соединения

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

AI-IAM-MFA1

Все профили

Усиленная аутентификация привилегированных пользователей

Перечень привилегированных ролей и групп, выгрузка эффективных прав, подтверждение состояния MFA или федеративной политики, срок исключения

AI-INFRA-CONSOLE1

Среда исполнения на Compute Cloud с самостоятельно размещенной моделью и любые профили с ВМ-компонентами

Отключение серийной консоли по умолчанию, аварийное включение только по исключению

Конфигурация ВМ или политики серийной консоли, отказ доступа, заявка и срок аварийного включения при наличии, события включения и отключения, журналы ОС или компенсирующий журнал

AI-IAM-LEASTPRIV1

Все профили

Отдельная рабочая идентичность, минимальная роль, область назначения

Эффективные прямые и унаследованные права, сопоставление роли с операцией, матрица субъект → операция → ресурс → роль или область действия → уровень привязки, маскированные области действия ключей

AI-IAM4

  • Управляемый инференс через AI Studio
  • Агент с MCP Gateway и инструментами

IAM-токен или API-ключ, роль, области действия, срок или пересмотр

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

AI-IAM5

Все профили

Периодичность пересмотра, охват прямых, групповых, унаследованных прав

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

AI-NET5

  • RAG через AI Search
  • RAG через собственное хранилище
  • Среда исполнения на Compute Cloud с самостоятельно размещенной моделью

Публичность хранилищ, точные идентификаторы, субъекты, сетевой путь

Эффективные привязки, ACL, тест чтения от разрешенного и неразрешенного субъекта, конфигурация публичного доступа и сети

AI-CRYPT1

  • RAG через AI Search
  • RAG через собственное хранилище
  • Среда исполнения на Compute Cloud с самостоятельно размещенной моделью

Режим шифрования, ключ, права на ключ, тест чтения штатной средой

Конфигурация шифрования, разрешенное чтение и отказ без права, идентификатор и привязки ключа, репетиция восстановления

AI-SECRET1

Все профили

Владелец, идентификатор, версия, потребители, доставка, срок, замена и отзыв

Сопоставление секрета с потребителем, тест отзыва и замены, привязки IAM и KMS, событие получения значения в Audit Trails, запись о ротации

AI-AUDIT1

Все профили

Перечень операций, источник события, область трейла, фильтры

Конфигурация трейла, безопасное тестовое действие и найденная запись, карта событий, спецификация трейла, тест отсутствующего события

AI-AUDIT2

Все профили

Удаление или преобразование секретов и ПДн до записи

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

AI-INFRA6

  • Среда исполнения в Managed Service for Kubernetes
  • Среда исполнения в Serverless Containers или Cloud Functions
  • Среда исполнения на Compute Cloud с самостоятельно размещенной моделью

Разделение идентичностей, сетевых путей, состояния, прав

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

AI-INFRA-ISOL2

  • Среда исполнения в Managed Service for Kubernetes
  • Среда исполнения в Serverless Containers или Cloud Functions
  • Среда исполнения на Compute Cloud с самостоятельно размещенной моделью

Создание и очистка временного состояния, граница процесса или экземпляра

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

AI-INFRA-ISOL3

  • Среда исполнения в Managed Service for Kubernetes
  • Среда исполнения в Serverless Containers или Cloud Functions
  • Среда исполнения на Compute Cloud с самостоятельно размещенной моделью

Отдельная среда, минимальная идентичность, лимиты, контроль сети

Разрешенная операция, тесты выхода за границы, завершение процесса, список разрешенных операций, подтверждение отсутствия побочных эффектов

AI-RAG-ACL2

  • RAG через AI Search
  • RAG через собственное хранилище

Документная авторизация до передачи фрагмента модели

Разрешенный поиск, попытка получить чужой документ, контекст модели, версия политики, манифест фактического контекста запроса

AI-DECOM1

Все профили

Полный инвентарь активных и резервных объектов, способ вывода

Версия инвентаря, акт завершения, тест вызова прежним способом, инвентаризация до и после, результат поиска остаточных объектов

AI-MON-ANOMALY2

Все профили

Сигналы, источник, окно, канал, действие

Конфигурация алерта, тест доставки, регистрация действия ответственного, идентификаторы дашборда и оповещения, временная шкала события, тикет реагирования

AI-MON-TRACE1

Все профили

Идентификатор корреляции, идентичность, версия модели, решение политики, инструмент

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

AI-MON-TRACE2

Агент с MCP Gateway и инструментами

Идентификаторы задачи и сессии, шаг, инструмент, результат

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

AI-FORENSIC2

Все профили

Состав, цель, срок, место, владелец, круг читателей

Сохраненная сессия, тест разрешенного и запрещенного чтения, область дела, результат удаления или запрета на удаление

AI-FORENSIC3

Все профили

Отделение от рабочих администраторов, разделение прав, целостность

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

AI-AGENT1

Агент с MCP Gateway и инструментами

Перечень инструментов, данных, получателей, максимальные последствия

Реестр возможностей, сопоставление с конфигурацией, версия реестра, тестовые события

AI-AGENT2

Агент с MCP Gateway и инструментами

Лимиты, точка контроля, безопасное состояние, условия остановки

Тест циклического ответа, повторяющейся ошибки, исчерпания лимита, версия политики и конфигурация счетчиков, итоговая причина остановки

AI-AGENT-GOAL1

Агент с MCP Gateway и инструментами

Доверенный источник цели, разделение фактов, предложений, инструкций

Тест расширения цели через пользователя, RAG, инструмент, версия цели и делегирование, подтверждение отсутствия вызова целевой системы

AI-IAM-LEASTPRIV3

Агент с MCP Gateway и инструментами

Отдельная идентичность инструмента, минимальные права, проверка бэкендом

Сопоставление бэкенда, сервисного аккаунта, ролей, тест подмены, матрица по инструментам, идентификаторы секретов

AI-IAM-COMPROMISE1

Агент с MCP Gateway и инструментами

Проверка пользователя, сессии, арендатора, контекст делегирования

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

AI-AGENT-HITL1

Агент с MCP Gateway и инструментами

Действия с существенными последствиями, показ цели и параметров

Тест действия без подтверждения, изменение параметра после подтверждения, идентификатор и хеш подтверждения, событие целевой системы

AI-MCP1

Агент с MCP Gateway и инструментами

Вызов, управление, привязки, сервисный аккаунт, целевой сервис

Конфигурация Gateway, разрешенный и запрещенный вызов, обход бэкенда, результат get и привязки шлюза, полная спецификация инструментов, состояние публичного доступа, область действия ключа API

AI-APP-INJECT2

Агент с MCP Gateway и инструментами

Проверяемый отправитель, версия схемы, срок, защита от повтора

Тесты с неверной схемой, истекшим сроком, повтором, подменой отправителя, идентичность и привязка отправителя, версии схемы и политики

AI-SUPPLY1

  • Обучение и эксперименты в DataSphere
  • Среда исполнения на Compute Cloud с самостоятельно размещенной моделью

Источник, автор, дата, версия, условия, контрольная сумма

Запись приемки, повторное получение и сопоставление суммы, исходный и внутренний хеши, тест карантина

AI-DATA-CHECK1

  • RAG через AI Search
  • RAG через собственное хранилище
  • Обучение и эксперименты в DataSphere

Автоматические и ручные проверки, карантин, ручное решение

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

AI-SUPPLY2

  • Обучение и эксперименты в DataSphere
  • Среда исполнения на Compute Cloud с самостоятельно размещенной моделью

Источник, контрольные суммы, формат, загрузчик, изолированный запуск

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

AI-SUPPLY3

  • Обучение и эксперименты в DataSphere
  • Среда исполнения на Compute Cloud с самостоятельно размещенной моделью

Заявка, проверка источника, целостность, поведенческие тесты, решение

Запись приемки, тест подмены контрольной суммы, пакет приемки и его хеш, подтверждение или исключение

AI-SUPPLY4

Все контейнерные среды исполнения:

  • Среда исполнения в Managed Service for Kubernetes
  • Среда исполнения в Serverless Containers или Cloud Functions
  • Среда исполнения на Compute Cloud с самостоятельно размещенной моделью

Перечень зависимостей, сведения об уязвимостях, срок исправления

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

AI-SUPPLY5

Все контейнерные среды исполнения:

  • Среда исполнения в Managed Service for Kubernetes
  • Среда исполнения в Serverless Containers или Cloud Functions
  • Среда исполнения на Compute Cloud с самостоятельно размещенной моделью

SBOM или манифест, состав, контрольные суммы

Сохраненный манифест, сравнение с фактическими объектами, хеш манифеста, карточки компонентов

AI-SUPPLY6

Все профили

Каналы уведомлений, процедура определения затронутых выпусков

Тестовое уведомление, поиск систем, решение об ограничении, затронутые манифесты выпусков, тикет

AI-COMPLY1

Все профили

Утвержденное решение, охват всех типов данных и получателей

Правовое решение и решение о соответствии требованиям, реестр сценариев, диаграмма потоков данных, идентификаторы потоков, пример трассировки

AI-COMPLY2

Все профили

Карта жизненного цикла, компоненты, регионы, копии, получатели

Карта потоков, реестр компонентов, инвентаризация ресурсов, тест неучтенной копии, выгрузки ресурсов, запись о миграции или удалении

AI-COMPLY3

Вызов внешнего модельного API из Yandex Cloud

Получатель, юрисдикция, эндпоинт, объем, условия, срок

Реестр получателей, конфигурация gateway, тест запрещенной передачи, идентификатор секрета, свидетельства провайдера, тест перенаправления

AI-COMPLY4

Вызов внешнего модельного API из Yandex Cloud

Решение уполномоченных представителей, сопоставление с ресурсами и маршрутами

Правовая оценка и оценка соответствия требованиям, реестр потоков, архитектурная схема, идентификаторы решений, отказ неизвестного ребра

AI-COMPLY-PII1

Любой профиль с потоком регулируемых данных, например:

  • Управляемый инференс через AI Studio
  • Вызов внешнего модельного API из Yandex Cloud

Обнаружение и преобразование до границы, обратимость, безопасное поведение

Политики преобразования, тест границы доверия, права на обратное преобразование, тип и версия преобразования, тесты остаточных полей и недоступности

AI-COMPLY-PII4

Любой профиль с потоком регулируемых данных, например:

  • Управляемый инференс через AI Studio
  • Обучение и эксперименты в DataSphere
  • Вызов внешнего модельного API из Yandex Cloud

Средства обнаружения, версионирование, тестовые наборы, мониторинг

Конфигурация DSPM/DLP, версии правил, результаты оценки качества, правила управления набором, версии детектора

AI-COMPLY-PII3

Любой профиль с защитным преобразованием регулируемых данных, например:

  • Управляемый инференс через AI Studio
  • Обучение и эксперименты в DataSphere
  • Вызов внешнего модельного API из Yandex Cloud

Минимальные привилегии, разделение обязанностей, журналирование без ПДн

IAM-политики, журналы преобразования, тесты отказоустойчивости, схема события, тесты недоступности и обхода

Управляемый инференс через AI StudioУправляемый инференс через AI Studio

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

Профиль применяется к управляемому API AI Studio. В архитектуре называется конкретная возможность: генерация текста, Responses, Realtime или другая документированная API-операция. Guardrails и политика авторизации IAM учитываются только при фактическом использовании; обе функции документированы как на стадии Preview и требуют отдельной проверки доступности.

Поток и границы доверия

пользователь → приложение или среда исполнения → 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. Они не гарантируют наличие полного промпта, ответа и сквозной прикладной корреляции; недостающую трассировку создает приложение. Экспорт и анализ настраиваются по официальной инструкции.

Положительная и отрицательная проверки

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

Что необходимо для реализации профиля

  • Архитектура: API, модель, среда исполнения и ветви данных.
  • Политика: IAM-токен или API-ключ, срок ключа, сетевые ограничения, правила и состав журналов.
  • Правовое решение: допустимые категории данных, цель, получатели и срок хранения.

RAG через AI SearchRAG через 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 Studio публикует searchindex.CreateSearchIndex, searchindex.UploadFilesToSearchIndex, searchindex.DeleteFilesFromSearchIndex и searchindex.DeleteSearchIndex. Отдельное событие изменения индекса и событие каждого поискового запроса в этом перечне не заявлены; права конечного пользователя и трассировку поиска с идентификаторами источников и решением авторизации записывает приложение.

Положительная и отрицательная проверки

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

Что необходимо для реализации профиля

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

RAG через собственное хранилищеRAG через собственное хранилище

Свойства Managed Service for OpenSearch и YDB различаются, поэтому они образуют два профиля. Для другого продукта владелец составляет отдельный профиль по тем же десяти полям; универсальная строка «иное хранилище» не является свидетельством.

Managed Service for OpenSearchManaged 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 и полноту контекста конечного пользователя.

Положительная и отрицательная проверки

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

Что необходимо для реализации профиля

  • Архитектура: индексы, среды загрузки и поиска и место документного ACL.
  • Политика: публичность, внутренние роли, KMS и сроки журналов.
  • Правовое решение: категории документов и допустимые получатели.

YDBYDB

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

Профиль применяется, если 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 записывает приложение или утвержденный слой запросов.

Положительная и отрицательная проверки

  1. Выполните разрешенное чтение и запрос чужого арендатора или строки.
  2. Выполните прямой запрос в обход API поиска и вызов с отозванными учетными данными.
  3. Отдельно покажите событие управления и прикладную трассировку запроса уровня данных.

Что необходимо для реализации профиля

  • Архитектура: режим базы, схема, индексы и ACL.
  • Политика: способ аутентификации, правила запросов и срок журналов.
  • Правовое решение: категории данных. Настройка KMS не заявляется без официального подтверждения для выбранной конфигурации YDB.

Агент с MCP Gateway и инструментамиАгент с 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 на каталог согласно инструкции создания; второе право разрешает привязку сервисного аккаунта и не является рабочей ролью Gateway.

Семантика остальных ролей берется из модели доступа AI Studio и обзора MCP Hub, а не выводится из названий.

Сеть

Фиксируются 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 Studio, включая mcp_hub.InvokeMcpTool, не доказывают полноту авторизации бэкенда, эффект на целевом ресурсе и содержимое ответа. Эти части связывает прикладная трассировка и журнал целевого сервиса.

Положительная и отрицательная проверки

Синтаксис диагностических команд берется из CLI-справочника MCP Gateway.

  1. Выполните list, get, list-access-bindings, list-operations.
  2. Проверьте вызов private Gateway с IAM-токеном или API-ключом и отказ без invoker.
  3. Проверьте доступ к выбранному внешнему или шаблонному серверу с требуемой дополнительной ролью и отказ без нее.
  4. Для public=true проверьте неаутентифицированный вызов и его запрет после отключения публичности.
  5. Дополнительно проверьте управляющую операцию из рабочей среды, превышение размера или схемы, прямой обход бэкенда, подтверждаемое действие и остановку цикла.

Что необходимо для реализации профиля

  • Архитектура: инструменты, бэкенды, целевые ресурсы и схема делегирования.
  • Политика: public/anonymous, approval, заголовки, размеры и лимиты цикла.
  • Правовое решение: внешние бэкенды и передаваемые категории данных.

Обучение и эксперименты в DataSphereОбучение и эксперименты в 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 покрывает опубликованные операции уровня управления. Метрики узлов и алиасов показывают эксплуатационное состояние, но не исполнение ячейки, содержимое данных, журнал промпта или полную цепочку происхождения; их закрывают журналы процесса и карточка происхождения.

Положительная и отрицательная проверки

  1. Выполните запуск от имени разрешенного и постороннего пользователя или сервисного аккаунта. Проверьте доступ задания к разрешенному и запрещенному ресурсу.
  2. Для ветви сервисного агента проверьте успешный API-вызов с токеном из SA_TOKEN_FILENAME, отказ после отзыва роли и отсутствие значения токена в параметрах и журналах.
  3. Проверьте исходящий путь пользовательской подсети, видимость секрета, срок данных задания и событие управления, не выводя токен или значение секрета.
  4. Проследите набор и модельный комплект до выпуска.

Что необходимо для реализации профиля

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

Среда исполнения в Managed Service for KubernetesСреда исполнения в 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; параметры приведены в инструкции изменения кластера. Состав записей ограничен опубликованной политикой аудита.

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

Положительная и отрицательная проверки

  1. Проверьте IAM и RBAC отдельно и выполните разрешенное и запрещенное действие API.
  2. Для федерации сервисных аккаунтов проверьте обмен токена разрешенного ресурса ServiceAccount в Kubernetes, отказ для другого пространства имен или ресурса ServiceAccount и отказ при удаленном исходящем маршруте или правиле к Yandex Cloud API.
  3. Проверьте запрос между пространствами имен, сетевую политику с запретом по умолчанию и эндпоинт метаданных.
  4. Проверьте получение и отзыв тестового секрета без вывода значения и дайджест образа.
  5. Проверьте событие аудита и корреляцию с журналом пода или приложения.

Что необходимо для реализации профиля

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

Среда исполнения в Serverless Containers или Cloud FunctionsСреда исполнения в Serverless Containers или Cloud Functions

Serverless Containers и Cloud Functions проверяются раздельно: ревизия контейнера и версия функции, роли управления, триггеры и журналы не взаимозаменяемы.

Serverless ContainersServerless 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 и не прикладное решение.

Положительная и отрицательная проверки

  1. Выполните вызов с ролью и без нее.
  2. Проверьте активную и предыдущую ревизии и операцию с целевым ресурсом от минимальной роли.
  3. Проверьте получение и отзыв тестового секрета с учетом кеша.
  4. Проверьте журнал запросов и откат.

Что необходимо для реализации профиля

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

Cloud FunctionsCloud 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 журналом каждого вызова.

Положительная и отрицательная проверки

  1. Выполните разрешенный и запрещенный вызов.
  2. Проверьте идентичность триггера, переключение версии и тега и отказ целевого ресурса.
  3. Проверьте получение и отзыв тестового секрета.
  4. Проверьте корреляцию идентификатора запроса и откат версии.

Что необходимо для реализации профиля

  • Архитектура: триггер, Gateway, версия и целевые ресурсы.
  • Политика: доступ, масштабирование, таймаут, редактирование содержимого журналов и срок хранения.
  • Правовое решение: содержимое вызова и журналов.

Среда исполнения на Compute Cloud с самостоятельно размещенной модельюСреда исполнения на 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 или прикладной инструментации; журналы ОС и приложения доставляются отдельно.

Положительная и отрицательная проверки

  1. Проверьте IAM, группы безопасности, маршруты, публичные IP-адреса, aws-v1-http-token=DISABLED, выбранные флаги метаданных GCE и шифрование. Запрос токена без Metadata-Flavor: Google должен завершиться отказом.
  2. Для OS Login проверьте разрешенный вход с compute.osLogin или compute.osAdminLogin, отказ после отзыва роли и отсутствие лишнего compute.operator при подключении не через CLI.
  3. Для ветви INSTANCE_METADATA проверьте точный состав SSH-ключей и отзыв тестового ключа.
  4. Выполните разрешенный и запрещенный сетевой/IAM-запрос.
  5. Получите и отзовите тестовый секрет. Проверьте отсутствие значения в образе и user-data.
  6. Сопоставьте событие управления, лог ОС или приложения и идентификатор корреляции.
  7. Проверьте восстановление или откат.

Что необходимо для реализации профиля

  • Архитектура: входной путь, GPU/CPU, среда исполнения, процессная изоляция и хранилища.
  • Политика: настройки защиты и обновления ОС, метаданные, KMS, резервные копии и срок хранения.
  • Правовое решение: данные, модель и лицензия.

Вызов внешнего модельного API из Yandex CloudВызов внешнего модельного 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, например доступ к секрету или изменение маршрута, но не обработку запроса внутри поставщика.

Положительная и отрицательная проверки

  1. Выполните разрешенный запрос на синтетических данных.
  2. Выполните запрос на неутвержденное имя хоста и вызов с отозванными учетными данными. Проверьте отказ DNS/TLS.
  3. Проверьте поведение при повторных ошибках или превышении лимита и при отправке лишнего поля.
  4. Свяжите записи приложения и прокси, не приписывая внешний отзыв 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.

Была ли статья полезна?

Предыдущая
Цепочка поставок
Следующая
Соответствие требованиям и обработка персональных и регулируемых данных
Создавайте контент и получайте гранты!Готовы написать своё руководство? Участвуйте в контент-программе и получайте гранты на работу с облачными сервисами!
Подробнее о программе
Проект Яндекса
© 2026 ООО «Яндекс.Облако»