网络安全风险评估预案

去年秋天，网络一家做跨境电商的安全客户半夜给我打电话，说后台订单数据全乱了，风险支付接口返回的评估金额比实际少了两个零。排查到凌晨三点，预案问题出在一台边缘服务器上——运维图省事，网络把测试环境的安全SSH密钥直接拷到了生产环境，而那台机器的风险防火墙规则里，22端口对公网敞开。评估攻击者没用什么高级漏洞，预案就是网络撞库进了这台机器，顺手改了配置文件。安全这事让我意识到，风险很多团队嘴里的评估“风险评估”，其实只是预案买了一套扫描工具，扫完出一份PDF，然后锁进文件夹。

真正的评估得从“你怕丢什么”开始。不是列资产清单那种丢法，而是问业务负责人：如果订单系统停四小时，损失是赔违约金还是客户直接跑光？如果用户手机号泄露，公关部要发几封道歉信？我见过一家做在线教育的，他们最怕的不是数据库被拖，而是直播课中途被劫持推流。这个优先级一确定，后面的评估路径就全变了——不再盯着通用漏洞评分，而是去看推流鉴权逻辑、CDN回源策略、老师端推流工具的版本。风险从来不是均匀分布的，它总往业务最疼的地方钻。

接下来得画一张“攻击路径图”，而不是漏洞列表。举个例子，某次给一个政务小程序做评估，扫描器报了一堆中危的XSS，但真正的入口是一个未授权的API接口，返回了内部系统的员工姓名和工号。攻击者拿这些信息去社工运维，比直接打XSS高效得多。所以评估的时候，我习惯把资产、身份、数据流、信任边界全摊在墙上，用马克笔连箭头。哪个环节能一步跨到核心数据，哪个环节就是红色节点。这种视觉化的东西比CVSS评分直观得多，业务方也能看懂。

然后是“修复成本 vs 攻击收益”的权衡。不是所有漏洞都值得修。一个内部测试环境的弱口令，攻击者得先突破VPN才能碰到，修它的优先级可能低于给客服系统加个验证码——因为后者直接暴露在公网，且每天有真实用户交互。我常跟客户说，别追求零漏洞，追求“攻击者觉得不划算”。比如把数据库的敏感字段做加密存储，哪怕被拖库，解密成本也高到让黑产放弃。这比天天追着开发修SQL注入更现实。

预案得落到具体动作上。谁在凌晨三点能爬起来重启服务？备份是每天全量还是增量？恢复演练上次做是什么时候？我见过太多预案写着“立即启动应急响应”，但连一个能拍板关停支付接口的人都找不到。所以我们的模板里会强制填三个角色：技术决策人、业务决策人、对外沟通人，附上手机号。每季度做一次“桌面推演”，拿一个真实故障场景，比如“CDN节点被污染，用户看到博彩广告”，让这三个人在会议室里模拟决策。推演两次之后，他们自己就会把预案里的废话删掉。

最后说个反直觉的观察：很多风险其实来自“合规驱动”的评估。为了过等保，买一堆设备，配一堆策略，结果运维嫌麻烦，把日志审计关了，把WAF设成只记录不拦截。这种评估做完，风险反而更高——因为管理层以为安全了。所以我现在做评估，第一件事是问运维：“你们最讨厌哪条安全策略？”那条策略大概率就是失效的。把它改成一个运维愿意执行的版本，比再加十条规则有用。