Списки разрешений OpenClaw, парное подключение и безопасность упоминаний в группах

Именно полезные возможности OpenClaw делают модель безопасности столь важной. Шлюз может подключать каналы обмена сообщениями к агенту, который может выполнять команды оболочки, читать и записывать файлы, управлять браузером и отправлять сообщения. Базовый, но высокоэффективный сценарий отказа — это доступ ненадёжного или скомпрометированного отправителя к агенту с избыточными привилегиями; приведённые ниже меры контроля снижают этот риск наряду с традиционной безопасностью хоста, зависимостей, учётных данных и сети.

Правильный порядок действий в самом OpenClaw (документация по безопасности):

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

В данной статье предполагается, что вы уже установили шлюз (настройка личного шлюза).

dmPolicy="open" и groupPolicy="open" являются настройками крайнего случая. Предпочитайте сопряжение и белые списки, если вы не доверяете полностью каждому участнику, имеющему доступ к боту. Открытые личные сообщения с включенными инструментами представляют собой поверхность удаленного управления для публичного доступа.

Каждый одобренный отправитель может стать путем ко всему, что агент может прочитать: почта, файлы, сессии браузера, данные клиентов в инструментах. Одобряйте людей так же, как вы одобряете SSH-ключи — избирательно, с возможностью отзыва и с указанием конкретной причины.

Модель доверия в одном абзаце

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

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

Доступ к ЛС: сопряжение, белый список, открытый режим, отключено

Каждый канал, поддерживающий личные сообщения (ЛС), поддерживает политику ЛС (названия могут незначительно отличаться в зависимости от канала; см. текущую документацию):

Одобряйте осознанно:

openclaw pairing list <channel>
openclaw pairing approve <channel> <code>

Подробности: сопряжение.

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

Два уровня белых списков

1. Белый список прямых сообщений (DM) (allowFrom / эквиваленты для конкретных каналов)

Кто может писать боту в личные сообщения. В текущей версии OpenClaw строки ожидающих и одобренных отправителей хранятся в ~/.openclaw/state/openclaw.sqlite, с привязкой к каналу и аккаунту. Старые файлы JSON с учетными данными являются входными данными для миграции устаревших систем, а не текущим источником авторизации (документация по состоянию сопряжения). Относитесь к файлу SQLite как к чувствительному состоянию авторизации и регулярно создавайте его резервные копии вместе с состоянием шлюза.

2. Белый список групп

Какие группы/каналы/серверы бот принимает в принципе, а также кто может активировать его внутри группы (groupPolicy="allowlist" + groupAllowFrom на поддерживаемых каналах).

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

Пример структуры (адаптируйте стабильные идентификаторы отправителей и имена агентов под текущую схему канала):

{
  channels: {
    whatsapp: {
      dmPolicy: 'allowlist',
      allowFrom: ['+15555550123'],
      groupPolicy: 'allowlist',
      groupAllowFrom: ['+15555550123'],
      groups: { '<approved-group-id>': { requireMention: true } },
    },
  },
  agents: {
    list: [{ id: 'main', groupChat: { mentionPatterns: ['@openclaw'] } }],
  },
}

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

Упоминания в группах как элемент контроля безопасности

В активных группах агент, работающий в режиме постоянного прослушивания:

• Тратит токены на шум
• Реагирует на инъекции промптов, скрытые в шутках, вставленных логах или связанных страницах
• Раскрывает контекст между пользователями, которые находятся в одном чате, но не имеют общих границ доверия

Требуйте упоминание (или эквивалентную активацию), если только комната не является выделенным каналом агента со строго ограниченным списком участников.

Даже при наличии контроля через упоминания, недоверенный контент, который получает бот (веб-страницы, вложения, электронные письма), может содержать вредоносные инструкции. Инъекции промптов не решаются только системными инструкциями. Жесткие меры включают политику инструментов, согласования, изоляцию (sandboxing) и контроль того, кто вообще может общаться с ботом.

Для инъекции промптов не требуются публичные личные сообщения. Если ботом можете пользоваться только вы, но он имеет доступ к открытому вебу или общим почтовым ящикам, враждебный текст всё равно может поступать через результаты работы инструментов.

Изоляция сессий для личных сообщений от нескольких пользователей

Поведение по умолчанию может направлять личные сообщения в основную сессию для обеспечения непрерывности диалога. Если бота могут использовать несколько человек, изолируйте сессии:

{ session: { dmScope: 'per-channel-peer' } }

Без изоляции контекст одного пользователя может проникать в ход беседы другого. Это является одновременно уязвимостью конфиденциальности и усилителем инъекций промптов.

Сетевая экспозиция

Прежде чем радоваться возможности удалённого общения:

• Для личных установок предпочитайте gateway.bind: "loopback"
• Требуйте токены аутентификации шлюза для любого доступа, кроме локального (loopback)
• Рассматривайте Tailscale Serve/Funnel и обратные прокси как события экспозиции — следуйте руководству по устранению рисков, если используете один из них
• Никогда не публикуйте интерфейс управления (:18789) или порты моделей в открытый интернет без аутентификации

Выполните:

openclaw security audit
openclaw security audit --deep
openclaw security audit --fix   # narrow safe remediations only

Порядок приоритизации из документации: сначала заблокируйте открытые личные сообщения и группы с доступом к инструментам, затем публичную сетевую экспозицию, затем удалённый контроль браузера, затем права доступа к файлам, затем плагины.

Усиленный базовый уровень (стартовая точка)

OpenClaw публикует компактный пример усиленной конфигурации: привязка к локальному интерфейсу, аутентификация по токену, профиль инструментов, ориентированный на сообщения, списки запрета для групп автоматизации/рантайма/файловой системы, запрет выполнения с ask: "always", отключённые расширенные инструменты, требования к парингу в стиле WhatsApp и упоминаниям. Скопируйте намерение в свою конфигурацию из актуальной страницы безопасности, а не фиксируйте устаревшую копию навсегда, затем проведите повторную проверку.

Значения по умолчанию для доверенного одиночного оператора могут разрешать выполнение команд хоста без запросов (security="full", ask="off"). Это намеренное UX-решение для личного ассистента, но не доказательство того, что следует оставлять его включённым после расширения каналов. Ужесточите настройки, если ваша модель угроз включает сообщения от других лиц.

Вопросы для ежеквартального обзора

Каждый квартал (или после любого расширения каналов):

1. Кто входит в каждый список разрешённых и почему?
2. Какие группы всё ещё имеют доступ к боту, и требуется ли его упоминание?
3. Включил ли кто-то open политику DM/группы «временно»?
4. Шире ли инструменты exec/browser по сравнению с моделью угроз прошлого квартала?
5. Запускался ли openclaw security audit с момента последнего изменения конфигурации?

Запишите ответы. Безопасность, которая существует только в чьей-то голове, не выдержит первого отпуска.

Примечания для Discord / Slack / Teams (те же принципы)

Интерфейсы каналов различаются; вопросы безопасности — нет:

• Какие гильдии/рабочие пространства/команды добавлены в белый список?
• Какие пользователи могут отправлять личные сообщения?
• Должен ли бот быть @упомянут в каналах?
• Хранятся ли токены бота только на хосте Gateway?

Для Discord и Slack OpenClaw документирует списки разрешённых для каждой поверхности (guilds, channels и связанные ключи — подтвердите текущую схему). Применяйте тот же подход «закрыто по умолчанию», что и в примерах WhatsApp/Telegram. Публичное рабочее пространство Slack с открытым агентом и инструментами exec — это инцидент, ожидающий любопытного коллеги.

Корпоративные чаты часто содержат персональные данные сотрудников и клиентов. Подключение OpenClaw к Slack/Teams является обработкой данных: знайте законное основание, кто может вызывать бота и какие выходные данные инструментов сохраняются в ~/.openclaw.

Конкретные истории сбоев (шаблоны, а не фольклор)

Вот какие формы принимают инциденты:

Забытая открытая политика DM

Токен бота попадает в публичный репозиторий или друг делится именем пользователя. Незнакомцы отправляют личные сообщения с запросами типа «проанализируй мои ~/Documents». При включённых инструментах модель может попытаться это сделать.

Группа без упоминания

Бот реагирует на каждый поток. Кто-то вставляет вредоносный README. Агент загружает и следует ему.

Общий семейный чат в WhatsApp

Подростки и подрядчики делят группу, в которой можно @ упоминать бота. Смешивание контекстов из-за непрерывности сессии. Шутка превращается в запрос на выполнение команды оболочки.

Удалённый интерфейс без аутентификации

:18789 привязан к локальной сети «чтобы телефон мог подключиться». Пользователи гостевой Wi-Fi получают доступ к плоскости управления.

Каждая из описанных ситуаций предотвращается парным подключением, списками разрешений, правилами упоминаний, изоляцией сессий и привязкой/аутентификацией — а не более строгим системным промптом.

Отзыв и отключение доступа

Составьте краткое руководство:

1. Удалите учётную запись из allowFrom или отзовите её запись парного подключения с помощью текущего CLI/интерфейса; убедитесь, что каноническая строка авторизации в SQLite удалена через поддерживаемые инструменты, а не путём прямого редактирования базы данных.
2. Если человек когда-либо видел токены канала, выполните их ротацию.
3. Проверьте сессии ~/.openclaw на наличие чувствительных остаточных данных.
4. Повторно запустите openclaw security audit.
5. Если у него было парное подключение узлов, отключите устройство.

Относитесь к этому как к восстановлению SSH-ключа, а не как к отписке от бота.

Чек-лист оператора

• Политика личных сообщений (DM) установлена на pairing или строгий режим allowlist
• allowFrom содержит только доверенные учётные записи
• Для групп требуется упоминание; настроены списки разрешений для групп
• dmScope изолирована, если существует несколько отправителей личных сообщений
• Обратная связь шлюза (или только аутентифицированный удалённый доступ)
• openclaw security audit в чистоте, позволяющей спокойно спать
• Инструменты высокого риска отключены до блокировки учётной записи
• Права доступа к директории состояния не разрешают чтение всем
• Шаги отключения доступа задокументированы для ваших каналов

Отзывайте записи парного подключения и списков разрешений, когда заканчивается использование номера телефона, учётной записи Slack или контракта подрядчика. Забытые строки в списке разрешений — это открытые приглашения. Экспортируйте или удаляйте историю сессий, содержащую личные данные других людей, когда прекращается законное основание для их обработки.

Списки разрешений и парное подключение — это не бюрократия. Это разница между личным шлюзом и API агента без аутентификации, подключённым к вашей оболочке. Настройте их до внедрения навыков, механизма heartbeat и автоматизаций удобства использования — о них речь пойдёт далее в разделе навыки, механизм heartbeat и одобрение.