> ## 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

> [!WARNING]
>
> Открывайте доступ к Gateway только после того, как сможете объяснить, кто может
> к нему подключаться, как выполняется аутентификация, каких агентов эти пользователи могут запускать
> и какие инструменты могут использовать эти агенты. Если есть сомнения, вернитесь к доступу
> только через loopback-интерфейс и повторно запустите аудит.

Это руководство преобразует общие рекомендации из раздела [Безопасность](https://docs2.openclaw.ai/ru/gateway/security.md) в
контрольный список оператора для удалённого доступа и предоставления доступа через каналы обмена сообщениями.

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

Отдавайте предпочтение наиболее узкой схеме, удовлетворяющей требованиям рабочего процесса.

| Схема | Рекомендуется, когда | Обязательные меры контроля |
| - | - | - |
| 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 theme={"theme":{"light":"min-light","dark":"min-dark"}}
openclaw doctor
openclaw security audit
openclaw security audit --deep
openclaw health
```

Сначала устраните критические замечания. Принимайте предупреждения только в том случае, если они являются намеренными и
задокументированы для данного развёртывания. Описание каждого `checkId` и соответствующего ключа исправления
см. в разделе [Проверки аудита безопасности](https://docs2.openclaw.ai/ru/gateway/security/audit-checks.md).

Для удалённой проверки через 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 },
  },
}
```

Расширяйте по одной мере контроля за раз: добавьте список разрешений для конкретного канала перед включением
инструментов с возможностью записи или включите обратный прокси перед приёмом удалённого трафика
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 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 или маршруты обратного прокси.
2. Смените токены/пароли Gateway и затронутые учётные данные интеграций.
3. Удалите `"*"` и неожиданных отправителей из списков разрешений.
4. Проверьте последние журналы аудита, историю запусков, вызовы инструментов и изменения конфигурации.
5. Повторно запустите `openclaw security audit --deep`.
6. Повторно включите доступ, используя наиболее узкую схему, удовлетворяющую требованиям рабочего процесса.

## Контрольный список проверки

* Gateway остаётся доступным только через loopback-интерфейс, если нет задокументированной причины для иного.
* Доступ не через loopback-интерфейс защищён аутентификацией и межсетевым экраном и не имеет прямого публичного маршрута.
* В развёртываниях с доверенным прокси строго ограничены IP-адреса прокси и контролируются заголовки.
* Для личных сообщений по умолчанию используются сопряжение или списки разрешений, а не открытый доступ.
* В группах требуются упоминания или явные списки разрешений.
* Общие каналы не имеют доступа к личным учётным данным.
* Сеансы, отличные от основного, выполняются в режиме изоляции.
* Выполнение команд на хосте и инструменты с повышенными привилегиями запрещены или требуют подтверждения.
* Секреты скрываются в журналах.
* Критические замечания аудита устранены.
* Шаги отката проверены и задокументированы.