01 从源头到图纸：威胁建模与安全设计

01 从源头到图纸：威胁建模与安全设计

威胁建模是在设计阶段系统性回答“该防谁、防什么、在哪拦”的方法，常用 STRIDE 从伪造、篡改、否认、信息泄露、拒绝服务、提权七类威胁逐条排查；安全设计与架构评审则把缓解措施落到组件、信任边界与数据流上，让漏洞在设计期就被拆掉，而不是上线后才补救。

第七幕开头讲“越早越省”。前六幕我们是在补已有系统的窟窿，这一节告诉你：如果从设计第一天就用威胁建模把威胁列出来，很多洞根本不会出现。修一行的成本远低于修一个架构，这是安全预算里最高的杠杆。

一、STRIDE：七类威胁的体检表

STRIDE 是微软提出的威胁枚举法，从七类别审每个组件与数据流：

• 伪装（Spoofing）：伪造身份，对应认证与信任链问题。
• 篡改（Tampering）：改数据/代码，对应完整性问题。
• 否认（Repudiation）：否认动作，对应审计与日志缺失。
• 信息泄露（Information Disclosure）：敏感数据被看，对应保密问题。
• 拒绝服务（Denial of Service）：资源耗尽，对应可用性问题。
• 提权（Elevation of Privilege）：权限升级，对应授权边界。

方法很简单：把系统的数据流程图或组件图画出来，对每个节点和每条流转挨个问“这里能不能被某类威胁利用”。回答“能/概率高”的，就是待缓解项。

七类威胁摆在一起看，各自盯的是信任链上的哪个环节，一目了然。

二、从“威胁清单”到“设计决策”

威胁建模不是终点，产出的缓解要能落到图纸：识别组件与信任边界（从外部请求进入内部内核的那道线）、明确数据流向与存储位置、决定在哪个组件上做认证/授权/加密/校验。评审架构时对照缓解是否齐备、边界是否清晰、是否遗留“无法缓解的残余风险”。

三、安全设计与架构评审要点

• 信任边界清晰：外部输入在哪进入、哪段代码可被不信任数据触达。
• 默认安全：组件默认关闭多余能力，白名单放行。
• 最小权限：应用、数据库、服务账户各按最小职责给权。
• 纵深防御：缓解不在单点，多处叠加（编码+WAF+CSP）。
• 记录残余风险：明确“设计决定容忍什么、为什么”。

四、工程实践要点

• 在高风险变更（涉及支付、身份、对外接口、海量敏感数据）上线前强制做一轮威胁建模评审。
• 把上一代发现的高危点沉淀进检查模板，避免同类设计重复犯错。
• 威胁建模结果与测试用例挂钩：每个已识别的威胁都应至少有一条对应的安全测试。
• 别把威胁建模做成“文档仪式”——结论要落到代码评审与测试里才算数。

💡 关键直觉：威胁建模的价值在“把攻击从一个猜谜变成一份清单”。遇到“该不该加一道校验”的纠结，回到建模清单查这条威胁在不在、缓解有没有，两者对齐，决策就清晰了。

五、一次完整的演练

背景：一个“上传头像”功能纳入改造，打算做威胁建模评审。操作：画数据流图，对该功能逐条套 STRIDE。结果：信息泄露（头像未脱敏对外）、篡改（改尺寸字段越界）、伪装（头像名可控可能路径穿越）等项被一一标出，连同缓解建议（白名单校验、随机命名、独立目录禁执行）写进清单。解读：设计期就把上传漏洞列全，不必等上线被扫。变式：把该清单转成对应安全测试，纳入后续回归，验证“建模 → 缓解 → 测试 → 回流”的闭环首环跑通。

六、威胁建模投入多少才合适

别把威胁建模做成“每改一行都要跑一遍”的负担。给一个分级的投入原则：低风险小改（文案、埋点）用轻量自查，对照上一轮沉淀的通用威胁清单过一遍即可；中等变更（新增接口、动了数据访问）做结构化 STRIDE 走查，产出缓解项清单；高风险变更（支付、身份、对外公开接口、大批敏感数据）必须做完整建模评审并落到设计与测试。威胁建模的粒度跟着风险走，才不至于要么不用、要么用得让人抵触——它的真正效率在于把有限的评审人日投到最值得的那几类变更上。

七、残余风险要“晒出来”而不是藏起来

建模最终总会留下一些“设计上决定暂时容忍”的风险：某接口必须兼容老协议、某字段临时明文、某第三方不可控。这些残余风险如果只是在评审会一句“先这样”带过，就再也找不回来。负责任的做法是给每一条残余风险记一张账：容忍什么、为什么容忍、计划何时解除、由谁负责跟进。这张“风险账本”挂在迭代计划里周期性翻看，防止“暂时容忍”悄悄变成“永远搁置”。毕竟威胁建模的最高价值不是清空所有威胁——那不存在——而是让每一步容忍都透明、可追溯、有人兜底。

八、把建模沉淀成下一次可用的资产

威胁建模最怕每次从零开始。上一轮已经识别过的威胁、已经趟过的高危模式，应该沉淀成一份“团队共享的威胁清单”不断累积，下次新功能评审直接拿它当起点，而不是全部重画。沉淀的方式很朴素：把历次建模标出的高频高危——注入端点落在哪、信任边界设在哪、哪些字段必经加密与脱敏——整理成 checklist，新设计先过一轮 check，再针对本期特有风险深究。如此滚动，建模从“一次性劳动”变成“可复利的资产”，团队对威胁的认知也随每次评审一起升级。反过来，每次评审挖出的新威胁又被添回清单，形成越用越厚的护城河。

本节要点回顾

• 建模投入分级：轻量自查、STRIDE 走查、完整评审按风险高低分配，把评审人日投到最值得的变更。
• 残余风险要晒账：记清容忍什么、为何容忍、何时解除、谁跟进，防止“暂时容忍”变成“永远搁置”。
• 威胁建模在设计期系统回答该防谁、防什么、在哪拦。
• STRIDE 七类（伪装、篡改、否认、信息泄露、拒绝服务、提权）是逐节点审查的体检表。
• 信任边界与数据流是建模的观察对象，缓解要落到设计与组件。
• 默认安全、最小权限、纵深防御是安全设计三原则。
• 威胁要能转成对应的安全测试，建模才不是文档仪式。