awatch-rus/AWatch-rus
1
0
Fork 0
Code Issues Pull Requests Actions 100 Packages Projects Releases Wiki Activity
Files
888dbc32ef06e32df04a1c482f110a76b1697761
AWatch-rus/docs/DETMIR_RUSSIAN_SOFTWARE_REGISTRY_POSITIONING_RU.md
T

15 KiB
Raw Blame History

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. Сайт продукта

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

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

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

  • 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/DETMIR_THREAT_MODEL_RU.md;
  • docs/DETMIR_UNIFIED_OPERATING_MODEL_RU.md;
  • docs/DETMIR_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 остаются функциональными модулями платформы;
  • не заявляем сертифицированную СЗИ;
  • сначала готовим сайт, документацию и правообладательский пакет.
Reference in New Issue View Git Blame Copy Permalink