정책 평가 로직 - AWS Identity and Access Management

문서의 영문과 번역 사이에 충돌이 있는 경우에는 영문 버전을 따릅니다. 번역 버전은 기계 번역을 사용하여 제공합니다.

정책 평가 로직

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

  1. 인증 – AWS는 먼저 필요하다면 요청을 생성하는 보안 주체를 인증합니다. 이 단계는 익명 사용자의 요청을 허용하는 Amazon S3와 같은 몇몇 서비스에서는 필요하지 않습니다.

  2. 요청 컨텍스트 처리 – AWS는 요청에 담긴 내용을 처리하여 어떤 정책을 요청에 적용할지 결정합니다.

  3. 단일 계좌 내의 정책 평가 – AWS는 정책의 평가 순서에 영향을 받는 모든 정책 유형을 평가합니다.

  4. 계정 내에서 요청의 허용 또는 거부 여부 결정 – 이때 AWS는 요청에 따른 정책을 처리하여 요청을 허용할지 거부할지 여부를 결정합니다.

요청 컨텍스트 처리

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

  • 작업(또는 작동) – 보안 주체가 수행하고자 하는 작업 또는 작동입니다.

  • 리소스 – 수행된 작업 또는 작동에 따른 AWS 리소스 객체입니다.

  • 보안 주체 – 요청을 보내는 사용자, 역할, 연합된 사용자 또는 애플리케이션입니다. 보안 주체에 대한 정보는 보안 주체와 관련된 정책을 포함합니다.

  • 환경 데이터 – IP 주소, 사용자 에이전트, SSL 사용 상태 또는 시간대와 같은 정보입니다.

  • 리소스 데이터 – 요청되는 리소스와 관련된 데이터. 여기에는 DynamoDB 테이블 이름 또는 Amazon EC2 인스턴스 태그와 같은 정보가 포함될 수 있습니다.

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

단일 계좌 내의 정책 평가

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

  1. 자격 증명 기반 정책 – 자격 증명 기반 정책은 IAM 자격 증명(사용자, 사용자 그룹 또는 역할)에 연결되어 IAM 엔터티(사용자 및 역할)에 권한을 부여합니다. 자격 증명 기반 정책만 요청에 적용되는 경우 AWS에서는 하나 이상의 Allow에 대해 이러한 정책을 모두 확인합니다.

  2. 리소스 기반 정책 – 리소스 기반 정책을 통해 보안 주체로서 지정된 보안 주체(계정, 사용자, 역할 또는 연합된 사용자)에 권한을 부여합니다. 권한은 보안 주체가 정책이 연결된 리소스를 사용하여 수행할 수 있는 작업을 정의합니다. 리소스 기반 정책 및 자격 증명 기반 정책 둘 다 요청에 적용되는 경우 AWS에서는 하나 이상의 Allow에 대해 이러한 정책을 모두 확인합니다.

  3. IAM 권한 경계 – 권한 경계는 자격 증명 기반 정책을 통해 IAM 엔터티(사용자 또는 역할)에 부여할 수 있는 최대 권한을 설정하는 고급 기능입니다. 엔터티에 대한 권한 경계를 설정할 경우 해당 엔터티는 자격 증명 기반 정책 및 관련 권한 경계 모두에서 허용되는 작업만 수행할 수 있습니다. 권한 경계의 암시적 거부는 리소스 기반 정책에서 부여한 권한을 제한하지 않습니다.

  4. AWS Organizations 서비스 제어 정책(SCP) – 조직 SCP는 조직 또는 조직 단위(OU)에 대한 최대 권한을 지정합니다. SCP 최대값은 각 AWS 계정 루트 사용자을 포함하여 멤버 계정의 보안 주체에 적용됩니다. SCP가 있는 경우 자격 증명 기반 및 리소스 기반 정책이 이러한 정책과 SCP에서 해당 작업을 허용하는 경우에 한해서만 멤버 계정의 보안 주체에게 권한을 부여합니다. 권한 경계와 SCP가 둘 다 있는 경우 권한 경계, SCP 및 자격 증명 기반 정책 모두에서 해당 작업을 허용해야 합니다.

  5. 세션 정책 – 세션 정책은 역할 또는 연합된 사용자에 대해 임시 세션을 프로그래밍 방식으로 생성할 때 파라미터로 전달하는 고급 정책입니다. 역할 세션을 프로그래밍 방식으로 생성하려면 AssumeRole* API 작업 중 하나를 사용합니다. 이를 수행하고 세션 정책을 전달할 때 결과적으로 얻는 세션의 권한은 IAM 엔터티의 자격 증명 기반 정책의 교차와 세션 정책입니다. 연합된 사용자 세션을 생성하려면 IAM 사용자의 액세스 키를 사용하여 GetFederationToken API 작업을 프로그래밍 방식으로 호출합니다. 리소스 기반 정책에는 세션 정책 권한 평가에 대한 각기 다른 효과가 있습니다. 그 차이는 사용자 또는 역할의 ARN이나 세션의 ARN이 리소스 기반 정책의 보안 주체로 나열되는지 여부에 따라 다릅니다. 자세한 정보는 세션 정책 단원을 참조하십시오.

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

리소스 기반 정책을 사용하여 ID 기반 정책 평가

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


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

권한 경계를 사용하여 ID 기반 정책 평가

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


          자격 증명 기반 정책 및 권한 경계 평가

ID 기반 정책 평가 조직 SCP

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


          자격 증명 기반 정책 및 SCP 평가

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

계정 내에서 요청의 허용 또는 거부 여부 결정

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

  • 기본적으로 모든 요청이 묵시적으로 거부됩니다. 또는 기본적으로 AWS 계정 루트 사용자에 모든 권한이 부여됩니다.

  • 자격 증명 기반 또는 리소스 기반 정책에 포함된 명시적 허용은 이 기본 작동을 재정의합니다.

  • 권한 경계, 조직 SCP 또는 세션 정책이 있는 경우 이러한 정책 유형이 명시적 거부로 허용을 재정의할 수도 있습니다.

  • 어떠한 정책의 명시적 거부도 허용을 무시합니다.

다음 순서도에 결정 방법에 대한 세부 정보가 나와 있습니다.


        평가 순서도
  1. 거부 평가 – 기본적으로 모든 요청이 거부됩니다. 이를 묵시적 거부라고 합니다. AWS 적용 코드는 해당 요청에 적용될 수 있는 계정 내의 모든 정책을 평가합니다. 여기에는 AWS Organizations SCP, 리소스 기반 정책, IAM 권한 경계, 역할 세션 정책 및 자격 증명 기반 정책이 포함됩니다. 이런 모든 정책에서 적용 코드는 해당 요청에 적용되는 Deny 설명문을 찾습니다. 이를 명시적 거부라고 합니다. 적용되는 명시적 거부가 하나라도 발견되면 이 코드는 최종 거부 결정을 반환합니다. 명시적 거부가 없으면 코드 실행이 계속됩니다.

  2. 조직 SCP – 그 다음에는 요청에 적용되는 AWS Organizations 서비스 제어 정책(SCP)을 평가합니다. SCP는 SCP가 연결된 계정의 보안 주체에 적용됩니다. 적용 가능한 Allow 문이 SCP에 없는 경우 요청이 묵시적으로 거부됩니다. 적용 코드가 최종 거부 결정을 반환합니다. SCP가 없거나 요청한 작업이 SCP에서 허용된 경우 코드 실행이 계속됩니다.

  3. 리소스 기반 정책 – 보안 주체에 대해 요청한 작업의 수행을 허용하는 리소스 기반 정책이 요청한 리소스에 지정된 경우 적용 코드는 최종 허용 결정을 반환합니다. 리소스 기반 정책이 없거나 이 정책에 Allow 문이 포함되지 않은 경우 코드 실행이 계속됩니다.

    참고

    IAM 역할 또는 사용자의 ARN을 리소스 기반 정책의 보안 주체로 지정한 경우 이 로직은 다르게 동작할 수 있습니다. 세션 정책을 사용하여 해당 역할 또는 연동 역할에 대해 임시 자격 증명 세션을 생성할 수도 있습니다. 이러한 경우 세션에 대해 유효한 권한은 사용자 또는 역할의 자격 증명 기반 정책에서 허용하는 권한을 초과할 수 없습니다. 자세한 정보는 세션 정책을 참조하십시오.

  4. IAM 권한 경계 – 다음에는 적용 코드가 보안 주체에 사용되는 IAM 엔터티에 권한 경계가 지정되어 있는지 여부를 확인합니다. 권한 경계를 설정하는 데 사용되는 정책에서 요청한 작업을 허용하지 않는 경우 요청이 묵시적으로 거부됩니다. 적용 코드가 최종 거부 결정을 반환합니다. 권한 경계가 없거나 요청한 작업이 권한 경계에서 허용된 경우 코드 실행이 계속됩니다.

  5. 세션 정책 – 그 다음, 적용 코드는 세션 정책을 전달하여 보안 주체에서 위임된 세션을 사용 중인지 확인합니다. AWS CLI 또는 AWS API를 사용하는 동안 세션 정책을 전달하여 역할이나 연합된 사용자에 대한 임시 자격 증명을 가져올 수 있습니다. 세션 정책이 있지만 요청한 작업이 세션 정책에서 허용되지 않는 경우 해당 요청이 묵시적으로 거부됩니다. 적용 코드가 최종 거부 결정을 반환합니다. 세션 정책이 없거나 요청한 작업이 세션 정책에서 허용된 경우 코드 실행이 계속됩니다.

  6. 자격 증명 기반 정책 – 그 다음, 적용 코드는 보안 주체에 대한 자격 증명 기반 정책을 확인합니다. IAM 사용자의 경우 이러한 정책에는 사용자 정책과 사용자가 속한 그룹의 정책이 포함됩니다. 적용 가능한 자격 증명 기반 정책에 요청한 작업을 허용하는 설명문이 있는 경우 적용 코드는 최종 허용 결정을 반환합니다. 요청한 작업을 허용하는 설명문이 없는 경우 해당 요청이 묵시적으로 거부되고, 적용 코드는 최종 거부 결정을 반환합니다.

  7. 오류 – AWS 적용 코드를 평가하는 도중 오류가 발생할 경우 코드는 예외를 생성한 후 닫힙니다.

ID 기반 및 리소스 기반 정책 평가 예

가장 일반적인 정책 유형은 자격 증명 정책 및 리소스 기반 정책입니다.

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

또한 다음 정책이 carlossalazar IAM 사용자와 연결되었다고 가정하십시오.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowS3ListRead", "Effect": "Allow", "Action": [ "s3:ListAllMyBuckets", "s3:HeadBucket" ], "Resource": "*" }, { "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*", "arn:aws:s3:::*log*/*" ] } ] }

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

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

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

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

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


        평가 순서도

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

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

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

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

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

권한 부여 전략을 설계한다면 Allow 설명문으로 정책을 생성하여 보안 주체가 성공적으로 요청하도록 허용합니다. 그러나 명시적 또는 묵시적 거부 조합을 선택할 수 있습니다. 예를 들어, 다음 정책을 생성하여 AWS의 모든 리소스에 관리자가 완전히 액세스하도록 허용하지만 결제 액세스를 명시적으로 거부할 수 있습니다. 다른 사람이 관리자에게 다른 정책을 추가하여 결제를 허용하려고 해도 이 명시적 거부 때문에 결제는 여전히 거부됩니다.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "*", "Resource": "*" }, { "Effect": "Deny", "Action": "aws-portal:*", "Resource": "*" } ] }

또한, 다음 정책을 생성하여 그룹 또는 IAM의 기타 리소스가 아닌 사용자가 사용자를 관리할 수 있도록 허용합니다. 이러한 작업은 기타 서비스의 작업처럼 묵시적으로 거부됩니다. 그러나 다른 사람이 정책을 이런 다른 작업을 수행하도록 허용하는 사용자에게 추가한다면 이런 작업이 허용됩니다.

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": [ "iam:AttachUserPolicy", "iam:CreateUser", "iam:DeleteUser", "iam:DeleteUserPolicy", "iam:DetachUserPolicy", "iam:GetUser", "iam:GetUserPolicy", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:ListUsers", "iam:PutUserPolicy", "iam:UpdateUser" ], "Resource": "*" } }