229 lines
9.4 KiB
Markdown
229 lines
9.4 KiB
Markdown
# AWatch-rus Portal
|
|
|
|
## Назначение
|
|
|
|
Портал является рабочим кабинетом для трех ролей:
|
|
|
|
- руководитель: пульс организации, активность, подразделения, риски;
|
|
- ИБ: риск-сигналы, события безопасности, evidence;
|
|
- расследователь: карточка инцидента, причины, проверяемые источники, отчет.
|
|
|
|
## Главные экраны
|
|
|
|
- `Обзор` - Executive Dashboard.
|
|
- `Сотрудники` - карточки сотрудников и объяснение индекса.
|
|
- `Подразделения` - сравнение групп, тренды и ответственные.
|
|
- `Риски` - read-only контроль безопасности.
|
|
- `Расследования` - инциденты, evidence и автоматическая read-only карточка расследования.
|
|
- `Сетевой периметр` - read-only контекст внешних сетевых сигналов.
|
|
- `Отчеты` - Markdown/PDF/JSON и управленческий текст.
|
|
- `Настройки` - read-only параметры расчета.
|
|
|
|
## Executive Dashboard
|
|
|
|
Показывает:
|
|
|
|
- сотрудников в работе;
|
|
- средний индекс активности;
|
|
- WARN/FAIL подразделения;
|
|
- критические риски;
|
|
- недельный тренд;
|
|
- достоверность данных агента;
|
|
- топ-5 лучших и проблемных подразделений;
|
|
- Heat Map;
|
|
- блок `Требует внимания`.
|
|
|
|
## Достоверность данных агента
|
|
|
|
Портал показывает карточку `Достоверность данных агента` в `Обзор` и
|
|
`Отчеты`. Это управленческий вывод о том, можно ли использовать текущий
|
|
`Индекс активности` и отчеты как подтвержденный KPI.
|
|
|
|
API сохраняет старое поле `agent_quality` и дополнительно отдает
|
|
`agent_quality_explain`:
|
|
|
|
- `status`;
|
|
- `title`;
|
|
- `summary`;
|
|
- `recommendation`;
|
|
- `kpi_accepted`.
|
|
|
|
Цвета статусов:
|
|
|
|
- `OK` - зеленый, KPI подтвержден основным источником;
|
|
- `WARNING` - желтый, данные собраны резервным способом;
|
|
- `DEGRADED` - оранжевый, данные нельзя использовать как доказательный KPI;
|
|
- `UNKNOWN` - серый, агент не передал diagnostics.
|
|
|
|
Карточка сначала показывает управленческий вывод, принято ли значение в KPI, и
|
|
рекомендацию. Технические поля доступны в раскрываемом блоке:
|
|
|
|
- источник коллектора;
|
|
- всего сессий;
|
|
- активных сессий;
|
|
- RDP-сессий;
|
|
- ошибка коллектора, если она есть.
|
|
|
|
Если diagnostics отсутствует, статус `UNKNOWN`, рекомендация - обновить Rust
|
|
agent и проверить поступление telemetry JSONL. Если источник `local_fallback`,
|
|
портал прямо пишет: `Диагностический режим, данные не засчитываются в KPI`.
|
|
|
|
## Стабильность агента за 7 дней
|
|
|
|
Портал показывает мини-блок `Стабильность агента за 7 дней`. Он отвечает на
|
|
вопрос, можно ли доверять недельному KPI, а не только текущему срезу.
|
|
|
|
`GET /api/reports` отдает:
|
|
|
|
- `agent_quality_history` - последняя запись качества по каждому дню за
|
|
7-дневное окно;
|
|
- `agent_quality_history_summary` - сводка по дням.
|
|
|
|
Элемент `agent_quality_history` содержит:
|
|
|
|
- `date`;
|
|
- `status`;
|
|
- `source`;
|
|
- `kpi_accepted`;
|
|
- `collector_error`, если он есть.
|
|
|
|
Сводка считает:
|
|
|
|
- сколько дней были `OK`;
|
|
- сколько дней были `WARNING`, `DEGRADED` или `UNKNOWN`;
|
|
- процент дней, когда KPI был принят.
|
|
|
|
Если за 7 дней меньше 5 дней `OK`, портал и executive summary показывают:
|
|
`KPI требует валидации: нестабильный сбор данных агента`.
|
|
|
|
## Качество данных по рабочим местам
|
|
|
|
Портал показывает карточку `Качество данных по рабочим местам`. Она отвечает
|
|
на управленческий вопрос: какие узлы дают подтвержденные данные, а какие
|
|
снижают доверие к KPI.
|
|
|
|
`GET /api/reports` отдает:
|
|
|
|
- `agent_quality_nodes` - последняя запись качества по каждому
|
|
`hostname`, при его отсутствии по `machine_id`, иначе `unknown`;
|
|
- `agent_quality_nodes_summary` - сводка по узлам.
|
|
|
|
Элемент `agent_quality_nodes` содержит:
|
|
|
|
- `hostname`;
|
|
- `last_seen_utc`;
|
|
- `source`;
|
|
- `status`;
|
|
- `kpi_accepted`;
|
|
- `sessions_total`;
|
|
- `rdp_sessions`;
|
|
- `collector_error`, если он есть;
|
|
- `recommendation`.
|
|
|
|
Сводка содержит:
|
|
|
|
- `total_nodes`;
|
|
- `ok_nodes`;
|
|
- `degraded_nodes` - узлы в `WARNING` или `DEGRADED`;
|
|
- `unknown_nodes`;
|
|
- `accepted_kpi_nodes_pct`.
|
|
|
|
Если `accepted_kpi_nodes_pct < 80` и узлы есть, executive summary показывает:
|
|
`KPI требует проверки: менее 80% узлов дают подтвержденные данные`.
|
|
|
|
Главная страница не перегружается: показывается сводка и таблица максимум из
|
|
10 проблемных узлов. Источник `local_fallback` никогда не подтверждает KPI.
|
|
|
|
## SLA покрытия агентов
|
|
|
|
Портал показывает карточку `Покрытие агентов`. Она отвечает на вопрос,
|
|
насколько текущий `Индекс активности` репрезентативен по всему парку рабочих
|
|
мест.
|
|
|
|
Источник ожидаемого состава парка задается JSON-файлом:
|
|
|
|
- CLI/env: `--expected-nodes-path` или `DETMIR_PORTAL_EXPECTED_NODES_PATH`;
|
|
- default: `config/expected_nodes.json`;
|
|
- публичный пример: `config/expected_nodes.example.json`.
|
|
|
|
Формат:
|
|
|
|
```json
|
|
{
|
|
"nodes": [
|
|
{
|
|
"hostname": "HOST-EXAMPLE-001",
|
|
"department": "Бухгалтерия",
|
|
"owner": "OWNER-EXAMPLE",
|
|
"criticality": "normal"
|
|
}
|
|
]
|
|
}
|
|
```
|
|
|
|
`GET /api/reports` отдает `agent_coverage_sla`:
|
|
|
|
- `expected_nodes` - сколько рабочих мест ожидается по конфигу;
|
|
- `reporting_nodes_24h` - сколько узлов прислали свежую за 24 часа
|
|
телеметрию, принятую в KPI;
|
|
- `stale_nodes` - узлы есть в telemetry, но последняя запись старше 24 часов;
|
|
- `missing_nodes` - узлы из expected list не найдены в telemetry;
|
|
- `coverage_pct` - процент узлов, подтверждающих KPI;
|
|
- `freshness_pct` - процент узлов со свежей telemetry независимо от качества
|
|
источника;
|
|
- `sla_status` - `OK`, `WARNING`, `CRITICAL` или `UNKNOWN`;
|
|
- `problem_nodes` - максимум выводится в UI по 10 проблемным узлам.
|
|
|
|
Правила SLA:
|
|
|
|
- `coverage_pct >= 90%` - `OK`;
|
|
- `75-89%` - `WARNING`;
|
|
- `<75%` - `CRITICAL`;
|
|
- если expected list отсутствует или пустой - `UNKNOWN`.
|
|
|
|
Если статус `CRITICAL`, executive summary показывает:
|
|
`Покрытие агентов критически недостаточно: KPI не может считаться репрезентативным`.
|
|
|
|
Если статус `WARNING`, executive summary показывает:
|
|
`KPI требует проверки: часть рабочих мест не присылает свежую телеметрию`.
|
|
|
|
Источник `local_fallback` может повышать `freshness_pct`, если телеметрия
|
|
свежая, но не повышает `coverage_pct` и не засчитывается как подтвержденный
|
|
KPI.
|
|
|
|
## Risk -> Investigation
|
|
|
|
Кнопка `Открыть расследование` переводит пользователя в read-only карточку.
|
|
|
|
Карточка содержит:
|
|
|
|
- `incident_id`;
|
|
- `risk_id`;
|
|
- `department`;
|
|
- `owner`;
|
|
- `activity_index`;
|
|
- `deviation`;
|
|
- `status`;
|
|
- `summary`;
|
|
- `why_it_is_risk`;
|
|
- `what_to_check`;
|
|
- `recommended_actions`;
|
|
- `evidence`;
|
|
- `generated_at`.
|
|
|
|
Предупреждение обязательно:
|
|
|
|
```text
|
|
Расследование сформировано автоматически. Решение принимает ответственный сотрудник.
|
|
```
|
|
|
|
## Проверка
|
|
|
|
Smoke-тест:
|
|
|
|
```bash
|
|
node scripts/detmir-portal-tabs-smoke.mjs
|
|
```
|
|
|
|
Тест проверяет все вкладки, read-only настройки и переход Risk -> Investigation.
|