AWatch-rus/REGISTER_RU_SOFTWARE.md

Сведения для подачи в реестр российского ПО

Статус документа: рабочий пакет для подготовки продукта AWatch-rus к экспертной проверке и возможной подаче в реестр российского ПО.

Документ намеренно описывает продукт как программный комплекс операционного контроля, технического аудита и управления ИТ-инфраструктурой. Продукт не заявляется как сертифицированная DLP, SIEM, EDR/XDR или средство защиты информации.

1. Наименование продукта

Публичное наименование:

• AWatch-rus.

Техническая база и репозиторий:

• AWatch-rus.

Рекомендуемая формула для документов:

Программный продукт AWatch-rus.

Для публичных материалов использовать единую формулу: Программный продукт AWatch-rus. Это не создает второго бренда и не отделяет продукт от репозитория.

2. Назначение ПО

AWatch-rus предназначен для централизованного операционного контроля, технического аудита и мониторинга ИТ-инфраструктуры организации.

Основные задачи:

• контроль состояния серверных сервисов, endpoint-сборщиков и витрин данных;
• учет пользовательской активности, рабочих интервалов и удаленных сессий;
• мониторинг свежести данных ActivityWatch и связанных buckets;
• контроль выполнения эксплуатационных регламентов и runbook-проверок;
• SLO/health мониторинг и безопасная автоматизация восстановления;
• отображение управленческих и технических dashboards;
• фиксация evidence по прикладным инцидентам;
• аудит действий оператора и техническая трассировка расследований.

Продукт закрывает задачу эксплуатационной видимости: администратор, оператор ИБ или руководитель видит, что сбор данных идет, инфраструктурные компоненты доступны, данные обновляются, а прикладные инциденты имеют прослеживаемую evidence-цепочку.

3. Класс ПО

Основной целевой класс для реестра:

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. Архитектура

Типовая архитектура экземпляра:

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. Подготовить приватную конфигурацию:

   cp private-config/deploy.env.example private-config/deploy.env
   cp ansible/inventory.example.ini ansible/inventory.ini
   

3. Заполнить параметры конкретного тестового экземпляра.

4. Собрать Rust artifacts:

   cd adk-rust
   cargo build --release --workspace
   

5. Выполнить syntax и quality checks:

   scripts/quality-gate.sh
   ansible-playbook --syntax-check -i ansible/inventory.ini ansible/deploy_aw_server.yml
   

6. Установить серверные компоненты и collectors по docs/INSTALL_RU.md.

7. Проверить работоспособность:

   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 - стратегия позиционирования.