最佳实践

本节列出了本指南中的一些高级要点。有关每点的详细讨论，请点击相应章节的链接。

选择适用于您的应用程序的访问控制模型

本指南讨论了几种访问控制模型。根据您的应用程序和业务需求，您应该选择适合自己的型号。考虑如何使用这些模型来满足您的访问控制需求，以及您的访问控制需求可能如何演变，这需要对所选方法进行更改。

实施 PDP

政策决策点 (PDP) 可以描述为策略或规则引擎。此组件负责应用策略或规则，并返回是否允许特定访问的决定。PDP 允许将应用程序代码中的授权逻辑转移到单独的系统中。这可以简化应用程序代码。它还提供了一个 easy-to-use等性接口，用于为微服务 APIs、前端后端 (BFF) 层或任何其他应用程序组件做出授权决策。PDP 可用于在整个应用程序中一致地强制执行租赁要求。

PEPs 为应用程序中的每个 API 实现

实施策略实施点 (PEP) 需要确定应在应用程序中何处实施访问控制。首先，在应用程序中找到可以合并的要点 PEPs。在决定添加位置时，请考虑以下原则 PEPs：

如果应用程序公开了 API，则应对该API进行授权和访问控制。

考虑使用 Amazon 验证权限或 OPA 作为您的 PDP 的策略引擎

与自定义策略引擎相比，Amazon 验证权限具有优势。它是一项可扩展、精细的权限管理和授权服务，适用于您构建的应用程序。它支持使用高级声明性开源语言 Cedar 编写策略。因此，与实施自己的解决方案相比，使用已验证权限实现策略引擎所需的开发工作更少。此外，经过验证的权限是完全托管的，因此您不必管理底层基础架构。

与自定义策略引擎相比，开放策略代理 (OPA) 具有优势。OPA 及其对 Rego 的策略评估提供了一个灵活的预建策略引擎，支持使用高级声明性语言编写策略。这使得实施策略引擎所需的工作量大大低于构建自己的解决方案。此外，OPA 正在迅速成为一种备受支持的授权标准。

为 OPA DevOps、监控和日志实现控制平面

由于 OPA 不提供通过源代码控制更新和跟踪授权逻辑更改的方法，因此我们建议您实现控制平面来执行这些功能。这将允许更轻松地将更新分发给 OPA 代理，特别是在 OPA 在分布式系统中运行时，这将减轻使用 OPA 的管理负担。此外，控制平面还可用于收集日志以进行聚合和监控 OPA 代理的状态。

在 “已验证权限” 中配置日志记录和可观察性功能

通过验证的权限，可以轻松访问可观察性功能。您可以将该服务配置为记录所有访问尝试 AWS CloudTrail、Amazon CloudWatch 日志组、S3 存储桶或 Amazon Data Firehose 传输流，从而能够快速响应安全事件和审计请求。此外，您可以通过监控服务的运行状况 AWS Health Dashboard。由于 Verified Permissions 是一项托管服务 AWS，因此其运行状况由维护，您可以使用其他 AWS 托管服务来配置其可观察性功能。

使用 CI/CD 管道配置和更新已验证权限中的策略存储和策略

Verified Permissions 是一项托管服务，因此您无需管理、配置或维护控制平面或代理即可执行更新。但是，我们仍然建议您使用持续集成和持续部署 (CI/CD) 管道来管理已验证权限策略存储的部署以及使用软件开发工具包的策略更新。 AWS当您更改已验证权限资源时，这项工作可以省去手动操作并降低操作员出错的可能性。

确定授权决策是否需要外部数据，然后选择适合该数据的模型

如果 PDP 可以仅基于 JSON Web Token (JWT) 中包含的数据做出授权决策，则通常无需导入外部数据来帮助做出这些决策。如果您使用已验证权限或 OPA 作为 PDP，它也可以接受作为请求的一部分传递的其他输入，即使这些数据未包含在 JWT 中。对于已验证的权限，您可以为其他数据使用上下文参数。对于 OPA，您可以使用 JSON 数据作为重载输入。如果您使用 JWT，则上下文或重载输入法通常比在其他来源中维护外部数据容易得多。如果需要更复杂的外部数据来做出授权决策，OPA 提供了几种检索外部数据的模型，而且 Verified Permissions 可以通过使用授权服务引用外部来源来补充其授权请求中的数据。