第二章 威胁建模入门：先搞清楚敌人长什么样
做隐私保护，最怕什么？最怕你连要防谁、防什么都不知道，就开始堆技术。我见过太多团队，上来就上加密、上防火墙，结果核心数据还是被拖走了。为什么？因为没做威胁建模。
威胁建模说白了就是——在坏人动手之前，你先模拟一遍他会怎么搞你。这一章，我们就把这件事聊透。
2.1 识别资产：你到底要保护什么？
很多人一上来就问“用什么加密算法”，我通常会反问一句：你的资产是什么？ 你连要保护的东西都没列清楚，谈什么保护方案？
在设备级隐私保护场景里，资产通常分三类：
| 资产类别 | 具体例子 | 泄露后果 |
|---|---|---|
| 用户身份数据 | 设备ID、IMEI、MAC地址、账户Token | 用户被追踪、账号被盗 |
| 生物特征数据 | 指纹模板、人脸特征向量、声纹 | 不可逆的隐私泄露 |
| 行为与偏好数据 | 位置轨迹、使用习惯、传感器数据 | 用户画像被滥用 |
我的习惯： 每次做新项目，我会先拉一张资产清单表，按“机密性、完整性、可用性”三个维度打分。分数最高的那几项，就是威胁建模的重点对象。
2.2 识别威胁源：谁想搞你？
资产列清楚了，接下来要问：谁会对这些资产感兴趣？
我遇到过不少开发者，觉得威胁源就是“黑客”。其实远不止这么简单。我把常见的威胁源分成四类：
- 外部攻击者： 远程黑客、恶意软件作者。他们想窃取数据、控制设备。
- 内部人员： 有权限的员工、第三方运维。我见过一个案例，内部运维把数据库备份文件拷走了。
- 物理接触者： 设备丢失/被盗后的捡到者。嗯，这个场景在IoT设备里特别常见。
- 应用/服务提供商： 你集成的第三方SDK、云服务商。他们可能过度收集数据。
避坑指南： 我曾经在一个项目中，只考虑了外部黑客，完全没管第三方SDK。结果上线后发现，某个广告SDK在后台偷偷上传了用户的WiFi列表。从那以后，我把“第三方组件”也列入了威胁源清单。
2.3 STRIDE威胁模型：微软的六把刀
资产和威胁源都清楚了，怎么系统化地找漏洞？我推荐用微软的STRIDE模型。这六个字母分别代表六类威胁：
| 字母 | 威胁类型 | 通俗解释 | 设备端例子 |
|---|---|---|---|
| S | Spoofing（假冒） | 冒充别人身份 | 伪造设备ID接入服务器 |
| T | Tampering（篡改） | 修改数据或代码 | 篡改固件中的隐私策略 |
| R | Repudiation（抵赖） | 做了不承认 | 用户否认发起过某次数据上传 |
| I | Information Disclosure（信息泄露） | 不该看的看到了 | 日志中打印了明文密码 |
| D | Denial of Service（拒绝服务） | 让服务不可用 | 耗尽设备电池或网络带宽 |
| E | Elevation of Privilege（权限提升） | 拿到更高权限 | 普通App获取了Root权限 |
我个人习惯，每次画完数据流图后，就拿着STRIDE这六把刀，一刀一刀地砍过去。每个数据流、每个处理节点，都问一遍：这里能不能假冒？能不能篡改？能不能泄露？
实战技巧： 别试图一次性覆盖所有威胁。我通常先关注S（假冒）和I（信息泄露），因为这两个在设备端隐私保护里最常见。其他四个可以后续迭代。
2.4 绘制数据流图：把系统画出来
威胁建模不能光靠脑子想，你得把系统画出来。数据流图（DFD）就是干这个的。它帮你理清：数据从哪来、经过谁、存到哪、谁在处理。
下面这张图，是我做的一个智能家居设备的数据流图简化版。你看一眼就明白了：
画完这张图，你再拿STRIDE去套：
- 用户App到设备固件的指令流——会不会被假冒？（S）
- 设备固件上传到云的数据——会不会被篡改？（T）
- 本地存储的密钥——会不会被泄露？（I）
你看，威胁一下子就具体了。
我的经验： 数据流图不用画得太细。第一版能画出5-8个核心节点就够了。画太细反而容易迷失在细节里，忘了整体威胁。
2.5 把威胁建模变成习惯
最后说一句。威胁建模不是一次性的工作。每次迭代、每次加新功能、每次引入新SDK，都应该重新跑一遍这个流程。
我见过最惨的案例，是一个团队在产品上线前才做威胁建模，结果发现架构有根本性缺陷，不得不重写。那感觉，就像房子盖好了才发现地基打歪了。
所以，从现在开始，把威胁建模当成你设计系统时的肌肉记忆。画图、列资产、套STRIDE、找威胁。这套动作做熟了，你的系统天然就会比别人硬气。