# 임시 보안 자격 증명에 대한 권한
AWS Security Token Service(AWS STS)를 사용하면 AWS 리소스에 대한 액세스를 제어할 수 있는 임시 보안 자격 증명을 생성하여 신뢰받는 사용자에게 제공할 수 있습니다. 에 대한 자세한 내용은 AWS STS 섹션을 참조하세요.[IAM의 임시 보안 자격 증명](id_credentials_temp.md). 임시 보안 자격 증명은 AWS STS가 발급한 후 만료 기간 동안 유효하며 취소될 수 없습니다. 그러나 임시 보안 자격 증명에 할당된 권한은 자격 증명을 사용해 요청이 이루어질 때마다 평가되기 때문에 자격 증명이 발급된 이후에라도 액세스 권한을 변경함으로써 자격 증명 취소 효과를 얻을 수 있습니다.
다음 주제는 독자가 AWS 권한 및 정책에 대한 유효한 지식이 있다고 가정합니다. 이 주제에 대한 자세한 내용은 [AWS리소스에 대한 액세스 관리](access.md) 섹션을 참조하세요.
**Topics**
+ [AssumeRole, AssumeRoleWithSAML 및 AssumeRoleWithWebIdentity에 대한 권한](id_credentials_temp_control-access_assumerole.md)
+ [위임된 역할로 수행한 작업 모니터링 및 제어](id_credentials_temp_control-access_monitor.md)
+ [GetFederationToken에 대한 권한](id_credentials_temp_control-access_getfederationtoken.md)
+ [GetSessionToken에 대한 권한](id_credentials_temp_control-access_getsessiontoken.md)
+ [임시 보안 자격 증명에 대한 권한 비활성화](id_credentials_temp_control-access_disable-perms.md)
+ [임시 보안 자격 증명을 생성할 수 있는 권한 부여](id_credentials_temp_control-access_enable-create.md)
+ [ID 강화 콘솔 세션을 사용하는 권한 부여](id_credentials_temp_control-access_sts-setcontext.md)
# AssumeRole, AssumeRoleWithSAML 및 AssumeRoleWithWebIdentity에 대한 권한
수임된 역할에 대한 권한 정책은 `AssumeRole`, `AssumeRoleWithSAML` 및 `AssumeRoleWithWebIdentity`에 의해 반환되는 임시 보안 자격 증명에 대한 권한을 결정합니다. 역할을 생성 또는 업데이트할 때 이러한 권한을 정의합니다.
인라인 또는 관리형 [세션 정책](access_policies.md#policies_session)을 `AssumeRole`, `AssumeRoleWithSAML` 또는 `AssumeRoleWithWebIdentity` API 작업의 파라미터로 전달할 수 있습니다. 세션 정책은 역할의 임시 자격 증명 세션에 대한 권한을 제한합니다. 결과적으로 얻는 세션의 권한은 역할의 자격 증명 기반 정책의 교차와 세션 정책입니다. 후속 AWS API 호출 시에도 역할의 임시 자격 증명을 사용하여 역할이 속한 계정의 리소스에 액세스할 수 있습니다. 세션 정책을 사용하여 수임된 역할의 자격 증명 기반 정책에서 허용되는 것보다 더 많은 권한을 부여할 수는 없습니다. 이 역할의 효과적인 권한을 AWS가 어떻게 결정하는지 자세히 알아보려면 [정책 평가 로직](reference_policies_evaluation-logic.md) 섹션을 참조하세요.
![\[PermissionsWhenPassingRoles_Diagram\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/role_passed_policy_permissions.png)
'허용' 또는 '거부' 권한 부여 결정을 내릴 때 `AssumeRole`에 대한 원래 호출을 생성한 자격 증명에 연결된 정책은 AWS에서 평가하지 않습니다. 해당 사용자는 맡은 역할에 의해 할당된 권한을 위해 자신의 원래 권한을 일시적으로 포기합니다. `AssumeRoleWithSAML` 및 `AssumeRoleWithWebIdentity` API 작업의 경우 API 호출자가 AWS 자격 증명이 아니기 때문에 평가할 정책이 없습니다.
## 예: AssumeRole을 사용한 권한 할당
서로 다른 종류의 정책으로 `AssumeRole` API 작업을 사용할 수 있습니다. 여기 몇 가지 예가 있습니다.
### 역할 권한 정책
이 예에서는 선택 사항인 `Policy` 파라미터에 세션 정책을 지정하지 않고 `AssumeRole` API 작업을 호출합니다. 임시 자격 증명에 할당된 권한은 위임된 역할의 권한 정책에 따라 결정됩니다. 다음 예제 권한 정책은 S3 버킷 `productionapp`에 포함된 객체를 모두 나열하도록 역할 권한을 부여합니다. 또한 해당 역할이 이 버킷 내에서 객체를 가져오고, 배치하고, 삭제하도록 허용합니다.
**Example 역할 권한 정책 예**
****
```
{
"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 작업의 일부로 포함하는 것입니다. 결과적으로 얻는 세션의 권한은 사용자 또는 역할의 자격 증명 기반 정책의 교집합과 세션 정책입니다. 세션 정책을 사용하여 수임된 역할의 자격 증명 기반 정책에서 허용되는 것보다 더 많은 권한을 부여할 수는 없습니다. 역할 세션 권한에 대한 자세한 정보는 [세션 정책](access_policies.md#policies_session) 섹션을 참조하세요.
새 세션의 임시 자격 증명을 검색한 후 이를 권한을 부여하고자 하는 사용자에게 전달할 수 있습니다.
예를 들어 다음 정책이 API 호출의 파라미터로 전달된다고 가정합시다. 세션을 사용하는 사람에게는 다음 작업에 대한 수행 권한만 부여됩니다.
+ `productionapp` 버킷에 있는 모든 객체의 목록을 조회합니다.
+ 객체를 가져와 `productionapp` 버킷에 넣습니다.
다음 세션 정책에서는 `s3:DeleteObject` 권한이 필터링되어 위임된 세션에 `s3:DeleteObject` 권한이 부여되지 않습니다. 이 정책은 역할 세션에 대한 최대 권한을 설정하여 역할에 대한 기존 권한 정책을 재정의합니다.
**Example `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` 문보다 우선 적용됩니다.
**Example 버킷 정책 예제**
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": {"AWS": "*"},
"Effect": "Deny",
"Action": "s3:DeleteObject",
"Resource": "arn:aws:s3:::productionapp/*"
}
}
```
다수의 정책 유형이 AWS에 의해 어떻게 결합되고 평가되는지에 대한 자세한 정보는 [정책 평가 로직](reference_policies_evaluation-logic.md) 섹션을 참조하세요.
# 위임된 역할로 수행한 작업 모니터링 및 제어
[IAM 역할](id_roles.md)은 [권한](access_policies.md)이 할당된 IAM의 객체입니다. IAM 자격 증명 또는 AWS 외부의 자격 증명을 사용하여 [해당 역할을 수임](id_roles_manage-assume.md)하면 역할에 할당된 권한이 있는 세션을 받습니다.
AWS에서 작업을 수행하는 경우 세션에 대한 정보를 AWS CloudTrail에 로깅하여 계정 관리자가 모니터링하도록 할 수 있습니다. 관리자는 AWS에서 작업을 수행하는 사용자 또는 애플리케이션을 식별하는 사용자 지정 문자열을 전달하기 위해 자격 증명을 요구하도록 역할을 구성할 수 있습니다. 이 자격 증명 정보는 AWS CloudTrail에 *소스 자격 증명*으로 저장됩니다. 관리자가 CloudTrail에서 활동을 검토할 때 소스 자격 증명 정보를 보고 수임된 역할 세션에서 누가 또는 어떤 작업을 수행했는지 확인할 수 있습니다.
소스 자격 증명은 설정된 후에는 역할 세션 중 수행되는 모든 AWS 작업에 대해 요청에 표시됩니다. 설정된 값은 역할이 AWS CLI 또는 AWS API를 통해 다른 역할을 수임([역할 체인](id_roles.md#iam-term-role-chaining)이라고 함)할 때 유지됩니다. 역할 세션 중에는 설정된 값을 변경할 수 없습니다. 관리자는 소스 자격 증명의 존재 여부나 값에 따라 세분화된 권한을 구성하여 공유 역할로 수행되는 AWS 작업을 보다 효과적으로 제어할 수 있습니다. 소스 자격 증명 속성을 사용할 수 있는지 여부, 필요한지 여부 및 사용할 수 있는 값을 결정할 수 있습니다.
소스 자격 증명을 사용하는 방법은 역할 세션 이름 및 세션 태그와 크게 다릅니다. 소스 자격 증명 값은 설정한 후에는 변경할 수 없고 역할 세션에서 수행되는 추가 작업에 대해 유지됩니다. 세션 태그와 역할 세션 이름을 사용하는 방법은 다음과 같습니다.
+ **세션 태그** - 역할을 수임하거나 사용자를 페더레이션할 때 세션 태그를 전달할 수 있습니다. 세션 태그는 역할을 수임할 때 표시됩니다. 태그 조건 키를 사용하여 해당 태그를 기반으로 보안 주체에 권한을 부여하는 정책을 정의할 수 있습니다. 그런 다음 CloudTrail을 사용하여 역할을 수임하거나 사용자를 페더레이션하기 위한 요청을 볼 수 있습니다. 세션 태그에 대한 자세한 내용은 [AWS STS에서 세션 태그 전달](id_session-tags.md) 섹션을 참조하세요.
+ **역할 세션 이름** - 역할 신뢰 정책에서 `sts:RoleSessionName` 조건 키를 사용하여 사용자가 역할을 수임할 때 특정 세션 이름을 제공하도록 요구할 수 있습니다. 여러 보안 주체가 한 역할을 사용할 때 역할 세션 간을 구분하기 위해 역할 세션 이름을 사용할 수 있습니다. 역할 세션 이름에 대한 자세한 내용은 [sts:RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname)을 참조하세요.
역할을 수임하는 자격 증명을 제어하려는 경우 소스 자격 증명을 사용하는 것이 좋습니다. 또한 소스 자격 증명은 CloudTrail 로그를 마이닝하여 누가 역할을 사용하여 작업을 수행했는지 확인하는 데에도 유용합니다.
**Topics**
+ [소스 자격 증명을 사용하도록 설정](#id_credentials_temp_control-access_monitor-setup)
+ [소스 자격 증명에 대해 알아야 할 사항](#id_credentials_temp_control-access_monitor-know)
+ [소스 자격 증명 설정에 필요한 권한](#id_credentials_temp_control-access_monitor-perms)
+ [역할을 수임할 때 소스 자격 증명 지정](#id_credentials_temp_control-access_monitor-specify-sourceid)
+ [AssumeRole에 소스 자격 증명 사용](#id_credentials_temp_control-access_monitor-assume-role)
+ [AssumeRoleWithSAML에 소스 자격 증명 사용](#id_credentials_temp_control-access_monitor-assume-role-saml)
+ [AssumeRoleWithWebIdentity에 소스 자격 증명 사용](#id_credentials_temp_control-access_monitor-assume-role-web-id)
+ [소스 자격 증명 정보를 사용하여 액세스 제어](#id_credentials_temp_control-access_monitor-control-access)
+ [CloudTrail에서 소스 자격 증명 보기](#id_credentials_temp_control-access_monitor-ct)
## 소스 자격 증명을 사용하도록 설정
소스 자격 증명을 사용하도록 설정하는 방법은 역할을 수임할 때 사용하는 방법에 따라 다릅니다. 예를 들어 IAM 사용자는 `AssumeRole` 작업을 사용하여 역할을 수임할 수 있습니다. 엔터프라이즈 자격 증명(인력 자격 증명이라고도 함)이 있으면 `AssumeRoleWithSAML`을 사용하여 AWS 리소스에 액세스할 수 있습니다. 최종 사용자가 모바일 또는 웹 애플리케이션에 액세스하는 경우 `AssumeRoleWithWebIdentity`를 사용하여 설정할 수 있습니다. 다음은 기존 환경에서 소스 자격 증명 정보를 활용하도록 설정하는 방법을 이해하는 데 도움이 되는 간략한 작업 흐름의 개요입니다.
1. **테스트 사용자 및 역할 구성** - 프로덕션 이전 환경을 사용하여 테스트 사용자 및 역할을 구성하고 소스 자격 증명을 설정할 수 있도록 정책을 구성합니다.
페더레이션 자격 증명을 위해 자격 증명 공급자(IdP)를 사용하는 경우 어설션 또는 토큰으로 원하는 소스 자격 증명의 사용자 속성을 전달하도록 IdP를 구성합니다.
1. **역할 수임** - 테스트를 위해 설정한 사용자와 역할을 사용하여 역할 수임과 소스 자격 증명 전달을 테스트합니다.
1. **CloudTrail 검토** - CloudTrail 로그에서 테스트 역할의 소스 자격 증명 정보를 검토합니다.
1. **사용자 교육** - 프로덕션 이전 환경에서 테스트한 후에는 필요한 경우 소스 자격 증명 정보를 전달하는 방법을 사용자에게 알려야 합니다. 사용자가 프로덕션 환경에서 소스 자격 증명을 제공해야 하는 시기의 기한을 설정합니다.
1. **프로덕션 정책 구성** - 프로덕션 환경의 정책을 구성한 다음 프로덕션 사용자 및 역할에 추가합니다.
1. **활동 모니터링** - CloudTrail 로그를 사용하여 프로덕션 역할 활동을 모니터링합니다.
## 소스 자격 증명에 대해 알아야 할 사항
소스 자격 증명 사용 시 다음 사항에 유의하세요.
+ 자격 증명 공급자(IdP)에 연결된 모든 역할에 대한 역할 신뢰 정책에 `sts:SetSourceIdentity` 권한이 있어야 합니다. 역할 신뢰 정책에 이 권한이 없는 역할의 경우 `AssumeRole*` 작업이 실패합니다. 각 역할에 대한 역할 신뢰 정책을 업데이트하지 않으려는 경우 소스 자격 증명을 전달하는 데 개별 IdP 인스턴스를 사용할 수 있습니다. 그런 다음 개별 IdP에 연결된 역할에만 `sts:SetSourceIdentity` 권한을 추가합니다.
+ 자격 증명이 소스 자격 증명을 설정하는 경우 `sts:SourceIdentity` 키가 요청에 있습니다. 역할 세션 중에 수행된 후속 작업의 경우 `aws:SourceIdentity` 키가 요청에 있습니다. AWS에서는 `sts:SourceIdentity` 또는 `aws:SourceIdentity` 키에 있는 소스 자격 증명 값을 제어하지 않습니다. 소스 자격 증명을 요구하도록 선택한 경우 사용자 또는 IIdP에서 제공할 속성을 선택해야 합니다. 보안을 위해 이러한 값이 제공되는 방식을 제어할 수 있어야 합니다.
+ 소스 자격 증명의 값은 2\$164자여야 하며 영숫자, 밑줄 및 다음 문자만 포함할 수 있습니다. **. , \$1 = @ -**(하이픈). **aws:** 텍스트로 시작하는 값은 사용할 수 없습니다. 이 접두사는 AWS 내부 전용으로 예약되어 있습니다.
+ AWS 서비스 또는 서비스 연결 역할이 페더레이션 또는 인력 자격 증명 대신 작업을 수행하는 경우에는 소스 자격 증명 정보가 CloudTrail에 의해 캡처되지 않습니다.
**중요**
역할을 수임할 때 소스 자격 증명을 설정해야 하는 역할로는 AWS Management Console에서 전환할 수 없습니다. 이러한 역할을 수임하려면 AWS CLI 또는 AWS API를 사용하여 `AssumeRole` 작업을 호출하고 소스 자격 증명 파라미터를 지정할 수 있습니다.
## 소스 자격 증명 설정에 필요한 권한
API 작업과 일치하는 작업 외에도 정책에는 다음과 같은 권한 전용 작업이 있어야 합니다.
```
sts:SetSourceIdentity
```
+ 소스 자격 증명을 지정하려면 보안 주체(IAM 사용자 및 역할)에 `sts:SetSourceIdentity`에 대한 권한이 있어야 합니다. 관리자는 역할 신뢰 정책과 보안 주체의 사용 권한 정책에서 이를 구성할 수 있습니다.
+ 다른 역할이 있는 역할을 수임할 때([역할 체인](id_roles.md#iam-term-role-chaining)이라고 함) 역할을 맡는 보안 주체의 권한 정책 및 대상 역할을 역할 신뢰 정책 모두에서 `sts:SetSourceIdentity`에 대한 권한이 필요합니다. 그렇지 않으면 역할 수임 작업이 실패합니다.
+ 소스 자격 증명을 사용하는 경우 IdP에 연결된 모든 역할에 대한 역할 신뢰 정책에 `sts:SetSourceIdentity` 권한이 있어야 합니다. 이 권한 없이 IdP에 연결된 모든 역할의 경우 `AssumeRole*` 작업이 실패합니다. 각 역할에 대한 역할 신뢰 정책을 업데이트하지 않으려는 경우 소스 자격 증명을 전달하는 데 개별 IdP 인스턴스를 사용하고 별도의 IdP에 연결된 역할에만 `sts:SetSourceIdentity` 권한을 추가할 수 있습니다.
+ 계정 경계에 걸쳐 소스 자격 증명을 설정하려면 두 위치에 `sts:SetSourceIdentity` 권한을 포함해야 합니다. 원본 계정에 있는 보안 주체의 권한 정책과 대상 계정에 있는 역할의 역할 신뢰 정책에 있어야 합니다. 예를 들어 [역할 체인](id_roles.md#iam-term-role-chaining)을 통해 역할이 다른 계정의 역할을 수임하는 데 사용되는 경우 이렇게 해야 할 수 있습니다.
계정 관리자로서, 자기 계정의 IAM 사용자 `DevUser`가 동일한 계정의 `Developer_Role`을 수임하도록 허용하려 한다고 가정합니다. 하지만 사용자가 소스 자격 증명을 IAM 사용자 이름으로 설정한 경우에만 이 작업을 허용하려고 합니다. IAM 사용자에 다음 정책을 연결할 수 있습니다.
**Example DevUser에 연결된 자격 증명 기반 정책의 예**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AssumeRole",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::123456789012:role/Developer_Role"
},
{
"Sid": "SetAwsUserNameAsSourceIdentity",
"Effect": "Allow",
"Action": "sts:SetSourceIdentity",
"Resource": "arn:aws:iam::123456789012:role/Developer_Role",
"Condition": {
"StringLike": {
"sts:SourceIdentity": "${aws:username}"
}
}
}
]
}
```
허용 가능한 소스 자격 증명 값을 적용하려면 다음 역할 신뢰 정책을 구성할 수 있습니다. 이 정책은 IAM 사용자에게 역할을 수임하고 소스 자격 증명을 설정할 수 있는 `DevUser` 권한을 부여합니다. `sts:SourceIdentity` 조건 키는 허용 가능한 소스 자격 증명 값을 정의합니다.
**Example 소스 자격 증명에 대한 역할 신뢰 정책의 예**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowDevUserAssumeRole",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/DevUser"
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity"
],
"Condition": {
"StringEquals": {
"sts:SourceIdentity": "DevUser"
}
}
}
]
}
```
------
IAM 사용자 `DevUser`의 자격 증명을 사용하여 사용자가 다음 AWS CLI 요청으로 `DeveloperRole`을 수임하려고 합니다.
**Example AssumeRole CLI 요청의 예**
```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/Developer_Role \
--role-session-name Dev-project \
--source-identity DevUser \
```
AWS에서 요청을 평가할 때 요청 컨텍스트에 `DevUser`의 `sts:SourceIdentity`가 포함되어 있습니다.
## 역할을 수임할 때 소스 자격 증명 지정
AWS STS `AssumeRole*` API 작업 중 하나를 사용하여 역할의 임시 보안 자격 증명을 가져올 때 소스 자격 증명을 지정할 수 있습니다. 사용하는 API 작업은 사용 사례에 따라 다릅니다. 예를 들어 IAM 역할을 사용하여 IAM 사용자에게 보통은 액세스할 수 없는 AWS 리소스에 대한 액세스 권한을 부여하는 경우 `AssumeRole` 작업을 사용할 수 있습니다. 엔터프라이즈 ID 페더레이션을 사용하여 인력 사용자를 관리하는 경우 `AssumeRoleWithSAML` 작업을 사용할 수 있습니다. OIDC 페더레이션을 사용하여 최종 사용자가 모바일 또는 웹 애플리케이션에 액세스할 수 있도록 허용하는 경우 `AssumeRoleWithWebIdentity` 작업을 사용할 수 있습니다. 다음 섹션에서는 각 작업에 소스 자격 증명을 사용하는 방법을 설명합니다. 임시 자격 증명의 일반적인 시나리오에 대한 자세한 내용은 [임시 자격 증명과 관련된 일반적인 시나리오](id_credentials_temp.md#sts-introduction) 섹션을 참조하세요.
## AssumeRole에 소스 자격 증명 사용
`AssumeRole` 작업은 AWS 리소스에 액세스하는 데 사용할 수 있는 임시 자격 증명 세트를 반환합니다. IAM 사용자 또는 역할 자격 증명을 사용하여 `AssumeRole`을 호출할 수 있습니다. 역할을 수임하는 동안 소스 자격 증명을 전달하려면 `-–source-identity` AWS CLI 옵션 또는 `SourceIdentity` AWS API 파라미터를 사용합니다. 다음 예제에서는 AWS CLI를 사용하여 소스 자격 증명을 지정하는 방법을 보여줍니다.
**Example AssumeRole CLI 요청의 예**
```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/developer \
--role-session-name Audit \
--source-identity Admin \
```
## AssumeRoleWithSAML에 소스 자격 증명 사용
`AssumeRoleWithSAML` 작업을 호출하는 보안 주체는 SAML 기반 연동을 사용하여 인증됩니다. 이 작업은 AWS 리소스에 액세스하는 데 사용할 수 있는 임시 자격 증명 세트를 반환합니다. AWS Management Console 액세스를 위해 SAML 기반 연동을 사용하는 방법에 대한 자세한 내용은 [SAML 2.0 페더레이션 위탁자의 AWS Management Console 액세스 활성화](id_roles_providers_enable-console-saml.md) 섹션을 참조하세요. AWS CLI 또는 AWS API 액세스에 대한 자세한 내용은 [SAML 2.0 연동](id_roles_providers_saml.md) 섹션을 참조하세요. Active Directory 사용자를 위한 SAML 연동을 설정하는 방법에 대한 튜토리얼은 AWS 보안 블로그의 [Active Directory Federation Services(ADFS)를 사용한 AWS 페더레이션 인증](https://aws.amazon.com/blogs/security/aws-federated-authentication-with-active-directory-federation-services-ad-fs/)을 참조하세요.
관리자는 회사 디렉터리의 멤버가 AWS STS `AssumeRoleWithSAML` 작업을 사용하여 AWS로 연동하도록 허용할 수 있습니다. 이렇게 하려면 다음 작업을 완료해야 합니다.
1. [조직에서 SAML 공급자를 구성합니다](id_roles_providers_saml_3rd-party.md).
1. [IAM에서 SAML 공급자를 생성합니다](id_roles_providers_create_saml.md)
1. [SAML 페더레이션 보안 주체에 대해 AWS에서 역할 및 해당 권한을 구성](id_roles_create_for-idp_saml.md)합니다.
1. [SAML IdP 구성을 완료하고 SAML 인증 응답에 대한 어설션 생성하기](id_roles_providers_create_saml_assertions.md)
소스 자격 증명에 대해 SAML 속성을 설정하려면 `Name` 속성과 함께 `Attribute` 요소를 `https://aws.amazon.com/SAML/Attributes/SourceIdentity`로 설정합니다. `AttributeValue` 요소를 사용하여 소스 자격 증명 값을 지정합니다. 예를 들어, 다음 자격 증명 속성을 소스 자격 증명으로 전달한다고 가정합니다.
`SourceIdentity:DiegoRamirez`
이러한 속성을 전달하려면 SAML 어설션에 다음 요소를 포함합니다.
**Example SAML 어설션의 코드 조각 예**
```
DiegoRamirez
```
## AssumeRoleWithWebIdentity에 소스 자격 증명 사용
`AssumeRoleWithWebIdentity` 작업을 호출하는 보안 주체는 OIDC(OpenID Connect) 호환 페더레이션을 사용하여 인증됩니다. 이 작업은 AWS 리소스에 액세스하는 데 사용할 수 있는 임시 자격 증명 세트를 반환합니다. AWS Management Console 액세스를 위해 OIDC 페더레이션을 사용하는 방법에 대한 자세한 내용은 [OIDC 페더레이션](id_roles_providers_oidc.md) 섹션을 참조하세요.
OpenID Connect(OIDC)에서 소스 자격 증명을 전달하려면 JSON 웹 토큰(JWT)에 소스 자격 증명을 포함시켜야 합니다. `AssumeRoleWithWebIdentity` 요청을 제출할 때 토큰의 `[https://aws.amazon.com/](https://aws.amazon.com/)source_identity` 네임스페이스에 소스 자격 증명을 포함합니다. OIDC 토큰 및 클레임에 대한 자세한 내용은 *Amazon Cognito 개발자 안내서*의 [사용자 풀과 함께 토큰 사용](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)을 참조하세요.
예를 들어, 다음의 디코딩된 JWT는 `Admin` 소스 자격 증명과 함께 `AssumeRoleWithWebIdentity`를 호출하는 데 사용되는 토큰입니다.
**Example 디코딩된 JSON 웹 토큰의 예**
```
{
"sub": "john",
"aud": "ac_oic_client",
"jti": "ZYUCeRMQVtqHypVPWAN3VB",
"iss": "https://xyz.com",
"iat": 1566583294,
"exp": 1566583354,
"auth_time": 1566583292,
"https://aws.amazon.com/source_identity":"Admin"
}
```
## 소스 자격 증명 정보를 사용하여 액세스 제어
소스 자격 증명이 처음 설정되면 [sts:SourceIdentity](reference_policies_iam-condition-keys.md#ck_sourceidentity) 키가 요청에 표시됩니다. 소스 자격 증명이 설정된 후 [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) 키는 역할 세션 중에 수행된 모든 후속 요청에 표시됩니다. 관리자는 소스 자격 증명의 존재 또는 속성의 값에 따라 AWS 작업을 수행할 조건부 권한 부여를 부여하는 정책을 작성할 수 있습니다.
개발자가 프로덕션 크리티컬 AWS 리소스에 쓰기 권한이 있는 중요한 역할을 수임하는 소스 자격 증명을 설정하도록 요구한다고 가정해 봅시다. 또한 `AssumeRoleWithSAML`을 사용하는 인력 자격 증명에 AWS 액세스 권한을 부여한다고 가정합니다. 수석 개발자 Saanvi 및 Diego만 역할에 액세스하게 만들고 싶기 때문에 역할에 대해 다음과 같은 신뢰 정책을 생성합니다.
**Example 소스 자격 증명에 대한 역할 신뢰 정책의 예(SAML)**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "SAMLProviderAssumeRoleWithSAML",
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider"
},
"Action": [
"sts:AssumeRoleWithSAML"
],
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
},
{
"Sid": "SetSourceIdentitySrEngs",
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:saml-provider/name-of-identity-provider"
},
"Action": [
"sts:SetSourceIdentity"
],
"Condition": {
"StringLike": {
"sts:SourceIdentity": [
"Saanvi",
"Diego"
]
}
}
}
]
}
```
------
신뢰 정책에는 Saanvi 또는 Diego가 중요한 역할을 수임하도록 설정된 소스 자격 증명을 필요로 하는 `sts:SourceIdentity` 조건이 포함되어 있습니다.
또는 페더레이션을 위해 OIDC 공급자를 사용하고 사용자가 `AssumeRoleWithWebIdentity`로 인증되는 경우의 역할 신뢰 정책은 다음과 같습니다.
**Example 소스 자격 증명에 대한 역할 신뢰 정책의 예(OIDC 공급자)**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/server.example.com"
},
"Action": [
"sts:AssumeRoleWithWebIdentity",
"sts:SetSourceIdentity"
],
"Condition": {
"StringEquals": {
"server.example.com:aud": "oidc-audience-id"
},
"StringLike": {
"sts:SourceIdentity": [
"Saanvi",
"Diego"
]
}
}
}
]
}
```
------
### 역할 체인 및 교차 계정 요구 사항
`CriticalRole`을 수임한 사용자에게 다른 계정의 `CriticalRole_2`도 수임하도록 허용하고 싶다고 가정해 봅시다. `CriticalRole`을 수임하기 위해 얻은 역할 세션 자격 증명이 다른 계정의 두 번째 역할 `CriticalRole_2`로의 [역할 체인](id_roles.md#iam-term-role-chaining)에 사용됩니다. 역할이 계정 경계를 건너서 수임되고 있습니다. 따라서 `sts:SetSourceIdentity` 권한은 `CriticalRole`에 대한 권한 정책 및 `CriticalRole_2`에 대한 역할 신뢰 정책 모두에 대해 부여되어야 합니다.
**Example CriticalRole에 대한 권한 정책 예**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AssumeRoleAndSetSourceIdentity",
"Effect": "Allow",
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity"
],
"Resource": "arn:aws:iam::222222222222:role/CriticalRole_2"
}
]
}
```
------
계정 경계에 걸친 소스 자격 증명 설정을 보호하기 위해 다음 역할 신뢰 정책은 `CriticalRole`에 대한 역할 보안 주체만을 신뢰합니다.
**Example CriticalRole\$12에 대한 역할 신뢰 정책의 예제**
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111111111111:role/CriticalRole"
},
"Action": [
"sts:AssumeRole",
"sts:SetSourceIdentity"
],
"Condition": {
"StringLike": {
"aws:SourceIdentity": ["Saanvi","Diego"]
}
}
}
]
}
```
------
사용자는 CriticalRole을 수임하여 얻은 역할 세션 자격 증명을 사용하여 다음 호출을 수행합니다. 소스 자격 증명은 CriticalRole을 수임하는 동안 설정되었으므로 명시적으로 다시 설정할 필요가 없습니다. `CriticalRole`이 수임될 때 사용자가 다음과 같이 설정된 값과 다른 소스 자격 증명을 설정하려고 시도하면 역할 수임 요청이 거부됩니다.
**Example AssumeRole CLI 요청의 예**
```
aws sts assume-role \
--role-arn arn:aws:iam::222222222222:role/CriticalRole_2 \
--role-session-name Audit \
```
호출하는 보안 주체가 역할을 수임하면 요청의 소스 자격 증명은 첫 번째 수임된 역할 세션에서 유지됩니다. 따라서 `aws:SourceIdentity` 및 `sts:SourceIdentity` 키 둘 모두 요청 컨텍스트에 표시됩니다.
## CloudTrail에서 소스 자격 증명 보기
CloudTrail을 사용하여 역할을 수임하거나 사용자를 연동하기 위한 요청을 볼 수 있습니다. AWS에서 작업을 수행하는 역할 또는 사용자 요청을 볼 수도 있습니다. CloudTrail 로그 파일에는 수임하는 역할 또는 페더레이션 사용자 세션의 소스 자격 증명 설정에 대한 정보가 포함됩니다. 자세한 내용은 [AWS CloudTrail을 사용하여 IAM 및 AWS STS API 호출 로깅](cloudtrail-integration.md) 섹션을 참조하세요.
예를 들어 사용자가 AWS STS `AssumeRole` 요청을 만들고 소스 자격 증명을 설정한다고 가정합니다. CloudTrail 로그에서 `requestParameters` 키에서 `sourceIdentity` 정보를 찾을 수 있습니다.
**Example AWS CloudTrail 로그의 requestParameters 섹션 예제**
```
"eventVersion": "1.05",
"userIdentity": {
"type": "AWSAccount",
"principalId": "AIDAJ45Q7YFFAREXAMPLE",
"accountId": "111122223333"
},
"eventTime": "2020-04-02T18:20:53Z",
"eventSource": "sts.amazonaws.com",
"eventName": "AssumeRole",
"awsRegion": "us-east-1",
"sourceIPAddress": "203.0.113.64",
"userAgent": "aws-cli/1.16.96 Python/3.6.0 Windows/10 botocore/1.12.86",
"requestParameters": {
"roleArn": "arn:aws:iam::123456789012:role/DevRole",
"roleSessionName": "Dev1",
"sourceIdentity": "source-identity-value-set"
}
```
사용자가 수임된 역할 세션을 사용하여 작업을 수행하는 경우 소스 자격 증명 정보는 CloudTrail 로그의 `userIdentity` 키에 표시됩니다.
**Example AWS CloudTrail 로그의 userIdentity 키 예제**
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROAJ45Q7YFFAREXAMPLE:Dev1",
"arn": "arn:aws:sts::123456789012:assumed-role/DevRole/Dev1",
"accountId": "123456789012",
"accessKeyId": "ASIAIOSFODNN7EXAMPLE",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROAJ45Q7YFFAREXAMPLE",
"arn": "arn:aws:iam::123456789012:role/DevRole",
"accountId": "123456789012",
"userName": "DevRole"
},
"webIdFederationData": {},
"attributes": {
"mfaAuthenticated": "false",
"creationDate": "2021-02-21T23:46:28Z"
},
"sourceIdentity": "source-identity-value-present"
}
}
}
```
CloudTrail 로그의 AWS STS API 이벤트 예제를 보려면 [CloudTrail 로그의 IAM API 이벤트 예제](cloudtrail-integration.md#cloudtrail-integration_examples-iam-api) 섹션을 참조하세요. CloudTrail 로그 파일에 저장된 정보에 대한 자세한 내용은 *AWS CloudTrail 사용 설명서*의 [CloudTrail 이벤트 참조](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/eventreference.html)를 참조하세요.
# GetFederationToken에 대한 권한
IAM 사용자가 `GetFederationToken` 작업을 호출하고 해당 사용자에 대한 임시 자격 증명을 반환합니다. 이 작업은 사용자를 *연동*합니다. AWS STS 페더레이션 사용자 세션에 할당된 권한은 둘 중 한 곳에 정의되어 있습니다.
+ `GetFederationToken` API 호출의 파라미터로 전달되는 세션 정책. (가장 일반적)
+ 정책의 `Principal` 요소에서 AWS STS 페더레이션 사용자 세션의 이름을 명시적으로 지정하는 호명하는 리소스 기반 정책. (일반적이지 않음)
세션 정책은 임시 세션을 프로그래밍 방식으로 생성할 때 파라미터로 전달하는 고급 정책입니다. AWS STS 페더레이션 사용자 세션을 생성하고 세션 정책을 전달할 때 결과적으로 얻는 세션의 권한은 사용자의 ID 기반 정책과 세션 정책의 교집합입니다. 세션 정책을 사용하여 연동된 사용자의 자격 증명 기반 정책에서 허용되는 권한을 부여할 수는 없습니다.
대부분의 경우 `GetFederationToken` API 호출로 정책을 전달하지 않으면 그 결과 얻게 되는 임시 보안 자격 증명은 아무 권한이 없습니다. 하지만 리소스 기반 정책은 세션에 대한 추가 권한을 제공할 수 있습니다. 세션을 허용된 보안 주체로 지정하는 리소스 기반 정책을 사용하여 리소스에 액세스할 수 있습니다.
다음 그림은 `GetFederationToken` 호출에 의해 반환되는 임시 보안 자격 증명에 대한 권한을 정책들이 어떻게 상호 작용하여 결정하는지를 시각적으로 재현한 것입니다.
![\[IAM 사용자다음 그림은 세션 권한이 사용자의 자격 증명 기반 정책과 세션 정책의 교차점임을 나타내는 체크 표시를 보여줍니다. 세션 권한은 사용자의 자격 증명 기반 정책과 리소스 기반 정책의 교차점도 될 수 있습니다.\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/getfederationtoken-permissions.diagram.png)
## 예: GetFederationToken을 사용한 권한 할당
서로 다른 종류의 정책으로 `GetFederationToken` API 작업을 사용할 수 있습니다. 여기 몇 가지 예가 있습니다.
### IAM 사용자에게 연결된 정책은 다음과 같습니다.
이 예시에는 2개의 백엔드 웹 서비스에 의존하는 브라우저 기반 클라이언트 애플리케이션이 있습니다. 백엔드 서비스 중 하나는 자신만의 인증 서버로서 고유한 자격 증명 시스템을 사용해 클라이언트 애플리케이션을 인증합니다. 다른 백엔드 서비스는 AWS 서비스로, 클라이언트 애플리케이션의 기능 중 일부를 제공합니다. 이 클라이언트 애플리케이션은 서버에 의해 인증되고, 서버는 적절한 권한 정책을 생성하거나 가져옵니다. 서버는 이제 `GetFederationToken` API를 호출해 임시 보안 자격 증명을 얻은 다음, 그 자격 증명을 클라이언트 애플리케이션에 반환합니다. 이제 클라이언트 애플리케이션은 임시 보안 자격 증명을 사용해 AWS 서비스에 직접 요청할 수 있게 됩니다. 이 아키텍처는 클라이언트 애플리케이션이 장기 AWS 자격 증명을 포함하지 않고도 AWS 요청을 할 수 있도록 허용합니다.
인증 서버에서 이름이 `token-app`인 IAM 사용자의 장기 보안 자격 증명을 사용하여 `GetFederationToken` API를 호출합니다. 하지만 장기 IAM 사용자 자격 증명은 서버에 유지되고 클라이언트에 배포되지 않습니다. 다음 정책 예제는 `token-app` IAM 사용자에게 연결되어 AWS STS 페더레이션 사용자(클라이언트)에게 필요한 가장 폭넓은 권한 집합을 정의합니다. `sts:GetFederationToken` 권한은 인증 서비스가 AWS STS 페더레이션 사용자에 대한 임시 보안 자격 증명을 얻는 데 필요합니다.
**Example `GetFederationToken`을 호출하는 IAM 사용자 `token-app`에 연결된 정책의 예**
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "dynamodb:ListTables",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "sqs:ReceiveMessage",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "sns:ListSubscriptions",
"Resource": "*"
}
]
}
```
이전 정책은 IAM 사용자에게 여러 가지 권한을 부여합니다. 하지만 이 정책만으로는 AWS STS 페더레이션 사용자에게 권한을 부여하지 않습니다. IAM 사용자가 `GetFederationToken`을 호출하고 정책을 API 직접 호출의 파라미터로 전달하지 않는다면, 그에 따라 AWS STS 페더레이션 사용자에게는 유효한 권한이 없습니다.
### 파라미터로 전달되는 세션 정책
AWS STS 페더레이션 사용자에게 적절한 권한이 할당되도록 하는 가장 일반적인 방법은 `GetFederationToken` API 직접 호출의 세션 정책을 전달하는 것입니다. 앞의 예시를 확장해 IAM 사용자 `token-app`의 자격 증명을 사용하여 `GetFederationToken` 호출이 이루어진다고 가정합니다. 그런 다음 세션 정책이 API 호출의 파라미터로 전달된다고 가정합니다. 결과적으로 AWS STS 페더레이션 사용자는 이름이 `productionapp`인 Amazon S3 버킷의 콘텐츠를 나열할 권한을 갖습니다. 사용자는 `productionapp` 버킷의 항목들에 대한 `GetObject`, `PutObject`, Amazon S3 및 `DeleteObject` 작업을 수행할 수 없습니다.
페더레이션 사용자에게 이 권한이 할당되는 것은 권한이 IAM 사용자 정책과 전달한 세션 정책의 교차 지점이기 때문입니다.
AWS STS 페더레이션 사용자는 Amazon SNS, Amazon SQS, Amazon DynamoDB 또는 S3 버킷(`productionapp` 제외)에서 작업을 수행할 수 없습니다. 이러한 작업은 관련 권한이 `GetFederationToken` 호출과 연결된 IAM 사용자에게 부여되었더라도 거부됩니다.
**Example `GetFederationToken` API 호출의 파라미터로 전달된 세션 정책의 예**
****
```
{
"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/*"]
}
]
}
```
### 리소스 기반 정책
일부 AWS 리소스는 리소스 기반 정책을 지원하고, 이 정책은 AWS STS 페더레이션 사용자에게 직접 권한을 부여하는 또 다른 메커니즘을 제공합니다. 일부 AWS 서비스만이 리소스 기반 정책을 지원합니다. 예를 들어, Amazon S3에는 버킷이 있고, Amazon SNS에는 주제가 있고, Amazon SQS에는 정책을 연결할 수 있는 대기열이 있습니다. 리소스 기반 정책을 지원하는 모든 서비스 목록은 [AWS IAM으로 작업하는 서비스](reference_aws-services-that-work-with-iam.md) 및 표의 "리소스 기반 정책" 열을 참조하세요. 리소스 기반 정책을 사용하여 AWS STS 페더레이션 사용자에게 직접 권한을 할당할 수 있습니다. 리소스 기반 정책의 `Principal` 요소에서 AWS STS 페더레이션 사용자의 Amazon 리소스 이름(ARN)을 지정합니다. 다음 예에서는 이를 설명하고 이름이 `productionapp`인 S3 버킷을 사용하여 앞의 예시를 확장합니다.
다음 리소스 기반 정책은 버킷에 연결되어 있습니다. 이 버킷 정책은 Carol이라는 AWS STS 페더레이션 사용자가 버킷에 액세스할 수 있도록 허용합니다. 앞서 설명한 정책 예제가 `token-app` IAM 사용자에 연결되어 있으면, Carol이라는 AWS STS 페더레이션 사용자는 `productionapp`라는 버킷에 대해 `s3:GetObject`, `s3:PutObject` 및 `s3:DeleteObject` 작업을 수행할 수 있는 권한이 있습니다. 이는 `GetFederationToken` API 호출의 파라미터로 전달되는 세션 정책이 없을 때에도 해당됩니다. 이 경우에 Carol이라는 AWS STS 페더레이션 사용자에게 다음 리소스 기반 정책에 의해 명시적으로 권한이 부여되었기 때문입니다.
그 권한이 IAM 사용자 ******및 AWS STS 페더레이션 사용자 둘 다에게 명시적으로 부여될 때만 AWS STS 페더레이션 사용자에게 권한이 부여됩니다. 다음 예제처럼 정책의 `Principal` 요소에서 AWS STS 페더레이션 사용자의 이름을 명시적으로 지정하는 리소스 기반 정책을 통해서도 계정 내에서 권한을 부여할 수 있습니다.
**Example 페더레이션 사용자에 대한 액세스를 허용하는 버킷 정책의 예**
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": {
"AWS": "arn:aws:sts::111122223333:federated-user/Carol"
},
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:PutObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::productionapp/*"
]
}
}
```
정책이 평가되는 방식에 대한 자세한 내용을 알아보려면 [정책 평가 로직](reference_policies_evaluation-logic.md)을 참조하세요.
# GetSessionToken에 대한 권한
`GetSessionToken` API 작업 또는 `get-session-token` CLI 명령을 호출해야 하는 기본적인 경우는 사용자가 멀티 팩터 인증(MFA)으로 인증되어야 할 때입니다. MFA로 인증된 사용자가 요청하는 경우에 한해 특정 작업들을 허용하는 정책을 작성하는 것도 가능합니다. MFA 권한 부여 확인을 성공적으로 통과하려면 사용자는 먼저 `GetSessionToken`을 호출하여 선택 사항인 `SerialNumber` 및 `TokenCode` 파라미터를 포함해야 합니다. 사용자가 MFA 디바이스를 통해 인증을 받으면 `GetSessionToken` API 작업에서 반환하는 자격 증명에는 MFA 컨텍스트가 포함됩니다. 이 컨텍스트에서는 사용자가 MFA 디바이스를 통해 인증을 받았고 MFA 인증이 필요한 API 작업에 대한 권한이 있음을 표시합니다.
## GetSessionToken에 필요한 권한
사용자는 권한이 없어도 세션 토큰을 얻을 수 있습니다. `GetSessionToken` 작업의 목적은 MFA를 사용하는 사용자를 인증하는 것입니다. 정책을 사용하여 인증 작업을 제어할 수는 없습니다.
대부분의 AWS 작업을 수행할 수 있는 권한을 부여하려면 이름이 같은 작업을 정책에 추가합니다. 예를 들어 사용자를 생성하려면 `CreateUser` API 작업, `create-user` CLI 명령 또는 AWS Management Console을 사용해야 합니다. 이러한 작업을 수행하려면 `CreateUser` 작업에 액세스할 수 있게 허용하는 정책이 있어야 합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:CreateUser",
"Resource": "*"
}
]
}
```
------
정책에 `GetSessionToken` 작업을 포함할 수 있지만, 사용자가 `GetSessionToken` 작업을 수행할 수 있는 권한에는 영향을 미치지 않습니다.
## GetSessionToken에서 부여하는 권한
`GetSessionToken`이 IAM 사용자의 자격 증명으로 호출되면, 임시 보안 자격 증명은 IAM 사용자와 동일한 권한을 갖습니다. 마찬가지로 `GetSessionToken`이 AWS 계정 루트 사용자 보안 인증 정보로 호출되면, 임시 보안 자격 증명은 루트 사용자 권한을 갖습니다.
**참고**
루트 사용자 자격 증명으로 `GetSessionToken`을 호출하지 않는 것이 좋습니다. 대신에 [모범 사례](best-practices-use-cases.md)에 따라 필요한 권한을 지닌 IAM 사용자를 생성하세요. 그런 다음 이러한 IAM 사용자를 AWS와의 일상적인 상호 작용에 사용하세요.
`GetSessionToken`을 호출할 때 얻는 임시 자격 증명은 다음과 같은 기능과 한계를 지닙니다.
+ `https://signin.aws.amazon.com/federation`에서 페더레이션 Single Sign-On 엔드포인트로 자격 증명을 전달하여 AWS Management Console에 액세스할 수 있습니다. 자세한 내용은 [AWS 콘솔에 대한 사용자 지정 ID 브로커 액세스 활성화](id_roles_providers_enable-console-custom-url.md) 섹션을 참조하세요.
+ 자격 증명을 사용해 IAM 또는 AWS STS API 작업을 호출할 수 **없습니다**. 자격 증명을 사용해 다른 ** 서비스에 대한 API 작업을 호출할 수는 **있습니다.AWS
[AWS STS 자격 증명 비교](id_credentials_sts-comparison.md)에서 이 API 작업과 이 작업의 한계 및 기능을 임시 보안 자격 증명을 생성하는 다른 API와 비교해 보세요.
`GetSessionToken`을 사용한 MFA 보호 API 액세스에 대한 자세한 내용은 [MFA를 통한 보안 API 액세스](id_credentials_mfa_configure-api-require.md) 섹션을 참조하세요.
# 임시 보안 자격 증명에 대한 권한 비활성화
임시 보안 인증 정보는 만료될 때까지 유효합니다. 이러한 보안 인증 정보는 900초(15분)부터 최대 129,600초(36시간)까지 지정된 기간 동안 유효합니다. 기본 세션 기간은 43,200초(12시간)입니다. 이러한 보안 인증 정보는 취소할 수 있지만, 보안 인증 정보가 도용되어 악의적인 계정 활동에 사용되지 않도록 하려면 IAM 사용자 또는 역할의 권한도 변경해야 합니다. 임시 보안 인증 정보에 할당된 권한은 AWS 요청을 위해 사용될 때마다 평가됩니다. 보안 인증 정보에서 모든 권한을 제거하면 이를 사용하는 AWS 요청은 실패합니다.
정책 업데이트가 적용되는 데 몇 분 정도 걸릴 수 있습니다. IAM 역할 세션의 경우, 역할의 임시 보안 인증 정보를 취소하여 역할을 수임하는 모든 사용자에게 재인증과 새 보안 인증 정보 요청을 강제할 수 있습니다. 자세한 내용은 [역할의 임시 보안 자격 증명 취소](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html) 단원을 참조하세요.
AWS 계정 루트 사용자에 대한 권한은 변경할 수 없습니다. 따라서 루트 사용자로 로그인할 때 `GetFederationToken` 또는 `GetSessionToken`을 호출하여 생성된 임시 보안 자격 증명에 대한 권한도 변경할 수 없습니다. 이런 이유 때문에 루트 사용자로 `GetFederationToken` 또는 `GetSessionToken`을 호출하지 않는 것이 좋습니다.
IAM 사용자에 대한 권한을 변경하는 절차는 [IAM 사용자의 권한 변경](id_users_change-permissions.md) 섹션을 참조하세요.
IAM 역할에 대한 권한을 변경하는 절차는 [역할 권한 업데이트](id_roles_update-role-permissions.md) 섹션을 참조하세요.
**중요**
IAM Identity Center 권한 세트에서 생성된 역할은 IAM에서 편집할 수 없습니다. IAM Identity Center에서 사용자의 활성 권한 세트 세션을 취소해야 합니다. 자세한 내용은 *IAM Identity Center 사용 설명서*의 [권한 세트에 의해 생성된 활성 IAM 역할 세션 취소](https://docs.aws.amazon.com/singlesignon/latest/userguide/useraccess.html#revoke-user-permissions)를 참조하세요.
**Topics**
+ [역할과 관련된 모든 IAM 역할 세션에 대한 액세스 거부](#deny-access-to-all-sessions)
+ [특정 IAM 역할 세션에 대한 액세스 거부](#deny-access-to-specific-session)
+ [조건 컨텍스트 키를 사용하여 임시 보안 인증 정보 세션에 대한 액세스 거부](#deny-access-to-specific-session-condition-key)
+ [리소스 기반 정책을 사용하여 특정 보안 주체에 대한 액세스 거부](#deny-access-with-resource-based)
## 역할과 관련된 모든 IAM 역할 세션에 대한 액세스 거부
이 절차는 역할과 연결된 **모든** IAM 역할 세션에 대한 권한을 거부합니다. 다음에 의한 의심스러운 액세스가 우려되는 경우 이 방법을 사용합니다.
+ 크로스 계정 액세스를 사용하는 다른 계정의 보안 주체
+ 계정 내 AWS 리소스에 액세스할 권한이 있는 외부 사용자 자격 증명
+ OIDC 공급자를 통해 모바일 또는 웹 애플리케이션에서 인증된 사용자
`AssumeRole`, `AssumeRoleWithSAML`, `AssumeRoleWithWebIdentity`, `GetFederationToken` 또는 `GetSessionToken`을 직접적으로 호출하여 획득한 임시 보안 인증 정보에 할당된 권한을 변경하거나 제거하려면 역할에 대한 권한을 정의하는 ID 기반 정책을 편집 또는 삭제하면 됩니다.
**중요**
보안 주체 액세스를 허용하는 리소스 기반 정책이 있는 경우 해당 리소스에 대한 명시적 거부도 추가해야 합니다. 세부 정보는 [리소스 기반 정책을 사용하여 특정 보안 주체에 대한 액세스 거부](#deny-access-with-resource-based) 섹션을 참조하세요.
**역할과 관련된 **모든** IAM 역할 세션에 대한 액세스를 거부하려면**
1. AWS Management Console에 로그인하고 IAM 콘솔을 엽니다.
1. 탐색 창에서 **역할**을 선택합니다.
1. 편집할 역할의 이름을 선택합니다. 검색 상자를 사용하여 목록을 필터링할 수 있습니다.
1. **권한** 탭을 선택합니다.
1. 편집할 관련 정책을 선택합니다. 고객 관리형 정책을 편집하기 전에 **연결된 엔터티** 탭을 검토하여 동일한 정책이 연결되었을 수 있는 다른 자격 증명에 대한 액세스가 중단되지 않도록 하세요.
1. **JSON** 탭을 선택하고 정책을 업데이트하여 모든 리소스 및 작업을 거부합니다.
**참고**
이러한 권한은 AWS 관리형 정책인 [AWSDenyAll](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSDenyAll.html)에 있는 권한과 동일합니다. 이 AWS 관리형 정책을 모든 액세스를 거부하려는 모든 IAM 사용자 또는 역할에 연결할 수 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAll",
"Effect": "Deny",
"Action": [
"*"
],
"Resource": "*"
}
]
}
```
------
1. **검토** 페이지에서 정책 **요약**을 검토하고 나서 **변경 사항 저장**을 선택하여 작업을 저장합니다.
정책을 업데이트하면 이러한 변경은 역할의 권한 정책을 변경하기 전에 발급된 보안 인증 정보를 비롯해 해당 역할에 연결된 모든 임시 보안 인증 정보의 권한에 영향을 미칩니다.
정책을 업데이트한 후 [역할의 임시 보안 인증 정보를 취소](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html)하여 역할의 발급된 보안 인증 정보에 대한 모든 권한을 즉시 취소할 수 있습니다.
## 특정 IAM 역할 세션에 대한 액세스 거부
모두 거부 정책을 사용하여 IAM 역할을 업데이트하거나 역할을 완전히 삭제하면 해당 역할에 액세스할 수 있는 모든 사용자의 액세스가 중단됩니다. 역할과 연결된 다른 모든 세션의 권한에 영향을 미치지 않으면서 액세스를 거부할 수 있습니다.
`Principal`에 대한 권한은 [조건 컨텍스트 키](#deny-access-to-specific-session-condition-key) 또는 [리소스 기반 정책](#deny-access-with-resource-based)을 사용하여 거부될 수 있습니다.
**작은 정보**
AWS CloudTrail 로그를 사용하여 페더레이션 사용자의 ARN을 찾을 수 있습니다. 자세한 내용은 [How to Easily Identify Your Federated Users by Using AWS CloudTrail](https://aws.amazon.com/blogs/security/how-to-easily-identify-your-federated-users-by-using-aws-cloudtrail/)을 참조하세요.
## 조건 컨텍스트 키를 사용하여 임시 보안 인증 정보 세션에 대한 액세스 거부
보안 인증 정보를 생성한 IAM 사용자 또는 역할의 권한에 영향을 미치지 않고 임시 보안 인증 정보에 대한 액세스를 거부하고자 하는 상황에서 ID 기반 정책의 조건 컨텍스트 키를 사용할 수 있습니다. IAM 역할의 경우, 정책을 업데이트한 후 [역할의 임시 보안 인증 정보 세션을 취소](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html)하여 모든 발급된 보안 인증 정보를 즉시 취소할 수 있습니다.
조건 컨텍스트 키에 대한 자세한 내용은 [AWS 글로벌 조건 컨텍스트 키](reference_policies_condition-keys.md) 섹션을 참조하세요.
### aws:PrincipalArn
ID 기반 정책에서 조건 컨텍스트 키 [aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn)을 사용하여 Amazon 리소스 이름(ARN)을 기준으로 특정 보안 주체에 대한 액세스를 거부할 수 있습니다. IAM 사용자의 ARN, 역할 또는 AWS STS 페더레이션 사용자 세션을 지정하면 정책의 조건 요소에 임시 보안 인증 정보가 연결됩니다.
**ARN을 기준으로 특정 보안 주체에 대한 액세스를 거부하려면**
1. IAM 콘솔의 탐색 창에서 **사용자** 또는 **역할**을 선택합니다.
1. 편집할 IAM 사용자 또는 역할의 이름을 선택합니다. 검색 상자를 사용하여 목록을 필터링할 수 있습니다.
1. **권한** 탭을 선택합니다.
1. 편집할 관련 정책을 선택합니다. 고객 관리형 정책을 편집하기 전에 **연결된 엔터티** 탭을 검토하여 동일한 정책이 연결되었을 수 있는 다른 자격 증명에 대한 액세스가 중단되지 않도록 하세요.
1. **JSON** 탭을 선택하고 다음 예제와 같이 보안 주체 ARN에 대한 거부 문을 추가합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"ArnEquals": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:role/ROLENAME",
"arn:aws:iam::222222222222:user/USERNAME",
"arn:aws:iam::222222222222:federated-user/USERNAME"
]
}
}
}
]
}
```
------
1. **검토** 페이지에서 정책 **요약**을 검토하고 나서 **변경 사항 저장**을 선택하여 작업을 저장합니다.
### aws:SourceIdentity
ID 기반 정책의 조건 컨텍스트 키 [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) 사용을 통해 IAM 역할 세션과 연결된 특정 소스 ID에 대한 액세스를 거부할 수 있습니다. 이는 보안 주체가 AWS STS `assume-role`\$1 CLI 명령 또는 AWS STS `AssumeRole`\$1 API 작업을 사용하여 역할을 수임할 때 `SourceIdentity` 요청 파라미터를 설정하여 역할 세션이 실행된 경우에만 적용됩니다. 정책의 `Condition` 요소에 임시 보안 자격 증명이 연결된 소스 ID를 지정하여 이를 수행할 수 있습니다.
컨텍스트 키 [sts:RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname)과 달리 소스 ID가 설정된 후에는 값을 변경할 수 없습니다. `aws:SourceIdentity` 키는 역할에서 수행되는 모든 작업의 요청 컨텍스트에 있습니다. 세션 자격 증명을 사용하여 다른 역할을 수임하는 경우 소스 ID가 후속 역할 세션에 유지됩니다. 한 역할에서 다른 역할을 맡는 것을 [역할 체인](id_roles.md#iam-term-role-chaining)이라고 합니다.
다음 정책은 조건 컨텍스트 키 `aws:SourceIdentity`를 사용하여 임시 보안 인증 정보 세션에 대한 액세스를 거부하는 방법의 예를 보여줍니다. 역할 세션과 연결된 소스 ID를 지정하면 자격 증명을 생성한 역할의 권한에 영향을 미치지 않으면서 명명된 소스 ID가 포함된 역할 세션을 거부합니다. 이 예제에서 역할 세션이 실행되었을 때 보안 주체가 설정한 소스 ID는 `nikki_wolf@example.com`입니다. 소스 ID가 정책 조건에 포함되고 정책 효과가 `Deny`로 설정되어 있기 때문에 소스 ID `nikki_wolf@example.com`을 포함하는 역할 세션의 요청은 거부됩니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringLike": {
"aws:SourceIdentity": [
"nikki_wolf@example.com",
""
]
}
}
}
]
}
```
------
### aws:userid
ID 기반 정책의 조건 컨텍스트 키 [aws:userid](reference_policies_condition-keys.md#condition-keys-userid)를 사용하여 IAM 사용자 또는 역할에 연결된 모든 또는 특정 임시 보안 인증 정보에 대한 액세스를 거부할 수 있습니다. IAM 사용자의 고유 식별자(ID), 역할 또는 AWS STS 페더레이션 사용자를 지정하면 정책의 `Condition` 요소에 임시 보안 인증 정보가 연결됩니다.
다음 정책은 조건 컨텍스트 키 `aws:userid`를 사용하여 임시 보안 인증 정보 세션에 대한 액세스를 거부하는 방법의 예를 보여줍니다.
+ `AIDAXUSER1`은 IAM 사용자의 고유 식별자를 나타냅니다. IAM 사용자의 고유 식별자를 컨텍스트 키 `aws:userid`의 값으로 지정하면 IAM 사용자에 대한 액세스를 거부합니다. 여기에는 `GetSessionToken` API를 호출하여 생성된 임시 보안 인증 정보 세션이 포함됩니다.
+ `AROAXROLE1:*`은 IAM 역할과 연결된 모든 세션의 고유 식별자를 나타냅니다. caller-specified-role-session-name 부분에 IAM 역할의 고유 식별자와 와일드카드(\$1) 문자를 컨텍스트 키 `aws:userid`의 값으로 지정하면 역할과 연결된 모든 세션이 거부됩니다.
+ `AROAXROLE2:`은 수임한 역할 세션의 고유 식별자를 나타냅니다. 수임한 역할 고유 식별자의 호출자 지정 역할 세션 이름 부분에서 StringLike 조건 연산자가 사용되는 경우 역할 세션 이름 또는 와일드카드 문자를 지정할 수 있습니다. 역할 세션 이름을 지정하면 보안 인증 정보를 생성한 역할의 권한에 영향을 미치지 않으면서 명명된 역할 세션을 거부합니다. 역할 세션 이름에 와일드카드 문자를 지정하면 해당 역할과 연결된 모든 세션을 거부합니다.
**참고**
수임한 역할 세션의 고유 식별자에 속하는 호출자 지정 역할 세션 이름은 역할 체인 중에 변경될 수 있습니다. 역할 체인은 한 역할이 다른 역할을 수임할 때 발생합니다. 보안 주체가 AWS STS `AssumeRole` API 작업을 사용하여 역할을 수임할 때 `RoleSessionName` 요청 파라미터를 사용하여 역할 세션 이름이 설정됩니다.
+ `account-id:`은 AWS STS 페더레이션 사용자 세션의 고유 식별자를 나타냅니다. IAM 사용자는 `GetFederationToken` API를 호출하여 이 세션을 생성합니다. AWS STS 페더레이션 사용자 세션의 고유 ID를 지정하면 보안 자격 증명을 생성한 IAM 사용자의 권한에 영향을 미치지 않으면서 명명된 페더레이션 세션을 거부합니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "*",
"Resource": "*",
"Condition": {
"StringLike": {
"aws:userId": [
"AIDAXUSER1",
"AROAXROLE1:*",
"AROAXROLE2:",
"123456789012:"
]
}
}
}
]
}
```
------
key values 키 값의 구체적인 예제는 [보안 주체 키 값](reference_policies_variables.md#principaltable) 섹션을 참조하세요. IAM 고유 식별자와 이를 가져오는 방법에 대한 자세한 내용은 [고유 식별자](reference_identifiers.md#identifiers-unique-ids) 섹션을 참조하세요.
## 리소스 기반 정책을 사용하여 특정 보안 주체에 대한 액세스 거부
리소스 기반 정책을 사용하여 특정 보안 주체에 대한 액세스를 제한하려면 `Condition` 요소의 조건 컨텍스트 키 [aws:PrincipalArn](reference_policies_condition-keys.md#condition-keys-principalarn) 또는 [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity)를 사용할 수 있습니다. 리소스 기반 정책은 리소스에 액세스할 수 있는 사용자와 리소스에 대해 수행할 수 있는 작업 및 제어에 연결된 권한 정책입니다.
`aws:PrincipalARN` 컨텍스트 키를 사용할 경우, 정책의 조건 요소에 있는 임시 보안 인증 정보와 연결된 IAM 사용자, 역할 또는 AWS STS 페더레이션 사용자 세션의 ARN을 지정하세요. 다음 예제 정책은 리소스 기반 정책에서 `aws:PrincipalARN` 컨텍스트 키를 사용하는 방법을 보여줍니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": "*",
"Effect": "Deny",
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"ArnEquals": {
"aws:PrincipalArn": [
"arn:aws:iam::222222222222:role/ROLENAME",
"arn:aws:iam::222222222222:user/USERNAME",
"arn:aws:sts::222222222222:federated-user/USERNAME"
]
}
}
}
}
```
------
`aws:SourceIdentity` 컨텍스트 키를 사용할 경우, 정책의 `Condition` 요소에 있는 역할의 임시 보안 인증 정보와 연결된 소스 자격 증명 값을 지정하세요. 이는 보안 주체가 AWS STS `assume-role`\$1 CLI 명령 또는 AWS STS `AssumeRole`\$1 API 작업을 사용하여 역할을 수임할 때 `SourceIdentity` 요청 파라미터를 설정하여 역할 세션이 실행된 경우에만 적용됩니다. 다음 예제는 리소스 기반 정책에서 `aws:SourceIdentity` 컨텍스트 키를 사용하는 방법을 보여줍니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Principal": "*",
"Effect": "Deny",
"Action": "s3:*",
"Resource": "arn:aws:s3:::amzn-s3-demo-bucket",
"Condition": {
"StringLike": {
"aws:SourceIdentity": [
"nikki_wolf@example.com",
""
]
}
}
}
}
```
------
보안 주체에 대한 ID 기반 정책만 업데이트할 경우에도, ID 기반 정책에서 명시적으로 거부된 경우를 제외하고는 리소스 기반 정책에서 허용되는 작업을 계속 수행할 수 있습니다.
**리소스 기반 정책의 특정 보안 주체에 대한 액세스를 거부하려면**
1. 서비스가 리소스 기반 정책을 지원하는지 여부는 [AWS IAM으로 작업하는 서비스](reference_aws-services-that-work-with-iam.md)에서 참조하세요.
1. AWS Management Console에 로그인하고 서비스에 대한 콘솔을 엽니다. 각 서비스는 콘솔에서 정책을 연결하는 위치가 다릅니다.
1. 리소스 기반 정책을 편집합니다. 거부 문을 편집하여 보안 인증 정보의 식별 정보를 지정합니다.
1. `Principal` 요소에서 와일드카드(\$1)를 입력합니다. 보안 주체는 `Condition` 요소에서 제한됩니다.
1. `Effect` 요소에서 ‘Deny’를 입력합니다.
1. `Action`에서 거부할 서비스 네임스페이스와 작업 이름을 입력합니다. 모든 작업을 거부하려면 와일드카드 (\$1) 문자를 사용합니다. 예를 들면 `"s3:*"`입니다.
1. `Resource`에서 대상 리소스의 ARN을 입력합니다. 예를 들면 `"arn:aws:s3:::amzn-s3-demo-bucket"`입니다.
1. `Condition` 요소에서 `aws:PrincipalARN` 또는 `aws:SourceIdentity` 컨텍스트 키를 지정합니다.
`aws:PrincipalARN` 컨텍스트 키를 사용할 경우 액세스를 거부할 보안 주체의 ARN을 입력합니다.
`aws:SourceIdentity` 컨텍스트 키를 사용할 경우 액세스를 거부할 역할 세션에 설정된 소스 자격 증명 값을 입력합니다.
1. 작업을 저장합니다.
# 임시 보안 자격 증명을 생성할 수 있는 권한 부여
기본적으로 IAM 사용자는 AWS STS 페더레이션 사용자 세션 및 역할을 위한 임시 보안 자격 증명을 생성할 수 있는 권한이 없습니다. 사용자에게 이러한 권한을 제공하려면 정책을 사용해야 합니다. 사용자에게 직접 권한을 부여할 수 있지만, 그룹에게 권한을 부여할 것을 강력히 권고합니다. 그렇게 하면 권한 관리가 훨씬 쉬워집니다. 어떤 사용자가 권한에 연결된 작업을 수행할 필요가 더 이상 없는 경우에는 그룹에서 그 사용자를 삭제하기만 하면 됩니다. 다른 어떤 사용자가 그 작업을 수행해야 한다면 해당 그룹에 추가해 권한을 부여하면 됩니다.
AWS STS 페더레이션 사용자 세션 또는 역할에 대한 임시 보안 자격 증명을 생성할 수 있는 권한을 IAM 그룹에 부여하려면 다음 권한 중 하나 또는 둘 다를 부여하는 정책을 연결하면 됩니다.
+ OIDC 및 SAML 페더레이션 보안 주체가 IAM 역할에 액세스하려면 AWS STS `AssumeRole`에 대한 액세스 권한을 부여합니다.
+ 역할이 필요하지 않은 AWS STS 페더레이션 사용자의 경우 AWS STS `GetFederationToken`에 대한 액세스 권한을 부여합니다.
`AssumeRole` 및 `GetFederationToken` API 작업 간의 차이점을 보려면 [임시 보안 자격 증명 요청](id_credentials_temp_request.md) 섹션을 참조하세요.
IAM 사용자는 [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html)을 호출하여 임시 보안 자격 증명을 생성할 수도 있습니다. 사용자는 권한이 없어도 `GetSessionToken`을 호출할 수 있습니다. 이 작업의 목적은 MFA를 사용하는 사용자를 인증하는 것입니다. 정책을 사용하여 인증을 제어할 수는 없습니다. 즉 IAM 사용자가 임시 자격 증명을 생성할 목적으로 `GetSessionToken`을 호출하는 작업을 하지 못하게 할 수 없습니다.
**Example 역할 수임 권한을 부여하는 정책 예**
다음 정책 예는 AWS 계정 `123123123123`의 `UpdateApp` 역할을 위해 `AssumeRole`을 호출할 수 있는 권한을 부여합니다. `AssumeRole`을 사용하는 경우, 페더레이션 사용자를 대신해 보안 자격 증명을 생성하는 사용자(또는 애플리케이션)는 역할 권한 정책에 아직 지정되지 않은 어떤 권한도 위임할 수 없습니다.
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::123123123123:role/UpdateAPP"
}]
}
```
**Example 페더레이션 사용자를 위한 임시 보안 자격 증명을 생성할 수 있는 권한을 부여하는 정책 예**
다음과 같은 정책 예시는 `GetFederationToken`에 액세스할 수 있는 권한을 부여합니다.
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": "*"
}]
}
```
**중요**
IAM 사용자에게 `GetFederationToken`을 사용해 AWS STS 페더레이션 사용자에 대한 임시 보안 자격 증명을 생성할 수 있는 권한을 부여하는 경우 이로 인해 해당 사용자가 자신의 권한을 위임할 수 있게 허용하는 것임을 유의해야 합니다. 여러 IAM 사용자 및 AWS 계정에 걸쳐 권한을 위임하는 것에 대한 자세한 내용은 [액세스 권한 위임을 위한 정책의 예](id_roles_create_policy-examples.md) 섹션을 참조하세요. 임시 보안 자격 증명에서 권한을 제어하는 것에 대한 자세한 정보는 [임시 보안 자격 증명에 대한 권한](id_credentials_temp_control-access.md) 섹션을 참조하세요.
**Example 페더레이션 사용자에 대해 임시 보안 자격 증명을 생성할 수 있는 사용자 제한 권한을 부여하는 정책 예**
IAM 사용자가 `GetFederationToken`을 호출하도록 허용할 때는 IAM 사용자가 위임할 수 있는 권한을 제한하는 것이 좋습니다. 예를 들어 다음 정책은 IAM 사용자가 이름이 **Manager로 시작하는 AWS STS 페더레이션 사용자에 대해서만 임시 보안 자격 증명을 생성하도록 허용하는 방법을 보여줍니다.
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": ["arn:aws:sts::123456789012:federated-user/Manager*"]
}]
}
```
# ID 강화 콘솔 세션을 사용하는 권한 부여
ID 강화 콘솔 세션을 사용하면 AWS IAM Identity Center 사용자가 로그인할 때 사용자 및 세션 ID를 사용자의 AWS 콘솔 세션에 포함할 수 있습니다. 예를 들어 Amazon Q Developer Pro는 ID 강화 콘솔 세션을 사용하여 서비스 경험을 개인화합니다. ID 강화 콘솔 세션에 대한 자세한 내용은 *AWS IAM Identity Center 사용 설명서*의 [Enabling identity-enhanced console sessions](https://docs.aws.amazon.com/singlesignon/latest/userguide/identity-enhanced-sessions.html)를 참조하세요. Amazon Q Developer 설정에 대한 자세한 내용은 Amazon Q Developer 사용 설명서의 [Setting up Amazon Q Developer](https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/setting-up.html)를 참조하세요.
사용자가 ID 강화 콘솔 세션을 사용하려면 ID 기반 정책을 사용하여 IAM 위탁자에게 자신의 콘솔 세션을 나타내는 리소스에 대한 `sts:SetContext` 권한을 부여해야 합니다.
**중요**
기본적으로 사용자는 ID 강화 콘솔 세션의 컨텍스트를 설정할 권한이 없습니다. 이를 허용하려면 아래 정책 예와 같이 ID 기반 정책에서 IAM 보안 주체에게 `sts:SetContext` 권한을 부여해야 합니다.
다음 예제의 ID 기반 정책은 IAM 위탁자에 `sts:SetContext` 권한을 부여하여 위탁자가 자신의 AWS 콘솔 세션에 대해 ID 강화 콘솔 세션 컨텍스트를 설정할 수 있도록 합니다. 정책 리소스 `arn:aws:sts::account-id:self`는 호출자의 AWS 세션을 나타냅니다. IAM Identity Center 권한 세트를 사용하여 정책을 배포하는 경우와 같이 여러 계정에 동일한 권한 정책을 배포하는 경우 `account-id` ARN 세그먼트를 와일드카드 문자(`*`)로 바꿀 수 있습니다.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:SetContext",
"Resource": "arn:aws:sts::111122223333:self"
}
]
}
```
------