Files
AWatch-rus/docs/PORTAL_RU.md
T

11 KiB

AWatch-rus Portal

Назначение

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

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

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

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

Загрузка и актуальность данных

В верхней части портала есть глобальная полоса Data Loading & Refresh Status. Она показывает, что сейчас происходит с данными, и не смешивает состояния нет данных и данные еще загружаются.

Статусы:

  • LOADING - портал загружает сводку, отчеты или выбранный раздел;
  • READY - данные успешно загружены и экран актуален;
  • EMPTY - источники ответили, но полезных записей для выбранного раздела или периода нет;
  • STALE - показаны ранее загруженные данные, новое фоновое обновление не завершилось;
  • ERROR - первичная загрузка не удалась, актуальных данных на экране нет.

Во время LOADING портал показывает skeleton placeholders и текст Данные загружаются; пустые таблицы и сообщения Нет данных не выводятся до завершения загрузки. После успешного обновления отображается время последнего обновления. При STALE старый экран остается доступным, но сверху появляется предупреждение о неудачном обновлении.

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.

Формат:

{
  "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.

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

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

Проверка

Smoke-тест:

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

Тест проверяет все вкладки, read-only настройки и переход Risk -> Investigation.