6.3 漏洞管理与配置合规

6.3 漏洞管理与配置合规

本节摘要：漏洞管理与配置合规是运营域的"日常保洁"：单点看都是小事，堆积起来就是下一次事件的全部条件。本节讲漏洞的优先级排序与修复时限怎么定、云上"配置漂移"为什么需要机器对抗、以及合规检查如何从年度大考变成每日体检。

漏洞清单不是任务清单

每个环境都有漏洞扫描器吐出的成百上千条发现。把它们直接扔给运维当任务清单，是这个领域最经典的失败模式：运维修不过来，开始按扫描器的严重度标签机械处理，真正危险的漏洞和鸡毛蒜皮的发现排在同一个队列里慢慢腐烂。漏洞管理的第一课是排序不是按漏洞本身，而是按漏洞与你环境的组合。

排序要叠加三个维度。可达性：这个漏洞暴露在哪个网络位置——公网可达的远程执行与内网深处的库漏洞，严重度标签相同、风险天差地别。资产价值：承载什么数据、什么业务（第三章的分类分级在此直接复用）。利用现状：是否已有公开利用代码、是否正被在野利用——有在野利用的漏洞，时限要压缩到"天"甚至"小时"。

修复时限的制定是安全与业务的谈判结果，但必须有硬底线。一套常见的四档节奏：在野利用且公网可达，二十四到四十八小时；高危且可达，一周；高危不可达或中危可达，一月；其余按季度批次。底线条款：任何时限到期未修的，升级到部门负责人签字延期——时限的意义就在"过期要解释"，无升级机制的时限只是日历装饰。

会话推演：一轮漏洞的分级处置

# 扫描结果按三维叠加排序（示意）
$ vuln-mgr triage --this-week
  [P0] 对外网关组件远程执行  在野利用中   公网可达  资产=核心交易
       → 时限24h · 热补丁或WAF虚拟补丁先行 · 每日跟踪
  [P1] 数据库中间件提权      有利用代码   仅内网    资产=核心数据
       → 时限7d · 优先收紧访问来源 · 补丁随维护窗口
  [P2] 应用框架反序列化      无公开利用  公网可达  资产=内部系统
       → 时限30d · 先加WAF规则 · 随版本迭代修复
  [P3] 镜像基础层老旧库      无利用      不可达    资产=批量节点
       → 季度批次 · 换基础镜像统一解决
​

处置的技巧在"等待期怎么活"：时限未到不等于袖手旁观。等待补丁窗口期，先上缓解措施——网络层收访问来源、应用层挂虚拟补丁、运行时降权。P3 那条尤其体现云的便利：几百台节点的底层库问题，最优解不是逐台打补丁，而是换一版基础镜像整体重建——第二章 IaC 与镜像治理的复利在此兑现。

解读这份分级：同一个扫描器输出的四条发现，处置动作、时限、责任路径完全不同。漏洞管理的专业度，就体现在这张组合判断表上——考试场景题给的多半正是"扫描器报了一条高危，下一步做什么"，答案永远从可达性与资产价值推起，而不是从严重度标签推起。

配置合规：对抗熵增的机器检查

配置漂移的物理学：任何环境不加干预都会向混乱演化。新服务上线、应急改动、人员更替，每件事都在悄悄偏离基线。第五章的漂移检测管住了 IaC 模板出生的资源，但环境里还有大量非模板来源的配置——操作台手工点的、脚本批量跑的、历史遗留的。配置合规检查就是把 2.3 的组件点检表变成全环境定期执行的机器检查：

# 每日配置合规巡检（节选输出）
$ config-guard run --profile baseline-v3
  [FAIL] 存储位置 public-media 未开访问日志        基线5.3 · 责任:内容组
  [FAIL] 数据库 audit-log-target 未配置外送        基线6.2 · 责任:平台组
  [WARN] 14 个 IAM 身份存在90天未使用权限          规则4.1 · 已开回收单
  [PASS] 其余 217 项检查通过                       通过率 98.2%

# 巡检结果自动流转：
#   FAIL → 开单派至责任组 → 时限整改 → 复检关闭
#   连续两期 FAIL → 升级至安全委员会周报
​

这套机制的设计要点有三。一是"检查项必须能自动判定"：写不进检查规则的基线条款要么补技术手段，要么移入人工评审清单——含糊的条款只会制造廉价的合规感。二是"发现即派单"：巡检的价值闭环在整改，不闭环的巡检只是心情记录。三是"趋势比绝对值重要"：通过率从八成爬到九成八的过程，就是环境质量的真实改善曲线；反过来连续下滑是管理信号，比单次 FAIL 更值得关注。

合规从大考到体检

把合规检查从年度大考改成每日体检，是云给合规域的最大红利。传统模式：年度审计前突击整改，证据靠人肉截图。云上模式：合规要求映射为持续执行的检查规则（第三章的加密基线、本章的配置规则、第五章的卡点记录），合规证据由系统自动归档——检查输出本身就是证据。审计来临时，导出近一年的巡检趋势与整改闭环记录，比任何突击准备都有说服力。7.1 的法规映射会给这套"规则库"补上法条出处，让每条检查规则都能回答"我为哪条要求服务"。

修复的责任政治学：三个常见僵局与破法

漏洞管理的失败大多不在技术而在协作，三个高频僵局提前给破法。僵局一，"老系统没人敢动"：某核心系统的组件三年没更新，谁改谁背锅。破法：不修组件先修环境——前面套虚拟补丁与访问收敛把风险压到可接受，同时给老系统立"退役计划"进风险登记册，让"不动"变成"有期限的接受"。僵局二，"业务高峰期不能停"：修复窗口与业务永远冲突。破法：把修复分级——能热修的（配置、规则）立即做，要重启的进常规窗口，要停机的用蓝绿或滚动替换（云的现代化工夫在这兑现）。僵局三，"修了又坏谁负责"：补丁引发故障的追责恐惧让修复动作迟疑。破法：修复决策留痕（谁批的、依据什么），失败复盘对事不对人——追溯机制若惩罚行动者，组织会训练出全员拖延。

三个僵局的共同解药是流程里的"留痕与分级"，这也再次呼应本册的母题：把安全判断变成可追溯的决策，而不是靠胆量。

度量：漏洞治理的两个真指标

最后给两个真指标，防止治理滑向数字游戏。第一个是逾期率：超过时限未修复的漏洞占比，按"可达性加资产价值"分层看——高层级的逾期率才是有效数字，全量平均会拿低危项稀释问题。第二个是复发率：同型漏洞（同类组件、同类误配）在修复后的再次出现频率——复发说明修的是症状不是因：镜像没换、模板没改、习惯没变。两个指标都按月看趋势，向上管理层汇报时配一句归因（"本月逾期升高源于某供应链事件的批量修复"），让数字带着故事走。

本节要点回顾

• 漏洞管理是风险管理不是打卡：可达性、可利用性、资产价值三问决定修复顺序，扫出的清单只是原料。
• 配置合规靠持续对账：基线写进模板、漂移检测守运行期（2.4 的底座在运营域兑现），合规状态是一个持续量而非年检结果。
• 修复要闭环到根因：镜像没换、模板没改的修复是复发预订，同型漏洞复发率是治理深度的试金石。
• 两个真指标：分层看逾期率、按月看复发率，汇报时数字带着归因走。
• 漏洞情报要接业务语境：同一个 CVE 在联网组件与内网组件上是两种风险，脱离语境的严重度只是标签。

一个高频之问

问：扫描工具报了三千个漏洞，团队一个月只能修三百个，怎么办？ 这正是"清单不是任务清单"的现实版本。三步走：先用可达性过滤（不可达的漏洞排最后，很多组织的"三千个"里六成属于此类）；再按资产价值分层出修复队列（核心级数据所在资产的高危项先行）；最后把剩余量转成结构性整改——若修不完的量大头集中在某个老镜像或某个框架版本，换掉它一次抵一千次修补。修不完永远不是加人的理由，是换打法的信号。

单点的隐患清理完了，下一节把镜头拉回完整的事件弧线：一场从凌晨告警到复盘会的全流程推演，检验本章前三节的能力如何咬合成一个体系。