# AWS 적용 코드 로직이 액세스 허용 또는 거부 요청을 평가하는 방법 AWS 적용 코드 로직 AWS 적용 코드는 AWS로 전송된 요청을 허용할지 거부할지 결정합니다. AWS에서는 요청 컨텍스트에 적용될 수 있는 모든 정책을 평가합니다. 다음은 AWS 정책 평가 논리의 요약입니다. + 기본적으로 모든 요청이 암시적으로 거부됩니다. 단, 전체 액세스 권한이 있는 AWS 계정 루트 사용자는 예외입니다. + 요청이 허용되려면 아래 평가 로직에 따라 정책 또는 정책 세트에서 명시적으로 허용해야 합니다. + 명시적 거부는 명시적 허용을 재정의합니다. 정책 평가는 요청이 단일 계정 내에 있는지 아니면 교차 계정 요청 내에 있는지에 따라 달라질 수 있습니다. 단일 계정 내의 IAM 역할 또는 사용자에 대한 정책 평가 결정 방법에 대한 자세한 내용은 [단일 계정 내 요청에 대한 정책 평가](reference_policies_evaluation-logic_policy-eval-basics.md) 섹션을 참조하세요. 교차 계정 요청에 대한 정책 평가 결정 방법에 대한 자세한 내용은 [Cross-account policy evaluation logic](reference_policies_evaluation-logic-cross-account.md) 섹션을 참조하세요. + **거부 평가** - 기본적으로 모든 요청이 거부됩니다. 이를 [묵시적 거부](reference_policies_evaluation-logic_AccessPolicyLanguage_Interplay.md)라고 합니다. AWS 적용 코드는 해당 요청에 적용될 수 있는 계정 내의 모든 정책을 평가합니다. 여기에는 AWS Organizations SCP 및 RCP, 리소스 기반 정책, ID 기반 정책, IAM 권한 경계 및 세션 정책이 포함됩니다. 이런 모든 정책에서 적용 코드는 해당 요청에 적용되는 `Deny` 설명문을 찾습니다. 이를 [명시적 거부](reference_policies_evaluation-logic_AccessPolicyLanguage_Interplay.md)라고 합니다. 적용되는 명시적 거부가 하나라도 발견되면 적용 코드는 최종 **거부** 결정을 반환합니다. 명시적 거부가 없으면 적용 코드 평가가 계속됩니다. + **AWS Organizations SCP** - 적용 코드가 요청에 적용되는 AWS Organizations 리소스 제어 정책(RCP)을 평가합니다. RCP는 RCP가 연결된 계정의 리소스에 적용됩니다. 적용 코드가 RCP에서 적용 가능한 `Allow` 문을 찾지 못하면 적용 코드는 **거부**라는 최종 결정을 반환합니다. `RCPFullAWSAccess`라는 AWS 관리형 정책은 루트, 각 OU, RCPs가 활성화된 AWS 계정 경우를 포함하여 조직의 모든 엔터티에 자동으로 생성되고 연결됩니다. `RCPFullAWSAccess`는 분리할 수 없으므로 항상 `Allow` 문이 있습니다. RCP가 없거나 요청한 작업이 RCP에서 허용된 경우 적용 코드 평가가 계속됩니다. + **AWS Organizations SCP** - 적용 코드가 요청에 적용되는 AWS Organizations 서비스 제어 정책(SCP)을 평가합니다. SCP는 SCP가 연결된 계정의 보안 주체에 적용됩니다. 적용 코드가 SCP에서 적용 가능한 `Allow` 문을 찾지 못하면 적용 코드는 **거부**라는 최종 결정을 반환합니다. SCP가 없거나 요청한 작업이 SCP에서 허용된 경우 적용 코드 평가가 계속됩니다. + **리소스 기반 정책** - 동일한 계정 내에서 리소스 기반 정책은 리소스에 액세스하는 보안 주체의 유형과 리소스 기반 정책에서 허용되는 보안 주체에 따라 정책 평가에 다르게 영향을 줍니다. 보안 주체 유형에 따라 자격 증명 기반 정책, 권한 경계 또는 세션 정책에 암시적 거부가 있는 경우에도 리소스 기반 정책의 `Allow`은(는) `Allow`의 최종 결정을 내릴 수 있습니다. 대부분 리소스의 경우, 액세스 권한을 부여하는 ID 기반 정책 또는 리소스 기반 정책의 위탁자에 대한 명시적 `Allow`만 필요합니다. [IAM 역할 신뢰 정책](access_policies-cross-account-resource-access.md#access_policies-cross-account-delegating-resource-based-policies)과 [KMS 키 정책](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html)은 [보안 주체](reference_policies_elements_principal.md)에 대한 액세스 권한을 명시적으로 허용해야 하므로 이 로직의 예외입니다. IAM 및 AWS KMS 이외의 서비스에 대한 리소스 기반 정책도 동일한 계정 내에서 명시적 `Allow` 문을 사용하여 액세스 권한을 부여해야 할 수 있습니다. 자세한 내용은 사용 중인 특정 서비스의 설명서를 참조하세요. 단일 계정 정책 평가 요청의 경우 지정한 위탁자가 IAM 사용자, IAM 역할 또는 세션 위탁자인 경우 리소스 기반 정책 로직이 기타 정책 유형과 다릅니다. 세션 보안 주체에는 [IAM 역할 세션](reference_policies_elements_principal.md#principal-role-session) 또는 [AWS STS 페더레이션 사용자 보안 주체](reference_policies_elements_principal.md#sts-session-principals)가 포함됩니다. 리소스 기반 정책이 요청을 수행하는 IAM 사용자 또는 세션 보안 주체에 직접 권한을 부여하는 경우, 자격 증명 기반 정책, 권한 경계 또는 세션 정책에서 암시적 거부가 최종 결정에 영향을 주지 않습니다. + **IAM 역할** - IAM 역할 ARN에 권한을 부여하는 리소스 기반 정책은 권한 경계 또는 세션 정책의 암시적 거부에 의해 제한됩니다. Principal 요소나 `aws:PrincipalArn` 조건 키에 역할 ARN을 지정할 수 있습니다. 두 경우 모두 요청을 하는 보안 주체는 **IAM 역할 세션**입니다. 자격 증명 기반 정책에 명시적 거부가 포함되지 않는 한, 권한 경계와 세션 정책은 Principal 요소에서 와일드카드(\$1)와 함께 `aws:PrincipalArn` 조건 키를 사용하여 부여한 권한을 제한하지 않습니다. 자세한 내용은 [IAM 역할 보안 주체](reference_policies_elements_principal.md#principal-roles) 섹션을 참조하세요. **역할 ARN 예** ``` arn:aws:iam::111122223333:role/examplerole ``` + **IAM 역할 세션** - 동일한 계정 내에서 IAM 역할 세션 ARN에 권한을 부여하는 리소스 기반 정책은 수임된 역할 세션에 직접 권한을 부여합니다. 세션에 직접 부여된 사용 권한은 자격 증명 기반 정책, 권한 경계 또는 세션 정책의 암시적 거부에 의해 제한되지 않습니다. 역할을 맡고 요청을 할 때 요청을 수행하는 보안 주체는 역할 자체의 ARN이 아니라 IAM 역할 세션 ARN입니다. 자세한 내용은 [역할 세션 보안 주체](reference_policies_elements_principal.md#principal-role-session) 섹션을 참조하세요. **역할 세션 ARN 예** ``` arn:aws:sts::111122223333:assumed-role/examplerole/examplerolesessionname ``` + **IAM 사용자** - 동일한 계정 내에서 IAM 사용자 ARN(페더레이션 사용자 세션이 아님)에게 권한을 부여하는 리소스 기반 정책은 자격 증명 기반 정책 또는 권한 경계에서 암시적 거부에 의해 제한되지 않습니다. **IAM 사용자 ARN 예** ``` arn:aws:iam::111122223333:user/exampleuser ``` + ****AWS STS 페더레이션 사용자 보안 주체 - 페더레이션 사용자 세션은 [`GetFederationToken`](id_credentials_temp_request.md#api_getfederationtoken) 호출을 통해 생성된 세션입니다. 페더레이션 사용자가 요청을 할 때 요청을 수행하는 보안 주체는 페더레이션된 IAM 사용자의 ARN이 아니라 페더레이션 사용자 ARN입니다. 동일한 계정 내에서 페더레이션 사용자 ARN에게 권한을 부여하는 리소스 기반 정책은 세션에 직접 권한을 부여합니다. 세션에 직접 부여된 사용 권한은 자격 증명 기반 정책, 권한 경계 또는 세션 정책의 암시적 거부에 의해 제한되지 않습니다. 그러나 리소스 기반 정책이 페더레이션한 IAM 사용자의 ARN에 권한을 부여하는 경우, 세션 중에 페더레이션 사용자가 요청한 요청은 권한 경계 또는 세션 정책의 암시적 거부에 의해 제한됩니다. ****페더레이션 사용자 세션 ARN 예제 ``` arn:aws:sts::111122223333:federated-user/exampleuser ``` + **ID 기반 정책** - 적용 코드는 위탁자에 대한 ID 기반 정책을 확인합니다. IAM 사용자의 경우 이러한 정책에는 사용자 정책과 사용자가 속한 그룹의 정책이 포함됩니다. ID 기반 정책이 없거나 ID 기반 정책에 요청된 작업을 허용하는 문이 없으면 요청은 암시적으로 거부되고 적용 코드는 최종 결정으로 **거부**를 반환합니다. 적용 가능한 ID 기반 정책에서 요청한 작업을 허용하는 설명문이 있는 경우 코드 평가가 계속됩니다. + **IAM 권한 경계** - 적용 코드가 위탁자에 사용되는 IAM 엔터티에 권한 경계가 있는지 여부를 확인합니다. 권한 경계를 설정하는 데 사용되는 정책에서 요청한 작업을 허용하지 않는 경우 요청이 묵시적으로 거부됩니다. 적용 코드가 최종 **거부** 결정을 반환합니다. 권한 경계가 없거나 요청한 작업이 권한 경계에서 허용된 경우 코드 평가가 계속됩니다. + **세션 정책** - 적용 코드에서는 그런 다음에 위탁자가 세션 위탁자인지 확인합니다. 세션 보안 주체에는 IAM 역할 세션 또는 AWS STS 페더레이션 사용자 세션이 포함됩니다. 보안 주체가 세션 보안 주체가 아닌 경우 적용 코드는 **허용** 최종 결정을 반환합니다. 세션 위탁자의 경우 적용 코드는 요청에 세션 정책이 전달되었는지 여부를 확인합니다. AWS CLI 또는 AWS API를 사용하는 동안 세션 정책을 전달하여 역할이나 AWS STS 페더레이션 사용자 보안 주체에 대한 임시 자격 증명을 가져올 수 있습니다. 세션 정책을 통과하지 못한 경우 기본 세션 정책이 생성되고 적용 코드가 최종 결정으로 **허용**을 반환합니다. + 세션 정책이 있지만 요청한 작업이 세션 정책에서 허용되지 않는 경우 해당 요청이 암시적으로 거부됩니다. 적용 코드가 최종 **거부** 결정을 반환합니다. + 적용 코드가 위탁자가 역할 세션인지 확인합니다. 보안 주체가 역할 세션인 경우 요청은 **Allow(허용됨)**입니다. 그렇지 않으면, 요청은 암시적으로 거부되며 적용 코드에서는 **거부**의 최종 결정을 반환합니다. + 세션 정책이 있고 요청한 작업을 허용한 경우, 적용 코드에서는 **Allow**(허용)의 최종 결정을 반환합니다. # 단일 계정 내 요청에 대한 정책 평가 단일 계정 정책 평가 ## IAM 역할에 대한 정책 평가 다음 흐름도는 단일 계정 내의 IAM 역할에 대한 정책 평가 결정 방법에 대한 세부 정보를 제공합니다. ![\[단일 계정 내 IAM 역할에 대한 평가 흐름도\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/PolicyEvaluationSingleAccountRole.png) ## IAM 사용자에 대한 정책 평가 다음 흐름도는 단일 계정 내의 IAM 사용자에 대한 정책 평가 결정 방법에 대한 세부 정보를 제공합니다. ![\[단일 계정 내 IAM 사용자에 대한 평가 흐름도\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/PolicyevaluationSingleAccountUser.png) ## 자격 증명 기반 정책 및 리소스 기반 정책 평가 예제 정책 평가 예 가장 일반적인 정책 유형은 자격 증명 정책 및 리소스 기반 정책입니다. 리소스에 대한 액세스가 요청되면 AWS는 동일한 계정 내에서 **하나 이상의 Allow**에 대해 정책에서 부여한 모든 권한을 평가합니다. 정책 중 하나에 포함된 명시적 거부는 허용을 재정의합니다. **중요** 동일한 계정 내의 ID 기반 정책이나 리소스 기반 정책 중 하나는 요청을 허용하고 다른 하나는 허용하지 않는 경우에도 요청은 계속 허용됩니다. Carlos가 `carlossalazar`라는 사용자 이름을 쓰고 있고 `amzn-s3-demo-bucket-carlossalazar-logs` Amazon S3 버킷에 파일을 저장하고자 한다고 가정합니다. 또한 다음 정책이 `carlossalazar` IAM 사용자와 연결되었다고 가정합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowS3ListRead", "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:GetAccountPublicAccessBlock", "s3:ListAccessPoints", "s3:ListAllMyBuckets" ], "Resource": "arn:aws:s3:::*" }, { "Sid": "AllowS3Self", "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar/*", "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar" ] }, { "Sid": "DenyS3Logs", "Effect": "Deny", "Action": "s3:*", "Resource": "arn:aws:s3:::*log*" } ] } ``` ------ 이 정책의 `AllowS3ListRead` 설명문은 카를로스가 계정에 있는 모든 버킷 목록을 보도록 허용합니다. `AllowS3Self` 설명문은 카를로스가 그의 사용자 이름과 동일한 버킷에 모두 액세스할 수 있도록 허용합니다. `DenyS3Logs` 설명문은 카를로스가 그의 이름 아래에 있는 `log`를 통해 모든 S3 버킷의 액세스를 거부합니다. 또한, 다음 리소스 기반 정책(버킷 정책이라고 함)은 `amzn-s3-demo-bucket-carlossalazar` 버킷에 연결됩니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::123456789012:user/carlossalazar" }, "Action": "s3:*", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar/*", "arn:aws:s3:::amzn-s3-demo-bucket-carlossalazar" ] } ] } ``` ------ 이 정책은 `carlossalazar` 사용자만 `amzn-s3-demo-bucket-carlossalazar` 버킷에 액세스할 수 있도록 지정합니다. 카를로스가 `amzn-s3-demo-bucket-carlossalazar-logs` 버킷에 파일을 저장하도록 요청하면 AWS는 해당 요청에 어떤 정책을 적용할지 결정합니다. 이 경우, 자격 증명 기반 정책과 리소스 기반 정책만 적용합니다. 이들은 모두 권한 정책입니다. 어떠한 권한 경계도 적용되지 않기 때문에 평가 로직은 다음 로직으로 줄어듭니다. ![\[평가 순서도\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/EffectivePermissionsShort.png) AWS는 먼저 요청 콘텍스트에 적용되는 `Deny` 설명문을 확인합니다. 자격 증명 기반 정책은 카를로스의 로깅을 통한 모든 S3 버킷의 액세스를 명시적으로 거부하기 때문에 이를 찾습니다. 카를로스의 액세스가 거부됩니다. Carlos가 실수를 알아차리고 `amzn-s3-demo-bucket-carlossalazar` 버킷에 파일을 저장하고자 한다고 가정하세요. AWS는 `Deny` 설명문을 확인하지만 찾지 못합니다. 그러면 권한 정책을 확인합니다. 자격 증명 기반 정책과 리소스 기반 정책 모두 요청을 허용합니다. 따라서 AWS는 요청을 허용합니다. 이들 중 하나라도 설명문을 명시적으로 거부한다면 요청은 거부됩니다. 정책 유형 중 하나는 요청을 허용하고 다른 하나는 요청을 허용하지 않는 경우에도 요청은 허용됩니다. # Cross-account policy evaluation logic 크로스 계정 정책 평가 한 계정의 보안 주체가 두 번째 계정의 리소스에 액세스하도록 허용할 수 있습니다. 이를 크로스 계정 액세스라고 합니다. 교차 계정 액세스를 허용할 때 보안 주체가 존재하는 계정을 *신뢰할 수 있는* 계정이라고 합니다. 리소스가 존재하는 계정을 *신뢰하는* 계정이라고 합니다. 교차 계정 액세스를 허용하려면 공유하려는 리소스에 리소스 기반 정책을 연결해야 합니다. 또한 요청에서 보안 주체 역할을 하는 아이덴티티에 아이덴티티 기반 정책을 연결해야 합니다. 신뢰하는 계정의 리소스 기반 정책은 리소스에 액세스할 수 있는 신뢰할 수 있는 계정의 보안 주체를 지정해야 합니다. 전체 계정이나 해당 IAM 사용자, AWS STS 페더레이션 사용자 보안 주체, IAM 역할 또는 위임된 역할 세션을 지정할 수 있습니다. AWS 서비스를 보안 주체로 지정할 수도 있습니다. 자세한 내용은 [보안 주체를 지정하는 방법](reference_policies_elements_principal.md#Principal_specifying) 섹션을 참조하세요. 보안 주체의 자격 증명 기반 정책은 신뢰 서비스의 리소스에 대한 요청된 액세스를 허용해야 합니다. 리소스의 ARN을 지정하여 이를 수행할 수 있습니다. IAM에서는 리소스 기반 정책을 IAM 역할에 연결하여 다른 계정의 보안 주체가 해당 역할을 수임하도록 허용할 수 있습니다. 역할의 리소스 기반 정책을 역할 신뢰 정책이라고 합니다. 이 역할을 가정하면 허용된 보안 주체는 결과로 생성되는 임시 자격 증명을 사용하여 계정의 여러 리소스에 액세스할 수 있습니다. 이러한 액세스 권한은 역할의 자격 증명 기반 권한 정책에 정의되어 있습니다. 역할을 사용하여 교차 계정 액세스를 허용하는 것과 다른 리소스 기반 정책을 사용하여 교차 계정 액세스를 허용하는 것이 어떻게 다른지 알아보려면 [IAM의 크로스 계정 리소스 액세스](access_policies-cross-account-resource-access.md) 섹션을 참조하세요. **중요** 다른 서비스는 정책 평가 로직에 영향을 줄 수 있습니다. 예를 들어, AWS Organizations는 하나 이상의 계정에서 위탁자와 리소스에 적용할 수 있는 [서비스 제어 정책](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)과 [리소스 제어 정책](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)을 지원합니다. AWS Resource Access Manager는 위탁자가 공유되는 리소스에 대해 수행할 수 있는 작업을 제어하는 ​​[정책 조각](https://docs.aws.amazon.com/ram/latest/userguide/permissions.html)을 지원합니다. ## 교차 계정 요청의 허용 여부 결정 교차 계정 요청의 경우 신뢰할 수 있는 `AccountA`의 요청자가 자격 증명 기반 정책을 가지고 있어야 합니다. 이 정책은 신뢰하는 `AccountB`에서 리소스에 대한 요청을 생성할 수 있도록 허용해야 합니다. 또한 `AccountB`의 리소스 기반 정책은 `AccountA`의 요청자가 리소스에 액세스할 수 있도록 허용해야 합니다. 사용자가 교차 계정 요청을 하면 AWS에서는 두 가지 평가를 수행합니다. AWS는 신뢰하는 계정 및 신뢰할 수 있는 계정에서 요청을 평가합니다. 단일 계정 내에서 요청을 평가하는 방법에 대한 자세한 내용은 [AWS 적용 코드 로직이 액세스 허용 또는 거부 요청을 평가하는 방법](reference_policies_evaluation-logic_policy-eval-denyallow.md) 섹션을 참조하세요. 두 평가에서 모두 `Allow`라는 결정을 반환하는 경우에만 요청이 허용됩니다. ![\[교차 계정 평가\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/policy_cross-account-eval-simple.png) 1. 한 계정의 보안 주체가 다른 계정의 리소스에 액세스하도록 요청하는 경우 이는 교차 계정 요청입니다. 1. 요청한 보안 주체는 신뢰할 수 있는 계정(`AccountA`)에 존재합니다. AWS는 이 계정을 평가할 때 자격 증명 기반 정책 및 자격 증명 기반 정책을 제한할 수 있는 정책을 확인합니다. 자세한 내용은 [권한 경계와 함께 자격 증명 기반 정책 평가](reference_policies_evaluation-logic.md#policy-eval-basics-id-bound) 섹션을 참조하세요. 1. 요청된 리소스가 신뢰하는 계정(`AccountB`)에 존재합니다. AWS는 이 계정을 평가할 때 요청된 리소스에 연결된 리소스 기반 정책과 리소스 기반 정책을 제한할 수 있는 정책을 확인합니다. 자세한 내용은 [리소스 기반 정책과 함께 자격 증명 기반 정책 평가](reference_policies_evaluation-logic.md#policy-eval-basics-id-rdp) 섹션을 참조하세요. 1. AWS에서는 두 계정 정책 평가에서 모두 요청을 허용하는 경우에만 요청을 허용합니다. 다음 흐름도는 교차 계정 요청에 대한 정책 평가 결정이 이루어지는 방법을 보다 자세히 보여줍니다. 다시, AWS에서는 두 계정 정책 평가에서 모두 요청을 허용하는 경우에만 요청을 허용합니다. ![\[자세한 교차 계정 정책 평가\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/PolicyEvaluationCrossAccount.png) ## 교차 계정 정책 평가의 예 다음 예에서는 한 계정의 역할에 두 번째 계정의 리소스 기반 정책에 의해 권한이 부여되는 시나리오를 보여줍니다. Carlos가 계정 111111111111에 `Demo`라는 IAM 역할이 있는 개발자라고 가정합니다. 그는 계정 222222222222에 있는 `amzn-s3-demo-bucket-production-logs` Amazon S3 버킷에 파일을 저장하려고 합니다. 또한 다음 정책이 `Demo` IAM 역할과 연결되었다고 가정합니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowS3ListRead", "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "*" }, { "Sid": "AllowS3ProductionObjectActions", "Effect": "Allow", "Action": "s3:*Object*", "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-production/*" }, { "Sid": "DenyS3Logs", "Effect": "Deny", "Action": "s3:*", "Resource": [ "arn:aws:s3:::*log*", "arn:aws:s3:::*log*/*" ] } ] } ``` ------ 이 정책의 `AllowS3ListRead` 문은 Carlos가 Amazon S3에 있는 모든 버킷의 목록을 보도록 허용합니다. `AllowS3ProductionObjectActions` 문은 Carlos에게 `amzn-s3-demo-bucket-production` 버킷의 객체에 대한 전체 액세스를 허용합니다. 또한, 다음 리소스 기반 정책(버킷 정책이라고 함)은 계정 222222222222의 `amzn-s3-demo-bucket-production` 버킷에 연결됩니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject*", "s3:PutObject*", "s3:ReplicateObject", "s3:RestoreObject" ], "Principal": { "AWS": "arn:aws:iam::111111111111:role/Demo" }, "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-production/*" } ] } ``` ------ 이 정책은 `Demo` 역할에 `amzn-s3-demo-bucket-production` 버킷의 객체에 대한 액세스를 허용합니다. 역할은 버킷의 객체를 생성하고 편집할 수는 있지만 삭제할 수는 없습니다. 역할은 버킷 자체를 관리할 수 없습니다. 카를로스가 `amzn-s3-demo-bucket-production-logs` 버킷에 파일을 저장하도록 요청하면 AWS는 해당 요청에 어떤 정책을 적용할지 결정합니다. 이 경우 `Demo` 역할에 연결된 ID 기반 정책이 계정 `111111111111`에 적용되는 유일한 정책입니다. 계정 `222222222222`에서는 `amzn-s3-demo-bucket-production-logs` 버킷에 연결된 리소스 기반 정책이 없습니다. AWS은 계정 `111111111111`을 평가할 때 `Deny`의 결정을 반환합니다. 이는 자격 증명 기반 정책의 `DenyS3Logs` 문이 모든 로그 버킷에 대한 액세스를 명시적으로 거부하기 때문입니다. 단일 계정 내에서 요청을 평가하는 방법에 대한 자세한 내용은 [AWS 적용 코드 로직이 액세스 허용 또는 거부 요청을 평가하는 방법](reference_policies_evaluation-logic_policy-eval-denyallow.md) 섹션을 참조하세요. 요청이 계정 중 하나에서 명시적으로 거부되기 때문에 최종 결정은 요청을 거부하는 것입니다. ![\[amzn-s3-demo-bucket-production-logs 버킷에 요청\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/policy_cross-account-eval-example.png) 카를로스가 자신의 실수를 깨닫고 `Production` 버킷에 파일을 저장하려고 시도한다고 가정합니다. AWS는 먼저 계정 `111111111111`을 확인하여 요청이 허용되는지 여부를 확인합니다. 자격 증명 기반 정책만 적용되며 요청을 허용합니다. 그리고 AWS는 계정 `222222222222`를 확인합니다. `Production` 버킷에 연결된 리소스 기반 정책만 적용되며 요청을 허용합니다. 두 계정 모두 요청을 허용하므로 최종 결정은 요청을 허용하는 것입니다. ![\[프로덕션 버킷에 요청\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/policy_cross-account-eval-example-correct.png)