2026: безопасность шлюза OpenClaw на практике — удалённый Mac, Bearer, egress и аудит

Зафиксируйте среду исполнения до любых «хардненинг»-настроек. Стек шлюза и CLI OpenClaw в 2026 году обычно ориентируют на актуальную линию Node LTS (на практике команды стандартизируют Node 22+). На удалённом Mac проверьте node -v и npm -v, ставьте Node через nvm или официальный pkg, чтобы обновления были воспроизводимыми и не смешивали префиксы.

Создайте отдельного пользователя macOS (например openclawsvc), которому принадлежат каталог установки и пути логов. Не запускайте шлюз от администратора с «бесшумным» sudo: один утёкший токен тогда превращается в полный доступ к диску. Проверьте фактические владельца и права:

id openclawsvc
ls -la ~/openclaw-gateway
chmod 750 ~/openclaw-gateway
chmod 600 ~/openclaw-gateway/.env.gateway

Права Privacy (TCC) выдавайте точечно. Если навык вызывает автоматизацию и появляются запросы macOS, документируйте их; не включайте Full Disk Access «ради скорости». Для launchd укажите UserName в plist, чтобы процесс явно работал не от привилегированной сессии инженера.

Первое решение плоскости управления — сетевая экспозиция. Безопасный шаблон на удалённом Mac: процесс OpenClaw слушает 127.0.0.1:PORT, а Caddy или nginx завершает TLS и проксирует на этот порт с опциональным allowlist IP. Публичный 0.0.0.0 без сильной аутентификации и сетевых ограничений — типичная находка в разборе утечек 2025–2026.

Включите bearer-аутентификацию на пути, который используют CI и клиенты. Токен храните в .env.gateway (режим 600) и пробрасывайте в окружение демона:

export OPENCLAW_GATEWAY_TOKEN="$(openssl rand -hex 32)"
# В plist launchd — блок EnvironmentVariables:
# OPENCLAW_GATEWAY_TOKEN = <значение из хранилища секретов>

В GitHub Actions и аналогах подставляйте токен из зашифрованных секретов и запретите эхо в логах. Полезный контроль в пайплайне: убедиться, что в индексе git нет открытого токена (например поиск по OPENCLAW_GATEWAY_TOKEN в отслеживаемых файлах с политикой «fail»).

Иллюстративный фрагмент openclaw.json (ключи подгоните под вашу версию OpenClaw):

{
  "gateway": {
    "listen": { "host": "127.0.0.1", "port": 18765 },
    "auth": { "mode": "bearer", "header": "Authorization" },
    "rateLimit": { "perMinute": 120 }
  }
}

Сочетайте bearer с сетевым периметром: VPN-only, для отладки — SSH-туннель ssh -L 18765:127.0.0.1:18765 user@remote-mac, файрвол с запретом по умолчанию для входящих.

Агент с произвольными HTTP-вызовами из навыков работает как усилитель SSRF. Начните с письменного allowlist хостов, которые реально нужны джобам, и только потом включайте технические ограничения.

Задайте прокси-переменные один раз для учётки сервиса и окружения launchd:

export HTTPS_PROXY="http://proxy.corp.example:8080"
export NO_PROXY="127.0.0.1,localhost,.internal.corp,artifacts.internal"

Если централизованный egress недоступен, комбинируйте встроенный межсетевой экран macOS, явные правила и версионируемые репозитории навыков — любое расширение исходящих адресов должно проходить ревью, а не «временно отключать фильтр».

Структурированные логи полезнее скриншотов в чате. Направьте stdout/stderr шлюза в каталог вроде /var/log/openclaw/ (владелец — сервисный пользователь) или используйте StandardOutPath / StandardErrorPath в plist. Ротацию настройте через newsyslog или небольшой logrotate, иначе длинные загрузки моделей быстро съедят диск.

Минимальный мониторинг на удалённом узле:

Если нет SIEM, даже grep -E "401|403|EACCES|certificate|handshake" по cron с письмом или webhook в мессенджер лучше полного молчания. Главное — заранее определить, кто реагирует на алерт и в какой SLA.

После изменений прогоните привычную проверку здоровья (например openclaw doctor, если доступно в вашей сборке) и локальный запрос:

curl -sf -H "Authorization: Bearer $OPENCLAW_GATEWAY_TOKEN" http://127.0.0.1:18765/health

Только после успешного локального теста расширяйте слушатель наружу через прокси с TLS и ACL.