怎样使用新密钥重新加密历史数据？

本文目录导读：

1. 核心原则
2. 场景与解决方案
3. 具体技术实现举例
4. 需要避免的陷阱
5. 总结建议

使用新密钥重新加密历史数据是一个常见的安全需求,通常称为密钥轮换或重新加密，具体操作取决于所使用的加密架构、数据存储方式以及系统设计，以下是一个通用的、安全的方法论和步骤，同时也指出了常见的陷阱。

核心原则

1. 绝不直接解密再加密：不要将数据完全解密为明文，再用新密钥加密，这会使数据在内存或磁盘上暴露于明文状态，严重违反安全原则（如PCI DSS或GDPR对数据保护的要求）。
2. 利用信封加密（Envelope Encryption）：这是最主流、最高效的解决方案，它只轮换密钥加密密钥（KEK），而数据加密密钥（DEK）保持不变。
3. 最小化停机时间：对于在线服务，重新加密整个数据集可能导致长时间不可用，需采用渐进式或后台处理策略。

场景与解决方案

使用信封加密（推荐，最安全高效）

架构说明：

• 数据加密密钥（DEK）：一个随机生成的对称密钥，用来加密实际数据。
• 密钥加密密钥（KEK）：一个主密钥，用来加密DEK（即对DEK进行“包装”）。
• 存储时：只存储被KEK加密后的DEK（称为“封装的DEK”），以及用DEK加密后的密文数据。

操作步骤：

1. 生成新KEK：创建新的主密钥（使用云KMS生成或本地HSM生成）。
2. 读取封装的DEK：从数据库或文件头中读取当前存储的、使用旧KEK加密的DEK密文。
3. 用旧KEK解密DEK：使用旧KEK解密密文DEK，得到原始的DEK明文。
   • 注意：此操作必须发生在内存中，且仅在安全环境中进行（如KMS内部或受控的HSM）。
4. 用新KEK重新加密DEK：使用新KEK对同一个DEK明文进行加密，生成新的“封装的DEK”。
5. 更新存储：将新生成的“封装的DEK”替换数据库中旧的“封装的DEK”或文件头。
6. 销毁旧KEK：在确信所有数据都已更新后，可以安全地销毁旧KEK（或使其失效）。

优点：无需解密实际数据，只需处理一小段密钥数据（通常几百字节），效率极高，数据本身（DEK）不变，因此无数据迁移风险。

适用场景：所有支持信封加密的系统（如云厂商的KMS服务、Amazon S3 SSE-KMS、Google Cloud CMEK、本地使用Vault等）。

直接加密（无信封架构，或需要轮换DEK本身）

当必须改变DEK本身（怀疑原DEK泄露），或者系统不支持信封加密时，只能对数据进行真正的重新加密。

操作步骤（按风险等级由低到高排列）：

1. 渐进式重加密（零停机）：

   • 修改应用层逻辑：当用户读取一条数据时，检测其使用的旧密钥版本，如果是旧密钥，立即用新密钥解密并重新加密后写回存储，可以启动一个后台异步任务，批量扫描所有数据并进行重新加密。
   • 需要一个密钥版本号字段，标记每条记录使用的密钥。
   • 此方法避免了大规模停机,但实现复杂。

2. 批量离线重加密：

   • 准备阶段：将服务切换为只读模式（或导入数据副本）。
   • 执行：编写脚本或使用工具（如openssl、gpg或云工具），按顺序执行：读取密文 → 解密为明文（内存中） → 用新密钥加密 → 写入新存储或覆盖原数据。
   • 风险：解密出的明文会短暂存在于内存中，若系统不安全，可能被窃取，操作耗时，且期间可能产生数据不一致。

3. 数据库级重加密：

   • 如果使用数据库原生的透明数据加密（TDE），通常会提供“重加密”命令（如SQL Server的ALTER DATABASE ENCRYPTION KEY），这是最简单的方法，但TDE通常保护“静止数据”，不保护应用访问时的内存。
   • 操作通常可以在线执行,但会产生性能开销。

具体技术实现举例

使用云KMS（如AWS KMS， Azure Key Vault， GCP Cloud KMS）

这是最安全的实践,你只需执行以下伪代码逻辑：

# 伪代码示例（AWS KMS使用信封加密）
# 假设每条记录都存储了加密的DEK（CiphertextBlob）
old_kek_key_id = "alias/old-key"
new_kek_key_id = "alias/new-key"
for each_record in database:
    old_wrapped_dek = each_record.ciphertext_dek
    # 1. 用旧KEK解密DEK（KMS内部完成，DEK明文不离开KMS）
    plaintext_dek = kms.decrypt(CiphertextBlob=old_wrapped_dek)['Plaintext']
    # 注意：你从来不会在本地看到plaintext_dek的明文，除非你显式打印它（禁止！）
    # 许多SDK允许你将解密操作和重新加密操作链式调用
    # 2. 用新KEK加密同一个DEK
    new_wrapped_dek = kms.encrypt(KeyId=new_kek_key_id, Plaintext=plaintext_dek)['CiphertextBlob']
    # 3. 更新记录
    update_record(key_field=new_kek_key_id, ciphertext_dek=new_wrapped_dek)

使用本地HSM或Vault

过程类似,但需要确保解密和重新加密的原子性操作在HSM内部完成，避免DEK明文暴露在内存中。

需要避免的陷阱

1. 解密后持久化明文：永远不要将解密后的文件写入磁盘或临时文件。
2. 在不可信环境操作：不要在客户端浏览器或非安全服务器上执行重加密操作。
3. 忘记处理元数据：加密密钥通常附带有版本标签，重新加密后必须更新所有元数据（如文件头部、数据库表字段）。
4. 依赖单一密钥加密所有数据：应尽量为每个用户或每条记录生成独立的DEK，这样轮换其中一个DEK不会影响其他数据。

总结建议

1. 首选信封加密：如果你的系统支持（或可以重构），这是最干净、最快速、最安全的方法，你只需要轮换KMS中的一个密钥，所有数据的“封装的DEK”可以一次性或分批更新。
2. 若不能信封，则采用渐进式：在应用层读取时做懒加载重加密，配合后台扫描任务。
3. 绝对避免“全量解密再加密”：除非数据量极小且能在一个受严密监控的专用脱敏环境内完成。
4. 做好密钥管理：使用密钥版本（Key Version）来区分新旧密钥，并保留旧密钥一段时间，以确保在重加密期间任何未处理的数据都能被解密。

你需要根据你的数据量、可用性要求和现有加密架构来选择具体方案，如果系统已使用信封加密，整个过程对用户几乎无感；如果直接加密，则需要更谨慎的设计。