AWatch-rus/SECURITY_OVERVIEW_RU.md

AWatch-rus: обзор системы для службы информационной безопасности

Обзор системы

AWatch-rus в текущем состоянии — это не только русифицированный ActivityWatch, а полный production-контур контроля пользовательской активности, DLP-сигналов, управленческой отчетности и bounded forensic follow-up.

Архитектурно систему удобно рассматривать как четыре основных operational tiers с выделенным forensic layer:

1. Windows Clients / RDP host На рабочих станциях и RDP-хостах работают PowerShell-коллекторы, которые собирают активность и DLP-сигналы.
2. Linux Server Серверный контур AW-rus на Linux принимает события, хранит bucket-данные, отдает WebUI и server-side API.
3. Integration Layer Здесь живут policy engine, case management, SIEM/webhook/syslog/CEF интеграции, Telegram operator path, 1C-аналитика и внешние poller'ы.
4. Monitoring Stack Grafana, Prometheus, SQL/ClickHouse аналитические слои и operator gateway для обзорных и управленческих экранов.
5. Forensic Layer Отдельный bounded DFIR-путь через Hayabusa, который используется для post-incident enrichment, а не как основной real-time detector.

Подтвержденный runtime для AWatch-rus:

• <AW_SERVER_HOST> — основной AW-rus server, health, worktime/reporting, DLP server-side services, Hayabusa processing.
• <GATEWAY_HOST> — operator/gateway host, Telegram bot, web gateway, часть 1C analytics runtime.
• <WINDOWS_HOST> — HOST-EXAMPLE, Windows/RDP host с collector toolkit.
• <GRAFANA_HOST> — Grafana.
• <FIREWALL_HOST> — pfSense, сетевой perimeter и VPN.

Ключевые потоки данных:

• endpoint collector -> AW-rus API -> aw-dlp-endpoint-signals_*, aw-file-operations_*, aw-worktime-sessions_*, aw-dlp-incidents_*;
• server-side policy/case/integration services -> operator workflows и compliance artifacts;
• worktime/management API на :5610 -> management pages, executive summary, trend/source freshness;
• 1C file telemetry -> ClickHouse/API/Grafana management contour;
• EVTX package -> Hayabusa intake -> case linkage / Telegram alert / bounded metadata.

DLP функционал

Endpoint Signals Collector

Файл: windows/dlp-endpoint-signals-collector.ps1

Реализует:

• мониторинг clipboard;
• мониторинг печати;
• мониторинг USB;
• загрузку локальной или server-side DLP policy;
• генерацию heartbeat и incident событий;
• transport queue на диске с lock-файлом и безопасным flush-потоком;
• telemetry по queueDepth, eventsEnqueued, eventsFlushed, sendFailures.

Для action: "block" реализованы активные меры:

• clipboard — очистка буфера обмена;
• USB — write-block через Set-Disk -IsReadOnly;
• print — отмена print jobs.

Важно:

• enforcement уже реализован, но его scope ограничен endpoint/email каналами;
• это не inline network DLP и не full-content gateway.

Browser Domains Collector с категоризацией

Файл: windows/browser-domains-native-collector.ps1

Реализует:

• сбор доменов и web-контекста;
• нормализацию в aw-detmir-web-category_*;
• сопоставление доменов с policy rules;
• генерацию DLP incident событий по web-правилам.

Практическое ограничение:

• web-контур в текущей модели в первую очередь наблюдающий и аналитический;
• Telegram DLP toggle не превращает browser path в настоящий inline web-block.

Email Outbound Collector

Файл: windows/email-outbound-collector.ps1

Реализует:

• мониторинг исходящей почты через Outlook COM и сетевые SMTP-сигналы;
• DLP-правила endpoint.email[];
• reaction path для action: "block" через перемещение письма в Drafts в Outlook mode;
• privacy-preserving подход: тема и получатели могут храниться как hash/metadata, без постоянного чтения тела письма.

DLP Aggregator

Файл: scripts/aggregate_dlp_events.py

Реализует:

• сбор aw-file-operations_* и aw-dlp-incidents_* в нормализованную БД;
• SQLite/PostgreSQL режимы;
• PRAGMA journal_mode=WAL для SQLite;
• основу для Grafana/SIEM-style reporting и поиска по событиям.

DLP Policy API

Каталог: aw-server/dlp-policy-engine/

Реализует:

• централизованную активную policy;
• versioning и checksum;
• endpoint pull-model;
• API GET /api/0/dlp/policies/active;
• API GET /api/0/dlp/policies/active/version;
• agent heartbeat / desired state path.

Это уже production-usable server-side policy layer, но не enterprise policy suite с RBAC, approval matrix и криптографической подписью policy bundle.

Управленческий мониторинг

Management Report Layer на :5610

Файл: aw-server/aw-worktime-api.py

Контур включает:

• GET /reports/worktime/today;
• GET /reports/worktime/management;
• форматы json, csv, html;
• отдельную управленческую интерпретацию рабочего окна против календарной активности.

Алиасы пользователей

Контур поддерживает:

• alias-файл сотрудников;
• owner/department mapping;
• manager-facing rollups по owner и department;
• нормализацию display names и руководителей.

Actions с приоритетами

Management report строит:

• очередь действий;
• critical/high приоритеты;
• owner/department scope;
• executive interpretation уровня “что делать сегодня”.

Source freshness monitoring

В management layer уже встроен контроль свежести источников:

• aw-worktime-sessions_*;
• aw-watcher-window_*;
• aw-watcher-afk_*;
• aw-file-operations_*;
• aw-detmir-web-category_*;
• смежные operational buckets.

Это важно с ИБ-позиции: система различает “данные есть, но пользователь не работал” и “данные stale, поэтому вывод ненадежен”.

Executive summary и trend-анализ

Server-side management report уже выдает:

• summary по active/inactive users;
• actions queue;
• executive summary;
• trend за несколько дней;
• filtered management view по owner/department.

Практический смысл:

• это не просто тайм-трекер;
• это управленческий слой поверх telemetry, который помогает различать operational drift, real inactivity и collector degradation.

Мониторинг и визуализация

Prometheus Exporter

В проекте есть operational contour с Prometheus-compatible health/metrics logic и E2E проверками. Это используется для контроля server-side доступности и для внешних dashboard/alert workflows.

Grafana дашборды

Version-controlled dashboard JSON находятся в grafana/ и clickhouse-1c/grafana/....

Основные экраны:

• RDP/worktime activity;
• DLP и ИБ overview;
• management/security boards;
• 1C file telemetry;
• 1C management board;
• financial reporting board.

SQL Exporter для 1С KPI

Для 1C контура реализован отдельный analytics stack:

• ClickHouse;
• ETL;
• company intelligence marts;
• management pages;
• Grafana dashboards.

Это read-only аналитический слой поверх telemetry и выгрузок, а не write-back path в production 1C.

E2E мониторинг

Контур уже содержит:

• aw-health-check;
• scripts/dlp-health-check.py;
• check-aw-full.sh;
• check-aw-data.sh;
• autoheal для worktime/reporting;
• внешний операторский контроль через Telegram bot.

Proxmox Web Gateway

Развертывание: ansible/deploy_proxmox_web_gateway.yml

Назначение:

• единая внутренняя точка входа для operator/management pages;
• HTTPS reverse entrypoint;
• маршруты на Proxmox GUI, AW-rus UI, management reports, Grafana и 1C pages.

Надежность и отказоустойчивость

WAL buffering

В проекте используются два близких, но разных механизма устойчивости:

• server-side SQLite WAL в policy/case/aggregation storage;
• Windows collector disk queue с lock-файлами и последующим flush в AW API.

Это снижает риск потери событий при кратковременной сетевой недоступности и при transient server-side сбоях.

Graceful shutdown

Collector и server-side сервисы проектировались так, чтобы:

• не терять queued данные при штатной остановке;
• не держать transport lock во время network I/O;
• не блокировать весь pipeline одним зависшим POST.

Health snapshots

Реализованы:

• aw-rus-healthd.py;
• state snapshots в AW_RUS_HEALTH_STATE_DIR;
• validation snapshots по Windows deploy/validation path;
• Hayabusa state snapshots (latest-intake.json).

Это дает operator и ИБ-команде не только “жив/мертв”, но и подтвержденное состояние последней валидации.

Retry с exponential backoff

Реализован retry/backoff path минимум в:

• Windows transport queue flush;
• webhook sender;
• ряде integration/ingest контуров.

Это защищает от transient network/API failure, не превращая ошибку в постоянный incident storm.

Предотвращение дубликатов процессов

В проекте есть отдельная работа против multi-instance regressions:

• lock-файлы для recovery/launch loops;
• проверки на stale queue + held lock;
• hardening deployment для Windows/RDP;
• частичное dedupe по incident/case semantics.

Практически это уменьшает риск process storm и ложных дублей telemetry.

Ротация архивов деплоя

В Windows deploy toolkit и forensic/ingest контурах есть архивирование и ротация:

• deploy/install archives;
• backup/rollback roots;
• Hayabusa package archive и extracted payload archive;
• install-kit snapshots.

Это важно для расследований и rollback, потому что артефакты не исчезают после первой обработки.

Интеграции

Hayabusa forensic анализ

Hayabusa интегрирован как bounded DFIR enrichment:

• Windows экспортирует EVTX package;
• сервер принимает пакет в drop/inbox;
• aw-hayabusa строит forensic report;
• case linkage пишет bounded metadata;
• high-severity path может триггерить Telegram alert.

Ключевая граница:

• Hayabusa не является primary runtime detector;
• это forensic follow-up после инцидентов.

pfSense poller

Файл: pfsense/pfsense-aw-poller.py

Реализует:

• внешний poller для pfSense API;
• отправку сетевой telemetry в ActivityWatch;
• включение firewall/VPN perimeter в единый observability contour.

File-1C telemetry

Файл: windows/export-upload-file-1c-telemetry.ps1

Реализует:

• read-only telemetry по файловым базам 1C;
• snapshots по db size, reglog, active locks, temp markers, scheduler activity;
• передачу данных в аналитический ClickHouse контур.

TSJ Guardian Bot

Файл: proxmox/tsj_guardian_bot.py

Реализует:

• operator-facing health checks;
• DLP mode control;
• bounded auto-heal;
• status, support and investigation commands;
• human-readable operator menu для DLP и forensic path.

MCP / PowerShell remote для AWatch-rus

Документ: docs/POWERSHELL_MCP_REMOTE_RU.md

Реализует:

• operator/Codex remote path к Windows host;
• SSH + powershell.exe вместо WSMan для interactive operations;
• преднастроенный управляемый PowerShell path для <WINDOWS_HOST>.

Деплой и эксплуатация

Proxmox LXC

Базовый production deployment рассчитан на:

• Proxmox;
• LXC/CT для AW-rus server и смежных сервисов;
• отдельные runtime-host'ы для Grafana и operator/gateway paths.

Ansible automation

Репозиторий содержит playbook'и для:

• server deployment;
• Windows deployment через WinRM;
• Grafana dashboard import;
• pfSense poller rollout;
• Proxmox web gateway rollout;
• bot/operator infrastructure.

Windows deploy modes

Поддерживаются:

• single-user;
• domain-users;
• ensemble;
• standalone-service deployment mode;
• validation и hardening/recovery paths.

Backup / rollback

В эксплуатационной модели уже предусмотрены:

• backup-first approach;
• deploy archives;
• rollback roots;
• vzdump/snapshot сценарии для LXC;
• forensic archive paths для intake payloads.

Health validation publishing

Операционная модель уже поддерживает публикацию validation/health state:

• server-side health snapshots;
• Windows validation reports;
• transport freshness checks;
• operator-visible status через runbook и Telegram path.

Безопасность и приватность

Хранение секретов

Проектный принцип:

• реальные секреты не должны лежать в репозитории;
• используются .example и local secret files;
• для PowerShell/MCP отдельно оговорен локальный secret-config с правами 600.

Приватность данных

Ключевые ограничения и свойства:

• система не ведет постоянную запись экрана;
• OCR применяется к incident artifacts, а не к постоянному screen stream;
• email path не обязан хранить тело писем в открытом виде;
• management и 1C слои строятся на read-only telemetry/выгрузках.

Сетевая безопасность

Целевой operational подход:

• внутренний/VPN access вместо лишней публикации сервисов наружу;
• pfSense как perimeter control;
• operator access через gateway и управляемые entrypoints;
• SSH и WinRM разделены по назначению.

Права доступа

Практическая модель прав:

• endpoint collectors и enforcement-функции требуют локальные Windows-права по своему каналу;
• часть enforcement logic требует admin/SYSTEM scope;
• server-side operator actions должны идти через ограниченные operational paths, а не прямой произвольный shell everywhere.

TLS для Proxmox gateway

Proxmox Web Gateway разворачивается через nginx с TLS:

• HTTP redirect на HTTPS;
• TLSv1.2 / TLSv1.3;
• отдельные certificate/key paths;
• по умолчанию возможен self-signed режим;
• для production рекомендуется заменить self-signed на корпоративный сертификат и держать gateway во внутреннем management contour.

Вывод для ИБ

AWatch-rus уже дает практический DLP/monitoring/investigation contour для Windows/RDP и связанного Linux/operator слоя:

• endpoint и email DLP;
• management и source-freshness layer;
• case/integration/reporting path;
• bounded Hayabusa follow-up;
• production automation и health/autoheal.

При этом систему нужно честно оценивать как open-source industrial scaffold с реализованными production-механиками, а не как полностью завершенную enterprise DLP-платформу со встроенным RBAC, SSO и hardware-grade isolation.