> ## Documentation Index > Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt > Use this file to discover all available pages before exploring further. # Руководство по открытию доступа к Gateway Открывайте 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 только для поддерживаемых поверхностей | | Привязка к tailnet/LAN | Выделенная частная сеть с известными устройствами | Аутентификация Gateway, allowlist в firewall, без публичного проброса портов | | Доверенный reverse proxy | SSO/OIDC организации перед Gateway | Аутентификация `trusted-proxy`, строгие `trustedProxies`, правила перезаписи/удаления заголовков, явно разрешенные пользователи | | Публичный интернет | Редкие развертывания с высоким риском | Прокси с учетом идентификации, TLS, ограничения частоты, строгие allowlist, изолированные неосновные сессии | Избегайте прямого публичного проброса портов к Gateway. Если вам нужен публичный доступ, поставьте перед ним прокси с учетом идентификации и сделайте этот прокси единственным сетевым путем к Gateway. ## Инвентаризация перед запуском Зафиксируйте это перед изменением политики bind, proxy, Tailscale или каналов: * Хост Gateway, пользователь ОС и каталог состояния. * URL Gateway и режим bind. * Режим аутентификации, источник токена/пароля или источник идентификации доверенного proxy. * Все включенные каналы и принимают ли они личные сообщения, группы или webhooks. * Агенты, доступные нелокальным отправителям. * Профиль инструментов, режим sandbox и политика повышенных инструментов для каждого доступного агента. * Внешние учетные данные, доступные этим агентам. * Расположение резервной копии для `~/.openclaw/openclaw.json` и учетных данных. Если боту может писать больше одного человека, считайте это общей делегированной властью над инструментами, а не изоляцией хоста для каждого пользователя. ## Базовые проверки Выполните их перед открытием доступа: ```bash theme={"theme":{"light":"min-light","dark":"min-dark"}} openclaw doctor openclaw security audit openclaw security audit --deep openclaw health ``` Сначала устраните критические находки. Предупреждения могут быть приемлемы только тогда, когда они намеренны и задокументированы для развертывания. Для удаленной проверки CLI передавайте учетные данные явно: ```bash theme={"theme":{"light":"min-light","dark":"min-dark"}} openclaw gateway probe --url ws://127.0.0.1:18789 --token "$OPENCLAW_GATEWAY_TOKEN" ``` Не предполагайте, что учетные данные из локальной конфигурации применяются к явно указанному удаленному URL. ## Минимальная безопасная базовая конфигурация Используйте эту форму как отправную точку для развертываний с открытым доступом: ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { 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 }, }, } ``` Затем расширяйте по одной мере контроля за раз. Например, добавьте allowlist для конкретного канала перед включением инструментов с возможностью записи или включите reverse proxy перед приемом удаленного трафика Control UI. Строгая базовая настройка `exec.security: "deny"` блокирует все вызовы exec, включая безопасную диагностику. Если диагностика или команды с низким риском обязательны, ослабляйте это только после выбора конкретных отправителей, агентов, команд и режима подтверждения, которые соответствуют вашей модели угроз. ## Доступ через личные сообщения и группы Каналы обмена сообщениями являются недоверенными поверхностями ввода. Перед разрешением личных сообщений или групп: * Предпочитайте `dmPolicy: "pairing"` или строгие списки `allowFrom`. * Избегайте `dmPolicy: "open"`, если не доверяете каждому отправителю. * Не сочетайте allowlist `"*"` с широким доступом к инструментам. * Требуйте упоминания в группах, если комната не находится под строгим контролем. * Используйте `session.dmScope: "per-channel-peer"`, когда несколько людей могут писать боту в личные сообщения. * Направляйте общие каналы к агентам с минимальным набором инструментов и без личных учетных данных. Pairing разрешает отправителю запускать бота. Он не делает этого отправителя отдельной границей безопасности хоста. ## Проверки reverse proxy Для прокси с учетом идентификации: * Прокси должен аутентифицировать пользователей перед пересылкой в Gateway. * Прямой доступ к порту Gateway должен быть заблокирован firewall или сетевой политикой. * `gateway.trustedProxies` должен содержать только исходные IP-адреса прокси. * Прокси должен удалять или перезаписывать предоставленные клиентом заголовки идентификации и пересылки. * `gateway.auth.trustedProxy.allowUsers` должен перечислять ожидаемых пользователей, когда прокси обслуживает больше одной аудитории. * Режим loopback-прокси на том же хосте должен использовать `allowLoopback` только тогда, когда локальным процессам доверяют и прокси владеет заголовками идентификации. Запустите `openclaw security audit --deep` после изменений proxy. Находки trusted-proxy намеренно имеют высокий сигнал, потому что прокси становится границей аутентификации. ## Проверка инструментов и sandbox Перед открытием агента для удаленных отправителей: * Подтвердите, какие сессии выполняются на хосте, а какие в sandbox. * Запретите host exec или требуйте подтверждения для него. * Держите повышенные инструменты отключенными, если они не нужны конкретному доверенному отправителю. * Избегайте инструментов browser, canvas, node, cron, gateway и session-spawn для открытых или полуоткрытых поверхностей обмена сообщениями. * Делайте bind mounts узкими и избегайте учетных данных, домашнего каталога, Docker socket и системных путей. * Используйте отдельные gateways, пользователей ОС или хосты для существенно разных границ доверия. Если удаленным пользователям нельзя полностью доверять, изоляция должна обеспечиваться отдельными развертываниями, а не только prompts или метками сессий. ## Проверка после изменений После каждого изменения доступа: 1. Повторно запустите `openclaw security audit --deep`. 2. Проверьте успешное авторизованное подключение. 3. Проверьте, что неавторизованный отправитель или браузерная сессия получают отказ. 4. Убедитесь, что логи редактируют секреты. 5. Убедитесь, что маршрутизация личных сообщений/групп достигает только нужного агента. 6. Убедитесь, что инструменты с высоким влиянием запрашивают подтверждение или запрещены. 7. Задокументируйте принятые остаточные предупреждения. Не переходите к следующему изменению доступа, пока текущее не будет понято. ## План отката Если Gateway может быть чрезмерно открыт: ```json5 theme={"theme":{"light":"min-light","dark":"min-dark"}} { 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 или маршруты reverse proxy. 2. Ротируйте токены/пароли Gateway и затронутые учетные данные интеграций. 3. Удалите `"*"` и неожиданных отправителей из allowlists. 4. Просмотрите недавние audit logs, историю запусков, вызовы инструментов и изменения конфигурации. 5. Повторно запустите `openclaw security audit --deep`. 6. Снова включите доступ по самой узкой схеме, которая удовлетворяет рабочему процессу. ## Контрольный список проверки * Gateway остается доступным только через loopback, если нет задокументированной причины. * Доступ не через loopback имеет аутентификацию, firewall и не имеет прямого публичного маршрута. * Развертывания trusted-proxy имеют строгие IP-адреса proxy и контроль заголовков. * Личные сообщения используют pairing или allowlists, а не открытый доступ по умолчанию. * Группы требуют упоминаний или явных allowlists. * Общие каналы не получают доступ к личным учетным данным. * Неосновные сессии выполняются в режиме sandbox. * Host exec и повышенные инструменты запрещены или требуют подтверждения. * Логи редактируют секреты. * Критические находки аудита устранены. * Шаги отката протестированы и задокументированы.