波仔
🛡️ 第一章 信息安全的基本概念
📄 一句话概括

信息安全的三个基本目标——机密性、完整性、可用性（合称 CIA）；三者不是并列的清单，而是三个不同的失效方式，其中最晚被发现的往往是机密性。

📝 本节和前面几节的关系

前面三节看的是"危险从哪来"（威胁的分类）和"人为什么会动手"（出现内部违规的原因）。这一节换一个坐标轴：不看威胁来自哪里，看它把什么弄坏了。

这样一来，前面那些零散的例子就能归位了：泄露客户名单破坏的是机密性，篡改金额破坏的是完整性，网站打不开破坏的是可用性。三要素是全课的通用坐标——后面每一节讲措施时，都会回到"它在保哪一个"。

一、三个词，三句话

要素 一句话 出事时的样子
机密性（C） 不该看的人看不到 资料被拷走、被偷看、被泄露
完整性（I） 不该改的没被改 数字被改、记录被替换、指令被篡改
可用性（A） 该用的时候能用 系统打不开、服务中断、数据取不出

英文首字母合起来是 CIA（Confidentiality / Integrity / Availability）。这个缩写容易让人联想到别的东西，但在安全领域它只指这三样。

三个定义里都藏着"相对性"，这一点必须讲清：

记住这个"相对性"，可以避开很多无效讨论。比如有人问"数据要不要加密"，正确答案不是"要"或"不要"，而是"谁能看、通过什么方式看"。

二、机密性：最晚被发现的那一个

三要素里，机密性的失效方式最特别：

数据被拷走一份，原系统不会少一根毫毛，性能不掉、功能不缺、日志里可能只有一行普通记录。也就是说：

机密性事故是"先发生在别人那里"的——你在对方开始使用它之后，才知道它没了。

这个特性直接决定了两件事：

  1. 机密性必须靠"事前"守——权限、加密、最小化。等发现的时候，事情已经发生完了。
  2. 机密性的防护效果很难验证——不像可用性可以压测，你没法"测一下数据有没有被偷走"。所以它更依赖制度与审计，而不是临时检查。

三、完整性：破坏的是"信任"

完整性的特殊之处在于：它保护的是你对数据的信任。

一个数字被改了，损失不只是"这个数字错了"，而是"我以后还敢不敢相信这套系统里的数"。

所以完整性事故的典型后果是连锁的：

完整性的技术手段也比较特别，它的核心是"能不能发现改动"，而不是"能不能阻止改动"——因为完全阻止改动很难，而让改动无法隐藏是可做到的：校验值、哈希、数字签名、版本记录、审计日志，都属于这一类。

一句话：完整性防不住"改"，但可以做到"改了你就瞒不住"。

四、可用性：唯一能被"善意"破坏的要素

可用性事故有一个别处没有的特点：它常常不是攻击造成的，而是自己造成的。

也就是说，可用性是三要素里唯一"正常操作也经常破坏"的一个。这带来两个推论：

  1. 可用性的设计必须考虑"操作失误"，不只是"恶意攻击"。变更前的备份、分步发布、可回滚，都是可用性措施。
  2. 可用性有很大的"成本项"性质——要更高可用性，就要更多冗余，成本上升很快。所以可用性目标通常写成"分级"的：核心系统要求极高，边缘系统可以接受短暂中断。

五、三要素会打架

最后要讲的是最实用的一点：三个目标之间经常互相冲突。

冲突 现象
机密性 vs 可用性 加密越严，取用越麻烦；审批越多，响应越慢
完整性 vs 可用性 数据要校验、要复核，就必然变慢；严到极致就没人用
机密性 vs 完整性 过度保密会让审计看不到内容，反而查不出改动

没有"三样都拉满"的方案。任何一套安全措施，本质上都是在三者之间选一个位置。这也是下一节（成本、便利性、安全性的考量）要接着讲的内容——把它变成一笔能算的账。

六、动手 Demo：安全事件的三要素归因器

下面这个 Demo 用多标签方式给 10 个事件归因，并回答一个问题：三要素里，哪一个被破坏时最难被立刻发现？

def tag(c, i, a):
    out = []
    if c:
        out.append("机密性")
    if i:
        out.append("完整性")
    if a:
        out.append("可用性")
    return out     # 一个事件可以同时破坏多个要素

实跑输出：

==============================================================================
一、逐事件归因（一个事件可以同时破坏多个要素）
==============================================================================
  编号  事件                                    C   I   A   归到哪几个要素
  --------------------------------------------------------------------------
  E01   客户数据库被拖走                        ●   ·   ·   机密性
  E02   转账金额被改成别的数                    ·   ●   ·   完整性
  E03   网站被打瘫三小时                        ·   ·   ●   可用性
  E04   报价单被偷看后照抄，抢走订单            ●   ·   ·   机密性
  E05   工资表被员工看到又悄悄改了几行          ●   ●   ·   机密性、完整性
  E06   勒索软件加密全部文件，业务停摆          ·   ·   ●   可用性
  E07   合同扫描件被替换成改过金额的版本        ·   ●   ·   完整性
  E08   服务器被占满带宽，对外服务时断时续      ·   ·   ●   可用性
  E09   源码仓库被入侵，代码被拿走              ●   ·   ·   机密性
  E10   监控日志被删，事后查不出谁动过          ●   ●   ●   机密性、完整性、可用性

==============================================================================
二、汇总
==============================================================================
  机密性   5 次   █████
  完整性   4 次   ████
  可用性   4 次   ████

  只看被破坏的次数，三要素排得很平均；
  但在这 10 个事件里，有 2 个同时踩了两个以上要素——
  现实中的事件很少只破坏一个要素，是【一个口子进来、几样一起坏】。

  ④ 真正要记住的差别在【发现难度】上：
     可用性出事你立刻知道（网站打不开、系统进不去）；
     完整性出事你也能查（对不上账、数字不对）；
     唯独机密性出事——数据被抄走一份——你这边一切正常，
     往往在对方已经用上之后才知道。
     所以三要素里，机密性最需要靠【事前】的权限和加密来守。

读这个输出：最值得看的是最后一行 E10——"监控日志被删"同时踩了三个要素，而它恰好是最难被发现的那种：日志没了这件事本身，只有在你需要它的时候才知道。这就是三要素的用法：给一个事故定性，然后决定先补哪一块。

七、⚠️ 2026 现状

30 秒实验

打开你最近使用过的一个在线服务（邮箱、网盘、公司系统都行），想三个问题：

  1. 如果它今天被陌生人看到了内容——你介意吗？介意的话，它的机密性对你还不够。
  2. 如果它今天有一个数字被改了，你能发现吗——有没有对账、校验或历史记录？
  3. 如果它今天打不开了，你能撑多久——有没有替代路径？

三个答案里最让你不舒服的那一个，就是这套服务在你这里最薄的那一环。这一节要带走的动作就是这一句：先知道自己最怕哪一样坏，再谈措施。

常见误区

  1. 错误：安全就是保密，把机密性做好就行了。——纠正：三要素是三个不同的失效方式。只做保密、不做完整性，会出现"数据没问题但数字被改了"；只做保密和完整性、不做可用性，会出现"什么都保住了但业务开不了门"。

  2. 错误：可用性是运维的事，跟安全无关。——纠正：可用性攻击是最便宜的攻击之一——不需要技术高明，让服务打不开就够了。而且可用性事故也大量来自内部操作失误。它从来都在安全范围内。

  3. 错误：数据加密了就绝对安全。——纠正：加密保护的是存储和传输，但数据在使用时必须是明文（程序要读它）。所以加密不能替代权限控制、不能替代审计、更不能替代"少收集一点"。加密是机密性的一个手段，不是机密性的全部。

  4. 错误：完整性就是"别让人改数据"。——纠正：业务每天都在合法地改数据，完整性做不到"阻止改动"。它的现实目标是让未授权的改动被发现——校验值、版本记录、审计日志，都属于这一类。

自测三问（点开对答案） 1. 一个员工把自己手机上的客户资料截图发到了工作群，破坏了哪一（几）个要素？ —— 主要是**机密性**（不该看到的人看到了），同时如果这个资料后来被转发到外部，还会持续扩大。**注意它也可能顺带破坏完整性**：因为群里的版本可能不是最新版本，被当成准确版本使用。 2. 为什么说"机密性事故是先发生在别人那里的"？这对措施选择有什么影响？ —— 因为**数据被复制走之后，你这边不会出现任何异常**——服务正常、性能正常、日志里也未必有醒目记录。所以机密性的措施必须**前置**（权限、加密、最小化收集、导出审计），很难靠"事后发现"来补救。 3. 一个系统把口令的加密强度提到了最高，但允许任何人执行删除操作。它的三要素里哪一项最薄？ —— **可用性**（也可能连带完整性）。这是一个典型的"抓错了重点"的例子：**看起来很安全**（加密做得很足），但**一条最基础的控制（谁能删）缺了**。

相关笔记