项目背景与真实业务场景混合加密整体原理通信流程与架构图基础实现版本4.1 依赖4.2 RSA 工具类4.3 AES-CBC 工具类4.4 请求模型4.5 AutoDecrypt 注解4.6 RequestWrapper4.7 Interceptor 解密4.8 Controller 示例4.9 Client 示例基础实现的安全缺陷分析企业级增强方案6.1 AES-GCM 替代 CBC6.2 Filter 全链路加解密6.3 防重放：timestamp + nonce + Redis6.4 防篡改：GCM 认证6.5 RSA Key 版本管理6.6 异常统一加密返回6.7 密钥安全管理（Secret / KMS）金融级安全算法组合标准性能优化与高并发实践真实业务案例金融支付政务接口物联网通信微服务零信任总结与工程落地建议第 1 章 项目背景与真实业务场景在多数 Web 项目中，接口安全通常被简单理解为“只要上了 HTTPS 就安全了”。 但在企业级系统，尤其是金融、政务、物联网、内部核心系统中，这种理解是严重不足的。HTTPS 只能解决“链路传输安全”问题：安全问题HTTPS 是否能解决数据在网络中被窃听✅请求体被篡改❌请求被复制并重放❌客户端被逆向或被植入木马❌内部服务被横向调用❌接口参数被构造恶意请求❌在真实企业环境中，攻击往往发生在HTTPS 之后：App 被反编译，密钥被提取内部接口被抓包复用接口被批量重放制造资金损失请求体被替换绕过风控微服务之间互相“裸奔”通信这类问题在安全审计中会被直接判定为：仅 HTTPS，不具备应用层安全能力1.1 为什么必须引入“应用层加密”企业级接口通常要求做到：数据内容不可被明文获取请求不可被篡改请求不可被重放响应数据同样加密密钥可以平滑轮换系统对业务代码无侵入因此形成标准模式：HTTPS + 应用层加密而应用层加密的经典组合是：RSA + AES职责划分：算法作用RSA安全传递 AES 密钥AES高性能加密业务数据最终通信模型：客户端 → AES 加密数据 客户端 → RSA 加密 AES Key 服务端 → RSA 解密 AES Key 服务端 → AES 解密业务数据1.2 真实业务场景一：金融支付接口金融系统接口的典型安全要求：订单金额、银行卡号、身份证号不能明文传输同一笔请求只能处理一次（防重放）请求内容必须可校验是否被篡改异常信息不能明文返回典型流程：客户端： 生成 AES Key AES-GCM 加密业务参数 RSA 公钥加密 AES Key 发送请求 服务端： RSA 私钥解密 AES Key AES-GCM 解密请求体 处理业务 AES-GCM 加密响应这类设计在：银行支付资金托管清结算系统都是强制规范。1.3 真实业务场景二：政务数据接口政务系统常见数据：身份证户籍信息企业法人信息社保、税务数据特点：数据极度敏感系统多为多部门对接API 经常被外部系统调用如果只靠 HTTPS，一旦某个合作系统被攻破：全量数据直接裸奔泄露引入应用层加密后：即使 HTTPS 被代理即使流量被拦截即使请求被复制没有私钥，也无法解密真实业务数据。1.4 真实业务场景三：物联网设备通信IoT 设备特点：容易被拆解固件可被逆向通信协议容易被仿造如果设备通信不做应用层加密：任意设备可伪造指令可远程控制设备可刷爆业务系统标准做法：设备端： 固定 RSA 公钥 每次通信生成 AES Key 所有数据 AES-GCM 加密1.5 真实业务场景四：微服务零信任在 Kubernetes、Service Mesh 架构中：内网不再是“安全区”任意 Pod 被攻破都可能横向攻击传统：内网 HTTP 明文企业级要求：内网 HTTPS + 应用层加密实现真正意义上的：零信任微服务通信1.6 本文目标本文目标不是“写一个能跑的 Demo”，而是：构建一个可以通过企业安全审计、可直接用于生产的 Spring Boot 应用层加密中间件体系最终效果：目标是否支持自动解密请求✅自动加密响应✅AES-GCM 防篡改✅防重放攻击✅Key 版本管理✅业务无侵入✅可平滑升级✅第 2 章 混合加密整体原理（RSA + AES）混合加密的核心思想是：用非对称加密解决密钥安全问题，用对称加密解决性能问题。如果只用 RSA 加密业务数据：性能极差加密数据长度受限高并发下几乎不可用如果只用 AES：AES 密钥必须安全传输一旦被抓包泄露，所有数据全部暴露所以在企业级系统中，必然采用：RSA + AES 混合加密模型2.1 整体交互时序图┌──────────┐ ┌──────────┐ │ Client │ │ Server │ └────┬─────┘ └────┬─────┘ │ 1. 生成 AES Key + IV │ │-------------------------------------│ │ 2. AES 加密业务数据 │ │-------------------------------------│ │ 3. RSA 公钥加密 AES Key │ │-------------------------------------│ │ 4. 发送 {encryptedData, encryptedKey, iv} │-------------------------------------│ │ │ 5. RSA 私钥解密 AES Key │ │ 6. AES 解密业务数据 │ │ 7. 执行业务逻辑 │ │ 8. AES 加密响应数据 │ │ 9. RSA 公钥加密新 AES Key（可选） │-------------------------------------│ │ 10. 接收加密响应数据 │2.2 请求体结构设计@Data public class EncryptedRequest { /** * AES 加密后的业务数据（Base64） */ private String encryptedData; /** * RSA 加密后的 AES Key（Base64） */ private String encryptedKey; /** * AES IV（Base64） */ private String iv; }从安全角度看，它承担三层责任：字段责任encryptedData业务数据机密性encryptedKeyAES 密钥安全传输ivAES 随机性与安全性2.3 为什么 AES Key 不能直接明文传假设你直接传：{ "encryptedData": "...", "aesKey": "abcd1234..." }那么任何抓包工具都能：直接解密请求体完全绕过 HTTPS导致所有业务数据泄露所以 AES Key 必须：只能被 RSA 公钥加密传输2.4 RSA 在这里的真实职责很多人误解 RSA 是“数据加密算法”，在企业级架构中它只做一件事：保护 AES KeyRSA 不直接加密大数据，只加密小而关键的数据：AES 密钥时间戳随机数签名数据2.5 AES 在这里的真实职责AES 负责：能力是否支持高速加密✅大数据量加密✅流式处理✅低 CPU 开销✅AES/CBC/PKCS5Padding这是教学级可用，但在金融级系统中我们后面会升级为：AES/GCM/NoPadding原因：模式是否防篡改CBC❌GCM✅2.6 混合加密完整生命周期一次请求完整生命周期：客户端生成 AES Key + IV客户端 AES 加密业务数据客户端 RSA 加密 AES Key发送加密请求服务端 RSA 解密 AES Key服务端 AES 解密业务数据服务端执行业务逻辑服务端 AES 加密响应数据返回给客户端客户端 AES 解密响应2.7 企业级加密目标拆解目标实现方式数据机密性AES密钥安全性RSA防篡改AES-GCM防重放时间戳 + nonce身份校验签名自动化Spring 拦截器 + 注解2.8 与 HTTPS 的关系说明必须强调：应用层加密不是替代 HTTPS，而是叠加最终安全层级：TLS（传输层） + RSA + AES（应用层）任何一