本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # Amazon Verified Permissions 策略存储 策略存储是策略和策略模板的容器。在每个策略存储中，您可以创建一个架构，用于验证添加到策略存储中的策略。此外，您还可以开启策略验证。如果在启用策略验证的情况下向策略存储中添加策略，则策略中定义的实体类型、常见类型和操作将根据架构进行验证，无效策略将被拒绝。 删除保护可防止意外删除策略存储。通过创建的所有新策略存储都启用了删除保护 AWS 管理控制台。相比之下，通过 API 或 SDK 调用创建的所有策略存储都将禁用该功能。 我们建议为每个应用程序创建一个策略存储，或者针对多租户应用程序为每个租户创建一个策略存储。在发出[授权请求](terminology.md#term-authorization-request)时，必须指定一个策略存储。您也可以创建策略存储别名，以便通过友好名称来引用您的策略存储。有关更多信息，请参阅 [Amazon 已验证权限策略存储别名](policy-store-aliases.md)。 我们建议将*命名空间*用于策略存储中的 Cedar 实体，以防止产生歧义。命名空间是类型的字符串前缀，由一对冒号（`::`）作为分隔符进行分隔。例如 `MyApplicationNamespace::exampleType`。Verified Permissions 支持每个策略存储库使用一个命名空间。当你使用多个相似的应用程序时，这些命名空间有助于保持一切顺畅。例如，在多租户应用程序中，使用命名空间将租户名称附加到架构中定义的类型后，将使它们与其他租户使用的类似类型区分开来。在查看授权请求的日志时，您可以轻松识别处理授权请求的租户。有关更多信息，请参阅《Cedar 策略语言参考指南》中的[命名空间](https://docs.cedarpolicy.com/overview/terminology.html#term-namespaces)**。 **Topics** + [创建 Verified Permissions 策略存储](policy-stores-create.md) + [与 API 关联的策略存储](policy-stores-api-userpool.md) + [删除策略存储](policy-stores-delete.md) # 创建 Verified Permissions 策略存储 您可以使用以下方法创建策略存储： + **按照指导设置进行**操作-在创建第一个策略之前，您将定义具有有效操作的资源类型和委托人类型。 + **使用 API Gateway 和身份源进行设置 — 使用身份**提供商 (IdP) 登录的用户以及通过 Amazon API Gateway API 登录的用户定义您的主体实体，以及通过 Amazon API Gateway API 进行操作和资源实体。如果您希望您的应用程序使用用户的群组成员资格或其他属性来授权 API 请求，我们建议您使用此选项。 + **从示例策略存储区开始**-选择预定义的示例项目策略存储库。如果您正在学习 Verified Permissions 并想要查看和测试示例策略，我们建议您使用此选项。 + **创建空策略存储库**-您将自己定义架构和所有访问策略。如果您已经熟悉如何配置策略存储，我们建议您使用此选项。 ------ #### [ Guided setup ] **要使用**引导式设置**配置方法创建策略存储，请按以下步骤操作：** 引导式设置向导将引导您完成创建策略存储第一次迭代的过程。您将为第一个资源类型创建架构，描述适用于该资源类型的操作以及您为其授予权限的主体类型。然后，您将创建第一个策略。完成此向导后，您将能够向策略存储中添加内容，扩展架构以描述其他资源和主体类型，以及创建其他策略和模板。 1. 在[已验证的权限控制台](https://console.aws.amazon.com/verifiedpermissions)中，选择**创建新的策略存储**。 1. 在 “**开始选项**” 部分中，选择**引导式设置**。 1. 输入**策略存储描述**。此文本可以是任何适合您组织的文本，作为对当前策略库功能的友好参考，例如*天气更新 Web 应用程序*。 1. 在**详细信息**部分中，输入**架构的命名空间**。有关命名空间的更多信息，请参阅。[命名空间定义](terminology-differences-avp-cedar.md#differences-namespaces) 1. 选择**下一步**。 1. 在**资源类型**窗口中，输入资源类型的名称。例如，`currentTemperature`可能是*天气更新 Web 应用程序*的资源。 1. （可选）选择**添加属性**，添加资源属性。输入**属性名称**，然后为资源的每个属性选择一个**属性类型**。选择每个属性是否为**必填项**。例如，`temperatureFormat`可以是`currentTemperature`资源的属性，可以是华氏度或摄氏度。要删除已为该资源类型添加的属性，请选择该属性旁边的**删除**。 1. 在**操作**字段中，输入要为指定的资源类型授权的操作。要为该资源类型添加其他操作，请选择**添加操作**。例如，`viewTemperature`可能是*天气更新 Web 应用程序*中的一个操作。要删除已为该资源类型添加的操作，请选择该操作旁边的**删除**。 1. 在**主体类型的名称**字段中，输入将对您的资源类型使用指定操作的主体类型的名称。默认情况下，**用户**已添加到此字段，但可以替换。 1. 选择**下一步**。 1. 在**主体类型**窗口中，为您的主体类型选择身份来源。 + 如果主体的 ID 和属性将由您的 Verified Permissions 应用程序直接提供，请选择**自定义**。要添加主体属性，请选择**添加属性**。根据架构验证策略时，Verified Permissions 会使用指定的属性值。要移除已为主体类型添加的属性，请选择该属性旁边的**移除**。 + 如果委**托人的 ID 和属性将由生成的 ID 或访问令牌提供，请选择 Cognito 用户池**。 Amazon Cognito选择**连接用户群体**。选择**AWS 区域**并键入要连接的 Amazon Cognito 用户池的用户池 **ID**。选择**连接**。有关更多信息，请参阅《Amazon Cognito 开发人员指南》中的[使用 Amazon Verified Permissions 进行授权](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html)**。 + 如果委托人的 ID 和属性将从**外部 OIDC 提供商**生成的 ID and/or 访问令牌中提取，请选择外部 OIDC 提供商，然后添加提供商和令牌详细信息。 1. 选择**下一步**。 1. 在**策略详细信息**部分中，为您的第一个 Cedar 策略输入可选的**策略描述**。 1. 在**主体范围**字段中，选择将从策略中获得权限的主体。 + 选择**特定主体**，将策略应用于特定主体。在**允许执行操作的主体**字段中选择该主体，然后为该主体输入一个实体标识符。例如，`user-id`可以是*天气更新 Web 应用程序*中的实体标识符。 **注意** 如果您使用的是 Amazon Cognito，则实体标识符的格式必须为`|`。 + 选择**所有主体**，将该策略应用于策略存储中的所有主体。 1. 在**资源范围**字段中，选择授权指定主体对哪些资源执行操作。 + 选择**特定资源**，将该策略应用于特定资源。在**此策略适用的资源**字段中选择该资源，然后为该资源输入一个实体标识符。例如，`temperature-id`可以是*天气更新 Web 应用程序*中的实体标识符。 + 选择**所有资源**，将该策略应用于策略存储中的所有资源。 1. 在**操作范围**字段中，选择授权指定主体执行的操作。 + 选择**特定操作集合**，将该策略应用于特定操作。在**此策略适用的操作**字段中，选中操作旁边的复选框。 + 选择**所有操作**，将该策略应用于策略存储中的所有操作。 1. 在**策略预览**部分中查看该策略。选择**创建策略存储**。 ------ #### [ Set up with API Gateway and an identity source ] **使用**设置方式 API Gateway 和身份源**配置方法创建策略存储** 该 API Gateway 选项使用经过 APIs 验证的权限策略来保护，该策略旨在根据用户的群组或*角色*做出授权决定。此选项构建一个策略存储库，用于测试身份源组的授权，以及使用 Lambda 授权方的 API。 IdP 中的用户及其群组要么成为您的委托人（ID 令牌），要么成为您的上下文（访问令牌）。 API Gateway API 中的方法和路径将成为您的策略授权的操作。您的应用程序将成为资源。作为此工作流程的结果，已验证权限将创建策略存储、Lambda 函数和 API Lambda 授权方。完成此工作流程后，您必须为您的 API 分配 Lambda [授权](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html)方。 1. 在[已验证的权限控制台](https://console.aws.amazon.com/verifiedpermissions)中，选择**创建新的策略存储**。 1. 在 “**开始选项**” 部分，选择 “**设置方式 API Gateway 和身份源**”，然后选择 “**下一步**”。 1. 在 “**导入资源和操作**” 步骤**的 API** 下，选择一个 API，该API将用作策略存储资源和操作的模型。 1. 从 API 中配置的阶段中选择**部署**阶段，然后选择**导入 API**。有关 API 阶段的更多信息，请参阅 [Amazon API Gateway 开发者指南中的为 REST API 设置阶段](https://docs.aws.amazon.com/apigateway/latest/developerguide/set-up-stages.html)。 1. 预览**导入的资源和操作地图**。 1. 要更新资源或操作，请在 API Gateway 控制台中修改您的 API 路径或方法，然后选择**导入 API** 以查看更新。 1. 如果您对自己的选择感到满意，请选择 “**下一步**”。 1. 在**身份来源**中，选择**身份提供者类型**。你可以选择 Amazon Cognito 用户池或 OpenID Connect (OIDC) IdP 类型。 1. 如果你选择 **Amazon Cognito**： 1. 选择 AWS 区域 与 AWS 账户 您的策略存储区相同的用户池。 1. 选择要**传递给要提交授权的 API 的令牌类型**。两种令牌类型都包含用户组，这是这种与 API 关联的授权模型的基础。 1. 在**应用程序客户端验证**下，您可以将策略存储的范围限制为多租户用户池中的一部分 Amazon Cognito 应用程序客户端。要要求该用户使用用户池中的一个或多个指定应用程序客户端进行身份验证，请选择 “**仅接受预期应用程序客户端的令牌**” IDs。要接受任何通过用户池进行身份验证的用户，请选择**不验证应用程序客户端 IDs**。 1. 选择**下一步**。 1. 如果您选择**外部 OIDC** 提供商： 1. 在**发卡机构 URL 中，输入您的 OIDC 发行**人的 URL。例如，这是提供授权服务器、签名密钥以及有关您的提供商的其他信息的服务端点`https://auth.example.com`。您的发卡机构 URL 必须托管 OIDC 发现文档，网址为。`/.well-known/openid-configuration` 1. 在**令牌类型**中，选择您希望您的应用程序提交以进行授权的 OIDC JWT 类型。有关更多信息，请参阅[将 Amazon Cognito 令牌映射到架构和将](cognito-map-token-to-schema.md) [OIDC 令牌映射到](oidc-map-token-to-schema.md)架构。 1. （可选）在**令牌声明-可选**中，选择**添加令牌声明**，输入令牌的名称，然后选择值类型。 1. 在**用户和群组令牌声明**中，执行以下操作： 1. 在身份源的**令牌中输入用户声明名称**。通常`sub`，这是来自您的身份证或访问令牌的声明，该令牌包含待评估实体的唯一标识符。来自连接的 OIDC IdP 的身份将映射到您的策略存储中的用户类型。 1. 在身份源的**令牌中输入群组声明名称**。通常`groups`，这是来自您的身份证或访问令牌的声明，其中包含用户的群组列表。您的策略存储将根据群组成员资格对请求进行授权。 1. 在**受众验证**中，选择`Add value`并添加您希望策略商店在授权请求中接受的值。 1. 选择**下一步**。 1. 如果您选择 **Amazon Cognito**，“已验证权限” 会查询您的用户池中的群组。对于 OIDC 提供商，请手动输入组名。“**将操作分配给群组**” 步骤可为您的策略存储创建允许群组成员执行操作的策略。 1. 选择或添加要包含在策略中的群组。 1. 为您选择的每个群组分配操作。 1. 选择**下一步**。 1. 在 Depl **oy 应用程序集成**中，选择是要稍后手动附加 Lambda 授权者，还是想让已验证的权限立即为您执行此操作，并查看已验证权限将为创建策略存储和 Lambda 授权者而采取的步骤。 1. 准备好创建新资源时，选择**创建策略存储**。 1. 在浏览器中保持 “**策略存储状态”** 步骤处于打开状态，以通过已验证的权限监控资源创建的进度。 1. 一段时间后（通常为大约一个小时），或者当 D **eploy Lambda 授权**方步骤显示**成功**时，如果您选择手动连接授权方，请配置您的授权方。 经过验证的权限将在您的 API 中创建一个 Lambda 函数和一个 Lambda 授权者。选择 “**打开 API**” 以导航到您的 API。 *要了解如何分配 Lambda 授权方，请参阅 A [mazon API Gateway 开发者指南中的使用 API Gateway Lambda 授权](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html)方。* 1. 导航到您的 API 的**授权方**，并记下已验证权限创建的授权方的名称。 1. 导航到 “**资源**”，然后在 API 中选择一种顶级方法。 1. 在 “**方法请求设置**” 下选择 “编辑**”**。 1. 将**授权**者设置为您之前记下的授权者名称。 1. 展开 **HTTP 请求标头**，输入**名称**或`AUTHORIZATION`，然后选择**必需**。 1. 部署 API 阶段。 1. **保存**您的更改。 1. 使用您在**选择身份来源步骤中选择**的**令牌类型的**用户池令牌来测试您的授权方。有关用户池登录和检索令牌的更多信息，请参阅 *Amazon Cognito* 开发者[指南中的用户池身份验证流程](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-authentication-flow.html)。 1. 在 API 请求的`AUTHORIZATION`标题中使用用户池令牌再次测试身份验证。 1. 检查您的新保单存储。添加和完善政策。 ------ #### [ Sample policy store ] **要使用**示例策略存储**配置方法创建策略存储，请按以下步骤操作：** 1. 在 “**起始选项**” 部分中，选择**示例策略存储**。 1. 在**示例项目**部分中，选择要使用的示例 Verified Permissions 应用程序的类型。 + **PhotoFlash**是一个面向客户的 Web 应用程序示例，它使用户能够与朋友共享个人照片和相册。用户可以对允许谁查看、评论和重新共享照片设置精细权限。账户所有者还可以创建好友组，并将照片整理到相册中。 + **DigitalPetStore**是一个示例应用程序，任何人都可以在其中注册并成为客户。客户可以添加待售宠物、搜索宠物和下单。添加宠物的客户将被记录为宠物主人。宠物主人可以更新宠物的详细信息、上传宠物图片或删除宠物清单。已下单的客户将被记录为订单所有者。订单所有者可以获取订单的详细信息或取消订单。宠物商店经理拥有管理权限。 **注意** **DigitalPetStore**示例策略存储区不包括策略模板。**PhotoFlash**和**TinyTodo**示例策略存储包括策略模板。 + **TinyTodo**是一个允许用户创建任务和任务列表的示例应用程序。列表所有者可以管理和共享自己的列表，并指定谁可以查看或编辑他们的列表。 1. 系统会根据您选择的示例项目，自动为示例策略存储的架构生成一个命名空间。 1. 选择**创建策略存储**。 您的策略存储是使用您选择的示例策略存储的策略和架构创建的。有关您可以为示例策略存储创建的模板链接策略的更多信息，请参阅[Amazon 已验证权限示例模板关联政策](policy-templates-example-policies.md)。 ------ #### [ Empty policy store ] **要使用**清空策略存储**配置方法创建策略存储，请按以下步骤操作：** 1. 在 “**起始选项**” 部分中，选择**清空策略存储**。 1. 选择**创建策略存储**。 创建的空策略存储没有架构，这意味着策略未经过验证。有关更新策略存储架构的更多信息，请参阅 [Amazon Verified Permissions 策略存储架构](schema.md)。 有关为策略存储创建策略的更多信息，请参阅[创建 Amazon Verified Permissions 静态策略](policies-create.md)和[创建与 Amazon 验证权限模板关联的政策](policy-templates-create-policy.md)。 ------ #### [ AWS CLI ] **要使用 AWS CLI创建空策略存储，请按以下步骤操作：** 您可以使用 `create-policy-store` 操作创建策略存储。 **注意** 使用创建的策略存储 AWS CLI 为空。 要添加架构，请参阅 [Amazon Verified Permissions 策略存储架构](schema.md)。 要添加策略，请参阅[创建 Amazon Verified Permissions 静态策略](policies-create.md)。 要添加策略模板，请参阅[创建 Amazon 已验证权限策略模板](policy-templates-create.md)。 ``` $ aws verifiedpermissions create-policy-store \ --validation-settings "mode=STRICT" { "arn": "arn:aws:verifiedpermissions::123456789012:policy-store/PSEXAMPLEabcdefg111111", "createdDate": "2023-05-16T17:41:29.103459+00:00", "lastUpdatedDate": "2023-05-16T17:41:29.103459+00:00", "policyStoreId": "PSEXAMPLEabcdefg111111" } ``` ------ #### [ AWS SDKs ] 您可以使用 `CreatePolicyStore` API 创建策略存储。有关更多信息，请参阅[CreatePolicyStore](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_CreatePolicyStore.html)《Amazon 已验证权限 API 参考指南》。 ------ # 使用 AWS 软件开发工具包在 Rust 中实现亚马逊验证权限 本主题提供了使用 AWS 软件开发工具包在 Rust 中实现 Amazon 验证权限的实际示例。此示例说明如何开发一种可以测试用户是否能够查看照片的授权模型。示例代码使用来自 [aws-sdk-verifiedpermissions](https://docs.rs/aws-sdk-verifiedpermissions/latest/aws_sdk_verifiedpermissions/)crate [适用于 Rust 的 AWS SDK](https://github.com/awslabs/aws-sdk-rust)，它提供了一组用于与 AWS 服务之交互的强大工具。 ## 先决条件 在开始之前，请确保在系统上配置了 [AWS CLI](https://aws.amazon.com/cli/)，并且熟悉 Rust。 + 有关安装的说明 AWS CLI，请参阅 [AWS CLI 安装指南](https://docs.aws.amazon.com//cli/latest/userguide/getting-started-install.html)。 + 有关配置的说明 AWS CLI，请参阅[中的[配置设置 AWS CLI](https://docs.aws.amazon.com//cli/latest/userguide/cli-configure-quickstart.html)和配置和凭据文件设置](https://docs.aws.amazon.com//cli/latest/userguide/cli-configure-profiles.html)。 AWS CLI + 有关 Rust 的更多信息，请参阅 [rust-lang.org](https://www.rust-lang.org/) 和 Rust [AWS 开发工具包开发人员指南](https://docs.aws.amazon.com//sdk-for-rust/latest/dg/welcome.html)。 准备好环境后，让我们来探讨如何在 Rust 中实现已验证的权限。 ## 测试示例代码 示例代码执行以下操作： + 设置要与之通信的 SDK 客户端 AWS + 创建[策略存储](policy-stores.md) + [通过添加架构来定义策略存储的结构](schema.md) + 添加用于检查授权请求的[策略](policies.md) + 发送测试[授权请求](authorization.md)以验证所有设置是否正确 **测试示例代码** 1. 创建一个 Rust 项目。 1. 将中的`main.rs`任何现有代码替换为以下代码： ``` use std::time::Duration; use std::thread::sleep; use aws_config::BehaviorVersion; use aws_sdk_verifiedpermissions::Client; use aws_sdk_verifiedpermissions::{ operation::{ create_policy::CreatePolicyOutput, create_policy_store::CreatePolicyStoreOutput, is_authorized::IsAuthorizedOutput, put_schema::PutSchemaOutput, }, types::{ ActionIdentifier, EntityIdentifier, PolicyDefinition, SchemaDefinition, StaticPolicyDefinition, ValidationSettings }, }; //Function that creates a policy store in the client that's passed async fn create_policy_store(client: &Client, valid_settings: &ValidationSettings)-> CreatePolicyStoreOutput { let policy_store = client.create_policy_store().validation_settings(valid_settings.clone()).send().await; return policy_store.unwrap(); } //Function that adds a schema to the policy store in the client async fn put_schema(client: &Client, ps_id: &str, schema: &str) -> PutSchemaOutput { let schema = client.put_schema().definition(SchemaDefinition::CedarJson(schema.to_string())).policy_store_id(ps_id.to_string()).send().await; return schema.unwrap(); } //Function that creates a policy in the policy store in the client async fn create_policy(client: &Client, ps_id: &str, policy_definition:&PolicyDefinition) -> CreatePolicyOutput { let create_policy = client.create_policy().definition(policy_definition.clone()).policy_store_id(ps_id).send().await; return create_policy.unwrap(); } //Function that tests the authorization request to the policy store in the client async fn authorize(client: &Client, ps_id: &str, principal: &EntityIdentifier, action: &ActionIdentifier, resource: &EntityIdentifier) -> IsAuthorizedOutput { let is_auth = client.is_authorized().principal(principal.to_owned()).action(action.to_owned()).resource(resource.to_owned()).policy_store_id(ps_id).send().await; return is_auth.unwrap(); } #[::tokio::main] async fn main() -> Result<(), aws_sdk_verifiedpermissions::Error> { //Set up SDK client let config = aws_config::load_defaults(BehaviorVersion::latest()).await; let client = aws_sdk_verifiedpermissions::Client::new(&config); //Create a policy store let valid_settings = ValidationSettings::builder() .mode({aws_sdk_verifiedpermissions::types::ValidationMode::Strict }) .build() .unwrap(); let policy_store = create_policy_store(&client, &valid_settings).await; println!( "Created Policy store with ID: {:?}", policy_store.policy_store_id ); //Add schema to policy store let schema= r#"{ "PhotoFlash": { "actions": { "ViewPhoto": { "appliesTo": { "context": { "type": "Record", "attributes": {} }, "principalTypes": [ "User" ], "resourceTypes": [ "Photo" ] }, "memberOf": [] } }, "entityTypes": { "Photo": { "memberOfTypes": [], "shape": { "type": "Record", "attributes": { "IsPrivate": { "type": "Boolean" } } } }, "User": { "memberOfTypes": [], "shape": { "attributes": {}, "type": "Record" } } } } }"#; let put_schema = put_schema(&client, &policy_store.policy_store_id, schema).await; println!( "Created Schema with Namespace: {:?}", put_schema.namespaces ); //Create policy let policy_text = r#" permit ( principal in PhotoFlash::User::"alice", action == PhotoFlash::Action::"ViewPhoto", resource == PhotoFlash::Photo::"VacationPhoto94.jpg" ); "#; let policy_definition = PolicyDefinition::Static(StaticPolicyDefinition::builder().statement(policy_text).build().unwrap()); let policy = create_policy(&client, &policy_store.policy_store_id, &policy_definition).await; println!( "Created Policy with ID: {:?}", policy.policy_id ); //Break to make sure the resources are created before testing authorization sleep(Duration::new(2, 0)); //Test authorization let principal= EntityIdentifier::builder().entity_id("alice").entity_type("PhotoFlash::User").build().unwrap(); let action = ActionIdentifier::builder().action_type("PhotoFlash::Action").action_id("ViewPhoto").build().unwrap(); let resource = EntityIdentifier::builder().entity_id("VacationPhoto94.jpg").entity_type("PhotoFlash::Photo").build().unwrap(); let auth = authorize(&client, &policy_store.policy_store_id, &principal, &action, &resource).await; println!( "Decision: {:?}", auth.decision ); println!( "Policy ID: {:?}", auth.determining_policies ); Ok(()) } ``` 1. 通过在终端`cargo run`中输入来运行代码。 如果代码运行正确，则终端将显示决定策略的策略 ID，`Decision: Allow`后面是确定策略的策略 ID。这意味着您已成功创建策略存储并使用适用于 Rust 的 AWS SDK 对其进行了测试。 ## 清理 资源 浏览完保单存储后，将其删除。 **删除策略存储** 您可以使用`delete-policy-store`操作删除策略存储，`PSEXAMPLEabcdefg111111`替换为要删除的策略存储 ID。 ``` $ aws verifiedpermissions delete-policy-store \ --policy-store-id PSEXAMPLEabcdefg111111 ``` 如果成功，此命令不会产生任何输出。 # 与 API 关联的策略存储 一个常见的用例是使用亚马逊验证权限来授权用户访问 APIs 托管在 Amazon API Gateway 上。使用 AWS 控制台中的向导，您可以为在 [Amazon](https://aws.amazon.com/cognito) Cognito 中管理的用户或任何 OIDC 身份提供商 (IdP) 创建基于角色的访问策略，并部署调 AWS Lambda 用已验证权限的授权方来评估这些策略。 要完成向导，请在[创建新的策略存储](policy-stores-create.md)时选择**设置方式 API Gateway 和身份提供商**，然后按照步骤进行操作。 已创建与 API 关联的策略存储，它会为授权请求预置您的授权模型和资源。策略存储库有一个身份源和一个连接到已验证权限的 Lambda 授权者 API Gateway 。创建策略存储后，您可以根据用户的群组成员资格授权 API 请求。例如，“已验证权限” 只能向属于该`Directors`群组成员的用户授予访问权限。 随着应用程序的增长，您可以使用 C [edar 策略](https://docs.cedarpolicy.com/)语言实现具有用户属性和范围 OAuth 2.0 的精细授权。例如，“已验证权限” 只能向在域中拥有`email`属性的用户授予访问权限`mycompany.co.uk`。 为 API 设置授权模型后，剩下的责任是对用户进行身份验证并在应用程序中生成 API 请求，以及维护您的策略存储。 要观看演示，请查看*Amazon Web Services YouTube 频道*上的 [Amazon 已验证权限-快速入门概述和演示](https://www.youtube.com/watch?v=OBrSrzfuWhQ)。 **Topics** + [经过验证的权限如何授权 API 请求](#policy-stores-api-userpool-how-it-works) + [API 关联策略存储的注意事项](#policy-stores-api-userpool-considerations) + [添加基于属性的访问控制 (ABAC)](#policy-stores-api-userpool-abac) + [通过以下方式进入生产阶段 AWS CloudFormation](policy-stores-api-userpool-considerations-production.md) + [对 API 关联策略存储进行故障排除](policy-stores-api-userpool-considerations-troubleshooting.md) **重要** 您在已验证权限控制台中**使用设置 API Gateway 方式和身份源**选项创建的策略存储不适用于立即部署到生产环境。使用初始策略存储，完成授权模型并将策略存储资源导出到 CloudFormation。使用以编程方式将已验证的权限部署到生产环境中。[AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk)有关更多信息，请参阅 [通过以下方式进入生产阶段 AWS CloudFormation](policy-stores-api-userpool-considerations-production.md)。 在关联到 API 和身份源的策略存储中，您的应用程序在向 API 发出请求时会在授权标头中显示用户池令牌。您的策略存储库的身份源为已验证的权限提供令牌验证。令牌与 [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)API 形成授权请求。`principal`Verified Permissions 围绕用户的群组成员资格制定策略，如身份 (ID) 和访问令牌（例如`cognito:groups`用户池）中的群组声明中所示。您的 API 在 Lambda 授权机构中处理来自您的应用程序的令牌，并将其提交给已验证权限以做出授权决定。当您的 API 收到来自 Lambda 授权方的授权决定时，它会将请求传递给您的数据源或拒绝该请求。 **身份来源和带有已验证权限的 API Gateway 授权的组成部分** + 用于对[Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html)用户进行身份验证和分组的用户池或 OIDC IdP。用户的令牌会填充群组成员资格以及已验证权限在您的策略存储中评估的委托人或上下文。 + 一个 [API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-rest-api.html)REST API。例如，“已验证权限” 定义来自 API 路径和 API 方法的操作`MyAPI::Action::get /photo`。 + 一个 Lambda 函数和一个 API 的 Lam [bda 授权者](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html)。Lambda 函数从您的用户池中获取不记名令牌，请求已验证权限的授权，然后将决策返回给。 API Gateway**设置方式 API Gateway 和身份源**工作流程会自动为您创建此 Lambda 授权方。 + 已验证权限策略存储。策略存储标识源是您的 Amazon Cognito 用户池或 OIDC 提供商组。策略存储架构反映了您的 API 的配置，策略将用户组与允许的 API 操作关联起来。 + 一种通过您的 IdP 对用户进行身份验证并将令牌附加到 API 请求的应用程序。 ## 经过验证的权限如何授权 API 请求 当您创建新的策略存储并选择**设置方式和身份源选项时，Ver API Gateway i** fied Permissions 会创建策略存储架构和策略。架构和策略反映了 API 操作以及您想要授权执行这些操作的用户组。[经过验证的权限还会创建 Lambda 函数和授权者。](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html) ![\[该图表显示了使用 Amazon API Gateway、Amazon Cognito 和亚马逊验证权限的授权请求流程。\]](http://docs.aws.amazon.com/zh_cn/verifiedpermissions/latest/userguide/images/api-authorization.png) 1. 您的用户通过 Amazon Cognito 或其他 OIDC IdP 使用您的应用程序登录。IdP 颁发包含用户信息的 ID 和访问令牌。 1. 您的应用程序存储 JWTs. 有关更多信息，请参阅《*Amazon Cognito 开发者指南》*中的在[用户池中使用令牌](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)。 1. 您的用户请求您的应用程序必须从外部 API 检索的数据。 1. 您的应用程序从中的 REST API 请求数据 API Gateway。它会附加 ID 或访问令牌作为请求标头。 1. 如果您的 API 有用于授权决策的缓存，则它会返回之前的响应。如果缓存已禁用或 API 没有当前缓存，则 API Gateway 会将请求参数传递给基于[令牌的 Lambda 授权](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html)者。 1. Lambda 函数通过 API 向已验证权限策略存储发送授权请求。[IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html)Lambda 函数传递授权决策的要素： 1. 用户的代币作为委托人。 1. 例如，API 方法与 API 路径相结合`GetPhoto`，作为操作。 1. `Application`作为资源的术语。 1. 已验证的权限会验证令牌。有关如何验证 Amazon Cognito 令牌的更多信息，请参阅*Amazon Cognito 开发者指南*中的[使用亚马逊验证权限进行授权](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html)。 1. Verified Permissions 会根据您的策略存储中的策略评估授权请求并返回授权决定。 1. Lambda 授权方会向返回`Allow`或`Deny`响应。 API Gateway 1. API 会向您的应用程序返回数据或`ACCESS_DENIED`响应。您的应用程序处理并显示 API 请求的结果。 ## API 关联策略存储的注意事项 在已验证权限控制台中构建与 API 关联的策略存储库时，您正在为最终的生产部署创建测试。在进入生产环境之前，请为 API 和用户池建立固定配置。请考虑以下因素： **API Gateway 缓存响应** 在与 API 关联的策略存储中，已验证权限会创建授权**缓存 TTL 为 120 秒的 Lambda 授权方**。您可以调整此值或在授权者中关闭缓存。在启用了缓存的授权方中，您的授权方每次都会返回相同的响应，直到 TTL 到期。这可以将用户池令牌的有效寿命延长一段时间，该持续时间等于请求阶段的缓存 TTL。 **Amazon Cognito 群组可以重复使用** Amazon Verified Permissions 根据用户 ID 或访问令牌中的`cognito:groups`声明来确定用户池用户的群组成员资格。此声明的值是该用户所属的用户池组的友好名称数组。您无法将用户池组与唯一标识符相关联。 您删除并重新创建的用户池组与策略存储中的同名用户池组与同一个组相同。从用户池中删除组时，请从策略存储中删除对该组的所有引用。 **API 派生的命名空间和架构是 point-in-time** 经过验证的权限会在某个*时间点捕获您的 API：它仅在*您创建策略存储时查询您的 API。当 API 的架构或名称发生变化时，您必须更新您的策略存储和 Lambda 授权机构，或者创建一个新的 API 关联策略存储。Verified Permissions 从您的 API 名称派生出策略存储[命](https://docs.cedarpolicy.com/schema/schema.html#schema-namespace)名空间。 **Lambda 函数没有 VPC 配置** 已验证权限为您的 API 授权方创建的 Lambda 函数将在默认 VPC 中启动。默认情况下。 APIs 将网络访问权限限制为私有的 Lambda 函数 VPCs 无法与授权具有已验证权限的访问请求的 Lambda 函数通信。 **“已验证权限” 在中部署授权方资源 CloudFormation** 要创建与 API 关联的策略存储，您必须使用高权限 AWS 委托人登录已验证权限控制台。该用户部署了一个 CloudFormation 堆栈，该堆栈可以跨多个 AWS 服务堆栈创建资源。该委托人必须有权在已验证的权限、 IAM、Lambda 和中添加和修改资源。 API Gateway最佳做法是，不要与组织中的其他管理员共享这些凭证。 [通过以下方式进入生产阶段 AWS CloudFormation](policy-stores-api-userpool-considerations-production.md)有关已验证权限创建的资源的概述，请参阅。 ## 添加基于属性的访问控制 (ABAC) 与 IdP 的典型身份验证会话会返回 ID 和访问令牌。您可以将这两种令牌类型中的任何一种作为不记名令牌传递给您的 API 的应用程序请求。根据您在创建策略存储时所做的选择，“验证权限” 需要两种类型的令牌之一。这两种类型都包含有关用户群组成员资格的信息。有关令牌类型的更多信息 Amazon Cognito，请参阅《*Amazon Cognito 开发者指南》*中的在[用户池中使用令牌](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)。 创建策略存储后，您可以添加和扩展策略。例如，您可以在将新群组添加到用户池时向策略中添加新群组。由于您的策略存储已经知道您的用户池以令牌形式呈现群组的方式，因此您可以使用新策略允许任何新群组执行一系列操作。 您可能还想将基于群组的策略评估模型扩展为基于用户属性的更精确的模型。用户池令牌包含其他用户信息，这些信息可能有助于做出授权决策。 **ID 令牌** ID 令牌代表用户的属性，具有高度的细粒度访问控制。要评估电子邮件地址、电话号码或部门和经理等自定义属性，请评估 ID 令牌。 **访问令牌** 访问令牌代表用户在 OAuth 2.0 范围内的权限。要添加授权层或设置对额外资源的请求，请评估访问令牌。例如，您可以验证用户是否属于相应的群组，*并且*其范围通常用于授权 API 的访问权限。`PetStore.read`用户池可以通过[资源服务器](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-define-resource-servers.html)向令牌添加自定义范围，并在[运行时自定义令牌](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-lambda-pre-token-generation.html#user-pool-lambda-pre-token-generation-accesstoken)。 有关处理 ID 和[访问 Amazon Cognito 令牌](cognito-map-token-to-schema.md)声明的策略示例，请参阅[将令牌映射到架构和将 OIDC 令牌](oidc-map-token-to-schema.md)映射到架构。 # 通过以下方式进入生产阶段 AWS CloudFormation 与 API 关联的策略存储库是一种快速构建 API 授权模型的方法。 API Gateway 它们旨在用作应用程序授权组件的测试环境。创建测试策略存储后，请花时间完善策略、架构和 Lambda 授权方。 您可能会调整 API 的架构，要求对策略存储架构和策略进行同等调整。与 API 关联的策略存储不会自动从 API 架构更新其架构，经过验证的权限仅在您创建策略存储时对 API 进行轮询。如果您的 API 更改得足够多，则可能需要使用新的策略存储库重复此过程。 当您的应用程序和授权模型准备好部署到生产环境时，请将您开发的 API 关联策略存储与自动化流程集成。作为最佳实践，我们建议您将策略存储架构和策略导出到可以部署到其他 AWS 账户 和的 AWS CloudFormation 模板中 AWS 区域。 与 API 关联的策略存储过程的结果是初始策略存储和 Lambda 授权者。Lambda 授权方有多个依赖资源。已验证权限将这些资源部署到自动 CloudFormation 生成的堆栈中。要部署到生产环境，您必须将策略存储和 Lambda 授权方资源收集到模板中。与 API 关联的策略存储库由以下资源组成： 1. [AWS::VerifiedPermissions::PolicyStore](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-verifiedpermissions-policystore.html)：将您的架构复制到`SchemaDefinition`对象。将`"`角色转义为`\"`. 1. [AWS::VerifiedPermissions::IdentitySource](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-verifiedpermissions-identitysource.html)：从测试策略存储库的输出[GetIdentitySource ](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_GetIdentitySource.html)中复制值，并根据需要进行修改。 1. 其中一项或多[AWS::VerifiedPermissions::Policy](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-verifiedpermissions-policy.html)项：将您的策略声明复制到`Definition`对象。将`"`角色转义为`\"`. 1. [AWS:: Lambda:: Function，:::](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-function.html) [Role，[AWS::: Policy，IAM:::](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html) Authori [AWS zer，:IAM:: Authoriz](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-policy.html) er，AWS ApiGateway[AWS::Lambda::Permission](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-permission.html)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-apigateway-authorizer.html) 以下模板是示例策略存储。您可以将现有堆栈中的 Lambda 授权方资源附加到此模板中。 ``` { "AWSTemplateFormatVersion": "2010-09-09", "Resources": { "MyExamplePolicyStore": { "Type": "AWS::VerifiedPermissions::PolicyStore", "Properties": { "ValidationSettings": { "Mode": "STRICT" }, "Description": "ApiGateway: PetStore/test", "Schema": { "CedarJson": "{\"PetStore\":{\"actions\":{\"get /pets\":{\"appliesTo\":{\"principalTypes\":[\"User\"],\"resourceTypes\":[\"Application\"],\"context\":{\"type\":\"Record\",\"attributes\":{}}}},\"get /\":{\"appliesTo\":{\"principalTypes\":[\"User\"],\"resourceTypes\":[\"Application\"],\"context\":{\"type\":\"Record\",\"attributes\":{}}}},\"get /pets/{petId}\":{\"appliesTo\":{\"context\":{\"type\":\"Record\",\"attributes\":{}},\"resourceTypes\":[\"Application\"],\"principalTypes\":[\"User\"]}},\"post /pets\":{\"appliesTo\":{\"principalTypes\":[\"User\"],\"resourceTypes\":[\"Application\"],\"context\":{\"type\":\"Record\",\"attributes\":{}}}}},\"entityTypes\":{\"Application\":{\"shape\":{\"type\":\"Record\",\"attributes\":{}}},\"User\":{\"memberOfTypes\":[\"UserGroup\"],\"shape\":{\"attributes\":{},\"type\":\"Record\"}},\"UserGroup\":{\"shape\":{\"type\":\"Record\",\"attributes\":{}}}}}}" } } }, "MyExamplePolicy": { "Type": "AWS::VerifiedPermissions::Policy", "Properties": { "Definition": { "Static": { "Description": "Policy defining permissions for testgroup cognito group", "Statement": "permit(\nprincipal in PetStore::UserGroup::\"us-east-1_EXAMPLE|testgroup\",\naction in [\n PetStore::Action::\"get /\",\n PetStore::Action::\"post /pets\",\n PetStore::Action::\"get /pets\",\n PetStore::Action::\"get /pets/{petId}\"\n],\nresource);" } }, "PolicyStoreId": { "Ref": "MyExamplePolicyStore" } }, "DependsOn": [ "MyExamplePolicyStore" ] }, "MyExampleIdentitySource": { "Type": "AWS::VerifiedPermissions::IdentitySource", "Properties": { "Configuration": { "CognitoUserPoolConfiguration": { "ClientIds": [ "1example23456789" ], "GroupConfiguration": { "GroupEntityType": "PetStore::UserGroup" }, "UserPoolArn": "arn:aws:cognito-idp:us-east-1:123456789012:userpool/us-east-1_EXAMPLE" } }, "PolicyStoreId": { "Ref": "MyExamplePolicyStore" }, "PrincipalEntityType": "PetStore::User" }, "DependsOn": [ "MyExamplePolicyStore" ] } } } ``` # 对 API 关联策略存储进行故障排除 使用此处的信息来帮助您诊断和修复构建与 Amazon Verified Permissions API 关联的策略存储库时的常见问题。 **Topics** + [我更新了政策，但授权决定没有改变](#policy-stores-api-userpool-considerations-troubleshooting-update-didnt-change) + [我将 Lambda 授权器附加到我的 API 中，但它没有生成授权请求](#policy-stores-api-userpool-considerations-troubleshooting-attached-not-deployed) + [我收到了意想不到的授权决定，想查看授权逻辑](#policy-stores-api-userpool-considerations-troubleshooting-review-code) + [我想从我的 Lambda 授权机构那里查找日志](#policy-stores-api-userpool-considerations-troubleshooting-find-logs) + [我的 Lambda 授权机构不存在](#policy-stores-api-userpool-considerations-troubleshooting-didnt-deploy) + [我的 API 位于私有 VPC 中，无法调用授权方](#policy-stores-api-userpool-considerations-troubleshooting-in-a-vpc) + [我想在我的授权模型中处理其他用户属性](#policy-stores-api-userpool-considerations-troubleshooting-fgac) + [我想添加新的操作、操作上下文属性或资源属性](#policy-stores-api-userpool-considerations-troubleshooting-action-resource-attributes) ## 我更新了政策，但授权决定没有改变 默认情况下，已验证权限将 Lambda 授权机构配置为将授权决策缓存 120 秒。两分钟后重试，或者在授权方上禁用缓存。有关更多信息，请参阅 *Amazon API Gateway 开发者指南中的启用 API* [缓存以增强响应能力](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-caching.html)。 ## 我将 Lambda 授权器附加到我的 API 中，但它没有生成授权请求 要开始处理请求，您必须部署授权者所连接的 API 阶段。有关更多信息，请参阅 *Amazon [API Gateway 开发者指南中的部署 RES](https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-deploy-api.html) T API*。 ## 我收到了意想不到的授权决定，想查看授权逻辑 与 API 关联的策略存储流程会为您的授权方创建一个 Lambda 函数。已验证的权限会自动将您的授权决策逻辑构建到授权者函数中。创建策略存储后，您可以返回以查看和更新函数中的逻辑。 要从 AWS CloudFormation 控制台中找到您的 Lambda 函数，请在新策略存储的**概**述页面上选择**检查部署**按钮。 您也可以在 AWS Lambda 控制台中找到您的函数。导航到策略存储 AWS 区域 中的控制台，搜索前缀为的函数名称`AVPAuthorizerLambda`。如果您创建了多个与 API 关联的策略存储，请使用函数的**上次修改**时间将其与策略存储的创建相关联。 ## 我想从我的 Lambda 授权机构那里查找日志 Lambda 函数收集指标并将其调用结果记录在亚马逊中。 CloudWatch要查看您的日志，请在 Lambda 控制台中[找到您的函数](#policy-stores-api-userpool-considerations-troubleshooting-review-code)，然后选择**监控**选项卡。选择**查看 CloudWatch 日志**并查看日志组中的条目。 有关 Lambda 函数日志的更多信息，请参阅*AWS Lambda 开发者*指南 AWS Lambda中的[将 Amazon CloudWatch 日志与一起使用](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html)。 ## 我的 Lambda 授权机构不存在 完成 API 关联策略存储的设置后，您必须将 Lambda 授权方附加到您的 API。如果您在 API Gateway 控制台中找不到授权者，则您的策略存储的其他资源可能已失败或尚未部署。与 API 关联的策略存储将这些资源部署在堆栈中。 CloudFormation 在创建过程结束时，已验证权限会显示一个标有 “**检查部署**” 标签的链接。如果您已经离开了此屏幕，请前往 CloudFormation 控制台，在最近的堆栈中搜索前缀为的名称。`AVPAuthorizer-` CloudFormation 在堆栈部署的输出中提供了宝贵的故障排除信息。 有关 CloudFormation 堆栈故障排除的帮助，请参阅《*AWS CloudFormation 用户指南》 CloudFormation*中的[故障排除](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html)。 ## 我的 API 位于私有 VPC 中，无法调用授权方 已验证权限不支持通过 VPC 终端节点访问 Lambda 授权方。您必须在您的 API 和用作授权方的 Lambda 函数之间打开一条网络路径。 ## 我想在我的授权模型中处理其他用户属性 与 API 关联的策略存储流程从用户令牌中的群组声明中派生出经过验证的权限策略。要更新您的授权模型以考虑其他用户属性，请将这些属性集成到您的策略中。 您可以将 Amazon Cognito 用户池中的 ID 和访问令牌中的许多声明映射到已验证的权限政策声明。例如，大多数用户的 ID 令牌中都有`email`声明。有关将身份来源的声明添加到策略的更多信息，请参阅将[Amazon Cognito 令牌映射到架构和将 OIDC 令](cognito-map-token-to-schema.md)[牌映射到](oidc-map-token-to-schema.md)架构。 ## 我想添加新的操作、操作上下文属性或资源属性 与 API 关联的策略存储库及其创建的 Lambda 授权方是一种资源。 point-in-time它们反映了创建 API 时的状态。策略存储架构不会为操作分配任何上下文属性，也不会为默认`Application`资源分配任何属性或父项。 向 API 添加操作（路径和方法）时，必须更新策略存储库以了解新操作。您还必须更新您的 Lambda 授权机构以处理新操作的授权请求。您可以[重新开始使用新的保单存储](policy-stores-create.md)，也可以更新现有的保单存储。 要更新现有的政策存储，请[找到您的函数](#policy-stores-api-userpool-considerations-troubleshooting-review-code)。检查自动生成的函数中的逻辑，并对其进行更新以处理新的操作、属性或上下文。然后[编辑您的架构](schema-edit.md)，使其包含新的操作和属性。 # 删除策略存储 您可以使用 AWS 管理控制台 或删除 Amazon 已验证的权限策略商店 AWS CLI。删除策略存储会永久删除架构以及策略存储中的所有策略和策略模板。与已删除的策略存储关联的所有策略存储别名也将被删除。 删除保护可防止意外删除策略存储。通过创建的所有新策略存储都启用了删除保护 AWS 管理控制台。相比之下，通过 API 或 SDK 调用创建的所有策略存储都将禁用该功能。 出于以下原因，您可能需要删除策略存储： + 您已达到给定区域中可用策略存储的配额。有关更多信息，请参阅 [资源配额](quotas.md#quotas-resources)。 + 您不再支持多租户应用程序中的租户，因此不再需要该策略存储。 ------ #### [ AWS 管理控制台 ] **删除策略存储** 1. 打开已[验证权限控制台](https://console.aws.amazon.com/verifiedpermissions/)。选择您的保单商店。 1. 在左侧的导航窗格中，选择**设置**。 1. 选择**删除此策略存储**。 1. 在文本框中输入 `delete`，然后选择**删除**。 **注意** 如果启用了删除保护，则需要先将其禁用，然后才能选择 “**删除**”。要将其禁用，请选择 “**禁用删除保护**”。 ------ #### [ AWS CLI ] **删除策略存储** 您可以使用`delete-policy-store`操作删除策略存储，`PSEXAMPLEabcdefg111111`替换为要删除的策略存储 ID。 ``` $ aws verifiedpermissions delete-policy-store \ --policy-store-id PSEXAMPLEabcdefg111111 ``` 如果成功，此命令不会产生任何输出。 **注意** 如果为此策略存储启用了删除保护，则必须先运行该`update-policy-store`操作并禁用删除保护。 ``` aws verifiedpermissions update-policy-store \ --deletion-protection "DISABLED" \ --policy-store-id PSEXAMPLEabcdefg111111 ``` ------