代码里写死数据库密码有多危险？用 SMS 动态取密，Spring Boot 5 行接入消除硬编码

“数据库密码是 admin123，配置在 config.properties 里”——这种做法在研发团队里极为常见，也是企业数据安全最大的"内鬼"。

硬编码的三重代价

第一，仓库即钥匙。 代码一旦提交到 Git，明文密码就跟着扩散到每一个 fork、每一次 CI 缓存、每一个离职员工的本地副本。攻击者拿到 shell 或拉到源码，直接获得最高权限，整个系统门户洞开。

第二，泄露无感、回收无门。 硬编码的密码长期固定，人员变动后旧密码依旧有效，无法即时回收；即便发现泄露，也要改代码、重新打包、重新部署，响应周期以天计。

第三，合规一票否决。 等保 2.0 明确要求"敏感凭据访问记录可审计"，而硬编码让凭据的使用完全不可见、不可追溯，审计直接不通过。

正确做法：凭据"不落地"

SMS 的核心思路是——应用通过 API 动态请求所需凭据，凭据绝不写入磁盘，始终保留在内存中，用完即释放。攻击者即使拿到服务器 shell，也找不到明文密码。具体遵循三条设计基线：

1. 职责分离：业务侧只保存"定位信息+接入配置"，不保存长期明文密码；
2. 运行时动态获取：凭据在运行时拉取，而非提前同步到本地或镜像层；
3. 绝不落盘、绝不打印：禁止写入 git/制品/配置文件/日志，排障日志只允许打印"是否命中、命中的 key（不含值）、错误码"。

Spring Boot 5 行接入实战

安当 SMS 提供 Java Spring Boot Starter 组件，核心代码改动不超过 5 行：

<!-- 1. pom.xml 添加依赖 -->
<dependency>
  <groupId>com.andang</groupId>
  <artifactId>sms-spring-boot-starter</artifactId>
  <version>1.x</version>
</dependency>

# 2. 配置文件指定 SMS 地址与 secret_name
sms:
  endpoint: https://sms.internal:8234
  secret-name: prod/mysql/order-service

// 3. 注入后直接取用，凭据在内存中、不落盘
@Autowired
private SecretTemplate secretTemplate;

public void query() {
    String pwd = secretTemplate.getSecret("prod/mysql/order-service");
    // 使用 pwd 建立连接，用完即释放，不写入任何文件
}

三步即可消除硬编码：加依赖 → 配 secret_name → 用 SecretTemplate 动态取密。其他语言通过 REST API 调用同样简单（POST /v1/secret/read 带鉴权头返回密文，本地用 SM4 解密到内存）。

从"托管"升级为"动态访问控制"

消除硬编码不是终点。当业务系统统一通过 SMS 动态取密，凭据就从"写死的常量"变成了"受控的资源"：谁能取、取哪个 label/version、取了之后做了什么，全部可审计。这一步，正是把"密码托管"真正升级为"最小权限的动态访问控制与统一机密治理"的关键。

转载自 CSDN-专业IT技术社区

原文链接：https://blog.csdn.net/m0_75002133/article/details/163583801