7.2 加密与数据保护

7.2 加密与数据保护

本节摘要：Snowflake 的所有数据从落盘那一刻起就是 AES-256 密文，加密不是可选项而是默认状态；密钥采用分层体系，由云服务层的密钥服务统一管理。本节讲清分层密钥的信任链、客户自管密钥的"拼钥匙"模式（Tri-Secret）、传输与使用环节的保护，以及"共享与克隆后加密状态如何"这类边角问题的答案。

默认加密：免配置的起点

接上章末的追问：即使有人绕过权限层拿到了物理盘，能看到明文吗？不能。存储层的每个微分区文件写入对象存储前都已完成 AES-256 加密，密钥与数据分离存放，解密只发生在被授权查询的计算节点内存里。这带来一个架构级的结论：权限模型（7.1）是第一道防线，加密是独立生效的第二道防线——前者配错时，后者仍然兜着物理层的底。

分层密钥体系的结构像一棵倒挂的树：

• 根密钥：账户级，由平台密钥服务托管（HSM 保护），从不离开密钥服务；
• 文件密钥：每个微分区文件一把，用根密钥体系包裹后与文件一起存放；
• 密钥轮换：支持按账户配置周期自动轮换，轮换的是密钥的包裹关系，不重写数据文件。

分层的目的在工程上很清晰：文件级密钥让"换一把钥匙"不必牵动整个账户的数据，根密钥的暴露面被压到最小。

Tri-Secret：把一把钥匙攥在自己手里

默认模式下密钥全部由平台托管，信任链止于平台。强合规行业（金融、医疗）常要求"平台也看不了明文"，Tri-Secret Safe 是对应的方案：数据加密密钥由平台侧密钥与客户侧密钥共同拼成——两把钥匙缺一把都解不开数据。

代价与纪律要一并说清：客户密钥被撤销或删除时，数据即刻不可解密——这既是它"自证清白"的能力，也是它最大的操作风险。启用 Tri-Secret 的账户必须同时管理好密钥的轮换计划、备份策略与应急联系人，丢了客户密钥，平台也救不回来。

启用流程走的是云平台密钥服务（KMS）侧：先在你的云账户里创建客户主密钥并授权平台服务访问，再在 Snowflake 账户级的 Tri-Secret 配置中绑定该密钥引用。配置入口在账户管理界面而非 SQL——它属于账户级基础设施设置，刻意没有做成随手的 DDL。验证生效可以通过平台支持的加密检查函数确认账户处于"三段密钥"状态，并把这个确认结果纳入安全基线检查清单。

传输与使用：三段旅程的加密连续性

数据在生命周期三个阶段都有对应保护，串起来看完整性更清楚：

使用中有一条与第3章呼应的细节：仓库计算节点的本地 SSD 缓存同样加密，节点释放时介质被平台擦除——所以"仓库挂起后数据缓存去哪了"的答案是：物理擦除，下次唤醒重新暖机，这也与 6.2 的缓存失效规则一致。

边角问题三连

克隆与共享之后，加密状态如何？ 不变。零拷贝克隆与共享引用的是同一批密文文件，解密路径与源表完全一致——既不会"复制了一份没加密的"，也不需要为新引用重新加密。这又一次体现了"元数据引用"思想的普惠：安全属性跟着物理文件走，而不是跟着逻辑对象走。

Time Travel 里的旧版本也加密吗？ 是。旧版本就是同一批文件里被标记的行，加密状态与现行版本无差别。

Stage 里的暂存文件呢？ 命名暂存区（含内部暂存区）中的文件同样默认加密；外部暂存区指向的自有对象存储桶，加密策略由你在云平台侧管理——用存储集成授权时，建议核对桶的默认加密配置，别让暂存区成为整条链路上唯一未加密的环节。

审计与监控：谁碰过数据

加密挡住物理层，权限挡住逻辑层，剩下的问题是"发生过的访问是否合规"。平台提供两级账本（7.1 提过，这里补监控视角）：查询历史适合运营期巡检——按用户、仓库、耗时筛异常模式（如非工作时间的大范围导出）；访问历史的列级血缘适合合规取证。配合掩码与行级策略（下一节），可以做到"敏感列每次被读取时动态决定给什么"——审计从事后追责前移到事中控制。

💡 关键直觉：数据安全的投入顺序应当是"权限模型 → 默认加密确认 → 敏感列策略 → 专项审计"。默认加密不用你操心，多数事故其实出在第一层：一个过宽的角色授权。把精力花在角色树上，比研究密钥更有杠杆。

本节要点回顾

• 默认状态：AES-256 全量加密 + 分层密钥 + 自动轮换，零配置起步。
• Tri-Secret：客户密钥与平台密钥拼合，平台也无法单独解密；代价是密钥自管的责任与风险。
• 三段保护：传输 TLS、静止 AES-256、使用中内存解密；克隆共享继承加密状态。
• 投入顺序：角色树 > 密钥研究；审计从事后追责走向事中策略控制。

物理与身份的防线都就位了。最后一道也是最贴近业务的防线：同一张表，让不同的人看见不同的内容。

合规要求如何映射到三层防线

合规条款通常是"结果语言"，落地时翻译成机制语言。以常见要求为例：数据不可物理窃取，对应默认加密与密钥分层；敏感数据最小可见，对应 7.3 的掩码与行级策略；访问可追溯，对应 7.1 的审计双账本；跨境传输可控，对应跨区复制与共享的区域策略。把条款逐条映射到机制并留档，审计时提供的是"机制清单加配置证据"，而不是临时补材料。这套映射表建议与法务共建并随合规要求更新维护。

密钥层级的文字画像

画不出图时的口述版本：把账户的加密体系想成一栋带门禁的档案库。每份档案（微分区文件）自带一把独立的小锁（文件密钥），小锁的钥匙被收进一层总控柜（由根密钥体系包裹），总控柜本身又安装在平台的密钥金库里（HMS 托管、轮换由服务执行）。档案在库房里永远是锁着的；被授权查阅时，管理员把对应钥匙送到阅览室（计算节点内存），阅毕即收回。Tri-Secret 相当于在总控柜上加装第二道锁，两把钥匙分属两家机构，缺一不可开柜。

这个画像能回答大部分边角疑问：为什么换钥匙不用重写档案（换的是包裹关系）；为什么克隆共享不改变加密（档案没动过）；为什么客户密钥丢失无解（第二道锁的钥匙只有客户持有）。

密钥之外：两个常被混入加密话题的话题

其一，字段级加密（应用侧加密后入库）与平台加密是两回事：前者密文进入 VARIANT 或文本列，平台无法对其做统计与剪枝，查询模式受限，除非确有端到端自控需求，不建议混用。其二，脱敏（7.3）不是加密：加密保护"存储与传输中的不可读"，脱敏控制"读取后的可见形态"，两者作用于生命周期的不同段，合规材料里分开表述。