기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # Amazon Verified Permissions 및 Cedar 정책 언어 용어 및 개념 Amazon Verified Permissions를 사용하려면 다음 개념을 이해해야 합니다. **Topics** + [권한 부여 모델](#term-authorization-model) + [권한 부여 요청](#term-authorization-request) + [권한 부여 응답](#term-authorization-response) + [고려 대상 정책](#term-considered-policies) + [컨텍스트 데이터](#term-context-data) + [결정적 정책](#term-determining-policies) + [엔터티 데이터](#term-entity-data) + [권한, 권한 부여 및 보안 주체](#term-permissions-authorization-principals) + [정책 적용](#term-policy-enforcement) + [정책 스토어](#term-policy-store) + [정책 스토어 별칭](#term-policy-store-alias) + [정책 이름](#term-policy-name) + [정책 템플릿 이름](#term-policy-template-name) + [충족 대상 정책](#term-satisfied-policies) + [Amazon Verified Permissions와 Cedar 정책 언어의 차이점](terminology-differences-avp-cedar.md) **Cedar 정책 언어 개념** + [권한 부여](https://docs.cedarpolicy.com/overview/terminology.html#authorization) + [엔터티](https://docs.cedarpolicy.com/overview/terminology.html#entity) + [그룹 및 계층](https://docs.cedarpolicy.com/overview/terminology.html#term-group) + [네임스페이스](https://docs.cedarpolicy.com/policies/validation.html#namespaces) + [정책](https://docs.cedarpolicy.com/overview/terminology.html#policy) + [정책 템플릿](https://docs.cedarpolicy.com/overview/terminology.html#policy-template) + [스키마](https://docs.cedarpolicy.com/overview/terminology.html#schema) ## 권한 부여 모델 *권한 부여 모델*은 애플리케이션이 수행하는 [권한 부여 요청](#term-authorization-request)의 범위와 이러한 요청을 평가하는 기준을 설명합니다. 이는 다양한 유형의 리소스, 해당 리소스에 대해 수행되는 작업, 해당 작업을 수행하는 보안 주체 유형에 따라 정의됩니다. 또한 이러한 작업이 수행되는 상황도 고려됩니다. *역할 기반 액세스 제어(RBAC)*는 역할을 정의하고 권한 집합과 연결하는 평가 기준입니다. 이러한 역할은 하나 이상의 자격 증명에 할당할 수 있습니다. 할당된 자격 증명은 역할에 연결된 권한을 획득하게 됩니다. 역할에 연결된 권한이 변경되면 변경 내용은 역할이 할당된 모든 자격 증명에 자동으로 영향을 미칩니다. Cedar는 보안 주체 그룹을 사용하여 RBAC 결정을 지원할 수 있습니다. *ABAC(속성 기반 액세스 제어)*는 자격 증명과 연결되는 권한을 해당 자격 증명의 속성에 따라 결정하는 평가 기준입니다. Cedar는 보안 주체의 속성을 참조하는 정책 조건을 사용하여 ABAC 결정을 지원할 수 있습니다. Cedar 정책 언어를 사용하면 속성 기반 조건을 가진 사용자 그룹에 대해 권한을 정의할 수 있으므로 RBAC와 ABAC를 단일 정책으로 결합할 수 있습니다. ## 권한 부여 요청 *권한 부여 요청*은 애플리케이션이 일련의 정책을 평가하여 보안 주체가 해당 컨텍스트에서 리소스에 대한 작업을 수행할 수 있는지 여부를 확인하기 위해 수행하는 Verified Permissions 요청입니다. ## 권한 부여 응답 *권한 부여 응답*은 [권한 부여 요청](#term-authorization-request)에 대한 응답입니다. 여기에는 허용 또는 거부 결정과 함께 결정적 정책의 ID와 같은 추가 정보가 포함됩니다. ## 고려 대상 정책 *고려 대상 정책*은 [인증 요청](#term-authorization-request)을 평가할 때 Verified Permissions이 포함하도록 선택한 전체 정책 집합입니다. ## 컨텍스트 데이터 *컨텍스트 데이터*는 평가할 추가 정보를 제공하는 속성 값입니다. ## 결정적 정책 *결정적 정책*은 [권한 부여 응답](#term-authorization-response)을 결정하는 정책입니다. 예를 들어 [충족된 정책](#term-satisfied-policies)이 두 개일 때 하나는 거부이고 다른 하나는 허용인 경우 거부 정책이 결정적 정책이 됩니다. 충족된 허용 정책이 여러 개 있고 충족된 금지 정책이 없는 경우 여러 결정적 정책이 있는 것입니다. 일치하는 정책이 없고 응답이 거부인 경우에는 결정적 정책이 없습니다. ## 엔터티 데이터 *엔터티 데이터*는 보안 주체, 작업, 리소스에 대한 데이터입니다. 정책 평가와 관련된 엔터티 데이터는 보안 주체 및 리소스의 엔터티 계층 구조 및 속성 값까지 포함하는 그룹 멤버십입니다. ## 권한, 권한 부여 및 보안 주체 Verified Permissions는 사용자가 빌드한 사용자 지정 애플리케이션 내에서 세분화된 *권한* 및 *권한 부여*를 관리합니다. *보안 주체*는 사용자 이름 또는 시스템 ID와 같은 식별자에 연결된 자격 증명을 보유한 애플리케이션의 사용자로 사용자 또는 시스템입니다. 인증 프로세스는 보안 주체가 실제로 해당 자격 증명이 맞는지 여부를 판단합니다. 이러한 자격 증명에는 해당 애플리케이션 내에서 해당 주체가 무엇을 할 수 있는지 결정하는 애플리케이션 *권한* 집합이 연결되어 있습니다. *권한 부여*는 이러한 권한을 평가하여 보안 주체가 애플리케이션에서 특정 작업을 수행할 수 있는지 여부를 결정하는 프로세스입니다. 이러한 권한은 [정책](https://docs.cedarpolicy.com/overview/terminology.html#policy)으로 표현될 수 있습니다. ## 정책 적용 *정책 적용*은 Verified Permissions 외부에서 애플리케이션 내 평가 결정을 적용하는 프로세스입니다. Verified Permissions 평가 결과로 거부가 반환되는 경우 정책 적용을 통해 보안 주체가 리소스에 액세스하지 못하도록 할 수 있습니다. ## 정책 스토어 *정책 스토어*는 정책 및 템플릿의 컨테이너입니다. 각 스토어에는 스토어에 추가된 정책을 검증하는 데 사용되는 스키마가 있습니다. 기본적으로 각 애플리케이션에는 자체 정책 스토어가 있지만 여러 애플리케이션이 단일 정책 스토어를 공유할 수 있습니다. 애플리케이션이 권한 부여 요청을 하면 해당 요청을 평가하는 데 사용된 정책 스토어를 식별합니다. 정책 스토어는 일련의 정책을 분리하는 방법을 제공하므로 다중 테넌트 애플리케이션에서 각 테넌트에 대한 스키마와 정책을 포함하는 데 사용할 수 있습니다. 단일 애플리케이션은 각 테넌트에 대해 별도의 정책 스토어를 가질 수 있습니다. [권한 부여 요청](#term-authorization-request)을 평가할 때 Verified Permissions는 해당 요청과 관련된 정책 스토어의 일부 정책만 고려합니다. 관련성은 정책 *범위*에 따라 결정됩니다. 범위는 정책이 적용되는 특정 보안 주체 및 리소스, 그리고 보안 주체가 해당 리소스에서 수행할 수 있는 작업을 식별합니다. 범위를 정의하면 고려 대상 정책의 범위를 좁혀 성능을 개선하는 데 도움이 됩니다. ## 정책 스토어 별칭 *정책 스토어 별칭*은 정책 스토어의 친숙한 이름입니다. 정책 스토어 별칭을 사용하여 `policyStoreId` 파라미터를 수락하는 Verified Permissions 작업에서 정책 스토어를 식별할 수 있습니다. 정책 스토어 별칭은 자체 ARN이 있는 독립적인 AWS 리소스입니다. ARNs 각 별칭은 한 번에 하나의 정책 저장소와 연결되며 여러 별칭을 동일한 정책 저장소와 연결할 수 있습니다. 자세한 내용은 [Amazon Verified Permissions 정책 스토어 별칭](policy-store-aliases.md) 단원을 참조하십시오. ## 정책 이름 *정책 이름은* 정책의 선택적인 표시 이름입니다. 정책 이름은 정책 스토어 내의 모든 정책에 대해 고유해야 하며 접두사가 붙어야 합니다`name/`. `policyId` 파라미터를 수락하는 컨트롤 플레인 작업에서 정책 ID 대신 정책 이름을 사용할 수 있습니다. 정책을 생성하거나 업데이트할 때 이름을 설정할 수 있습니다. `GetPolicy` 및 만 출력에 이름을 `ListPolicies` 반환합니다. ## 정책 템플릿 이름 *정책 템플릿 이름은* 정책 템플릿의 선택적인 표시 이름입니다. 정책 템플릿 이름은 정책 스토어 내의 모든 정책 템플릿에 대해 고유해야 하며 접두사가 붙어야 합니다`name/`. `policyTemplateId` 파라미터를 수락하는 컨트롤 플레인 작업에서 정책 템플릿 ID 대신 정책 템플릿 이름을 사용할 수 있습니다. 정책 템플릿을 생성하거나 업데이트할 때 이름을 설정할 수 있습니다. `GetPolicyTemplate` 및 만 출력에 이름을 `ListPolicyTemplates` 반환합니다. ## 충족 대상 정책 *충족 대상 정책*은 [권한 부여 요청](#term-authorization-request)의 매개변수와 일치하는 정책입니다. # Amazon Verified Permissions와 Cedar 정책 언어의 차이점 Amazon Verified Permissions는 Cedar 정책 언어 엔진을 사용하여 권한 부여 작업을 수행합니다. 하지만 기본 Cedar 구현과 Verified Permissions에서 확인할 수 있는 Cedar 구현 간에는 몇 가지 차이점이 있습니다. 이 항목에서는 이러한 차이점을 설명합니다. ## 네임스페이스 정의 Cedar의 Verified Permissions 구현은 기본 Cedar 구현과 다음과 같은 차이점이 있습니다. + Verified Permissions는 정책 스토어에 정의된 [스키마에서 네임스페이스](https://docs.cedarpolicy.com/schema/schema.html#namespace)를 하나만 지원합니다. + Verified Permissions에서는 빈 문자열이거나 `aws`, `amazon`또는 값을 포함하는 [네임스페이스](https://docs.cedarpolicy.com/schema/schema.html#namespace)를 생성할 수 없습니다`cedar`. ## 정책 템플릿 지원 Verified Permissions과 Cedar는 모두 범위에서 `principal` 및 `resource`에 대한 자리 표시자만 허용합니다. 하지만 Verified Permissions를 사용하려면 `principal` 및 `resource`에 제약이 있어야 합니다. 다음 정책은 Cedar에서 유효하지만 `principal`에 제약이 없기 때문에 Verified Permissions에서는 거부됩니다. ``` permit(principal, action == Action::"view", resource == ?resource); ``` 다음 두 예제에서는 `principal` 및 `resource`에 제약이 있기 때문에 Cedar와 Verified Permissions 모두에서 유효합니다. ``` permit(principal == User::"alice", action == Action::"view", resource == ?resource); ``` ``` permit(principal == ?principal, action == Action::"a", resource in ?resource); ``` ## 스키마 지원 Verified Permissions를 사용하려면 모든 스키마 JSON 키 이름이 비어 있지 않은 문자열이어야 합니다. Cedar는 속성 또는 네임스페이스와 같은 몇 가지 경우에 빈 문자열을 허용합니다. ## 작업 그룹 정의 Cedar 권한 부여 방법을 사용하려면 정책에 따라 권한 부여 요청을 평가할 때 고려해야 할 엔터티 목록이 필요합니다. 애플리케이션이 사용하는 작업 및 작업 그룹은 스키마에서 정의할 수 있습니다. 하지만 Cedar는 평가 요청의 일부로 스키마를 포함시키지 않습니다. 대신 Cedar는 사용자가 제출한 정책 및 정책 템플릿을 검증하는 데만 스키마를 사용합니다. Cedar는 평가 요청 중에 스키마를 참조하지 않으므로 스키마에 작업 그룹을 정의했더라도 권한 부여 API 작업에 전달해야 하는 엔터티 목록의 일부로 작업 그룹 목록도 포함해야 합니다. Verified Permissions는 이 작업을 사용자 대신 수행합니다. 스키마에서 정의한 모든 작업 그룹은 `IsAuthorized` 또는 `IsAuthorizedWithToken` 작업에 매개 변수로 전달하는 엔터티 목록에 자동으로 추가됩니다. ## 엔터티 형식 `entityList` 파라미터를 사용하는 Verified Permissions 엔터티의 JSON 형식은 다음과 같은 점에서 Cedar와 다릅니다. + Verified Permissions에서 JSON 객체는 모든 키-값 쌍을 이름이 `Record`인 JSON 객체로 래핑해야 합니다. + Verified Permissions의 JSON 목록은 키 이름이 `Set`이고 값이 Cedar의 원래 JSON 목록인 JSON 키-값 쌍으로 래핑되어야 합니다. + `String`, `Long`, 및 `Boolean` 유형 이름의 경우 Cedar의 각 키-값 쌍은 Verified Permissions의 JSON 객체로 대체됩니다. 객체 이름은 원래 키 이름입니다. JSON 객체 내에는 키-값 쌍이 하나 있는데, 여기서 키 이름은 스칼라 값(`String`, `Long`, 또는 `Boolean`)의 유형 이름이고 값은 Cedar 엔터티의 값입니다. + Cedar 엔터티와 Verified Permissions 엔터티의 구문 형식은 다음과 같은 측면에서 다릅니다. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/verifiedpermissions/latest/userguide/terminology-differences-avp-cedar.html) **Example - 목록** 다음 예제에서는 개체 목록이 각각 Cedar 및 Verified Permissions로 표현되는 방법을 보여줍니다. ``` [ { "number": 1 }, { "sentence": "Here is an example sentence" }, { "Question": false } ] ``` ``` { "Set": [ { "Record": { "number": { "Long": 1 } } }, { "Record": { "sentence": { "String": "Here is an example sentence" } } }, { "Record": { "question": { "Boolean": false } } } ] } ``` **Example - 정책 평가** 다음 예제에서는 Cedar 및 Verified Permissions의 권한 부여 요청에서 정책을 평가하기 위해 개체의 형식이 어떻게 지정되는지 보여줍니다. ``` [ { "uid": { "type": "PhotoApp::User", "id": "alice" }, "attrs": { "age": 25, "name": "alice", "userId": "123456789012" }, "parents": [ { "type": "PhotoApp::UserGroup", "id": "alice_friends" }, { "type": "PhotoApp::UserGroup", "id": "AVTeam" } ] }, { "uid": { "type": "PhotoApp::Photo", "id": "vacationPhoto.jpg" }, "attrs": { "private": false, "account": { "__entity": { "type": "PhotoApp::Account", "id": "ahmad" } } }, "parents": [] }, { "uid": { "type": "PhotoApp::UserGroup", "id": "alice_friends" }, "attrs": {}, "parents": [] }, { "uid": { "type": "PhotoApp::UserGroup", "id": "AVTeam" }, "attrs": {}, "parents": [] } ] ``` ``` [ { "Identifier": { "EntityType": "PhotoApp::User", "EntityId": "alice" }, "Attributes": { "age": { "Long": 25 }, "name": { "String": "alice" }, "userId": { "String": "123456789012" } }, "Parents": [ { "EntityType": "PhotoApp::UserGroup", "EntityId": "alice_friends" }, { "EntityType": "PhotoApp::UserGroup", "EntityId": "AVTeam" } ] }, { "Identifier": { "EntityType": "PhotoApp::Photo", "EntityId": "vacationPhoto.jpg" }, "Attributes": { "private": { "Boolean": false }, "account": { "EntityIdentifier": { "EntityType": "PhotoApp::Account", "EntityId": "ahmad" } } }, "Parents": [] }, { "Identifier": { "EntityType": "PhotoApp::UserGroup", "EntityId": "alice_friends" }, "Parents": [] }, { "Identifier": { "EntityType": "PhotoApp::UserGroup", "EntityId": "AVTeam" }, "Parents": [] } ] ``` ## 길이 및 크기 제한 Verified Permissions는 스키마, 정책 및 정책 템플릿을 보관하기 위한 정책 스토어 형태의 스토리지를 지원합니다. 이러한 스토리지로 인해 Verified Permissions에는 Cedar와 관련이 없는 일부 길이 및 크기 제한이 적용됩니다. | 객체 | Verified Permissions 제한(바이트 단위) | Cedar 제한 | | --- | --- | --- | | 정책 크기¹ | 10,000 | 없음 | | 인라인 정책 설명 | 150 | Cedar에는 해당 사항 없음 | | 정책 템플릿 크기 | 10,000 | 없음 | | 스키마 크기 | 100,000건 | 없음 | | 엔터티 유형 | 200 | 없음 | | 정책 ID | 64 | 없음 | | 정책 템플릿 ID | 64 | 없음 | | 엔터티 ID | 200 | 없음 | | 정책 스토어 ID | 64 | Cedar에는 해당 사항 없음 | ¹ Verified Permissions의 정책 스토어당 정책 한도는 정책 스토어에서 생성된 정책의 보안 주체, 작업 및 리소스의 합산 크기를 기준으로 합니다. 단일 리소스와 관련된 모든 정책의 총 크기는 200,000바이트를 초과할 수 없습니다. 템플릿 연결 정책의 경우 정책 템플릿의 크기가 한 번만 계산되며 각 템플릿 연결 정책을 인스턴스화하는 데 사용되는 각 매개 변수 집합의 크기를 더합니다.