做数据安全评估时最容易卡在一句话上：威胁到底从哪来。写成清单往往是「内部人员、外部攻击、系统漏洞」一堆并列词，看着全，却判断不了先防哪个。这篇不列长表，而是给一个分层视角——人、系统、流程、第三方、环境各管什么，再给一份按数据流走一遍的盘点顺序和几个常被漏掉的判断盲区，帮你把威胁清单变成能排优先级的判断。
做数据安全评估时最容易卡在一句话上：威胁到底从哪来。很多人的清单写出来是「内部人员、外部攻击、系统漏洞」一堆并列词，看着挺全，但排不出先后，也分不清哪个该谁管。结果评估报告写了几十页，整改的时候还是拍脑袋。
这篇不给你列长表，而是给一个分层视角：人、系统、流程、第三方、环境各管什么，再给一份按数据流走一遍的盘点顺序，以及几个常被漏掉的判断盲区。目标是让威胁清单从「看起来很全」变成「能排优先级、能落到人」。
先搞清楚：为什么要按来源分威胁，而不是按风险列清单
按「泄露、篡改、丢失」这种结果来列风险，最大的问题是同一个事故会在好几个格子里重复出现。一次误发邮件，既是泄露、也可能是合规问题、还可能被算成流程缺陷，三处都写一遍，最后没人认领。
按来源分就不一样了：每一类威胁天然对应一个控制面和一个负责人。人的问题归权限和流程，系统的问题归配置和运维，第三方的问题归合同和准入。这样清单才不是给 auditors 看的摆设，而是能派活的工具。
- 按结果列风险的后果：同一个事故在多个格子里重复出现，责任分不下去
- 按来源分的好处：每类威胁都能落到具体控制面和负责人，整改有主
- 不适用的情况：纯技术渗透测试报告可以按攻击面写，但给管理层或合规用的评估不建议只按技术面切
- 自检方法：每一类威胁都问一句「谁在什么环节能碰到数据」，答不上来就说明这一类分错了
威胁的五个来源层，各自盯什么
下面这五层不是严格互斥的，边界上会有重叠，但用来分工足够清楚。盘的时候允许一条威胁同时挂两个层，但要指定一个主责层，否则又会回到没人管的状态。
| 来源层 | 主要盯什么 | 常见误判 |
|---|---|---|
| 人 | 内部误操作、越权访问、离职遗留权限、外部社工骗取凭据 | 以为靠员工安全意识培训就能解决，实际多半是权限和流程问题 |
| 系统与技术 | 配置错误、漏洞未修、密钥管理松、日志缺失 | 默认数据是被「攻破」的，其实大量事故是配错、开错、传错 |
| 流程与制度 | 审批缺位、分级不清、导出无痕、外包人员无约束 | 把制度挂在墙上，不看实际执行路径 |
| 第三方与供应链 | 中转站、SaaS、云厂商、外包开发，数据出边界后控制力骤降 | 当成外部攻击来防，实际更多是合同和留存条款问题 |
| 环境与外部 | 灾害、机房故障、监管政策变化、账号被限制后的数据可取回性 | 默认这类不可控，直接跳过不评 |
这张表建议当模板用，但别直接抄进报告。每一层都要结合自己的数据流改成具体条目，比如「人」这一层要写清楚是哪些岗位、哪些系统里有导出权限，而不是笼统写「内部人员」。
按数据流走一遍：威胁盘点的执行顺序
顺序很重要。先画流再套层，比先列威胁再找位置靠谱得多，因为威胁清单容易凭印象写，数据流是能对着系统一条条核的。
- 画数据流从采集入口、处理、存储、共享、导出到销毁，每个节点标上谁有权限、数据以什么形态停留。画完找非安全同事看一眼，看有没有节点对不上业务实际。
- 逐节点套五层每个节点问一遍：这个点上谁可能碰到数据、怎么碰到。只记录，先不评分，避免过早下结论把真实威胁过滤掉。
- 标记可控性每个威胁标成三类：自己能改配置解决的、要谈合同才能解决的、只能监测不能消除的。三类分开处理，不要混在一张整改表里。
- 统一口径回到站内 安全与合规（/safety） 分区和 安全与合规术语对照（/ai-dict/category/safety） 对齐用词，避免评估会上各说各话。
- 只给前两类排优先级能自己改的和能谈合同的优先排，监测类做成持续监控项而不是整改项，否则清单会越拉越长。
这套顺序跑完，产出应该是一张带节点、带主责层、带可控性标记的表，而不是一段段描述。如果还是描述，说明第二步套层时没有落到具体系统上。
几个常被漏掉的判断盲区
- 只看「有没有被黑」，不看「数据是否被合法地发出去」：很多风险发生在正常业务流程里，比如把样本数据贴进外部工具，流程上一路绿灯
- 把第三方等同外部攻击：供应链风险更多是合同和留存条款问题，不到出事看不出差别；具体检测口径可以到 中转站真假在线实测（/tools/verify） 和 检测口径与数据来源（/about） 核对
- 只评一次不做回访：人员、系统、供应商都在变，评估结论要带有效期，频率按团队规模和数据类型自己定，没有通用标准
- 忽略「取不回来」这类风险：账号被限制、服务下线时历史数据能不能导出，往往没人评估过，建议单独列一项
判断盲区有没有补上，有个简单办法：把评估结论拿给非安全岗位的同事看，问他「这里面哪条你觉得跟你没关系」。他说没关系的那条，多半就是漏了执行路径的那条。
威胁清单的价值不在全，在于每一条都能指到一个能改的地方和一个人。下一步带着这张分层表去核对实际在用的外部服务和工具，看数据到底流向了哪里、有没有检测记录，比在会议室里补清单有效得多。→
常见问题
威胁来源和风险点是什么关系，是不是一件事？
不是。威胁来源回答「谁或什么可能造成伤害」，风险点是「某个具体场景下威胁碰上脆弱性之后的后果」。评估时先列来源再落到场景，顺序反了容易把清单写成一堆重复词。
小团队没专职安全岗，这套分层还做得动吗？
做得动，但只做两层就够：先把数据流画出来，再重点看人的权限和第三方边界。这两块在小团队里出问题的概率最高，其余层可以先写成监控项，等规模上来再补。
第三方那一层怎么判断要不要继续用？
看三条：数据发过去之后能不能撤回或删除、对方留存多久、出了事有没有可核对的记录。三条里有一条说不清，就先别把敏感数据放进去；具体到中转站场景可到站内验真页面先跑一遍再决定。
