docs(registry): add expert test scenario

2026-06-03 09:27:08 +03:00
parent 5598894717
commit e94174a89c
3 changed files with 146 additions and 0 deletions
@@ -50,6 +50,7 @@ runtime, OCR/content-analysis, 1C/AI/ETL integration и MCP/dev helpers. Эти
 - [Сведения для подачи в реестр](REGISTER_RU_SOFTWARE.md)
 - [Описание продукта](PRODUCT_DESCRIPTION_RU.md)
 - [Установка для эксперта](INSTALL_FOR_EXPERT_RU.md)
+- [Сценарий экспертной проверки](docs/EXPERT_TEST_SCENARIO_RU.md)
 - [Сторонние компоненты](THIRD_PARTY_COMPONENTS.md)
 - [Сторонние лицензии](THIRD_PARTY_LICENSES_RU.md)
 - [Архитектура](docs/ARCHITECTURE_RU.md)
@@ -297,6 +297,7 @@ stale/dead buckets для обязательных источников.

 - `PRODUCT_DESCRIPTION_RU.md` - краткое описание продукта.
 - `INSTALL_FOR_EXPERT_RU.md` - короткая инструкция установки экземпляра.
+- `docs/EXPERT_TEST_SCENARIO_RU.md` - ручной сценарий экспертной проверки после установки.
 - `THIRD_PARTY_COMPONENTS.md` - обзор сторонних компонентов.
 - `THIRD_PARTY_LICENSES_RU.md` - лицензии и license-audit checklist.
 - `docs/ARCHITECTURE_RU.md` - архитектура.
@@ -0,0 +1,144 @@
+# Сценарий экспертной проверки
+
+Документ описывает короткий ручной сценарий проверки установленного экземпляра
+DetMir/AWatch-rus. Он рассчитан на чистый тестовый стенд после установки по
+`docs/INSTALL_FOR_EXPERT_RU.md`.
+
+## Предусловия
+
+- серверный экземпляр установлен и запущен;
+- доступен операторский web UI или gateway URL тестового стенда;
+- доступен тестовый Windows endpoint с установленными collectors;
+- задан тестовый пользователь, например `HOST-EXAMPLE\user1`;
+- Grafana/отчеты включены, если они входят в проверяемый состав поставки;
+- используются только тестовые файлы и тестовые данные.
+
+## 1. Вход в web-интерфейс
+
+Действия:
+
+1. Открыть операторский портал по URL тестового стенда.
+2. Войти под тестовой учетной записью администратора или оператора.
+3. Открыть карточки ActivityWatch, Инциденты ИБ, отчеты и Grafana.
+
+Ожидаемый результат:
+
+- портал открывается без ошибки `500/502/503`;
+- карточки не ведут на личные адреса разработчика;
+- ссылки используют адреса тестового стенда;
+- Grafana/ActivityWatch доступны через опубликованные переходы.
+
+## 2. Проверка базового статуса контура
+
+Действия на сервере:
+
+```bash
+detmir-check --json
+detmir-status --json
+systemctl --failed --no-pager
+```
+
+Ожидаемый результат:
+
+- `detmir-check` возвращает JSON без критичных ошибок;
+- `detmir-status` показывает агрегированный статус установленного контура;
+- `systemctl --failed` не показывает критичных units DetMir/AWatch-rus.
+
+## 3. Проверка clipboard/USB/print сигналов
+
+Действия на тестовом Windows endpoint:
+
+1. Скопировать тестовую строку в clipboard.
+2. Подключить тестовый USB-носитель или выполнить имитацию USB-события,
+   предусмотренную стендом.
+3. Отправить тестовый документ на тестовый printer/PDF-printer.
+
+Ожидаемый результат:
+
+- в ActivityWatch появляются события endpoint/file operations;
+- в операторском портале или Grafana видны новые сигналы по тестовому host;
+- события содержат тестовые metadata и не содержат секретов стенда.
+
+## 4. Генерация DLP-инцидента
+
+Действия:
+
+1. Создать тестовый файл с явно тестовой строкой, например:
+   `TEST_PERSONAL_DATA_SNILS_112-233-445-95`.
+2. Выполнить действие, которое на стенде контролируется DLP policy:
+   копирование, перемещение, печать или другой включенный канал.
+3. Дождаться обработки collector/server-side pipeline.
+
+Ожидаемый результат:
+
+- создается DLP-инцидент тестового типа;
+- инцидент привязан к тестовому host/user;
+- severity и policy/rule отображаются в карточке инцидента;
+- инцидент не требует ручного редактирования SQLite или логов.
+
+## 5. Просмотр case и evidence
+
+Действия:
+
+1. Открыть раздел `Инциденты ИБ`.
+2. Найти созданный тестовый инцидент.
+3. Открыть case detail.
+4. Проверить evidence: screenshot, metadata, checksum или ссылку на артефакт,
+   если evidence collection включен на стенде.
+5. Отметить инцидент как просмотренный тестовым оператором.
+
+Ожидаемый результат:
+
+- case открывается из web UI;
+- evidence доступно только через портал/API, а не через произвольный raw path;
+- просмотр evidence фиксируется в audit trail или журнале case;
+- checksum/metadata отображаются без раскрытия локальных приватных путей.
+
+## 6. Экспорт отчета
+
+Действия:
+
+1. Открыть отчет по DLP/инцидентам или worktime management report.
+2. Выбрать тестовый период, включающий созданный инцидент.
+3. Экспортировать отчет в доступном формате стенда: HTML, CSV, JSON или PDF.
+
+Ожидаемый результат:
+
+- отчет формируется без ошибки;
+- тестовый инцидент присутствует в отчете;
+- отчет содержит дату, host/user, policy/rule, статус case и ссылку/идентификатор
+  evidence;
+- экспорт не содержит секретов, приватных токенов и внутренних путей оператора.
+
+## 7. Завершение теста
+
+Действия:
+
+1. Пометить тестовый case как `closed`, `resolved` или аналогичный статус,
+   если workflow стенда это поддерживает.
+2. Повторно открыть список инцидентов и убедиться, что статус изменился.
+3. Сохранить диагностический минимум:
+
+```bash
+detmir-check --json > expert-detmir-check.json
+detmir-status --json > expert-detmir-status.json
+```
+
+Ожидаемый результат:
+
+- статус case обновлен;
+- повторный `detmir-check` не показывает новых критичных ошибок;
+- эксперт может приложить JSON-выводы и экспортированный отчет к протоколу
+  проверки.
+
+## Критерий прохождения
+
+Сценарий считается пройденным, если эксперт смог:
+
+- войти в web-интерфейс;
+- увидеть состояние контура;
+- получить тестовый endpoint/DLP signal;
+- открыть DLP case;
+- просмотреть evidence;
+- экспортировать отчет;
+- закрыть или обработать тестовый инцидент без ручного вмешательства в БД.