安全问题处理

概述 —— 这个页面做什么

安全 ▸ 问题处理 把安全事件与入侵响应作为一块统一的案例看板来管理，流水线共五个阶段：

open → investigating → cause_identified → resolved → closed

每个案例都带有**「500 报告」结构**（直接原因／根本原因／解决措施／防范行动）和一条可审计的时间线。本页面是 服务 ▸ 问题处理 控制器的镜像：两者共用同一张 infr_incident 表，但本页面按 area='security' 过滤，从而把安全案例与服务事件分开。

案例进入这块看板有两条途径：

1. 手动登记 —— 由运维人员创建案例。可选的 source：manual · agency · quarantine。
2. 诊断升级 —— 安全诊断 中 fail + crit 的发现会被自动升级为案例（source=detection）。这是仅由系统写入的 source，操作人员无法手动选择。

本控制台不会直接操作远端的 crontab 或防火墙。它是一个记录并跟踪人工响应过程的工作流工具。真正的封禁／隔离动作在 封禁列表 和 自动封禁 中执行。

什么时候用

• 把 IDS／AI 检测（威胁、检测 · JA3）中已确认的入侵嫌疑，升级为带有调查与解决记录的正式案例。
• 跟踪 agency（CERT、执法机关）的协查请求或入侵通报。
• 管理处于 quarantine（隔离）状态的主机，直至恢复并重新投入使用。
• 接收 安全诊断 标记为 fail+crit 的加固／rootkit 风险作为自动创建的案例，并指派后续处理人。
• 事后计算 MTTR 与累计停机时长，并记录直接原因、根本原因与防范行动。

页面布局

KPI 条

案例看板

案例按以下顺序排序：

1. 状态排序 —— open → investigating → cause_identified → resolved → closed
2. 严重程度排序 —— crit → warn → info
3. 最新优先 —— id 降序

每张卡片显示标题、严重程度、状态、source 徽标、关联的项目／服务、发生时间、停机时长以及事件条数。

详情弹窗

打开一个案例后，会分为左右两栏：

• 报告 —— 摘要、直接原因、根本原因、解决措施、防范行动等字段。
• 时间线 —— 按时间先后展示 infr_incident_event 的历史（创建、备注、状态变更……）。

点击顶部的状态流水线会打开阶段迁移对话框，其中给出「本阶段该做什么」的指引，并允许就地更新该阶段的报告字段。

使用方法

创建案例（手动）

1. 点击顶部的 ［登记案例］。
2. 填写标题（必填）、严重程度和 source（manual ／ agency ／ quarantine）。
3. 可选填写项目、服务、URL、发生时间、影响范围、停机时长（分钟）。
4. ［保存］ —— 以 status=open、area=security、detected_at=now() 创建新案例，并向时间线写入一条 created 事件。

source 列表中没有 detection —— 它是仅由系统写入的 source，由安全诊断自动生成。

状态迁移（流水线）

在详情弹窗的流水线上点击目标状态。各阶段建议开展的工作如下：

服务端的迁移规则：

• 迁移到 resolved 时，若 resolved_at 为空，则用 now() 填充。
• 迁移到 closed 时，如果对话框中填写了关闭时间，就采用该值；未填写时，仅在尚无值的情况下默认取 now()。
• 状态确实发生变化时，会向时间线写入一条 status_change（from→to）事件；若同时填写了备注，还会追加一条 note 事件。

协作备注

在详情弹窗中添加备注，会在时间线上记录一条 kind=note 事件。系统没有单独的备注表 —— 备注统一并入 infr_incident_event。

删除

删除案例时会同时删除其 infr_incident_event 记录，并写入审计日志。（升级来源的那次诊断扫描是独立的，不会被删除。）

升级案例的自动解决

当 安全诊断 接收到一次探针结果时，DiagnosticsService::reconcileCases() 会按主机逐一核对案例：

• 出现 fail + crit 的发现 → 以 fingerprint 为键 upsert 一条未结案例（重复出现时递增 occurrence_count）。
• 后续扫描中该项通过／消失 → 未结案例被自动解决（status=resolved、resolved_at、resolution=auto-resolved text），并追加一条 status_change 时间线事件。

自动解决只在对应的诊断检查再次通过时才会触发。手动创建的案例（manual／agency／quarantine）永远不会被自动解决 —— 必须由操作人员沿流水线推进。

数据来源

数据表

枚举值

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 结构）

API 端点

访问权限

• 读取：整个安全分组由 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。迁移会在 meta 中保存 {from,to}，保存则记录 {title,severity}。参见 审计日志。

故障排查与常见问题

Q. 在服务看板上看到的案例，这里却没有。 两块看板共用同一张 infr_incident 表，但按 area 划分。本页面只显示 area='security'。服务事件请到 服务 ▸ 问题处理 中查找。

Q. 我无法用 detection 这个 source 创建案例。 这是预期行为。detection 是仅由系统写入的 source，由 安全诊断 从 fail+crit 的发现中自动创建。手动登记只提供 manual、agency、quarantine。

Q. 一个自动升级的案例自己变成了已解决。 当后续扫描中对应的诊断检查通过时，reconcileCases() 会自动解决这条未结案例：resolution 会被填入自动解决说明文本，并追加一条状态变更事件。

Q. MTTR 是空的。 MTTR 只针对同时具有 occurred_at 与 resolved_at 的案例计算。没有发生时间、或尚未解决的案例都会被排除。

Q. 可以把关闭时间设成过去的时刻吗？ 可以。在关闭对话框的关闭时间字段中填入数值（与发生时间是同一种输入界面），系统会原样保存。留空时，服务端仅在尚无值的情况下才填入 now()。

Q. 删除案例会连同它的诊断扫描一起删掉吗？ 不会。升级而来的案例与作为其来源的诊断扫描相互独立。删除案例只会移除与之关联的时间线事件。

相关内容

• 安全诊断 —— 把 fail+crit 的发现自动升级到本看板的来源。
• 服务问题处理 —— 同一套工作流在服务侧（area='service'）的镜像。
• 安全概览 —— 威胁 → 检测 → 响应的防御漏斗叙事。
• 威胁 · 检测 · JA3 —— 可升级为案例的入侵候选来源。
• 审计日志 —— 案例写入操作的持久记录。