Четыре проверки перед действием
RBAC — управление доступом через роли: сотруднику дают права в соответствии с его рабочими обязанностями. В Студии допуск к действию зависит также от группы, личной привязки к исходной системе и прав в ней. Для изменения записей добавляются ограничения операции и подтверждение человеком.
Администратор управляет кругом доступных действий, сохраняя реальные права в исходной системе.
Как права выглядят в рабочей ситуации
Сотруднику юридического отдела можно разрешить искать договоры, а инженеру — видеть назначенный проект. Это не означает общего доступа к документам друг друга. Администратор управляет ролями и группами, личный профиль подключения принадлежит сотруднику, а исходная система проверяет собственные права. Операции изменения и регулярные задания проходят дополнительные ограничения и фиксируются в журнале.
Один и тот же помощник выполняет только действия, доступные конкретному сотруднику и разрешённые политикой.
Роли администратора и обычного сотрудника
Администратор создаёт и блокирует учётные записи, назначает роли и группы, проверяет доступ к подключениям, конфигурацию и журнал. Обычный сотрудник работает со своими задачами и персональными подключениями в пределах разрешений. Роль администратора сама по себе не подменяет права корпоративной базы или почтового сервера.
Названия ролей и состав групп нужно закрепить во внутреннем регламенте организации: типовой набор доступа не является описанием полномочий вашего юридического или финансового отдела.
Прозрачнее разделение между тем, кто настраивает систему, и тем, кто выполняет рабочую задачу.
Создание, группа и отзыв доступа
Центр пользователей показывает участников, их статус и группы. Ответственный добавляет сотрудника, назначает доступ и может его заблокировать. Для увольнения или смены должности нужен также отзыв личных ключей и прав в исходных системах: одного изменения роли в Студии недостаточно.
Проще пересматривать доступы при кадровых изменениях и проводить внутренние проверки.
Личные подключения вместо общего ключа
К почте, Яндекс 360, Git-системе или другой системе сотрудник подключается под выделенными ему полномочиями. Студия не должна выдавать всем пользователям единый ключ администратора к важным данным. При необходимости токен можно отозвать и подключить заново.
Для сервисного подключения к инфраструктуре отдельно настраиваются минимально необходимые права и зона видимости.
Действия привязываются к владельцу подключения, а ущерб от лишних прав ограничивается.
Чтение, запись и критические операции
Операции классифицируются как чтение, создание, изменение и административные действия. Чтение удобно для поиска и сводок; отправка письма, создание задачи и изменение статуса требуют более строгой политики. В некоторых подключениях запись доступна только администратору и после просмотра параметров операции.
Подтверждение в интерактивном диалоге и запуск без человека по расписанию — разные режимы. При проектировании автоматизации нужно проверить, какие операции допустимы именно для автономного выполнения, и согласовать получателей и пределы действия.
Случайная просьба помощнику не становится автоматически правом изменить данные компании.
Журнал, границы и реальные ограничения
Проверка обращения к шлюзу и журнал действий помогают расследовать, кто запросил действие и что произошло. Права исходной системы и сети остаются отдельным уровнем защиты. Организации необходимо настроить резервное копирование, сроки хранения журналов и контроль за внешними каналами по своей политике.
Не следует считать, что наличие ролей само по себе означает выполненные требования 152-ФЗ или защиту от всех видов недоверенного содержимого. Для критических процессов нужны испытания и правила подтверждения.
Яндекс Облако: Стандарт безопасности ИИ описывает минимальные права инструментов, подтверждение критичных действий, защиту от вредоносных инструкций и аудит. Исследование и методика ↗
Яндекс Облако: Методология AI-SAFE рассматривает утечки, подмену инструкций, небезопасные инструменты и атаки на знания и агентов. Исследование и методика ↗
Проверяемые действия и ограниченные полномочия делают использование агентов управляемым.
Пример политики для трёх сотрудников
| Сотрудник | Данные | Разрешённая работа | Изменения |
|---|---|---|---|
| Юрист | Договоры своего отдела | Поиск, сравнение редакций, проект заключения | Публикация после согласования ответственным |
| Аналитик | Выделенная база только для чтения | Выборки с ограничением и сводки | Изменение записей недоступно |
| Администратор | Состояние инфраструктуры | Проверка конфигураций и журналов | Критическое действие по отдельному порядку |
Это пример внутреннего правила, а не автоматически созданная в продукте схема доступа: состав групп и полномочий задаёт организация.
Каждый сотрудник видит доступные ему инструменты, а политика следует за рабочей ролью.
Документы для проверки и внедрения.
Условия и эксплуатационные процедуры собраны в отдельном разделе: резюме и исходные документы по этой теме. Все 13 PDF доступны в общем каталоге документации.