多租户 AI Agent 安全执行：用 VPC、DNS 防火墙与端点策略封住数据外泄路径

预计阅读时间：10 分钟

当 AI Agent 能够生成并执行 Python 等科学计算代码时，安全边界就不能只停留在提示词过滤。生成的代码应被视为不可信工作负载：它可能误读其他租户的数据，也可能通过 HTTPS、DNS 查询甚至云服务 API 将数据带出执行环境。

Benchling 的案例展示了一种纵深防御思路：利用 Amazon Bedrock AgentCore Code Interpreter 的 VPC 模式隔离代码执行环境，再用 Amazon Route 53 Resolver DNS Firewall 和 VPC 端点策略限制网络出口。关键不是某一个产品开关，而是让每一层都只能放行执行任务真正需要的能力。

从“代码沙箱”升级为“租户安全边界”

多租户 Agent 平台至少要处理三类风险：

租户间越权：租户 A 生成的代码读取了租户 B 的对象、数据库记录或内部 API。
外部数据外泄：代码把实验数据发送到任意公网地址。
隐蔽通道外泄：即使阻断 HTTP，代码仍可能把数据编码进 DNS 子域名，例如 secret-part.attacker.example。

因此，仅限制 Python 模块、扫描生成代码或设置执行超时并不够。更稳妥的架构是把一次 Agent 执行放进受控网络环境：

AgentCore Code Interpreter 以 VPC 模式运行，并接入专用私有子网。
执行子网不配置直接互联网出口，也不通过 NAT 网关访问任意公网地址。
需要访问的 AWS 服务通过 VPC Endpoint 暴露。
Endpoint Policy、执行角色 IAM Policy 和目标资源策略共同限制访问范围。
Route 53 Resolver DNS Firewall 采用允许列表，并拦截未知域名。
应用层继续校验租户身份，不能把网络隔离当作唯一授权机制。

这里有一个重要原则：网络决定“能去哪里”，身份策略决定“能做什么”，应用授权决定“能访问哪个租户的数据”。三层不能互相替代。

为什么阻断公网出口仍然要管 DNS

很多隔离方案会删除默认路由、关闭 NAT，然后认为数据已经无法外泄。但 VPC 内的工作负载通常仍可向 AmazonProvidedDNS 发送解析请求。如果攻击者能控制某个权威 DNS 域名，就可能把敏感内容编码到查询名称中：

<base32-encoded-data>.collect.attacker.example

即使最终连接不到这个域名，权威 DNS 服务器仍可能看到查询内容。Route 53 Resolver DNS Firewall 的作用，就是在 VPC Resolver 处理查询时执行域名规则，只允许业务所需域名，其余请求直接返回 NXDOMAIN 或其他阻断响应。

DNS 防火墙也不是万能的。如果执行环境还能访问公网 HTTPS，代码可能使用 DNS over HTTPS 绕过传统 DNS 控制。因此，DNS Firewall 应与无公网路由、严格的安全组以及 VPC Endpoint 配合使用，而不是单独部署。

可改造的 DNS 默认拒绝模板

下面是一个可直接改造的 CloudFormation 示例。它先允许指定域名，再通过 * 规则阻断其他查询。部署前必须替换示例域名，并根据实际区域和服务缩小 AWS 域名范围。

将以下内容保存为 dns-firewall.yaml：

AWSTemplateFormatVersion: '2010-09-09'
Description: Default-deny DNS firewall for an isolated AI code execution VPC

Parameters:
  VpcId:
    Type: AWS::EC2::VPC::Id

Resources:
  AllowedDomains:
    Type: AWS::Route53Resolver::FirewallDomainList
    Properties:
      Name: ai-sandbox-allowed-domains
      Domains:
        # 示例值：生产环境应优先允许实际使用的服务域名。
        - amazonaws.com
        - '*.amazonaws.com'
        - corp.example
        - '*.corp.example'

  BlockAllDomains:
    Type: AWS::Route53Resolver::FirewallDomainList
    Properties:
      Name: ai-sandbox-block-all
      Domains:
        - '*'

  FirewallRuleGroup:
    Type: AWS::Route53Resolver::FirewallRuleGroup
    Properties:
      Name: ai-sandbox-default-deny
      FirewallRules:
        - Action: ALLOW
          FirewallDomainListId: !Ref AllowedDomains
          Priority: 100
        - Action: BLOCK
          BlockResponse: NXDOMAIN
          FirewallDomainListId: !Ref BlockAllDomains
          Priority: 200

  FirewallAssociation:
    Type: AWS::Route53Resolver::FirewallRuleGroupAssociation
    Properties:
      Name: ai-sandbox-vpc-association
      FirewallRuleGroupId: !Ref FirewallRuleGroup
      MutationProtection: ENABLED
      Priority: 100
      VpcId: !Ref VpcId

Outputs:
  FirewallRuleGroupId:
    Value: !Ref FirewallRuleGroup

部署命令如下：

aws cloudformation deploy \
  --stack-name ai-sandbox-dns-firewall \
  --template-file dns-firewall.yaml \
  --parameter-overrides VpcId=vpc-0123456789abcdef0

从 Agent 执行环境所在子网进行验证：

# 应按允许规则正常解析；请替换成实际需要的服务域名。
dig s3.us-east-1.amazonaws.com

# 在默认拒绝策略下，应得到 NXDOMAIN 或被阻断。
dig unique-test-name.example.com

示例为了便于理解允许了 *.amazonaws.com，但这对生产环境通常过宽。更好的做法是只允许实际使用的区域化服务域名，启用 VPC Endpoint 的 Private DNS，并确保子网本身没有 NAT 或 Internet Gateway 出口。

VPC Endpoint Policy 不是装饰品

仅创建 S3、Secrets Manager 或其他服务的 VPC Endpoint，并不代表 Agent 只能访问指定资源。端点策略应成为额外的粗粒度边界，防止执行角色因 IAM 配置错误而访问不相关的桶或服务。

下面的 S3 Gateway Endpoint Policy 示例只允许一个执行角色访问一个租户前缀。部署前替换账号、角色、桶名、租户 ID 和 Endpoint ID。

将策略保存为 s3-endpoint-policy.json：

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListOnlyTenantPrefix",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<ACCOUNT_ID>:role/agentcore-tenant-a-execution"
      },
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::scientific-agent-data",
      "Condition": {
        "StringLike": {
          "s3:prefix": [
            "tenants/tenant-a/*"
          ]
        }
      }
    },
    {
      "Sid": "AccessOnlyTenantObjects",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<ACCOUNT_ID>:role/agentcore-tenant-a-execution"
      },
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::scientific-agent-data/tenants/tenant-a/*"
    }
  ]
}

应用策略：

aws ec2 modify-vpc-endpoint \
  --vpc-endpoint-id vpce-0123456789abcdef0 \
  --policy-document file://s3-endpoint-policy.json

在数千租户环境中，不应机械地为每个租户复制整套 VPC。可以按风险等级或业务单元建立隔离单元，每个单元使用独立子网、端点和执行角色；单元内部再通过租户专属 IAM Session、S3 前缀、KMS Encryption Context 和应用层授权进行细分。

还要注意，Endpoint Policy 不会替代 IAM Policy 或 S3 Bucket Policy。一次访问通常需要同时通过：

执行角色的身份策略；
VPC Endpoint Policy；
S3 Bucket Policy 或目标服务的资源策略；
KMS Key Policy，如果对象使用客户管理密钥加密；
应用自身的租户授权检查。

上线前的安全检查表

将 Agent 生成代码投入多租户生产环境前，可以逐项确认：

Code Interpreter 是否运行在指定 VPC、私有子网和最小化安全组中？
子网是否真的没有任意公网出口，包括 NAT、代理和可访问的转发服务？
所有必需的 AWS API 是否通过 VPC Endpoint 访问？
Endpoint Policy 是否只允许必要的服务、资源和执行角色？
DNS 是否采用允许列表，未知域名是否默认阻断？
是否开启 Route 53 Resolver Query Logging、VPC Flow Logs、CloudTrail 和服务访问日志？
租户 ID 是否由可信控制平面注入，而不是由模型输出决定？
临时凭证、工作目录和缓存是否在执行结束后销毁？
是否测试过跨租户读取、DNS 隧道、重定向、预签名 URL 和云元数据访问？

Benchling 案例最值得借鉴的地方，是把 AI 代码执行视为真正的不可信计算，而不是普通后端函数。VPC 模式提供隔离基础，DNS Firewall 封堵容易被忽略的隐蔽通道，Endpoint Policy 则限制云服务访问范围。只有这些控制相互叠加，才能在保留 Agent 执行能力的同时，把一次配置失误演变成跨租户事件的概率降下来。