AssumeRole, AssumeRoleWithSAML, AssumeRoleWithWebIdentity의 권한

AssumeRole, AssumeRoleWithSAML, AssumeRoleWithWebIdentity의 권한 (Permissions for AssumeRole, AssumeRoleWithSAML, and AssumeRoleWithWebIdentity)

수임되는 역할의 권한 정책이 AssumeRole, AssumeRoleWithSAML, AssumeRoleWithWebIdentity가 반환하는 임시 보안 자격 증명의 권한을 결정해요. 이 권한은 역할을 만들거나 업데이트할 때 정의해요.

출처: 문서

본문

선택적으로 AssumeRole, AssumeRoleWithSAML, 또는 AssumeRoleWithWebIdentity API 작업의 파라미터로 인라인 또는 관리형 세션 정책을 전달할 수 있어요. 세션 정책은 역할의 임시 자격 증명 세션의 권한을 제한해요. 결과 세션의 권한은 역할의 아이덴티티 기반 정책과 세션 정책의 교집합이에요. 역할의 임시 자격 증명을 후속 AWS API 호출에 사용해, 역할을 소유한 계정의 리소스에 접근할 수 있어요. 세션 정책으로 수임되는 역할의 아이덴티티 기반 정책이 허용하는 것보다 더 많은 권한을 부여할 수는 없어요. AWS가 역할의 실효 권한을 어떻게 결정하는지 알아보려면 정책 평가 로직을 참고하세요.

원래 AssumeRole 호출을 만든 자격 증명에 연결된 정책은, "허용(allow)" 또는 "거부(deny)" 인가 결정을 내릴 때 AWS가 평가하지 않아요. 사용자는 원래 권한을 잠시 내려놓고 수임된 역할이 할당한 권한을 사용해요. AssumeRoleWithSAML과 AssumeRoleWithWebIdentity API 작업의 경우엔 API 호출자가 AWS 아이덴티티가 아니므로 평가할 정책이 없어요.

예시: AssumeRole로 권한 할당

AssumeRole API 작업을 다양한 종류의 정책과 함께 사용할 수 있어요. 몇 가지 예시를 볼게요.

역할 권한 정책

이 예시에서는 선택적 Policy 파라미터에 세션 정책을 지정하지 않고 AssumeRole API 작업을 호출해요. 임시 자격 증명에 할당된 권한은 수임되는 역할의 권한 정책이 결정해요. 다음 예시 권한 정책은 역할에게 productionapp이라는 S3 버킷에 포함된 모든 객체를 나열할 권한을 부여해요. 또한 그 버킷 안에서 객체를 가져오기(get), 넣기(put), 삭제하기(delete)를 허용해요.

역할 권한 정책 예시
{
  "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 버킷에서 객체를 가져오기(get)와 넣기(put)만 할 수 있게 하고 싶다고 상상해 보세요. 삭제는 허용하고 싶지 않아요. 이를 달성하는 한 가지 방법은 새 역할을 만들고 그 역할의 권한 정책에 원하는 권한을 지정하는 거예요. 또 다른 방법은 AssumeRole API를 호출할 때 선택적 Policy 파라미터에 세션 정책을 포함하는 거예요. 결과 세션의 권한은 역할의 아이덴티티 기반 정책과 세션 정책의 교집합이에요. 세션 정책으로 수임되는 역할의 아이덴티티 기반 정책이 허용하는 것보다 더 많은 권한을 부여할 수는 없어요. 역할 세션 권한에 대한 자세한 내용은 세션 정책을 참고하세요.

새 세션의 임시 자격 증명을 검색한 후에는 그 자격 증명을, 그 권한을 갖길 원하는 사용자에게 전달할 수 있어요.

예를 들어 다음 정책이 API 호출의 파라미터로 전달된다고 해 보죠. 세션을 사용하는 사람은 다음 작업만 수행할 권한이 있어요.

  • productionapp 버킷의 모든 객체 나열
  • productionapp 버킷에서 객체 가져오기(get)와 넣기(put)

다음 세션 정책에서는 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가 여러 정책 유형을 어떻게 결합·평가하는지에 대한 자세한 내용은 정책 평가 로직을 참고하세요.

더 알아보기 (Learn more)