到现在为止，你可能已经听说了那个逃脱安全评估并攻击了Hugging Face（一个LLM市场）的AI代理。这个代理认为Hugging Face可能拥有它基准测试的答案，所以它偷走了这些答案以便在考试中作弊。这是一个有趣的动机，但结果却令人感到恐惧。Hugging Face发布了一份详细的入侵重建报告，涵盖了四天半时间内恢复的约17,600个动作，包括沙箱逃逸、代码执行、云凭证、即兴指挥与控制系统，以及最终使用Tailscale在其组织内部传播。但Tailscale是一个零信任网络！零信任的整个目的就是防止攻击者横向移动到你的公司内部。那么问题出在哪里？在Tailscale出现的地方没有发现或利用任何“Tailscale”的“漏洞”，这可能让我们感觉更加不安。Tailscale在AI基础设施中无处不在：几乎每个AI公司都在使用Tailscale。因此，最终我们出现在一份AI事件报告中并不令人惊讶。但是，我们是一个安全工具。他们的入侵就是我们的入侵，而我们有责任认真对待。就像在任何事后分析中，我们需要反思发生了什么以及我们本可以做些什么来防止它。在代理逃脱沙箱并找到Tailscale时，它已经获得了生产工作者内的代码执行权限，达到了Kubernetes节点的根访问权限，并读取了包含136个密钥的生产秘密存储。从某种意义上说，在我们甚至到达现场之前，游戏就已经结束了。但是，这不正是问题所在吗？我们来回退一两级。为什么长期存在的秘密密钥会对任何人可访问？因为长期凭证是标准。虽然它们不应该是，但我们现在已经看到了一个很好的示例说明原因。在大多数入侵由人以人类速度完成的旧世界中，凭证泄露的缓解措施被视为可有可无。在安全团队的低优先级清单中，一个大型凭证库，可以一次读取136个密钥，是一个待做事项。而现在，在一个流氓AI代理的世界中，巨大的凭证金库就是奖品。这已经不再可以接受。我只知道两种主要的解决方案来解决长期凭证的问题。首先，你可以配置一个仅发行基于你一次性插入的长期凭证的短期凭证的库，而这个库永远不会把长期凭证返回。例如，HashiCorp Vault可以做到这一点；他们称之为动态凭证。不幸的是，动态凭证的设置和维护工作量很大。当安全需要工作时，人们往往不会去做。第二个选项是一个凭证注入代理。如果客户端C想访问服务器S，不要给C提供S的凭证；相反，让它通过一个强化的代理P发送请求，P只负责接收请求、插入凭证并将其传递出去。凭证注入正在获得人气，因为现代的基于网状的网络消除了大部分延迟。几个月前，我们收购了Border0（“Tailscale PAM”），这是一款优雅且相当精美的凭证注入代理，与Tailscale紧密集成。全面部署的Border0本应阻止读取这136个密钥，并记录每一个尝试使用密钥的行为（同样的凭证注入能力也存在于Aperture Connectors中）。但是，这些技术太新了。我们大多数客户甚至还没有查看它。一个额外的第三选项：Tailscale本身。在Tailscale中，你的节点密钥可以使用TPM进行机器绑定以防止导出，如果你是企业用户，你绝对应该这样做。不幸的是，由于我们在某些用户硬件上发现的HSM问题，我们不得不在Linux和Windows上默认关闭TPM存储。无论如何，在今天的案例中，攻击是授予对Tailscale访问权的因素，因此我们来得太晚。那个长期存在的身份验证密钥根本不需要存在。由于没有实施动态凭证或凭证注入代理，导致了136个密钥的泄漏。下一道防线是什么？这136个凭证中有一个是可重用的Tailscale认证密钥 ，用于在他们的尾网中创建新的Tailscale CI（持续集成，用于自动化测试）节点。代理将该密钥复制到一系列外部沙箱中，并在几天内使用它，使总共181个节点注册到Hugging Face的尾网中。这些节点每个都获得了一个Tailscale身份标签，赋予了它们作为CI节点所需的所有访问权限。我们无法拯救这136个密钥。但可重用的Tailscale密钥不应该在其中。我们为此类情况建立了工作负载身份联合。它依赖于你的云提供商提供“环境权限”，以短期凭证的形式生成，这些凭证来自正在运行的虚拟机（或容器）的云身份。CI作业可以请求其云平台的签名OIDC令牌。Tailscale验证令牌，然后根据该工作负载分配的标签和范围授予访问权限。值得注意的是，一旦启用，这个过程可以自动进行：启动CI节点，Tailscale获取身份，分配相应标签。没有凭证可以泄漏，当