密钥

5分钟。就这么长时间。 一个安全研究员故意在GitHub的公开仓库中发布了一个AWS访问密钥，作为实验。 5分钟后，就有人在用它挖加密货币了。 5分钟。 有机器人24/7扫描GitHub，专门寻找这种东西：暴露的凭证。而且它们很快。比你意识到自己搞砸了要快得多。 数字很可怕 据GitHub统计，2024年有3900万个密钥在公开仓库中泄露。比前一年增加了67%。 专门扫描这类问题的GitGuardian仅在公开仓库中就发现了2370万个新密钥。最糟糕的是：2022年检测到的70%密钥在2024年仍然有效。 两年后。仍然能用。等着有人使用它们。 不只是无名小卒 丰田在GitHub上暴露了AWS凭证，这些凭证可以访问他们的车辆远程信息处理系统。培生集团因为有人在配置文件中留下GitLab令牌而丢失数据。酒店管理公司Otelier因为Bitbucket上暴露的凭证，看着8TB的S3数据被盗。 这不只发生在实习生身上。财富500强企业也会中招。 经典借口：“这只是我的个人项目” 是啊，当然。 问题是那个个人项目使用了和生产环境相同的OpenAI API密钥。或者你的Telegram机器人令牌。或者你的测试数据库凭证，哦惊喜，里面有真实数据因为"这样测试更容易"。 然后有一天你不假思索地执行git push。或者因为想展示给某人看而把仓库从私有改为公开。或者GitHub出现bug临时暴露了私有仓库（这种事发生过）。 然后你发现AWS账单从20欧元变成了2000欧元。一夜之间。 “但我立刻删除了” 又一个经典。 Git是版本控制系统。它的工作就是记住发生的所有事情。删除提交不会从历史记录中删除密钥。强制推送不会从分支中删除它。绝对不会从已经复制它的机器人那里删除。 一旦密钥接触到公开仓库，就算是被泄露了。句号。必须轮换。 灾难金字塔 这是典型项目中密钥管理的演进过程： 级别1：地狱 1 2 3 # config.py AWS_KEY = "AKIAIOSFODNN7EXAMPLE" AWS_SECRET = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" 直接写在代码里。已提交。在生产环境中。别笑，这真的存在。 级别2：炼狱 1 2 3 # .env (据说在.gitignore中) AWS_KEY=AKIAIOSFODNN7EXAMPLE AWS_SECRET=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY 好一些，但那个.env最终会出现在备份中，在你通过Slack发送的压缩包中，在你卖掉的硬盘中… 级别3：边缘地带 1 2 # 系统环境变量中的密钥 export AWS_KEY=... 可以，但你把它们存在哪里？便利贴？桌面上的secrets.txt文件？给自己发的Slack消息？ ...