1. 项目概述：为什么Druid的SQL密码加密是必选项

如果你在用Druid连接池，还在配置文件里写password=123456，那你的数据库可能正在“裸奔”。这不是危言耸听，我见过太多项目，包括一些体量不小的系统，数据库密码就这么明文躺在application.yml或者druid.properties里。运维、开发、甚至版本控制系统里都能看到。一旦配置文件泄露，攻击者拿到数据库连接，后果不堪设想。所以，给Druid的SQL连接密码加密，不是一个“可选项”，而是一个必须立刻上马的“安全基线”。

Druid作为阿里巴巴开源的优秀数据库连接池，除了监控、防SQL注入这些广为人知的功能，其实早就内置了一套完善的密码加解密机制。核心就是通过一个叫ConfigFilter的过滤器来实现的。简单来说，它的工作原理是：你在配置文件里存放的是加密后的密文，应用启动时，Druid会调用这个过滤器，用你配置的密钥对密文进行解密，拿到真正的明文密码，再去创建数据库连接。整个过程对业务代码完全透明，你只需要在配置上做一点改动。

很多人觉得这步操作麻烦，或者觉得内网环境无所谓。但根据我多年的运维和开发经验，安全漏洞往往发生在最意想不到的环节。比如，开发人员把带密码的配置文件误传到公开的Git仓库；再比如，服务器被入侵，攻击者第一件事就是翻找各种配置文件。把密码加密，相当于给数据库大门加了一把锁，即使配置文件被看到，攻击者也无法直接使用。接下来，我就带你从原理到实操，彻底搞定Druid的SQL密码加密。

2. 核心原理与方案选型：为什么是ConfigFilter和RSA？

2.1 Druid密码加密的底层逻辑

Druid的密码加密解密，其核心是一个名为com.alibaba.druid.filter.config.ConfigFilter的类。它实现了Filter接口，在连接池初始化的关键链路中发挥作用。你可以把它理解为一个“密码翻译官”。

它的工作流程是这样的：

1. 启动阶段：当Spring Boot应用启动，初始化DruidDataSource时，会读取配置文件（如spring.datasource.druid.connection-properties中的配置）。
2. 过滤器介入：如果配置中启用了ConfigFilter，Druid会实例化它。ConfigFilter会扫描所有以config.开头的配置项。
3. 解密操作：当它发现config.decrypt、config.decrypt.key等关键配置后，就会对配置文件中指定的加密内容（比如password=后面的密文）进行解密。
4. 替换明文：解密得到的明文密码，会被设置回DataSource的属性中，后续的连接创建就使用这个解密后的密码。

整个过程对JdbcTemplate、MyBatis等数据库操作框架完全无感，它们拿到的DataSource已经是一个“准备好了”的正确连接池。

2.2 加密算法选型：对称加密 vs 非对称加密

Druid官方主要支持两种方式：RSA非对称加密和简单的对称加密。这里我强烈推荐使用RSA非对称加密。

• 对称加密（如AES）：加密和解密使用同一把密钥。这把密钥既要放在生成密文的开发环境，又要放在运行密文的线上服务器环境。如果服务器被攻破，密钥和密文同时暴露，加密就形同虚设。这相当于把钥匙和锁一起给了别人。
• RSA非对称加密：会生成一对密钥：公钥（Public Key）和私钥（Private Key）。公钥用来加密，私钥用来解密。公钥可以公开，你甚至可以把它放到代码仓库里；而私钥必须严格保密，只存放在线上服务器。这样，开发人员可以用公钥加密密码，将密文写入配置。而线上服务器用私钥解密。即使代码和配置文件全部泄露，攻击者没有私钥，也无法解密出密码。

注意：网上有些教程会教你用Druid自带的命令行工具生成简单的对称加密密码，这在早期版本或许可行，但从安全角度是不推荐的。RSA方案在密钥管理上更安全，也是目前生产环境的主流实践。

2.3 方案对比与决策

为了更清晰，我把几种常见的密码处理方式做个对比：

对于绝大多数Spring Boot项目，综合安全性、复杂度和可控性，“Druid RSA非对称加密”是最佳平衡点。下面我们就按这个方案来实施。

3. 详细配置与实操步骤：手把手实现加密

3.1 第一步：生成RSA密钥对

这是最核心的一步，我们需要生成一对RSA密钥。你可以使用Druid自带的工具类来生成，非常方便。

1. 编写一个简单的Java类：在你的项目里随便找个地方（比如test目录下）创建一个GenKeyPair.java。

import com.alibaba.druid.filter.config.ConfigTools; public class GenKeyPair { public static void main(String[] args) throws Exception { // 生成密钥对，参数“密码”用于加密私钥，可以为空字符串 String[] keyPair = ConfigTools.genKeyPair(512); // 512是密钥长度，也可用1024，更长更安全但性能略低 System.out.println("私钥（Private Key）: " + keyPair[0]); System.out.println("公钥（Public Key）: " + keyPair[1]); System.out.println("请妥善保存私钥，切勿泄露！公钥可用于加密。"); } }

2. 运行并保存结果：执行这个main方法，控制台会打印出私钥和公钥。务必妥善保存私钥，建议放到服务器的安全位置（如仅限运维人员访问的目录），或者放入服务器的环境变量中。公钥可以放在项目里。

实操心得：

• 密钥长度512对于密码加密足够用，生成也快。如果对安全有极致要求，可以用1024或2048。
• 一定要把私钥和公钥分开保存。我的习惯是：将公钥（publicKey）放到项目的配置目录下（如config/），并加入.gitignore，防止误提交。私钥则通过运维部署脚本，在启动应用时注入到环境变量里。

3.2 第二步：使用公钥加密数据库密码

拿到公钥后，我们需要对原始的数据库明文密码进行加密。同样使用Druid的工具。

import com.alibaba.druid.filter.config.ConfigTools; public class EncryptPassword { public static void main(String[] args) throws Exception { String publicKey = "你的公钥字符串"; // 替换为上一步生成的公钥 String plainPassword = "your_db_password_123"; // 替换为你的真实数据库密码 String encryptedPassword = ConfigTools.encrypt(publicKey, plainPassword); System.out.println("加密后的密码: " + encryptedPassword); } }

运行后，你会得到一长串加密后的密文。这个密文就是将来要写入配置文件的内容。

3.3 第三步：在Spring Boot中配置Druid

假设你使用的是application.yml，配置如下。关键点在于connection-properties和filters。

spring: datasource: type: com.alibaba.druid.pool.DruidDataSource driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/your_db?useUnicode=true&characterEncoding=utf8 username: your_username password: 上面生成的加密后的密文 # 这里放密文！ druid: # 连接池通用配置 initial-size: 5 min-idle: 5 max-active: 20 # 关键配置：启用ConfigFilter并指定解密属性 filters: config connection-properties: | config.decrypt=true config.decrypt.key=${DRUID_PUBLIC_KEY:你的公钥字符串} # 优先从环境变量DRUID_PUBLIC_KEY读取，没有则用默认值 # 如果你的密码是加密的，必须设置此项为true config.decrypt=true # 其他监控等配置 stat-view-servlet: enabled: true login-username: admin login-password: admin123 web-stat-filter: enabled: true

配置解析与注意事项：

1. filters: config：这行必须加上，用于启用ConfigFilter。
2. connection-properties：这是一个多行属性，里面的配置会传递给ConfigFilter。
   • config.decrypt=true：告诉过滤器，密码需要解密。
   • config.decrypt.key：这是核心。这里应该放你的公钥。我强烈推荐使用${}占位符从环境变量读取（如${DRUID_PUBLIC_KEY}）。这样，公钥就不需要硬编码在配置文件中，可以通过启动命令-DDRUID_PUBLIC_KEY=xxx或容器环境变量传入，更安全。
3. password字段：这里填写的已经是加密后的密文，不再是明文。

踩坑提醒：这里最容易出错的就是config.decrypt.key放错了密钥。记住，这里放的是公钥，不是私钥！私钥是解密方（服务器）使用的，在Druid的这个配置里，我们是用公钥加密，所以配置里也是公钥。Druid内部会用这个公钥去验证和解密（实际上RSA解密用的是私钥，但Druid的ConfigFilter在decrypt模式下，配置的公钥是用于解密流程的特定环节，更准确地说，它需要配对私钥来工作。但官方示例和常见实践中，config.decrypt.key通常放置的是公钥，私钥通过config.decrypt.key的另一种方式或默认机制在Druid内部使用。为了简化并避免混淆，最稳妥的做法是：使用ConfigTools.encrypt()加密时用的公钥，就放在config.decrypt.key里。Druid的ConfigFilter在decrypt=true时，默认会使用这个key作为公钥去处理密码。如果遇到解密失败，请检查密钥是否配对）。

3.4 第四步：提供私钥给运行环境

应用启动时，ConfigFilter需要私钥来完成解密。私钥绝对不能写在项目代码或配置里。正确做法是通过系统属性或环境变量传入。

方式一：启动命令传入（推荐）

java -jar your-app.jar \ --druid.config.decrypt.key=你的公钥字符串 \ -Ddruid.config.decrypt.key=你的公钥字符串 # 两种方式均可，Spring Boot能识别

在application.yml中，config.decrypt.key配置为${druid.config.decrypt.key:}，即可读取到此值。

方式二：在IDE的运行配置中设置环境变量如果你在本地开发调试，可以在IDE的Run/Debug Configuration中，添加一个环境变量：

DRUID_PUBLIC_KEY=你的公钥字符串

然后在YAML配置中使用${DRUID_PUBLIC_KEY}引用。

方式三：置于服务器环境变量在生产环境的服务器上，将公钥设置为操作系统环境变量，或在容器（如Docker）的启动脚本中设置，确保安全。

4. 深入排查：常见问题与解决方案实录

即使按照步骤操作，也可能会遇到问题。下面是我在多次部署中总结的常见错误和解决方法。

4.1 问题一：启动报错java.lang.IllegalArgumentException: Failed to decrypt.

这是最典型的错误，意思是解密失败。

排查思路：

1. 检查密钥配对：确保用于解密的config.decrypt.key（公钥）和最初加密密码时使用的公钥是同一对密钥中的公钥。用错密钥对必然失败。重新执行一遍生成密钥对和加密的流程，确保使用匹配的公私钥。
2. 检查密码密文：确认password字段里的密文，是否就是由正确的公钥加密生成的。有没有多复制了空格、换行符？最好把密文贴到一个文本编辑器里，检查首尾是否有不可见字符。
3. 检查私钥的提供方式：确认私钥是否正确地提供给了应用。如果你在connection-properties里配置了config.decrypt.key（公钥），那么Druid默认会使用系统属性druid.config.decrypt.key中的值作为公钥。请确保启动命令或环境变量设置正确。一个快速的测试方法是，在应用启动后的日志中，搜索druid关键词，看Druid初始化时的配置日志，确认config.decrypt.key的值是否被正确加载。
4. 密钥长度问题：如果你用的密钥长度是1024，但加密时可能因为某些工具默认不同，导致格式不兼容。确保生成、加密、解密整个链条使用的工具和参数一致，都使用Druid的ConfigTools类。

4.2 问题二：配置了加密，但连接池初始化成功，监控页面却显示明文密码？

这是一个“虚惊一场”的问题，但很重要。Druid的监控页面（StatViewServlet）为了展示友好，默认会显示解密后的明文密码。这引发了安全担忧。

解决方案：从安全角度，生产环境必须关闭Druid监控页面的直接访问，或者至少要加强访问控制。在配置中：

spring: datasource: druid: stat-view-servlet: enabled: true # 可以开启，但必须配下面两项 login-username: 一个强用户名 # 必须设置 login-password: 一个强密码 # 必须设置 allow: 127.0.0.1 # 只允许本机访问，生产环境可以设置为空或内网IP deny: # 拒绝所有其他IP

更安全的做法是，通过公司内部的网关或认证系统来代理访问监控页面，而不是直接暴露在公网。监控页面显示的密码是Druid从内存中读取的，只要你的应用服务器本身是安全的，这个风险相对可控，但依然要遵循最小暴露原则。

4.3 问题三：多数据源场景下如何配置加密？

现在微服务架构下，一个应用连接多个数据库很常见。Druid在多数据源下的密码加密配置原理相同，但结构稍复杂。

假设你有两个数据源：primaryDataSource和secondaryDataSource。

@Configuration public class DruidConfig { @Bean @ConfigurationProperties("spring.datasource.druid.primary") public DataSource primaryDataSource() { // 这里DruidDataSource会根据前缀自动绑定属性 return DruidDataSourceBuilder.create().build(); } @Bean @ConfigurationProperties("spring.datasource.druid.secondary") public DataSource secondaryDataSource() { return DruidDataSourceBuilder.create().build(); } }

对应的application.yml配置：

spring: datasource: druid: # 公共的Druid配置，如果每个数据源不同，则需分别配置 filters: config connection-properties: | config.decrypt=true config.decrypt.key=${DRUID_PUBLIC_KEY} stat-view-servlet: enabled: true login-username: admin login-password: admin123 primary: url: jdbc:mysql://host1:3306/db1 username: user1 password: 数据源1的加密密码 driver-class-name: com.mysql.cj.jdbc.Driver # 可以覆盖公共配置 filters: config,wall,stat secondary: url: jdbc:mysql://host2:3306/db2 username: user2 password: 数据源2的加密密码 driver-class-name: com.mysql.cj.jdbc.Driver initial-size: 3 max-active: 15

关键点：每个数据源的password字段填入各自对应的加密密文。filters和connection-properties可以在公共部分配置，作用于所有数据源。如果某个数据源不需要加密（极不推荐），可以在其专属配置下覆盖filters。

4.4 问题四：密码加密后，如何动态修改密码？

这是密码加密方案的高级话题。传统明文配置下，改密码需要重启应用。而使用ConfigFilter并结合外部配置（如环境变量），可以实现一定程度的动态性，但并非完全热更新。

推荐方案：

1. 密码轮换：当数据库密码需要变更时，运维人员用新的密码生成新的密文。
2. 更新配置源：将新的密文更新到配置中心（如Apollo、Nacos）或服务器环境变量中。
3. 应用刷新：对于Spring Boot应用，可以使用@RefreshScope注解刷新DataSourceBean，或者通过Actuator的/refresh端点（Spring Boot 2.7之前）来动态更新配置。但是请注意，Druid连接池本身持有的物理连接可能仍然使用旧的密码，直到连接重建。最稳妥的方式是，在密码变更后，安排一次应用的重启（可以滚动重启），以确保所有连接都使用新密码建立。

更复杂的动态密码管理（如与Vault集成）则需要更深入的定制，超出了基础加密的范围。

5. 安全加固与最佳实践建议

配置完密码加密只是第一步，围绕Druid和数据安全，还有几个必须关注的加固点。

5.1 关闭监控页面的风险

如前所述，stat-view-servlet虽然方便，但也是安全隐患。除了设置强密码和IP白名单外，生产环境我建议通过条件配置来彻底关闭它。

spring: datasource: druid: stat-view-servlet: enabled: @spring.profiles.active@ != 'prod' # 非生产环境才开启 # 或者使用明确的配置 # enabled: false

5.2 连接池参数优化与防泄漏

密码安全了，连接池本身的使用也要规范，防止连接泄漏导致资源耗尽。

• 配置合理的超时时间：remove-abandoned-timeout（例如300秒），connection-error-retry-attempts（0表示不重试）。
• 开启泄漏检测：remove-abandoned: true和log-abandoned: true，这样长时间未关闭的连接会被回收，并打印日志，方便定位问题代码。
• 定期验证连接：validation-query: SELECT 1和test-while-idle: true，确保连接池中的连接是有效的。

5.3 密钥管理规范

• 公私钥分离：公钥可以放在项目配置目录（但需.gitignore），私钥必须通过安全的CI/CD管道或运维工具注入到生产环境，绝不能进入代码仓库。
• 定期轮换密钥：像轮换密码一样，定期（如每半年或一年）生成新的RSA密钥对，重新加密所有数据库密码并更新配置。这能有效降低密钥长期暴露的风险。
• 使用专业的密钥管理服务：在大型企业或对安全要求极高的场景，考虑使用HashiCorp Vault、阿里云KMS等专业服务来管理私钥，应用在启动时从这些服务动态获取。

5.4 与整体安全体系结合

Druid密码加密是应用层安全的一环，还需要与其他措施配合：

• 数据库层面：限制数据库账号的权限，遵循最小权限原则。生产环境的数据库账号只授予必要的CRUD权限，禁止DROP、GRANT等操作。
• 网络层面：数据库服务器应该部署在内网，通过安全组或防火墙严格限制访问来源IP，只允许应用服务器访问。
• 运维层面：配置文件、日志中都不能出现明文密码。定期进行安全扫描和审计。

配置Druid的SQL密码加密，从生成密钥到最终上线，整个过程如果熟练了，半小时内就能搞定。但这半小时的投入，为你的系统数据库增加了一道坚实的防线。在安全问题上，永远不要抱有侥幸心理。看似繁琐的步骤，都是为了在出现问题时，能将损失降到最低。我经历过因为配置文件泄露导致的紧急排查，那种焦头烂额的感觉，希望你们永远不要遇到。从今天起，就把明文密码从你的配置文件中清理掉吧。