6.1 风险评估、缓解与业务连续性

6.1 风险评估、缓解与业务连续性

本节摘要：风险评估（Risk Assessment）系统性地识别资产、威胁与弱点并量化排序；风险缓解（Risk Mitigation）为排序结果选择处置策略；业务连续性计划（BCP）与灾难恢复计划（DRP）回答"缓解失效之后怎么办"。四者构成"事前算账、事中处置、事后能续"的完整治理链。承接 1.3 节的风险公式，本节把它展开成可执行的组织流程，通往 6.2 节的合规底线。

从公式到流程隔着三步

1.3 节给了公式：风险 = 威胁 × 漏洞 × 影响。公式好记，难的是把它变成一家组织能持续运转的流程——识别什么资产？威胁场景从哪来？影响怎么估值？谁来定处置顺序？本节就是把这条公式展开成流程。

第一步永远是资产识别，而且是按业务价值识别而不是按设备清单识别。清单上是一台数据库服务器，业务语言里它是"每天承载十二万单交易的核心"，两个描述对应的风险完全不同。资产识别的产物叫资产清单——听起来枯燥，但它是一切后续工作的地基：6.4 节的漏洞管理要对着它扫，6.5 节的云责任划分要对着它分，出事时 6.3 节的响应要对着它定影响面。地基缺一块，后面处处漏水。

第二步是威胁场景构建：对着资产清单问"它会怎么坏"。务实的方法是从行业威胁库与自身历史事件出发，为每类核心资产写出三五个具体场景（"勒索软件加密核心数据库并外泄副本""离职运维在边界防火墙留后门"），比抽象地罗列"黑客攻击"有用得多。

第三步是量化与排序。别被"精确算出风险值"诱惑——安全风险的概率没有足够样本支撑精确计算。工程做法是半定量分级：可能性和影响各按三到五档打分，相乘得出风险级。够排序就行，排序才是评估的目的。

图 6-1 风险处置四象限

验明正身：缓解与连续性

风险缓解是对排序结果的处置决策，四条路对应四个象限：缓解、转移、接受、规避。管理层的价值恰恰在这张象限图前体现——技术团队陈述风险，管理层决定花多少钱压哪个、接受哪个。风险评估报告最后必须落成"处置计划：每项风险、策略、责任人、完成时限"，没有归属人的风险项等于没评估。

**业务连续性计划（BCP）与灾难恢复计划（DRP）**是缓解失效后的安全网。两者常被混用，边界其实是：BCP 管业务（"关键业务如何以降级形态继续运转"——手工开单、切备用供应商），DRP 管技术（"IT 系统如何在灾难后恢复"——备份、备用机房、恢复流程）。DRP 是 BCP 的技术支柱。

DRP 有两个必须背下来的指标：RTO（恢复时间目标——灾难发生后多久必须恢复服务）与RPO（恢复点目标——能容忍丢多少时间的数据）。两个指标共同决定备份方案的形态：

需求: RTO 4 小时, RPO 15 分钟
推导:
  RPO 15 分钟  → 每日全量备份不够, 需要日志级或准实时复制
  RTO 4 小时   → 异地冷备恢复不及, 需温备或热备站点
  方案: 本地快照按小时 + 异地准实时复制 + 季度切换演练
成本: 与 RTO/RPO 的苛刻程度呈指数关系 —— 指标是业务定的, 账单也是业务认的
​

最后一行是本节的隐藏考点：RTO/RPO 每收紧一个数量级，成本翻的不止一倍。让业务部门在知情的情况下选择指标，比让技术团队自作主张背锅合理得多。

工程实践要点

备份的可用性要用恢复演练证明。 "有备份"和"备份能恢复"是两回事——没有做过恢复演练的备份体系，故障率远超直觉（备份任务静默失败、介质损坏、恢复流程没人会走）。演练要真刀真枪：随机挑一个月前的备份，在隔离环境完整恢复一遍并验数据。

评估要定期重跑。 资产在变、威胁在变、去年的"低可能"今年可能不再是低可能（新攻击技术、新业务形态）。年度全量评估加重大变更即时评估，是常见的节奏。

⚠️ 常见坑：风险评估做完就归档。评估报告的价值在它驱动的处置计划，不在报告本身。归档型评估是合规表演，第一年做完第二年开始互相抄。

💡 关键直觉：连续性计划的本质是"预先替慌乱的自己做决策"——灾难发生时的团队没有思考带宽，所有当下该做的判断，都必须提前写成清单、演练成肌肉记忆。

鉴定结论

• 评估三步走：按业务价值识别资产、写具体威胁场景、半定量分级排序，够排序就够用；
• 处置四象限（缓解、转移、接受、规避）每项都要有归属人与时限，"接受"是书面决策不是默认；
• RTO 与 RPO 由业务知情选择，备份体系的价值用恢复演练证明；
• 风险处置守的是组织的自愿底线，还有一条法定底线——下一节的合规与法律法规。

附卷：一次风险评估的现场记录

把一场两个小时的评估会（脱敏改写）浓缩成现场记录，看流程怎么走：

资产定级: 核心交易库(关键) 官网(重要) 内部Wiki(一般) 报表沙箱(一般)
场景一: 勒索软件经钓鱼进入, 加密交易库与备份
        可能性=中 影响=很高 → 高风险
场景二: 官网组件漏洞被批量利用挂马
        可能性=高 影响=中 → 高风险
场景三: 内部Wiki被暴力破解
        可能性=低 影响=低 → 接受, 记录在案
处置决定: 场景一 缓解(网络分段+备份隔离+演练); 场景二 缓解(WAF+补丁窗口);
          场景三 接受(书面记录, 每季复审)
遗留动作: 场景一的备份隔离改造, 责任人=运维负责人, 时限=六周
​

记录里最值钱的是最后一行——评估会的产出从来不是"风险清单"本身，而是带责任人、带时限的遗留动作。没有这一行，两个小时的会就只是聊天。另一处值得注意是场景三的处置：把"接受"写下来本身就是决策，写下来的接受项才有复审的锚点，口头接受等于没接受。

RTO 与 RPO 的现场对话也常被漏记，补一段典型问答：业务方开口"要零丢失、分钟级恢复"，追问两个问题就回到现实——"上一次意外中断损失了什么、当时的真实感受"；"愿意为分钟级每年支付多少"。多数业务在第二个问题后会把指标放宽到可负担的水平。指标由业务知情选择，是 6.1 节正文的隐藏考点，现场记录里的每一条指标都要能追溯到业务方的签字，而不是技术团队的自作主张。备份方案的形态跟着指标走，账单也跟着指标走，顺序不能反。

附卷二：连续性演练的三级菜单

BCP 与 DRP 的价值全在演练里，演练不必都是大阵仗，按成本分三级轮着来：

三级菜单的关键是"轮着来"：只做一级会练成嘴上功夫，只做三级会把团队练怕（成本高、易出事），梯度推进既保真实又可持续。二级演练里最值得反复做的是备份恢复——它是所有连续性能力的地基，而且可以做到不碰生产（隔离环境恢复加数据校验）。每一次二级演练都应产出一份"与指标的偏差记录"：备份多大、恢复多久、丢了多少，三个数字与 RTO/RPO 的差值就是下一笔改进预算的依据。

最后提醒一个容易被遗忘的角落：连续性计划自身也要有"版本管理与异地副本"。见过把灾备预案存在待灾机房里的团队——机房真出事时，预案和机房一起消失。预案的最新版放在第三地，联系人表按月核实，这两件小事在真灾难日的价值超过所有设备。

附卷二：评估报告的一页纸模板

评估的产出要让管理层十分钟看完，一页纸模板如下：

标题: XX 季度风险评估摘要
第一行: 总体结论(高风险 N 项, 均有处置计划)
表格: Top5 风险 —— 名称/等级/处置策略/责任人/时限
趋势: 与上季度对比, 新增/关闭/超期 三组数字
求助: 需要管理层拍板的事项(通常一至两项)
附件: 完整风险台账(供查阅, 不供阅读)
​

模板的精髓是"求助"栏：评估会最值钱的产出就是那件必须管理层拍板的事（给预算、停某服务、接受某风险）。没有这一栏，管理层看完只会说"知道了"。有这一栏，每次评估都是一次决策会议。一页纸写不下是常态，写不下说明没排序——Top5 之外的都在附件里，附件就是给细节准备的仓库。