全盘加密只回答一个问题:当对手拿到你的存储介质、机器已经关机时,他们能得到什么?你可能关心的其他问题——主机商能看到什么、运行中的服务器被查封会怎样、备份是否安全——答案完全不同,把它们混为一谈,正是人们最终用上一套什么都保护不了的加密方案的原因。
这个区别值得说清楚,因为「LUKS 加密」这几个字出现在这个行业几乎每一个隐私主机商的页面上,我们自己的页面也不例外。它是一项真实有效的控制手段,运行成本几乎为零,同时也是主机行业里被夸大最多的一项控制手段。本指南介绍静态加密在一台租来的服务器上到底能防住什么、三种值得部署的方案及各自的命令、小型 VPS 上真正重要的两个参数,以及那些会让整套加密沦为摆设的常见错误。
静态加密到底能防住什么
静态加密(encryption at rest)是指卷处于关闭状态时,存储介质上的字节全部是密文。这是一个很窄的承诺,它的价值取决于一个变量:对手到手的那一刻,密钥在哪里。
| 场景 | LUKS 能起作用吗? |
|---|---|
| 硬盘退役、保修期内被换掉,或在报废时被转卖 | 能——教科书式的场景,也远比任何戏剧化的情形常见 |
| 机器在关机状态下被查封,或存储设备被从机架上拆走 | 能,前提是密钥没有留在机器上 |
| 主机商在服务器运行期间复制了你的虚拟磁盘 | 复制出来的是密文——但密钥就在同一台物理主机的 RAM 里 |
| 拥有虚拟化层权限的对手转储了虚拟机内存 | 不能。已解锁卷的密钥就在内核内存里 |
| 有人拿到了你正在运行的服务器的 root 权限 | 不能。文件系统已挂载,对方读到的和你看到的一样 |
| 你的备份以明文形式离开了服务器 | 不能。这个问题要在源头解决,而不是在目的地解决 |
| 你被要求交出密码短语 | 这不是技术问题——下文另有说明 |
把这张表当作定义来读,而不是当作一种失望。花一个小时消除「硬盘被拆走」这一类暴露风险是值得的,恰恰因为这是你没有其他手段可以防御的一类风险,也是不需要任何人针对你就会发生的一类风险:硬件会故障并被更换,阵列会退役,卷会被重新分配给下一个租户。加密能把这一切都变成毫无影响的小事。
为什么 VPS 不是笔记本电脑
在笔记本电脑上,这套设计不言自明。你在开机时输入密码短语,密钥只在机器唤醒期间存在于 RAM 中,关机就结束了这个故事。服务器旁边没有人守在控制台前。必须有某种东西在每次开机时提供密钥,而「某种东西」的每一种候选方案,都是在可用性和防护力之间做取舍:
- 由人来输入。最强的方案,因为密钥从不停留在机器上——但服务器一旦重启就无法自己恢复,必须有你在场,而且你需要在操作系统存在之前就有办法进入。
- 由机器自己保存。方便,但在大多数自行搭建的方案里会自我瓦解:密钥文件如果和数据放在同一块虚拟磁盘上,就意味着谁拿到了磁盘,谁就拿到了密钥。
- 由另一台机器交出密钥。基于网络的解锁,通常是 Clevis 配合 Tang 服务器。服务器只有在还能连到你控制的主机时才会自行解锁,这是一个确实有用的特性——但这只是把信任转移了位置,而不是消除了信任。
还有第二个差异,大多数指南都跳过不谈。在 VPS 上,/boot 和 initramfs 都是明文,它们存放在主机商最终能控制的存储上,而且没有任何你能验证的启动链——没有属于你自己的 TPM,没有可信测量启动,没有任何东西可供认证。一个想要你密码短语的主机商,完全可以修改 initramfs,在你下一次解锁时把它收集走。这不是在描述我们做了什么,而是在描述这套架构本身允许什么——而这是思考一台租来的电脑时唯一诚实的方式。我们的VPS 与独立服务器对比一文从硬件的角度讨论了同一条信任边界,我们对离岸主机匿名性的坦率回答则把同样的原则用在了这方面的营销话术上。
三种值得部署的方案
并不存在唯一正确的方案——只存在一种你能承受其失败方式的方案。以下三种基本涵盖了所有真实场景。
| 方案 | 覆盖范围 | 重启的代价 | 被锁在外面的风险 |
|---|---|---|---|
| 1.加密数据卷,开机后手动打开 | 真正重要的数据——数据库、邮件存储、文档、密钥 | 服务器自行恢复;加密卷等你来开 | 很低 |
2.全盘 root LUKS 加密,配合 dropbear 远程解锁 | 一切:系统日志、配置、swap,全部都在内 | 每次重启都需要你在启动完成前通过 SSH 介入 | 确实存在——initramfs 网络配置一旦出错,机器就会失联 |
| 3.裸机在安装时加密,通过 IPMI 输入密码短语 | 一切,密钥之下没有任何虚拟化层 | 每次重启都需要你通过带外控制台介入 | 低——IPMI 是一条独立于系统之外的通道 |
除非有特殊原因,否则从第一种开始。它以很小的运维风险换来了大部分防护效果,而且拥有另外两种都不具备的一个特性:无论发生什么,都不会阻止服务器重新上线。方案三是唯一一种密码短语是主机商触及不到的事实、而不是主机商给出的一句承诺的方案,这也是为什么我们的独立服务器在安装时就完成 LUKS 加密,密码短语我们自己也从未见过。
在运行中的 VPS 上加密一个数据卷
这是应该最先尝试的方案。不需要重装任何东西,启动流程也不会有任何变化,就算出错,最坏的结果也不过是把一个容器文件删掉重来。在一台正在运行的 Debian 或 Ubuntu 服务器上,十五分钟就能完成。
- 安装工具。
apt install cryptsetup。如果你的方案自带了第二块块设备,直接用它,跳过下一步。 - 创建一个容器。在单盘 VPS 上,实用的做法是用一个文件:
fallocate -l 40G /var/lib/vault.img。它的表现和一块磁盘一样,以后还能扩容。 - 格式化为 LUKS2。
cryptsetup luksFormat --type luks2 /var/lib/vault.img。加密算法保持默认即可;下文会讲到在小型服务器上唯一值得手动调整的参数。 - 打开它并铺上文件系统。
cryptsetup open /var/lib/vault.img vault会给你/dev/mapper/vault;接着执行mkfs.ext4 /dev/mapper/vault和mount /dev/mapper/vault /srv/vault。 - 把重要数据搬过去,再把服务指向它。用绑定挂载,或者在停掉服务后用
rsync,通常比软链接更干净——数据库尤其不喜欢被链接牵着到处跑。 - 备份 LUKS 头。
cryptsetup luksHeaderBackup /var/lib/vault.img --header-backup-file vault-header.bin,然后把这个文件转移到服务器之外。容器开头几千字节一旦损坏,后面所有字节都会永久性地报废,而这是唯一能防住这一点的保险。 - 关闭它,并证明自己还能重新打开。
umount /srv/vault && cryptsetup close vault,然后凭你记下的笔记而不是凭记忆重新打开它。要在里面存放任何有价值的东西之前就做这一步。
重启之后,加密卷会保持关闭,直到你登录并把它打开。这不是一个需要绕开的限制——这正是它存在的全部意义。一个会自己打开的卷,就是一个密钥留在机器上的卷。
shred 从设计上就不可靠——你以为在覆写的那一层,并不是真正存放数据的那一层。如果这些数据确实敏感,应该在一台全新服务器上从一开始就加密,而不是把旧服务器上的数据迁移进加密。全盘 root 加密,配合 SSH 远程解锁
如果要求是关机后被查封时没有任何可读内容留存——日志、shell 历史、软件包列表、你运行的东西的整体样貌——那么根文件系统也必须放进容器里。这时问题就变成了如何把密码短语送进一台还没启动的机器,而答案是在 initramfs 里放一个小型 SSH 服务器。
- 从一开始就加密安装。通过自定义 ISO 上传启动发行版安装程序,选择带加密 LVM 的引导式分区。原地转换一个正在运行的根文件系统在技术上可行,但不值得冒这个险。
- 加入预启动 SSH 服务器。
apt install dropbear-initramfs,然后把你的公钥放进/etc/dropbear/initramfs/authorized_keys。这是一套独立于你平时 SSH 使用的密钥——请专门为此使用一把独立的密钥。 - 把它锁紧。在
/etc/dropbear/initramfs/dropbear.conf中设置DROPBEAR_OPTIONS="-I 180 -j -k -p 2222 -s":禁止密码登录、禁止端口转发、使用独立端口,并设置空闲超时,防止卡住的会话让启动流程一直悬着。 - 给 initramfs 配上网络。把静态的
ip=参数加进GRUB_CMDLINE_LINUX(在/etc/default/grub文件里)——格式是ip=address::gateway:netmask::interface:off。这一阶段依赖 DHCP,是人们把自己锁在外面的常见原因。 - 重新生成并重启。
update-initramfs -u && update-grub,然后重启,用ssh -p 2222 root@your-server连接,执行cryptroot-unlock。你的客户端会提示一个未知的主机密钥:initramfs 有自己的一套密钥,这是预期之中的现象,值得单独记一条known_hosts条目。 - 在依赖它之前先测试失败路径。装一次内核更新,重启,再解锁一次。内核升级会重新生成 initramfs,而配置错误恰恰就在这个时候暴露出来。
dropbear 没能正常启动,SSH 帮不了你——唯一的退路是一个在操作系统启动之前就能用的控制台。每一台 ServHidden VPS 都自带 VNC 控制台访问,每一台独立服务器都配有完整的 IPMI/KVM,所以这条退路始终存在。如果主机商不提供这个,方案一才是唯一负责任的选择。真正重要的两个参数,以及小型 VPS 的陷阱
LUKS2 默认使用 512 位密钥的 AES-XTS,配合 Argon2id 密钥派生。两者都是正确的选择。手动调整加密算法往往会让系统同时变得更慢、更弱,网上流传的大量复制粘贴命令行做的正是这件事。不过,有两件事值得你留意。
性能通常不是问题——直到它成为问题
用 grep -m1 -o aes /proc/cpuinfo 检查硬件加速支持,用 cryptsetup benchmark 实测性能。在任何带 AES-NI 的 CPU 上——也就是我们运行的每一个节点——AES-XTS 每核心每秒能处理数 GB 数据,远超单块虚拟磁盘的吞吐能力,所以实际可见的开销只是高负载 I/O 下百分之几的 CPU 占用,以及略微增加的延迟。没有 AES-NI 时情况正好相反,加密会成为瓶颈;这也是唯一一种换用其他加密算法算得上是真正决策、而不是照抄惯例的情形。
真正会咬人的是 Argon2id 的内存需求
Argon2id 刻意设计得很吃内存,而 cryptsetup 会在格式化时根据当前机器的 RAM 来校准参数。如果在一台 32 GB 的工作站上格式化卷,再把它挪到一台 1 GB 的 VPS 上,解锁很可能会直接失败,因为密钥派生所需要的内存根本不存在——在 initramfs 里情况还会更糟,因为可用内存远比运行中的系统里少。在小型实例上,应该把它锁定:cryptsetup luksFormat --type luks2 --pbkdf argon2id --pbkdf-memory 262144 /dev/vdb 会把内存占用限制在 256 MB。调低这个数值,确实会实实在在地削弱抵御离线暴力破解的能力,所以要用更长的密码短语来补偿。
还有一个可选参数,值得认真权衡,而不是直接照抄:--allow-discards 会把 TRIM 指令透传给底层设备,这对 SSD 的磨损和长期性能有好处,但也会暴露出卷里大致用了多少空间、大致用在哪里。它默认是关闭的。打开它之前,要清楚自己会因此泄露什么。
swap、日志、快照——容易被忘掉的部分
一个加密卷,周围却在到处泄露明文,是最常见的一种失败,而且在有人专门去查之前,它一直不会被发现。
- swap。内存里的任何内容都可能被换出到磁盘上,包括你小心放进加密卷里的那些材料。要么直接禁用 swap,要么用一条
/etc/crypttab记录让它每次开机都用随机密钥,例如swap /dev/vdb1 /dev/urandom swap,cipher=aes-xts-plain64,size=256。 - 一切写在你没留意的地方的数据。
/var/log、/tmp、数据库的数据目录、/var/lib/docker、shell 历史记录、systemd 日志。只加密了/srv/vault,却任由 PostgreSQL 把数据写进/var/lib/postgresql,基本等于什么都没做。加密之前先把这些位置全部列出来。 - 快照。加密卷的块级快照本身是密文,所以没有问题。但捕获内存状态的快照是完全不同的东西,可能包含密钥。使用之前,先弄清楚主机商面板里做的是哪一种快照。
- 备份。目的地不是解决这个问题的地方。restic、BorgBackup 这类工具会在源头就完成加密,目标端永远看不到密钥,这也是为什么备份服务器可以是另一个司法辖区里一台普通的机器,而不必是一台可信的机器。
- 已经发送到别处的明文。静态加密不能追溯生效。任何已经被复制、发送邮件或同步到别处的内容,都在你现在划出的这条边界之外。
密钥放在哪里,才是设计的全部
上面每一种方案,本质上都是在回答密钥托管在哪里这个问题。一共有四种选择,而且它们并不等价:
- 记在你的脑子里,每次开机手动输入。防护力最强,运维摩擦也最大。没有你在场,机器真的读不出任何东西。
- 存在加密机器上的一个文件里。只能防住不动脑子的磁盘转卖,别的什么都防不了。如果这个文件放在明文的
/boot里,那就完全没有任何防护——这是自建加密方案里最常见的一个错误。 - 由你控制的另一台机器通过网络提供。Clevis 绑定 Tang 服务器:
clevis luks bind -d /dev/vdb tang '{"url":"https://tang.example.net"}'。服务器只要还能连回你的主机,就会无人值守地自动启动,在其他任何地方都拒绝解锁。这对无人值守的服务器集群非常合适,代价是 Tang 主机变成了必须重点防护的对象。 - 存在 TPM 里。在你自己拥有的硬件上才有意义。在 VPS 上,虚拟 TPM 是由你本想排除在外的那个虚拟化层提供的,所以它解决的是便利性,不是信任问题。
一个测试就能看清大多数设计:如果机器不需要你就能到达登录提示符,那密钥就在机器上。这可能是一笔完全合理的取舍——很多工作负载想要的是无人值守重启,而不是抵御一个执意攻击的对手。要有意识地做出这个选择,而不要把结果说成它并不是的样子。
主机商能看到什么,以及司法辖区从哪里开始起作用
在 VPS 上,你之下始终有一层虚拟化层。我们不读取虚拟机内存,不保留流量、连接或 DNS 日志,也不留控制台记录——但这些都是政策,坦率地说,VPS 这种架构要求你去信任这些政策。在裸机上,你和硅片之间没有虚拟化层:安装时就配置好的全盘加密,配合一个我们从未收到过的密码短语,是机器本身的物理属性,而不是我们给出的一种保证。你真正要在两者之间做的选择,是这个差异,而不是加密算法的选择。
这也是为什么加密和司法辖区是同一个答案的两半。加密决定了你磁盘的一份拷贝值多少钱;司法辖区决定了谁能通过什么程序、以多快的速度强制机器被交出。我们在七个司法辖区运营——冰岛、瑞士、巴拿马、罗马尼亚、摩尔多瓦、荷兰和俄罗斯——在它们之间如何取舍,详见我们的司法辖区指南,或者通过更简短的司法辖区选择器和节点页面了解。
加密碰不到的那部分,是强制披露,因为它针对的是你本人,而不是硬件。英国、法国和澳大利亚等国家的法律,可以要求一个人交出解密密钥,拒绝就要面临处罚。这种风险跟着你人在哪里走,而不是服务器在哪里,机器上的任何配置都改变不了这一点。不提供身份证件注册,能从源头上减少可供追查的文件记录——这正是无 KYC 主机服务和加密最终会被放在一起讨论的、朴实无华的现实原因——但它防不住一个已经知道你名字的法庭。
让加密沦为摆设的九个错误
- 用同一块磁盘上的密钥文件自动解锁。大多数所谓「已加密」的服务器都是这种情况,等同于把钥匙插在锁上没拔。
- 加密了一个敏感数据根本不会用到的卷。加密卷是空的,数据库并不在里面。
- 从不备份 LUKS 头。容器开头一个扇区损坏,后面所有字节就永久性地报废了。
- 从不测试解锁路径。结果一次内核升级重新生成了 initramfs,下一次重启就变成了一场抢救行动。
- 在大机器上格式化,却在小机器上解锁。Argon2id 需要的内存,VPS 给不出来,卷就打不开。
- 把密码短语设得像登录密码一样。离线攻击唯一受到的限制就是密钥派生函数本身。长度才是真正能争取到时间的东西。
- 把明文迁移进加密卷,就以为原始数据已经不存在了。在虚拟化存储上,覆写并不能可靠地抹除数据。
- 把密码短语通过管理这台机器所用的同一条通道发送出去。服务器 OpSec 一文讲了这样做会带来的关联问题。
- 把主机商的加密和你自己的加密混为一谈。「所有基础设施都是静态加密的」——我们也不例外——保护的是基础设施本身。只有你自己掌握的密钥,才能保护你不受基础设施的影响。
那么,在 VPS 上做这件事到底值不值?
值得,但要把预期调准。花一个小时,几乎没有可测量的运行成本,一个加密数据卷就能永久性地消除一整类你原本无法应对的暴露风险:退役的硬件、被重新分配的存储、落入他人之手的关机机器。在每一台存有重要数据的服务器上,紧跟在首小时加固清单之后做这件事就够了。
它做不到的,是把一台租来的电脑变成你自己的电脑。如果你的威胁模型里,主机商本身就是对手,那么没有任何加密算法能解决这个问题——答案是独立硬件:密钥通过 IPMI 输入、从不经过任何虚拟化层,再加上一个经过刻意挑选的司法辖区,以及不在任何服务器上放不必要东西的自律。让防护手段匹配真实的威胁,才是隐私和看起来像隐私之间的差别。