AWatch-rus/docs/DETMIR_CURRENT_STATE_RU.md

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 после 2026-06-30 prod hardening: server-side DLP runtime зафиксирован в core_only/disabled. Portal DLP UI/API module может оставаться включённым для чтения исторического SQLite/evidence-среза, но это не означает запуск DLP collectors/exporters.
• Server-side optional DLP runtime control: AW_DLP_ENABLED=false|true и DETMIR_DLP_ENABLED=false|true.
• Current resource profile: AW_DLP_ENABLED=false, AW_DLP_PROFILE=core_only; возврат в light выполняется только вручную после проверки нагрузки.
• Runtime control/statistics script: scripts/detmir_dlp_runtime_control.sh / live /usr/local/bin/detmir-dlp-runtime-control.
• DLP runtime state after 2026-06-30 prod hardening: AW_DLP_ENABLED=false, AW_DLP_PROFILE=core_only, AW_DLP_INFLUX_ENABLED=false; optional DLP units should be inactive/disabled. detmir-dlp-load-guard.timer remains enabled and active as protection for any later operator re-enable.
• Reason: DLP runtime materially increases Proxmox VM/LXC, InfluxDB, Grafana, ClickHouse and AW server load. In production DetMir the safe default is core_only; light is a reconnectable profile, not the automatic default.
• Auto-disable guard: scripts/detmir_dlp_load_guard.sh / live /usr/local/bin/detmir-dlp-load-guard. При перегрузе переводит DLP в core_only через runtime-control и пишет evidence в /var/lib/activitywatch/health/dlp-light-guard-state.json.
• DLP warehouse sync для портала: scripts/detmir_dlp_warehouse_sync.sh / live /usr/local/bin/detmir-dlp-warehouse-sync. Доставляет локальный SQLite snapshot на portal host для UEBA/DLP views без heavy DLP hot path.
• Loki CT is intentionally excluded from the current DetMir production resource profile. It must not be returned by routine deploy/recovery while the goal is to keep Proxmox VM/LXC load low.
• 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; текущий lightweight-профиль оставляет DLP-status/UEBA-сигналы включенными без тяжелого evidence/case/exporter path. Полная оптимизация тяжелого 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 должно показывать честный статус:

DLP module disabled / not configured

без заявления, что DLP-проверки выполнены.

Рекомендуемые feature flags

Минимальная целевая модель конфигурации:

{
  "modules": {
    "dlp": {
      "enabled": false,
      "evidence": false,
      "correlation": false,
      "screenshots": false,
      "hot_path": false
    }
  }
}

Первая реализованная runtime-граница:

--dlp-module-enabled
DETMIR_PORTAL_DLP_MODULE_ENABLED=true|false
AW_DLP_ENABLED=true|false
DETMIR_DLP_ENABLED=true|false

DetMir production default после 2026-06-30 hardening: AW_DLP_ENABLED=false / AW_DLP_PROFILE=core_only. Portal DLP module may stay enabled for historical/security views, but server-side DLP collectors/exporters remain off. В этом режиме портал:

• не читает DLP incident/case/review/audit файлы в основном report/operator path;
• использует только уже имеющийся лёгкий DLP-срез для UEBA и статуса;
• не включает evidence/case/exporters/Loki/Influx-heavy path;
• не считает отсутствие heavy DLP ошибкой Workforce core.

Ansible-параметр поставки для старого disabled-профиля:

detmir_portal_dlp_module_enabled_override: false

Для текущего safe production профиля:

detmir_portal_dlp_module_enabled_override: true
aw_dlp_profile: "core_only"
aw_dlp_enabled: false
aw_dlp_influx_enabled: false
aw_dlp_light_collector_enabled: false
aw_dlp_light_guard_enabled: true

Возврат в light выполняется только после resource check:

sudo AW_DLP_DISABLED_REASON=operator_reenable_after_resource_check \
  /usr/local/bin/detmir-dlp-runtime-control set-profile light
sudo sed -i \
  -e 's/^AW_DLP_ENABLED=.*/AW_DLP_ENABLED=true/' \
  -e 's/^AW_DLP_PROFILE=.*/AW_DLP_PROFILE=light/' \
  /etc/activitywatch/aw-server.env

Отдельный detmir-portal-evidence сервис не отключается этим флагом и остается самостоятельным контуром evidence/API при наличии отдельной конфигурации.

Hayabusa/Velociraptor boundary:

• Hayabusa/Sigma and Velociraptor are optional security findings / forensics sources, not Workforce hot path dependencies.
• Heavy DLP runtime can remain disabled while Hayabusa/Velociraptor findings are imported into Security Finding Inbox / ClickHouse.
• Velociraptor server/client mode must be enabled explicitly (disabled|offline_collector|server_clients) and must not be auto-started by routine production deploy on the small DetMir Proxmox contour.
• Findings from Velociraptor/Hayabusa support decide -> plan -> approve -> apply -> verify, but do not imply automatic remediation without approval.

Server-side optional DLP runtime описан отдельно:

• DLP_OPTIONAL_RUNTIME_RU.md.
• DLP_RESOURCE_PROFILES_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;
• DLP profile changes use /usr/local/bin/detmir-dlp-runtime-control set-profile <profile> and keep a rollback snapshot for /usr/local/bin/detmir-dlp-runtime-control rollback;
• перед отключением и после отключения собираются JSON-срезы в /var/lib/activitywatch/health/dlp-runtime-history/, latest-срез остается в /var/lib/activitywatch/health/dlp-runtime-state.json.

При AW_DLP_PROFILE=light:

• activitywatch-dlp-aggregator.timer собирает только ограниченный набор DLP events в локальный SQLite warehouse;
• detmir-dlp-warehouse-sync.timer доставляет этот warehouse на portal host атомарным snapshot;
• UEBA может учитывать dlp_warn/dlp_fail без запуска Loki/Influx-heavy path;
• detmir-dlp-load-guard.timer автоматически переводит профиль в core_only при превышении порогов load/RAM/iowait;
• тяжёлые DLP units (aw-dlp-influx-exporter, report/syslog/webhook/CEF, policy engine, case management, evidence API) должны оставаться выключенными.
• если detmir-dlp-load-guard.timer видит повторный перегруз, он автоматически возвращает DLP runtime в core_only.

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:

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:

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

Команда восстановления:

nmcli connection down 'pfSense-gate-UDP4-1194-vpn_prog10-config' || true
sleep 2
nmcli connection up 'pfSense-gate-UDP4-1194-vpn_prog10-config'

Проверка:

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 ради ускорения портала.
• Не включать heavy DLP или Velociraptor server runtime автоматически при обычном deploy без ресурсного решения.
• Не включать Loki CT автоматически при обычном deploy/recovery DetMir.
• Не менять 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.