요청 컨텍스트 처리 단일 계정 내에서 정책 평가 계정 내에서 요청 허용 여부 결정 자격 증명 기반 정책 및 리소스 기반 정책 평가 예제 명시적 거부와 묵시적 거부 차이

정책 평가 로직

보안 주체가 AWS Management Console, AWS API 또는 AWS CLI를 사용하려고 시도하면 해당 보안 주체가 요청을 AWS에 전송합니다. AWS 서비스가 요청을 받으면 AWS는 여러 단계를 완료하여 요청을 허용할지 거부할지 여부를 결정합니다.

인증 - AWS는 먼저 필요하다면 요청을 생성하는 보안 주체를 인증합니다. 이 단계는 익명 사용자의 요청을 허용하는 Amazon S3와 같은 일부 서비스에서는 필요하지 않습니다.
요청 컨텍스트 처리 – AWS는 요청에 담긴 내용을 처리하여 어떤 정책을 요청에 적용할지 결정합니다.
단일 계정 내에서 정책 평가 – AWS는 정책의 평가 순서에 영향을 받는 모든 정책 유형을 평가합니다.
계정 내에서 요청 허용 여부 결정 – AWS이때 는 요청에 따른 정책을 처리하여 요청을 허용할지 거부할지 여부를 결정합니다.

요청 컨텍스트 처리

AWS는 요청을 처리하여 다음 정보를 요청 콘텍스트에 모읍니다.

작업(또는 작동) - 보안 주체가 수행하고자 하는 작업 또는 작동입니다.
리소스 - 수행된 작업 또는 작동에 따른 AWS 리소스 객체입니다.
보안 주체 - 요청을 보내는 사용자, 역할, 페더레이션 사용자 또는 애플리케이션입니다. 보안 주체에 대한 정보는 보안 주체와 관련된 정책을 포함합니다.
환경 데이터 – IP 주소, 사용자 에이전트, SSL 사용 상태 또는 시간대와 같은 정보입니다.
리소스 데이터 – 요청되는 리소스와 관련된 데이터. 여기에는 DynamoDB 테이블 이름 또는 Amazon EC2 인스턴스 태그와 같은 정보가 포함될 수 있습니다.

AWS는 이러한 정보를 사용하여 요청 콘텍스트에 적용되는 정책을 찾습니다.

단일 계정 내에서 정책 평가

AWS는 요청 콘텍스트에 적용되는 정책 유형에 따라 정책을 평가합니다. 빈도순으로 나열된 다음 정책 유형을 단일 AWS 계정 내에서 사용할 수 있습니다. 이러한 정책 유형에 대한 자세한 정보는 IAM의 정책 및 권한 섹션을 참조하세요. AWS에서 크로스 계정 액세스에 대한 정책을 평가하는 방법에 대한 자세한 내용은 교차 계정 정책 평가 로직 섹션을 참조하세요.

자격 증명 기반 정책 - 자격 증명 기반 정책은 IAM 자격 증명(사용자, 사용자 그룹 또는 역할)에 연결되어 IAM 엔터티(사용자 및 역할)에 권한을 부여합니다. 자격 증명 기반 정책만 요청에 적용되는 경우 AWS에서는 하나 이상의 Allow에 대해 이러한 정책을 모두 확인합니다.
리소스 기반 정책 - 리소스 기반 정책을 통해 보안 주체로서 지정된 보안 주체(계정, 사용자, 역할 및 역할 세션 및 IAM 페더레이션 사용자와 같은 세션 보안 주체)에 권한을 부여합니다. 권한은 보안 주체가 정책이 연결된 리소스를 사용하여 수행할 수 있는 작업을 정의합니다. 리소스 기반 정책 및 자격 증명 기반 정책 둘 다 요청에 적용되는 경우 AWS에서는 하나 이상의 Allow에 대해 이러한 정책을 모두 확인합니다. 리소스 기반 정책을 평가할 때 정책에 지정된 보안 주체 ARN은 다른 정책 유형의 암시적 거부가 최종 결정에 적용되는지 여부를 결정합니다.
IAM 권한 경계 - 권한 경계는 자격 증명 기반 정책을 통해 IAM 엔터티(사용자 또는 역할)에 부여할 수 있는 최대 권한을 설정하는 고급 기능입니다. 엔터티에 대한 권한 경계를 설정할 경우 해당 엔터티는 자격 증명 기반 정책 및 관련 권한 경계 모두에서 허용되는 작업만 수행할 수 있습니다. 경우에 따라, 권한 경계의 암시적 거부는 리소스 기반 정책에서 부여한 권한을 제한할 수 있습니다. 자세한 내용은 이 주제 뒷부분의 계정 내에서 요청 허용 여부 결정 섹션을 참조하세요.
AWS Organizations 서비스 제어 정책(SCP) - 조직 SCP는 조직 또는 조직 단위(OU)에 대한 최대 권한을 지정합니다. SCP 최대값은 각 AWS 계정 루트 사용자을 포함하여 멤버 계정의 보안 주체에 적용됩니다. SCP가 있는 경우 자격 증명 기반 및 리소스 기반 정책이 이러한 정책과 SCP에서 해당 작업을 허용하는 경우에 한해서만 멤버 계정의 보안 주체에게 권한을 부여합니다. 권한 경계와 SCP가 둘 다 있는 경우 권한 경계, SCP 및 자격 증명 기반 정책 모두에서 해당 작업을 허용해야 합니다.
세션 정책 - 세션 정책은 역할 또는 페더레이션 사용자에 대해 임시 세션을 프로그래밍 방식으로 생성할 때 파라미터로 전달하는 고급 정책입니다. 역할 세션을 프로그래밍 방식으로 생성하려면 AssumeRole* API 작업 중 하나를 사용합니다. 이를 수행하고 세션 정책을 전달할 때 결과적으로 얻는 세션의 권한은 IAM 엔터티의 자격 증명 기반 정책의 교차와 세션 정책입니다. 페더레이션 사용자 세션을 생성하려면 IAM 사용자 액세스 키를 사용하여 GetFederationToken API 작업을 프로그래밍 방식으로 호출합니다. 리소스 기반 정책에는 세션 정책 권한 평가에 대한 각기 다른 효과가 있습니다. 그 차이는 사용자 또는 역할의 ARN이나 세션의 ARN이 리소스 기반 정책의 보안 주체로 나열되는지 여부에 따라 다릅니다. 자세한 내용은 세션 정책 섹션을 참조하세요.

이러한 정책 중 하나에 포함된 명시적 거부는 허용을 재정의함을 명심하세요.

리소스 기반 정책과 함께 자격 증명 기반 정책 평가

자격 증명 기반 정책 및 리소스 기반 정책은 연결된 자격 증명이나 리소스에 권한을 부여합니다. IAM 엔터티(사용자 또는 역할)가 동일 계정 내에서 리소스에 대한 액세스를 요청할 경우 AWS는 자격 증명 기반 및 리소스 기반 정책을 통해 부여된 모든 권한을 평가합니다. 결과적으로 두 정책 유형의 모든 권한이 권한으로 부여됩니다. 자격 증명 기반 정책, 리소스 기반 정책 또는 두 정책 모두에 의해 작업이 허용되는 경우 AWS에서는 해당 작업을 허용합니다. 이들 정책 중 하나에 포함된 명시적 거부는 허용을 재정의합니다.

권한 경계와 함께 자격 증명 기반 정책 평가

AWS에서 사용자의 자격 증명 기반 정책 및 권한 경계를 평가하는 경우 결과적으로 두 범주의 공통된 권한만 권한으로 부여됩니다. 기존 자격 증명 기반 정책으로 사용자에 권한 경계를 추가하면 사용자가 수행할 수 있는 작업을 축소할 수 있습니다. 또는 사용자에게서 권한 경계를 제거하면 사용자가 수행할 수 있는 작업이 늘어날 수 있습니다. 이들 정책 중 하나에 포함된 명시적 거부는 허용을 재정의합니다. 다른 정책 유형을 권한 경계와 함께 평가하는 방식에 대해 자세히 알아보려면 경계가 있는 효과적인 권한 평가 섹션을 참조하세요.

조직 SCP와 함께 자격 증명 기반 정책 평가

사용자가 조직의 멤버인 계정에 속하는 경우 결과로 나온 권한은 사용자의 정책과 SCP의 교집합입니다. 즉, 자격 증명 기반 정책 및 SCP 모두에서 작업이 허용되어야 합니다. 이들 정책 중 하나에 포함된 명시적 거부는 허용을 재정의합니다.

AWS Organizations에서 계정이 조직의 멤버인지 여부를 알아볼 수 있습니다. 조직 멤버가 SCP의 영향을 받을 수 있습니다. AWS CLI 명령 또는 AWS API 작업을 사용하여 이 데이터를 보려면 조직 엔터티에 대해 organizations:DescribeOrganization 작업 권한이 있어야 합니다. 조직 콘솔에서 작업을 수행할 추가 권한이 있어야 합니다. SCP가 특정 요청에 대한 액세스를 거부하는지 여부를 확인하거나 유효 권한을 변경하려면 AWS Organizations 관리자에게 문의하세요.

계정 내에서 요청 허용 여부 결정

보안 주체가 AWS로 요청을 보내 보안 주체의 엔터티와 동일한 계정에 있는 리소스에 액세스한다고 가정합니다. AWS 시행 코드는 요청의 허용 또는 거부 여부를 결정합니다. AWS에서는 요청 컨텍스트에 적용될 수 있는 모든 정책을 평가합니다. 다음은 단일 계정에 적용되는 이러한 정책에 대한 AWS 평가 논리를 요약한 것입니다.

기본적으로 모든 요청이 암시적으로 거부됩니다. 단, 전체 액세스 권한이 있는 AWS 계정 루트 사용자는 예외입니다.
자격 증명 기반 또는 리소스 기반 정책에 포함된 명시적 허용은 이 기본 작동을 재정의합니다.
권한 경계, 조직 SCP 또는 세션 정책이 있는 경우 이러한 정책 유형이 명시적 거부로 허용을 재정의할 수도 있습니다.
어떠한 정책의 명시적 거부도 허용을 무시합니다.

다음 순서도에 결정 방법에 대한 세부 정보가 나와 있습니다. 이 순서도는 리소스 기반 정책의 영향과 다른 유형의 정책에 대한 암시적 거부는 다루지 않습니다.

거부 평가 - 기본적으로 모든 요청이 거부됩니다. 이를 묵시적 거부라고 합니다. AWS 적용 코드는 해당 요청에 적용될 수 있는 계정 내의 모든 정책을 평가합니다. 여기에는 AWS Organizations SCP, 리소스 기반 정책, 자격 증명 기반 정책, IAM 권한 경계 및 세션 정책이 포함됩니다. 이런 모든 정책에서 적용 코드는 해당 요청에 적용되는 Deny 설명문을 찾습니다. 이를 명시적 거부라고 합니다. 적용되는 명시적 거부가 하나라도 발견되면 이 적용 코드는 최종 거부 결정을 반환합니다. 명시적 거부가 없으면 적용 코드 평가가 계속됩니다.
조직 SCP - 그다음에는 적용 코드가 요청에 적용되는 AWS Organizations 서비스 제어 정책(SCP)을 평가합니다. SCP는 SCP가 연결된 계정의 보안 주체에 적용됩니다. 적용 가능한 Allow 문이 SCP에 없는 경우 거부가 암시적이더라도 요청이 명시적으로 거부됩니다. 적용 코드가 최종 거부 결정을 반환합니다. SCP가 없거나 요청한 작업이 SCP에서 허용된 경우 적용 코드 평가가 계속됩니다.

리소스 기반 정책 - 동일한 계정 내에서 리소스 기반 정책은 리소스에 액세스하는 보안 주체의 유형과 리소스 기반 정책에서 허용되는 보안 주체에 따라 정책 평가에 다르게 영향을 줍니다. 보안 주체 유형에 따라 자격 증명 기반 정책, 권한 경계 또는 세션 정책에 암시적 거부가 있는 경우에도 리소스 기반 정책의 Allow은(는) Allow의 최종 결정을 내릴 수 있습니다.

대부분 리소스의 경우, 액세스 권한을 부여하는 자격 증명 기반 정책 또는 리소스 기반 정책의 보안 주체에 대한 명시적인 허용만 필요합니다. IAM 역할 신뢰 정책과 KMS 키 정책은 보안 주체에 대한 액세스 권한을 명시적으로 허용해야 하므로 이 로직의 예외입니다.

지정한 보안 주체가 IAM 사용자, IAM 역할 또는 세션 보안 주체인 경우 리소스 기반 정책 로직이 기타 정책 유형과 다릅니다. 세션 보안 주체에는 IAM 역할 세션 또는 IAM 페더레이션 사용자 세션이 포함됩니다. 리소스 기반 정책이 요청을 수행하는 IAM 사용자 또는 세션 보안 주체에 직접 권한을 부여하는 경우, 자격 증명 기반 정책, 권한 경계 또는 세션 정책에서 암시적 거부가 최종 결정에 영향을 주지 않습니다.

다음 표에서는 자격 증명 기반 정책, 권한 경계 및 세션 정책에 암시적 거부가 있을 때 여러 보안 주체 유형에 대한 리소스 기반 정책의 영향을 이해하는 데 도움이 됩니다.

리소스 기반 정책 및 다른 정책 유형의 암시적 거부(동일한 계정)
요청하는 보안 주체	리소스 기반 정책	자격 증명 기반 정책	권한 경계	세션 정책	결과	Reason
IAM 역할	해당 사항 없음	해당 사항 없음	해당 사항 없음	해당 사항 없음	해당 사항 없음	역할 자체는 요청을 할 수 없습니다. 역할이 수임된 후 역할 세션에 대한 요청이 이루어집니다.
IAM 역할 세션	역할 ARN 허용	암시적 거부	암시적 거부	암시적 거부	DENY	권한 경계 및 세션 정책은 최종 결정의 일부로 평가됩니다. 두 정책 중 하나에서 암시적 거부로 인해 DENY 결정이 발생합니다.
IAM 역할 세션	역할 세션 ARN 허용	암시적 거부	암시적 거부	암시적 거부	허용	권한은 세션에 직접 부여됩니다. 다른 정책 유형은 결정에 영향을 주지 않습니다.
IAM 사용자	IAM 사용자 ARN 허용	암시적 거부	암시적 거부	해당 사항 없음	허용	권한은 사용자에게 직접 부여됩니다. 다른 정책 유형은 결정에 영향을 주지 않습니다.
IAM 페더레이션 사용자(`GetFederationToken`)	IAM 사용자 ARN 허용	암시적 거부	암시적 거부	암시적 거부	DENY	권한 경계 또는 세션 정책에서 암시적 거부로 인해 DENY(거부)가 발생합니다.
IAM 페더레이션 사용자(`GetFederationToken`)	IAM 페더레이션 사용자 세션 ARN 허용	암시적 거부	암시적 거부	암시적 거부	허용	권한은 세션에 직접 부여됩니다. 다른 정책 유형은 결정에 영향을 주지 않습니다.
루트 사용자	루트 사용자 ARN 허용	해당 사항 없음	해당 사항 없음	해당 사항 없음	허용	루트 사용자는 AWS 계정의 모든 리소스에는 완전한 무제한 액세스 권한이 있습니다. AWS Organizations의 계정 루트 사용자에 대한 액세스를 제어하는 방법을 알아보려면 조직 사용 설명서의 서비스 제어 정책(SCP)을 참조하세요.
AWS 서비스 주체	AWS서비스 보안 주체 허용	해당 사항 없음	해당 사항 없음	해당 사항 없음	허용	리소스 기반 정책이 AWS 서비스 보안 주체에게 직접 권한을 부여하면 다른 정책 유형은 결정에 영향을 주지 않습니다.

IAM 역할 - IAM 역할 ARN에 권한을 부여하는 리소스 기반 정책은 권한 경계 또는 세션 정책의 암시적 거부에 의해 제한됩니다.

역할 ARN 예
```
arn:aws:iam::111122223333:role/examplerole
```
IAM 역할 세션 - 동일한 계정 내에서 IAM 역할 세션 ARN에 권한을 부여하는 리소스 기반 정책은 수임된 역할 세션에 직접 권한을 부여합니다. 세션에 직접 부여된 사용 권한은 자격 증명 기반 정책, 권한 경계 또는 세션 정책의 암시적 거부에 의해 제한되지 않습니다. 역할을 맡고 요청을 할 때 요청을 수행하는 보안 주체는 역할 자체의 ARN이 아니라 IAM 역할 세션 ARN입니다.

역할 세션 ARN 예
```
arn:aws:sts::111122223333:assumed-role/examplerole/examplerolesessionname
```
IAM 사용자 - 동일한 계정 내에서 IAM 사용자 ARN(페더레이션 사용자 세션이 아님)에게 권한을 부여하는 리소스 기반 정책은 자격 증명 기반 정책 또는 권한 경계에서 암시적 거부에 의해 제한되지 않습니다.

IAM 사용자 ARN 예
```
arn:aws:iam::111122223333:user/exampleuser
```
IAM 페더레이션 사용자 세션 - IAM 페더레이션 사용자 세션은 GetFederationToken 호출을 통해 생성된 세션입니다. 페더레이션 사용자가 요청을 할 때 요청을 수행하는 보안 주체는 페더레이션된 IAM 사용자의 ARN이 아니라 페더레이션 사용자 ARN입니다. 동일한 계정 내에서 페더레이션 사용자 ARN에게 권한을 부여하는 리소스 기반 정책은 세션에 직접 권한을 부여합니다. 세션에 직접 부여된 사용 권한은 자격 증명 기반 정책, 권한 경계 또는 세션 정책의 암시적 거부에 의해 제한되지 않습니다.

그러나 리소스 기반 정책이 페더레이션한 IAM 사용자의 ARN에 권한을 부여하는 경우, 세션 중에 페더레이션 사용자가 요청한 요청은 권한 경계 또는 세션 정책의 암시적 거부에 의해 제한됩니다.

IAM 페더레이션 사용자 세션 ARN 예
```
arn:aws:sts::111122223333:federated-user/exampleuser
```

자격 증명 기반 정책 - 그런 다음, 적용 코드는 보안 주체에 대한 자격 증명 기반 정책을 확인합니다. IAM 사용자의 경우 이러한 정책에는 사용자 정책과 사용자가 속한 그룹의 정책이 포함됩니다. 자격 증명 기반 정책이 없거나 요청된 작업을 허용하는 자격 증명 기반 정책에 대한 설명이 없는 경우, 적용 코드는 최종 Deny(거부) 결정을 반환합니다. 적용 가능한 자격 증명 기반 정책에서 요청한 작업을 허용하는 설명문이 있는 경우, 코드는 유지됩니다.
IAM 권한 경계 - 다음에는 코드가 보안 주체에 사용되는 IAM 엔터티에 권한 경계가 지정되어 있는지 여부를 확인합니다. 권한 경계를 설정하는 데 사용되는 정책에서 요청한 작업을 허용하지 않는 경우 요청이 묵시적으로 거부됩니다. 적용 코드가 최종 거부 결정을 반환합니다. 권한 경계가 없거나 요청한 작업이 권한 경계에서 허용된 경우 코드 실행이 계속됩니다.
세션 정책 - 코드에서는 그런 다음에 보안 주체가 세션 보안 주체인지 확인합니다. 세션 보안 주체에는 IAM 역할 세션 또는 IAM 페더레이션 사용자 세션이 포함됩니다. 보안 주체가 세션 보안 주체가 아닌 경우 적용 코드는 허용 최종 결정을 반환합니다.

세션 보안 주체의 경우 코드는 요청에 세션 정책이 전달되었는지 여부를 확인합니다. AWS CLI 또는 AWS API를 사용하는 동안 세션 정책을 전달하여 역할이나 IAM 페더레이션 사용자에 대한 임시 자격 증명을 가져올 수 있습니다.
- 세션 정책이 있지만 요청한 작업이 세션 정책에서 허용되지 않는 경우 해당 요청이 암시적으로 거부됩니다. 적용 코드가 최종 거부 결정을 반환합니다.
- 세션 정책이 없는 경우 코드는 보안 주체가 역할 세션인지 여부를 확인합니다. 보안 주체가 역할 세션인 경우 요청은 Allow(허용됨)입니다. 그렇지 않으면, 요청은 암시적으로 거부되며 코드에서는 Deny(거부)의 최종 결정을 반환합니다.
- 세션 정책이 있고 요청한 작업을 허용한 경우, 적용 코드에서는 Allow(허용)의 최종 결정을 반환합니다.
오류 - AWS 적용 코드를 평가하는 도중 오류가 발생할 경우 코드는 예외를 생성한 후 닫힙니다.

자격 증명 기반 정책 및 리소스 기반 정책 평가 예제

가장 일반적인 정책 유형은 자격 증명 정책 및 리소스 기반 정책입니다. 리소스에 대한 액세스가 요청되면 AWS는 동일한 계정 내에서 하나 이상의 Allow에 대해 정책에서 부여한 모든 권한을 평가합니다. 정책 중 하나에 포함된 명시적 거부는 허용을 재정의합니다.

중요

동일한 계정 내의 ID 기반 정책이나 리소스 기반 정책 중 하나는 요청을 허용하고 다른 하나는 허용하지 않는 경우에도 요청은 계속 허용됩니다.

Carlos가 carlossalazar라는 사용자 이름을 쓰고 있고 carlossalazar-logs Amazon S3 버킷에 파일을 저장하고자 한다고 가정합니다.

또한 다음 정책이 carlossalazar IAM 사용자와 연결되었다고 가정합니다.


{
    "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:::carlossalazar/*",
                "arn:aws:s3:::carlossalazar"
            ]
        },
        {
            "Sid": "DenyS3Logs",
            "Effect": "Deny",
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::*log*"
        }
    ]
}

이 정책의 AllowS3ListRead 설명문은 카를로스가 계정에 있는 모든 버킷 목록을 보도록 허용합니다. AllowS3Self 설명문은 카를로스가 그의 사용자 이름과 동일한 버킷에 모두 액세스할 수 있도록 허용합니다. DenyS3Logs 설명문은 카를로스가 그의 이름 아래에 있는 log를 통해 모든 S3 버킷의 액세스를 거부합니다.

또한, 다음 리소스 기반 정책(버킷 정책이라고 함)은 carlossalazar 버킷에 연결됩니다.


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:user/carlossalazar"
            },
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::carlossalazar/*",
                "arn:aws:s3:::carlossalazar"
            ]
        }
    ]
}

이 정책은 carlossalazar 사용자만 carlossalazar 버킷에 액세스할 수 있도록 지정합니다.

카를로스가 carlossalazar-logs 버킷에 파일을 저장하도록 요청하면 AWS는 해당 요청에 어떤 정책을 적용할지 결정합니다. 이 경우, 자격 증명 기반 정책과 리소스 기반 정책만 적용합니다. 이들은 모두 권한 정책입니다. 어떠한 권한 경계도 적용되지 않기 때문에 평가 로직은 다음 로직으로 줄어듭니다.

AWS는 먼저 요청 콘텍스트에 적용되는 Deny 설명문을 확인합니다. 자격 증명 기반 정책은 카를로스의 로깅을 통한 모든 S3 버킷의 액세스를 명시적으로 거부하기 때문에 이를 찾습니다. 카를로스의 액세스가 거부됩니다.

Carlos가 실수를 알아차리고 carlossalazar 버킷에 파일을 저장하고자 한다고 가정하세요. AWS는 Deny 설명문을 확인하지만 찾지 못합니다. 그러면 권한 정책을 확인합니다. 자격 증명 기반 정책과 리소스 기반 정책 모두 요청을 허용합니다. 따라서 AWS는 요청을 허용합니다. 이들 중 하나라도 설명문을 명시적으로 거부한다면 요청은 거부됩니다. 정책 유형 중 하나는 요청을 허용하고 다른 하나는 요청을 허용하지 않는 경우에도 요청은 허용됩니다.

명시적 거부와 묵시적 거부 차이

적용 가능한 정책이 Deny 설명문을 포함한다면 요청은 명시적으로 거부됩니다. 정책이 Allow 설명문과 Deny 설명문을 포함한 요청에 적용된다면 Deny 설명문은 Allow 설명문에 우선합니다. 이 요청은 명시적으로 거부됩니다.

적용 가능한 Deny 설명문이 없고 적용 가능한 Allow 설명문도 없다면 묵시적 거부가 발생합니다. IAM 보안 주체가 기본적으로 액세스를 거부하기 때문에 명시적으로 작업을 허용해야 합니다. 그렇지 않으면 액세스는 묵시적으로 거부됩니다.

권한 부여 전략을 설계한다면 Allow 설명문으로 정책을 생성하여 보안 주체가 성공적으로 요청하도록 허용합니다. 그러나 명시적 또는 묵시적 거부 조합을 선택할 수 있습니다.

예를 들어, 허용되는 작업, 암시적으로 거부된 작업 및 명시적으로 거부된 작업을 포함하는 다음 정책을 생성할 수 있습니다. AllowGetList 설명문은 접두사 Get 및 List(으)로 시작하는 IAM 작업에 대한 읽기 전용 액세스를 허용합니다. iam:CreatePolicy와(과) 같은 IAM의 다른 모든 작업은 암시적으로 거부됩니다. DenyReports 설명문은 iam:GetOrganizationsAccessReport와 같이 Report 접미사가 포함된 작업에 대한 액세스를 거부하여 IAM 보고서에 대한 액세스를 명시적으로 거부합니다. 누군가가 이 보안 주체에 다른 정책을 추가하여 iam:GenerateCredentialReport와 같은 IAM 보고서에 대한 액세스 권한을 부여하는 경우, 보고서 관련 요청은 이 명시적 거부로 인해 계속 거부됩니다.


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowGetList",
            "Effect": "Allow",
            "Action": [
                "iam:Get*",
                "iam:List*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "DenyReports",
            "Effect": "Deny",
            "Action": "iam:*Report",
            "Resource": "*"
        }
    ]
}

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

지원되는 데이터 형식

교차 계정 정책 평가 로직