docs(detmir): record production restore baseline

docs/DETMIR_CURRENT_STATE_RU.md

@@ -0,0 +1,308 @@
+# DetMir/AWatch-rus: актуальное состояние и граница DLP-модуля
+
+Дата фиксации: 2026-06-25.
+
+Обновление 2026-06-29 после восстановления RDP-сервера: фактический
+production IP Windows/RDP host теперь `192.168.100.19`; stable ActivityWatch
+logical host id остаётся `SHARKON2025`. Подробный post-restore baseline:
+`docs/DETMIR_RESTORE_BASELINE_2026-06-29_RU.md`.
+
+Документ фиксирует фактическое состояние DetMir/AWatch-rus и первую границу
+переработки горячего пути портала. Это не release evidence для реестра
+российского ПО, не заявление о сертификации и не claim замены DLP/SIEM/EDR.
+
+## Runtime baseline
+
+- Контур: DetMir / AWatch-rus.
+- Stable Windows/RDP logical host id для ActivityWatch bucket-ов и отчетов:
+  `SHARKON2025`. Это legacy logical id, а не обязательное физическое имя
+  Windows-сервера. Правило rename-safe эксплуатации описано в
+  `docs/WINDOWS_LOGICAL_HOST_ID_RU.md`.
+- Текущий физический RDP/WinRM target: `192.168.100.19`.
+- Portal host: `10.10.10.2`.
+- Portal service: `detmir-portal.service`.
+- Portal URL: `http://10.10.10.2:8720/`.
+- Задеплоенный binary hash:
+  `653b22b0fbf29a22f7de42ade7b689490b1de16fa07e785e4e0efd3078e7a3bc`.
+- Бэкап предыдущего binary на сервере:
+  `/usr/local/bin/detmir-portal.bak.20260625T045640Z`.
+- Runtime mode после phase 1 deploy:
+  `DETMIR_PORTAL_DLP_MODULE_ENABLED=false`.
+- Server-side optional DLP runtime control:
+  `AW_DLP_ENABLED=false|true` и `DETMIR_DLP_ENABLED=false|true`.
+- Runtime control/statistics script:
+  `scripts/detmir_dlp_runtime_control.sh` / live
+  `/usr/local/bin/detmir-dlp-runtime-control`.
+- Live DLP runtime state after 2026-06-25 controlled disable:
+  `AW_DLP_ENABLED=false`, `AW_DLP_INFLUX_ENABLED=false`;
+  active/enabled DLP units: `0/0`.
+- Health после деплоя: `/healthz` возвращал `status=ok`.
+- Readiness после деплоя: `/readyz` возвращал `status=ready`.
+
+## Что исправлено в текущем baseline
+
+- Первичная загрузка портала больше не зависает в бесконечном `LOADING`.
+- При холодном старте тяжелый операторский срез не блокирует UI бесконечно.
+- Frontend показывает честное состояние `STALE / Первичный срез прогревается`.
+- При prewarm больше не смешиваются статусы `STALE` и ложное
+  `Данные отсутствуют`.
+- Progress bar доходит до `100%` в fail-soft/prewarm состоянии.
+- Browser smoke после деплоя подтвердил:
+  - `loadStatus=STALE`;
+  - `progress=100%`;
+  - `LOADING=false`;
+  - `EMPTY=false`;
+  - `ERROR=false`.
+
+## Phase 1 live verification
+
+2026-06-25 после сборки `detmir-portal` и деплоя через
+`ansible/deploy_detmir_portal.yml --limit proxmox` подтверждено:
+
+- `/healthz`: `status=ok`;
+- `/readyz`: `status=ready`;
+- `/api/reports`: `ok=true`, `cache_status=warming`,
+  `modules.dlp.enabled=false`, `modules.dlp.hot_path=false`;
+- `/api/operator`: `cache_status=warming`, `summary.severity=STALE`,
+  `modules.dlp.status=disabled`, `incidents=0`;
+- server log для `/api/operator`: `status=200`, `latency_ms=49`.
+
+Это подтверждает, что первый operator/API screen больше не блокируется на
+холодной полной сборке. Полный snapshot строится в фоне и честно помечается как
+`warming`/`STALE`.
+
+## Текущая проблема производительности
+
+Наблюдаемые признаки:
+
+- после restart полный тяжелый snapshot может уходить в prewarm/stale mode;
+- report cache и stale UI защищают пользователя от зависания, но не убирают
+  саму стоимость тяжелых расчетов;
+- DLP evidence, screenshots, endpoint signals, case review и forensics
+  enrichment требуют больше CPU/IO/сетевых операций, чем Workforce core.
+
+Вывод: DLP/evidence/forensics enrichment уже вынесен из обязательного hot path
+phase 1 через `DETMIR_PORTAL_DLP_MODULE_ENABLED=false`, но полная оптимизация
+тяжелого snapshot/prewarm остается отдельной инженерной задачей.
+
+## Целевая граница после переработки
+
+Core hot path:
+
+- Workforce Operations;
+- worktime/activity;
+- загрузка, простои, перегруз;
+- дисциплина процесса;
+- качество и полнота данных;
+- легкие агрегаты для руководителя;
+- readiness/health без ожидания DLP.
+
+Optional DLP module:
+
+- DLP endpoint signals;
+- clipboard/USB/print/web/file operation incidents;
+- screenshots/evidence;
+- DLP/case review;
+- heavy security correlation;
+- forensics timelines and evidence packages;
+- Hayabusa enrichment where needed.
+
+Отключение optional DLP module не должно ломать:
+
+- `/healthz`;
+- `/readyz`;
+- первичную загрузку портала;
+- Workforce views;
+- management reports;
+- базовый operator dashboard.
+
+Отключение optional DLP module должно показывать честный статус:
+
+```text
+DLP module disabled / not configured
+```
+
+без заявления, что DLP-проверки выполнены.
+
+## Рекомендуемые feature flags
+
+Минимальная целевая модель конфигурации:
+
+```json
+{
+  "modules": {
+    "dlp": {
+      "enabled": false,
+      "evidence": false,
+      "correlation": false,
+      "screenshots": false,
+      "hot_path": false
+    }
+  }
+}
+```
+
+Первая реализованная runtime-граница:
+
+```text
+--dlp-module-enabled
+DETMIR_PORTAL_DLP_MODULE_ENABLED=true|false
+AW_DLP_ENABLED=true|false
+DETMIR_DLP_ENABLED=true|false
+```
+
+Default остается `true`, чтобы существующее поведение не менялось без явного
+решения администратора. Для ускоренного Workforce/operator режима допускается
+`DETMIR_PORTAL_DLP_MODULE_ENABLED=false`; в этом режиме портал:
+
+- не читает DLP incident/case/review/audit файлы в основном report/operator
+  path;
+- отключает security-events backend внутри snapshot, не меняя сохраненные
+  ClickHouse credentials;
+- возвращает disabled-state для DLP evidence API;
+- не считает отсутствие DLP ошибкой Workforce core.
+
+Ansible-параметр поставки:
+
+```yaml
+detmir_portal_dlp_module_enabled_override: false
+```
+
+Отдельный `detmir-portal-evidence` сервис не отключается этим флагом и остается
+самостоятельным контуром evidence/API при наличии отдельной конфигурации.
+
+Server-side optional DLP runtime описан отдельно:
+
+- [DLP_OPTIONAL_RUNTIME_RU.md](DLP_OPTIONAL_RUNTIME_RU.md).
+
+При `AW_DLP_ENABLED=false`:
+
+- `dlp-health-check` возвращает штатный `dlp:mode=disabled`;
+- `detmir-dlp` не выполняет SSH health probe;
+- `detmir-check`, `check-aw-full` и `check-aw-data` не считают DLP buckets
+  обязательными;
+- `detmir-readiness` не требует DLP Influx write и DLP systemd units;
+- перед отключением и после отключения собираются JSON-срезы в
+  `/var/lib/activitywatch/health/dlp-runtime-history/`, latest-срез остается в
+  `/var/lib/activitywatch/health/dlp-runtime-state.json`.
+
+Live disable evidence 2026-06-25:
+
+- `dlp-health-check` returned `ok=true`, `dlp:mode=disabled`;
+- `detmir-dlp` returned `ok=true`, `dlp:mode=disabled`;
+- pre-disable active units:
+  `aw-dlp-influx-exporter.timer`,
+  `activitywatch-dlp-aggregator.timer`,
+  `aw-dlp-report-scheduler.timer`,
+  `aw-dlp-syslog-forwarder.timer`,
+  `aw-dlp-webhook-sender.timer`,
+  `aw-dlp-cef-exporter.timer`,
+  `aw-dlp-ioc-refresh.timer`,
+  `aw-dlp-policy-engine.service`,
+  `aw-dlp-case-management.service`,
+  `detmir-portal-evidence.service`;
+- post-disable active/enabled DLP units: `0/0`;
+- retained evidence files:
+  `/var/lib/activitywatch/health/dlp-runtime-history/dlp-runtime-current-20260625T083619Z.json`,
+  `/var/lib/activitywatch/health/dlp-runtime-history/dlp-runtime-pre_disable-20260625T083637Z.json`,
+  `/var/lib/activitywatch/health/dlp-runtime-history/dlp-runtime-disabled-20260625T083700Z.json`;
+- `check-aw-full` with `AW_DLP_ENABLED=false` reports `DLP buckets ...
+  SKIPPED`;
+- ActivityWatch core services remained active:
+  `activitywatch-server`, `aw-worktime-api`.
+
+Separate live observations after DLP disable, before 2026-06-29 restore:
+
+- `aw-watcher-afk`, `aw-watcher-window` and `aw-worktime-sessions` were stale
+  in the manual check and require separate RDP collector/session recovery;
+- WinRM from the server side to `192.168.100.18:5985` was unreachable during
+  this check;
+- these are not treated as DLP disable regressions.
+
+Post-restore correction on 2026-06-29:
+
+- current physical RDP/WinRM target is `192.168.100.19`;
+- laptop route to `192.168.100.19` is through DetMir OpenVPN gateway
+  `10.0.13.1`;
+- WinRM `5985` and RDP `3389` are reachable from the admin laptop;
+- stable ActivityWatch logical host id remains `SHARKON2025`.
+
+Fail-safe правила:
+
+- если DLP выключена, Security/Forensics views должны показывать disabled-state,
+  а не падать;
+- если DLP включена, тяжелые DLP операции должны выполняться асинхронно или
+  через cache, а не блокировать первый Workforce/operator screen;
+- readiness не должен заявлять DLP healthy, если модуль отключен или не
+  проверен;
+- отсутствие DLP не является ошибкой Workforce core.
+
+## Сетевое состояние
+
+Доступ к DetMir зависит от NetworkManager VPN profile
+`pfSense-gate-UDP4-1194-vpn_prog10-config`. Имя tun-интерфейса не является
+семантической идентичностью и должно проверяться по адресу `10.0.13.*`.
+
+Пример рабочего route:
+
+```text
+10.10.10.2 via 10.0.13.1 dev <current-detmir-tun>
+```
+
+Наблюдавшаяся нестабильность dataplane:
+
+- tun device может присутствовать в routing table, но gateway `10.0.13.1` не
+  отвечает;
+- при этом SSH, `/healthz` и браузерная проверка DetMir недоступны;
+- после ручного поднятия NetworkManager-подключения
+  `pfSense-gate-UDP4-1194-vpn_prog10-config` доступ восстанавливался.
+- 2026-06-25 после phase 1 deploy зафиксирован отдельный сбой:
+  `nm-openvpn` для `178.178.98.83:1194` получил `TLS handshake failed` и
+  `connect timeout exceeded`; повторная production-очистка старого systemd
+  prewarm drop-in отложена до восстановления VPN handshake.
+
+Актуальная проверка 2026-06-29:
+
+```text
+192.168.100.19 via 10.0.13.1 dev <current-detmir-tun>
+10.0.13.1 ping OK
+192.168.100.19:5985 OK
+192.168.100.19:3389 OK
+```
+
+Команда восстановления:
+
+```bash
+nmcli connection down 'pfSense-gate-UDP4-1194-vpn_prog10-config' || true
+sleep 2
+nmcli connection up 'pfSense-gate-UDP4-1194-vpn_prog10-config'
+```
+
+Проверка:
+
+```bash
+ping -c 2 -W 2 10.0.13.1
+ping -c 2 -W 2 10.10.10.2
+nc -vz -w 3 10.10.10.2 22
+curl -sS --max-time 5 http://10.10.10.2:8720/healthz
+```
+
+## Что не менять без отдельной задачи
+
+- Не удалять DLP collectors и warehouse ради ускорения портала.
+- Не менять UI/API несовместимо: новые поля должны быть additive.
+- Не заявлять completed DLP decoupling до live deploy и browser/API smoke.
+- Не позиционировать AWatch-rus как сертифицированную DLP/SIEM/EDR/СЗИ.
+
+## Следующий инженерный шаг
+
+Закрыть оставшиеся production-hardening пункты:
+
+1. После восстановления DetMir VPN повторно прогнать
+   `ansible/deploy_detmir_portal.yml`, чтобы удалить legacy drop-in
+   `/etc/systemd/system/detmir-portal.service.d/30-prewarm-after-start.conf`.
+2. Подтвердить remote `sha256sum /usr/local/bin/detmir-portal` и отсутствие
+   `ExecStartPost` prewarm в `systemctl cat detmir-portal`.
+3. Подтвердить browser smoke без зависания первичной загрузки.
+4. Добавить метрики и smoke для режимов `dlp.enabled=false` и
+   `dlp.enabled=true`.