文章总结： 本文提供一套可直接用于S3/S4项目的安全架构评审落地方法，核心是用数据流图、威胁台账和证据链将评审从会议转为项目动作。方法涵盖评审前准备、数据流图绘制、STRIDE威胁建模、滥用故事分析、风险排序、控制任务落地、例外闭环及证据管理。强调每条关键风险需被定位、处理、验证和关闭，并给出可操作清单与常见失败模式，对安全架构师、研发及项目经理具有实用参考价值。 综合评分： 90 文章分类： 安全建设,解决方案,安全运营

安全架构评审落地实战：威胁建模、评审清单和例外闭环

原创

咸鱼翻身日记 咸鱼翻身日记

企业安全指南

2026年9月11日 16:02 浙江

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

用一张数据流图、一个威胁台账和一条证据链，把评审从会议变成项目动作

上一篇《安全架构评审机制：从项目立项到上线门禁》建立了项目分级、六类触发、五道门、八个评审视角和明确结论。机制解决“什么时候评、谁来决定”，实战还要回答“评审会上具体看什么、风险怎么写、控制怎么落到任务、例外怎么退出”。

这一篇提供一套可以直接用于 S3/S4 项目的最小化方法：评审前准备输入，现场用数据流图和威胁建模识别设计风险，评审后把风险转成控制任务、验证证据和门禁条件。对 安全架构师、企业与解决方案架构师、产品和研发负责人、项目经理、安全 Champion、DevSecOps、测试、运维、数据、隐私和 SOC 团队 来说，目标不是产出厚文档，而是让每条关键风险都能被定位、处理、验证和关闭。

一、先准备一页评审任务书

| 字段 | 示例 | | — | — | | 项目与版本 | 客户订单平台 V2.3，方案基线 2026-09-01 | | 业务目标 | 支持客户下单、支付、发货和售后查询 | | 风险等级 | S3：公网、支付、个人信息、第三方物流 | | 本次范围 | Web、移动端、API 网关、订单服务、支付回调和客服后台 | | 不在范围 | 财务结算系统内部改造 | | 触发原因 | 新增开放 API、外部物流 Webhook 和对象存储导出 | | 业务 Owner | 电商业务负责人 | | 技术 Owner | 订单平台研发负责人 | | 评审目标 | 确认身份、对象授权、回调可信、数据导出和恢复控制 | | 目标门 | G2 方案门，十个工作日后进入 G3 设计门 |

任务书用于控制讨论边界。如果范围、版本和目标门都不清楚，评审很容易变成产品介绍会或漫无边际的问题收集。

二、评审前一天完成八项检查

| 检查项 | 不满足时怎么处理 | | — | — | | 架构图包含真实组件和外部依赖 | 退回补图，不接受“微服务架构”概念图 | | 数据流标明协议、方向、数据类型 | 补充箭头和数据分类 | | 用户、服务、管理员身份分开 | 补充身份与凭据来源 | | 公网、租户、环境和管理面边界明确 | 标出信任边界 | | 关键 API、消息、文件和回调有清单 | 补充入口、调用方和鉴权方式 | | 高权动作和批量操作有清单 | 补充执行人、审批和审计 | | 关键依赖有 Owner 和替代方式 | 补充供应商、SLA、降级和退出 | | RTO、RPO、日志和应急责任明确 | 由业务和运维确认最低要求 |

输入不完整不代表取消评审，可以先开 30 分钟建模准备会，但不能在缺少边界的情况下给出“通过”结论。

三、数据流图只画六类元素

| 元素 | 要画什么 | 常见遗漏 | | — | — | — | | 外部实体 | 客户、客服、合作伙伴、管理员、外部系统 | 只画用户，不画第三方和运维人员 | | 处理过程 | 网关、服务、函数、批处理、智能体和管理后台 | 把整个平台画成一个方框 | | 数据存储 | 数据库、缓存、消息、对象存储、日志和备份 | 忽略临时文件、导出桶和搜索索引 | | 数据流 | API、消息、文件、事件、回调和管理命令 | 不写协议、方向、敏感级别和认证方式 | | 信任边界 | 公网、VPC、租户、生产、第三方和管理面 | 只画网络边界，不画身份和租户边界 | | 安全控制 | 身份、授权、加密、校验、审计、隔离和恢复 | 把 WAF 当作所有风险的答案 |

图要能回答：数据从哪里来，经过谁，以什么身份进入哪个边界，落到哪里，谁可以再把它取走。通常一张上下文图加一张关键链路图就够，不要一开始画到每个类和函数。

四、给每条箭头补齐七个属性

| 属性 | 例子 | | — | — | | 调用方与接收方 | 物流平台 → API 网关 → 订单服务 | | 协议与入口 | HTTPS POST /callbacks/status | | 数据分类 | 订单号、手机号、物流状态，内部/敏感 | | 身份凭据 | 合作伙伴 client_id、证书和短期 Token | | 完整性控制 | 签名、时间戳、Nonce、防重放和幂等键 | | 失败处理 | 重试队列、死信、告警和人工补偿 | | 追踪字段 | request_id、partner_id、order_id、result |

只要箭头属性补齐，大量风险会自然暴露：共享密钥无法区分合作伙伴、回调没有防重放、失败消息无限重试、敏感字段进入日志、对象授权只在前端判断。

五、先找五类边界，再谈 STRIDE

| 边界 | 需要确认 | | — | — | | 用户与系统 | 登录、会话、设备、风控和高风险加验 | | 服务与服务 | 工作负载身份、Token 受众、权限和凭据轮换 | | 租户与租户 | tenant_id 来源、服务端过滤、缓存和导出隔离 | | 内部与第三方 | 合同对象、接口范围、签名、限流、监控和退出 | | 业务面与管理面 | 管理入口、个人身份、审批、临时提权和操作留痕 |

网络在同一个 VPC，不代表处在同一信任级别；使用同一个云账号，也不代表不同租户可以共享数据访问上下文。

六、按组件逐项跑 STRIDE 提示

| 类别 | 追问 | 订单平台示例 | | — | — | — | | S 身份冒充 | 谁可能伪装成合法用户或服务 | 伪造物流回调、盗用客服会话 | | T 数据篡改 | 数据或控制参数在哪里可能被修改 | 修改订单归属、价格、退款状态 | | R 行为抵赖 | 关键操作能否定位到真实个人和请求 | 共享客服账号批量导出后无法追责 | | I 信息泄露 | 数据会在哪个存储、响应或日志泄露 | 错误响应返回身份证号，对象存储误公开 | | D 服务拒绝 | 哪个资源、队列或依赖可被耗尽 | 回调重放压满消息队列和下游连接池 | | E 权限提升 | 普通身份如何获得高权动作 | 修改对象 ID 读取他人订单，客服越权退款 |

STRIDE 是提示词，不是完成条件。同一威胁可能跨多个类别，最终应按具体攻击路径和业务影响记录，而不是为了填满六列制造低价值问题。

七、用滥用故事补足业务逻辑风险

| 正常故事 | 滥用故事 | 需要验证的控制 | | — | — | — | | 客户查看自己的订单 | 客户修改 order_id 查看他人订单 | 服务端对象级授权、租户过滤和测试 | | 物流平台更新状态 | 攻击者重放已签名回调重复触发状态 | 时间窗、Nonce、幂等和异常告警 | | 客服导出投诉记录 | 客服批量搜索并导出非负责区域数据 | 数据范围、审批、水印、速率和审计 | | 管理员修复异常订单 | 管理员绕过审批直接退款 | 临时提权、双人批准和不可篡改日志 | | 系统故障后恢复 | 恢复了数据库但缓存和消息状态不一致 | 恢复顺序、对账脚本和业务验收 |

业务逻辑问题通常无法由通用扫描器发现。产品 Owner、客服、运营和财务参与滥用故事讨论，价值往往高于安全团队独自列技术漏洞。

八、威胁卡使用十个字段

| 字段 | 内容 | | — | — | | threat_id | 例如 TM-ORDER-017 | | 资产与业务目标 | 客户订单隐私和正确履约 | | 前置条件 | 已登录普通客户，可修改 order_id | | 攻击路径 | 客户端参数 → API → 订单查询 → 数据库 | | 现有控制 | 网关认证，前端隐藏按钮 | | 控制缺口 | 后端未校验订单归属 | | 业务影响 | 跨用户订单、地址和手机号泄露 | | 风险等级 | S3 高，公网可重复利用 | | 处理决定 | 服务端对象授权，禁止仅依赖前端 | | Owner、期限、验证 | 订单团队；G3 前完成；自动越权用例复测 |

风险描述要包含条件、路径和影响。只写“存在越权风险”无法指导设计，也无法判断修复是否真的关闭攻击路径。

九、用五个因素快速排序

| 因素 | 评分问题 | | — | — | | 业务影响 | 是否影响核心交易、敏感数据、客户或法定义务 | | 暴露程度 | 是否公网、跨租户、第三方可达或高频调用 | | 攻击可行性 | 是否低权限、低成本、可自动化和可重复 | | 控制强度 | 现有控制能否预防、检测、止损和恢复 | | 时间窗口 | 是否即将上线、外部威胁活跃或修复窗口有限 |

排序的目的不是计算漂亮分数，而是决定谁先处理、在哪一道门前完成、需要什么级别的风险批准。

十、把处理决定写成控制任务

| 模糊结论 | 可执行任务 | | — | — | | 防止越权 | 在订单查询服务按 user_id、tenant_id、order_id 做服务端授权；新增正反向自动测试 | | 防止重放 | 回调签名覆盖请求体、时间戳和 Nonce；五分钟窗口；重复事件进入告警 | | 加强审计 | 导出记录包含个人身份、查询条件、数据量、审批号、结果和 Trace ID | | 做好恢复 | 按数据库、消息、缓存顺序恢复；执行订单对账并由业务 Owner 验收 | | 管理员要安全 | 管理入口独立、MFA、任务审批、两小时提权、命令和结果留痕 |

每条任务都要明确执行点、默认行为、失败行为、Owner 和验证方式。控制没有进入需求、代码、配置或运行手册，就不算真正落地。

十一、评审清单按场景选，不要全部询问

| 场景 | 优先检查 | | — | — | | 公网 Web/API | 认证、对象授权、输入、速率、会话、错误和日志 | | 敏感数据平台 | 分类、最小化、隔离、加密、导出、保留和删除 | | 管理后台 | 管理面隔离、个人身份、MFA、提权、审批和审计 | | 第三方接入 | 担保、接口范围、签名、限流、监控、期限和退出 | | 云原生平台 | 工作负载身份、Secret、网络策略、镜像、准入和审计 | | AI/智能体 | 数据来源、Prompt、RAG 权限、工具参数、动作确认和停止开关 | | 批处理与消息 | 生产者身份、Schema、幂等、重试、死信和补偿 | | 韧性改造 | 依赖、容量、降级、备份、切换、回切和业务验证 |

清单用于提醒，不用于替代思考。根据项目分级和实际组件选取问题，避免让低风险项目回答上百项无关问题。

十二、评审会按 90 分钟运行

| 时间 | 活动 | 主持人 | | — | — | — | | 0—10 分钟 | 确认范围、版本、目标门和已知假设 | 项目经理 | | 10—25 分钟 | 讲解上下文图、关键数据流和边界 | 架构师 | | 25—55 分钟 | 按关键链路识别威胁与滥用故事 | 安全架构师 | | 55—70 分钟 | 选择处理方式、控制模式和验证手段 | 项目与安全联合 | | 70—82 分钟 | 确认高风险、Owner、期限和门禁 | 业务与技术 Owner | | 82—90 分钟 | 复述结论、争议、例外和下一步 | 评审主持人 |

会前异步阅读输入，会中只讨论关键风险和决定，会后当天发布记录。把时间花在逐页介绍系统，通常说明准备工作没有完成。

十三、评审结论记录七项内容

| 项目 | 要求 | | — | — | | 评审对象 | 项目、范围、环境、架构版本和目标门 | | 参与角色 | 业务、架构、研发、安全、测试和运维代表 | | 关键假设 | 流量、数据、身份、依赖和信任前提 | | 风险摘要 | 高中低风险数量及最关键场景 | | 架构决定 | 采用、调整或偏离哪些标准模式 | | 门禁条件 | 必须在下一阶段前完成的事项和证据 | | 正式结论 | 通过、条件通过、修改复审、接受或不通过 |

“会议讨论过”不是证据。结论要有编号、版本、日期和批准人，并与威胁卡、项目任务和发布记录互相链接。

十四、例外按七步闭环

| 步骤 | 输出 | | — | — | | 1 申请 | 对象、标准要求、偏离原因和影响范围 | | 2 评估 | 风险场景、严重度、持续时间和可选方案 | | 3 补偿 | 临时限制、监控、人工复核、降级或隔离 | | 4 批准 | 风险 Owner 按等级批准，执行人不得自批 | | 5 监控 | 例外期间的告警、指标和异常升级方式 | | 6 到期决定 | 修复关闭、延期升级、替代或停止服务 | | 7 退出验证 | 权限、旁路、临时配置和数据残留已清理 |

延期必须重新说明风险和业务原因，不能复制旧申请。连续延期两次，应升级到架构治理或年度路线图处理。

十五、证据目录按六个文件夹组织

| 文件夹 | 内容 | | — | — | | 01_scope | 任务书、分级、触发器、范围和参与人 | | 02_model | 架构图、数据流、边界、资产和关键假设 | | 03_threats | 威胁卡、滥用故事、排序和处理决定 | | 04_controls | 安全需求、架构决定、任务和配置回读 | | 05_validation | 自动检查、代码测试、攻击验证、演练和复测 | | 06_decision | 结论、例外、批准、门禁和退出证据 |

文件名带项目、版本、日期和唯一 ID；关键原始证据保留哈希或不可变存储。截图可以辅助说明，但不要让截图成为唯一证据。

十六、把评审结果接入研发流程

| 系统 | 接入方式 | | — | — | | 项目平台 | 分级和触发器决定是否创建评审任务 | | 架构仓库 | 保存版本化图、ADR、安全模式和偏离记录 | | 需求与缺陷平台 | 每条高风险映射任务、Owner、期限和验证 | | CI/CD | 自动检查和高风险未关闭状态影响发布 | | 例外台账 | 到期提醒、升级、补偿监控和退出证明 | | 运营平台 | 日志、告警、事件和恢复结果回流威胁模型 |

尽量使用现有项目与研发工具，不要另建只有安全团队维护的孤岛系统。安全字段可以扩展，但对象 ID 必须统一。

十七、六类变化触发增量更新

| 变化 | 增量复审重点 | | — | — | | 新入口或用户群 | 认证、授权、速率、滥用和日志 | | 新数据或用途 | 分类、同意、隔离、共享、保留和删除 | | 新第三方或组件 | 信任、权限、来源、SLA、替代和退出 | | 权限模型变化 | 角色、机器身份、高权和紧急访问 | | 架构基础变化 | 数据流、边界、单点、配置和恢复 | | 事件或控制失效 | 同根因路径、假设、规则、测试和模式 |

增量评审只处理变化和受影响路径，不必每次重做全量模型；但架构重构或边界大幅变化时，应重新建立基线。

十八、最常见的六个失败模式

| 失败模式 | 纠正方式 | | — | — | | 图很漂亮但没有真实数据流 | 从关键业务请求和管理动作反向画图 | | STRIDE 填满表格却没有优先级 | 只保留有具体路径和业务影响的威胁 | | 所有问题都交给安全团队 | 业务定影响，架构定方案，项目交付控制 | | 控制写成“加强、完善、做好” | 改写为对象、动作、执行点和验证方式 | | 条件通过后无人回读 | 条件直接进入下一道门和发布阻断 | | 例外长期续期 | 到期升级、补偿监控并验证退出 |

十九、四周跑通一个试点

| 周次 | 重点 | 交付物 | | — | — | — | | 第 1 周 | 选 S3 项目、确认输入和关键链路 | 任务书、上下文图、数据流初稿 | | 第 2 周 | 开威胁建模会并完成排序 | 威胁卡、滥用故事和处理决定 | | 第 3 周 | 控制进入需求、代码、配置和测试 | 项目任务、测试用例和例外申请 | | 第 4 周 | 完成回读、复测和门禁结论 | 证据目录、正式结论和复盘清单 |

试点结束后，统计输入缺口、高频威胁、重复控制和流程等待时间，把可复用内容沉淀为安全模式和自动检查。

二十、上线前验收清单

| 验收项 | 结果 | | — | — | | 一页任务书明确范围、版本、风险等级和目标门 | □ | | 数据流图覆盖六类元素和五类信任边界 | □ | | 关键箭头具备七个属性 | □ | | STRIDE 与滥用故事覆盖主要业务风险 | □ | | 每条高风险使用十字段威胁卡 | □ | | 风险排序能说明业务影响、暴露、可行性和时限 | □ | | 处理决定已转成可执行、可验证的项目任务 | □ | | 评审清单按实际场景裁剪 | □ | | 90 分钟评审形成七项正式结论记录 | □ | | 条件通过和例外已进入七步闭环 | □ | | 六个证据文件夹可关联项目版本和问题 ID | □ | | 重大变化和生产事件能触发增量更新 | □ |

二十一、下一篇预告

本篇把评审机制转成了任务书、数据流图、威胁卡、控制任务、证据目录和例外闭环。下一篇继续沉淀共性能力：安全需求与控制标准库：把评审结论转成研发任务和验收标准，重点讲如何让安全要求带编号、适用条件、默认实现、验证方式和例外边界。

参考来源

1. NIST SP 800-160 Vol. 1 Rev. 1 Engineering Trustworthy Secure Systems
2. NIST Secure Software Development Framework
3. NIST IR 8397 Guidelines on Minimum Standards for Developer Verification of Software
4. OWASP Threat Modeling Cheat Sheet
5. OWASP SAMM Threat Modeling
6. OWASP SAMM Architecture Assessment
7. 国家互联网信息办公室
8. 工业和信息化部

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：企业安全指南 咸鱼翻身日记 咸鱼翻身日记《安全架构评审落地实战：威胁建模、评审清单和例外闭环》