Политики администратора¶

Что вы узнаете¶

Политики определяют, какие действия Студия допускает независимо от поведения конкретной модели. В текущей версии они являются центральной частью корпоративной защиты: пользовательский интерфейс показывает действующий профиль, а фактические ограничения применяются на сервере.

1. Где посмотреть действующие политики¶

Откройте вкладку «Параметры».

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

Экран показывает ключевые состояния, например:

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

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

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

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

Поэтому правильная схема:

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

Внешний вид кнопки не является механизмом безопасности.

3. Уровни политик¶

3.1. Права на возможности¶

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

Примеры:

использование сервисов;
создание помощников;
веб-поиск;
память;
плановые задания.

3.2. Доступ к конкретному ресурсу¶

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

3.3. Политика подтверждения¶

Определяет, какие операции:

выполняются автоматически;
спрашивают человека;
запрещаются.

3.4. Серверный список разрешённых операций¶

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

3.5. Права внешней системы¶

Последний уровень — роли самой внешней системы.

4. Базовый профиль текущей поставки¶

Для 0.3.66 документируем следующий профиль.

Область	Политика
Яндекс Облако	системные операции только чтения
Изменение ресурсов Яндекс Облака	запрещено шлюзом
Выполнение произвольного серверного кода	запрещено
Создание внешних сервисов обычным пользователем	запрещено
Публикация пользователем внешнего сервиса	запрещена
Неизвестные операции	требуют подтверждения
Локальный веб-поиск	требует подтверждения
Утверждённое чтение YC	может выполняться автоматически

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

5. Роль пользователя и политика — разные вещи¶

Роль отвечает на вопрос:

Что этому пользователю вообще доступно?

Политика отвечает:

Как разрешённая возможность может выполняться?

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

6. Почему администратор тоже не должен обходить системный запрет¶

Администратор интерфейса — не обязательно суперпользователь всех подключённых систем.

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

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

7. Рекомендуемые профили¶

Строгий корпоративный¶

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

Исследовательский¶

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

Можно разрешить больше экспериментальных сервисов, но:

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

8. Как менять политику безопасно¶

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

Рекомендуемый процесс:

Описать требуемое изменение.
Указать угрозу или бизнес-причину.
Определить точную операцию, которую нужно разрешить.
Не расширять весь сервис, если достаточно одной операции.
Ограничить внешние права.
Обновить конфигурацию поверх базовой платформы.
Перезапустить или переопубликовать только необходимые компоненты.
Выполнить положительные и отрицательные испытания.
Обновить документацию.
Зафиксировать изменение в журнале релиза.

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

Для НайсСофт — ИИ Студии действует архитектурное правило:

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

Политики, интерфейс и интеграции реализуются через:

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

Это позволяет обновлять базовую платформу без ручного переноса большого форка.

10. Минимальные права внешней системы¶

Политика Студии не заменяет принцип минимальных прав.

Плохо:

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

Лучше:

ограничить внешнюю учётную запись чтением и дополнительно ограничить операции в Студии.

Так одна ошибка не разрушает всю модель безопасности.

11. Область должна фиксироваться сервером¶

Если пользователь может произвольно передать идентификатор любой организации, облака или проекта, роль «только чтение» может всё равно раскрыть слишком много данных.

Поэтому критичные области должны:

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

Именно так построено подключение рабочего каталога Яндекс Облака.

12. Политика для групп и ролей¶

При проектировании доступа используйте следующий порядок:

Сначала определите бизнес-роли.
Затем создайте группы пользователей.
Выдайте каждой роли только нужные классы функций.
Отдельно выдайте доступ к конкретным помощникам и сервисам.
Не используйте индивидуальные исключения там, где можно применить группу.
Регулярно пересматривайте группы.

Это упрощает отзыв доступа при переводе или увольнении сотрудника.

13. Пример матрицы доступа¶

Группа	Инфраструктура YC	Расходы YC	Документация YC	Собственные сервисы
Разработчики	чтение	нет	да	по необходимости
Эксплуатация	чтение	ограниченно	да	да
Финансы	нет	чтение	да	финансовые
Безопасность	чтение	по необходимости	да	диагностические
Обычные сотрудники	нет	нет	да	только утверждённые

Это пример, а не обязательная схема. Реальная матрица зависит от организации.

14. Журналирование¶

Для важного сервиса желательно фиксировать:

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

Не записывайте в обычный журнал:

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

15. Проверки после изменения политики¶

Минимальный набор:

Положительный тест¶

Разрешённое чтение действительно работает.

Отрицательный тест¶

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

Проверка области¶

Нельзя запросить данные за пределами разрешённой области.

Проверка роли¶

Пользователь без права не получает доступ.

Проверка подтверждения¶

Операция требуемого класса действительно останавливается перед выполнением.

Проверка прямого вызова¶

Запрет работает не только через кнопки интерфейса, но и на сервере.

16. Признаки слишком широкой политики¶

Пересмотрите настройки, если:

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

17. Признаки слишком строгой политики¶

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

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

Решение — не отключать защиту целиком, а:

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

18. Чек-лист администратора¶

Перед публикацией нового сервиса: