1. 威胁建模到底在解决什么问题很多人第一次听到“威胁建模”这个词脑子里浮现的是一群安全专家围坐在白板前画一堆看不懂的框和箭头最后产出一份没人看的文档。如果你也这么想那说明你还没真正被安全问题毒打过。我做了十多年安全相关的工作参与过大小几十个系统的威胁建模可以很负责任地说威胁建模不是安全团队的专属仪式而是每一个做系统设计的人都应该掌握的基本功。它的核心价值可以用一句话概括在写第一行代码之前就把“谁会来搞我、从哪儿搞、搞了会怎样”想清楚。这听起来像是常识但现实中我见过太多团队是反着来的——先花三个月把系统上线然后安全扫描报告出来一堆高危漏洞再花三个月打补丁最后发现有些问题根本补不了因为架构层面就错了。威胁建模要解决的就是这种“事后诸葛亮”的困境。具体来说威胁建模能帮你做到三件事。第一识别资产和攻击面你得先知道自己有什么值钱的东西以及这些东西暴露在哪些入口上。第二枚举潜在威胁不是泛泛地说“可能有黑客攻击”而是具体到“攻击者可能通过伪造令牌绕过认证进而读取其他租户的数据”。第三确定缓解措施的优先级资源永远有限威胁建模帮你把精力花在真正要命的地方而不是给每个低风险问题都打补丁。适合谁来学我的答案是所有参与系统设计和开发的人。后端工程师、前端工程师、架构师、产品经理、运维人员甚至技术管理者都应该懂威胁建模的基本方法。你不需要成为安全专家但你需要具备“攻击者视角”的思维方式。这篇内容会从实操角度出发把威胁建模的完整流程拆开讲清楚包括每一步具体怎么做、用什么工具、容易踩什么坑以及我这些年积累下来的一些经验技巧。2. 动手之前先搞清楚建模对象和边界2.1 画一张让所有人都能看懂的架构图威胁建模的第一步不是打开什么高级工具而是画图。听起来很简单但我见过太多团队在这一步就翻车了。常见的问题是图画得太细细到每个类的方法调用都画出来结果没人看得懂或者图画得太粗就画一个“用户 - 系统 - 数据库”的三层框图根本没法分析威胁。我的经验是画一张“数据流图”级别的架构图就够了。具体来说你需要在这张图上标出以下几类元素外部实体与系统交互的人或外部系统比如用户、第三方支付网关、上游数据提供方。处理过程系统内部对数据进行处理的核心模块比如认证服务、订单处理引擎、报表生成器。数据存储数据落地的地方比如关系型数据库、对象存储、缓存、消息队列。数据流数据在以上元素之间流动的路径用带箭头的线表示。信任边界这是最关键但最容易被忽略的元素。信任边界是不同信任级别区域之间的分界线比如公网和内网之间、用户可控区域和系统可控区域之间。威胁往往就发生在数据跨越信任边界的地方。画图的时候有一个实用技巧用不同颜色标注信任边界。比如公网区域用红色DMZ 用黄色内网核心区用绿色。这样一眼就能看出哪些数据流跨越了信任边界需要重点分析。我通常会用简单的绘图工具比如 draw.io 或者纸笔快速画一版然后在团队评审时一起完善。不要一上来就追求完美先画出来再迭代。2.2 明确“什么值得保护”和“谁可能来攻击”图画完之后下一步是资产识别。资产就是那些如果被破坏、泄露或篡改会让你真正感到痛的东西。我一般会把资产分成几类数据资产用户个人信息、支付凭证、商业机密、源代码、密钥。功能资产核心业务逻辑、交易引擎、认证授权机制。基础设施资产服务器、网络设备、数据库实例、容器编排平台。识别资产的时候有一个常见的误区只关注数据忽略功能。比如一个推荐算法系统它的核心资产可能不是用户数据而是推荐模型本身。如果攻击者能操纵推荐结果造成的业务损失可能比数据泄露还大。所以资产识别要结合业务场景来想。接下来是攻击者画像。你不需要列出所有可能的攻击者但至少要区分几类外部攻击者没有合法账号从公网发起攻击。内部攻击者有合法账号但权限受限可能越权访问。供应链攻击者通过第三方组件或服务间接入侵。自动化攻击爬虫、扫描器、暴力破解工具。不同攻击者的动机、能力和资源不同对应的威胁也不同。比如外部攻击者可能更关注绕过认证而内部攻击者可能更关注权限提升。把攻击者画像和资产清单放在一起看你就能初步判断哪些资产面临哪些威胁。注意资产识别和攻击者画像不是一次性的工作。系统架构变了、业务逻辑变了、外部环境变了这些都需要重新评估。我一般建议至少每个大版本迭代做一次轻量级的复查。3. 用 STRIDE 把威胁一条条揪出来3.1 STRIDE 六类威胁的实操解读STRIDE 是威胁建模领域最经典的框架之一它把威胁分成六类仿冒、篡改、否认、信息泄露、拒绝服务、权限提升。这个框架的好处是简单好记而且每一类都对应着明确的安全属性。下面我结合具体例子来讲每一类怎么用。仿冒攻击者假装成另一个人或系统。比如伪造 JWT 令牌、盗用会话 Cookie、冒充内部服务调用 API。对应的安全属性是认证。你在分析时要问自己这个入口有没有做身份验证验证机制能不能被绕过篡改攻击者修改数据或代码。比如修改请求参数、篡改数据库记录、注入恶意代码。对应的安全属性是完整性。你要检查数据在传输和存储过程中有没有完整性校验输入有没有做验证和转义否认用户或系统否认自己做过某个操作。比如用户否认下过某个订单、管理员否认删过某个配置。对应的安全属性是不可否认性。你需要确认关键操作有没有审计日志日志能不能被篡改信息泄露敏感信息被未授权的人看到。比如数据库备份泄露、日志里打印了密码、错误信息暴露了内部路径。对应的安全属性是机密性。你要审查敏感数据有没有加密访问控制是否到位错误处理会不会泄露信息拒绝服务让系统无法正常提供服务。比如耗尽连接池、塞满磁盘、触发无限循环。对应的安全属性是可用性。你要评估有没有资源限制有没有限流和熔断机制权限提升攻击者获得本不该有的权限。比如普通用户变成管理员、容器逃逸到宿主机。对应的安全属性是授权。你要检查权限模型是否合理有没有越权漏洞在实际操作中我会针对每一条数据流逐一过一遍 STRIDE 六类威胁。比如有一条数据流是“用户浏览器 - API 网关”我就问这条流有没有仿冒风险有没有篡改风险……以此类推。这样做虽然看起来机械但能保证不遗漏。3.2 用攻击树把威胁拆到可执行粒度STRIDE 帮你识别威胁类型但有时候一个威胁太笼统没法直接指导修复。这时候可以用攻击树来细化。攻击树的根节点是攻击者的目标比如“获取管理员权限”然后往下拆解成子目标直到每个叶子节点都是一个具体的攻击步骤。举个例子攻击者的目标是“读取其他用户的订单数据”。拆解下来可能是绕过认证窃取会话令牌通过 XSS 获取 Cookie通过网络嗅探获取令牌暴力破解密码撞库攻击弱密码猜测绕过授权修改请求中的用户 ID利用 IDOR 漏洞利用角色配置错误这样拆解之后每个叶子节点都对应一个具体的缓解措施。比如针对“通过 XSS 获取 Cookie”你可以设置 Cookie 的 HttpOnly 标志针对“修改请求中的用户 ID”你可以在服务端做严格的权限校验。攻击树的好处是把抽象威胁变成可操作项而且能帮你发现组合攻击路径——有些攻击单独看不可行但组合起来就能成功。我通常会在 STRIDE 分析之后对高风险威胁画攻击树。不需要每个威胁都画只画那些你觉得“如果真的发生会很严重”的。画的时候可以用简单的文本缩进也可以用专业工具关键是团队能看懂、能讨论。3.3 威胁排序不是所有威胁都值得马上修识别出一堆威胁之后下一步是排序。我见过一些团队威胁建模做完列了五十条威胁然后每条都标“高危”结果开发团队直接崩溃——根本修不过来。威胁排序的目的是把有限的资源投入到最需要的地方。我常用的排序方法是风险 可能性 × 影响。可能性考虑几个因素攻击者有没有动机攻击难度大不大系统暴露面广不广影响则考虑数据泄露的严重程度业务中断的时长合规风险品牌损失具体操作时我会给每个威胁打两个分可能性 1-5 分影响 1-5 分然后相乘得到风险分。1-6 分是低风险可以接受或后续处理8-12 分是中风险需要制定修复计划15-25 分是高风险必须立即处理。这个打分当然有主观成分但重要的是团队一起讨论并达成共识而不是追求绝对精确。提示威胁排序的结果应该和业务目标对齐。比如一个内部工具和一个面向公众的支付系统同样的威胁等级可能对应不同的处理优先级。不要脱离业务谈安全。4. 从威胁清单到可落地的缓解措施4.1 缓解措施的四种基本策略识别出威胁并排好序之后接下来就是决定怎么处理。安全领域有四种基本的风险处理策略缓解、转移、接受、规避。我逐一解释一下在威胁建模场景下怎么用。缓解是最常见的策略通过技术或管理手段降低威胁的可能性或影响。比如针对 SQL 注入威胁你使用参数化查询针对 DDoS 威胁你部署流量清洗和限流。缓解措施要具体到“谁在什么时间点做什么”而不是泛泛地说“加强安全”。转移是把风险转嫁给第三方。比如购买网络安全保险、把支付逻辑外包给有资质的支付服务商。转移不意味着你不管了你仍然需要评估第三方的安全能力并在合同里明确安全责任。接受是承认风险存在但选择不处理。这通常适用于低风险威胁或者处理成本远高于潜在损失的场景。接受风险需要明确记录并得到相关方确认不能是“假装没看见”。规避是直接去掉产生威胁的功能或架构。比如某个功能需要收集敏感信息但安全风险太高产品决定不做这个功能。规避是最彻底的策略但往往需要产品层面的决策。在实际项目中大部分威胁是通过缓解来处理少数通过转移或接受。我的经验是每一条威胁都要有明确的处理策略和责任人不能有“悬而未决”的威胁。4.2 把缓解措施写成开发能直接用的任务威胁建模的输出如果只是一份“威胁列表”开发团队往往不知道怎么落地。我习惯把每条缓解措施转化成具体的开发任务包含以下要素任务描述具体要做什么比如“在订单查询接口增加基于用户 ID 的权限校验”。验收标准怎么验证做完了比如“使用用户 A 的令牌查询用户 B 的订单返回 403”。优先级对应威胁排序的结果。参考信息相关的威胁描述、攻击路径、安全编码规范链接。这样做的好处是威胁建模的产出直接进入开发流程而不是变成一份没人看的文档。我通常会在项目管理工具里创建对应的任务并和开发负责人确认排期。还有一个实用技巧把缓解措施分成“架构级”和“代码级”。架构级的措施比如“在网关层统一做认证”需要架构师参与代码级的措施比如“对用户输入做转义”开发工程师就能搞定。分开之后责任更清晰推进也更顺畅。4.3 验证缓解措施是否真的有效措施定了、任务做了不代表威胁就消失了。验证是威胁建模闭环中不可或缺的一环。我一般会从三个层面验证代码审查检查缓解措施是否被正确实现。比如要求用参数化查询那就去看代码里是不是真的用了有没有漏掉的地方。代码审查可以由安全团队做也可以由开发团队交叉审查。渗透测试模拟攻击者尝试绕过缓解措施。比如你加了权限校验渗透测试就尝试用各种方式越权。渗透测试最好由独立于开发团队的人来做避免“自己测自己”的盲区。监控和告警有些威胁无法完全消除只能通过监控来及时发现。比如暴力破解你无法阻止攻击者尝试但可以通过监控登录失败率来及时发现并封禁。监控规则本身也需要定期审查和调整。我踩过的一个坑是缓解措施上线后没有回归验证。有一次我们给一个接口加了限流但后来一次重构把限流配置弄丢了直到线上出问题才发现。所以我的建议是把安全验证纳入 CI/CD 流程每次发布都自动跑一遍关键安全检查避免人为遗漏。5. 威胁建模落地时最容易踩的五个坑5.1 坑一做成一次性文档写完就锁进柜子这是最最常见的坑。团队花了一周时间做威胁建模产出一份几十页的文档然后……就没有然后了。系统迭代了好几个版本架构变了、接口变了但威胁模型还是老的。等到出安全事件时翻出来一看发现分析的还是半年前的架构。根因是把威胁建模当成了“交付物”而不是“持续活动”。威胁建模的本质是随着系统演进而不断更新的风险认知不是一份静态文档。我的做法是把威胁建模嵌入到开发流程中。具体来说每次架构评审必须包含安全评审环节更新威胁模型。每个大版本迭代做一次轻量级威胁复查看看有没有新增的攻击面。每次安全事件或漏洞修复后回溯威胁模型看看是不是有遗漏的威胁类型。工具方面我推荐用版本控制的文本格式来维护威胁模型比如 Markdown 或 YAML 文件和代码一起放在代码仓库里。这样每次变更都有记录也方便和代码关联。5.2 坑二只做技术威胁忽略业务逻辑威胁很多团队做威胁建模时注意力全在技术层面SQL 注入、XSS、缓冲区溢出……这些当然重要但业务逻辑漏洞往往危害更大且更难发现。比如优惠券可以无限叠加使用。退款流程可以绕过审批直接到账。积分兑换没有做并发控制导致超兑。这些漏洞不是技术框架能防住的必须从业务逻辑层面分析。我在威胁建模时会专门花时间走一遍核心业务流程问自己如果我是攻击者我会怎么利用这个流程的规则来获利实操建议在画数据流图时除了技术组件也把业务规则标出来。比如“每个用户每天只能领一次优惠券”这条规则在图上标注出来然后分析这条规则在哪个环节校验能不能绕过并发情况下会不会失效5.3 坑三安全团队闭门造车开发团队不参与我见过一些公司威胁建模是安全团队关起门来做的做完之后把报告发给开发团队说“你们照着修”。结果开发团队一看很多威胁根本不适用或者修复建议太笼统没法落地。更糟糕的是开发团队会觉得“安全是安全团队的事”缺乏主人翁意识。正确的做法是威胁建模必须是跨职能协作的活动。安全团队可以提供方法和工具但最了解系统的是开发团队。我通常组织一个 2-3 小时的威胁建模工作坊参与人包括架构师、核心开发、产品经理、运维代表、安全工程师。大家一起画图、一起识别威胁、一起讨论缓解措施。这样产出的结果更贴合实际而且开发团队从一开始就参与了后续落地也更顺畅。工作坊的节奏我一般这样控制前 30 分钟画架构图和数据流图中间 60 分钟用 STRIDE 识别威胁后 60 分钟讨论缓解措施和优先级。中间可以休息一下避免疲劳导致质量下降。5.4 坑四威胁描述太抽象没法指导修复“存在信息泄露风险”“可能被拒绝服务攻击”——这种威胁描述等于没说。好的威胁描述应该具体到攻击者是谁、用什么手段、攻击哪个组件、造成什么后果。我要求团队用这样的模板来描述威胁[攻击者类型] 可以通过 [攻击手段] 攻击 [目标组件]导致 [具体后果]。比如“外部攻击者可以通过伪造 JWT 令牌中的用户 ID访问订单查询接口导致读取其他用户的订单数据。”这样的描述直接指向了修复方向验证 JWT 签名、在服务端校验用户 ID 与令牌的一致性。威胁描述越具体缓解措施就越明确。5.5 坑五忽略第三方组件和供应链威胁现代系统大量依赖第三方库、开源组件、云服务。这些依赖本身可能带来威胁。比如某个 npm 包被投毒、某个云服务的配置错误导致数据暴露。很多团队做威胁建模时只关注自己写的代码忽略了这些外部依赖。我的做法是在架构图上明确标出所有第三方依赖和外部服务然后针对每一个问如果这个依赖被攻破会影响什么有没有替代方案有没有监控手段具体措施包括使用软件物料清单管理依赖、定期扫描依赖漏洞、对关键依赖做安全评估、在合同里明确第三方安全责任。这些工作不需要在每次威胁建模时全部做一遍但至少在架构层面要有意识。6. 让威胁建模持续产生价值的几个习惯6.1 建立轻量级的威胁建模模板如果你每次做威胁建模都从零开始那很难坚持。我建议团队沉淀一套自己的模板包含架构图模板预置常见的信任边界标注STRIDE 检查清单针对你们的技术栈定制威胁描述模板缓解措施跟踪表模板不需要很复杂一页纸就够了。关键是让新成员也能快速上手降低威胁建模的门槛。我们团队现在的模板就是一个 Markdown 文件包含上述几个部分新项目直接复制一份就能用。6.2 把安全需求写进用户故事敏捷开发中安全需求往往被当成“非功能性需求”忽略掉。我的做法是把威胁建模产出的缓解措施转化成安全用户故事和功能故事一起排优先级。比如作为系统我需要在订单查询接口校验请求者只能查询自己的订单以防止越权访问。这样安全需求就进入了正常的开发流程而不是额外的负担。产品经理也能看到安全工作的价值更容易争取资源。6.3 定期回顾安全事件和漏洞每次出现安全事件或发现漏洞都是改进威胁模型的好机会。我会组织一个简短的回顾问三个问题这个威胁在我们的威胁模型里吗如果在为什么缓解措施没生效如果不在为什么没识别出来我们的威胁建模流程有什么可以改进的类似的威胁在其他系统里存在吗这种回顾不需要很正式半个小时就够了但坚持做下来威胁建模的质量会越来越高。6.4 培养团队的攻击者思维威胁建模最终依赖的是人的判断。工具和方法再好如果团队缺乏攻击者思维也很难识别出真正的威胁。我鼓励团队做几件事定期分享安全案例每周花 15 分钟分享一个真实的安全事件讨论如果是我们的系统会怎样。做内部攻防演练让开发团队尝试攻击自己写的系统体验攻击者的视角。鼓励“如果我是坏人”的讨论在需求评审和设计评审时专门留几分钟问这个问题。这些习惯看起来简单但长期坚持下来团队的安全意识会有质的提升。我见过很多团队做了一年威胁建模之后开发工程师在写代码时就会主动考虑安全问题而不是等安全团队来提。威胁建模不是银弹它不能保证系统绝对安全。但它能让你在正确的时间做正确的事——在架构还没定型的时候发现致命问题在代码还没写的时候确定安全需求在资源有限的时候把精力花在刀刃上。我个人的体会是威胁建模做得好的团队不是没有安全漏洞而是不会在同一个地方摔倒两次。