硬编码密钥

硬编码密钥存在什么风险？

密钥暴露面越多，风险就越大

密钥硬编码在代码中导致的直接结果就是代码在哪里，密钥就在哪里。研发人员电脑上存在密钥，如果电脑被攻击则密钥也会被泄漏。其次，研发人员可能因为安全意识不足，将代码上传至各类私有云盘、家里电脑或 U 盘中，导致风险面增大。更有甚者，会将代码上传至 GitHub，而忽略其中的硬编码密钥，从而被恶意利用，比如我曾经发现的控制某云厂商全部管理权限。

攻击者拿到硬编码密钥后攻击成本较低

攻击者无论通过什么方式拿到你代码，首先就会去看硬编码密钥部分，尝试利用这些代码中的明文密钥。比如存在邮箱密码，则会尝试登录你的邮箱，进一步渗透并挖掘邮件中有价值的内容；有 FTP 账号密码，则会尝试连接 FTP，挖掘其中有价值的文件。

硬编码意味着你不会去变更它

当密钥硬编码在代码中时，改动密钥的成本就会增大，每次改动密钥时你需要额外进行应用发布和测试。而密钥的安全策略中，定期更换是最重要的因素，因为你无法知道在何时何处密钥泄漏过，因此定期更换密钥能降低风险。

硬编码密钥解决方案

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

业内一般做法是通过配置管理中心来管理配置，密钥不适合明文存储因此配置管理中心需要对密钥进行加密，而配置管理中心也有多种实现方案。

标记位替换方案将密钥与代码在物理上隔离，只在发布阶段由集成系统完成注入。 代码中是一个标记 <access_key_id>，当代码进行发布时，由集成系统调用配置管理中心，将代码中的密钥标记替换为真实密钥后再发布到服务器中。此时要确保服务器的权限管控是最小化的。

环境变量和配置文件方案通过加密推送将密钥与代码仓库彻底解耦。 配置管理中心将应用所需的密钥信息加密推送到对应服务器的环境变量（ENV）或专门配置文件中，配置中心提供统一的 SDK 来读取并解密。

动态配置下发方案在运行时按需获取密钥，进一步缩短了密钥的暴露窗口。 配置中心在每台服务器上有一个 Agent，由 Agent 定期拉取最新配置并加密保存在对应服务器中，应用通过配置中心提供的 SDK 读取解密后的密钥。

除了代码中硬编码密钥外，也需要格外关心应用中的日志打印和请求包中传输明文密钥。