정책 평가 로직

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

요청 컨텍스트 처리

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

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

단일 계정 내에서 정책 평가

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Carlos가 carlossalazar라는 사용자 이름을 쓰고 있고 amzn-s3-demo-bucket-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:::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 버킷에 연결됩니다.

{
    "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는 해당 요청에 어떤 정책을 적용할지 결정합니다. 이 경우, 자격 증명 기반 정책과 리소스 기반 정책만 적용합니다. 이들은 모두 권한 정책입니다. 어떠한 권한 경계도 적용되지 않기 때문에 평가 로직은 다음 로직으로 줄어듭니다.

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

Carlos가 실수를 알아차리고 amzn-s3-demo-bucket-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": "*"
        }
    ]
}