数据加密实战：磁盘、数据库与传输层

数据加密通常分三层：静止时的磁盘加密、数据库层面的静态加密、以及传输过程中的 TLS 加密。三层各司其职——磁盘加密防"物理介质被拿走"，数据库加密防"备份文件泄露"与内部越权读取，传输加密防"链路被窃听"。大多数站点只做了第三层（HTTPS），前两层常被忽略。

磁盘加密：LUKS 与 cryptsetup

LUKS 是 Linux 主流的磁盘加密标准，底层由内核 dm-crypt 实现。它可以加密整个磁盘、分区、RAID 卷、逻辑卷甚至单个文件容器，对上层文件系统透明。

cryptsetup luksFormat /dev/sdX
cryptsetup open /dev/sdX cryptroot

再列几条常用命令，覆盖备份与恢复：

# 备份 LUKS 头部（务必在写入数据前做）
cryptsetup luksHeaderBackup /dev/sdX --header-backup-file luks-header.bak
# 恢复头部
cryptsetup luksHeaderRestore /dev/sdX --header-backup-file luks-header.bak
# 查看卷的加密参数与密钥槽位
cryptsetup luksDump /dev/sdX

开机自动解锁的 /etc/crypttab 大致长这样，密钥文件权限建议设为 400 并单独存放：

cryptroot /dev/sdX2 /etc/luks/root.key luks
cryptswap /dev/sdX3 /etc/luks/swap.key luks

参考：ArchWiki dm-crypt 全文 https://wiki.archlinux.org/title/Dm-crypt

落地要点：

交换分区（swap）也必须加密，否则内存中的数据会被换出到明文磁盘；
开机自动解锁可通过 /etc/crypttab 配合密钥文件实现，密钥文件建议单独存放并限制权限；
务必备份 LUKS 头部（cryptsetup luksHeaderBackup），头部损坏将直接导致数据无法解锁；
云端场景建议对根分区做全盘加密，配合备份策略把密钥与数据分开保管。

数据库加密：静态加密与字段级加密

数据库层有两种常见做法：

实例级静态加密（TDE）：MySQL/MariaDB、PostgreSQL 等对数据文件自动加密，透明但密钥通常由数据库管理；
字段级加密：在应用层对敏感字段（身份证、手机号、支付信息）单独加密，密钥由应用或机密管理体系托管，防御力度更高。

字段级加密需要在查询、索引与排序上做取舍，建议只对真正敏感的字段启用，并配合SQL 注入防护防止密文被绕过。

两种做法的取舍如下：

维度	实例级 TDE	字段级加密
加密对象	整个数据文件	指定敏感字段
密钥管理	数据库内置	应用/机密管理系统
对查询的影响	无	需改造索引、排序与搜索
防御上限	防备份与文件泄露	可防应用层越权读取

TDE 防的是"文件层面"，字段级防的是"字段层面"，两者不冲突：对绝大多数普通字段用 TDE，对身份证、支付 token 这类核心敏感字段叠加字段级加密，是性价比最高的组合。

传输加密：TLS 部署

传输层加密即我们熟悉的 HTTPS。证书申请与自动续期可直接参考SSL 证书自动续期，全站迁移可参考HTTPS 迁移指南。除 Web 外，数据库主从、Redis 等内部链路也应启用 TLS 或至少限制在加密的内网/专线内。

密钥管理与备份

加密系统的安全性最终取决于密钥：

密钥与密文分开存放，避免同机同盘；
制定密钥轮换计划，磁盘加密密钥、数据库密钥与 TLS 私钥周期不同；
密钥丢失等于数据永久不可读，务必做好密钥托管与恢复演练。

三层加密如何协同

三层加密并非互相替代，而是层层加固：

磁盘加密保证介质层面的机密性，即使硬盘被拆走也无法直接读取；
数据库静态加密保证数据文件与备份的机密性，防止"拿到备份=拿到数据"；
TLS 保证传输链路机密性，防止抓包窃听与中间人篡改。

对合规场景，通常要求三层同时满足，并在审计中证明密钥生命周期管理到位。磁盘与数据库层的密钥一般由系统/数据库管理，字段级与 TLS 私钥则建议由机密管理体系托管，便于轮换与审计。

三层各自的"防什么、密钥谁管、用什么工具"归纳如下：

加密层	防什么	密钥谁管	典型工具
磁盘加密	物理介质被取走	系统启动时	LUKS/dm-crypt、BitLocker
数据库静态加密	备份泄露、越权读文件	数据库/应用	TDE、字段级加密
TLS 传输加密	链路窃听、中间人篡改	证书/私钥托管	Let's Encrypt、mTLS

一个真实事故的教训

某创业公司做了 HTTPS 与数据库备份，但没做磁盘加密。一次机房搬迁时，运维误把两块旧硬盘随电子垃圾处理，其中一块正是主库所在盘。虽然备份完好，但按公司合规审计要求，"可读介质流出"必须上报并评估泄露范围——因为盘上的明文数据库无法证明从未被动过，审计与法务流程拖了两个多月。

如果他们当时做了全盘 LUKS 加密并妥善备份头部，这块盘即使流出也只是一堆密文，问题会小得多。这个案例的教训很直接：磁盘加密防的不只是"被偷"，还有"无法证明没被偷"。

常见误区

只加密了数据盘，忘记加密 swap 与临时目录；
备份文件未加密，等于把解密后的明文复制出去；
密钥与密文放在同一台机器同一块盘，失去意义；
忘记备份 LUKS 头部，一旦损坏整盘数据不可恢复。

16IDC 观察

对合规要求高的电商、SaaS 与支付类站点，三层加密是标配而不是加分项。小站点至少应做到：磁盘全盘加密 + HTTPS + 数据库备份加密，再配合安全加固分类中的基线方案形成体系。

原文来源：https://wiki.archlinux.org/title/Dm-crypt

数据加密实战：磁盘、数据库与传输层