--- read_when: - Отладка ошибок отсутствующей области оператора - Проверка подтверждений сопряжения устройств или узлов - Добавление или классификация методов RPC Gateway summary: Роли операторов, области действия и проверки при одобрении для клиентов Gateway title: Области действия оператора x-i18n: generated_at: "2026-06-28T22:59:25Z" model: gpt-5.5 postprocess_version: locale-links-v1 provider: openai source_hash: dc59453ae1a73b52276185de2cedd1ed4da027111168eda8107d6ba0b74aec2f 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, Control UI, автоматизация и доверенные вспомогательные процессы. - `node`: хосты возможностей, такие как macOS, iOS, Android или узлы без графического интерфейса, которые предоставляют команды через `node.invoke`. Методы RPC оператора требуют роль `operator`. Методы, инициированные узлом, требуют роль `node`. ## Уровни областей доступа | Область доступа | Значение | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `operator.read` | Статус только для чтения, списки, каталог, журналы, чтение сеансов и другие неизменяющие вызовы плоскости управления. | | `operator.write` | Обычные изменяющие действия оператора, такие как отправка сообщений, вызов инструментов, обновление настроек речи/голоса и ретрансляция команд узла. Также удовлетворяет `operator.read`. | | `operator.admin` | Административный доступ к плоскости управления. Удовлетворяет любой области доступа `operator.*`. Требуется для изменения конфигурации, обновлений, нативных хуков, чувствительных зарезервированных пространств имен и подтверждений с высоким риском. | | `operator.pairing` | Управление сопряжением устройств и узлов, включая просмотр списка, подтверждение, отклонение, удаление, ротацию и отзыв записей сопряжения или токенов устройств. | | `operator.approvals` | API подтверждений exec и Plugin. | | `operator.talk.secrets` | Чтение конфигурации Talk с включенными секретами. | Неизвестные будущие области доступа `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`, но применяется тот же словарь уровней подтверждения. `node.pair.approve` использует список команд ожидающего запроса, чтобы вывести дополнительные требуемые области доступа: - Запрос без команд: `operator.pairing` - Не-exec команды узла: `operator.pairing` + `operator.write` - `system.run`, `system.run.prepare` или `system.which`: `operator.pairing` + `operator.admin` Сопряжение узлов устанавливает идентичность и доверие. Оно не заменяет собственную политику подтверждения exec для `system.run` узла. ## Аутентификация с общим секретом Аутентификация с общим токеном/паролем Gateway рассматривается как доверенный операторский доступ для этого Gateway. HTTP-поверхности, совместимые с OpenAI, `/tools/invoke` и HTTP-эндпоинты истории сеансов восстанавливают обычный полный набор областей доступа оператора по умолчанию для bearer-аутентификации с общим секретом, даже если вызывающий клиент отправляет более узкие объявленные области доступа. Режимы с идентичностью, такие как аутентификация через доверенный прокси или `none` для частного ingress, по-прежнему могут учитывать явно объявленные области доступа. Используйте отдельные Gateway для реального разделения границ доверия.