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

Amazon Verified Permissions를 통한 권한 부여

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

앱은 또는 BatchIsAuthorizedWithToken API 요청의 Verified Permissions에 사용자의 자격 증명 IsAuthorizedWithToken 또는 액세스 토큰을 제공할 수 있습니다. 이러한 API 작업은 사용자를 로 수락Principal하고 액세스Resource하려는 의 Action에 대한 권한 부여 결정을 내립니다. 추가 사용자 지정은 자세한 액세스 결정에 기여할 Context 수 있습니다.

앱에서 IsAuthorizedWithToken API 요청에 토큰을 제시하면 Verified Permissions는 다음과 같은 검증을 수행합니다.

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

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

정책 평가

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

토큰 사용자 지정

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

API Verified Permissions를 사용한 권한 부여

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

다음 다이어그램은 확인된 권한이 API 있는 API 게이트웨이의 권한 부여 흐름을 보여줍니다. 자세한 내용은 Amazon Verified Permissions 사용 설명서의 API연결된 정책 스토어를 참조하세요.

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

정책 스토어 설정 선택

정책 스토어에서 자격 증명 소스를 구성할 때 액세스 또는 ID 토큰을 처리할지 여부를 선택해야 합니다. 이 결정은 정책 엔진이 작동하는 방식에 중요합니다. ID 토큰에는 사용자 속성이 포함됩니다. 액세스 토큰에는 사용자 액세스 제어 정보인 OAuth 범위가 포함됩니다. 두 토큰 유형 모두 그룹 멤버십 정보가 있지만 일반적으로 Verified Permissions 정책 스토어를 RBAC 사용하여 에 대한 액세스 토큰을 사용하는 것이 좋습니다. 액세스 토큰은 권한 부여 결정에 기여할 수 있는 범위를 가진 그룹 멤버십에 추가됩니다. 액세스 토큰의 클레임은 권한 부여 요청의 컨텍스트가 됩니다.

사용자 풀을 자격 증명 소스로 구성할 때 사용자 및 그룹 엔터티 유형도 구성해야 합니다. 엔터티 유형은 Verified Permissions 정책에서 참조할 수 있는 보안 주체, 작업 및 리소스 식별자입니다. 정책 스토어의 엔터티는 멤버십 관계를 가질 수 있으며, 여기서 한 엔터티는 상위 엔터티의 멤버일 수 있습니다. 멤버십을 사용하면 보안 주체 그룹, 작업 그룹 및 리소스 그룹을 참조할 수 있습니다. 사용자 풀 그룹의 경우 지정하는 사용자 엔터티 유형은 그룹 엔터티 유형의 구성원이어야 합니다. 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
  );

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

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

사용자 풀은 요청 이외의 조건에서 Verified Permissions에 대한 권한 부여 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
);

다음은 us-east-1_Example 하위 또는 사용자 ID가 인 사용자 풀의 사용자에 대한 예제 보안 주체입니다973db890-092c-49e4-a9d0-912a4c0a20c7.

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

Verified Permissions 정책에서 사용자 그룹을 지정하려면 다음 형식을 사용합니다.

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

다음은 예제입니다.

속성 기반 액세스 제어

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