Инструкция по предоставлению доступа к Gateway

​

Выберите схему предоставления доступа

​

Предварительная инвентаризация

• Хост Gateway, пользователь ОС и каталог состояния (по умолчанию ~/.openclaw).
• URL Gateway и режим привязки (gateway.bind; порт по умолчанию 18789).
• Режим аутентификации, источник токена/пароля или источник идентификации доверенного прокси.
• Каждый включённый канал и поддерживаемые им личные сообщения, группы или Webhook.
• Агенты, доступные нелокальным отправителям.
• Профиль инструментов, режим изоляции и политика инструментов с повышенными привилегиями для каждого доступного агента.
• Внешние учётные данные, доступные этим агентам.
• Расположение резервной копии ~/.openclaw/openclaw.json и учётных данных.

​

Базовые проверки

openclaw doctor
openclaw security audit
openclaw security audit --deep
openclaw health

openclaw gateway probe --url ws://127.0.0.1:18789 --token "$OPENCLAW_GATEWAY_TOKEN"

​

Минимальная безопасная базовая конфигурация

{
  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 },
  },
}

​

Доступ через личные сообщения и группы

• Предпочитайте 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 только для прокси на том же хосте, где локальные процессы являются доверенными, а заголовки идентификации контролируются прокси.

​

Проверка инструментов и изоляции

• Проверьте, какие сеансы выполняются на хосте, а какие — в изолированной среде.
• Запретите выполнение команд на хосте или требуйте подтверждения.
• Не включайте инструменты с повышенными привилегиями, если они не нужны конкретному доверенному отправителю.
• Не предоставляйте инструменты браузера, canvas, node, cron, gateway и создания сеансов для открытых или полуоткрытых поверхностей обмена сообщениями.
• Ограничивайте точки монтирования; избегайте путей к учётным данным, домашним каталогам, сокету Docker и системным ресурсам.
• Используйте отдельные экземпляры Gateway, пользователей ОС или хосты для существенно различающихся границ доверия.

​

Проверка после изменений

1. Повторно запустите openclaw security audit --deep.
2. Убедитесь, что авторизованное подключение успешно устанавливается.
3. Убедитесь, что неавторизованному отправителю или сеансу браузера отказано в доступе.
4. Убедитесь, что секреты скрываются в журналах.
5. Убедитесь, что маршрутизация личных сообщений и групп направляет сообщения только назначенному агенту.
6. Убедитесь, что инструменты с высоким уровнем воздействия запрашивают подтверждение или запрещены.
7. Задокументируйте принятые остаточные предупреждения.

​

План отката

{
  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-адреса прокси и контролируются заголовки.
• Для личных сообщений по умолчанию используются сопряжение или списки разрешений, а не открытый доступ.
• В группах требуются упоминания или явные списки разрешений.
• Общие каналы не имеют доступа к личным учётным данным.
• Сеансы, отличные от основного, выполняются в режиме изоляции.
• Выполнение команд на хосте и инструменты с повышенными привилегиями запрещены или требуют подтверждения.
• Секреты скрываются в журналах.
• Критические замечания аудита устранены.
• Шаги отката проверены и задокументированы.