Files
AWatch-rus/docs/PORTAL_RU.md
T

303 lines
15 KiB
Markdown

# AWatch-rus Portal
## Назначение
Портал является рабочим кабинетом для трех ролей:
- руководитель: пульс организации, активность, подразделения, риски;
- ИБ: риск-сигналы, события безопасности, материалы проверки;
- расследователь: карточка инцидента, причины, проверяемые источники, отчет.
## Главные экраны
- `Обзор` - сводка руководителя и главный вывод.
- `Сотрудники` - карточки сотрудников и объяснение индекса.
- `Подразделения` - сравнение групп, тренды и ответственные.
- `Риски` - контроль безопасности только для чтения.
- `Расследования` - инциденты, материалы проверки и автоматическая карточка расследования только для чтения.
- `Сетевой периметр` - внешний сетевой контекст только для чтения.
- `Отчеты` - текстовый отчет, печать/PDF, выгрузка данных и управленческий текст.
- `Настройки` - параметры расчета только для чтения.
## Ролевые представления
Во вкладке `Обзор` есть переключатель представления:
- `Руководитель` - главный вывод, сводка руководителя, риски подразделений и
карта рисков;
- `Безопасность` - записи, которые требуют проверки, связь рисков и
активности, агрегированные события безопасности за 24 часа, расследования,
аудит решений и материалы расследования;
- `Эксплуатация` - полнота данных, качество сбора, ошибки и телеметрия рабочих
мест.
Переключатель не меняет модель данных и не создает новые API. Он только
группирует существующие блоки портала под разные категории пользователей:
директор, сотрудник безопасности и администратор эксплуатации.
## События безопасности
Портал поддерживает необязательный источник агрегированных событий безопасности
из ClickHouse. По умолчанию он выключен и не влияет на работу портала.
Если источник включен, портал показывает только сводные числа за 24 часа:
общее количество событий, неуспешные и подозрительные входы, RDP-сессии,
изменения учетных записей, ошибки агентов и топ подразделений. Сырые журналы и
SIEM-представление не выводятся.
Подробности настройки: [SECURITY_EVENTS_CLICKHOUSE_RU.md](SECURITY_EVENTS_CLICKHOUSE_RU.md).
## Загрузка и актуальность данных
В верхней части портала есть глобальная полоса `Загрузка и актуальность
данных`. Она показывает, что сейчас происходит с данными, и не смешивает
состояния `нет данных` и `данные еще загружаются`.
Видимые статусы:
- `Загрузка данных` - портал получает данные и готовит экран;
- `Данные готовы` - данные успешно загружены и экран актуален;
- `Данные отсутствуют` - источники ответили, но полезных записей для выбранного
раздела или периода нет;
- `Данные устарели` - показаны ранее загруженные данные, новое фоновое
обновление не завершилось;
- `Ошибка получения данных` - первичная загрузка не удалась, актуальных данных
на экране нет.
Этапы прогресса:
- `Получение данных`;
- `Расчёт показателей`;
- `Формирование главного вывода`;
- `Подготовка разделов`.
Во время загрузки портал показывает заготовки карточек и текст `Загрузка
данных`; пустые таблицы и сообщения `Нет данных` не выводятся до завершения
загрузки. После успешного обновления отображается время последнего обновления.
При состоянии `Данные устарели` старый экран остается доступным, но сверху
появляется предупреждение о неудачном обновлении.
## Сводка руководителя
Показывает:
- сотрудников в работе;
- средний индекс активности;
- WARN/FAIL подразделения;
- критические риски;
- недельный тренд;
- качество данных;
- топ-5 лучших и проблемных подразделений;
- карту рисков;
- блок `Требует внимания`.
## Качество данных
Портал показывает карточку `Качество данных` в `Обзор` и
`Отчеты`. Это управленческий вывод о том, можно ли использовать текущий
`Индекс активности` и отчеты как подтвержденные показатели.
API сохраняет старое поле `agent_quality` и дополнительно отдает
`agent_quality_explain`:
- `status`;
- `title`;
- `summary`;
- `recommendation`;
- `kpi_accepted` - участвуют ли данные в показателях.
Цвета статусов:
- `OK` - зеленый, показатели подтверждены основным источником;
- `WARNING` - желтый, данные собраны резервным способом;
- `DEGRADED` - оранжевый, данные нельзя использовать как доказательные показатели;
- `UNKNOWN` - серый, агент не передал диагностику качества.
Карточка сначала показывает управленческий вывод, участвуют ли данные в показателях, и
рекомендацию. Технические поля доступны в раскрываемом блоке:
- источник коллектора;
- всего сессий;
- активных сессий;
- удаленных сеансов;
- ошибка коллектора, если она есть.
Если диагностика отсутствует, статус `UNKNOWN`, рекомендация - обновить Rust
agent и проверить поступление telemetry JSONL. Если источник `local_fallback`,
портал прямо пишет: `Диагностический режим, данные не засчитываются в показатели активности`.
## Стабильность агента за 7 дней
Портал показывает мини-блок `Стабильность агента за 7 дней`. Он отвечает на
вопрос, можно ли доверять недельным показателям, а не только текущему срезу.
`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`;
- процент дней, когда показатели были подтверждены.
Если за 7 дней меньше 5 дней `OK`, портал и краткий вывод показывают:
`Показатели требуют проверки: нестабильный сбор данных агента`.
## Качество данных по рабочим местам
Портал показывает карточку `Качество данных по рабочим местам`. Она отвечает
на управленческий вопрос: какие узлы дают подтвержденные данные, а какие
снижают доверие к показателям.
`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` и узлы есть, краткий вывод показывает:
`Показатели требуют проверки: менее 80% рабочих мест дают подтвержденные данные`.
Главная страница не перегружается: показывается сводка и таблица максимум из
10 проблемных узлов. Источник `local_fallback` никогда не подтверждает показатели.
## Полнота данных
Портал показывает карточку `Полнота данных`. Она отвечает на вопрос,
насколько текущий `Индекс активности` репрезентативен по всему парку рабочих
мест.
Источник ожидаемого состава парка задается 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 часа
телеметрию, принятую в показатели;
- `stale_nodes` - узлы есть в telemetry, но последняя запись старше 24 часов;
- `missing_nodes` - узлы из expected list не найдены в telemetry;
- `coverage_pct` - процент узлов, подтверждающих показатели;
- `freshness_pct` - процент узлов со свежей telemetry независимо от качества
источника;
- `sla_status` - статус полноты данных: `OK`, `WARNING`, `CRITICAL` или `UNKNOWN`;
- `problem_nodes` - максимум выводится в UI по 10 проблемным узлам.
Правила полноты данных:
- `coverage_pct >= 90%` - `OK`;
- `75-89%` - `WARNING`;
- `<75%` - `CRITICAL`;
- если expected list отсутствует или пустой - `UNKNOWN`.
Если статус `CRITICAL`, краткий вывод показывает:
`Полнота данных критически недостаточна: показатели нельзя считать репрезентативными`.
Если статус `WARNING`, краткий вывод показывает:
`Показатели требуют проверки: часть рабочих мест не присылает свежую телеметрию`.
Источник `local_fallback` может повышать `freshness_pct`, если телеметрия
свежая, но не повышает `coverage_pct` и не засчитывается как подтвержденные
показатели.
## Переход от риска к расследованию
Кнопка `Открыть расследование` переводит пользователя в карточку только для чтения.
Карточка содержит:
- номер;
- риск;
- подразделение;
- ответственного;
- индекс активности;
- отклонение;
- статус;
- краткое описание;
- почему это риск;
- что проверить;
- рекомендуемые действия;
- материалы расследования;
- дату формирования.
Предупреждение обязательно:
```text
Расследование сформировано автоматически. Решение принимает ответственный сотрудник.
```
## Проверка
Smoke-тест:
```bash
node scripts/detmir-portal-tabs-smoke.mjs
```
Тест проверяет все вкладки, настройки только для чтения и переход от риска к расследованию.
Проверка страницы архитектуры и CSS:
```bash
DETMIR_PORTAL_SMOKE_URL=http://127.0.0.1:8720/portal/ node scripts/detmir-portal-tabs-smoke.mjs
curl -fsS http://127.0.0.1:8720/portal/architecture | grep -E 'Rust Agent|PowerShell Provider|implemented|planned|future'
rg -n '[0-9]+ (px|fr|rem|em|%)' adk-rust/crates/detmir-portal/src/static/app.css || true
```
Ожидаемый результат:
- `/portal/architecture` возвращает `200`;
- страница содержит `Rust Agent`, `PowerShell Provider`, `implemented`,
`planned`, `future`;
- команда `rg` не находит разорванные CSS-единицы вида `1 px`, `8 px`,
`1 fr`.