1.1 CIA 三元组：安全目标的三根柱子

1.1 CIA 三元组：安全目标的三根柱子

本节摘要：CIA 三元组指机密性（Confidentiality）、完整性（Integrity）、可用性（Availability），是信息安全的三个根本目标。任何安全产品、策略或事件，最终都能归类为"保护了某项属性"或"破坏了某项属性"。本节给出三项属性的可操作定义、典型破坏手段对照，以及用它们拆解真实事件的方法。承接全册导读的鉴定框架，本节是坐标系的第一根轴，通往 1.2 的 AAA 行为描述。

先看一桩判例：一次数据库泄露里谁丢了什么

某电商公司的运维把一份含三百多万用户记录的数据库备份传到了公有网盘，链接没有设密码，被搜索引擎抓到后泄露。事件曝光后，公司内部对损失的描述五花八门：市场部说"用户可能流失"，法务部说"可能面临处罚"，运维主管说"备份流程有漏洞"。这些说法都对，但没法加总。

用 CIA 三元组重新切一遍，结论立刻清晰：备份文件脱离了访问控制范围，机密性被破坏；泄露后公司无法保证副本未被篡改，完整性处于存疑状态；事后应急期间该数据的主副本与灾备同步被暂停，可用性出现局部受损。三句话说完损失，法务和市场部拿到的就是同一份技术事实。

这就是 CIA 的价值：它把"出了多大事"从情绪描述变成可归类的技术事实。鉴定所给它的定位是——所有安全争议的最终仲裁标准。

验明正身：三项属性的可操作定义

机密性（Confidentiality）：信息只对授权者可见。注意定义的重心在"授权"而非"加密"——加密只是实现机密性的手段之一，访问控制、网络分段、脱敏显示同样在维护它。反过来说，一份没加密但严格限权的内网文档，其机密性可能好于一份加密后把密钥发到群里文档里"以防忘记"的设计。

完整性（Integrity）：信息不被未授权地篡改，且篡改能够被发现。这里有个容易被忽略的细节：完整性包含两层——防篡改（阻止写入）与可检测（事后能发现被动过）。文件校验和、数字签名、数据库事务约束都在服务其中一层。

可用性（Availability）：授权者在需要时能够访问信息与系统。可用性是三项里最"工程化"的一项，它的敌人不只是黑客——断电、误删、光缆被挖断、备份恢复失败同样在破坏它。这也是为什么 DDoS 攻击选它下手：不需要突破任何防线，只要把"可用"变成"不可用"。

三项属性彼此并不独立，甚至存在张力。为了可用性做的多副本设计会扩大机密性的暴露面；为了机密性做的强加密与频繁认证会拖累可用性。真实的系统从来不是三项都拉满，而是在三者之间做工程取舍——这就是为什么鉴定结论总是"看场景"。

图 1-1 三项属性与典型破坏手段对照

运作机理：三元组怎么当尺子用

拿尺子的动作分两步。第一步是归类：把事件、需求或产品功能映射到 C、I、A 的某一项上。归类时问一句话就够——"这件事发生后，是秘密泄露了、内容被改了，还是服务用不了了？"三种答案对应三项属性，两个以上同时发生就都写上。

第二步是追问实现手段。同一项属性有不同的实现路径，成本差别巨大。以机密性为例，从便宜到贵大致是：制度约束（保密协议）→ 访问控制（账号权限）→ 网络隔离（内网分段）→ 加密（存储与传输）。很多团队的错误在于直接跳到最贵的那层，用加密掩盖权限设计的混乱——密钥管理本身又成了新的机密性负担。

下面这段会话演示一个最小化的完整性校验流程。发布方先对文件计算哈希并公布，使用方下载后重算比对，不一致即说明文件在途中被篡改：

$ sha256sum app-v1.2.3.tar.gz
8f3a9c...e21b  app-v1.2.3.tar.gz     # 发布方公布在官网的指纹

$ sha256sum ~/下载/app-v1.2.3.tar.gz
77d0aa...9c3d  app-v1.2.3.tar.gz     # 与公布值不一致 → 完整性被破坏，停止安装
​

两行命令守住的是完整性，而不是机密性——哈希不保密任何内容，它只回答"变没变"。这个区分很重要：很多人把哈希当成"加密"，混为一谈的后果是该用加密的地方用了哈希（机密性裸奔），该用哈希的地方却以为加密过就万事大吉（篡改无从发现）。第 4 章会把这两个概念彻底分开。

工程实践要点：DAD 三违与取舍

与 CIA 对偶的是 DAD：泄露（Disclosure）、篡改（Alteration）、破坏（Destruction），分别对应三项属性的失败形态。做威胁建模时，正着列"我们要保护什么"往往列不全，反着列"每项属性被破坏的具体画面"反而容易穷举。安全需求说明书里写得出的画面，才是能被测试验证的需求。

⚠️ 常见坑：把可用性当成"运维的事"而踢出安全预算。2021 年前后多家机构遭遇的勒索事件里，攻击面往往是从机密性漏洞进来的（钓鱼拿凭据），最终损失却主要落在可用性上（业务系统被加密停摆）。三项属性一根绳，预算切成三段管，绳子一定在最细的那段断。

💡 关键直觉：遇到任何安全争论，先问"这动了 C、I、A 的哪一项、动多少"。能回答这个问题，讨论就在技术轨道上；回答不了，说明争论的双方手里都没有尺子。

鉴定结论

• CIA 是目标层概念：它不提供任何技术，只提供度量安全的语言；
• 三项属性彼此牵制，真实系统做的是显式取舍，取舍要写进设计文档而不是留在架构师脑子里；
• 判例归类的口诀：秘密泄露看 C、内容变了看 I、服务瘫了看 A；
• 下一节把镜头从"保护什么"转向"谁在访问"：认证、授权、审计，是三项属性在行为层面的三道闸门。

附卷：三个高频误用与快速自测

鉴定所在多年"接诊"里发现，CIA 被用错的方式比用它对的方式还多。挑三个最常见误用摆上台面。

误用一：把三元组当采购项。"我们买了 CIA 解决方案"这句话在术语层面就不成立——CIA 是目标不是产品，市面上不存在"CIA 一体机"。正确的说法是"我们为机密性买了 DLP、为完整性买了签名校验、为可用性买了双活集群"：每一项投入都该能指认它在守护哪项属性，指认不出 = 采购动机可疑。

**误用二：可用性只算在线率，不算恢复速度。**系统"一直在线"和"坏了能很快回来"是两件事。前者靠冗余，后者靠演练过的恢复流程。大量组织在线率漂亮、恢复能力为零——一断就是一天，因为从来没人练习过恢复。度量可用性时，MTTR（平均恢复时长）至少与在线率同等重要。

**误用三：完整性只防"坏人改"，不防"好人错"。**审计里最常见的完整性事故不是攻击，是误操作：脚本写错条件批量更新、手工改库漏了 where 条件。完整性设计要同时覆盖两类写入者——权限管住坏人，事务约束与变更流程管住好人。

自测一下，看尺子拿稳了没有：

五道题里若有两道归类犹豫，建议回到正文重走一遍归类口诀——秘密泄露看 C、内容变了看 I、服务瘫了看 A。