IAM의 교차 계정 리소스 접근

IAM의 교차 계정 리소스 접근 (Cross account resource access in IAM)

일부 AWS 서비스에서는 IAM을 사용해 리소스에 교차 계정 접근을 부여할 수 있어요. 이렇게 하려면 공유하려는 리소스에 리소스 기반 정책을 직접 연결하거나, 역할을 프록시로 사용할 수 있어요.

출처: 문서

본문

리소스를 직접 공유하려면 공유하려는 리소스가 리소스 기반 정책을 지원해야 해요. 역할의 아이덴티티 기반 정책과 달리, 리소스 기반 정책은 누가(어떤 프린시펄) 그 리소스에 접근할 수 있는지를 지정해요.

리소스 기반 정책을 지원하지 않는 다른 계정의 리소스에 접근하려면 역할을 프록시로 사용해요.

이 정책 유형들의 차이에 대한 자세한 내용은 아이덴티티 기반 정책과 리소스 기반 정책을 참고하세요.

참고

IAM 역할과 리소스 기반 정책은 단일 파티션 안에서만 계정 간에 접근을 위임해요. 예를 들어 표준 aws 파티션의 미국 서부(캘리포니아 북부)에 계정이 있고, aws-cn 파티션의 중국에도 계정이 있다고 해요. 중국 계정의 리소스 기반 정책으로 표준 AWS 계정의 사용자 접근을 허용할 수는 없어요.

역할을 사용한 교차 계정 접근

모든 AWS 서비스가 리소스 기반 정책을 지원하는 것은 아니에요. 이런 서비스에는 교차 계정 IAM 역할을 사용해 권한 관리를 중앙화할 수 있어요. 교차 계정 IAM 역할은 다른 AWS 계정의 IAM 프린시펄이 역할을 수임하도록 허용하는 트러스트 정책을 포함하는 IAM 역할이에요. 간단히 말해, 한 AWS 계정에 역할을 만들어 특정 권한을 다른 AWS 계정에 위임할 수 있어요.

IAM 아이덴티티에 정책을 연결하는 방법은 IAM 정책 관리를 참고하세요.

참고

프린시펄이 역할로 전환해 역할의 권한을 일시적으로 사용하면, 그 프린시펄은 원래 권한을 내려놓고 수임한 역할에 할당된 권한을 갖게 돼요.

APN 파트너 소프트웨어가 고객 계정에 접근해야 하는 상황에 이 과정이 어떻게 적용되는지 살펴볼게요.

  1. 고객이 자체 계정에, APN 파트너가 필요로 하는 Amazon S3 리소스에 접근을 허용하는 정책을 가진 IAM 역할을 만들어요. 이 예시에서 역할 이름은 APNPartner예요. 
    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::bucket-name"
            ]
        }
    ]
}
  2. 고객은 APN 파트너의 AWS 계정 ID를 APNPartner 역할의 트러스트 정책에 제공해, 파트너의 AWS 계정이 역할을 수임할 수 있도록 지정해요. 
    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111122223333:role/APN-user-name"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}
  3. 고객이 역할의 ARN을 APN 파트너에게 줘요. ARN은 역할의 완전한 이름이에요. 
    arn:aws:iam::Customer-Account-ID:role/APNPartner
    • 참고
      멀티 테넌트 상황에서는 외부 ID를 사용하길 권장해요. 자세한 내용은 제3자가 소유한 AWS 계정에 대한 접근을 참고하세요.
  4. APN 파트너의 소프트웨어가 고객 계정에 접근해야 할 때, 소프트웨어는 AWS Security Token Service의 AssumeRole API를 고객 계정의 역할 ARN과 함께 호출해요. STS는 소프트웨어가 작업을 수행할 수 있게 하는 임시 AWS 자격 증명을 반환해요.

역할로 교차 계정 접근을 부여하는 또 다른 예시는 우리가 소유한 다른 AWS 계정의 IAM 사용자에 대한 접근을 참고하세요. IAM 튜토리얼: IAM 역할로 AWS 계정 간 접근 위임을 따라 할 수도 있어요.

리소스 기반 정책을 사용한 교차 계정 접근

계정이 리소스 기반 정책으로 다른 계정을 통해 리소스에 접근할 때, 프린시펄은 신뢰받는 계정에서 계속 작업하며 역할 권한을 받기 위해 권한을 내려놓을 필요가 없어요. 즉 프린시펄은 신뢰하는 계정의 리소스에 접근하면서 신뢰받는 계정의 리소스에도 계속 접근할 수 있어요. 이는 다른 계정의 공유 리소스와 정보를 복사하는 같은 작업에 유용해요.

리소스 기반 정책에서 지정할 수 있는 프린시펄에는 계정, IAM 사용자, AWS STS 페더레이션 사용자 프린시펄, SAML 페더레이션 프린시펄, OIDC 페더레이션 프린시펄, IAM 역할, 수임 역할 세션, AWS 서비스가 있어요. 자세한 내용은 프린시펄 지정을 참고하세요.

신뢰 영역(신뢰하는 조직·계정) 밖의 계정에 있는 프린시펄이 역할을 수임할 수 있는지 알아보려면 외부 엔터티와 공유된 리소스 식별을 참고하세요.

다음 목록은 리소스 기반 정책을 지원하는 일부 AWS 서비스를 포함해요. 권한 정책을 프린시펄 대신 리소스에 연결하는 것을 지원하는 증가하는 AWS 서비스의 완전한 목록은 IAM과 함께 동작하는 AWS 서비스를 보고 "Resource Based" 열에 "예"가 있는 서비스를 찾으세요.

  • Amazon S3 버킷 — 정책이 버킷에 연결되지만, 정책은 버킷과 그 안의 객체 모두에 대한 접근을 제어해요. 자세한 내용은 Amazon Simple Storage Service 사용자 가이드의 Amazon S3용 Bucket 정책을 참고하세요. 어떤 경우에는 Amazon S3에 대한 교차 계정 접근에 역할을 사용하는 것이 더 나을 수 있어요. 자세한 내용은 Amazon Simple Storage Service 사용자 가이드의 예시 연습을 참고하세요.
  • Amazon Simple Notification Service(Amazon SNS) 토픽 — 자세한 내용은 Amazon Simple Notification Service 개발자 가이드의 Amazon SNS 접근 제어 예시 사례를 참고하세요.
  • Amazon Simple Queue Service(Amazon SQS) 큐 — 자세한 내용은 Amazon Simple Queue Service 개발자 가이드의 부록: 접근 정책 언어를 참고하세요.

AWS 권한을 위임하는 리소스 기반 정책

리소스가 계정의 프린시펄에게 권한을 부여한다면, 그 권한을 특정 IAM 아이덴티티에 위임할 수 있어요. 아이덴티티는 계정의 사용자, 사용자 그룹, 또는 역할이에요. 아이덴티티에 정책을 연결해 권한을 위임해요. 리소스 소유 계정이 허용하는 최대 권한까지 부여할 수 있어요.

중요

교차 계정 접근에서 프린시펄은 아이덴티티 정책과 리소스 기반 정책 둘 다에서 Allow가 필요해요.

리소스 기반 정책이 계정의 모든 프린시펄에게 리소스에 대한 전체 관리 접근을 허용한다고 가정해요. 그러면 우리 AWS 계정의 프린시펄에게 전체 접근, 읽기 전용 접근, 또는 다른 부분 접근을 위임할 수 있어요. 또는 리소스 기반 정책이 나열 권한만 허용한다면 목록 접근만 위임할 수 있어요. 계정이 가진 것보다 더 많은 권한을 위임하려 하면 프린시펄은 여전히 목록 접근만 갖게 돼요.

이러한 결정이 어떻게 이루어지는지에 대한 자세한 내용은 계정 내 요청 허용·거부 결정을 참고하세요.

참고

IAM 역할과 리소스 기반 정책은 단일 파티션 안에서만 계정 간에 접근을 위임해요. 예를 들어 표준 aws 파티션의 계정과 aws-cn 파티션의 계정 사이에는 교차 계정 접근을 추가할 수 없어요.

예를 들어 AccountA와 AccountB를 관리한다고 가정해요. AccountA에 BucketA라는 Amazon S3 버킷이 있어요.

  1. BucketA에, AccountB의 모든 프린시펄에게 버킷의 객체에 대한 전체 접근을 허용하는 리소스 기반 정책을 연결해요. 그들은 버킷의 객체를 만들고, 읽고, 삭제할 수 있어요. 
    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PrincipalAccess",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111122223333:root"
            },
            "Action": "s3:*",
            "Resource": "arn:aws:s3:::BucketA/*"
        }
    ]
}
  2. AccountA는 리소스 기반 정책에서 AccountB를 프린시펄로 지정해 AccountB에게 BucketA에 대한 전체 접근을 주어요. 결과적으로 AccountB는 BucketA에서 어떤 작업이든 수행할 권한이 있고, AccountB 관리자는 자기 계정의 사용자에게 접근을 위임할 수 있어요.
  3. AccountB 루트 사용자는 계정에 부여된 모든 권한을 가져요. 따라서 루트 사용자는 BucketA에 대한 전체 접근 권한이 있어요.
  4. AccountB에서 User2라는 IAM 사용자에, BucketA의 객체에 대한 읽기 전용 접근을 허용하는 정책을 연결해요. 이는 User2가 객체를 볼 수 있지만 만들거나, 편집하거나, 삭제할 수 없다는 뜻이에요. 
    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": "arn:aws:s3:::BucketA/*"
        }
    ]
}
  5. AccountB가 위임할 수 있는 최대 접근 수준은 계정에 부여된 접근 수준이에요. 이 경우 리소스 기반 정책이 AccountB에 전체 접근을 부여했지만 User2에게는 읽기 전용 접근만 부여됐어요.
  6. AccountB 관리자는 User1에게 접근을 주지 않았어요. 기본적으로 사용자는 명시적으로 부여된 권한 외에 어떤 권한도 없으므로 User1은 BucketA에 접근하지 못해요.

IAM은 프린시펄이 요청을 할 때 그 프린시펄의 권한을 평가해요. 와일드카드(*)로 사용자에게 리소스에 대한 전체 접근을 준다면, 프린시펄은 AWS 계정이 접근할 수 있는 어떤 리소스든 접근할 수 있어요. 이는 사용자 정책을 만든 뒤 우리가 추가하거나 접근하게 되는 리소스에도 적용돼요.

앞선 예시에서 AccountB가 User2에 모든 계정의 모든 리소스에 대한 전체 접근을 허용하는 정책을 연결했다면, User2는 AccountB가 접근할 수 있는 어떤 리소스든 자동으로 접근할 수 있어요. 여기에는 BucketA 접근과 AccountA의 리소스 기반 정책이 부여한 다른 리소스 접근이 포함돼요.

애플리케이션·서비스에 접근을 부여하는 것 같은 역할의 복잡한 사용에 대한 자세한 내용은 IAM 역할의 일반적인 시나리오를 참고하세요.

중요

신뢰하는 엔터티에게만 접근을 주고 필요한 최소 수준의 접근을 부여하세요. 신뢰하는 엔터티가 다른 AWS 계정일 때마다, 어떤 IAM 프린시펄이든 우리 리소스에 접근할 권한이 부여될 수 있어요. 신뢰하는 AWS 계정은 부여받은 접근 범위까지만 위임할 수 있어요. 계정 자체가 부여받은 것보다 더 많은 접근은 위임할 수 없어요.

권한, 정책, 정책을 작성하는 데 사용하는 권한 정책 언어에 대한 정보는 AWS 리소스 접근 관리를 참고하세요.

더 알아보기 (Learn more)