Skip to content

EXPERT_TEST_SCENARIO_RU.md

Latest commit

 

History

History
144 lines (102 loc) · 7.04 KB

EXPERT_TEST_SCENARIO_RU.md

File metadata and controls

144 lines (102 loc) · 7.04 KB
Raw

Сценарий экспертной проверки

Документ описывает короткий ручной сценарий проверки установленного экземпляра 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. Проверка базового статуса контура

Действия на сервере:

detmir-check --json
detmir-status --json
systemctl --failed --no-pager

Ожидаемый результат:

  • detmir-check возвращает JSON без критичных ошибок;
  • detmir-status показывает агрегированный статус установленного контура;
  • systemctl --failed не показывает критичных units 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. Сохранить диагностический минимум:
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;
  • экспортировать отчет;
  • закрыть или обработать тестовый инцидент без ручного вмешательства в БД.