Сервисы и политики¶

Что вы сделаете¶

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

1. Главный принцип¶

Модель может предложить действие.

Но модель не является источником полномочий.

Окончательное решение принимают:

права пользователя
        ↓
права роли
        ↓
серверная политика Студии
        ↓
права служебной учётной записи внешнего сервиса
        ↓
фактическая операция

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

2. Где смотреть корпоративную политику¶

Откройте административный раздел «Параметры».

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

Проверяйте как минимум:

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

3. Три результата проверки операции¶

Автоматически¶

Операция считается доверенной и разрешённой серверной политикой.

Пример:

получить список виртуальных машин

если сервис Яндекс Облака опубликован только на чтение.

С подтверждением¶

Перед выполнением пользователь видит запрос на подтверждение.

Пример:

обращение к неизвестному внешнему инструменту

Запрещено¶

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

Пример текущего продуктового профиля:

произвольное выполнение серверного кода

4. Почему подтверждение не заменяет запрет¶

Для опасной операции недостаточно показать кнопку:

«Вы уверены?»

Если операция по корпоративной политике вообще не допускается, правильное решение — не публиковать её модели или блокировать на сервере.

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

5. Сервисы Яндекс Облака¶

Текущий шлюз публикует утверждённый набор операций только чтения.

Защита строится несколькими слоями:

IAM Яндекс Облака
+
рабочий каталог
+
права роли Студии
+
разрешённый список операций шлюза
+
повторная проверка фактического вызова

Даже если интерфейс автоматически разрешает чтение, это не расширяет IAM-права служебной учётной записи.

6. Операции изменения в Яндекс Облаке¶

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

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

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

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

7. Интернет-поиск¶

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

Это полезно, если организация хочет, чтобы пользователь осознанно разрешал внешний сетевой запрос.

Администратор должен решить:

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

8. Неизвестные сервисы¶

Правило безопасного поведения:

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

До утверждения:

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

9. Пользовательское создание сервисов¶

В текущем корпоративном профиле обычному пользователю запрещено:

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

Это защита от неуправляемого вывода данных.

10. Подключение корпоративного сервиса администратором¶

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

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

Рекомендуемая схема:

ИИ Студия
    ↓
отдельный сервис НайсСофт/организации
    ↓
минимальная служебная учётная запись
    ↓
корпоративная система

Перед включением документируйте:

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

11. Классификация операций¶

Для каждой операции заполните таблицу:

Операция	Читает	Изменяет	Чувствительные данные	Подтверждение	Разрешена USER
Получить список	да	нет	возможно	по политике	да
Создать объект	да	да	возможно	обязательно/запрет	нет по умолчанию
Удалить объект	да	да	да	запрет или строгий процесс	нет

Не классифицируйте сервис целиком как «безопасный»: оценивайте каждую операцию.

12. Секреты сервиса¶

Секреты должны храниться на серверной стороне.

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

пароль;
закрытый ключ;
токен доступа;
строку подключения с паролем;
полный файл .env.

Если внешняя система поддерживает краткоживущие токены — предпочитайте их долгоживущим статическим секретам.

13. Сетевые ограничения¶

Даже корректно аутентифицированный сервис должен иметь только необходимые сетевые маршруты.

Проверяйте:

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

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

14. Подтверждение и плановые задания¶

Автоматический запуск помощника по расписанию не должен обходить политику подтверждений.

Если действие требует человека, плановое задание должно:

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

Не создавайте скрытый «автоматический ADMIN» для обхода этого ограничения.

15. Помощники¶

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

При запуске учитываются:

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

16. Изменение политики¶

Для любого ослабления:

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

17. Проверка после обновления¶

Обязательно повторите:

запрет кода;
запрет пользовательского создания внешних сервисов;
системный набор Яндекс Облака только чтения;
подтверждение интернет-поиска, если оно требуется;
подтверждение неизвестных сервисов;
роль USER;
роль ADMIN;
один помощник с сервисом.

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

18. Аварийное отключение сервиса¶

Для каждого внешнего сервиса должна существовать процедура:

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

Процедура должна быть известна до инцидента.

19. Приёмочные испытания нового сервиса¶

Минимум:

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

Что дальше¶

Для Яндекс Облака перейдите к административной интеграции. Для общих принципов см. Подключённые сервисы.