OpenClaw предоставляет агенту системный уровень доступа: файлы, терминал, браузер, мессенджеры, API внешних сервисов. Для личного использования это удобно. Для корпоративного деплоя это означает, что компромисс агента — это компромисс всей инфраструктуры, к которой он подключён.
Enterprise-безопасность OpenClaw — это не набор галочек, а архитектурная дисциплина. Этот материал описывает полный фреймворк: от изоляции идентификаторов до человеческого контроля над критическими операциями.
Почему enterprise-безопасность — отдельная задача
По данным исследований 2026 года, 42 000 экземпляров OpenClaw публично доступны в интернете без должной защиты. 36% скиллов ClawHub содержат уязвимости разной степени серьёзности. CVE-2026-25253 позволял перехватывать токены аутентификации через один переход по вредоносной ссылке.
Всё это — следствие одной проблемы: OpenClaw проектировался для персонального использования, где пользователь = администратор = единственный оператор. В корпоративной среде этой модели доверия нет.
Четыре архитектурных риска enterprise-деплоя:
- Избыточные привилегии — агент с доступом «ко всему» при компромисе одного канала
- Shared credentials — несколько агентов используют один API-ключ
- Отсутствие аудита — нет логов того, что агент делал от имени организации
- Неконтролируемые скиллы — установка сторонних плагинов без проверки
1. Identity Isolation: один агент — один идентификатор
Базовый принцип: каждый агент получает собственный набор credentials, не разделяемый с другими агентами или людьми.
Схема изоляции
Команда маркетинга
└── Агент marketing-01
├── Anthropic API Key: sk-ant-marketing-... (только этот агент)
├── HubSpot API: только read для контактов
└── Slack Bot Token: только #marketing-*
Команда DevOps
└── Агент devops-01
├── Anthropic API Key: sk-ant-devops-... (только этот агент)
├── GitHub Token: read/write только devops-repo
└── Slack Bot Token: только #alerts, #devopsПрактическая реализация
Разворачивайте отдельный экземпляр OpenClaw для каждой команды или роли. Это противоречит интуиции «один агент на компанию», но это правильная архитектура:
- При компромисе агента маркетинга DevOps недоступен
- Ротация ключей не затрагивает работу других команд
- Аудит прозрачен: все действия конкретного агента — в одном логе
Ротация ключей — раз в 90 дней как минимум, немедленно при подозрении на утечку.
2. RBAC: ролевая модель доступа
OpenClaw не имеет встроенного RBAC, поэтому ролевую модель строят на уровне конфигурации агента и сетевых ограничений.
Четыре базовые роли
| Роль | Описание | Доступ |
|---|---|---|
| viewer | Только чтение, без выполнения | Чтение файлов, запросы к read-only API |
| operator | Стандартные операции | Создание задач, обновление CRM, отправка сообщений |
| admin | Расширенные операции | Создание агентов, изменение конфигурации |
| superadmin | Полный доступ | Только для экстренных случаев, требует двойного подтверждения |
Конфигурация через SOUL.md
## Роль и ограничения
Ты агент уровня OPERATOR для команды customer-support.
### Разрешено:
- Читать и обновлять тикеты в Zendesk
- Отвечать клиентам в Slack-канале #support
- Запрашивать данные клиентов по ID из CRM (read-only)
- Создавать внутренние заметки к тикетам
### Запрещено без явного подтверждения руководителя:
- Удалять тикеты или данные клиентов
- Изменять статус тикетов на "resolved" для сложных кейсов
- Обращаться к финансовым данным
- Устанавливать новые скиллы
### При неясности:
Напиши в #support-admin и дожди человека.3. Least-Privilege Allowlists: минимальные привилегии
Подход «blacklist» (запрещать конкретные действия) слабее подхода «allowlist» (разрешать только конкретные действия). Allowlist безопаснее по умолчанию: всё, что не разрешено явно, — запрещено.
Allowlist на уровне файловой системы
// openclaw.json
{
"filesystem": {
"mode": "allowlist",
"allowed_paths": [
"~/work/marketing/",
"~/reports/",
"/tmp/openclaw-scratch/"
],
"denied_paths": [
"~/.ssh/",
"~/.aws/",
"~/.openclaw/",
"/etc/"
]
}
}Allowlist на уровне команд
{
"shell": {
"mode": "allowlist",
"allowed_commands": [
"git status",
"git log",
"git diff",
"npm test",
"npm run lint",
"curl https://api.example.com/*"
],
"require_confirmation": [
"git push",
"git commit",
"npm publish",
"rm -rf"
],
"blocked_commands": [
"sudo",
"chmod 777",
"wget",
"nc",
"nmap"
]
}
}Allowlist на уровне скиллов
Ведите внутренний реестр одобренных скиллов. Устанавливайте только из него:
# Approved Skills Registry (хранить в корп. Wiki)
## Разрешённые скиллы (версия зафиксирована)
- slack-notifications@2.1.0 (одобрен 2026-03-15, аудит: security-team)
- github-pr-summary@1.4.2 (одобрен 2026-03-20, аудит: devops-lead)
- zendesk-triage@3.0.1 (одобрен 2026-04-01, аудит: security-team)
## Запрещённые скиллы
- browser-autopilot (неограниченный web-доступ)
- shell-executor-pro (обход allowlist)4. VPC и сетевая изоляция
Порт 18789 (Gateway OpenClaw) должен быть полностью закрыт для внешнего интернета. Это не опция — это требование.
Архитектура сетевой изоляции
Интернет
│
▼
[Reverse Proxy / Nginx] ← только HTTPS:443, с mTLS для enterprise
│
▼
[VPC / Private Network]
├── OpenClaw Agent 1 (порт 18789, bind: 127.0.0.1)
├── OpenClaw Agent 2 (порт 18790, bind: 127.0.0.1)
└── OpenClaw Admin (порт 18791, bind: 10.0.0.0/8)Firewall rules (пример для iptables)
# Закрыть порт 18789 для внешних подключений
iptables -A INPUT -p tcp --dport 18789 -s 0.0.0.0/0 -j DROP
# Разрешить только из внутренней сети
iptables -A INPUT -p tcp --dport 18789 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 18789 -s 192.168.0.0/16 -j ACCEPT
# Разрешить localhost
iptables -A INPUT -p tcp --dport 18789 -s 127.0.0.1 -j ACCEPTDocker network isolation
# docker-compose.yml
services:
openclaw-agent:
image: openclaw/openclaw:v2026.4.11
networks:
- internal
# Нет expose/ports — агент недоступен извне
nginx:
image: nginx:alpine
ports:
- "443:443"
networks:
- internal
- external
networks:
internal:
internal: true # Полностью изолированная сеть
external:
driver: bridge5. Comprehensive Logging: полный аудит действий
Без логирования вы не можете ответить на вопрос: «Что делал агент в промежутке с 14:00 до 15:30 в пятницу?»
Что логировать обязательно
{
"log_events": {
"agent_sessions": true, // Начало и конец каждой сессии
"tool_calls": true, // Каждый вызов инструмента агентом
"file_operations": true, // Чтение/запись/удаление файлов
"shell_commands": true, // Каждая выполненная команда
"api_calls": true, // Внешние API-запросы
"skill_installations": true, // Установка/обновление скиллов
"config_changes": true, // Изменения конфигурации
"auth_attempts": true // Попытки аутентификации
},
"log_format": "json",
"log_destination": "/var/log/openclaw/audit.jsonl"
}Формат лога для SIEM
{
"timestamp": "2026-04-15T14:23:45.123Z",
"agent_id": "devops-01",
"session_id": "sess_xyz789",
"event_type": "shell_command",
"command": "git push origin main",
"exit_code": 0,
"user_approved": true,
"approval_timestamp": "2026-04-15T14:23:40.000Z",
"approver": "ivan.ivanov@company.ru"
}Интеграция с Elastic/Splunk
# Filebeat конфигурация для OpenClaw логов
filebeat.inputs:
- type: log
paths:
- /var/log/openclaw/audit.jsonl
json.keys_under_root: true
json.add_error_key: true
output.elasticsearch:
hosts: ["https://elastic.company.internal:9200"]
index: "openclaw-audit-%{+yyyy.MM.dd}"6. Encrypted Vaults: защита credentials
Никогда не храните API-ключи в ~/.openclaw/ в открытом виде для продакшн-окружений. Это не совет — это требование enterprise-безопасности.
Вариант 1: 1Password CLI
# Устанавливаем 1Password CLI
brew install --cask 1password-cli
# Создаём запись для OpenClaw
op item create \
--category login \
--title "OpenClaw Anthropic Key" \
--vault "Engineering" \
credential[text]="sk-ant-..."
# Запуск OpenClaw через 1Password CLI
op run --env-file=".env.op" -- openclaw start# .env.op
ANTHROPIC_API_KEY=op://Engineering/OpenClaw Anthropic Key/credential
OPENCLAW_TOKEN=op://Engineering/OpenClaw Gateway Token/passwordВариант 2: Docker Secrets
# docker-compose.yml
services:
openclaw-agent:
image: openclaw/openclaw:v2026.4.11
secrets:
- anthropic_key
- openclaw_token
environment:
ANTHROPIC_API_KEY_FILE: /run/secrets/anthropic_key
OPENCLAW_TOKEN_FILE: /run/secrets/openclaw_token
secrets:
anthropic_key:
external: true
openclaw_token:
external: true# Создание Docker secrets
echo "sk-ant-..." | docker secret create anthropic_key -
echo "secure-token-here" | docker secret create openclaw_token -Вариант 3: HashiCorp Vault
# Запись секрета в Vault
vault kv put secret/openclaw/devops-01 \
anthropic_key="sk-ant-..." \
github_token="ghp_..."
# Чтение в скрипте запуска OpenClaw
export ANTHROPIC_API_KEY=$(vault kv get -field=anthropic_key secret/openclaw/devops-01)
openclaw start7. Docker Sandboxing: ограничение ресурсов
Даже если атакующий получит контроль над агентом, Docker-ограничения снизят ущерб.
# docker-compose.yml — hardened конфигурация
services:
openclaw-agent:
image: openclaw/openclaw:v2026.4.11
# Ограничение ресурсов
deploy:
resources:
limits:
cpus: '2'
memory: 4G
reservations:
cpus: '0.5'
memory: 512M
# Безопасность
security_opt:
- no-new-privileges:true
- seccomp:./seccomp-openclaw.json
cap_drop:
- ALL
cap_add:
- NET_BIND_SERVICE # Только если нужно
# Filesystem
read_only: true
tmpfs:
- /tmp:size=512m,mode=1777
volumes:
- openclaw-data:/home/openclaw/.openclaw:rw
- ./workspace:/workspace:ro # Рабочая директория только для чтения
# User
user: "1000:1000" # Не rootSeccomp профиль (минимальный)
// seccomp-openclaw.json — разрешаем только необходимые syscalls
{
"defaultAction": "SCMP_ACT_ERRNO",
"architectures": ["SCMP_ARCH_X86_64"],
"syscalls": [
{
"names": ["read", "write", "open", "close", "stat", "fstat",
"mmap", "mprotect", "munmap", "brk", "rt_sigaction",
"clone", "fork", "execve", "exit", "wait4",
"socket", "connect", "sendto", "recvfrom",
"fcntl", "gettimeofday", "getpid", "getuid"],
"action": "SCMP_ACT_ALLOW"
}
]
}8. Human-in-the-Loop: контроль критических операций
Автономность агента — его главная ценность. Но не все операции должны выполняться без надзора.
Категории операций по уровню риска
| Категория | Примеры | Требуется подтверждение |
|---|---|---|
| Низкий риск | Чтение файлов, поиск, генерация черновиков | Нет |
| Средний риск | Отправка сообщений, создание тикетов, коммиты | Уведомление после |
| Высокий риск | Деплой, удаление данных, внешние платежи | Подтверждение до |
| Критический риск | Изменение прав доступа, финансовые транзакции >$1000 | Двойное подтверждение |
Настройка в SOUL.md
## Протокол подтверждения
Перед выполнением операций высокого риска:
1. Опиши, что собираешься сделать
2. Укажи, почему это необходимо
3. Перечисли возможные последствия
4. Дождись явного "Да, выполняй" от пользователя
Операции высокого риска:
- git push в любую ветку
- Удаление файлов или данных
- Отправка email клиентам
- Создание или изменение пользователей в любой системе
- Операции с деньгами
Никогда не выполняй критические операции в рамках автоматического TaskFlow
без явного указания в конфигурации TaskFlow.Чек-лист «Security Readiness Before Production»
Идентификация и доступ
- Каждый агент имеет собственный набор API-ключей (не разделяет с другими)
- API-ключи созданы с минимально необходимыми правами
- Настроена ротация ключей (максимум 90 дней)
- Ключи хранятся в vault (1Password / Docker Secrets / HashiCorp Vault), не в открытом тексте
Сетевая безопасность
- Порт 18789 недоступен из интернета (firewall)
- Агент работает в изолированной Docker-сети
- Внешний доступ — только через reverse proxy с HTTPS
- Shodan не видит ваш сервер на порту 18789
Конфигурация агента
- Настроен allowlist файловых путей
- Настроен allowlist команд с require_confirmation для опасных операций
- SOUL.md содержит явный список запрещённых операций
- Установлены только скиллы из внутреннего реестра одобренных
Логирование и мониторинг
- Включено логирование всех tool calls и shell commands
- Логи отправляются в централизованную SIEM систему
- Настроены алерты на подозрительные паттерны (много команд за короткое время, доступ к запрещённым путям)
- Есть процедура разбора инцидентов по логам
Изоляция
- Контейнер работает не от root (user: 1000:1000)
- Применён seccomp профиль
- Убраны лишние capabilities (cap_drop: ALL)
- Применён no-new-privileges
Процессы
- Есть процедура действий при подозрении на компромисс агента
- Настроен human-in-the-loop для операций высокого риска
- Проводится ревью установленных скиллов раз в квартал
- Есть план восстановления после инцидента
Что дальше
Отдельные темы, затронутые в этом материале, раскрыты подробнее в статьях по безопасности:
- 100+ CVE OpenClaw в 2026 году — статистика уязвимостей и темп патчей
- Права доступа в OpenClaw — детальная настройка разрешений
- OpenClaw и Docker: безопасная настройка — полное руководство по контейнеризации
- OpenClaw для бизнеса — сценарии enterprise-автоматизации
Если вы только начинаете enterprise-деплой — начните с identity isolation и allowlist. Это даст 80% защиты с 20% усилий. Остальное добавляйте по мере роста критичности задач агента.