代理访问模型（27分钟阅读）

# 代理访问模型 来源：https://blog.cloudflare.com/the-agent-access-model/ 过去十二年间，企业安全一直在远离“信任网络”这一理念。BeyondCorp 提出，请求的来源——无论是在企业内网还是公共互联网——不应决定其是否被允许。身份和设备健康状况才应当决定。这一模型取得了胜利：如今，它构成了零信任（Zero Trust）的很大一部分基础。 Google 的 BeyondCorp 假设了一个特定的主体：一个坐在设备前的人，以人类的速度行动。而如今，组织正在部署**代理（agent）**——代表我们进行推理、行动并访问系统的软件主体。一个任务级（task-scoped）的代理运行是短暂的。当工作完成时，它便结束。一个长期运行的代理服务可能处理许多这样的任务，并且以远超人类的速度移动数据。 我们为人类构建的各类控制措施，在用于代理时并不会大声宣告失败。它们悄无声息地失败——授予过多权限、看到过少信息、信任时间过长。 本文提出了一种面向代理的访问模型：**代理访问模型（Agent Access Model，AAM）**。我们将描述该模型，并展示其各组件如何构建。随后，我们将通过一个具体示例进行说明，并把当前已有的单一主体（single-principal）控制措施，与更难的**多方访问控制（multiplayer access control）**问题区分开来。 当前的大量工作试图让每一次访问决策变得更智能。AAM 采取了不同的思路：让代理的能力范围更小，这样需要判断的东西本身就变少了。 ## 转变 十年前，企业安全中的难题是：*这个请求来自哪里，我是否信任那个地方？* BeyondCorp 的回答是：你根本不应该信任那个地方。你对用户进行身份验证，检查设备状态，然后针对该特定请求做出访问决策。位置变成了众多信号之一，而不是最终裁决。 这种重新定义之所以有效，是因为主体是可读的（legible）。人类每天早上登录，携带一两台设备，以人类速度工作，并产生一连串系统可以进行推理的访问决策。我们围绕这种主体形态建立了一整个行业：单点登录、设备态势、条件访问、会话风险评分。 代理不具备这种形态。 一个代理服务可能运行许多任务。在本文中，代理是指一次任务级（task-scoped）的运行。我们用**任务执行图（task execution graph）**来指代属于该运行、并受相同能力上限和信任级别约束的所有工作。同一个运行框架去解决一个不同的任务、消费一个不同的事件、或按明天的计划运行时，会产生一个新的执行图。一条人类指令（*对账这两个分类账*、*处理隔夜警报*、*开一个修复此 Bug 的 Pull Request*）可以分派一个或多个这样的任务。每个任务可能需要访问数据库、源代码库、日志、工单系统、知识库、文档或电子表格。任务可能需要广泛的访问权限。它现在就需要，为这个任务而需要，并且理想情况下不会多出一秒钟。 代理必须拥有足以完成其任务的权限，且仅此而已。最小权限原则与访问控制本身一样古老。发生变化的是执行它的速度和频率。对于人类员工队伍来说，最小权限往往是一种每季度审查一次的策略。而对于大量短生命周期代理来说，它是一个实时运行并留下审计追踪的系统。 ## 为什么人类模型无法迁移 代理看起来像是服务账号或速度极快的用户。以下四个属性使得这两类控制措施都不适用。 **代理是短暂的，而凭证是持久的。** 服务账号是为长期运行的软件设计的：一个薪资系统，一个夜间批处理作业。它们通常带有长期有效的密钥、宽泛的权限范围，并且很少轮换。当应用于短暂存活的代理时，这些凭证的寿命超过了它们被签发时所服务的工作，并会残留在内存、日志或环境变量中，可能被重放。凭证的生命周期应当与任务的生命周期相匹配。对于代理来说，这通常只有几分钟。 **代理以机器速度行动。** 针对人类活动调优的异常检测、速率限制和数据丢失控制可能反应过慢。一个拥有数据库连接和出站网络路径的代理，可以在人类调优的控制措施完成采样之前，读取一张表并将其 POST 到外部端点。因此，预防性控制必须以内联方式、在行动发生的节点上运行。 **提示词（prompt）不是边界。** 团队通常告诉代理*不要访问生产环境*或*绝不向第三方发送数据*。这些指令有助于塑造行为，但它们并不强制执行访问控制。模型可能被其读取的数据中注入的内容所操纵，也可能自行产生不安全的行为。推断出的意图可以为风险决策提供信息，但攻击者可以通过同样的文本来塑造这一信号。强制执行应当属于中介工具调用的运行框架（harness），以及中介数据包的网络层。一个你能靠说话就绕过去的边界，并不是真正的边界。 **代理会在多个跳点（hop）之间组合权限。** 代理可以调用一个工具，而该工具又调用另一个代理，后者再代表最初的人类调用 API。在这条链的某个环节，“这是为谁做的、他们被允许做什么”的答案可能会消失。现有原语处理单跳委托的能力，比处理多跳或多个人类的组合要好得多。 ## 代理访问模型 代理访问模型以一个规则为起点：**不要信任运行本身。针对任务及其累积状态，对每一个动作进行授权。** BeyondCorp 从*网络*中移除了隐式信任。AAM 则从*任务执行图*中移除隐式信任。对一个动作的授权不会延续到下一个动作。每一个动作都根据三件事进行评估：代理是谁、它被授权执行什么任务、以及该执行图已经接触过哪些与策略相关的资源。这种累积状态只会减少执行图剩余的能力。 Google 的 *Beyond Zero* 也采用了相同的开局：将信任边界从应用程序缩小到单个动作，并以机器速度做出决策。Beyond Zero 在每次授权决策背后放置了一个推理引擎。AAM 则限定了该引擎必须判断的能力集合。这两种方法可以相互配合。对于跨越已声明中介边界的动作，AAM 会记录每次授权决策背后的代理、主体和任务。 AAM 有五个原则。 1. **凭证是短生命周期的，并且是绑定的。** 代理接收到的凭证是为该任务铸就的，并随任务一起过期。令牌是发送者约束的（sender-constrained），因此即使令牌被盗，没有运行框架持有的证明密钥也无法重放。 2. **强制执行存在于运行框架和网络之中，而非提示词之中。** 策略在实际发生工具调用和网络请求的地方应用。提示词是用来表达意图的地方，而绝不是用来实施边界的地方。 3. **人工监督是例外情况。** 审批仅保留给那些值得进行审批的决策。让一个人批准每一步，会导致疲劳和反射性点击。 4. **授权许可基于证据进行审查。** 直接捕获的活动可以显示某个任务模板过于宽泛或过于狭窄的地方。系统提出变更以供审查，而经过批准的变更将应用于未来的任务。它绝不会扩大当前正在运行的任务的权限。 5. **能力状态只朝一个方向移动。** 当已声明的受保护事件发生时，信任棘轮（Trust Ratchet）会按照策略移除任务执行图中的能力。被信任棘轮移除的权限，只有在新授权的任务中才能恢复。 ## 参考架构 该架构包含四个主动控制组件和两个支撑系统。主动控制组件治理任务。代理活动日志（Agent Activity Log）和授权审查循环（Grant Review Loop）则基于任务留下的证据进行运作。AAM 定义了这些组件如何组合在一起，以及每个组件必须保证什么。这是一个参考架构，而非线级（wire-level）规范。 ### 4.1 代理身份代理（Agent Identity Broker） 在分派时，**代理身份代理**签发一个短生命周期的、可验证的、且限定于该任务的凭证。该凭证的过期时间不晚于任务结束。 该凭证是*任务级*的：它编码了“这是代理 X，代表主体 H，执行任务 T”。它也是*发送者约束*的，绑定到由运行框架持有的证明密钥。仅凭泄露的令牌，没有该密钥就无法重放，而且模型永远不会收到这个密钥。 现有标准提供了这两种原语。**OAuth 2.0 Token Exchange（RFC 8693）** 定义了通过安全令牌服务（Security Token Service）进行的交换，并可以生成按受众（audience）、资源或权限范围收窄的令牌。授权服务器的策略决定了它签发什么。令牌的 `act` 声明标识当前的执行者，而嵌套的 `act` 声明可以保留先前的执行者以供归因。**DPoP（RFC 9449）** 将 OAuth 令牌绑定到客户端密钥，并要求在每个受保护请求上提供证明。该证明覆盖 HTTP 方法和目标 URI，但不覆盖请求体、查询参数或工具参数。因此，运行框架必须对一个不可变的请求表示进行授权，并执行同一个请求。 这两个标准都没有定义 AAM 的任务模板、信任棘轮状态或跨层强制执行。AAuth 草案 09 解决了代理到资源的身份与授权问题，包括每实例身份、可选任务（missions）、工具权限、审计和异步授权。它可能实现该模型的一部分，并且仍在演进中。AAM 依赖凭证的四个属性：短生命周期、任务级、发送者约束、可归因。它不依赖某个特定协议胜出。 ### 4.2 任务级访问引擎（Task-Scoped Access Engine） 凭证确立了代理是谁、正在执行哪个任务。**任务级访问引擎**则针对每个请求决定：*这个*身份是否可以对*这个*资源执行*这个*动作。它通过将任务本身作为决策的一等输入，扩展了 BeyondCorp 的访问控制引擎。 它的职责是让最小权限既成为默认值，也成为天花板。一个任务授权可能这样写：“代理 X，为任务 T，可以在接下来的十分钟内读取表 A、B 和 C。” 这就是授权包络（envelope）。未声明的动作一律拒绝。 这个包络从哪里来？任务的范围是在代理被分派时声明的，而不是由代理在运行时协商的。在常见情况下，一个人或代表人类常设权限的系统会一次性定义一个任务模板：“对账任务可以读取这三张表，并发布到该频道。” 每次分派都是对该模板的一次实例化。模板是配置的单元，因此策略的数量取决于不同任务的种类，而不是运行次数。在分派时，访问引擎将经批准的模板与发起主体和代理服务的权限取交集，然后应用资源所有者和租户策略。这个交集就是任务的能力上限。代理可以请求更少的权限，而信任棘轮可以移除能力。更广泛的权限则需要一个新授权的任务。 对于每个动作，适配器（adapter）构建并冻结完整的请求表示，包括操作、资源、影响范围的参数、租户和接收方。访问引擎根据当前能力上限对该表示进行授权，然后适配器执行同一个表示。凭证续期会重新验证原始上限和当前信任棘轮状态。它无法恢复已被移除的能力，也无法延长最大任务生命周期。 ### 4.3 中介层（Mediation Layer，运行框架与网络） **中介层**治理两个边界：运行框架暴露的工具路径，以及被强制经过部署网络边界的出站流量。 第一个是运行框架（harness），即代理工具调用的运行时中介。它通过已声明的工具路径拦截调用，根据任务策略对其进行检查，并发出强制执行事件，但受第 4.6 节所述收集缺口的影响。运行框架可以区分读取和更新，并约束影响范围的参数。MCP 通过定义的传输协议标准化了请求，并为 HTTP 传输提供了 OAuth 资源服务器边界。其授权层并未定义 AAM 所要求的逐工具或逐参数策略。运行框架或工具服务器必须强制执行这些策略。远程 MCP 服务器仍然是一个独立的强制执行边界，拥有自己的下游访问和出口路径。 第二个是网络层，即代理连接所经过的出站路径。如果代理仍然可以打开一个到互联网的任意套接字，那么一套被完美中介的工具调用就毫无意义。网络层控制决定哪些目的地和协议可以通过其路由的流量访问，包括来自子进程和委托运行时（delegated runtimes）的流量。网络通常能看到目的地和传输层属性。它只有在协议暴露了 HTTP 方法、租户、接收方或应用操作等信息时，或者流量终止于受信任的中介点时，才能强制执行这些约束。 运行框架只有在真正执行强制时才能被称为运行框架。它的默认行为是拒绝：一个工具调用之所以被允许，是因为任务级策略点名允许它，而不是因为代理请求了它。同样的纪律也适用于网络层。MCP 的逐步升级授权（step-up authorization）也保持在任务能力上限之内。范围挑战（scope challenge）不能恢复已被信任棘轮移除的能力，也不能为当前任务增加权限。 两个强制执行点的失败方式不同。一个利用运行框架漏洞的请求，仍然应当遇到网络策略的拦截。一个网络配置错误，也不应当授予工具访问权限。这两个实现应当尽可能独立失败，尽管它们共享任务策略和信任棘轮状态。该控制平面是一个共同的依赖项，必须默认失败关闭（fail closed）。 ### 4.4 信任棘轮（Trust Ratchet） **信任棘轮**使信任变得*有状态*。它的主要目的是限制数据外泄。“信任”是任务执行图仍然可以做什么的简写，而不是对模型意图或可靠性的判断。就像棘轮一样，在执行过程中，其能力状态只能收窄。 策略会预先声明激活棘轮的受保护事件、每次转换所施加的限制，以及必须遵守新状态的组件。一次受保护的读取可能会移除外部目的地，同时保留一个类型严格受限的内部输出。另一个任务可能会在某类查询之后收窄数据库范围。 一个执行图可以以受限状态开始。在凭证、工具或出口流量启用之前，分派策略会评估初始提示词、恢复的记忆和移交的输入。一个带有未知或未分类输入的任务，将以受限状态开始，或者默认失败关闭。 我们最初为人类构建数据丢失控制——人类以人的速度、人的数量泄露数据。而一个已经读取了系统记录（system of record）并保留出站路径的代理，可以以机器速度外泄数据。信任棘轮在释放敏感响应之前收窄该路径。“更窄”具体意味着什么，由策略指明，而不是留给代理或模型去解释。对于网络而言，可能是目的地白名单。对于数据而言，可能是更窄的资源或查询范围。这些轴（axes）是预先声明的，因此操作员可以清楚地看到每次转换会移除哪些能力。 并行工作使这不仅仅是简单的两状态转换。运行框架会持有响应，直到所有强制执行点都采用新状态。状态存储使用比较并交换（compare-and-set）或单一写入者来序列化更新。每个组件停止使用旧状态、清除缓存的决策，并确认新版本。运行框架取消或排空旧工作。网络强制执行关闭或重新授权持久连接。运行框架只有在所有确认都到达后才释放响应。任何冲突、超时、错误或缺失确认都会阻止响应。转换以失败关闭的方式完成。