접근 위임용 정책 예제

접근 위임용 정책 예제

다음 예제는 AWS 계정이 다른 AWS 계정의 리소스에 접근하도록 허용하거나 부여하는 방법을 보여줍니다. 이러한 예제 JSON 정책 문서로 IAM 정책을 만드는 방법은 JSON 편집기로 정책 생성 문서를 참고하세요.

출처: 문서

본문

이번 강의에서 다룰 내용은 다음과 같아요.

  • 역할을 사용해 다른 AWS 계정의 리소스에 접근 위임
  • 정책을 사용해 서비스에 접근 위임
  • 리소스 기반 정책을 사용해 다른 계정의 Amazon S3 버킷에 접근 위임
  • 리소스 기반 정책을 사용해 다른 계정의 Amazon SQS 큐에 접근 위임
  • 계정이 접근이 거부되면 위임할 수 없음

역할을 사용해 다른 AWS 계정의 리소스에 접근 위임

IAM 역할을 사용해 한 계정의 사용자에게 다른 계정의 AWS 리소스 접근 권한을 부여하는 방법을 보여주는 튜토리얼은 IAM 튜토리얼: IAM 역할을 사용해 AWS 계정 간 액세스 위임 문서를 참고하세요.

중요 역할 신뢰 정책의 Principal 요소에 특정 역할이나 사용자의 ARN을 포함할 수 있어요. 정책을 저장하면 AWS가 ARN을 고유 주체 ID로 변환합니다. 이는 누군가 역할이나 사용자를 제거하고 다시 만들어 권한을 상승시키는 위험을 완화하는 데 도움이 됩니다. 콘솔에서는 신뢰 정책이 표시될 때 ARN으로 다시 역변환되므로 이 ID를 보통 볼 수 없습니다. 하지만 역할이나 사용자를 삭제하면 관계가 끊어집니다. 사용자나 역할을 다시 만들어도 신뢰 정책에 저장된 주체 ID와 일치하지 않으므로 정책이 더 이상 적용되지 않습니다. 이 경우 AWS가 ARN으로 다시 매핑할 수 없으므로 콘솔에 주체 ID가 표시됩니다. 결과적으로 신뢰 정책의 Principal 요소에서 참조되는 사용자나 역할을 삭제하고 다시 만들었다면 ARN을 교체하도록 역할을 편집해야 합니다. 정책을 저장하면 새 주체 ID로 변환됩니다.

정책을 사용해 서비스에 접근 위임

다음 예제는 역할에 연결할 수 있는 정책을 보여줍니다. 이 정책은 Amazon EMR과 AWS Data Pipeline이라는 두 서비스가 역할을 수임하도록 허용합니다. 그러면 서비스가 역할에 할당된 권한 정책(표시 안 됨)이 부여한 작업을 수행할 수 있어요. 여러 서비스 주체를 지정하려면 두 개의 Service 요소를 지정하지 마세요. 하나만 가질 수 있습니다. 대신 단일 Service 요소의 값으로 여러 서비스 주체의 배열을 사용합니다.

{
  "Version":"2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "elasticmapreduce.amazonaws.com",
          "datapipeline.amazonaws.com"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

리소스 기반 정책을 사용해 다른 계정의 Amazon S3 버킷에 접근 위임

이 예제에서 계정 A는 리소스 기반 정책(Amazon S3 버킷 정책)을 사용해 계정 A의 S3 버킷에 대한 전체 접근 권한을 계정 B에 부여합니다. 그런 다음 계정 B는 IAM 사용자 정책을 만들어 계정 A의 버킷에 대한 접근을 계정 B의 사용자 중 한 명에게 위임합니다.

계정 A의 S3 버킷 정책은 다음 정책처럼 보일 수 있습니다. 이 예제에서 계정 A의 S3 버킷 이름은 amzn-s3-demo-bucket이고, 계정 B의 계정 번호는 111122223333입니다. 개별 사용자나 그룹을 지정하지 않고 계정 자체만 지정합니다.

{
  "Version":"2012-10-17",
  "Statement": {
    "Sid": "AccountBAccess1",
    "Effect": "Allow",
    "Principal": {"AWS": "111122223333"},
    "Action": "s3:*",
    "Resource": [
      "arn:aws:s3:::amzn-s3-demo-bucket",
      "arn:aws:s3:::amzn-s3-demo-bucket/*"
    ]
  }
}

또는 계정 A는 Amazon S3 액세스 제어 목록(ACL)을 사용해 계정 B에게 S3 버킷 또는 버킷 내 단일 객체에 대한 접근 권한을 부여할 수 있어요. 이 경우 계정 A가 계정 B에 접근을 부여하는 방법만 달라집니다. 계정 B는 이 예제의 다음 부분에서 설명하는 대로 계정 B의 IAM 그룹에 접근을 위임하는 정책을 여전히 사용합니다. S3 버킷과 객체의 접근 통제에 대한 자세한 내용은 Amazon Simple Storage Service 사용자 가이드의 액세스 제어를 참고하세요.

계정 B의 관리자는 다음 샘플 정책을 만들 수 있어요. 이 정책은 계정 B의 그룹이나 사용자에게 읽기 접근을 허용합니다. 앞의 정책은 계정 B에 접근을 부여합니다. 하지만 계정 B의 개별 그룹과 사용자는 그룹이나 사용자 정책이 리소스에 대한 권한을 명시적으로 부여할 때까지 리소스에 접근할 수 없습니다. 이 정책의 권한은 앞의 교차 계정 정책의 권한 하위 집합일 수밖에 없습니다. 계정 B는 첫 번째 정책에서 계정 A가 계정 B에 부여한 것보다 더 많은 권한을 자신의 그룹과 사용자에게 부여할 수 없습니다. 이 정책에서 Action 요소는 List 작업만 허용하도록 명시적으로 정의되고, 이 정책의 Resource 요소는 계정 A가 구현한 버킷 정책의 Resource와 일치합니다.

이 정책을 구현하기 위해 계정 B는 IAM을 사용해 계정 B의 적절한 사용자(또는 그룹)에 연결합니다.

{
  "Version":"2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "s3:List*",
    "Resource": [
      "arn:aws:s3:::amzn-s3-demo-bucket",
      "arn:aws:s3:::amzn-s3-demo-bucket/*"
    ]
  }
}

리소스 기반 정책을 사용해 다른 계정의 Amazon SQS 큐에 접근 위임

다음 예제에서 계정 A에는 큐에 연결된 리소스 기반 정책을 사용해 계정 B에 큐 접근을 부여하는 Amazon SQS 큐가 있습니다. 그런 다음 계정 B는 IAM 그룹 정책을 사용해 계정 B의 그룹에 접근을 위임합니다.

다음 예제 큐 정책은 계정 B에게 2014년 11월 30일 정오부터 오후 3시 사이에만 계정 A의 queue1이라는 큐에서 SendMessage와 ReceiveMessage 작업을 수행할 권한을 부여합니다. 계정 B의 계정 번호는 1111-2222-3333입니다. 계정 A는 이 정책을 구현하기 위해 Amazon SQS를 사용합니다.

{
  "Version":"2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "111122223333"},
    "Action": [
      "sqs:SendMessage",
      "sqs:ReceiveMessage"
    ],
    "Resource": ["arn:aws:sqs:*:123456789012:queue1"],
    "Condition": {
      "DateGreaterThan": {"aws:CurrentTime": "2014-11-30T12:00Z"},
      "DateLessThan": {"aws:CurrentTime": "2014-11-30T15:00Z"}
    }
  }
}

계정 B의 그룹에 접근을 위임하는 계정 B의 정책은 다음 예제처럼 보일 수 있습니다. 계정 B는 IAM을 사용해 이 정책을 그룹(또는 사용자)에 연결합니다.

{
  "Version":"2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sqs:*",
    "Resource": "arn:aws:sqs:*:123456789012:queue1"
  }
}

앞의 IAM 사용자 정책 예제에서 계정 B는 와일드카드를 사용해 계정 A의 큐에서 모든 Amazon SQS 작업에 대한 접근을 사용자에게 부여합니다. 하지만 계정 B는 부여받은 만큼만 접근을 위임할 수 있습니다. 두 번째 정책이 있는 계정 B 그룹은 2014년 11월 30일 정오부터 오후 3시 사이에만 큐에 접근할 수 있습니다. 사용자는 계정 A의 Amazon SQS 큐 정책에 정의된 대로 SendMessage와 ReceiveMessage 작업만 수행할 수 있습니다.

계정이 접근이 거부되면 위임할 수 없음

AWS 계정은 다른 계정이 사용자의 상위 계정에 대한 접근을 명시적으로 거부한 경우 다른 계정의 리소스에 대한 접근을 위임할 수 없습니다. 사용자가 접근을 부여하는 기존 정책을 갖고 있든 없든 거부는 그 계정의 사용자에게 전파됩니다.

예를 들어 계정 A는 계정 A의 S3 버킷에 계정 B의 접근을 명시적으로 거부하는 버킷 정책을 작성합니다. 하지만 계정 B는 계정 A의 버킷에 대한 접근을 계정 B의 사용자에게 부여하는 IAM 사용자 정책을 작성합니다. 계정 A의 S3 버킷에 적용된 명시적 거부는 계정 B의 사용자에게 전파됩니다. 이는 계정 B의 사용자에게 접근을 부여하는 IAM 사용자 정책을 재정의합니다. (권한이 어떻게 평가되는지에 대한 자세한 정보는 정책 평가 논리 문서를 참고하세요.)

계정 A의 버킷 정책은 다음 정책처럼 보일 수 있습니다. 이 예제에서 계정 A의 S3 버킷 이름은 amzn-s3-demo-bucket이고, 계정 B의 계정 번호는 1111-2222-3333입니다. 계정 A는 이 정책을 구현하기 위해 Amazon S3를 사용합니다.

{
  "Version":"2012-10-17",
  "Statement": {
    "Sid": "AccountBDeny",
    "Effect": "Deny",
    "Principal": {"AWS": "111122223333"},
    "Action": "s3:*",
    "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/*"
  }
}

이 명시적 거부는 계정 A의 S3 버킷에 접근할 권한을 제공하는 계정 B의 모든 정책을 재정의합니다.

더 알아보기 (Learn more)