2、威胁建模与风险分析：STRIDE模型、数据资产分类、风险矩阵评估方法
做存储安全，第一件事不是买防火墙，也不是写加密代码。
而是搞清楚一个问题：你到底在防谁？防什么？
我见过太多团队，上来就堆安全工具，结果核心数据裸奔，边缘接口却锁得死死的。说白了，方向错了，投入再多也是白搭。
这一章，我们就来聊聊威胁建模和风险分析。这是整个安全架构的“地基”。地基没打牢，后面全是空中楼阁。
2.1 威胁建模：用STRIDE给系统“体检”
威胁建模不是玄学，是一套结构化的分析方法。我个人习惯用微软提出的STRIDE模型，它把威胁分成六类，覆盖了绝大多数攻击场景。
| 威胁类型 | 英文 | 核心问题 | 存储场景举例 |
|---|---|---|---|
| S 假冒 | Spoofing | 别人能不能假装是你？ | 伪造API密钥写入存储桶 |
| T 篡改 | Tampering | 数据在传输或存储中能被改吗？ | 中间人修改备份文件内容 |
| R 抵赖 | Repudiation | 做了坏事能赖账吗？ | 删除日志后否认操作 |
| I 信息泄露 | Information Disclosure | 敏感数据能被不该看到的人看到吗？ | 数据库备份文件权限配置错误 |
| D 拒绝服务 | Denial of Service | 系统能被搞瘫痪吗？ | 大量请求打满存储IOPS |
| E 权限提升 | Elevation of Privilege | 普通用户能拿到管理员权限吗？ | 利用存储系统漏洞提权访问其他租户数据 |
我的习惯：每次做新系统的威胁建模，我都会拿这张表逐项过一遍。别嫌麻烦，漏掉一项，可能就是一次严重的安全事件。
具体怎么做？我一般分四步走：
- 画数据流图——把系统里的数据流向、存储节点、信任边界画出来。这是基础，画不清楚后面都是瞎猜。
- 逐项套STRIDE——对数据流图里的每个元素，问自己上面那六个问题。比如“这个存储节点有没有假冒风险？”
- 记录威胁清单——把识别出的威胁记下来，包括威胁描述、影响范围、可能触发条件。
- 初步排序——先凭经验把明显的高危项标出来，后面再用风险矩阵精确定量。
注意：威胁建模不是一次性工作。系统架构变了、业务场景变了，都要重新过一遍。我曾经见过一个团队，三年前的威胁模型还在用，结果新加的分布式存储节点完全没覆盖到。
2.2 数据资产分类：先搞清楚你要保护什么
你想想看，如果连自己家里有什么值钱东西都不知道，你怎么决定锁哪扇门？
数据资产分类就是这个道理。我建议按敏感程度和业务影响两个维度来分。
| 等级 | 定义 | 典型数据 | 存储要求 |
|---|---|---|---|
| L1 公开 | 泄露无影响 | 产品宣传资料、公开文档 | 基本访问控制 |
| L2 内部 | 泄露有轻微影响 | 内部培训材料、非敏感运维日志 | 身份认证 + 访问审计 |
| L3 敏感 | 泄露有较大影响 | 用户个人信息、业务配置 | 加密存储 + 细粒度权限 + 审计 |
| L4 机密 | 泄露有严重影响 | 支付密钥、用户密码、核心算法 | 硬件加密 + 严格隔离 + 多人审批 |
这里有个坑，我踩过。曾经有个项目，我们把所有数据都标成了L3，觉得这样最安全。结果呢？开发效率直线下降，每次读个配置文件都要走审批流程。后来我们重新梳理，把真正需要保护的核心数据挑出来，其他降级处理，事情才顺了。
核心原则：分类的目的是差异化保护。不是所有数据都需要银行级安全，也不是所有数据都可以裸奔。找到那个平衡点，才是本事。
2.3 风险矩阵评估：把威胁变成可量化的数字
威胁清单有了，数据分类也做了，接下来就是评估风险。我常用的工具是风险矩阵。
风险 = 可能性 × 影响程度
就这么简单。但怎么定义“可能性”和“影响程度”，需要结合你的业务场景。
| 等级 | 可能性描述 | 影响程度描述 |
|---|---|---|
| 1 很低 | 几乎不可能发生，需要多重条件同时满足 | 轻微数据泄露，无业务影响 |
| 2 低 | 有理论可能，但实际很难触发 | 少量非敏感数据泄露，可快速恢复 |
| 3 中 | 有一定概率，历史上出现过类似案例 | 部分敏感数据泄露，业务受影响数小时 |
| 4 高 | 容易触发，常见攻击手段 | 大量敏感数据泄露，业务中断一天以上 |
| 5 很高 | 几乎必然发生，或已有公开漏洞 | 核心数据全部泄露，业务瘫痪，法律诉讼 |
然后，把每个威胁的“可能性”和“影响程度”相乘，得到风险值。我一般这样划分：
- 1-6分：低风险——接受或监控，定期复查
- 7-14分：中风险——制定缓解措施，限期整改
- 15-25分：高风险——立即处理，不解决不上线
避坑指南：我曾经犯过一个错误——把所有威胁都打成了中风险。为什么？因为怕打低了出事，打高了又显得自己无能。结果就是，中风险清单太长，根本分不清优先级。后来我强制自己：每个威胁必须给出具体理由，不能凭感觉打分。
2.4 本章知识体系总览
下面这张图，把本章的核心逻辑串起来了。你可以把它当作一个检查清单，每次做威胁建模时对照着走一遍。
2.5 实战小贴士：别让模型变成纸上谈兵
理论说完了，说点实际的。我见过太多团队，威胁模型做得漂漂亮亮，PPT能讲两个小时，结果一上线该出问题还是出问题。
为什么会这样？因为模型和现实脱节了。
- 别假设攻击者很笨——你想到的防御，攻击者可能早就研究透了。多想想“如果我是攻击者，我会怎么绕过这个控制？”
- 别忽略内部威胁——很多数据泄露不是外部黑客干的，而是内部员工误操作或恶意行为。STRIDE里的“假冒”和“抵赖”就是针对这个。
- 定期复盘——我每季度会拉上运维和开发，花半天时间重新过一遍威胁模型。别等到出了事才想起来。
一句话总结：威胁建模不是交作业，是帮你提前发现坑。风险分析不是算数学题，是帮你把钱花在刀刃上。