企业官网建设流程全解析

• 应用安全

导读

本文基于 OWASP Cheat Sheet Series 仓库中的《Authorization Decisions & Output Handling》草案文档，系统讲解现代授权系统中"授权决策"与"决策结果输出处理"的完整技术脉络：从单次决策请求、批量请求等 PDP 调用机制，到输出数据基数（Output Data Cardinality）的三种层级，再到 PDP as Filter、Authorized Data Set、Authorization Filter 三大输出处理模式及其权衡，最后给出延迟、吞吐、缓存与降级策略等性能决策依据。读完本文，你将能够依据候选集规模、输出基数、PDP 类型（PBAC / ReBAC / NGAC）与延迟预算，为具体业务场景选型正确的授权输出处理方案。

授权请求的规范形式：从原子决策到授权集合

授权请求的规范形式是："主体 X 能否对客体 Z 执行动作 Y？"（Can subject X perform action Y on object Z?）。在最简单的情况下，这类请求的结果是一个原子化的 permit（允许）或 deny（拒绝）判定。

但在真实系统中，授权决策几乎从不局限于单一、孤立的检查。系统经常需要确定一个主体在一组资源上可以做什么——例如渲染一份过滤后的列表，或者决定为某个对象显示哪些操作按钮。这引出了一个超越单次 PDP 调用机制的问题：被授权的资源集合或动作集合是如何确定的，又由谁来负责确定？

历史上，PDP 只返回原子化决策。如果系统需要知道主体能访问众多对象中的哪些，PEP（Policy Enforcement Point，策略执行点）就必须先从数据源取出全部候选对象，再逐一（或以批处理方式减少往返）向 PDP 检查。这种方式可用，但会给数据源和 PEP 带来显著负载，且在大数据集下扩展性很差。

数据源 vs. PIP 的区分：本文所说的数据源是应用自身的存储——持有被过滤或查询资源的数据库、API 或服务。它们不同于 Policy Information Points（PIP，策略信息点）——PIP 提供的是作为策略评估输入的属性，相关内容在 Authorization Input Data Dimensions & Distribution 中专门讨论。

现代 PDP 实现——尤其是 ReBAC 和 NGAC 系统，以及策略语言表达力足够强的 PBAC 系统——可以直接返回结构化结果：一个计算出的允许资源集合，或者一个可由数据源自行应用的过滤表达式。这使"确定授权集合"的责任从 PEP 转移到了 PDP 或数据层，也让逐项迭代或批处理退化为兜底方案而非默认做法。

Authorization Request Mechanics：授权请求机制

单次决策请求（Single Decision Request）

一次单次决策请求就是向 PDP 发送的一条授权查询，返回一个**输出数据（output data）**对象。一个请求至少是三元组——(subject, action, object)——通常还是四元组：(subject, action, object, context)，其中 context 携带与决策相关的附加信息，如环境属性、风险信号或请求元数据（详见 Authorization Input Data Dimensions & Distribution 对输入数据的讨论）。

这一结构是刻意的：PEP 只负责提供"谁在请求、想做什么、对什么做"，而不提供"决策应该如何做出"的标准。PDP 中的策略逻辑完全负责评估这些标准。把授权标准泄漏进请求的做法——例如直接传角色名或权限标志——属于反模式，因为它把 PEP 与策略内部实现耦合起来，破坏了让授权体系可维护的关注点分离原则。

PDP 返回的输出数据可能是简单的 permit/deny、结构化结果或列表——具体取决于策略逻辑产生什么以及 PDP 支持什么。

批量请求（Batch Request）

批量请求把多条独立的单次决策请求打包进一次 PDP 调用，每次查询各自返回一个输出数据对象。它是调用层面的优化手段，用于减少跨多次检查的往返次数与序列化开销。批量调用典型用于两种场景：

• 一个对象的多个动作：PEP 需要知道主体能对某个特定资源执行哪些动作——例如决定是否渲染"读取 / 编辑 / 删除"按钮。与其发三次独立请求，不如打包成一次调用。
• 一个动作作用于已知且有界的候选集：PEP 已经持有一小批对象，需要对每个对象做同样的动作检查——例如过滤一小段搜索结果。与其逐条迭代调用，不如一次性发出所有检查。

即使有了批处理，PEP 仍须先取得候选集，而且当输出数据基数很高或事先未知时，批处理也无济于事。

Output Data Cardinality：输出数据基数

输出数据基数描述 PDP 返回的决策对象的结构与规模。它由策略逻辑定义，而策略逻辑又反映消费方应用的需求。常见的三种输出基数层级：

高输出基数往往需要分页（pagination）、流式（streaming）、查询改写（query rewriting），或者把授权逻辑进一步下推到靠近数据源的位置。这直接决定了本文下一节三种模式各自的适用边界。

Policy Output Data Handling Patterns：策略输出数据处理模式

以下模式描述了当决策涉及一组资源而非单个对象时，系统如何处理授权。它们的差异点在于：授权集合在哪里被确定（PEP、PDP 还是数据源），以及 PDP 返回什么作为结果。

模式一：PDP as Filter（暴力查找）

PEP 先从数据源取出所有可能相关的数据，再对每一项向 PDP 发起检查——通过单次决策请求，或在受支持时通过批量请求。被允许的项进入最终结果。

优点（Pros）

• 实现简单。
• 兼容任何类型的 PDP。
• 易于调试与监控。

缺点（Cons）

• 候选集大时延迟高、扩展性差（PDP 调用被反复发起）。
• 取回的数据超出所需，资源消耗增加。
• 将 PEP 与服务业务逻辑紧密耦合。
• 使 PEP 外部化变得困难甚至不可能。
• 策略变更可能需要服务重新部署或重构。

典型适用场景：候选集较小、且 PDP 不支持 Authorized Data Set 与 Authorization Filter 时。

模式二：Authorized Data Set（授权数据集）

PEP 向 PDP 发起单次请求，PDP 直接返回主体可访问的完整资源集合——例如一份被允许的对象 ID 列表。PDP 基于策略逻辑与可用属性构造该结果。

优点（Pros）

• 无需事先取回候选集。
• 一次返回全部结果，减少往返次数。
• 简化 PEP 逻辑——确定授权集合的复杂度由 PDP 承担。
• 非常适合能利用内部关系图数据计算允许资源的 ReBAC / NGAC PDP。

缺点（Cons）

• 将 PEP 外部化（例如外部代理）仅在输出数据集为低到中基数时才可行。
• 可能使数据访问的错误处理与监控变复杂。
• 更大的输出数据集需要分页或流式处理。
• 对采用 PBAC 方法的 PDP，会导致策略复杂化。
• 并非每个 PBAC PDP 实现都支持。

典型适用场景：低到中输出基数，尤其是 PDP 能高效地从内部关系或图数据计算允许资源时。

模式三：Authorization Filter（授权过滤器）

PEP 调用 PDP，PDP 返回一个过滤表达式——例如查询谓词或基于属性的条件。PEP 在数据检索时应用该过滤器，因此只有被允许的数据才会被取回。

优点（Pros）

• 无需事先取回候选集。
• 对大数据集高度高效——过滤发生在数据源侧。
• 高输出基数下扩展性良好。
• 降低 PDP 负载。
• 支持灵活的 PEP 部署位置——作为服务的一部分或外部代理。

缺点（Cons）

• 并非每个 PDP 都支持（ReBAC 与 NGAC PDP 完全不支持）。
• 要求 PEP 或数据访问层正确应用返回的过滤器。
• 可能使访问决策的错误处理、监控与诊断变复杂。

典型适用场景：高输出基数、资源可查询，且授权约束可被翻译为数据源过滤器时。

模式选型：决策责任从 PEP 向 PDP/数据层转移

三种模式本质上代表"确定授权集合"这一职责的三种落点：

这一演变在架构层面的意义在于：它呼应了 OWASP Cheat Sheet Series 中 Authorization Patterns 讨论的 PDP 部署选择（嵌入式库、Sidecar 进程或外部 PDP 服务）——嵌入式与 sidecar 型 PDP 通常更擅长在本地计算授权集合，而外部 PDP 更适合配合过滤器表达式或批量调用。同时，Authorization_Cheat_Sheet 提醒我们，无论选择哪种输出处理方式，都必须坚持"Deny by Default"（默认拒绝）与"Validate the Permissions on Every Request"（每个请求都校验权限）的安全底线——过滤/计算只是执行方式，不改变安全原则。

Interaction & Output Handling — Quick Reference（快速参考）

Performance Considerations：性能考量

性能在授权系统设计中至关重要——尤其在延迟敏感的环境里。授权决策会消耗响应产生前延迟预算的一部分；从用户视角看，**TTFB（Time to First Byte）**是最能反映响应性的指标之一。以下因素对评估集成与输出处理选型最为关键。输入侧的绩效因素（如数据检索延迟、PDP 存储需求、同步开销）见 Authorization Input Data Dimensions & Distribution。

• 策略评估延迟（Policy evaluation latency）：PDP 计算一次决策所需时间。取决于策略的数量与复杂度、被评估的输入数据量，以及 PDP 是否必须在内部枚举或过滤大规模结果集。
• 策略输出处理（Policy output handling）：增加与输出基数成正比的工作量。所选输出处理模式会影响处理和应用结果所需的时间。
• PDP 集成开销（PDP integration overhead）：涵盖每次 PDP 调用的网络延迟、TLS 握手、DNS 解析与序列化成本。协议选择（如 HTTP/1.1 vs HTTP/2 vs gRPC）会进一步影响此开销。进程内 PDP 可最小化该开销，但可能增加本地资源争用。对于每个请求发起多次 PDP 调用的模式（如不带批处理的 PDP as Filter），此开销会成倍放大；批量请求可直接削减这种倍增效应。
• 运行时资源争用（Runtime resource contention）：当 PDP 与边缘组件、网关或应用服务共置时尤其突出（"Busy Neighbor"效应）。PDP 通常是 CPU 与内存密集型组件。共享计算资源若无隔离，会同时拖累 PDP 与宿主组件的吞吐。这一点在将 PDP 集成进边缘组件（嵌入式或 sidecar）时尤为相关——边缘组件往往为高 IOPS 吞吐而优化，此时嵌入 PDP 就引入了 CPU 密集的策略评估与 I/O 密集的请求处理之间的取舍。
• 缓存与记忆化（Caching and memoization）：可显著降低决策延迟——许多 PDP 支持对确定性输入的评估结果缓存。这些优化可降低延迟，但可能导致过期决策，需要稳健的缓存失效逻辑。
• 降级策略与超时（Fallback strategies and timeouts）：决定 PDP 缓慢或不可用时系统的行为。fail-closed（关闭时拒绝）、fail-open（关闭时放行）与优雅降级的选择，同时影响感知性能与安全态势。

Performance Quick Reference（性能速查表）

与 OWASP Cheat Sheet Series 其他主题的衔接

本主题是 OWASP Cheat Sheet Series 授权体系的一环，可与仓库内其他文档配合阅读，形成完整决策链：

• 输入侧：Authorization Input Data Dimensions & Distribution 定义了输入数据的本地性（Locality）、基数（Cardinality）与新鲜度（Freshness），并给出 On-Demand Data Pull、Out-of-Band Data Push、Request-Time Data Injection、Embedded Data 四种输入数据分发策略——输入数据如何到达 PDP 直接影响输出处理模式与缓存/失效策略的选择。
• 策略侧：Authorization Policy Dimensions & Distribution 讨论策略所有权（Microservice / Domain / Central）与策略变更延迟，决定策略是随 PDP 嵌入发布还是带外推送——这与输出处理中"策略变更是否需要重新部署服务"直接相关。
• 架构侧：Authorization Patterns 详细对比分散式服务级、集中式服务级、边缘级（经典/现代）授权模式及 PDP 部署选项（嵌入式 / Sidecar / 外部），是选择 Remote PDP 还是 In-process PDP 等性能决策的架构前提。
• 基础原则：Authorization_Cheat_Sheet 提供"最小权限""默认拒绝""每次请求校验""优先 ABAC/ReBAC 而非 RBAC"等基础安全原则，为所有授权模式提供安全底线。

选择授权输出处理模式没有放之四海而皆准的答案：最终决策取决于 PDP 类型（PBAC / ReBAC / NGAC）、输出基数、延迟预算、弹性要求、存储约束与治理边界。务实的最佳实践是：小候选集用 PDP as Filter，低/中基数授权集合用 Authorized Data Set，高基数可查询资源用 Authorization Filter，并在所有场景下配合批量请求与合理缓存策略控制延迟。

• 应用安全