Решение проблем безопасности — Руководство InfraGuard

Обзор — что делает этот экран

Безопасность ▸ Решение проблем ведёт реагирование на инциденты безопасности и компрометации как единую доску обращений с конвейером из пяти стадий:

open → investigating → cause_identified → resolved → closed

Каждое обращение несёт структуру отчёта 500 (прямая причина / коренная причина / решение / предупреждающие меры) и пригодную для аудита хронологию. Этот экран зеркалит контроллер Сервис ▸ Решение проблем: он использует ту же таблицу infr_incident, но фильтрует по area='security', чтобы обращения по безопасности не смешивались с сервисными инцидентами.

Обращения попадают на эту доску двумя путями:

Ручное заведение — оператор создаёт обращение. Доступные для выбора источники: manual · agency · quarantine.
Повышение из диагностики — находки fail + crit из Диагностики безопасности автоматически повышаются до обращений (source=detection). Это чисто системный источник, который оператор не может выбрать вручную.

Эта консоль не трогает удалённый crontab и межсетевые экраны напрямую. Это рабочий инструмент, который фиксирует и отслеживает процесс реагирования, выполняемый людьми. Собственно блокировка и помещение в карантин выполняются в разделах Блок-лист и Автоблокировка.

Когда использовать

Чтобы повысить подтверждённое подозрение на компрометацию, полученное от IDS/ИИ-обнаружения (Угрозы, Обнаружения · ИИ JA3), до формального обращения со следом расследования и решения.
Чтобы отслеживать запросы о взаимодействии или уведомления о компрометации от agency (CERT, правоохранительные органы).
Чтобы вести узел от quarantine через восстановление до повторного ввода в эксплуатацию.
Чтобы получать риски укрепления и руткитов, отмеченные Диагностикой безопасности как fail+crit, в виде автоматически созданных обращений и назначать по ним ответственных.
Чтобы постфактум вычислять MTTR и суммарный простой, а также документировать прямые и коренные причины вместе с предупреждающими мерами.

Структура экрана

Полоса KPI

KPI	Определение
total	Общее число обращений с `area='security'`
active	Сумма `open + investigating + cause_identified`
resolved	Сумма `resolved + closed`
MTTR	Среднее число минут по обращениям, у которых есть и `occurred_at`, и `resolved_at`
downtime	Сумма `downtime_min` по всем обращениям
uptime target	`OpsPolicy::slaDefaults()['uptime_target']`

Доска обращений

Обращения сортируются по:

Рангу статуса — open → investigating → cause_identified → resolved → closed
Рангу серьёзности — crit → warn → info
Свежести — по убыванию id

На каждой карточке видны заголовок, серьёзность, статус, значок источника, связанный проект или сервис, время возникновения, простой и число событий.

Окно подробностей

При открытии обращения окно делится на две панели:

Отчёт — поля сводки, прямой причины, коренной причины, решения и предупреждающих мер.
Хронология — история из infr_incident_event (создание, заметка, смена статуса, …) в хронологическом порядке.

Щелчок по конвейеру статусов сверху открывает диалог перехода между стадиями: он показывает подсказку «что делать на этой стадии» и позволяет прямо там обновить поля отчёта, относящиеся к ней.

Как пользоваться

Создать обращение (вручную)

Нажмите [Завести обращение] вверху экрана.
Введите заголовок (обязательно), серьёзность и источник (manual / agency / quarantine).
При необходимости укажите проект, сервис, URL, время возникновения, влияние и простой (в минутах).
[Сохранить] — создаётся новое обращение со значениями status=open, area=security, detected_at=now(), а в хронологию записывается событие created.

detection не предлагается в списке источников — это чисто системный источник, который Диагностика безопасности создаёт автоматически.

Переходы статуса (конвейер)

Щёлкните нужный статус в конвейере окна подробностей. Рекомендуемая работа на каждой стадии:

Стадия	Что делать на этой стадии
open	Вернуть обращение в приём (до начала анализа)
investigating	Подтвердить симптомы, оценить влияние, написать сводку
cause_identified	Определить и зафиксировать прямую причину и фоновую (коренную) причину
resolved	Зафиксировать способ восстановления и предупреждающие меры
closed	Убедиться, что меры и профилактика выполнены, и закрыть обращение

Правила перехода на стороне сервера:

При переходе в resolved поле resolved_at заполняется значением now(), если оно было пустым.
При переходе в closed используется время закрытия, указанное в диалоге, если оно задано; иначе по умолчанию берётся now(), но лишь когда значения ещё нет.
Когда статус действительно меняется, в хронологию записывается событие status_change (from→to); если при этом добавлена заметка, создаётся ещё и событие note.

Заметки для совместной работы

Добавление заметки в окне подробностей записывает в хронологию событие kind=note. Отдельной таблицы заметок нет — заметки сведены в infr_incident_event.

Удаление

Удаление обращения удаляет и его строки в infr_incident_event и записывается в журнал аудита. (Исходное диагностическое сканирование, стоящее за повышенным обращением, независимо и не удаляется.)

Автоматическое решение повышенных обращений

Когда Диагностика безопасности принимает результат зонда, DiagnosticsService::reconcileCases() сверяет обращения по каждому узлу:

Находка fail + crit → выполняется upsert открытого обращения по ключу fingerprint (повторное появление увеличивает occurrence_count).
Когда более позднее сканирование проходит эту проверку либо пункт исчезает → открытое обращение решается автоматически (status=resolved, resolved_at, resolution=auto-resolved text) с добавлением события status_change в хронологию.

Автоматическое решение срабатывает только тогда, когда диагностическая проверка снова проходит. Обращения, созданные вручную (manual/agency/quarantine), никогда не решаются автоматически — оператор обязан провести их по конвейеру сам.

Источники данных

Таблицы

Таблица	Роль
`infr_incident`	Тело обращения (с фильтром `area='security'`). Статус, серьёзность, источник, поля отчёта 500, время возникновения/решения/закрытия, `fingerprint`, `occurrence_count`
`infr_incident_event`	Хронология обращения (создание, заметка, смена статуса, …)
`infr_project`	Список проектов для привязки
`infr_service`	Список сервисов для привязки

Перечисления

STATUSES   = [open, investigating, cause_identified, resolved, closed]
SEVERITIES = [info, warn, crit]
SOURCES    = [manual, pulse, alert, agency, quarantine, detection]   # все
manual-selectable sources = [manual, agency, quarantine]
OPEN_STATUSES (dedup targets) = [open, investigating, cause_identified]
AREAS = [service, security]   # ось разделения общей таблицы

Поля отчёта (структура 500)

Поле	Значение
`summary`	Сводка симптома и влияния
`direct_cause`	Непосредственная причина (например, MySQL Too many connections)
`root_cause`	Фоновая / коренная причина (например, утечка соединений в скрипте)
`resolution`	Восстановление, применённое во время инцидента
`action_taken`	Предупреждающие меры на будущее
`downtime_min`	Простой (в минутах) — источник KPI downtime
`impact`	Затронутый охват

Точки API

Метод · путь	Назначение
`GET /security/resolution`	Первичная отрисовка доски
`GET /security/resolution/live`	Обновление опросом (обращения, KPI, метка времени)
`POST /security/resolution/save`	Создание / обновление обращения
`POST /security/resolution/transition`	Переход статуса (+ необязательная заметка / обновление отчёта)
`POST /security/resolution/note`	Добавление заметки для совместной работы
`POST /security/resolution/delete`	Удаление обращения

Доступ

Чтение: вся группа «Безопасность» защищена посредником infr.level:2. Войти могут только пользователи уровня 2 и выше (staff=5 · admin=10); демо (1) блокируется.
Запись (сохранение/переход/заметка/удаление): метод контроллера canWrite() заново проверяет infr_user_level >= 2 в сессии. Ниже этого уровня возвращается 403 (resolution.err.forbidden).
Аудит: каждая запись фиксируется в infr_audit_log — sec.incident_create · sec.incident_update · sec.incident_transition · sec.incident_delete. Переходы сохраняют в метаданных {from,to}, а сохранения — {title,severity}. См. Журнал аудита.

Диагностика неполадок и частые вопросы

В. Обращение, которое я вижу на сервисной доске, здесь отсутствует. Обе доски используют одну и ту же таблицу infr_incident, но разделяются по area. Этот экран показывает только area='security'. Сервисные инциденты ищите в разделе Сервис ▸ Решение проблем.

В. У меня не получается создать обращение с источником detection. Так и задумано. detection — чисто системный источник, который Диагностика безопасности создаёт автоматически из находок fail+crit. При ручном заведении доступны только manual, agency и quarantine.

В. Автоматически повышенное обращение само перешло в решённые. Когда лежащая в его основе диагностическая проверка проходит при более позднем сканировании, reconcileCases() автоматически решает открытое обращение: поле resolution заполняется текстом об автоматическом решении, а в хронологию добавляется событие смены статуса.

В. MTTR пустой. MTTR рассчитывается только для обращений, у которых есть одновременно occurred_at и resolved_at. Обращения без времени возникновения или ещё не решённые исключаются.

В. Можно ли задать время закрытия задним числом? Да. Введите значение в поле время закрытия диалога закрытия (тот же интерфейс, что и у времени возникновения) — оно сохранится как есть. Если оставить поле пустым, сервер подставит now() только при условии, что значения ещё нет.

В. Удаляет ли удаление обращения его диагностическое сканирование? Нет. Повышенное обращение и породившее его диагностическое сканирование независимы. При удалении обращения исчезают только связанные с ним события хронологии.

Связанные материалы

Диагностика безопасности — источник, который автоматически повышает находки fail+crit на эту доску.
Решение проблем сервиса — зеркало того же процесса на стороне сервиса (area='service').
Обзор безопасности — повествование о воронке защиты угроза → обнаружение → реагирование.
Угрозы · Обнаружения · ИИ JA3 — источники кандидатов на компрометацию, которых повышают до обращений.
Журнал аудита — постоянная летопись изменяющих операций над обращениями.