Безопасность

[!WARNING] Модель доверия персонального помощника: данное руководство предполагает одну доверенную границу оператора на шлюз (модель одного пользователя/персонального помощника). OpenClaw не является враждебной границей безопасности мультитенантности для нескольких конфликтующих пользователей, совместно использующих одного агента/шлюз. Если вам нужна работа со смешанным доверием или конфликтующими пользователями, разделите границы доверия (отдельный шлюз + учетные данные, в идеале отдельные пользователи/хосты ОС).

Сначала область: модель безопасности персонального помощника

Руководство по безопасности OpenClaw предполагает развертывание персонального помощника: одна доверенная граница оператора, потенциально много агентов.

• Поддерживаемая модель безопасности: один пользователь/граница доверия на шлюз (предпочтительно один пользователь/хост/VPS ОС на границу).
• Не является поддерживаемой границей безопасности: один общий шлюз/агент, используемый взаимно недоверенными или конфликтующими пользователями.
• Если требуется изоляция конфликтующих пользователей, разделите по границе доверия (отдельный шлюз + учетные данные и, в идеале, отдельные пользователи/хосты ОС).
• Если несколько недоверенных пользователей могут отправлять сообщения одному агенту с инструментами, считайте, что они разделяют одно и то же делегированное право на использование инструментов для этого агента.

На этой странице объясняется укрепление в рамках этой модели. Она не претендует на враждебную изоляцию мультитенантности на одном общем шлюзе.

Быстрая проверка: аудит безопасности openclaw

См. также: Формальная верификация (Модели безопасности) Запускайте это регулярно (особенно после изменения конфигурации или открытия сетевых поверхностей):

openclaw security audit
openclaw security audit --deep
openclaw security audit --fix
openclaw security audit --json

Он отмечает распространенные ошибки (раскрытие аутентификации шлюза, раскрытие управления браузером, расширенные списки разрешений, права файловой системы). OpenClaw — это и продукт, и эксперимент: вы подключаете поведение передовых моделей к реальным поверхностям обмена сообщениями и реальным инструментам. Не существует «идеально безопасной» настройки. Цель — быть осознанным в отношении:

• кто может общаться с вашим ботом
• где боту разрешено действовать
• к чему бот может получить доступ

Начните с минимального доступа, который все еще работает, а затем расширяйте его по мере роста уверенности.

Предположение о развертывании (важно)

OpenClaw предполагает, что хост и граница конфигурации являются доверенными:

• Если кто-то может изменить состояние/конфигурацию хоста шлюза (~/.openclaw, включая openclaw.json), считайте его доверенным оператором.
• Запуск одного шлюза для нескольких взаимно недоверенных/конфликтующих операторов не является рекомендуемой настройкой.
• Для команд со смешанным доверием разделите границы доверия с помощью отдельных шлюзов (или, как минимум, отдельных пользователей/хостов ОС).
• OpenClaw может запускать несколько экземпляров шлюза на одной машине, но рекомендуемые операции отдают предпочтение чистому разделению границ доверия.
• Рекомендуемая настройка по умолчанию: один пользователь на машину/хост (или VPS), один шлюз для этого пользователя и один или несколько агентов в этом шлюзе.
• Если несколько пользователей хотят использовать OpenClaw, используйте один VPS/хост на пользователя.

Практическое следствие (граница доверия оператора)

Внутри одного экземпляра шлюза аутентифицированный доступ оператора является доверенной ролью плоскости управления, а не ролью арендатора на пользователя.

• Операторы с доступом на чтение/к плоскости управления могут по замыслу просматривать метаданные/историю сеансов шлюза.
• Идентификаторы сеансов (sessionKey, ID сеансов, метки) — это селекторы маршрутизации, а не токены авторизации.
• Пример: ожидание изоляции на оператора для таких методов, как sessions.list, sessions.preview или chat.history, выходит за рамки этой модели.
• Если вам нужна изоляция конфликтующих пользователей, запускайте отдельные шлюзы на границу доверия.
• Несколько шлюзов на одной машине технически возможны, но не являются рекомендуемой базой для изоляции нескольких пользователей.

Модель персонального помощника (не мультитенантная шина)

OpenClaw разработан как модель безопасности персонального помощника: одна доверенная граница оператора, потенциально много агентов.

• Если несколько человек могут отправлять сообщения одному агенту с инструментами, каждый из них может управлять одним и тем же набором разрешений.
• Изоляция сеансов/памяти на пользователя помогает приватности, но не превращает общего агента в авторизацию хоста на пользователя.
• Если пользователи могут быть конфликтующими по отношению друг к другу, запускайте отдельные шлюзы (или отдельных пользователей/хостов ОС) на границу доверия.

Общая рабочая область Slack: реальный риск

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

• любой разрешенный отправитель может инициировать вызовы инструментов (exec, браузер, сетевые/файловые инструменты) в рамках политики агента;
• инъекция промпта/контента от одного отправителя может вызвать действия, влияющие на общее состояние, устройства или выводы;
• если у одного общего агента есть конфиденциальные учетные данные/файлы, любой разрешенный отправитель потенциально может управлять утечкой через использование инструментов.

Используйте отдельных агентов/шлюзы с минимальными инструментами для рабочих процессов команды; храните агентов с личными данными приватными.

Агент, общий для компании: допустимый шаблон

Это допустимо, когда все, использующие этого агента, находятся в одной границе доверия (например, одна команда компании) и агент строго ограничен бизнес-сферой.

• запустите его на выделенной машине/ВМ/контейнере;
• используйте выделенного пользователя ОС + выделенный браузер/профиль/учетные записи для этой среды выполнения;
• не входите в этой среде выполнения в личные учетные записи Apple/Google или личные профили менеджера паролей/браузера.

Если вы смешиваете личные и корпоративные идентификаторы в одной среде выполнения, вы разрушаете разделение и увеличиваете риск раскрытия личных данных.

Концепция доверия шлюза и узла

Рассматривайте шлюз и узел как один домен доверия оператора с разными ролями:

• Шлюз — это плоскость управления и поверхность политики (gateway.auth, политика инструментов, маршрутизация).
• Узел — это поверхность удаленного выполнения, связанная с этим шлюзом (команды, действия с устройствами, возможности локального хоста).
• Вызывающая сторона, аутентифицированная в шлюзе, считается доверенной в рамках шлюза. После сопряжения действия узла являются доверенными действиями оператора на этом узле.
• sessionKey — это селектор маршрутизации/контекста, а не авторизация на пользователя.
• Одобрения выполнения (список разрешений + запрос) — это ограничительные меры для намерений оператора, а не враждебная изоляция мультитенантности.

Если вам нужна изоляция конфликтующих пользователей, разделите границы доверия по пользователю/хосту ОС и запускайте отдельные шлюзы.

Матрица границ доверия

Используйте это как быструю модель при оценке рисков:

Не уязвимости по замыслу

Эти шаблоны часто сообщаются и обычно закрываются без действий, если не показан реальный обход границы:

• Цепочки, основанные только на инъекции промпта, без обхода политики/аутентификации/изоляции.
• Утверждения, предполагающие враждебную мультитенантную работу на одном общем хосте/конфигурации.
• Утверждения, классифицирующие нормальный доступ оператора на чтение (например, sessions.list/sessions.preview/chat.history) как IDOR в настройке общего шлюза.
• Результаты, связанные с развертыванием только на localhost (например, HSTS на шлюзе только для loopback).
• Результаты, связанные с подписью входящих веб-хуков Discord для входящих путей, которых нет в этом репозитории.
• Результаты «Отсутствует авторизация на пользователя», которые рассматривают sessionKey как токен аутентификации.

Контрольный список для исследователей перед отправкой

Перед открытием GHSA проверьте все это:

1. Воспроизведение все еще работает на последней ветке main или последнем релизе.
2. Отчет включает точный путь кода (файл, функция, диапазон строк) и протестированную версию/коммит.
3. Воздействие пересекает задокументированную границу доверия (не только инъекцию промпта).
4. Утверждение не указано в Вне области действия.
5. Существующие рекомендации были проверены на дубликаты (используйте канонический GHSA, когда применимо).
6. Предположения о развертывании явные (loopback/локальный против открытого, доверенные против недоверенных операторов).

Укрепленная базовая настройка за 60 секунд

Используйте эту базовую настройку сначала, а затем выборочно повторно включайте инструменты для доверенного агента:

{
  gateway: {
    mode: "local",
    bind: "loopback",
    auth: { mode: "token", token: "replace-with-long-random-token" },
  },
  session: {
    dmScope: "per-channel-peer",
  },
  tools: {
    profile: "messaging",
    deny: ["group:automation", "group:runtime", "group:fs", "sessions_spawn", "sessions_send"],
    fs: { workspaceOnly: true },
    exec: { security: "deny", ask: "always" },
    elevated: { enabled: false },
  },
  channels: {
    whatsapp: { dmPolicy: "pairing", groups: { "*": { requireMention: true } } },
  },
}

Это сохраняет шлюз только локальным, изолирует личные сообщения и по умолчанию отключает инструменты плоскости управления/среды выполнения.

Быстрое правило для общего входящего ящика

Если более одного человека могут отправлять личные сообщения вашему боту:

• Установите session.dmScope: "per-channel-peer" (или "per-account-channel-peer" для каналов с несколькими учетными записями).
• Сохраняйте dmPolicy: "pairing" или строгие списки разрешений.
• Никогда не сочетайте общие личные сообщения с широким доступом к инструментам.
• Это укрепляет совместные/общие входящие ящики, но не предназначено для враждебной изоляции совместных арендаторов, когда пользователи имеют общий доступ на запись к хосту/конфигурации.

Что проверяет аудит (высокоуровнево)

• Входящий доступ (политики личных сообщений, политики групп, списки разрешений): могут ли незнакомцы активировать бота?
• Радиус поражения инструментов (расширенные инструменты + открытые комнаты): может ли инъекция промпта превратиться в действия shell/файлов/сети?
• Сетевое воздействие (привязка/аутентификация шлюза, Tailscale Serve/Funnel, слабые/короткие токены аутентификации).
• Раскрытие управления браузером (удаленные узлы, порты ретрансляции, удаленные конечные точки CDP).
• Гигиена локального диска (права доступа, символьные ссылки, включаемые конфигурации, пути «синхронизированных папок»).
• Плагины (расширения существуют без явного списка разрешений).
• Дрейф/неправильная конфигурация политики (настроены параметры изоляции docker, но режим изоляции выключен; неэффективные шаблоны gateway.nodes.denyCommands, потому что сопоставление происходит только по точному имени команды (например, system.run) и не проверяет текст shell; опасные записи gateway.nodes.allowCommands; глобальный tools.profile="minimal" переопределен профилями на агента; инструменты плагинов расширений доступны при разрешительной политике инструментов).
• Дрейф ожиданий среды выполнения (например, tools.exec.host="sandbox" при выключенном режиме изоляции, что запускается непосредственно на хосте шлюза).
• Гигиена моделей (предупреждение, когда настроенные модели выглядят устаревшими; не жесткая блокировка).

Если вы запустите --deep, OpenClaw также пытается выполнить проверку живого шлюза по возможности.

Карта хранения учетных данных

Используйте это при аудите доступа или принятии решения о резервном копировании:

• WhatsApp: ~/.openclaw/credentials/whatsapp/<accountId>/creds.json
• Токен бота Telegram: конфигурация/env или channels.telegram.tokenFile
• Токен бота Discord: конфигурация/env или SecretRef (провайдеры env/файл/exec)
• Токены Slack: конфигурация/env (channels.slack.*)
• Списки разрешений для сопряжения:
  • ~/.openclaw/credentials/<channel>-allowFrom.json (учетная запись по умолчанию)
  • ~/.openclaw/credentials/<channel>-<accountId>-allowFrom.json (нестандартные учетные записи)
• Профили аутентификации моделей: ~/.openclaw/agents/<agentId>/agent/auth-profiles.json
• Полезная нагрузка секретов на основе файлов (опционально): ~/.openclaw/secrets.json
• Устаревший импорт OAuth: ~/.openclaw/credentials/oauth.json

Контрольный список аудита безопасности

Когда аудит выводит результаты, рассматривайте это как порядок приоритетов:

1. Все, что «открыто» + инструменты включены: сначала заблокируйте личные сообщения/группы (сопряжение/списки разрешений), затем ужесточите политику инструментов/изоляцию.
2. Публичное сетевое воздействие (привязка к LAN, Funnel, отсутствие аутентификации): исправьте немедленно.
3. Удаленное раскрытие управления браузером: рассматривайте это как доступ оператора (только tailnet, намеренно сопрягайте узлы, избегайте публичного воздействия).
4. Права доступа: убедитесь, что состояние/конфигурация/учетные данные/аутентификация не доступны для чтения группой/всем миром.
5. Плагины/расширения: загружайте только то, чему явно доверяете.
6. Выбор модели: предпочитайте современные, защищенные инструкциями модели для любого бота с инструментами.

Глоссарий аудита безопасности

Высокозначимые значения checkId, которые вы, скорее всего, увидите в реальных развертываниях (не исчерпывающе):

Control UI по HTTP

Control UI нужен безопасный контекст (HTTPS или localhost) для генерации идентификатора устройства. gateway.controlUi.allowInsecureAuth не обходит проверки безопасного контекста, идентификатора устройства или сопряжения устройств. Предпочитайте HTTPS (Tailscale Serve) или открывайте UI на 127.0.0.1. Только для аварийных сценариев, gateway.controlUi.dangerouslyDisableDeviceAuth отключает проверки идентификатора устройства полностью. Это серьезное понижение уровня безопасности; держите его выключенным, если вы не занимаетесь активной отладкой и можете быстро откатить. openclaw security audit предупреждает, когда эта настройка включена.

Сводка небезопасных или опасных флагов

openclaw security audit включает config.insecure_or_dangerous_flags, когда включены известные небезопасные/опасные переключатели отладки. Эта проверка в настоящее время агрегирует:

• gateway.controlUi.allowInsecureAuth=true
• gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true
• gateway.controlUi.dangerouslyDisableDeviceAuth=true
• hooks.gmail.allowUnsafeExternalContent=true
• hooks.mappings[<index>].allowUnsafeExternalContent=true
• tools.exec.applyPatch.workspaceOnly=false

Полные dangerous* / dangerously* ключи конфигурации, определенные в схеме конфигурации OpenClaw:

• gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback
• gateway.controlUi.dangerouslyDisableDeviceAuth
• browser.ssrfPolicy.dangerouslyAllowPrivateNetwork
• channels.discord.dangerouslyAllowNameMatching
• channels.discord.accounts.<accountId>.dangerouslyAllowNameMatching
• channels.slack.dangerouslyAllowNameMatching
• channels.slack.accounts.<accountId>.dangerouslyAllowNameMatching
• channels.googlechat.dangerouslyAllowNameMatching
• channels.googlechat.accounts.<accountId>.dangerouslyAllowNameMatching
• channels.msteams.dangerouslyAllowNameMatching
• channels.irc.dangerouslyAllowNameMatching (канал расширения)
• channels.irc.accounts.<accountId>.dangerouslyAllowNameMatching (канал расширения)
• channels.mattermost.dangerouslyAllowNameMatching (канал расширения)
• channels.mattermost.accounts.<accountId>.dangerouslyAllowNameMatching (канал расширения)
• agents.defaults.sandbox.docker.dangerouslyAllowReservedContainerTargets
• agents.defaults.sandbox.docker.dangerouslyAllowExternalBindSources
• agents.defaults.sandbox.docker.dangerouslyAllowContainerNamespaceJoin
• agents.list[<index>].sandbox.docker.dangerouslyAllowReservedContainerTargets
• agents.list[<index>].sandbox.docker.dangerouslyAllowExternalBindSources
• agents.list[<index>].sandbox.docker.dangerouslyAllowContainerNamespaceJoin

Конфигурация обратного прокси

Если вы запускаете шлюз за обратным прокси (nginx, Caddy, Traefik и т.д.), вы должны настроить gateway.trustedProxies для правильного определения IP-адреса клиента. Когда шлюз обнаруживает заголовки прокси от адреса, который не находится в trustedProxies, он не будет рассматривать соединения как локальных клиентов. Если аутентификация шлюза отключена, эти соединения отклоняются. Это предотвращает обход аутентификации, когда проксированные соединения в противном случае выглядели бы исходящими с localhost и получали автоматическое доверие.

gateway:
  trustedProxies:
    - "127.0.0.1" # если ваш прокси работает на localhost
  # Опционально. По умолчанию false.
  # Включайте только если ваш прокси не может предоставить X-Forwarded-For.
  allowRealIpFallback: false
  auth:
    mode: password
    password: ${OPENCLAW_GATEWAY_PASSWORD}

Когда trustedProxies настроен, шлюз использует X-Forwarded-For для определения IP-адреса клиента. X-Real-IP игнорируется по умолчанию, если явно не установлено gateway.allowRealIpFallback: true. Правильное поведение обратного прокси (перезаписать входящие заголовки переадресации):

proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Real-IP $remote_addr;

Неправильное поведение обратного прокси (добавить/сохранить ненадежные заголовки переадресации):

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Примечания по HSTS и источникам

• Шлюз OpenClaw в первую очередь локальный/loopback. Если вы завершаете TLS на обратном прокси, установите HSTS на домене HTTPS, обращенном к прокси.
• Если шлюз сам завершает HTTPS, вы можете установить gateway.http.securityHeaders.strictTransportSecurity для отправки заголовка HSTS из ответов OpenClaw.
• Подробное руководство по развертыванию находится в Аутентификация доверенного прокси.
• Для развертываний Control UI не на loopback, gateway.controlUi.allowedOrigins требуется по умолчанию.
• gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true включает режим резервного источника на основе заголовка Host; рассматривайте это как опасную политику, выбранную оператором.
• Рассматривайте поведение подмены DNS и заголовка хоста прокси как проблемы усиления защиты развертывания; держите trustedProxies узкими и избегайте прямого воздействия шлюза на публичный интернет.

Локальные логи сеансов хранятся на диске

OpenClaw хранит расшифровки сеансов на диске в ~/.openclaw/agents/<agentId>/sessions/*.jsonl. Это необходимо для непрерывности сеансов и (опционально) индексации памяти сеансов, но это также означает, что любой процесс/пользователь с доступом к файловой системе может читать эти логи. Рассматривайте доступ к диску как границу доверия и заблокируйте права доступа на ~/.openclaw (см.