docs(wiki): add security, sales and missing wiki pages

2026-05-27 06:40:08 +03:00
parent 3042bd5042
commit 51cb43666a
8 changed files with 1159 additions and 374 deletions
@@ -0,0 +1,52 @@
+# DLP Aggregation
+
+Централизованная агрегация DLP-событий в `AWatch-rus` реализована скриптом:
+
+- `scripts/aggregate_dlp_events.py`
+
+Это server-side слой, который собирает события из bucket-контуров `ActivityWatch` и пишет их в нормализованное хранилище для отчётности, поиска и Grafana/SIEM-style use cases.
+
+## Какие потоки читаются
+
+Сейчас агрегируются:
+
+- `aw-file-operations_*`
+- `aw-dlp-incidents_*`
+
+То есть в агрегатор попадают:
+
+- файловые операции
+- DLP-инциденты
+- связанный контекст хоста и пользователя
+
+## Куда пишутся данные
+
+Поддерживаются два режима:
+
+- `SQLite` — быстрый smoke/runtime без отдельной БД
+- `PostgreSQL` — централизованный reporting path
+
+Для `SQLite` используется `WAL`, чтобы контур был устойчивее при обычной эксплуатации.
+
+## Что даёт агрегатор
+
+Этот слой нужен для:
+
+- централизованного поиска по DLP-событиям
+- Grafana-дашбордов
+- выгрузки в SIEM-подобные контуры
+- нормализации событий из разных bucket-источников
+
+## Инкрементальная работа
+
+Агрегатор хранит state и продолжает сбор с последней успешной точки, чтобы:
+
+- не читать весь исторический массив каждый раз
+- не плодить дубли
+- переживать рестарты и кратковременные сбои
+
+## Канонические документы
+
+- [Основной документ по агрегатору](../dlp-aggregator.md)
+- [Настройка сервера](Server-Setup)
+- [Prometheus + Grafana стек](Monitoring-Setup)
@@ -0,0 +1,107 @@
+# DLP Rules
+
+Базовая DLP-политика в `AWatch-rus` задаётся JSON-файлом:
+
+- `windows/dlp-policy.example.json`
+
+Это основной policy contract для endpoint- и web/DLP-логики.
+
+## Структура политики
+
+Типовой файл содержит разделы:
+
+- `defaults`
+- `rules`
+- `endpoint`
+- `contentAnalysis`
+- `ioc`
+
+## defaults
+
+Глобальные параметры по умолчанию:
+
+- `enabled`
+- `cooldownSeconds`
+- `action`
+- `severity`
+
+## rules
+
+Верхний `rules[]` используется в первую очередь для web/domain сценариев:
+
+- `domains`
+- `categoryGroups`
+- `hourFrom`
+- `hourTo`
+- `message`
+- `action`
+- `severity`
+
+Это полезно для:
+
+- личных сайтов в рабочее время
+- облачных хранилищ
+- anonymizer/VPN web-path
+
+## endpoint
+
+Endpoint-правила разделены по каналам:
+
+- `endpoint.clipboard[]`
+- `endpoint.usb[]`
+- `endpoint.print[]`
+- `endpoint.email[]`
+
+Типовые поля:
+
+- `id`
+- `enabled`
+- `cooldownSeconds`
+- `action`
+- `severity`
+- `message`
+
+Дополнительные условия зависят от канала:
+
+- `regexPatterns`, `minLength` — для clipboard
+- `documentRegex` — для print
+- `subjectRegex`, `recipientRegex`, `attachmentRegex`, `externalOnly` — для email
+
+## contentAnalysis
+
+Этот раздел управляет server-side content analysis контуром:
+
+- `dictionaryPack`
+- `regexPack`
+- `ocrEnabled`
+
+## ioc
+
+IOC-слой позволяет подтягивать внешние индикаторы:
+
+- `enabled`
+- `source`
+- `format`
+- `refreshMinutes`
+
+## Действия
+
+На практике используются:
+
+- `log`
+- `alert`
+- `block`
+
+Важно различать:
+
+- `alert` — зафиксировать и эскалировать
+- `block` — реально ограничить действие, если канал это поддерживает
+
+Полный `block` уже есть для части endpoint/email каналов, но не превращает браузерный путь в полноценный inline web-gateway.
+
+## Канонические документы
+
+- [Пример policy](../../windows/dlp-policy.example.json)
+- [DLP Endpoint Monitoring](DLP-Endpoint-Monitoring)
+- [Email Outbound Monitoring](Email-Outbound-Monitoring)
+- [Категоризация сайтов](Web-Categorization)
@@ -0,0 +1,70 @@
+# Email Outbound Monitoring
+
+Мониторинг исходящей почты в `AWatch-rus` реализован отдельным Windows-коллектором:
+
+- `windows/email-outbound-collector.ps1`
+
+Это production-компонент DLP-контура, а не экспериментальный proof-of-concept.
+
+## Что собирается
+
+Поддерживаются два режима:
+
+- `outlook` — через Outlook COM и папку `Sent Items`
+- `smtp` — через наблюдение SMTP/TCP-соединений
+- `both` — оба режима одновременно
+
+Коллектор пишет:
+
+- `aw-email-monitor_<host>` — email-события и heartbeat
+- `aw-dlp-incidents_<host>` — инциденты при срабатывании DLP-правил
+
+## Что умеет DLP
+
+Email-правила живут в секции:
+
+- `endpoint.email[]`
+
+Поддерживаются типовые условия:
+
+- `subjectRegex`
+- `recipientRegex`
+- `senderRegex`
+- `attachmentRegex`
+- `minAttachments`
+- `minBodyLength`
+- `externalOnly`
+- `internalDomain`
+
+Поддерживаемые действия:
+
+- `alert`
+- `block`
+
+Практическая граница важна:
+
+- полноценный `block` работает в `Outlook mode`
+- в `SMTP mode` система честно фиксирует инцидент и уведомление, но не делает inline network-block
+
+## Где используется
+
+Компонент нужен для:
+
+- DLP по исходящей почте
+- расследований и case path
+- ИБ-дашбордов
+- operator review
+
+## Развёртывание
+
+Коллектор рассчитан на user-session запуск и обычно входит в Windows deployment toolkit:
+
+- `windows/deploy-single-user.ps1`
+- `windows/deploy-domain-users.ps1`
+- `windows/ActivityWatch.Windows.Common.psm1`
+
+## Канонические документы
+
+- [Основной документ по коллектору](../email-outbound-collector.md)
+- [Установка Windows collectors](Windows-Installation)
+- [DLP Правила](DLP-Rules)
@@ -0,0 +1,61 @@
+# Host Groups
+
+Группы хостов в `AWatch-rus` нужны для того, чтобы WebUI показывал не плоский список bucket'ов, а осмысленные operational сегменты.
+
+Основной конфиг:
+
+- `aw-server/aw-host-groups.json`
+
+## Для чего это нужно
+
+Host groups помогают:
+
+- разделять Windows/RDP, Linux workers и инфраструктурные узлы
+- показывать разные полезные ссылки для разных типов хостов
+- не смешивать пользовательскую активность с инфраструктурным шумом
+- сделать WebUI пригодным для DetMir operational use
+
+## Структура конфига
+
+Каждая группа содержит:
+
+- `id`
+- `name`
+- `description`
+- `patterns`
+- `links`
+
+`patterns` — это regex-маски по hostname.  
+`links` — это действия и переходы, которые WebUI показывает для группы.
+
+## Что уже используется в DetMir
+
+В текущем конфиге есть группы:
+
+- `pve-detmir`
+- `windows-rdp`
+- `linux-remote`
+- `virtual-infra`
+
+Примеры полезных ссылок внутри групп:
+
+- `Активность`
+- `DLP`
+- `SSH сессии`
+- `Команды shell`
+- `Web категории`
+- `Все бакеты`
+
+## Где применяется
+
+Этот контур используется в русифицированном WebUI и в DetMir host grouping path.
+
+Связанные файлы:
+
+- `aw-server/apply_webui_ru_patch.sh`
+- `docs/wiki/WebUI-Russian-Patches.md`
+
+## Канонические документы
+
+- [WebUI Русификация](WebUI-Russian-Patches)
+- [Конфиг групп хостов](../../aw-server/aw-host-groups.json)
@@ -0,0 +1,52 @@
+# Prometheus Exporter
+
+`AWatch-rus` использует Prometheus-compatible exporter path для operational monitoring и Grafana.
+
+Назначение контура простое:
+
+- собрать health и activity-метрики из `ActivityWatch`
+- отдать их в формате Prometheus
+- использовать дальше в `Prometheus -> Grafana -> alerts`
+
+## Что экспортируется
+
+Типовые группы метрик:
+
+- состояние bucket-источников
+- активность хостов
+- collector heartbeat
+- exporter health
+- временные метки последней активности
+
+## Основные endpoint'ы
+
+Обычно используются:
+
+- `/metrics`
+- `/health`
+
+## Где применяется
+
+Exporter нужен для:
+
+- Grafana operational dashboards
+- внешнего мониторинга доступности
+- алертинга по деградации collector/runtime path
+- E2E health checks
+
+## Практический контур
+
+В репозитории monitoring path уже связан с:
+
+- `Prometheus`
+- `Grafana`
+- `AW-rus health checks`
+- `check-aw-full.sh`
+
+То есть это не “метрики ради метрик”, а часть рабочего operational контроля.
+
+## Канонические документы
+
+- [Monitoring Setup](Monitoring-Setup)
+- [Компонентная диаграмма exporter](../diagrams/prometheus-exporter.md)
+- [Компоненты системы](Components)
@@ -0,0 +1,60 @@
+# Web Categorization
+
+В `AWatch-rus` web-категоризация используется для того, чтобы browser/domain telemetry была пригодна не только для raw-логов, но и для DLP, worktime и управленческой аналитики.
+
+## Источник данных
+
+Основной Windows-компонент:
+
+- `Browser Domains Collector`
+
+События попадают в bucket-поток:
+
+- `aw-detmir-web-category_<host>`
+
+## Зачем нужна категоризация
+
+Она позволяет:
+
+- отделять рабочие ресурсы от нейтральных и личных
+- строить DLP-правила по категориям
+- использовать browser telemetry в worktime и management-отчётах
+- давать понятный руководителю и ИБ срез, а не просто список доменов
+
+## Кастомные правила
+
+Для override/extension используется файл:
+
+- `windows/web-category-rules.example.json`
+
+Типовая группировка:
+
+- `work`
+- `neutral`
+- `personal`
+
+Правила задаются по доменам и root-domain логике.
+
+## Связь с DLP policy
+
+Web-категории используются вместе с `windows/dlp-policy.example.json`, где верхний `rules[]` может ссылаться на:
+
+- `categoryGroups`
+- конкретные `domains`
+- временные окна (`hourFrom` / `hourTo`)
+
+## Практическая граница
+
+Текущий browser path в первую очередь:
+
+- наблюдающий
+- аналитический
+- policy-aware
+
+То есть категоризация уже production-usable, но не равна полноценному inline secure web gateway.
+
+## Канонические документы
+
+- [Browser Domains Monitoring](Browser-Domains-Monitoring)
+- [Пример category rules](../../windows/web-category-rules.example.json)
+- [Пример DLP policy](../../windows/dlp-policy.example.json)