--- read_when: - Предоставление доступа к Gateway через LAN, tailnet, Tailscale Serve, Funnel или обратный прокси - Проверка развертывания перед предоставлением доступа реальным пользователям обмена сообщениями - Откат рискованной конфигурации удалённого доступа или личных сообщений sidebarTitle: Exposure runbook summary: Контрольный список предварительных проверок и отката перед предоставлением доступа к Gateway OpenClaw за пределами loopback-интерфейса title: Инструкция по предоставлению доступа к Gateway x-i18n: generated_at: "2026-07-13T18:10:31Z" model: gpt-5.6 postprocess_version: locale-links-v1 prompt_version: 24 provider: openai source_hash: fb8e66af57e804325afc91281122b822183337177c734efe065c5fc18b175e72 source_path: gateway/security/exposure-runbook.md workflow: 16 --- Открывайте доступ к Gateway только после того, как сможете объяснить, кто может к нему подключаться, как выполняется аутентификация, каких агентов эти пользователи могут запускать и какие инструменты могут использовать эти агенты. Если есть сомнения, вернитесь к доступу только через loopback-интерфейс и повторно запустите аудит. Это руководство преобразует общие рекомендации из раздела [Безопасность](/ru/gateway/security) в контрольный список оператора для удалённого доступа и предоставления доступа через каналы обмена сообщениями. ## Выберите схему предоставления доступа Отдавайте предпочтение наиболее узкой схеме, удовлетворяющей требованиям рабочего процесса. | Схема | Рекомендуется, когда | Обязательные меры контроля | | -------------------------- | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------- | | Loopback + SSH-туннель | Личное использование, административный доступ, отладка | Сохраните `gateway.bind: "loopback"` и туннель `127.0.0.1:18789` | | Loopback + Tailscale Serve | Личный доступ из tailnet к Control UI/WebSocket | Оставьте Gateway доступным только через loopback-интерфейс; заголовки идентификации Tailscale аутентифицируют только поверхность WebSocket Control UI, но не другие пути аутентификации | | Привязка к tailnet/LAN | Выделенная частная сеть с известными устройствами | Аутентификация Gateway, список разрешённых адресов в межсетевом экране, отсутствие публичного перенаправления портов | | Доверенный обратный прокси | SSO/OIDC организации перед Gateway | Аутентификация `trusted-proxy`, строгий `trustedProxies`, правила перезаписи/удаления заголовков, явно разрешённые пользователи | | Публичный интернет | Редкие развёртывания с высоким риском | Прокси с учётом идентификации, TLS, ограничения частоты запросов, строгие списки разрешений, изолированные сеансы, отличные от основного | Не используйте прямое публичное перенаправление портов к Gateway. Если публичный доступ необходим, установите перед ним прокси с учётом идентификации и сделайте прокси единственным сетевым путём к Gateway. ## Предварительная инвентаризация Зафиксируйте следующие сведения перед изменением политики привязки, прокси, Tailscale или каналов: - Хост Gateway, пользователь ОС и каталог состояния (по умолчанию `~/.openclaw`). - URL Gateway и режим привязки (`gateway.bind`; порт по умолчанию `18789`). - Режим аутентификации, источник токена/пароля или источник идентификации доверенного прокси. - Каждый включённый канал и поддерживаемые им личные сообщения, группы или Webhook. - Агенты, доступные нелокальным отправителям. - Профиль инструментов, режим изоляции и политика инструментов с повышенными привилегиями для каждого доступного агента. - Внешние учётные данные, доступные этим агентам. - Расположение резервной копии `~/.openclaw/openclaw.json` и учётных данных. Если боту могут отправлять сообщения несколько человек, рассматривайте это как совместное делегирование полномочий на использование инструментов, а не как изоляцию на уровне хоста для каждого пользователя. ## Базовые проверки Выполните перед открытием доступа: ```bash openclaw doctor openclaw security audit openclaw security audit --deep openclaw health ``` Сначала устраните критические замечания. Принимайте предупреждения только в том случае, если они являются намеренными и задокументированы для данного развёртывания. Описание каждого `checkId` и соответствующего ключа исправления см. в разделе [Проверки аудита безопасности](/ru/gateway/security/audit-checks). Для удалённой проверки через CLI передавайте учётные данные явно: ```bash openclaw gateway probe --url ws://127.0.0.1:18789 --token "$OPENCLAW_GATEWAY_TOKEN" ``` Не предполагайте, что учётные данные из локальной конфигурации применяются к явно указанному удалённому URL. ## Минимальная безопасная базовая конфигурация Используйте следующую структуру в качестве отправной точки для развёртываний с внешним доступом: ```json5 { gateway: { bind: "loopback", auth: { mode: "token", token: "replace-with-a-long-random-token", }, }, session: { dmScope: "per-channel-peer", }, agents: { defaults: { sandbox: { mode: "non-main" }, }, }, tools: { profile: "messaging", exec: { security: "deny", ask: "always" }, elevated: { enabled: false }, }, } ``` Расширяйте по одной мере контроля за раз: добавьте список разрешений для конкретного канала перед включением инструментов с возможностью записи или включите обратный прокси перед приёмом удалённого трафика Control UI. `tools.exec.security: "deny"` блокирует все вызовы exec, включая безопасную диагностику. Если требуются диагностические команды или команды с низким уровнем риска, ослабляйте это ограничение только после выбора конкретных отправителей, агентов, команд и режима подтверждения, соответствующих вашей модели угроз. ## Доступ через личные сообщения и группы Каналы обмена сообщениями являются поверхностями для ввода недоверенных данных. Перед разрешением личных сообщений или групп: - Предпочитайте `dmPolicy: "pairing"` или строгий список `allowFrom` вместо `dmPolicy: "open"`. - Не сочетайте списки разрешений `"*"` с широким доступом к инструментам. - Требуйте упоминания в группах, если только доступ к комнате не контролируется строго. - Задайте `session.dmScope: "per-channel-peer"` (или `"per-account-channel-peer"` для каналов с несколькими учётными записями), если боту могут отправлять личные сообщения несколько человек, чтобы контекст сеансов личных сообщений не был общим. - Направляйте общие каналы агентам с минимальным набором инструментов и без личных учётных данных. Сопряжение разрешает отправителю запускать бота. Оно не создаёт для этого отправителя отдельную границу безопасности хоста. ## Проверки обратного прокси Для прокси с учётом идентификации: - Прокси должен аутентифицировать пользователей перед перенаправлением запросов к Gateway. - Межсетевой экран или сетевая политика должны блокировать прямой доступ к порту Gateway. - `gateway.trustedProxies` должен содержать только исходные IP-адреса прокси. - Прокси должен удалять или перезаписывать предоставленные клиентом заголовки идентификации и перенаправления. - Задайте `gateway.auth.trustedProxy.allowUsers`, если прокси обслуживает более одной аудитории. - Используйте `gateway.auth.trustedProxy.allowLoopback` только для прокси на том же хосте, где локальные процессы являются доверенными, а заголовки идентификации контролируются прокси. После изменения прокси запустите `openclaw security audit --deep`. Замечания, связанные с доверенным прокси, особенно важны, поскольку прокси становится границей аутентификации. ## Проверка инструментов и изоляции Перед предоставлением удалённым отправителям доступа к агенту: - Проверьте, какие сеансы выполняются на хосте, а какие — в изолированной среде. - Запретите выполнение команд на хосте или требуйте подтверждения. - Не включайте инструменты с повышенными привилегиями, если они не нужны конкретному доверенному отправителю. - Не предоставляйте инструменты браузера, canvas, node, cron, gateway и создания сеансов для открытых или полуоткрытых поверхностей обмена сообщениями. - Ограничивайте точки монтирования; избегайте путей к учётным данным, домашним каталогам, сокету Docker и системным ресурсам. - Используйте отдельные экземпляры Gateway, пользователей ОС или хосты для существенно различающихся границ доверия. Если удалённые пользователи не являются полностью доверенными, изоляцию необходимо обеспечивать отдельными развёртываниями, а не только инструкциями или метками сеансов. ## Проверка после изменений После каждого изменения внешнего доступа: 1. Повторно запустите `openclaw security audit --deep`. 2. Убедитесь, что авторизованное подключение успешно устанавливается. 3. Убедитесь, что неавторизованному отправителю или сеансу браузера отказано в доступе. 4. Убедитесь, что секреты скрываются в журналах. 5. Убедитесь, что маршрутизация личных сообщений и групп направляет сообщения только назначенному агенту. 6. Убедитесь, что инструменты с высоким уровнем воздействия запрашивают подтверждение или запрещены. 7. Задокументируйте принятые остаточные предупреждения. Не переходите к следующему изменению внешнего доступа, пока текущее изменение не будет полностью понятно. ## План отката Если Gateway может быть чрезмерно открыт: ```json5 { gateway: { bind: "loopback", }, channels: { whatsapp: { dmPolicy: "disabled" }, telegram: { dmPolicy: "disabled" }, discord: { dmPolicy: "disabled" }, slack: { dmPolicy: "disabled" }, }, tools: { exec: { security: "deny", ask: "always" }, elevated: { enabled: false }, }, } ``` Затем: 1. Остановите публичное перенаправление, Tailscale Funnel или маршруты обратного прокси. 2. Смените токены/пароли Gateway и затронутые учётные данные интеграций. 3. Удалите `"*"` и неожиданных отправителей из списков разрешений. 4. Проверьте последние журналы аудита, историю запусков, вызовы инструментов и изменения конфигурации. 5. Повторно запустите `openclaw security audit --deep`. 6. Повторно включите доступ, используя наиболее узкую схему, удовлетворяющую требованиям рабочего процесса. ## Контрольный список проверки - Gateway остаётся доступным только через loopback-интерфейс, если нет задокументированной причины для иного. - Доступ не через loopback-интерфейс защищён аутентификацией и межсетевым экраном и не имеет прямого публичного маршрута. - В развёртываниях с доверенным прокси строго ограничены IP-адреса прокси и контролируются заголовки. - Для личных сообщений по умолчанию используются сопряжение или списки разрешений, а не открытый доступ. - В группах требуются упоминания или явные списки разрешений. - Общие каналы не имеют доступа к личным учётным данным. - Сеансы, отличные от основного, выполняются в режиме изоляции. - Выполнение команд на хосте и инструменты с повышенными привилегиями запрещены или требуют подтверждения. - Секреты скрываются в журналах. - Критические замечания аудита устранены. - Шаги отката проверены и задокументированы.