awatch-rus/AWatch-rus
1
0
Fork 0
Code Issues Pull Requests Actions 100 Packages Projects Releases Wiki Activity
Files
8a7fbe7d6a8b0a94c3bd9b72bbc6e26ce3d932db
AWatch-rus/docs/DETMIR_CURRENT_STATE_RU.md
T

14 KiB
Raw Blame History

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.
  • Reason: DLP runtime materially increases Proxmox VM/LXC, InfluxDB, Grafana, ClickHouse and AW server load. In production DetMir it is currently kept disabled, but remains a documented optional module that can be enabled later.
  • 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 должно показывать честный статус:

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

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-параметр поставки:

detmir_portal_dlp_module_enabled_override: false

Отдельный 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 описан отдельно:

При 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:

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 без ресурсного решения.
  • Не менять 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.
Reference in New Issue View Git Blame Copy Permalink