From 51cb43666a89db02920f1ae34765f4a244601add Mon Sep 17 00:00:00 2001 From: igor04091968 Date: Wed, 27 May 2026 06:40:08 +0300 Subject: [PATCH] docs(wiki): add security, sales and missing wiki pages --- SALES_OVERVIEW_RU.md | 677 +++++++++++-------------- SECURITY_OVERVIEW_RU.md | 454 +++++++++++++++++ docs/wiki/DLP-Aggregation.md | 52 ++ docs/wiki/DLP-Rules.md | 107 ++++ docs/wiki/Email-Outbound-Monitoring.md | 70 +++ docs/wiki/Host-Groups.md | 61 +++ docs/wiki/Prometheus-Exporter.md | 52 ++ docs/wiki/Web-Categorization.md | 60 +++ 8 files changed, 1159 insertions(+), 374 deletions(-) create mode 100644 SECURITY_OVERVIEW_RU.md create mode 100644 docs/wiki/DLP-Aggregation.md create mode 100644 docs/wiki/DLP-Rules.md create mode 100644 docs/wiki/Email-Outbound-Monitoring.md create mode 100644 docs/wiki/Host-Groups.md create mode 100644 docs/wiki/Prometheus-Exporter.md create mode 100644 docs/wiki/Web-Categorization.md diff --git a/SALES_OVERVIEW_RU.md b/SALES_OVERVIEW_RU.md index edbb5be..4d07c59 100644 --- a/SALES_OVERVIEW_RU.md +++ b/SALES_OVERVIEW_RU.md @@ -1,501 +1,430 @@ -# AW-rus: корпоративный мониторинг активности и DLP-контур +# AWatch-rus: обзор решения для продажи и коммерческого представления ## Executive Summary -**AW-rus** — это корпоративная система мониторинга рабочей активности сотрудников с DLP-функциями, построенная на open-source базе ActivityWatch и дополненная промышленным контуром сбора, аналитики, правил, визуализации и автоматизации развертывания. +`AWatch-rus` — это корпоративная система мониторинга активности сотрудников с DLP-функциями, управленческим слоем и интеграцией в существующий ИТ/ИБ-контур компании. -Решение ориентировано на компании сегмента **SMB** и **mid-market**, которым нужен практичный баланс между контролем, безопасностью и стоимостью владения. AW-rus закрывает задачи: +По сути это практичный средний слой между простыми time-tracker решениями и тяжелыми enterprise DLP-платформами: -- мониторинга активности пользователей в Windows и Linux; -- выявления событий, потенциально связанных с утечкой данных; -- учета рабочего времени и активности в RDP-сессиях; -- визуализации данных для ИБ, руководства и операционных команд; -- быстрого развертывания без тяжелого агентского ПО и vendor lock-in. +- есть контроль действий пользователей и DLP-сигналы; +- есть реальный management layer, а не только сырые события; +- есть интеграции с `1С`, Grafana, Linux-инфраструктурой и forensic follow-up; +- при этом стоимость входа и сопровождения обычно ниже, чем у классических enterprise-комплексов. -### Позиционирование +Решение особенно уместно там, где: -AW-rus — это **корпоративная система мониторинга активности с DLP-функциями**, которая занимает нишу между: - -- простыми табельными/тайм-трекерными продуктами без ИБ-контроля; -- тяжелыми enterprise DLP-платформами с высокой стоимостью лицензий и внедрения. - -### Ключевое отличие - -- **Open-source база**: нет жесткой привязки к вендору. -- **Легкий агентский слой**: Windows-коллекторы реализованы на PowerShell без тяжелых проприетарных агентов и без kernel-mode драйверов. -- **Гибкая настройка**: правила, категории, дешборды и сценарии интеграции адаптируются под конкретную организацию. -- **Полная русификация**: интерфейсы и дашборды ориентированы на русскоязычных пользователей и ИБ-службу. - -### Целевая аудитория - -- компании от **25 до 500+ рабочих мест**; -- организации с удаленными сотрудниками и RDP-сценариями; -- предприятия с 1С, бухгалтерией, HR и ИБ-контролем; -- компании, которым нужен DLP-подход без стоимости классических enterprise-комплексов. - ---- +- есть `Windows` и `RDP`-сценарии; +- важен контроль активности и дисциплины данных; +- уже используется `1С`; +- нужен open-source контур без жесткой привязки к одному вендору. ## Основные возможности -## 1. DLP-мониторинг +### DLP мониторинг -AW-rus собирает и обрабатывает события, связанные с потенциальной утечкой данных: +Система уже собирает и обрабатывает: -- **clipboard monitoring** — контроль буфера обмена; -- **print monitoring** — контроль печати; -- **file operations** — мониторинг файловых операций; -- **browser monitoring** — события браузеров и web-активности; -- **outgoing email monitoring** — контроль исходящей почты; -- **endpoint signals** — единый поток сигналов для разборов, правил и отчетности. +- события `clipboard`; +- печать; +- `USB`; +- браузерные домены и web-категории; +- исходящую почту; +- файловые операции; +- DLP-инциденты и review workflow. -### Что это дает бизнесу +### Enforcement -- раннее обнаружение рискованных действий; -- прозрачность действий сотрудников при работе с чувствительной информацией; -- возможность не только увидеть событие, но и связать его с пользователем, сессией и рабочим контекстом. +`AWatch-rus` умеет не только наблюдать, но и ограничивать: -## 2. Enforcement +- `clipboard block`; +- `USB write-block`; +- отмену печати; +- block path для email в поддерживаемом Outlook-сценарии. -Помимо мониторинга, система поддерживает контур **enforcement**: +Это дает возможность внедрять контур поэтапно: сначала `monitor`, затем `enforce`. -- блокировка или ограничение **USB-сценариев**; -- блокировка или ограничение **печати**; -- контроль и ограничение **clipboard-сценариев**; -- управление реакцией через правила и действия. +### Браузеры -Это позволяет перейти от режима “просто логируем” к режиму “контролируем и предотвращаем”. +Поддерживается: -## 3. Мониторинг браузеров с категоризацией +- сбор доменов и web-контекста; +- категоризация активности; +- связка браузерной телеметрии с DLP и worktime; +- использование данных в dashboard и incident path. -Система поддерживает: +### Email -- мониторинг браузерной активности; -- категоризацию доменов и рабочих сценариев; -- разделение на рабочую, нейтральную и потенциально рискованную активность; -- использование данных в отчетах, дешбордах и правилах. +Поддерживается: -## 4. Мониторинг исходящей почты +- мониторинг исходящей почты; +- правила `endpoint.email[]`; +- сигналы по теме, адресатам и вложениям; +- блокирующий сценарий в Outlook mode. -AW-rus может выявлять события, связанные с исходящей почтой: +### Worktime -- факт отправки; -- контекст пользователя и хоста; -- использование в DLP-пайплайне и ИБ-разборе. +Система дает: -## 5. Учет рабочего времени +- фактический worktime по RDP-сессиям; +- ежедневные отчеты; +- `HTML/CSV/JSON` выдачу; +- server-side management reporting на `:5610`. -Решение поддерживает учет фактической активности: +### Management Report Layer -- активность в **RDP-сессиях**; -- данные по пользователям и сессиям; -- ежедневные и почасовые агрегаты; -- HTML/CSV/JSON-отчеты; -- управленческие Grafana-дешборды по активности пользователей. +Это одна из самых сильных частей решения. Поверх телеметрии строится: -Практически это означает, что компания получает не “формальное время входа”, а данные о **реальной активности в рабочем контуре**. +- управленческий отчет; +- очередь действий по сотрудникам и подразделениям; +- source freshness; +- executive summary; +- trend-анализ. -## 6. Интеграция с 1С +### Интеграция с 1С -Для сред с 1С решение поддерживает отдельный аналитический слой: +Есть отдельный file-based `1С` analytics contour: -- Grafana-дешборды по данным 1С; -- интеграцию с MSSQL/PostgreSQL-источниками в контуре 1С; -- использование для HR, бухгалтерии, ИБ и управленческой отчетности. +- telemetry по файловым базам; +- `ClickHouse`-модели; +- company intelligence; +- manager brief и management actions; +- Grafana boards для руководителя и операционного контура. -## 7. Linux-поддержка +### Linux поддержка -AW-rus рассчитан не только на Windows-среду: +Решение не замкнуто только на Windows: -- поддерживается Linux-серверный контур; -- есть поддержка сценариев удаленной работы; -- возможен аудит и логирование **SSH-активности**; -- решение подходит для смешанных Windows/Linux-инфраструктур. +- Linux server-side runtime; +- Linux operational integrations; +- SSH/console logging; +- смешанный Windows/Linux operational model. -## 8. Интеграция с pfSense +### pfSense -AW-rus можно встроить в сетевой и ИБ-контур организации: +Система может быть включена в perimeter/security contour компании через: -- интеграция с **pfSense**; -- визуализация логов и инфраструктурных событий; -- использование в едином мониторинговом ландшафте вместе с Grafana, InfluxDB, Prometheus и Loki. +- внешний `pfSense` poller; +- передачу network telemetry в общий контур; +- единый operator visibility path. ---- +### Forensic анализ + +`Hayabusa` интегрирован как bounded DFIR layer: + +- EVTX export с Windows; +- server-side processing; +- case linkage; +- Telegram alert path для follow-up. + +Это усиливает ценность решения для ИБ без превращения продукта в отдельную SIEM/DFIR-платформу. + +## Управленческие функции + +### Management Report Layer + +Руководитель получает не просто технические bucket-данные, а: + +- картину по активности сотрудников; +- сводку по owner/department; +- проблемные зоны и приоритеты; +- понятную очередь действий. + +### Actions с приоритетами + +Система умеет формировать: + +- `critical/high` actions; +- рекомендации, кого проверять первым; +- причины для escalation; +- управленческий список действий без ручного разбора сырых событий. + +### Executive summary + +Management API и `1С` management brief формируют human-readable summary уровня: + +- что сломалось; +- где данные stale; +- кто не показывает активность; +- какие пользователи и предприятия требуют внимания в первую очередь. + +### Trend-анализ + +В продукт уже встроены: + +- несколько дней тренда по worktime; +- trend и weekly views в `1С` intelligence contour; +- сравнительный анализ текущего и исторического состояния. + +### Source freshness + +Это критически важная функция для менеджмента и ИБ: + +- система показывает, где проблема в поведении пользователя, а где в деградации источника; +- решения не принимаются вслепую по сломанной телеметрии. + +### Алиасы пользователей + +Поддерживаются: + +- normalized user aliases; +- owner/department mapping; +- manager-facing каталоги ответственных. + +За счет этого отчеты пригодны для бизнеса, а не только для инженеров. ## Архитектура и компоненты -AW-rus построен как **трехуровневая архитектура**. +Архитектура строится как цепочка: -## 1. Уровень сбора +- `Windows Clients / RDP host`; +- `Linux Server`; +- `Integration Layer`; +- `Monitoring Stack`; +- выделенный `Forensic Layer`. -### Windows-коллекторы +Практически это означает: -На рабочих станциях и RDP-хостах используются PowerShell-коллекторы, в том числе: +- Windows PowerShell collectors; +- Linux `AW-rus` server; +- DLP Policy API и Case API; +- Grafana/Prometheus/ClickHouse analytics; +- Proxmox/operator gateway; +- `Hayabusa` follow-up path. -- сбор активности окон; -- сбор AFK-статуса; -- сбор RDP session activity; -- сбор DLP endpoint signals; -- сбор browser/domain activity; -- сбор file operations; -- сбор исходящей почты и дополнительных сигналов. +### Windows коллекторы -Преимущество такого подхода: +В состав входят: -- легкий агентский слой; -- простое сопровождение; -- высокая прозрачность логики; -- отсутствие тяжелого проприетарного бинарного агента как обязательного элемента. +- endpoint DLP collector; +- browser domains collector; +- file operations collector; +- email outbound collector; +- worktime session collector; +- deploy/hardening/validation toolkit. -## 2. Уровень хранения и обработки +### Linux сервер -### Linux-сервер AW-rus +Серверный слой включает: -Серверный контур разворачивается на Linux и включает: +- `ActivityWatch` API и WebUI; +- RU patch и DLP overlay; +- `aw-worktime-api` на `:5610`; +- policy engine; +- case management; +- health/autoheal path. -- **ActivityWatch Server** как базовый контур приема событий; -- серверные сервисы аналитики и API; -- DLP policy engine; -- DLP case management; -- worktime API; -- export-пайплайны в InfluxDB/Grafana; -- генерацию compliance и forensic-артефактов. +### Monitoring стек -### Что важно уточнить +Визуализация и наблюдаемость строятся через: -Базовое оперативное хранилище ActivityWatch использует собственный серверный storage-контур. При этом AW-rus уже интегрирован с внешними источниками и аналитическими БД: +- Grafana; +- Prometheus-compatible monitoring path; +- `1С` analytics dashboards; +- Proxmox Web Gateway как operator entrypoint. -- **InfluxDB** для временных рядов и Grafana-дешбордов; -- **PostgreSQL / MSSQL** в интеграционных сценариях, например для 1С; -- дополнительные ИБ и отчетные контуры по мере развития решения. +### Proxmox Web Gateway -То есть продукт не завязан на одну технологию хранения и может быть встроен в существующий ландшафт компании. +Gateway дает: -## 3. Уровень визуализации и мониторинга - -Используется современный стек визуализации: - -- **Grafana** для управленческих и ИБ-дешбордов; -- **Prometheus** и related monitoring stack для операционного мониторинга; -- дополнительные интеграции с логовым и сетевым контуром. - ---- +- одну точку входа для операторов и руководства; +- маршруты на Proxmox GUI, AW-rus UI, management pages, Grafana; +- HTTPS access path для внутреннего management contour. ## Преимущества перед конкурентами -## 1. Open-source база +### Open-source - нет vendor lock-in; -- прозрачная архитектура; -- высокая кастомизируемость; -- контроль над развитием продукта внутри компании или подрядчика. +- прозрачный код и архитектура; +- можно дорабатывать под процессы заказчика; +- проще аудитировать и сопровождать. -## 2. Легкий агент +### Легкий агент -Во многих коммерческих DLP-решениях агент: +- PowerShell collector model; +- нет обязательного тяжелого kernel-level агента; +- легче пилот и проще сопровождение. -- тяжелый; -- чувствителен к обновлениям ОС; -- сложен в сопровождении; -- заметно влияет на рабочие станции. +### Гибкая DLP политика -В AW-rus агентский слой сделан легче: +- JSON-based policy; +- server-side policy API; +- monitor/enforce режимы; +- адаптация под реальные каналы утечки и корпоративные правила. -- PowerShell-коллекторы; -- меньше технологической инерции; -- быстрее адаптация под конкретные процессы компании. +### Русификация -## 3. Гибкая DLP-политика +- русифицированный WebUI; +- русские Grafana dashboards; +- русская эксплуатационная документация; +- нормальная operator terminology без англоязычного vendor-noise. -Логика правил и действий может быть адаптирована под реальные бизнес-процессы: +### Linux поддержка -- JSON-based rules; -- кастомные workflow; -- управляемые реакции и дешборды; -- возможность быстро менять политику без полной замены системы. +- Linux server-side runtime; +- Linux operational integrations; +- гибридный Windows/Linux контур. -## 4. Полная русификация +### Management Layer -Для многих open-source решений слабое место — интерфейс и документация. В AW-rus это закрыто: +Это сильная дифференциация относительно простых time-tracker решений: -- русифицированный Web UI; -- русифицированные Grafana-дешборды; -- документация и runbook’и на русском языке. +- actions; +- executive summary; +- source freshness; +- owner/department rollups; +- trend и management pages. -## 5. Linux-поддержка +### Низкая стоимость владения -Большинство SMB-решений фокусируется только на Windows. AW-rus поддерживает смешанные среды, что важно для: +По сравнению с классическими enterprise DLP-платформами заказчик получает шанс: -- DevOps/IT-команд; -- удаленных Linux-пользователей; -- инфраструктурных подразделений; -- гибридных компаний. +- снизить лицензионную нагрузку; +- не переплачивать за лишний функционал; +- дешевле входить в пилот; +- лучше контролировать стоимость масштабирования. -## 6. Низкая стоимость владения - -По сравнению с enterprise DLP-классом AW-rus потенциально позволяет: - -- снизить лицензирование на **40–70%**; -- сократить стоимость пилота и внедрения; -- уменьшить зависимость от платных vendor-specific модулей; -- масштабировать систему без кратного роста лицензионной нагрузки. - -Точная экономия зависит от числа пользователей, требований по enforcement и интеграциям, но именно TCO — одна из сильнейших сторон продукта. - -## 7. Быстрое развертывание - -За счет связки **Ansible + PowerShell** типовой пилот можно запускать быстро: - -- пилотная зона — от **1–2 рабочих дней**; -- расширение на новый сегмент — без ручной пересборки архитектуры; -- повторяемый deployment без “магии в голове внедренца”. - ---- +Корректная подача здесь простая: это не “бесплатная замена любому enterprise DLP”, а прагматичный контур с сильным TCO-профилем. ## Сценарии использования -## Защита от утечек данных +### Защита от утечек -Подходит для компаний, где нужно: +Подходит, если нужно: -- видеть попытки небезопасной передачи данных; -- контролировать печать, буфер обмена, файловые операции и email; -- внедрять не только мониторинг, но и policy-driven enforcement. +- видеть рискованные действия по `clipboard`, `USB`, печати, email, browser и files; +- фиксировать инциденты; +- в нужных каналах включать block/restrict path. -## Мониторинг продуктивности +### Мониторинг продуктивности -Решение позволяет: +Подходит, если компании нужно: -- видеть реальную активность пользователей; -- анализировать работу по дням, часам и пользователям; -- строить прозрачные управленческие отчеты. +- учитывать активность в RDP; +- получать реальные worktime-данные; +- понимать, кто неактивен по факту, а не по формальному входу в систему. -## Комплаенс и 152-ФЗ +### Комплаенс 152-ФЗ -Для российских организаций это особенно важно: +Система полезна как practical control/evidence layer: -- формирование контуров контроля доступа и действий; -- накопление артефактов для внутренних разборов; -- поддержка compliance-отчетности; -- возможность встроить продукт в регламент по защите персональных данных. +- DLP incidents; +- compliance reports; +- operator review; +- контроль работы с чувствительными данными. -## Интеграция с 1С для HR и бухгалтерии +Это не “автоматическая сертификация”, а инструмент реального operational compliance support. -Компании, где 1С — ключевая система, получают: +### Интеграция с 1С -- отдельный слой аналитики; -- мониторинг рабочих сценариев вокруг 1С; -- данные для HR, ИБ и руководителей. +Подходит для компаний, где важно: -## Мониторинг удаленных сотрудников +- видеть состояние файловых баз; +- понимать активность и риски по предприятиям; +- связывать ИТ, ИБ и управленческий слой. -Особенно актуально для: +### Управленческий контроль -- RDP-хостов; -- распределенных филиалов; -- гибридного формата работы; -- аутсорсинговых и бэк-офисных подразделений. +Подходит для: ---- +- руководителей подразделений; +- операционных менеджеров; +- ИБ и ИТ, которым нужны единые summary и actions; +- сменных и распределенных управленческих контуров. + +### Forensic анализ + +Полезен для заказчиков, которым нужен: + +- bounded forensic follow-up; +- EVTX-based post-incident path; +- связка инцидента, кейса и расследования в одном operational контуре. ## Технические требования -## Клиентская часть +Базовый practical profile: -- Windows 10 / 11; -- терминальные/RDP-сценарии; -- PowerShell-совместимая среда; -- возможность разворачивать scheduled tasks и агентские скрипты. +- `Windows 10/11` для рабочих станций; +- `Windows Server` / RDP-host сценарии, включая текущий production-target `Windows Server 2025`; +- `Linux` серверный контур на `Debian/Ubuntu`; +- `Docker` для части monitoring/analytics stack; +- `PostgreSQL` и/или другие аналитические БД в интеграционных сценариях; +- `ClickHouse` для file-based `1С` analytics; +- Grafana для визуализации. -## Серверная часть - -- Linux, предпочтительно **Debian / Ubuntu**; -- выделенный сервер или VM под AW-rus; -- сетевой доступ до клиентского контура; -- базовый эксплуатационный контур Linux-сервисов. - -## Аналитика и мониторинг - -- **InfluxDB** для временных рядов; -- **Grafana** для дешбордов; -- **Prometheus** и/или смежный monitoring stack; -- при интеграциях — PostgreSQL / MSSQL / SQL exporter / внешние источники. - -## Инфраструктура - -- Docker или контейнерный/VM-контур для мониторингового стека; -- Ansible для повторяемого deployment; -- возможность сетевых интеграций с pfSense и инфраструктурными сервисами. - ---- +Иными словами, продукт не требует exotic stack и нормально ложится в типовую инфраструктуру компании. ## Уровни зрелости продукта -Развитие AW-rus уже имеет практический roadmap и реализованные уровни зрелости. +Состояние продукта корректно описывать так: -## Phase 1: Базовый мониторинг +- operational phases `1-3` по production health, operator path и Windows hardening уже закрыты; +- server-side DLP chain, content-analysis base и docs/release sync уже реализованы; +- maturity по DLP roadmap сейчас выглядит так: + - `Phase 1` — сделано; + - `Phase 2` — внедрено частично; + - `Phase 2.5` enforcement и email outbound — внедрены; + - `Phase 3+` — дальнейшее развитие policy/correlation/SIEM/advanced analytics. -**Реализовано** +Roadmap дальше идет в сторону: -- мониторинг оконной активности; -- базовая визуализация в ActivityWatch; -- базовый operational stack. +- deeper DLP runtime; +- дополнительных regression guards; +- усиления management и integration layer. -## Phase 2: DLP endpoint monitoring - -**Реализовано** - -- endpoint signals; -- browser monitoring; -- file operations; -- базовая DLP-корреляция; -- DLP dashboards. - -## Phase 2.5: Enforcement - -**Реализовано** - -- policy-driven блокировки и ограничения; -- контур правил и реакций; -- практический enforcement layer. - -## Phase 3: Email monitoring - -**Реализовано** - -- мониторинг исходящей почты; -- включение email-событий в DLP-контур. - -## Roadmap развития - -Следующие логичные направления развития: - -- расширение каталогов DLP-классификации; -- развитие кейс-менеджмента и цепочки доказательств; -- более глубокая интеграция с SIEM/SOAR; -- расширение Linux endpoint coverage; -- advanced analytics для руководства и ИБ. - ---- +То есть продукт уже production-usable, но остается пространством для целевых enterprise-усилений под конкретного заказчика. ## Стоимость и ROI -## Почему экономически это интересно +### Сравнение с enterprise решениями -Enterprise DLP-решения часто стоят дорого не только по лицензии, но и по: +Типовой enterprise DLP-проект часто означает: -- стоимости внедрения; -- стоимости сопровождения; -- закрытости интеграций; -- цене масштабирования; -- необходимости использовать проприетарную экосистему. +- дорогое лицензирование; +- тяжелый агент; +- длительный rollout; +- дорогое сопровождение изменений. -AW-rus снижает эти расходы за счет: +`AWatch-rus` выигрывает там, где заказчику важны: -- open-source базы; -- отсутствия жесткой лицензионной модели на ядро платформы; -- легких агентов; -- повторяемой автоматизации; -- возможности доработки под клиента без полной смены продукта. +- lower entry cost; +- управляемый пилот; +- понятная архитектура; +- возможность адаптации без полной смены платформы. -## Пример экономического эффекта +### Экономия на лицензиях -Для SMB/mid-market сценариев типичный эффект может выражаться в: +Корректная коммерческая формулировка такая: -- сокращении TCO на **40–70%** относительно классических enterprise DLP; -- запуске пилота без многомесячного проекта; -- более быстром выходе на прикладную пользу для ИБ и руководства. - -## Быстрый ROI - -ROI достигается быстрее, если компании критичны: - -- контроль удаленных сотрудников; -- защита от утечек; -- прозрачность работы в RDP/офисных контурах; -- аналитика для ИБ и управленцев в единой системе. - ---- +- заказчик потенциально экономит на лицензиях и внедрении по сравнению с тяжелыми enterprise-пакетами; +- итоговая экономия зависит от числа endpoint'ов, объема enforcement, требований к SIEM/SSO/RBAC и объема кастомизации; +- сильная сторона решения — контролируемая стоимость владения, а не обещание “заменить все enterprise DLP в один клик”. ## Поддержка и обучение -## Документация +Проект уже опирается на: -Продукт сопровождается документацией, runbook’ами, конфигами и эксплуатационными материалами. +- подробную русскую документацию; +- runbook и deployment guides; +- Ansible и PowerShell automation; +- community-style support model; +- возможность кастомизации под нужды конкретного заказчика. -## Community и open-source подход +Для коммерческого внедрения это означает, что можно предложить: -Open-source база дает: - -- прозрачность развития; -- гибкость интеграций; -- возможность не зависеть от закрытого vendor roadmap. - -## Кастомизация - -AW-rus особенно силен там, где нужен не “коробочный компромисс”, а адаптация под среду заказчика: - -- категории; -- DLP-политики; -- отчеты; -- дешборды; -- интеграции с 1С, pfSense и внутренними системами. - ---- +- пилот; +- rollout; +- обучение операторов и ИБ; +- кастомизацию dashboard, policy и integration path. ## Контакты и следующий шаг -## Как начать +Практический следующий шаг для потенциального заказчика: -Оптимальный путь внедрения: +1. Провести короткий discovery по инфраструктуре, числу Windows/RDP-host'ов и наличию `1С`. +2. Определить, нужен ли только monitor-mode или сразу важен enforcement path. +3. Выделить пилотный сегмент. +4. Поднять pilot deployment с management report layer и базовым DLP/monitoring контуром. +5. После пилота решить, какие enterprise-усиления действительно нужны, а какие не дадут окупаемого эффекта. -1. определить пилотный контур; -2. выбрать 1–2 бизнес-сценария с быстрым эффектом; -3. развернуть серверный контур и пилотную группу клиентов; -4. согласовать дешборды, правила и роли пользователей; -5. перейти к промышленному расширению. - -## Demo и пилот - -Рекомендуемый формат старта: - -- demo-сессия для бизнеса и ИБ; -- пилот на ограниченной группе пользователей; -- оценка эффекта на реальных данных компании; -- решение о масштабировании на всю организацию. - -## Визуальная презентация - -Для демонстрации живых интерфейсов и dashboard'ов используйте: - -- [docs/PRESENTATION_RU.md](docs/PRESENTATION_RU.md) - -В документ уже включены скриншоты: - -- управленческого dashboard по активности пользователей в RDP; -- технического DLP/ИБ dashboard; -- управленческого ИБ dashboard; -- обзорного DLP dashboard; -- экранов AW-rus с activity summary и raw DLP bucket. - -## Что получает заказчик на первом этапе - -- работающий мониторинговый контур; -- дешборды для руководства и ИБ; -- DLP-сигналы и кейсы; -- отчеты по активности и рабочему времени; -- понятную основу для дальнейшего развития. - ---- - -## Краткий вывод - -AW-rus — это не “еще один тайм-трекер” и не попытка копировать тяжёлые enterprise DLP-системы один в один. Это практичный корпоративный продукт для компаний, которым нужен: - -- контроль активности; -- DLP-подход; -- русскоязычный интерфейс; -- Linux- и RDP-ориентированная архитектура; -- внятная экономика внедрения; -- отсутствие vendor lock-in. - -Для SMB и mid-market это особенно сильное сочетание: **реальные функции корпоративного контроля без избыточной стоимости классических enterprise DLP-комплексов**. +Самая сильная подача продукта простая: не обещать “всё для всех”, а показывать, что `AWatch-rus` уже дает работающий operational control contour с DLP, management и forensic follow-up там, где многие компании либо переплачивают за тяжелые платформы, либо вообще живут без управляемого контроля. diff --git a/SECURITY_OVERVIEW_RU.md b/SECURITY_OVERVIEW_RU.md new file mode 100644 index 0000000..e3c583a --- /dev/null +++ b/SECURITY_OVERVIEW_RU.md @@ -0,0 +1,454 @@ +# 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 для `DetMir`: + +- `10.10.10.13` — основной `AW-rus` server, health, worktime/reporting, DLP server-side services, `Hayabusa` processing. +- `10.10.10.2` — operator/gateway host, Telegram bot, web gateway, часть `1C` analytics runtime. +- `192.168.100.18` — `SHARKON2025`, Windows/RDP host с collector toolkit. +- `10.10.10.11` — Grafana. +- `10.10.10.1` — `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 для DetMir + +Документ: `docs/DETMIR_POWERSHELL_MCP_REMOTE_RU.md` + +Реализует: + +- operator/Codex remote path к Windows host; +- `SSH + powershell.exe` вместо `WSMan` для interactive operations; +- преднастроенный управляемый PowerShell path для `192.168.100.18`. + +## Деплой и эксплуатация + +### 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. diff --git a/docs/wiki/DLP-Aggregation.md b/docs/wiki/DLP-Aggregation.md new file mode 100644 index 0000000..f2af65a --- /dev/null +++ b/docs/wiki/DLP-Aggregation.md @@ -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) diff --git a/docs/wiki/DLP-Rules.md b/docs/wiki/DLP-Rules.md new file mode 100644 index 0000000..a3d43db --- /dev/null +++ b/docs/wiki/DLP-Rules.md @@ -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) diff --git a/docs/wiki/Email-Outbound-Monitoring.md b/docs/wiki/Email-Outbound-Monitoring.md new file mode 100644 index 0000000..7a57e94 --- /dev/null +++ b/docs/wiki/Email-Outbound-Monitoring.md @@ -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_` — email-события и heartbeat +- `aw-dlp-incidents_` — инциденты при срабатывании 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) diff --git a/docs/wiki/Host-Groups.md b/docs/wiki/Host-Groups.md new file mode 100644 index 0000000..a3e6f38 --- /dev/null +++ b/docs/wiki/Host-Groups.md @@ -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) diff --git a/docs/wiki/Prometheus-Exporter.md b/docs/wiki/Prometheus-Exporter.md new file mode 100644 index 0000000..9d9be8e --- /dev/null +++ b/docs/wiki/Prometheus-Exporter.md @@ -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) diff --git a/docs/wiki/Web-Categorization.md b/docs/wiki/Web-Categorization.md new file mode 100644 index 0000000..57c806c --- /dev/null +++ b/docs/wiki/Web-Categorization.md @@ -0,0 +1,60 @@ +# Web Categorization + +В `AWatch-rus` web-категоризация используется для того, чтобы browser/domain telemetry была пригодна не только для raw-логов, но и для DLP, worktime и управленческой аналитики. + +## Источник данных + +Основной Windows-компонент: + +- `Browser Domains Collector` + +События попадают в bucket-поток: + +- `aw-detmir-web-category_` + +## Зачем нужна категоризация + +Она позволяет: + +- отделять рабочие ресурсы от нейтральных и личных +- строить 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)