AssumeRole, AssumeRoleWithSAML 및 AssumeRoleWithWebIdentity에 대한 권한

수임된 역할에 대한 권한 정책은 AssumeRole, AssumeRoleWithSAML 및 AssumeRoleWithWebIdentity에 의해 반환되는 임시 보안 자격 증명에 대한 권한을 결정합니다. 역할을 생성 또는 업데이트할 때 이러한 권한을 정의합니다.

인라인 또는 관리형 세션 정책을 AssumeRole, AssumeRoleWithSAML 또는 AssumeRoleWithWebIdentity API 작업의 파라미터로 전달할 수 있습니다. 세션 정책은 역할의 임시 자격 증명 세션에 대한 권한을 제한합니다. 결과적으로 얻는 세션의 권한은 역할의 자격 증명 기반 정책의 교차와 세션 정책입니다. 후속 AWS API 호출 시에도 역할의 임시 자격 증명을 사용하여 역할이 속한 계정의 리소스에 액세스할 수 있습니다. 세션 정책을 사용하여 수임된 역할의 자격 증명 기반 정책에서 허용되는 것보다 더 많은 권한을 부여할 수는 없습니다. 이 역할의 효과적인 권한을 AWS가 어떻게 결정하는지 자세히 알아보려면 정책 평가 로직 섹션을 참조하세요.

'허용' 또는 '거부' 권한 부여 결정을 내릴 때 AssumeRole에 대한 원래 호출을 생성한 자격 증명에 연결된 정책은 AWS에서 평가하지 않습니다. 해당 사용자는 맡은 역할에 의해 할당된 권한을 위해 자신의 원래 권한을 일시적으로 포기합니다. AssumeRoleWithSAML 및 AssumeRoleWithWebIdentity API 작업의 경우 API 호출자가 AWS 자격 증명이 아니기 때문에 평가할 정책이 없습니다.

예: AssumeRole을 사용한 권한 할당

서로 다른 종류의 정책으로 AssumeRole API 작업을 사용할 수 있습니다. 여기 몇 가지 예가 있습니다.

역할 권한 정책

이 예에서는 선택 사항인 Policy 파라미터에 세션 정책을 지정하지 않고 AssumeRole API 작업을 호출합니다. 임시 자격 증명에 할당된 권한은 위임된 역할의 권한 정책에 따라 결정됩니다. 다음 예제 권한 정책은 S3 버킷 productionapp에 포함된 객체를 모두 나열하도록 역할 권한을 부여합니다. 또한 해당 역할이 이 버킷 내에서 객체를 가져오고, 배치하고, 삭제하도록 허용합니다.

예 역할 권한 정책 예

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::productionapp"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::productionapp/*"
    }
  ]
}

파라미터로 전달되는 세션 정책

사용자에게 이전 예제와 동일한 역할을 수임하도록 허용하려 한다고 가정해 보겠습니다. 하지만 이 경우 역할 세션에 대해 productionapp S3 버킷에/에서 객체를 넣거나 가져오는 작업만을 허용하는 권한을 부여하고자 합니다. 객체를 삭제할 수 없도록 하고자 합니다. 이렇게 하기 위한 한 가지 방법은 새 역할을 만들어 그 역할의 권한 정책에 원하는 권한을 지정하는 것입니다. 또 다른 방법은 AssumeRole API를 호출하여 선택 사항인 Policy 파라미터의 세션 정책을 API 작업의 일부로 포함하는 것입니다. 결과적으로 얻는 세션의 권한은 사용자 또는 역할의 자격 증명 기반 정책의 교집합과 세션 정책입니다. 세션 정책을 사용하여 수임된 역할의 자격 증명 기반 정책에서 허용되는 것보다 더 많은 권한을 부여할 수는 없습니다. 역할 세션 권한에 대한 자세한 정보는 세션 정책 섹션을 참조하세요.

새 세션의 임시 자격 증명을 검색한 후 이를 권한을 부여하고자 하는 사용자에게 전달할 수 있습니다.

예를 들어 다음 정책이 API 호출의 파라미터로 전달된다고 가정합시다. 세션을 사용하는 사람에게는 다음 작업에 대한 수행 권한만 부여됩니다.

• productionapp 버킷에 있는 모든 객체의 목록을 조회합니다.

• 객체를 가져와 productionapp 버킷에 넣습니다.

다음 세션 정책에서는 s3:DeleteObject 권한이 필터링되어 위임된 세션에 s3:DeleteObject 권한이 부여되지 않습니다. 이 정책은 역할 세션에 대한 최대 권한을 설정하여 역할에 대한 기존 권한 정책을 재정의합니다.

예 AssumeRole API 호출로 전달된 세션 정책 예

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::productionapp"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::productionapp/*"
    }
  ]
}

리소스 기반 정책

일부 AWS 리소스는 리소스 기반 정책을 지원하고 이 정책은 임시 보안 자격 증명에 영향을 미치는 권한을 정의하는 또 다른 메커니즘을 제공합니다. Amazon S3 버킷, Amazon SNS 주제, Amazon SQS 대기열 같은 일부 리소스만이 리소스 기반 정책을 지원합니다. 다음 예는 앞의 예들을 확장한 것으로서 productionapp이라는 S3 버킷을 사용합니다. 다음 정책은 버킷에 연결되어 있습니다.

다음 리소스 기반 정책을 productionapp 버킷에 연결할 때 모든 사용자들은 버킷에서 객체를 삭제할 권한을 거부당합니다. (정책의 Principal 요소에 유의하세요.) 역할 권한 정책이 DeleteObject 권한을 부여한다 해도 여기에는 모든 수임된 역할 사용자들이 포함됩니다. 명시적인 Deny 문은 항상 Allow 문보다 우선 적용됩니다.

예 버킷 정책 예제

{
  "Version": "2012-10-17",
  "Statement": {
    "Principal": {"AWS": "*"},
    "Effect": "Deny",
    "Action": "s3:DeleteObject",
    "Resource": "arn:aws:s3:::productionapp/*"
  }
}

다수의 정책 유형이 AWS에 의해 어떻게 결합되고 평가되는지에 대한 자세한 정보는 정책 평가 로직 섹션을 참조하세요.