3. 安全需求分析：从威胁到安全需求的转化
上一章我们画出了威胁模型，手里攥着一堆攻击路径。但问题来了——这些威胁怎么变成真正的安全需求？
我见过不少团队，威胁分析报告写得厚厚一本，结果开发一看就懵了：「这玩意儿我该怎么改代码？」说白了，威胁是问题，需求才是解决方案。中间缺了一座桥。
这一章，我们就来搭这座桥。
3.1 从威胁到安全需求的转化方法
转化不是拍脑袋。我个人习惯用一套标准流程，把每个威胁拆解成可落地的需求条目。
3.1.1 威胁-需求映射矩阵
每个威胁至少对应一个安全目标。我常用的映射关系是这样的：
| 威胁类型 | 典型场景 | 安全目标 | 需求示例 |
|---|---|---|---|
| 欺骗 | 攻击者伪造身份 | 认证 | 所有API调用必须携带JWT令牌 |
| 篡改 | 中间人修改请求 | 完整性 | 传输层使用TLS 1.3，关键字段加签 |
| 抵赖 | 用户否认操作 | 不可否认性 | 所有写操作记录审计日志，包含时间戳和用户ID |
| 信息泄露 | 数据库被拖库 | 机密性 | 存储层敏感字段使用AES-256加密 |
| 拒绝服务 | 流量攻击打垮服务 | 可用性 | 网关层配置限流，单IP每秒不超过100次请求 |
| 权限提升 | 普通用户越权访问 | 授权 | 每个接口校验用户角色，RBAC模型落地 |
嗯，这里要注意：一个威胁可能对应多个安全目标。比如「攻击者通过SQL注入拖库」，既涉及机密性（数据被拿走），也涉及完整性（数据被篡改）。
3.1.2 转化三步法
我在项目中总结了一套三步走的套路：
- 描述威胁：用一句话说清楚「谁、通过什么方式、攻击什么资产、造成什么后果」。
- 确定安全目标：从STRIDE或CIA三元组里选一个或多个目标。
- 写出需求：用「系统必须/应该/可以」的句式，写一条可验证的需求。
举个例子：
威胁描述：攻击者通过未授权接口调用，获取用户手机号。
安全目标：授权 + 机密性。
安全需求：系统必须对每个API请求进行身份验证和权限校验；用户手机号在数据库中必须使用AES-256加密存储。
3.2 安全需求分类：预防 / 检测 / 响应
需求写出来了，但怎么分类？我习惯按时间维度分——攻击发生前、攻击发生时、攻击发生后。
说白了就是：预防（别让它发生）、检测（发生了你得知道）、响应（知道了你得处理）。
3.2.1 预防类需求
这类需求最容易被接受，因为「防患于未然」的道理谁都懂。但代价也最高——你想想看，为了防一个概率极低的攻击，可能要多写几千行代码。
典型预防需求：
- 输入校验：所有用户输入必须经过白名单过滤。
- 身份认证：登录必须使用MFA。
- 访问控制：基于RBAC的权限校验。
- 加密：传输层和存储层加密。
- 安全配置：服务器禁用不安全的TLS版本。
我的经验：预防类需求要优先落地，但别追求100%覆盖。我曾经在一个项目里花了两个月做全量输入校验，结果发现80%的攻击都来自三个核心接口。先守住关键路径，再慢慢补全。
3.2.2 检测类需求
预防不是万能的。你想想看，零日漏洞怎么防？内部人员作案怎么防？
检测类需求就是你的「第二道防线」。它的核心目标是：缩短攻击者的自由活动时间。
典型检测需求：
- 日志记录：所有认证失败、权限异常、数据变更必须记录。
- 告警规则：同一IP 5分钟内登录失败超过10次，触发告警。
- 异常检测：用户行为偏离基线（比如凌晨3点批量导出数据），标记为可疑。
- 完整性校验：关键配置文件定期计算哈希值，发现变化立即告警。
避坑指南：我曾经见过一个团队，日志写得比业务代码还多，一天产生几个TB的日志。结果呢？没人看。检测类需求一定要配套「可消费」的输出——要么是告警，要么是可视化报表。否则就是数据垃圾。
3.2.3 响应类需求
检测到攻击了，然后呢？
响应类需求定义了「发现安全事件后，系统该做什么」。这部分往往被忽略，但恰恰是决定损失大小的关键。
典型响应需求：
- 自动阻断：检测到暴力破解，自动封禁源IP 30分钟。
- 降级处理：认证服务不可用时，切换到备用认证方式。
- 数据隔离：发现数据泄露，立即隔离受影响的数据分区。
- 恢复流程：从备份恢复被篡改的数据，RTO不超过4小时。
- 取证保留：安全事件发生后，保留所有相关日志，防止被覆盖。
3.3 需求优先级排序
需求列了一大堆，但资源有限。先做哪个？
我见过最蠢的做法是「按领导喜好排」——领导说加密重要，就全员搞加密；领导说日志重要，就全员写日志。结果呢？安全没做好，业务也耽误了。
3.3.1 排序维度
我个人习惯用两个维度来排：威胁等级和实施成本。
| 威胁等级 | 实施成本 | 优先级 | 行动建议 |
|---|---|---|---|
| 高 | 低 | P0（立即做） | 马上排入当前迭代 |
| 高 | 高 | P1（尽快做） | 拆解成多个子任务，逐步落地 |
| 低 | 低 | P2（顺手做） | 在开发其他功能时顺带完成 |
| 低 | 高 | P3（暂缓做） | 放入技术债务清单，定期评估 |
威胁等级怎么定？我一般用DREAD模型打分：
- D（Damage）：造成的损失有多大？
- R（Reproducibility）：复现难度高不高？
- E（Exploitability）：利用难度高不高？
- A（Affected Users）：影响多少用户？
- D（Discoverability）：发现难度高不高？
每个维度打1-3分，总分越高，威胁等级越高。
3.3.2 排序实操案例
拿一个真实项目举例。当时我们做的是一个电商平台，威胁分析后列了这些需求：
| 安全需求 | 威胁等级 | 实施成本 | 优先级 |
|---|---|---|---|
| 支付接口必须使用TLS 1.3 | 高（15分） | 低（1人天） | P0 |
| 用户密码必须加盐哈希存储 | 高（14分） | 低（2人天） | P0 |
| 全站API接入WAF | 高（13分） | 高（20人天） | P1 |
| 后台操作日志审计 | 中（9分） | 低（3人天） | P2 |
| 用户头像上传做病毒扫描 | 低（5分） | 高（15人天） | P3 |
你看，P0的两个需求都是「高威胁+低成本」，必须马上做。P1的WAF虽然重要，但成本高，可以拆成两期做。P3的头像扫描，说实话，电商平台被通过头像上传攻击的概率极低，先放着。
3.4 本章知识体系
下面这张图把整个流程串起来了：
3.5 避坑总结
最后，分享几个我踩过的坑：
坑一：需求写得太抽象
「系统必须保证数据安全」——这种需求等于没写。安全需求必须可验证：用什么算法？密钥存哪里？谁来管理？
坑二：只做预防，不做检测和响应
我曾经有个项目，防火墙、WAF、加密全上了，结果内部员工拖库拖了一个月才发现。为什么？因为没有检测类需求。记住：预防不是100%可靠的。
坑三：优先级排序只看技术难度
「这个需求好做，先做这个」——这是典型的开发思维。安全需求排序必须看威胁等级。一个低威胁的需求再简单，也不该挤占高威胁需求的资源。