Перейти к содержанию

Права служебной учётной записи

Интеграция с Яндекс Облаком работает от имени отдельной служебной учётной записи. Поэтому безопасность интеграции определяется сразу двумя независимыми уровнями:

  1. какими правами служебная учётная запись обладает в самом Яндекс Облаке;
  2. какие возможности разрешает этому пользователю серверная политика ИИ Студии.

Даже если интерфейс Студии показывает кнопку или сервис, Яндекс Облако всё равно проверяет IAM-права. И наоборот: даже если служебная учётная запись технически имеет более широкую роль, шлюз NiceSoft дополнительно ограничивает доступ рабочим каталог, пользовательской ролью и списком разрешённых операций только для чтения.

Important

Не используйте принцип «выдадим editor, чтобы точно заработало». Для стандартной интеграции ИИ Студии изменяющие роли не нужны.

Результат

После этой инструкции вы сможете:

  • выбрать минимальный набор ролей для интеграции;
  • отличить права инфраструктуры, Billing и Yandex AI;
  • понять, на какой ресурс назначается каждая роль;
  • проверить наследованные роли;
  • диагностировать 403 PERMISSION_DENIED без выдачи admin;
  • построить отдельные профили доступа для тестовой и рабочий-среды.

1. Главный принцип: least privilege

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

Для текущего продукта это означает прежде всего чтение:

получить список ресурсов
        ↓
прочитать конфигурацию
        ↓
прочитать разрешённые сервисные данные
        ↓
проанализировать их

а не:

создать / изменить / удалить / остановить / запустить / опубликовать

шлюз NiceSoft дополнительно принудительно ограничивает операции режимом только для чтения, но это не повод выдавать избыточные IAM-права.

Защита должна быть многослойной:

Yandex IAM
    ↓
NiceSoft Gateway RBAC
    ↓
read-only allow-list
    ↓
scope рабочего Folder
    ↓
доступ пользователя Студии

Если один уровень настроен ошибочно, остальные всё равно уменьшают последствия.

2. Два подхода к правам инфраструктуры

Для чтения инфраструктуры есть два практических подхода.

Вариант A. Простой базовый профиль только для чтения

Назначить служебной учётной записи примитивную роль:

viewer

на конкретный рабочий каталог.

Преимущества:

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

Недостаток:

  • роль распространяется сразу на широкий набор сервисов;
  • viewer даёт не только метаданные, но и доступ к сервисным данным в режиме чтения там, где сервис это поддерживает.

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

Вариант B. Строгий рабочий-профиль

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

Например:

Область Пример роли Что требуется Студии
Compute облако compute.viewer ВМ, диски, образы, снапшоты, группы, операции
VPC vpc.viewer сети, подсети, маршруты, адреса, NAT, security groups
Resource Manager resource-manager.viewer или resource-manager.auditor облака, каталоги, назначения ролей
Cloud Functions functions.viewer функции, триггеры, конфигурация, квоты
Object Storage — только конфигурация storage.configViewer бакеты, настройки, список объектов без чтения содержимого
Object Storage — с содержимым storage.viewer в том числе чтение содержимого объектов
Billing billing.accounts.viewer расходы и usage details
Yandex AI Studio ai.languageModels.user выполнение запросов к текстовым моделям

Это только примеры основных ролей. Если вы включаете дополнительные сервисы Студии — Serverless Containers, Workflows, API Gateway, Data Catalog и другие — подберите их роли просмотра и аудита по актуальному Справочнику ролей Яндекс Облако.

Tip

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

3. auditor и viewer — не одно и то же

Это особенно важно для корпоративного контура.

auditor

Предназначен для чтения:

  • метаданных;
  • конфигурации;
  • информации о ресурсах;
  • истории операций;
  • назначенных прав.

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

Пример: можно увидеть, что бакет существует и как он настроен, но не обязательно читать лежащие внутри данные.

viewer

Включает возможности auditor, но дополнительно может давать read-доступ к данным сервиса.

Поэтому утверждение:

«viewer безопасен, потому что даёт только чтение»

неполное.

Только для чтения защищает от изменения ресурса, но не от раскрытия информации.

4. Особый случай: Object Storage

Object Storage хорошо показывает разницу между конфигурационным и содержательным доступом.

storage.configViewer

Подходит, если помощнику нужно знать:

  • какие бакеты существуют;
  • какие объекты перечислены;
  • политики доступа;
  • CORS;
  • lifecycle;
  • versioning;
  • encryption settings;
  • метаданные.

При этом роль не предназначена для чтения содержимого объектов.

storage.viewer

Позволяет также читать данные внутри бакетов.

Это может быть оправдано, если пользователь действительно должен спрашивать:

Что находится в этом объекте?

или:

Проанализируй содержимое файла из бакета.

Но если требуется только инвентаризация, используйте более узкую роль.

Danger

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

5. На какой ресурс назначать роль

Одна из самых частых ошибок — правильная роль назначена не на тот объект.

В Яндекс Облаке права наследуются по иерархии:

Организация
    ↓
Облако
    ↓
Folder
    ↓
Ресурсы Folder

Если роль назначена на каталог, она применяется к поддерживающим наследование ресурсам этого каталога.

Если роль назначена на облако, она может распространиться на все каталоги облака.

Если роль назначена на Organization, область становится ещё шире.

Для ИИ Студии типичный безопасный выбор:

роль → конкретный рабочий Folder

а не:

роль → вся Organization

6. Почему на уровне облака роль обычно хуже на уровне каталога

Предположим, в одном облаке есть:

prod
stage
dev
security
finance

Если служебной учётной записи выдать viewer на облако, она потенциально сможет читать данные всех этих каталогов.

Но если Студия должна работать только с prod, безопаснее:

viewer → prod Folder

или ещё более узкие сервисные роли на prod.

Это уменьшает blast radius при компрометации ключа.

7. рабочий каталог и права

рабочий каталог — основная рабочая область интеграции.

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

Это не заменяет IAM.

Правильная модель:

Working Folder выбран в Студии
        +
service account имеет нужные IAM-права на этот Folder
        +
NiceSoft policy разрешает конкретную capability
        =
запрос работает

Если любой элемент отсутствует — действие должно завершиться отказом или пустым результатом.

8. идентификатор облака обычно определяется из каталога

В актуальном сценарии подключения главное значение — идентификатор каталога.

Студия проверяет каталог через API и определяет связанное облако.

Поэтому при привязка идентификатор облака может быть необязательным полем.

Если вы всё-таки указываете оба ID, они должны относиться друг к другу.

Ошибка вида:

Folder belongs to another Cloud

означает не проблему ключа, а несогласованность область доступа.

9. Billing — отдельная область прав

Доступ к ресурсам каталог не означает автоматически доступ к платёжный аккаунт.

Для FinOps используется отдельная роль:

billing.accounts.viewer

Она назначается на платёжный аккаунт.

Не на каталог.

Не на облако.

Не на объект служебной учётной записи.

Эта роль позволяет, среди прочего:

  • видеть данные платёжного аккаунта;
  • получать usage details;
  • контролировать расходы;
  • выполнять API-запросы детализации.

Для стандартного FinOps-профиля только для чтения не нужны billing.accounts.editor или billing.accounts.admin.

10. Почему billing.accounts.editor не нужен

billing.accounts.editor умеет значительно больше:

  • создавать бюджеты;
  • связывать облака;
  • работать с экспортами;
  • выполнять другие административные операции.

Студия не должна получать такие полномочия только ради просмотра затрат.

Для анализа расходов базовый профиль:

billing.accounts.viewer

11. платёжный аккаунт и рабочий каталог — разные сущности

платёжный аккаунт может обслуживать несколько облаков и множество каталог.

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

Но текущая политика NiceSoft для обычного пользователя дополнительно ограничивает финансовые запросы подключённым рабочим каталогом.

Логика:

Billing Account
   ├── Cloud A
   │    ├── Folder prod  ← paired Folder
   │    └── Folder dev
   └── Cloud B
        └── Folder analytics

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

12. Yandex AI Studio — отдельная роль

Для текстовых моделей Яндекса используется:

ai.languageModels.user

Эта роль позволяет использовать модели генерации текста, embeddings и классификаторы в AI Studio.

Назначать её нужно служебной учётной записи на каталоге AI Studio.

Warning

каталог AI Studio может не совпадать с рабочим каталогом интеграции инфраструктуры.

В Центре управления моделями Студия показывает каталог, который фактически используется для Yandex AI.

13. Почему ai.editor не нужен

Для обычной генерации текста не требуется право:

ai.editor

Оно значительно шире и включает управление дополнительными AI Studio ресурсами.

Для текущего text-only маршрута базовый профиль:

ai.languageModels.user

14. Три независимых область доступа

После полной настройки полезно представлять интеграцию как три независимых области:

Задача Где назначаются права Типичный базовый профиль
Анализ инфраструктуры рабочий каталог viewer или набор сервисных ролей просмотра/аудита
FinOps платёжный аккаунт billing.accounts.viewer
YandexGPT / Alice AI каталог AI Studio ai.languageModels.user

Если одна функция работает, это ничего не доказывает о другой.

Например:

Compute работает
Billing = 403
Yandex AI = 403

может быть абсолютно логичным состоянием при неполной настройке ролей.

15. Наследование ролей

Роль может быть назначена не непосредственно на каталог, а выше:

  • на облако;
  • на Organization.

Тогда она наследуется.

Поэтому при диагностике нельзя смотреть только назначения ролей самого каталог.

Нужно проверить:

Folder
Cloud
Organization

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

16. Access Policy может запретить разрешённое ролью действие

В Яндекс Облаке роль — не единственный уровень контроля.

Organization / облако / каталог могут иметь access policies.

Поэтому возможна ситуация:

роль есть
        ↓
permission формально входит в роль
        ↓
access policy запрещает операцию
        ↓
403

Не исправляйте такой 403 выдачей ещё более сильной роли до проверки policy.

17. USER и ADMIN внутри Студии

IAM-права служебная учётная запись — только первый уровень.

Второй уровень — права пользователя внутри ИИ Студии.

шлюз NiceSoft получает идентичность пользователя Студии и применяет серверную policy.

Это позволяет, например:

  • ADMIN видеть диагностические функции;
  • USER использовать только разрешённые категории;
  • ограничить Billing подключённым рабочим каталогом;
  • скрыть или запретить отдельный сервис;
  • блокировать неизвестный вызов независимо от IAM служебная учётная запись.

То есть:

service account permission ≠ permission каждого пользователя Студии

18. Почему нельзя полагаться только на интерфейс

Скрытая кнопка — не механизм безопасности.

Поэтому критические ограничения применяются серверная часть-ом.

Даже если пользователь сформирует запрос вручную или изменит JavaScript в браузере:

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

19. Рекомендуемый стартовый профиль

Для небольшого пилота, где требуется широкий анализ одного каталог:

Working Folder:
  viewer

Billing Account:
  billing.accounts.viewer     # только если нужен FinOps

AI Studio Folder:
  ai.languageModels.user      # только если нужен Yandex AI

Это понятный базовый профиль.

После успешного теста для рабочий можно заменить viewer на набор granular сервисные роли.

20. Рекомендуемый строгий профиль

Пример для компании, которой нужны только Compute, VPC и метаданные Object Storage:

Working Folder:
  compute.viewer
  vpc.viewer
  storage.configViewer
  resource-manager.auditor

Billing Account:
  billing.accounts.viewer     # если нужен FinOps

AI Studio Folder:
  ai.languageModels.user      # если нужен Yandex AI

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

Note

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

21. Отдельные служебная учётная запись для разных контуров

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

studio-infra-reader
studio-finops-reader
studio-ai-model-user

Это уменьшает blast radius, но усложняет эксплуатацию.

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

22. Не используйте личный аккаунт

Плохая схема:

личная учётная запись администратора
        ↓
личный OAuth / ручной токен
        ↓
production-интеграция

Проблемы:

  • сотрудник может уволиться;
  • сессия может истечь;
  • личные права часто чрезмерны;
  • сложнее аудит;
  • невозможно нормально отделить человека от приложения.

Правильно:

отдельный service account
        ↓
минимальные роли
        ↓
authorized key
        ↓
NiceSoft Gateway

23. Как назначить роль через консоль

Общий порядок:

  1. откройте ресурс, на котором должна действовать роль;
  2. откройте управление доступом;
  3. добавьте участника;
  4. выберите служебную учётную запись Студии;
  5. выберите необходимую роль;
  6. сохраните;
  7. подождите распространения IAM;
  8. повторите тест из Студии.

Главное — сначала открыть правильный ресурс.

Для billing.accounts.viewer это платёжный аккаунт.

Для ai.languageModels.user — каталог AI Studio.

Для compute.viewer — рабочий каталог или конкретный поддерживаемый ресурс.

24. Как назначить роль через CLI

Пример viewer на каталог:

yc resource-manager folder add-access-binding <FOLDER_ID> \
  --role viewer \
  --subject serviceAccount:<SERVICE_ACCOUNT_ID>

Пример compute.viewer:

yc resource-manager folder add-access-binding <FOLDER_ID> \
  --role compute.viewer \
  --subject serviceAccount:<SERVICE_ACCOUNT_ID>

Пример Yandex AI:

yc resource-manager folder add-access-binding <AI_STUDIO_FOLDER_ID> \
  --role ai.languageModels.user \
  --subject serviceAccount:<SERVICE_ACCOUNT_ID>

Для Billing удобнее использовать интерфейс Billing или соответствующий Billing API/CLI с учётом текущей документации Яндекс Облака.

25. Как проверить назначенные роли

Не ограничивайтесь вопросом:

Есть ли роль на каталог?

Проверьте:

  1. прямые bindings каталог;
  2. облако;
  3. Organization;
  4. платёжный аккаунт;
  5. отдельный каталог AI Studio;
  6. действующие access policies.

Для просмотра назначения ролей каталога CLI:

yc resource-manager folder list-access-bindings <FOLDER_ID>

Но помните: список прямых bindings не всегда показывает всю картину наследования.

26. Диагностика 403 PERMISSION_DENIED

Не начинайте с повышения роли.

Используйте порядок:

1. Какой сервис вернул 403?
2. Какой resource ID использовался?
3. Какая операция выполнялась?
4. Какой service account аутентифицирован?
5. Какая роль требуется?
6. На каком объекте она назначена?
7. Не должна ли она наследоваться?
8. Нет ли запрещающей access policy?
9. Не ограничивает ли NiceSoft Gateway пользователя дополнительно?

27. 403 Infrastructure

Если не читаются ВМ:

проверьте compute.viewer или эквивалентный доступ только для чтения на рабочий каталог.

Если не читаются сети:

проверьте vpc.viewer.

Если не читается Object Storage:

определите, требуется ли:

storage.configViewer

или действительно:

storage.viewer

Не повышайте доступ к содержимому бакетов без необходимости.

28. 403 Billing

Проверьте:

billing.accounts.viewer

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

Типичная ошибка:

billing.accounts.viewer назначен на Folder

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

29. 403 Yandex AI

Проверьте:

ai.languageModels.user

на каталог AI Studio, отображаемом в Центре управления моделями.

Не ориентируйтесь автоматически на подключённый рабочий каталог.

Очень частая ошибка:

роль выдана на рабочий Folder инфраструктуры
AI Studio Folder другой
→ 403

30. Почему выдача editor часто маскирует проблему

Допустим, 403 возник из-за неверного идентификатор каталога.

Вы выдаёте editor на всё облако.

Ошибка исчезает.

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

Результат:

  • интеграция работает;
  • least privilege нарушен;
  • blast radius вырос;
  • реальная ошибка область доступа осталась скрыта.

Поэтому диагностировать нужно причину, а не «лечить» 403 привилегиями.

31. Проверка после настройки прав

После изменения ролей выполните несколько положительных тестов.

Infrastructure

Перечисли виртуальные машины рабочего каталога.

Network

Какие сети, подсети и security groups существуют в рабочем каталоге?

Billing

Покажи расход рабочего каталога за текущий месяц.

Yandex AI

В Модели → Yandex AI нажмите Проверить доступ.

32. Обязательный отрицательный тест

Права считаются правильно настроенными только после проверки запрещённого сценария.

Например, попросите:

Останови эту виртуальную машину.

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

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

33. Проверка доступа к чувствительным данным

Для каждого подключаемого сервиса спросите:

Какие данные сможет прочитать служебная учётная запись при компрометации ключа?

Особенно внимательно проверяйте:

  • Object Storage;
  • базы данных;
  • Data Catalog;
  • IAM bindings;
  • Billing;
  • журналы и операции;
  • serverless environment метаданные.

Только для чтения не означает low sensitivity.

34. Периодическая ревизия

Права служебная учётная запись должны пересматриваться минимум:

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

Хорошая практика — хранить утверждённую матрица ролей рядом с эксплуатационной документацией.

35. Пример матрица ролей

Service account: nicesoft-ai-studio-prod

Working Folder: b1g...
  compute.viewer
  vpc.viewer
  resource-manager.auditor
  storage.configViewer

Billing Account: dn2...
  billing.accounts.viewer

AI Studio Folder: b1a...
  ai.languageModels.user

Forbidden:
  editor
  admin
  billing.accounts.editor
  billing.accounts.admin

Такую матрицу удобно проверять при аудите.

36. Что делать, если сервису внезапно понадобилось больше прав

Не повышайте роль сразу.

Сначала зафиксируйте:

какой пользовательский сценарий
какой сервис
какой API method
какое permission отсутствует
какие данные возвращаются
почему это необходимо бизнесу

Затем выберите максимально узкую сервисная роль.

После изменения повторите:

  • положительный тест;
  • отрицательный тест;
  • проверку область доступа;
  • анализ чувствительности данных.

37. Контрольный список администратора

Перед вводом интеграции в эксплуатацию проверьте:

  • служебная учётная запись отдельный и имеет понятное имя;
  • личные токены пользователей не используются;
  • рабочий каталог задан явно;
  • инфраструктурные роли назначены только на нужную область;
  • editor/admin отсутствуют без документированного исключения;
  • Billing имеет только billing.accounts.viewer;
  • Yandex AI имеет только необходимую роль;
  • Object Storage не даёт чтение содержимого без необходимости;
  • учтены унаследованные роли;
  • проверены access policies;
  • положительные тесты работают;
  • изменяющие операции отклоняются;
  • роль-модель зафиксирована в документации организации.

Официальная документация Яндекс Облака

Для финальной проверки используйте актуальные страницы Яндекс Облака:

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

Что дальше

После настройки IAM обязательно изучите Безопасный режим интеграции, а при любой ошибке доступа используйте Диагностику Яндекс Облака.