IAM 역할 또는 사용자를 사용하여 API 호출을 요청할 때 명시적 거부 오류 메시지 문제를 해결하려면 어떻게 해야 합니까?
AWS Identity and Access Management(IAM) 역할 또는 사용자를 사용하여 API 호출을 요청할 때 명시적 거부 오류 메시지가 표시되는 문제를 해결하고 싶습니다.
간략한 설명
IAM 엔터티(역할 또는 사용자)가 API 호출을 성공적으로 수행하려면 해당 엔터티가 다음 조건을 충족해야 합니다.
- 역할 또는 사용자에게 API 호출을 요청할 수 있는 올바른 권한이 있습니다.
- 요청 컨텍스트에 적용되는 어떤 정책의 문에서도 권한이 거부되지 않습니다.
IAM 엔터티가 이러한 조건을 충족하지 않으면 API 호출이 실패하고 다음과 비슷한 (AccessDenied) 오류가 반환됩니다.
- "IAM user or role experiencing the issue: arn:XXXXXXXX:iam::XXXXXXXX:role/TestReadOnly"
- "Error: An error occurred (AccessDenied) when calling the RunInstances operation: User: arn:aws:iam::XXXXXXXX:user/tester is not authorized to perform: ec2:RunInstances on resource: role TestReadOnly with an explicit deny"
참고: 이 문서의 문제 해결 단계에서는 명시적 거부 오류에 대해 구체적으로 다루고 암시적 거부 오류는 다루지 않습니다. 암시적 거부 오류에 대한 자세한 내용은 암시적 거부와 명시적 거부 간의 차이를 참조하십시오.
해결 방법
명시적 거부 오류는 다음 정책 중 하나 이상의 문제로 인해 발생합니다.
- ID 기반 정책
- 리소스 기반 정책
- 권한 경계
- 서비스 제어 정책
- 세션 정책
ID 기반 정책
ID 기반 정책은 엔터티의 허용/거부 작업을 제어합니다. 이러한 문제 해결 단계를 사용하여 ID 기반 정책의 문제를 식별할 수 있습니다.
참고: 실수로 권한이 부여되는 액세스를 방지하려면 조건에 Deny를 StringNotLike와 함께 사용하는 것이 좋습니다.
1. ID 기반 정책에 거부 문이 없는지 확인합니다. 이 예에는 거부 문이 있습니다.
{ "Effect": "Deny", "Action": "iam:DeleteRole" "Resource": "*" }
2. 정책에 다중 인증(MFA)이 적용되는지 확인합니다. MFA가 적용될 때 IAM 엔터티가 다른 인증 요소를 사용하지 않고 인증하면 권한이 거부됩니다. 예를 들어, 엔터티가 MFA 없이 AWS CLI를 사용하여 인증하면 API 호출이 거부됩니다. MFA 적용의 다음 예를 참조하십시오.
{ "Sid": "DenyAllExceptListedIfNoMFA", "Effect": "Deny", "NotAction": [ "iam:CreateVirtualMFADevice", "iam:EnableMFADevice", "iam:GetUser", "iam:ListMFADevices", "iam:ListVirtualMFADevices", "iam:ResyncMFADevice", "sts:GetSessionToken" ], "Resource": "*", "Condition": { "BoolIfExists": {"aws:MultiFactorAuthPresent": "false"} } }
이 정책은 NotAction 정책 요소에 언급된 API 호출을 제외한 모든 API 호출을 명시적으로 거부합니다.
3. 정책이 모든 필수 조건을 충족하는지 확인합니다. 정책에 여러 조건 연산자 또는 키가 있는 경우 AND 로직을 사용하여 조건이 평가됩니다. 동일한 AND 로직을 가져오려면 각 RequestTag 키를 별도의 문에서 사용해야 합니다. 다음은 API 호출 실패의 원인이 되는 일반적인 문제의 예입니다.
{ "Sid": "AllowRunInstancesWithRestrictions2", "Effect": "Deny", "Action": [ "ec2:CreateVolume", "ec2:RunInstances" ], "Resource": [ "arn:aws:ec2:*:*:volume/*", "arn:aws:ec2:*:*:instance/*" ], "Condition": { "ForAllValues:StringNotLike": { "aws:TagKeys": "Production" }, "StringEquals": { "ec2:InstanceType": "t2.micro" } } }
이러한 API 호출에 대한 명시적인 액세스 거부 오류가 발생하지 않도록 하려면 위 조건이 충족되었는지 확인하십시오.
참고: aws:TagKeys 조건은 대소문자를 구분합니다.
리소스 기반 정책
리소스 기반 정책은 리소스에 대한 액세스를 허용하거나 거부합니다. 통합된 IAM ID 기반 정책과 달리 리소스 기반 정책은 서비스에서 설계합니다. 다음 문제 해결 단계에서는 Amazon Simple Storage Service(Amazon S3) 리소스 기반 정책과 VPC 엔드포인트 정책을 예로 사용합니다.
S3 버킷 정책 평가
Amazon S3 버킷 정책 평가는 다음과 같이 작동합니다.
참고: 여기서는 버킷 ACL이 기본값으로 설정된 것으로 가정합니다.
- 동일한 계정의 버킷에 액세스하려면 IAM 엔터티에 IAM ID 기반 또는 버킷 정책의 권한이 필요합니다.
- 다른 계정의 버킷에 액세스하려면 IAM 엔터티에 버킷 정책 및 IAM ID 기반 권한이 있어야 액세스 권한을 얻을 수 있습니다.
1. 리소스 기반 정책의 거부 문을 확인합니다. 이 예는 버킷 정책의 거부 문을 보여줍니다.
{ "Effect": "deny", "Principal": { "AWS": "arn:aws:iam::111111111111:role/ROLENAME" }, "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::MyExampleBucket" }
2. 정책에 설명된 ARN이 올바른지 확인합니다.
3. 버킷 정책은 현재 사용자의 aws:userid가 정책에 정의된 것과 같지 않을 경우 액세스를 거부합니다. 다음 예를 참조하십시오.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": [ "arn:aws:s3:::MyExampleBucket", "arn:aws:s3:::MyExampleBucket/*" ], "Condition": { "StringNotLike": { "aws:userId": [ "AROAEXAMPLEID:*", "AIDAEXAMPLEID", "111111111111" ] } } } ] }
VPC 엔드포인트
VPC 엔드포인트 정책은 엔드포인트에 연결되는 IAM 리소스 정책입니다. 이 정책은 IAM 사용자 정책이나 서비스별 정책(예: S3 버킷 정책)을 재정의하거나 대체하지 않습니다.
인터페이스 엔드포인트를 사용하여 Amazon S3에 연결할 때 Amazon S3 데이터에 대한 액세스를 제어하는 두 가지 방법이 있습니다.
- VPC 엔드포인트를 사용하여 엔드포인트 서비스에 액세스할 수 있는 AWS 보안 주체(AWS 계정, IAM 사용자 및 IAM 역할)를 제어할 수 있습니다.
- Amazon S3 버킷 정책을 사용하여 버킷에 액세스할 수 있는 VPC 또는 VPC 엔드포인트를 제어할 수 있습니다.
아래 예는 Amazon S3 버킷 정책입니다. 이 정책은 ID가 vpce-11111인 VPC 엔드포인트가 examplebucket이라는 특정 버킷에 액세스하는 것을 제한합니다. 정책은 지정된 엔드포인트를 사용하지 않을 경우 버킷에 대한 모든 액세스를 거부합니다. aws:SourceVpce 조건은 엔드포인트를 지정하는 데 사용됩니다.
{ "Version": "2012-10-17", "Id": "Policy123456789”, "Statement": [ { "Sid": "AccessSpecificVPCEOnly", "Principal": "*", "Action": "s3:*", "Effect": "Deny", "Resource": ["arn:aws:s3:::examplebucket", "arn:aws:s3:::examplebucket/*"], "Condition": { "StringNotEqualsIfExists": { "aws:SourceVpce": "vpce-11111” } } } ] }
VPC 엔드포인트가 리소스에 대한 액세스를 명시적으로 거부하고 있지 않은지 항상 확인하십시오.
권한 경계
권한 경계는 ID 기반 정책이 IAM 엔터티에 부여할 수 있는 최대 권한을 설정하는 관리형 정책입니다. 이 관리형 정책은 엔터티에 대한 권한을 제한할 수 있으며, 이로 인해 명시적인 거부 오류 메시지가 표시될 수 있습니다.
이 예는 IAM 정책에서는 허용되었지만 권한 경계에서 명시적으로 거부된 작업을 보여줍니다. 아래 권한 경계를 참조하십시오.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "ec2:*" "Resource": "*" } ] }
사용자에게 다음과 같은 권한이 있습니다.
{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "ec2:RunInstances", "Resource": "*" } }
사용자에게 RunInstances 권한이 있더라도 요청을 하면 명시적인 거부 메시지가 표시됩니다. 이 오류를 해결하려면 권한 경계와 IAM이 모두 이 작업을 명시적으로 허용하는지 확인하십시오.
서비스 제어 정책
서비스 제어 정책(SCP)을 사용하면 조직의 권한을 관리할 수 있습니다. 다음 예는 SCP의 거부 문을 보여줍니다. 이 예에서는 SCP가 멤버 계정이나 특정 조직 단위(OU)에 연결되어 있습니다. 이는 RunInstances 작업에 대한 액세스를 명시적으로 거부합니다.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "ec2:RunInstances" "Resource": "*" } ] }
명시적 거부 오류를 해결하려면 다음 작업 중 하나를 수행하십시오.
- 계정에서 SCP를 분리합니다.
- 일부 사용 사례를 제외하는 조건을 추가하여 거부 문을 수정합니다. 예를 들어, 이 예에서 이 SCP는 IAM 보안 주체가 CloudOps 역할을 사용하는 경우 ec2:RunInstances를 거부하지 않습니다.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "ec2:RunInstances" "Resource": "*", "Condition": { "ArnNotLike": { "aws:PrincipalARN": "arn:aws:iam::*:role/CloudOps" } } } ] }
세션 정책
세션 정책은 역할 또는 사용자를 위한 임시 세션을 프로그래밍 방식으로 생성할 때 파라미터로 전달하는 고급 정책입니다. AssumeRole, AssumeRoleWithSAML 또는 AssumeRoleWithWebIdentity API 작업을 사용하여 역할 세션을 생성하고 세션 정책을 전달할 수 있습니다.
예를 들어 이 정책은 사용자가 RunInstances API 호출을 시도할 때 명시적 거부 오류를 생성합니다. 세션 정책의 거부 문을 항상 확인하십시오.
{ "Version": "2012-10-17", "Statement": { "Effect": "Deny", "Action": "ec2:RunInstances", "Resource": "*" } }
관련 정보
서비스 제어 정책을 사용하여 AWS Organization의 계정 전체에 대한 권한 가드 레일을 설정하는 방법
- 언어
- 한국어
