Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
 IgorRachkov
|
ae048ac1c8 | ||
|
IgorRachkov
|
ded569207e | ||
|
IgorRachkov
|
55c0d06baa | ||
|
IgorRachkovandGitHub
|
3b5fe0c116 | ||
|
IgorRachkovandGitHub
|
a2575233b7 | ||
|
igor04091968
|
8236789781 | ||
|
IgorRachkovandGitHub
|
02967629ff | ||
|
IgorRachkovandGitHub
|
ff6d7155cd |
@@ -38,3 +38,82 @@
|
||||
Продукт относится к классу средств управления ИТ-службой,
|
||||
ИТ-инфраструктурой и ИТ-активами. Продукт не заявляется как
|
||||
сертифицированная DLP, SIEM, EDR/XDR или средство защиты информации.
|
||||
|
||||
|
||||
## Профессиональные сильные стороны проекта
|
||||
|
||||
Ниже — краткая и профессиональная сводка ключевых преимуществ AWatch-rus,
|
||||
предназначенная для реестра программного обеспечения и технического аудитa.
|
||||
|
||||
### 1. Архитектура и инженерный дизайн
|
||||
|
||||
- Rust-first, модульная архитектура: более 40 специализированных крейтов в
|
||||
workspace, четкая декомпозиция ответственности и воспроизводимые сборки
|
||||
(Cargo.lock).
|
||||
- Разделение на логические уровни: endpoint -> серверные хранилища ->
|
||||
processing -> operator -> automation, что упрощает тестирование и валидацию.
|
||||
- Четкие migration-runbooks для последовательного перехода legacy-python → Rust.
|
||||
|
||||
### 2. Операционная зрелость
|
||||
|
||||
- Полноценный Ansible-ensemble для end-to-end развёртывания (Proxmox, Linux,
|
||||
централизованный Windows rollout по WinRM), включая retry-политику,
|
||||
smoke-тесты и валидацию после деплоя.
|
||||
- Safe-run pattern: dry-run/apply planners, backup-before-delete, atomic
|
||||
операции и conservative no-restart paths.
|
||||
- Набор модулей для диагностики и качества (detmir-*, aw-*, quality-gate,
|
||||
smoke checks) обеспечивает fast feedback при внедрении.
|
||||
|
||||
### 3. Безопасность и работа с evidence
|
||||
|
||||
- Изолированный путь evidence: opaque IDs, bearer-upload, magic validation
|
||||
для изображений, размерные лимиты, SHA-256 валидация, atomic write и audit
|
||||
trails.
|
||||
- Security hardening guide: TLS по умолчанию, reverse-proxy, firewall
|
||||
рекомендации, сервисные аккаунты и минимальные привилегии.
|
||||
- Ясные границы продукта: не позиционируется как сертифицированная СЗИ/DLP;
|
||||
это снижает юридические риски при регистрации и аудите.
|
||||
|
||||
### 4. Production-readiness и валидация пилота
|
||||
|
||||
- Полный комплект acceptance и pilot-checklists (30-дневный pilot success
|
||||
criteria) с метриками доступности, coverage, freshness и времени реакции.
|
||||
- Runbooks и операционная документация для восстановления, резервного копирования
|
||||
и отката.
|
||||
|
||||
### 5. Наблюдаемость и качество данных
|
||||
|
||||
- Встроенные SLO/health monitoring, Prometheus/ Grafana витрины и
|
||||
детализированные smoke/contour тесты.
|
||||
- Механизмы объяснимости: UEBA v1 rule-based с reason-codes и объяснениями KPI
|
||||
coverage/confidence.
|
||||
|
||||
### 6. Поддержка Windows/RDP и forensics
|
||||
|
||||
- Централизованный Windows rollout и валидация (API smoke-checks для
|
||||
aw-watcher-afk/aw-watcher-window).
|
||||
- Серверная автоматическая обработка Hayabusa: auto-upload, severity scoring,
|
||||
case creation и уведомления (Telegram) с пороговой фильтрацией.
|
||||
|
||||
### 7. Документированность и готовность к реестру
|
||||
|
||||
- Полный набор документов для регистрации: product passport, architecture,
|
||||
functional scope, dependency statement, deployment model и readiness checklist.
|
||||
- Демонстрационные сценарии и фикстуры, исключающие реальные персональные и
|
||||
сетевые данные — соответствует требованиям для публичных материалов.
|
||||
|
||||
### 8. Честное позиционирование и риски
|
||||
|
||||
- Прозрачность ограничений (что реализовано, что planned/future) — важный
|
||||
аспект при подаче в реестр и при взаимодействии с заказчиком.
|
||||
- Документированная gap-analysis и roadmap-conformance audit облегчают
|
||||
процессы оценки соответствия и планирования доработок.
|
||||
|
||||
|
||||
---
|
||||
|
||||
Если нужно, могу:
|
||||
- добавить этот раздел как отдельный файл в docs/ (например,
|
||||
docs/PROFESSIONAL_HIGHLIGHTS_RU.md), либо
|
||||
- вставить в другой документ (например, в architecture или registry passport),
|
||||
- сгенерировать краткую выдержку на 1 страницу для подачи в реестр.
|
||||
|
||||
@@ -5,21 +5,17 @@ AWatch-rus - программный комплекс операционного
|
||||
корпоративной ИТ-инфраструктуры на базе ActivityWatch, Rust-сервисов
|
||||
автоматизации, Grafana/Prometheus-витрин и модулей расследования инцидентов.
|
||||
|
||||
Проект не позиционируется как сертифицированная DLP/SIEM/EDR/XDR/СЗИ. DLP,
|
||||
evidence и Hayabusa используются как прикладные модули внутри платформы
|
||||
операционного контроля и технического аудита.
|
||||
Проект не позиционируется как сертифицированная DLP/SIEM/EDR/XDR/СЗИ,хотя DLP,evidence и Hayabusa используются в проекте.
|
||||
|
||||
## Назначение
|
||||
|
||||
- AWatch-rus Workforce: активность сотрудников, загрузка, RDP/1C/рабочие
|
||||
приложения и управленческие отчеты для владельца бизнеса.
|
||||
- AWatch-rus Security: DLP-сигналы, evidence, очередь кейсов и audit действий
|
||||
оператора без заявления продукта как сертифицированной СЗИ.
|
||||
- AWatch-rus Forensics: цепочки событий, Hayabusa/offline-разбор и материалы для
|
||||
внутреннего расследования.
|
||||
- AWatch-rus Security: DLP-сигналы, evidence, очередь кейсов и audit действий оператора без заявления продукта как сертифицированной СЗИ.
|
||||
- AWatch-rus Forensics: цепочки событий, Hayabusa/offline-разбор и материалы для внутреннего расследования.
|
||||
- Контроль доступности и свежести данных ActivityWatch.
|
||||
- Учет активного времени, RDP-сессий, окон, приложений и рабочих интервалов.
|
||||
- Витрины Grafana для администратора, оператора ИБ и руководителя.
|
||||
- Учет активного времени, Windows RDP-сессий окон, приложений и рабочих интервалов а также активности пользователей в Linux/Unix системах.
|
||||
- витрины Grafana для администратора, оператора ИБ и руководителя(dashboards).
|
||||
- Автоматизация runbook-проверок, health-check, SLO и безопасного auto-heal.
|
||||
- Сбор evidence по инцидентам и аудит действий оператора.
|
||||
|
||||
@@ -28,18 +24,17 @@ evidence и Hayabusa используются как прикладные мод
|
||||
Основной серверный runtime AWatch-rus переведен на Rust: status/check/auto-heal,
|
||||
SLO, worktime, DLP server-side helpers, evidence и install-kit tooling.
|
||||
|
||||
Python в репозитории остается для вспомогательных направлений: Telegram bot
|
||||
runtime, OCR/content-analysis, 1C/AI/ETL integration и MCP/dev helpers. Эти
|
||||
части не являются ядром Rust-first runtime.
|
||||
Python, присутствующий в коде репозитория, остается для вспомогательных направлений: Telegram bot
|
||||
runtime(для оперативного оповещения), OCR/content-analysis, 1C/AI/ETL integration и MCP/dev helpers. Эти части не являются ядром Rust-first runtime.
|
||||
|
||||
Портальный слой зафиксирован как Rust server-rendered HTML + HTMX-compatible
|
||||
JSON API, OpenAPI и TypeScript declarations. Dioxus не используется и не
|
||||
рассматривается для Pilot v1.0. React, Tauri и Electron также не входят в
|
||||
текущий основной UI.
|
||||
текущий основной UI, но возможна их интеграция в проект.
|
||||
|
||||
## Product Evolution
|
||||
|
||||
AWatch-rus уже является рабочей платформой Workforce + Security + Forensics.
|
||||
AWatch-rus является рабочей платформой Workforce + Security + Forensics.
|
||||
Архитектура предусматривает расширение на агентные и agentless-источники
|
||||
данных. Planned/Future элементы ниже не являются реализованной функциональностью
|
||||
и не должны трактоваться как готовые collectors или integrations.
|
||||
|
||||
@@ -13,23 +13,22 @@ Forensics с прозрачными rule-based объяснениями.
|
||||
| Продукт | Публичная категория | Сильная сторона | Как позиционировать AWatch-rus рядом |
|
||||
| --- | --- | --- | --- |
|
||||
| ActivityWatch | Open-source automated time tracker | Локальный, открытый и понятный сбор активности приложений и сайтов | AWatch-rus развивает этот подход в пилотный корпоративный контур с ролями, отчетами, Risk Narrative и эксплуатационной документацией |
|
||||
| Стахановец | Контроль сотрудников, мониторинг активности, DLP-возможности | Зрелый классический контроль рабочих мест и политик мониторинга | AWatch-rus не должен заявлять функциональный паритет; его сильная зона - объяснимый управленческий KPI, Security Analytics и пилотная прозрачность |
|
||||
| StaffCop | Employee Monitoring, Insider Risk, Workforce Analytics, DLP | Широкий набор функций мониторинга, productivity analytics, расследований и DLP-направления | AWatch-rus нужно показывать как более узкий и прозрачный пилотный контур, без обещания заменить StaffCop по широте функций |
|
||||
| SearchInform | DLP, Risk Monitor, SIEM, TimeInformer и смежные продукты | Комплексная линейка ИБ-продуктов и мониторинга внутренних рисков | AWatch-rus не конкурирует как полноценный SIEM/DLP; он может быть легким аналитическим слоем для Workforce-first пилота |
|
||||
| Стахановец | Контроль сотрудников, мониторинг активности, DLP-возможности | Зрелый классический контроль рабочих мест и политик мониторинга | AWatch-rus не заявляет функциональный паритет; его сильная зона - объяснимый управленческий KPI, Security Analytics и пилотная прозрачность |
|
||||
| StaffCop | Employee Monitoring, Insider Risk, Workforce Analytics, DLP | Широкий набор функций мониторинга, productivity analytics, расследований и DLP-направления | AWatch-rus это более узкий и прозрачный пилотный контур, без обещания заменить StaffCop по широте функций |
|
||||
| SearchInform | DLP, Risk Monitor, SIEM, TimeInformer и смежные продукты | Комплексная линейка ИБ-продуктов и мониторинга внутренних рисков | AWatch-rus не конкурирует как полноценный SIEM/DLP; он является легким аналитическим слоем для Workforce-first пилота |
|
||||
| InfoWatch | DLP и защита от утечек конфиденциальной информации | Сильное DLP-направление, политики, интеграции и регуляторный контекст | AWatch-rus не заменяет DLP; он показывает операционную активность, объяснимые риски и материалы для внутренней проверки |
|
||||
|
||||
## Где AWatch-rus уместен
|
||||
|
||||
- Быстрый пилот для руководителя, ИБ и эксплуатации без тяжелого SIEM/DLP
|
||||
внедрения.
|
||||
внедрения в организациях,желающих иметь современное программное обеспечение такого типа.
|
||||
- Workforce-first аналитика с объяснением KPI, coverage и confidence.
|
||||
- Разделение Executive, Workforce, Security и Forensics сценариев.
|
||||
- Прозрачная rule-based модель UEBA Score v1 и Risk Narrative без ML/LLM.
|
||||
- Прозрачная rule-based модель UEBA Score v1 и Risk Narrative без дорогих средств использования Искусственного Интеллекта ML/LLM.
|
||||
- Подготовка evidence package и Markdown-отчетов для ручной проверки.
|
||||
- Честная демонстрация границ: planned, future и contract_only не выдаются за
|
||||
implemented.
|
||||
- Честная демонстрация границ: planned, future и contract_only не выдаются за implemented.
|
||||
|
||||
## Где зрелые конкуренты обычно сильнее
|
||||
## Где зрелые тяжелые конкуренты обычно сильнее
|
||||
|
||||
- Глубокие DLP-политики, контентная фильтрация и блокировки каналов утечки.
|
||||
- Масштабные SIEM/SOC-процессы и готовые интеграции ИБ.
|
||||
@@ -39,12 +38,10 @@ Forensics с прозрачными rule-based объяснениями.
|
||||
- Поддержка сложных enterprise-сценариев с централизованным управлением
|
||||
агентами и политиками.
|
||||
|
||||
## Что нельзя заявлять
|
||||
## Что не заявляется
|
||||
|
||||
- Что AWatch-rus заменяет DLP, SIEM, EDR или XDR.
|
||||
- Что planned или future providers уже работают в production.
|
||||
- Что pfSense readiness означает готовый ingestion, если он находится в статусе
|
||||
`contract_only`.
|
||||
- Что Risk Narrative является ML-прогнозом.
|
||||
- Что система автоматически оценивает персонал или принимает кадровые решения.
|
||||
|
||||
|
||||
+297
-542
@@ -1,667 +1,422 @@
|
||||
Полная инструкция по развёртыванию и поддержке AWatch-rus
|
||||
# Полная инструкция по развёртыванию и поддержке ActivityWatch-Russian
|
||||
|
||||
Статус документа
|
||||
Документ описывает полный цикл: Proxmox/LXC сервер, установка ActivityWatch Server, RU Web UI patch, развёртывание Windows-клиентов в другом AD-домене, валидация, сопровождение и rollback.
|
||||
|
||||
Этот документ описывает актуальный **Rust-fiWindows/PowerShell deployment flow больше не считается основным способом развёртывания, патчинга или эксплуатации. Если в репозитории остаются старые ".ps1"-файлы, они рассматриваются как legacy/history или как будущий provider-слой, но не как production runtime.
|
||||
---
|
||||
|
||||
0. Назначение
|
||||
## 0) Структура проекта (полные пути)
|
||||
|
||||
AWatch-rus — программный комплекс операционного контроля, технического аудита, оценки трудоотдачи сотрудников и мониторинга корпоративной ИТ-инфраструктуры на базе:
|
||||
- `<PROJECT_ROOT>/private-config/deploy.env`
|
||||
- `<PROJECT_ROOT>/proxmox/create-ct.sh`
|
||||
- `<PROJECT_ROOT>/proxmox/push-aw-artifacts.sh`
|
||||
- `<PROJECT_ROOT>/aw-server/install_aw_server.sh`
|
||||
- `<PROJECT_ROOT>/aw-server/apply_webui_ru_patch.sh`
|
||||
- `<PROJECT_ROOT>/windows/deploy-single-user.ps1`
|
||||
- `<PROJECT_ROOT>/windows/deploy-domain-users.ps1`
|
||||
- `<PROJECT_ROOT>/windows/deploy-ensemble.ps1`
|
||||
- `<PROJECT_ROOT>/windows/hardening-recovery.ps1`
|
||||
- `<PROJECT_ROOT>/windows/validate-deployment.ps1`
|
||||
- `<PROJECT_ROOT>/windows/browser-domains-native-collector.ps1`
|
||||
- `<PROJECT_ROOT>/windows/dlp-endpoint-signals-collector.ps1`
|
||||
- `<PROJECT_ROOT>/ansible/deploy_aw_server.yml`
|
||||
- `<PROJECT_ROOT>/ansible/provision_proxmox_ct_and_deploy_aw.yml`
|
||||
- `<PROJECT_ROOT>/ansible/provision_proxmox_ct_matrix_and_deploy_aw.yml`
|
||||
- `<PROJECT_ROOT>/ansible/deploy_aw_windows.yml`
|
||||
|
||||
- Rust backend/runtime;
|
||||
- Rust Agent;
|
||||
- Rust server-rendered HTML + HTMX-compatible JSON API;
|
||||
- Grafana/Prometheus-витрин;
|
||||
- модулей Workforce, Security и Forensics;
|
||||
- evidence/reporting tooling;
|
||||
- ActivityWatch-compatible источников данных, где это применимо.
|
||||
---
|
||||
|
||||
Проект не позиционируется как сертифицированная DLP/SIEM/EDR/XDR/СЗИ. DLP, evidence, UEBA и расследовательские функции используются как внутренние аналитические и операционные модули.
|
||||
## 1) Подготовка
|
||||
|
||||
1. Актуальная архитектура
|
||||
### 1.1 Требования
|
||||
|
||||
1.1 Основной runtime
|
||||
- Proxmox VE 8/9, доступ root (или sudo с правами на `pct`).
|
||||
- Шаблон Debian 12 LXC на хосте Proxmox.
|
||||
- Windows хост(ы) с PowerShell 5.1+ и правами локального администратора.
|
||||
- Сетевой доступ Windows-клиентов до ActivityWatch Server (`5600/tcp`).
|
||||
|
||||
Основной production runtime AWatch-rus — Rust-first:
|
||||
### 1.2 Подготовка единого файла секретов
|
||||
|
||||
- backend/runtime — Rust;
|
||||
- agent — Rust;
|
||||
- portal — Rust server-rendered HTML + HTMX-compatible JSON API;
|
||||
- operational status/check — Rust;
|
||||
- DLP server-side helpers — Rust;
|
||||
- worktime helpers/exporters/prewarm — Rust;
|
||||
- SLO/health/readiness helpers — Rust;
|
||||
- evidence/install-kit tooling — Rust;
|
||||
- auto-heal helpers — Rust, только в безопасном режиме.
|
||||
Скопируйте шаблон:
|
||||
|
||||
1.2 Что не является основным runtime
|
||||
```bash
|
||||
cp <PROJECT_ROOT>/private-config/deploy.env.example \
|
||||
<PROJECT_ROOT>/private-config/deploy.env
|
||||
```
|
||||
|
||||
Не считать основным production deployment flow:
|
||||
Заполните в файле `<PROJECT_ROOT>/private-config/deploy.env`:
|
||||
|
||||
- PowerShell deployment;
|
||||
- старые Windows ".ps1" rollout scripts;
|
||||
- ручное исправление production-файлов без release/backup;
|
||||
- прямое редактирование Web UI в "/opt" без воспроизводимого патча;
|
||||
- Python/shell как основной operational runtime, если для компонента уже есть Rust-аналог.
|
||||
- все `CT_*` параметры контейнера;
|
||||
- все `AW_SERVER_*` параметры сервера;
|
||||
- `CT_PASSWORD` (реальный пароль).
|
||||
|
||||
Python, shell, Ansible или PowerShell могут оставаться в проекте только как:
|
||||
Важно: этот файл подхватывается автоматически скриптами Proxmox.
|
||||
|
||||
- legacy compatibility;
|
||||
- вспомогательные dev/test tools;
|
||||
- миграционные сценарии;
|
||||
- будущие provider-слои;
|
||||
- Telegram/OCR/AI/ETL/MCP helpers, если они явно не входят в Rust-first core.
|
||||
---
|
||||
|
||||
2. Типовые роли узлов
|
||||
## 2) Развёртывание сервера в Proxmox
|
||||
|
||||
2.1 Server node
|
||||
### 2.0 Ansible full-stack (создание CT + установка AW)
|
||||
|
||||
Серверный узел содержит:
|
||||
Подготовьте:
|
||||
|
||||
- AWatch-rus backend/runtime;
|
||||
- portal;
|
||||
- API;
|
||||
- exporters;
|
||||
- health/readiness/status tooling;
|
||||
- systemd units/timers;
|
||||
- Grafana/Prometheus integration;
|
||||
- evidence/reporting storage.
|
||||
- `<PROJECT_ROOT>/ansible/inventory.ini`
|
||||
- `<PROJECT_ROOT>/ansible/group_vars/all.yml`
|
||||
- `<PROJECT_ROOT>/ansible/group_vars/proxmox.yml`
|
||||
|
||||
2.2 Agent node
|
||||
Запуск:
|
||||
|
||||
Agent node содержит:
|
||||
```bash
|
||||
cd <PROJECT_ROOT>/ansible
|
||||
ansible-playbook -i inventory.ini provision_proxmox_ct_and_deploy_aw.yml
|
||||
```
|
||||
|
||||
- Rust Agent;
|
||||
- локальную конфигурацию агента;
|
||||
- systemd service или другой штатный supervisor;
|
||||
- локальные логи;
|
||||
- буфер/очередь, если предусмотрено конфигурацией;
|
||||
- сетевой доступ до backend/API.
|
||||
Этот сценарий полностью закрывает:
|
||||
|
||||
2.3 Monitoring node
|
||||
- создание CT в Proxmox;
|
||||
- bootstrap пакетов в CT;
|
||||
- установку ActivityWatch Server;
|
||||
- применение RU Web UI patch;
|
||||
- проверку API.
|
||||
|
||||
Monitoring node может содержать:
|
||||
Для массового режима (несколько CT):
|
||||
|
||||
- Prometheus;
|
||||
- Grafana;
|
||||
- dashboards;
|
||||
- alerting rules;
|
||||
- external logs/metrics storage.
|
||||
```bash
|
||||
cd <PROJECT_ROOT>/ansible
|
||||
ansible-playbook -i inventory.ini provision_proxmox_ct_matrix_and_deploy_aw.yml
|
||||
```
|
||||
|
||||
Monitoring node может совпадать с server node в пилотной установке.
|
||||
### 2.1 Создать LXC контейнер
|
||||
|
||||
3. Требования
|
||||
На узле Proxmox:
|
||||
|
||||
3.1 Базовые требования
|
||||
```bash
|
||||
cd <PROJECT_ROOT>
|
||||
<PROJECT_ROOT>/proxmox/create-ct.sh
|
||||
```
|
||||
|
||||
- Linux-сервер или LXC/VM.
|
||||
- Доступ администратора к systemd.
|
||||
- Rust toolchain для сборочного узла.
|
||||
- Сетевой доступ между agent node и server node.
|
||||
- Закрытый доступ к API и порталу через VPN, reverse proxy или внутренний контур.
|
||||
- Backup/snapshot перед любым production patch.
|
||||
По умолчанию читается:
|
||||
|
||||
3.2 Рекомендуемый production-подход
|
||||
- `<PROJECT_ROOT>/private-config/deploy.env`
|
||||
|
||||
Для production не собирать проект прямо на боевом сервере, если есть отдельный build host.
|
||||
При необходимости можно передать другой путь:
|
||||
|
||||
Рекомендуемый поток:
|
||||
```bash
|
||||
<PROJECT_ROOT>/proxmox/create-ct.sh /absolute/path/to/deploy.env
|
||||
```
|
||||
|
||||
git checkout нужного commit/tag
|
||||
→ cargo fmt / clippy / test / build
|
||||
→ упаковка release artifacts
|
||||
→ перенос artifacts на сервер
|
||||
→ backup/snapshot
|
||||
→ остановка/перезапуск нужных services
|
||||
→ smoke tests
|
||||
→ фиксация версии
|
||||
### 2.2 Загрузить bootstrap-артефакты и env внутрь CT
|
||||
|
||||
4. Основные пути
|
||||
```bash
|
||||
cd <PROJECT_ROOT>
|
||||
<PROJECT_ROOT>/proxmox/push-aw-artifacts.sh
|
||||
```
|
||||
|
||||
Рекомендуемая структура на сервере:
|
||||
Скрипт загружает в CT:
|
||||
|
||||
/opt/awatch-rus/
|
||||
bin/
|
||||
etc/
|
||||
portal/
|
||||
releases/
|
||||
evidence/
|
||||
reports/
|
||||
logs/
|
||||
- `<CT_BOOTSTRAP_DIR>/install_aw_server.sh`
|
||||
- `<CT_BOOTSTRAP_DIR>/apply_webui_ru_patch.sh`
|
||||
- `<CT_BOOTSTRAP_DIR>/activitywatch-server.service`
|
||||
- `<CT_BOOTSTRAP_DIR>/aw-ru-patch.js`
|
||||
- `<CT_BOOTSTRAP_DIR>/aw-sw-cleanup.js`
|
||||
- `/etc/activitywatch/aw-server.env` (из `AW_SERVER_*`)
|
||||
|
||||
/etc/awatch-rus/
|
||||
awatch-rus.env
|
||||
agent.env
|
||||
portal.env
|
||||
### 2.3 Установить ActivityWatch Server внутри CT
|
||||
|
||||
/var/lib/awatch-rus/
|
||||
data/
|
||||
state/
|
||||
cache/
|
||||
evidence/
|
||||
reports/
|
||||
```bash
|
||||
pct enter <CT_ID>
|
||||
bash <CT_BOOTSTRAP_DIR>/install_aw_server.sh
|
||||
```
|
||||
|
||||
/var/log/awatch-rus/
|
||||
backend.log
|
||||
agent.log
|
||||
portal.log
|
||||
exporter.log
|
||||
### 2.4 Применить RU patch Web UI
|
||||
|
||||
Рекомендуемые runtime binaries:
|
||||
```bash
|
||||
bash <CT_BOOTSTRAP_DIR>/apply_webui_ru_patch.sh
|
||||
systemctl restart activitywatch-server.service
|
||||
```
|
||||
|
||||
/usr/local/bin/detmir-status
|
||||
/usr/local/bin/detmir-check
|
||||
/usr/local/bin/detmir-dlp
|
||||
/usr/local/bin/detmir-auto
|
||||
/usr/local/bin/detmir-heal-safe
|
||||
/usr/local/bin/aw-rus-healthd
|
||||
После применения патча доступны:
|
||||
|
||||
Имена конкретных бинарников должны соответствовать текущему "Cargo.toml" и фактически собранным artifacts. Если имя binary изменено, документация и systemd unit должны обновляться в том же commit.
|
||||
- верхнее меню `DLP` в Web UI;
|
||||
- DLP-страница bucket `aw-dlp-endpoint-signals_<HOST>`;
|
||||
- встроенный центр `DLP review и правила`;
|
||||
- служебные buckets `aw-dlp-review_<HOST>` и `aw-dlp-rules_<HOST>`.
|
||||
|
||||
5. Конфигурация
|
||||
### 2.5 Проверка сервера
|
||||
|
||||
5.1 Общие правила
|
||||
В CT:
|
||||
|
||||
- Не хранить production secrets в публичном репозитории.
|
||||
- Не коммитить реальные hostnames, IP, логины, ФИО, токены, пароли.
|
||||
- Для production использовать "/etc/awatch-rus/*.env".
|
||||
- Для demo использовать только обезличенные fixtures.
|
||||
- Все параметры, влияющие на runtime, должны быть описаны в документации.
|
||||
```bash
|
||||
systemctl status activitywatch-server.service --no-pager
|
||||
curl -fsS http://127.0.0.1:5600/api/0/info
|
||||
ss -ltnp | grep 5600
|
||||
grep -n 'aw-ru-patch\|aw-sw-cleanup' /opt/activitywatch/webui-ru/index.html
|
||||
```
|
||||
|
||||
5.2 Пример server env
|
||||
Ожидается:
|
||||
|
||||
AWATCH_ENV=production
|
||||
AWATCH_BIND_ADDR=127.0.0.1
|
||||
AWATCH_PORT=5600
|
||||
AWATCH_DATA_DIR=/var/lib/awatch-rus/data
|
||||
AWATCH_LOG_DIR=/var/log/awatch-rus
|
||||
AWATCH_EVIDENCE_DIR=/var/lib/awatch-rus/evidence
|
||||
AWATCH_REPORTS_DIR=/var/lib/awatch-rus/reports
|
||||
RUST_LOG=info
|
||||
- сервис `active (running)`;
|
||||
- API отвечает JSON;
|
||||
- порт 5600 слушается;
|
||||
- в `index.html` присутствуют оба скрипта.
|
||||
|
||||
5.3 Пример agent env
|
||||
Дополнительно после первого входа в Web UI:
|
||||
|
||||
AWATCH_AGENT_ENV=production
|
||||
AWATCH_SERVER_URL=https://awatch.example.local
|
||||
AWATCH_AGENT_HOST_ID=HOSTNAME_OR_NODE_ID
|
||||
AWATCH_AGENT_DATA_DIR=/var/lib/awatch-rus/agent
|
||||
AWATCH_AGENT_LOG_DIR=/var/log/awatch-rus
|
||||
RUST_LOG=info
|
||||
- `#/home` должен показывать один корректный пункт `DLP`;
|
||||
- `#/buckets/aw-dlp-endpoint-signals_<HOST>` должен открываться без ошибок;
|
||||
- сохранение review/rule должно создавать buckets `aw-dlp-review_<HOST>` и `aw-dlp-rules_<HOST>`.
|
||||
|
||||
6. Сборка
|
||||
---
|
||||
|
||||
6.1 Проверки перед сборкой
|
||||
## 3) Развёртывание Windows-клиентов (другой AD-домен)
|
||||
|
||||
На build host:
|
||||
### 3.1 Подготовка на Windows-хосте
|
||||
|
||||
cd /path/to/AWatch-rus
|
||||
Скопируйте каталог:
|
||||
|
||||
git status --short
|
||||
cargo fmt --all -- --check
|
||||
cargo clippy --workspace --all-targets -- -D warnings
|
||||
cargo test --workspace
|
||||
- `<PROJECT_ROOT>/windows`
|
||||
|
||||
Если в репозитории есть проектные quality gates, выполнить их обязательно:
|
||||
например в:
|
||||
|
||||
bash scripts/check_private_config_guard.sh
|
||||
bash scripts/quality-gate.sh
|
||||
- `C:\Program Files\AWatch-rus\windows`
|
||||
|
||||
Если какой-то скрипт отсутствует в текущей ветке, не создавать фиктивную замену. Зафиксировать это в release notes.
|
||||
Откройте **elevated PowerShell**:
|
||||
|
||||
6.2 Release build
|
||||
```powershell
|
||||
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope Process
|
||||
```
|
||||
|
||||
cargo build --release --workspace
|
||||
### 3.2 Массовое доменное развёртывание (рекомендуется)
|
||||
|
||||
Проверить artifacts:
|
||||
Если текущий production ещё работает в старых каталогах
|
||||
`C:\Program Files\ActivityWatch-Phase2` и `C:\ProgramData\ActivityWatch-Phase2`,
|
||||
сначала выполните безопасную миграцию:
|
||||
|
||||
find target/release -maxdepth 1 -type f -executable -print
|
||||
```powershell
|
||||
C:\Program Files\AWatch-rus\windows\migrate-awatch-rus-paths.ps1 -WhatIf
|
||||
C:\Program Files\AWatch-rus\windows\migrate-awatch-rus-paths.ps1
|
||||
```
|
||||
|
||||
6.3 Упаковка artifacts
|
||||
Скрипт остановит `ActivityWatch Recovery`/`ActivityWatch Launch *`, создаст backup в
|
||||
`C:\ProgramData\AWatch-rus\migration-backups\...`, перенесёт файлы в единые пути,
|
||||
пересоздаст `deployment-config.json`/scheduled tasks и запустит validation.
|
||||
|
||||
Рекомендуемый вариант:
|
||||
Пример со списком пользователей:
|
||||
|
||||
mkdir -p dist/awatch-rus-release/bin
|
||||
cp target/release/detmir-status dist/awatch-rus-release/bin/ 2>/dev/null || true
|
||||
cp target/release/detmir-check dist/awatch-rus-release/bin/ 2>/dev/null || true
|
||||
cp target/release/detmir-dlp dist/awatch-rus-release/bin/ 2>/dev/null || true
|
||||
cp target/release/detmir-auto dist/awatch-rus-release/bin/ 2>/dev/null || true
|
||||
cp target/release/detmir-heal-safe dist/awatch-rus-release/bin/ 2>/dev/null || true
|
||||
cp target/release/aw-rus-healthd dist/awatch-rus-release/bin/ 2>/dev/null || true
|
||||
```powershell
|
||||
C:\Program Files\AWatch-rus\windows\deploy-domain-users.ps1 `
|
||||
-ServerHost aw.example.local `
|
||||
-ServerPort 5600 `
|
||||
-Domain CONTOSO `
|
||||
-UserListPath C:\Deploy\aw-users.txt `
|
||||
-CustomRulesPath C:\Program Files\AWatch-rus\windows\web-category-rules.example.json
|
||||
```
|
||||
|
||||
tar -C dist -czf awatch-rus-release.tar.gz awatch-rus-release
|
||||
sha256sum awatch-rus-release.tar.gz > awatch-rus-release.tar.gz.sha256
|
||||
Поддерживаемые варианты:
|
||||
|
||||
Не использовать "cp ... || true" в CI без последующей проверки обязательных binaries. Для ручного production release список обязательных binaries должен быть проверен явно.
|
||||
- `-Users user01,user02`
|
||||
- `-Users 'CONTOSO\user01','CONTOSO\user02'`
|
||||
- `-UserListPath <txt|csv>`
|
||||
|
||||
7. Первичное развёртывание server node
|
||||
### 3.2.1 Ensemble orchestration (рекомендуется для production)
|
||||
|
||||
7.1 Создание каталогов
|
||||
```powershell
|
||||
C:\Program Files\AWatch-rus\windows\deploy-ensemble.ps1 `
|
||||
-ServerHost aw.example.local `
|
||||
-ServerPort 5600 `
|
||||
-Domain CONTOSO `
|
||||
-Users user1,user2,user3,user4,user5 `
|
||||
-ValidateAfterDeploy
|
||||
```
|
||||
|
||||
sudo mkdir -p /opt/awatch-rus/bin
|
||||
sudo mkdir -p /opt/awatch-rus/releases
|
||||
sudo mkdir -p /etc/awatch-rus
|
||||
sudo mkdir -p /var/lib/awatch-rus/data
|
||||
sudo mkdir -p /var/lib/awatch-rus/state
|
||||
sudo mkdir -p /var/lib/awatch-rus/evidence
|
||||
sudo mkdir -p /var/lib/awatch-rus/reports
|
||||
sudo mkdir -p /var/log/awatch-rus
|
||||
Отчёт сохраняется в:
|
||||
|
||||
7.2 Установка binaries
|
||||
- `C:\ProgramData\AWatch-rus\ensemble-report-YYYYMMDD-HHMMSS.json`
|
||||
|
||||
sudo install -m 0755 dist/awatch-rus-release/bin/* /opt/awatch-rus/bin/
|
||||
### 3.3 Single-user развёртывание
|
||||
|
||||
Создать symlink для удобства:
|
||||
```powershell
|
||||
C:\Program Files\AWatch-rus\windows\deploy-single-user.ps1 `
|
||||
-ServerHost aw.example.local `
|
||||
-ServerPort 5600 `
|
||||
-TargetUser 'CONTOSO\user01' `
|
||||
-CustomRulesPath C:\Program Files\AWatch-rus\windows\web-category-rules.example.json
|
||||
```
|
||||
|
||||
sudo ln -sf /opt/awatch-rus/bin/detmir-status /usr/local/bin/detmir-status
|
||||
sudo ln -sf /opt/awatch-rus/bin/detmir-check /usr/local/bin/detmir-check
|
||||
sudo ln -sf /opt/awatch-rus/bin/detmir-dlp /usr/local/bin/detmir-dlp
|
||||
### 3.4 Recovery / hardening
|
||||
|
||||
Если binary отсутствует, не создавать пустой symlink. Сначала проверить фактический состав release artifact.
|
||||
```powershell
|
||||
C:\Program Files\AWatch-rus\windows\hardening-recovery.ps1 `
|
||||
-ConfigPath C:\ProgramData\AWatch-rus\deployment-config.json
|
||||
```
|
||||
|
||||
7.3 Конфигурация
|
||||
### 3.5 Валидация deployment-а (PowerShell report)
|
||||
|
||||
sudo install -m 0640 awatch-rus.env /etc/awatch-rus/awatch-rus.env
|
||||
```powershell
|
||||
$report = C:\Program Files\AWatch-rus\windows\validate-deployment.ps1 `
|
||||
-ConfigPath C:\ProgramData\AWatch-rus\deployment-config.json
|
||||
$report | ConvertTo-Json -Depth 12
|
||||
```
|
||||
|
||||
Проверить права:
|
||||
---
|
||||
|
||||
sudo chown root:root /etc/awatch-rus/awatch-rus.env
|
||||
sudo chmod 0640 /etc/awatch-rus/awatch-rus.env
|
||||
## 4) Что должно появиться на Windows после установки
|
||||
|
||||
8. systemd units
|
||||
- `C:\Program Files\AWatch-rus\bin`
|
||||
- `C:\ProgramData\AWatch-rus\deployment-config.json`
|
||||
- `C:\ProgramData\AWatch-rus\launch-watchers.ps1`
|
||||
- `C:\ProgramData\AWatch-rus\recovery-loop.ps1`
|
||||
- `C:\ProgramData\AWatch-rus\browser-domains-native-collector.ps1`
|
||||
- `C:\ProgramData\AWatch-rus\web-category-rules.json`
|
||||
- `C:\ProgramData\AWatch-rus\logs\`
|
||||
|
||||
8.1 Пример backend service
|
||||
Задачи планировщика:
|
||||
|
||||
[Unit]
|
||||
Description=AWatch-rus backend/runtime
|
||||
After=network-online.target
|
||||
Wants=network-online.target
|
||||
- `ActivityWatch Launch [<user>]` (per-user, при логоне)
|
||||
- `ActivityWatch Recovery` (system-level recovery)
|
||||
|
||||
[Service]
|
||||
Type=simple
|
||||
EnvironmentFile=/etc/awatch-rus/awatch-rus.env
|
||||
ExecStart=/opt/awatch-rus/bin/awatch-rus-backend
|
||||
Restart=on-failure
|
||||
RestartSec=5
|
||||
WorkingDirectory=/opt/awatch-rus
|
||||
NoNewPrivileges=true
|
||||
PrivateTmp=true
|
||||
ProtectSystem=full
|
||||
ProtectHome=true
|
||||
ReadWritePaths=/var/lib/awatch-rus /var/log/awatch-rus
|
||||
---
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
## 5) Полная валидация потока данных
|
||||
|
||||
Если фактическое имя backend binary отличается, заменить "awatch-rus-backend" на актуальное имя из release artifact.
|
||||
### 5.1 На Windows-хосте
|
||||
|
||||
8.2 Пример health service
|
||||
Проверить процессы:
|
||||
|
||||
[Unit]
|
||||
Description=AWatch-rus health daemon
|
||||
After=network-online.target
|
||||
Wants=network-online.target
|
||||
```powershell
|
||||
Get-Process aw-watcher-afk,aw-watcher-window -ErrorAction SilentlyContinue
|
||||
Get-CimInstance Win32_Process | ? { $_.CommandLine -like '*browser-domains-native-collector.ps1*' } | select ProcessId,SessionId,CommandLine
|
||||
```
|
||||
|
||||
[Service]
|
||||
Type=simple
|
||||
EnvironmentFile=/etc/awatch-rus/awatch-rus.env
|
||||
ExecStart=/opt/awatch-rus/bin/aw-rus-healthd
|
||||
Restart=on-failure
|
||||
RestartSec=5
|
||||
WorkingDirectory=/opt/awatch-rus
|
||||
NoNewPrivileges=true
|
||||
PrivateTmp=true
|
||||
ProtectSystem=full
|
||||
ProtectHome=true
|
||||
ReadWritePaths=/var/lib/awatch-rus /var/log/awatch-rus
|
||||
Проверить задачи:
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
```powershell
|
||||
Get-ScheduledTask | ? { $_.TaskName -like 'ActivityWatch*' } | select TaskName,State
|
||||
```
|
||||
|
||||
8.3 Применение unit files
|
||||
### 5.2 На сервере ActivityWatch API
|
||||
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl enable --now awatch-rus-backend.service
|
||||
sudo systemctl enable --now aw-rus-healthd.service
|
||||
```bash
|
||||
curl -sS http://127.0.0.1:5600/api/0/buckets | jq 'keys'
|
||||
```
|
||||
|
||||
Если конкретный unit не используется в текущей инсталляции, не создавать фиктивный сервис. Документировать фактический набор services.
|
||||
Ожидаемые bucket'ы:
|
||||
|
||||
9. Развёртывание Rust Agent
|
||||
- `aw-watcher-afk_<HOST>`
|
||||
- `aw-watcher-window_<HOST>`
|
||||
- `aw-watcher-web-<browser>_<HOST>`
|
||||
- `aw-detmir-web-category_<HOST>` (категоризованный поток)
|
||||
- `aw-dlp-endpoint-signals_<HOST>` (endpoint сигналы)
|
||||
- `aw-dlp-review_<HOST>` (ручная классификация через UI)
|
||||
- `aw-dlp-rules_<HOST>` (suppress/rule записи через UI)
|
||||
|
||||
9.1 Установка agent binary
|
||||
Проверка событий браузера:
|
||||
|
||||
sudo mkdir -p /opt/awatch-rus/bin
|
||||
sudo mkdir -p /etc/awatch-rus
|
||||
sudo mkdir -p /var/lib/awatch-rus/agent
|
||||
sudo mkdir -p /var/log/awatch-rus
|
||||
```bash
|
||||
curl -sS "http://127.0.0.1:5600/api/0/buckets/aw-watcher-web-edge_<HOST>/events?limit=5" | jq
|
||||
```
|
||||
|
||||
sudo install -m 0755 awatch-rus-agent /opt/awatch-rus/bin/awatch-rus-agent
|
||||
sudo install -m 0640 agent.env /etc/awatch-rus/agent.env
|
||||
Проверка категоризации:
|
||||
|
||||
9.2 Пример agent service
|
||||
```bash
|
||||
curl -sS "http://127.0.0.1:5600/api/0/buckets/aw-detmir-web-category_<HOST>/events?limit=5" | jq
|
||||
```
|
||||
|
||||
[Unit]
|
||||
Description=AWatch-rus Rust Agent
|
||||
After=network-online.target
|
||||
Wants=network-online.target
|
||||
Проверка DLP review/rules:
|
||||
|
||||
[Service]
|
||||
Type=simple
|
||||
EnvironmentFile=/etc/awatch-rus/agent.env
|
||||
ExecStart=/opt/awatch-rus/bin/awatch-rus-agent
|
||||
Restart=on-failure
|
||||
RestartSec=5
|
||||
WorkingDirectory=/opt/awatch-rus
|
||||
NoNewPrivileges=true
|
||||
PrivateTmp=true
|
||||
ProtectSystem=full
|
||||
ProtectHome=true
|
||||
ReadWritePaths=/var/lib/awatch-rus /var/log/awatch-rus
|
||||
```bash
|
||||
curl -sS "http://127.0.0.1:5600/api/0/buckets/aw-dlp-review_<HOST>/events?limit=20" | jq
|
||||
curl -sS "http://127.0.0.1:5600/api/0/buckets/aw-dlp-rules_<HOST>/events?limit=20" | jq
|
||||
```
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
Ожидаемые поля review:
|
||||
|
||||
9.3 Запуск agent
|
||||
- `reviewId`
|
||||
- `signalType`
|
||||
- `verdict`
|
||||
- `category`
|
||||
- `comment`
|
||||
- `archived`
|
||||
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl enable --now awatch-rus-agent.service
|
||||
sudo systemctl status awatch-rus-agent.service --no-pager
|
||||
Ожидаемые поля rules:
|
||||
|
||||
10. Развёртывание портала
|
||||
- `ruleId`
|
||||
- `signalType`
|
||||
- `match`
|
||||
- `category`
|
||||
- `comment`
|
||||
- `enabled`
|
||||
|
||||
Портальный слой AWatch-rus зафиксирован как Rust server-rendered HTML + HTMX-compatible JSON API.
|
||||
---
|
||||
|
||||
10.1 Общий порядок
|
||||
## 6) Сопровождение (обязательно)
|
||||
|
||||
build portal/backend binary
|
||||
→ install binary
|
||||
→ install templates/static assets, если они выделены отдельно
|
||||
→ update portal env
|
||||
→ restart portal service
|
||||
→ smoke check HTTP/API routes
|
||||
### 6.1 Backup перед любыми изменениями
|
||||
|
||||
10.2 Проверка портала
|
||||
|
||||
curl -fsS http://127.0.0.1:5600/healthz
|
||||
curl -fsS http://127.0.0.1:5600/readyz
|
||||
curl -fsS http://127.0.0.1:5600/version
|
||||
|
||||
Если конкретные endpoints в текущей версии отличаются, использовать фактически реализованные health/readiness/version endpoints и обновить этот документ в том же commit.
|
||||
|
||||
11. Патчи в развернутой среде
|
||||
|
||||
11.1 Правило
|
||||
|
||||
Любой production patch применяется только через контролируемый цикл:
|
||||
|
||||
определить commit/tag
|
||||
→ собрать release artifact
|
||||
→ выполнить локальные проверки
|
||||
→ сделать backup/snapshot
|
||||
→ установить новые binaries/configs
|
||||
→ restart/reload services
|
||||
→ smoke tests
|
||||
→ зафиксировать результат
|
||||
→ сохранить rollback path
|
||||
|
||||
11.2 Перед патчем
|
||||
|
||||
git rev-parse HEAD
|
||||
git status --short
|
||||
|
||||
Сохранить:
|
||||
|
||||
дата/время
|
||||
commit/tag
|
||||
кто применяет
|
||||
какие services затрагиваются
|
||||
какой rollback path
|
||||
|
||||
11.3 Backup перед патчем
|
||||
|
||||
Если используется Proxmox/LXC:
|
||||
На Proxmox:
|
||||
|
||||
```bash
|
||||
vzdump <CT_ID> --mode snapshot --compress zstd --storage <BACKUP_STORAGE>
|
||||
```
|
||||
|
||||
Внутри сервера:
|
||||
Конфиги внутри CT:
|
||||
|
||||
sudo tar -C / -czf /root/awatch-rus-backup-$(date +%Y%m%d-%H%M%S).tgz \
|
||||
etc/awatch-rus \
|
||||
opt/awatch-rus \
|
||||
var/lib/awatch-rus \
|
||||
var/log/awatch-rus
|
||||
```bash
|
||||
pct exec <CT_ID> -- tar -C / -czf <PRIVATE_BACKUP_DIR>/activitywatch-config-backup.tgz \
|
||||
etc/activitywatch \
|
||||
etc/systemd/system/activitywatch-server.service \
|
||||
opt/activitywatch/webui-ru \
|
||||
opt/activitywatch/releases
|
||||
```
|
||||
|
||||
Если данные большие, backup "/var/lib/awatch-rus" выполнять отдельной процедурой согласно backup policy.
|
||||
### 6.2 Обновление сервера
|
||||
|
||||
11.4 Установка нового binary
|
||||
1. Обновить `AW_SERVER_VERSION` и `AW_SERVER_DOWNLOAD_URL` в
|
||||
`<PROJECT_ROOT>/private-config/deploy.env`
|
||||
2. Выполнить:
|
||||
|
||||
Сохранить предыдущую версию:
|
||||
```bash
|
||||
<PROJECT_ROOT>/proxmox/push-aw-artifacts.sh
|
||||
pct enter <CT_ID>
|
||||
bash <CT_BOOTSTRAP_DIR>/install_aw_server.sh
|
||||
bash <CT_BOOTSTRAP_DIR>/apply_webui_ru_patch.sh
|
||||
systemctl restart activitywatch-server.service
|
||||
```
|
||||
|
||||
sudo mkdir -p /opt/awatch-rus/releases/previous
|
||||
sudo cp -a /opt/awatch-rus/bin /opt/awatch-rus/releases/previous/bin-$(date +%Y%m%d-%H%M%S)
|
||||
3. Повторить валидацию API/UI.
|
||||
|
||||
Установить новый artifact:
|
||||
### 6.3 Rollback
|
||||
|
||||
sudo install -m 0755 dist/awatch-rus-release/bin/* /opt/awatch-rus/bin/
|
||||
RU patch rollback:
|
||||
|
||||
11.5 Restart services
|
||||
```bash
|
||||
cp /opt/activitywatch/webui-ru/index.html.bak.<timestamp> /opt/activitywatch/webui-ru/index.html
|
||||
systemctl restart activitywatch-server.service
|
||||
```
|
||||
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl restart awatch-rus-backend.service
|
||||
sudo systemctl restart aw-rus-healthd.service
|
||||
Полный rollback:
|
||||
|
||||
Если патч касается только agent:
|
||||
- восстановить CT из snapshot/backup;
|
||||
- проверить API и Web UI;
|
||||
- проверить доступность для Windows-клиентов.
|
||||
|
||||
sudo systemctl restart awatch-rus-agent.service
|
||||
---
|
||||
|
||||
Если сервис в текущем контуре называется иначе, использовать фактическое имя systemd unit.
|
||||
## 7) Безопасность
|
||||
|
||||
12. Smoke-тесты после патча
|
||||
- Не хранить реальные приватные параметры вне `<PROJECT_ROOT>/private-config/deploy.env`.
|
||||
- Не открывать `5600/tcp` в интернет напрямую.
|
||||
- Публиковать через VPN или reverse proxy с ограничением доступа.
|
||||
- Перед изменениями всегда делать backup.
|
||||
|
||||
12.1 Systemd
|
||||
---
|
||||
|
||||
systemctl --failed --no-pager
|
||||
systemctl status awatch-rus-backend.service --no-pager
|
||||
systemctl status aw-rus-healthd.service --no-pager
|
||||
## 8) Короткий чек-лист ввода в эксплуатацию
|
||||
|
||||
12.2 Rust operational checks
|
||||
|
||||
detmir-status --json
|
||||
detmir-check --json
|
||||
detmir-dlp --json
|
||||
|
||||
Если отдельная команда не установлена в данном контуре, это не считается ошибкой только при наличии документированного исключения.
|
||||
|
||||
12.3 HTTP/API
|
||||
|
||||
curl -fsS http://127.0.0.1:5600/healthz
|
||||
curl -fsS http://127.0.0.1:5600/readyz
|
||||
curl -fsS http://127.0.0.1:5600/version
|
||||
|
||||
12.4 Portal smoke
|
||||
|
||||
Проверить в браузере:
|
||||
|
||||
/portal
|
||||
/portal/reports
|
||||
/portal/architecture
|
||||
|
||||
Для Pilot v1 проверить роли:
|
||||
|
||||
executive
|
||||
manager
|
||||
security
|
||||
forensics
|
||||
admin
|
||||
|
||||
12.5 Data freshness
|
||||
|
||||
Проверить, что витрины и отчёты не пустые из-за сбоя сбора:
|
||||
|
||||
последние события поступают
|
||||
worktime reports обновляются
|
||||
DLP/security events отображаются, если включены
|
||||
evidence/reporting не падает
|
||||
Grafana dashboards открываются
|
||||
|
||||
13. Rollback
|
||||
|
||||
13.1 Быстрый rollback binary
|
||||
|
||||
Найти предыдущий backup:
|
||||
|
||||
ls -lah /opt/awatch-rus/releases/previous/
|
||||
|
||||
Восстановить:
|
||||
|
||||
sudo rsync -a --delete /opt/awatch-rus/releases/previous/bin-YYYYMMDD-HHMMSS/ /opt/awatch-rus/bin/
|
||||
sudo systemctl restart awatch-rus-backend.service
|
||||
sudo systemctl restart aw-rus-healthd.service
|
||||
|
||||
13.2 Rollback конфигурации
|
||||
|
||||
sudo cp /etc/awatch-rus/awatch-rus.env.bak /etc/awatch-rus/awatch-rus.env
|
||||
sudo systemctl restart awatch-rus-backend.service
|
||||
|
||||
13.3 Rollback CT/VM
|
||||
|
||||
Если повреждение затрагивает runtime, данные или systemd-конфигурацию:
|
||||
|
||||
остановить сервисы
|
||||
восстановить snapshot/backup
|
||||
проверить health/readiness/version
|
||||
проверить портал
|
||||
проверить поступление данных
|
||||
зафиксировать incident note
|
||||
|
||||
14. Monitoring
|
||||
|
||||
14.1 Что должно контролироваться
|
||||
|
||||
- service status;
|
||||
- process uptime;
|
||||
- API health/readiness;
|
||||
- latency;
|
||||
- error rate;
|
||||
- freshness данных;
|
||||
- заполненность диска;
|
||||
- размер логов;
|
||||
- успешность exporters;
|
||||
- SLO status;
|
||||
- agent coverage;
|
||||
- отсутствие failed systemd units.
|
||||
|
||||
14.2 Grafana
|
||||
|
||||
В Grafana должны быть разделены витрины:
|
||||
|
||||
- executive dashboard;
|
||||
- security dashboard;
|
||||
- operations dashboard;
|
||||
- RDP/user activity dashboard;
|
||||
- data quality/freshness dashboard;
|
||||
- DLP/evidence dashboard, если модуль включён.
|
||||
|
||||
14.3 Prometheus
|
||||
|
||||
Prometheus scrape должен быть доступен только из внутреннего контура мониторинга. Не открывать metrics endpoints наружу.
|
||||
|
||||
15. Security hardening
|
||||
|
||||
Обязательные правила:
|
||||
|
||||
- не публиковать API напрямую в интернет;
|
||||
- использовать VPN/reverse proxy/access control;
|
||||
- закрыть лишние порты;
|
||||
- хранить secrets вне git;
|
||||
- ограничить права systemd services;
|
||||
- использовать отдельного service user, если это поддерживается текущей установкой;
|
||||
- включить backup;
|
||||
- проверять логи после каждого патча;
|
||||
- не использовать demo fixtures как production data;
|
||||
- не смешивать реальные ФИО/IP/hostname с публичными demo screenshots.
|
||||
|
||||
16. Проверка перед вводом в эксплуатацию
|
||||
|
||||
Минимальный checklist:
|
||||
|
||||
[ ] выбран commit/tag release
|
||||
[ ] cargo fmt прошёл
|
||||
[ ] cargo clippy прошёл
|
||||
[ ] cargo test прошёл
|
||||
[ ] cargo build --release прошёл
|
||||
[ ] private config guard прошёл
|
||||
[ ] backup/snapshot создан
|
||||
[ ] binaries установлены
|
||||
[ ] systemd services запущены
|
||||
[ ] health/readiness/version отвечают
|
||||
[ ] detmir-status/check/dlp работают
|
||||
[ ] portal открывается
|
||||
[ ] роли Pilot v1 проверены
|
||||
[ ] Grafana dashboards открываются
|
||||
[ ] данные поступают
|
||||
[ ] rollback path известен
|
||||
[ ] дата/commit/оператор зафиксированы
|
||||
|
||||
17. Что больше не использовать как основной путь
|
||||
|
||||
Не использовать как основной production flow:
|
||||
|
||||
windows/deploy-single-user.ps1
|
||||
windows/deploy-domain-users.ps1
|
||||
windows/deploy-ensemble.ps1
|
||||
windows/validate-deployment.ps1
|
||||
windows/hardening-recovery.ps1
|
||||
windows/browser-domains-native-collector.ps1
|
||||
windows/dlp-endpoint-signals-collector.ps1
|
||||
|
||||
Если эти файлы физически остаются в репозитории, они должны быть явно помечены как:
|
||||
|
||||
legacy
|
||||
planned provider
|
||||
migration-only
|
||||
dev/test helper
|
||||
|
||||
Они не должны описываться в основном deployment manual как обязательный production-путь.
|
||||
|
||||
18. Короткий production runbook
|
||||
|
||||
18.1 Развернуть
|
||||
|
||||
cargo fmt --all -- --check
|
||||
cargo clippy --workspace --all-targets -- -D warnings
|
||||
cargo test --workspace
|
||||
cargo build --release --workspace
|
||||
|
||||
sudo install -m 0755 target/release/<binary> /opt/awatch-rus/bin/<binary>
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl restart <service>.service
|
||||
|
||||
18.2 Проверить
|
||||
|
||||
systemctl --failed --no-pager
|
||||
detmir-status --json
|
||||
detmir-check --json
|
||||
curl -fsS http://127.0.0.1:5600/healthz
|
||||
curl -fsS http://127.0.0.1:5600/readyz
|
||||
curl -fsS http://127.0.0.1:5600/version
|
||||
|
||||
18.3 Откатить
|
||||
|
||||
sudo rsync -a --delete /opt/awatch-rus/releases/previous/bin-YYYYMMDD-HHMMSS/ /opt/awatch-rus/bin/
|
||||
sudo systemctl restart <service>.service
|
||||
|
||||
19. Правило актуализации этого документа
|
||||
|
||||
Если меняется:
|
||||
|
||||
- имя binary;
|
||||
- имя systemd unit;
|
||||
- порт;
|
||||
- endpoint;
|
||||
- путь хранения данных;
|
||||
- способ сборки;
|
||||
- способ доставки artifacts;
|
||||
- smoke-test;
|
||||
- rollback procedure;
|
||||
|
||||
то этот файл должен обновляться в том же commit, что и изменение кода или deployment-конфигурации.
|
||||
1. Заполнен `<PROJECT_ROOT>/private-config/deploy.env`.
|
||||
2. Выполнен `<PROJECT_ROOT>/proxmox/create-ct.sh`.
|
||||
3. Выполнен `<PROJECT_ROOT>/proxmox/push-aw-artifacts.sh`.
|
||||
4. В CT выполнены `<CT_BOOTSTRAP_DIR>/install_aw_server.sh` и `<CT_BOOTSTRAP_DIR>/apply_webui_ru_patch.sh`.
|
||||
5. Сервер API/порт/UI проверены.
|
||||
6. На Windows выполнен `deploy-domain-users.ps1`.
|
||||
7. Проверены процессы, задачи и bucket'ы.
|
||||
8. Зафиксированы параметры и дата ввода.
|
||||
|
||||
@@ -0,0 +1,89 @@
|
||||
# Профессиональные сильные стороны проекта AWatch-rus
|
||||
|
||||
Ниже — структурированная, формальная сводка ключевых преимуществ AWatch-rus,
|
||||
подходит для включения в пакет документов при регистрации в реестре ПО и для
|
||||
технического аудита.
|
||||
|
||||
## 1. Архитектура и инженерный дизайн
|
||||
|
||||
- Rust-first, модульная архитектура: более 40 специализированных крейтов в
|
||||
workspace, четкая декомпозиция ответственности и воспроизводимые сборки
|
||||
(Cargo.lock).
|
||||
- Разделение на логические уровни: endpoint → серверные хранилища → processing
|
||||
→ operator → automation, что упрощает тестирование, валидацию и аудит.
|
||||
- Workspace resolver v3 и требуемая версия rust (1.85) — современный базис для
|
||||
поддержки и сопровождения.
|
||||
- Четкие migration-runbooks для последовательного и безопасного перехода
|
||||
legacy Python → Rust.
|
||||
|
||||
## 2. Операционная зрелость и автоматизация
|
||||
|
||||
- Полноценный Ansible-ensemble для end-to-end развёртывания (Proxmox, Linux,
|
||||
централизованный Windows rollout по WinRM) с retry-политикой, smoke-тестами
|
||||
и пост-deploy валидацией.
|
||||
- Safe-run pattern: dry-run/apply planners, backup-before-delete, atomic
|
||||
операции, conservative no-restart paths — минимизация риска при операциях.
|
||||
- Набор диагностических модулей (detmir-*, aw-*, quality-gate, smoke checks)
|
||||
обеспечивает быстрый feedback и ускоряет внедрение.
|
||||
|
||||
## 3. Безопасность и обращение с evidence
|
||||
|
||||
- Изолированный путь evidence: opaque IDs, bearer-upload, magic validation для
|
||||
PNG/JPEG, ограничение размера, SHA-256 валидация, atomic write и детальные
|
||||
audit trails.
|
||||
- Security hardening guide: обязательное TLS, reverse-proxy, firewall rules,
|
||||
минимальные привилегии для сервисных аккаунтов и контроль доступа к
|
||||
evidence-материалам.
|
||||
- Позиционирование: продукт не позиционируется как сертифицированная DLP/SIEM/
|
||||
EDR — это уменьшает юридические риски при регистрации и определяет четкие
|
||||
ожидания заказчика.
|
||||
|
||||
## 4. Production-readiness и критерии приёмки
|
||||
|
||||
- Полный комплект acceptance и pilot-checklists (30-дневный Pilot Success
|
||||
Criteria) с метриками: доступность портала, coverage источников, freshness
|
||||
данных, время загрузки сценариев Executive/Reporting, доля подтверждённых
|
||||
incident candidates.
|
||||
- Runbooks для восстановления, backup & restore сценарии и documented rollback
|
||||
steps.
|
||||
|
||||
## 5. Наблюдаемость, качество данных и объяснимость
|
||||
|
||||
- Встроенные SLO/health monitoring, Prometheus + Grafana витрины и
|
||||
детализированные smoke/contour тесты для проверки консистентности данных.
|
||||
- UEBA v1 — прозрачная rule-based модель с reason-codes; KPI показывают
|
||||
coverage и confidence, что повышает доверие заказчика.
|
||||
|
||||
## 6. Поддержка Windows/RDP и forensic pipelines
|
||||
|
||||
- Централизованный Windows rollout: deploy-скрипты, winrm retry logic, API
|
||||
smoke-checks (aw-watcher-afk / aw-watcher-window).
|
||||
- Серверная Hayabusa pipeline: auto-upload EVTX, severity scoring, automatic
|
||||
case creation, bounded metadata storage и Telegram-уведомления с пороговой
|
||||
фильтрацией.
|
||||
|
||||
## 7. Документированность и готовность к реестру
|
||||
|
||||
- Набор документов для регистрации: product passport, architecture, functional
|
||||
scope, dependency statement, deployment model, readiness checklist.
|
||||
- Demo fixtures и скриншоты анонимизированы (не содержат реальных IP/логинов/ФИО)
|
||||
— соответствует требованиям для публичных материалов и подачи в реестр.
|
||||
|
||||
## 8. Честное позиционирование и управление рисками
|
||||
|
||||
- Ясно задокументированы границы продукта и planned/future элементы — это
|
||||
облегчает аудит и формирует реалистичные expectations у заказчика.
|
||||
- Наличие gap-analysis и roadmap-conformance audit ускоряет планирование
|
||||
необходимых доработок перед масштабированием.
|
||||
|
||||
---
|
||||
|
||||
Файл сохранён в ветке `docs/add-professional-highlights` по пути
|
||||
`docs/PROFESSIONAL_HIGHLIGHTS_RU.md`.
|
||||
|
||||
Далее могу:
|
||||
- открыть Pull Request в main с этим изменением (рекомендуется для review),
|
||||
- смержить напрямую в main (если вы хотите немедленно обновить основную ветку),
|
||||
- или создать краткую 1-страничную выдержку для подачи в реестр.
|
||||
|
||||
Как предпочитаете поступить дальше?
|
||||
@@ -0,0 +1,174 @@
|
||||
# Резолюция по проекту AWatch-rus
|
||||
|
||||
## 📋 РЕЗОЛЮЦИЯ ПО ПРОЕКТУ AWatch-rus
|
||||
|
||||
### 1. ОБЗОР ПРОЕКТА
|
||||
|
||||
**Название:** AWatch-rus — платформа операционного контроля и технического аудита
|
||||
|
||||
**Статус:** Активный проект в стадии Pilot v1.0
|
||||
|
||||
**Язык реализации:** Rust (основной backend) + Python (вспомогательные компоненты)
|
||||
|
||||
**Лицензия:** Apache License 2.0
|
||||
|
||||
**Видимость:** Открытый репозиторий
|
||||
|
||||
---
|
||||
|
||||
### 2. НАЗНАЧЕНИЕ И ЦЕННОСТЬ
|
||||
|
||||
Проект предназначен для:
|
||||
- Workforce Analytics — мониторинг активности сотрудников, загруженности, использования приложений
|
||||
- Security Operations — DLP-сигналы, detection событий, управление инцидентами
|
||||
- Forensics & Incident Response — сбор evidence, offline-анализ через Hayabusa, расследования
|
||||
|
||||
**Целевая аудитория:** руководители, операторы ИБ, администраторы ИТ-инфраструктуры, forensics-специалисты
|
||||
|
||||
---
|
||||
|
||||
### 3. КЛЮЧЕВЫЕ КОМПОНЕНТЫ АРХИТЕКТУРЫ
|
||||
|
||||
| Компонент | Технология | Назначение |
|
||||
|-----------|------------|-----------|
|
||||
| Rust Backend | Rust runtime | Основной сервер, SLO, DLP-обработка, evidence, auto-heal |
|
||||
| Windows Collector | PowerShell/Rust | Сбор данных: AFK, window-tracking, RDP-сессии, DLP-события |
|
||||
| Grafana/Prometheus | Dashboards | Витрины для админов, операторов, руководителей |
|
||||
| ActivityWatch | Modified base | Основа для сбора telemetry и worktime |
|
||||
| Portal UI | Rust server-rendered HTML + HTMX | Веб-интерфейс на основе server-side rendering |
|
||||
|
||||
---
|
||||
|
||||
### 4. ФУНКЦИОНАЛЬНЫЕ ВОЗМОЖНОСТИ (Implemented)
|
||||
|
||||
✅ Workforce Module:
|
||||
- Отслеживание активности: рабочее время, простои, переключение окон
|
||||
- RDP-сессии с детализацией
|
||||
- Профилирование приложений и сайтов
|
||||
- KPI-отчёты для руководства
|
||||
|
||||
✅ Security Module:
|
||||
- DLP-детектирование (копирование, печать, USB)
|
||||
- UEBA v1 (прозрачная rule-based модель, без ML)
|
||||
- Управление очередью инцидентов
|
||||
- Audit действий оператора
|
||||
|
||||
✅ Forensics Module:
|
||||
- Hayabusa integration для EVTX-анализа
|
||||
- Offline investigation packs
|
||||
- Timeline и Evidence-галереи
|
||||
- Расследование инцидентов
|
||||
|
||||
✅ Operations:
|
||||
- Role-based access (executive, manager, security, forensics, admin)
|
||||
- Pilot v1.0 validation
|
||||
- Deployment topologies & sizing guide
|
||||
- Production hardening
|
||||
|
||||
---
|
||||
|
||||
### 5. ПЛАНЫ И РАСШИРЕНИЕ
|
||||
|
||||
Planned:
|
||||
- PowerShell Provider для мониторинга
|
||||
- SSH Provider
|
||||
- Syslog Provider
|
||||
- 1C Integration Provider
|
||||
- Russian OS support validation
|
||||
|
||||
Future:
|
||||
- Extended Enterprise connectors
|
||||
- SCUD/VPN integrations
|
||||
- React/TypeScript Enterprise UI
|
||||
- Tauri Desktop Forensics
|
||||
|
||||
---
|
||||
|
||||
### 6. ТЕХНИЧЕСКОЕ СОСТОЯНИЕ
|
||||
|
||||
| Метрика | Значение |
|
||||
|---------|----------|
|
||||
| Open Issues | 1 |
|
||||
| Forks | 2 |
|
||||
| Stars | 2 |
|
||||
| Repository Size | ~10.5 MB |
|
||||
| Last Push | 2026-06-12T19:17:35Z |
|
||||
| Default Branch | main |
|
||||
|
||||
---
|
||||
|
||||
### 7. DEPLOYMENT И PRODUCTION-READINESS
|
||||
|
||||
Инструменты развёртывания:
|
||||
- Ansible playbooks (полный automation stack)
|
||||
- Proxmox provisioning (CT creation)
|
||||
- Windows WinRM rollout (centralized deployment)
|
||||
- Docker/CT topologies (multi-node)
|
||||
|
||||
Документация и валидация:
|
||||
- Pilot v1.0 демо-сценарии
|
||||
- Enterprise deployment guide
|
||||
- Security hardening & backup/recovery
|
||||
- Sizing guide
|
||||
- Registry readiness документы
|
||||
|
||||
---
|
||||
|
||||
### 8. ТЕХНИЧЕСКИЕ ПРЕИМУЩЕСТВА
|
||||
|
||||
- Rust-first approach — производительность, безопасность памяти, надёжность
|
||||
- Server-side rendering — снижение нагрузки на клиент
|
||||
- API-first — OpenAPI contracts, TypeScript declarations
|
||||
- Observability — Prometheus metrics, Grafana dashboards
|
||||
- Security by default — read-only по умолчанию, безопасные mutation paths
|
||||
- Modular Rust workspace — четкая декомпозиция модулей
|
||||
|
||||
---
|
||||
|
||||
### 9. ОГРАНИЧЕНИЯ И ПОЗИЦИОНИРОВАНИЕ
|
||||
|
||||
Не позиционируется как:
|
||||
- Сертифицированная DLP/SIEM/EDR/XDR
|
||||
- ML-based UEBA
|
||||
- Юридически гарантированная неизменность evidence
|
||||
|
||||
Позиционируется как:
|
||||
- Операционная платформа контроля (Workforce + Security + Forensics)
|
||||
- Pilot-ready решение для технического аудита
|
||||
- Расширяемая архитектура для агентных и agentless-источников
|
||||
|
||||
---
|
||||
|
||||
### 10. РЕКОМЕНДАЦИИ
|
||||
|
||||
Для потенциальных пользователей:
|
||||
1. Начать с Pilot v1 demo
|
||||
2. Пройти Pilot validation checklist
|
||||
3. Использовать Ansible automation для развёртывания
|
||||
4. Ознакомиться с Security hardening guide
|
||||
5. Планировать интеграции через role-based contracts
|
||||
|
||||
Для разработчиков:
|
||||
1. Контрибутировать через PR согласно guidelines
|
||||
2. Использовать migration runbook для изменений
|
||||
3. Поддерживать quality gates и smoke tests
|
||||
|
||||
---
|
||||
|
||||
### 11. ИТОГОВАЯ ОЦЕНКА
|
||||
|
||||
- Качество кода: высокое (Rust-first, модульная архитектура)
|
||||
- Документация: полная, пригодна для реестра
|
||||
- Production-readiness: готов к пилоту, требуется валидация
|
||||
- Сообщество: ранняя стадия
|
||||
- Расширяемость: высокая
|
||||
|
||||
---
|
||||
|
||||
## ✅ ИТОГОВЫЙ ВЕРДИКТ
|
||||
|
||||
AWatch-rus — профессиональный, хорошо структурированный проект для операционного контроля корпоративной ИТ-инфраструктуры. Проект готов к оценке и пилотному развёртыванию; перед production рекомендуется пройти валидацию по чеклистам.
|
||||
|
||||
---
|
||||
|
||||
*Файл добавлён в ветку `docs/add-professional-highlights` как `docs/RELEASE_RESOLUTION_RU.md`.*
|
||||
Reference in New Issue
Block a user