3.2 数据加密机制

3.2 数据加密机制

本节摘要：加密是数据安全的最后防线，但"开了加密"不等于"安全"。本节按传输、静态、使用中三种数据状态逐一配锁，讲透信封加密的分层设计与密钥托管的责任差异，并划清加密的能力边界——它防什么、防不了什么。

三种状态，三套锁

数据在云上只以三种状态存在，每种状态的攻击面不同，锁也不同。

传输中：数据在客户端与服务端、服务与服务之间流动。风险是窃听与中间人篡改。锁是传输层加密（如今通用做法是 TLS 一类的通道加密）。评审要点不在"有没有 HTTPS"这种存在性问题，而在强度与覆盖：是否全链路强制（内网服务之间也加密是零信任时代的新默认）、证书来源是否可信、老协议版本是否禁用。数据库连接不加密、内部服务裸奔明文，是内网横移的经典通道。

静态：数据躺在磁盘、对象存储、数据库、备份里。风险是介质丢失、越权读取、备份泄露。锁是静态加密——但关键理解在于：云上的静态加密几乎都是信封加密，"开了加密"其实意味着"有一套密钥体系在运转"，安全性取决于密钥管得好不好，这正是 3.3 的伏笔。

使用中：数据正在内存与 CPU 里被计算。传统加密管不到这一段——数据要参与计算就必须解密进内存，这被称为加密的最后空白。机密计算与同态加密等技术试图补上这块：前者给内存上锁并验证运行环境，后者让密文直接参与运算。两者都还处于"特定场景可用"阶段，考试只要求知道它们的存在与定位，不必深入数学。

三种状态的锁要连成链才成立——任何一段明文裸奔，其他段的白费。评审时用"全程追踪"法：挑一份核心数据，从进入系统到落盘归档走一遍，找出所有明文瞬间，逐个判断是否可接受。

信封加密：云上加密的默认形态

云上的静态加密通常不用一把钥匙加密所有数据，而是两层结构：数据密钥加密数据，主密钥加密数据密钥。这就是信封加密。它解决的问题很实际：直接用主密钥加密海量数据，主密钥会被高频调用、暴露面大、轮换时几乎要重加密全世界；信封结构让主密钥只干一件轻活——加密数据密钥，数据密钥随数据走，主密钥留在密钥服务里不出来。

图 3-2：信封加密的分层流程

信封结构顺带解决了密钥托管的责任问题，派生出三种模式，责任光谱从厂商到客户依次加重：厂商托管密钥（全托管，省心但客户无法独立验证）、客户主密钥（密钥在客户控制的密钥服务里，可审计可作废）、客户完全自持（密钥在客户自己的硬件里，云侧永不接触）。考试高频点是它们的取舍：自持程度越高，控制力越强，弄丢密钥的后果也越不可逆——自持密钥丢了，数据是永久读不回来的，没有客服能救。

加密的边界：它防什么，防不了什么

有判断力的加密观，来自认清边界。加密防得住：介质被物理窃取、备份泄露、存储层越权直读。加密防不住：应用层的越权访问——攻击者用合法应用身份穿过应用读数据，数据会在应用层被解密后交给他，密钥体系全程毫不知情；也防不住密钥使用者作恶——能调密钥服务的身份本身被盗（回想第一章威胁底图的凭据入口），整座密码学大厦对攻击者敞开。

所以加密的正确位置是纵深防御的一层，与访问控制、审计、DLP 配套成链。考试场景题里凡是"上了加密是否可以不做访问控制"的选项，几乎都是错误答案。反过来，"由于应用层已有权限体系，静态加密可以省"也是错误答案——两层各防各的攻击者，谁也替代不了谁。

落到实务，两条检查建议：一是核对自己环境的数据库连接与内部服务通信是否强制加密（传输态最常被省）；二是核对核心存储的密钥模式属于哪一档、作废密钥的流程是否演练过（静态态最常被假想为已安全）。

三种状态的现场自查顺序

理论之外给一条现场自查的动线，按"最容易出事"的顺序走。第一站查传输态的内网段：外部 HTTPS 几乎都配了，内部服务间与数据库连接是最常见的裸奔区，抓一次配置即可确认。第二站查静态态的"角落存储"：主数据库的加密通常开着，日志桶、临时导出、测试环境的副本才是泄露常客——用 3.1 的扫描思路全量盘点，不靠记忆点名。第三站查使用态的边界场景：核心敏感数据是否有落入第三方分析平台、开发笔记本明文缓存的链路——使用态是三种状态里管控最弱的一环，至少要让敏感数据的使用范围显式化。

自查的结果通常印证一个规律：三种状态的投入与其风险恰好倒挂——大家把预算堆在最显眼的外部传输上，而角落里的静态副本与使用中的流转才是事故多发段。评审时用这条倒挂规律去校准投入，比按清单均匀用力更有效。

一道考试风格的场景判断

给一道典型的场景判断，练加密域的答题手感。题干：某应用已对数据库启用厂商托管密钥的静态加密，安全团队是否可以停止关注该数据库的数据安全？

分析：静态加密只封住"绕过应用直读存储"这条路。应用层的越权查询（攻击者以合法应用身份查询他人数据）不受加密影响——数据在应用层是明文交付的；密钥若因调用身份被盗而被滥用，密文对攻击者同样敞开；备份与导出文件是否加密、传输是否强制、访问是否留痕，题干统统没有说。所以正确答案是：不可以，静态加密只是数据保护的一层，访问控制、审计、传输加密各司其职缺一不可。这个判断背后就是本节反复强调的能力边界——加密防"绕过"，不防"穿过"。

密钥模式选型：一次完整的决策推演

三种密钥托管模式怎么选，拿一个具体场景推一遍。背景：一家支付公司要在云上存交易流水，监管要求密钥产生与销毁全程可审计，且公司承诺客户"密钥不由云厂商单方控制"。约束列完，逐档过：厂商托管密钥首先出局——无法满足"可审计可自证"的承诺；客户完全自持在技术上最合承诺，但支付系统每秒数千次的加解密都要穿越自建密钥设施的可用性瓶颈，团队只有两名安全工程师，运维风险反而成为新的更大风险；最后落在客户主密钥档：密钥材料由密钥服务保管但策略归客户定，轮换、作废、审计全部留痕且可导出证明，配合年度演练满足承诺。

这个推演演示了数据域决策的通用算法：先列外部约束（法规、合同承诺），再算运维承受力，最后选"满足约束前提下运维最轻"的档位。考试场景题的选项设计同构——约束里的一个词（"可审计""不可导出""性能优先"）就能翻转答案。

顺带钉死一个高频考点：轮换。数据密钥轮换成本低（只重加密数据密钥或对新数据用新钥），主密钥轮换要重加密全部数据密钥，所以信封结构的工程动机之一就是让主密钥可以"躺平"——按年轮换即可，甚至以轮换数据密钥代替轮换主密钥。答题时区分"谁在轮换、轮换什么、代价多大"，选项的措辞陷阱大多埋在这。

本节要点回顾

• 三种状态三套锁，连成链才成立：内网明文与角落副本是最常见的断点，全程追踪法专治"想当然已加密"。
• 信封加密是云上默认形态：主密钥只锁数据密钥，换来低暴露面与低成本轮换。
• 密钥托管是责任光谱：厂商托管、客户主密钥、完全自持，控制力与不可逆风险同向增长。
• 加密防"绕过"不防"穿过"：应用层越权与密钥使用者作恶都在加密能力之外，纵深防御不可省层。
• 自查按风险倒挂排序：先内网传输，再角落存储，最后使用态边界。

补一个容易被追问的边界问题：加密能不能满足"数据不可见"的合规承诺？答案要看承诺的精确措辞。"存储加密"类承诺信封加密可以满足；但若承诺的是"厂商无法接触明文"，厂商托管密钥模式就不作数——密钥在厂商的密钥服务里，厂商在受控流程下具备解密能力。写合同（7.2）与对外承诺时，加密措辞要精确到密钥归属与调用条件，这正是 3.2 与 3.3 必须连读的原因。

锁讲完了，下一节管钥匙：密钥的托管、轮换、销毁与证书的到期治理——数据域里事故率最高的一环，恰恰在锁之外。