AutoGov

July 12, 2026 · View on GitHub

Governance-платформа для self-hosted-автоматизаций (в первую очередь n8n). Закрывает жизненный цикл теневой автоматизации по формуле найти → задокументировать → защитить → чинить.

Реализация по ТЗ v0.1 (docs/TZ.md). Текущий объём — MVP (Этап Э1): модуль M1 «Обнаружение» поверх универсального ядра-платформы (Требование ТЗ-0).

Статус: MVP, годный к пилоту. Модули M2–M4 присутствуют как плагины-заглушки, доказывающие плагинную архитектуру ядра.

Документация: Руководство пользователя · Архитектура · Go-to-Market / как продавать · ТЗ

Что делает MVP

Обнаруживает инстансы n8n множеством методов (ТЗ §5.1): Docker-инспекция, процессы, сетевой фингерпринт (/rest, /api/v1/docs, /healthz), файловая система (~/.n8n, docker-compose, .env), cron/systemd-таймеры. Детект — многосигнальный (не по одному признаку), чтобы снижать ложные срабатывания.
Инвентаризирует активы (ТЗ §5.2): хост, владелец, способ запуска, версия, сетевая доступность, тип БД, режим single/queue.
Строит карту «инстанс → креды → целевые системы» (ТЗ §5.3): к каким 1С/CRM/БД/платёжным/облачным системам имеет доступ теневой инстанс.
Оценивает риск (ТЗ §5.4): числовой скор + категория Critical/High/Medium/Low
- объяснение на естественном языке (генерируется локально, без внешних LLM).
Управляет ложными срабатываниями (ТЗ §5.6): whitelisting по хосту/образу/ движку/инстансу.
Оповещает и отчитывается (ТЗ §5.5): syslog/CEF для SIEM (Wazuh/Splunk), webhook, e-mail, Telegram; экспорт отчёта в JSON/CSV/PDF; веб-дашборд.

Приватность и локализация (критично для РК)

Privacy by design (ТЗ §7, §9): в модели данных нет полей для значений секретов и содержимого ПДн. Агент фиксирует только факт наличия секрета, его тип и целевую систему — значение никогда не извлекается и не передаётся (только SHA-256-отпечаток для корреляции).
Подписанные артефакты (ТЗ §9): агент проверяет свой бинарник по ed25519-подписанному манифесту при старте и отказывается работать при подмене (fail-closed). См. cmd/autogov-sign и USAGE §7.
On-prem по умолчанию (ТЗ §8.4): в режиме onprem любой исходящий трафик во внешние сервисы (включая внешние LLM) запрещён и требует явного включения администратором (allow_external_egress) с предупреждением о трансграничной передаче (Закон РК № 94-V). Egress-guard проверяется на старте — внешний адресат ломает запуск, а не «молча течёт».

Архитектура

Агенты (outbound-only, mTLS) ──▶ Ingest API ──▶ Event Bus ──▶ Module Runtime (плагины M1..M4)
                                                                   │
                        Asset Store ◀── Risk Engine ── Findings ──┤──▶ Notifier (syslog/CEF, webhook, ...)
                                                                   │
                                              Web UI / Public API (RBAC + аудит)

Ключевой инвариант (ТЗ-0): ядро (агент + control plane + модель данных + шина событий) — универсальное; M1 — первый вертикальный срез поверх него. M2–M4 подключаются как плагины без изменения ядра. Это проверяется тестом internal/modules/plugin_test.go (модуль M2 HoneyNodes встаёт на ту же шину и хранилище и выдаёт находку).

Подробности — в docs/ARCHITECTURE.md.

Компоненты

Путь	Назначение
`cmd/controlplane`	Центральный сервер: ingest, API, UI, модули
`cmd/agent`	Хост-сенсор (outbound-only), коллекторы + spool
`cmd/autogov-sign`	Подпись релизов (ed25519) и проверка целостности (ТЗ §9)
`internal/signing`	ed25519-подпись манифеста + проверка хеша бинарника
`internal/model`	Модель данных (ТЗ §7)
`internal/bus`	Событийная шина
`internal/store`	Хранилище активов/находок (JSON snapshot + JSONL-аудит)
`internal/modules`	Module Runtime + плагины `discovery` (M1), `honeynodes` (M2), `selfhealing` (M3), `autodoc` (M4)
`internal/risk`	Риск-скоринг с локальными объяснениями
`internal/agent/...`	Коллекторы, sanitizer (privacy-guard), disk spool
`internal/notify`	Нотификаторы + on-prem egress-guard
`internal/report`	Отчёты JSON/CSV/PDF (PDF — без внешних зависимостей)
`internal/server`	HTTP-сервер, RBAC, аудит, встроенный дашборд

Реализация — чистая стандартная библиотека Go, без внешних зависимостей (важно для аудируемости агента и air-gapped-развёртывания).

Быстрый старт (демо-стек)

Поднимает control plane + агент + намеренно «теневой» n8n (тестовый периметр из критериев приёмки ТЗ §12):

cd deploy
docker compose up --build

Откройте http://localhost:8443, войдите токеном dev-admin (роль admin). Через ~30 c агент обнаружит контейнер shadow-n8n, построит инвентарь и покажет находки с риск-скором.

Демо использует dev-токены и HTTP. Для пилота включите TLS/mTLS, замените все токены и оставьте mode: onprem.

Локальный запуск без Docker

go build -o bin/ ./cmd/...

# control plane
./bin/controlplane -config deploy/controlplane.example.json

# агент (на защищаемом хосте)
./bin/agent -config deploy/agent.example.json          # демон
./bin/agent -config deploy/agent.example.json -once     # один проход (для проверки)

Роли и API (RBAC, ТЗ §9)

Роль	Доступ
`viewer`	Сводка, инстансы, находки, хосты
`analyst`	+ карта доступа (чувствительный артефакт), смена статуса находок, автодокументация
`admin`	+ whitelisting, экспорт отчётов, аудит-лог

Основные эндпоинты (Authorization: Bearer <token>):

POST /ingest/v1/events                      # приём наблюдений от агентов (agent-токен + опц. mTLS)
GET  /api/v1/summary                        # KPI для дашборда
GET  /api/v1/instances[?engine=n8n]         # инвентарь
GET  /api/v1/instances/{id}                 # инстанс + воркфлоу + (analyst+) креды/reachability
GET  /api/v1/findings[?severity=critical]   # находки
POST /api/v1/findings/{id}/{ack|resolve|reopen}
GET  /api/v1/reachability                   # карта доступа (analyst+)
GET/POST/DELETE /api/v1/whitelist[/{id}]    # управление ложными срабатываниями (admin)
GET  /api/v1/reports/export?format=json|csv|pdf   # отчёты (admin)
GET  /api/v1/docs/infra.md                  # автодокументация (M4, analyst+)
GET  /api/v1/audit                          # аудит-лог (admin)

Тесты

go test ./...

Покрывают ключевые инварианты ТЗ:

§5.1/§9/§12 п.3 — sanitizer никогда не выпускает значения секретов;
§5.1/§5.3/§5.4 — end-to-end pipeline детекта n8n, карты доступа и скоринга;
§5.6 — многосигнальность и whitelisting снижают ложные срабатывания;
§8.2 — идемпотентность приёма (нет дублей находок);
§8.4 — on-prem egress-guard блокирует внешних адресатов;
ТЗ-0 — плагинная модель (модуль M2 без изменения ядра).

Соответствие критериям приёмки MVP (ТЗ §12)

Критерий	Где реализовано
1. Обнаружение n8n всеми методами, ≤5% FP после whitelist	`internal/agent/collect/*`, `internal/modules/discovery`, whitelisting в `store`/`server`
2. Карта «креды → целевые системы» + риск-категория	`discovery` (reachability) + `internal/risk`
3. Ни одного значения секрета не извлекается/передаётся	`internal/agent/sanitize` + модель без полей секретов
4. On-prem без исходящих соединений	`mode:onprem` + `notify.EgressGuard`
5. Отчёт (PDF/JSON) + находки в Wazuh через syslog/CEF	`internal/report`, `internal/notify` (CEF)

Дорожная карта

Э1 (сделано): M1 Discovery для n8n — MVP.
Э2: обобщённые автоматизации (Make-агенты, скрипты), Windows-агент, расширенные SIEM-интеграции.
Э3: M2 HoneyNodes (контракт и заглушка уже есть).
Э4: M3 Self-healing / M4 Autodoc (контракты и заглушки уже есть).

Правовые замечания (из ТЗ §13)

Лицензия n8n (SUL): продукт инспектирует уже развёрнутые клиентом инстансы, не хостит n8n как сервис. Текст SUL проверить построчно до релиза.
Закон РК № 94-V (локализация ПДн): on-prem-режим + запрет внешнего egress по умолчанию.
Закон РК № 256-VIII по ИИ (в силе с 11.07.2026): требуется юридический разбор применимости к ИИ-компонентам (объяснения рисков, будущий M3).