3、密码管理基础：为什么需要密码改造？常见密码存储风险

聊到密码改造，很多人第一反应是："密码不是一直在用吗？改什么？" 嗯，我刚开始接触 CI/CD 时也是这个想法。直到有一次，团队里有同事把数据库密码直接写死在代码里，结果代码不小心被推到了 GitHub 公开仓库。那天的紧急会议，我到现在还记得。密码改造，说白了就是用一套机制来避免这类低级错误，让密码在自动化流程中不再裸奔。

CI/CD 流水线天生就是自动化的——代码从提交到部署，中间要经过很多环节。每个环节都可能接触到敏感凭据。你想想看，如果密码是硬编码的，那只要一个环节出问题，所有东西都白费了。所以，密码改造不是"要不要做"的问题，而是"怎么做"的问题。

3.1 密码改造的背景与意义

传统软件部署，密码往往写在配置文件里，或者靠运维人员手动输入。这在单体应用时代勉强能用，但在 CI/CD 场景下，问题就大了。

• 自动化流程需要自动获取凭据——没人站在终端前帮你敲密码。
• 流水线环节多，暴露面大——代码检查、构建、测试、部署，每一环都可能泄露密码。
• 团队协作频繁——多人维护同一个仓库，密码容易扩散。
• 合规要求越来越严——等保、GDPR、SOC2 都在盯着你。

我在项目中见过太多因为密码管理不当而导致的"惨案"。说白了，密码改造就是给 CI/CD 流水线装上一道"自动门"，让密码该出现的时候出现，不该出现的时候藏好。

3.2 常见密码存储风险

下面这几个风险，我几乎在每个项目里都见过。你仔细对照一下，自己踩过几个坑。

3.2.1 硬编码密码

把密码直接写在源代码里——这是最原始也最危险的做法。代码一旦泄露，密码就跟着完蛋。我在项目中遇到过有人把数据库密码写在 Python 脚本里，结果脚本被提交到 Git 仓库，密码就这么躺在那儿好几年。

3.2.2 配置文件泄露

把密码放在 application.yml、.env、config.json 这类文件里，比硬编码好一点，但依然不够。配置文件容易被误传、误分享，或者不小心被打包进制品中。我记得有个项目，测试环境的配置文件直接包含了生产数据库的地址和密码——就因为复制粘贴时忘了改。

3.2.3 环境变量泄露

通过环境变量传递密码是常见做法，但问题在于：子进程会继承父进程的环境变量。如果你在 CI/CD 脚本里设置了密码，那所有子进程都能读到它。调试信息、错误报告、甚至是日志里，都可能把环境变量整个打印出来。

3.2.4 日志泄露

这个坑我踩过。有一次排查线上问题，我在日志里竟然看到了完整的数据库连接串——用户名、密码清清楚楚地列在那里。为什么会这样？因为框架在初始化数据源时把连接串打到了日志里，而没有人想到要过滤它。

3.2.5 版本控制泄露

Git 历史是"永不消逝的电波"。即使你后来删除了密码文件，它依然躺在历史记录里。我曾经接手过一个项目，翻 Git log 时发现半年前有人提交过包含密码的配置文件，而且那个仓库是公开的。嗯，那时候我就知道，清除历史可不是简单的 git rm 能解决的。

风险类型	风险等级	典型案例	改造方向
硬编码密码	严重	代码中写死数据库密码	密钥管理服务
配置文件泄露	高	application.yml 泄露	环境变量 + 密钥中心
环境变量泄露	中	子进程继承环境变量	临时凭据 + 最小权限
日志泄露	高	SQL 连接串打印到日志	日志脱敏 + 过滤
版本控制泄露	严重	Git 历史中的密码	历史清除 + 预提交钩子

3.3 密码改造的核心目标

了解了风险，我们来看看改造要达成什么目标。我个人习惯把目标总结为四个词：消除、动态、最小、审计。

• 消除硬编码——所有敏感凭据不出现在代码、配置、环境变量中。
• 动态获取——运行时从密钥管理服务（如 Vault、AWS Secrets Manager）获取凭据。
• 权限最小化——每个服务只拿它需要的权限，不多给。
• 审计与轮转——记录谁用了哪个密码，定期自动更换。

拿 Python 举个简单例子。改造前，你可能这样写：

# ❌ 改造前：硬编码密码
DB_PASSWORD = "my_secret_password_123"
conn = pymysql.connect(host=..., password=DB_PASSWORD)

改造后，应该是这样：

# ✅ 改造后：从密钥管理服务动态获取
from vault import get_secret
DB_PASSWORD = get_secret("db/prod/password")
conn = pymysql.connect(host=..., password=DB_PASSWORD)

你想想看，只要密钥服务本身是安全的，那密码就永远不会出现在代码、日志或 Git 历史里。这才是密码改造的核心逻辑。

3.4 密码改造的收益

说了这么多风险，改造到底能带来什么好处？我列了一个表，一目了然。

维度	收益	说明
安全	大幅降低泄露风险	密码不在代码、配置、日志中裸奔
运维	自动化轮转，无需人工	定期换密码不再需要停机或手动操作
合规	满足审计与等保要求	所有凭据访问有记录，可追溯
协作	减少团队间的密码传递	不再需要用聊天工具发密码

这张图概括了密码改造的完整逻辑：从识别风险开始，到实施改造，再到持续审计，最终落到安全加固。每一步都离不开团队的执行力，也离不开工具的支撑。

我建议你在开始改造之前，先对照上面的表格，把当前项目中的密码存储方式梳理一遍。哪些是硬编码的？哪些躺在配置文件里？Git 历史里有没有"历史遗留问题"？搞清楚这些，改造才能有的放矢。