1. 为什么要在yml里加密数据库密码但凡做过后端项目的几乎都绕不开一个尴尬的现实数据库密码明文躺在配置文件里。尤其是Spring Boot项目application.yml里一行password: root123456提交到代码仓库的那一刻基本等于把钥匙插在门上还贴了张纸条。我见过太多团队的做法是——开发环境无所谓生产环境靠运维手动改配置或者干脆用环境变量兜着。这些办法不是不行但都有各自的别扭之处。Druid作为国内使用极广的数据库连接池除了连接管理、监控这些常规能力它还内置了一套配置加密机制。这套机制的核心思路很朴素把明文密码用非对称加密算法处理成密文配置文件里只放密文和公钥程序启动时Druid自动用私钥解密。这样即使配置文件泄露攻击者拿到的也只是一串没有私钥就无法还原的密文。这个方案解决的核心问题是配置文件的可读安全性。注意它解决的不是数据库本身的访问安全也不是网络传输安全而是配置文件被看到这个具体场景。很多人在这一点上理解有偏差以为加密了就万事大吉其实不然——私钥如果和配置文件放在一起那加密就形同虚设。所以这套机制的正确用法是密文和公钥放配置文件私钥通过启动参数、环境变量或者独立的密钥文件注入。适合读这篇内容的人大概是这样几类正在用Spring Boot Druid MySQL这套组合的开发者被安全扫描工具报过配置文件明文密码告警的人想给现有项目加一层配置保护但不想大动干戈的人。如果你用的是HikariCP或者其他连接池思路可以参考但具体API不一样需要另找方案。我下面会以druid-1.1.20这个版本为基准来写这个版本在加密这块已经比较稳定了网上很多老教程用的是1.0.xAPI有差异直接照搬容易踩坑。整个流程我会拆成生成密钥对加密密码配置yml启动验证几个环节每个环节都说说为什么这么做以及我实际踩过的坑。2. 密钥对与密文的生成Druid自带工具怎么用2.1 找到正确的工具类入口Druid的加密工具藏在com.alibaba.druid.filter.config.ConfigTools这个类里。1.1.20版本中这个类提供了几个静态方法最常用的是ConfigTools.encrypt(String plainText)和ConfigTools.decrypt(String publicKey, String cipherText)。注意这里的参数顺序很多教程写反了导致解密失败还找不到原因。最省事的验证方式不是写代码而是直接用命令行跑。Druid的jar包下载下来之后可以这样执行java -cp druid-1.1.20.jar com.alibaba.druid.filter.config.ConfigTools 你的明文密码执行完会输出三行内容分别是privateKey、publicKey和encryptedPassword。这三样东西就是后续配置的全部素材。我建议第一次用的时候先拿一个测试密码跑一遍确认工具能正常工作再往正式项目里套。如果你是用Maven管理的项目本地仓库里应该已经有这个jar了路径大概在~/.m2/repository/com/alibaba/druid/1.1.20/druid-1.1.20.jar。直接引用这个路径就行不用额外下载。2.2 三样产物的各自用途和存放原则工具跑出来的三样东西用途完全不同存放位置也必须分开这是整个方案安全性的关键。privateKey私钥用来解密的绝对不能放进配置文件。正确做法是通过启动参数传入比如-Ddruid.config.privateKeyxxx或者用环境变量。如果项目部署在容器里可以用Secret挂载成文件再读取。我见过有人把私钥也写进yml然后还觉得自己加密了这跟没加密没区别。publicKey公钥这个可以放配置文件因为它的作用是加密不是解密。Druid在启动时会用公钥去解密……等等这里有个容易绕晕的点。实际上Druid的解密流程是配置文件里放公钥和密文程序用公钥去解密密文。这是因为Druid用的是非对称加密里的特殊用法——公钥解密、私钥加密。所以公钥放配置文件是安全的私钥才是需要保护的。encryptedPassword密文这个就是替换原来明文密码的位置直接放yml里。我整理了一个对照表方便你一眼看清产物用途存放位置是否可公开privateKey加密密码生成密文时用启动参数/环境变量/密钥文件否必须保护publicKey解密密文运行时用application.yml是可公开encryptedPassword替代明文密码application.yml是可公开注意私钥一旦泄露整套加密就失去意义。所以私钥的管理要当成数据库密码本身来对待甚至更严格。2.3 一个容易忽略的细节换行和空格命令行跑出来的密钥是一长串Base64字符串复制的时候特别容易带上换行或者首尾空格。Druid在解析的时候对空格是敏感的多一个空格就解密失败报的错还是那种看不出所以然的DecryptException。我的习惯是复制到配置文件后用编辑器的显示空白字符功能检查一遍确保没有多余字符。另外如果你是在Windows的cmd里跑命令输出的内容可能会因为编码问题出现乱码。建议在PowerShell或者Git Bash里执行输出更干净。如果实在只有cmd可以把输出重定向到文件再打开看。3. yml配置的完整写法与各字段含义3.1 基础配置结构拿到三样产物之后yml的写法是这样的spring: datasource: druid: url: jdbc:mysql://localhost:3306/your_db?useUnicodetruecharacterEncodingutf8 username: your_username password: ${druid.encrypted.password} filters: config connect-properties: config.decrypt: true config.decrypt.key: ${druid.public.key}这里有几个关键点需要展开说。filters: config这一行是必须的它告诉Druid启用配置过滤器。没有这一行后面的解密配置不会生效Druid会把密文当明文密码直接拿去连数据库结果就是认证失败。connect-properties下面的两个属性是解密的核心。config.decrypt: true开启解密开关config.decrypt.key指定公钥。注意这里的key名字是固定的不能自己改Druid内部就是按这个字符串去取的。3.2 用占位符把敏感信息外置上面写法里我用了${druid.encrypted.password}和${druid.public.key}这种占位符而不是直接把值写死。这样做的好处是密文和公钥可以通过启动参数或者环境变量注入yml文件本身可以放心提交到仓库。对应的启动命令大概是这样java -jar your-app.jar \ --druid.encrypted.password你生成的密文 \ --druid.public.key你生成的公钥如果觉得命令行太长也可以放在application-{profile}.yml里但这个文件要加入.gitignore。两种方式各有取舍命令行参数的好处是不会误提交坏处是每次启动都要带一长串独立配置文件的好处是启动命令干净坏处是要靠纪律保证不提交。我个人的选择是密文和公钥放独立的application-prod.yml并加入gitignore私钥通过环境变量注入。这样配置文件里看不到任何敏感信息启动命令也不至于太长。3.3 私钥的注入方式私钥的注入Druid没有强制规定方式只要在程序启动前能拿到就行。常见的几种第一种是JVM参数-Ddruid.config.privateKeyxxx然后在代码里用System.getProperty读取。这种方式简单直接但JVM参数在有些环境下会被打印到日志里需要注意。第二种是环境变量export DRUID_PRIVATE_KEYxxx代码里用System.getenv读取。容器化部署时这种方式最自然K8s的Secret可以直接挂成环境变量。第三种是独立的密钥文件程序启动时读取文件内容。这种方式适合密钥比较长、不方便放环境变量的场景。不管用哪种核心原则就一条私钥不能出现在任何会被提交到代码仓库的文件里。提示如果你用的是配置中心比如Nacos、Apollo私钥可以放在配置中心的加密配置里这样连环境变量都省了。但配置中心本身的安全要另外考虑。4. 启动验证与常见报错排查4.1 怎么确认解密真的生效了配置写完启动项目怎么知道解密成功了最直接的信号是项目能正常连上数据库没有报认证失败。但这只能说明能用不能说明解密生效了——万一Druid把密文当明文用而你的数据库密码恰好就是那串密文那也能连上当然这种概率极低。更可靠的验证方式是看日志。Druid在解密成功时会打一条debug级别的日志内容大概是decrypt password success之类的。把日志级别调到debug启动一次看到这条日志就说明解密流程走通了。另一个办法是故意把公钥改错一个字符重启项目。如果报解密失败说明解密逻辑确实在跑如果还能正常连数据库那说明你的配置根本没生效Druid在用别的方式拿密码。这个反向验证我强烈建议做一次很多人配了半天其实压根没生效只是碰巧数据库密码简单或者有其他配置兜底。4.2 几个高频报错及对应原因报错一java.lang.RuntimeException: com.alibaba.druid.pool.DruidDataSource$CreateConnectionThread error后面跟着Access denied for user。这个最直接就是密码不对。但要注意区分两种情况一种是密文本身错了比如复制时漏了字符另一种是解密没生效Druid拿密文当明文去连了。区分方法是看日志里有没有解密相关的记录。如果没有检查filters: config和config.decrypt: true是不是都配了。报错二com.alibaba.druid.filter.config.ConfigTools$DecryptException: decrypt error。这是解密过程本身出错常见原因有三个公钥和密文不匹配用了A次生成的公钥配B次生成的密文、公钥里有空格或换行、密文被yml的某些特殊字符转义了。逐个排查重点看公钥的完整性。报错三启动时报Cannot resolve placeholder druid.encrypted.password。这是占位符没被替换说明你用了${}但没提供对应的值。检查启动参数或者环境变量是不是拼写错了Spring的占位符是大小写敏感的。报错四config.decrypt.key配置了但没生效。检查这个属性是不是放在了connect-properties下面。有些教程把它放在druid的直接子级那样是不生效的。Druid读取的是连接属性不是数据源属性这个层级关系不能错。4.3 一个隐蔽的坑yml的冒号转义如果你的密文或者公钥里包含冒号Base64编码的结果里确实可能出现在yml里直接写会被解析成键值对的分隔符。解决办法是用引号把整个值包起来password: ${druid.encrypted.password}或者用yml的块标量写法。我遇到过好几次因为冒号没转义导致配置解析异常的情况报错信息完全看不出跟冒号有关排查了很久。所以养成习惯yml里所有可能含特殊字符的值一律加引号。5. 生产环境落地的几个现实问题5.1 密钥轮换怎么做密码有轮换周期密钥其实也应该有。但Druid这套机制下密钥轮换意味着要重新生成密钥对、重新加密密码、更新配置、重启应用。如果有多套环境、多个实例这个操作成本不低。我的建议是把密钥轮换和密码轮换绑定在一起做。反正改密码也要重启顺便把密钥也换了。轮换时先生成新密钥对用新公钥加密新密码更新配置然后滚动重启。旧密钥在确认所有实例都更新完之后再废弃。如果实例很多滚动重启期间新旧配置会共存这时候要注意新实例用新密钥旧实例用旧密钥两套配置得同时存在一段时间。可以通过配置中心做灰度或者干脆选个低峰期一次性重启。5.2 和现有监控体系的兼容Druid的一大卖点是监控加密配置之后监控还能不能用答案是能因为监控走的是数据源内部的数据跟密码怎么来的没关系。但有一点要注意Druid的监控页面里有时候会显示数据源配置如果配置里包含公钥公钥会显示出来。公钥本身不敏感但如果你的安全规范要求连公钥都不能暴露那就需要在监控页面做过滤。另外有些团队用Druid的StatFilter做SQL监控加密配置不影响这部分功能。真正受影响的是那些直接读取DruidDataSource的password属性的自定义代码——加密后这个属性拿到的是密文不是明文。如果有代码依赖这个需要改成从别的地方拿明文。5.3 多数据源场景下的配置一个项目配多个数据源是常事每个数据源的密码都要加密。这时候公钥可以共用一个密文各自独立。配置结构大概是这样spring: datasource: druid: master: url: jdbc:mysql://master-host:3306/db1 username: user1 password: ${master.encrypted.password} filters: config connect-properties: config.decrypt: true config.decrypt.key: ${druid.public.key} slave: url: jdbc:mysql://slave-host:3306/db2 username: user2 password: ${slave.encrypted.password} filters: config connect-properties: config.decrypt: true config.decrypt.key: ${druid.public.key}注意每个数据源都要单独配filters和connect-properties不能只在顶层配一次。Druid的配置过滤器是绑定在数据源实例上的不是全局的。这一点跟很多人直觉不一样我第一次配多数据源时就栽在这里顶层配了以为下面都生效结果只有一个数据源解密成功。5.4 这套方案的能力边界说了这么多好处也得说清楚它做不到什么。Druid的配置加密解决的是配置文件明文问题它不解决内存中的密码泄露解密后的明文密码在JVM内存里有内存dump权限的人还是能拿到。网络传输安全数据库连接是否加密取决于JDBC URL里的SSL配置跟这个方案无关。数据库侧的访问控制密码加密了但密码本身的权限该多大还是多大不会因为加密就变小。私钥管理私钥怎么安全地送到应用手里这是另一个问题Druid不管。所以正确的定位是它是配置安全的一个环节不是全部。配合最小权限原则、网络隔离、审计日志一起用才有意义。指望一个加密功能解决所有安全问题那是不现实的。我在实际项目里推这套方案时最大的阻力往往不是技术而是流程——运维习惯了直接改配置文件现在要改成走启动参数多了一道手续。这时候需要把好处讲清楚配置文件可以放心提交了密码轮换不用再挨个改文件了安全扫描不再报警了。把这些实际收益摆出来配合度会高很多。最后分享一个我自己的小习惯每次生成新的密钥对之后我会把私钥、公钥、密文三者的对应关系记在一个离线的地方比如加密的笔记软件标注好生成日期和对应的环境。这样过半年再回头看不至于对着一堆密钥发懵不知道哪个是哪个。密钥管理这件事工具能帮的有限更多还是靠人的纪律。 
长河君 · 2026/10/16 10:09:30 · 阅读 1.2k Spring Boot中Druid数据库密码加密配置实战与避坑指南
1. 为什么要在yml里加密数据库密码但凡做过后端项目的几乎都绕不开一个尴尬的现实数据库密码明文躺在配置文件里。尤其是Spring Boot项目application.yml里一行password: root123456提交到代码仓库的那一刻基本等于把钥匙插在门上还贴了张纸条。我见过太多团队的做法是——开发环境无所谓生产环境靠运维手动改配置或者干脆用环境变量兜着。这些办法不是不行但都有各自的别扭之处。Druid作为国内使用极广的数据库连接池除了连接管理、监控这些常规能力它还内置了一套配置加密机制。这套机制的核心思路很朴素把明文密码用非对称加密算法处理成密文配置文件里只放密文和公钥程序启动时Druid自动用私钥解密。这样即使配置文件泄露攻击者拿到的也只是一串没有私钥就无法还原的密文。这个方案解决的核心问题是配置文件的可读安全性。注意它解决的不是数据库本身的访问安全也不是网络传输安全而是配置文件被看到这个具体场景。很多人在这一点上理解有偏差以为加密了就万事大吉其实不然——私钥如果和配置文件放在一起那加密就形同虚设。所以这套机制的正确用法是密文和公钥放配置文件私钥通过启动参数、环境变量或者独立的密钥文件注入。适合读这篇内容的人大概是这样几类正在用Spring Boot Druid MySQL这套组合的开发者被安全扫描工具报过配置文件明文密码告警的人想给现有项目加一层配置保护但不想大动干戈的人。如果你用的是HikariCP或者其他连接池思路可以参考但具体API不一样需要另找方案。我下面会以druid-1.1.20这个版本为基准来写这个版本在加密这块已经比较稳定了网上很多老教程用的是1.0.xAPI有差异直接照搬容易踩坑。整个流程我会拆成生成密钥对加密密码配置yml启动验证几个环节每个环节都说说为什么这么做以及我实际踩过的坑。2. 密钥对与密文的生成Druid自带工具怎么用2.1 找到正确的工具类入口Druid的加密工具藏在com.alibaba.druid.filter.config.ConfigTools这个类里。1.1.20版本中这个类提供了几个静态方法最常用的是ConfigTools.encrypt(String plainText)和ConfigTools.decrypt(String publicKey, String cipherText)。注意这里的参数顺序很多教程写反了导致解密失败还找不到原因。最省事的验证方式不是写代码而是直接用命令行跑。Druid的jar包下载下来之后可以这样执行java -cp druid-1.1.20.jar com.alibaba.druid.filter.config.ConfigTools 你的明文密码执行完会输出三行内容分别是privateKey、publicKey和encryptedPassword。这三样东西就是后续配置的全部素材。我建议第一次用的时候先拿一个测试密码跑一遍确认工具能正常工作再往正式项目里套。如果你是用Maven管理的项目本地仓库里应该已经有这个jar了路径大概在~/.m2/repository/com/alibaba/druid/1.1.20/druid-1.1.20.jar。直接引用这个路径就行不用额外下载。2.2 三样产物的各自用途和存放原则工具跑出来的三样东西用途完全不同存放位置也必须分开这是整个方案安全性的关键。privateKey私钥用来解密的绝对不能放进配置文件。正确做法是通过启动参数传入比如-Ddruid.config.privateKeyxxx或者用环境变量。如果项目部署在容器里可以用Secret挂载成文件再读取。我见过有人把私钥也写进yml然后还觉得自己加密了这跟没加密没区别。publicKey公钥这个可以放配置文件因为它的作用是加密不是解密。Druid在启动时会用公钥去解密……等等这里有个容易绕晕的点。实际上Druid的解密流程是配置文件里放公钥和密文程序用公钥去解密密文。这是因为Druid用的是非对称加密里的特殊用法——公钥解密、私钥加密。所以公钥放配置文件是安全的私钥才是需要保护的。encryptedPassword密文这个就是替换原来明文密码的位置直接放yml里。我整理了一个对照表方便你一眼看清产物用途存放位置是否可公开privateKey加密密码生成密文时用启动参数/环境变量/密钥文件否必须保护publicKey解密密文运行时用application.yml是可公开encryptedPassword替代明文密码application.yml是可公开注意私钥一旦泄露整套加密就失去意义。所以私钥的管理要当成数据库密码本身来对待甚至更严格。2.3 一个容易忽略的细节换行和空格命令行跑出来的密钥是一长串Base64字符串复制的时候特别容易带上换行或者首尾空格。Druid在解析的时候对空格是敏感的多一个空格就解密失败报的错还是那种看不出所以然的DecryptException。我的习惯是复制到配置文件后用编辑器的显示空白字符功能检查一遍确保没有多余字符。另外如果你是在Windows的cmd里跑命令输出的内容可能会因为编码问题出现乱码。建议在PowerShell或者Git Bash里执行输出更干净。如果实在只有cmd可以把输出重定向到文件再打开看。3. yml配置的完整写法与各字段含义3.1 基础配置结构拿到三样产物之后yml的写法是这样的spring: datasource: druid: url: jdbc:mysql://localhost:3306/your_db?useUnicodetruecharacterEncodingutf8 username: your_username password: ${druid.encrypted.password} filters: config connect-properties: config.decrypt: true config.decrypt.key: ${druid.public.key}这里有几个关键点需要展开说。filters: config这一行是必须的它告诉Druid启用配置过滤器。没有这一行后面的解密配置不会生效Druid会把密文当明文密码直接拿去连数据库结果就是认证失败。connect-properties下面的两个属性是解密的核心。config.decrypt: true开启解密开关config.decrypt.key指定公钥。注意这里的key名字是固定的不能自己改Druid内部就是按这个字符串去取的。3.2 用占位符把敏感信息外置上面写法里我用了${druid.encrypted.password}和${druid.public.key}这种占位符而不是直接把值写死。这样做的好处是密文和公钥可以通过启动参数或者环境变量注入yml文件本身可以放心提交到仓库。对应的启动命令大概是这样java -jar your-app.jar \ --druid.encrypted.password你生成的密文 \ --druid.public.key你生成的公钥如果觉得命令行太长也可以放在application-{profile}.yml里但这个文件要加入.gitignore。两种方式各有取舍命令行参数的好处是不会误提交坏处是每次启动都要带一长串独立配置文件的好处是启动命令干净坏处是要靠纪律保证不提交。我个人的选择是密文和公钥放独立的application-prod.yml并加入gitignore私钥通过环境变量注入。这样配置文件里看不到任何敏感信息启动命令也不至于太长。3.3 私钥的注入方式私钥的注入Druid没有强制规定方式只要在程序启动前能拿到就行。常见的几种第一种是JVM参数-Ddruid.config.privateKeyxxx然后在代码里用System.getProperty读取。这种方式简单直接但JVM参数在有些环境下会被打印到日志里需要注意。第二种是环境变量export DRUID_PRIVATE_KEYxxx代码里用System.getenv读取。容器化部署时这种方式最自然K8s的Secret可以直接挂成环境变量。第三种是独立的密钥文件程序启动时读取文件内容。这种方式适合密钥比较长、不方便放环境变量的场景。不管用哪种核心原则就一条私钥不能出现在任何会被提交到代码仓库的文件里。提示如果你用的是配置中心比如Nacos、Apollo私钥可以放在配置中心的加密配置里这样连环境变量都省了。但配置中心本身的安全要另外考虑。4. 启动验证与常见报错排查4.1 怎么确认解密真的生效了配置写完启动项目怎么知道解密成功了最直接的信号是项目能正常连上数据库没有报认证失败。但这只能说明能用不能说明解密生效了——万一Druid把密文当明文用而你的数据库密码恰好就是那串密文那也能连上当然这种概率极低。更可靠的验证方式是看日志。Druid在解密成功时会打一条debug级别的日志内容大概是decrypt password success之类的。把日志级别调到debug启动一次看到这条日志就说明解密流程走通了。另一个办法是故意把公钥改错一个字符重启项目。如果报解密失败说明解密逻辑确实在跑如果还能正常连数据库那说明你的配置根本没生效Druid在用别的方式拿密码。这个反向验证我强烈建议做一次很多人配了半天其实压根没生效只是碰巧数据库密码简单或者有其他配置兜底。4.2 几个高频报错及对应原因报错一java.lang.RuntimeException: com.alibaba.druid.pool.DruidDataSource$CreateConnectionThread error后面跟着Access denied for user。这个最直接就是密码不对。但要注意区分两种情况一种是密文本身错了比如复制时漏了字符另一种是解密没生效Druid拿密文当明文去连了。区分方法是看日志里有没有解密相关的记录。如果没有检查filters: config和config.decrypt: true是不是都配了。报错二com.alibaba.druid.filter.config.ConfigTools$DecryptException: decrypt error。这是解密过程本身出错常见原因有三个公钥和密文不匹配用了A次生成的公钥配B次生成的密文、公钥里有空格或换行、密文被yml的某些特殊字符转义了。逐个排查重点看公钥的完整性。报错三启动时报Cannot resolve placeholder druid.encrypted.password。这是占位符没被替换说明你用了${}但没提供对应的值。检查启动参数或者环境变量是不是拼写错了Spring的占位符是大小写敏感的。报错四config.decrypt.key配置了但没生效。检查这个属性是不是放在了connect-properties下面。有些教程把它放在druid的直接子级那样是不生效的。Druid读取的是连接属性不是数据源属性这个层级关系不能错。4.3 一个隐蔽的坑yml的冒号转义如果你的密文或者公钥里包含冒号Base64编码的结果里确实可能出现在yml里直接写会被解析成键值对的分隔符。解决办法是用引号把整个值包起来password: ${druid.encrypted.password}或者用yml的块标量写法。我遇到过好几次因为冒号没转义导致配置解析异常的情况报错信息完全看不出跟冒号有关排查了很久。所以养成习惯yml里所有可能含特殊字符的值一律加引号。5. 生产环境落地的几个现实问题5.1 密钥轮换怎么做密码有轮换周期密钥其实也应该有。但Druid这套机制下密钥轮换意味着要重新生成密钥对、重新加密密码、更新配置、重启应用。如果有多套环境、多个实例这个操作成本不低。我的建议是把密钥轮换和密码轮换绑定在一起做。反正改密码也要重启顺便把密钥也换了。轮换时先生成新密钥对用新公钥加密新密码更新配置然后滚动重启。旧密钥在确认所有实例都更新完之后再废弃。如果实例很多滚动重启期间新旧配置会共存这时候要注意新实例用新密钥旧实例用旧密钥两套配置得同时存在一段时间。可以通过配置中心做灰度或者干脆选个低峰期一次性重启。5.2 和现有监控体系的兼容Druid的一大卖点是监控加密配置之后监控还能不能用答案是能因为监控走的是数据源内部的数据跟密码怎么来的没关系。但有一点要注意Druid的监控页面里有时候会显示数据源配置如果配置里包含公钥公钥会显示出来。公钥本身不敏感但如果你的安全规范要求连公钥都不能暴露那就需要在监控页面做过滤。另外有些团队用Druid的StatFilter做SQL监控加密配置不影响这部分功能。真正受影响的是那些直接读取DruidDataSource的password属性的自定义代码——加密后这个属性拿到的是密文不是明文。如果有代码依赖这个需要改成从别的地方拿明文。5.3 多数据源场景下的配置一个项目配多个数据源是常事每个数据源的密码都要加密。这时候公钥可以共用一个密文各自独立。配置结构大概是这样spring: datasource: druid: master: url: jdbc:mysql://master-host:3306/db1 username: user1 password: ${master.encrypted.password} filters: config connect-properties: config.decrypt: true config.decrypt.key: ${druid.public.key} slave: url: jdbc:mysql://slave-host:3306/db2 username: user2 password: ${slave.encrypted.password} filters: config connect-properties: config.decrypt: true config.decrypt.key: ${druid.public.key}注意每个数据源都要单独配filters和connect-properties不能只在顶层配一次。Druid的配置过滤器是绑定在数据源实例上的不是全局的。这一点跟很多人直觉不一样我第一次配多数据源时就栽在这里顶层配了以为下面都生效结果只有一个数据源解密成功。5.4 这套方案的能力边界说了这么多好处也得说清楚它做不到什么。Druid的配置加密解决的是配置文件明文问题它不解决内存中的密码泄露解密后的明文密码在JVM内存里有内存dump权限的人还是能拿到。网络传输安全数据库连接是否加密取决于JDBC URL里的SSL配置跟这个方案无关。数据库侧的访问控制密码加密了但密码本身的权限该多大还是多大不会因为加密就变小。私钥管理私钥怎么安全地送到应用手里这是另一个问题Druid不管。所以正确的定位是它是配置安全的一个环节不是全部。配合最小权限原则、网络隔离、审计日志一起用才有意义。指望一个加密功能解决所有安全问题那是不现实的。我在实际项目里推这套方案时最大的阻力往往不是技术而是流程——运维习惯了直接改配置文件现在要改成走启动参数多了一道手续。这时候需要把好处讲清楚配置文件可以放心提交了密码轮换不用再挨个改文件了安全扫描不再报警了。把这些实际收益摆出来配合度会高很多。最后分享一个我自己的小习惯每次生成新的密钥对之后我会把私钥、公钥、密文三者的对应关系记在一个离线的地方比如加密的笔记软件标注好生成日期和对应的环境。这样过半年再回头看不至于对着一堆密钥发懵不知道哪个是哪个。密钥管理这件事工具能帮的有限更多还是靠人的纪律。