Cross-account policy evaluation logic

한 계정의 보안 주체가 두 번째 계정의 리소스에 액세스하도록 허용할 수 있습니다. 이를 크로스 계정 액세스라고 합니다. 교차 계정 액세스를 허용할 때 보안 주체가 존재하는 계정을 신뢰할 수 있는 계정이라고 합니다. 리소스가 존재하는 계정을 신뢰하는 계정이라고 합니다.

교차 계정 액세스를 허용하려면 공유하려는 리소스에 리소스 기반 정책을 연결해야 합니다. 또한 요청에서 보안 주체 역할을 하는 아이덴티티에 아이덴티티 기반 정책을 연결해야 합니다. 신뢰하는 계정의 리소스 기반 정책은 리소스에 액세스할 수 있는 신뢰할 수 있는 계정의 보안 주체를 지정해야 합니다. 전체 계정이나 해당 IAM 사용자, 페더레이션 사용자, IAM 역할 또는 위임된 역할 세션을 지정할 수 있습니다. AWS 서비스를 보안 주체로 지정할 수도 있습니다. 자세한 내용은 보안 주체를 지정하는 방법 단원을 참조하십시오.

보안 주체의 자격 증명 기반 정책은 신뢰 서비스의 리소스에 대한 요청된 액세스를 허용해야 합니다. 리소스의 ARN을 지정하여 이를 수행할 수 있습니다.

IAM에서는 리소스 기반 정책을 IAM 역할에 연결하여 다른 계정의 보안 주체가 해당 역할을 수임하도록 허용할 수 있습니다. 역할의 리소스 기반 정책을 역할 신뢰 정책이라고 합니다. 이 역할을 가정하면 허용된 보안 주체는 결과로 생성되는 임시 자격 증명을 사용하여 계정의 여러 리소스에 액세스할 수 있습니다. 이러한 액세스 권한은 역할의 자격 증명 기반 권한 정책에 정의되어 있습니다. 역할을 사용하여 교차 계정 액세스를 허용하는 것과 다른 리소스 기반 정책을 사용하여 교차 계정 액세스를 허용하는 것이 어떻게 다른지 알아보려면 IAM의 크로스 계정 리소스 액세스 섹션을 참조하세요.

교차 계정 요청의 허용 여부 결정

교차 계정 요청의 경우 신뢰할 수 있는 AccountA의 요청자가 자격 증명 기반 정책을 가지고 있어야 합니다. 이 정책은 신뢰하는 AccountB에서 리소스에 대한 요청을 생성할 수 있도록 허용해야 합니다. 또한 AccountB의 리소스 기반 정책은 AccountA의 요청자가 리소스에 액세스할 수 있도록 허용해야 합니다.

사용자가 교차 계정 요청을 하면 AWS에서는 두 가지 평가를 수행합니다. AWS는 신뢰하는 계정 및 신뢰할 수 있는 계정에서 요청을 평가합니다. 단일 계정 내에서 요청을 평가하는 방법에 대한 자세한 내용은 AWS 적용 코드 로직이 액세스 허용 또는 거부 요청을 평가하는 방법 섹션을 참조하세요. 두 평가에서 모두 Allow라는 결정을 반환하는 경우에만 요청이 허용됩니다.

다음 흐름도는 교차 계정 요청에 대한 정책 평가 결정이 이루어지는 방법을 보다 자세히 보여줍니다. 다시, AWS에서는 두 계정 정책 평가에서 모두 요청을 허용하는 경우에만 요청을 허용합니다.

교차 계정 정책 평가의 예

다음 예에서는 한 계정의 역할에 두 번째 계정의 리소스 기반 정책에 의해 권한이 부여되는 시나리오를 보여줍니다.

Carlos가 계정 111111111111에 Demo라는 IAM 역할이 있는 개발자라고 가정합니다. 그는 계정 222222222222에 있는 amzn-s3-demo-bucket-production-logs Amazon S3 버킷에 파일을 저장하려고 합니다.

또한 다음 정책이 Demo IAM 역할과 연결되었다고 가정합니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowS3ListRead",
            "Effect": "Allow",
            "Action": "s3:ListAllMyBuckets",
            "Resource": "*"
        },
        {
            "Sid": "AllowS3ProductionObjectActions",
            "Effect": "Allow",
            "Action": "s3:*Object*",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-production/*"
        },
        {
            "Sid": "DenyS3Logs",
            "Effect": "Deny",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::*log*",
                "arn:aws:s3:::*log*/*"
            ]
        }
    ]
}

이 정책의 AllowS3ListRead 문은 Carlos가 Amazon S3에 있는 모든 버킷의 목록을 보도록 허용합니다. AllowS3ProductionObjectActions 문은 Carlos에게 amzn-s3-demo-bucket-production 버킷의 객체에 대한 전체 액세스를 허용합니다.

또한, 다음 리소스 기반 정책(버킷 정책이라고 함)은 계정 222222222222의 amzn-s3-demo-bucket-production 버킷에 연결됩니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject*",
                "s3:PutObject*",
                "s3:ReplicateObject",
                "s3:RestoreObject"
            ],
            "Principal": { "AWS": "arn:aws:iam::111111111111:role/Demo" },
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket-production/*"
        }
    ]
}

이 정책은 Demo 역할에 amzn-s3-demo-bucket-production 버킷의 객체에 대한 액세스를 허용합니다. 역할은 버킷의 객체를 생성하고 편집할 수는 있지만 삭제할 수는 없습니다. 역할은 버킷 자체를 관리할 수 없습니다.

카를로스가 amzn-s3-demo-bucket-production-logs 버킷에 파일을 저장하도록 요청하면 AWS는 해당 요청에 어떤 정책을 적용할지 결정합니다. 이 경우 Demo 역할에 연결된 ID 기반 정책이 계정 111111111111에 적용되는 유일한 정책입니다. 계정 222222222222에서는 amzn-s3-demo-bucket-production-logs 버킷에 연결된 리소스 기반 정책이 없습니다. AWS은 계정 111111111111을 평가할 때 Deny의 결정을 반환합니다. 이는 자격 증명 기반 정책의 DenyS3Logs 문이 모든 로그 버킷에 대한 액세스를 명시적으로 거부하기 때문입니다. 단일 계정 내에서 요청을 평가하는 방법에 대한 자세한 내용은 AWS 적용 코드 로직이 액세스 허용 또는 거부 요청을 평가하는 방법 섹션을 참조하세요.

요청이 계정 중 하나에서 명시적으로 거부되기 때문에 최종 결정은 요청을 거부하는 것입니다.

카를로스가 자신의 실수를 깨닫고 Production 버킷에 파일을 저장하려고 시도한다고 가정합니다. AWS는 먼저 계정 111111111111을 확인하여 요청이 허용되는지 여부를 확인합니다. 자격 증명 기반 정책만 적용되며 요청을 허용합니다. 그리고 AWS는 계정 222222222222를 확인합니다. Production 버킷에 연결된 리소스 기반 정책만 적용되며 요청을 허용합니다. 두 계정 모두 요청을 허용하므로 최종 결정은 요청을 허용하는 것입니다.