# AWatch-rus: позиционирование для реестра российского ПО

Дата фиксации: `2026-06-03`

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

Этот документ не является юридическим заключением. Он фиксирует инженерно и
продуктово безопасную линию, чтобы не заявлять лишние классы и не создавать
ненужные вопросы по сертификации.

## 1. Вывод

Публичное имя продукта: `AWatch-rus`.
Репозиторий и техническая база: `AWatch-rus`.

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

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

AWatch-rus нужно позиционировать не как классическую DLP, SIEM, EDR/XDR
или СЗИ, а как:

> отечественную платформу операционного контроля, технического аудита,
> мониторинга действий пользователей, контроля регламентов и автоматизации
> реагирования в корпоративной ИТ-инфраструктуре.

Практически лучший основной заход в классификаторе:

| Приоритет | Класс | Почему подходит |
|---|---|---|
| Основной | `09.10 Средства управления ИТ-службой, ИТ-инфраструктурой и ИТ-активами` | AWatch-rus контролирует состояние сервисов, инфраструктурных компонентов, endpoint/runtime-задач, инцидентов и operational health. |
| Дополнительный, если нужен | `09.01 Средства управления бизнес-процессами (BPM)` | Runbook, регламенты, контроль исполнения, операторские workflow и auto-response можно описывать как управление процессами. |
| Осторожная будущая опция | security/ИБ-классы классификатора | Использовать только после отдельной подготовки доказательной базы и консультации, чтобы не подтягивать ожидания к сертифицированной СЗИ. |

Главная рекомендация: идти через `09.10`, а ИБ/DLP описывать как прикладные
модули мониторинга, аудита и расследования, не как отдельный сертифицированный
класс защиты информации.

## 2. Что не заявлять

Не заявлять продукт как:

- DLP-систему enterprise-класса;
- SIEM;
- EDR/XDR;
- сертифицированное средство защиты информации;
- продукт с заверенной моделью угроз ФСТЭК;
- продукт, обеспечивающий юридически гарантированную неизменность
  доказательств без отдельного WORM/подписанного хранилища.

Причина простая: в текущем состоянии у продукта есть сильные DLP/ИБ-возможности,
но нет формального сертификационного контура, нативного полного RBAC,
криптографической подписи политик и внешней аттестации.

## 3. Рабочее публичное описание

### Короткое описание

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

### Расширенное описание

AWatch-rus объединяет сбор активности пользователей, мониторинг
состояния сервисов, контроль endpoint-событий, DLP-сигналы, evidence workflow,
Grafana/portal-аналитику, Telegram-оповещения, runbook automation и
автовосстановление. Платформа предназначена для эксплуатации корпоративного
контура, технического аудита, контроля исполнения регламентов и расследования
операционных инцидентов.

Система ориентирована на автономную серверную работу: ключевые проверки,
синхронизация evidence, dashboards, health/SLO и операторский портал работают
на production-узлах без зависимости от ноутбука администратора.

## 4. Что можно заявлять как функции

Безопасные функции для сайта и карточки продукта:

- мониторинг активности пользователей и рабочих сессий;
- сбор endpoint-телеметрии;
- контроль состояния сервисов, scheduled tasks и systemd units;
- технический аудит действий и событий;
- контроль регламентов эксплуатации;
- runbook automation;
- safe auto-heal по allowlist;
- фиксация и разбор инцидентов;
- evidence workflow: metadata, screenshot preview/download, SHA-256 check,
  audit view/download/upload;
- Grafana dashboards и портал для оператора, менеджера и владельца;
- отчеты worktime/management;
- интеграция с ActivityWatch, InfluxDB, Grafana, SQLite/warehouse,
  ClickHouse/1C analytics;
- Telegram-уведомления и operator command path;
- Rust-first runtime helpers для скорости и надежности.

## 5. Что писать осторожно

Формулировки, которые можно использовать, но без сертификационных обещаний:

| Тема | Безопасная формулировка | Не писать |
|---|---|---|
| DLP | `DLP-сигналы`, `контроль событий возможной утечки`, `модуль фиксации ИБ-инцидентов` | `сертифицированная DLP-система`, `предотвращает все утечки` |
| ИБ | `расследование инцидентов`, `технический аудит`, `evidence workflow` | `СЗИ`, `сертифицированная защита информации` |
| SIEM | `централизованный сбор и визуализация событий` | `полноценная SIEM` |
| EDR | `endpoint telemetry`, `контроль состояния collector runtime` | `EDR/XDR` |
| Доказательства | `технические подтверждения инцидентов` | `юридически неизменяемые доказательства` |
| ИИ | `помощник оператора`, `сводки по данным системы` | `автономное принятие юридически значимых решений` |

## 6. Минимальный пакет для реестра

Перед подачей нужно подготовить:

1. Подтверждение правообладания.
   - Для текущей фиксации правообладатель: Игорь.
   - Практически желательно оформить свидетельство о регистрации программы в
     Роспатенте, хотя само по себе оно не заменяет все требования реестра.
2. Публичный сайт правообладателя или продукта.
   - Описание продукта.
   - Функциональные характеристики.
   - Документация по установке и эксплуатации.
   - Контакты правообладателя.
   - Сведения о поддерживаемых ОС/СУБД/инфраструктуре.
3. Документацию.
   - Руководство администратора.
   - Руководство оператора.
   - Руководство установки.
   - Описание архитектуры.
   - Описание модели угроз и ограничений.
   - Описание лицензирования и поставки.
4. Доказательство самостоятельности продукта.
   - Состав исходников.
   - Список сторонних компонентов и лицензий.
   - Сборка из репозитория.
   - Версионированные release artifacts.
5. Демонстрационные материалы.
   - Скриншоты портала.
   - Скриншоты Grafana dashboards.
   - Пример incident/evidence workflow.
   - Пример операторского отчета.

## 7. Сайт продукта

Минимальная структура сайта:

```text
/
  О продукте
  Возможности
  Архитектура
  Документация
  Установка
  Эксплуатация
  Скриншоты
  Ограничения и безопасность
  Контакты правообладателя
```

Рекомендуемый технический путь:

- static site или `mdBook`;
- исходники сайта в репозитории;
- публикация на отдельном домене/поддомене;
- документация генерируется из markdown, чтобы не расходиться с repo;
- отдельный раздел `Правообладание и лицензирование`.

Не надо начинать с маркетингового лендинга. Для реестра и экспертной проверки
важнее спокойный технический сайт с документацией, скриншотами и понятной
установкой.

## 8. Нормативные основания, которые учитываем

Рабочие ориентиры на дату фиксации:

- Постановление Правительства РФ от 16.11.2015 N 1236 задает правила ведения
  реестра российского ПО и состав сведений, включая сведения о правообладателе,
  сайте с документацией и основаниях исключительного права.
  Источник: `https://legalacts.ru/doc/postanovlenie-pravitelstva-rf-ot-16112015-n-1236/`
- Приказ Минцифры/Минкомсвязи России от 22.09.2020 N 486 утверждает
  классификатор программ для ЭВМ и баз данных.
  Источник: `https://normativ.kontur.ru/document?documentId=468531&moduleId=1`
- Официальный публичный реестр показывает, что карточки ПО содержат
  правообладателя, описание, класс ПО и адрес страницы сайта правообладателя с
  документацией.
  Источник: `https://reestr.digital.gov.ru/`

Практический вывод: карточка AWatch-rus должна быть подготовлена под функциональный
класс, сайт и документацию, а не под security-сертификацию.

## 9. Документы проекта, которые уже закрывают часть подготовки

Уже есть сильная база:

- `docs/THREAT_MODEL_RU.md`;
- `docs/UNIFIED_OPERATING_MODEL_RU.md`;
- `docs/PORTAL_GUI_PLAN_RU.md`;
- `docs/dlp-security-functional-spec-ru.md`;
- `docs/dlp-gap-analysis.md`;
- `docs/GRAFANA_DASHBOARDS_RU.md`;
- `docs/FULL_DEPLOYMENT_MANUAL_RU.md`;
- `docs/PRESENTATION_RU.md`;
- `docs/ADMIN_GUIDE_RU.md`;
- `docs/OPERATOR_GUIDE_RU.md`;
- `docs/INSTALL_RU.md`;
- `docs/ARCHITECTURE_RU.md`;
- `docs/OWNERSHIP_RU.md`;
- `docs/THIRD_PARTY_LICENSES_RU.md`;
- `docs/REGISTRY_CHECKLIST_RU.md`;
- `adk-rust/RUNBOOK.md`.

Эти документы надо привести к единому публичному пакету: меньше внутренних IP,
секретов и runtime-шума, больше описания назначения, установки, эксплуатации и
ограничений.

## 10. Очередь работ

1. Подготовить публичный `README_PRODUCT_RU.md`.
2. Собрать `docs/site/` или `mdbook/` для сайта.
3. Сделать страницу продукта с описанием класса `09.10`.
4. Подготовить страницу ограничений и security boundaries.
5. Подготовить скриншоты портала/Grafana без секретов и внутренних адресов.
6. Сформировать проверенный license/SBOM пакет.
7. Подготовить пакет для Роспатента.
8. После этого готовить заявку в реестр.

## 11. Решение на текущий момент

Текущая линия принята:

- основной публичный класс: операционный контроль и управление
  ИТ-инфраструктурой;
- основной классификаторный ориентир: `09.10`;
- публичное имя: `AWatch-rus`;
- техническая база/репозиторий: `AWatch-rus`;
- формула: `Программный продукт AWatch-rus`;
- DLP/ИБ/evidence/Hayabusa остаются функциональными модулями платформы;
- не заявляем сертифицированную СЗИ;
- сначала готовим сайт, документацию и правообладательский пакет.