1. 项目概述：从“明文裸奔”到“加密武装”

如果你刚接触数据库开发或者运维，是不是经常在配置文件里看到类似password=123456这样的数据库连接密码？或者，你的项目里是不是直接把数据库密码写死在代码里，然后上传到了某个代码托管平台？如果你点头了，那这篇文章就是为你准备的。数据库密码加密，这听起来像是一个高大上的安全话题，但它的本质其实很简单：给你的数据库大门加一把可靠的锁，而不是把钥匙直接插在门上。

我们这次要聊的，不是那些复杂的、需要专业安全团队介入的企业级全链路加密方案，而是每一个开发者、每一个项目在起步阶段就应该掌握的基础安全实践。核心就围绕两个问题展开：第一，为什么数据库密码必须加密？第二，具体怎么加密？我会用最直白的方式，带你从“为什么”一直走到“怎么做”，让你不仅能动手实现，更能理解每一步背后的安全逻辑。无论是个人项目、毕业设计，还是初创公司的第一个产品，这套思路都能帮你筑起第一道安全防线。

2. 核心需求解析：为什么数据库密码不能“裸奔”？

在动手之前，我们必须先达成共识：对数据库密码进行加密存储，不是一道可选题，而是一道必答题。这背后的逻辑，远比我们想象的要深刻。

2.1 风险场景：密码泄露的“多米诺骨牌”效应

想象一下，你的应用配置文件application.properties或config.yaml里明文写着数据库连接字符串。一旦这个文件因为以下任何一种情况被泄露，后果将是灾难性的：

1. 代码仓库泄露：这是新手最容易踩的坑。为了方便，直接把包含数据库配置的代码推送到 GitHub、Gitee 等公开或权限设置不当的私有仓库。黑客有专门的爬虫工具，7x24小时扫描全网代码仓库，寻找这类“宝藏”。
2. 服务器入侵：攻击者通过应用漏洞（如SQL注入、文件上传漏洞）拿到了服务器部分权限，第一件事就是翻找配置文件。明文密码让他可以长驱直入，直接操作你的核心数据库。
3. 配置中心管理不当：即使使用了配置中心，如果配置中心本身的安全策略薄弱，或者传输、存储过程未加密，密码同样面临风险。
4. 内部人员风险：开发、测试、运维人员都有可能接触到配置文件。明文存储意味着任何能接触到配置的人，都掌握了打开数据库的钥匙，这不符合“最小权限原则”。

一旦数据库密码泄露，攻击者就获得了对你数据资产的最高权限。他可以随意增删改查数据、拖走整个数据库、甚至植入勒索病毒。对于用户来说，这意味着隐私泄露（如手机号、地址）；对于企业来说，这可能意味着商业机密丢失、服务中断、巨额罚款和声誉崩塌。

2.2 加密的本质：增加攻击成本与时间

安全领域有一个共识：没有绝对的安全，只有相对的安全。加密的目的，不是制造一个“无法破解”的保险箱（理论上不存在），而是极大提高攻击者的成本和所需时间，使其攻击行为变得不划算。

• 明文存储：攻击成本几乎为0。看到即得到。
• 简单编码（如Base64）：攻击成本极低。这根本不是加密，只是换了一种表示形式，相当于把钥匙从门上拔下来，藏在了脚垫下面。
• 弱加密算法（如DES、自制算法）：攻击成本较低。可能被暴力破解或利用算法漏洞快速攻破。
• 强加密算法（如AES-256）配合妥善的密钥管理：攻击成本极高。即使攻击者拿到了密文，在没有密钥的情况下，想通过暴力破解可能需要数百年甚至更久的时间。

我们的目标，就是通过合理的加密手段，将风险从“瞬时灾难”降级为“可预警、可处置的安全事件”。

2.3 合规性要求

除了实际的安全风险，越来越多的行业标准和法律法规也明确要求对敏感信息（数据库凭证无疑是核心敏感信息）进行加密存储。例如，等保2.0、GDPR（通用数据保护条例）等，都对数据安全提出了明确要求。未加密存储密码，在审计和合规检查中是一个明确的扣分项甚至违规项。

注意：这里务必区分两个概念——“数据库存储加密”和“数据库密码加密”。前者是指对数据库内部存储的数据进行加密（如TDE透明数据加密），防止硬盘被盗导致数据泄露。后者是指对连接数据库所用的密码这个字符串进行加密，防止配置泄露导致数据库被非法访问。本文聚焦于后者，即“连接凭证的安全”。

3. 技术方案选型：对称、非对称还是哈希？

明确了“为什么”，接下来就是“用什么”。加密算法种类繁多，选错了方向，可能事倍功半甚至引入新的风险。对于数据库密码加密这个场景，我们主要考虑以下几种方案：

3.1 哈希算法（Hashing）：单向的“指纹”验证

• 原理：将任意长度的输入（密码）通过哈希函数（如SHA-256, bcrypt, Argon2）转换成固定长度的、不可逆的字符串（哈希值）。像指纹一样，理论上无法从指纹还原出整个人。
• 典型应用：用户登录密码的存储。服务器不存储用户明文密码，只存储其哈希值。登录时，对用户输入的密码做同样的哈希计算，比对哈希值是否一致。
• 为什么不适合数据库密码加密？因为数据库连接时，客户端（你的应用）需要向数据库服务端提供原始的、可用的密码进行身份认证。哈希是不可逆的，你无法从哈希值还原出密码明文去连接数据库。所以，哈希算法在此场景下不适用。

3.2 对称加密（Symmetric Encryption）：用同一把钥匙锁和开

• 原理：加密和解密使用同一把密钥。就像你用同一把钥匙锁门和开门。
• 常见算法：AES (Advanced Encryption Standard)， 是目前最主流、最安全的对称加密算法，密钥长度通常为128、192或256位。
• 适用性分析：
  • 优点：加解密速度快，效率高，适合对大量数据进行加密。
  • 缺点：密钥管理是最大挑战。加密后的密码（密文）和加密密钥（Key）都需要保存。如果密钥和密文放在一起（比如都写在配置文件里），那加密就形同虚设。
• 结论：可用，但关键在于如何安全地管理加密密钥。需要将密钥与密文分离存储。

3.3 非对称加密（Asymmetric Encryption）：公钥锁，私钥开

• 原理：使用一对密钥：公钥（Public Key）和私钥（Private Key）。公钥可以公开，用于加密数据；私钥必须严格保密，用于解密数据。就像每个人都有一个公开的投信口（公钥）和一个私有的开箱钥匙（私钥）。
• 常见算法：RSA, ECC。
• 适用性分析：
  • 优点：解决了对称加密的密钥分发难题。你可以放心地把公钥给任何人，即使他们用公钥加密了信息，也只有持有私钥的你能解密。
  • 缺点：加解密速度比对称加密慢得多，不适合加密大量数据。
• 结论：非常适合本场景。我们可以用公钥加密数据库密码，将密文存入配置文件或环境变量。应用启动时，用严格保密的私钥（存放在服务器安全位置，或由硬件安全模块HSM管理）来解密出明文密码，用于连接数据库。这样，即使配置文件泄露，攻击者没有私钥也无法解密。

3.4 方案对比与选型建议

给新手的实操建议：

1. 个人项目/学习环境：如果对安全性要求不是极端苛刻，可以采用“对称加密（AES）+ 密钥与密文分离”的方案。例如，将加密后的密码放在配置文件中，而加密密钥通过环境变量传递。这样，即使代码和配置文件泄露，攻击者没有服务器上的环境变量，也无法解密。
2. 生产环境/对安全有要求：强烈推荐使用“非对称加密（RSA）”方案。将公钥集成到你的应用构建或部署流程中用于加密密码，私钥则存放在服务器上一个权限严格控制的位置（如仅应用运行用户可读），或使用专业的密钥管理服务（KMS）。
3. 利用现有框架能力：许多成熟的框架和配置中心（如Spring Cloud Config, Apache Commons Configuration）都内置或可集成加解密功能，通常采用非对称加密，直接使用它们是更高效、更安全的选择。

4. 实战演练：三种主流加密方案实现

理论说再多，不如动手做一遍。下面我将分别演示对称加密、非对称加密以及利用Spring Boot框架的配置加密这三种最实用的实现方式。我会使用Java语言示例，但原理是通用的。

4.1 方案一：使用AES对称加密（密钥分离）

这个方案的核心思想是：用AES算法加密密码，但加密密钥不写在配置文件中。

步骤1：生成一个强密钥不要使用像“mySecretKey123”这样的字符串作为密钥。AES-256要求一个32字节（256位）的密钥。我们可以用安全的随机数生成器来生成。

import javax.crypto.KeyGenerator; import javax.crypto.SecretKey; import java.util.Base64; public class KeyGenUtil { public static String generateAESKey() throws Exception { KeyGenerator keyGen = KeyGenerator.getInstance("AES"); keyGen.init(256); // 指定密钥长度 SecretKey secretKey = keyGen.generateKey(); return Base64.getEncoder().encodeToString(secretKey.getEncoded()); } public static void main(String[] args) throws Exception { String aesKey = generateAESKey(); System.out.println("生成的AES密钥 (Base64): " + aesKey); // 示例输出： `k4P7qN9wV2zXcF1hJmZ3L0oA8bR5tY6uI` } }

步骤2：使用生成的密钥加密数据库密码假设你的数据库密码是MySuperSecretDBP@ssw0rd。

import javax.crypto.Cipher; import javax.crypto.spec.SecretKeySpec; import java.util.Base64; public class AESEncryptor { private static final String ALGORITHM = "AES"; public static String encrypt(String plainText, String base64Key) throws Exception { byte[] keyBytes = Base64.getDecoder().decode(base64Key); SecretKeySpec secretKey = new SecretKeySpec(keyBytes, ALGORITHM); Cipher cipher = Cipher.getInstance(ALGORITHM); cipher.init(Cipher.ENCRYPT_MODE, secretKey); byte[] encryptedBytes = cipher.doFinal(plainText.getBytes("UTF-8")); return Base64.getEncoder().encodeToString(encryptedBytes); } public static void main(String[] args) throws Exception { String originalPassword = "MySuperSecretDBP@ssw0rd"; String base64AESKey = "k4P7qN9wV2zXcF1hJmZ3L0oA8bR5tY6uI"; // 上一步生成的密钥 String encryptedPassword = encrypt(originalPassword, base64AESKey); System.out.println("加密后的密码: " + encryptedPassword); // 示例输出： `5f4dcc3b5aa765d61d8327deb882cf99...` } }

步骤3：安全存储与使用

• 密文：将encryptedPassword写入你的配置文件application.properties。

  # application.properties db.encrypted.password=5f4dcc3b5aa765d61d8327deb882cf99...

• 密钥：绝对不要写在配置文件或代码里。可以通过以下方式传递：
  • 环境变量：在启动应用时设置export DB_AES_KEY=k4P7qN9wV2zXcF1hJmZ3L0oA8bR5tY6uI，然后在代码中通过System.getenv("DB_AES_KEY")获取。
  • 启动参数：java -jar yourapp.jar --db.aes.key=k4P7qN9wV2zXcF1hJmZ3L0oA8bR5tY6uI
  • 密钥管理服务：生产环境推荐使用，如HashiCorp Vault、AWS KMS、阿里云KMS等。

步骤4：应用启动时解密在你的数据源配置类中，读取加密的密码和密钥，然后解密。

import org.springframework.beans.factory.annotation.Value; import javax.annotation.PostConstruct; import javax.sql.DataSource; // ... 省略部分Spring配置代码 @Configuration public class DataSourceConfig { @Value("${db.encrypted.password}") private String encryptedPassword; // 密钥从环境变量获取 private String getAesKeyFromEnv() { return System.getenv("DB_AES_KEY"); } @Bean public DataSource dataSource() throws Exception { String aesKey = getAesKeyFromEnv(); if (aesKey == null || aesKey.isEmpty()) { throw new IllegalStateException("DB_AES_KEY 环境变量未设置！"); } // 这里需要实现一个decrypt方法，与上面的encrypt对应 String realPassword = decrypt(encryptedPassword, aesKey); HikariConfig config = new HikariConfig(); config.setJdbcUrl("jdbc:mysql://localhost:3306/yourdb"); config.setUsername("youruser"); config.setPassword(realPassword); // 使用解密后的真实密码 // ... 其他配置 return new HikariDataSource(config); } private String decrypt(String cipherText, String base64Key) throws Exception { // 解密逻辑，与加密对称 byte[] keyBytes = Base64.getDecoder().decode(base64Key); SecretKeySpec secretKey = new SecretKeySpec(keyBytes, "AES"); Cipher cipher = Cipher.getInstance("AES"); cipher.init(Cipher.DECRYPT_MODE, secretKey); byte[] decryptedBytes = cipher.doFinal(Base64.getDecoder().decode(cipherText)); return new String(decryptedBytes, "UTF-8"); } }

实操心得：AES加密需要选择正确的模式和填充方式（如AES/CBC/PKCS5Padding），上面的示例为了简洁使用了默认模式。在生产中，务必指定完整的算法/模式/填充，并管理好初始化向量（IV）。一个更安全的写法是：Cipher.getInstance("AES/GCM/NoPadding")，GCM模式能同时提供加密和完整性验证。

4.2 方案二：使用RSA非对称加密

这个方案更安全，因为你可以公开加密用的公钥，而把解密的私钥藏好。

步骤1：生成RSA密钥对

import java.security.KeyPair; import java.security.KeyPairGenerator; import java.util.Base64; public class RSAKeyGenUtil { public static void main(String[] args) throws Exception { KeyPairGenerator keyGen = KeyPairGenerator.getInstance("RSA"); keyGen.initialize(2048); // 密钥长度，推荐2048位以上 KeyPair keyPair = keyGen.generateKeyPair(); String publicKey = Base64.getEncoder().encodeToString(keyPair.getPublic().getEncoded()); String privateKey = Base64.getEncoder().encodeToString(keyPair.getPrivate().getEncoded()); System.out.println("公钥 (Base64):\n" + publicKey); System.out.println("\n私钥 (Base64):\n" + privateKey); } }

请务必妥善保存生成的私钥！公钥可以交给任何需要加密密码的人或系统。

步骤2：使用公钥加密密码这个操作可以在部署脚本、CI/CD流水线或者一个独立的安全工具中完成。

import javax.crypto.Cipher; import java.security.KeyFactory; import java.security.PublicKey; import java.security.spec.X509EncodedKeySpec; import java.util.Base64; public class RSAEncryptor { public static String encryptWithPublicKey(String plainText, String base64PublicKey) throws Exception { byte[] keyBytes = Base64.getDecoder().decode(base64PublicKey); X509EncodedKeySpec spec = new X509EncodedKeySpec(keyBytes); KeyFactory keyFactory = KeyFactory.getInstance("RSA"); PublicKey publicKey = keyFactory.generatePublic(spec); Cipher cipher = Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding"); // 使用OAEP填充，更安全 cipher.init(Cipher.ENCRYPT_MODE, publicKey); byte[] encryptedBytes = cipher.doFinal(plainText.getBytes("UTF-8")); return Base64.getEncoder().encodeToString(encryptedBytes); } public static void main(String[] args) throws Exception { String originalPassword = "MySuperSecretDBP@ssw0rd"; String base64PublicKey = "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1Q..."; // 你的公钥 String encryptedPassword = encryptWithPublicKey(originalPassword, base64PublicKey); System.out.println("RSA加密后的密码: " + encryptedPassword); } }

将得到的encryptedPassword存入配置文件。

步骤3：应用中使用私钥解密私钥需要被安全地放置在应用服务器上（如一个权限为400的文件），应用启动时读取并解密。

import javax.crypto.Cipher; import java.nio.file.Files; import java.nio.file.Paths; import java.security.KeyFactory; import java.security.PrivateKey; import java.security.spec.PKCS8EncodedKeySpec; import java.util.Base64; public class RSADecryptor { public static String decryptWithPrivateKey(String cipherText, String base64PrivateKey) throws Exception { byte[] keyBytes = Base64.getDecoder().decode(base64PrivateKey); PKCS8EncodedKeySpec spec = new PKCS8EncodedKeySpec(keyBytes); KeyFactory keyFactory = KeyFactory.getInstance("RSA"); PrivateKey privateKey = keyFactory.generatePrivate(spec); Cipher cipher = Cipher.getInstance("RSA/ECB/OAEPWithSHA-256AndMGF1Padding"); cipher.init(Cipher.DECRYPT_MODE, privateKey); byte[] decryptedBytes = cipher.doFinal(Base64.getDecoder().decode(cipherText)); return new String(decryptedBytes, "UTF-8"); } // 从文件读取私钥 private String loadPrivateKeyFromFile(String filePath) throws Exception { byte[] keyBytes = Files.readAllBytes(Paths.get(filePath)); // 假设文件里存的是Base64编码的私钥 return new String(keyBytes).trim(); } }

在Spring的DataSourceConfig中，调用decryptWithPrivateKey方法，传入配置中的密文和从安全位置读取的私钥，即可得到真实密码。

4.3 方案三：使用Spring Boot配置加密（Jasypt）

对于Spring Boot项目，有一个非常流行的库叫Jasypt，它极大地简化了配置属性的加解密过程，底层通常使用对称加密。

步骤1：添加依赖在pom.xml中添加：

<dependency> <groupId>com.github.ulisesbocchio</groupId> <artifactId>jasypt-spring-boot-starter</artifactId> <version>3.0.5</version> <!-- 使用最新版本 --> </dependency>

步骤2：加密你的密码首先，你需要一个密钥（在Jasypt中叫“密码”）。通过环境变量JASYPT_ENCRYPTOR_PASSWORD设置它。 然后使用Jasypt提供的命令行工具或API加密：

# 假设你通过CLI工具加密 java -cp jasypt-1.9.3.jar org.jasypt.intf.cli.JasyptPBEStringEncryptionCLI input="MySuperSecretDBP@ssw0rd" password=YourSecretJasyptKey algorithm=PBEWithMD5AndDES

输出会包含ENC(加密后的字符串)。

步骤3：修改配置文件将加密后的字符串（带ENC()包裹）放入application.properties：

spring.datasource.password=ENC(加密后的字符串)

步骤4：启动应用时提供密钥在启动应用时，必须让Jasypt知道解密密钥：

java -Djasypt.encryptor.password=YourSecretJasyptKey -jar yourapp.jar

或者通过环境变量：

export JASYPT_ENCRYPTOR_PASSWORD=YourSecretJasyptKey java -jar yourapp.jar

Spring Boot在启动时，Jasypt会自动检测到ENC(...)格式的属性值，并用提供的密钥将其解密，然后注入到数据源中。这种方式对代码是透明的，无需修改任何业务逻辑。

注意事项：Jasypt默认的PBEWithMD5AndDES算法较弱。建议在application.properties中配置更强的算法，如：

jasypt.encryptor.algorithm=PBEWithHMACSHA512AndAES_256 jasypt.encryptor.iv-generator-classname=org.jasypt.iv.RandomIvGenerator

5. 密钥管理：比加密本身更重要的环节

“锁”造得再坚固，“钥匙”没管好也是白搭。密钥管理是加密体系中至关重要的一环。

1. 永远不要将密钥硬编码在代码或配置文件中：这是最低级的错误。一旦代码库泄露，密钥直接暴露。
2. 使用环境变量：对于单机或小型应用，通过操作系统环境变量传递密钥是一个简单有效的方法。确保只有运行应用的用户有权限读取这些环境变量。
3. 使用启动参数：类似环境变量，但要注意命令行历史可能记录密码。
4. 使用密钥管理服务：在生产环境中，这是最佳实践。
   • 云服务商提供：AWS KMS, Azure Key Vault, 阿里云KMS, 腾讯云KMS等。它们提供密钥的创建、轮转、审计和安全的加解密API。
   • 自建/开源方案：HashiCorp Vault, CyberArk 等。这些工具可以集中管理密钥、证书、令牌等所有秘密信息。
5. 密钥轮转：定期更换加密密钥。即使当前密钥泄露，因为密文是用旧密钥加密的，攻击者也无法解密（前提是新数据用新密钥加密）。这需要设计好密钥版本管理机制。
6. 权限最小化：确保只有需要访问密钥的服务或进程才有相应的读取权限。使用操作系统用户、组或容器安全上下文进行严格控制。

6. 常见问题与排查技巧实录

在实际操作中，你肯定会遇到各种“坑”。下面是我总结的一些典型问题及解决方法。

6.1 加密/解密失败：算法/模式/填充不匹配

• 问题描述：在AES加密时，加密端用了AES/CBC/PKCS5Padding，解密端用了AES（默认可能是ECB模式），导致解密失败，报BadPaddingException或其他异常。
• 排查思路：
  1. 确认算法字符串完全一致：加解密双方必须使用完全相同的“算法/模式/填充”字符串。例如，都使用AES/GCM/NoPadding。
  2. 对于CBC等模式，需要管理IV：CBC模式需要初始化向量（IV）。加密时生成的IV，必须提供给解密方。通常将IV和密文一起存储（如IV + 密文）。
  3. 检查密钥长度和编码：确保密钥字节数组的长度符合算法要求（AES-128是16字节，256是32字节）。确保加解密双方对密钥的编码方式一致（如都是Base64或Hex）。
• 解决方案：在代码中显式、完整地指定算法参数，并编写单元测试确保加解密过程可逆。

6.2 环境变量未设置或读取不到

• 问题描述：应用启动失败，报错DB_AES_KEY为空或JASYPT_ENCRYPTOR_PASSWORD未找到。
• 排查思路：
  1. 检查环境变量是否已设置：在启动应用的终端执行echo $DB_AES_KEY或printenv DB_AES_KEY。
  2. 检查作用域：在哪个用户、哪个shell中设置的环境变量？应用进程是否运行在同一个上下文中？例如，在~/.bashrc中设置的环境变量，对systemd服务可能不可见。
  3. 容器化环境：在Docker中，需要通过-e参数或Dockerfile的ENV指令传递环境变量。在Kubernetes中，使用Secret并通过环境变量或Volume挂载。
• 解决方案：
  • 对于系统服务，考虑使用服务管理器（如systemd）的EnvironmentFile指令来加载包含环境变量的文件。
  • 使用.env文件（配合dotenv库）在开发环境管理变量，但切勿将.env文件提交到代码库。
  • 在应用启动脚本中显式设置环境变量。

6.3 性能考量与连接池初始化

• 问题描述：每次建立数据库连接都实时解密密码，可能会对应用启动速度或高频创建连接的操作产生轻微影响。
• 解决方案：
  • 缓存解密结果：在应用启动时，解密一次密码，并将明文密码缓存在内存中的一个安全变量里（注意Java中String是不可变的，但仍有被内存转储的风险，对于极高安全要求，可使用char[]并在使用后清空）。
  • 使用连接池：这是标准做法。连接池（如HikariCP）在初始化时会使用解密后的密码创建一批连接，后续请求直接从池中获取，避免了重复解密。确保连接池的配置（如dataSource.password）在初始化时已经是被解密后的值。

6.4 密文被误识别或截断

• 问题描述：加密后的密文是Base64字符串，可能包含+,/,=等特殊字符。如果直接粘贴到YAML配置文件中，可能会引起YAML解析错误（如:被当作映射符号）。或者在传输过程中被意外截断。
• 解决方案：
  1. YAML中引号包裹：在application.yml中，用单引号或双引号将密文包裹起来。

     db: encrypted-password: 'ENC(你们好+/==)'

  2. 考虑URL安全的Base64编码：使用Base64.getUrlEncoder()进行编码，生成不带+、/的字符串，用-和_替代，并且省略填充符=。解密时使用对应的Base64.getUrlDecoder()。

6.5 密钥泄露后的应急响应

即使做了加密，也要有应急预案。假设你怀疑加密密钥已经泄露：

1. 立即轮转密钥：这是首要任务。生成新的加密密钥。
2. 更新所有密文：使用新密钥，重新加密所有敏感的配置值（数据库密码、API密钥等）。
3. 更新部署：将新的密文和密钥（通过安全渠道）部署到所有环境。
4. 审计与排查：审查日志，排查密钥是如何泄露的（代码泄露、服务器入侵、内部问题？），并封堵漏洞。
5. 考虑凭证失效：如果泄露的是数据库密码，最彻底的方法是直接在数据库层面修改用户密码，然后更新应用配置。这样即使旧密文被解密，得到的也是无效密码。

7. 进阶思考与最佳实践

掌握了基础操作后，我们可以思考如何做得更优雅、更安全。

1. 将加解密过程集成到CI/CD流水线：不要在开发人员的机器上加密生产环境的密码。应该在构建或部署阶段，由流水线工具（如Jenkins, GitLab CI）从安全的存储中获取密钥，对配置进行加密，然后生成最终部署的配置包。这样开发人员接触不到生产密钥和密文。
2. 使用配置中心并开启加密功能：如Spring Cloud Config Server原生支持对称和非对称加密。将加密的配置存放在Git仓库中，Config Server在提供给客户端前会自动解密。这样客户端应用拿到的就是明文，简化了客户端的逻辑。
3. 区分环境：开发、测试、生产环境使用不同的加密密钥。这可以通过环境变量或配置中心的不同profile来实现。
4. 定期审计：定期检查是否有包含敏感信息的配置文件被误提交到了代码仓库。可以使用像git-secrets、truffleHog这样的工具进行自动化扫描。
5. 零信任与临时凭证：在云原生和容器化环境中，更先进的思路是使用“零信任”模型。例如，让应用通过IAM角色（如AWS IAM Role for Service Accounts）动态获取数据库访问凭证，而不是使用静态的、长期有效的密码。这从根本上消除了密码存储和泄露的风险。

数据库密码加密是应用安全的第一道门槛，它体现了一个开发者最基本的安全素养。从今天开始，告别配置文件里的明文密码，为你守护的数据资产加上第一把可靠的锁。记住，安全不是一个功能，而是一个贯穿始终的过程。