145 lines
7.0 KiB
Markdown
145 lines
7.0 KiB
Markdown
# Сценарий экспертной проверки
|
||
|
||
Документ описывает короткий ручной сценарий проверки установленного экземпляра
|
||
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 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;
|
||
- экспортировать отчет;
|
||
- закрыть или обработать тестовый инцидент без ручного вмешательства в БД.
|