诺和诺德（Novo Nordisk）维持着一套多层安全基础设施。该公司采用了先进的终端检测、网络分段以及专门的安全运营中心。这些防御措施每年耗资数百万美元。然而，仅仅因为一个面向公众的网站上的一串文本字符串，整个架构就崩溃了。这家丹麦制药巨头的遭到的入侵是现代软件开发架构悖论的一个案例研究。由于一个身份验证令牌出现在了错误的地方，导致在周界防御上的巨额投资宣告失败。
我多年来一直通过 Signal 和 PGP 加密频道与安全研究人员交流。他们中的大多数人并不会在加固的防火墙中寻找复杂的零日漏洞。他们寻找的是阻力最小的路径。在诺和诺德事件中，这条路径就是一个被留在某个不起眼的子域名客户端 JavaScript 中的高权限 GitHub 个人访问令牌（PAT）。这并不是一次复杂的黑客攻击，而是一次发现过程。一旦名为 FulcrumSec 的威胁组织在 3 月份发现了这个令牌，正式的安全周界就变得无关紧要了。该令牌提供了经过身份验证的访问权限。对于内部系统而言，攻击者就是合法的开发人员。
无声入侵的剖析
FulcrumSec 在被发现之前，已在诺和诺德网络内部运行了两个多月。在此期间，该组织利用初始的 GitHub 令牌克隆了私有仓库。这些仓库中包含的不不仅仅是代码，还包含二级凭据、基础设施定义和内部文档。这是现代入侵中的常见模式。攻击者利用一个微小的立足点来获取更强大的秘密。当他们拥有大门的钥匙时，就不需要利用软件漏洞。
到诺和诺德在 6 月 11 日披露该事件时，攻击者已经窃取了 1.3TB 的数据。这批缓存包含 700,000 个文件。虽然该公司最初将影响描述为仅限于伪匿名的患者数据和医疗保健专业人员记录，但现实情况似乎更为严重。被盗数据包括已上市和未发布药物的专利信息、临床试验研究以及内部 AI 模型。FulcrumSec 声称，这些信息可以为竞争对手节省三到五年的开发时间。这就是系统性失败的定义。违规行为从一个简单的令牌泄露演变为核心知识产权的流失。
为什么开发流水线就是生产系统
开发平台是现代企业中价值最高的系统。大多数安全计划未能认识到这一现实。代码仓库不再仅仅是文本文件的简单存储箱。它是整个数字环境的蓝图。它保存着云环境的配置和将代码推送到客户手中的部署流水线。当攻击者获得仓库的访问权限时，他们就看到了组织的“布线图”。
Magna5 的首席信息安全官 Matt Kimpel 指出，开发人员拥有对最重要系统的常驻访问权限。他们持有构建流水线和云环境的凭据。这些系统位于生产环境的上游。如果攻击者在代码编译之前就将其破坏，他们就控制了最终产品。这使得开发人员的工作站和仓库比生产服务器本身更为关键。传统的保护措施（如分支审批和代码审查）假设执行操作的人是受信任的员工。如果身份被冒用，这些相同的控制措施反而会为攻击提供便利。
机器身份的隐形风险
组织通常将机密管理视为一个工具问题。他们购买一个保险库（Vault）并认为问题已解决。诺和诺德事件证明，机密管理是一个身份问题。泄露的 GitHub 令牌是一个机器身份。与人类账户不同，机器凭据通常缺乏明确的所有者。它们没有一致的轮换计划。它们经常缺乏有效的监控。这些令牌在不更改的情况下可以持续存在数月或数年。
Keeper Security 的 CISO Shane Barney 指出，这种隐形性使单个令牌变成了长期入侵的工具。当机器凭据带有广泛的权限且无人监控其使用情况时，攻击者不需要提权。访问权限已经存在。爆炸半径覆盖整个环境。这就是攻击者在 60 天内未被发现的原因。他们并不是在强行闯入系统，而是在按照系统的设计方式使用系统。
二级威胁者的出现
另一个自称 TheUSERS007 的威胁组织也声称在 6 月 5 日至 6 月 7 日期间访问了诺和诺德的系统。该组织的目标是与 AI 研究相关的数据。这表明一旦发生重大泄露，其他参与者就会开始探测相同的基础设施。开发流水线中的单个漏洞通常预示着更广泛的系统性弱点。如果一个开发人员在公共脚本中留下了令牌，其他开发人员很可能也遵循类似的安全性差的模式。攻击面不是一张静态的地图。它是一个动态的环境，一个错误就会招致多个对手的进一步审查。
这种二次入侵突显了内部 AI 模型面临的风险。这些模型代表了制药研究的未来。它们建立在多年的专利数据和巨大的计算投资之上。这些模型的丢失不仅仅是数据泄露，更是竞争优势的丧失。数字环境没有物理围墙。一旦系统的逻辑通过源代码和模型权重暴露出来，损害就是永久性的。
从响应式工具转向主动身份控制
为了减轻这些风险，组织必须改变看待开发人员访问权限的方式。保险库是存放机密的盒子。身份管理则是控制谁可以打开盒子以及打开多久。目标是缩短每个机密的有效期。如果一个令牌在四小时后过期，JavaScript 文件中的泄露只是暂时的麻烦。如果一个令牌有效期为一年，泄露就是一场灾难。
集中化机密管理是必要的一步。环境中的每个身份都应遵循最小权限原则。这意味着 GitHub 令牌应仅具有访问任务所需特定仓库的权限。它不应拥有对整个组织的广泛管理权限。自动化轮换可确保凭据的寿命不会超过其用途。这种纪律并不能阻止攻击者找到令牌，但它限制了他们能做的事情。
流水线安全的实际步骤
组织应首先盘点非人类身份。大多数公司不知道其环境中存在多少 API 密钥或服务账户。你无法保护你看不到的东西。此盘点应包括每个密钥的范围及其最后使用日期。许多组织发现，很大一部分活动令牌已不再必要。这些孤立的机密是攻击者的高价值目标。
监控机器身份与监控人类登录同样重要。安全团队必须为服务账户建立正常行为基准。如果一个 GitHub 令牌通常从已知的 IP 地址访问三个仓库，突然开始从不同地区克隆 500 个仓库，系统应触发警报。检测必须发生在身份层。修补软件很重要，但在身份成为主要目标的时代，对凭据使用情况的可视化是抓住无声入侵者的唯一方法。
立即降低风险的步骤
- 扫描所有面向公众的资产以查找暴露的机密。使用自动化工具在客户端代码中查找令牌、API 密钥和数据库凭据。
- 实施短期令牌。只要平台支持，就用细粒度、有时限的凭据替换长效的个人访问令牌。
- 审计仓库权限。移除开发人员令牌的管理权限。确保没有任何单个令牌有权克隆整个代码库。
- 在 CI/CD 流水线中启用机密扫描。在包含明文机密的提交到达仓库之前将其拦截。
- 监控异常仓库活动。针对批量克隆或来自异常位置的访问设置警报。
这一事件提醒我们，周界已经转移。它不再位于网络的边缘，而是存在于单个令牌和特定身份的层面上。如果你不像管理生产服务器那样严格管理这些身份，你的防御就是一种幻觉。
来源：NIST Cybersecurity Framework, MITRE ATT&CK Framework (Technique T1528: Steal Application Access Token), DataBreaches.net reporting.
免责声明：本文仅供参考和教育目的。它不能替代专业的网络安全审计或事件响应服务。
