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

교차 계정 정책 평가 로직

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

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

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

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

중요

다른 서비스는 정책 평가 로직에 영향을 줄 수 있습니다. 예를 들어 AWS Organizations에서는 하나 이상의 보안 주체 계정에 서비스 제어 정책을 적용할 수 있도록 지원합니다. AWS Resource Access Manager에서는 보안 주체가 공유되는 리소스에서 수행할 수 있는 작업을 제어하는 정책 조각을 지원합니다.

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

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

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


        교차 계정 평가
  1. 한 계정의 보안 주체가 다른 계정의 리소스에 액세스하도록 요청하는 경우 이는 교차 계정 요청입니다.

  2. 요청한 보안 주체는 신뢰할 수 있는 계정(AccountA)에 존재합니다. AWS는 이 계정을 평가할 때 자격 증명 기반 정책 및 자격 증명 기반 정책을 제한할 수 있는 정책을 확인합니다. 자세한 내용은 단일 계정 내에서 정책 평가 섹션을 참조하세요.

  3. 요청된 리소스가 신뢰하는 계정(AccountB)에 존재합니다. AWS는 이 계정을 평가할 때 요청된 리소스에 연결된 리소스 기반 정책과 리소스 기반 정책을 제한할 수 있는 정책을 확인합니다. 자세한 내용은 단일 계정 내에서 정책 평가 섹션을 참조하세요.

  4. AWS에서는 두 계정 정책 평가에서 모두 요청을 허용하는 경우에만 요청을 허용합니다.

교차 계정 정책 평가의 예

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

Carlos가 계정 111111111111에 carlossalazar라는 이름의 IAM 사용자가 있는 개발자라고 가정합니다. 그는 계정 222222222222에 있는 Production-logs Amazon S3 버킷에 파일을 저장하려고 합니다.

또한 다음 정책이 carlossalazar 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:::Production/*" }, { "Sid": "DenyS3Logs", "Effect": "Deny", "Action": "s3:*", "Resource": [ "arn:aws:s3:::*log*", "arn:aws:s3:::*log*/*" ] } ] }

이 정책의 AllowS3ListRead 문은 Carlos가 Amazon S3에 있는 모든 버킷의 목록을 보도록 허용합니다. AllowS3ProductionObjectActions 문은 Carlos에게 Production 버킷의 객체에 대한 전체 액세스를 허용합니다. DenyS3Logs 설명문은 카를로스가 그의 이름 아래에 있는 log를 통해 모든 S3 버킷의 액세스를 거부합니다. 또한 해당 버킷의 모든 객체에 대한 액세스를 거부합니다.

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

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject*", "s3:PutObject*", "s3:ReplicateObject", "s3:RestoreObject" ], "Principal": { "AWS": "arn:aws:iam::111111111111:user/carlossalazar" }, "Resource": "arn:aws:s3:::Production/*" } ] }

이 정책은 carlossalazar 사용자에게 Production 버킷의 객체에 대한 액세스를 허용합니다. 그는 버킷의 객체를 생성하고 편집할 수는 있지만 삭제할 수는 없습니다. 그는 버킷 자체를 관리할 수 없습니다.

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

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


        프로덕션 로그 버킷에 요청

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


        프로덕션 버킷에 요청