密钥/凭证的安全存储：别再写死在代码里

"先把密码写代码里，回头再改"

这句话，你说过吗？

"回头再改"的密码，90% 都不会改。

写死在代码里的密码，是最常见、最危险的安全问题之一。

凭证硬编码的 4 个风险

风险一：代码泄露 = 凭证泄露

场景： 代码推送到 GitHub，或被其他方式泄露。

风险：

• 攻击者获取代码，直接找到凭证
• 凭证可能被用于攻击你的系统
• 影响范围不可控

风险二：代码审查时被看到

场景： 代码在团队内审查，凭证被多人看到。

风险：

• 凭证被不必要的人员看到
• 增加泄露风险

风险三：代码复用时泄露

场景： 代码被复制到其他项目、开源项目。

风险：

• 凭证随代码被带到其他地方
• 凭证暴露范围扩大

风险四：无法单独轮换

场景： 凭证硬编码在代码中。

风险：

• 轮换凭证需要修改代码
• 修改代码需要重新部署
• 无法快速响应泄露事件

凭证存储的正确方式

方式一：环境变量

最简单、最通用的方法。

import os
db_password = os.environ.get("DB_PASSWORD")

优点：

• 简单易用
• 不需要额外工具
• 代码与凭证分离

缺点：

• 环境变量可能被其他进程读取
• 需要管理环境变量的设置

方式二：配置文件

将凭证放在配置文件中，配置文件不纳入版本控制。

# config/secrets.yml (加入 .gitignore)
database:
  password: "your_password_here"

优点：

• 集中管理
• 不同环境使用不同配置文件

缺点：

• 配置文件权限需要控制
• 需要管理 .gitignore

方式三：密钥管理服务

企业级解决方案。

优点：

• 专业安全
• 支持自动轮换
• 访问审计

缺点：

• 需要额外部署和维护
• 学习成本

不同场景的推荐方案

一句话总结

凭证别写死在代码里，用环境变量、配置文件或密钥管理服务。代码与凭证分离，才能安全。

标签： 开发安全、密钥管理、凭证安全、信息安全意识