AWS 적용 코드 로직이 액세스 허용 또는 거부 요청을 평가하는 방법 - AWS Identity and Access Management

AWS 적용 코드 로직이 액세스 허용 또는 거부 요청을 평가하는 방법

AWS 적용 코드는 AWS로 전송된 요청을 허용할지 거부할지 결정합니다. AWS에서는 요청 컨텍스트에 적용될 수 있는 모든 정책을 평가합니다. 다음은 AWS 정책 평가 논리의 요약입니다.

  • 기본적으로 모든 요청이 암시적으로 거부됩니다. 단, 전체 액세스 권한이 있는 AWS 계정 루트 사용자는 예외입니다.

  • 요청이 허용되려면 아래 평가 로직에 따라 정책 또는 정책 세트에서 명시적으로 허용해야 합니다.

  • 명시적 거부는 명시적 허용을 재정의합니다.

다음 흐름도는 단일 계정 및 교차 계정 액세스 모두에 대한 결정이 어떻게 내려지는지에 대한 세부 정보를 제공합니다.

평가 순서도

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

  • 조직 SCP - 적용 코드가 요청에 적용되는 AWS Organizations 리소스 제어 정책(RCP)을 평가합니다. RCP는 RCP가 연결된 계정의 리소스에 적용됩니다. 적용 코드가 RCP에서 적용 가능한 Allow 문을 찾지 못하면 적용 코드는 거부라는 최종 결정을 반환합니다. RCPFullAWSAccess라는 AWS 관리형 정책은 루트, 각 OU, RCPs가 활성화된 AWS 계정 경우를 포함하여 조직의 모든 엔터티에 자동으로 생성되고 연결됩니다. RCPFullAWSAccess는 분리할 수 없으므로 항상 Allow 문이 있습니다. RCP가 없거나 요청한 작업이 RCP에서 허용된 경우 적용 코드 평가가 계속됩니다.

  • 조직 SCP - 적용 코드가 요청에 적용되는 AWS Organizations 서비스 제어 정책(SCP)을 평가합니다. SCP는 SCP가 연결된 계정의 보안 주체에 적용됩니다. 적용 코드가 SCP에서 적용 가능한 Allow 문을 찾지 못하면 적용 코드는 거부라는 최종 결정을 반환합니다. SCP가 없거나 요청한 작업이 SCP에서 허용된 경우 적용 코드 평가가 계속됩니다.

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

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

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

    • IAM 역할 - IAM 역할 ARN에 권한을 부여하는 리소스 기반 정책은 권한 경계 또는 세션 정책의 암시적 거부에 의해 제한됩니다. Principal 요소나 aws:PrincipalArn 조건 키에 역할 ARN을 지정할 수 있습니다. 두 경우 모두 요청을 하는 보안 주체는 IAM 역할 세션입니다.

      자격 증명 기반 정책에 명시적 거부가 포함되지 않는 한, 권한 경계와 세션 정책은 Principal 요소에서 와일드카드(*)와 함께 aws:PrincipalArn 조건 키를 사용하여 부여한 권한을 제한하지 않습니다. 자세한 내용은 IAM 역할 보안 주체 단원을 참조하십시오.

      역할 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

  • ID 기반 정책 - 적용 코드는 위탁자에 대한 ID 기반 정책을 확인합니다. IAM 사용자의 경우 이러한 정책에는 사용자 정책과 사용자가 속한 그룹의 정책이 포함됩니다. ID 기반 정책이 없거나 ID 기반 정책에 요청된 작업을 허용하는 문이 없으면 요청은 암시적으로 거부되고 적용 코드는 최종 결정으로 거부를 반환합니다. 적용 가능한 ID 기반 정책에서 요청한 작업을 허용하는 설명문이 있는 경우 코드 평가가 계속됩니다.

  • IAM 권한 경계 - 적용 코드가 위탁자에 사용되는 IAM 엔터티에 권한 경계가 있는지 여부를 확인합니다. 권한 경계를 설정하는 데 사용되는 정책에서 요청한 작업을 허용하지 않는 경우 요청이 묵시적으로 거부됩니다. 적용 코드가 최종 거부 결정을 반환합니다. 권한 경계가 없거나 요청한 작업이 권한 경계에서 허용된 경우 코드 평가가 계속됩니다.

  • 세션 정책 - 적용 코드에서는 그런 다음에 위탁자가 세션 위탁자인지 확인합니다. 세션 보안 주체에는 IAM 역할 세션 또는 IAM 페더레이션 사용자 세션이 포함됩니다. 보안 주체가 세션 보안 주체가 아닌 경우 적용 코드는 허용 최종 결정을 반환합니다.

    세션 위탁자의 경우 적용 코드는 요청에 세션 정책이 전달되었는지 여부를 확인합니다. AWS CLI 또는 AWS API를 사용하는 동안 세션 정책을 전달하여 역할이나 IAM 페더레이션 사용자에 대한 임시 자격 증명을 가져올 수 있습니다. 세션 정책을 통과하지 못한 경우 기본 세션 정책이 생성되고 적용 코드가 최종 결정으로 허용을 반환합니다.

    • 세션 정책이 있지만 요청한 작업이 세션 정책에서 허용되지 않는 경우 해당 요청이 암시적으로 거부됩니다. 적용 코드가 최종 거부 결정을 반환합니다.

    • 적용 코드가 위탁자가 역할 세션인지 확인합니다. 보안 주체가 역할 세션인 경우 요청은 Allow(허용됨)입니다. 그렇지 않으면, 요청은 암시적으로 거부되며 적용 코드에서는 거부의 최종 결정을 반환합니다.

    • 세션 정책이 있고 요청한 작업을 허용한 경우, 적용 코드에서는 Allow(허용)의 최종 결정을 반환합니다.