Spring Boot接口加解密实战：RSA+AES+签名验签与等保合规方案

让你从头写一套接口加解密方案，可能大家第一反应都是“直接上全链路HTTPS不就行了”。但你要是真拿这种思路去做等保2.0的整改，等测评师拿抓包工具一看，发现业务请求体里的明文内容一眼就能读完，那你连整改说明都写不踏实。更实际的情况是，很多项目根本不具备全程私有网络的部署条件，第三方对接、移动端直连、H5页面调用，这些场景下接口对外暴露几乎是必然的。所以我在实际做等保合规改造时，最终选择了一套很经典的组合方案：RSA + AES + 签名验签，用RSA做密钥的交换，用AES做业务数据的加解密，再用签名保证数据没有被中途篡改。整套逻辑放在Spring Boot 3.4里实现，既能满足合规审计的“传输加密、完整性保护、抗重放”这些通用安全基线，又能真正落地到日常业务接口，不阻塞开发联调。

这篇文章我会把从方案选型、报文协议设计、工具类封装，到Filter拦截器、响应加密、防重放、异常分支处理，再到线上压测数据和踩坑经验一次性讲完。适合正在做等保整改的项目负责人、主力后端，以及想了解接口安全问题解决方案的初中级开发者。内容不会只贴代码，我会把每一步“为什么这么设计”也说清楚，这样你拿去评审、写设计文档、对接第三方时，才不会被问倒。

1. 等保合规的通用安全基线：接口防泄露与防篡改到底考什么

每次一提到等保2.0，很多人脑子里冒出来的就是防火墙、堡垒机、日志审计、密码设备这些大件。业务接口层面的加解密，反而容易被糊弄过去。但我做过几个等保整改项目之后，有个很直观的感受：测评最常抓的接口漏洞，其实就是明文传输、无防篡改机制、无抗重放能力这三样。

1.1 安全通信网络要求里真正落地到接口的条款

通读等保2.0里跟应用层相关的安全要求，扣住核心有这么几条：

• 通信传输完整性：应用系统应该能检测到通信过程中数据是否被篡改。
• 通信传输保密性：应用系统应该能对通信过程中的敏感数据字段进行加密。
• 抗重放：应能防止在通信过程中的重复报文体被反复提交。
• 可信验证：应基于硬件级可信根对通信设备的引导程序等进行可信验证，这部分往往落地到服务器侧更多。

翻译成你能直接写代码的功能点，就是：

这套需求并不会死抠“你必须用RSA还是SM2”，更不会指定“你必须用AES-256-GCM”。它给的是一个目标，不是实现路径。所以你完全可以做技术选型，只要能把完整性和保密性的面儿撑起来，测评师看的是测评结果，不是你的具体实现函数名。

1.2 为什么只上HTTPS还不够用

实测中很多开发对“加密”的理解就是“上了HTTPS就安全了”。这话不能算全错，但放到等保整改里明显不够。

HTTPS解决的是TLS层传输加密，它保护的是“中间人看不到你TCP管道里的内容”。可问题在于，你一旦把接口暴露给第三方或H5页面，业务体到达终端以后、进入TLS加密之前，以及离开TLS解密之后，都存在明文窗口期。更直接的情况是：调用方拿着抓包工具，在App端用中间人代理把HTTPS证书替换了（这方面工具太成熟了），照样能直接看到明文JSON。哪怕你配了HTTPS，业务字段还是会以明文形式出现在请求Body里。

所以我把应用层加解密称之为“最后一段私密性兜底”。它不做传输层的事，只负责保证：就算数据被扒下来，也是一堆密文和签名，没法直接伪造合法报文、没法直接阅读业务内容。这套思路在等保里也更好过关，因为“应用系统设计为敏感数据字段加密存储和传输”是能明确写进整改说明书的。

1.3 加解密方案为什么是RSA+AES+签名三件套

先说结论：纯RSA加密所有业务数据完全不可行，纯AES对称加密没有密钥安全管理能力，只验签不加密则隐私内容暴露，只加密不验签则可能被伪造密文投毒。

实际职责划分很简单：

• RSA负责密钥交换：客户端随机生成一个AES对称密钥，用服务端公钥加密后传给服务端，服务端用私钥解开拿到AES密钥。
• AES负责数据机密性：真正加密大段业务JSON用AES，吞吐高、性能好、没有RSA那种“最多只能加密密钥长度减掉填充余量”的硬限制。
• RSA签名负责完整性：用私钥对明文业务字段签名，接收方用公钥验签，只要数据被改动一个字节，签名就对不上。

这里有个关键感悟：不要在业务体加密之外去信任任何“看起来没被动过的JSON”。哪怕外面包了层AES密文，如果对方AES密钥已经被拖走，密文照样可伪造。所以签名要覆盖“解密后的明文 + 时间戳 + nonce随机数”，而不是只签一个密文摘要。

2. 报文协议设计：整个方案的地基

写代码之前，第一步不是建项目，而是定协议。协议不先想明白，后面写Filter会乱成一锅粥。我给出的报文格式是我在项目中踩过坑之后调整出来的版本，兼顾了可读性和安全性。

2.1 请求报文格式与字段职责分配

客户端发给服务端的JSON，统一这种结构：

{ "encryptKey": "base64(RSA公钥加密后的AES密钥)", "timestamp": 1733721600000, "nonce": "f3a4b7c9-6d8e-4f1a-9c2b-5e7d8a9b0c1d", "sign": "base64(SHA256withRSA签名字符串)", "data": "base64(AES-GCM加密后的业务数据)" }

我做项目时习惯把encryptKey、timestamp、nonce放外层命名为“固定包头字段”，data是真正的业务密文。服务端处理顺序是：

1. 拿到encryptKey，用服务端私钥解密，得到AES对称密钥。
2. 用AES密钥解密data字段，拿到明文业务JSON。
3. 用明文业务JSON + timestamp + nonce 拼出待验签串，再用客户端公钥验sign。
4. 验签通过后，放到Request属性里，继续走Spring MVC正常流程。

顺序很重要，AES解密必须在验签之前做，因为签名针对的是明文业务体，不是密文。这个顺序你要是反过来，就永远验不过。

2.2 先签后加密与先加密后签名的选择

有的方案喜欢把签名放在密文外面，也就是先把业务体用AES加密，再对密文本身做RSA签名。这样做的好处是服务端不用先解密就能验签，能省一次解密流程。坏处也很明显：签名无法覆盖到明文内容，万一某个环节把密文解密之后又用了另一套明文，那后面再怎么验签都验的是密文，对业务明文没有约束力。

我倾向于“先组装完整明文，签名明文，再加密明文”。也就是sign本身也是基于明文生成的。服务端验签时，先解密拿到明文再验签。这里的额外开销也就是一次AES解密，这对现代CPU来说几乎可以忽略，但换来的却是“签名直接关联真实业务语义”的强保证。等保评审讲“完整性校验”时，这个设计讲起来逻辑也顺。

2.3 时间戳和nonce的防重放配合

防重放这块，最容易踩坑的就是只做时间戳判断。比如你判断“请求时间不超过当前时间5分钟”，那攻击者在这5分钟内反复重放同样的请求，你的业务系统依然会重复执行。尤其是下单、转账、领券这类操作，重放就是真金白银的事。

所以协议里nonce不是摆设，它的目的就是配合Redis或本地缓存实现“一次性请求ID”。服务端对每个已处理过的nonce缓存一段时间（比如10分钟），缓存有效期内如果再次提交相同的nonce，直接拒绝。时间戳管“过期”，nonce管“去重”，两者配合才能把重放漏洞堵死。

实现中我建议用Redis而不是本地Map做nonce去重，因为接口往往是多实例部署，本地Map在集群里根本不共享，只有Redis或集中式缓存才能保证全局唯一。代码大概是：

String nonceKey = "API:NONCE:" + nonce; Boolean firstSeen = redisTemplate.opsForValue().setIfAbsent(nonceKey, "1", Duration.ofMinutes(10)); if (Boolean.FALSE.equals(firstSeen)) { throw new ApiSecurityException("重复请求，拒绝处理"); }

别小看这段代码，它就是我线上联调时被坑出来的经验。第一版我图省事只做了时间戳，结果测试自测时用jmeter重放了10个一模一样的下单请求，库存直接被扣了10次。

3. Spring Boot 3.4工程化：基础工具类与密钥管理

接下来开始写代码。我用的是当前比较新的Spring Boot 3.4.x + JDK 17。如果你还在用Spring Boot 2.x，有些类名和API会有差异，比如jakarta.servlet和javax.servlet的区别，这个需要你自己迁移一下。

3.1 项目依赖与基础配置

新建项目时引入这几个依赖就够了：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-validation</artifactId> </dependency>

如果你本地没起Redis，可以先不管nonce去重那部分逻辑，或者直接用ConcurrentHashMap做单机版降级，但上线前请务必换回Redis。

application.yml里配置公私钥和加密方案参数：

api-security: server-private-key: "MIIEvQIBADANBg...完整Base64私钥" client-public-key: "MIIBIjANBgkq...完整Base64公钥" aes-key-size: 256 timestamp-valid-window: 300000

注意server-private-key是服务端私钥，用来解客户端传过来的加密AES密钥；client-public-key是客户端公钥，用来验证客户端签名。有些团队习惯反过来，服务端私钥签名、客户端公钥验签，这就要看你们密钥是双向还是单向的。我写的是“客户端签名、服务端验签、服务端加密响应、客户端解密响应”的模型，更贴近真实第三方对接。

3.2 RSA工具类：算法与填充模式的选择

RSA工具类里最容易掉坑的是填充模式。网上很多示例写的是RSA/ECB/PKCS1Padding，这个放在OAEP出现前的老系统里还能跑，但现在安全测评看到PKCS1Padding基本都会挑毛病，要求升级到OAEP。

Java里实际推荐用RSA/ECB/OAEPWithSHA-256AndMGF1Padding，也就是OAEP的SHA-256变体。它比老版PKCS1多了一次掩码生成，抗攻击能力更强。

public class RsaUtil { private static final String RSA_ALGORITHM = "RSA/ECB/OAEPWithSHA-256AndMGF1Padding"; private static final int KEY_SIZE = 2048; public static KeyPair generateKeyPair() throws NoSuchAlgorithmException { KeyPairGenerator generator = KeyPairGenerator.getInstance("RSA"); generator.initialize(KEY_SIZE); return generator.generateKeyPair(); } public static String encrypt(String plainText, PublicKey publicKey) throws Exception { Cipher cipher = Cipher.getInstance(RSA_ALGORITHM); cipher.init(Cipher.ENCRYPT_MODE, publicKey); byte[] encrypted = cipher.doFinal(plainText.getBytes(StandardCharsets.UTF_8)); return Base64.getEncoder().encodeToString(encrypted); } public static String decrypt(String cipherText, PrivateKey privateKey) throws Exception { Cipher cipher = Cipher.getInstance(RSA_ALGORITHM); cipher.init(Cipher.DECRYPT_MODE, privateKey); byte[] decrypted = cipher.doFinal(Base64.getDecoder().decode(cipherText)); return new String(decrypted, StandardCharsets.UTF_8); } }

这里有一个容易被忽视的硬限制：RSA一次只能加密“密钥位数 / 8 - 2 * 哈希长度 - 2”那么长的数据。用2048位密钥、SHA-256摘要的话，最多只能加密约190个字节左右。所以千万不要拿RSA去加密长JSON，AES密钥本身才32字节，加密它完全没问题。

3.3 AES工具类：为什么用GCM而不是ECB或CBC

AES本身有很多工作模式，我只推荐GCM。原因很直白：

• ECB模式相同明文加密成相同密文，根本不隐藏任何重复模式，测评当场就能指出来。
• CBC模式需要初始化向量，还需要自己拼PKCS5Padding，容易做错。
• GCM模式自带认证标签，能同时保证机密性和完整性，Java底层直接支持。

使用GCM时需要两个重要参数：一个12字节的初始化向量（IV）和一个16字节的认证标签。每次加密都必须生成新的随机IV，绝对不能复用。代码里我会把IV和密文拼在一起传输，方便解密时提取：

public class AesGcmUtil { private static final int GCM_IV_LENGTH = 12; private static final int GCM_TAG_LENGTH_BITS = 128; public static EncryptResult encrypt(byte[] plainText, byte[] aesKey) throws Exception { byte[] iv = new byte[GCM_IV_LENGTH]; SecureRandom secureRandom = new SecureRandom(); secureRandom.nextBytes(iv); Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding"); SecretKeySpec keySpec = new SecretKeySpec(aesKey, "AES"); GCMParameterSpec gcmSpec = new GCMParameterSpec(GCM_TAG_LENGTH_BITS, iv); cipher.init(Cipher.ENCRYPT_MODE, keySpec, gcmSpec); byte[] cipherText = cipher.doFinal(plainText); byte[] combined = ByteBuffer.allocate(iv.length + cipherText.length) .put(iv) .put(cipherText) .array(); return new EncryptResult(combined, iv); } public static byte[] decrypt(byte[] combined, byte[] aesKey) throws Exception { byte[] iv = Arrays.copyOfRange(combined, 0, GCM_IV_LENGTH); byte[] cipherText = Arrays.copyOfRange(combined, GCM_IV_LENGTH, combined.length); Cipher cipher = Cipher.getInstance("AES/GCM/NoPadding"); SecretKeySpec keySpec = new SecretKeySpec(aesKey, "AES"); GCMParameterSpec gcmSpec = new GCMParameterSpec(GCM_TAG_LENGTH_BITS, iv); cipher.init(Cipher.DECRYPT_MODE, keySpec, gcmSpec); return cipher.doFinal(cipherText); } }

注意SecureRandom必须每次重新取，不能用new Random()，否则IV生成不够随机，GCM的认证保护形同虚设。

3.4 签名工具类：私钥签名公钥验签

我偏好用SHA256withRSA做签名算法。它基于非对称密钥，客户端和服务端各持有一对，签字方用私钥签名，验证方用公钥验证，天然符合“防抵赖”的需求。如果你更偏好国密算法，也可以换成SM2withSM3，不过那样要额外引入BouncyCastle，这里先用标准JDK能跑的方案演示。

public class SignatureUtil { public static String sign(String content, PrivateKey privateKey) throws Exception { Signature signature = Signature.getInstance("SHA256withRSA"); signature.initSign(privateKey); signature.update(content.getBytes(StandardCharsets.UTF_8)); byte[] signed = signature.sign(); return Base64.getEncoder().encodeToString(signed); } public static boolean verify(String content, String signatureBase64, PublicKey publicKey) throws Exception { Signature signature = Signature.getInstance("SHA256withRSA"); signature.initVerify(publicKey); signature.update(content.getBytes(StandardCharsets.UTF_8)); return signature.verify(Base64.getDecoder().decode(signatureBase64)); } }

签名内容我建议统一用一个规范化拼串方法，把参数按固定顺序拼起来，避免两边字段顺序不一致导致验签失败。比如：

String signContent = plainBusinessJson + "&" + timestamp + "&" + nonce;

时间戳、nonce一定要参与签名计算。如果只签明文业务体，攻击者可以把一个老请求里的timestamp改成不超时的新时间，只要业务体没变，签名照样是有效的，这会绕开重放校验。

4. 核心实战环节：过滤器解密请求、响应加密

工具类写完之后，真正难的是把它们串进Spring Boot的请求处理链路里。这里要说明我对拦截器选择的思考过程。

4.1 为什么用Filter而不是Interceptor

Spring MVC的HandlerInterceptor虽然更好用，但它工作在Spring MVC的HandlerMapping之后。如果有请求压根没映射到任何Controller，比如404，那Interceptor根本不会执行。更麻烦的是，如果把解密逻辑放在Interceptor里，等你看到HttpServletRequest的时候，Spring MVC已经因为找不到合适的方法而报错了。

Filter处于Servlet容器最外层，请求进入容器后，最先经过Filter链，还没碰Spring MVC。这样我可以对请求体完成“解密 + 验签”之后，再把包装过的请求对象传递下去。后续不管Spring MVC能不能找到Controller，至少加解密逻辑是完整生效的。

4.2 RequestWrapper的写法与流的缓存

HttpServletRequest.getInputStream()只能读一次，这是Servlet规范限制。而Filter里解密必然要读一遍输入流，解密之后还得让Controller再读一遍解密后的明文流，所以必须做一层包装。

我的做法是自定义一个SecurityRequestWrapper，在构造时就把原始流读出来、解析并解密，之后Controller读到的是解密后的明文流：

public class SecurityRequestWrapper extends HttpServletRequestWrapper { private final String decryptedBody; public SecurityRequestWrapper(HttpServletRequest request) throws IOException { super(request); // 读取原始请求体 String encryptedBody = StreamUtils.copyToString(request.getInputStream(), StandardCharsets.UTF_8); // 解析报文头 SecurityRequestPacket packet = JSON.parseObject(encryptedBody, SecurityRequestPacket.class); String aesKeyBase64 = RsaUtil.decrypt(packet.getEncryptKey(), serverPrivateKey); byte[] aesKey = Base64.getDecoder().decode(aesKeyBase64); byte[] decryptedBytes = AesGcmUtil.decrypt(Base64.getDecoder().decode(packet.getData()), aesKey); String plainBody = new String(decryptedBytes, StandardCharsets.UTF_8); // 验证签名 String signContent = plainBody + "&" + packet.getTimestamp() + "&" + packet.getNonce(); boolean valid = SignatureUtil.verify(signContent, packet.getSign(), clientPublicKey); if (!valid) { throw new ApiSecurityException("验签失败，数据可能被篡改"); } // 保存解密后的明文，供后续业务使用 this.decryptedBody = plainBody; // 顺便缓存AES密钥，响应加密时复用 request.setAttribute(Constants.AES_KEY_ATTR, aesKey); } @Override public ServletInputStream getInputStream() throws IOException { final ByteArrayInputStream byteArrayInputStream = new ByteArrayInputStream(decryptedBody.getBytes(StandardCharsets.UTF_8)); return new ServletInputStream() { @Override public int read() throws IOException { return byteArrayInputStream.read(); } @Override public boolean isFinished() { return byteArrayInputStream.available() == 0; } @Override public boolean isReady() { return true; } @Override public void setReadListener(ReadListener readListener) { } }; } @Override public BufferedReader getReader() throws IOException { return new BufferedReader(new InputStreamReader(getInputStream())); } }

这里有个很重要的点：我把AES密钥塞进了Request的attribute里。这样后续响应加密时，就能直接用request.getAttribute(Constants.AES_KEY_ATTR)取出同一把会话密钥，保证响应是能用这把密钥解密的。

4.3 响应加密的实现路径：ResponseBodyAdvice vs 包装器

响应加密目前有两种主流做法：

1. ResponseBodyAdvice：在Spring MVC序列化Controller返回值之后、写回响应体之前拦截，对JSON字符串做AES加密。优点是能拿到真实的Controller返回对象，改起来很顺手；缺点是它是Spring MVC里的一环，如果请求根本没进Controller，比如Filter里直接抛了异常，它拦不到。

2. 自定义HttpServletResponseWrapper：在Filter里把响应包装成“只写密文”的输出流，在Controller返回时把所有字节缓存下来，最后统一加密。优点是覆盖链路更完整，连Spring Security的406、401响应都能处理；缺点是写起来麻烦，要自己维护一个BufferOutputStream。

如果你背景是纯Spring Boot，没有Spring Security，我建议用ResponseBodyAdvice，开发效率更高。如果你们项目里同时接了Spring Security或Shiro，最好用Filter + ResponseWrapper。

我用Filter全链路包装的方案做演示，因为更贴近等保整改“全部响应密文化”的诉求。

public class SecurityResponseWrapper extends HttpServletResponseWrapper { private final ByteArrayOutputStream buffer = new ByteArrayOutputStream(); public SecurityResponseWrapper(HttpServletResponse response) { super(response); } @Override public ServletOutputStream getOutputStream() throws IOException { return new ServletOutputStream() { @Override public void write(int b) throws IOException { buffer.write(b); } @Override public boolean isReady() { return true; } @Override public void setWriteListener(WriteListener writeListener) { } }; } @Override public PrintWriter getWriter() throws IOException { return new PrintWriter(buffer, true); } public byte[] getBufferedBytes() { return buffer.toByteArray(); } }

Filter主逻辑里，在chain.doFilter执行完之后，从包装器里取出明文字节，拿Request里缓存的AES密钥加密，再往真实Response里写出：

@Slf4j @Component public class ApiSecurityFilter implements Filter { @Override public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain chain) throws IOException, ServletException { HttpServletRequest request = (HttpServletRequest) servletRequest; HttpServletResponse response = (HttpServletResponse) servletResponse; String uri = request.getRequestURI(); if (shouldSkip(uri)) { chain.doFilter(request, response); return; } SecurityRequestWrapper requestWrapper; SecurityResponseWrapper responseWrapper = new SecurityResponseWrapper(response); try { requestWrapper = new SecurityRequestWrapper(request); } catch (ApiSecurityException e) { // 这里要写一个统一异常响应，注意也要加密，否则就留了明文逃生口 writeErrorResponse(response, e); return; } try { chain.doFilter(requestWrapper, responseWrapper); byte[] plainBytes = responseWrapper.getBufferedBytes(); byte[] aesKey = (byte[]) requestWrapper.getAttribute(Constants.AES_KEY_ATTR); byte[] encrypted = AesGcmUtil.encrypt(plainBytes, aesKey); response.getOutputStream().write(encrypted); } catch (Exception e) { writeErrorResponse(response, e); } } }

4.4 签名验签流程与异常处理分支

我在Filter里会把验签失败、解密异常、重复请求分情况抛出不同的错误码。比如验签失败返回4101，重复请求返回4102，解密失败返回4103。错误响应也要遵循统一密文封装，否则攻击者能拿明文错误信息做信息收集。

错误响应的格式和正常响应一致：

{ "timestamp": 1733721600000, "nonce": "随机值", "sign": "签名", "data": "AES密文，里面的业务结构是 {code:4101, message:验签失败}" }

签名就用服务端的私钥对错误信息明文做一次。客户端拿到后先验签再解密，保证错误信息也是可信的、未经篡改的。

5. 上线前必须知道的坑：从开发到联调的灵魂拷问

这一章节全是实战里被捶出来的经验，不写代码，但比代码更值钱。

5.1 流只能读一次引发的血案

有次联调时，对方一直报“请求体为空”，排查半天发现是我们在Filter里读了一次原始输入流，解密完用getReader()给Controller提供流，但另一个权限过滤器又先一步读了getInputStream()，把流读完没重置。后面Spring MVC再读就只剩空数据了。

解决办法有两个：一是建立团队约定，所有需要读Body的过滤器都基于自定义Wrapper来做，不直接操作原始Request；二是在Wrapper里做一次缓存，让后续所有getInputStream()调用都返回同一个缓存流，不要各自去原始流里读。

5.2 Spring Security和Swagger的链路冲突

集成Spring Security时，过滤器顺序会变成一个真正的坑。SecurityFilter一定要在ApiSecurityFilter之后吗？不一定，要看你的鉴权逻辑需不需要明文。如果Spring Security的认证过滤器需要读取用户名密码做登录校验，那它必须在解密之后执行。而Swagger文档的访问路径（/v3/api-docs/**、/swagger-ui/**）又必须跳过加解密，否则没带密钥的文档请求会直接被拦死。

我最终的过滤器链跑出来大致是这样：ApiSecurityFilter放在最外层，但内部用白名单跳过Swagger、健康检查、静态资源；然后才是Spring Security。如果你在Filter里做加解密，同时Spring Security又做认证，那HttpServletRequest必须用包装器传给Spring Security，否则Security读不到明文。

5.3 异步返回与响应加密失效问题

如果Controller用了Callable或DeferredResult，请求会提前返回，等异步线程处理完后再提交响应。这时候Filter里的doFilter已经执行完了，responseWrapper.getBufferedBytes()拿到的可能是空内容，异步线程里的输出流根本不会经过你的加密逻辑。

处理方式要么约定所有异步接口结果先统一收集，再走一次包装器；要么干脆规范项目里回调请求都走同步，不搞异步。第二个方案听起来粗暴，但实际项目里业务接口大部分都是同步的，硬上异步只会让加解密链路的复杂度飙升。

5.4 日志打印与敏感数据脱敏

加解密日志这块很容易在等保审计时被翻出来砍一刀。明文业务日志里如果打到身份证、手机号、地址，那测评直接视为敏感信息泄露。我建议：

• 日志里只打印加密前报文的哈希值、请求路径、时间戳、nonce。
• 明文业务体一律不输出，除非开了debug模式且只输出到本地文件。
• 异常堆栈打印时，注意别把请求参数原样打印。

这四条当时帮我挡住了好几条测评整改项，确实值得记下来。

6. 性能实测与上线验收：这把锁到底上多少成本

很多人一听到“接口加解密”就觉得性能会崩。实际上用GCM对称加密，开销远没想象中那么大。真正贵的反而是签名验签里的一次RSA非对称运算和双方密钥交换。

6.1 压测数据：加解密带来的耗时开销占比

我在一台低配4核8G的虚拟机上做过压测，测试场景是Spring Boot 3.4 + Redis，单接口平均处理逻辑本身约40ms，分成三组对比：

可以看出，加解密链路对性能的影响大概在15%到20%，业务逻辑本身也许只有几十毫秒，加解密多出来的其实不算离谱。关键还是看你怎么优化。

6.2 可优化的四个方向：公钥缓存、密钥池化、并行加密、降低日志

• 公钥缓存：从配置里加载公钥、私钥时，不要每次都重新解析PKCS8，而是用单例对象缓存住PrivateKey和PublicKey。RSA私钥解析在Java里是个耗时的操作，每次请求都做的QPS能立刻掉一截。
• AES密钥池化：虽然这笔实现里是每次请求随机生成一把AES密钥，但如果你追求更高性能，可以考虑密钥池化，让一段时间内的短会话复用同一把对称密钥，减少RSA交换次数。
• 并行加密：如果响应体特别大，可以分段做GCM加密，Java的Cipher支持并行更新，能利用多核优势。但业务响应通常不大，优化收益不明显。
• 日志级别把控：加解密失败时容易打印大量堆栈，日志I/O在压测时是隐形杀手，生产环境务必把异常日志量控制在合理范围内。

6.3 最终上线检查清单和验收建议

我在交付每个项目前会跑一遍自查清单，这里公开给你参考：

• 白名单路径是否已配置完整，Swagger、健康检查、静态资源是否不受影响。
• 是否已确认所有对外业务接口都被加密拦住，没有漏网的明文接口。
• nonce去重是否已接入Redis，长时间运行的集群不会出现本地Map分片去重失效。
• 错误响应是否也做了加密，没有把异常明文写给调用方。
• 日志里是否还有明文敏感字段输出。
• 客户端SDK是否覆盖了生成AES密钥、RSA加密、AES加密、签名生成的全流程。
• 密钥轮换机制是否已准备，至少约定好运维侧半年到一年换一次公私钥。

每个小项有问题的，补完再提测。最好在预评审前自己先用抓包工具模拟一遍攻击，互传一个明文包、修改一个字节试试，看看服务端能不能正确拦截。

我自己的经验是：这类安全改造，最耗时的不是代码实现，而是跟不同调用方对协议、排错、联调的过程。所以你一点要把报文格式、错误码、签名规则写成一份对接文档，提前发给所有外部调用团队，省下后面在线上一家家解释的时间。

最后再说一句真实感受：接口加解密不是安全银弹，不能替代权限管控、不能替代WAF、也不能替代全链路的日志审计。但它确实是把等保2.0在应用层传输数据安全这块抓得最牢的一层网。做技术选型时，别上来就追最繁的方案，先把RSA+AES+签名验签这套组合跑通，再回头审视自己的业务场景是不是真的需要更复杂的国密体系或专用密码设备。能把这一整套逻辑自洽地讲清楚、落地好，你面对测评和评审时就已经很有底气了。