别人机器上的磁盘加密

每一家主打隐私的服务商都会说磁盘已加密。这通常是真的，也通常回答了一个没人问过的问题。加密要操心三种状态，而服务器的整个工作生命周期都处在全盘加密覆盖不到的那一种里。本文要说清楚这条边界到底划在哪里、两侧各是什么，以及打着同一个名字出售的两种方案里，哪一种才是密钥握在您自己手里的那一种。

数据的三种状态，以及没人加密的那一种

数据被分为三种状态，其中两种已经被彻底解决。静态数据是躺在磁盘上、当下没有任何程序在读取的数据：全盘加密解决了它，数据库或对象存储层面的加密又叠加了一层。传输中数据是正在穿越网络的数据：TLS 解决了它，解决得如此彻底，以至于一张签发错误的证书如今都会成为新闻。使用中数据是被加载进某个运行中进程内存里的数据——而服务器发出的每一个字节，无论多么短暂，都必须先经过这个状态才能被发送出去。

静态数据加密这个说法很精确，精确到容易被一眼带过。它描述的是机器处于关机状态时数据所处的状态。而服务器存在的全部意义，就是不能关机。在它运行的漫长岁月里，卷是打开的，数据库文件对任何以正确用户身份运行的进程都是可读的，加密除了等待一次断电之外，什么也没有在做。

这四个字还藏着第二件事：密钥到底握在谁手里。同一个名字下卖的是两种截然不同的方案。服务商可以用自己掌管的密钥加密存储层：这保护了服务商自身的报废处理流程，也缩小了它自身的泄露面，确实也能防止硬盘整块被带出机房——但握着密钥的那一方，正是您原本要提防的那一方。另一种做法是在您自己的机器内部加密这个卷，密钥只存在于您的脑子里，以及运行中内核的内存里。只有第二种方案才会改变第三方能拿到什么，本文其余部分说的也都是第二种。

以上都不是反对加密磁盘的理由，而是提醒您：要弄清楚下面八种场景里，自己究竟覆盖了哪几种，又没覆盖哪几种。能挡住一件真实威胁的加密就值得部署；而若误以为它能挡住全部八种，反而比不加密更糟，因为这种错觉会让人停止思考。

机器运行期间，密钥存放在哪里

解锁一个 LUKS 卷时，输入的口令本身并不是密钥。它解开的是存放在卷头部的主密钥，而这把主密钥随后会一直留在内核内存里，直到卷被关闭或机器断电为止。每一次读写都要经过它。不存在这样一种可用的加密磁盘配置：磁盘在使用中，密钥却存放在别处——这不是哪个实现细节没做好，而是使用加密磁盘这件事本身的含义。

在自己拥有的硬件上，这段内存装在您掌控的机箱、放在您掌控的房间里，能打的攻击也很罕见：需要物理接触，或者利用断电后内存芯片残留的那几秒电荷。在虚拟服务器上，情况不是程度上的差异，而是性质上的差异——您内核的内存，本就是主机内存的一部分。虚拟化层天生就能寻址到它，因为正是靠着这种寻址能力，虚拟化层才最初把这段内存分配给了您。有三种再普通不过的操作会读取它：

• 热迁移。把一台运行中的虚拟机从一台物理主机搬到另一台，需要在它运行的同时把内存整体复制过去。这是一项正常功能——主机正是靠它才能在不重启您的机器的前提下完成维护——而您的主密钥，就在被复制的那些内存页里。
• 包含内存的快照。只针对磁盘、且卷本身由您自己加密的快照，里面只有密文，别无其他。而能让机器原样恢复运行的快照则包含密钥，因为「原样」本身就包括密钥在内。
• 内存转储。客户机的内存，本质上位于主机上某个进程的地址空间之内。读取该进程的内存是一项常规调试操作，相应工具本就随虚拟化软件栈一起提供，不需要额外偷运进来。

以上都不是在断言您的服务商正在做这些事，而是在说明：做这些事完全不需要您配合、不会在您能看到的任何地方留下痕迹，而且和平常的平台维护毫无区别。这才是值得写进威胁模型的唯一属性：不是对方正在做什么，而是对方能在您毫无察觉的情况下做什么。往外推一层，同样的道理也解释了为什么您面前的镜像仓库和反向代理，要和主机列在同一张清单里。

重启难题，以及那条会前功尽弃的捷径

系统要引导到能接受 SSH 连接的程度，加密的根卷就必须先解锁。在笔记本电脑上，可以直接在键盘上敲入口令。而在两千公里外、您从未踏足过的机房里的一台机器上，需要用到键盘的那一刻，根本没有键盘可用。每一种现实可行的解法都是一种取舍——而下面四种里，有一种根本算不上取舍，只是装出一副已经取舍过的样子。

远程机器上解锁加密根卷的四种方式

方式	支持无人值守重启	能否挡住被偷走的硬盘	代价是什么
在引导镜像里跑 SSH	否	是	initramfs 里跑一个极简 SSH 服务，让您能连上去输入口令。机器会一直停在那里，直到有人醒着、能联系得上为止。这是最诚实的做法，代价也是真实的：凌晨四点的一次重启，会一直算作故障，直到有人发现为止。
网络绑定密钥	是	部分	机器在启动时，从您运行在别处的一台服务器上取得解锁密钥，您可以拒绝向一台已被搬动、或您没有下令重启的机器发放密钥。密钥服务器本身必须一直在线，而且要放在同一份命令够不到的地方——否则您只是把同一把锁拆成了两扇门。
密钥文件放在引导镜像里	是	否	密钥放在 initramfs 里，initramfs 放在未加密的引导分区里，而引导分区又在原本想保护的那块磁盘上。谁拿走磁盘，谁就顺带拿走了密钥。这种配置很常见，开机也顺畅无比，却什么都防不住。
密封给 TPM	是	部分	在自己拥有的硬件上，真正的安全芯片只会把密钥交给一条未被篡改过的引导链。而在虚拟服务器上，这块芯片是由主机模拟出来的，把密钥密封给它，恰恰就是把密钥交给了您原本想隔绝的那一方。

第三行值得多看一眼。当需求被写成磁盘必须加密、却没人追问「为了什么」时，最终往往就落到这一行。审计能通过，块设备也确实是加密的，可密钥就随着同一块硬盘一起搬走，藏在一个恢复 shell 大约四秒钟就能读到的文件里。

这也是租用的虚拟机和自己拥有的机器之间，最明显的一处实际差异。在独立服务器上，带外管理接口能给您一个不受重启影响的控制台，于是第一行不再是一次故障，只是两分钟的短暂中断——第四行里芯片被模拟的问题也随之消失，因为这块芯片是焊在主板上的硬件，而不是由您正要提防的那一方用软件模拟出来的。

全盘加密到底换来了什么

同一个问题，问了八遍。真正重要的是最后一列，因为在加密帮不上忙的每一行里，总有别的东西在起作用——把那个「别的东西」点出来，正是这张表存在的全部意义。

八种场景，以及全盘加密是否改变结果

场景	加密是否有帮助	真正起决定作用的是什么
硬盘退役、转售或保修退回	是	没有别的手段能覆盖这一场景。硬盘不断地离开数据中心，清除数据是一道流程，而流程会悄无声息地失效。这正是全盘加密最初被发明来对付的场景，对付起来也确实名副其实。
机器断电、硬盘被拆走	是	同样的保护、同样的边界，而这条边界就是「关机」二字。一台在运行中被夺走的机器，等于是一台在解锁状态下被夺走的机器——卷是打开的，密钥也还留在内存里。
备份副本存放在别处	部分	源卷上的加密，对数据的副本毫无作用。真正起决定作用的，是这份备份在离开原机器之前是否已经加密，而且密钥没有存放在被备份的那台机器上。
平台生成了一份快照	部分	只针对磁盘、且由自己加密的快照，是一堆密文，没有口令谁也用不了。而连内存状态一并捕获的快照，也会把密钥一并捕获进去。这两种都叫「快照」。
有人在运行中的机器上拿到了 shell	否	卷早已处于打开状态，入侵者读到的是文件而不是磁盘块。决定这一行结果的是补丁是否及时、权限是否最小化，以及凭据是否在不同服务之间复用，加密在这里毫无贡献。
主机运营方，或任何掌握其访问权限的人	否	唯一有用的，是密钥根本不曾进入这台机器的加密方式。硬件内存加密是唯一的例外，而它在几乎所有地方都是默认关闭的，下一节会讲到这一点。
一份命令送达服务商	部分	谁有权提出要求、需要出示什么，由司法管辖区决定；答复里能包含什么，则由加密决定。我们自己公开的立场是两句独立的话，两句都很重要：我们不掌握客户的密钥，也就无法提供；而虚拟服务器上未加密的卷，依然需要一份指名该服务的命令才能被调取。
您必须披露一起数据泄露事件	部分	如果您的用户在欧盟境内，GDPR 第 32 条明确把加密列为对您的期望措施之一；而第 34 条规定，只要数据已被处理得不可读，通知数据主体的义务就可以免除——但通知监管机构的义务从不因此免除。这一条能否适用，完全取决于数据离开时密钥在哪里。

磁盘之上：什么能在恶意主机面前幸存

到目前为止，讲的都是止步于块设备这一层的内容。在它之上还有三样东西，合起来正是上表第五、第六、第七行的唯一答案。

在应用层之上加密，而不是在它下面

字段级加密是指应用程序在把某个值写入数据库之前先加密，读回来之后再解密。无论谁以什么方式导出了这个数据库，拿到的都只是密文。它的代价是无法再对这些加密字段做搜索或索引，所以它更适合用在少数真正值得的字段上——消息正文、上传的文件、第三方令牌——而不是所有字段。这条路走到尽头就是端到端加密：密钥属于用户，服务器从不接触明文，恶意主机什么也拿不到，因为那里本就没有东西可拿。这是本页唯一一种真正不在乎底层由谁运营的架构，而且它首先是一项产品决策，其次才是基础设施决策。

备份是一项独立的决策，而不是加密的自然结果

数据离开一台加密机器最常见的途径就是备份。推送到对象存储的快照、同步到第二个服务商的数据库导出、拉到某台工作站上的归档——这些都不会从它们来源的那个卷继承任何保护。要在数据被写入备份的那一刻就加密它，密钥存放在这台机器自己够不到的地方，这样一来即使服务器本身被攻破，也无法解密自己的历史备份。然后，要在真正需要之前，先在另一台机器上把某份备份恢复出来试一试：一份打不开的加密备份，是一种格外干净利落的、把一切都丢光的方式。存放在另一个国家的副本，同时也是受另一套规则约束的副本——这是在不知不觉间选定的第二个司法管辖区。

内存加密，以及您多半还没有用上它

没人加密的那种状态，其实也有硬件层面的答案。机密计算相关的扩展——AMD 的 SEV-SNP、Intel 的 TDX——会把客户机的内存和寄存器状态用一把由独立安全处理器掌管、而非由虚拟化层掌管的密钥加密起来，这样即便主机把内存转储出来，拿到的也只是密文。这项技术是真实存在、已经在用的。但它也很局限：SEV-SNP 需要第三代或更新的 EPYC 芯片，主机必须专门为此配置，客户机还得能证明自己确实用上了它。几乎没有哪种通用型虚拟服务器会提供它，更不会默默地就提供了。除非服务商白纸黑字告诉您、并能说明如何自行核实这份认证，否则就该假定自己没有它。

一套如实承认自身局限的方案

以上这些，结论都不是算了，别费这个劲。而是要落到一套配置上——它的局限，您能坦然大声说出口，不必回避。

1. 写下您要防范的那一个具体场景（5 分钟）。是退役的硬盘、运行中被查扣的机器、恶意主机、法院命令，还是必须披露的数据泄露事件。这几种场景的答案各不相同，一套想同时应付全部五种的方案，最终往往一种也应付不了。
2. 把加密放在密钥所在的地方（决策）。如果密钥握在服务商手里，您买到的保护就只是防止硬盘离开机房，仅此而已。如果想要更多，这个卷就必须由您自己、在客户机内部、用平台永远看不到的东西来解锁。
3. 加密数据卷而不是根卷（配置）。加密根卷意味着每次重启都要等您出手。单独用一个加密卷存放数据库目录、上传文件和各种密钥，机器就能自己重新开机，而敏感部分则一直保持关闭，直到亲自打开它。这才是大多数小型平台该做的折中方案，却几乎没人把它写下来。
4. 密钥文件绝不能留在未加密的引导分区里（规则）。如果机器要在无人值守、既没有密钥服务器也没有控制台的情况下开机，那密钥就只能在磁盘上，没有第三种可能。如果被盗的硬盘确实就是您全部的威胁模型，这是一笔划算的取舍；除此之外的任何情况，这都是自欺欺人。
5. 在写入的那一刻就加密备份，密钥存放在别处（配置）。然后挑一个什么都没出岔子的日子，把某一份备份恢复到另一台机器上试一试。
6. 用一句话说清楚自己覆盖了什么（5 分钟）。大致应该是：把这块硬盘从机架上拆走的攻击者一无所获，而在运行中的机器或它的主机上拿到 root 的任何人则能拿到一切。如果这句话写下来让人不自在，那是因为它是真的。

这六件事里，两件是决策，四件是配置。决策要花一个下午，配置只要一小时，可这一小时如果没有前面那个下午，就毫无意义。顺序反过来做，最终就会落到第一张表的第三行——一台通过了审计、却对谁都防不住的机器。

到底在防范哪种场景，首先是一个威胁建模问题，其次才是一个加密问题，而那个一小时版本的练习，几乎顺带就能产出第六步要写的那句话。如果答案最终指向的是一份法院命令而不是一块硬盘，那么真正决定结果的那一层根本不在磁盘上——而在于哪国的法律能触及服务商，以及该如何在信任之前先核实这一点。

由负责运维该平台的工程师撰写，并已于 今天 复核。如果这里有错误或内容已过时，请通过客户面板告知我们——目前约有一半的内容更新正是这样来的。