加解密服务

---

KMS Sidecar 方案

采用 Sidecar 模式，加密服务和业务服务占用同一个 Pod 资源，通过本地 gRPC 方式通信。业务服务引入加密客户端 SDK 包（通信客户端），在 Spring 框架加载类到 IOC 容器时创建 KMS 客户端。

通信流程

第一步：握手

业务服务通过单例模式创建加密客户端，通过本地 gRPC 协议调用 Sidecar 中的加密服务进行加密授权握手通信，握手成功后销毁客户端。

第二步：加密通信

新创建加密客户端建立 gRPC 连接，并检查是否能够 ping 通。后续业务服务通过加密工具类进行加解密时，会通过 gRPC 协议调用加密服务进行加解密。

好处：业务开发无法感知具体的加解密实现逻辑，进一步保证了数据安全。

---

Sidecar 模式

"Sidecar 模式"是一种软件架构模式，广泛应用于微服务和云原生环境中。其核心思想是将辅助功能或通用服务作为"边车"容器，部署在主应用旁边，共同运行在同一 Pod 或同一主机上。

原理分析

• 配合运行：Sidecar 容器与主应用容器在同一环境中共享网络空间、存储卷和运行空间，确保高效通信
• 职责划分：Sidecar 承担辅助任务（日志收集、监控、代理、安全、配置管理、缓存等），减少主应用的复杂度
• 解耦设计：主应用和 Sidecar 解耦，功能可独立开发、部署和维护，提高灵活性和可扩展性
• 动态管理：可灵活启用、停用或更换 Sidecar 而不影响主应用，支持逐步迁移和灰度发布

实现机制

• 运行在同一 Pod 中（Kubernetes 环境）：多容器在同一 Pod 中共享网络、存储和调度
• 通信方式：通过本地网络接口（localhost）进行高效通信，无需远程调用
• 自动化部署：利用容器编排工具（如 Kubernetes）自动管理 Sidecar 的生命周期

架构示意

+---------------------------+
|          Pod              |
| +-----------+-----------+ |
| |  主应用   |  Sidecar   | |
| +-----------+-----------+ |
+---------------------------+

主要优势

• 改善微服务的可观测性、安全性和可管理性
• 支持微服务的灵活扩展和弹性部署
• 降低主应用的复杂度，专注核心业务

---

信封加密

信封加密是一种结合对称加密和非对称加密优势的分层加密策略，特别适合保护文件等大量数据。

基本原理

• 加密阶段：生成两样东西——文件密文（由 DEK 加密文件内容得到）和加密的 DEK（由 KEK 加密 DEK 得到）。两者组合在一起，构成完整的"信封"
• 解密阶段：接收方使用自己的私钥解开"信封"的密封（解密出原始的 DEK），再用 DEK 解开文件密文

核心建议

使用可靠的密钥管理服务（KMS）：将 KEK 存储在专业的 KMS 或硬件安全模块（HSM）中，避免本地存储风险。利用 KMS 提供的密钥轮换、访问控制和审计日志功能。

单次加密数据较大（>10MB）推荐使用信封加密（文件加密）。