加密算法与密钥类型：对称、非对称、HMAC

聊密钥边界之前，得先把加密算法和密钥类型理清楚。我在不少合规审计现场见过，团队把 AES 和 RSA 混着用，结果密钥管理一团糟。说白了，每种算法对应哪种密钥，怎么存、怎么轮换，SOC 2 是有明确期望的。你想想看，审计员翻到你的密钥策略，发现 HMAC 密钥和对称加密密钥共用同一套轮换周期……他就得给你开 finding。

对称加密：一把钥匙开一把锁

对称加密，我最常接触的就是 AES-256-GCM。密钥只有一个，加密解密都用它。好处是快，适合大块数据。坏处是——密钥怎么安全地传给对方？在 SOC 2 语境下，对称密钥属于“高敏感资产”，必须硬件安全模块（HSM）或密钥管理服务（KMS）来托管。

我记得有次帮客户做密钥边界评审，他们直接把 AES 密钥写死在配置文件里，还提交到了 Git 仓库……嗯，那是真头疼。后来我们强制要求：对称密钥不能离开 KMS 的边界，应用层只拿密钥的引用（Key ID）。

非对称加密：公钥加密，私钥解密

非对称加密，用 RSA 还是 ECC？我个人意见：新项目一律用 ECDSA 或 Ed25519。RSA 4096 虽然合规上也说得过去，但性能差点，密钥也大。SOC 2 要求保护私钥的机密性和完整性——私钥是“密钥边界”的核心实体，泄露等于全盘皆输。

我曾经在云端部署服务时，发现有人把私钥和代码放在同一个 S3 桶里，桶权限还是公开读的……审计员来的时候，脸都绿了。记住：私钥必须放在独立的密钥存储区域，访问权限最小化，并且开启日志记录。

• RSA：2048 bit 是底线，4096 更稳妥；加密和签名都用同一对密钥时，要分开用途。
• ECC：P-256（secp256r1）或 P-384；Ed25519 也受欢迎。
• 密钥用途分离：签名密钥和加密密钥不能混用。我习惯在 KMS 里创建两个密钥别名，一个签名用，一个加密用。

HMAC：消息完整性的守护者

HMAC 不是加密算法，它是一个基于哈希的消息认证码。用对称密钥来保证数据没被篡改。你可能在 JWT、API 签名里见过它。HMAC 的密钥和对称加密密钥一样需要保护，但有一个关键差异——HMAC 密钥通常不需要解密任何东西，它只用来验证。

所以你会看到一些系统把 HMAC 密钥和 AES 密钥存在同一个 KMS 密钥池里。这其实有风险：审计员会问，如果 HMAC 密钥泄露，攻击者能不能伪造任意 API 请求？

怎么解决？我建议把 HMAC 密钥单独放一个 KMS 区域，而且设置不同的轮换周期（比如 30 天轮换一次）。

密钥边界三维度：存储、使用、传输

现在我们把三种密钥类型放在一起看。SOC 2 关注的密钥边界，其实围绕三个维度：

1. 存储边界：密钥不能离开受控的密钥存储区域。比如 KMS 的硬件安全边界，或者 HSM 的物理边界。
2. 使用边界：谁、什么进程、通过什么接口可以使用密钥。必须记录每次使用。
3. 传输边界：密钥在生成、轮换、备份过程中，必须加密传输，且通过 TLS/mTLS 保护。

我见过不少设计漂亮的安全架构，但密钥的备份文件竟然通过 FTP 传输……嗯，这就把边界打破了。你想想看，SOC 2 期望的是每个环节都有明确的边界定义，而且可审计。

实践中如何选择？

我通常用一张简单的决策表来帮团队决定：

• 需要加密大量静态数据？ → 对称加密（AES-256-GCM），密钥托管在 KMS。
• 需要数字签名或身份认证？ → 非对称加密（Ed25519 或 ECDSA P-256），私钥不可导出。
• 需要验证 API 请求完整性？ → HMAC-SHA256，密钥单独管理，30 天轮换。