

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

# Amazon Verified Permissions 정책 스토어
<a name="policy-stores"></a>

정책 스토어는 정책 및 정책 템플릿의 컨테이너입니다. 각 정책 스토어에서 정책 스토어에 추가된 정책을 검증하는 데 사용되는 스키마를 생성할 수 있습니다. 또한 정책 검증을 켤 수 있습니다. 정책 검증이 활성화된 정책 스토어에 정책을 추가하면 정책에 정의된 엔터티 유형, 공통 유형 및 작업이 스키마에 대해 검증되고 잘못된 정책이 거부됩니다.

삭제 방지 기능은 정책 스토어의 우발적 삭제를 방지합니다. 를 통해 생성된 모든 새 정책 스토어에서 삭제 방지가 활성화됩니다 AWS Management Console. 반대로 API 또는 SDK 직접 호출을 통해 생성된 모든 정책 저장소에 대해서는 비활성화됩니다.

애플리케이션당 하나의 정책 스토어를 생성하거나 다중 테넌트 애플리케이션의 경우 테넌트당 하나의 정책 스토어를 생성하는 것이 좋습니다. [권한 부여 요청](terminology.md#term-authorization-request) 시 정책 스토어를 지정해야 합니다. 정책 스토어 별칭을 생성하여 기억하기 쉬운 이름으로 정책 스토어를 참조할 수도 있습니다. 자세한 내용은 [Amazon Verified Permissions 정책 스토어 별칭](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 정책 스토어 생성
<a name="policy-stores-create"></a>

다음 방법을 사용하여 정책 스토어를 생성할 수 있습니다.
+ **안내 설정 따르**기 - 첫 번째 정책을 생성하기 전에 유효한 작업과 보안 주체 유형을 사용하여 리소스 유형을 정의합니다.
+ ** API Gateway 및 자격 증명 소스로 설정** - 자격 증명 공급자(IdP)로 로그인하는 사용자와 Amazon API Gateway API의 작업 및 리소스 엔터티를 사용하여 보안 주체 엔터티를 정의합니다. 애플리케이션이 사용자의 그룹 멤버십 또는 기타 속성을 사용하여 API 요청을 승인하도록 하려면이 옵션을 사용하는 것이 좋습니다.
+ **샘플 정책 스토어에서 시작** - 사전 정의된 샘플 프로젝트 정책 스토어를 선택합니다. Verified Permissions에 대해 알아보고 예시 정책을 보고 테스트하려는 경우 이 옵션을 사용하는 것이 좋습니다.
+ **빈 정책 스토어 생성** - 스키마와 모든 액세스 정책을 직접 정의합니다. 정책 스토어 구성에 이미 익숙한 경우 이 옵션을 사용하는 것이 좋습니다.

------
#### [ Guided setup ]

****설정 안내** 구성 방법을 사용하여 정책 스토어를 생성하려면**

설정 안내 마법사가 정책 스토어의 첫 번째 반복을 생성하는 프로세스를 안내합니다. 이 프로세스에서는 첫 번째 리소스 유형에 대한 스키마를 만들고, 해당 리소스 유형에 적용할 수 있는 작업과 작업 권한을 부여할 보안 주체 유형을 지정합니다. 그런 다음 첫 번째 정책을 생성합니다. 이 마법사를 완료하면 정책 스토어에 정책을 추가하고, 스키마를 확장하여 다른 리소스 및 보안 주체 유형을 설명하고, 추가 정책 및 템플릿을 생성할 수 있습니다.

1. [Verified Permissions 콘솔](https://console.aws.amazon.com/verifiedpermissions)에서 **새 정책 스토어 생성을** 선택합니다.

1. **시작 옵션** 섹션에서 **안내형 설정을** 선택합니다.

1. **정책 스토어 설명을** 입력합니다. 이 텍스트는 *날씨 업데이트 웹 애플리케이션*과 같이 현재 정책 스토어의 함수에 대한 친숙한 참조로 조직에 적합한 텍스트일 수 있습니다.

1. **세부 정보** 섹션에서 **스키마의 네임스페이스**를 입력합니다. 네임스페이스에 대한 자세한 내용은 섹션을 참조하세요[네임스페이스 정의](terminology-differences-avp-cedar.md#differences-namespaces).

1. **다음**을 선택합니다.

1. **리소스 유형** 창에서 리소스 유형의 이름을 입력합니다. 예를 들어는 *날씨 업데이트 웹 애플리케이션의* 리소스일 `currentTemperature` 수 있습니다.

1. (선택 사항) **속성 추가**를 선택하여 리소스 속성을 추가합니다. **속성 이름**을 입력하고 리소스의 각 속성에 대해 **속성 유형**을 선택합니다. 각 속성이 **필수**인지 여부를 선택합니다. 예를 들어는 `currentTemperature` 리소스의 속성일 `temperatureFormat` 수 있으며 화씨 또는 섭씨일 수 있습니다. 리소스 유형에 추가된 속성을 제거하려면 해당 속성 옆에 있는 **제거**를 선택합니다.

1. **작업** 필드에 지정된 리소스 유형에 대해 승인할 작업을 입력합니다. 리소스 유형에 대해 작업을 더 추가하려면 **작업 추가**를 선택합니다. 예를 들어는 *날씨 업데이트 웹 애플리케이션의* 작업일 `viewTemperature` 수 있습니다. 리소스 유형에 대해 추가된 작업을 제거하려면 해당 작업 옆에 있는 **제거**를 선택합니다.

1. **보안 주체 유형 이름** 필드에 해당 리소스 유형에 지정된 작업을 사용할 보안 주체 유형의 이름을 입력합니다. 기본적으로 **사용자는**이 필드에 추가되지만 교체할 수 있습니다.

1. **다음**을 선택합니다.

1. **보안 주체 유형** 창에서 보안 주체 유형의 자격 증명 소스를 선택합니다.
   + Verified Permissions 애플리케이션에서 보안 주체의 ID 및 속성이 직접 제공되도록 하려면 **사용자 지정**을 선택합니다. 보안 주체 속성을 추가하려면 **속성 추가**를 선택합니다. Verified Permissions는 스키마에 대해 정책을 검증할 때 지정된 속성 값을 사용합니다. 보안 주체 유형에 추가된 속성을 제거하려면 속성 옆에 있는 **제거**를 선택합니다.
   + 에서 생성한 ID 또는 액세스 토큰에서 보안 주체의 ID 및 속성을 제공할 경우 **Cognito 사용자 풀**을 선택합니다 Amazon Cognito. **사용자 풀 연결**을 선택합니다. 를 선택하고 연결할 **사용자 풀의 사용자 풀 ID**를 **AWS 리전** 입력합니다. Amazon Cognito **연결**을 선택합니다. 자세한 내용은 *Amazon Cognito 개발자 안내서*의 [Amazon Verified Permissions를 통한 권한 부여](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html)를 참조하세요.
   + **외부 OIDC 공급자**가 생성한 ID 및/또는 액세스 토큰에서 보안 주체의 ID 및 속성을 추출할 경우 외부 OIDC 공급자를 선택하고 공급자 및 토큰 세부 정보를 추가합니다.

1. **다음**을 선택합니다.

1. **정책 세부 정보** 섹션에서 첫 번째 Cedar 정책에 대해 선택적으로 **정책 설명**을 입력합니다.

1. **보안 주체 범위** 필드에서 정책으로부터 권한을 부여받을 보안 주체를 선택합니다.
   + 정책을 특정 보안 주체에 적용하려면 **특정 보안 주체**를 선택합니다. **작업을 수행하도록 허용할 보안 주체** 필드에서 보안 주체를 선택하고 보안 주체의 개체 식별자를 입력합니다. 예를 들어는 *날씨 업데이트 웹 애플리케이션의* 엔터티 식별자일 `user-id` 수 있습니다.
**참고**  
를 사용하는 경우 Amazon Cognito엔터티 식별자의 형식은 여야 합니다`<userpool-id>|<sub>`.
   + 정책 스토어의 모든 보안 주체에 정책을 적용하려면 **모든 보안 주체**를 선택합니다.

1. **리소스 범위** 필드에서 지정된 보안 주체에게 작업 권한을 부여할 리소스를 선택합니다.
   + 정책을 특정 리소스에 적용하려면 **특정 리소스**를 선택합니다. **이 정책을 적용해야 하는 리소스** 필드에서 리소스를 선택하고 리소스의 개체 식별자를 입력합니다. 예를 들어는 *날씨 업데이트 웹 애플리케이션의* 엔터티 식별자일 `temperature-id` 수 있습니다.
   + 정책 스토어의 모든 리소스에 정책을 적용하려면 **모든 리소스**를 선택합니다.

1. **작업 범위** 필드에서 지정된 보안 주체에게 수행할 권한을 부여할 작업을 선택합니다.
   + 정책을 여러 특정 작업에 적용하려면 **특정 작업 세트**를 선택합니다. **이 정책을 적용해야 하는 작업** 필드에서 해당 작업 옆에 있는 확인란을 선택합니다.
   + 정책 스토어의 모든 작업에 정책을 적용하려면 **모든 작업**을 선택합니다.

1. **정책 미리 보기** 섹션에서 정책을 검토하십시오. **정책 스토어 생성**을 선택합니다.

------
#### [ Set up with API Gateway and an identity source ]

**로 **설정 API Gateway 및 자격 증명 소스 구성 방법을 사용하여 정책 스토어를** 생성하려면**

 API Gateway 옵션은 사용자의 그룹 또는 *역할*에서 권한 부여 결정을 내리도록 설계된 Verified Permissions 정책을 사용하여 APIs를 보호합니다. 이 옵션은 자격 증명 소스 그룹을 사용하여 권한 부여를 테스트하고 Lambda 권한 부여자를 사용하여 API를 테스트하기 위한 정책 스토어를 빌드합니다.

IdP의 사용자 및 해당 그룹은 보안 주체(ID 토큰) 또는 컨텍스트(액세스 토큰)가 됩니다. API의 메서 API Gateway 드와 경로는 정책이 승인하는 작업이 됩니다. 애플리케이션이 리소스가 됩니다. 이 워크플로의 결과로 Verified Permissions는 정책 스토어, Lambda 함수 및 API Lambda 권한 부여자를 생성합니다. 이 워크플로를 완료한 후 API에 Lambda [권한 부여자를](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html) 할당해야 합니다.

1. [Verified Permissions 콘솔](https://console.aws.amazon.com/verifiedpermissions)에서 **새 정책 스토어 생성을** 선택합니다.

1. **시작 옵션** 섹션에서 ** API Gateway 및 자격 증명 소스를 사용하여 설정을** 선택하고 **다음을** 선택합니다.

1. **리소스 및 작업 가져오기** 단계의 **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. 자격 증명 소스의 **토큰에 사용자 클레임 이름을** 입력합니다. 이는 일반적으로 평가할 엔터티의 고유 식별자를 포함하는 ID 또는 액세스 토큰`sub`의 클레임입니다. 연결된 OIDC IdP의 ID는 정책 스토어의 사용자 유형에 매핑됩니다.

      1. 자격 증명 소스의 **토큰에 그룹 클레임 이름을** 입력합니다. 이는 일반적으로 사용자 그룹 목록이 포함된 ID 또는 액세스 토큰`groups`의 클레임입니다. 정책 스토어는 그룹 멤버십을 기반으로 요청을 승인합니다.

   1. **대상 검증**에서 정책 스토어가 권한 부여 요청에서 수락할 값을 `Add value` 선택하고 추가합니다.

   1. **다음**을 선택합니다.

1. 를 선택한 경우 **Amazon Cognito**Verified Permissions는 사용자 풀에서 그룹을 쿼리합니다. OIDC 공급자의 경우 그룹 이름을 수동으로 입력합니다. **그룹에 작업 할당** 단계에서는 그룹 구성원이 작업을 수행하도록 허용하는 정책 스토어에 대한 정책을 생성합니다.

   1. 정책에 포함할 그룹을 선택하거나 추가합니다.

   1. 선택한 각 그룹에 작업을 할당합니다.

   1. **다음**을 선택합니다.

1. **앱 통합 배포**에서 나중에 수동으로 Lambda 권한 부여자를 연결할지 아니면 Verified Permissions가 대신 연결하도록 할지 선택하고 Verified Permissions가 정책 스토어 및 Lambda 권한 부여자를 생성하기 위해 수행할 단계를 검토합니다.

1. 새 리소스를 생성할 준비가 되면 **정책 스토어 생성을** 선택합니다.

1. 브라우저에서 **정책 스토어 상태** 단계를 열어두어 Verified Permissions의 리소스 생성 진행 상황을 모니터링합니다.

1. 보통 약 1시간 후 또는 **Lambda 권한 부여자 배포** 단계에 **성공**이 표시되면 권한 부여자를 수동으로 연결하도록 선택한 경우 권한 부여자를 구성합니다.

   Verified Permissions는 API에 Lambda 함수와 Lambda 권한 부여자를 생성했습니다. **API 열기**를 선택하여 API로 이동합니다.

   Lambda 권한 부여자를 할당하는 방법을 알아보려면 *Amazon API Gateway 개발자 안내서*의 [API Gateway Lambda 권한 부여자 사용을](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html) 참조하세요.

   1. API의 **권한 부여자로** 이동하여 Verified Permissions가 생성한 권한 부여자의 이름을 기록해 둡니다.

   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**는 사용자가 개별 사진 및 앨범을 친구와 공유할 수 있는 고객용 샘플 웹 애플리케이션입니다. 사용자는 사진을 보거나 댓글을 달고 재공유할 수 있는 사람의 권한을 세분화하여 설정할 수 있습니다. 계정 소유자는 친구 그룹을 만들고 사진을 앨범으로 정리할 수도 있습니다.
   + **DigitalPetStore**는 누구나 등록하여 고객이 될 수 있는 샘플 애플리케이션입니다. 고객은 판매할 반려동물을 추가하거나 반려동물을 검색하고 주문할 수 있습니다. 반려동물을 추가한 고객은 반려동물 소유자로 기록됩니다. 반려동물 소유자는 반려동물의 세부 정보를 업데이트하거나 반려동물 이미지를 업로드하고 반려동물 등록 내용을 삭제할 수 있습니다. 반려동물을 주문한 고객은 주문 소유자로 기록됩니다. 주문 소유자는 주문에 대한 세부 정보를 확인하거나 주문을 취소할 수 있습니다. 반려동물 스토어 매니저에게는 관리자 액세스 권한이 부여됩니다.
**참고**  
**DigitalPetStore** 샘플 정책 스토어에는 정책 템플릿이 포함되어 있지 않습니다. **PhotoFlash** 및 **TinyTodo** 샘플 정책 스토어에는 정책 템플릿이 포함되어 있습니다.
   + **TinyTodo**는 사용자가 작업 및 작업 목록을 생성할 수 있는 샘플 애플리케이션입니다. 목록 소유자는 목록을 관리 및 공유하고 목록을 보거나 편집할 수 있는 사람을 지정할 수 있습니다.

1. 샘플 정책 스토어의 스키마 네임스페이스는 선택한 샘플 프로젝트에 따라 자동으로 생성됩니다.

1. **정책 스토어 생성**을 선택합니다.

   선택한 샘플 정책 스토어에 대한 정책 및 스키마를 사용하여 정책 스토어가 생성됩니다. 샘플 정책 스토어에 대해 생성할 수 있는 템플릿이 연결된 정책에 대한 자세한 내용은 [Amazon Verified Permissions 예제 템플릿 연결 정책](policy-templates-example-policies.md)를 참조하세요.

------
#### [ Empty policy store ]

****빈 정책 스토어** 구성 방법을 사용하여 정책 스토어를 생성하려면**

1. **시작 옵션** 섹션에서 **정책 저장소 비우기를** 선택합니다.

1. **정책 스토어 생성**을 선택합니다.

빈 정책 스토어는 스키마 없이 생성되므로 정책이 검증되지 않습니다. 정책 스토어의 스키마 업데이트에 대한 자세한 내용은 [Amazon Verified Permissions 정책 스토어 스키마](schema.md)를 참조하세요.

정책 스토어의 정책 생성에 대한 자세한 내용은 [Amazon Verified Permissions 정적 정책 생성](policies-create.md) 및 [Amazon Verified Permissions 템플릿 연결 정책 생성](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 Verified Permissions 정책 템플릿 생성](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를 사용하여 정책 스토어를 생성할 수 있습니다. 자세한 내용은 Amazon Verified Permissions API 참조 가이드의 [CreatePolicyStore](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_CreatePolicyStore.html)를 참조하세요.

------

# AWS SDK를 사용하여 Rust에서 Amazon Verified Permissions 구현
<a name="code-samples-rust"></a>

이 주제에서는 SDK를 사용하여 Rust에서 Amazon Verified Permissions를 구현하는 실제 예제를 AWS 제공합니다. 이 예제에서는 사용자가 사진을 볼 수 있는지 테스트할 수 있는 권한 부여 모델을 개발하는 방법을 보여줍니다. 샘플 코드는의 [aws-sdk-verifiedpermissions](https://docs.rs/aws-sdk-verifiedpermissions/latest/aws_sdk_verifiedpermissions/) 크레이트를 사용합니다. [AWS SDK for Rust](https://github.com/awslabs/aws-sdk-rust)이 크레이트는와 상호 작용하기 위한 강력한 도구 세트를 제공합니다 AWS 서비스.

## 사전 조건
<a name="rust-prereqs"></a>

 시작하기 전에 시스템에 [AWS CLI](https://aws.amazon.com/cli/)가 구성되어 있고 Rust에 익숙해야 합니다.
+ 설치에 대한 지침은 [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) 구성 및 자격 증명 파일 설정을 AWS CLI참조하세요. [AWS CLI](https://docs.aws.amazon.com//cli/latest/userguide/cli-configure-profiles.html) 
+ Rust에 대한 자세한 내용은 [rust-lang.org](https://www.rust-lang.org/) 및 [AWS SDK for Rust 개발자 안내서](https://docs.aws.amazon.com//sdk-for-rust/latest/dg/welcome.html)를 참조하세요.

환경을 준비하면서 Rust에서 Verified Permissions를 구현하는 방법을 살펴보겠습니다.

## 샘플 코드 테스트
<a name="rust-code"></a>

샘플 코드는 다음을 수행합니다.
+ 와 통신할 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` 표시됩니다. 즉, 정책 스토어를 성공적으로 생성하고 AWS SDK for Rust를 사용하여 테스트했습니다.

## 리소스 정리
<a name="rust-clean-up"></a>

정책 스토어 탐색을 완료한 후 삭제합니다.

**정책 저장소 삭제**  
를 삭제하려는 정책 스토어 ID`PSEXAMPLEabcdefg111111`로 바꾸는 `delete-policy-store` 작업을 사용하여 정책 스토어를 삭제할 수 있습니다.

```
$ aws verifiedpermissions delete-policy-store \
    --policy-store-id PSEXAMPLEabcdefg111111
```

성공하면 이 명령은 출력을 생성하지 않습니다.

# API 연결 정책 스토어
<a name="policy-stores-api-userpool"></a>

일반적인 사용 사례는 Amazon Verified Permissions를 사용하여 Amazon API Gateway에서 호스팅되는 APIs에 대한 사용자 액세스를 승인하는 것입니다. AWS 콘솔에서 마법사를 사용하여 [Amazon Cognito](https://aws.amazon.com/cognito) 또는 OIDC 자격 증명 공급자(IdP)에서 관리되는 사용자를 위한 역할 기반 액세스 정책을 생성하고 Verified Permissions를 호출하는 AWS Lambda 권한 부여자를 배포하여 이러한 정책을 평가할 수 있습니다.

마법사를 완료하려면 [새 정책 스토어를 생성할](policy-stores-create.md) 때 ** API Gateway 및 자격 증명 공급자로 설정을** 선택하고 단계를 따릅니다.

API 연결 정책 스토어가 생성되고 권한 부여 요청에 대한 권한 부여 모델과 리소스를 프로비저닝합니다. 정책 스토어에는 API Gateway Verified Permissions에 연결하는 자격 증명 소스와 Lambda 권한 부여자가 있습니다. 정책 스토어가 생성되면 사용자의 그룹 멤버십을 기반으로 API 요청을 승인할 수 있습니다. 예를 들어 Verified Permissions는 `Directors` 그룹의 구성원인 사용자에게만 액세스 권한을 부여할 수 있습니다.

애플리케이션이 확장되면 [Cedar 정책 언어를](https://docs.cedarpolicy.com/) 사용하여 사용자 속성 및 OAuth 2.0 범위를 사용하여 세분화된 권한 부여를 구현할 수 있습니다. 예를 들어 Verified Permissions는 도메인에 `email` 속성이 있는 사용자에게만 액세스 권한을 부여할 수 있습니다`mycompany.co.uk`.

API에 대한 권한 부여 모델을 설정한 후 나머지 책임은 사용자를 인증하고 애플리케이션에서 API 요청을 생성하고 정책 스토어를 유지하는 것입니다.

데모를 보려면 *Amazon Web Services YouTube 채널*의 [Amazon Verified Permissions - Quick Start Overview and Demo](https://www.youtube.com/watch?v=OBrSrzfuWhQ)를 참조하세요.

**Topics**
+ [Verified Permissions가 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 및 Verified Permissions 콘솔의 자격 증명 소스** 옵션으로 생성한 정책 스토어는 프로덕션에 즉시 배포하기 위한 것이 아닙니다. 초기 정책 스토어를 사용하여 권한 부여 모델을 완료하고 정책 스토어 리소스를 CloudFormation으로 내보냅니다. 를 사용하여 프로그래밍 방식으로 Verified Permissions를 프로덕션에 배포합니다[AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk). 자세한 내용은 [를 사용하여 프로덕션으로 전환 AWS CloudFormation](policy-stores-api-userpool-considerations-production.md) 단원을 참조하십시오.

API 및 자격 증명 소스에 연결된 정책 스토어에서 애플리케이션은 API에 요청할 때 권한 부여 헤더에 사용자 풀 토큰을 제공합니다. 정책 스토어의 자격 증명 소스는 Verified Permissions에 대한 토큰 검증을 제공합니다. 토큰은 [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html) API를 사용하여 권한 부여 요청`principal`에서를 형성합니다. Verified Permissions는 사용자 풀과 같은 ID(ID) 및 액세스 토큰의 그룹 클레임에 표시된 대로 사용자의 그룹 멤버십에 `cognito:groups` 대한 정책을 빌드합니다. API는 Lambda 권한 부여자의 애플리케이션에서 토큰을 처리하고 권한 부여 결정을 위해 Verified Permissions에 제출합니다. API는 Lambda 권한 부여자로부터 권한 부여 결정을 받으면 요청을 데이터 소스에 전달하거나 요청을 거부합니다.

**Verified Permissions를 사용한 자격 증명 소스 및 API Gateway 권한 부여의 구성 요소**
+ [Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-identity-pools.html) 사용자를 인증하고 그룹화하는 사용자 풀 또는 OIDC IdP입니다. 사용자의 토큰은 그룹 멤버십과 Verified Permissions가 정책 스토어에서 평가하는 보안 주체 또는 컨텍스트를 채웁니다.
+ [API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-rest-api.html) REST API. Verified Permissions는와 같은 API 경로 및 API 메서드의 작업을 정의합니다`MyAPI::Action::get /photo`.
+ API에 대한 Lambda 함수 및 [Lambda 권한 부여자](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html). Lambda 함수는 사용자 풀에서 보유자 토큰을 가져와 Verified Permissions에 권한 부여를 요청하고 결정을 반환합니다 API Gateway. **로 설정 API Gateway 및 자격 증명 소스 워크플로는** 자동으로이 Lambda 권한 부여자를 생성합니다.
+ Verified Permissions 정책 스토어. 정책 스토어 자격 증명 소스는 Amazon Cognito 사용자 풀 또는 OIDC 공급자 그룹입니다. 정책 스토어 스키마는 API의 구성을 반영하며, 정책은 사용자 그룹을 허용된 API 작업에 연결합니다.
+ IdP로 사용자를 인증하고 API 요청에 토큰을 추가하는 애플리케이션입니다.

## Verified Permissions가 API 요청을 승인하는 방법
<a name="policy-stores-api-userpool-how-it-works"></a>

새 정책 스토어를 생성하고 **로 설정 API Gateway 및 자격 증명 소스** 옵션을 선택하면 Verified Permissions가 정책 스토어 스키마 및 정책을 생성합니다. 스키마 및 정책은 API 작업과 작업을 수행할 권한을 부여하려는 사용자 그룹을 반영합니다. Verified Permissions는 Lambda 함수 및 [권한 부여자](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html)도 생성합니다.

![\[Amazon API Gateway, Amazon Cognito 및 Amazon Verified Permissions를 사용하여 권한 부여 요청의 흐름을 표시하는 다이어그램입니다.\]](http://docs.aws.amazon.com/ko_kr/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 함수는 [IsAuthorizedWithToken](https://docs.aws.amazon.com/verifiedpermissions/latest/apireference/API_IsAuthorizedWithToken.html) API를 사용하여 Verified Permissions 정책 스토어에 권한 부여 요청을 보냅니다. Lambda 함수는 권한 부여 결정의 요소를 전달합니다.

   1. 보안 주체로서의 사용자 토큰입니다.

   1. API 경로와 결합된 API 메서드, 예: 작업`GetPhoto`.

   1. 리소스`Application`로서의 용어입니다.

1. Verified Permissions는 토큰을 검증합니다. Amazon Cognito 토큰 검증 방법에 대한 자세한 내용은 *Amazon Cognito 개발자 안내서*의 [Amazon Verified Permissions 권한 부여를 참조하세요](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 연결 정책 스토어에 대한 고려 사항
<a name="policy-stores-api-userpool-considerations"></a>

Verified Permissions 콘솔에서 API 연결 정책 스토어를 빌드하면 최종 프로덕션 배포에 대한 테스트를 생성합니다. 프로덕션으로 이동하기 전에 API 및 사용자 풀에 대한 고정 구성을 설정합니다. 다음 요인을 고려하세요.

**API Gateway 는 응답을 캐싱합니다.**  
API 연결 정책 스토어에서 Verified Permissions는 **권한 부여 캐싱** TTL이 120초인 Lambda 권한 부여자를 생성합니다. 이 값을 조정하거나 권한 부여자에서 캐싱을 끌 수 있습니다. 캐싱이 활성화된 권한 부여자에서 권한 부여자는 TTL이 만료될 때까지 매번 동일한 응답을 반환합니다. 이렇게 하면 요청된 단계의 캐싱 TTL과 동일한 기간만큼 사용자 풀 토큰의 유효 수명을 연장할 수 있습니다.

**Amazon Cognito 그룹을 재사용할 수 있음**  
Amazon Verified Permissions는 사용자 ID 또는 액세스 토큰의 `cognito:groups` 클레임에서 사용자 풀 사용자의 그룹 멤버십을 결정합니다. 이 클레임의 값은 사용자가 속한 사용자 풀 그룹의 기억하기 쉬운 이름 배열입니다. 사용자 풀 그룹을 고유 식별자와 연결할 수 없습니다.  
정책 스토어에 동일한 이름으로 삭제하고 다시 생성하는 사용자 풀 그룹은 동일한 그룹과 동일합니다. 사용자 풀에서 그룹을 삭제할 때 정책 스토어에서 그룹에 대한 모든 참조를 삭제합니다.

**API에서 파생된 네임스페이스 및 스키마는 point-in-time**  
Verified Permissions는 *특정* 시점에 API를 캡처합니다. 정책 스토어를 생성할 때만 API를 쿼리합니다. API의 스키마 또는 이름이 변경되면 정책 저장소 및 Lambda 권한 부여자를 업데이트하거나 새 API 연결 정책 저장소를 생성해야 합니다. Verified Permissions는 API 이름에서 정책 스토어 [네임스페이스](https://docs.cedarpolicy.com/schema/schema.html#schema-namespace)를 파생합니다.

**Lambda 함수에는 VPC 구성이 없습니다.**  
API 권한 부여자에 대해 Verified Permissions가 생성하는 Lambda 함수는 기본 VPC에서 시작됩니다. 기본적으로 입니다. 프라이빗 VPCs로 제한된 네트워크 액세스 권한이 있는 APIs는 Verified Permissions로 액세스 요청을 승인하는 Lambda 함수와 통신할 수 없습니다.

**Verified Permissions는 CloudFormation에 권한 부여자 리소스를 배포합니다.**  
API 연결 정책 스토어를 생성하려면 Verified Permissions 콘솔에 권한이 AWS 높은 보안 주체에 로그인해야 합니다. 이 사용자는 여러에 리소스를 생성하는 CloudFormation 스택을 배포합니다 AWS 서비스. 이 보안 주체는 Verified Permissions, IAM Lambda 및에서 리소스를 추가하고 수정할 수 있는 권한이 있어야 합니다 API Gateway. 이러한 자격 증명을 조직의 다른 관리자와 공유하지 않는 것이 가장 좋습니다.  
Verified Permissions가 생성하는 리소스에 대한 개요는 [를 사용하여 프로덕션으로 전환 AWS CloudFormation](policy-stores-api-userpool-considerations-production.md) 섹션을 참조하세요.

## 속성 기반 액세스 제어(ABAC) 추가
<a name="policy-stores-api-userpool-abac"></a>

IdP가 있는 일반적인 인증 세션은 ID 및 액세스 토큰을 반환합니다. 애플리케이션 요청에서 이러한 토큰 유형 중 하나를 보유자 토큰으로 API에 전달할 수 있습니다. 정책 스토어를 생성할 때의 선택에 따라 Verified Permissions는 두 가지 유형의 토큰 중 하나를 기대합니다. 두 유형 모두 사용자의 그룹 멤버십에 대한 정보를 포함합니다. 의 토큰 유형에 대한 자세한 내용은 *Amazon Cognito 개발자 안내서*의 사용자 풀과 함께 토큰 사용을 Amazon Cognito참조하세요. [https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html](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](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
<a name="policy-stores-api-userpool-considerations-production"></a>

API 연결 정책 스토어는 API Gateway API에 대한 권한 부여 모델을 빠르게 구축하는 방법입니다. 애플리케이션의 권한 부여 구성 요소에 대한 테스트 환경 역할을 하도록 설계되었습니다. 테스트 정책 스토어를 생성한 후 정책, 스키마 및 Lambda 권한 부여자를 구체화하는 데 시간을 할애합니다.

API의 아키텍처를 조정하려면 정책 스토어 스키마 및 정책을 동등하게 조정해야 할 수 있습니다. API 연결 정책 스토어는 API 아키텍처에서 스키마를 자동으로 업데이트하지 않습니다. 확인 권한은 정책 스토어를 생성할 때만 API를 폴링합니다. API가 충분히 변경되면 새 정책 스토어로 프로세스를 반복해야 할 수 있습니다.

애플리케이션 및 권한 부여 모델을 프로덕션에 배포할 준비가 되면 자동화 프로세스와 함께 개발한 API 연결 정책 스토어를 통합합니다. 가장 좋은 방법은 정책 스토어 스키마와 정책을 다른 AWS 계정 및에 배포할 수 있는 AWS CloudFormation 템플릿으로 내보내는 것입니다 AWS 리전.

API 연결 정책 스토어 프로세스의 결과는 초기 정책 스토어와 Lambda 권한 부여자입니다. Lambda 권한 부여자에는 여러 종속 리소스가 있습니다. Verified Permissions는 이러한 리소스를 자동으로 생성된 CloudFormation 스택에 배포합니다. 프로덕션에 배포하려면 정책 스토어와 Lambda 권한 부여자 리소스를 템플릿으로 수집해야 합니다. API 연결 정책 스토어는 다음 리소스로 구성됩니다.<a name="policy-stores-api-userpool-considerations-production-resources"></a>

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), [AWS::IAM::Role](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html), [AWS::IAM::Policy](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-policy.html), [AWS::ApiGateway::Authorizer](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-apigateway-authorizer.html), [AWS::Lambda::Permission](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-lambda-permission.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 연결 정책 스토어 문제 해결
<a name="policy-stores-api-userpool-considerations-troubleshooting"></a>

Amazon Verified Permissions API 연결 정책 스토어를 빌드할 때 일반적인 문제를 진단하고 해결하는 데 도움이 되도록 여기의 정보를 사용하세요.

**Topics**
+ [정책을 업데이트했지만 권한 부여 결정이 변경되지 않음](#policy-stores-api-userpool-considerations-troubleshooting-update-didnt-change)
+ [API에 Lambda 권한 부여자를 연결했지만 권한 부여 요청을 생성하지 않습니다.](#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)

## 정책을 업데이트했지만 권한 부여 결정이 변경되지 않음
<a name="policy-stores-api-userpool-considerations-troubleshooting-update-didnt-change"></a>

기본적으로 Verified Permissions는 120초 동안 권한 부여 결정을 캐싱하도록 Lambda 권한 부여자를 구성합니다. 2분 후에 다시 시도하거나 권한 부여자의 캐시를 비활성화합니다. 자세한 내용은 *Amazon API Gateway * [API Gateway 개발자 안내서의 API 캐싱 활성화를 참조하세요](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-caching.html).

## API에 Lambda 권한 부여자를 연결했지만 권한 부여 요청을 생성하지 않습니다.
<a name="policy-stores-api-userpool-considerations-troubleshooting-attached-not-deployed"></a>

요청 처리를 시작하려면 권한 부여자를 연결한 API 단계를 배포해야 합니다. 자세한 내용은 *Amazon API Gateway * [API Gateway 개발자 안내서의 REST API 배포](https://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-deploy-api.html)를 참조하세요.

## 예상치 못한 권한 부여 결정을 받았으며 권한 부여 로직을 검토하고 싶습니다.
<a name="policy-stores-api-userpool-considerations-troubleshooting-review-code"></a>

API 연결 정책 스토어 프로세스는 권한 부여자를 위한 Lambda 함수를 생성합니다. Verified Permissions는 권한 부여 결정의 로직을 권한 부여자 함수에 자동으로 빌드합니다. 정책 스토어를 생성한 후 돌아가 함수의 로직을 검토하고 업데이트할 수 있습니다.

 AWS CloudFormation 콘솔에서 Lambda 함수를 찾으려면 새 정책 스토어의 **개요** 페이지에서 **배포 확인** 버튼을 선택합니다.

 AWS Lambda 콘솔에서 함수를 찾을 수도 있습니다. 정책 스토어 AWS 리전 의에서 콘솔로 이동하여 접두사가 인 함수 이름을 검색합니다`AVPAuthorizerLambda`. API 연결 정책 스토어를 두 개 이상 생성한 경우 함수의 **마지막 수정** 시간을 사용하여 이를 정책 스토어 생성과 상호 연관시킵니다.

## Lambda 권한 부여자에서 로그를 찾고 싶습니다.
<a name="policy-stores-api-userpool-considerations-troubleshooting-find-logs"></a>

Lambda 함수는 지표를 수집하고 Amazon CloudWatch에 호출 결과를 기록합니다. 로그를 검토하려면 Lambda 콘솔에서 [함수를 찾아](#policy-stores-api-userpool-considerations-troubleshooting-review-code) **모니터** 탭을 선택합니다. **CloudWatch 로그 보기를** 선택하고 로그 그룹의 항목을 검토합니다.

Lambda 함수 로그에 대한 자세한 내용은 *AWS Lambda 개발자 안내서*의 [에서 Amazon CloudWatch Logs 사용을 AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/monitoring-cloudwatchlogs.html) 참조하세요.

## Lambda 권한 부여자가 존재하지 않음
<a name="policy-stores-api-userpool-considerations-troubleshooting-didnt-deploy"></a>

API 연결 정책 스토어 설정을 완료한 후에는 Lambda 권한 부여자를 API에 연결해야 합니다. API Gateway 콘솔에서 권한 부여자를 찾을 수 없는 경우 정책 스토어의 추가 리소스가 실패했거나 아직 배포되지 않았을 수 있습니다. API 연결 정책 스토어는 이러한 리소스를 CloudFormation 스택에 배포합니다.

Verified Permissions는 생성 프로세스 종료 시 **배포 확인** 레이블이 있는 링크를 표시합니다. 이미이 화면에서 다른 곳으로 이동한 경우 CloudFormation 콘솔로 이동하여 최근 스택에서 접두사가 붙은 이름을 검색합니다`AVPAuthorizer-<policy store ID>`. CloudFormation은 스택 배포의 출력에 중요한 문제 해결 정보를 제공합니다.

CloudFormation 스택 문제 해결에 대한 도움말은 *AWS CloudFormation 사용 설명서*의 [ CloudFormation 문제 해결을 참조하세요](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html).

## API가 프라이빗 VPC에 있으며 권한 부여자를 호출할 수 없음
<a name="policy-stores-api-userpool-considerations-troubleshooting-in-a-vpc"></a>

Verified Permissions는 VPC 엔드포인트를 통한 Lambda 권한 부여자에 대한 액세스를 지원하지 않습니다. API와 권한 부여자 역할을 하는 Lambda 함수 간에 네트워크 경로를 열어야 합니다.

## 권한 부여 모델에서 추가 사용자 속성을 처리하고 싶습니다.
<a name="policy-stores-api-userpool-considerations-troubleshooting-fgac"></a>

API 연결 정책 스토어 프로세스는 사용자 토큰의 그룹 클레임에서 Verified Permissions 정책을 파생합니다. 추가 사용자 속성을 고려하도록 권한 부여 모델을 업데이트하려면 해당 속성을 정책에 통합합니다.

Amazon Cognito 사용자 풀의 ID 및 액세스 토큰에 있는 여러 클레임을 Verified Permissions 정책 설명에 매핑할 수 있습니다. 예를 들어 대부분의 사용자는 ID 토큰에 `email` 클레임이 있습니다. 자격 증명 소스의 클레임을 정책에 추가하는 방법에 대한 자세한 내용은 [스키마에 Amazon Cognito 토큰 매핑](cognito-map-token-to-schema.md) 및 스키[마에 OIDC 토큰 매핑을](oidc-map-token-to-schema.md) 참조하세요.

## 새 작업, 작업 컨텍스트 속성 또는 리소스 속성을 추가하려고 함
<a name="policy-stores-api-userpool-considerations-troubleshooting-action-resource-attributes"></a>

API 연결 정책 스토어와 생성하는 Lambda 권한 부여자는 point-in-time 리소스입니다. 생성 시 API의 상태를 반영합니다. 정책 스토어 스키마는 작업에 컨텍스트 속성이나 기본 `Application` 리소스에 속성 또는 상위 속성을 할당하지 않습니다.

API에 경로 및 메서드와 같은 작업을 추가할 때 새 작업을 인식하도록 정책 스토어를 업데이트해야 합니다. 또한 새 작업에 대한 권한 부여 요청을 처리하도록 Lambda 권한 부여자를 업데이트해야 합니다. [새 정책 스토어로 다시 시작](policy-stores-create.md)하거나 기존 정책 스토어를 업데이트할 수 있습니다.

기존 정책 스토어를 업데이트하려면 [함수를 찾습니다](#policy-stores-api-userpool-considerations-troubleshooting-review-code). 자동으로 생성된 함수에서 로직을 검사하고 업데이트하여 새 작업, 속성 또는 컨텍스트를 처리합니다. 그런 다음 [스키마를 편집](schema-edit.md)하여 새 작업과 속성을 포함합니다.

# 정책 스토어 삭제
<a name="policy-stores-delete"></a>

 AWS Management Console 또는를 사용하여 Amazon Verified Permissions 정책 스토어를 삭제할 수 있습니다 AWS CLI. 정책 스토어를 삭제하면 스키마와 정책 스토어의 정책 및 정책 템플릿이 영구적으로 삭제됩니다. 삭제된 정책 스토어와 연결된 모든 정책 스토어 별칭도 삭제됩니다.

삭제 방지 기능은 정책 스토어의 우발적 삭제를 방지합니다. 를 통해 생성된 모든 새 정책 스토어에서 삭제 방지가 활성화됩니다 AWS Management Console. 반대로 API 또는 SDK 직접 호출을 통해 생성된 모든 정책 저장소에 대해서는 비활성화됩니다.

다음과 같은 이유로 정책 스토어를 삭제할 수 있습니다.
+ 지정된 리전에서 사용 가능한 정책 스토어의 할당량에 도달했습니다. 자세한 내용은 [리소스 할당량](quotas.md#quotas-resources) 단원을 참조하십시오.
+ 다중 테넌트 애플리케이션에서 더 이상 테넌트를 지원하지 않으므로 더 이상 해당 정책 스토어가 필요하지 않습니다.

------
#### [ AWS Management Console ]

**정책 저장소 삭제**

1. [Verified Permissions 콘솔](https://console.aws.amazon.com/verifiedpermissions/)을 엽니다. 정책 스토어를 선택합니다.

1. 왼쪽의 탐색 창에서 **설정**을 선택합니다.

1. **이 정책 스토어 삭제**를 선택합니다.

1. 텍스트 상자에 `delete`를 입력하고 **삭제**를 선택합니다.
**참고**  
삭제 방지가 활성화된 경우 **삭제**를 선택하려면 먼저 삭제 방지를 비활성화해야 합니다. 비활성화하려면 **삭제 방지 비활성화**를 선택합니다.

------
#### [ AWS CLI ]

**정책 저장소 삭제**  
를 삭제하려는 정책 스토어 ID`PSEXAMPLEabcdefg111111`로 바꾸는 `delete-policy-store` 작업을 사용하여 정책 스토어를 삭제할 수 있습니다.

```
$ aws verifiedpermissions delete-policy-store \
    --policy-store-id PSEXAMPLEabcdefg111111
```

성공하면 이 명령은 출력을 생성하지 않습니다.

**참고**  
이 정책 스토어에 대해 삭제 방지가 활성화된 경우 먼저 `update-policy-store` 작업을 실행하고 삭제 방지를 비활성화해야 합니다.  

```
aws verifiedpermissions update-policy-store \
    --deletion-protection "DISABLED" \
    --policy-store-id PSEXAMPLEabcdefg111111
```

------