docs(detmir): record production restore baseline

2026-06-29 13:20:54 +03:00
parent 34e017673a
commit 583cfe7003
14 changed files with 934 additions and 48 deletions
@@ -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`.
@@ -0,0 +1,74 @@
+# DetMir restore baseline 2026-06-29
+
+Дата фиксации: 2026-06-29.
+
+Документ фиксирует фактическое состояние восстановленного контура
+AWatch-rus/DetMir после возврата RDP-сервера `SHARKON2025`.
+
+## Итог
+
+- AW server: `10.10.10.13:5600`, API отвечает, CORS OK.
+- Worktime API: `10.10.10.13:5610`, `/health` OK, report endpoints отвечают.
+- Portal/gateway: `https://dm.iri1968.dpdns.org/healthz` отвечает `200 ok`.
+- RDP host physical IP: `192.168.100.19`.
+- Stable ActivityWatch logical host id: `SHARKON2025`.
+- Старый IP `192.168.100.18` не считать текущим production target.
+
+## Выполненные исправления
+
+- На ноутбуке добавлен постоянный маршрут к `192.168.100.19/32` через DetMir
+  VPN gateway `10.0.13.1`.
+- `ansible/inventory.ini` переведен на `rdp-prod ansible_host=192.168.100.19`.
+- Диагностические скрипты больше не жёстко привязаны к `192.168.100.18`.
+- `/etc/activitywatch/aw-server.env` на AW server обновлен:
+  `AW_MONITORED_WINDOWS_HOST=192.168.100.19`.
+- На RDP host добавлены узкие Windows Firewall allow-правила для
+  `10.10.10.13 -> 5985/3389`; промежуточный firewall всё ещё блокирует этот
+  server-side TCP path.
+- Guard restart-budget quarantine очищен через backup и reset runtime state.
+- ClickHouse Security Finding Inbox schema применена:
+  `security_findings`, `security_finding_workflow_events`,
+  `security_finding_inbox`.
+- `check-aw-full` обновлен: env-aware RDP host, корректный CORS origin,
+  AFK freshness через `bucket.metadata.end`.
+
+## Проверенный статус по 7 пунктам
+
+1. AW-server/portal/API: доступны; `check-aw-data.sh` OK, public `/healthz` OK.
+2. RDP host: `192.168.100.19`, `COMPUTERNAME=SHARKON2025`,
+   WinRM/RDP/SSH доступны с админского ноутбука; guard service running.
+3. ActivityWatch buckets: worktime, session, AFK, DLP endpoint signals fresh;
+   window bucket корректно классифицируется как inactive при отсутствии
+   интерактивной активности.
+4. ClickHouse/filter/security findings: ClickHouse healthy, Security Finding
+   Inbox schema создана; portal endpoint защищен auth и без авторизации
+   возвращает `401`.
+5. InfluxDB/Grafana: InfluxDB health `pass`, Grafana DB health `ok`,
+   Influx datasource health OK. Loki log contour intentionally disabled to
+   reduce resource usage.
+6. Hayabusa/Velociraptor layer: Hayabusa doctor OK, drop.path active,
+   incoming/drop backlog empty, latest intake `2026-06-29T09:00:23Z`,
+   bad zip сохранен только в quarantine как evidence. Velociraptor остаётся
+   addon/source path; live service не заявляется как подтвержденный.
+7. Baseline зафиксирован в этом документе и связан с operational docs/skills.
+
+## Остаточные риски
+
+- `aw-rus-healthd.service` на AW server всё ещё видит TCP timeout до
+  `192.168.100.19:5985/3389` через gateway `10.10.10.1`, хотя ICMP проходит и
+  доступ с админского ноутбука есть. Это network policy gap на промежуточном
+  firewall/ACL, не SQLite/datastore failure.
+- Grafana Loki datasource `10.10.10.12:3100` intentionally disabled: Proxmox
+  LXC `202 loki-logs` is stopped, active config has `onboot: 0`, and TCP
+  `10.10.10.12:3100` is closed. This is an operator decision to save resources
+  and does not break core AW/worktime/ClickHouse.
+
+## Проверки
+
+- `AW_MONITORED_WINDOWS_HOSTNAME=SHARKON2025 ./check-aw-data.sh` - OK.
+- `AW_SMOKE_AW_SERVER=http://10.10.10.13:5600
+  AW_SMOKE_SOURCE_HOSTNAME=SHARKON2025
+  AW_SMOKE_WINDOWS_HOST=192.168.100.19 ./check-aw-full.sh --no-color` - OK.
+- `cargo test -p check-aw-full` - 4 passed.
+- `bash -n` для изменённых shell scripts - OK.
+- `AW_SMOKE_LOKI_ENABLED=0` is the current default for local smoke checks.
@@ -55,7 +55,7 @@ DETMIR_SUPPORT_PVE_HOST=10.10.10.2
 DETMIR_SUPPORT_AW_HOST=10.10.10.13
 DETMIR_SUPPORT_WEB_HOST=10.10.10.2
 DETMIR_SUPPORT_WEB_TLS_HOST=10.10.10.2
-DETMIR_SUPPORT_WINDOWS_HOST=192.168.100.18
+DETMIR_SUPPORT_WINDOWS_HOST=192.168.100.19
 DETMIR_SUPPORT_SURICATA_HOST=10.10.10.2

 DETMIR_SUPPORT_SSH_USER=igor
@@ -79,6 +79,7 @@ DETMIR_SUPPORT_PVE_BACKUP_DIRS=/var/lib/pve/local-btrfs/dump

 - операторский gateway находится на `10.10.10.2`, а не на историческом
  `10.10.10.11`;
+- текущий Windows/RDP target после восстановления: `192.168.100.19`;
 - web health endpoint: `https://10.10.10.2/healthz`, ожидаемый ответ `200`;
 - защищенный корень gateway `https://10.10.10.2/` штатно отвечает `401`;
 - AW API health проверяется через
@@ -0,0 +1,166 @@
+# Optional DLP runtime for DetMir
+
+Цель: DLP-контур должен отключаться управляемо, без ложных аварий в health/readiness и без автоматического подъема heavy-пайплайна, когда задача контура - снизить нагрузку на InfluxDB, Grafana и ClickHouse.
+
+## Что отключается
+
+Штатный runtime off включает:
+
+- `AW_DLP_ENABLED=false` на AW server;
+- `DETMIR_DLP_ENABLED=false` в управляющем DetMir contour check;
+- `DETMIR_PORTAL_DLP_MODULE_ENABLED=false` для portal UI/API DLP-модуля;
+- остановку DLP timers/services:
+  - `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`, если DLP evidence upload больше не нужен.
+
+Worktime, ActivityWatch server, browser/window/AFK collection, Hayabusa and 1C/ClickHouse core не считаются DLP runtime и отдельно не отключаются.
+
+## Статистика перед отключением
+
+На AW server:
+
+```bash
+sudo bash /usr/local/bin/detmir-dlp-runtime-control stats
+sudo cat /var/lib/activitywatch/health/dlp-runtime-state.json
+```
+
+Из репозитория до деплоя:
+
+```bash
+sudo bash scripts/detmir_dlp_runtime_control.sh stats
+```
+
+JSON фиксирует:
+
+- generated timestamp;
+- effective mode;
+- DLP unit `active/enabled/load` state;
+- последние timestamps по DLP buckets для текущего host;
+- причину отключения.
+
+Каждый запуск дополнительно сохраняет неизменяемый снимок в
+`/var/lib/activitywatch/health/dlp-runtime-history/`. При `disable` остаются
+как минимум два снимка: `pre_disable` до остановки units и `disabled` после
+остановки/disable/reset-failed.
+
+## Отключение
+
+На AW server:
+
+```bash
+sudo install -o root -g root -m 0755 scripts/detmir_dlp_runtime_control.sh /usr/local/bin/detmir-dlp-runtime-control
+sudo sed -i \
+  -e 's/^AW_DLP_ENABLED=.*/AW_DLP_ENABLED=false/' \
+  -e 's/^AW_DLP_DISABLED_REASON=.*/AW_DLP_DISABLED_REASON=operator_disabled_to_reduce_influx_grafana_clickhouse_load/' \
+  /etc/activitywatch/aw-server.env
+sudo /usr/local/bin/detmir-dlp-runtime-control disable
+sudo systemctl restart aw-worktime-api.service || true
+```
+
+Для portal:
+
+```bash
+sudo sed -i 's/^DETMIR_PORTAL_DLP_MODULE_ENABLED=.*/DETMIR_PORTAL_DLP_MODULE_ENABLED=false/' /etc/detmir-portal.env
+sudo systemctl restart detmir-portal.service
+```
+
+Если переменной нет, добавьте ее в соответствующий env-файл отдельной строкой.
+
+## Проверка после отключения
+
+```bash
+AW_DLP_ENABLED=false DETMIR_DLP_ENABLED=false /usr/local/bin/dlp-health-check --json
+DETMIR_DLP_ENABLED=false detmir-dlp
+DETMIR_DLP_ENABLED=false detmir-check --json
+AW_DLP_ENABLED=false check-aw-full
+```
+
+Ожидаемое поведение:
+
+- `dlp-health-check` возвращает `ok=true` и `dlp:mode=disabled`;
+- `detmir-dlp` не открывает SSH health probe и возвращает disabled payload;
+- `detmir-check` не проверяет DLP buckets;
+- `check-aw-full` показывает DLP buckets как `SKIPPED`;
+- DLP units остаются stopped/disabled;
+- worktime/core проверки продолжают работать.
+
+## Live evidence 2026-06-25
+
+На DetMir/AW server выполнен controlled disable:
+
+- `AW_DLP_ENABLED=false`;
+- `AW_DLP_INFLUX_ENABLED=false`;
+- `AW_DLP_DISABLED_REASON=operator_disabled_to_reduce_influx_grafana_clickhouse_load`;
+- `AW_DLP_DISABLED_SINCE=2026-06-25`.
+
+Зафиксированы evidence-снимки:
+
+```text
+/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
+```
+
+Результат:
+
+- pre-disable active units included DLP Influx exporter, aggregator, report,
+  integration, policy/case and evidence units;
+- post-disable active/enabled DLP units: `0/0`;
+- `dlp-health-check` returned `ok=true`, `dlp:mode=disabled`;
+- `detmir-dlp` returned `ok=true`, `dlp:mode=disabled`;
+- `check-aw-full` returned `DLP buckets ... SKIPPED`.
+
+Отдельные non-DLP findings того же ручного прогона:
+
+- AFK/window/worktime buckets were stale and require RDP collector/session
+  recovery;
+- WinRM from server side to `192.168.100.18:5985` was unreachable;
+- these findings are outside the DLP runtime disable boundary.
+
+## Возврат DLP
+
+```bash
+sudo sed -i 's/^AW_DLP_ENABLED=.*/AW_DLP_ENABLED=true/' /etc/activitywatch/aw-server.env
+sudo /usr/local/bin/detmir-dlp-runtime-control enable
+sudo systemctl restart aw-worktime-api.service || true
+```
+
+Для portal:
+
+```bash
+sudo sed -i 's/^DETMIR_PORTAL_DLP_MODULE_ENABLED=.*/DETMIR_PORTAL_DLP_MODULE_ENABLED=true/' /etc/detmir-portal.env
+sudo systemctl restart detmir-portal.service
+```
+
+После включения выполнить:
+
+```bash
+/usr/local/bin/dlp-health-check --json
+detmir-dlp
+detmir-check --json
+```
+
+## Ansible
+
+В inventory/group vars:
+
+```yaml
+aw_dlp_enabled: false
+aw_dlp_disabled_reason: "operator_disabled_to_reduce_influx_grafana_clickhouse_load"
+aw_dlp_disabled_since: "2026-06-25"
+detmir_portal_dlp_module_enabled_override: false
+```
+
+При `aw_dlp_enabled: false` playbook пишет `AW_DLP_ENABLED=false`, не включает DLP service/timer runtime и не должен возвращать DLP Influx exporter/aggregator в active state.
+
+## Ограничения
+
+Это не удаление DLP-функциональности и не заявление, что DLP заменен другим средством. Это штатный режим временного/постоянного отключения тяжелого DLP runtime для стабилизации производительности. Исторические DLP buckets и артефакты могут оставаться на диске и в ActivityWatch до отдельной retention/cleanup процедуры.
@@ -94,11 +94,26 @@ Browser smoke не заменяет API/CLI проверки. Он подтве

 ```bash
 cd /mnt/usb_hdd2/Projects/ActivityWatch-Russian
-NO_PROXY=localhost,127.0.0.1,10.10.10.13,10.10.10.2,192.168.100.18,10.10.10.0/24 \
-no_proxy=localhost,127.0.0.1,10.10.10.13,10.10.10.2,192.168.100.18,10.10.10.0/24 \
+NO_PROXY=localhost,127.0.0.1,10.10.10.13,10.10.10.2,192.168.100.19,10.10.10.0/24 \
+no_proxy=localhost,127.0.0.1,10.10.10.13,10.10.10.2,192.168.100.19,10.10.10.0/24 \
+AW_SMOKE_WINDOWS_HOST=192.168.100.19 \
+AW_SMOKE_SOURCE_HOSTNAME=SHARKON2025 \
 ./check-aw-full.sh
 ```

+Для DetMir production при проверке после rename RDP-сервера явно фиксируйте
+stable logical host id:
+
+```bash
+AW_MONITORED_WINDOWS_HOSTNAME=SHARKON2025 ./check-aw-data.sh
+AW_SMOKE_WINDOWS_HOST=192.168.100.19 \
+AW_SMOKE_SOURCE_HOSTNAME=SHARKON2025 \
+./scripts/aw-contour-smoke-local.sh --skip-winrm
+```
+
+`SHARKON2025` в этих командах - исторический ActivityWatch logical id, не
+физическое имя Windows-сервера.
+
 Для workforce ClickHouse дополнительно проверить quality views:

 ```sql
@@ -60,6 +60,62 @@ backup, registry-readiness документации, плана российск
 - First protected PR workflow: PR #50 opened; required checks passed;
  review/merge still `pending_review_required`.
 - First reviewed PR evidence: pending.
+- DetMir portal live baseline on 2026-06-25:
+  `docs/DETMIR_CURRENT_STATE_RU.md`.
+- DetMir portal deployed binary:
+  `653b22b0fbf29a22f7de42ade7b689490b1de16fa07e785e4e0efd3078e7a3bc`.
+- DetMir portal cold-start UI hang: mitigated. During cold/prewarm state the UI
+  now shows `STALE / Первичный срез прогревается`, not endless loading.
+- DetMir DLP hot-path boundary: phase 1 deployed on the portal service with
+  `DETMIR_PORTAL_DLP_MODULE_ENABLED=false`.
+- DetMir optional DLP runtime controls: implemented in code/docs through
+  `AW_DLP_ENABLED`, `DETMIR_DLP_ENABLED`,
+  `scripts/detmir_dlp_runtime_control.sh` and
+  `docs/DLP_OPTIONAL_RUNTIME_RU.md`.
+- DetMir optional DLP runtime live state: disabled on 2026-06-25 to reduce
+  InfluxDB/Grafana/ClickHouse/AW server load. Evidence:
+  `dlp-health-check=dlp:mode disabled`, `detmir-dlp=dlp:mode disabled`,
+  active/enabled DLP units `0/0`, history snapshots under
+  `/var/lib/activitywatch/health/dlp-runtime-history/`.
+- DetMir DLP buckets in manual full check: `SKIPPED` under
+  `AW_DLP_ENABLED=false`, not reported as dead.
+- DetMir RDP collector freshness after 2026-06-29 restore: physical RDP target
+  is `192.168.100.19`, stable AW logical host id remains `SHARKON2025`.
+  Buckets are fresh/inactive as expected, collector guard quarantine was reset,
+  and `check-aw-full` was updated to use env-driven RDP target and AFK
+  `metadata.end` freshness. Admin laptop route to `192.168.100.19` goes through
+  DetMir OpenVPN gateway `10.0.13.1`; WinRM `5985` and RDP `3389` are reachable
+  from the admin laptop.
+- Low-cost containment pack: first safe control-plane layer implemented as
+  Rust `containment-engine`, example policy/finding fixtures, Ansible/env
+  disabled-by-default configuration, and operator/policy runbooks. Current
+  engine is decision/shadow only and does not mutate firewall, pfSense, AD,
+  VLAN or routes.
+- Security Finding Inbox: ClickHouse schema, DetMir Portal view/API,
+  Hayabusa/Velociraptor ingest adapters and separate
+  `security-finding-inbox executor` are implemented. Portal records workflow
+  events only; approved `apply_requested` can be processed by the fail-closed
+  executor through `containment-engine` `decide -> plan -> apply -> verify`
+  with rollback on apply failure.
+- Security Finding Inbox live schema: applied on ClickHouse 2026-06-29
+  (`security_findings`, `security_finding_workflow_events`,
+  `security_finding_inbox`).
+- DetMir Loki log contour: intentionally disabled by operator to reduce
+  resource usage. Proxmox LXC `202 loki-logs` is stopped, active config has
+  `onboot: 0`, and smoke checks skip Loki by default unless
+  `AW_SMOKE_LOKI_ENABLED=1` is set.
+- DetMir restore baseline 2026-06-29:
+  `docs/DETMIR_RESTORE_BASELINE_2026-06-29_RU.md`.
+- DetMir API smoke after phase 1: `/healthz` and `/readyz` OK;
+  `/api/reports` returned `cache_status=warming` with
+  `modules.dlp.enabled=false`; `/api/operator` returned bounded
+  `cache_status=warming` / `summary.severity=STALE` without waiting for the
+  full cold snapshot.
+- DetMir remaining heavy path risk: full report/snapshot prewarm can still be
+  CPU/IO expensive; deeper optimization remains pending.
+- DetMir VPN access rule: do not identify the contour by `tun0`/`tun1`; verify
+  by NetworkManager profile, `10.0.13.*` address, route via `10.0.13.1` and live
+  reachability.

 ## Что готово

@@ -133,6 +189,11 @@ backup, registry-readiness документации, плана российск
 - External peer review remains pending.
 - Community adoption remains low until external contributors, public reviews
  and sustained third-party activity appear.
+- DetMir DLP runtime disable is complete for the current live contour; deeper
+  long-term DLP product modularization and retention/cleanup policy remain
+  separate future work.
+- DetMir RDP collector/session recovery after 2026-06-29 restore is verified by
+  live smoke: `check-aw-full` reports `FRESH=8 STALE=0 DEAD=0`.

 ## Честные ограничения

@@ -170,3 +231,4 @@ backup, registry-readiness документации, плана российск
 - `docs/public-issues/public-issues-manifest.json`
 - `docs/BRANCH_PROTECTION_POLICY_RU.md`
 - `docs/BRANCH_PROTECTION_EVIDENCE_RU.md`
+- `docs/DETMIR_CURRENT_STATE_RU.md`
@@ -0,0 +1,133 @@
+# Stable logical host id для Windows/RDP контура
+
+Дата фиксации: 2026-06-27.
+
+Обновление 2026-06-29: восстановленный production RDP host доступен как
+`192.168.100.19`, но logical host id остаётся `SHARKON2025`.
+
+Этот документ описывает правило, которое защищает AWatch-rus/DetMir от поломки
+при переименовании Windows/RDP сервера.
+
+## Правило
+
+В AWatch-rus есть два разных идентификатора:
+
+| Поле | Назначение | Можно менять при rename Windows |
+| --- | --- | --- |
+| physical Windows name / `COMPUTERNAME` | имя ОС, локальный домен учеток, WinRM/администрирование | да |
+| `awHostname` / logical host id | суффикс ActivityWatch bucket, Grafana переменные, ClickHouse workforce keys, worktime reports | нет, только через плановую миграцию |
+
+Для DetMir production текущий stable logical host id:
+
+```text
+SHARKON2025
+```
+
+Это legacy logical id для сохранения истории bucket-ов и дашбордов. Он больше
+не должен трактоваться как обязательное физическое имя Windows-сервера.
+
+Физический IP/адрес администрирования задаётся отдельно в inventory/env:
+
+```text
+rdp-prod ansible_host=192.168.100.19
+AW_MONITORED_WINDOWS_HOST=192.168.100.19
+```
+
+## Где задается
+
+Windows deploy:
+
+```yaml
+aw_windows_logical_host_id: "SHARKON2025"
+aw_windows_hostname_override: "{{ aw_windows_logical_host_id }}"
+```
+
+Файл:
+
+```text
+ansible/host_vars/rdp-prod.yml
+```
+
+Server-side reports:
+
+```text
+AW_WORKTIME_HOST=<logical_host_id>
+AW_MONITORED_WINDOWS_HOSTNAME=<logical_host_id>
+AW_WORKTIME_INFLUX_HOSTS=<logical_host_id>
+AW_DLP_INFLUX_HOSTS=<logical_host_id>
+```
+
+Windows runtime config:
+
+```text
+C:\ProgramData\AWatch-rus\deployment-config.json
+```
+
+Ключ:
+
+```json
+{
+  "awHostname": "SHARKON2025"
+}
+```
+
+## Что делать при переименовании RDP сервера
+
+1. Не менять `awHostname`, если нет отдельного плана миграции исторических
+   bucket-ов, Grafana и ClickHouse.
+2. Windows account domain / local logon prefix можно задать явно:
+
+```yaml
+aw_windows_domain: "<new_windows_computer_or_domain_name>"
+```
+
+Если `aw_windows_domain` пустой или оставлен как `HOST-EXAMPLE`, playbook
+прочитает текущий `$env:COMPUTERNAME` через WinRM и использует его только для
+Windows-учёток. Это не меняет `awHostname`.
+
+3. Повторно применить Windows deploy после восстановления WinRM:
+
+```bash
+cd ansible
+ansible-playbook -i inventory.ini deploy_aw_windows.yml --limit rdp-prod
+```
+
+4. Проверить на Windows:
+
+```powershell
+Get-Content -Raw 'C:\ProgramData\AWatch-rus\deployment-config.json' |
+  ConvertFrom-Json |
+  Select-Object awHostname,userTasks
+```
+
+5. Проверить ActivityWatch buckets:
+
+```bash
+AW_MONITORED_WINDOWS_HOSTNAME=SHARKON2025 ./check-aw-data.sh
+```
+
+## Что ломается, если использовать `COMPUTERNAME` как bucket id
+
+- появляются новые пустые bucket-и после rename;
+- старые dashboards продолжают смотреть на старый host;
+- `aw-worktime-api` считает источники stale/missing;
+- ClickHouse workforce catalog перестает связывать пользователей с событиями;
+- guard/recovery может искать неправильные launch tasks.
+
+## Миграция на новый logical id
+
+Переход с `SHARKON2025` на нейтральный id вроде `DETMIR-RDP-01` допустим только
+как отдельная planned migration:
+
+- остановить Windows collectors;
+- создать mapping старого и нового logical id;
+- обновить Grafana dashboards;
+- обновить ClickHouse workforce catalog;
+- решить, переносить ли исторические ActivityWatch bucket-и или оставить их
+  read-only;
+- обновить `AW_WORKTIME_HOST`, `AW_MONITORED_WINDOWS_HOSTNAME`,
+  `AW_WORKTIME_INFLUX_HOSTS`, `AW_DLP_INFLUX_HOSTS`;
+- перезапустить server-side services;
+- выполнить smoke-check и ручную проверку портала.
+
+Без этих шагов менять logical id в production нельзя.