第4章 数据加密分层策略：传输层加密、应用层加密、数据库加密，性能衰减评估模型

4.1 系统边界与分层定义

数据加密分层策略将加密能力拆解到三个独立且可叠加的边界：

• 传输层加密：保护数据在网络链路中的机密性与完整性，典型实现为 TLS/HTTPS、mTLS。边界为客户端与服务端之间的网络信道。
• 应用层加密：在业务逻辑内部对敏感字段进行加密，常用于 API 负载、JWT Payload、业务敏感字段（身份证、手机号）。边界为应用服务的内存与数据库之间的“明文”表示。
• 数据库加密：对持久化存储中的数据执行加密，包括透明数据加密（TDE）或列级/表级加密。边界为存储引擎以及备份文件。

4.2 组件职责与信任链路

4.3 数据流与控制流

典型请求经历以下加密/解密步骤：

1. 客户端发起 HTTPS 请求，TLS 握手后 HTTP 请求被对称加密。
2. 应用服务解密 TLS，得到明文 HTTP 请求。
3. 应用服务识别敏感字段，使用应用层密钥重新加密该字段（如用户手机号）。
4. 构造 SQL 或 NoSQL 语句，将加密后的字段发送到数据库。
5. 数据库引擎在写入前对整页或列执行 TDE 加密，存储层保持密文。

控制流：密钥管理服务（KMS）向应用层和数据库层分发加密密钥，并监控密钥使用频率。

4.4 选型权衡

4.5 风险点

• 密钥管理风险：密钥丢失导致数据无法解密；密钥轮换期间服务不可用。
• 性能衰减累积：三层串联后总延迟 ≈ 握手延迟 + 应用层耗时 + 数据库 I/O 增加，可能突破 SLA。
• 兼容性问题：TLS 版本不统一、应用层加密后的字段长度变化导致索引失效、TDE 与部分查询优化不兼容。
• 信任链路断裂：如果应用服务和数据库部署在同一节点，传输层加密虽减配，但应用层密钥与数据库密钥需明确隔离。

4.6 落地步骤

1. 评估现有数据流：梳理所有敏感字段、API 路径、存储位置，识别加密盲区。
2. 选择加密层组合：根据合规清单（GDPR、等保三级）决定必须启用的层。
3. 实施传输层加密：部署证书、配置 mTLS（如果采用双向认证），关闭不安全的协议版本。
4. 实施应用层加密：引入加解密 SDK，改造业务代码，设计字段级密钥体系。
5. 实施数据库加密：开启 TDE 或列加密，配置 KMS 集成，调整索引策略。
6. 性能基准测试：记录基线（无加密）和每层叠加后的延迟、吞吐量。

4.7 验收标准

• 传输层：证书有效，SSL Labs 评级 A+，握手时间 ≤ 100ms。
• 应用层：敏感字段在存储和日志中均为密文，加解密延迟 ≤ 5ms 每字段。
• 数据库层：TDE 开启后，全表扫描性能衰减 ≤ 20%，点查询性能衰减 ≤ 10%。
• 总链路的 P99 延迟在加密前基线基础上增加不超过 40%。

4.8 性能衰减评估模型

一个简化的线性叠加模型（单位：ms，假设单请求无阻塞）：

Total_Latency = Base_Service_Latency
               + TLS_Handshake_Latency (一次连接, 分摊到 N 请求)
               + TLS_Symmetric_Decrypt_Latency × Data_Size
               + App_Encrypt_Latency × Sensitive_Fields_Count
               + TDE_IO_Penalty × Query_IO_Count

该模型可用于容量规划，例如预估 QPS 下降比例：

QPS with encryption = 1 / (1 / Base_QPS + Total_Latency / 1000)

下图展示三层加密在系统内的协同关系与性能影响方向：