Анализ разрывов готовности пилота AWatch-rus

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

Аудируемый срез: origin/main, 9c57d6d2ce7eae1b133c937f037b24933f5797fe.

Цель: объективно определить готовность AWatch-rus к контролируемой пилотной эксплуатации и демонстрации руководителю, ИБ и эксплуатации.

Ограничения аудита: код, архитектура, сущности и интеграции не изменялись. Сформирован только этот аудитный документ.

Не входило в аудит: pfSense, Telegram, Grafana, InfluxDB.

Что готово

Архитектура пилота выстроена как понятная цепочка: агент -> телеметрия -> аналитика -> риск -> расследование -> отчет.
Rust workspace на текущем origin/main проходит обязательные проверки:

Проверка	Результат
`cargo test --workspace`	Пройдено.
`cargo clippy --all-targets --all-features`	Пройдено.
`cargo build --release`	Пройдено.
`node scripts/detmir-portal-tabs-smoke.mjs`	Пройдено против рабочего портала через временный туннель; `security_events=available`.

Portal UX проходит smoke: вкладки Обзор, Сотрудники, Подразделения, Риски, Расследования, Сетевой периметр, Отчеты, Настройки открываются без ошибок консоли и HTTP 4xx/5xx.
Executive View готов к показу руководителю: главный вывод расположен первым, порядок управленческих блоков подтвержден smoke, англоязычные и лишние технические термины в проверяемом пользовательском слое не обнаружены.
Security View готов к показу ИБ: есть кандидаты на проверку, расследования, аудит, материалы расследования и переход из риска в карточку расследования. Smoke подтвердил 3 кнопки перехода к расследованию.
Operations View готов к показу эксплуатации: видны полнота и качество данных, состояние источников, режим событий безопасности и ошибки сбора.
ClickHouse integration работает в пилотном контуре: /api/health возвращает ok=true, источник security_events активен, портал получает агрегированные события безопасности через ClickHouse.
Сбор данных 1С и DLP зафиксирован как Rust-first runtime: aw-1c-ingest-rust и Windows telemetry/evidence sync работают с 15-минутным циклом; скриншоты 1С не копируются, доказательные PNG остаются только для DLP-событий.
Agent/Rust migration закрывает критичный runtime-риск: основной сбор worktime, browser/domain, URL/domain extraction, clipboard/USB/print incident semantics и DLP evidence path покрыты Rust-бинарниками и тестами.
Документы docs/PORTAL_RU.md и docs/SECURITY_EVENTS_CLICKHOUSE_RU.md присутствуют и отражают текущую модель портала и ClickHouse-событий.
Пилотные документы находятся в единой структуре docs/: docs/CUSTOMER_PILOT_PACK_RU.md, docs/PILOT_READINESS_AUDIT_RU.md, docs/SALES_POSITIONING_RU.md, docs/DEMO_RUNBOOK_RU.md.
10-минутный демонстрационный путь технически доступен: главный риск, подразделение, причина риска, кандидат, расследование, пакет расследования и итоговый управленческий вывод показываются в портале.

Что критично исправить

Критичных блокеров в коде, сборке и smoke-проверке для контролируемого пилота на текущем срезе не выявлено.

Критичные условия перед фактическим показом:

Демо должно запускаться на контуре, где развернут именно commit 9c57d6d2ce7eae1b133c937f037b24933f5797fe или более новый проверенный срез.
Перед показом нужен короткий преддемо-прогон на той же сети и экране: открыть портал, дождаться Данные готовы, проверить кандидата, открыть расследование и сформировать отчет.
Нельзя продавать текущий срез как промышленно завершенную платформу без оговорок по доступу, retention, backup, versioning и регламенту эксплуатации.

Что желательно исправить

Русифицировать заголовки customer-facing документов: текущие документы используют названия вроде Customer Pilot Pack и Sales Positioning, что слабее выглядит на показе руководителю и заказчику.
Отдельно перед демо проверить экспорт в формате, который будет показан: текстовый отчет, печать или PDF.
Добавить в регулярный smoke мобильный/визуальный прогон. Текущий detmir-portal-tabs-smoke.mjs хорошо проверяет функциональный путь, но не является полноценной визуальной regression-проверкой.
Сформировать явную матрицу совместимости API: agent, portal, telemetry, ClickHouse security events и investigation state.
Убрать из публичного customer-facing пакета внутренние формулировки про <LOCAL_CARGO_TARGET_DIR>, private contour и служебные runtime-детали.

Что перенести после пилота

Полное hardening локальных JSON/JSONL/state-хранилищ: atomic write, блокировки, retention, backup/restore и нагрузочные тесты больших файлов.
Промышленный app-layer RBAC для портала. Сейчас ролевые представления есть в UX, но контроль доступа должен оставаться задачей защищенного контура или reverse proxy до отдельного product hardening.
Полное удаление оставшихся PowerShell deploy/bootstrap/fallback-элементов. Для пилота важно отсутствие PowerShell как основного runtime-сборщика; полная зачистка deploy-истории не является блокером показа.
Load/sizing-профиль под промышленную эксплуатацию: количество рабочих мест, объем событий, глубина хранения, требования к ClickHouse и файловому evidence.
Формальные регламенты хранения и доступа к материалам расследований.
CI-упаковку customer-facing документов с проверкой путей, ссылок и русских заголовков.

Риски пилота

Риск	Влияние	Оценка
Контур демо не совпадает с проверенным commit	Возможны расхождения UI, API или данных	Критично контролировать перед показом
Документы или ссылки изменятся без проверки	Путает hand-off и приемку пакета	Контролировать markdown link-check перед передачей
Первый запуск портала без прогрева	Может выглядеть как зависшая загрузка	Управляемо преддемо-прогоном
В текущих данных исчезнут кандидаты на расследование	10-минутный сценарий потеряет самый сильный пример	Проверять `/api/reports` перед демо
ClickHouse станет недоступен	Operations View покажет fallback/ошибку вместо полного ИБ-среза	Не блокер UI, но слабее для ИБ
Нет промышленного RBAC внутри приложения	Нельзя открывать портал вне защищенного контура	Для контролируемого пилота приемлемо
Остаточные PowerShell deploy/fallback артефакты	Могут вызвать вопросы эксплуатации о миграции	Объяснять как legacy/fallback, не runtime-core
Нет полной визуальной mobile regression-проверки в обязательном smoke	Возможны мелкие UX-дефекты на нестандартном экране	Проверить вручную перед показом с планшета/ноутбука

Дополнительное наблюдение: один первичный запуск smoke через только что созданный туннель один раз не дождался READY за 30 секунд. Повтор с тем же 30-секундным таймаутом прошел примерно за 8 секунд, /portal/api/reports отвечал примерно за 0.4 секунды. Это не выглядит как продуктовый блокер, но подтверждает необходимость преддемо-прогона.

Итоговая оценка готовности

Статус: AWatch-rus готов к контролируемому демонстрационному пилоту на текущем origin/main.

Оценка готовности: 88%.

Обоснование:

Сборка, тесты, clippy, release build и portal smoke на проверенном срезе успешны.
Executive/Security/Operations View закрывают основной сценарий для руководителя, ИБ и эксплуатации.
Rust runtime migration убрал главный риск зависимости от PowerShell в рабочих сборщиках.
ClickHouse-события безопасности доступны и отражаются в портале.
Оставшиеся разрывы относятся в основном к вычитке документов, преддемо дисциплине, промышленному hardening и формальному управлению доступом.

Рекомендация: допустить к пилоту только как контролируемый демонстрационный контур. Перед показом выполнить короткий smoke на рабочем URL, проверить наличие кандидата на расследование, открыть пакет расследования и заранее подготовить итоговый отчет.

12 KiB Raw Blame History