VPN 加密的是旅程，而不是磁盘或云端的副本

追踪一个文件从笔记本电脑到同事手中：它存在于磁盘上，穿过一条隧道，落入云存储桶，又被复制进一份备份。这些环节中只有一段被 VPN 覆盖，而且它是存在时间最短的那一段。隧道关闭后，其他副本仍然存在，处在其所有者实际配置的存储加密之下。弄清哪份副本由什么保护，可以避免把一条能用的隧道误当成数据保护策略。

追踪一个文件经过三份副本

先看字节在哪里静止，再看它们在哪里移动，最后看它们在哪里再次存储。隧道位于中间环节。隧道两侧的存储加密、应用加密和访问控制是彼此独立的机制，各有独立的密钥保管方。

在做任何选择之前先画出这条路径。这张图通常会发现，大多数人担心的那份副本——传输途中的那份——存在的秒数最少。它也会显示哪一跳在房间里没有人负责，而那通常正是需要关注的一跳。

隧道的工作止于它自己的端点

传统 VPN 加密其两个端点之间的那一段。越过远端端点之后，流量又是普通 IP，除非另有东西保护它；这就是为什么浏览器会话可以端到端保持加密，而隧道只覆盖第一段。

关于那一段，没有任何东西说明接收方如何存储上传内容、在日志里写什么、保留哪些账户元数据。这些是接收系统的属性，无论请求是否经由隧道到达都成立。一个宣传加密传输的运营商描述的是旅程，而不是仓库。

你的磁盘和你的密钥库是两个独立的决定

全盘加密在关机时保护卷，它依赖设备或用户在启动时提供的密钥。密码管理器的保险库用一把由主凭据派生的密钥加密自身内容。打开 VPN 不会做这两件事中的任何一件，也不会加密已经存在于下载文件夹里的明文导出文件。

导出文件让这一点变得具体。为迁移而写的保险库导出是一个包含全部秘密的明文文件，除非有人删除它，否则它会熬过隧道、会话和重启。

file export-notes.json
head -c 80 export-notes.json
sha256sum export-notes.json

如果那份输出是可读文本，这个文件就没有保护。迁移一结束就把它删掉，并记住：现代存储上的安全擦除因设备而异，并不是一条通用的可移植命令。

云端加密实际覆盖了什么

服务器端加密保护已存储的对象，防止获得底层介质的人读取，而提供商仍然持有能够读取它的密钥。客户端加密则在文件上传前就完成加密，让明文不进入提供商的范围，但把密钥保管和恢复的责任转移给你。

两种模式都没有错，它们回答的是不同的问题：谁应当能够读取这些数据。要检查产品实际配置，而不是假定一种模式隐含另一种。逐字阅读密钥保管声明，包括支持团队恢复账户时会发生什么。如果提供商能在没有你的密钥的情况下恢复访问，那么提供商就能读取该对象。

副本会悄悄增多。一个共享链接、一个同步客户端、一个本地缓存和一个备份任务，各自在一项你未必选择的策略下再创建一个对象。对重要的数据把它们逐一列出，因为只要共享文件夹里放着一份明文副本，路径上最强的加密也毫无意义。

证据是恢复，而不是上传速度

存储设计的有用证据是：该看到的人能恢复数据，不该看到的人不能。上传吞吐量衡量的是完全另一回事，并且会讨好任何从未被恢复过的设计。从你所依赖的每份副本中各挑一个文件，证明它能回来。

从你所依赖的每份副本中恢复一个文件，使用恢复材料而不是当初创建它的会话。只保存在那台故障机器里的密钥不算是恢复方案；而一份恢复时需要你已丢失的保险库的备份，则是另一种单点故障。

NIST 的密钥管理指南涵盖了比任何单个产品决定活得更久的那类生命周期问题。把答案与它们所保护的数据放在一起，并在副本、接收方或存储提供商发生变化时重新审视。