1. 概述
威胁建模是一种结构化的安全分析方法, 用于在设计阶段系统性地识别、分类和评估潜在安全威胁。通过威胁建模, 开发团队可以在编写代码之前理解系统面临的攻击面, 并设计相应的缓解措施。这是SDL设计阶段最重要的安全活动之一。
2. STRIDE 方法论
STRIDE 是 Microsoft 提出的威胁分类模型, 将安全威胁分为六个类别。每个类别对应一种特定的安全属性违反:
| 威胁类别 | 全称 | 违反的安全属性 | 典型示例 |
|---|---|---|---|
| S | Spoofing (欺骗) | 认证 (Authentication) | 伪造用户身份、IP欺骗、证书伪造 |
| T | Tampering (篡改) | 完整性 (Integrity) | 修改传输数据、SQL注入、参数篡改 |
| R | Repudiation (抵赖) | 不可否认性 (Non-repudiation) | 否认执行过某操作、日志被删除 |
| I | Information Disclosure (信息泄露) | 保密性 (Confidentiality) | 数据泄露、错误信息暴露、侧信道攻击 |
| D | Denial of Service (拒绝服务) | 可用性 (Availability) | 资源耗尽、放大攻击、逻辑DoS |
| E | Elevation of Privilege (权限提升) | 授权 (Authorization) | 垂直越权、水平越权、容器逃逸 |
3. 数据流图 (Data Flow Diagrams)
数据流图 (DFD) 是威胁建模的基础工具。通过可视化系统中的数据流动, 识别信任边界和潜在攻击点。DFD 使用四种基本元素:
- 外部实体 (External Entity) - 系统边界外的交互方, 如用户、第三方服务
- 进程 (Process) - 数据处理单元, 如 Web Server、API Gateway
- 数据存储 (Data Store) - 持久化存储, 如数据库、文件系统、缓存
- 数据流 (Data Flow) - 元素之间的数据传输, 如 HTTP 请求、数据库查询
在DFD上标注信任边界 (Trust Boundary)至关重要。每当数据流跨越信任边界时, 都需要进行安全检查。常见的信任边界包括: 外网与内网之间、应用层与数据库层之间、不同权限级别的组件之间。
4. 攻击树 (Attack Trees)
攻击树是一种从攻击者视角分析威胁的建模方法, 由 Bruce Schneier 于 1999 年系统化提出。其结构为:
- 根节点: 攻击目标 (如"获取管理员权限")
- 子节点: 达成目标的不同路径 (OR关系) 或必须同时满足的条件 (AND关系)
- 叶节点: 具体的攻击行为
攻击树的优势在于可以为每条路径标注成本、难度和概率, 从而量化评估不同攻击路径的风险等级, 指导缓解措施的优先级排序。
5. 微服务架构的威胁建模
5.1 微服务特有挑战
微服务架构引入了分布式系统的复杂性, 使威胁建模面临新的挑战:
- 攻击面扩大: 每个服务都有独立的 API 端点, 服务间通信增加了内部攻击面
- 信任边界模糊: 服务间是否互相信任? East-West 流量的安全策略往往被忽视
- 依赖链风险: 一个服务被攻破可能级联影响整个系统
- 身份传播: 用户身份在服务调用链中如何安全传递和验证
5.2 应对策略
- 零信任网络: 服务间通信默认不信任, 使用 mTLS 进行双向认证
- Service Mesh: 使用 Istio/Linkerd 统一管理服务间安全策略
- API Gateway: 集中认证和限流, 减少每个服务的安全负担
- 分段建模: 对每个微服务单独进行威胁建模, 再分析服务间交互的威胁
6. 威胁建模的实施流程
6.1 准备阶段
收集系统架构文档、部署图、API 规范和数据分类信息。组建建模团队, 应包括架构师、开发负责人、安全工程师和产品经理 (了解业务上下文)。
6.2 建模阶段
绘制 DFD, 标注信任边界, 使用 STRIDE 对每个元素和数据流逐一分析潜在威胁。建议使用白板或建模工具进行协作, 鼓励团队成员从不同角度提出威胁场景。
6.3 评估与排序
使用 DREAD 或 CVSS 等评分模型对已识别的威胁进行风险评估。DREAD 评估维度包括:
- Damage - 攻击造成的损害程度
- Reproducibility - 攻击的可复现性
- Exploitability - 攻击的难度
- Affected Users - 受影响的用户范围
- Discoverability - 漏洞被发现的难度
6.4 缓解与验证
为每个高风险威胁制定缓解措施, 将其转化为安全需求纳入开发计划。缓解策略包括: 消除 (Eliminate)、迁移 (Transfer)、缓解 (Mitigate) 和接受 (Accept)。在后续的验证阶段, 需确认缓解措施已正确实施。
7. 小结
威胁建模的价值在于将安全思维系统化。它不要求团队中每个人都是安全专家, 而是通过结构化的分析框架, 帮助开发团队有序地思考安全问题。建议在每个重大版本和架构变更时执行威胁建模, 并将结果作为安全设计文档的一部分持续维护。