有一家面向企业的软件即服务（SaaS）产品，由一位非工程师出身的高管构建，在两天内就直接上线生产环境，方法是将所有工作都交给人工智能处理。
真实客户正在使用它。它能正常运行。功能发布迅速。这确实令人印象深刻。
随后，我接手了该产品的基础设施和运维工作。我是那个一步步检查“已在生产环境中运行”的代码路径的人。这就像是一场寻宝游戏，又像是一次扫雷行动——介于两者之间。
今天的故事关乎其中的一个步骤：密钥（应用程序接口密钥等）的存放位置，以及在那里上演的捉迷藏游戏。
先说结论：每次我说“呃，这很危险”时，密钥的藏身之处就会搬家。而每次它搬家后，我都会得到一种眼神，仿佛在说“这下安全了吧，对吧？”
隐藏某物与保护某物是两回事。这就是整篇文章的核心观点。
第一阶段：硬编码在源代码中
我发现的第一个问题简直是不加掩饰的错误。
应用程序接口密钥被直接写入了源代码。
API_KEY = "(真实的密钥字符串)" # ...就这样公开暴露着
这是典型的氛围编程（即你给人工智能一个模糊的指令，它就构建出东西）。让代码跑起来是唯一的优先事项，因此它选择了最短的有效路径——原样嵌入值。人工智能乐意生成“能运行的代码”；除非你明确要求，否则它不会生成“将密钥当作机密对待的代码”。
于是我表达了观点：“在源代码中硬编码密钥是不好的。只要有人查看代码仓库，密钥就会泄露。”
这位高管态度很好，立即进行了修复。确实修复了，但是——
第二阶段：迁移到自述文件
他们说已经修复了，所以我检查了一下。源代码中的密钥不见了。哦，不错。
除了——它现在出现在自述文件（README）中。
作为“设置步骤”的一部分。非常“贴心”。
## 设置
1. 克隆代码仓库
2. 设置以下密钥：(真实的密钥字符串)
……你看到了吗？密钥只是从源代码移到了说明文档中——它仍然位于代码仓库内，暴露程度丝毫未减。事实上，原本深埋在代码中的内容被提升到了文档中最显眼、最核心的位置，而这是每个人首先阅读的地方。
用捉迷藏来比喻：它从衣柜里出来，现在正站在玄关处。更容易找到了。干得漂亮。
我理解那种成就感——“我从代码中移除了它。”我懂。但在密钥管理领域，一旦它进入代码仓库，游戏就已经结束了。你已将其交给了每一个克隆仓库的人。
第三阶段：存储在数据库中（进步！），但是……
“自述文件也不行。重点在于：根本不要把它放在代码仓库里。”我再次解释了一遍。
这次他们认真思考了，下次我查看时，密钥被存储在了数据库中。
从方向上来说，这是正确的。它离开了代码仓库。代码中没有密钥，自述文件中也没有。这是进步。我鼓了掌。真心实意地。
我确实鼓掌了。但是。
当我实际查看内部情况时，该值以明文形式坐落在那里。
没有加密，没有掩码，什么都没有。打开数据表，任何人都可以读取它——密钥字符串就那样安然无恙地待在那里。
把它放入数据库并不等于安全。 免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
