awatch-rus/AWatch-rus
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(registry): strengthen software registry package

Browse Source
This commit is contained in:
igor04091968
2026-06-03 08:30:37 +03:00
parent c2d1f40033
commit 35653b45b6
5 changed files with 612 additions and 159 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.gitignore
+4
View File
@@ -35,3 +35,7 @@ data/
/.graphify_*.json /.graphify_*.json
/.graphify_*.txt /.graphify_*.txt
/.graphify_python/ /.graphify_python/
# Release assets kept outside git
/install-kit-awindows-*.zip
/install-kit-awindows-*.tar.gz
README.md
+10
View File
@@ -17,6 +17,15 @@ evidence и Hayabusa используются как прикладные мод
- Автоматизация runbook-проверок, health-check, SLO и безопасного auto-heal. - Автоматизация runbook-проверок, health-check, SLO и безопасного auto-heal.
- Сбор evidence по инцидентам и аудит действий оператора. - Сбор evidence по инцидентам и аудит действий оператора.
## Rust-first runtime
Основной серверный runtime DetMir переведен на 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.
## Что видит оператор ## Что видит оператор
- Работал ли пользователь за компьютером или в удаленной сессии. - Работал ли пользователь за компьютером или в удаленной сессии.
@@ -42,6 +51,7 @@ evidence и Hayabusa используются как прикладные мод
- [Описание продукта](PRODUCT_DESCRIPTION_RU.md) - [Описание продукта](PRODUCT_DESCRIPTION_RU.md)
- [Установка для эксперта](INSTALL_FOR_EXPERT_RU.md) - [Установка для эксперта](INSTALL_FOR_EXPERT_RU.md)
- [Сторонние компоненты](THIRD_PARTY_COMPONENTS.md) - [Сторонние компоненты](THIRD_PARTY_COMPONENTS.md)
- [Сторонние лицензии](THIRD_PARTY_LICENSES_RU.md)
- [Архитектура](docs/ARCHITECTURE_RU.md) - [Архитектура](docs/ARCHITECTURE_RU.md)
- [Установка](docs/INSTALL_RU.md) - [Установка](docs/INSTALL_RU.md)
- [Руководство администратора](docs/ADMIN_GUIDE_RU.md) - [Руководство администратора](docs/ADMIN_GUIDE_RU.md)
REGISTER_RU_SOFTWARE.md
+263 -74
View File
@@ -1,117 +1,306 @@
# Сведения для подачи в реестр российского ПО # Сведения для подачи в реестр российского ПО
## 1. Назначение ПО Статус документа: рабочий пакет для подготовки продукта `DetMir` на базе
`AWatch-rus` к экспертной проверке и возможной подаче в реестр российского ПО.
`DetMir` на базе `AWatch-rus` - программный комплекс операционного контроля, Документ намеренно описывает продукт как программный комплекс операционного
технического аудита и мониторинга ИТ-инфраструктуры. контроля, технического аудита и управления ИТ-инфраструктурой. Продукт не
заявляется как сертифицированная DLP, SIEM, EDR/XDR или средство защиты
информации.
ПО предназначено для: ## 1. Наименование продукта
- контроля состояния сервисов и endpoint-сборщиков; Коммерческое/продуктовое наименование:
- учета пользовательской активности и рабочего времени;
- централизованного технического аудита событий;
- отображения данных в Grafana/портале оператора;
- автоматизации runbook-проверок, SLO-контроля и безопасного реагирования;
- фиксации evidence по прикладным инцидентам и аудита действий оператора.
ПО не заявляется как сертифицированная DLP, SIEM, EDR/XDR или средство защиты - `DetMir`.
информации. Модули DLP/evidence/Hayabusa рассматриваются как прикладные модули
операционного контроля и расследования событий.
## 2. Класс ПО Техническая база и репозиторий:
Основной целевой класс: - `AWatch-rus`.
- `09.10 Средства управления ИТ-службой, ИТ-инфраструктурой и ИТ-активами`. Рекомендуемая формула для документов:
Возможный дополнительный контекст: ```text
DetMir, программный комплекс на базе AWatch-rus.
```
Такое разделение позволяет использовать `DetMir` как продуктовую марку, а
`AWatch-rus` как техническое имя репозитория и исходной кодовой базы.
## 2. Назначение ПО
`DetMir` предназначен для централизованного операционного контроля,
технического аудита и мониторинга ИТ-инфраструктуры организации.
Основные задачи:
- контроль состояния серверных сервисов, endpoint-сборщиков и витрин данных;
- учет пользовательской активности, рабочих интервалов и удаленных сессий;
- мониторинг свежести данных ActivityWatch и связанных buckets;
- контроль выполнения эксплуатационных регламентов и runbook-проверок;
- SLO/health мониторинг и безопасная автоматизация восстановления;
- отображение управленческих и технических dashboards;
- фиксация evidence по прикладным инцидентам;
- аудит действий оператора и техническая трассировка расследований.
Продукт закрывает задачу эксплуатационной видимости: администратор,
оператор ИБ или руководитель видит, что сбор данных идет, инфраструктурные
компоненты доступны, данные обновляются, а прикладные инциденты имеют
прослеживаемую evidence-цепочку.
## 3. Класс ПО
Основной целевой класс для реестра:
```text
09.10 Средства управления ИТ-службой, ИТ-инфраструктурой и ИТ-активами
```
Обоснование:
- продукт контролирует состояние ИТ-сервисов и инфраструктурных компонентов;
- содержит operational dashboards, health-check и SLO-мониторинг;
- автоматизирует эксплуатационные проверки и безопасные recovery-действия;
- хранит технические состояния, отчеты, evidence и audit trail;
- применяется для контроля работоспособности и наблюдаемости корпоративного
контура.
Дополнительный контекст, который можно использовать в описании:
- автоматизация регламентов эксплуатации;
- технический аудит; - технический аудит;
- мониторинг корпоративной инфраструктуры. - интеллектуальный мониторинг инфраструктуры;
- автоматизация runbook-процессов;
- контроль регламентов эксплуатации.
## 3. Правообладатель Не рекомендуется заявлять продукт как:
- сертифицированную DLP;
- SIEM;
- EDR/XDR;
- средство защиты информации;
- продукт с формальной ФСТЭК-моделью угроз.
Модули DLP/evidence/Hayabusa описываются как прикладные модули операционного
контроля и расследования событий, а не как самостоятельная сертифицированная
система защиты информации.
## 4. Правообладатель
Правообладатель: владелец репозитория и программного комплекса `DetMir / Правообладатель: владелец репозитория и программного комплекса `DetMir /
AWatch-rus`. AWatch-rus`.
Перед подачей в реестр рекомендуется оформить отдельный правообладательский Перед подачей в реестр рекомендуется подготовить отдельный
пакет: правообладательский пакет:
- сведения о правообладателе; - сведения о правообладателе;
- подтверждение авторства собственных модулей; - описание прав на собственные модули;
- перечень сторонних компонентов; - подтверждение авторства или передачи прав на разработанные компоненты;
- условия лицензирования и распространения; - перечень сторонних компонентов и лицензий;
- описание модели распространения;
- при необходимости - свидетельство Роспатента о регистрации программы для ЭВМ. - при необходимости - свидетельство Роспатента о регистрации программы для ЭВМ.
## 4. Состав поставки Собственными компонентами считаются:
В состав поставки входят: - Rust helpers и runtime-модули DetMir;
- Rust workspace `adk-rust/` с основными runtime helpers;
- Ansible playbooks для установки и обновления серверных компонентов;
- Windows PowerShell collectors и deployment scripts;
- Grafana dashboards и monitoring assets;
- ActivityWatch server customization и RU WebUI patching;
- портал оператора; - портал оператора;
- документация администратора, оператора, установки и архитектуры; - Ansible deployment automation;
- install-kit artifacts для повторяемой поставки. - Windows collectors/deployment scripts;
- ActivityWatch RU customization;
- Grafana dashboards проекта;
- документация, runbooks и install-kit packaging.
Индивидуальные production inventory, пароли, токены, домены, IP-адреса и Сторонние компоненты перечислены отдельно в `THIRD_PARTY_LICENSES_RU.md` и
локальные runtime-файлы не входят в публичную поставку. `docs/THIRD_PARTY_LICENSES_RU.md`.
## 5. Установка экземпляра ## 5. Состав поставки
Типовой порядок установки: Публичная поставка состоит из исходного кода, документации и шаблонов
конфигурации. Индивидуальные параметры конкретного стенда не входят в
публичную поставку.
1. Подготовить Linux/Proxmox или другой серверный runtime согласно В состав входят:
`docs/INSTALL_RU.md`.
2. Скопировать `private-config/deploy.env.example` в локальный - `adk-rust/` - Rust workspace с основными runtime helpers;
`private-config/deploy.env` и заполнить параметры конкретного экземпляра. - `ansible/` - playbooks и examples для установки серверных и endpoint
3. Подготовить Ansible inventory локально на основе компонентов;
`ansible/inventory.example.ini`. - `aw-server/` - ActivityWatch server customization, service files,
4. Собрать Rust release artifacts: 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 + DetMir Rust helpers
|
+--> SQLite state/cases/policy/evidence metadata
+--> InfluxDB/metrics storage
+--> Grafana dashboards
+--> DetMir operator portal
+--> Telegram/operator runtime, если включен
```
Ядро DetMir реализовано как 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 ```bash
cd adk-rust cd adk-rust
cargo build --release --workspace cargo build --release --workspace
``` ```
5. Выполнить playbooks установки серверных компонентов и сборщиков. 5. Выполнить syntax и quality checks:
6. Проверить контур:
```bash ```bash
scripts/quality-gate.sh 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-check
detmir-status detmir-status
``` ```
Точные адреса сервисов, домены, учетные данные и токены задаются только в Ожидаемый результат: статус `OK`, отсутствуют критичные service failures и
локальных конфигурационных файлах экземпляра. stale/dead buckets для обязательных источников.
## 6. Сторонние компоненты ## 10. Ограничения
Основные внешние компоненты:
- ActivityWatch;
- Rust crates ecosystem;
- Grafana;
- Prometheus/InfluxDB exporters and clients;
- Ansible;
- PowerShell/Windows runtime;
- SQLite;
- Hayabusa and related DFIR tooling where enabled.
Детальный перечень ведется в `docs/THIRD_PARTY_LICENSES_RU.md`.
## 7. Ограничения и зависимости
- Для полноценной работы нужны права администратора на устанавливаемых
серверных и endpoint-компонентах.
- Telegram runtime, если используется, остается отдельным Python-компонентом.
- OCR/content-analysis может использовать Python-зависимости для обработки
изображений; основной серверный runtime переведен на Rust-first helpers.
- Сетевые адреса, домены, токены и inventory являются параметрами конкретного
экземпляра и не должны публиковаться в репозитории.
- Продукт не заменяет формально сертифицированные средства защиты информации - Продукт не заменяет формально сертифицированные средства защиты информации
без отдельной сертификации и модели угроз. без отдельной сертификации.
- Реальные сетевые адреса, домены, токены и inventory являются параметрами
экземпляра и не публикуются.
- Для endpoint deployment нужны административные права.
- Для некоторых прикладных модулей нужны внешние сервисы: Grafana, InfluxDB,
Hayabusa или Python OCR stack.
- License compatibility сторонних компонентов должна проверяться перед
коммерческой поставкой.
## 11. Документы пакета
- `PRODUCT_DESCRIPTION_RU.md` - краткое описание продукта.
- `INSTALL_FOR_EXPERT_RU.md` - короткая инструкция установки экземпляра.
- `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/DETMIR_RUSSIAN_SOFTWARE_REGISTRY_POSITIONING_RU.md` - стратегия
позиционирования.
THIRD_PARTY_LICENSES_RU.md
+185
View File
@@ -0,0 +1,185 @@
# DetMir / AWatch-rus: сторонние компоненты и лицензии
Статус документа: рабочий license inventory для подготовки поставки и
экспертной проверки. Документ не является юридическим заключением. Перед
коммерческой поставкой или подачей в реестр нужно выполнить полный
автоматизированный SBOM/license audit по конкретной release-сборке.
## 1. Собственный код проекта
Собственные компоненты `DetMir / AWatch-rus`:
- Rust workspace `adk-rust/`;
- DetMir status/check/auto/heal helpers;
- worktime exporters/API/bridge/autoheal;
- DLP server-side helpers;
- evidence API и portal helpers;
- Ansible playbooks и deployment automation;
- Windows PowerShell collectors/deployment scripts;
- ActivityWatch RU WebUI patches;
- Grafana dashboards проекта;
- install-kit tooling;
- документация.
Для собственного кода в корне репозитория указан `LICENSE`:
```text
Apache License 2.0
```
Это применимо только к собственным частям проекта. Сторонние компоненты
сохраняют свои лицензии.
## 2. Ключевые сторонние компоненты
| Компонент | Роль в продукте | Типовая лицензия upstream | Статус поставки | Комментарий для аудита |
|---|---|---|---|---|
| ActivityWatch | Базовый сбор и API событий активности | MPL-2.0 | Устанавливается/используется как внешний компонент | Weak copyleft на измененные MPL-файлы; модификации ActivityWatch нужно учитывать отдельно. |
| Grafana OSS | Dashboards и визуализация | AGPL-3.0 для современных версий Grafana OSS | Обычно внешний сервис/контейнер, не собственный код DetMir | AGPL требует отдельной проверки модели распространения и сетевого использования. |
| Prometheus | Monitoring ecosystem, exporters, scrape model | Apache-2.0 | Внешний компонент при включении мониторинга | Совместим с Apache-поставкой при соблюдении notice/license требований. |
| InfluxDB / compatible TSDB | Хранилище временных рядов `aw_metrics` | Зависит от версии/дистрибутива | Внешний компонент | Зафиксировать конкретную версию в release notes. |
| Hayabusa | Offline/DFIR timeline и enrichment | AGPLv3; rules могут иметь Detection Rule License | Опциональный прикладной модуль расследования | Не позиционировать как ядро продукта; проверить obligations при включении в поставку. |
| Ansible | Deployment automation | GPL-3.0-or-later для Ansible core | Инструмент установки | Обычно не линкуется с кодом продукта; входит в toolchain. |
| PowerShell | Windows deployment/collectors runtime | MIT для PowerShell Core; Windows PowerShell как компонент ОС | Runtime/tooling | Уточнять окружение заказчика: Windows PowerShell или PowerShell 7. |
| SQLite | Local state/warehouse DB | Public domain/blessing style | Embedded/library/runtime | Обычно низкий license risk. |
| ClickHouse clients/tooling | 1C/file analytics integration | Зависит от клиента; ClickHouse server Apache-2.0 | Отдельный 1C/business-data слой | Не является обязательным ядром DetMir. |
| OpenAI/Pollinations-compatible integrations | AI assistant/integration paths | API terms, не open-source license | Опционально | Не включать ключи/API credentials в поставку. |
## 3. Rust dependencies
Rust является основным runtime-слоем DetMir. Точный список зависимостей должен
фиксироваться по `Cargo.lock` конкретного релиза.
Ключевые crates, используемые в workspace:
| Crate | Назначение | Типичные лицензии ecosystem | Действие перед релизом |
|---|---|---|---|
| `anyhow` | Error handling | MIT OR Apache-2.0 | Проверить через `cargo about`. |
| `clap` | CLI parsing | MIT OR Apache-2.0 | Проверить transitive deps. |
| `chrono` | Date/time | MIT OR Apache-2.0 | Зафиксировать версию. |
| `serde`, `serde_json`, `serde_yaml` | Serialization | MIT OR Apache-2.0 | Проверить YAML transitive deps. |
| `reqwest` | HTTP client | MIT OR Apache-2.0 | Проверить TLS backend и transitive deps. |
| `rusqlite` | SQLite access | MIT | Проверить bundled/system SQLite режим. |
| `regex` | Matching rules | MIT OR Apache-2.0 | Низкий риск. |
| `sha2` | Hashing | MIT OR Apache-2.0 | Низкий риск. |
| `base64` | Encoding/decoding | MIT OR Apache-2.0 | Низкий риск. |
| `tiny_http` | Lightweight HTTP service | MIT OR Apache-2.0 | Проверить версию. |
| `url`, `urlencoding` | URL handling | MIT OR Apache-2.0 | Проверить transitive deps. |
| `tempfile` | Tests/temp files | MIT OR Apache-2.0 | Test/dev dependency. |
Обязательные команды для release audit:
```bash
cargo install cargo-about cargo-deny cargo-auditable
cd adk-rust
cargo metadata --locked --format-version 1 > ../docs/sbom-cargo-metadata.json
cargo deny check
cargo about generate about.hbs > ../docs/licenses-rust.html
```
Если шаблон `about.hbs` отсутствует, его нужно добавить в release tooling или
использовать стандартный шаблон организации.
## 4. Python-зависимости
Python не является основным runtime-ядром DetMir. Он остается для
согласованных вспомогательных направлений:
- Telegram bot runtime, если включен в экземпляре;
- OCR/content-analysis path;
- 1C/AI/ETL integration layer;
- MCP/dev helper tools;
- legacy-compatible scripts, не входящие в Rust-first server core.
Известные requirements:
| Файл | Назначение | Основные зависимости | License-audit действие |
|---|---|---|---|
| `aw-server/dlp-content-analysis/requirements.txt` | OCR/content analysis | `pytesseract`, `Pillow` | Проверить OCR stack и system Tesseract license отдельно. |
| `aw-server/dlp-case-management/requirements.txt` | Legacy/reference case API | `fastapi`, `uvicorn`, `pydantic` | Проверить, поставляется ли как runtime или только reference. |
| `aw-server/dlp-policy-engine/requirements.txt` | Legacy/reference policy API | `fastapi`, `uvicorn`, `pydantic` | Rust replacement должен быть primary runtime. |
| `aw-server/dlp-compliance/requirements.txt` | Legacy/reference reports | `requests` | Проверить, не входит ли в active runtime. |
| `aw-server/dlp-integrations/requirements.txt` | Legacy/reference integrations | `PyYAML` | Проверить статус после Rust migration. |
| `clickhouse-1c/ai/requirements.txt` | 1C/AI APIs | `fastapi`, `uvicorn`, `clickhouse-connect` | Отдельный business-data слой. |
| `clickhouse-1c/etl/requirements.txt` | 1C ETL | `clickhouse-connect`, `PyYAML`, `python-dateutil`, `openpyxl` | Отдельный ETL слой. |
| `detmir-mcp` | MCP helper | Python MCP stack | Не основное runtime-ядро продукта. |
Команды для Python license report:
```bash
python3 -m venv /tmp/detmir-license-audit
. /tmp/detmir-license-audit/bin/activate
python -m pip install -U pip pip-licenses
pip-licenses --from=mixed --format=markdown > docs/licenses-python.md
```
Команду нужно выполнять в окружении, где установлены зависимости конкретного
release profile.
## 5. Frontend, dashboards и browser tooling
| Компонент | Роль | License-audit действие |
|---|---|---|
| Grafana dashboards JSON | Собственные dashboards DetMir | Входят в собственную поставку; проверить отсутствие embedded secrets/URLs. |
| ActivityWatch WebUI patches | Собственный overlay/patch слой | Учитывать MPL-2.0 границы ActivityWatch, если изменяются upstream файлы. |
| Playwright/browser smoke tooling | Проверки UI | Обычно dev/test dependency; не включать в runtime claim. |
| JavaScript snippets | WebUI patching/helper scripts | Проверить зависимости, если добавляются npm packages. |
## 6. Компоненты с повышенным вниманием
| Компонент | Причина внимания | Рекомендация |
|---|---|---|
| Grafana OSS | AGPL-3.0 для современных версий | В реестровой поставке описывать как внешний компонент или проверить obligations. |
| Hayabusa | AGPLv3 + отдельная лицензия rules | Держать как optional offline module; не смешивать с закрытым ядром без аудита. |
| Ansible | GPL toolchain | Описывать как инструмент установки, не как linked library продукта. |
| OCR/Tesseract stack | Несколько уровней зависимостей | Фиксировать конкретные пакеты ОС и Python packages. |
| Python legacy paths | Могут выглядеть как ядро | В документации указывать, что Rust-first runtime является основным. |
## 7. Что поставляется вместе с продуктом
В публичной поставке могут присутствовать:
- исходный код собственных модулей;
- шаблоны конфигурации;
- Ansible playbooks;
- Grafana dashboards;
- Windows collectors scripts;
- install-kit archives как GitHub Release assets;
- документация.
Не должны поставляться в публичном git:
- production inventory;
- реальные домены/IP конкретного экземпляра;
- пароли и токены;
- runtime базы данных;
- customer evidence;
- локальная история разработки;
- случайные binary archives в корне репозитория.
## 8. Release checklist по лицензиям
Перед каждым публичным release:
1. Собрать Rust SBOM по `Cargo.lock`.
2. Выполнить `cargo deny check`.
3. Сформировать Rust license report.
4. Сформировать Python license report для включенных profiles.
5. Проверить Grafana/Hayabusa/Ansible как внешние компоненты.
6. Проверить, что root репозитория не содержит случайных архивов сборки.
7. Проверить отсутствие secrets, private inventory, customer paths.
8. Зафиксировать версию ActivityWatch и способ ее установки.
9. Зафиксировать, какие optional modules включены в релиз.
10. Сохранить отчеты в release artifacts или `docs/licenses-*`.
## 9. Источники для проверки upstream лицензий
- ActivityWatch repository/license: `https://github.com/ActivityWatch/activitywatch`
- Grafana licensing: `https://grafana.com/licensing/`
- Grafana repository/license: `https://github.com/grafana/grafana`
- Prometheus repository/license: `https://github.com/prometheus/prometheus`
- Hayabusa repository/license: `https://github.com/Yamato-Security/hayabusa`
- Ansible repository/license: `https://github.com/ansible/ansible`
Финальная версия документа должна ссылаться на конкретные версии компонентов,
использованные в release build.
docs/THIRD_PARTY_LICENSES_RU.md
+150 -85
View File
@@ -1,120 +1,185 @@
# DetMir: сторонние компоненты и лицензии # DetMir / AWatch-rus: сторонние компоненты и лицензии
Статус: первичный inventory для подготовки к реестру российского ПО. Статус документа: рабочий license inventory для подготовки поставки и
экспертной проверки. Документ не является юридическим заключением. Перед
коммерческой поставкой или подачей в реестр нужно выполнить полный
автоматизированный SBOM/license audit по конкретной release-сборке.
Этот документ не заменяет юридическую license audit. Перед подачей в реестр ## 1. Собственный код проекта
нужно выполнить автоматизированную проверку зависимостей и сохранить отчет.
Продуктовое имя: `DetMir`. Собственные компоненты `DetMir / AWatch-rus`:
Техническая база и репозиторий: `AWatch-rus`.
## 1. Собственный код
Собственный код проекта включает:
- Rust workspace `adk-rust/`; - Rust workspace `adk-rust/`;
- Ansible playbooks; - DetMir status/check/auto/heal helpers;
- Windows PowerShell collectors и deployment scripts; - worktime exporters/API/bridge/autoheal;
- AW-rus WebUI patches; - DLP server-side helpers;
- DetMir Portal; - evidence API и portal helpers;
- DLP/worktime/status/reporting helpers; - Ansible playbooks и deployment automation;
- документацию проекта. - Windows PowerShell collectors/deployment scripts;
- ActivityWatch RU WebUI patches;
- Grafana dashboards проекта;
- install-kit tooling;
- документация.
В `adk-rust/Cargo.toml` для workspace указан license: Для собственного кода в корне репозитория указан `LICENSE`:
```text ```text
Apache-2.0 Apache License 2.0
``` ```
Перед публичной поставкой нужно проверить, что license root файла и все Это применимо только к собственным частям проекта. Сторонние компоненты
исходники согласованы с выбранной моделью поставки. сохраняют свои лицензии.
## 2. Основные внешние компоненты runtime ## 2. Ключевые сторонние компоненты
| Компонент | Роль | | Компонент | Роль в продукте | Типовая лицензия upstream | Статус поставки | Комментарий для аудита |
|---|---| |---|---|---|---|---|
| ActivityWatch | Базовый сбор и API событий активности. | | ActivityWatch | Базовый сбор и API событий активности | MPL-2.0 | Устанавливается/используется как внешний компонент | Weak copyleft на измененные MPL-файлы; модификации ActivityWatch нужно учитывать отдельно. |
| Grafana | Dashboards и визуализация. | | Grafana OSS | Dashboards и визуализация | AGPL-3.0 для современных версий Grafana OSS | Обычно внешний сервис/контейнер, не собственный код DetMir | AGPL требует отдельной проверки модели распространения и сетевого использования. |
| InfluxDB | Метрики и временные ряды. | | Prometheus | Monitoring ecosystem, exporters, scrape model | Apache-2.0 | Внешний компонент при включении мониторинга | Совместим с Apache-поставкой при соблюдении notice/license требований. |
| ClickHouse | 1C/file analytics слой. | | InfluxDB / compatible TSDB | Хранилище временных рядов `aw_metrics` | Зависит от версии/дистрибутива | Внешний компонент | Зафиксировать конкретную версию в release notes. |
| SQLite | Локальные state/warehouse/cases/policy хранилища. | | Hayabusa | Offline/DFIR timeline и enrichment | AGPLv3; rules могут иметь Detection Rule License | Опциональный прикладной модуль расследования | Не позиционировать как ядро продукта; проверить obligations при включении в поставку. |
| Python | Telegram runtime и legacy-compatible tooling. | | Ansible | Deployment automation | GPL-3.0-or-later для Ansible core | Инструмент установки | Обычно не линкуется с кодом продукта; входит в toolchain. |
| Rust crates ecosystem | Основной runtime DetMir helpers. | | PowerShell | Windows deployment/collectors runtime | MIT для PowerShell Core; Windows PowerShell как компонент ОС | Runtime/tooling | Уточнять окружение заказчика: Windows PowerShell или PowerShell 7. |
| PowerShell | Windows collectors/deployment. | | SQLite | Local state/warehouse DB | Public domain/blessing style | Embedded/library/runtime | Обычно низкий license risk. |
| Hayabusa | Offline/DFIR enrichment. | | ClickHouse clients/tooling | 1C/file analytics integration | Зависит от клиента; ClickHouse server Apache-2.0 | Отдельный 1C/business-data слой | Не является обязательным ядром DetMir. |
| Ansible | Deployment automation. | | OpenAI/Pollinations-compatible integrations | AI assistant/integration paths | API terms, не open-source license | Опционально | Не включать ключи/API credentials в поставку. |
## 3. Rust зависимости ## 3. Rust dependencies
Найдены workspace dependencies: Rust является основным runtime-слоем DetMir. Точный список зависимостей должен
фиксироваться по `Cargo.lock` конкретного релиза.
| Dependency | Использование | Ключевые crates, используемые в workspace:
|---|---|
| `adk-rust` | Agent/tooling integration. |
| `anyhow` | Error handling. |
| `base64` | Evidence upload body decoding. |
| `chrono` | Time/date handling. |
| `clap` | CLI parsing. |
| `fs2` | File locks. |
| `reqwest` | HTTP client. |
| `regex` | Rules/content matching. |
| `rusqlite` | SQLite access. |
| `serde`, `serde_json`, `serde_yaml` | Serialization. |
| `sha2` | SHA-256 validation. |
| `tempfile` | Tests/temp files. |
| `tiny_http` | Lightweight HTTP services. |
| `url`, `urlencoding` | URL handling. |
Перед релизом выполнить: | Crate | Назначение | Типичные лицензии ecosystem | Действие перед релизом |
|---|---|---|---|
| `anyhow` | Error handling | MIT OR Apache-2.0 | Проверить через `cargo about`. |
| `clap` | CLI parsing | MIT OR Apache-2.0 | Проверить transitive deps. |
| `chrono` | Date/time | MIT OR Apache-2.0 | Зафиксировать версию. |
| `serde`, `serde_json`, `serde_yaml` | Serialization | MIT OR Apache-2.0 | Проверить YAML transitive deps. |
| `reqwest` | HTTP client | MIT OR Apache-2.0 | Проверить TLS backend и transitive deps. |
| `rusqlite` | SQLite access | MIT | Проверить bundled/system SQLite режим. |
| `regex` | Matching rules | MIT OR Apache-2.0 | Низкий риск. |
| `sha2` | Hashing | MIT OR Apache-2.0 | Низкий риск. |
| `base64` | Encoding/decoding | MIT OR Apache-2.0 | Низкий риск. |
| `tiny_http` | Lightweight HTTP service | MIT OR Apache-2.0 | Проверить версию. |
| `url`, `urlencoding` | URL handling | MIT OR Apache-2.0 | Проверить transitive deps. |
| `tempfile` | Tests/temp files | MIT OR Apache-2.0 | Test/dev dependency. |
Обязательные команды для release audit:
```bash ```bash
cargo install cargo-about cargo-deny cargo install cargo-about cargo-deny cargo-auditable
cd adk-rust cd adk-rust
cargo about generate about.hbs > ../docs/licenses-rust.html cargo metadata --locked --format-version 1 > ../docs/sbom-cargo-metadata.json
cargo deny check cargo deny check
cargo about generate about.hbs > ../docs/licenses-rust.html
``` ```
Шаблон `about.hbs` нужно добавить отдельно. Если шаблон `about.hbs` отсутствует, его нужно добавить в release tooling или
использовать стандартный шаблон организации.
## 4. Python зависимости ## 4. Python-зависимости
Найдены requirements: Python не является основным runtime-ядром DetMir. Он остается для
согласованных вспомогательных направлений:
| Файл | Зависимости | - Telegram bot runtime, если включен в экземпляре;
|---|---| - OCR/content-analysis path;
| `aw-server/dlp-case-management/requirements.txt` | `fastapi`, `uvicorn`, `pydantic` | - 1C/AI/ETL integration layer;
| `aw-server/dlp-compliance/requirements.txt` | `requests` | - MCP/dev helper tools;
| `aw-server/dlp-content-analysis/requirements.txt` | `pytesseract`, `Pillow` | - legacy-compatible scripts, не входящие в Rust-first server core.
| `aw-server/dlp-integrations/requirements.txt` | `PyYAML` |
| `aw-server/dlp-policy-engine/requirements.txt` | `fastapi`, `uvicorn`, `pydantic` |
| `clickhouse-1c/ai/requirements.txt` | `fastapi`, `uvicorn`, `clickhouse-connect` |
| `clickhouse-1c/etl/requirements.txt` | `clickhouse-connect`, `PyYAML`, `python-dateutil`, `openpyxl` |
Перед релизом выполнить license scan: Известные requirements:
| Файл | Назначение | Основные зависимости | License-audit действие |
|---|---|---|---|
| `aw-server/dlp-content-analysis/requirements.txt` | OCR/content analysis | `pytesseract`, `Pillow` | Проверить OCR stack и system Tesseract license отдельно. |
| `aw-server/dlp-case-management/requirements.txt` | Legacy/reference case API | `fastapi`, `uvicorn`, `pydantic` | Проверить, поставляется ли как runtime или только reference. |
| `aw-server/dlp-policy-engine/requirements.txt` | Legacy/reference policy API | `fastapi`, `uvicorn`, `pydantic` | Rust replacement должен быть primary runtime. |
| `aw-server/dlp-compliance/requirements.txt` | Legacy/reference reports | `requests` | Проверить, не входит ли в active runtime. |
| `aw-server/dlp-integrations/requirements.txt` | Legacy/reference integrations | `PyYAML` | Проверить статус после Rust migration. |
| `clickhouse-1c/ai/requirements.txt` | 1C/AI APIs | `fastapi`, `uvicorn`, `clickhouse-connect` | Отдельный business-data слой. |
| `clickhouse-1c/etl/requirements.txt` | 1C ETL | `clickhouse-connect`, `PyYAML`, `python-dateutil`, `openpyxl` | Отдельный ETL слой. |
| `detmir-mcp` | MCP helper | Python MCP stack | Не основное runtime-ядро продукта. |
Команды для Python license report:
```bash ```bash
python3 -m pip install pip-licenses python3 -m venv /tmp/detmir-license-audit
. /tmp/detmir-license-audit/bin/activate
python -m pip install -U pip pip-licenses
pip-licenses --from=mixed --format=markdown > docs/licenses-python.md pip-licenses --from=mixed --format=markdown > docs/licenses-python.md
``` ```
Команду запускать в воспроизводимом virtualenv, где установлены реальные Команду нужно выполнять в окружении, где установлены зависимости конкретного
runtime dependencies. release profile.
## 5. Что нужно закрыть перед подачей ## 5. Frontend, dashboards и browser tooling
1. Добавить root `LICENSE`. | Компонент | Роль | License-audit действие |
2. Добавить `NOTICE`, если это потребуется выбранными лицензиями. |---|---|---|
3. Сформировать полный SBOM. | Grafana dashboards JSON | Собственные dashboards DetMir | Входят в собственную поставку; проверить отсутствие embedded secrets/URLs. |
4. Проверить transitive dependencies. | ActivityWatch WebUI patches | Собственный overlay/patch слой | Учитывать MPL-2.0 границы ActivityWatch, если изменяются upstream файлы. |
5. Зафиксировать список компонентов, которые поставляются вместе с продуктом. | Playwright/browser smoke tooling | Проверки UI | Обычно dev/test dependency; не включать в runtime claim. |
6. Отделить компоненты, которые устанавливаются пользователем самостоятельно. | JavaScript snippets | WebUI patching/helper scripts | Проверить зависимости, если добавляются npm packages. |
7. Проверить отсутствие GPL/AGPL-компонентов, если выбранная модель поставки с
ними несовместима.
8. Подготовить публичный `THIRD_PARTY_NOTICES`.
## 6. Связанные документы ## 6. Компоненты с повышенным вниманием
- `docs/OWNERSHIP_RU.md` | Компонент | Причина внимания | Рекомендация |
- `docs/REGISTRY_CHECKLIST_RU.md` |---|---|---|
- `docs/DETMIR_RUSSIAN_SOFTWARE_REGISTRY_POSITIONING_RU.md` | Grafana OSS | AGPL-3.0 для современных версий | В реестровой поставке описывать как внешний компонент или проверить obligations. |
| Hayabusa | AGPLv3 + отдельная лицензия rules | Держать как optional offline module; не смешивать с закрытым ядром без аудита. |
| Ansible | GPL toolchain | Описывать как инструмент установки, не как linked library продукта. |
| OCR/Tesseract stack | Несколько уровней зависимостей | Фиксировать конкретные пакеты ОС и Python packages. |
| Python legacy paths | Могут выглядеть как ядро | В документации указывать, что Rust-first runtime является основным. |
## 7. Что поставляется вместе с продуктом
В публичной поставке могут присутствовать:
- исходный код собственных модулей;
- шаблоны конфигурации;
- Ansible playbooks;
- Grafana dashboards;
- Windows collectors scripts;
- install-kit archives как GitHub Release assets;
- документация.
Не должны поставляться в публичном git:
- production inventory;
- реальные домены/IP конкретного экземпляра;
- пароли и токены;
- runtime базы данных;
- customer evidence;
- локальная история разработки;
- случайные binary archives в корне репозитория.
## 8. Release checklist по лицензиям
Перед каждым публичным release:
1. Собрать Rust SBOM по `Cargo.lock`.
2. Выполнить `cargo deny check`.
3. Сформировать Rust license report.
4. Сформировать Python license report для включенных profiles.
5. Проверить Grafana/Hayabusa/Ansible как внешние компоненты.
6. Проверить, что root репозитория не содержит случайных архивов сборки.
7. Проверить отсутствие secrets, private inventory, customer paths.
8. Зафиксировать версию ActivityWatch и способ ее установки.
9. Зафиксировать, какие optional modules включены в релиз.
10. Сохранить отчеты в release artifacts или `docs/licenses-*`.
## 9. Источники для проверки upstream лицензий
- ActivityWatch repository/license: `https://github.com/ActivityWatch/activitywatch`
- Grafana licensing: `https://grafana.com/licensing/`
- Grafana repository/license: `https://github.com/grafana/grafana`
- Prometheus repository/license: `https://github.com/prometheus/prometheus`
- Hayabusa repository/license: `https://github.com/Yamato-Security/hayabusa`
- Ansible repository/license: `https://github.com/ansible/ansible`
Финальная версия документа должна ссылаться на конкретные версии компонентов,
использованные в release build.