--- read_when: - Отладка ошибок отсутствующей области доступа оператора - Проверка подтверждений сопряжения устройств или Node - Добавление или классификация методов RPC Gateway summary: Роли операторов, области доступа и проверки при подтверждении для клиентов Gateway title: Области действия операторов x-i18n: generated_at: "2026-07-16T16:22:49Z" model: gpt-5.6 postprocess_version: locale-links-v1 prompt_version: 32 provider: openai source_hash: 5e74cdd87d21a9e0eafea6b7e4b18ab2e5b74e6c570603b1d4ad4dff83c65619 source_path: gateway/operator-scopes.md workflow: 16 --- Области доступа оператора определяют, что клиент Gateway может делать после аутентификации. Это защитный механизм плоскости управления внутри одного доверенного операторского домена Gateway, а не изоляция от враждебных арендаторов. Для строгого разделения людей, команд или машин запускайте отдельные Gateway от имени разных пользователей ОС или на разных хостах. См. также: [Безопасность](/ru/gateway/security), [Протокол Gateway](/ru/gateway/protocol), [Сопряжение Gateway](/ru/gateway/pairing), [CLI устройств](/ru/cli/devices). ## Роли Каждый клиент Gateway WebSocket подключается с одной ролью: - `operator`: клиенты плоскости управления, такие как CLI, интерфейс управления, средства автоматизации и доверенные вспомогательные процессы. - `node`: узлы, предоставляющие возможности (macOS, iOS, Android, без графического интерфейса) и открывающие доступ к командам через `node.invoke`. Методы RPC оператора требуют роль `operator`; методы, инициированные узлом, требуют роль `node`. ## Уровни областей доступа | Область доступа | Значение | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `operator.read` | Состояние только для чтения, списки, каталог, журналы, чтение сеансов и другие вызовы, не изменяющие данные. | | `operator.write` | Изменяющие действия оператора: отправка сообщений, вызов инструментов, обновление настроек разговора и голоса, ретрансляция команд узлу. Также удовлетворяет `operator.read`. | | `operator.admin` | Административный доступ. Удовлетворяет требованиям любой области `operator.*`. Требуется для изменения конфигурации, обновлений, нативных хуков, зарезервированных пространств имён и подтверждения действий с высоким риском. | | `operator.pairing` | Управление сопряжением устройств и узлов: просмотр списка, подтверждение, отклонение, удаление, ротация и отзыв. | | `operator.approvals` | API подтверждения выполнения команд и плагинов. | | `operator.talk.secrets` | Чтение конфигурации разговора, включая секреты. | Неизвестные будущие области `operator.*` требуют точного совпадения, если вызывающая сторона ещё не имеет `operator.admin`. ## Область метода — лишь первый барьер У каждого RPC Gateway есть область метода с минимально необходимыми привилегиями, определяющая, достигнет ли запрос его обработчика. Затем некоторые обработчики применяют более строгие проверки в зависимости от конкретного подтверждаемого или изменяемого объекта: - `device.pair.approve` доступен при наличии `operator.pairing`, но подтверждение устройства оператора может создать или сохранить только те области, которыми уже обладает вызывающая сторона. - `node.pair.approve` доступен при наличии `operator.pairing`, после чего определяет дополнительные области подтверждения из заявленного списка команд ожидающего узла. - `chat.send` — метод с областью записи, но для команд чата `/config set` и `/config unset` дополнительно требуется `operator.admin`, независимо от области вызывающей стороны для отправки сообщений в чат. Это позволяет операторам с ограниченными областями выполнять низкорисковые действия сопряжения, не требуя административных прав для подтверждения любого сопряжения. ## Подтверждение сопряжения устройств Записи сопряжения устройств — долговременный источник подтверждённых ролей и областей. Уже сопряжённое устройство не получает более широкий доступ незаметно: при повторном подключении с запросом более широкой роли или областей создаётся новый ожидающий запрос на повышение доступа. При подтверждении запроса устройства: - Запрос без роли оператора не требует подтверждения областей оператора. - Запрос роли устройства, не являющейся операторской (например, `node`), требует `operator.admin`, хотя самому `device.pair.approve` требуется только `operator.pairing`. - Запрос `operator.read`, `operator.write`, `operator.approvals`, `operator.pairing` или `operator.talk.secrets` требует, чтобы вызывающая сторона уже имела эту область либо `operator.admin`. - Запрос `operator.admin` требует `operator.admin`. - Запрос восстановления без явно заданных областей может унаследовать области существующего токена оператора; если у этого токена административная область, для подтверждения всё равно требуется `operator.admin`. Сеансы с общим секретом без административных прав и сеансы доверенного прокси могут подтверждать запросы устройств оператора только в пределах собственных заявленных операторских областей; подтверждать неоператорские роли могут только администраторы, даже если такие сеансы в остальных случаях могут использовать `operator.pairing`. Для сеансов с токеном сопряжённого устройства управление ограничено собственным устройством, если у вызывающей стороны нет `operator.admin`: вызывающая сторона без административных прав видит только собственные записи сопряжения и может подтверждать, отклонять, ротировать, отзывать или удалять только запись собственного устройства. ## Подтверждение сопряжения узлов Устаревшие методы `node.pair.*` используют отдельное хранилище сопряжений узлов, принадлежащее Gateway. Вместо него узлы WS используют сопряжение устройств (`role: node`), но применяется тот же набор терминов подтверждения. Связь между двумя хранилищами описана в разделе [Сопряжение Gateway](/ru/gateway/pairing). `node.pair.approve` определяет дополнительные требуемые области из списка команд ожидающего запроса: | Заявленные команды | Требуемые области | | -------------------------------------------------------------------------------------------------------------------- | ------------------------------------- | | нет | `operator.pairing` | | обычные команды узла | `operator.pairing` + `operator.write` | | `system.run`, `system.run.prepare`, `system.which`, `browser.proxy`, `fs.listDir` или `system.execApprovals.get/set` | `operator.pairing` + `operator.admin` | Подтверждение декларации узла не включает команды, у которых есть отдельный барьер списка разрешений среды выполнения. Например, подтверждение узла, заявляющего `computer.act`, требует сопряжения и области записи, но лишь регистрирует доступную поверхность. Администратор или владелец всё равно должен активировать `computer.act`. Пока эта возможность активна, её вызов через метод `node.invoke` с областью записи не требует административной области для каждого действия. Сопряжение узла устанавливает идентичность и доверие; оно не заменяет собственную политику подтверждения выполнения `system.run` узла. ## Аутентификация с общим секретом Аутентификация по общему токену или паролю Gateway считается доверенным операторским доступом к этому Gateway. HTTP-интерфейсы, совместимые с OpenAI, `/tools/invoke` и HTTP- эндпоинты истории сеансов восстанавливают полный набор областей оператора по умолчанию при аутентификации предъявителя с общим секретом, даже если вызывающая сторона заявляет более узкие области. Режимы с идентификацией, такие как аутентификация через доверенный прокси или частный входной `none`, по-прежнему могут учитывать явно заявленные области. Для реального разделения границ доверия используйте отдельные Gateway.