AWatch-rus/PILOT_READINESS_AUDIT_RU.md

Аудит готовности AWatch-rus / DetMir к пилотной эксплуатации

Дата аудита: 2026-06-05

Объект аудита: AWatch-rus / DetMir, Rust workspace adk-rust, портал detmir-portal, агент awatch-agent-rs, документы коммерческого пилота и реестровой подготовки.

Ограничения аудита: архитектура не менялась, новые сущности не добавлялись, рефакторинг не выполнялся. Проверка выполнена как readiness-аудит к контролируемому пилоту, а не как сертификационная экспертиза СЗИ.

1. Итоговая оценка

Статус: ГОТОВ К КОНТРОЛИРУЕМОМУ ДЕМОНСТРАЦИОННОМУ ПИЛОТУ

Оценка готовности: 90 / 100

Вывод:

• Для ограниченного пилота на заранее согласованном контуре критических технических блокеров в коде и портале не выявлено.
• Полный демонстрационный путь "главный риск -> подразделение -> кандидат -> расследование -> пакет -> отчет" проверен на рабочем DetMir-контуре; перед показом нужен только короткий преддемо-прогон на той же сети и экране.
• Для широкого промышленного внедрения остаются обязательные доработки: формальный контур доступа/RBAC, backup/retention для файловых state, sizing/load-тесты, API/schema versioning и регламент эксплуатации агента.
• Текущая продуктовая линия корректная: Workforce-first, операционный контроль, технический аудит, explainable risk и расследования без заявления продукта как сертифицированной DLP/SIEM/EDR/СЗИ.

2. Выполненные проверки

Проверка	Результат
cargo test --workspace	OK после локального переноса Cargo target на Linux-ФС: <LOCAL_CARGO_TARGET_DIR>. Старый target/ на fuseblk не подходит для libsqlite3-sys.
cargo clippy --all-targets --all-features	OK
cargo build --release	OK
node scripts/detmir-portal-tabs-smoke.mjs против <PORTAL_URL>	OK; security events доступны через ClickHouse, переход к расследованию проверен, найдено 3 кнопки расследования.
GET /portal/api/reports на пустом state-dir	OK, валидный JSON
Отсутствие expected_nodes.json	OK, agent_coverage_sla.sla_status=UNKNOWN
Отсутствие incident_reviews.json, incident_review_audit.jsonl, cases.json	OK, портал не падает
local_fallback в тестах агента/портала	OK, не подтверждает KPI
collector_error в тестах портала	OK, виден в explain/markdown

Portal smoke подтвердил:

• вкладки Обзор, Сотрудники, Подразделения, Риски, Расследования, Сетевой периметр, Отчеты, Настройки открываются;
• Risk Narrative выводится первым;
• read-only настройки отображают период, рабочий день, русские названия порогов и источник правил;
• видимые статусы портала переведены с OK/WARN/FAIL/UNKNOWN на русские формулировки; технические подсказки ClickHouse/env убраны из пользовательских экранов;
• переход "кандидат -> расследование" проверен: smoke нашел 3 кнопки перехода и открыл карточку расследования;
• события безопасности читаются порталом через ClickHouse: backend=clickhouse, status=ok, fallback_used=false;
• первый расчет отчета прогревается при старте detmir-portal.service; после прогрева /api/reports отвечает за доли секунды;
• фоновое обновление больше не переводит готовый экран в состояние "Загрузка данных"; 70-секундная браузерная проверка сохранила READY;
• мобильная проверка 390px прошла: READY, глобального горизонтального overflow нет.

3. Архитектура

Сильные стороны:

• Архитектура уже выстроена как цепочка Agent -> Telemetry -> Analytics -> Risk -> Investigation -> Report.
• Rust-first runtime покрывает критичные серверные helpers, DLP/worktime paths, readiness, portal и собственный агент.
• pfSense/network perimeter оставлен optional/read-only слоем, что снижает риск пилота и соответствует текущим ограничениям проекта.
• Python сохранен только для оговоренных исключений, не как ядро продукта.
• Документы фиксируют корректное позиционирование: не СЗИ/DLP/SIEM, а платформа операционного контроля, технического аудита и Workforce/UEBA-аналитики.

Слабые стороны:

• Архитектура пока сильно завязана на набор сервисов/утилит и файловых интеграций; единая production control-plane модель еще не оформлена.
• Часть интеграций исторически выросла из ops-скриптов; runtime уже Rust-first, но границы владения между portal, AW, DLP, readiness и worktime требуют отдельной эксплуатационной схемы.
• Для пилота это приемлемо, но для масштабирования потребуется явная схема сервисов, портов, state-файлов, владельцев данных и recovery flows.

Оценка: хорошо для пилота, нужно усилить для масштабного rollout.

4. API

Сильные стороны:

• GET /api/reports устойчиво собирает executive dashboard, Risk Narrative, Trust KPI, agent quality, coverage SLA, business risk, heatmap, correlation, candidates, cases и markdown.
• POST /api/telemetry защищен API key/Bearer token и не принимает дефолтный change-me.
• Старые telemetry payload без diagnostics не ломают отчеты: качество данных становится UNKNOWN.
• Incident Review и Cases не создают инциденты автоматически; workflow остается ручным и проверяемым.

Слабые стороны:

• Контракты API уже доступны через /api/contracts, OpenAPI и TypeScript, но нужна формальная матрица версий и журнал совместимых/несовместимых изменений полей.
• Нет отдельного lightweight endpoint для части управленческих данных; /api/reports остается большим агрегирующим endpoint.
• Авторизация пользователя портала предполагается внешним gateway; сам портал не реализует полноценный RBAC.

Риск пилота: средний. Для контролируемого стенда допустимо, для заказчика нужен фиксированный API contract и контур доступа.

5. Portal UI

Сильные стороны:

• Портал уже выглядит как управленческий контур: сначала связанная картина риска, затем сводка руководителя, доверие к данным, риски, кандидаты и дела.
• UI smoke подтверждает работу всех основных вкладок.
• Risk Narrative связывает Trust KPI, Agent Coverage, Business Risk, Heatmap, Security Correlation, Incident Candidates и Cases.
• Для руководителя важные выводы формулируются человеко-понятно, а не только техническими метриками.

Слабые стороны:

• Разделение ролей пока в основном интерфейсное и организационное; enforcement должен выполняться внешним auth/RBAC-контуром.
• На пустых данных портал работает, но часть выводов ожидаемо имеет статус UNKNOWN/ATTENTION; перед демо нужен подготовленный demo/pilot dataset.
• PDF/export-путь требует отдельной приемочной проверки в конкретном окружении.
• Документы для заказчика все еще требуют языковой чистки от англоязычных терминов и технических сокращений.

Оценка: готов к демонстрации и пилоту при наличии auth gateway.

6. Rust Agent

Сильные стороны:

• awatch-agent-rs имеет единую модель TelemetryRecord для Windows/Linux/FreeBSD.
• Есть retry/backoff/spool: кратковременный обрыв связи не обязан приводить к потере данных.
• Session quality уже поднят до уровня portal/report: wts_api, quser_utf16, quser_lossy, env_sessionname_fallback, local_fallback.
• local_fallback явно считается диагностическим режимом и не подтверждает KPI.
• Тесты покрывают дедупликацию сессий, local_fallback, spool, конфиг и сериализацию.

Слабые стороны:

• Windows collector промышленного уровня еще требует расширения вокруг Event Log, ETW/WMI и устойчивой установки как service с централизованным rollout/rollback.
• FreeBSD/pfSense mode находится на read-only foundation уровне и не должен продаваться как законченный firewall/NAC enforcement.
• Нужен регламент мониторинга spool backlog, версии агента и качества данных по рабочим местам.

Оценка: достаточно для пилотного сбора worktime/RDP, не завершено как полный enterprise endpoint agent.

7. JSON-хранилища и state

Проверенные state-файлы:

• telemetry.jsonl
• data/incident_reviews.json
• data/incident_review_audit.jsonl
• data/cases.json
• config/expected_nodes.json

Сильные стороны:

• Отсутствующие файлы не ломают портал.
• Audit trail для incident review append-only по смыслу и не удаляет историю.
• Cases создаются только вручную из подтвержденных candidates.
• Пустой state-dir возвращает валидный /api/reports.

Слабые стороны:

• JSON/JSONL storage пока годится для пилота, но не для высокой конкуренции записи, больших объемов и долгого retention без ротации.
• Нужны регламенты backup/restore, lock/atomic-write policy, ротация audit JSONL и контроль размера telemetry history.
• Нужна миграционная политика state schema.

Риск пилота: средний. Для 1-2 подразделений допустимо, для широкого внедрения нужен storage hardening или перенос критичного state в SQLite/DB.

8. Документация

Сильные стороны:

• Есть документы по архитектуре, порталу, security model, agent architecture, deployment, Business Risk, pilot checklist, release readiness и позиционированию.
• Документация удерживает безопасную линию для реестра: прикладные ИБ/DLP-lite функции не заявляются как сертифицированная СЗИ.
• Pilot checklist уже содержит доступ, scope, retention, Grafana, evidence, readiness и приемку.

Слабые стороны:

• Нет единого “операторского пакета пилота” в одном маршруте: installation -> first telemetry -> validation -> demo -> acceptance.
• API-контракты уже оформлены отдельными маршрутами, но документация должна явно ссылаться на OpenAPI/TypeScript и порядок проверки совместимости.
• Не хватает sizing guide: число endpoints, объем telemetry/day, CPU/RAM/disk, рекомендуемый retention.

Оценка: хорошая база, нужно уплотнить до customer pilot pack.

9. Отказоустойчивость

Сильные стороны:

• Агент имеет spool/retry.
• Портал best-effort читает optional state и не падает при отсутствии telemetry/review/audit/cases/expected_nodes.
• Readiness bundle, checksum/signature и Prometheus/Grafana readiness ideas уже заложены в документах и тестах.
• Legacy fallback сохранен там, где это нужно для rollback.

Слабые стороны:

• Нет HA для портала/AW server/хранилищ.
• Нет формального RTO/RPO.
• Нет нагрузочного теста на массовый прием telemetry и генерацию /api/reports.
• Нет отдельной очереди с backpressure на серверной стороне telemetry ingest.

Оценка: достаточно для контролируемого пилота, не достаточно для SLA-продажи.

10. Обратная совместимость

Сильные стороны:

• Старые telemetry без diagnostics работают.
• agent_quality сохранен, новые explain/history/nodes поля добавлены без поломки старого API.
• Отсутствие JSON state файлов обрабатывается.
• PowerShell collector сохранен как legacy fallback, а не удален.

Слабые стороны:

• Нет формальной матрицы совместимости версий agent/server/portal.
• Нет version negotiation для telemetry payload.
• Нужен changelog breaking/non-breaking API полей.

Оценка: практически совместимо, формально не закреплено.

11. Производительность

Сильные стороны:

• Rust-gates проходят быстро, release build чистый.
• Критичные runtime helpers переведены на Rust.
• Portal snapshot cache снижает повторное выполнение внешних команд.

Слабые стороны:

• /api/reports является агрегирующим endpoint и потенциально станет тяжелым при росте telemetry history, cases, candidates и audit JSONL.
• JSONL scan без ограниченной индексации может стать узким местом.
• Нет зафиксированного benchmark: endpoints, records/day, время формирования отчета, p95/p99 latency.

Оценка: достаточно для пилота, нужны load-тесты перед масштабированием.

12. Безопасность

Сильные стороны:

• Публичная документация придерживается sanitized-подхода и не должна содержать live infrastructure values.
• Evidence path защищен opaque ID, canonical path/root allowlist, magic validation, max-size limit, hash validation и Bearer upload token.
• Telemetry ingest не принимает дефолтный ключ.
• local_fallback не используется как доказательство активности.
• pfSense mutation/enforcement не включен в текущий scope.

Слабые стороны:

• Portal auth/RBAC должен быть гарантирован внешним gateway; без него портал не должен публиковаться наружу.
• Нужны security headers, TLS termination profile, session/access log policy.
• Нужно определить, кто может менять Incident Review/Cases и как проверяется reviewer.
• JSON state и evidence нуждаются в отдельном backup/retention/access-control регламенте.

Оценка: нормально для закрытого пилота за auth gateway, нельзя открывать как самостоятельный публичный портал без gateway/RBAC.

13. Сильные стороны проекта

• Сформирована понятная коммерческая ценность: Workforce-first + Security + Forensics.
• Портал показывает не только метрики, а причинно-следственную картину риска.
• Rust-first перенос выполнен широко: agent, portal, DLP/worktime/readiness, helpers и проверки.
• Есть доказательная линия: agent quality, coverage SLA, candidates, incident review audit, investigation packs, cases.
• Тесты закрывают ключевые регрессии: old telemetry, missing state, fallback, collector errors, coverage SLA, markdown order.
• Публичное позиционирование стало безопаснее для реестра и коммерческой презентации.

14. Слабые стороны

• Нет встроенного RBAC/auth в portal application layer.
• JSON/JSONL state пока не hardened для больших объемов и параллельных записей.
• API-контракты и OpenAPI уже есть, но нет формального versioning и матрицы совместимости agent/server/portal.
• Нет load/sizing профиля.
• Windows agent еще требует промышленного rollout guide и матрицы OS/locale.
• FreeBSD/pfSense support нельзя считать законченным commercial module.
• Не хватает единого customer pilot runbook с шагами “чистая VM -> агенты -> первый отчет -> приемка”.

15. Технический долг

1. Описать и зафиксировать API schema/versioning.
2. Ввести storage policy для JSON/JSONL: lock, atomic write, rotation, backup, restore, retention.
3. Разделить heavy /api/reports на стабильные contract endpoints или документировать его как aggregate endpoint с p95 SLA.
4. Добавить benchmark/load-test сценарий telemetry ingest и report generation.
5. Оформить RBAC/auth gateway profile для ролей: владелец, руководитель, ИБ, оператор, администратор.
6. Сделать matrix agent compatibility: OS, locale, session source, fallback, worktime accepted/not accepted.
7. Подготовить anonymized pilot dataset и регламент преддемо-прогона.

16. Риски пилота

Риск	Уровень	Что сделать до пилота
Неверная трактовка proxy KPI как абсолютной “полезности”	HIGH	В договоре/демо явно писать: индекс активности - proxy, веса приложений согласуются по ролям.
Недостаточное покрытие агентов	HIGH	Заполнить expected_nodes.json, проверять coverage SLA каждый день.
Портал без auth gateway	CRITICAL	Не публиковать портал без TLS/auth/RBAC reverse proxy.
Рост JSONL/audit файлов	MEDIUM	Включить retention/backup/rotation policy.
Спорные candidates из-за плохого data quality	MEDIUM	Использовать agent quality, local_fallback не принимать в KPI, показывать Trust KPI.
Неописанная версия agent/server	MEDIUM	Зафиксировать версии в pilot acceptance и release manifest.
Evidence/privacy вопросы	HIGH	Согласовать локальный регламент, доступы, retention, уведомление сотрудников.

17. Блокеры внедрения

Для контролируемого пилота:

• Критических блокеров не выявлено, если портал закрыт auth gateway и scope пилота ограничен заранее выбранными рабочими местами.

Для промышленного customer rollout:

1. Нет формального production auth/RBAC profile для портала.
2. Нет утвержденного backup/retention/access-control регламента для telemetry, cases, audit и evidence.
3. Нет sizing/load-test отчета.
4. Нет формального API versioning и матрицы совместимости agent/server/portal.
5. Нет завершенного customer pilot runbook с ожидаемыми результатами проверки.

18. Рекомендации v0.3

Приоритет P0 до пилота:

1. Подготовить закрытый auth gateway profile: TLS, Basic/OIDC/VPN, role mapping, access logs.
2. Заполнить expected_nodes.json для пилотного scope и проверить coverage SLA.
3. Описать pilot retention: telemetry, reports, incident review audit, cases, evidence.
4. Зафиксировать версии agent/server/portal и команды проверки в pilot acceptance act.
5. Перед показом выполнить преддемо-прогон: готовность данных, наличие кандидата, открытие расследования, скачивание пакета и итоговый отчет.

Приоритет P1 для v0.3:

1. Зафиксировать API versioning, матрицу совместимости и порядок проверки OpenAPI/TypeScript contracts.
2. Добавить storage hardening для JSON/JSONL state или перенести критичный state в SQLite.
3. Сделать load test: 50/100/250 endpoints, records/day, /api/reports p95.
4. Расширить agent deployment docs: Windows service, rollback, locale matrix, spool monitoring.
5. Добавить единый PILOT_RUNBOOK_RU.md: установка, проверка, smoke, отчет, критерии приемки.

Приоритет P2 после пилота:

1. Развивать per-user baseline и role-based workforce weights.
2. Укрепить FreeBSD/pfSense read-only mode, но не включать enforcement без отдельного решения.
3. Добавить SIEM/syslog/webhook export profile как integration pack.
4. Добавить formal evidence chain policy, если продукт будет продаваться как Forensics-ready.

19. Финальный вывод

AWatch-rus / DetMir уже можно показывать заказчику как MVP+/v0.3 платформу Workforce-first операционного контроля с explainable risk и ручным расследовательским workflow.

Для пилота система должна запускаться в закрытом контуре, с заранее согласованными рабочими местами, включенным agent coverage SLA, заполненным списком expected nodes и внешним auth gateway перед порталом.

Главная техническая граница зрелости сейчас не в UI и не в Rust-переносе, а в эксплуатационной дисциплине: доступы, retention, backup, API contract, sizing и регламент качества данных агента.