Настройка безопасности и управления доступом OpenClaw
Развернули OpenClaw на сервере клиента, дали всем сотрудникам один и тот же токен — через неделю агент выполнял задачи с привилегиями администратора от имени стажёра. Это не гипотетический сценарий, это типичная конфигурация «по умолчанию» автономного агента без настроенной модели доступа.
OpenClaw работает с реальными инструментами: файловая система, bash, браузер, внешние API. Ошибка в политике доступа здесь — не «предупреждение в логах», а выполненная команда, удалённый файл, отправленный запрос.
Архитектура разграничения доступа в OpenClaw
OpenClaw использует концепцию tool permissions — каждому агенту или роли назначается конкретный набор разрешённых инструментов и областей действия. Настройка выполняется через конфигурационный файл агента и политики на уровне orchestrator.
Базовая структура политики доступа:
agent_policies:
role: analyst
allowed_tools:
- read_file
- search_web
- query_database
denied_tools:
- execute_shell
- write_file
- send_email
scope:
file_paths: ["/data/reports/*"]
db_schemas: ["analytics"]
Это не просто «белый список инструментов» — важно ограничить scope внутри разрешённых инструментов. Агент с read_file без ограничения path может прочитать /etc/passwd так же легко, как и целевой отчёт.
Ролевая модель и изоляция агентов
Для production-деплоя мы строим минимум три уровня:
Уровень 1 — системные политики. Конфигурируется на уровне Docker/VM, где запущен агент. Ограничения через Linux namespaces, seccomp-профили, AppArmor. Агент физически не может обратиться к сетевым ресурсам вне разрешённого CIDR.
Уровень 2 — политики OpenClaw. Ролевая модель внутри платформы: admin, operator, readonly, кастомные роли. Каждая роль — явный список инструментов и scope. Новые роли создаются по принципу least privilege: начинаем с пустых прав, добавляем только необходимое.
Уровень 3 — аудит и алерты. Все вызовы инструментов логируются с контекстом: кто вызвал, с какими аргументами, результат. Аномальные паттерны (агент внезапно начинает вызывать execute_shell чаще нормы) — алерт в SIEM или Slack.
Управление секретами и токенами
Типичная ошибка — передавать API-ключи через переменные окружения в docker-compose.yml, который лежит в репозитории. Для OpenClaw настраиваем интеграцию с Vault (HashiCorp) или AWS Secrets Manager:
# Агент получает токен через short-lived credentials
vault_client = hvac.Client(url=VAULT_ADDR)
secret = vault_client.secrets.kv.read_secret_version(
path="openclaw/production/openai_key"
)
api_key = secret["data"]["data"]["key"]
Токены ротируются каждые 24 часа. Агент не хранит ключ в памяти дольше сессии.
Практический кейс
Клиент — финтех-компания, 15 агентов OpenClaw обрабатывают клиентские запросы. Проблема: агент службы поддержки имел доступ к инструменту query_database без ограничения схем — мог читать таблицы с транзакциями, которые не нужны для ответа на запрос.
Что сделали:
- Разделили агентов на 4 роли с изолированными DB-схемами
- Добавили row-level security в PostgreSQL как дополнительный слой
- Настроили логирование всех SQL-запросов через pgaudit
- Внедрили алерт при обращении к схемам вне scope роли
Результат: 0 инцидентов несанкционированного доступа за 6 месяцев, полный audit trail для комплаенс-проверок.
Аутентификация пользователей и агентов
Для multi-tenant деплоев настраиваем SSO через OIDC (Keycloak, Okta, Azure AD). Каждый агент получает собственный service account с ограниченным временем жизни токена. Межагентное взаимодействие — через mTLS с сертификатами, выданными внутренним CA.
Процесс внедрения
- Аудит текущей конфигурации — инвентаризация всех инструментов и прав
- Проектирование ролевой модели — под реальные бизнес-процессы
- Настройка политик — конфиги для каждой роли, тестирование в staging
- Интеграция с Vault/Secrets Manager — ротация секретов
- Настройка аудита — логирование, алерты, дашборды
- Penetration testing — попытки выйти за рамки политик
Сроки: от 1 недели для простой конфигурации, 3–6 недель для enterprise-деплоя с SSO, Vault и полным аудитом.