310 lines
14 KiB
Markdown
310 lines
14 KiB
Markdown
# Сведения для подачи в реестр российского ПО
|
||
|
||
Статус документа: рабочий пакет для подготовки продукта `AWatch-rus` к
|
||
экспертной проверке и возможной подаче в реестр российского ПО.
|
||
|
||
Документ намеренно описывает продукт как программный комплекс операционного
|
||
контроля, технического аудита и управления ИТ-инфраструктурой. Продукт не
|
||
заявляется как сертифицированная DLP, SIEM, EDR/XDR или средство защиты
|
||
информации.
|
||
|
||
## 1. Наименование продукта
|
||
|
||
Публичное наименование:
|
||
|
||
- `AWatch-rus`.
|
||
|
||
Техническая база и репозиторий:
|
||
|
||
- `AWatch-rus`.
|
||
|
||
Рекомендуемая формула для документов:
|
||
|
||
```text
|
||
Программный продукт AWatch-rus.
|
||
```
|
||
|
||
Для публичных материалов использовать единую формулу: `Программный продукт
|
||
AWatch-rus`. Это не создает второго бренда и не отделяет продукт от
|
||
репозитория.
|
||
|
||
## 2. Назначение ПО
|
||
|
||
`AWatch-rus` предназначен для централизованного операционного контроля,
|
||
технического аудита и мониторинга ИТ-инфраструктуры организации.
|
||
|
||
Основные задачи:
|
||
|
||
- контроль состояния серверных сервисов, endpoint-сборщиков и витрин данных;
|
||
- учет пользовательской активности, рабочих интервалов и удаленных сессий;
|
||
- мониторинг свежести данных ActivityWatch и связанных buckets;
|
||
- контроль выполнения эксплуатационных регламентов и runbook-проверок;
|
||
- SLO/health мониторинг и безопасная автоматизация восстановления;
|
||
- отображение управленческих и технических dashboards;
|
||
- фиксация evidence по прикладным инцидентам;
|
||
- аудит действий оператора и техническая трассировка расследований.
|
||
|
||
Продукт закрывает задачу эксплуатационной видимости: администратор,
|
||
оператор ИБ или руководитель видит, что сбор данных идет, инфраструктурные
|
||
компоненты доступны, данные обновляются, а прикладные инциденты имеют
|
||
прослеживаемую evidence-цепочку.
|
||
|
||
## 3. Класс ПО
|
||
|
||
Основной целевой класс для реестра:
|
||
|
||
```text
|
||
09.10 Средства управления ИТ-службой, ИТ-инфраструктурой и ИТ-активами
|
||
```
|
||
|
||
Обоснование:
|
||
|
||
- продукт контролирует состояние ИТ-сервисов и инфраструктурных компонентов;
|
||
- содержит operational dashboards, health-check и SLO-мониторинг;
|
||
- автоматизирует эксплуатационные проверки и безопасные recovery-действия;
|
||
- хранит технические состояния, отчеты, evidence и audit trail;
|
||
- применяется для контроля работоспособности и наблюдаемости корпоративного
|
||
контура.
|
||
|
||
Дополнительный контекст, который можно использовать в описании:
|
||
|
||
- технический аудит;
|
||
- интеллектуальный мониторинг инфраструктуры;
|
||
- автоматизация runbook-процессов;
|
||
- контроль регламентов эксплуатации.
|
||
|
||
Не рекомендуется заявлять продукт как:
|
||
|
||
- сертифицированную DLP;
|
||
- SIEM;
|
||
- EDR/XDR;
|
||
- средство защиты информации;
|
||
- продукт с формальной ФСТЭК-моделью угроз.
|
||
|
||
Модули DLP/evidence/Hayabusa описываются как прикладные модули операционного
|
||
контроля и расследования событий, а не как самостоятельная сертифицированная
|
||
система защиты информации.
|
||
|
||
## 4. Правообладатель
|
||
|
||
Правообладатель: владелец репозитория и программного продукта `AWatch-rus`.
|
||
|
||
Перед подачей в реестр рекомендуется подготовить отдельный
|
||
правообладательский пакет:
|
||
|
||
- сведения о правообладателе;
|
||
- описание прав на собственные модули;
|
||
- подтверждение авторства или передачи прав на разработанные компоненты;
|
||
- перечень сторонних компонентов и лицензий;
|
||
- описание модели распространения;
|
||
- при необходимости - свидетельство Роспатента о регистрации программы для ЭВМ.
|
||
|
||
Собственными компонентами считаются:
|
||
|
||
- Rust helpers и runtime-модули AWatch-rus;
|
||
- портал оператора;
|
||
- Ansible deployment automation;
|
||
- Windows collectors/deployment scripts;
|
||
- ActivityWatch RU customization;
|
||
- Grafana dashboards проекта;
|
||
- документация, runbooks и install-kit packaging.
|
||
|
||
Сторонние компоненты перечислены отдельно в `THIRD_PARTY_LICENSES_RU.md` и
|
||
`docs/THIRD_PARTY_LICENSES_RU.md`.
|
||
|
||
## 5. Состав поставки
|
||
|
||
Публичная поставка состоит из исходного кода, документации и шаблонов
|
||
конфигурации. Индивидуальные параметры конкретного стенда не входят в
|
||
публичную поставку.
|
||
|
||
В состав входят:
|
||
|
||
- `adk-rust/` - Rust workspace с основными runtime helpers;
|
||
- `ansible/` - playbooks и examples для установки серверных и endpoint
|
||
компонентов;
|
||
- `aw-server/` - ActivityWatch server customization, service files,
|
||
RU WebUI patches и server-side helpers;
|
||
- `windows/` - Windows collectors, scheduled task deployment и common module;
|
||
- `grafana/` - dashboards для технического и управленческого мониторинга;
|
||
- `proxmox/` - операторские helpers, включая Telegram runtime, если он
|
||
используется в конкретном экземпляре;
|
||
- `docs/` - руководства администратора, оператора, архитектура, threat model,
|
||
registry positioning и runbooks;
|
||
- `private-config/*.example` - шаблоны приватной конфигурации;
|
||
- release assets - install-kit archives для проверяемых сборок.
|
||
|
||
Не входят в публичный репозиторий:
|
||
|
||
- production inventory;
|
||
- пароли;
|
||
- токены;
|
||
- реальные IP-адреса и домены экземпляра;
|
||
- runtime базы данных и evidence;
|
||
- customer deployment snapshots;
|
||
- локальная история работы операторских ИИ-агентов.
|
||
|
||
## 6. Функциональный состав
|
||
|
||
### 6.1. Контроль ActivityWatch telemetry
|
||
|
||
- проверка доступности AW API;
|
||
- контроль свежести buckets;
|
||
- учет event-driven buckets без ложного dead/stale статуса;
|
||
- health summary для оператора;
|
||
- SLO sampling и summary.
|
||
|
||
### 6.2. Учет активности и рабочего времени
|
||
|
||
- обработка window/AFK/session данных;
|
||
- отчеты по активному времени;
|
||
- поддержка RDP/Windows collector flow;
|
||
- InfluxDB/Grafana витрины;
|
||
- heartbeat freshness для контроля работы exporter-а.
|
||
|
||
### 6.3. Операционный контроль и auto-heal
|
||
|
||
- `detmir-check`;
|
||
- `detmir-status`;
|
||
- `detmir-auto`;
|
||
- безопасные recovery paths;
|
||
- контроль systemd timers/services;
|
||
- исключение опасных destructive actions из автоматического режима.
|
||
|
||
### 6.4. Evidence и расследования
|
||
|
||
- хранение evidence metadata;
|
||
- screenshot/evidence viewer в портале оператора;
|
||
- audit записи просмотра evidence;
|
||
- Hayabusa/offline DFIR flow как прикладной модуль расследования.
|
||
|
||
### 6.5. Визуализация
|
||
|
||
- Grafana dashboards;
|
||
- портал оператора;
|
||
- management views для руководителя;
|
||
- technical views для администратора и оператора ИБ.
|
||
|
||
## 7. Архитектура
|
||
|
||
Типовая архитектура экземпляра:
|
||
|
||
```text
|
||
Windows/Linux endpoints
|
||
|
|
||
v
|
||
ActivityWatch collectors / endpoint helpers
|
||
|
|
||
v
|
||
AW server + AWatch-rus Rust helpers
|
||
|
|
||
+--> SQLite state/cases/policy/evidence metadata
|
||
+--> InfluxDB/metrics storage
|
||
+--> Grafana dashboards
|
||
+--> AWatch-rus operator portal
|
||
+--> Telegram/operator runtime, если включен
|
||
```
|
||
|
||
Ядро AWatch-rus реализовано как Rust-first runtime:
|
||
|
||
- health/status/check helpers;
|
||
- worktime exporters/API/bridges;
|
||
- DLP server-side processing helpers;
|
||
- evidence API/portal helpers;
|
||
- install-kit validation tools;
|
||
- operational quality gates.
|
||
|
||
Python в составе проекта не является основным ядром продукта. Он остается для:
|
||
|
||
- Telegram bot runtime, если используется заказчиком;
|
||
- OCR/content-analysis path, где нужны Python OCR/ML библиотеки;
|
||
- 1C/AI/ETL интеграций;
|
||
- отдельных MCP/dev helper сценариев.
|
||
|
||
Такое разделение фиксируется как архитектурное: критичные серверные проверки,
|
||
status path, SLO, worktime, DLP server-side helpers и install-kit tooling
|
||
переведены на Rust-first модель.
|
||
|
||
## 8. Зависимости
|
||
|
||
Основные runtime dependencies:
|
||
|
||
- Linux/systemd;
|
||
- ActivityWatch;
|
||
- Rust runtime artifacts, собранные из `adk-rust`;
|
||
- SQLite;
|
||
- Grafana;
|
||
- InfluxDB или совместимое хранилище временных рядов, если включены metrics;
|
||
- Ansible для установки;
|
||
- PowerShell/Windows Task Scheduler для Windows collectors;
|
||
- Hayabusa для offline DFIR workflow, если включен;
|
||
- Python только для согласованных вспомогательных модулей.
|
||
|
||
Сторонние лицензии и риски AGPL/GPL/weak copyleft описаны в
|
||
`THIRD_PARTY_LICENSES_RU.md`.
|
||
|
||
## 9. Установка экземпляра
|
||
|
||
Короткий порядок для эксперта:
|
||
|
||
1. Склонировать репозиторий.
|
||
2. Подготовить приватную конфигурацию:
|
||
|
||
```bash
|
||
cp private-config/deploy.env.example private-config/deploy.env
|
||
cp ansible/inventory.example.ini ansible/inventory.ini
|
||
```
|
||
|
||
3. Заполнить параметры конкретного тестового экземпляра.
|
||
4. Собрать Rust artifacts:
|
||
|
||
```bash
|
||
cd adk-rust
|
||
cargo build --release --workspace
|
||
```
|
||
|
||
5. Выполнить syntax и quality checks:
|
||
|
||
```bash
|
||
scripts/quality-gate.sh
|
||
ansible-playbook --syntax-check -i ansible/inventory.ini ansible/deploy_aw_server.yml
|
||
```
|
||
|
||
6. Установить серверные компоненты и collectors по `docs/INSTALL_RU.md`.
|
||
7. Проверить работоспособность:
|
||
|
||
```bash
|
||
detmir-check
|
||
detmir-status
|
||
```
|
||
|
||
Ожидаемый результат: статус `OK`, отсутствуют критичные service failures и
|
||
stale/dead buckets для обязательных источников.
|
||
|
||
## 10. Ограничения
|
||
|
||
- Продукт не заменяет формально сертифицированные средства защиты информации
|
||
без отдельной сертификации.
|
||
- Реальные сетевые адреса, домены, токены и inventory являются параметрами
|
||
экземпляра и не публикуются.
|
||
- Для endpoint deployment нужны административные права.
|
||
- Для некоторых прикладных модулей нужны внешние сервисы: Grafana, InfluxDB,
|
||
Hayabusa или Python OCR stack.
|
||
- License compatibility сторонних компонентов должна проверяться перед
|
||
коммерческой поставкой.
|
||
|
||
## 11. Документы пакета
|
||
|
||
- `PRODUCT_DESCRIPTION_RU.md` - краткое описание продукта.
|
||
- `CHANGELOG_RU.md` - журнал изменений и статус публичных release-пакетов.
|
||
- `INSTALL_FOR_EXPERT_RU.md` - короткая инструкция установки экземпляра.
|
||
- `docs/EXPERT_TEST_SCENARIO_RU.md` - ручной сценарий экспертной проверки после установки.
|
||
- `docs/RELEASE_MANIFEST_2026-06.md` - manifest release artifacts, checksums и gates.
|
||
- `THIRD_PARTY_COMPONENTS.md` - обзор сторонних компонентов.
|
||
- `THIRD_PARTY_LICENSES_RU.md` - лицензии и license-audit checklist.
|
||
- `docs/ARCHITECTURE_RU.md` - архитектура.
|
||
- `docs/ADMIN_GUIDE_RU.md` - руководство администратора.
|
||
- `docs/OPERATOR_GUIDE_RU.md` - руководство оператора.
|
||
- `docs/RUSSIAN_SOFTWARE_REGISTRY_POSITIONING_RU.md` - стратегия
|
||
позиционирования.
|