项目源码安全审查—密钥硬编码问题

目录

• 危害说明
• 防护的核心
• 如何安全地在配置中心存放密钥？
  • 方案一：使用配置中心自带的加密功能
  • 方案二：与专业的密钥管理系统集成
  • 方案三：在交付流程中动态注入

---

密码硬编码（Hard-Coded Secrets）是指将敏感信息（如数据库密码、API密钥、加密密钥、第三方服务凭证等）以明文形式直接写入应用程序的源代码、配置文件或固件中的行为。

常见的密钥硬编码场景：

• 密钥放在环境变量、配置
  • 在配置文件中：<add key="ConnectionString" value="Server=...;User Id=sa;Password=password;" />
• 密钥加密存储在代码里
  • 在Python代码中：db_password = "MySuperSecretPassword123!"
  • 在Java代码中：String apiKey = "AKIAIOSFODNN7EXAMPLE";

自查方法：

通过关键搜索
String pass="fadfdafad"
# Password key pwd pass jdbc encryption key  Cipher key 等关键字搜索

---

危害说明

硬编码是安全实践中的大忌，主要原因如下：

1. 丧失机密性： 源代码通常会被存储在版本控制系统（如Git）中，可能会被多位开发者访问，也可能意外泄露到公共平台（如GitHub）。一旦泄露，所有硬编码的密码都将暴露。
2. 难以轮换： 如果一个密码被固定在程序内，遇到泄露想要更换时，开发人员必须修改代码、重新测试、重新部署整个应用程序。这个过程非常繁琐、耗时，且容易引发新危机。
3. 权限扩散： 任何有权访问代码的人（包括不应知道生产环境密码的开发者）都获得了敏感信息的访问权限，违反了“最小权限原则”。
4. 缺乏审计： 无法追踪和审计是谁、在什么时候、使用了哪个密钥访问了关键服务。

---

防护的核心

核心点在于密钥、代码、开发人员分离，尽可能少的让密钥被人接触到。（只是减缓因人导致的安全风险，无法杜绝研发人员恶意通过各种手段去获取到真实Key并利用。）

总结：将秘密与代码分离;

1. 分离配置与代码： 敏感信息不属于代码的一部分。代码是逻辑，配置是环境依赖。两者应该完全分开。
2. 使用安全的凭据管理系统： 将秘密集中存储在专门设计的安全系统中，如KMS、HashiCorp Vault、Azure Key Vault等。应用程序在运行时动态地从这些系统获取凭据。
3. 最小权限原则： 应用程序和访问秘密的系统身份（如IAM角色）只应被授予完成其功能所必需的最小权限。
4. 环境隔离： 为开发、测试、生产等不同环境使用不同的凭据。开发环境的数据库密码绝不能和生产环境相同。
5. 加密与审计： 对静态存储（At-Rest）和传输中（In-Transit）的秘密进行加密，并记录所有对敏感凭据的访问和操作日志。

企业应制定安全策略：
密钥的安全策略中，密钥分层、密钥定期更换是重要的防护策略，因为你无法知道在何时何处密钥泄漏过，因此定期更换密钥能降低风险。

---

如何安全地在配置中心存放密钥？

方案一：使用配置中心自带的加密功能

这是最常见的做法。配置中心提供一个加密/解密接口，你存入的是密文，应用获取时再自动解密或在客户端解密。

工作流程：

1. 加密：运维或安全人员通过配置中心提供的工具或界面，用指定的密钥（KMS）将原始密钥加密成一段密文。
2. 存储：将这段密文作为配置值存入配置中心。
3. 读取与解密：
   • 应用程序从配置中心拉取到的是密文。
   • 应用程序通过配置中心的客户端或API，附带必要的权限认证，请求解密服务。
   • 配置中心（或集成的KMS）验证应用身份后，将密文解密为明文，返回给应用。

举例：

• Spring Cloud Config：支持使用对称或非对称加密对配置文件中的{cipher}...密文进行解密。
• Nacos：可以集成阿里云的KMS进行配置加密。
• Apollo：提供了可扩展的加密接口，可以方便地对接公司内部的KMS。

---

方案二：与专业的密钥管理系统集成

这是更安全、更专业的做法。配置中心本身不负责加解密，而是去调用一个专门的密钥管理服务。

工作流程：

1. 配置中心里不直接存储密钥，而是存储一个指向KMS中某个密钥的“引用”或“路径”。
2. 应用程序从配置中心获取到这个“路径”。
3. 应用程序凭借自身的身份（如云上的IAM角色、服务账号等）向KMS发起请求，认证通过后，从该“路径”下获取到真实的密钥。

举例：

• AWS：将数据库连接字符串存放在 AWS Systems Manager Parameter Store 中，并使用 AWS KMS 进行加密。应用通过IAM角色授权来访问和解密。
• Azure：应用配置可以方便地集成 Azure Key Vault。
• Google Cloud：使用 Secret Manager 来存储密钥，然后在配置中引用。

这种方式实现了 “权责分离” ：配置中心管配置，密钥库管密钥，安全性更高。

---

方案三：在交付流程中动态注入

相对来说，这个方案不是那么安全，建议在“简陋”环境中使用。

在CI/CD流水线中，在部署应用之前，由流水线工具从安全的密钥库中取出密钥，并动态地注入到应用的环境变量或配置文件中。配置中心可能只存放非敏感的配置。这种方式将密钥完全排除在配置中心的存储之外。