AK/SK 别再写进代码里：一次密钥误提交后的清理与三层防护

一次本地调试，我为了图省事，把一对用于调用对象存储接口的 AK/SK 直接写进了配置文件，提交代码时也没多想。直到同事在代码评审里问了一句“这个密钥是谁的”，我才意识到它已经跟着提交进了仓库历史。那一刻我才明白，密钥泄露最危险的不是写错了一行配置，而是很多人第一反应是“删掉那行代码再提交一次”，以为这样就解决了。实际上只要提交进过仓库，密钥就已经在历史记录里留了底，删文件、改提交、甚至删分支都清不掉它。

第一步：先作废，再谈清理

发现泄露后我做的第一件事不是改代码，而是登录 IAM 控制台，在“我的凭证”里把那对 AK 先停用，随后直接删除。AK 一旦泄露就默认它已经被别人看到过，抱着“应该没人注意到”的侥幸心理是最贵的。停用之后，我又重新创建了一对只用于当前项目的 AK，并把它的权限收紧到只读对象存储里某一个桶，而不是沿用原来那把什么都能做的密钥。接着，我去翻了云上操作记录，确认在泄露到作废这段时间内没有出现异常的调用和陌生的登录来源。清理代码可以慢慢做，作废密钥一分钟都不能等。

第二步：代码里不再出现明文密钥

新的密钥我再也没有写进代码和配置文件。本地开发时，我把它放进不会提交的 .env 文件，并在 .gitignore 里把 .env 和 config.local.yaml 这类本地配置明确排除。程序启动时只从环境变量读取：

import os

ak = os.environ.get("HUAWEICLOUD_SDK_AK")
sk = os.environ.get("HUAWEICLOUD_SDK_SK")
if not ak or not sk:
    raise RuntimeError("缺少必要的环境变量，请先配置 AK/SK")

这样做的好处很直接：代码仓库里永远找不到密钥，换一台机器、换一个环境，只需要改环境变量，不用改代码。部署到云服务器上时，同样用环境变量或实例的凭证注入方式传密钥，不要把密钥写进启动脚本，也不要写进镜像里。镜像一旦被别人拿到，里面的密钥就等于公开了。

第三步：防再犯的三道关

只靠“下次注意”是靠不住的，我给自己加了三道关。第一道在提交之前：本地装一个密钥扫描工具，提交前扫一遍仓库，扫出疑似密钥就直接拦截。第二道在代码评审时：把“是否出现明文密钥、账号密码、Token”列进评审清单，评审人看到配置文件改动要多看一眼。第三道在权限上：开发、测试、生产用不同的密钥，每个密钥只给完成当前任务刚好够用的权限，并且定期轮换；主账号的 AK 平时根本不创建，需要时才临时创建、用完就删。

这次教训的成本其实不算高，因为发现得早、作废得快。但它让我彻底改了一个习惯：密钥不是配置，是凭证。配置可以写进代码，凭证只能交给环境和权限系统去管。