亚马逊AWS官方博客
多租户 AI agent 的数据安全：Amazon FSx for NetApp ONTAP 的访问边界与会话防护
摘要：AI agent 被操纵后可能越权访问或破坏文件数据。本文介绍如何利用 Amazon FSx for NetApp ONTAP 在 agent 之外划分访问边界、限制会话影响范围，并实现检测与恢复。olicy、自主勒索软件防护、NAS 审计、快照和取证副本，实现检测、告警、取证与恢复。
目录
一、前言
AI agent 的能力正从内容生成和知识检索，逐步延伸到直接读写企业文件，例如修改代码、整理文档、分析数据以及调整配置。当一个 agent 平台同时服务多个租户，每个租户又承载大量并发会话时，数据访问与修改的边界会变得更加复杂。agent 的行为由模型推理驱动，可能受到提示词注入、被篡改的输入以及模型不确定性的影响，部署方很难保证其始终按照预期执行。因此，工具收敛、输入输出过滤和人工审批虽不可或缺，但真正的数据边界仍应由 agent 执行环境之外的组件强制实施。
Amazon FSx for NetApp ONTAP（下文简称 FSx for ONTAP）将数据访问控制和数据管理能力置于存储系统内部。存储虚拟机（SVM）提供命名空间、网络接口和管理边界；客户端的挂载与文件操作由存储端依据 export policy 和文件权限判定；快照和 FlexClone 则通过独立于数据访问路径的管理接口创建。只要管理接口与 agent 隔离，即使 agent 失控，也无法修改存储端的授权规则。对于需要直接读写企业文件的 agent 场景，FSx for ONTAP 主要提供以下能力：
- 按网络身份实施存储侧授权：挂载点（junction）只定义卷在命名空间中的路径，本身不授予权限；export policy 按客户端地址、协议和安全类型决定是否允许挂载，以及授予只读还是读写权限。
- 为会话提供轻量工作区和可写副本：qtree 可用于创建带树配额的会话工作区；当会话需要独立改写共享数据时，可以按需创建 FlexClone 写时复制副本。
- 建立可信用户身份：在经确认具备 NFS Kerberos 内核和用户态能力的客户端环境中，存储端可以依据 KDC 签发的票据识别用户，为文件权限和 NFSv4 ACL 提供可信的身份基础；其他环境需要由 agent 外部的数据访问层实施会话级授权。
- 在存储侧检测并阻断异常操作：FPolicy 可以按规则拒绝高风险文件操作；自主勒索软件防护（ARP）可以识别异常的批量改写并自动创建快照。
- 支持审计、取证与恢复：NAS 审计记录文件访问事件；快照和 FlexClone 可用于冻结现场、派生取证副本和恢复数据。
本文按照上述层次展开：先利用网络身份划分租户组和 agent 的访问范围，再使用 qtree 与 FlexClone 限制会话失控的影响范围；对于需要强制区分用户或会话的场景，由 agent 外部的受信任数据访问层实施授权；最后通过检测、告警、取证和恢复能力形成纵深防御。
二、Agent 的威胁与权限模型
2.1 Agent 被操纵的风险
在正常情况下，agent 会按照指令在授权范围内工作。风险出现在 agent 受到操纵之后。例如，agent 在处理任务时读取了嵌入恶意指令的内容，随后尝试访问未授权目录、读取其他会话的工作数据，或者批量删除其具有写权限的文件。在过去的一些公开报道中，有许多内容展示了这类攻击路径：
- Palo Alto Networks Unit 42 在 AgentCore 上进行过受控演示：研究人员在支持工单中嵌入隐藏指令，诱导 agent 通过内置 shell 工具下载并执行脚本，再从同一 Linux 身份下的服务进程内存中读取可复用的登录令牌。AWS 将其归类为 informative，并把工具范围收敛和出站过滤列为客户侧控制措施；相关报道据此将问题定性为配置风险与权限边界问题，而非经 AWS 确认的产品漏洞（参见 LinuxSecurity 对该研究的报道）。
- Trail of Bits 演示了从提示注入到远程代码执行的攻击链，说明仅依赖人工审批的命令确认机制也可能被诱导绕过。
- agent 以 root 身份运行所带来的风险已受到业界关注，参见 Resilient Cyber 的 Your AI Agent Is Running As Root。
收敛 agent 可用的工具、使用 guardrail 过滤输入输出、保留高风险操作的人工审批，并尽可能以非 root 身份运行 agent，仍然是必要的基础控制。但是，这些措施位于 agent 所在的执行环境中，一旦 agent 被完全操纵，就可能被绕过或失效。因此，数据访问边界和恢复能力必须由 agent 无法修改的外部组件提供。
2.2 威胁模型
接下来本文使用一个示例配置说明威胁模型。该配置可能是一个常见但绝非推荐的部署方式：agent 进程以 uid 0 运行，并在容器内自行挂载 NFS。此时 agent 既可以执行 mount -t nfs，也可以切换进程的 uid/gid，相当于已被完全操纵并取得容器内最高权限。最佳实践是由平台或独立的特权组件完成挂载，再以非 root 用户运行 agent，并移除 agent 的挂载和身份切换能力，从而缩小容器内的攻击面。
在这种配置下，agent 可能会有以下潜在风险：
- 攻击者能力：攻击者通过提示词注入或被篡改的输入操纵 agent，并以 agent 进程的身份在容器内执行任意代码。
- 容器内权限：agent 拥有 root 和
CAP_SYS_ADMIN，能够自行挂载 NFS 并切换 uid/gid。在 AUTH_SYS 认证下，存储端接收的是客户端声明的用户身份；root squash 只映射 uid 0，不能阻止进程切换到其他 uid。因此，依赖客户端声明身份的文件权限不能单独作为强制边界。 - 网络可达性：agent 可以访问安全组允许的目的地，包括 SVM 的 NFS 数据 LIF；如果出站规则未收敛，还可能访问存储管理接口或公网。
- 凭证边界：ONTAP 管理凭证只应由编排层持有，Runtime 执行角色不应具备读取该凭证或管理 FSx 资源的权限。Runtime 的网络出站也应允许访问数据 LIF 的 NFS 端口，而不应允许访问管理 LIF。
- 攻击目标：读取或篡改其他租户、其他用户或其他会话的数据；破坏源数据；向外部传输数据；删除操作痕迹；耗尽存储容量；触达管理面。
2.3 示例场景与权限需求
以一个通用的多租户 agent 平台作为示例。平台基于 Amazon Bedrock AgentCore Runtime 构建，企业文件存放在 FSx for ONTAP 上，并由多个租户共享：
- 每个租户可以部署用途不同的多个 agent，每个 agent 又可服务权限不同的用户和并发会话。
- 不同租户的数据需要相互隔离；同一租户内的不同 agent 可能对同一数据集具有不同的只读或读写权限。
假设租户 A 的数据存放在卷 1 和卷 2 中，卷 2 内还包含仅允许授权用户访问的受限目录。期望权限如下：
| 发起方 | 租户 A 卷 1 | 租户 A 卷 2 | 卷 2 中的受限目录 | 其他租户数据 |
| 租户 A：agent X，普通用户会话 | 读写 | 只读 | 不可访问 | 不可访问 |
| 租户 A：agent Y，普通用户会话 | 只读 | 读写 | 不可访问 | 不可访问 |
| 租户 A：agent Y，授权用户会话 | 只读 | 读写 | 只读 | 不可访问 |
| 其他租户：任意 agent | 不可访问 | 不可访问 | 不可访问 | 按各自租户授权 |
同一个 agent 同时服务多个会话时，各会话的中间结果还应相互独立，一个会话的误操作不应影响源数据或其他会话。
这些边界需要由不同机制共同实现。export policy 按网络身份区分租户组和 agent；在 AUTH_SYS 下，同一 Runtime 内的用户和会话不能依靠 uid 获得强制隔离；客户端经独立验证具备 NFS Kerberos 所需的内核和用户态能力时，可以使用经过认证的用户身份进一步授权，否则需要使用外部受信任数据访问层；qtree 和 FlexClone 用于限制单个会话的资源消耗与修改范围；FPolicy、ARP、NAS 审计和快照则提供阻断、告警、取证与恢复能力。
三、按网络身份划分访问边界
3.1 SVM 与 export policy
FSx for ONTAP 提供两个层次的网络侧边界：
- SVM：一个文件系统可以包含多个 SVM。每个 SVM 拥有独立的命名空间、数据 LIF、export policy、Active Directory 加入关系和管理边界，适合隔离要求较高的少数业务域或租户组。
- export policy：每个卷都可以关联一项 export policy。规则按客户端地址或网段、NFS 版本和安全类型，决定客户端是否可以访问卷，以及授予只读还是读写权限。
AgentCore Runtime 使用 VPC 网络模式时，会在指定子网中创建弹性网络接口（ENI）。ENI 的私有地址由服务分配，agent 无法在容器内修改。使用相同子网和安全组配置的 agent 可能共用 ENI（参见 AgentCore VPC 连接文档）。
AgentCore 的多租户部署可以采用 dedicated 或 shared Runtime（参见 Building multi-tenant agents with Amazon Bedrock AgentCore）。多个租户共用 Runtime 或来源子网时，export policy 无法仅凭网络身份区分这些租户。更现实的做法是划分少数权限层级，例如把需要访问敏感卷的租户组或 agent 部署在专用子网中，敏感卷只允许该子网访问。这样，export policy 强制的是权限层级之间的边界；同一子网内的租户仍需依靠应用身份或 agent 外部的受信任数据访问层进一步区分。
3.2 按网络身份限制挂载
以下示例使用两个位于不同权限子网的 Runtime，分别代表租户组 A 和租户组 B。ONTAP 为两个租户组分别创建卷，并只允许对应子网访问：
# 租户组 A：只允许 A 的 Runtime 子网访问，仅使用 NFSv4，并启用 root squash
vserver export-policy create -vserver <SVM> -policyname tenant_a
vserver export-policy rule create -vserver <SVM> -policyname tenant_a -ruleindex 1 \
-clientmatch <TENANT_A_CIDR> -protocol nfs4 \
-rorule sys -rwrule sys -superuser none
volume modify -vserver <SVM> -volume <TENANT_A_VOLUME> -policy tenant_a
# 租户组 B 同理
vserver export-policy create -vserver <SVM> -policyname tenant_b
vserver export-policy rule create -vserver <SVM> -policyname tenant_b -ruleindex 1 \
-clientmatch <TENANT_B_CIDR> -protocol nfs4 \
-rorule sys -rwrule sys -superuser none
volume modify -vserver <SVM> -volume <TENANT_B_VOLUME> -policy tenant_b
在这项配置下，租户组 A 的 Runtime 只能挂载 A 的卷，租户组 B 同理。拒绝由存储端依据来源网络身份执行，与 agent 在容器内使用的 uid 无关。当然，如果两个 Runtime 位于同样的子网，以上 CIDR 规则便无法区分二者。
3.3 按网络身份区分读写权限
export policy 不仅决定客户端能否访问卷，rorule 与 rwrule 还可以按网络身份分别授予只读和读写权限。以同一租户内的 agent X 与 agent Y 为例，假设二者的 Runtime 位于不同权限子网，存储侧有三个示例卷：
- 共享卷：两个 agent 均为只读。
- 卷 1：agent X 可读写，agent Y 只读。
- 卷 2：agent X 只读，agent Y 可读写。
每个卷关联一项 export policy，并为两个 agent 分别建立规则。rorule sys 允许以 AUTH_SYS 方式读取；rwrule sys 允许写入，rwrule never 拒绝写入；superuser none 启用 root squash。卷 1 的配置示例如下：
vserver export-policy create -vserver <SVM> -policyname vol1_pol
vserver export-policy rule create -vserver <SVM> -policyname vol1_pol -ruleindex 1 \
-clientmatch <AGENT_X_CIDR> -protocol nfs4 \
-rorule sys -rwrule sys -superuser none
vserver export-policy rule create -vserver <SVM> -policyname vol1_pol -ruleindex 2 \
-clientmatch <AGENT_Y_CIDR> -protocol nfs4 \
-rorule sys -rwrule never -superuser none
volume modify -vserver <SVM> -volume <VOLUME_1> -policy vol1_pol
卷 2 将两条规则的 rwrule 对调；共享卷的两条规则均使用 rwrule never。最终权限如下：
| 发起方 | 共享卷 | 卷 1 | 卷 2 |
| agent X | 只读 | 读写 | 只读 |
| agent Y | 只读 | 只读 | 读写 |
需要注意的是，网络身份只能区分到 Runtime 或来源子网，不能区分同一 Runtime 内的用户。在 AUTH_SYS 下，即使启用了 root squash，agent 仍可能切换到其他 uid，以绕过此防护手段。因此，需要强制保护的用户级数据不能只依赖 AUTH_SYS 下的 uid 和目录权限，而应在客户端满足 NFS Kerberos 前提时使用后文所述的可信身份，或由外部受信任数据访问层实施授权。
四、限制会话的爆炸半径：qtree 工作区与 FlexClone
在 AUTH_SYS 部署中，同一 Runtime 内的会话通过该 Runtime 的一个或多个 ENI 访问存储，ENI 与会话之间没有一一对应关系，存储端无法依据来源地址区分会话。无论是否具备可信的会话身份，仍需要限制单个会话对其已授权数据的影响范围。为此，可以按需求分配两类工作空间：大多数会话使用独立 qtree；需要改写共享数据集的会话再使用 FlexClone。
4.1 为每个会话配置独立 qtree 工作区
qtree 是卷内的逻辑分区，可以单独设置树配额、安全风格和 export policy。编排层可以在工作区卷中为每个会话创建一个 qtree，并设置容量或文件数配额，从而避免单个会话耗尽整个卷。FSx for ONTAP 支持 qtree 和树配额，可通过 ONTAP CLI 或 REST API 管理（参见 Manage storage consumption at scale using quotas on Amazon FSx for NetApp ONTAP）；树配额对 root 同样生效（参见 ONTAP 树配额文档）。
qtree 的创建和删除较为轻量，适合数量多、生命周期短且并发度高的 agent 会话。单个卷最多可创建 4,994 个 qtree（参见 ONTAP CLI 文档：volume qtree create），也不会消耗额外的卷配额。部署时仍应把活跃会话分散到多个卷，以避免单卷吞吐或元数据热点。qtree 的创建、配额设置和回收均应由 agent 执行环境之外的编排层完成。
| 维度 | qtree | FlexClone |
| 创建与回收 | 轻量，适合频繁创建 | 开销较高，突发场景可使用预建池 |
| 卷配额 | 不单独占用卷配额 | 每个 FlexClone 占用一个卷 |
| 初始内容 | 空工作区 | 源卷的写时复制视图 |
| 容量限制 | 树配额 | 卷容量与配额 |
| 快照与恢复 | 快照按所在卷创建，恢复时需定位到单个 qtree | 可独立创建快照并整卷恢复 |
qtree 只划分路径和资源配额，不自动形成会话级授权边界。在 AUTH_SYS 下，同一 Runtime 内的会话一旦知道其他 qtree 的路径，就可能挂载或访问它们。因此，qtree 名称不应包含租户或业务语义，路径随机化只能作为辅助遮蔽；会话级强制隔离需要在客户端满足 NFS Kerberos 前提时使用可信身份，或使用受信任的数据访问代理。
编排层还需要管理 qtree 的生命周期。会话结束后，应先提取需要长期保留的产出，根据取证策略创建或复用卷快照，再删除不再需要的 qtree 和配额规则。快照按卷保留数据块，因此 qtree 删除后，相关空间可能要等引用这些数据的快照过期后才会释放。
4.2 为改写共享数据的会话创建 FlexClone
当会话需要在共享数据集上进行独立修改时，可以由编排层从源卷创建 FlexClone。FlexClone 使用写时复制：新卷与父卷共享未修改的数据块，只有发生写入的部分才占用新空间（参见 ONTAP FlexClone 文档）。会话的写入和删除只作用于 FlexClone，不影响源卷。
FlexClone 每个副本都占用一个卷，创建速度也低于 qtree，因此不宜作为所有高并发会话的默认工作区。更合适的方式是只为确需改写共享数据的会话分配 FlexClone，并在突发场景中使用预建 FlexClone 池。编排层负责创建、授权和回收 FlexClone，agent 只接收被分配的 junction。
创建 FlexClone 时不能在同一个请求中指定新的 export policy，FlexClone 会先继承父卷策略，再由编排层切换到目标策略。为避免这一短暂窗口引入意外访问，源卷应关联拒绝客户端访问的策略；FlexClone 创建后，编排层再为其应用会话或权限层级对应的策略。
qtree 和 FlexClone 限制的是越权或误操作造成的后果，而不是阻止越权本身。下一节将说明如何使用 Kerberos 为 NFS 访问建立可信用户身份。
五、使用 Kerberos 建立可信用户身份
本节讨论 FSx for ONTAP 与通用 NFS 客户端之间的 Kerberos 身份机制。需要注意的是，是否能够采用该方案，取决于客户端是否同时具备 Kerberos 用户态组件、rpc.gssd、RPCSEC_GSS Kerberos 内核机制和受控的票据存储。
AUTH_SYS 使用客户端声明的 uid 作为用户身份，存储端无法确认该身份是否真实。NFS Kerberos 则要求客户端出示由 KDC 签发的票据，ONTAP 根据经过认证的 principal 执行名称映射，再以映射后的 UNIX 用户判定文件权限和 NFSv4 ACL。FSx for ONTAP 支持 krb5、krb5i 和 krb5p：krb5 提供身份认证，krb5i 进一步校验每条 NFS 消息的完整性，krb5p 还会保护传输内容的机密性（参见 ONTAP NFS Kerberos 支持说明）。
使用 Kerberos 通常需要完成以下配置：
- 为 SVM 配置 Active Directory 或外部 Kerberos 域，并在数据 LIF 上启用 NFS Kerberos（参见 ONTAP NFS Kerberos 域配置文档）。
- 为用户分配 principal。需要把授权细化到应用会话时，由编排层为每个会话分配唯一 principal 和短生命周期票据。ONTAP 本身并不识别应用会话，这一映射关系必须由编排层维护。
- 通过名称映射把 principal 转换为预先存在的 UNIX 用户，再以目录权限或 NFSv4 ACL 授予该用户所需权限。名称映射应限定到明确的 principal 命名空间，避免使用匹配整个 Kerberos 域的宽泛规则。
- 将区域卷或数据卷的 export policy 设置为只接受所需的 Kerberos 安全类型，不再放行
sys。
以下示例只匹配以 session_ 开头的 principal，并把捕获的名称映射到对应 UNIX 用户：
# 区域卷或数据卷只接受 Kerberos，并启用 root squash
vserver export-policy create -vserver <SVM> -policyname <KERBEROS_POLICY>
vserver export-policy rule create -vserver <SVM> -policyname <KERBEROS_POLICY> -ruleindex 1 \
-clientmatch <CLIENT_CIDR> -protocol nfs4 \
-rorule krb5 -rwrule krb5 -superuser none
# 仅映射 session_ 命名空间中的 principal
vserver name-mapping create -vserver <SVM> -direction krb-unix -position <POSITION> \
-pattern "^session_(.+)@<REALM>$" -replacement "\1"
客户端挂载前需要取得有效票据并运行 rpc.gssd。挂载目标应使用与 NFS 服务主体名称一致的 DNS 主机名；直接使用数据 LIF IP 只有在 SPN 和名称解析被专门配置为匹配该地址时才可能成功，通常会因服务主体名称不一致而被拒绝：
# 确认客户端已有有效票据，并且 rpc.gssd 正在运行
klist
mount -t nfs -o vers=4.1,sec=krb5 \
<SVM_DNS_NAME>:/<NFS_PATH> <MOUNT_POINT>
Kerberos 凭证还需要独立管理。不要把可长期复用的 keytab 直接暴露给 agent；如必须使用 keytab，应由受信任的挂载组件持有，并在会话结束后轮换或销毁。停用 principal 不会立即使已经签发的票据失效，因此票据有效期应尽量缩短，会话结束时还应销毁票据缓存。
Kerberos 解决的是身份可信问题，但不能限制已经获得合法权限的会话如何修改自己的数据。因此，它仍需与 qtree、FlexClone、FPolicy、审计和快照配合使用。对于未确认具备完整 NFS Kerberos 客户端能力的运行环境，应把严格的会话级授权转移到 agent 外部的受信任数据访问层。
六、检测与阻断：FPolicy 与自主勒索软件防护
FPolicy 是 ONTAP 的文件操作策略框架（参见 Protecting data against ransomware with Amazon FSx for NetApp ONTAP）。客户端发起文件操作时，存储端会依据 FPolicy 规则进行判定。native engine 由 ONTAP 直接执行规则并拒绝命中的操作；external engine 则把操作发送给外部 FPolicy 服务器，由外部服务记录或作出同步判定。
对 agent 场景而言，native engine 适合拦截模式明确的高风险操作，例如创建特定扩展名的文件，或把现有文件重命名为已知的勒索软件扩展名。规则可以按卷、协议、文件操作和扩展名组合：
# 定义需要检查的 NFSv4 文件操作
vserver fpolicy policy event create -vserver <SVM> \
-event-name agent_risky_ops -protocol nfsv4 \
-file-operations create,rename,write
# 使用 native engine，命中规则时直接拒绝
vserver fpolicy policy create -vserver <SVM> \
-policy-name agent_block -events agent_risky_ops -engine native
# 限定作用卷和扩展名
vserver fpolicy policy scope create -vserver <SVM> \
-policy-name agent_block -volumes-to-include <AGENT_VOLUMES> \
-file-extensions-to-include locked,encrypted
vserver fpolicy enable -vserver <SVM> \
-policy-name agent_block -sequence-number 1
命中策略的操作会在客户端表现为权限拒绝，容器内的 root 也无法绕过存储端判定。FPolicy 只能匹配预先定义的模式，无法判断正常文件名下的内容改写是否恶意。使用 REST API 管理策略时，应先创建策略，再通过单独请求启用。
自主勒索软件防护（ARP）是 ONTAP 内置的异常行为检测能力（参见 FSx for ONTAP ARP 文档）。ARP 分析文件活动、数据熵和扩展名变化，识别异常的批量改写、加密或删除，并在检测到威胁时创建快照和发出告警。从 ONTAP 9.16.1 起，ARP 使用预训练的机器学习模型，启用后即可进入主动保护，无需学习期（参见 ONTAP ARP 文档）。ARP 按卷启用：
security anti-ransomware volume enable \
-vserver <SVM> -volume <AGENT_VOLUME>
ARP/AI 不适合高频创建和删除文件的临时测试或开发类负载，因此不应默认启用在高周转的会话 qtree 工作区卷上；它更适合保护持久数据卷，并应在启用前评估工作负载特征。FPolicy 和 ARP 都不是完整的访问控制。FPolicy 无法覆盖未预先定义的操作模式；ARP 依赖行为特征，少量、缓慢或近似正常业务的改写可能不会触发告警，而且它不能阻止异常发生前后的全部写入。两者看到的客户端通常是 Runtime ENI，不能直接把操作归因到具体会话。它们应作为检测和止损层，与访问边界、审计和快照恢复共同使用。
七、告警、取证与恢复
当会话失控并改写或删除数据时，平台通常需要完成三项工作：及时发现异常并告警，确认会话执行了哪些操作，以及恢复被错误修改的数据。存储侧审计可以提供独立于 agent 的访问记录，快照与 FlexClone 则用于冻结现场和恢复数据。
7.1 告警：NFSv4 审计 ACE 与 NAS 审计
在 SVM 上启用 NAS 审计后，ONTAP 会把文件访问事件写入指定的审计卷（参见 FSx for ONTAP 文件访问审计）。对于 NFSv4 客户端，由文件或目录 ACL 中的审计 ACE 决定哪些成功或失败的操作需要记录。审计 ACE 不授予也不拒绝访问权限，只控制审计事件的生成。
以下示例启用文件操作审计，并在受信任的管理挂载点上为敏感目录添加可继承的审计 ACE。vserver audit create 不是幂等命令；SVM 已有审计配置时，应保留原配置并使用 vserver audit modify 调整事件范围：
# 先确认 SVM 是否已有审计配置
vserver audit show -vserver <SVM>
# 仅在尚未配置审计时创建；已有配置时使用 vserver audit modify
vserver audit create -vserver <SVM> \
-destination /<AUDIT_JUNCTION> -events file-ops -format xml
vserver audit enable -vserver <SVM>
# 记录任何主体的写入、追加和删除操作，包含成功与失败事件
nfs4_setfacl -a "U:SFfd:EVERYONE@:waDd" \
<TRUSTED_ADMIN_MOUNT>/<SENSITIVE_DIR>
f 和 d 继承标志使新文件和新子目录继承审计 ACE。对于已有文件，应先读取并检查现有 ACL，再由受信任的编排层逐项补充，避免重复执行 nfs4_setfacl -a 产生重复 ACE。递归修改还要求执行身份拥有目标树中所有对象的 ACL 修改权限；启用 root squash 后，不应假设客户端 root 具备该权限。审计事件会先缓存在内存中，在达到轮转条件或执行 vserver audit rotate-log -vserver <SVM> 后写入审计卷。安全团队可以依据删除数量、拒绝访问次数或敏感路径的写入事件生成告警。使用 Kerberos 时，审计记录中的认证身份可用于用户级关联；要进一步定位到具体会话，还需结合调用日志中的会话标识。
7.2 取证：快照与取证副本
发现异常后，应先创建快照冻结现场，再从该快照派生 FlexClone 取证副本。这样安全团队在副本上分析时，不会修改原始现场：
| 步骤 | 操作 | 作用 |
| 1 | 会话结束或发现异常时，为相关卷创建快照 | 冻结现场 |
| 2 | 从快照派生 FlexClone 取证副本 | 保留异常前后的文件状态，供独立分析 |
7.3 恢复：整卷回滚或单目录恢复
取证完成并确认恢复点后，可以按照会话工作区类型选择恢复方式：
- FlexClone 会话独占一个卷，可以把该卷整体回滚到指定快照。
- 多个 qtree 共用一个卷，不能为恢复单个会话而执行整卷回滚，否则会同时撤销其他会话的合法改动。此时应仅从卷快照恢复目标 qtree 的目录。
创建快照、派生取证副本和整卷回滚的 ONTAP CLI 如下：
volume snapshot create -vserver <SVM> \
-volume <SESSION_VOLUME> -snapshot session_end
volume clone create -vserver <SVM> -flexclone <FORENSIC_VOLUME> \
-parent-volume <SESSION_VOLUME> -parent-snapshot session_end \
-junction-path /<FORENSIC_JUNCTION>
volume snapshot restore -vserver <SVM> \
-volume <SESSION_VOLUME> -snapshot session_end
qtree 会话可以从 .snapshot 目录恢复。该目录默认可直接访问，但不会出现在普通目录列表中。以下命令只同步目标 qtree，不会回滚同卷上的其他 qtree：
rsync -a --delete --omit-dir-times \
<MOUNT>/.snapshot/session_end/<QTREE>/ \
<MOUNT>/<QTREE>/
八、总结
当 AI agent 直接读写企业文件数据时，部署方不能假设 agent 的每一步操作都符合预期。有效的数据安全体系需要把授权、资源限制、检测和恢复能力放在 agent 无法修改的外部控制层中。
FSx for ONTAP 可以在这套体系中承担多层职责：
- export policy 按来源网络身份划分租户组和 agent 的挂载、只读与读写权限，但不能区分共用 Runtime 或来源子网的租户。
- qtree 为高并发会话提供轻量、带配额的工作区；FlexClone 为需要改写共享数据的会话提供独立的写时复制副本。二者限制影响范围，但不自动形成授权边界。
- AUTH_SYS 无法提供可信的用户身份。在客户端经独立验证具备 NFS Kerberos 内核和用户态能力时，可以由存储端按经过认证的 principal 授权；其他运行环境则应把严格的会话级授权转移到 agent 外部的受信任数据访问层。
- FPolicy 和 ARP 分别覆盖已知高风险模式与异常批量改写；NAS 审计、快照和取证副本则支持告警、调查与恢复。
- ONTAP 管理接口和管理凭证必须与 agent 隔离，Runtime 出站只允许访问必要的数据面端口。
➡️ 下一步行动：
相关产品：
- Amazon Bedrock — 用于构建生成式人工智能应用程序和代理的端到端平台
- Amazon Bedrock AgentCore — 加快代理投入生产的速度
- Amazon VPC — 隔离云网络
相关文章：
- 利用AWS Budget实现Amazon Bedrock 用量监控、超预算告警与自动中断方案
- Zenjoy 基于 Amazon Bedrock 和 EKS 构建 AIOps Agent：打通 Prometheus、ES 与夜莺的智能化告警实战
- 别让你的 Amazon Bedrock 模型为他人”打工”——API 调用安全防护指南
- 简化故障注入，读懂应用影响：用 AI Agent 做混沌工程
- 基于 AWS DevOps Agent 构建 AI 驱动的运维分析系统
*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。
本篇作者
AWS 架构师中心：云端创新的引领者探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用
|
 |
