数据库密码还在 Git 里？用 SMS凭据管理系统实现生产/开发环境隔离

标签：#数据库安全 #Secrets管理 #安当SMS #环境隔离 #等保三级 #SpringBoot

一、一个血泪教训：开发误连生产库，删了测试数据？

去年，我们团队发生了一起"低级但致命"的事故：

一位新来的开发同事，在本地调试时，不小心把 application-dev.yml 中的数据库地址写成了生产库 IP。

更糟的是，他用的还是生产库的 root 账号密码------因为公司所有环境共用一套凭据。

虽然只执行了 DELETE FROM test_table，但客户要求我们解释："为什么开发能直接访问生产数据库？"

复盘发现，根源在于：

所有环境的数据库密码都写在配置文件里；
生产和开发使用相同的高权限账号；
凭据无生命周期管理，离职员工仍可连接。

🚨 这不仅违反最小权限原则，也直接触碰等保三级红线。

二、理想状态：凭据应具备哪些能力？

经过多次项目踩坑，我们认为一个合格的数据库凭据管理方案必须满足：

能力	说明
✅ 动态生成	每次应用启动获得临时账号，用完即废
✅ 环境隔离	开发只能访问 dev 库，生产只能访问 prod 库
✅ 权限最小化	开发账号只有 SELECT，生产账号按需授权
✅ 审计可追溯	谁在何时申请了哪个库的凭证
✅ 无静态密码	开发、运维、CI/CD 均不接触明文

好消息是，这类能力可通过 Secrets 管理系统实现 。

我们最终采用 ** SMS（Secure Management System）**，并在多个金融客户项目中落地。

三、架构设计：用命名空间隔离生产与开发

SMS 支持 路径级（Path-based）策略控制，我们这样规划：

复制代码

secret/
├── db/
│   ├── prod/                 ← 生产环境
│   │   ├── mysql-his/creds/app-role
│   │   └── pg-report/creds/reader-role
│   └── dev/                  ← 开发/测试环境
│       ├── mysql-his/creds/dev-role
│       └── pg-report/creds/test-role

关键策略配置：

1. 生产环境策略

hcl 复制代码

# policy-prod.hcl
path "db/prod/*" {
  capabilities = ["read"]
}
# 仅允许生产服务器 Pod 或特定服务账号访问

2. 开发环境策略

hcl 复制代码

# policy-dev.hcl
path "db/dev/*" {
  capabilities = ["read"]
}
# 允许开发人员本地工具或 CI/CD 流水线访问

🔒 核心原则 ：
生产凭据路径对开发人员完全不可见，从根上杜绝误连。

四、实战：Spring Boot 多环境动态凭据集成

步骤1：添加依赖

xml 复制代码

<dependency>
  <groupId>cn.andang</groupId>
  <artifactId>sms-spring-boot-starter</artifactId>
  <version>2.3.0</version>
</dependency>

步骤2：配置不同环境的凭据路径

application-prod.yml（部署在生产 K8s）

yaml 复制代码

andang:
  sms:
    endpoint: https://sms.internal:8200
    role-id: app-prod-role
    secret-id: ${SMS_SECRET_ID}  # 通过 K8s Secret 注入
    database-path: db/prod/mysql-his/creds/app-role

application-dev.yml（本地或测试环境）

yaml 复制代码

andang:
  sms:
    endpoint: https://sms.internal:8200
    role-id: dev-team-role
    secret-id: ${DEV_SMS_SECRET_ID}
    database-path: db/dev/mysql-his/creds/dev-role

步骤3：动态构建数据源

java 复制代码

@Bean
@Primary
public DataSource dataSource(SmsTemplate sms, @Value("${andang.sms.database-path}") String path) {
    Map<String, String> creds = sms.read(path); // 自动获取对应环境的临时账号
    
    HikariConfig config = new HikariConfig();
    config.setJdbcUrl("jdbc:mysql://db:3306/his");
    config.setUsername(creds.get("username"));   // 如 v-prod-app-a1b2c3
    config.setPassword(creds.get("password"));   // 有效期 1 小时
    return new HikariDataSource(config);
}

五、效果验证：权限与隔离双重保障

场景	结果
开发本地启动	获取 `v-dev-his-xxxx` 账号，仅能查 dev 库，且无 DELETE 权限
生产 Pod 启动	获取 `v-prod-his-yyyy` 账号，可读写 prod 库，1 小时后自动删除
开发尝试访问 prod 路径	SMS 返回 403 Forbidden，日志告警
离职员工 Token 泄露	凭证已过期，无法连接任何数据库

✅ 全程无静态密码，无跨环境访问可能。

六、合规价值：直通等保三级与密评

要求	SMS 实现方式
等保2.0 8.1.5.2	动态凭证实现"权限最小化"，生产/开发账号严格分离
等保2.0 8.1.4.3	Secrets 使用 SM4 加密存储（信创版）
《个保法》第51条	凭据生命周期可控，降低个人信息泄露风险
审计要求	所有凭据申请记录包含：用户、IP、时间、环境标识

七、给 DevOps 的建议

不要用同一套凭据跑所有环境------这是安全大忌；
将 Secrets 路径纳入 CI/CD 流水线变量，避免硬编码；
定期轮换主账号密码------ SMS凭据管理系统支持自动更新数据库 root 凭据；
开启审计告警：对异常路径访问（如 dev 访问 prod）实时通知。

安全不是阻碍效率，而是让效率建立在可信基础上。