IAM의 크로스 계정 리소스 액세스
일부 AWS 서비스의 경우, IAM을 사용하여 리소스에 대한 크로스 계정 액세스 권한을 부여할 수 있습니다. 이렇게 하려면 공유하려는 리소스에 리소스 정책을 직접 연결하거나 역할을 프록시로 사용하면 됩니다.
리소스를 직접 공유하려면, 공유하려는 리소스가 반드시 리소스 기반 정책을 지원해야 합니다. 역할의 ID 기반 정책과 달리 리소스 기반 정책은 해당 리소스에 액세스할 수 있는 사용자(보안 주체)를 지정합니다.
리소스 기반 정책을 지원하지 않는 다른 계정의 리소스에 액세스하려는 경우, 역할을 프록시로 사용합니다.
이러한 정책 유형 간의 차이에 대한 자세한 내용은 자격 증명 기반 정책 및 리소스 기반 정책 섹션을 참조하세요.
참고
IAM 역할 및 리소스 기반 정책은 단일 파티션 내에서만 계정 간에 액세스 권한을 위임합니다. 미국 서부(캘리포니아 북부)의 표준 aws 파티션에 계정이 있는 경우를 예로 들어보겠습니다. 중국의 aws-cn 파티션에도 계정이 있습니다. 이 경우 중국의 계정에서 리소스 기반 정책을 사용하여 AWS 표준 계정의 사용자에 대한 액세스를 허용할 수 없습니다.
역할을 사용한 크로스 계정 액세스
모든 AWS 서비스에서 리소스 기반 정책을 지원하는 것은 아닙니다. 이러한 서비스의 경우 여러 서비스에 대한 크로스 계정 액세스를 제공할 때 크로스 계정 IAM 역할을 사용하여 권한 관리를 중앙 집중화할 수 있습니다. 크로스 계정 IAM 역할은 다른 AWS 계정의 IAM 보안 주체가 역할을 수임할 수 있도록 하는 신뢰 정책을 포함하는 IAM 역할입니다. 간단히 설명하자면, 특정 권한을 다른 AWS 계정에 위임하는 역할을 단일 AWS 계정에 생성할 수 있습니다.
IAM 자격 증명에 정책을 연결하는 방법에 대한 자세한 내용은 IAM 정책 관리 섹션을 참조하세요.
참고
보안 주체가 역할의 권한을 일시적으로 사용하기 위해 특정 역할로 전환하면, 원래 권한을 포기하고 수임하는 역할에 할당된 권한을 갖게 됩니다.
고객 계정에 액세스해야 하는 APN 파트너 소프트웨어에 적용되는 전체 프로세스를 살펴보겠습니다.
-
고객이 자신의 계정에 APN 파트너가 요구하는 Amazon S3 리소스에 대한 액세스를 허용하는 정책을 포함하여 IAM 역할을 생성합니다. 이 예에서 역할의 이름은
APNPartner입니다.{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "s3:*", "Resource": [ "arn:aws:s3:::bucket-name" ] } ] } -
이후 고객은
APNPartner역할에 대한 신뢰 정책에 APN 파트너의 AWS 계정 ID를 제공하여 파트너의 AWS 계정에서 역할을 수임할 수 있도록 지정합니다.{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::APN-account-ID:role/APN-user-name" }, "Action": "sts:AssumeRole" } ] } -
고객이 역할의 Amazon 리소스 이름(ARN)을 APN 파트너에게 제공합니다. ARN은 역할의 정규화된 이름입니다.
arn:aws:iam::APN-ACCOUNT-ID:role/APNPartner참고
멀티 테넌트 상황에서는 외부 ID를 사용하는 것이 좋습니다. 자세한 내용은 AWS 리소스에 대한 액세스 권한을 타사에 부여할 때 외부 ID를 사용하는 방법 섹션을 참조하세요.
-
APN 파트너의 소프트웨어가 고객 계정에 액세스해야 하는 경우, 해당 소프트웨어는 고객 계정 내 역할의 ARN을 사용하여 AWS Security Token Service에서 AssumeRole API를 호출합니다. STS는 소프트웨어가 작업을 수행할 수 있도록 하는 임시 AWS 보안 인증 정보를 반환합니다.
역할을 사용하여 크로스 계정 액세스 권한을 부여하는 또 다른 예는 소유한 다른 AWS 계정의 IAM 사용자에 액세스 권한 제공 섹션을 참조하세요. 튜토리얼: IAM 역할을 사용한 AWS 계정 간 액세스 권한 위임에 접속해도 됩니다.
리소스 기반 정책을 사용한 크로스 계정 액세스
계정에서 리소스 기반 정책을 사용하여 다른 계정을 통해 리소스에 액세스할 경우, 보안 주체는 여전히 신뢰할 수 있는 계정에서 작업을 할 수 있고, 역할 권한을 수신하기 위해 자신의 권한을 포기할 필요가 없습니다. 즉, 보안 주체는 신뢰하는 계정의 리소스에 대한 액세스 권한을 유지하면서 신뢰할 수 있는 계정의 리소스에 계속 액세스할 수 있습니다. 다른 계정의 공유 리소스로 정보를 복사하거나 공유 리소스의 정보를 복사하는 등의 작업에서 이는 특히 유용합니다.
리소스 기반 정책에서 지정할 수 있는 보안 주체에는 계정, IAM 사용자, 페더레이션 사용자, IAM 역할, 수임된 역할 세션 또는 AWS 서비스가 포함됩니다. 자세한 내용은 보안 주체 지정을 참조하세요.
해당 신뢰 영역(신뢰할 수 있는 조직 또는 계정) 외의 계정 내 보안 주체가 역할을 수임하는 권한이 있는지 자세히 알고 싶다면, 외부 엔티티와 공유되는 리소스 식별을 참조하세요.
다음 목록에는 리소스 기반 정책을 지원하는 일부 AWS 서비스가 나와 있습니다. 보안 주체 대신 리소스에 권한 정책을 연결할 수 있도록 지원하는 AWS 서비스는 늘어나고 있습니다. 해당 서비스의 전체 목록은 AWS IAM으로 작업하는 서비스 섹션을 참조하고 리소스 기반 열의 값이 예인 서비스를 찾아보세요.
-
Amazon S3 버킷 - 정책은 버킷과 연결되지만, 버킷과 그 안에 포함된 객체에 대한 액세스를 모두 제어합니다. 자세한 내용은 Amazon Simple Storage Service 사용 설명서의 액세스 제어를 참조하세요. 일부의 경우, Amazon S3의 크로스 계정 액세스를 위한 역할을 사용하는 것이 최선일 수 있습니다. 자세한 내용은 Amazon Simple Storage Service 사용 설명서의 연습 예제를 참조하세요.
-
Amazon Simple Notification Service(SNS) 주제 - 자세한 내용은 Amazon Simple Notification Service 개발자 안내서에서 Amazon SNS 액세스 제어 사례를 참조하세요.
-
Amazon Simple Queue Service(Amazon SQS) 대기열 - 자세한 내용은 Amazon Simple Queue Service 개발자 안내서의 부록: 액세스 정책 언어를 참조하세요.
리소스 기반 정책에서 AWS 권한 위임
리소스가 계정의 보안 주체에 권한을 부여하는 경우 이러한 권한을 특정 IAM 자격 증명에 위임할 수 있습니다. 자격 증명은 사용자, 사용자 그룹 또는 계정의 역할입니다. 자격 증명에 정책을 연결하여 권한을 위임합니다. 리소스 소유 계정에서 허용하는 최대 권한을 부여할 수 있습니다.
중요
크로스 계정 액세스에서 보안 주체는 ID 정책 및 리소스 기반 정책에 Allow 항목이 있어야 합니다.
리소스 기반 정책에서는 계정의 모든 보안 주체에게 리소스에 대한 전체 관리 액세스 권한을 허용한다고 가정합니다. 이제 AWS 계정의 보안 주체에게 전체 액세스 권한, 읽기 전용 액세스 권한 또는 기타 부분적 액세스 권한을 위임할 수 있습니다. 또는 리소스 기반 정책에서 목록 액세스 권한만 허용하는 경우에는 목록 액세스 권한만 위임할 수 있습니다. 계정에 부여된 것보다 더 많은 권한을 위임하려고 해도 보안 주체는 목록 액세스 권한만 갖게 됩니다.
이러한 결정을 내리는 방법에 대한 자세한 내용은 계정 내에서 요청 허용 여부 결정을 참조하세요.
참고
IAM 역할 및 리소스 기반 정책은 단일 파티션 내에서만 계정 간에 액세스 권한을 위임합니다. 예를 들어 표준 aws 파티션의 계정과 aws-cn 파티션의 계정 간에 크로스 계정 액세스를 추가할 수 없습니다.
예를 들어 AccountA 및 AccountB를 관리한다고 가정합니다. AccountA에 BucketA라는 Amazon S3 버킷이 있습니다.
-
AccountB의 모든 보안 주체에게 버킷의 객체에 대한 전체 액세스 권한을 허용하는 리소스 기반 정책을
BucketA에 연결합니다. 해당 버킷의 모든 객체를 생성, 읽기 또는 삭제할 수 있습니다.{ "Version": "2012-10-17", "Statement": [ { "Sid": "PrincipalAccess", "Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::AccountB:root"}, "Action": "s3:*", "Resource": "arn:aws:s3:::BucketA/*" } ] }AccountA는 리소스 기반 정책에서 보안 주체로서 AccountB를 명명하여 AccountB에게 BucketA에 대한 전체 액세스 권한을 제공합니다. 그 결과 AccountB는 계정 BucketA에 대해 모든 작업을 수행할 권한이 있으며, AccountB 관리자는 AccountB에 속한 사용자에게 액세스 권한을 위임할 수 있습니다.
AccountB 루트 사용자는 계정에 부여된 모든 권한을 가집니다. 따라서 루트 사용자는 BucketA에 대한 전체 액세스 권한을 가집니다.
-
AccountB에서 User2라는 IAM 사용자에게 정책을 연결합니다. 이 정책은 사용자에게 BucketA의 객체에 대한 읽기 전용 액세스를 허용합니다. 즉, User2는 객체를 볼 수 있지만 객체를 생성, 편집 또는 삭제할 수는 없습니다.
{ "Version": "2012-10-17", "Statement": [ { "Effect" : "Allow", "Action" : [ "s3:Get*", "s3:List*" ], "Resource" : "arn:aws:s3:::BucketA/*" } ] }AccountB가 위임할 수 있는 최대 액세스 수준은 계정에 부여된 액세스 수준입니다. 이 경우 리소스 기반 정책에서는 AccountB에 대한 전체 액세스 권한을 부여하지만 User2에는 읽기 전용 액세스 권한만 부여됩니다.
AccountB 관리자는 User1에게 액세스 권한을 부여하지 않습니다. 기본적으로 사용자는 명시적으로 부여된 권한을 제외하고는 어떤 권한도 없으므로 User1은 BucketA에 대한 액세스 권한이 없습니다.
IAM은 보안 주체가 요청을 할 때 보안 주체의 권한을 평가합니다. 와일드카드(*)를 사용하여 사용자에게 리소스에 대한 전체 액세스 권한을 부여하면 보안 주체는 AWS 계정이 액세스 권한을 가지고 있는 모든 리소스에 액세스할 수 있습니다. 사용자 정책을 생성한 이후에 추가하거나 액세스 권한을 획득한 리소스의 경우에도 마찬가지입니다.
앞의 예에서 AccountB가 모든 계정의 모든 리소스에 대한 전체 액세스 권한을 허용하는 정책을 User2에 연결했다면 User2는 AccountB에 액세스 권한이 있는 모든 리소스에 자동으로 액세스할 수 있었을 것입니다. 여기에는 BucketA 액세스 권한과 AccountA의 리소스 기반 정책에서 부여한 다른 리소스에 대한 액세스 권한이 포함됩니다 .
애플리케이션 및 서비스에 대한 액세스 권한 부여 등, 역할의 복잡한 사용 사례에 대한 자세한 내용은 역할에 대한 일반적인 시나리오: 사용자, 애플리케이션 및 서비스 섹션을 참조하세요.
중요
신뢰 관계가 설정된 엔터티에만 액세스 권한을 부여하고 필요한 최소 수준의 액세스 권한만 부여합니다. 신뢰할 수 있는 엔터티가 다른 AWS 계정인 경우에는 어떠한 IAM 보안 주체에게든 리소스에 대한 액세스 권한을 부여할 수 있습니다. 신뢰하는 AWS 계정은 권한이 부여된 액세스 범위 내에서만 권한을 위임할 수 있으며, 계정에 부여된 권한보다 더 많은 액세스 권한을 위임할 수 없습니다.
권한, 정책 및 정책 작성에 사용하는 권한 정책 언어에 대한 자세한 내용은 AWS리소스에 대한 액세스 관리 섹션을 참조하세요.
