项目定下来那天我就知道代码库里那些明文密码迟早会出事。Spring Boot 项目的配置文件里躺着数据库口令、Redis 密码、第三方 API Key很多人习惯直接写在 application.yml 里觉得“内网没事”“反正只有运维看得到”。直到有一次代码包被误传到外部共享目录我才彻底明白配置文件里的敏感信息一旦进版本库就不再是秘密。Git 历史里永远有它日志、CI 产物、同事的本地分支都可能成为泄露出口。所以后来我给自己定了一条规矩配置文件里不允许出现明文敏感信息。最开始是想找现成工具对比之后发现主流做法其实就三条路Jasypt 这种启动时自动解密的库、Spring Cloud Config 集中配置加密、以及自己写 AES 解密器。没有绝对好坏只有适不适合。这篇文章我把三种方案的真实接入过程、背后的原理、踩过的坑都整理出来给正在纠结的人一个明确参考。1. 方案选型前的三个核心问题在选工具之前先别急着引依赖。先把下面三个问题想明白否则不管选哪种方案最后都会变成“为了加密而加密”。1.1 敏感信息到底会从哪里泄露很多人以为加密是为了防黑客拖库其实大部分泄露发生在工程协作环节。最常见的几个出口代码仓库被误设为公开、源码包通过微信或网盘外传、CI 构建日志把配置完整打印出来、开发人员离职带走本地代码、外包团队拿到完整配置文件。明文敏感信息意味着只要上述任何一个环节出问题数据库口令和密钥就等于直接公开。加密存储的核心目的是让“拿到配置文件的人”无法直接读取真实值。哪怕文件被泄露攻击者看到的也是一串不可逆的密文或者需要额外密钥才能解开的密文。注意这里我说的是“无法直接读取”不是说绝对安全。凡是需要在运行时解密的方案都假设密钥本身是安全的所以密钥怎么放比加密算法本身更需要设计。1.2 加密的目标不是阻止开发而是降低泄密影响如果加密之后每次启动都要手工输入密钥开发效率会急剧下降最后团队一定会想办法绕过这个流程。真正合理的加密方案应该能做到开发环境用开发密钥测试环境用测试密钥生产环境用生产密钥而这一切对业务代码透明。也就是说业务代码读取配置的方式不变还是Value(${db.password})只是配置值从明文变成了密文。启动时某个模块负责把密文解成明文再放进 Spring 的 Environment 里。这也是 Jasypt 和 Spring Cloud Config 比较受欢迎的原因因为它们把这个过程封装得非常干净。1.3 三种方案的选型原则我的选型判断标准主要有四条。第一依赖要少不能为了加密配置文件引入一整套用不上的微服务框架。第二密钥不能出现在代码库里哪怕是加密后的密钥也不行必须通过环境变量或外部配置注入。第三支持多环境切换不能因为换了个环境就改代码。第四一旦加密后出问题可以快速回滚和解密不能出现“配置文件加密了但启动直接失败”的僵局。按照这个标准小项目优先考虑 Jasypt因为它是纯 Spring Boot 集成改动最小微服务数量多且有统一配置需求时才考虑 Spring Cloud Config如果团队对安全有特殊要求并且有时间自研再考虑自定义 AES 方案。接下来逐一展开。2. 方案一Jasypt 加密最成熟的即时加密方案Jasypt 是 Java 社区里使用率最高的配置加密库之一Spring Boot 场景下直接使用对应的 starter 就能做到启动时自动解密。它最大的优势是接入成本低不需要额外部署任何服务。2.1 Jasypt 的工作原理与核心配置Jasypt 的核心思路是你把真实值加密成一串密文放进配置文件里形如ENC(密文)。应用启动时Jasypt 的EnableEncryptableProperties机制会拦截 Spring Environment 的属性解析过程凡是值以ENC(...)包裹的都会在注入到Value或ConfigurationProperties之前被自动解密。解密需要密钥这个密钥叫jasypt.encryptor.password绝对不能写在配置文件里。我通常的做法是通过环境变量传入比如启动命令中加-Djasypt.encryptor.password你的密钥或者写成export JASYPT_ENCRYPTOR_PASSWORDxxx后再启动。这里需要特别注意Jasypt Spring Boot Starter 2.x 默认支持jasypt.encryptor.password属性也支持直接映射同名环境变量具体映射规则可以查对应版本的文档我实践中习惯显式传入避免版本差异造成的坑。2.2 实际接入步骤第一步在pom.xml中加入依赖。如果用的是 Spring Boot 2.x常见的坐标是dependency groupIdcom.github.ulisesbocchio/groupId artifactIdjasypt-spring-boot-starter/artifactId version3.0.5/version /dependency第二步用 Jasypt 提供的加密工具生成密文。可以用官方提供的加密命令也可以在测试类里写一段代码。我习惯用 Maven 插件直接生成避免写多余的测试代码。以 3.x 版本为例在项目根目录执行mvn jasypt:encrypt-value -Djasypt.encryptor.password你的密钥 -Djasypt.encryptor.algorithmPBEWITHHMACSHA512ANDAES_128 -Djasypt.encryptor.iv-generator-classnameorg.jasypt.iv.RandomIvGenerator -Djasypt.encryptor.value真实密码命令中指定的算法要和配置文件里的算法一致否则启动时会解密失败。3.x 版本里默认算法就是PBEWITHHMACSHA512ANDAES_128同时还要求指定 IV 生成器否则会报错。这点和 2.x 差别很大很多人升级后在这里栽了跟头。第三步把生成的密文填进配置文件spring: datasource: username: root password: ENC(密文串)第四步启动时传入密钥。生产环境我推荐用环境变量export JASYPT_ENCRYPTOR_PASSWORD你的密钥 java -jar app.jar如果密钥包含特殊字符注意转义问题最好避免使用$、\、空格等字符不然环境变量的解析会坑你一把。2.3 使用中的注意事项和常见坑Jasypt 最常见的坑有三个。第一个是算法不匹配用插件生成密文时的算法跟运行时配置的算法不一致启动直接DecryptionException。解决办法是锁定同一个版本最好在pom.xml里固定插件版本和依赖版本而且配置项里的算法参数保持一致。第二个坑是密文中的特殊字符被 YAML 误解析。ENC(...)中的密文如果含特殊符号比如、/、在 YAML 里需要加引号否则解析结果可能被截断或报错。我一般统一把包含密文的值写成双引号字符串password: ENC(abcdefgh)第三个坑是密钥管理。很多团队把jasypt.encryptor.password写进了 CI 脚本这等于加密白做了。正确做法是把密钥放到部署平台的密钥管理功能中或由运维在启动前手动注入不要以任何形式提交到仓库。3. 方案二基于 Spring Cloud Config 的加密方案如果你的服务已经上了 Spring Cloud 体系配置不再散落在各个服务本地而是集中在 Config Server 上那么第二种方案更合适。它不是简单地对配置文件做加密而是把加密工作放到了配置中心这一层。3.1 配置中心加密的工作方式Spring Cloud Config Server 支持对单个属性值加密存储。具体来说你在 Config Server 上配置一个对称密钥或非对称密钥客户端向 Config Server 拉取配置时如果某个值以{cipher}开头Config Server 会先解密再返回给客户端。所以客户端拿到的一直是明文服务端存储的是密文。这样做的好处是敏感信息只出现在两个位置原始配置源头用于加密的明文和 Config Server 的解密内存中。各个微服务的本地仓库不再保存任何配置文件里的真实密码风险面大大缩小。不过也要注意这种方案意味着所有微服务都信任 Config Server 返回的结果。一旦 Config Server 被攻破攻击者可以直接调用解密接口拿到所有明文配置或者直接替换返回给客户端的配置内容。所以 Config Server 本身的安全防护非常重要网络策略、访问控制、密钥存储都必须单独加固。3.2 对称与非对称加密的接入步骤在 Config Server 的配置文件里需要指定加密密钥。对称加密最简单配置一个encrypt.key然后启动服务。假设服务端口是 8888用 curl 请求加密接口curl -X POST http://localhost:8888/encrypt --data-urlencode 数据库真实密码 -H Content-Type: text/plain返回的密文以{cipher}开头与密文拼接放进配置仓库的对应属性里。例如spring: datasource: password: {cipher}AgAAABN...密文客户端服务只需要引入 Spring Cloud Config Client正常配置bootstrap.yml指向 Config Server不需要关心解密逻辑。这种方式接入起来很顺畅而且对原有代码几乎零侵入。非对称加密方式是使用 RSA 密钥对私钥放在 Config Server公钥放在本地加密工具用于生成密文。公钥可以提交到代码库私钥不行。这个适合安全要求更高的场景因为即使公钥泄露别人也无法解密只能用于加密。3.3 适用场景与局限Spring Cloud Config 适合微服务数量多、配置变更频繁、需要统一治理的团队。它解决了配置文件分散导致的敏感信息多处残留问题还能配合 Git 仓库做配置版本管理。但也必须看到它的成本你要额外部署和维护一套配置中心还要处理 Config Server 的高可用和权限控制。对只有两三个 Spring Boot 服务的项目来说引入 Config Server 明显过重。它更适合已经搭好注册中心、网关、配置中心的完整微服务架构否则单纯为了加密配置文件而上整套配置中心性价比很低。另外如果团队没有专门的运维能力Config Server 带来的运维复杂度反而会变成新的风险。我在一个模拟微服务项目里实践过这种方案印象最深的一点是配置仓库里的 Git 历史中那些{cipher}密文即使泄露也无法直接还原明文因为加密私钥只保存在 Config Server 所在环境。但如果私钥本身也被攻破整个体系就会崩盘所以必须把私钥放在单独的安全存储里并严格控制谁能访问 Config Server 的/encrypt接口。4. 方案三自研 AES 解密器完全掌握密钥生命周期第三种方案是我在某个内部工具类项目里尝试过的不依赖 Jasypt也不引入配置中心而是自己在 Spring Boot 启动阶段写一个解密处理器用 AES 对配置值做加解密。它的核心价值在于可以完全控制密钥从哪里读取、什么时候解密、解密后要不要继续传递。4.1 自定义 EnvironmentPostProcessor 实现自动解密Spring Boot 启动过程中EnvironmentPostProcessor是一个很有用的扩展点。它会在 Spring Environment 准备完成后、创建 Bean 之前执行我们可以在这个阶段读取配置文件里的密文并替换成明文。具体思路是定义一种约定格式比如配置值以DEC(开头以)结尾那么启动时就用自定义解密器还原真实值。例如spring: datasource: password: DEC(u3e1hK7k8r9oP2a)然后在META-INF/spring.factories或新版 Spring Boot 的META-INF/spring/org.springframework.boot.env.EnvironmentPostProcessor文件中注册我们的实现类。4.2 代码实现与配置示例先写一个简单的 AES 工具类采用AES/GCM/NoPadding算法密钥从环境变量APP_CONFIG_KEY读取public class AesDecryptor { private static final String ALGORITHM AES/GCM/NoPadding; private static final int IV_SIZE 12; public static String decrypt(String encrypted) throws Exception { String key System.getenv(APP_CONFIG_KEY); if (key null || key.length() ! 16) { throw new IllegalStateException(APP_CONFIG_KEY must be 16 chars); } byte[] data Base64.getDecoder().decode(encrypted); byte[] iv Arrays.copyOfRange(data, 0, IV_SIZE); byte[] cipherBytes Arrays.copyOfRange(data, IV_SIZE, data.length); Cipher cipher Cipher.getInstance(ALGORITHM); SecretKeySpec spec new SecretKeySpec(key.getBytes(StandardCharsets.UTF_8), AES); cipher.init(Cipher.DECRYPT_MODE, spec, new GCMParameterSpec(128, iv)); return new String(cipher.doFinal(cipherBytes), StandardCharsets.UTF_8); } }注意GCM 模式需要 12 字节 IV而且解密前要校验 tag这里我简化了逻辑。生产环境不建议把 IV 和密文直接拼在一起但比例子更复杂的方案就不展开了。然后是 EnvironmentPostProcessor 的实现public class DecryptEnvironmentPostProcessor implements EnvironmentPostProcessor { private static final String PREFIX DEC(; private static final String SUFFIX ); Override public void postProcessEnvironment(ConfigurableEnvironment environment, SpringApplication application) { MutablePropertySources sources environment.getPropertySources(); for (PropertySource? source : sources) { if (source instanceof EnumerablePropertySource) { MapString, Object decrypted new HashMap(); EnumerablePropertySource? enumerable (EnumerablePropertySource?) source; for (String name : enumerable.getPropertyNames()) { Object value enumerable.getProperty(name); if (value instanceof String ((String) value).startsWith(PREFIX)) { String raw ((String) value).substring(PREFIX.length(), ((String) value).length() - SUFFIX.length()); try { decrypted.put(name, AesDecryptor.decrypt(raw)); } catch (Exception e) { throw new IllegalStateException(Failed to decrypt property: name, e); } } } if (!decrypted.isEmpty()) { sources.replace(name, new MapPropertySource(name -decrypted, decrypted)); } } } } }然后在META-INF/spring/org.springframework.boot.env.EnvironmentPostProcessor文件里写com.example.config.DecryptEnvironmentPostProcessor这里的com.example.config需要替换成你自己项目的包名。另外要注意替换 PropertySource 时我用的replace会把原配置源整个替换这在多环境合并时可能影响其他属性。更稳妥的方案是往 Environment 顶层插入一个新的高优先级 PropertySource而不是直接覆盖现有源。我在第一次实现时就因为直接替换导致其他非加密属性丢失后来改成在原来源之前插入MapPropertySource才解决。4.3 自研方案的安全风险与控制措施自研方案最大的风险不是 AES 算法本身而是密钥和 IV 的管理。很多人把密钥直接写死在代码里或者把密钥配置项和密文放在同一个配置文件里这就等于没加密。正确的做法是密钥从环境变量注入同时部署时由运维单独管理该环境变量并定期轮换。另一个风险是缺少标准化的密文格式团队成员容易误操作。如果没有清晰的规范和检查机制很可能出现“新加一个配置忘了加密”的情况。我当时给项目加了一个启动时的扫描逻辑凡是配置项名字包含 password、secret、key、token 等关键字如果值是明文则启动报错强制大家走加密流程。这种方法很暴力但非常有效。最后要提醒一点自研加解密并不难难的是后续的安全审查和密钥轮换机制。如果团队没有专业的密码学知识我不建议在生产系统里自研加密方案更推荐使用成熟库或配置中心。自研方案更适合内部工具、原型验证、以及明确知道自己在做什么的团队。5. 三种方案横向对比与最终选型建议到了这一步三个方案的基本原理和实操路径都清楚了直接给结论很容易误导人。我把它们放到同一张表里从各个维度做对比然后再结合常见项目类型给选型建议。5.1 功能、安全、运维维度对比对比项JasyptSpring Cloud Config自研 AES配置存储位置各服务本地配置文件中央配置仓库各服务本地配置文件密文格式ENC(密文){cipher}密文DEC(密文)或自定义额外依赖引入 starter引入完整配置中心组件无密钥管理方式环境变量/JVM 参数配置中心加密密钥自己实现接入成本低高中对业务代码侵入无无无安全强度中高取决于密钥管理高但配置中心是单点取决于密钥与实现质量适合场景中小型单体服务微服务集群、配置集中管理有特殊需求的内部项目从功能上看Jasypt 和自研 AES 本质上都是“本地密文 启动解密”区别在于标准库是否帮你处理了边界情况。Spring Cloud Config 则完全不同它把加密和配置治理合为一体适合从架构上解决配置分散的问题。5.2 不同项目规模下的选择建议如果项目是单体 Spring Boot服务数量不超过五个团队也没有专门的运维平台我的建议是用 Jasypt。它一行注解都不用写把密文填进去启动时传入密钥就行。Jasypt 社区活跃遇到问题搜一下基本都有答案这是它最大的价值。如果项目已经是微服务架构有配置中心、注册中心等基础设施那直接用 Spring Cloud Config 的加密能力。虽然配置中心本身要维护但这笔投入换来的是统一配置视图和集中的敏感信息管理。需要注意的是务必给 Config Server 加好访问白名单避免任意服务都能拉到全部配置。如果项目只是内部工具不希望引入第三方库或者需要兼容某些非常规的配置来源自研 AES 是可行的。但前提是你能驾驭密钥生命周期包括密钥生成、分发、轮换和回收。做不到这一点就不要因为“看起来简单”而选择这条路线。5.3 实操中的避坑清单根据我做过的几个项目整理了一份避坑清单。第一密钥永远不要和密文放在同一个配置源里哪怕是开发环境。第二加密工具版本和运行版本必须保持一致Jasypt 2.x 升级到 3.x 时算法和 IV 默认值都变了踩坑概率很高。第三配置文件中所有密文值都加引号避免 YAML 解析问题。第四生产环境启动时不要开启打印配置的日志级别否则密文和解密后明文都可能被刷到日志里。第五自定义 EnvironmentPostProcessor 时注意属性源的替换顺序不要覆盖原有的配置优先级。第六无论哪种方案都要准备一个“解密工具”用来排查问题比如确认真实配置值是否符合预期而不是靠猜。另外密钥轮换是很多团队忽略的环节。Jasypt 场景下如果更换密钥所有历史密文都要重新加密否则无法解密。Spring Cloud Config 如果使用的是对称密钥同样的道理。所以建议从一开始就把密钥版本化考虑好轮换策略别等到安全审计要求提上来才动手。我个人在实际操作中最深刻的体会是配置加密这件事工具只占了三分剩下七分靠制度和习惯。Jasypt 用得再好如果有人把解密密钥发给外包群一切等于白做。所以一定要在团队内部约定好敏感信息的处理规范并且用代码扫描、启动检查等手段去兜底而不是只依赖某个加密库。最后分享一个使用技巧如果你用 Jasypt 且担心配置文件里某个密文被误改为明文可以在启动类中增加一个检查逻辑扫描环境变量中的关键属性值一旦发现类似 password 的值不是以ENC(开头就立即抛异常。这种“宁可启动失败也不让明文悄悄上线”的思路帮我避免过好几次危险变更。