awatch-rus/AWatch-rus

Fork 0

Files

T

igor04091968 05e9af02db docs+portal: polish architecture smoke and screenshot

2026-06-06 14:52:18 +03:00

15 KiB

Raw Blame History

AWatch-rus Portal

Назначение

Портал является рабочим кабинетом для трех ролей:

руководитель: пульс организации, активность, подразделения, риски;
ИБ: риск-сигналы, события безопасности, материалы проверки;
расследователь: карточка инцидента, причины, проверяемые источники, отчет.

Главные экраны

Обзор - сводка руководителя и главный вывод.
Сотрудники - карточки сотрудников и объяснение индекса.
Подразделения - сравнение групп, тренды и ответственные.
Риски - контроль безопасности только для чтения.
Расследования - инциденты, материалы проверки и автоматическая карточка расследования только для чтения.
Сетевой периметр - внешний сетевой контекст только для чтения.
Отчеты - текстовый отчет, печать/PDF, выгрузка данных и управленческий текст.
Настройки - параметры расчета только для чтения.

Ролевые представления

Во вкладке Обзор есть переключатель представления:

Руководитель - главный вывод, сводка руководителя, риски подразделений и карта рисков;
Безопасность - записи, которые требуют проверки, связь рисков и активности, агрегированные события безопасности за 24 часа, расследования, аудит решений и материалы расследования;
Эксплуатация - полнота данных, качество сбора, ошибки и телеметрия рабочих мест.

Переключатель не меняет модель данных и не создает новые API. Он только группирует существующие блоки портала под разные категории пользователей: директор, сотрудник безопасности и администратор эксплуатации.

События безопасности

Портал поддерживает необязательный источник агрегированных событий безопасности из ClickHouse. По умолчанию он выключен и не влияет на работу портала.

Если источник включен, портал показывает только сводные числа за 24 часа: общее количество событий, неуспешные и подозрительные входы, RDP-сессии, изменения учетных записей, ошибки агентов и топ подразделений. Сырые журналы и SIEM-представление не выводятся.

Подробности настройки: 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.

Формат:

{
  "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 и не засчитывается как подтвержденные показатели.

Переход от риска к расследованию

Кнопка Открыть расследование переводит пользователя в карточку только для чтения.

Карточка содержит:

номер;
риск;
подразделение;
ответственного;
индекс активности;
отклонение;
статус;
краткое описание;
почему это риск;
что проверить;
рекомендуемые действия;
материалы расследования;
дату формирования.

Предупреждение обязательно:

Расследование сформировано автоматически. Решение принимает ответственный сотрудник.

Проверка

Smoke-тест:

node scripts/detmir-portal-tabs-smoke.mjs

Тест проверяет все вкладки, настройки только для чтения и переход от риска к расследованию.

Проверка страницы архитектуры и CSS:

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.

15 KiB Raw Blame History