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

企业安全岗最怕的不是「有威胁」，而是说不清威胁从哪来——老板问一句「我们数据到底危险在哪」，只能答「黑客、内鬼、系统漏洞」三件套。这篇把外部攻击、内部人员、供应链、AI 用法、流程与制度缺陷、物理与环境因素拆成一张可勾选的清单，顺带给一套按影响面排序的排查顺序，让你在写风险评估报告或开安全会时能直接对着讲。

安全岗被老板问「我们数据到底危险在哪」，最怕的是只能回一句「黑客、内鬼、系统漏洞」。这三件套没错，但既没法排优先级，也没法写进评估报告。真正能用的是把威胁拆成一张可勾选的清单，每一条都能落到「谁、通过什么路径、能碰到哪份数据」。

下面把外部攻击、内部人员、供应链、AI 用法、流程制度、物理环境六类因素摊开，再给一套按影响面排序的排查顺序。写风险评估、开安全会、给业务方讲风险时，可以直接对着这张清单往下点。

先把「威胁」拆成可勾选的项，而不是一句口号

清单的价值在于能开会、能写报告、能排优先级，不在于概念背得多全。每一项都要能被追问三句：来源是谁、走哪条路径、最后碰到哪份数据。答不上来的条目，要么是分类太粗，要么是根本没调研过自己的现状。

建议用两轴交叉来分类：一轴是来源（内部还是外部），另一轴是载体（人、系统、流程、物理环境）。两轴一交叉，漏项会少很多。同一件事经常跨类，比如供应商账号被撞库，既是外部攻击也是供应链问题，归类时以「谁最先能发现」为准，别纠结。

• 用途一：写风险评估报告时当检查表，逐条标「有/无/部分」
• 用途二：开安全会时当议程，按节过一遍，逐节定负责人
• 用途三：排整改优先级时当打分表，按影响面和发生概率给权重
• 不适用的情况：只做单点技术加固、不打算做整体评估时，这张清单会显得过重，取其中两三节就够

外部因素：攻击面、凭据与自动化撞库

外部威胁最常见的问题不是「防不住高手」，而是「不知道自己还开着什么」。公网接口、后台入口、测试环境、对象存储桶、第三方回调地址，很多事故出在「没人记得还在跑」的旧服务上。先盘清暴露面，比急着上设备有用。

凭据类是另一大块：撞库、钓鱼、API Key 泄露后被扫到。自查动作可以先按 /key-leak-self-check 的做法跑一遍，看有没有 Key 出现在不该出现的地方。自动化扫爬和批量探测通常先于真实入侵出现，日志里表现为同段 IP 反复打同一路径，别只当噪声过滤掉。

内部因素：权限、离职与「顺手方便」

内部威胁不必然是恶意。越权访问、共用账号、把数据导到本地做分析，都是高频诱因，而且多数人觉得自己只是在「顺手把活干完」。正因为动机不坏，这类问题更难靠制度口号压住，只能靠权限设计和日志归因。

重点盯三个时点：入职开权限、转岗换职责、离职交接口。交接清单可以参照 /key-rotation-least-privilege 的思路，核心是「权限跟着职责走，不跟着人走」。共用账号最大的危害不是被偷，而是日志失去归因能力，出事时查不出是谁做的，这一点比「被谁偷了」更常拖慢处置。

1. 拉两张表一张是「当前有权限的人」，一张是「近半年实际调用过的人」，都从系统里导出，别靠记忆。
2. 做差集两张表的差集就是「有权限但没用」的账号，差集越大越要问原因，通常能找到僵尸权限。
3. 定三个时点规则入职、转岗、离职各写一条可执行动作，比如离职当天回收哪些权限、谁签字确认。
4. 验证随机抽一个近期转岗的人，看他的权限是否真的按新职责调整过，还是新旧叠加。

供应链与第三方：你控制不了的那一段

第三方包括云厂商、模型 API、中转站、外包开发、SaaS 工具。每一家都要问清三件事：数据流向哪、留存多久、能不能删。答不上来的供应商，就是一份说不清的风险。接入中转类服务前，先核对该站是否在 /sites 目录内有记录、是否有可查的口径说明，别只看速度和价格。

合同与条款层面，至少要能回答「数据出境了吗、走了哪条路径」。路径判断可以对照 /data-export-compliance-paths 的梳理，把常见路径过一遍，再看自己踩了哪几条。供应商换了底层实现却不通知你，也是常见情况，所以口径要写进合同而不只是口头确认。

• 数据流向：从哪进、经过谁、最后存哪
• 留存时长：默认存多久、能不能按需删
• 访问方：供应商内部哪些角色能看
• 变更通知：底层实现或子处理方变化时是否告知
• 退出机制：停止合作后数据怎么导出和销毁

AI 用法带来的新增因素：提示词、日志与幻觉

把数据发给外部模型，本质是一次对外披露。先明确哪些字段绝不能进提示词，原则部分看 key-safety，这里只做执行层检查：输入侧有没有脱敏、输出侧有没有回传、会话记录存在哪里、谁能看。很多团队只盯输入，忘了会话和调试日志会把敏感内容一起带走。

模型输出本身也可能成为风险源。把幻觉内容当成事实写进对外文档或代码，属于数据质量与决策层面的威胁，虽然不直接泄露数据，但会让错误结论以「有依据」的样子扩散。判断边界：如果用完全离线私有部署，这一节的网络类风险下降，但内部权限与日志问题照旧存在。

流程与制度缺陷：最容易被忽略的一类

典型表现是：没有数据分级、没有审批就直接导出、没有变更记录、出事找不到责任人。这一类不像漏洞那样能扫描出来，只能靠抽查真实操作来验证，所以最容易被评估报告漏掉。

制度文件写得再全，只要没人执行就等于没有。检查方式是随机抽三笔真实操作，看能否还原出完整的审批链。评估时把「机制缺失」和「机制存在但没人用」分开记，前者的整改成本是建流程，后者是改习惯，完全两回事。自查项可以从 /enterprise-data-security-selfcheck 的口径拆，但别照抄，要按自己业务裁剪。

• 有没有数据分级，不同级别对应不同审批
• 导出和分享是否有留痕，能否追溯到人
• 变更是否有记录，谁改的、什么时候改的
• 责任是否到岗到人，出事第一个找谁
• 流程是否被实际执行，抽三笔操作验证

物理与环境：小概率但难恢复

设备丢失、维修送修、报废未擦盘、办公区随手拍屏幕，这些都属于物理路径的数据外泄。概率不高，但一旦发生往往无法收回，处置难度比线上事件更大，因为「已经出去了」这件事没法撤销。

备份与容灾不算「威胁」本身，但备份被勒索软件一起加密时，它就从防线变成了同案受害者。所以备份要单独做权限隔离和离线副本，别和主系统共用一个管理入口。不适用的情况：全部跑在合规机房且无本地终端的团队，这一节可以压缩成一条设备管理要求。

1. 给移动设备定规则加密、开机密码、丢失上报时限，写清楚谁负责登记。
2. 给维修定流程送修前是否拆盘、是否有人陪同、维修方是否签保密条款。
3. 给报废定动作擦盘或销毁要有记录，保留序列号和操作人。
4. 验证随机抽一台近期报废的设备，看有没有擦除记录，能不能查到经手人。

按影响面排序的排查顺序与报告写法

排序建议：先排「已经发生过」的迹象，比如异常登录、外传记录；再排「暴露在公网且无人管」的资产；最后排纯理论风险。这个顺序的好处是先处理有证据的，避免一上来就在低概率场景上耗资源。

排查顺序模板：凭据与权限、对外暴露面、第三方数据流向、日志与留证、制度执行抽查、物理与环境。报告里每条威胁写清四要素：来源、路径、受影响数据范围、现有控制手段，别只写风险名称。留证与举证的动作可以参考 /dispute-evidence-keep，重点是把时间点、操作人、原始截图和账单对应上。

威胁清单的作用不是把风险列全，而是让每一条都能找到负责人和下一步动作。