Authorization Policy and Data Distribution Cheat Sheet / 授权策略和数据分发速查表

Introduction / 介绍

An authorization decision is only as reliable as its policy and input data. A Policy Decision Point (PDP) evaluates rules using attributes supplied by a Policy Enforcement Point (PEP) or an authoritative Policy Information Point (PIP). OPA's external data guidance describes common ways to deliver those inputs. See Authorization Patterns for component placement.

授权决策的可靠性仅取决于其策略和输入数据。策略决策点（PDP）使用由策略执行点（PEP）或权威的策略信息点（PIP）提供的属性来评估规则。OPA的外部数据指南描述了传递这些输入的常见方式。参见授权模式以了解组件放置。

Define Ownership and Freshness Requirements / 定义所有权和新鲜度要求

Record who may change each policy and attribute, which service is authoritative for it, and the maximum delay before a change must affect decisions. Distinguish policy changes, such as a new restriction, from data changes, such as revoking a user's membership. Neither organizational ownership nor update frequency determines acceptable delay: a central policy can require an emergency update, while another can have a scheduled effective date.

记录谁可以更改每项策略和属性，哪个服务对此具有权威性，以及更改必须影响决策前的最大延迟。区分策略更改，如新的限制，与数据更改，如撤销用户的会员资格。组织所有权或更新频率并不决定可接受的延迟：中央策略可以要求紧急更新，而另一个则可以有一个计划的生效日期。

Choose delivery against those requirements. OPA bundles can carry both policies and data, but distribution is eventually consistent. A successful publication is not proof that every PDP has activated the update.

根据这些要求选择交付方式。OPA捆绑包可以携带策略和数据，但最终是一致的。成功的发布并不能证明每个PDP都已激活更新。

Requirement / 需求	Suitable starting point / 合适的起点	Security condition / 安全条件
Emergency restriction or revocation 紧急限制或撤销	Dynamic updates or authoritative lookup 动态更新或权威查找	Measure the propagation bound and deny affected operations when it cannot be met 测量传播边界，当无法满足时拒绝受影响操作
Scheduled, stable rules 计划内稳定规则	Versioned deployment or dynamic distribution 版本化部署或动态分发	Activate the required revision before its effective deadline 在其生效截止日期前激活所需修订版
Frequently changing resource or relationship data 频繁变化的资源或关系数据	Synchronization or lookup from its authoritative source 从其权威源进行同步或查找	Account for replication lag and cached decisions 考虑复制延迟和缓存决策
Request-specific attributes 请求特定的属性	Validated context passed by the PEP 由PEP传递的验证上下文	Authenticate the PEP and establish where each security-relevant value came from 验证PEP并确定每个与安全相关的值来源

Deliver Policies and Data / 交付策略和数据

A Policy Administration Point (PAP) manages policy changes. Distribute approved policies independently of application releases when restrictions must take effect sooner than a deployment can reliably complete. Delivery may use push or pull; OPA bundle downloads are an example of pull-based updates outside the decision request. Embedding policies in a release is suitable only when its deployment process meets the required update deadline.

策略管理点（PAP）管理策略更改。当限制必须比部署可靠地完成更早生效时，独立于应用程序发布分发批准的策略。交付可以使用推送或拉取；OPA捆绑包下载是决策请求之外的基于拉取的更新的示例。将策略嵌入到发布中仅在其部署过程满足所需的更新截止日期时适用。

For input data, select among these approaches using the source's consistency guarantees and the PDP's actual capabilities. Model names alone do not establish which mechanisms a product supports.

对于输入数据，根据源的一致性保证和PDP的实际能力选择这些方法。仅模型名称本身并不能确定产品支持哪些机制。

Lookup During Evaluation / 评估期间查找

The PDP retrieves required attributes from an authoritative PIP.

PDP从权威的PIP检索所需属性。

Use this when the source can satisfy the decision's availability and freshness requirements. A lookup does not guarantee current data if the source, replica, or intermediate cache is stale. Deny affected operations when a required attribute cannot be obtained reliably.

当源可以满足决策的可用性和新鲜度要求时使用此方法。如果源、副本或中间缓存已过时，查找不能保证当前数据。当无法可靠地获取所需属性时，拒绝受影响的操作。

Replicated Data / 复制数据

Updates reach a PDP's local data store before evaluation.

更新在评估之前达到PDP的本地数据存储。

This removes the PIP from the immediate request path but creates a revocation delay. Monitor synchronization progress and handle missed, repeated, and reordered updates. Do not describe local availability as a freshness guarantee.

这消除了PIP从直接请求路径，但创建了撤销延迟。监控同步进度并处理遗漏、重复和重新排序的更新。不要将本地可用性描述为新鲜度保证。

Request-Time Data / 请求时间数据

The PEP collects attributes and includes them in its decision request.

PEP 收集属性并将它们包含在其决策请求中。

The AuthZEN security considerations address PEP authentication and trust. An authenticated PEP must still derive user identity, roles, ownership, and tenant membership from trusted sources; copying values from an end user request does not make them authoritative. Validate resource identifiers against the actual target and distinguish user-supplied context from verified attributes.

AuthZEN 安全考虑因素（https://openid.net/specs/authorization-api-1_0.html#section-11）涵盖了PEP身份验证和信任。经过身份验证的PEP仍需从可信来源推导用户身份、角色、所有权和租户成员资格；从终端用户请求中复制值并不能使其具有权威性。验证资源标识符与实际目标的一致性，并区分用户提供的上下文与验证属性。

Embedded Data / 嵌入式数据

Stable data is packaged with the PDP or policy release.

稳定数据与PDP或策略发布一起打包。

Use this only when changing the data through a deployment meets its freshness requirement. Avoid embedding mutable account status or revocation data in releases that cannot update promptly.

仅在通过部署更改数据以满足其新鲜度要求时使用。避免在无法及时更新的发布中嵌入可变账户状态或撤销数据。

Protect Distribution and Administration / 保护分发和管理

Protect network-exposed decision APIs and the APIs that read or modify policy and data. Authenticate PEPs and administrators, restrict each to the tenants and operations they need, and prevent service teams from replacing organization-wide restrictions. OPA's API security documentation describes authentication and authorization for these interfaces. An in-process PDP shares the application's trust boundary; it does not require a separate network authentication exchange.

保护网络暴露的决策API以及读取或修改策略和数据的API。对PEP和管理员进行身份验证，限制每个用户只能访问他们需要的租户和操作，并防止服务团队替换组织范围内的限制。OPA的API安全文档描述了这些接口的认证和授权。进程中的PDP共享应用程序的信任边界；它不需要单独的网络身份验证交换。

Verify policy artifacts before activation. For bundles, require a signature from a configured trusted publisher and verify all covered files; OPA documents the verification and activation rules. Protect transport and signing keys as well. A valid signature proves origin and integrity, not that a policy is correct or current.

在激活策略之前进行验证。对于捆绑包，要求配置的受信任发布者提供的签名，并验证所有受覆盖的文件；OPA记录了验证和激活规则。同时也要保护传输和签名密钥。有效的签名证明了来源和完整性，而不是策略是否正确或最新。

Pin deployments to reviewed policy and schema versions, and record which revision each PDP actually activates. Reject unexpected or obsolete revisions; allow a rollback only through the reviewed release process. Test that service-owned rules cannot override mandatory restrictions. These controls are needed for embedded releases as well as dynamic delivery.

将部署与已审查的策略和模式版本绑定，并记录每个PDP实际激活的修订版本。拒绝意外或过时的修订版本；仅允许通过审查的发布流程进行回滚。测试服务拥有的规则不能覆盖强制限制。这些控制对于嵌入式发布以及动态交付都是必要的。

Freshness and Outages / 新鲜度和中断

Distinguish loss of the policy distribution service from loss of a usable authorization decision. OPA retains its existing bundle when a new bundle fails verification; this preserves availability but does not establish that the old bundle is still fresh enough.

区分策略分发服务丢失与可用授权决策丢失。当新的包验证失败时，OPA保留其现有的包；这保留了可用性，但并不能确定旧包仍然足够新鲜。

• Continue evaluating a previously verified policy only while its policy, data, and any decision-cache freshness requirements remain satisfied.
  中文：仅在策略、数据和任何决策缓存新鲜度要求仍然满足的情况下，继续评估先前验证的策略。
• At startup, do not serve protected operations until the required policy and data are available and valid.
  中文：在启动时，在所需的策略和数据可用且有效之前，不要提供受保护的操作。
• Deny affected operations when required inputs are missing, invalid, or older than the allowed bound. Do not turn a timeout or undefined result into a permit; follow Deny by Default.
  中文：当所需输入缺失、无效或超过允许的上限时，拒绝受影响的操作。不要将超时或未定义的结果变成允许；遵循默认拒绝。
• Exercise revocation, delayed updates, invalid artifacts, unavailable sources, and recovery. Verify the effective decision at the PEP, not just delivery to the PDP.
  中文：执行撤销、延迟更新、无效工件、不可用来源和恢复。在PEP处验证有效决策，而不仅仅是PDP的交付。

Prefer reviewed, versioned policies and an explicit freshness budget for each security-relevant input. Select the simplest delivery mechanism that meets those limits and stop granting affected access when it cannot.

优先选择已审查、版本化的策略以及每个安全相关输入的显式新鲜度预算。选择满足这些限制的最简单交付机制，并在无法授予受影响访问时停止授权。

References / 参考

• OPA external data integration) （OPA外部数据集成）
• OPA policy and data bundles) （OPA策略和数据包）
• OpenID AuthZEN security considerations) （OpenID AuthZEN安全考虑）