很多人被问到「数据安全有什么特点」时，只能背出保密性、完整性、可用性三个词，真到评审或者出事复盘时却对不上具体证据。这篇不背定义，而是把每个特征翻译成「出了什么问题算它坏了」「你手上有什么材料能证明它没坏」，最后给一张对照表和自查顺序，方便你拿去开会对齐口径。
很多人被问到「数据安全有什么特点」时，脑子里蹦出来的就是保密性、完整性、可用性这三个词。背是背得出，可真到了评审会或者出事复盘，拿不出对应的证据，还是对不上账。问题不在你记性差，而在于这个通用模型最早是给信息系统设计的，放到今天数据到处流转的链路里，会漏掉几块关键东西。
这篇不重新讲定义。做法是把每个特征翻译成两句人话：出了什么情况算这个特征坏了，以及你手上有什么材料能证明它没坏。最后给一张对照表和一套自查顺序，你直接拿去开会对齐口径就行。需要提醒的是，下面提到的各类工具和方案的实测情况，建议到站内工具目录核对当时的数字，别凭印象做决策。
先别急着背三个词：为什么光有保密性完整性可用性不够用
CIA 三元组是通用模型，面向的是「一个系统本身安不安全」。但现在的数据不是待在一个系统里，它要在数据库、备份、日志、外部接口、第三方工具之间来回跑。一旦数据离开你熟悉的边界，三元组就管不到那么远了。
- 可追溯性
- 数据从哪来、经过谁的手、最后落在哪，能不能串成一条完整链路
- 可控性
- 数据交出去以后，你还留不留得住话事权，能不能撤回、限用途、要求删除
- 可举证性
- 出了争议时，你手上的记录能不能当证据用，而不是只能靠当事人回忆
判断标准很简单：如果你的清单里说不出「谁在什么时候动了哪条数据」，那你的模型就是缺的，至少缺可追溯这一块。反过来说，也有不适用的时候——纯离线单机、不对外流转的小数据集，用三元组基本够，硬套全套只会把流程拖慢。
保密性：不是「加密了就安全」，而是「谁能看到什么粒度的东西」
保密性最容易被理解成「有没有加密」，但加密只是手段。真正的问题是：传输时、落盘时、被处理时，这三段分别暴露给谁。尤其是发给外部处理工具或模型接口那一刻，数据已经不在你的机房里了，这一段往往没人管。
- 传输和落盘用的加密方式，以及拿不到密钥的人能不能从密文反推出原始信息
- 脱敏的粒度够不够粗，比如把姓名去掉但保留了工号和部门，照样能对上人
- 日志和错误堆栈里有没有残留原始字段，这是最常见的漏点
- 权限是按整表给的还是按字段给的，能不能只让某类角色看到必要部分
判断标准不是「用了什么技术」，而是「拿到明文或密文的人，能不能反推出原始信息」。有一类场景不用硬套保密性：公开数据、已公告的信息，对它们强调保密反而拖慢流程。落地动作是列出每一份数据的可见人群清单，按角色去核对，而不是按文件去核对。
完整性：数据没被改动，和「改动被记录下来了」是两回事
完整性其实分两层。第一层是内容一致，数据没被偷偷改过；第二层是过程可查，就算改过，也能知道是谁在什么时候改的、改成了什么。很多人只做了第一层，校验通过就以为过关，结果真出事时只能证明「现在是对的」，证明不了「当时是对的」。
判断标准一句话：能不能在不依赖当事人回忆的前提下，还原某条数据的历史状态。如果做不到，说明你的完整性只做了一半。常见踩坑的地方有多系统同步时的覆盖写、批量脚本误更新、有人直接连数据库改字段，这三类操作最容易把痕迹抹掉。
- 标出关键字段先列出哪些字段一旦错了会影响业务判断，比如金额、状态、归属人，不用全表都管
- 加变更痕迹给关键字段带上更新时间与操作人，改之前留一份旧值，这一步比买工具划算
- 验证能不能还原随便挑一条记录，试着不靠任何人的记忆还原它三此之前的状态，还原不出来就回到上一步补
可用性：数据在，但你取不出来，一样算失效
可用性经常被简化成「服务器别挂」。但数据安全语境下的可用性更宽：权限还在不在、密钥有没有丢、接口还能不能调通、导出还跑不跑得动。任何一环断了，数据物理上还在，业务上等于没有。
最容易忽略的一环是依赖第三方服务时的情况。配额变了、限速收紧了、账号状态异常了，你的可用性就跟着动，而这些问题通常不会提前通知你。判断标准很直接：假设现在就要全量导出一次，看多久能拿到、由谁操作、中途卡在哪。
可追溯性：出事那一刻，能不能说清「数据从哪来、到哪去」
可追溯要能回答三个问题：来源是谁、中间经过哪些环节、最终落在谁的机器上。这三个问题连起来就是一条链路。很多人一看自己日志挺多，就觉得可追溯没问题，但日志多和链路完整是两码事——字段缺了关键一环，条数再多也拼不出全貌。
- 来源环节有没有记录数据是谁提供、通过什么方式进来的
- 中间处理环节有没有留下输入输出的标识，而不是只记「任务执行成功」
- 投递环节有没有记录最终去向，包括发给了哪个外部方
- 常见断点是中转或代理环节不留痕、本地批处理没有记录、跨团队靠口头交付
- 判断标准是链路完整度，能从头串到尾才算过关
有一种情况可以不追全过程：链路极短的内部一次性处理，只留结果不留过程也能接受。但前提是你要把「哪些处理属于这一类」写进说明，而不是事后拿它当借口。对外部工具和接口的调用情况，建议到站内工具目录比对当时的记录，别只信自己这边的日志。
可控性：数据交出去之后，你还留不留得住话事权
可控性管的是「交出去以后」这段。它包含三件事：能不能撤回、能不能限制对方的用途、能不能要求对方删除并给出凭证。这三件事得在给数据之前谈好，交出去之后再补，通常补不回来。
| 要确认的点 | 看什么材料 | 缺了会怎样 |
|---|---|---|
| 留存期限 | 合同或条款里的留存约定 | 对方无限期留着，你无法主张删除 |
| 用途边界 | 写清允许用于哪些目的 | 数据被拿去做你不知情的用途 |
| 删除方式 | 约定的删除动作与回执 | 要求删除时对方口头答应，事后无从核对 |
| 撤回机制 | 终止合作时的数据处置流程 | 合作关系结束，数据去向不明 |
判断标准就是这张表里的材料有没有、写没写清。最容易失守的场景是把数据交给第三方的处理工具，或者把内容直接贴进外部的对话窗口。当然，公开数据集和你主动发布的内容不适用可控性要求，这部分不必强求。
一张对照表：把六个特征翻译成你今天能查的证据
概念讲完，关键是把它们落到「能翻出来给人看的材料」上。下面这张表左边是特征，右边是对应的证据。用法是先把材料摊开，哪一格空着就先补哪一格，不要一上来就从买工具开始。
| 特征维度 | 对应的证据材料 | 判断标准 |
|---|---|---|
| 保密性 | 可见人群清单、脱敏规则文件、权限配置记录 | 拿到信息的人能不能反推原始内容 |
| 完整性 | 关键字段的变更记录、改前留档 | 能否不靠回忆还原历史状态 |
| 可用性 | 导出或恢复的演练记录、密钥和账号的托管方式 | 预设一次全量导出，多久能拿到 |
| 可追溯性 | 数据流转链路说明、各环节的处理标识 | 能否从头串到尾，中间不断 |
| 可控性 | 对外条款里的留存期限、用途边界、删除约定 | 要求删除时有没有可核对的动作 |
每个特征还要追加一句自问：这份材料是谁做的、什么时候做的、现在还能不能复现。三个问题有一个答不上来，这份证据的分量就要打折。工具和方案的横向对照，可以到站内评测页面看当时的记录，别拿旧印象当结论。
三个常见误判：别把「做了动作」当成「有了特征」
自查时最容易出现的问题，是把「我做过这件事」当成「这个特征已经达标」。做过和达标之间隔着验证这一步，而验证往往被跳过。
- 误判一：上了加密就等于保密性达标，但密钥管理没做好，等于白做一层
- 误判二：有审计日志就等于可追溯，可日志字段缺了关键信息，照样拼不出链路
- 误判三：跑过一次恢复演练就等于可用性没问题，可演练没覆盖到真实操作人就说明不了问题
排除方法其实很朴素：对每个特征追一句「证据是谁做的、什么时候做的、还能复现吗」。三个问题都答得上来，这个特征才算真的有，否则只是看起来有。一套完整的自查顺序，可以参考站内指南中心里关于数据合规自查的路径，按顺序过一遍。
下一步把上面那张对照表打印出来，先盘一遍你手头现有的材料，再决定要补什么、要不要换工具；具体方案和对比数据到站内各页面核对当时的数字，别凭记忆下判断。→常见问题
数据安全的特征到底有哪几个，最标准的是哪一套？
没有唯一权威的一套。通用模型常用保密性、完整性、可用性三块，但它偏向信息系统视角。实际做数据安全时通常会再补上可追溯性和可控性，因为今天的数据经常会交给外部服务处理。建议按你的业务链路选，能把每个特征对上一份现有材料就行。
我们公司规模很小，这几个特征都要做吗？
不必全做，但要先分清哪些数据碰不得。小团队可以先把保密性（哪些内容不能外发）和可控性（交给第三方的数据怎么约定）做扎实，完整性和可追溯性可以退化成正经的变更记录加一份链路说明，成本很低。可用性至少在关键数据上做一次导出演练。
可追溯性和日志审计是不是一回事？
不是。日志是原料，可追溯是能不能用这些原料拼出一条完整链路。很多团队日志很多，但缺来源标识或环节记录，最后还是说不清数据经过了谁。判断方法很简单：随机挑一条数据，看你能不能只靠记录还原它的完整路径。
怎么判断一个特征是不是真的达标了？
用「可举证」当标准，而不是用「有没有做过」。每个特征都问一句：如果明天要向上级或者客户证明这一点，我拿什么出来。拿不出来的，就当作还没达标。这比按清单打勾更能筛掉纸面合规。
这几个特征之间会互相冲突吗？
会。比如为了可追溯而全量留存日志，会拉高保密性风险；为了保密而过度收紧权限，又会影响可用性。处理办法不是追求全都满分，而是按数据分级分别定优先级，把取舍写下来给相关方确认，别让它在事后变成争议。
