docs(wiki): add security, sales and missing wiki pages
This commit is contained in:
igor04091968
+303
-374
@@ -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 там, где многие компании либо переплачивают за тяжелые платформы, либо вообще живут без управляемого контроля.
|
||||
|
||||
@@ -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.
|
||||
@@ -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)
|
||||
Reference in New Issue
Block a user