4. 安全设计评审作业：检查架构设计、评估攻击面、输出改进建议
核心目标：在安全引导阶段的早期，通过结构化评审发现架构层缺陷与攻击面，输出可落地的改进建议，避免漏洞累积到开发后期。
适用场景
- 系统或模块完成概要设计 / 详细设计，尚未进入编码阶段。
- 涉及用户身份、支付、敏感数据、外部网络接口或第三方集成的功能模块。
- 重构、迁移（如微服务拆分、云原生改造）等重大变更场景。
- 甲方安全评审 / 乙方安全交付物验收。
前置条件
- 收到完整的架构设计文档（包括系统上下文图、组件图、数据流图 DFD、信任边界标注）。
- 设计文档已通过自检清单（如 STRIDE per element 检查）。
- 安全评审人员具备威胁建模基础，且已了解业务上下文。
- 评审环境已准备：白板 / 协作画板（如 Miro）、威胁建模工具（如 Microsoft TMT、OWASP Threat Dragon）。
- 提供《安全设计评审检查单》（见下方附件模板）。
操作步骤
- 架构视图分解：将系统拆解为用户交互层、业务逻辑层、数据持久层、外部依赖层；标注信任边界（Trust Boundary）。
- 分块威胁识别：对每个组件、数据流、存储项应用 STRIDE 分类（Spoofing / Tampering / Repudiation / Information Disclosure / Denial of Service / Elevation of Privilege），记录威胁描述与影响等级。
- 攻击面枚举：列出所有外部可访问的入口、协议、端口、API、文件接收点、认证凭据存储位置。使用攻击面度量表计算暴露分数。
- 风险排序与证据收集：按 DREAD / CVSS 打分，整理高风险项列表，附上设计文档截屏或数据流路径说明。
- 改进建议输出：每项风险给出 强制（Must）、推荐（Should）、可选（Could） 级别的缓解措施，并标注预期修复时间（如“安全引导阶段内完成”）。
实操技巧：使用 DFM（Data Flow Mindmap）快速标注数据流，并在每一步之后核对《安全设计评审检查单》对应条目，避免遗漏。
输入 / 输出物
| 类别 | 名称 | 说明 |
|---|---|---|
| 输入 | 架构设计文档 | 含上下文图、组件图、DFD、信任边界表 |
| 业务需求说明书 | 明确资产与合规要求（如 GDPR、等保 2.0） | |
| 历史安全评审记录 | 上一轮或相似系统的问题清单 | |
| 输出 | 安全评审报告 | 含威胁清单、攻击面图、风险热力图、改进建议表 |
| 评审跟踪看板 | 每项修复任务的负责人、状态、预期完成时间 |
责任边界
- 安全引导师：负责组织评审会、引导威胁建模、裁定风险等级、审核改进建议的充分性。
- 架构师 / 设计工程师：提供设计文档并解释设计决策、参与威胁识别、接受或申诉改进建议。
- 产品经理：确认业务需求与安全约束的平衡，对耗时较长的强制项给出排期承诺。
- 测试工程师：参与攻击面枚举，为后续渗透测试提供输入。
记录材料
- 《安全设计评审会议纪要》（含日期、参与者、会议决议）
- 《威胁模型文件》（.tm7 / 在线画板链接）
- 《攻击面登记表》（CSV 格式，含入口点、协议、认证方式、暴露评分）
- 《改进建议跟踪表》（点击率：风险 ID、建议描述、严重等级、负责人、状态、关闭备注）
异常处理
| 异常情况 | 处理方式 |
|---|---|
| 设计文档缺少 DFD 或信任边界标注 | 暂停评审，要求补全后再进入，可提供模板加速 |
| 参与者对风险等级争议较大 | 使用“红队投票” + 业务影响加权法，取中位数并记录少数意见 |
| 改进建议涉及重大架构变更 | 升级至架构评审委员会，启动变更控制流程，本阶段可先输出临时缓解措施 |
| 时间窗口不足，无法完成全量评审 | 按攻击面分数排序，优先评审 Top 5 高风险组件，其余纳入下一轮 |
验收标准
- 评审报告覆盖所有组件及跨信任边界的数据流。
- 每个高风险项均有对应的强制级改进建议，且建议可追溯至设计文档的具体位置。
- 攻击面登记表包含至少 10 个 外部入口点，且已明确认证 / 鉴权 / 加密水平。
- 所有参与者（安全、架构、产品）在会议纪要上签字或确认。
- 改进建议跟踪表已创建，且第一项强制项已分配负责人。
常见失败模式：将评审做成“阅读文档走形式”，未真正进行威胁建模；攻击面枚举仅依赖经验，未使用工具辅助导致遗漏；改进建议过于抽象（如“加强认证”），没有具体的协议 / 库 / 配置参数。本章 SOP 的目标是强制产出可执行、可验证的安全设计改进项。