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

Анализ инфраструктуры Яндекс Облака

После подключения рабочего каталога ИИ Студия может использовать разрешённые сервисы Яндекс Облака, работающие только для чтения, как источник фактических данных.

Цель этой функции — убрать необходимость вручную переходить между десятками экранов консоли ради простого вопроса:

Из чего вообще состоит наш проект?

или:

Почему эта ВМ имеет доступ в Интернет и какие ресурсы с ней связаны?

Главный принцип

ИИ Студия должна различать:

факт из Yandex Cloud
        ↓
связь нескольких фактов
        ↓
интерпретация модели
        ↓
рекомендация

Например:

  • VM status = RUNNING — факт;
  • VM находится в subnet X — факт;
  • subnet X использует route table Y — факт;
  • «эта ВМ относится к пользовательскому интерфейсу» — может быть только выводом по имени/labels;
  • «эту ВМ можно удалить» — опасная рекомендация, для которой одних метаданных недостаточно.

Warning

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

1. С чего начать анализ

Начните с инвентаризации.

Опиши рабочий каталог Яндекс Облака.
Сначала перечисли найденные классы ресурсов и их количество.
Затем покажи ключевые связи между ними.
Ничего не изменяй.
Если назначение ресурса нельзя определить по данным, пометь его как «назначение не определено».

Это лучше, чем сразу спрашивать:

Всё ли у нас правильно?

Потому что сначала нужно получить проверяемую картину состояния.

2. Compute облако

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

Типовые вопросы:

Какие виртуальные машины находятся в рабочем Folder?

Покажи только работающие виртуальные машины.
Для каждой укажи ID, имя, статус и известные сетевые интерфейсы.

Какие диски связаны с каждой виртуальной машиной?

Есть ли диски, которые не удалось связать с работающей ВМ?
Не называй их «неиспользуемыми», если этого нельзя доказать только по текущим метаданным.

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

Что обычно полезно смотреть

  • instance ID;
  • имя;
  • статус;
  • zone;
  • platform;
  • vCPU/RAM, если они доступны;
  • network interfaces;
  • attached disks;
  • labels;
  • instance group membership;
  • операции и квоты — если соответствующий метод опубликован интеграцией.

3. Virtual Private облако

Для сети полезнее не просто получить список объектов, а построить связи.

Пример:

Построй текстовую схему сети рабочего Folder:
- сети;
- подсети;
- CIDR;
- route tables;
- NAT gateways;
- security groups;
- публичные IP, если они доступны.

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

Другие запросы:

Какие подсети есть в проекте и какие CIDR они используют?

Какие security groups найдены и к каким ресурсам они относятся?

Есть ли публичные IP-адреса? Покажи ресурс-владелец, если связь можно определить.

Не просите «найти уязвимости» без критериев

Лучше:

Проверь сетевые метаданные по таким правилам:
1. публичный IP;
2. security group с очень широким источником;
3. маршрут по умолчанию через Internet/NAT gateway;
4. ресурсы без понятной связи по имени/labels.

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

4. IAM и права доступа

IAM-анализ особенно чувствителен к формулировкам.

Хорошие вопросы:

Какие access bindings видны на рабочем Folder?
Сгруппируй по subject и роли.

Найди назначения примитивных ролей editor/admin на рабочем Folder.
Не меняй их. Покажи только субъект, роль и область назначения.

Какие права назначены service account <имя>?
Если часть ролей наследуется сверху, укажи это отдельно, если источник позволяет определить.

Warning

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

5. Object Storage

Object Storage требует особенно аккуратного отношения, потому что некоторые viewer-роли могут разрешать читать содержимое объектов, а не только названия бакетов.

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

Безопасные административные запросы:

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

Покажи настройки versioning, encryption и lifecycle, если они доступны.

Какие бакеты имеют конфигурацию статического сайта?

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

6. Managed YDB и базы данных

Текущая базовая инфраструктурная интеграция включает Managed YDB метаданные.

Используйте её для вопросов уровня:

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

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

Разделяйте:

управляющая плоскость ресурса
≠
пользовательские данные внутри базы

7. Cloud Functions

Отдельный сервис интеграции умеет читать сведения о Cloud Functions.

Примеры:

Какие Cloud Functions созданы в рабочем каталоге?

Покажи версии функций, runtime и scaling policies.

Какие операции по функциям видны за последнее время?

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

8. Serverless Containers и Container Registry

Примеры:

Какие Serverless Containers существуют?
Покажи активные ревизии и основные параметры.

Какие образы/registry-связи можно определить для контейнеров?

Покажи назначенные права для контейнеров, если они доступны.

В зависимости от роли viewer могут быть видны переменные окружения ревизии. Это потенциально чувствительные данные.

Danger

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

9. Триггеры

Только для чтения интеграция позволяет анализировать serverless triggers.

Полезный запрос:

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

Это помогает понять event-driven архитектуру без ручного обхода интерфейса.

10. Workflows

Примеры:

Какие Workflows существуют и какие последние executions видны?

Есть ли завершившиеся ошибкой запуски Workflows?
Верни только факты из истории выполнения.

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

Текущий профиль не предназначен для запуска нового execution из чата.

11. API Шлюз

Можно анализировать:

  • список API шлюзs;
  • OpenAPI метаданные/specification там, где она доступна;
  • WebSocket метаданные;
  • операции;
  • права доступа.

Пример:

Какие API Gateway настроены?
Покажи публичные endpoints, если их можно достоверно определить из конфигурации.

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

12. Метаданные шлюза сервисов Яндекс Облака

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

Для обычного бизнес-пользователя этот раздел обычно не нужен.

Он полезен администраторам платформы для вопросов вида:

Какие gateway-конфигурации существуют и какие права на них назначены?

13. Data Catalog

Интеграция предусматривает поиск метаданных только для чтения Data Catalog и lineage.

Примеры:

Найди объекты данных, связанные с <название/термин>.

Покажи lineage для объекта <идентификатор>, если он доступен.

Какие связанные datasets/объекты видит каталог?

Data Catalog показывает метаданные. Это не означает автоматический доступ к содержимому каждой базы или таблицы.

14. Yandex Search API как отдельный сервис

Кроме собственного интернет-поиска Студии может быть опубликован сервис поиска Яндекса.

Это другой путь и другая настройка.

Не смешивайте:

  • обычный Web Search Студии через локальный поисковый контур;
  • Yandex Search API в составе YC-интеграции.

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

15. Составить архитектурное описание

Один из самых полезных сценариев:

На основании только фактически полученных данных подготовь описание инфраструктуры рабочего Folder.

Структура:
1. назначение каталога — только если можно определить;
2. вычислительные ресурсы;
3. сети;
4. хранилища;
5. serverless;
6. IAM;
7. связи ресурсов;
8. неизвестные/неоднозначные места.

Для каждого вывода отделяй «факт из YC» от «интерпретация».

16. Сравнить фактическую инфраструктуру с документацией

Комбинированный сценарий:

Получить фактическую конфигурацию нашего ресурса <...>.
Затем найти актуальную официальную документацию Яндекс Облака для этой функции.
Сравнить конфигурацию с текущими рекомендациями.
Не считать рекомендацией то, что не подтверждено официальным источником.

Это сильнее обычного веб-поиска: модель видит и ваше состояние, и актуальное правило.

17. Как проверять результат

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

1. Проверьте объект

ID, имя, каталог.

2. Проверьте исходный факт

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

3. Проверьте интерпретацию

Задайте модели вопрос:

Какие части предыдущего ответа были прямыми фактами из YC, а какие — твоими выводами?

18. Ограничения режима только для чтения

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

Но чтение тоже может раскрывать чувствительную информацию:

  • IP;
  • topology;
  • IAM bindings;
  • environment variables;
  • имена внутренних ресурсов;
  • object content при соответствующей роли;
  • OpenAPI specification;
  • labels с бизнес-данными.

Поэтому least privilege всё равно обязателен.

19. Когда ответ «ничего не найдено» нельзя считать фактом отсутствия

Причины:

  • другой каталог;
  • не хватает роли;
  • конкретный сервис не активирован;
  • API вернул ошибку;
  • модель выбрала не тот сервис;
  • фильтр запроса слишком узкий;
  • ресурс существует на другом уровне иерархии.

Правильный follow-up:

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

20. Готовый набор контрольных запросов

1. Покажи рабочий Folder и Cloud.
2. Перечисли ВМ.
3. Перечисли сети и подсети.
4. Перечисли диски.
5. Покажи публичные IP, если доступны.
6. Покажи IAM bindings на Folder.
7. Перечисли Functions.
8. Перечисли Serverless Containers.
9. Перечисли Workflows.
10. Составь карту связей и пометь предположения.

Сохраните этот набор как корпоративный smoke test интеграции.

Что дальше