1. 项目概述为什么我们需要对配置文件加密在Spring Boot项目里数据库连接信息、第三方服务的密钥、Redis密码这些敏感配置通常都明晃晃地写在application.yml或application.properties里。开发时为了方便直接写明文密码root:123456是常态。但项目一旦要部署到生产环境或者代码要提交到Git仓库问题就来了。把包含明文密码的配置文件推送到Git无异于把自家大门的钥匙挂在公告栏上而生产服务器的配置文件如果被轻易获取数据安全防线将形同虚设。我经历过几次安全审计扫描工具一跑直接就把配置文件里的明文密码列为高危漏洞。所以给配置文件加密尤其是数据库密码这类核心敏感信息加密从一个“可选项”变成了一个“必选项”。MyBatis-Plus作为我们操作数据库的利器其数据源配置恰恰是加密的重灾区。手动解密再注入虽然可行但繁琐且容易出错。今天要聊的就是如何将MyBatis-Plus与配置加密方案无缝整合实现配置项“落地即密文运行时解密”让安全性和开发便利性兼得。这个方案的核心价值在于无侵入性和自动化。我们不需要修改MyBatis-Plus的核心代码也不需要重写SqlSessionFactory而是利用Spring Boot的配置加载机制在配置被解析、数据源被创建之前完成解密操作。这样MyBatis-Plus感知到的永远是正确的、已解密的连接信息整个加解密过程对它来说是透明的。2. 加密方案选型与设计思路拆解面对“加密”这个需求第一步不是埋头写代码而是选对方案。不同的场景适合的加密方式和集成策略完全不同。2.1 主流配置加密方案对比目前在Spring Boot生态中主要有以下几种思路Jasypt (Java Simplified Encryption)老牌选手社区成熟支持多种加密算法如PBEWithMD5AndDES与Spring Boot集成有现成的starter。其原理是通过特定的格式如ENC(密文)在配置文件中标识需要解密的内容并提供一个StringEncryptorBean在运行时解密。Spring Cloud Config Server的加密功能如果你在用Spring Cloud Config做分布式配置中心它原生支持对称/非对称加密。但这属于“重量级”方案引入了额外的服务组件适合微服务架构对于单体的、只想加密本地配置的项目来说过于复杂。自定义EnvironmentPostProcessor这是最灵活、侵入性最低的方案。通过实现EnvironmentPostProcessor接口我们可以在Spring Boot应用上下文准备环境、但还未创建Bean之前拦截并处理所有的配置属性。你可以在这里注入自己的解密逻辑。使用Vault或阿里云KMS等外部密钥管理服务安全性最高将密钥与代码、配置完全分离。但同样会引入外部依赖和网络调用增加架构复杂度和运维成本。对于大多数结合MyBatis-Plus的项目我的建议是优先考虑Jasypt或自定义EnvironmentPostProcessor。如果项目已经用了Jasypt继续用它是最平滑的。如果是新项目或者对Jasypt的默认算法有顾虑想更精细地控制解密过程那么自定义EnvironmentPostProcessor是更好的选择它让你拥有100%的控制权。注意无论选择哪种方案加密密钥或盐值、种子的管理都是重中之重。绝对不要将密钥硬编码在业务代码或配置文件中。推荐的做法是使用环境变量JAVA_OPTS-Djasypt.encryptor.password你的密钥或在应用启动时通过命令行参数传入。对于更高安全要求的场景应该使用上述第4种方案从安全的密钥服务中获取密钥。2.2 与MyBatis-Plus的整合设计思路MyBatis-Plus本身不提供也不关心配置加密它只负责从Spring的Environment里读取spring.datasource下的配置来构建数据源。因此我们的加密整合点必须在MyBatis-Plus或者说Spring Boot的DataSourceAutoConfiguration读取配置之前。整个流程可以抽象为以下几步写入开发/运维人员将加密后的字符串如3xY7vViQzB4K9hLgM2pNqRsT写入配置文件替换原来的明文密码。加载Spring Boot启动加载配置文件到Environment。解密关键钩子在我们的自定义处理器如EnvironmentPostProcessor中遍历Environment的属性源识别出需要解密的属性例如所有以.password结尾的key或者被特定标记包裹的值并调用解密服务进行解密。替换将解密后的明文值写回Environment。注意这个过程是在内存中完成的不会修改磁盘上的配置文件。使用MyBatis-Plus的自动配置类DataSourceAutoConfiguration开始执行它从Environment中读取spring.datasource.password此时读到的已经是解密后的明文从而成功创建出可用的DataSourceBean。这样设计的好处是对MyBatis-Plus零改造。它甚至不知道密码被加密过整个加解密过程就像是一个安静的“前置过滤器”。3. 基于自定义EnvironmentPostProcessor的实战实现我更喜欢自定义EnvironmentPostProcessor的方案因为它足够轻量、灵活并且能清晰地展示整个解密流程。下面我们一步步来实现。3.1 项目基础环境与依赖准备首先创建一个标准的Spring Boot项目并引入MyBatis-Plus的依赖。!-- pom.xml -- dependencies !-- Spring Boot Starter -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- MyBatis-Plus Starter -- dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.6/version !-- 请使用最新稳定版 -- /dependency !-- 数据库驱动 (以MySQL为例) -- dependency groupIdmysql/groupId artifactIdmysql-connector-java/artifactId scoperuntime/scope /dependency !-- 加解密工具 (以Apache Commons Codec为例简单演示) -- dependency groupIdcommons-codec/groupId artifactIdcommons-codec/artifactId version1.16.0/version /dependency !-- 配置文件处理器让IDE能识别自定义配置 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-configuration-processor/artifactId optionaltrue/optional /dependency /dependencies这里没有引入Jasypt因为我们准备自己实现解密器。我们使用commons-codec来做Base64编解码实际加密算法你可以选择更安全的比如AES。3.2 实现核心解密工具类我们先实现一个简单的AES加解密工具。再次强调密钥secretKey绝不能写死在这里我们稍后会从环境变量获取。package com.example.demo.util; import org.apache.commons.codec.binary.Base64; import javax.crypto.Cipher; import javax.crypto.spec.SecretKeySpec; import java.nio.charset.StandardCharsets; /** * 简单的AES加解密工具类 (ECB模式PKCS5Padding) * 注意ECB模式不适合加密大量重复模式的数据生产环境建议使用CBC或GCM模式并管理好IV。 */ public class AesUtil { // 算法定义 private static final String ALGORITHM AES; private static final String TRANSFORMATION AES/ECB/PKCS5Padding; /** * 加密 * param content 明文 * param secretKey 密钥必须为16、24或32字节 * return Base64编码的密文 */ public static String encrypt(String content, String secretKey) throws Exception { SecretKeySpec keySpec new SecretKeySpec(secretKey.getBytes(StandardCharsets.UTF_8), ALGORITHM); Cipher cipher Cipher.getInstance(TRANSFORMATION); cipher.init(Cipher.ENCRYPT_MODE, keySpec); byte[] encryptedBytes cipher.doFinal(content.getBytes(StandardCharsets.UTF_8)); return Base64.encodeBase64String(encryptedBytes); } /** * 解密 * param encryptedContent Base64编码的密文 * param secretKey 密钥必须为16、24或32字节 * return 明文 */ public static String decrypt(String encryptedContent, String secretKey) throws Exception { SecretKeySpec keySpec new SecretKeySpec(secretKey.getBytes(StandardCharsets.UTF_8), ALGORITHM); Cipher cipher Cipher.getInstance(TRANSFORMATION); cipher.init(Cipher.DECRYPT_MODE, keySpec); byte[] decodedBytes Base64.decodeBase64(encryptedContent); byte[] decryptedBytes cipher.doFinal(decodedBytes); return new String(decryptedBytes, StandardCharsets.UTF_8); } }这个工具类提供了基础的AES加解密功能。为了便于在配置文件中识别哪些值需要解密我们定义一个简单的格式约定例如用DEC::作为密文的前缀。3.3 实现自定义EnvironmentPostProcessor这是最核心的一步。我们需要创建一个类实现EnvironmentPostProcessor接口并在spring.factories中注册它。package com.example.demo.config; import com.example.demo.util.AesUtil; import org.springframework.boot.SpringApplication; import org.springframework.boot.env.EnvironmentPostProcessor; import org.springframework.core.env.ConfigurableEnvironment; import org.springframework.core.env.MapPropertySource; import org.springframework.core.env.MutablePropertySources; import org.springframework.core.env.PropertySource; import org.springframework.util.StringUtils; import java.util.HashMap; import java.util.Map; public class DecryptEnvironmentPostProcessor implements EnvironmentPostProcessor { // 约定密文以 DEC:: 开头 private static final String PREFIX DEC::; // 加密密钥的环境变量名 private static final String ENV_KEY CONFIG_ENCRYPT_KEY; Override public void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application) { // 1. 获取加密密钥 String secretKey environment.getProperty(ENV_KEY); if (!StringUtils.hasText(secretKey)) { // 如果环境变量没有尝试从命令行参数或默认配置获取不推荐硬编码 secretKey environment.getProperty(config.encrypt.key); if (!StringUtils.hasText(secretKey)) { // 如果还是没有密钥则不解密但记录警告。生产环境应严格杜绝此情况。 System.err.println(警告: 未找到配置加密密钥跳过配置文件解密。请设置环境变量 ENV_KEY); return; } } // 2. 获取所有的属性源 MutablePropertySources propertySources environment.getPropertySources(); MapString, Object decryptedProperties new HashMap(); // 3. 遍历所有属性源寻找需要解密的属性 for (PropertySource? source : propertySources) { if (source instanceof EnumerablePropertySource) { EnumerablePropertySource? enumerableSource (EnumerablePropertySource?) source; for (String propertyName : enumerableSource.getPropertyNames()) { Object propertyValue source.getProperty(propertyName); if (propertyValue instanceof String) { String value (String) propertyValue; // 判断是否需要解密 if (value.startsWith(PREFIX)) { String encryptedValue value.substring(PREFIX.length()); try { String decryptedValue AesUtil.decrypt(encryptedValue, secretKey); // 将解密后的键值对存入临时Map decryptedProperties.put(propertyName, decryptedValue); System.out.println(已解密配置项: propertyName); } catch (Exception e) { throw new RuntimeException(解密配置项 [ propertyName ] 失败密文: encryptedValue, e); } } } } } } // 4. 将解密后的属性覆盖到环境变量中最高优先级之一 if (!decryptedProperties.isEmpty()) { MapPropertySource decryptedPropertySource new MapPropertySource(decryptedProperties, decryptedProperties); propertySources.addFirst(decryptedPropertySource); // 添加到最前面确保优先级最高 } } }关键点解析密钥获取首先从环境变量CONFIG_ENCRYPT_KEY获取密钥这是最安全的方式。如果没找到可以有一个兜底比如从config.encrypt.key读取但生产环境必须使用环境变量。遍历属性源Environment包含多个属性源如命令行参数、系统属性、配置文件等。我们遍历所有可枚举的源。识别与解密我们约定密文以DEC::开头。识别到这样的值后去掉前缀调用AesUtil.decrypt进行解密。覆盖属性解密后的键值对存入一个Map并包装成一个新的MapPropertySource。通过addFirst()方法将其添加到属性源列表的最前面。这意味着当Spring后续读取属性时会优先使用我们解密后的值覆盖掉原来DEC::开头的密文值。3.4 注册Processor并编写配置文件要让Spring Boot在启动时加载我们的EnvironmentPostProcessor需要在resources/META-INF/下创建spring.factories文件。# src/main/resources/META-INF/spring.factories org.springframework.boot.env.EnvironmentPostProcessorcom.example.demo.config.DecryptEnvironmentPostProcessor现在我们来准备加密后的配置文件。首先你需要用AesUtil.encrypt方法可以写个简单的main方法或单元测试将你的明文密码加密。假设你的数据库明文密码是MySecretDBPassword123!密钥是My16CharSecretKey!16字节加密后得到的Base64字符串可能是5f4dcc3b5aa765d61d8327deb882cf99示例非真实结果。那么你的application.yml配置文件应该这样写# application.yml spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/my_db?useSSLfalseserverTimezoneUTC username: root password: DEC::5f4dcc3b5aa765d61d8327deb882cf99 # 这里是加密后的字符串前面加上了我们约定的前缀 hikari: connection-timeout: 30000 maximum-pool-size: 10 # 其他配置... mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl # 开启SQL日志方便调试3.5 启动应用并验证最后一步就是启动应用了。密钥通过环境变量传入。Linux/Mac:export CONFIG_ENCRYPT_KEYMy16CharSecretKey! java -jar your-application.jarWindows (CMD):set CONFIG_ENCRYPT_KEYMy16CharSecretKey! java -jar your-application.jar或者使用启动参数安全性稍低因为能在进程列表里看到java -DCONFIG_ENCRYPT_KEYMy16CharSecretKey! -jar your-application.jar启动时你应该在日志中看到类似“已解密配置项: spring.datasource.password”的输出。随后MyBatis-Plus会正常初始化连接池成功建立应用启动完成。你可以写一个简单的测试Controller或单元测试注入DataSource并尝试获取一个连接来验证配置是否真的解密成功了。4. 方案优化、安全增强与生产级考量上面的方案是一个可运行的原型但要用于生产环境还需要在安全性、健壮性和易用性上做大量增强。4.1 加密算法的安全升级我们之前使用了AES/ECB模式。ECB模式简单但有个致命缺点相同的明文块会加密成相同的密文块。如果密码很短且配置文件中有多个相同密码攻击者可能通过模式分析获得信息。生产环境建议使用AES/CBC/PKCS5Padding或AES/GCM/NoPadding模式。CBC模式需要初始化向量IVGCM模式同时提供加密和完整性验证。IV的管理IV不需要保密但必须不可预测通常随机生成。对于配置文件加密我们可以将IV和密文一起存储。例如将IV:密文拼接后Base64再加上我们的DEC::前缀。密钥长度务必使用256位32字节的密钥。考虑使用专业的库比如Google的Tink库它提供了更安全、易用的加密API避免了自己实现可能产生的漏洞。一个增强版的解密逻辑伪代码// 假设密文格式为 DEC::BASE64(IV AES_CBC_ENCRYPT(明文)) String fullCipherText value.substring(PREFIX.length()); byte[] cipherData Base64.decode(fullCipherText); // 前16字节是IV byte[] iv Arrays.copyOfRange(cipherData, 0, 16); // 后面是真正的密文 byte[] cipherText Arrays.copyOfRange(cipherData, 16, cipherData.length); // 使用密钥和IV初始化Cipher进行解密...4.2 灵活的解密策略与属性匹配我们之前只解密了以DEC::开头的值。但在实际中可能需要更灵活的匹配规则基于属性名模式解密所有名称中包含password、secret、key、token的属性无论其值格式如何。多级前缀可以设计不同的前缀对应不同的解密算法或密钥例如AES::、RSA::。忽略某些属性源可能不想解密来自命令行参数CommandLinePropertySource的属性。这需要我们在EnvironmentPostProcessor中实现更复杂的属性过滤和策略逻辑。4.3 密钥管理从环境变量到专业服务环境变量是比代码硬编码好得多的方式但仍有风险例如服务器被入侵后环境变量可能被读取。对于更高安全等级的要求启动脚本保护确保存放启动脚本和设置环境变量的目录权限严格受限。使用云厂商的密钥管理服务如AWS KMS, Azure Key Vault, 阿里云KMS。应用启动时通过实例角色如AWS IAM Role临时获取解密密钥密钥不在任何持久化介质中留存。集成HashiCorp VaultVault可以动态生成数据库凭证应用根本不需要知道静态密码。这是最理想的“零密码”方案但架构复杂度最高。4.4 与配置中心结合如果你的配置不是放在本地application.yml而是来自Nacos、Apollo、Spring Cloud Config等配置中心解密逻辑应该放在哪里客户端解密推荐配置中心下发热的密文配置由客户端你的Spring Boot应用在接收到配置后用自己的密钥解密。这要求每个客户端都拥有解密能力密钥但配置中心不感知加密。服务端解密配置中心服务端存储密文并在有权限的客户端拉取时由服务端解密后下发明文。这减轻了客户端负担但将安全压力转移到了配置中心且网络传输的是明文。我们的EnvironmentPostProcessor方案天然支持客户端解密。只要配置中心客户端如Nacos Client将配置加载到Spring的Environment中我们的Processor就能在Bean初始化前对其进行解密。4.5 监控、日志与故障排查谨慎日志解密过程中绝对不要在日志中打印解密后的明文密码。我们之前的System.out.println仅用于调试生产环境必须移除或改为DEBUG级别日志且只打印属性名不打印值。健康检查可以创建一个健康指示器HealthIndicator在应用启动后尝试用解密后的配置建立一个简单的数据库连接如果失败则在健康检查端点中报告便于运维发现配置错误。清晰的错误信息解密失败时如密钥错误、密文格式错误应抛出带有明确提示的异常帮助快速定位问题但不要泄露密钥或密文细节。5. 常见问题、排查技巧与实操心得在实际落地过程中我踩过不少坑这里总结一下最常见的问题和解决办法。5.1 应用启动失败DataSource创建异常问题现象应用启动时报错提示“Cannot create connection to database server”或“Access denied for user”但确认密码在加密前是正确的。排查思路首先确认解密是否生效在DecryptEnvironmentPostProcessor中增加调试日志打印出解密前后的属性名和值值可打马赛克如spring.datasource.passwordDEC::****-spring.datasource.password****[DECRYPTED]。确保Processor被正确加载和执行。检查密钥百分之八十的问题出在密钥上。确保环境变量CONFIG_ENCRYPT_KEY已设置且与加密时使用的密钥完全一致注意大小写、空格、特殊字符。检查密文确认配置文件中的密文是完整且未经篡改的Base64字符串。Base64字符串通常只包含A-Za-z0-9/这些字符。可以尝试用在线工具仅用于测试或写个小程序用同一个密钥解密看是否能得到预期明文。检查依赖和算法确保加解密双方使用的算法、模式、填充方式完全一致。例如加密用AES/CBC/PKCS5Padding解密也必须用同样的。Cipher.getInstance(“AES”)在不同JDK版本或提供商下可能有默认模式最好显式指定完整参数。5.2 解密处理器未生效问题现象配置了DEC::前缀但应用启动时没有解密日志连接失败。排查思路检查spring.factories确认文件路径是src/main/resources/META-INF/spring.factories并且内容拼写正确全类名无误。检查Processor类是否在组件扫描路径EnvironmentPostProcessor的实现类不能被Component等注解标记也不应在主应用类的扫描包路径下被自动实例化。它必须通过spring.factories机制加载。如果被重复实例化可能会导致问题。检查属性源顺序我们的Processor通过addFirst添加解密后的属性源。如果其他后置的Processor或配置源修改了属性可能会覆盖我们的结果。可以调试查看environment.getProperty(“spring.datasource.password”)最终的值是什么。5.3 与特定配置或库的兼容性问题问题现象应用能启动但某些功能如Actuator端点、特定Starter行为异常。排查思路过早的解密我们的Processor在Environment准备阶段运行。如果某些库在这个阶段之前就需要读取配置极其罕见可能会读到密文。这种情况需要调整Processor的执行顺序通过实现Ordered接口或使用Order注解。属性名冲突确保你的解密属性名不会和其他框架的预留属性名冲突。使用DEC::前缀能很大程度上避免这个问题。Profile特异性配置application-dev.yml和application-prod.yml中的加密配置要分别处理。确保不同环境使用不同的密钥或者密文是基于对应环境的正确明文加密的。5.4 性能考量加解密操作会有性能开销但对于配置文件这个开销是启动时一次性的对运行时性能几乎没有影响。除非你有成百上千个需要解密的配置项否则无需担心。如果确实很多可以考虑缓存解密结果避免在遍历属性源时重复解密同一个属性。实操心得密钥轮换定期更换加密密钥是一个好习惯。但这意味着你需要用新密钥重新加密所有配置文件并协调应用重启。设计时要考虑好轮换流程。备份明文在安全的离线位置备份一份关键的明文配置如数据库连接串以防密钥丢失导致全线瘫痪。循序渐进可以先从最敏感的数据库密码开始加密稳定后再逐步推广到Redis密码、API密钥等其他配置。团队协作在团队中推行此方案时务必文档化加密/解密流程并提供便捷的脚本工具降低开发人员的操作门槛和出错概率。