Безопасность и доступ

27.04.2026 · 4 мин чтения · admin

OpenClaw работает как персональный ассистент. Безопасность строится вокруг модели «один доверенный оператор на Gateway».

Модель доверия

OpenClaw — это не система для нескольких враждебных пользователей. Это персональный ассистент: один оператор, один Gateway, несколько агентов.

Ключевые правила:

Один пользователь = одна машина = один Gateway. Если нескольким людям нужен доступ — каждому свой Gateway.

Кто может менять ~/.openclaw/ — тот и оператор. Файлы конфигурации и credentials определяют доверенный контур.

Gateway и ноды — один контур доверия. Gateway — контрольная плоскость, нода — удалённая поверхность исполнения.

Сессии (sessionKey) — это маршрутизаторы, не авторизация. Не используйте их как защиту.

Shared Slack workspace: реальный риск

Если «все в Slack могут писать боту» — основной риск делегированное управление инструментами:

Любой отправитель может вызвать exec, браузер, файловые инструменты в рамках политики агента

Prompt injection от одного отправителя может вызвать действия, затрагивающие общее состояние

Если у общего агента есть sensitive credentials — любой отправитель может вызвать утечку через инструменты

Решение: отдельные агенты/Gateway с минимальными инструментами для командных workflow. Личные агенты — приватными.

Company-shared agent: допустимый паттерн

Если все пользователи в одном контуре доверия (например, одна команда):

Выделенная машина/VM/контейнер

Выделенный OS-пользователь + выделенный браузер/профиль

Не входить в личные Apple/Google аккалы на этом runtime

Смешивание личных и рабочих аккаунтов на одном runtime увеличивает риск утечки персональных данных.

Быстрая проверка

openclaw security audit           # базовая проверка
openclaw security audit --deep    # глубокая проверка
openclaw security audit --fix     # исправить проблемы
openclaw security audit --json    # JSON-вывод

security audit --fix исправляет:

Открытые групповые политики → заменяет на allowlists

Восстанавливает logging.redactSensitive: "tools"

Ужимает права доступа к файлам state/config

Сбрасывает Windows ACL при необходимости

Кто может писать боту

Настройте dmPolicy для каждого канала:

pairing (по умолчанию) — новые отправители получают код одобрения

allowlist — только из списка allowFrom

open — всем (осторожно!)

disabled — никому

{
  channels: {
    telegram: {
      dmPolicy: "allowlist",
      allowFrom: ["tg:123456789"],
    },
  },
}

Авторизация Gateway

Gateway защищён токеном или паролем. При установке токен генерируется автоматически.

Если вы открываете Gateway наружу (Tailscale, публичный IP) — обязательно настройте авторизацию:

{
  gateway: {
    auth: {
      mode: "token",
      token: "ваш-секретный-токен",
    },
  },
}

Режимы авторизации: token, password, trusted-proxy.

Trusted Proxy Auth (аутентификация через прокси)

Когда OpenClaw работает за прокси с идентификацией (Pomerium, Caddy + OAuth, nginx + oauth2-proxy, Traefik), можно делегировать аутентификацию прокси.

Чувствительно к безопасности. Неправильная конфигурация может открыть несанкционированный доступ.

Когда использовать

Прокси обрабатывает OAuth/OIDC/SAML и передаёт идентификатор пользователя через заголовки
Kubernetes/контейнерная среда, где прокси — единственный путь к Gateway
Ошибки WebSocket 1008 unauthorized (браузеры не передают токены в WS payload)

Конфигурация

{
  gateway: {
    bind: "lan",
    trustedProxies: ["10.0.0.1"],  // только реальные IP прокси
    auth: {
      mode: "trusted-proxy",
      trustedProxy: {
        userHeader: "x-forwarded-user",
        requiredHeaders: ["x-forwarded-proto"],
        allowUsers: ["nick@example.com"],
      },
    },
  },
}

Примеры прокси

Pomerium	`x-pomerium-claim-email`
Caddy + OAuth	`x-forwarded-user`
nginx + oauth2-proxy	`x-auth-request-email`
Traefik + Forward Auth	`x-forwarded-user`

Важные правила

Trusted-proxy отклоняет loopback-запросы (127.0.0.1, ::1)
Не устанавливайте одновременно gateway.auth.token и trusted-proxy
trustedProxies — только реальные IP прокси, не подсети
Non-loopback Control UI требует явного gateway.controlUi.allowedOrigins

Чеклист безопасности

Порт Gateway закрыт файрволом от всего, кроме прокси
Прокси перезаписывает (не дополняет) заголовки x-forwarded-*
Прокси обрабатывает TLS; пользователи подключаются по HTTPS
allowUsers задан (ограничивает список пользователей)

Типичные ошибки

`trusted_proxy_untrusted_source`	Запрос не из `trustedProxies`
`trusted_proxy_loopback_source`	Loopback-прокси на том же хосте
`trusted_proxy_user_missing`	Заголовок пользователя пуст/отсутствует
`trusted_proxy_user_not_allowed`	Пользователь не в `allowUsers`

Авторизация провайдеров

API-ключи хранятся в ~/.openclaw/agents//agent/auth-profiles.json.

Настройка через env

export OPENAI_API_KEY="sk-..."
openclaw models status

Для systemd/daemon — кладите ключи в ~/.openclaw/.env:

cat >> ~/.openclaw/.env

Проверка авторизации

openclaw models status              # статус моделей
openclaw models status --check      # exit 1 если истёк/отсутствует
openclaw models status --probe      # live-probe авторизации

Claude CLI

Для Anthropic можно переиспользовать локальный логин Claude CLI:

claude auth login
openclaw models auth login --provider anthropic --method cli --set-default

Sandbox (изоляция)

По умолчанию агент выполняет код на вашей машине. Можно включить изоляцию:

{
  agents: {
    defaults: {
      sandbox: {
        mode: "non-main",   // off | non-main | all
        scope: "session",   // agent | session | shared
        backend: "docker",  // docker | ssh | openshell
      },
    },
  },
}

Что изолируется

Выполнение инструментов (exec, read, write, edit, apply_patch, process)

Опционально — браузер (sandbox.browser)

Что НЕ изолируется

Сам процесс Gateway

Elevated exec (tools.elevated) — обходит sandbox!

Режимы

Режим	Описание
`off`	Без sandbox
`non-main`	Sandbox только для не-main сессий
`all`	Все сессии в sandbox

Scope (область)

Scope	Описание
`agent`	Один контейнер на агента
`session`	Один контейнер на сессию
`shared`	Один контейнер на все sandbox-сессии

Бэкенды

Бэкенд	Где запускается	Настройка
Docker	Локальный контейнер	`scripts/sandbox-setup.sh`
SSH	Любой SSH-хост	SSH-ключ + целевой хост
OpenShell	Managed sandbox	Плагин OpenShell

OpenShell (managed sandbox)

OpenShell — облачная managed-песочница. Не требует Docker на хосте.

Быстрый старт

{
  agents: {
    defaults: {
      sandbox: {
        mode: "all",
        backend: "openshell",
        scope: "session",
        workspaceAccess: "rw",
      },
    },
  },
  plugins: {
    entries: {
      openshell: {
        enabled: true,
        config: {
          from: "openclaw",
          mode: "remote",
        },
      },
    },
  },
}

Проверка: openclaw sandbox list, openclaw sandbox explain.

Режимы рабочего пространства

	`mirror`	`remote`
Каноническое пространство	Локальный хост	Удалённый OpenShell
Синхронизация	Двунаправленная (каждый exec)	Однократная инициализация
Накладные расходы	Выше	Ниже
Локальные правки видны?	Да, при следующем exec	Нет, до recreate
Лучше для	Разработка	Долгоживущие агенты, CI

Конфигурация OpenShell

`mode`	`"mirror"` \| `"remote"`	`"mirror"`
`command`	Путь к CLI	`"openshell"`
`from`	Источник песочницы	`"openclaw"`
`gateway`	Имя шлюза OpenShell	—
`policy`	ID политики	—
`providers`	Провайдеры для подключения	`[]`
`gpu`	Запросить GPU	`false`
`timeoutSeconds`	Таймаут CLI	`120`

Управление

openclaw sandbox list        # все среды (Docker + OpenShell)
openclaw sandbox explain     # эффективная политика
openclaw sandbox recreate --all  # пересоздать

Пересоздавайте после изменения sandbox.backend, openshell.config.from, openshell.config.mode или openshell.config.policy.

Ограничения

Браузер в песочнице не поддерживается на OpenShell
sandbox.docker.binds не применяется к OpenShell

Elevated mode (повышенный режим)

Когда агент работает внутри песочницы, его команды exec ограничены средой песочницы. Повышенный режим (elevated mode) позволяет агенту выйти за пределы песочницы и выполнять команды на хосте.

Повышенный режим изменяет поведение только когда агент запущен в песочнице. Для агентов без песочницы exec и так выполняется на хосте.

Директивы

`/elevated on`	Выполнять вне песочницы, с подтверждениями
`/elevated full`	Выполнять вне песочницы, без подтверждений
`/elevated off`	Вернуться в песочницу

Сокращённый вариант: /elev on|off|full. Без аргумента — показать текущий уровень.

Конфигурация

{
  tools: {
    elevated: {
      enabled: true,
      allowFrom: {
        telegram: ["123456789"],
        whatsapp: ["+79001234567"],
      },
    },
  },
}

Порядок приоритета

Встроенная директива в сообщении (только для этого сообщения)
Переопределение сессии (отправка сообщения только с директивой)
Глобальное значение (agents.defaults.elevatedDefault)

Списки допуска

Глобально: tools.elevated.enabled + tools.elevated.allowFrom
Per-агент: agents.list[].tools.elevated (может только ограничивать)
Discord fallback: если tools.elevated.allowFrom.discord не указан, используется channels.discord.allowFrom

Что elevated НЕ контролирует

Политика инструментов: если exec запрещён политикой, elevated не переопределит
Выбор хоста: elevated не превращает auto в свободный кросс-хостный обход

Credential storage

Где лежат секреты:

Тип	Путь
WhatsApp	`~/.openclaw/credentials/whatsapp//creds.json`
Telegram	конфиг/env или `channels.telegram.tokenFile`
Discord	конфиг/env или SecretRef
Auth-профили	`~/.openclaw/agents//agent/auth-profiles.json`
Secrets (опц.)	`~/.openclaw/secrets.json`
Pairing	`~/.openclaw/credentials/-allowFrom.json`

Что дальше

Конфигурация Gateway — общие настройки

Сеть и удалённый доступ — SSH и Tailscale

Модель доверия

Быстрая проверка

Кто может писать боту

Авторизация Gateway

Trusted Proxy Auth (аутентификация через прокси)

Когда использовать

Конфигурация

Примеры прокси

Важные правила

Чеклист безопасности

Типичные ошибки

Авторизация провайдеров

Настройка через env

Проверка авторизации

Claude CLI

Sandbox (изоляция)

Что изолируется

Что НЕ изолируется

Режимы

Scope (область)

Бэкенды

OpenShell (managed sandbox)

Быстрый старт

Режимы рабочего пространства

Конфигурация OpenShell

Управление

Ограничения

Elevated mode (повышенный режим)

Директивы

Конфигурация

Порядок приоритета

Списки допуска

Что elevated НЕ контролирует

Credential storage

Рекомендации

Что дальше