Amazon Verified Permissions를 통한 권한 부여 - Amazon Cognito
API검증된 권한을 통한 권한 부여Amazon Cognito 사용자에 대한 정책 예시

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

Amazon Verified Permissions를 통한 권한 부여

Amazon Verified Permissions는 사용자가 구축하는 애플리케이션에 대한 권한 부여 서비스입니다. Amazon Cognito 사용자 풀을 자격 증명 소스로 추가하면 앱에서 허용 또는 거부 결정을 위해 사용자 풀 액세스 또는 자격 증명(ID) 토큰을 Verified Permissions에 전달할 수 있습니다. Verified Permissions는 Cedar 정책 언어로 작성한 정책을 기반으로 사용자의 속성과 요청 컨텍스트를 고려합니다. 요청 컨텍스트에는 요청한 문서, 이미지 또는 기타 리소스의 식별자와 사용자가 리소스에 대해 수행하려는 작업이 포함될 수 있습니다.

앱은 또는 요청의 검증된 권한에 IsAuthorizedWithToken대한 사용자 ID 또는 액세스 토큰을 제공할 수 있습니다. BatchIsAuthorizedWithTokenAPI 이러한 API 작업은 사용자를 Principal A로 받아들이고 Resource 사용자가 액세스하려는 Action 서버에 대한 권한 부여 결정을 내립니다. 추가 사용자 Context 지정은 세부적인 액세스 결정에 기여할 수 있습니다.

앱이 IsAuthorizedWithToken API 요청에서 토큰을 제시하면 검증된 권한은 다음 검증을 수행합니다.

  1. 사용자 풀이 요청된 정책 스토어에 대해 구성된 Verified Permissions 자격 증명 소스입니다.

  2. 액세스 또는 자격 증명 토큰의 client_id 또는 aud 클레임이 각각 Verified Permissions에 제공한 사용자 풀 앱 클라이언트 ID와 일치합니다. 이 클레임을 확인하려면 Verified Permissions 자격 증명 소스에서 클라이언트 ID 검증 구성 작업을 수행해야 합니다.

  3. 토큰이 만료되지 않았습니다.

  4. 토큰의 token_use 클레임 값은 IsAuthorizedWithToken 전달한 매개변수와 일치합니다. token_use클레임을 파라미터에 전달한 access 경우와 accessToken 파라미터에 전달한 id 경우에만 클레임이 identityToken 유효합니다.

  5. 토큰의 서명은 사용자 풀의 게시된 JSON 웹 키 (JWKs) 에서 가져옵니다. 광고를 JWKs 볼 수 있습니다https://cognito-idp.Region.amazonaws.com/your user pool ID/.well-known/jwks.json.

취소된 토큰 및 삭제된 사용자

Verified Permissions는 자격 증명 소스와 사용자 토큰의 만료 시간을 통해 알고 있는 정보만 검증합니다. Verified Permissions는 토큰 취소 또는 사용자 존재 여부를 확인하지 않습니다. 사용자 토큰을 취소했거나 사용자 풀에서 사용자 프로필을 삭제한 경우에도 Verified Permissions는 토큰이 만료될 때까지 토큰을 유효한 것으로 간주합니다.

정책 평가

사용자 풀을 정책 스토어의 자격 증명 소스로 구성합니다. 요청에서 사용자의 토큰을 Verified Permissions에 제출하도록 앱을 구성합니다. 각 요청에 대해 Verified Permissions는 토큰의 클레임을 정책과 비교합니다. 검증된 권한 정책은 의 IAM 정책과 비슷합니다 AWS. 보안 주체, 리소스 및 작업을 선언합니다. 확인된 권한은 허용된 작업과 Allow 일치하고 Deny 명시적 작업과 일치하지 않으면 요청에 응답하고 그렇지 않으면 로 응답합니다. Deny 자세한 내용은 Amazon Verified Permissions 사용 설명서의 Amazon Verified Permissions 정책을 참조하세요.

토큰 사용자 지정

Verified Permissions에 제시하려는 사용자 주장을 변경, 추가, 제거하려면 a를 사용하여 액세스 및 ID 토큰의 콘텐츠를 사용자 지정하십시오. 사전 토큰 생성 Lambda 트리거 사전 토큰 생성 트리거를 사용하여 토큰에 클레임을 추가하고 수정할 수 있습니다. 예를 들어 데이터베이스에서 추가 사용자 속성을 쿼리하고 ID 토큰으로 인코딩할 수 있습니다.

참고

Verified Permissions가 클레임을 처리하는 방식 때문에 cognito, dev 또는 custom이라는 이름의 클레임을 사전 토큰 생성 함수에 추가하지 마세요. 이러한 예약된 클레임 접두사를 cognito:username과 같이 콜론으로 구분된 형식이 아닌 전체 클레임 이름으로 제시하면 권한 부여 요청이 실패합니다.

추가 리소스

API검증된 권한을 통한 권한 부여

ID 또는 액세스 토큰은 검증된 권한으로 API Amazon REST APIs Gateway의 백엔드 요청을 승인할 수 있습니다. 사용자 풀 및 에 대한 즉각적인 링크가 포함된 정책 저장소를 생성할 수 있습니다. API Cognito 및 API Gateway로 설정 시작 옵션을 사용하면 검증된 권한은 사용자 풀 ID 소스를 정책 스토어에 추가하고 Lambda 권한 부여자를 정책 스토어에 추가합니다. API 애플리케이션이 사용자 풀 베어러 토큰을 에 전달하면 Lambda API 권한 부여자가 검증된 권한을 호출합니다. 권한 부여자는 토큰을 보안 주체로 전달하고 요청 경로와 메서드를 작업으로 전달합니다.

다음 다이어그램은 검증된 권한이 API 있는 API 게이트웨이의 권한 부여 흐름을 보여줍니다. 자세한 내용은 Amazon 검증 권한 사용 설명서의 API-linked 정책 스토어를 참조하십시오.

Amazon 검증 권한을 통한 API 권한 부여 흐름을 보여주는 다이어그램. 애플리케이션이 Amazon API 게이트웨이에 요청을 보냅니다API. Lambda API 권한 부여자를 호출합니다. 권한 부여자는 검증된 권한을 요청합니다. API 검증된 권한은 토큰 유효성을 확인하고 승인 결정을 반환합니다.

검증된 권한은 사용자 풀 그룹을 중심으로 API 권한 부여를 구성합니다. ID와 액세스 토큰 모두 cognito:groups 클레임을 포함하므로 정책 저장소는 다양한 애플리케이션 APIs 컨텍스트에서 사용자에 대한 역할 기반 액세스 제어 (RBAC) 를 관리할 수 있습니다.

정책 저장소 설정 선택

정책 저장소에서 ID 소스를 구성할 때는 액세스 토큰을 처리할지 ID 토큰을 처리할지 여부를 선택해야 합니다. 이 결정은 정책 엔진 운영 방식에 있어 매우 중요합니다. ID 토큰에는 사용자 속성이 포함됩니다. 액세스 토큰에는 사용자 액세스 제어 정보 (범위) 가 포함됩니다. OAuth 두 토큰 유형 모두 그룹 구성원 정보를 포함하지만 일반적으로 Verified Permissions 정책 저장소가 RBAC 있는 액세스 토큰을 사용하는 것이 좋습니다. 액세스 토큰은 권한 부여 결정에 영향을 줄 수 있는 범위를 통해 그룹 구성원 자격을 높여줍니다. 액세스 토큰의 클레임은 권한 부여 요청의 컨텍스트가 됩니다.

또한 사용자 풀을 ID 소스로 구성할 때 사용자 및 그룹 엔티티 유형을 구성해야 합니다. 엔티티 유형은 검증된 권한 정책에서 참조할 수 있는 보안 주체, 작업 및 리소스 식별자입니다. 정책 저장소의 엔티티는 멤버 자격 관계를 가질 수 있으며, 여기서 한 엔티티는 상위 엔티티의 구성원이 될 수 있습니다. 멤버십이 있으면 주도자 그룹, 작업 그룹 및 리소스 그룹을 참조할 수 있습니다. 사용자 풀 그룹의 경우 지정하는 사용자 엔티티 유형이 그룹 엔티티 유형의 멤버여야 합니다. API연결된 정책 저장소를 설정하거나 Verified Permissions 콘솔의 설정 안내를 따르는 경우 정책 저장소는 자동으로 이 상위-구성원 관계를 가집니다.

ID 토큰은 속성 기반 액세스 제어 () RBAC 와 결합할 수 있습니다. ABAC API연결된 정책 저장소를 생성한 후에는 사용자 특성 및 그룹 구성원으로 정책을 개선할 수 있습니다. ID 토큰의 특성 클레임은 권한 부여 요청의 주요 특성이 됩니다. 정책은 주요 특성에 따라 권한 부여 결정을 내릴 수 있습니다.

제공하는 허용 가능한 앱 클라이언트 목록과 일치하는 aud 또는 client_id 클레임이 있는 토큰을 수락하도록 정책 저장소를 구성할 수도 있습니다.

역할 API 기반 권한 부여에 대한 예제 정책

다음 예제 정책은 예를 들어 Verified Permissions 정책 저장소를 설치하여 만든 것입니다. PetStoreRESTAPI 

permit(
  principal in PetStore::UserGroup::"us-east-1_EXAMPLE|MyGroup",
  action in [ PetStore::Action::"get /pets", PetStore::Action::"get /pets/{petId}" ],
  resource
  );

다음과 같은 경우 검증된 권한은 애플리케이션의 권한 부여 요청에 Allow 결정을 반환합니다.

  1. 애플리케이션이 Authorization 헤더의 ID 또는 액세스 토큰을 베어러 토큰으로 전달했습니다.

  2. 애플리케이션이 문자열이 MyGroup 포함된 cognito:groups 클레임과 함께 토큰을 전달했습니다.

  3. 애플리케이션에서 예를 들어, https://myapi.example.com/pets 또는 를 HTTP GET https://myapi.example.com/pets/scrappy 요청했습니다.

Amazon Cognito 사용자에 대한 정책 예시

사용자 풀은 요청 이외의 조건으로 검증된 권한에 대한 권한 부여 API 요청을 생성할 수도 있습니다. 애플리케이션의 모든 액세스 제어 결정을 정책 저장소에 제출할 수 있습니다. 예를 들어 요청이 네트워크를 전송하기 전에 속성 기반 액세스 제어로 Amazon DynamoDB 또는 Amazon S3 보안을 보완하여 할당량 사용을 줄일 수 있습니다.

다음 예에서는 Cedar 정책 언어를 사용하여 하나의 사용자 풀 앱 클라이언트로 인증하는 Finance 사용자가 example_image.png를 읽고 쓸 수 있도록 허용합니다. 앱 사용자인 John은 앱 클라이언트로부터 ID 토큰을 수신하여 URL 승인이 필요한 GET 요청에 따라 이를 전달합니다. https://example.com/images/example_image.png John의 ID 토큰에는 사용자 풀 앱 클라이언트 ID 1234567890example에 대한 aud 클레임이 있습니다. 또한 사전 토큰 생성 Lambda 함수가 John에 대한 값 Finance1234를 가진 새 클레임 costCenter를 삽입했습니다.

permit (
   principal,
   actions in [ExampleCorp::Action::"readFile", "writeFile"],
   resource == ExampleCorp::Photo::"example_image.png"
)
when {
   principal.aud == "1234567890example" &&
   principal.custom.costCenter like "Finance*"
};

다음 요청 본문은 Allow 응답을 생성합니다.

{
   "accesstoken": "[John's ID token]",
   "action": {
      "actionId": "readFile",
      "actionType": "Action"
   },
   "resource": {
      "entityId": "example_image.png",
      "entityType": "Photo"
   }
}

Verified Permissions 정책에 보안 주체를 지정하려면 다음과 같은 형식을 사용합니다.

permit (
   principal == [Namespace]::[Entity]::"[user pool ID]"|"[user sub]",
   action,
   resource
);

다음은 서브가 있는 ID 또는 사용자 ID (사용자 IDus-east-1_Example) 를 가진 사용자 풀의 사용자 보안 주체 예시입니다. 973db890-092c-49e4-a9d0-912a4c0a20c7 

principal == ExampleCorp::User::"us-east-1_Example|973db890-092c-49e4-a9d0-912a4c0a20c7",

검증된 권한 정책에서 사용자 그룹을 지정하려면 다음 형식을 사용하십시오.

permit (
   principal in [Namespace]::[Group Entity]::"[Group name]",
   action,
   resource
);

다음은 예제입니다.

속성 기반 액세스 제어

앱에 대한 검증된 권한을 통한 권한 부여 및 자격 증명용 Amazon Cognito AWS 자격 증명 풀의 액세스 제어 기능에 대한 속성은 모두 속성 기반 액세스 제어 () 의 한 형태입니다. ABAC 다음은 검증된 권한과 Amazon ABAC Cognito의 기능을 비교한 것입니다. ABAC에서는 시스템이 엔티티의 속성을 검사하고 사용자가 정의한 조건에 따라 권한 부여 결정을 내립니다.

Service 프로세스 Result
Amazon Verified Permissions 사용자 풀 JWT 분석을 통해 Allow OR Deny 결정을 반환합니다. Cedar 정책 평가에 따라 애플리케이션 리소스에 대한 액세스의 성공 또는 실패 여부가 결정됩니다.
Amazon Cognito 자격 증명 풀 (액세스 제어를 위한 속성) 속성에 따라 사용자에게 세션 태그를 할당합니다. IAM정책 조건은 태그 Allow 또는 Deny 사용자 액세스를 AWS 서비스확인할 수 있습니다. IAM역할에 대한 임시 AWS 자격 증명이 있는 태그가 지정된 세션입니다.