Railway 数据泄露事件本可避免，安全架构被指存在重大缺失

Railway 11 月 10 日的事件报告描述了一名攻击者窃取客户机密，包括 OpenRouter、Anthropic 和 OpenAI 等 AI 服务的 API 密钥。我们认为，标准的安全控制本应阻止这种访问。本文解释了架构在哪些地方存在不足，以及客户本应得到什么样的保护。

我们认为这是一次严重的、本可避免的架构和领导力失败。托管服务提供商有责任防止一个客户的代码触及另一个客户的机密。其领导层必须将这种保护作为一项要求，而不是将客户数据置于风险之中。

最初的漏洞利用涉及一条由 AI 辅助探测组成的复杂链条，可能具有新颖性。但这并不能为缺失的保护措施开脱——正是这些缺失让攻击者得以进一步深入。隔离客户工作负载并将凭据限制在所需的访问范围内，是众所周知的安全基本原则。Railway 本应更清楚这一点。

当我们的团队在 AWS 构建系统时，通过虚拟机（VM）实现隔离以及严格限制凭据是运行不受信任客户代码的基础要求。我们在 Forte 也遵循这些原则。Railway 所描述的架构未达到这一标准。

租给别人一个保险箱，并不意味着你应该让他们独自待在金库里，而其他所有人的箱子都没上锁。付费访问自己的箱子并不赋予他们打开别人箱子的权利。

安全审查需要从这种可能性出发。假设客户代码会寻找凭据、试图逃逸其容器，并探测它能触及的任何服务。然后问：如果其中一次尝试成功了，是什么阻止它触及另一个客户的数据？

根据 Railway 的攻击时间线，攻击者部分逃逸了围绕共享 VM 中运行的构建的文件系统限制。一个被盗的构建凭据让他们访问了构建历史和内部源代码。构建历史暴露了客户的环境变量。

内部源代码帮助攻击者发现了颁发云凭据规则中的一个独立配置错误。这条路径最终通向一台用于管理工作负载的机器，在那里他们获得了加密客户机密的访问权限以及解密这些机密的权限。

该图总结了通往客户数据的这两条路径。它展示的是报告的攻击序列，而非 Railway 的整个基础设施。

边界 1：隔离 仅有文件系统规则。来自不同客户的构建共享同一个 VM。

边界 2：最小权限 该凭据存在是为了推送镜像。其他系统也接受了它。 一台机器可以读取加密变量并解密其密钥。

有多个机会可以阻止这次攻击。构建需要更强的隔离，而它能触及的系统需要强制执行更严格的权限。

当这些客户可以运行恶意代码时，将每个客户的文件放在单独目录中并不能提供足够的保护。普通 Linux 容器也共享宿主机的内核——操作系统的核心。如果攻击者突破了其容器周围的限制，该宿主机上的其他工作负载就可能面临风险。

这就是为什么我们要求为无法相互信任的客户工作负载使用单独的 VM。每个 VM 有自己的内核，硬件虚拟化增加了攻击者必须跨越的另一道边界。客户仍然可以共享物理硬件，但将他们的容器放在一个 VM 内并不能在他们之间提供 VM 边界。

AWS 在其容器隔离指南中做出了这一区分。Fargate 任务运行在硬件虚拟化环境和 MicroVM 中。对于共享 EC2 宿主机上的容器，AWS 甚至明确警告：凭据和临时文件可能被该宿主机上的其他容器访问。

构建需要这种保护，程度不亚于运行中的应用程序。安装依赖或运行构建脚本会执行客户控制的代码。将构建视为“危险性较低”会在平台首次运行该代码的关键节点留下缺口。

单独的 VM 有助于遏制从构建容器中的逃逸。它无法阻止攻击者利用该 VM 内可用的过于强大的凭据，这就是为什么权限需要单独审查。

最小权限有一个直截了当的含义：只给一项工作完成其工作所需的访问权限。例如，上传容器镜像的构建需要上传该镜像的权限。它不应该能够读取另一个客户的构建历史或平台的内部源代码。

每个接受凭据的服务都必须检查它允许什么。识别有效凭据只是第一步。服务还必须检查该凭据是否允许对该客户的资源执行此操作。来自平台网络内部的请求并不能使这些检查变成可选的。

安全审查应检查客户代码可能触及的每个凭据。如果它被盗了，攻击者能读取或更改什么？这种访问能帮助他们获得更强大的凭据吗？审查需要沿着这些连接追踪，并检查访问实际上会在哪里被拒绝。

快速过期的凭据仍然需要有限的权限。过期减少了攻击者使用被盗凭据的时间；它并不限制他们在这段时间内能做什么。颁发凭据的规则还必须防止攻击者获得新的凭据。AWS 的 IAM 指南建议同时使用临时凭据和最小权限。

在我们看来，允许构建凭据暴露无关客户的数据是不可原谅的。运行不受信任代码的平台必须为凭据盗窃做好准备，并限制其可能造成的损害。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）