📚 课程目录第4章利用AMD EPYC安全加密虚拟化（SEV）保护备份数据

4. 利用AMD EPYC安全加密虚拟化（SEV）保护备份数据

在备份与灾难恢复体系中，备份数据往往包含数据库全量快照、虚拟机镜像、密钥材料和业务归档，一旦备份介质或备份链路被攻破，损失可能比生产系统被入侵更大。AMD EPYC 处理器内置的 AMD Secure Encrypted Virtualization（SEV）系列技术，为备份工作负载提供了一条从 CPU 内存加密到虚拟机隔离的硬件级保护路径。理解 SEV、SEV-ES、SEV-SNP 三代能力的差异，并把它落到备份数据的传输加密与静态存储加密上，是构建可信备份平台的关键一环。

一、SEV、SEV-ES、SEV-SNP 的能力边界

SEV 的核心是 AMD 安全处理器（AMD-SP，基于 ARM Cortex-A5 的安全协处理器）为每个虚拟机生成独立的 AES-128 加密密钥，密钥由芯片内硬件随机数发生器产生，永不以明文离开安全处理器。虚拟机物理地址空间中的内存页在写入 DRAM 前由内存控制器加密，读取时解密，因此宿主机管理员、Hypervisor 甚至物理内存抓取工具都无法直接读取客户机明文。SEV 的局限在于：CPU 寄存器状态在虚拟机退出（VMEXIT）时仍会以明文形式保存在 Hypervisor 可访问的内存中，恶意 Hypervisor 可以借此窃取寄存器中的敏感数据。

SEV-ES（Encrypted State）在 SEV 基础上增加了对 CPU 寄存器状态的加密。当客户机发生 VMEXIT 时，通用寄存器、控制寄存器、段寄存器等被加密后写入 VMSA（Virtual Machine Save Area），Hypervisor 只能看到密文。这带来一个副作用：Hypervisor 无法再代为处理某些异常和指令，需要由客户机通过 #VC（VMM Communication）异常自行处理，因此对 Guest OS 内核版本有要求（Linux 5.10+ 对 SEV-ES 支持较完善）。

SEV-SNP（Secure Nested Paging）是第三代方案，重点补齐了完整性与重放保护。它引入 RMP（Reverse Map Table）记录每一页内存的归属与状态，防止 Hypervisor 通过重映射、重放、别名映射等方式篡改客户机内存；同时提供 attestation 报告，客户机可向远程验证方证明自己运行在真实 AMD 硬件上、固件版本可信、初始内存未被篡改。对于备份场景，SNP 的价值在于：备份代理运行在受 SNP 保护的虚拟机中时，可以生成可验证的证明报告，让备份服务器确认“数据确实来自受保护的执行环境”。

二、备份传输加密的配置

备份传输加密的目标是让数据在离开受保护虚拟机之后、到达备份服务器之前始终处于密文状态。推荐使用 TLS 1.3，并在备份代理与备份服务器之间启用双向证书认证（mTLS），避免仅靠单向证书被中间人冒充。以常见的 restic 备份到 REST 服务器为例，服务端启用 TLS：

# 备份服务器：生成自签 CA 与服务器证书
openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes \
  -keyout ca.key -out ca.crt -subj "/CN=Backup-CA"

openssl req -newkey rsa:4096 -sha256 -nodes \
  -keyout server.key -out server.csr -subj "/CN=backup.internal"

openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \
  -CAcreateserial -out server.crt -days 3650 -sha256

# 启动 restic REST 服务端，强制 TLS
rest-server --tls --tls-cert server.crt --tls-key server.key \
  --path /srv/restic-data --listen 0.0.0.0:8443

备份代理侧指定 CA 并执行备份，同时通过环境变量传入仓库密码，避免密码出现在命令行历史中：

export RESTIC_REPOSITORY="rest:https://backup.internal:8443/"
export RESTIC_PASSWORD_FILE="/etc/restic/pw"
restic -o cacert=/etc/restic/ca.crt backup /var/lib/mysql

如果备份流量走的是不可信网络，还可以在传输层之上叠加 IPsec，或在应用层使用 age/GPG 对备份流做二次封装。需要注意的是，SEV 保护的是虚拟机内存，不直接保护网络链路，因此传输加密必须由 TLS/IPsec 这类协议独立承担，两者是互补关系而非替代关系。

三、静态存储加密的配置

备份落盘后，静态加密负责防止磁盘被物理窃取或退役后数据泄露。在 Linux 上常用 LUKS2，密钥派生使用 Argon2id，加密算法使用 aes-xts-plain64，密钥长度 512 位（对应 AES-256-XTS）。示例：

# 创建 LUKS2 加密卷，使用 Argon2id 抗暴力破解
cryptsetup luksFormat --type luks2 \
  --cipher aes-xts-plain64 --key-size 512 \
  --pbkdf argon2id --pbkdf-memory 1048576 \
  --pbkdf-parallel 4 /dev/nvme1n1p1

cryptsetup open /dev/nvme1n1p1 backup_crypt
mkfs.xfs /dev/mapper/backup_crypt
mount /dev/mapper/backup_crypt /srv/backup

如果备份存储使用 ZFS，可直接启用原生加密，密钥格式选择 passphrase 或 raw keyfile，并配合 zfs load-key 在启动时解锁。无论 LUKS2 还是 ZFS 原生加密，密钥都不应与密文存放在同一介质上，建议由外部 KMS 或 TPM 2.0 托管，并设置自动轮换策略。

四、验证方法与判断依据

配置完成后必须做可验证的检查，而不是只看配置文件。第一，确认 SEV-SNP 已启用：在客户机内执行 dmesg | grep -i sev，应看到 SEV-SNP: RMP table initialized 或类似字样；在宿主机上执行 dmesg | grep -i snp 确认固件已开启 SNP。第二，读取 attestation 报告：使用 sevctl verify 与 sevctl show 获取报告，核对报告中的固件版本、TCB 版本与预期一致，若报告无法通过 AMD 根证书链验证，则说明环境不可信。第三，验证静态加密：执行 cryptsetup luksDump /dev/nvme1n1p1，确认 Cipher 为 aes-xts-plain64、Key 为 512 bits、PBKDF 为 argon2id。第四，验证传输加密：在备份服务器上用 tcpdump -i eth0 -A port 8443 抓包，应只能看到 TLS 握手与密文，看不到备份文件路径或内容。第五，做反向验证：在 Hypervisor 上尝试用 gdb 或内存转储工具读取客户机内存，若只能得到密文，说明 SEV 隔离生效。

SEV、SEV-ES、SEV-SNP 保护的是虚拟机内存与执行状态，不保护网络与磁盘。备份场景中应把三者与 TLS、LUKS2/ZFS 加密组合使用，形成“内存加密 + 传输加密 + 静态加密”的三层防护，任何一层缺失都会留下可被利用的缺口。

启用 SEV-ES 后，部分旧版 Guest 内核因无法正确处理 #VC 异常会出现启动失败或性能下降，建议先在测试环境验证内核版本（Linux 5.10+）与驱动兼容性，再在生产备份节点上启用。SEV-SNP 还要求宿主机 BIOS 开启 SNP 并更新到支持 SNP 的固件版本，否则 attestation 报告无法生成。

保护层	技术手段	验证命令	判断依据
内存 / 执行状态	SEV-SNP	dmesg \| grep -i snp；sevctl verify	报告通过 AMD 根证书链验证
传输	TLS 1.3 + mTLS	tcpdump -i eth0 -A port 8443	仅见握手与密文，无明文路径
静态存储	LUKS2 / ZFS 原生加密	cryptsetup luksDump	Cipher=aes-xts-plain64，Key=512 bits
密钥管理	KMS / TPM 2.0	检查密钥轮换日志	密钥与密文分离存放，定期轮换

把上述配置与验证串起来，备份平台就具备了从 CPU 内存到磁盘的完整加密链路。实际落地时建议先在单节点验证 SEV-SNP 与 LUKS2 的组合，再逐步扩展到备份服务器集群，并在每次固件或内核升级后重新执行 attestation 验证，确保信任链没有在升级过程中被破坏。