Benchling 用 Bedrock AgentCore 为多租户 AI Agent 构建深度防御安全架构

当 Benchling 需要在数千个生命科学租户间运行 AI 智能体生成的科学代码时，其安全团队发现传统的沙箱隔离已不足以应对需求。如今，这套架构每周处理超过 250 个租户的 600 多次代码执行会话，且从未发生安全事件。标准网络控制可以阻止 HTTP、限制出口端口并限制出站连接，但 DNS 解析通常仍然是被允许的——即使系统默认配置对其进行了限制，你也可能无法了解或控制这些限制的具体情况。这正是 Benchling 在数千个生命科学租户间部署 AI 智能体时面临的挑战。他们的安全团队需要对网络隔离拥有完全的控制权，而不仅仅是依赖系统默认配置，以满足其对大规模执行不受信任代码的威胁模型。

在本文中，我们展示 Benchling 如何构建纵深防御安全架构，在数千个生命科学租户间运行 AI 智能体生成的科学代码。Amazon Bedrock AgentCore 是一个可在任意框架或模型下大规模构建、连接和优化智能体的平台。Benchling 在 Amazon Virtual Private Cloud（VPC）模式下使用 AgentCore Code Interpreter。该方案结合了账户级隔离、Amazon Route 53 Resolver DNS Firewall 和 VPC 端点策略，在执行每个作业的数据访问控制的同时帮助防止数据泄露。

多租户代码执行安全

Benchling 的 AI 应用生成的科学代码代表数千个租户中的研究人员运行。主要用例是 AI 智能体生成的科学代码，不过 Code Interpreter 也用于更简单的计算以及作为代码生成沙箱。安全要求非常严格——每个会话只能访问该租户的数据，不能有跨租户的可见性；代码不能建立未授权的网络连接或通过任何途径泄露数据；每个执行会话必须完全隔离，且解决方案不能要求每个租户配置一个 AWS Identity and Access Management（IAM）角色，因为在这样的规模下这会造成无法承受的角色蔓延。

在安全评审期间，Benchling 团队评估了每种 Code Interpreter 网络模式的网络隔离特性，并将其与威胁模型进行对照。虽然沙箱模式限制了到 Amazon Simple Storage Service（Amazon S3）操作的出站访问，但 Benchling 的安全态势要求客户可控的网络隔离。他们需要精确定义哪些域名可以解析、哪些端点可以访问，还需要通过自己的集成测试套件持续验证这些控制措施。对于在数千个受监管生命科学租户间处理敏感科学数据的应用而言，仅依赖应用管理的网络限制是不够的。他们需要的解决方案是让 Benchling 端到端地拥有安全控制权——必须阻止未授权的网络向量（包括 DNS），同时不产生每个租户一个 IAM 角色的角色蔓延问题，也不会将主生产账户暴露在不受信任的执行环境中。

解决方案架构概述

图 1：Benchling 的多租户代码执行纵深防御架构

图 1 展示了完整的解决方案架构。左侧的生产账户包含 Benchling 堆栈、IAM 角色、AWS STS 和 Amazon S3 中的客户数据。任务被分派到右侧的"不受信任代码账户"，这是一个独立的 AWS 账户，包含 ACCI VPC。该 VPC 没有互联网网关，也没有 NAT 网关。Code Interpreter 运行在一个专用安全组内，仅限 443 端口，无法通向公共互联网。

Code Interpreter 的 DNS 查询由 Route 53 Resolver DNS Firewall 进行评估，它采用三级优先级的解析器策略。优先级 10 阻止已知恶意域名，优先级 100 仅允许明确列出的端点，优先级 200 阻止其余查询。在安全组下方，VPC 端点提供了唯一允许的网络路径。S3 网关端点和接口端点处理授权的 S3 访问，而 NACL 和前缀列表路由将流量限制在这两个端点上。每个作业的凭证通过 AWS STS 从生产账户注入到各个会话中，动态限定数据访问范围。一个持续验证套件运行集成测试，模拟针对此配置的数据泄露尝试。

Benchling 的解决方案使用一个独立的 AWS 账户来执行不受信任的代码，与主生产账户分离。AI 生成的代码在这个隔离的"不受信任代码账户"中运行，提供了作用域隔离。即使出现问题，包含客户数据和访问角色的主 Benchling 生产账户也不会直接暴露。

这个不受信任代码账户中托管着 AgentCore Code Interpreter（ACCI）以及 Benchling 现有的基于容器的执行环境（该环境使用 gVisor——一种容器沙箱运行时，通过拦截应用程序系统调用来提供内核级隔离——进行每个作业的隔离）。gVisor 环境是 Benchling 此前已有的计算隔离层，不属于本文所描述模式的组成部分。这两个执行环境各自拥有作用域受限的 IAM 角色，确保两者都无法将访问权限提升到其预期边界之外。

当任务从生产账户分派到不受信任账户时，数据访问按作业进行作用域限定。只有该作业所需的特定数据才是可访问的。生产账户凭证和更广泛的客户数据存储不会直接暴露给不受信任的代码。

为每个租户维护一个 IAM 角色会在数千个租户间造成无法承受的角色蔓延。相反，Benchling 通过 AWS Security Token Service（AWS STS）在每个 ACCI 会话中按作业注入凭证，在不累积静态角色的情况下动态限定访问范围。

DNS Firewall 配置

ACCI VPC 的设计理念是"除非明确允许，否则一律禁止"。没有互联网网关，也没有 NAT 网关。在这个 VPC 中运行的代码无法直接访问互联网。DNS 泄露防御的核心是 Amazon Route 53 Resolver DNS Firewall。它采用遵循"拒绝列表→允许列表→全部拒绝"模式的三优先级解析器策略：

P10：高优先级阻止（显式拒绝列表）

作为最高优先级被首先评估的这条规则，阻止对已知非预期域名的解析。这在恶意逻辑生效之前捕获明显的威胁。例如，如果 Benchling 识别出与已知数据泄露工具包或命令与控制基础设施相关的域名，这些域名会在这一层被阻止，而不受任何其他配置影响。该规则作为威胁情报的快速通道而存在。Benchling 可以主动枚举敌对端点并确保它们被立即拒绝，而不必仅仅依赖域名不在允许列表中这一事实。该规则还提供了可观测性。命中显式拒绝列表的查询会生成 DNS Firewall 日志，向安全团队发出潜在恶意活动的早期警告，表明沙箱中的代码正在尝试可疑的解析。

P100：允许列表（S3 存储桶和显式域名）

第二层是允许列表，仅允许对明确列出的域名进行 DNS 解析。在实践中，这仅限于数据访问所需的 S3 端点，通常没有其他内容。允许列表是刻意保持最小化的，因为每个获准的域名都代表一个潜在的泄露向量。Benchling 将解析范围限定为仅作业执行所需的特定 S3 存储桶端点。即使恶意代码试图联系合法的 AWS 服务端点用于非预期目的，除非 Benchling 明确批准，否则它无法解析该端点。这使 Benchling 拥有网络边界的完全所有权。与依赖可能随服务版本变化而变化的系统默认配置不同，允许列表是一个客户可控的产物，Benchling 可以按自己的计划对其进行审计、版本控制和更新。

P200：全部阻止（兜底 NODATA）

最后一条规则是一个兜底规则，对 P100 未明确允许的任何 DNS 查询都返回 NODATA。正是这条规则使得 DNS 数据泄露成为不可能。在典型的 DNS 隧道攻击中，恶意代码将窃取的数据编码为 DNS 查询中的子域名标签（例如 base64payload.example.com），并依赖递归解析将该查询送达攻击者控制的权威域名服务器。有了这个兜底规则，任何不在严格允许列表中的域名都会收到 NODATA 响应。编码后的泄露查询没有任何解析路径可以穿透。DNS 递归链在第一跳就被截断了。这最后一条规则将 VPC 从"受限"转变为"密封"。没有它，任何新域名或被忽视的端点都会默认允许解析。有了它，安全态势被反转：除非 Benchling 明确决定允许，否则任何域名都无法解析。

持续验证

Benchling 的产品安全团队首先在一个概念验证 VPC 中证明了这种方法的有效性。他们逐一测试了防御的每一层。DNS 隧道尝试证实，Route 53 Resolver DNS Firewall 对任何不在明确允许列表中的域名都返回 NODATA。直接 IP 连接尝试证实，前缀列表路由和 NACL 将流量限制在 443 端口和临时返回端口，无法到达任意外部主机。API 调用尝试证实，VPC 端点策略拒绝针对范围外任何 S3 存储桶的请求。由于没有互联网网关、NAT 网关和默认安全组，对于绕过这些控制的流量根本没有出站路径。

在概念验证验证了架构之后，Benchling 的基础设施团队将这些泄露模拟纳入了他们的持续集成测试套件。这些测试演练了真实攻击者会使用的相同向量。包括通过编码子域名查询进行 DNS 隧道挖掘、直接连接未授权端点，以及试图访问 VPCE 策略范围外 S3 存储桶等。如果任何测试解析了不应解析的域名、到达了外部端点，或将数据移出了批准的存储桶，流水线就会失败并阻止发布。

这种方法之所以重要，是因为安全配置并非静态的。随着基础设施演进、VPC 设置会发生变化；为支持功能开发会添加新端点；随着团队接入新服务，IAM 策略也会更新。如果没有持续验证，在部署时安全的配置可能随着周围环境的变化而悄然降级。通过将抗泄露能力视为一种可测试的属性而非一次性设置，Benchling 确保任何未来会无意中削弱安全边界的基础设施变更都能在进入生产环境之前被捕获。

VPC 端点策略与数据访问控制

由于 VPC 中没有互联网网关或 NAT 网关，AWS 服务访问必须通过 VPC 端点流动。Benchling 部署了一个网关端点用于区域内 Amazon S3 访问，以及一个接口端点用于跨区域 S3 访问。每个端点都附带了明确列出允许到达的 S3 存储桶的策略。任何针对策略中未包含的存储桶的请求，都会在到达 S3 之前在网络层被拒绝。

这创建了一种独立于 IAM 的防御。即使不受信任的代码获得了它不应访问的存储桶的有效凭证，端点策略也会阻止该请求。凭证限制了一个会话被授权执行的操作，而端点策略限制了网络在物理上能够交付的内容。Benchling 并未为数千个租户预配置 IAM 角色，而是通过 AWS STS 在每个任务的基础上向每个 ACCI 会话注入范围受限的凭证。每个任务仅获得其特定租户数据所需的权限。

流量还受到前缀列表路由和 NACL 的进一步约束，将通信限制在 443 端口和临时返回端口。Code Interpreter 在一个专用安全组中运行，没有默认的回退规则。没有任何端口、协议或网络路径可以让数据离开环境，除了通过明确限定的 VPC 端点。

通过网关 VPC 端点的 S3 访问

Benchling 为区域内 S3 访问配置了网关 VPC 端点，为跨区域 S3 访问配置了接口 VPC 端点。每个端点都附带了 VPCE 策略，明确列出仅授权给给定执行上下文的特定 S3 存储桶。任何针对策略中未包含的存储桶的 API 调用，都会在到达 S3 服务之前在网络层被拒绝。这意味着即使不受信任的代码以某种方式获得了另一个租户存储桶的有效凭证，请求仍然会失败。网络本身拒绝承载该流量。这创建了一种独立于 IAM 的防御，因此仅凭凭证被盗不足以访问未授权数据。

按任务划分的凭证作用域

Benchling 并未为数千个租户预配置 IAM 角色，而是通过 AWS Security Token Service (AWS STS) 向每个 ACCI 会话注入范围受限的凭证。每个任务仅获得其特定租户数据所需的权限。生产账户决定一个任务可以访问哪些数据，生成适当范围的临时凭证，并在调度时将其注入会话。Code Interpreter 执行角色的 S3 访问仅限于主堆栈存储桶。在启动时，一个会话策略被传入每个 Code Interpreter 执行，限制 S3 访问到授权存储桶内特定租户的路劲前缀。这确保了运行在沙箱内的代码只能访问它被调度去服务的那个租户的数据。这就是架构中显示的"按任务数据导出作用域"。Benchling 评估了授予 ACCI 角色对所有租户存储桶的广泛访问权限的替代方案，并拒绝了它，因为那样的话一个被攻陷的会话就会有通往任何租户数据的路径。

网络层锁定

除了 DNS Firewall 和 VPC 端点策略，NACL 还将流量限制在 443 端口和临时返回端口，前缀列表路由确保流量只能到达 VPC 端点，而 Code Interpreter 在一个没有默认回退规则的专用安全组中运行。攻击面被缩减到仅剩 Code Interpreter 及其限定的 VPC 端点。

为什么选择 AgentCore Code Interpreter 而非自定义沙箱

在采用 AgentCore 之前，Benchling 的团队评估了构建自己的沙箱解决方案。需求很明确：他们需要临时执行会话、任务级隔离、无持久状态，以及在 VPC 内运行以便应用自己的网络安全控制的能力。如果内部构建这将意味着设计自定义容器编排、实现沙箱生命周期管理，以及从零开始构建网络隔离原语。他们还需要持续修补安全漏洞，同时跟上不断演变的威胁向量。这代表着一项重大的持续工程投入，从 Benchling 的核心产品中抽调资源，且对客户没有任何差异化价值。

AgentCore Code Interpreter 在 VPC 模式下绕过了整条工作流。每个会话都是隔离的、短暂的，任务之间没有持久状态。AWS 处理沙箱生命周期，包括修补、扩展和强化执行环境。在 Benchling 自有的锁定 VPC 内运行 Code Interpreter 意味着他们可以在现有 AWS 安全原语（如 DNS Firewall、VPC 端点策略和 NACL）之上叠加层级，而无需构建自定义网络。这让 Benchling 的基础设施团队能够专注于产品安全控制，而非沙箱维护。

"有了 AgentCore Code Interpreter，我们能够购买而非自建一个安全解决方案。"

— Jeremy Stashewsky，应用安全工程师，Benchling

成果与业务影响

自 2026 年 4 月初在 VPC 模式下部署 AgentCore Code Interpreter 以来，Benchling 已扩展至每天超过 600 次代码执行会话，每周为超过 250 个不同租户提供 AI 智能体生成的科学工作负载服务。这证明了在其客户群中的广泛采用，且未损害其安全态势。部署以来，Benchling 报告了零安全事件和零跨租户数据泄露。

"为 AI 智能体提供代码解释器对于我们客户所要求的科学准确性来说是不可妥协的，但我们的威胁模型假设任何智能体或用户编写的代码都可能是非预期的。我们需要一个真正的沙箱，除了 S3 之外零网络访问。AgentCore Code Interpreter 在 VPC 模式下，结合 Route 53 DNS Firewall 和 VPC 端点，让我们能够关闭我们测试过的每一个泄露向量（包括 DNS），而无需自行构建。"

在多租户环境中运行 AI 生成的代码会引入传统沙箱无法完全解决的数据泄露向量。其中 DNS 解析尤其容易被忽视，因为标准网络控制措施主要聚焦于 HTTP、出站端口和直连连接。 Benchling 实现的这一模式提供了一份蓝图，可以在不构建自定义沙箱基础设施的情况下弥合这一缺口。

该架构以账户级隔离为起点，将不可信代码执行与生产系统完全分离。Amazon Bedrock AgentCore Code Interpreter 在 VPC 模式下提供托管的临时执行环境，位于该隔离账户内。Route 53 Resolver DNS Firewall 通过拒绝列表、允许列表、全量拒绝策略封堵 DNS 数据泄露向量。VPC 端点策略将服务访问限制在每个作业所需的特定 S3 存储桶内。通过 AWS STS 的按作业凭证作用域确保即使会话完全被攻陷，也无法超出单个租户的数据范围。

没有任何单一控制措施能够独自胜任。正是所有这些层的组合，加上通过自动化测试进行的持续验证，才得以规避整类数据泄露向量。每一层捕获其他层可能遗漏的威胁，而持续验证确保随着基础设施演进，安全态势始终保持稳固。

要开始使用 VPC 模式下的 Amazon Bedrock AgentCore Code Interpreter，请参阅 Code Interpreter 文档和 VPC 配置指南。您可以按照本文描述的模式，部署配置了 Route 53 DNS Firewall 和 VPC 端点策略的锁定 VPC。如果您已在沙箱环境中运行不可信代码，请考虑您当前的架构是否将 DNS 作为数据泄露渠道进行防护，并确认您是否具有持续验证机制来证明这一点。

Benchling 是面向生物科技研发的 AI 平台，统一科学数据并自动化工作流程，加速发现与开发。全球超过 1300 家企业信任 Benchling，从创新初创公司到默克（Merck）、Moderna、赛诺菲（Sanofi）等全球领导者，Benchling 为科学家提供了一个统一的地方来捕获、连接和操作整个研发生命周期中的数据。通过 Benchling AI，AI 智能体和模型直接作用于科学工作流程中，以结构化数据为基础。结果是团队效率更高、分子质量更好、突破性成果更快走向世界。