威胁数据安全的主要因素有哪些

做数据安全的人常被问一个问题：到底哪些东西在威胁我们的数据？答案往往被答成一份模糊的风险列表，落不到自己系统上。这篇换个做法：先把威胁因素按来源分层，再按数据流经的环节定位，最后给一套能每周跑的自查顺序。适合手里管着日志、权限、接口和三方接入的人，用来把「风险很多」变成「这周先查哪三条」。

做数据安全的人常被问：到底哪些东西在威胁我们的数据？多数回答会背出一串名词——泄露、越权、勒索、供应链，听着都对，落到自己系统上却不知道从哪查。问题不在名词不够，而在这份清单没有绑上触发条件，也没有告诉你先看哪个。

换个做法：先把威胁因素按来源分层，再按数据流经的环节定位，最后给一套能每周跑的自查顺序。下面每一节都带观察指标和验证动作，你可以直接对着自己的系统勾。适合手里管着日志、权限、接口和三方接入的人，用来把「风险很多」变成「这周先查哪三条」。

为什么「威胁因素清单」抄了也没用

通用清单只列名词，不列触发条件。同样是「越权访问」，在一个五个人的小团队里可能只是共享账号被两个人同时用，在一个几十人的研发团队里则是角色没收敛、离职账号没停用。触发条件不同，你该看的日志字段、该问的人、该改的配置都不一样，抄来的名词对不上号，排查时就无从下手。

所以威胁要按来源分类来看：有权限的人、被托管的系统、走过网络、业务本身。四类混在一起看，最容易漏的是内部误用——它既不像攻击那样有异常流量特征，也不像合规问题那样有明文条款，往往就藏在一次正常的导出操作里。

同一类因素在不同数据形态上表现完全不同。结构化库看的是权限和审计，日志看的是写入方和留存，模型调用记录看的是请求体里夹带了什么。清单必须跟数据形态绑定，否则你查了库、漏了日志，等于没查。

人为因素：有权限的人才是最大变量

人为因素里至少分三类：越权访问、配置失误、主动带走。越权不是黑客行为，常常是岗位变动后旧权限没回收；配置失误最典型的是把对象存储或数据库快照设成公开可读；主动带走多在离职前后出现，表现为异常时段的高频导出。

• 权限变更记录：近一个月新增和变更的授权，逐条问为什么加，加完有没有人复核
• 异常时段导出：非工作时段、单账号短时间内的大批量取数，按账号和数据范围拉出来看
• 岗位与权限对照：这个人当前负责什么，实际能碰到的数据范围有没有超出岗位本身
• 共享账号：小团队常靠一个账号跑所有事，至少记录谁在什么时间用它做过什么

不适用情形要说清：小团队没有独立权限系统时，先别硬凑审计字段，用共享账号的登录日志加上人工确认代替。强行给一个没有 RBAC 的系统补审计，往往补出一堆没人看的日志，反而掩盖了真正该盯的那几个账号。

系统与供应商因素：你控不住的那一段

自建系统的问题相对好查：补丁滞后、备份文件可读、测试环境直接灌生产数据。这三条的共同点是你能改。真正难的是供应商那一段——数据交出去之后，留存多久、会不会二次使用、有没有再转给下一家，全看合同怎么写。

判断标准很直接：合同里有没有写清留存期限、删除方式、子处理者告知义务。没写，就等于默认按对方方便来。到时候你去问，对方说「我们的隐私政策里写了」，而那份政策随时可改，你手里没有可主张的条款。

留存期限

数据在对方那里放多久，到期是自动删还是等你要

子处理者

对方把数据转给哪些下游，转之前要不要通知你

二次使用

除提供服务外，对方能不能拿去训练或做分析

删除证明

删除后有没有可核验的回执，而不是一句已删除

聊这些条款时，别用自己的叫法跟对方对，容易各说各话。到站内 /safety 和 /ai-dict/category/safety 对照一遍安全合规术语的口径，把留存、删除、子处理者这些词先对齐，再看合同草稿。

网络传输因素：被截、被仿、被记录

网络这一层有三类典型问题：明文传输被截获、中间人伪造端点、链路上被代理记录。前两类靠加密和证书校验能挡一部分，第三类最难，因为代理在你自己的架构里，流量看着正常，内容却多留了一份。

1. 抓一次真实请求用抓包或日志回放的方式，看请求从发起到落地是否全程加密，有没有中途出现明文段落。验证方式：换一个网络环境再抓一次，比对两次的端点是否一致。
2. 查证书链确认客户端校验的是真实端点证书，而不是被替换过的中间证书。验证方式：看是否出现自签证书或未登记的中转节点。
3. 列出中间层把网关、代理、日志采集、监控探针逐个登记，问每一层是否留存报文。验证方式：对照登记表与抓到的实际链路，多出来的就是没登记的。

别只看对方宣传页上写「已加密」。到 /tools/verify 看当前站点的实测口径，那里讲的是怎么验证而不是怎么宣称。判断标准：你能自己复现一次链路检查，才算这一层有底。

模型与数据管道因素：提示词、缓存、日志

接入模型之后，数据多走了几段路。提示词里夹带的敏感信息会进请求体、进缓存、进日志，这三处的留存期限往往由不同的人决定，也不一致。你按最短的那个去承诺删除，实际删不掉最长的那处。

向量库和检索层更容易被忽略。文档切分之后，原文和片段是两份东西，你删了原文，片段可能还在索引里；重新切分一次，又生成一批新的。片段的可检索性让残留比原文更难清理。

顺序建议：先弄清日志到底记了什么，再决定哪些字段必须在入口脱敏。到 /relay-logging-privacy 把日志口径看明白，比事后逐条删有效得多。判断标准是——你能不能说出一个敏感字段从进入到落库经过了哪几个位置。

合规与流程因素：不是技术问题但会放大技术问题

无授权采集、超范围使用、出境未评估，这三类本身不是技术漏洞，但会把一次技术层面的泄露升级成监管事件。技术上同样的错误，有没有授权、有没有评估，处理结论完全不同。

落地只看两件事：数据地图有没有更新到新增的接口，处理目的是否与当初告知用户的一致。新接口上线时最容易漏更地图，结果数据流出去半年，地图上还是老样子。目的不一致则是隐性风险，用户同意的是甲用途，你后来拿去做乙用途，哪怕数据没泄露也站不住。

涉及跨境时，先到 /guides/data-export-path-choice 对一遍路径再动手，别先传后补。不适用情形：如果数据全在境内、无外部调用、也没有第三方处理者，这一节的评估动作可以简化，但数据地图和目的记录仍要留。

一周自查顺序：先查哪三条

威胁因素列全了，接下来是排序。排错的代价是：你把时间花在整改最容易的地方，而最不可逆的地方一直没人看。下面这个顺序按「不可逆程度」排，一周能跑完一轮。

1. 第一步 查出口把所有把数据发出去的地方列出来：对外接口、模型调用、三方工具、报表导出。逐个登记目的地和字段。验证方式：拿这份登记表跟实际出网流量比对，多出来的就是漏登记的。
2. 第二步 查权限近一个月新增的账号和权限变更，逐条问为什么加、有没有复核。验证方式：随机抽几条，找申请人自己复述用途，说不清的先收回。
3. 第三步 查留存缓存和日志的实际保存时长，跟制度里写的对不对得上。验证方式：直接看存储上的实际对象和过期配置，不看文档。

顺序理由：出口最不可逆，数据出去就收不回；权限最容易失控，加的时候一句话，收的时候没人记得；留存影响面最广，但也是最容易统一整改的一项，放最后做收益最大。小团队如果一周跑不完，先保住第一步和第二步。

这套排查不适用的情况

不是所有场景都值得按这个顺序走。数据量小、全在内网单机、无外部调用的场景，按上面三步会过度投入，简化成权限加备份两项就够，重点看谁能登录和备份能不能恢复。

• 已发生泄露时不要按本文顺序，先止损再排查，止损流程看本分区的时间线类文章
• 多方共管同一份数据时，先划分责任边界再排查，否则查到的问题没人认领
• 纯离线、无第三方处理者的系统，合规那一节可简化，但数据地图仍要维护
• 刚上线的系统，先跑出口和权限两步，留存策略等业务稳定后再收敛

排查的价值不在列全威胁，而在排出多数人认同的那个先后——先做不可逆的，再做工作量大的。