

# IAM 자격 증명
<a name="id"></a>

IAM 자격 증명은 하나 이상의 정책과 연결될 수 있으며, 이는 자격 증명이 수행할 권한을 받은 작업, 대상 AWS 리소스 및 관련 조건을 결정합니다. IAM 자격 증명에는 IAM 사용자, IAM 그룹 및 IAM 역할이 포함됩니다. IAM 엔터티는 사용자(사람) 또는 프로그래밍 워크로드를 대표하는 자격 증명 유형으로, 이를 통해 인증 후 AWS 계정에서 작업을 수행할 수 있는 권한을 받습니다. IAM 엔터티에는 IAM 사용자와 IAM 역할이 있습니다. 일반적으로 사용되는 용어에 대한 정의는 [용어](introduction_identity-management.md#intro-structure-terms) 섹션을 참조하세요.

외부 ID 제공업체의 기존 ID를 페더레이션할 수 있습니다. 이러한 ID는 AWS 리소스에 액세스하는 IAM 역할을 수임합니다. 자세한 내용은 [ID 공급자 및 AWS로의 페더레이션](id_roles_providers.md) 섹션을 참조하세요.

또한 ID 및 AWS 리소스 액세스 권한을 생성하고 관리하는 데에도 AWS IAM Identity Center를 사용할 수 있습니다. IAM Identity Center 권한 세트는 리소스에 대한 액세스를 제공하는 데 필요한 IAM 역할을 자동으로 생성합니다. 자세한 정보는 [IAM Identity Center란?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)을 참조하세요.

AWS 계정 루트 사용자는 AWS 계정이 설정될 때 생성되는 AWS 계정 위탁자입니다. 루트 사용자에게는 계정의 모든 AWS 서비스 및 리소스에 액세스할 수 있는 권한이 있습니다. 자세한 내용은 [IAM 루트 사용자](#id_root) 섹션을 참조하세요.

**참고**  
IAM ID에 대한 작업을 수행할 때는 [IAM 보안 모범 사례](https://docs.aws.amazon.com//IAM/latest/UserGuide/best-practices-use-cases.html)를 따르세요.
루트 사용자에 대한 작업을 수행할 때는 [AWS 계정 루트 사용자 모범 사례](root-user-best-practices.md)를 따르세요.
로그인하는 데 문제가 있는 경우 [AWS Management Console 로그인](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html)을 참조하세요.

## IAM 루트 사용자
<a name="id_root"></a>

AWS 계정을 생성할 때는 해당 계정의 모든 AWS 서비스 및 리소스에 대한 완전한 액세스 권한이 있는 단일 로그인 ID로 시작합니다. 이 자격 증명을 AWS 계정 *루트 사용자*라고 합니다. 자세한 내용은 [AWS 계정 루트 사용자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html)를 참조하세요.

## IAM 사용자
<a name="id_iam-users"></a>

*IAM 사용자*는 단일 개인 또는 애플리케이션에 대한 특정 권한을 가지고 있는 AWS 계정 내 ID입니다. 자세한 내용은 [IAM 사용자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)를 참조하세요.

## IAM 사용자 그룹
<a name="id_iam-groups"></a>

**IAM 사용자 그룹은 IAM 사용자 컬렉션을 지정하는 자격 증명입니다. 자세한 내용은 [사용자 그룹](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)을 참조하세요.

## IAM 역할
<a name="id_iam-roles"></a>

*IAM 역할*은 특정 권한을 가지고 있는 AWS 계정 계정 내 자격 증명입니다. 이 역할은 IAM 사용자와 유사하지만 특정 개인과 연결되지 않습니다. 자세한 내용은 [IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)을 참조하세요.

# AWS 계정 루트 사용자
<a name="id_root-user"></a>

Amazon Web Services(AWS) 계정을 처음 생성하는 경우에는 계정의 모든 AWS 서비스 및 리소스에 대한 전체 액세스 권한을 지닌 단일 로그인 자격 증명으로 시작합니다. 이 자격 증명을 AWS계정 루트 사용자라고 합니다.** AWS 계정을 생성할 때 사용한 이메일 주소 및 암호가 루트 사용자로 로그인할 때 사용하는 자격 증명입니다.
+ 루트 수준 권한이 필요한 작업을 수행하는 경우에만 루트 사용자를 사용합니다. 루트 사용자로 로그인해야 하는 전체 작업 목록을 보려면 [루트 사용자 보안 인증이 필요한 작업](#root-user-tasks) 섹션을 참조하세요.
+ [AWS 계정에 대한 루트 사용자 모범 사례](root-user-best-practices.md)를 따릅니다.
+ 로그인하는 데 문제가 있는 경우 [AWS Management Console 로그인](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html)을 참조하세요.

**중요**  
일상적인 작업에 루트 사용자를 사용하지 말고 [AWS 계정에 대한 루트 사용자 모범 사례](root-user-best-practices.md)를 따르는 것이 좋습니다. 루트 사용자 자격 증명을 보호하고 루트 사용자만 수행할 수 있는 작업을 수행하는 데 사용합니다. 루트 사용자로 로그인해야 하는 전체 작업 목록을 보려면 [루트 사용자 보안 인증이 필요한 작업](#root-user-tasks) 섹션을 참조하세요.

MFA는 기본적으로 루트 사용자에게 적용되지만 초기 계정 생성 중에 또는 로그인 중에 프롬프트가 표시될 때 MFA를 추가하는 고객 측 작업이 필요합니다. MFA를 사용하여 루트 사용자를 보호하는 방법에 대한 자세한 내용은 [AWS 계정 루트 사용자에 대한 다중 인증](enable-mfa-for-root.md) 섹션을 참조하세요.

## 중앙에서 멤버 계정에 대한 루트 액세스 관리
<a name="id_root-user-access-management"></a>

자격 증명을 대규모로 관리할 수 있도록 AWS Organizations에서 멤버 계정의 루트 사용자 자격 증명에 대한 액세스를 중앙에서 보호할 수 있습니다. AWS Organizations를 활성화하면 중앙 관리를 위해 모든 AWS 계정을 조직으로 결합합니다. 루트 액세스를 중앙 집중화하면 루트 사용자 자격 증명을 제거하고 멤버 계정에서 다음과 같은 권한 있는 태스크를 수행할 수 있습니다.

**멤버 계정 루트 사용자 자격 증명 제거**  
[멤버 계정에 대한 루트 액세스를 중앙 집중화](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-enable-root-access.html)한 후 Organizations의 멤버 계정에서 루트 사용자 자격 증명을 삭제하도록 선택할 수 있습니다. 루트 사용자 암호, 액세스 키, 서명 인증서를 제거하고, 다중 인증(MFA)을 비활성화할 수 있습니다. Organizations에서 생성하는 새 계정에는 기본적으로 루트 사용자 자격 증명이 없습니다. 계정 복구가 활성화되지 않으면 멤버 계정은 루트 사용자로 로그인하거나 루트 사용자의 암호 복구를 수행할 수 없습니다.

**루트 사용자 자격 증명이 필요한 권한 있는 태스크 수행**  
일부 태스크는 계정의 루트 사용자로 로그인한 경우에만 수행할 수 있습니다. 이 [루트 사용자 보안 인증이 필요한 작업](#root-user-tasks) 중 일부는 IAM에 대한 관리 계정 또는 위임된 관리자가 수행할 수 있습니다. 멤버 계정에서 권한 있는 작업을 수행하는 방법에 대해 자세히 알아보려면 [권한 있는 태스크 수행](id_root-user-privileged-task.md) 섹션을 참조하세요.

**루트 사용자의 계정 복구 활성화**  
멤버 계정에 대한 루트 사용자 자격 증명을 복구해야 하는 경우 Organizations 관리 계정 또는 위임된 관리자가 **암호 복구 허용** 권한 있는 태스크를 수행할 수 있습니다. 멤버 계정의 루트 사용자 이메일 받은 편지함에 액세스할 수 있는 사람은 [루트 사용자 암호를 재설정](https://docs.aws.amazon.com/IAM/latest/UserGuide/reset-root-password.html)하여 루트 사용자 자격 증명을 복구할 수 있습니다. 루트 사용자에 대한 액세스가 필요한 태스크를 완료한 후에는 루트 사용자 자격 증명을 삭제하는 것이 좋습니다.

# 멤버 계정에 대한 루트 액세스 중앙 집중화
<a name="id_root-enable-root-access"></a>

루트 사용자 자격 증명은 계정의 모든 AWS 서비스 및 리소스에 대한 전체 액세스 권한이 있는 각 AWS 계정에 할당된 초기 자격 증명입니다. AWS Organizations를 활성화하면 중앙 관리를 위해 모든 AWS 계정을 조직으로 결합합니다. 각 멤버 계정에는 멤버 계정에서 작업을 수행할 수 있는 기본 권한이 있는 자체 루트 사용자가 있습니다. AWS Organizations를 사용하여 관리하는 AWS 계정의 루트 사용자 자격 증명을 중앙에서 보호하여 대규모 루트 사용자 자격 증명 복구 및 액세스를 방지하는 것이 좋습니다.

루트 액세스를 중앙 집중화한 후 조직의 멤버 계정에서 루트 사용자 자격 증명을 삭제하도록 선택할 수 있습니다. 루트 사용자 암호, 액세스 키, 서명 인증서를 제거하고, 다중 인증(MFA)을 비활성화할 수 있습니다. AWS Organizations에서 생성하는 새 계정에는 기본적으로 루트 사용자 자격 증명이 없습니다. 멤버 계정은 루트 사용자로 로그인하거나 루트 사용자의 암호 복구를 수행할 수 없습니다.

**참고**  
일부 [루트 사용자 보안 인증이 필요한 작업](id_root-user.md#root-user-tasks)는 IAM의 관리 계정 또는 위임된 관리자가 수행할 수 있지만, 일부 태스크는 계정의 루트 사용자로 로그인할 때만 수행할 수 있습니다.  
이러한 작업 중 하나를 수행하기 위해 멤버 계정의 루트 사용자 자격 증명을 복구해야 하는 경우, [권한 있는 태스크 수행](id_root-user-privileged-task.md)의 단계를 따르고 **암호 복구 허용**을 선택합니다. 그러면 멤버 계정의 루트 사용자 이메일 받은 편지함에 액세스할 수 있는 사람이 단계를 따라 [루트 사용자 암호를 재설정](https://docs.aws.amazon.com/IAM/latest/UserGuide/reset-root-password.html)하고 멤버 계정 루트 사용자로 로그인할 수 있습니다.  
 루트 사용자에 대한 액세스가 필요한 태스크를 완료한 후에는 루트 사용자 자격 증명을 삭제하는 것이 좋습니다.

## 사전 조건
<a name="enable-root-access-management_prerequisite"></a>

루트 액세스를 중앙 집중화하기 전에 다음 설정으로 계정을 구성해야 합니다.
+ 이 경우 다음 IAM 권한이 있어야 합니다.
  + `iam:GetAccessKeyLastUsed`
  + `iam:GetAccountSummary`
  + `iam:GetLoginProfile`
  + `iam:GetUser`
  + `iam:ListAccessKeys`
  + `iam:ListMFADevices`
  + `iam:ListSigningCertificates`
  + `sts:AssumeRoot`
**참고**  
멤버 계정의 루트 사용자 자격 증명 상태를 감사하려면 AWS Organizations 멤버 계정에서 권한 있는 태스크를 수행할 때 [IAMAuditRootUserCredentials](security-iam-awsmanpol.md#security-iam-awsmanpol-IAMAuditRootUserCredentials) AWS 관리형 정책을 사용하여 권한 범위를 축소하거나 `iam:GetAccountSummary`에 액세스할 수 있는 정책을 사용합니다.  
루트 사용자 자격 증명 정보 보고서를 생성하려면 다른 정책에 동일한 출력을 생성하는 `iam:GetAccountSummary` 작업만 있으면 됩니다. 다음을 비롯한 개별 루트 사용자 자격 증명 정보를 나열하거나 가져올 수 있습니다.  
루트 사용자 암호가 있는지 여부
루트 사용자에게 액세스 키가 있는지 여부 및 해당 액세스 키를 마지막으로 사용한 시점
루트 사용자에게 서명 인증서가 연결되었는지 여부
루트 사용자에게 연결된 MFA 디바이스
통합 루트 사용자 자격 증명 상태 목록
+ [AWS Organizations](https://docs.aws.amazon.com//organizations/latest/userguide/orgs_introduction.html)에서 AWS 계정을 관리해야 합니다.
+ 조직에서 이 기능을 활성화하려면 다음과 같은 권한이 있어야 합니다.
  + `iam:EnableOrganizationsRootCredentialsManagement`
  + `iam:EnableOrganizationsRootSessions`
  + `iam:ListOrganizationsFeatures`
  + `organizations:EnableAwsServiceAccess`
  + `organizations:ListAccountsForParent`
  + `organizations:RegisterDelegatedAdministrator` 
+ 콘솔 기능을 최적화하려면 다음과 같은 추가 권한을 활성화하는 것이 좋습니다.
  + `organizations:DescribeAccount`
  + `organizations:DescribeOrganization`
  + `organizations:ListAWSServiceAccessForOrganization`
  + `organizations:ListDelegatedAdministrators`
  + `organizations:ListOrganizationalUnitsForParent`
  + `organizations:ListParents`
  + `organizations:ListTagsForResource`

## 중앙 집중식 루트 액세스 활성화(콘솔)
<a name="enable-root-access-console"></a>

**AWS Management Console에서 멤버 계정에 대해 이 기능을 활성화하려면 다음을 수행하세요.**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 콘솔의 탐색 창에서 **루트 액세스 관리**를 선택하고 **활성화**를 선택합니다.
**참고**  
**루트 액세스 관리가 비활성화**되어 있는 경우 AWS Organizations에서 AWS Identity and Access Management에 대해 신뢰할 수 있는 액세스를 활성화하세요. 자세한 내용은 *AWS Organizations 사용 설명서*의 [AWS IAM and AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/services-that-can-integrate-iam.html)를 참조하세요.

1. 활성화할 수 있는 기능 섹션에서 활성화할 기능을 선택합니다.
   + IAM에 대한 관리 계정과 위임된 관리자가 멤버 계정의 루트 사용자 자격 증명을 삭제할 수 있도록 허용하려면 **루트 자격 증명 관리**를 선택하세요. 멤버 계정에서 권한 있는 루트 작업을 활성화해야 멤버 계정이 루트 사용자 자격 증명을 삭제한 후에도 복구할 수 있습니다.
   + **멤버 계정의 권한 있는 루트 작업**을 선택하여 IAM에 대한 관리 계정과 위임된 관리자가 루트 사용자 자격 증명이 필요한 특정 작업을 수행할 수 있도록 허용하세요.

1. (선택 사항) 루트 사용자 액세스를 관리하고 멤버 계정에 대한 권한 있는 작업을 수행할 권한이 있는 **위임된 관리자**의 계정 ID를 입력합니다. 보안이나 관리 목적으로 사용되는 계정을 권장합니다.

1. **활성화**를 선택합니다.

## 중앙 집중식 루트 액세스 활성화(AWS CLI)
<a name="enable-root-access-cli"></a>

**AWS Command Line Interface(AWS CLI)에서 중앙 집중식 루트 액세스를 활성화하려면 다음을 수행하세요.**

1. AWS Organizations에서 AWS Identity and Access Management에 대해 신뢰할 수 있는 액세스를 아직 활성화하지 않은 경우 [aws organizations enable-aws-service-access](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/organizations/enable-aws-service-access.html) 명령을 사용합니다.

1. [aws iam enable-organizations-root-credentials-management](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/enable-organizations-root-credentials-management.html) 명령을 사용하여 관리 계정과 위임된 관리자가 멤버 계정의 루트 사용자 자격 증명을 삭제하도록 허용하세요.

1. [aws iam enable-organizations-root-sessions](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/enable-organizations-root-sessions.html) 명령을 사용하여 관리 계정과 위임된 관리자가 루트 사용자 자격 증명이 필요한 특정 작업을 수행하도록 허용하세요.

1. (선택 사항) [aws organizations register-delegated-administrator](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/organizations/register-delegated-administrator.html) 명령을 사용하여 위임된 관리자를 등록합니다.

   다음 예에서는 계정 111111111111을 IAM 서비스에 대한 위임된 관리자로 할당합니다.

   ```
   aws organizations register-delegated-administrator 
   --service-principal iam.amazonaws.com
   --account-id 111111111111
   ```

## 중앙 집중식 루트 액세스 활성화(AWS API)
<a name="enable-root-access-api"></a>

**AWS API에서 중앙 집중식 루트 액세스를 활성화하려면 다음을 수행하세요.**

1. AWS Organizations에서 AWS Identity and Access Management에 대해 신뢰할 수 있는 액세스를 아직 활성화하지 않은 경우 [EnableAWSServiceAccess](https://docs.aws.amazon.com/organizations/latest/APIReference/API_EnableAWSServiceAccess.html) 명령을 사용합니다.

1. [EnableOrganizationsRootCredentialsManagement](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableOrganizationsRootCredentialsManagement.html) 명령을 사용하여 관리 계정과 위임된 관리자가 멤버 계정의 루트 사용자 자격 증명을 삭제하도록 허용하세요.

1. [EnableOrganizationsRootSessions](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableOrganizationsRootSessions.html) 명령을 사용하여 관리 계정과 위임된 관리자가 루트 사용자 자격 증명이 필요한 특정 작업을 수행하도록 허용하세요.

1. (선택 사항) [RegisterDelegatedAdministrator](https://docs.aws.amazon.com/organizations/latest/APIReference/API_RegisterDelegatedAdministrator.html) 명령을 사용하여 위임된 관리자를 등록합니다.

## 다음 단계
<a name="enable-root-access_next-steps"></a>

조직의 멤버 계정에 대한 권한 있는 자격 증명을 중앙에서 보호한 후에는 [권한 있는 태스크 수행](id_root-user-privileged-task.md) 섹션을 참조하여 멤버 계정에서 권한 있는 작업을 수행하세요.

# AWS Organizations 멤버 계정에서 권한 있는 태스크 수행
<a name="id_root-user-privileged-task"></a>

IAM의 AWS Organizations 관리 계정 또는 위임된 관리자 계정은 멤버 계정에서 몇 가지 권한 있는 작업을 수행할 수 있습니다. 멤버 계정을 사용하지 않으면 루트 사용자 자격 증명이 필요합니다. 중앙 집중식 루트 액세스를 사용하면 이러한 태스크는 권한 있는 단기 세션을 통해 수행됩니다. 이러한 세션은 멤버 계정에 루트 사용자 로그인을 요구하지 않고 권한 있는 특정 작업으로 한정된 임시 자격 증명을 제공합니다.

권한 있는 세션을 시작하면 잘못 구성된 Amazon S3 버킷 정책을 삭제하고, 잘못 구성된 Amazon SQS 대기열 정책을 삭제하고, 멤버 계정의 루트 사용자 자격 증명을 삭제하고, 멤버 계정에 대해 루트 사용자 자격 증명을 다시 활성화할 수 있습니다.

**참고**  
중앙 집중식 루트 액세스를 사용하려면 `sts:AssumeRoot` 권한이 명시적으로 부여된 IAM 사용자 또는 역할로 관리 계정이나 위임된 관리자 계정을 통해 로그인해야 합니다. 루트 사용자 자격 증명을 사용하여 `sts:AssumeRoot`를 직접적으로 호출할 수 없습니다.

## 사전 조건
<a name="root-user-privileged-task_prerequisite"></a>

권한 있는 세션을 시작하려면 다음 설정이 필요합니다.
+ 조직에서 중앙 집중식 루트 액세스를 활성화했습니다. 이 기능을 활성화하는 단계는 [멤버 계정에 대한 루트 액세스 중앙 집중화](id_root-enable-root-access.md) 섹션을 참조하세요.
+ 관리 계정 또는 위임된 관리자 계정에 `sts:AssumeRoot` 권한이 있습니다.

## 멤버 계정에서 권한 있는 작업 수행
<a name="root-user-privileged-task_action-console"></a>

**AWS Management Console에서 멤버 계정의 권한 있는 작업에 대한 세션을 시작하려면 다음을 수행하세요.**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 콘솔의 탐색 창에서 **루트 액세스 관리**를 선택합니다.

1. 멤버 계정 목록에서 이름을 선택하고 **권한 있는 작업 수행**을 선택합니다.

1. 멤버 계정에서 수행할 권한 있는 작업을 선택합니다.
   + 모든 위탁자의 Amazon S3 버킷 액세스를 거부하는 잘못 구성된 버킷 정책을 제거하려면 **Amazon S3 버킷 정책 삭제**를 선택합니다.

     1. **S3 찾아보기**를 선택하여 멤버 계정이 소유한 버킷에서 이름을 선택하고 **선택**을 선택합니다.

     1. **버킷 정책 삭제**를 선택합니다.

     1. 잘못 구성된 정책을 삭제한 후 Amazon S3 콘솔을 사용하여 버킷 정책을 수정합니다. 자세한 내용은 * Amazon S3 사용 설명서*의 [Amazon S3 콘솔을 사용하여 버킷 정책 추가](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html)를 참조하세요.
   + 모든 위탁자가 Amazon SQS 대기열에 액세스하는 것을 거부하는 Amazon Simple Queue Service 리소스 기반 정책을 삭제하려면 **Delete Amazon SQS 정책 삭제**를 선택합니다.

     1. **SQS 대기열 이름**에 대기열 이름을 입력하고 **SQS 정책 삭제**를 선택합니다.

     1. 잘못 구성된 정책을 삭제한 후 Amazon SQS 콘솔을 사용하여 대기열 정책을 수정합니다. 자세한 내용은 *Amazon SQS 개발자 안내서*의 [Configuring an access policy in Amazon SQS](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-configure-add-permissions.html)를 참조하세요.
   + 멤버 계정에서 루트 액세스를 제거하려면 **루트 자격 증명 삭제**를 선택합니다. 루트 사용자 자격 증명을 삭제하면 루트 사용자 암호, 액세스 키, 서명 인증서가 제거되고 멤버 계정에 대한 다중 인증(MFA)이 비활성화됩니다.

     1. **루트 자격 증명 삭제**를 선택합니다.
   + 멤버 계정에 대한 루트 사용자 자격 증명을 복구하려면 **암호 복구 허용**을 선택합니다.

     이 옵션은 멤버 계정에 루트 사용자 자격 증명이 없는 경우에만 사용할 수 있습니다.

     1. **암호 복구 허용**을 선택합니다.

     1. 이 권한 있는 작업을 수행한 후 멤버 계정의 루트 사용자 이메일 받은 편지함에 액세스할 수 있는 사람은 [루트 사용자 암호를 재설정](https://docs.aws.amazon.com/IAM/latest/UserGuide/reset-root-password.html)하고 멤버 계정 루트 사용자로 로그인할 수 있습니다.

## 멤버 계정에서 권한 있는 작업 수행(AWS CLI)
<a name="root-user-privileged-task_action-cli"></a>

**AWS Command Line Interface에서 멤버 계정의 권한 있는 작업에 대한 세션을 시작하려면 다음을 수행하세요.**

1. [aws sts assume-root](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sts/assume-root.html) 명령을 사용하여 루트 사용자 세션을 수임합니다.
**참고**  
`sts:AssumeRoot`에는 글로벌 엔드포인트가 지원되지 않습니다. 이 요청을 리전 AWS STS 엔드포인트로 보내야 합니다. 자세한 내용은 [AWS 리전에서 AWS STS 관리](id_credentials_temp_enable-regions.md) 섹션을 참조하세요.

   멤버 계정에 대해 권한 있는 루트 사용자 세션을 시작할 때 `task-policy-arn`을 정의하여 세션 중 수행할 권한 있는 작업에 대한 세션 범위를 지정해야 합니다. 다음 AWS 관리형 정책 중 하나를 사용하여 권한 있는 세션 작업의 범위를 지정할 수 있습니다.
   + [IAMAuditRootUserCredentials](security-iam-awsmanpol.md#security-iam-awsmanpol-IAMAuditRootUserCredentials)
   + [IAMCreateRootUserPassword](security-iam-awsmanpol.md#security-iam-awsmanpol-IAMCreateRootUserPassword)
   + [IAMDeleteRootUserCredentials](security-iam-awsmanpol.md#security-iam-awsmanpol-IAMDeleteRootUserCredentials)
   + [S3UnlockBucketPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-S3UnlockBucketPolicy)
   + [SQSUnlockQueuePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-SQSUnlockQueuePolicy)

   권한 있는 루트 사용자 세션 중 관리 계정 또는 위임된 관리자가 수행할 수 있는 작업을 제한하려면 AWS STS 조건 키 [sts:TaskPolicyArn](reference_policies_iam-condition-keys.md#ck_taskpolicyarn)을 사용합니다.

    다음 예에서는 위임된 관리자가 루트를 수임하여 멤버 계정 ID *111122223333*에 대한 루트 사용자 자격 증명을 삭제합니다.

   ```
   aws sts assume-root \
     --target-principal 111122223333 \
     --task-policy-arn arn=arn:aws:iam::aws:policy/root-task/IAMDeleteRootUserCredentials \
     --duration-seconds 900
   ```

1. 응답에서 `SessionToken`, `AccessKeyId`, `SecretAccessKey`를 사용하여 멤버 계정에서 권한 있는 작업을 수행합니다. 요청에서 사용자 이름과 암호를 생략하여 멤버 계정으로 기본 설정할 수 있습니다.
   + **루트 사용자 자격 증명의 상태를 확인합니다**. 멤버 계정의 루트 사용자 자격 증명 상태를 확인하려면 다음 명령을 사용합니다.
     + [get-user](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/get-user.html)
     + [get-login-profile](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/get-login-profile.html)
     + [list-access-keys](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-access-keys.html)
     + [list-signing-certificates](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-signing-certificates.html)
     + [list-mfa-devices](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-mfa-devices.html)
     + [get-access-key-last-used](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/get-access-key-last-used.html)
   + **루트 사용자 자격 증명을 삭제합니다**. 루트 액세스를 삭제하려면 다음 명령을 사용합니다. 루트 사용자 암호, 액세스 키, 서명 인증서를 제거하고, 다중 인증(MFA)을 비활성화하여 루트 사용자에 대한 모든 액세스 및 복구를 제거할 수 있습니다.
     + [delete-login-profile](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/delete-login-profile.html)
     + [delete-access-key](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/delete-access-key.html)
     + [delete-signing-certificate](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/delete-signing-certificate.html)
     + [deactivate-mfa-device](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/deactivate-mfa-device.html)
   + **Amazon S3 버킷 정책을 삭제합니다**. 모든 위탁자의 Amazon S3 버킷 액세스를 거부하는 잘못 구성된 버킷 정책을 읽고, 편집하고, 삭제하려면 다음 명령을 사용합니다.
     + [list-buckets](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/list-buckets.html)
     + [get-bucket-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/get-bucket-policy.html)
     + [put-bucket-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/put-bucket-policy.html)
     + [delete-bucket-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3api/delete-bucket-policy.html)
   + **Amazon SQS 정책을 삭제합니다**. 모든 위탁자가 Amazon SQS 대기열에 액세스하는 것을 거부하는 Amazon Simple Queue Service 리소스 기반 정책을 보고 삭제하려면 다음 명령을 사용합니다.
     + [list-queues](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sqs/list-queues.html)
     + [get-queue-url](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sqs/get-queue-url.html)
     + [get-queue-attributes](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sqs/get-queue-attributes.html)
     + [set-queue-attributes](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sqs/set-queue-attributes.html)
   + **암호 복구를 허용합니다**. 사용자 이름을 보고 멤버 계정에 대한 루트 사용자 자격 증명을 복구하려면 다음 명령을 사용합니다.
     + [get-login-profile](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/get-login-profile.html)
     + [create-login-profile](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-login-profile.html)

## 멤버 계정에서 권한 있는 작업 수행(AWS API)
<a name="root-user-privileged-task_action-api"></a>

**AWS API에서 멤버 계정의 권한 있는 작업에 대한 세션을 시작하려면 다음을 수행하세요.**

1. [AssumeRoot](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoot.html) 명령을 사용하여 루트 사용자 세션을 가장합니다.
**참고**  
AssumeRoot에는 글로벌 엔드포인트가 지원되지 않습니다. 이 요청을 리전 AWS STS 엔드포인트로 보내야 합니다. 자세한 내용은 [AWS 리전에서 AWS STS 관리](id_credentials_temp_enable-regions.md) 섹션을 참조하세요.

   멤버 계정에 대해 권한 있는 루트 사용자 세션을 시작할 때 `TaskPolicyArn`을 정의하여 세션 중 수행할 권한 있는 작업에 대한 세션 범위를 지정해야 합니다. 다음 AWS 관리형 정책 중 하나를 사용하여 권한 있는 세션 작업의 범위를 지정할 수 있습니다.
   + [IAMAuditRootUserCredentials](security-iam-awsmanpol.md#security-iam-awsmanpol-IAMAuditRootUserCredentials)
   + [IAMCreateRootUserPassword](security-iam-awsmanpol.md#security-iam-awsmanpol-IAMCreateRootUserPassword)
   + [IAMDeleteRootUserCredentials](security-iam-awsmanpol.md#security-iam-awsmanpol-IAMDeleteRootUserCredentials)
   + [S3UnlockBucketPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-S3UnlockBucketPolicy)
   + [SQSUnlockQueuePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-SQSUnlockQueuePolicy)

   권한 있는 루트 사용자 세션 중 관리 계정 또는 위임된 관리자가 수행할 수 있는 작업을 제한하려면 AWS STS 조건 키 [sts:TaskPolicyArn](reference_policies_iam-condition-keys.md#ck_taskpolicyarn)을 사용합니다.

   다음 예에서 위임된 관리자는 멤버 계정 ID *111122223333*의 Amazon S3 버킷에 대해 잘못 구성된 리소스 기반 정책을 읽고, 편집하고, 삭제할 루트를 수임합니다.

   ```
   https://sts.us-east-2.amazonaws.com/
     ?Version=2011-06-15
     &Action=AssumeRoot
     &TargetPrincipal=111122223333
     &PolicyArns.arn=arn:aws:iam::aws:policy/root-task/S3UnlockBucketPolicy 
     &DurationSeconds 900
   ```

1. 응답에서 `SessionToken`, `AccessKeyId`, `SecretAccessKey`를 사용하여 멤버 계정에서 권한 있는 작업을 수행합니다. 요청에서 사용자 이름과 암호를 생략하여 멤버 계정으로 기본 설정할 수 있습니다.
   + **루트 사용자 자격 증명의 상태를 확인합니다**. 멤버 계정에 대한 루트 사용자 자격 증명 상태를 확인하려면 다음 명령을 사용합니다.
     + [GetUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetUser.html)
     + [GetLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetLoginProfile.html)
     + [ListAccessKeys](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccessKeys.html)
     + [ListSigningCertificates](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListSigningCertificates.html)
     + [ListMFADevices](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListMFADevices.html)
     + [GetAccessKeyLastUsed](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html)
   + **루트 사용자 자격 증명을 삭제합니다**. 루트 액세스를 삭제하려면 다음 명령을 사용합니다. 루트 사용자 암호, 액세스 키, 서명 인증서를 제거하고, 다중 인증(MFA)을 비활성화하여 루트 사용자에 대한 모든 액세스 및 복구를 제거할 수 있습니다.
     + [DeleteLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteLoginProfile.html)
     + [DeleteAccessKey](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccessKey.html)
     + [DeleteSigningCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteSigningCertificate.html)
     + [DeactivateMfaDevice](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html)
   + **Amazon S3 버킷 정책을 삭제합니다**. 모든 위탁자가 Amazon S3 버킷에 액세스하지 못하도록 거부하는 잘못 구성된 버킷 정책을 읽고, 편집하고, 삭제하려면 다음 명령을 사용합니다.
     + [ListBuckets](https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListBuckets.html)
     + [GetBucketPolicy](https://docs.aws.amazon.com/AmazonS3/latest/API/API_GetBucketPolicy.html)
     + [PutBucketPolicy](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutBucketPolicy.html)
     + [DeleteBucketPolicy](https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteBucketPolicy.html)
   + **Amazon SQS 정책을 삭제합니다**. 모든 위탁자가 Amazon SQS 대기열에 액세스하는 것을 거부하는 Amazon Simple Queue Service 리소스 기반 정책을 보고 삭제하려면 다음 명령을 사용합니다.
     + [ListQueues](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_ListQueues.html)
     + [GetQueueUrl](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_GetQueueUrl.html)
     + [GetQueueAttributes](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_GetQueueAttributes.html)
     + [SetQueueAttributes](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/APIReference/API_SetQueueAttributes.html)
   + **암호 복구를 허용합니다**. 사용자 이름을 보고 멤버 계정의 루트 사용자 자격 증명을 복구하려면 다음 명령을 사용합니다.
     + [GetLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetLoginProfile.html)
     + [CreateLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateLoginProfile.html)

# AWS 계정 루트 사용자에 대한 다중 인증
<a name="enable-mfa-for-root"></a>

**중요**  
AWS는 가능한 한 AWS에 대한 MFA에 패스키나 보안 키를 사용할 것을 권장합니다. 패스키나 보안 키가 피싱과 같은 공격에 더 강하기 때문입니다. 자세한 내용은 [패스키 및 보안 키](#passkeys-security-keys-for-root) 섹션을 참조하세요.

다중 인증(MFA)은 보안을 강화하는 간단하고 효과적인 메커니즘입니다. 첫 번째 요소인 암호는 기억해야 하는 비밀이며 지식 요소라고도 합니다. 다른 요소로는 보유 요소(보안 키 등 귀하가 보유하는 것) 또는 고유 요소(생체인식 스캔 등 귀하에 대한 것)가 있습니다. 보안 강화를 위해 다중 인증(MFA)을 구성하여 AWS 리소스를 보호하는 것이 좋습니다.

**참고**  
모든 AWS 계정 유형(독립 실행형, 관리 및 멤버 계정)은 루트 사용자에 대해 MFA를 구성해야 합니다. MFA가 아직 활성화되지 않은 경우 사용자는 AWS Management Console에 액세스하기 위해 처음 로그인을 시도한 날로부터 35일 이내에 MFA를 등록해야 합니다.

AWS 계정 루트 사용자와 IAM 사용자에 대해 MFA를 활성화할 수 있습니다. 루트 사용자에 대해 활성화한 MFA는 루트 사용자 자격 증명에만 영향을 줍니다. IAM 사용자에 대해 MFA를 활성화하는 방법에 대한 자세한 내용은 [IAM의 AWS 다중 인증](id_credentials_mfa.md) 단원을 참조하세요.

**참고**  
AWS Organizations를 사용하여 관리하는 AWS 계정에는 자격 증명 복구 및 대규모 액세스를 방지하기 위해 멤버 계정의 [루트 액세스를 중앙에서 관리하는](id_root-user.md#id_root-user-access-management) 옵션이 있을 수 있습니다. 이 옵션을 활성화하는 경우 암호 및 MFA를 포함하여 멤버 계정에서 루트 사용자 자격 증명을 삭제하여 루트 사용자로 로그인, 암호 복구 또는 MFA 설정을 효과적으로 방지할 수 있습니다. 또는 암호 기반 로그인 방법을 유지 관리하려는 경우 계정 보호를 강화하기 위해 MFA를 등록하여 계정을 보호합니다.

루트 사용자에 대해 MFA를 활성화하기 전에 [계정 설정과 연락처 정보를 검토하고 업데이트](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-root-user.html)하여 이메일 및 전화번호에 대한 액세스 권한이 있는지 확인합니다. MFA 디바이스가 분실 또는 도난되었거나 작동하지 않는 경우에도 해당 이메일과 전화번호를 사용하여 자격 증명을 확인하여 루트 사용자로 로그인할 수 있습니다. 다른 인증 요소를 사용하여 로그인하는 방법은 [IAM에서 MFA로 보호되는 ID 복구](id_credentials_mfa_lost-or-broken.md) 섹션을 참조하세요. 이 기능을 비활성화하려면 [AWS Support](https://console.aws.amazon.com/support/home#/)에 문의하세요.

AWS는 루트 사용자를 위해 다음과 같은 MFA 유형을 지원합니다.
+ [패스키 및 보안 키](#passkeys-security-keys-for-root)
+ [가상 인증 애플리케이션](#virtual-auth-apps-for-root)
+ [하드웨어 TOTP 토큰](#hardware-totp-token-for-root)

## 패스키 및 보안 키
<a name="passkeys-security-keys-for-root"></a>

AWS Identity and Access Management는 MFA용 패스키 및 보안 키를 지원합니다. FIDO 표준에 기반한 패스키는 퍼블릭 키 암호화 기법을 사용하여 암호보다 안전한 강력한 피싱 방지 인증을 제공합니다. AWS는 디바이스 바운드 패스키(보안 키)와 동기화된 패스키라는 두 가지 유형의 패스키를 지원합니다.
+ **보안 키**: YubiKey처럼 2차 인증 요소로 사용되는 물리적 디바이스입니다. 하나의 보안 키가 여러 루트 사용자 계정과 IAM 사용자를 지원할 수 있습니다.
+ **동기화된 패스키**: Google, Apple, Microsoft 계정 같은 공급자와 1Password, Dashlane, Bitwarden 같은 서드 파티 서비스의 자격 증명 관리자를 2차 인증 요소로 사용합니다.

Apple MacBook의 Touch ID와 같은 내장된 생체 인식 인증자를 사용하여 자격 증명 관리자의 잠금을 해제하고 AWS에 로그인할 수 있습니다. 패스키는 지문, 얼굴 또는 디바이스 PIN을 사용하여 선택한 공급자와 함께 생성됩니다. 또한 모바일 디바이스 또는 하드웨어 보안 키와 같은 한 디바이스에 있는 교차 디바이스 인증(CDA) 패스키로 노트북 등의 다른 디바이스에 로그인할 수 있습니다. 자세한 내용은 [교차 디바이스 인증](https://passkeys.dev/docs/reference/terms/#cross-device-authentication-cda)(CDA)을 참조하세요.

디바이스 간에 패스키를 동기화하여 AWS 로그인을 용이하게 하고 사용성과 복구 가능성을 높일 수 있습니다. 패스키 및 보안 키 활성화에 대한 자세한 내용은 [루트 사용자용 패스키 또는 보안 키 활성화(콘솔)](enable-fido-mfa-for-root.md) 섹션을 참조하세요.

FIDO Alliance는 FIDO 사양과 호환되는 모든 [FIDO 인증 제품](https://fidoalliance.org/certification/fido-certified-products/) 목록을 유지 관리합니다.

## 가상 인증 애플리케이션
<a name="virtual-auth-apps-for-root"></a>

가상 인증 애플리케이션은 전화 또는 기타 디바이스에서 실행되고 물리적 디바이스를 에뮬레이트합니다. 가상 인증 앱은 [시간 기반 일회용 암호](https://datatracker.ietf.org/doc/html/rfc6238)(TOTP) 알고리즘을 구현하고 단일 디바이스에서 여러 토큰을 지원합니다. 사용자는 로그인 중에 안내에 따라 디바이스의 유효 코드를 입력해야 합니다. 사용자에게 할당된 각 토큰은 고유해야 합니다. 사용자는 다른 사용자의 토큰의 코드를 입력하여 인증할 수 없습니다.

하드웨어 구매 승인을 기다리는 동안 또는 하드웨어 도착을 기다리는 동안 가상 MFA 디바이스를 사용하는 것이 좋습니다. 가상 MFA 디바이스로 사용할 수 있는 몇 가지 지원되는 앱의 목록은 [다중 인증(MFA)](https://aws.amazon.com/iam/features/mfa/?audit=2019q1) 섹션을 참조하세요. AWS를 사용하여 가상 MFA 디바이스를 설정하기 위한 지침은 [루트 사용자용 가상 MFA 디바이스 활성화(콘솔)](enable-virt-mfa-for-root.md) 섹션을 참조하세요.

## 하드웨어 TOTP 토큰
<a name="hardware-totp-token-for-root"></a>

하드웨어 디바이스가 [시간 기반 일회용 암호(TOTP) 알고리즘](https://datatracker.ietf.org/doc/html/rfc6238)에 따라 6자리 숫자 코드를 생성합니다. 사용자는 로그인할 때 두 번째 웹페이지에서 디바이스의 유효 코드를 입력해야 합니다. 사용자에게 할당된 각 MFA 디바이스는 고유해야 합니다. 사용자는 다른 사용자의 디바이스의 코드를 입력하여 인증받을 수 없습니다. 지원되는 하드웨어 MFA 디바이스에 대한 자세한 내용은 [다중 인증(MFA)](https://aws.amazon.com/iam/features/mfa/?audit=2019q1) 섹션을 참조하세요. AWS를 사용하여 하드웨어 TOTP 토큰을 설정하는 지침은 [루트 사용자에 대해 하드웨어 TOTP 토큰 활성화(콘솔)](enable-hw-mfa-for-root.md) 섹션을 참조하세요.

물리적 MFA 디바이스를 사용하려는 경우 하드웨어 TOTP 디바이스 대신 FIDO 보안 키를 사용하는 것이 좋습니다. FIDO 보안 키는 배터리 요구 사항이 없고 피싱 방지가 가능하다는 이점이 있으며, 단일 디바이스에서 여러 루트 및 IAM 사용자를 지원하여 보안을 강화합니다.

**Topics**
+ [

## 패스키 및 보안 키
](#passkeys-security-keys-for-root)
+ [

## 가상 인증 애플리케이션
](#virtual-auth-apps-for-root)
+ [

## 하드웨어 TOTP 토큰
](#hardware-totp-token-for-root)
+ [

# 루트 사용자용 패스키 또는 보안 키 활성화(콘솔)
](enable-fido-mfa-for-root.md)
+ [

# 루트 사용자용 가상 MFA 디바이스 활성화(콘솔)
](enable-virt-mfa-for-root.md)
+ [

# 루트 사용자에 대해 하드웨어 TOTP 토큰 활성화(콘솔)
](enable-hw-mfa-for-root.md)

# 루트 사용자용 패스키 또는 보안 키 활성화(콘솔)
<a name="enable-fido-mfa-for-root"></a>

루트 사용자 패스키 구성 및 활성화는 AWS Management Console에서만 가능하고 AWS CLI 또는 AWS API에서는 불가능합니다.<a name="enable_fido_root"></a>

**루트 사용자 패스키 또는 보안 키를 활성화하려면(콘솔)**

1. [AWS Management Console](https://console.aws.amazon.com/)을 열고 루트 사용자 자격 증명을 사용하여 로그인합니다.

   자세한 지침은 *AWS Sign-In 사용 설명서*의 [루트 사용자로 AWS Management Console에 로그인](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-root-user-sign-in-tutorial.html)을 참조하세요.

1. 탐색 표시줄 오른쪽에서 계정 이름을 선택하고 **Security credentials**(보안 자격 증명)를 선택합니다.  
![\[탐색 메뉴의 보안 자격 증명\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/security-credentials-root.shared.console.png)

1. 루트 사용자 **내 보안 자격 증명** 페이지의 **다중 인증(MFA)**에서 **MFA 디바이스 할당**을 선택합니다.

1. **MFA 디바이스 이름** 페이지에서 **디바이스 이름**을 입력하고 **패스키 또는 보안 키**를 선택한 후 **다음**을 선택합니다.

1. **디바이스 설정**에서 패스키를 설정합니다. 얼굴이나 지문 같은 생체 인식 데이터 또는 디바이스 PIN을 사용하거나 컴퓨터의 USB 포트에 FIDO 보안 키를 삽입한 다음 탭하여 패스키를 생성합니다.

1. 브라우저의 지침에 따라 패스키 공급자를 선택하거나 여러 디바이스에서 사용할 패스키를 저장할 위치를 선택합니다.

1. **계속**을 선택합니다.

이제 AWS에서 사용할 패스키를 등록했습니다. 다음에 루트 사용자 자격 증명을 사용하여 로그인할 때 패스키로 인증하여 로그인 절차를 완료해야 합니다.

FIDO 보안 키 문제를 해결하는 데 도움이 필요한 경우 [패스키 및 FIDO 보안 키 관련 문제 해결](troubleshoot_mfa-fido.md) 섹션을 참조하세요.

# 루트 사용자용 가상 MFA 디바이스 활성화(콘솔)
<a name="enable-virt-mfa-for-root"></a>

AWS Management Console을 사용하여 루트 사용자의 가상 MFA 디바이스를 구성 및 활성화할 수 있습니다. AWS 계정에 대해 MFA 디바이스를 활성화하려면 루트 사용자 보안 인증으로 AWS에 로그인해야 합니다.

**루트 사용자에 사용하기 위해 가상 MFA 디바이스를 구성 및 활성화하려면(콘솔)**

1. [AWS Management Console](https://console.aws.amazon.com/)을 열고 루트 사용자 자격 증명을 사용하여 로그인합니다.

   자세한 지침은 *AWS Sign-In 사용 설명서*의 [루트 사용자로 AWS Management Console에 로그인](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-root-user-sign-in-tutorial.html)을 참조하세요.

1. 탐색 표시줄 오른쪽에서 계정 이름을 선택하고 **Security credentials**(보안 자격 증명)를 선택합니다.  
![\[탐색 메뉴의 보안 자격 증명\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/security-credentials-root.shared.console.png)

1. **Multi-Factor Authentication (MFA)**(다중 인증(MFA)) 섹션에서 **Assign MFA device**(MFA 디바이스 할당)를 선택합니다.

1. 마법사에서 **디바이스 이름**을 입력하고 **인증 앱**을 선택한 후 **다음**을 선택합니다.

   IAM은 QR 코드 그래픽을 포함하여 가상 MFA 디바이스의 구성 정보를 생성 및 표시합니다. 그래픽은 QR 코드를 지원하지 않는 디바이스 상에서 수동 입력할 수 있는 보안 구성 키를 표시한 것입니다.

1. 디바이스에서 가상 MFA 앱을 엽니다.

   가상 MFA 앱이 다수의 가상 MFA 디바이스 또는 계정을 지원하는 경우 새로운 가상 MFA 디바이스 또는 계정을 생성하는 옵션을 선택합니다.

1. 앱을 구성하는 가장 쉬운 방법은 앱을 사용하여 QR 코드를 스캔하는 것입니다. 코드를 스캔하지 못하는 경우 구성 정보를 직접 입력할 수 있습니다. IAM에서 생성된 QR 코드와 보안 구성 키는 AWS 계정과 연동되기 때문에 다른 계정에서는 사용할 수 없습니다. 하지만 사용하던 MFA 디바이스에 대한 액세스 권한을 잃은 경우 재사용을 통해 계정에 대한 새로운 MFA 디바이스를 구성할 수 있습니다.
   + QR 코드를 사용하여 가상 MFA 디바이스를 구성하려면, 마법사에서 **Show QR code(QT 코드 표시)**를 선택합니다. 그리고 코드 스캔에 대한 앱 지침을 따릅니다. 예를 들어 카메라 모양의 아이콘을 선택하거나, **계정 바코드 스캔(Scan account barcode)**과 같은 명령을 선택한 다음, 디바이스의 카메라를 사용하여 QR 코드를 스캔할 수 있습니다.
   + **Set up device**(디바이스 설정) 마법사에서 **Show secret key**(보안 키 표시)를 선택한 다음 MFA 앱에 보안 키를 입력합니다.
**중요**  
QR 코드 또는 보안 구성 키를 안전하게 백업하거나, 혹은 계정의 여러 MFA 디바이스를 활성화하세요. [현재 지원되는 MFA 유형](https://aws.amazon.com/iam/features/mfa/)을 조합하여 최대 **8**개의 MFA 디바이스를 AWS 계정 루트 사용자 및 IAM 사용자에게 등록할 수 있습니다. 예를 들어 가상 MFA 디바이스가 호스팅되어 있는 스마트폰을 분실하는 경우 가상 MFA 디바이스를 사용할 수 없습니다. 이 경우 사용자에게 연결된 추가 MFA 디바이스가 없거나 [루트 사용자 MFA 디바이스 복구](id_credentials_mfa_lost-or-broken.md#root-mfa-lost-or-broken)로도 계정에 로그인할 수 없는 경우 계정에 로그인할 수 없으며 [고객 서비스에 문의](https://support.aws.amazon.com/#/contacts/aws-mfa-support)하여 계정에 대한 MFA 보호를 제거해야 합니다.

   그 디바이스는 6자리 번호를 생성합니다.

1. 마법사의 **MFA code 1**(MFA 코드 1) 상자에 현재 가상 MFA 디바이스에 표시된 일회용 암호를 입력합니다. 디바이스가 새로운 일회용 암호를 생성할 때까지 최대 30초 기다립니다. 그런 다음 두 번째 일회용 암호를 **MFA code 2(MFA 코드 2)** 상자에 입력합니다. **Add MFA**(MFA 추가)를 선택합니다.
**중요**  
코드를 생성한 후 즉시 요청을 제출하세요. 코드를 생성한 후 너무 오래 기다렸다 요청을 제출할 경우 MFA 디바이스가 사용자와 연결은 되지만 MFA 디바이스가 동기화되지 않습니다. 이는 시간 기반 일회용 암호(TOTP)가 잠시 후에 만료되기 때문입니다. 이 경우, [디바이스를 재동기화](id_credentials_mfa_sync.md)할 수 있습니다.

이제 AWS에서 디바이스를 사용할 준비가 끝났습니다. AWS Management Console의 MFA 사용 방법에 대한 자세한 내용은 [MFA 지원 로그인](console_sign-in-mfa.md) 섹션을 참조하세요.

# 루트 사용자에 대해 하드웨어 TOTP 토큰 활성화(콘솔)
<a name="enable-hw-mfa-for-root"></a>

AWS Management Console에서만 루트 사용자에 대한 물리적 MFA 디바이스를 구성하고 활성화할 수 있으며, AWS CLI 또는 AWS API에서는 활성화할 수 없습니다.

**참고**  
**MFA를 사용하여 로그인** 및 **인증 디바이스 문제 해결**과 같은 다른 텍스트가 나타날 수 있습니다. 그러나 동일한 기능이 제공됩니다. 어느 경우든 대체 인증 요소를 사용하여 계정 이메일 주소 및 전화번호를 확인할 수 없는 경우 [AWS Support](https://aws.amazon.com/forms/aws-mfa-support)에 문의하여 MFA 설정을 삭제합니다.<a name="enable_physical_root"></a>

**자신의 루트 사용자에 대해 하드웨어 TOTP 토큰을 활성화하려면(콘솔)**

1. [AWS Management Console](https://console.aws.amazon.com/)을 열고 루트 사용자 자격 증명을 사용하여 로그인합니다.

   자세한 지침은 *AWS Sign-In 사용 설명서*의 [루트 사용자로 AWS Management Console에 로그인](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-root-user-sign-in-tutorial.html)을 참조하세요.

1. 탐색 표시줄 오른쪽에서 계정 이름을 선택하고 **Security credentials**(보안 자격 증명)를 선택합니다.  
![\[탐색 메뉴의 보안 자격 증명\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/security-credentials-root.shared.console.png)

1. **Multi-factor authentication (MFA)(멀티 팩터 인증(MFA))** 섹션을 확장합니다.

1. **Assign MFA device**(MFA 디바이스 할당)를 선택합니다.

1. 마법사에서 **Device name**(디바이스 이름)을 입력하고 **Hardware TOTP token**(하드웨어 TOTP 토큰), **Next**(다음)를 차례로 선택합니다.

1. **Serial number(일련 번호)** 상자에 MFA 디바이스 뒷면에 있는 일련 번호를 입력합니다.

1. **MFA code 1(MFA 코드 1)** 상자에 MFA 디바이스에 표시된 6자리 번호를 입력합니다. 디바이스 전면의 버튼을 눌러야 번호가 표시되는 경우도 있습니다.  
![\[IAM 대시보드, MFA 디바이스\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/MFADevice.png)

1. 디바이스가 코드를 새로 고칠 때까지 30초 동안 기다린 다음 **MFA code 2(MFA 코드 2)** 상자에 다음 6자리 번호를 입력합니다. 다시 디바이스 전면의 버튼을 눌러야 두 번째 번호가 표시되는 경우도 있습니다.

1. **Add MFA**(MFA 추가)를 선택합니다. 이제 MFA 디바이스가 AWS 계정과 연결되었습니다.
**중요**  
인증 코드를 생성한 후 바로 요청을 제출하세요. 코드를 생성한 후 너무 오래 기다렸다 요청을 제출할 경우 MFA 디바이스가 사용자와 연결은 되지만 MFA 디바이스가 동기화되지 않습니다. 이는 시간 기반 일회용 암호(TOTP)가 잠시 후에 만료되기 때문입니다. 이 경우, [디바이스를 재동기화](id_credentials_mfa_sync.md)할 수 있습니다.

   다음에 루트 사용자 자격 증명을 사용하여 로그인할 때도 MFA 디바이스의 코드를 입력해야 합니다.

# AWS 계정 루트 사용자의 암호 변경
<a name="root-user-password"></a>

[보안 인증 정보](https://console.aws.amazon.com/iam/home?#security_credential) 또는 **계정** 페이지에서 이메일 주소 및 암호를 변경할 수 있습니다. 또한 AWS 로그인 페이지에서 **Forgot password?(암호 찾기)**를 선택하여 암호를 재설정할 수 있습니다.

루트 사용자 암호를 변경하려면 IAM 사용자가 아니라 AWS 계정 루트 사용자로 로그인해야 합니다. *잊어버린 루트 사용자 암호*를 재설정하는 방법에 대한 자세한 내용은 [잊거나 분실한 루트 사용자 암호 재설정](reset-root-password.md) 섹션을 참조하세요.

암호를 보호하려면 다음과 같은 모범 사례를 활용하는 것이 중요합니다.
+ 암호를 주기적으로 변경합니다.
+ 암호는 비공개로 유지합니다. 암호를 아는 사람이 해당 계정에 액세스할 수도 있기 때문입니다.
+ AWS의 암호를 다른 사이트에서 사용하는 것과 다르게 지정하세요.
+ 짐작하기 쉬운 암호를 사용하지 마세요. 여기에는 `secret`, `password`, `amazon` 또는 `123456` 같은 암호가 포함됩니다. 또한 사전에 나오는 단어, 사용자 이름, 이메일 주소 또는 알아내기 쉬운 그 밖의 개인 정보도 피합니다.

**중요**  
AWS Organizations를 사용하여 관리되는 AWS 계정에 멤버 계정에 대한 [중앙 집중식 루트 액세스](id_root-user.md#id_root-user-access-management)가 활성화되어 있을 수 있습니다. 이러한 멤버 계정은 루트 사용자 자격 증명이 없고, 루트 사용자로 로그인할 수 없으며, 루트 사용자 암호를 복구할 수 없습니다. 루트 사용자 자격 증명이 필요한 태스크를 수행해야 하는 경우 관리자에게 문의하세요.

------
#### [ AWS Management Console ]

**루트 사용자의 암호를 변경하려면**
**최소 권한**  
다음 단계를 수행하려면 적어도 다음과 같은 IAM 권한이 있어야 합니다.  
추가 AWS Identity and Access Management(IAM) 권한이 필요하지 않은 AWS 계정 루트 사용자로 로그인해야 합니다. IAM 사용자 또는 역할로는 이 단계를 수행할 수 없습니다.

1. [AWS Management Console](https://console.aws.amazon.com/)을 열고 루트 사용자 자격 증명을 사용하여 로그인합니다.

   자세한 지침은 *AWS Sign-In 사용 설명서*의 [루트 사용자로 AWS Management Console에 로그인](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-root-user-sign-in-tutorial.html)을 참조하세요.

1. 콘솔의 오른쪽 상단 모서리 부분에서 계정 이름이나 번호를 선택한 다음 **보안 자격 증명**을 선택합니다.

1. **계정** 페이지에서 **계정 설정** 옆의 **편집**을 선택합니다. 보안을 위해 재인증하라는 메시지가 표시됩니다.
**참고**  
**편집** 옵션이 나타나지 않으면 계정의 루트 사용자로 로그인하지 않은 것일 수 있습니다. IAM 사용자 또는 역할로 로그인한 상태에서는 계정 설정을 수정할 수 없습니다.

1. **계정 설정 업데이트** 페이지의 **암호**에서 **편집**을 선택합니다.

1. **암호 업데이트** 페이지에서 **현재 암호**, **새 암호**, **새 암호 확인** 필드를 입력합니다.
**중요**  
강력한 암호를 선택해야 합니다. IAM 사용자에 대한 계정 암호 정책을 설정할 수는 있지만 루트 사용자에게는 이 정책이 적용되지 않습니다.

   AWS는 암호가 다음 조건을 충족하도록 요구합니다.
   + 최소 8자, 최대 128자여야 합니다.
   + 대문자, 소문자, 숫자, 기호(\$1 @ \$1 \$1 % ^ & \$1 () <> [] \$1\$1 \$1 \$1\$1-=) 중 적어도 세 가지 문자 유형을 혼합하여 포함해야 합니다.
   + AWS 계정 이름 또는 이메일 주소와 동일하지 않아야 합니다.

1. **변경 사항 저장**을 선택합니다.

------
#### [ AWS CLI or AWS SDK ]

이 작업은 AWS SDK 중 하나의 API 작업에서 또는 AWS CLI에서 지원되지 않습니다. 이 작업은 AWS Management Console을 사용해야만 수행할 수 있습니다.

------

# 잊거나 분실한 루트 사용자 암호 재설정
<a name="reset-root-password"></a>

AWS 계정을 처음 생성할 때 이메일 주소와 암호를 입력했습니다. 그 주소와 암호가 바로 AWS 계정 루트 사용자 자격 증명입니다. 루트 사용자 암호를 잊어버린 경우, AWS Management Console에서 암호를 재설정할 수 있습니다.

AWS Organizations를 사용하여 관리되는 AWS 계정에 멤버 계정에 대한 [중앙 집중식 루트 액세스](id_root-user.md#id_root-user-access-management)가 활성화되어 있을 수 있습니다. 이러한 멤버 계정은 루트 사용자 자격 증명이 없고, 루트 사용자로 로그인할 수 없으며, 루트 사용자 암호를 복구할 수 없습니다. 루트 사용자 자격 증명이 필요한 태스크를 수행해야 하는 경우 관리자에게 문의하세요.

**중요**  
**AWS에 로그인하는 데 문제가 있나요?** 사용자 유형에 맞는 올바른 [AWS 로그인 페이지](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-tutorials.html)에 있는지 확인합니다. AWS 계정 루트 사용자(계정 소유자)인 경우 AWS 계정을 생성할 때 설정한 보안 인증을 사용하여 AWS에 로그인할 수 있습니다. IAM 사용자인 경우 계정 관리자가 AWS에 로그인하는 데 사용할 수 있는 자격 증명을 제공할 수 있습니다. 지원을 요청해야 하는 경우 이 페이지의 피드백 링크를 사용하지 마세요. 이 양식은 지원가 아닌 AWS 설명서 팀에서 접수합니다. 대신 [Contact Us](https://aws.amazon.com/contact-us/)(문의처) 페이지에서 **Still unable to log into your AWS account**(여전히 계정에 로그인할 수 없음)을 선택한 다음 사용 가능한 지원 옵션 중 하나를 선택합니다.

**루트 사용자 암호 재설정하기**

1. [AWS Management Console](https://console.aws.amazon.com/)을 열고 루트 사용자 자격 증명을 사용하여 로그인합니다.

   자세한 지침은 *AWS Sign-In 사용 설명서*의 [루트 사용자로 AWS Management Console에 로그인](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-root-user-sign-in-tutorial.html)을 참조하세요.
**참고**  
 [AWS Management Console](https://console.aws.amazon.com/)에 *IAM 사용자* 자격 증명을 사용하여 로그인한 경우 로그아웃해야 루트 사용자 암호를 재설정할 수 있습니다. 해당 계정의 IAM 사용자 로그인 페이지가 표시되면, 페이지 하단에 있는 **루트 계정 자격 증명을 사용한 로그인(Sign-in using root account credentials)**을 선택합니다. 필요한 경우 계정 이메일 주소를 입력하고 **다음**을 선택하여 **Root user sign in(루트 사용자 로그인)** 페이지에 액세스합니다.

1. **비밀번호가 생각나지 않는 경우**를 선택합니다.
**참고**  
IAM 사용자인 경우 이 옵션을 사용할 수 없습니다. **비밀번호가 생각나지 않는 경우** 옵션은 루트 사용자 계정에만 제공됩니다. IAM 사용자는 관리자에게 잊어버린 암호를 재설정해달라고 요청해야 합니다. 자세한 내용은 [I forgot my IAM user password for my AWS account](https://docs.aws.amazon.com/signin/latest/userguide/troubleshooting-sign-in-issues.html#troubleshoot-forgot-iam-password)를 참조하세요. AWS 액세스 포털을 통해 로그인하는 경우 [Resetting your IAM Identity Center user password](https://docs.aws.amazon.com/singlesignon/latest/userguide/resetpassword-accessportal.html)를 참조하세요.

1. 계정과 연결된 이메일 주소를 입력합니다. 그런 다음 CAPTCHA 텍스트를 입력하고 **계속**을 선택합니다.

1. AWS 계정과 연결된 이메일에 Amazon Web Services에서 보낸 메시지가 있는지 확인합니다. `@verify.signin.aws`로 끝나는 주소에서 보낸 이메일입니다. 이메일 지침을 따릅니다. 계정으로 이메일이 오지 않았으면 스팸 폴더를 점검합니다. 이메일에 더 이상 액세스할 수 없는 경우 *AWS Sign-In 사용 설명서*의 [AWS 계정 이메일에 액세스할 수 없음](https://docs.aws.amazon.com/signin/latest/userguide/console-sign-in-troubleshooting.html#credentials-not-working-console)을 참조하세요.

# 루트 사용자용 액세스 키 생성
<a name="id_root-user_manage_add-key"></a>

**주의**  
루트 사용자에 대한 액세스 키 페어는 생성하지 **않는** 것이 좋습니다. [일부 작업에만 루트 사용자가 필요하고](id_root-user.md#root-user-tasks) 이러한 작업은 대개 자주 수행하지 않으므로 AWS Management Console에 로그인하여 루트 사용자 작업을 수행하는 것이 좋습니다. 액세스 키를 생성하기 전에 [장기 액세스 키의 대안](security-creds-programmatic-access.md#security-creds-alternatives-to-long-term-access-keys)을 검토합니다.

권장하지는 않지만 루트 사용자에 대한 액세스 키를 생성할 수는 있습니다. AWS Command Line Interface(AWS CLI)에서 명령을 실행하거나 루트 사용자 보안 인증을 사용하여 AWS SDK 중 하나에서 API 작업을 사용하면 됩니다. 액세스 키를 만들 때 액세스 키 ID와 보안 액세스 키를 한 세트로 생성합니다. 액세스 키 생성 중에 AWS는 액세스 키의 보안 액세스 키 부분을 확인하고 다운로드할 기회를 한 번 부여합니다. 보안 액세스 키를 다운로드하지 않았거나 분실한 경우 액세스 키를 삭제한 다음 새로 생성할 수 있습니다. 콘솔, AWS CLI 또는 AWS API를 사용해 루트 사용자 액세스 키를 생성할 수 있습니다.

새로 생성한 액세스 키는 *활성* 상태입니다. 즉, CLI 및 API 호출에 대해 액세스 키를 사용할 수 있습니다. 루트 사용자에게 최대 두 개의 액세스 키를 할당할 수 있습니다.

사용하지 않는 액세스 키는 비활성화해야 합니다. 액세스 키가 비활성화되면 API 호출에 사용할 수 없습니다. 비활성 키는 여전히 제한에 포함됩니다. 언제든지 액세스 키를 생성하거나 삭제할 수 있습니다. 그러나 액세스 키를 삭제하면 영구 삭제되어 되돌릴 수 없습니다.

------
#### [ AWS Management Console ]

**AWS 계정 루트 사용자에 대한 액세스 키를 생성하려면**
**최소 권한**  
다음 단계를 수행하려면 적어도 다음과 같은 IAM 권한이 있어야 합니다.  
추가 AWS Identity and Access Management(IAM) 권한이 필요하지 않은 AWS 계정 루트 사용자로 로그인해야 합니다. IAM 사용자 또는 역할로는 이 단계를 수행할 수 없습니다.

1. [AWS Management Console](https://console.aws.amazon.com/)을 열고 루트 사용자 자격 증명을 사용하여 로그인합니다.

   자세한 지침은 *AWS Sign-In 사용 설명서*의 [루트 사용자로 AWS Management Console에 로그인](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-root-user-sign-in-tutorial.html)을 참조하세요.

1. 콘솔의 오른쪽 상단 모서리 부분에서 계정 이름이나 번호를 선택한 후 **보안 인증**을 선택합니다.

1. **액세스 키** 섹션에서 **액세스 키 생성**을 선택합니다. 이 옵션을 사용할 수 없는 경우 이미 최대 개수의 액세스 키가 있는 것입니다. 새 키를 생성하려면 먼저 기존 액세스 키 중 하나를 삭제해야 합니다. 자세한 내용은 [IAM 객체 할당량](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html#reference_iam-quotas-entities)을 참조하세요.

1. **루트 사용자 액세스 키의 대안** 페이지에서 보안 권장 사항을 검토합니다. 계속하려면 확인란을 선택하고 **액세스 키 생성**을 선택하세요.

1. **액세스 키 검색** 페이지에 **액세스 키** ID가 표시됩니다.

1. **비밀 액세스 키**에서 **표시**를 선택하고 브라우저 창에서 액세스 키 ID 및 비밀 키를 복사해 다른 안전한 곳에 붙여넣습니다. 또는 **.csv 파일 다운로드**를 선택하면 액세스 키 ID와 비밀 키가 포함된 `rootkey.csv` 파일을 다운로드할 수 있습니다. 파일을 안전한 곳에 저장합니다.

1. **완료**를 선택합니다. 액세스 키가 더 이상 필요하지 않으면 [삭제하는 것이 좋습니다.](id_root-user_manage_delete-key.md) 아니면 다른 사람이 악용하지 못하도록 최소한 비활성화하는 것이 좋습니다.

------
#### [ AWS CLI & SDKs ]

**루트 사용자에 대한 액세스 키를 생성하려면**
**참고**  
루트 사용자로 다음 명령 또는 API 작업을 실행하려면 활성 액세스 키 페어가 이미 하나 있어야 합니다. 액세스 키가 없는 경우 AWS Management Console을 사용하여 첫 번째 액세스 키를 생성합니다. 그런 다음, AWS CLI에서 첫 번째 액세스 키의 보안 인증을 사용하여 두 번째 액세스 키를 생성하거나 액세스 키를 삭제할 수 있습니다.
+ AWS CLI: [aws iam create-access-key](https://docs.aws.amazon.com/cli/latest/reference/iam/create-access-key.html)  
**Example**  

  ```
  $ aws iam create-access-key
  {
      "AccessKey": {
          "UserName": "MyUserName",
          "AccessKeyId": "AKIAIOSFODNN7EXAMPLE",
          "Status": "Active",
          "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
          "CreateDate": "2021-04-08T19:30:16+00:00"
      }
  }
  ```
+ AWS API: *IAM API 참조*의 [CreateAccessKey](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html).

------

# 루트 사용자용 액세스 키 삭제
<a name="id_root-user_manage_delete-key"></a>

AWS Management Console, AWS CLI 또는 AWS API를 사용하여 루트 사용자 액세스 키를 삭제할 수 있습니다.

------
#### [ AWS Management Console ]

**루트 사용자에 대한 액세스 키를 삭제하려면**
**최소 권한**  
다음 단계를 수행하려면 적어도 다음과 같은 IAM 권한이 있어야 합니다.  
추가 AWS Identity and Access Management(IAM) 권한이 필요하지 않은 AWS 계정 루트 사용자로 로그인해야 합니다. IAM 사용자 또는 역할로는 이 단계를 수행할 수 없습니다.

1. [AWS Management Console](https://console.aws.amazon.com/)을 열고 루트 사용자 자격 증명을 사용하여 로그인합니다.

   자세한 지침은 *AWS Sign-In 사용 설명서*의 [루트 사용자로 AWS Management Console에 로그인](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-root-user-sign-in-tutorial.html)을 참조하세요.

1. 콘솔의 오른쪽 상단 모서리 부분에서 계정 이름이나 번호를 선택한 후 **보안 인증**을 선택합니다.

1. **액세스 키** 섹션에서 삭제하려는 액세스 키를 선택하고 **작업**에서 **삭제**를 선택합니다.
**참고**  
또는 액세스 키를 영구적으로 삭제하는 대신 **비활성화**할 수도 있습니다. 이렇게 하면 키 ID나 비밀 키를 변경하지 않고도 나중에 액세스 키를 다시 사용할 수 있습니다. 키가 비활성 상태인 동안 AWS API에 대한 요청에 이 키를 사용하려고 하면 액세스 거부됨 오류로 인해 실패합니다.

1. **<access key ID> 삭제** 대화 상자에서 **비활성화**를 선택하고 삭제할 액세스 키 ID를 입력한 다음, **삭제**를 선택합니다.

------
#### [ AWS CLI & SDKs ]

**루트 사용자에 대한 액세스 키를 삭제하려면**
**최소 권한**  
다음 단계를 수행하려면 적어도 다음과 같은 IAM 권한이 있어야 합니다.  
추가 AWS Identity and Access Management(IAM) 권한이 필요하지 않은 AWS 계정 루트 사용자로 로그인해야 합니다. IAM 사용자 또는 역할로는 이 단계를 수행할 수 없습니다.
+ AWS CLI: [aws iam delete-access-key](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-access-key.html)  
**Example**  

  ```
  $ aws iam delete-access-key \
      --access-key-id AKIAIOSFODNN7EXAMPLE
  ```

  이 명령은 성공 시 출력을 생성하지 않습니다.
+ AWS API: [DeleteAccessKey](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccessKey.html) 

------

## 루트 사용자 보안 인증이 필요한 작업
<a name="root-user-tasks"></a>

일상 작업을 수행하고 AWS 리소스에 액세스하도록 [AWS IAM Identity Center에서 관리 사용자를 구성](https://docs.aws.amazon.com/singlesignon/latest/userguide/getting-started.html)하는 것이 좋습니다. 하지만 아래 나열된 작업은 계정의 루트 사용자로 로그인한 경우에만 수행할 수 있습니다.

AWS Organizations의 멤버 계정에서 권한 있는 루트 사용자 자격 증명을 간편하게 관리하기 위해 중앙 집중식 루트 액세스를 활성화하여 AWS 계정에 대한 높은 권한의 액세스를 중앙에서 보호할 수 있습니다. [중앙에서 멤버 계정에 대한 루트 액세스 관리](#id_root-user-access-management)를 통해 장기 루트 사용자 자격 증명 복구를 중앙에서 제거하고 방지하여 조직의 계정 보안을 강화할 수 있습니다. 이 기능을 활성화한 후 멤버 계정에서 다음과 같은 권한 있는 태스크를 수행할 수 있습니다.
+ 멤버 계정 루트 사용자 자격 증명을 제거하여 루트 사용자의 계정 복구를 방지합니다. 암호 복구를 허용하여 멤버 계정에 대한 루트 사용자 자격 증명을 복구할 수도 있습니다.
+ 모든 위탁자의 Amazon S3 버킷 액세스를 거부하는 잘못 구성된 버킷 정책을 제거합니다.
+ 모든 위탁자가 Amazon SQS 대기열에 액세스하는 것을 거부하는 Amazon Simple Queue Service 리소스 기반 정책을 삭제합니다.

**계정 관리 작업**
+ [AWS 계정 설정을 변경합니다.](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-root-user.html) AWS Organizations의 일부가 아닌 독립 실행형 AWS 계정는 이메일 주소, 루트 사용자 암호, 루트 사용자 액세스 키를 업데이트하는 데 루트 자격 증명이 필요합니다. 계정 이름, 연락처 정보, 대체 연락처, 결제 통화 기본 설정, AWS 리전 등의 기타 계정 설정에는 루트 사용자 자격 증명이 필요하지 않습니다.
**참고**  
AWS Organizations는 모든 기능이 활성화된 상태에서 관리 계정 및 위임된 관리자 계정으로 멤버 계정 설정을 중앙에서 관리하는 데 사용할 수 있습니다. 관리 계정과 위임된 관리자 계정 모두에서 승인된 IAM 사용자 또는 IAM 역할은 멤버 계정을 닫고 멤버 계정의 루트 이메일 주소, 계정 이름, 연락처 정보, 대체 연락처, AWS 리전를 업데이트할 수 있습니다.
+ [AWS 계정를 닫습니다.](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/close-account.html) AWS Organizations의 일부가 아닌 독립 실행형 AWS 계정는 계정을 해지하기 위해 루트 자격 증명이 필요합니다. AWS Organizations를 사용하면 관리 계정 및 위임된 관리자 계정으로 멤버 계정을 중앙에서 해지할수 있습니다.
+ [IAM 사용자 권한을 복원합니다.](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-edit.html) IAM 관리자가 실수로 권한을 취소하면 루트 사용자로 로그인하여 정책을 편집하고 해당 권한을 복원할 수 있습니다.

**결제 작업**
+ [과금 정보 및 비용 관리 콘솔에 대한 IAM 액세스를 활성화합니다](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/control-access-billing.html#ControllingAccessWebsite-Activate).
+ 일부 결제 작업은 루트 사용자만 수행할 수 있습니다. 자세한 내용은 AWS Billing 사용 설명서에서 [AWS 계정 관리](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/manage-account-payment.html)를 참조하세요.
+ 특정 세금 계산서를 조회합니다. [aws-portal:ViewBilling](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/billing-permissions-ref.html#user-permissions) 권한이 있는 IAM 사용자는 AWS 유럽(AWS Inc. 또는 Amazon Internet Services Private Limited(AISPL) 제외)에서 VAT 인보이스를 보고 다운로드할 수 있습니다.

**AWS GovCloud (US) 작업**
+ [AWS GovCloud (US)에 대한 가입.](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/getting-started-sign-up.html)
+ AWS Support에서 AWS GovCloud (US) 계정 루트 사용자 액세스 키를 요청합니다.

**Amazon EC2 작업**
+ 예약 인스턴스 마켓플레이스에 [판매자로 등록](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ri-market-general.html)합니다.

**AWS KMS 작업**
+ AWS Key Management Service 키를 관리할 수 없게 된 경우 관리자는 지원에 연락하여 키를 복구할 수 있습니다. 그러나 지원는 티켓 OTP 확인을 통한 권한 부여를 위해 루트 사용자의 기본 전화번호로 응답합니다.

**Amazon Mechanical Turk Task**
+  [귀하의 AWS 계정을 MTurk 요청자 계정에 연결합니다](https://docs.aws.amazon.com/AWSMechTurk/latest/AWSMechanicalTurkGettingStartedGuide/SetUp.html#accountlinking).

**Amazon Simple Storage Service Tasks**
+ [멀티 팩터 인증(MFA)을 활성화하도록 Amazon S3 버킷을 구성합니다](https://docs.aws.amazon.com/AmazonS3/latest/userguide/MultiFactorAuthenticationDelete.html).
+ [모든 보안 주체를 거부하는 Amazon S3 버킷 정책을 편집하거나 삭제합니다](https://aws.amazon.com/premiumsupport/knowledge-center/change-vpc-endpoint-s3-bucket-policy/).

  권한 있는 작업을 사용하여 버킷 정책이 잘못 구성된 Amazon S3 버킷을 열 수 있습니다. 자세한 내용은 [AWS Organizations 멤버 계정에서 권한 있는 태스크 수행](id_root-user-privileged-task.md)을 참조하세요.

**Amazon Simple Queue Service Task**
+ [모든 위탁자를 거부하는 Amazon SQS 리소스 기반 정책을 편집하거나 삭제합니다](https://aws.amazon.com/premiumsupport/knowledge-center/sqs-queue-access-issues-deny-policy).

  권한 있는 작업을 사용하여 리소스 기반 정책이 잘못 구성된 Amazon SQS 대기열을 열 수 있습니다. 자세한 내용은 [AWS Organizations 멤버 계정에서 권한 있는 태스크 수행](id_root-user-privileged-task.md)을 참조하세요.

## 추가 리소스
<a name="id_root-user-resources"></a>

AWS 루트 사용자에 대한 자세한 내용은 다음 리소스를 참조하세요.
+ 루트 사용자 문제에 대한 도움말은 [루트 사용자 관련 문제 해결](troubleshooting_root-user.md)의 내용을 참조하세요.
+ AWS Organizations에서 루트 사용자 이메일 주소를 중앙에서 관리하려면 *AWS Organizations 사용 설명서*의 [멤버 계정의 루트 사용자 이메일 주소 업데이트](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_update_primary_email.html)를 참조하세요.

다음 문서에서는 루트 사용자 작업에 대한 추가 정보를 제공합니다.
+ [내 AWS 계정 및 해당 리소스를 보호하기 위한 모범 사례로 무엇이 있나요?](https://repost.aws/knowledge-center/security-best-practices)
+ [내 루트 사용자가 사용되었음을 알리는 EventBridge 이벤트 규칙을 생성하려면 어떻게 해야 하나요?](https://repost.aws/knowledge-center/root-user-account-eventbridge-rule)
+ [AWS 계정 루트 사용자 활동 모니터링 및 알림](https://aws.amazon.com/blogs/mt/monitor-and-notify-on-aws-account-root-user-activity/) 
+ [IAM 루트 사용자 활동 모니터링](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/monitor-iam-root-user-activity.html) 

# IAM 사용자
<a name="id_users"></a>

**중요**  
 IAM [모범 사례](best-practices.md)는 장기 보안 인증 정보가 있는 IAM 사용자를 사용하는 대신, 인간 사용자가 자격 증명 공급자와의 페더레이션을 사용하여 임시 보안 인증으로 AWS에 액세스하도록 하는 것입니다. 페더레이션 사용자가 지원하지 않는 [특정 사용 사례](gs-identities-iam-users.md)에는 IAM 사용자만 사용하는 것이 좋습니다.

*IAM 사용자*는 AWS 계정에서 생성하는 엔터티입니다. IAM 사용자는 AWS 리소스와 상호 작용하기 위해 IAM 사용자를 사용하는 인간 사용자 또는 워크로드를 나타냅니다. IAM 사용자는 이름 및 자격 증명으로 구성됩니다.

관리자 권한이 있는 IAM 사용자는 AWS 계정 루트 사용자과 같지 않습니다. 루트 사용자에 대한 자세한 내용은 [AWS 계정 루트 사용자](id_root-user.md) 섹션을 참조하세요.

## AWS가 IAM 사용자를 식별하는 방법
<a name="id_users_create_aws-identifiers"></a>

사용자를 생성하면 IAM은 해당 사용자를 식별하는 다음과 같은 방법을 생성합니다.
+ IAM 사용자 생성 시 지정한 이름으로서 `Richard` 또는 `Anaya`와 같은 IAM 사용자가 "쉽게 알 수 있는 이름"입니다. 이 이름들은 AWS Management Console에서 볼 수 있습니다. IAM 사용자 이름은 Amazon 리소스 이름(ARN)에 표시되므로 IAM 이름에 개인 식별 정보를 포함하지 않는 것이 좋습니다. IAM 이름에 대한 요구 사항 및 제한 사항은 [IAM 이름 요구 사항](reference_iam-quotas.md#reference_iam-quotas-names) 섹션을 참조하세요.
+ IAM 사용자의 Amazon 리소스 이름(ARN)입니다. 모든 AWS 전반에 IAM 사용자를 특별하게 식별할 필요가 있는 경우 ARN을 사용합니다. 예를 들어, ARN을 사용하여 IAM 사용자를 Amazon S3 버킷의 IAM 정책에서 `Principal`로 지정할 수 있습니다. IAM 사용자의 ARN은 다음과 같을 수 있습니다.

  `arn:aws:iam::account-ID-without-hyphens:user/Richard`
+ IAM 사용자의 고유 식별자입니다. 이 ID는 IAM 사용자를 생성하기 위해 API, Tools for Windows PowerShell 또는 AWS CLI를 사용할 때만 반환됩니다. 콘솔에서는 이 ID를 볼 수 없습니다.

이 식별자에 대한 자세한 정보는 [IAM 식별자](reference_identifiers.md) 섹션을 참조하세요.

## IAM 사용자 및 보안 인증
<a name="id_users_creds"></a>

AWS는 IAM 사용자 보안 인증에 따라 다양한 방법으로 액세스할 수 있습니다.
+ [**콘솔 암호**](id_credentials_passwords.md): IAM 사용자가 입력해 AWS Management Console과 같은 상호 작용 세션으로 로그인할 수 있는 암호. IAM 사용자의 암호(콘솔 액세스)를 비활성화하면 사용자가 해당 로그인 보안 인증을 사용하여 AWS Management Console에 로그인하지 못합니다. 그렇더라도 사용자의 권한이 변경되거나 위임된 역할을 사용하여 콘솔에 액세스하지 못하게 되지는 않습니다. 콘솔 액세스가 활성화된 IAM 사용자는 이러한 동일한 자격 증명을 사용하여 `aws login` AWS CLI 명령으로 AWS CLI 및 SDK 액세스를 인증할 수도 있습니다. 이러한 사용자는 [SignInLocalDevelopmentAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/SignInLocalDevelopmentAccess.html) 권한이 있어야 합니다. 자세한 내용은 *AWS Command Line Interface 사용 설명서*의 [AWS CLI 인증 및 액세스 제어](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-authentication.html)를 참조하세요.
+ [**액세스 키**](id_credentials_access-keys.md): 프로그래밍 방식으로 AWS를 호출하는 데 사용됩니다. 그러나 IAM 사용자를 위한 액세스 키를 생성하기 전에 고려해야 할 더 안전한 대안이 있습니다. 자세한 내용은 **AWS 일반 참조의 [장기 액세스 키에 대한 고려 사항 및 대안](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#alternatives-to-long-term-access-keys)을 참조하세요. IAM 사용자에게 활성 액세스 키가 있다면 해당 키는 계속 작동하고 AWS CLI, Tools for Windows PowerShell 또는 AWS API 또는 AWS Console Mobile Application을 통해 액세스를 허용합니다.
+ [**CodeCommit에 사용할 SSH 키**](id_credentials_ssh-keys.md): CodeCommit를 사용한 인증에 사용할 수 있는 OpenSSH 형식의 SSH 퍼블릭 키
+ [**서버 인증서**](id_credentials_server-certs.md): 일부 AWS 서비스를 사용한 인증에 사용할 수 있는 SSL/TLS 인증서. 서버 인증서를 프로비저닝, 관리 및 배포할 때 AWS Certificate Manager(ACM)를 사용하는 것이 좋습니다. ACM에서 지원하지 않는 리전에서 HTTPS 연결을 지원해야 하는 경우에만 IAM을 사용합니다. ACM을 지원하는 리전을 알아보려면 **AWS 일반 참조의 [AWS Certificate Manager 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/acm.html)을 참조하세요.

IAM 사용자에게 적절한 자격 증명을 선택할 수 있습니다. AWS Management Console을 사용하여 IAM 사용자를 생성할 때 최소한 콘솔 암호 또는 액세스 키를 포함하도록 선택해야 합니다. 기본적으로 AWS CLI 또는 AWS API를 사용하여 새로 생성된 IAM 사용자는 어떤 종류의 자격 증명도 보유하지 않습니다. 사용자의 사용 사례를 기반으로 IAM 사용자의 보안 인증 유형을 생성해야 합니다.

다음 옵션을 이용해 암호, 액세스 키 및 다중 인증(MFA) 디바이스를 관리합니다.
+ **[IAM 사용자 암호 관리.](id_credentials_passwords.md)** AWS Management Console에 대한 액세스를 허용하는 암호를 생성 및 변경합니다. 암호 정책을 최소 암호 복잡성을 적용하도록 설정 IAM 사용자에게 자신의 암호를 변경할 수 있도록 허용합니다.
+ **[IAM 사용자의 액세스 키 관리.](id_credentials_access-keys.md)** 계정의 리소스에 대한 프로그래밍 방식의 액세스를 위해 액세스 키를 생성하고 업데이트합니다.
+ **[IAM 사용자에 대해 다중 인증(MFA)을 활성화합니다](id_credentials_mfa.md).** [가장 좋은 방법](best-practices.md)은 계정에 속한 모든 IAM 사용자에게 다중 인증(MFA)을 요구하는 것입니다. MFA를 사용할 경우 IAM 사용자는 두 가지 형식의 식별이 가능합니다. 먼저, 사용자는 사용자 ID의 일부분인 자격 증명(암호 또는 액세스 키)을 제공합니다. 또한 하드웨어 디바이스 또는 스마트폰이나 태블릿의 애플리케이션에서 생성된 임시 숫자 코드를 제공합니다.
+ **[미사용 암호 및 액세스 키 찾기](id_credentials_finding-unused.md).** 계정 또는 계정 내 IAM 사용자의 암호 또는 액세스 키를 보유하는 사람은 누구든지 AWS 리소스에 액세스할 수 있습니다. 보안 [모범 사례](https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html)는 IAM 사용자에게 암호 및 액세스 키가 필요하지 않을 때 해당 항목을 제거하는 것입니다.
+ **[계정의 자격 증명 보고서 다운로드](id_credentials_getting-report.md).** 계정의 모든 IAM 사용자와 해당 사용자의 암호, 액세스 키, MFA 디바이스 등 다양한 자격 증명의 상태를 나열하는 자격 증명 보고서를 생성하고 다운로드할 수 있습니다. 암호와 액세스 키의 경우 자격 증명 보고서를 통해 암호 또는 액세스 키가 언제 마지막으로 사용되었는지 알 수 있습니다.

## IAM 사용자 및 권한
<a name="id_users_perms"></a>

기본적으로 새로운 IAM 사용자는 작업을 수행할 어떠한 [권한](access.md)도 없습니다. 사용자는 AWS 작업을 수행하거나 AWS 리소스에 액세스할 수 있는 권한이 없습니다. 개별 IAM 사용자를 두면 각 사용자에게 개별적으로 권한을 할당할 수 있다는 장점이 있습니다. 사용자 몇 명에게 관리 권한을 할당하면 이들이 AWS 리소스를 관리하고 다른 IAM 사용자까지 생성하고 관리할 수 있습니다. 그러나 대부분의 경우 사용자의 업무에 필요한 작업(AWS 작업) 및 리소스로만 사용자의 권한을 제한합니다.

Diego라는 사용자가 있다고 가정해 보겠습니다. IAM 사용자 `Diego`를 생성할 때 해당 사용자에 대한 암호를 생성하고 권한을 연결하여 특정 Amazon EC2 인스턴스를 시작하고 Amazon RDS 데이터베이스의 테이블에서 (`GET`) 정보를 읽을 수 있도록 할 수 있습니다. IAM 사용자를 생성하여 초기 자격 증명과 권한을 부여하는 절차는 [AWS 계정에서 IAM 사용자 생성](id_users_create.md) 섹션을 참조하세요. 기존 사용자에 대한 권한을 변경하는 절차는 [IAM 사용자의 권한 변경](id_users_change-permissions.md) 섹션을 참조하세요. 사용자의 암호나 액세스 키를 변경하는 절차는 [AWS의 사용자 암호](id_credentials_passwords.md) 및 [IAM 사용자의 액세스 키 관리](id_credentials_access-keys.md) 섹션을 참조하세요.

IAM 사용자에게 권한 경계를 추가할 수 있습니다. 권한 경계는 AWS 관리형 정책을 사용하여 자격 증명 기반 정책이 IAM 사용자 또는 역할에 부여할 수 있는 최대 권한을 제한할 수 있는 고급 기능입니다. 정책 유형 및 활용에 대한 자세한 정보는 [AWS Identity and Access Management의 정책 및 권한](access_policies.md) 섹션을 참조하세요.

## IAM 사용자 및 계정
<a name="id_users_accounts"></a>

각 IAM 사용자는 오직 한 개의 AWS 계정과만 연결됩니다. IAM 사용자는 AWS 계정 내에서 정의되기 때문에 AWS에서 파일에 결제 방법을 저장해 두지 않아도 됩니다. 계정에 속한 IAM 사용자가 수행하는 모든 AWS 활동은 해당 계정으로 청구됩니다.

AWS 계정의 IAM 리소스 수와 크기는 제한되어 있습니다. 자세한 내용은 [IAM 및 AWS STS 할당량](reference_iam-quotas.md) 섹션을 참조하세요.

## 서비스 계정인 IAM 사용자
<a name="id_users_service_accounts"></a>

IAM 사용자는 연결된 자격 증명 및 권한을 지닌 IAM의 리소스입니다. IAM 사용자는 자격 증명을 사용하여 AWS에 요청하는 사용자 또는 애플리케이션을 나타낼 수 있습니다. 이를 일반적으로 *서비스 계정*이라 합니다. 애플리케이션에서 IAM 사용자의 장기 자격 증명을 사용하기로 선택한 경우 **액세스 키를 애플리케이션 코드에 직접 포함하지 마세요.** AWS SDK 및 AWS Command Line Interface를 사용하면 코드에서 유지할 필요가 없도록 알려진 위치에 액세스 키를 추가할 수 있습니다. 자세한 내용은 **AWS 일반 참조의 [적절하게 IAM 사용자 액세스 키 관리](https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html#iam-user-access-keys)를 참조하세요. 또는 모범 사례로서 [장기 액세스 키 대신 임시 보안 자격 증명(IAM 역할)을 사용](https://docs.aws.amazon.com/general/latest/gr/aws-access-keys-best-practices.html#use-roles)할 수 있습니다.

# IAM 사용자가 AWS에 로그인하는 방법
<a name="id_users_sign-in"></a>

IAM 사용자로 AWS Management Console에 로그인하려면 사용자 이름과 암호 이외에 계정 ID 또는 계정 별칭을 제공해야 합니다. 관리자가 콘솔에서 IAM 사용자를 생성한 경우, 계정 ID 또는 계정 별칭이 포함된 계정 로그인 페이지의 URL, 사용자 이름 등을 비롯한 로그인 자격 증명을 전송했을 것입니다.

```
https://My_AWS_Account_ID.signin.aws.amazon.com/console/
```

**도움말**  
웹 브라우저에서 계정 로그인 페이지를 위한 북마크를 만들려면 북마크 입력란에 계정의 로그인 URL을 직접 입력해야 합니다. 리디렉션은 로그인 URL을 가릴 수 있으므로 웹 브라우저 북마크 기능을 사용하지 마세요.

다음의 일반 로그인 엔드포인트에서 로그인하고 계정 ID 또는 계정 별칭을 직접 입력할 수도 있습니다.

```
[https://console.aws.amazon.com/](https://console.aws.amazon.com/)
```

사용자 편의를 위해 AWS 로그인 페이지는 브라우저 쿠키를 사용하여 IAM 사용자 이름 및 계정 정보를 기억합니다. 다음에 사용자가 AWS Management Console의 아무 페이지로든 이동하면 콘솔이 쿠키를 사용하여 사용자를 사용자 로그인 페이지로 리디렉션합니다.

IAM 사용자 자격 증명에 연결된 정책에서 관리자가 지정하는 AWS 리소스에만 액세스할 수 있습니다. 콘솔에서 작업하려면 AWS 리소스 나열 및 생성 등 콘솔이 수행하는 작업을 수행할 권한이 있어야 합니다. 자세한 내용은 [AWS리소스에 대한 액세스 관리](access.md) 및 [IAM 자격 증명 기반 정책의 예](access_policies_examples.md) 섹션을 참조하세요.

**참고**  
조직에 기존의 자격 증명 시스템이 있는 경우, Single Sign-On(SSO) 옵션을 만드는 것이 좋습니다. SSO는 IAM 사용자 자격 증명이 없어도 계정의 AWS Management Console에 액세스할 수 있는 권한을 사용자에게 제공합니다. 또한 SSO를 사용하면 사용자가 조직의 사이트와 AWS에 따로 로그인하지 않아도 됩니다. 자세한 내용은 [AWS 콘솔에 대한 사용자 지정 ID 브로커 액세스 활성화](id_roles_providers_enable-console-custom-url.md) 단원을 참조하십시오.

**CloudTrail에 로그인 세부 정보 로깅**  
CloudTrail에서 로그인 이벤트를 로그에 기록하도록 설정한 경우 CloudTrail에서 이벤트를 기록할 위치를 선택하는 방법을 알고 있어야 합니다.
+ 사용자가 콘솔에 직접 로그인할 경우 선택한 서비스 콘솔이 리전을 지원하는지 여부를 기준으로 글로벌 또는 리전 로그인 종단점으로 리디렉션됩니다. 예를 들어 메인 콘솔 홈 페이지는 리전을 지원합니다. 따라서 다음 URL에 로그인할 경우

  ```
  https://alias.signin.aws.amazon.com/console
  ```

  `https://us-east-2.signin.aws.amazon.com`과 같은 리전 로그인 엔드포인트로 리디렉션되어 사용자의 리전 로그에 리전 CloudTrail 로그 항목이 기록됩니다.

  반면 Amazon S3 콘솔은 리전을 지원하지 않습니다. 따라서 다음 URL에 로그인할 경우

  ```
  https://alias.signin.aws.amazon.com/console/s3
  ```

  AWS가 `https://signin.aws.amazon.com`의 글로벌 로그인 엔드포인트로 사용자를 리디렉션하여 글로벌 CloudTrail 로그 항목이 기록됩니다.
+ 다음과 같은 URL 구문을 사용하여 리전이 활성화된 메인 콘솔 홈 페이지에 로그인하면 특정 리전 로그인 종단점을 수동으로 요청할 수 있습니다.

  ```
  https://alias.signin.aws.amazon.com/console?region=ap-southeast-1
  ```

  AWS가 사용자를 `ap-southeast-1` 리전 로그인 엔드포인트로 리디렉션하고 리전 CloudTrail 로그 이벤트가 발생합니다.

CloudTrail 및 IAM에 대한 자세한 내용은 [CloudTrail로 IAM 이벤트 로깅](https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html)을 참조하세요.

계정을 통해 사용자가 작업하기 위해 프로그래밍 방식의 액세스가 필요한 경우 각 사용자의 액세스 키 페어(액세스 키 ID와 보안 액세스 키)를 생성할 수 있습니다. 그러나 사용자를 위한 액세스 키를 생성하기 전에 고려해야 할 더 안전한 대안이 있습니다. 자세한 내용은 **AWS 일반 참조의 [장기 액세스 키에 대한 고려 사항 및 대안](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html#alternatives-to-long-term-access-keys)을 참조하세요.

## 추가 리소스
<a name="id_users_sign-in-additional-resources"></a>

다음 리소스는 AWS 로그인에 대해 자세히 알아보는 데 도움을 줄 수 있습니다.
+ [AWS Sign-In 사용 설명서](https://docs.aws.amazon.com/signin/latest/userguide/what-is-sign-in.html)는 사용자 유형에 따라 Amazon Web Services (AWS)에 로그인할 수 있는 다양한 방법을 이해하는 데 도움을 줍니다.
+ AWS Management Console의 단일 웹 브라우저에서 최대 5개의 서로 다른 자격 증명을 동시에 로그인할 수 있습니다. 자세한 내용은 *AWS Management Console 시작 안내서*의 [Signing in to multiple accounts](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/multisession.html)를 참조하세요.

# MFA 지원 로그인
<a name="console_sign-in-mfa"></a>

[멀티 팩터 인증(MFA)](id_credentials_mfa.md) 디바이스를 사용하여 구성된 사용자는 MFA 디바이스를 사용하여 AWS Management Console에 로그인해야 합니다. 사용자가 자신의 로그인 보안 인증 정보를 입력하면 AWS는 해당 사용자의 계정에서 해당 사용자에게 MFA가 필요한지를 확인합니다.

**중요**  
AWS STS [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) API 직접 호출로 AWS Management Console에 직접 액세스하는 데 액세스 키 및 비밀 키 자격 증명을 사용하는 경우 MFA가 필요하지 않습니다. 자세한 내용은 [콘솔 액세스에 액세스 키 및 비밀 키 자격 증명 사용](securing_access-keys.md#console-access-security-keys) 단원을 참조하십시오.

다음 주제에서는 MFA가 필요할 때 사용자가 로그인을 완료하는 방법에 대한 정보를 제공합니다.

**Topics**
+ [

## 다중 MFA 디바이스 활성화
](#console_sign-in-multiple-mfa)
+ [

## FIDO 보안 키
](#console_sign-in-mfa-fido)
+ [

## 가상 MFA 디바이스
](#console_sign-in-mfa-virtual)
+ [

## 하드웨어 TOTP 토큰
](#console_sign-in-mfa-hardware)

## 다중 MFA 디바이스 활성화
<a name="console_sign-in-multiple-mfa"></a>

사용자가 AWS 계정 루트 사용자 또는 해당 계정에 대해 활성화된 여러 MFA 디바이스가 있는 IAM 사용자로 AWS Management Console에 로그인하는 경우 하나의 MFA 디바이스만 사용하여 로그인하면 됩니다. 사용자가 사용자 암호로 인증한 후 인증을 완료하는 데 사용할 MFA 디바이스 유형을 선택합니다. 그런 다음 사용자에게 선택한 디바이스 유형으로 인증하라는 메시지가 표시됩니다.

## FIDO 보안 키
<a name="console_sign-in-mfa-fido"></a>

MFA가 필요한 사용자에게는 두 번째 로그인 페이지가 나타납니다. 사용자가 FIDO 보안 키를 터치해야 합니다.

**참고**  
Google Chrome 사용자는 **amazon.com으로 아이덴티티 확인(Verify your identity with amazon.com)**을 요청하는 팝업에서 사용 가능한 옵션을 선택해서는 안 됩니다. 보안 키를 탭하기만 하면 됩니다.

다른 MFA 디바이스와 달리 FIDO 보안 키는 항상 동기화되어 있습니다. FIDO 보안 키를 분실했거나 도난당한 경우 관리자가 비활성화할 수 있습니다. 자세한 내용은 [MFA 디바이스 비활성화(콘솔)](id_credentials_mfa_disable.md#deactive-mfa-console) 단원을 참조하십시오.

WebAuthn을 지원하는 브라우저와 AWS에서 지원하는 FIDO 준수 디바이스에 대한 자세한 내용을 알아보려면 [패스키 및 보안 키 사용이 지원되는 구성](id_credentials_mfa_fido_supported_configurations.md) 섹션을 참조하세요.

## 가상 MFA 디바이스
<a name="console_sign-in-mfa-virtual"></a>

MFA가 필요한 사용자에게는 두 번째 로그인 페이지가 나타납니다. **MFA code(MFA 코드)** 상자에 MFA 애플리케이션에서 제공한 숫자 코드를 입력해야 합니다.

MFA 코드가 올바르면 사용자는 AWS Management Console에 액세스할 수 있습니다. 코드가 올바르지 않으면 다른 코드로 다시 시도할 수 있습니다.

가상 MFA 디바이스는 동기화되지 않을 수 있습니다. 여러 번 시도한 후에도 사용자가 AWS Management Console에 로그인할 수 없으면 가상 MFA 디바이스를 동기화하라는 메시지가 표시됩니다. 사용자는 화면에 표시되는 메시지에 따라 가상 MFA 디바이스를 동기화할 수 있습니다. AWS 계정에 속한 사용자 대신 디바이스를 동기화할 수 있는 방법에 대한 자세한 내용은 [가상 및 하드웨어 MFA 디바이스 재동기화](id_credentials_mfa_sync.md) 섹션을 참조하세요.

## 하드웨어 TOTP 토큰
<a name="console_sign-in-mfa-hardware"></a>

MFA가 필요한 사용자에게는 두 번째 로그인 페이지가 나타납니다. **MFA code**(MFA 코드) 상자에 하드웨어 TOTP 토큰에서 제공한 숫자 코드를 입력해야 합니다.

MFA 코드가 올바르면 사용자는 AWS Management Console에 액세스할 수 있습니다. 코드가 올바르지 않으면 다른 코드로 다시 시도할 수 있습니다.

하드웨어 TOTP 토큰이 동기화되지 않을 수 있습니다. 여러 번 시도하여 실패한 후에도 사용자가 AWS Management Console에 로그인할 수 없으면 MFA 토큰 디바이스를 동기화하라는 메시지가 표시됩니다. 사용자는 화면에 표시되는 메시지에 따라 MFA 토큰 디바이스를 동기화할 수 있습니다. AWS 계정에 속한 사용자 대신 디바이스를 동기화할 수 있는 방법에 대한 자세한 내용은 [가상 및 하드웨어 MFA 디바이스 재동기화](id_credentials_mfa_sync.md) 섹션을 참조하세요.

# AWS 계정에서 IAM 사용자 생성
<a name="id_users_create"></a>

**중요**  
 IAM [모범 사례](best-practices.md)는 장기 보안 인증 정보가 있는 IAM 사용자를 사용하는 대신, 인간 사용자가 자격 증명 공급자와의 페더레이션을 사용하여 임시 보안 인증으로 AWS에 액세스하도록 하는 것입니다. 페더레이션 사용자가 지원하지 않는 [특정 사용 사례](gs-identities-iam-users.md)에는 IAM 사용자만 사용하는 것이 좋습니다.

IAM 사용자를 생성하고 사용자가 작업을 수행하도록 허용하는 프로세스가 다음 단계를 구성합니다.

1. [AWS Management Console, AWS CLI](getting-started-workloads.md), Tools for Windows PowerShell에서 사용자를 생성하거나 AWS API 작업을 사용하여 사용자를 생성합니다. AWS Management Console에서 사용자를 생성하면 선택한 항목에 따라 1\$14단계는 자동으로 처리됩니다. 프로그래밍 방식으로 IAM 사용자를 생성하는 경우, 각 단계를 개별적으로 수행해야 합니다.

1. 사용자에게 필요한 액세스 유형에 따라 사용자의 자격 증명을 생성합니다.
   + **콘솔 액세스 활성화 – *선택 사항***: 사용자가 AWS Management Console에 액세스해야 할 경우, [해당 사용자의 암호를 생성](id_credentials_passwords_admin-change-user.md)합니다. 사용자의 콘솔 액세스를 비활성화하면 사용자가 사용자 이름과 암호를 사용하여 AWS Management Console에 로그인하지 못합니다. 그렇더라도 사용자의 권한이 변경되거나 위임된 역할을 사용하여 콘솔에 액세스하지 못하게 되지는 않습니다.
**작은 정보**  
사용자에게 필요한 보안 인증만 생성하세요. 예를 들어, AWS Management Console을 통해서만 액세스해야 하는 사용자에게는 액세스 키를 생성해서는 안 됩니다.

1. 사용자에게 필수 작업을 수행할 권한을 부여합니다. IAM 사용자를 그룹에 추가한 후 해당 그룹에 연결된 정책을 통해 권한을 관리하는 것이 좋습니다. 그러나 권한 정책을 사용자에게 직접 연결하여 권한을 부여할 수도 있습니다. 콘솔을 사용하여 사용자를 추가하는 경우 기존 사용자의 권한을 새 사용자에게 복사할 수 있습니다.

   사용자가 보유할 수 있는 최대 권한을 정의하는 정책을 지정하여 사용자의 권한을 제한하도록 [권한 경계](access_policies_boundaries.md)를 추가할 수도 있습니다. 권한 경계는 어떤 권한도 부여하지 않습니다.

   권한을 부여하거나 권한 경계를 설정하는 데 사용할 사용자 지정 권한 정책을 생성하는 방법에 대한 지침은 [고객 관리형 정책으로 사용자 지정 IAM 권한 정의](access_policies_create.md) 섹션을 참조하세요.

1. (선택 사항) 태그를 연결하여 메타데이터를 사용자에게 추가합니다. IAM에서의 태그 사용에 대한 자세한 내용은 [AWS Identity and Access Management 리소스용 태그](id_tags.md) 섹션을 참조하세요.

1. 사용자에게 필요한 로그인 정보를 제공합니다. 여기에는 암호를 비롯해 사용자가 자격 증명을 제공하는 계정 로그인 웹 페이지의 콘솔 URL이 포함됩니다. 자세한 내용은 [IAM 사용자가 AWS에 로그인하는 방법](id_users_sign-in.md) 단원을 참조하십시오.

1. (선택 사항) 사용자에 대한 [멀티 팩터 인증(MFA)](id_credentials_mfa.md)을 구성합니다. MFA의 경우, 사용자가 AWS Management Console에 로그인할 때마다 일회용 코드를 입력해야 합니다.

1. (선택 사항) IAM 사용자에게 자신의 보안 자격 증명을 관리할 권한을 부여합니다. (기본적으로 IAM 사용자는 자신의 자격 증명을 관리할 권한이 없습니다.) 자세한 내용은 [IAM 사용자에게 자신의 암호 변경 허용](id_credentials_passwords_enable-user-change.md) 단원을 참조하십시오.
**참고**  
콘솔을 사용하여 사용자를 생성하고 **사용자는 다음 로그인 시 새 암호를 생성해야 합니다.**(권장)를 선택하는 경우 사용자에게 필요한 권한이 부여됩니다.

사용자를 생성하기 위해 필요한 권한에 대한 자세한 내용은 [IAM 리소스에 액세스하는 데 필요한 권한](access_permissions-required.md) 섹션을 참조하세요.

특정 사용 사례에 맞게 IAM 사용자를 생성하는 방법에 대한 지침은 다음 주제를 참조하세요.
+ [비상 액세스를 위한 IAM 사용자 생성](getting-started-emergency-iam-user.md)
+ [IAM 역할을 사용할 수 없는 워크로드용 IAM 사용자 생성](getting-started-workloads.md)

# IAM 사용자 보기
<a name="id_users_list"></a>

AWS 계정 또는 특정 IAM 그룹에 속한 IAM 사용자를 나열하고 특정 사용자가 속한 모든 IAM 그룹을 나열할 수 있습니다. 사용자 표시에 필요한 권한에 대한 자세한 내용은 [IAM 리소스에 액세스하는 데 필요한 권한](access_permissions-required.md) 섹션을 참조하세요.

## 계정에 속한 모든 IAM 사용자 나열
<a name="id_users_manage_list-users"></a>

------
#### [ Console ]

1. *AWS 로그인 사용 설명서*의 [AWS에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) 항목에 설명된 대로 사용자 유형에 맞는 로그인 절차를 따르세요.

1. **IAM 콘솔 홈** 페이지의 왼쪽 탐색 창에서 쿼리를 **IAM 검색** 텍스트 상자에 입력합니다.

1. 탐색 창에서 **사용자**를 선택합니다.

콘솔에 AWS 계정에 속한 IAM 사용자가 표시됩니다.

------
#### [ AWS CLI ]

다음 명령 실행:
+ `[aws iam list-users](https://docs.aws.amazon.com/cli/latest/reference/iam/list-users.html)`

------
#### [ API ]

다음 작업을 직접 호출:
+ `[ListUsers](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListUsers.html)` 

------

## IAM 그룹의 IAM 사용자 나열
<a name="id_users_manage_list-users-group"></a>

------
#### [ Console ]

1. *AWS 로그인 사용 설명서*의 [AWS에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) 항목에 설명된 대로 사용자 유형에 맞는 로그인 절차를 따르세요.

1. **IAM 콘솔 홈** 페이지의 왼쪽 탐색 창에서 쿼리를 **IAM 검색** 텍스트 상자에 입력합니다.

1. 탐색 창에서 **사용자 그룹**을 선택합니다.

1. 사용자 그룹의 이름을 선택합니다.

그룹의 구성원인 IAM 사용자는 **사용자** 탭에 나열됩니다.

------
#### [ AWS CLI ]

다음 명령 실행:
+ `[aws iam get-group](https://docs.aws.amazon.com/cli/latest/reference/iam/get-group.html)`

------
#### [ API ]

다음 작업을 직접 호출:
+ `[GetGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetGroup.html)` 

------

## 특정 사용자가 속한 모든 IAM 그룹을 나열하려면
<a name="id_users_manage_list-groups-users"></a>

------
#### [ Console ]

1. *AWS 로그인 사용 설명서*의 [AWS에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) 항목에 설명된 대로 사용자 유형에 맞는 로그인 절차를 따르세요.

1. **IAM 콘솔 홈** 페이지의 왼쪽 탐색 창에서 쿼리를 **IAM 검색** 텍스트 상자에 입력합니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. **사용자** 목록에서 IAM 사용자 이름을 선택합니다.

1. **그룹** 탭을 선택하면 현재 사용자를 포함하는 그룹 목록이 표시됩니다.

------
#### [ AWS CLI ]

다음 명령 실행:
+ `[aws iam list-groups-for-user](https://docs.aws.amazon.com/cli/latest/reference/iam/list-groups-for-user.html)`

------
#### [ API ]

다음 작업을 직접 호출:
+ `[ListGroupsForUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListGroupsForUser.html)` 

------

## 다음 단계
<a name="id_users_list-next-steps"></a>

IAM 사용자 목록이 생성되면 다음 절차를 사용하여 IAM 사용자의 이름을 바꾸거나, 삭제하거나, 비활성화할 수 있습니다.
+ [IAM 사용자 이름 바꾸기](id_users_rename.md)
+ [IAM 사용자 제거 또는 비활성화](id_users_remove.md)

# IAM 사용자 이름 바꾸기
<a name="id_users_rename"></a>

**참고**  
[가장 좋은 방법](best-practices.md)은 인간 사용자가 ID 제공업체와의 페더레이션을 사용하여 임시 보안 인증으로 AWS에 액세스하도록 하는 것입니다. 이 방법을 따르는 경우 사용자가 IAM 사용자 및 그룹을 관리하지 않습니다. 대신 사용자와 그룹은 AWS 외부에서 관리되며 *페더레이션형 ID*로 AWS 리소스에 액세스할 수 있습니다. AWS 페더레이션형 ID는 엔터프라이즈 사용자 디렉터리, 웹 ID 제공업체, Directory Service, Identity Center 디렉터리의 사용자 또는 ID 소스를 통해 제공된 보안 인증을 사용하여 AWS 서비스에 액세스하는 모든 사용자입니다. 페더레이션형 ID는 ID 제공업체에서 정의한 그룹을 사용합니다. AWS IAM Identity Center를 사용하는 경우 IAM Identity Center에서 사용자 및 그룹 생성에 대한 자세한 내용은 *AWS IAM Identity Center User Guide*( 사용 설명서)의 [Manage identities in IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html)(IAM Identity Center에서 ID 관리)를 참조하세요.

Amazon Web Services는 AWS 계정에 속한 IAM 사용자를 관리할 수 있는 다양한 도구를 제공합니다. 계정 또는 사용자 그룹에 속한 IAM 사용자를 나열하거나 특정 사용자가 속한 모든 IAM 그룹을 나열할 수 있습니다. IAM 사용자의 이름을 변경하거나 경로를 변경할 수 있습니다. IAM 사용자 대신 페더레이션형 ID를 사용하도록 전환하는 경우 AWS 계정에서 IAM 사용자를 삭제하거나 사용자를 비활성화할 수 있습니다.

IAM 사용자의 관리형 정책을 추가, 변경 또는 제거하는 방법에 대한 자세한 내용은 [IAM 사용자의 권한 변경](id_users_change-permissions.md) 섹션을 참조하세요. IAM 사용자의 인라인 정책을 관리하는 방법에 대한 자세한 내용은 [IAM 자격 증명 권한 추가 및 제거](access_policies_manage-attach-detach.md), [IAM 정책 편집](access_policies_manage-edit.md), [IAM 정책 삭제](access_policies_manage-delete.md) 섹션을 참조하세요. 가장 좋은 방법은 인라인 정책 대신 관리형 정책을 사용하는 것입니다. *AWS 관리형 정책*은 많은 일반 사용 사례에 대한 권한을 부여합니다. AWS 관리형 정책은 모든 AWS 고객이 사용할 수 있기 때문에 특정 사용 사례에 대해 최소 권한을 부여하지 않을 수 있습니다. 따라서 사용 사례에 고유한 [고객 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)을 정의하여 권한을 줄이는 것이 좋습니다. 자세한 내용은 [AWS 관리형 정책](access_policies_managed-vs-inline.md#aws-managed-policies) 단원을 참조하십시오. 특정 작업 기능을 위해 설계된 AWS 관리형 정책에 대한 자세한 내용은 [직무에 관한 AWS 관리형 정책](access_policies_job-functions.md) 섹션을 참조하세요.

IAM 정책 검증에 대한 자세한 내용은 [IAM 정책 검증](access_policies_policy-validator.md) 섹션을 참조하세요.

**작은 정보**  
[IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)는 IAM 역할이 사용하는 서비스와 작업을 분석한 다음 사용할 수 있는 세분화된 정책을 생성할 수 있습니다. 생성된 각 정책을 테스트한 후 프로덕션 환경에 해당 정책을 배포할 수 있습니다. 이렇게 하면 워크로드에 필요한 권한만 부여할 수 있습니다. 정책 생성에 대한 자세한 내용은 [IAM Access Analyzer 정책 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)을 참조하세요.

IAM 사용자 암호 관리에 대한 자세한 내용은 [IAM 사용자 암호 관리](id_credentials_passwords_admin-change-user.md) 섹션을 참조하세요.

## IAM 사용자 이름 바꾸기
<a name="id_users_renaming"></a>

사용자의 이름 또는 경로를 변경하려면 AWS CLI, Tools for Windows PowerShell 또는 AWS API를 사용해야 합니다. 콘솔에서는 사용자의 이름을 변경할 수 있는 옵션이 없습니다. 사용자의 이름을 변경하기 위해 필요한 권한에 대한 자세한 내용은 [IAM 리소스에 액세스하는 데 필요한 권한](access_permissions-required.md) 섹션을 참조하세요.

사용자의 이름 또는 경로를 변경하면 다음과 같이 진행됩니다.
+ 사용자에 연결된 정책은 이름이 변경되어도 계속 유지됩니다.
+ 사용자는 전과 동일한 IAM 그룹에 새 이름으로 표시됩니다.
+ 사용자의 고유 ID는 전과 같습니다. 고유 ID에 대한 자세한 내용은 [고유 식별자](reference_identifiers.md#identifiers-unique-ids) 섹션을 참조하세요.
+ 사용자를 *보안 주체로* 참조(해당 사용자에게 액세스가 부여됨)하는 리소스 또는 역할 정책은 새 이름 또는 경로를 사용하도록 자동 업데이트됩니다. 예를 들어 Amazon SQS의 대기열 기반 정책 또는 Amazon S3의 리소스 기반 정책은 자동 업데이트되어 새 이름과 경로를 사용합니다.

사용자를 *리소스로* 참조하는 정책은 새 이름 또는 경로를 사용하도록 IAM에서 자동 업데이트하지 않으므로 수동으로 업데이트해야 합니다. 예를 들어 사용자 `Richard`에게 자신의 보안 자격 증명을 관리하는 정책이 연결되어 있을 경우 관리자가 `Richard`에서 `Rich`로 이름을 변경하면 다음과 같이 리소스가 변경되도록 관리자가 정책도 업데이트해야 합니다.

```
arn:aws:iam::111122223333:user/division_abc/subdivision_xyz/Richard
```

다음으로 업데이트:

```
arn:aws:iam::111122223333:user/division_abc/subdivision_xyz/Rich
```

마찬가지로 경로를 변경할 경우에도 관리자가 사용자에 대한 새 경로를 반영하도록 정책을 업데이트해야 합니다.

### 사용자의 이름을 바꾸려면
<a name="id_users_manage_list-users-rename"></a>
+ AWS CLI: [aws iam update-user](https://docs.aws.amazon.com/cli/latest/reference/iam/update-user.html)
+ AWS API: [UpdateUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateUser.html) 

# IAM 사용자 제거 또는 비활성화
<a name="id_users_remove"></a>

[모범 사례](best-practices.md#remove-credentials)에 따라 AWS 계정에서 미사용 IAM 사용자를 제거하는 것이 좋습니다. 나중에 사용할 수 있도록 IAM 사용자 자격 증명을 유지하려면 계정에서 삭제하는 대신 사용자의 액세스를 비활성화할 수 있습니다. 자세한 내용은 [IAM 사용자 비활성화](#id_users_deactivating) 섹션을 참조하세요.

**주의**  
IAM 사용자와 해당 액세스 키가 삭제되면 복원하거나 복구할 수 없습니다.

## 사전 조건 - IAM 사용자 액세스 보기
<a name="users-manage_prerequisites"></a>

사용자를 제거하기 전에 최근 서비스 수준 활동을 검토합니다. 이렇게 하면 이를 사용하는 보안 주체(개인 또는 애플리케이션)의 액세스 권한 제거를 방지할 수 있습니다. 마지막으로 액세스한 정보 보기에 대한 자세한 내용은 [마지막으로 액세스한 정보를 사용하여 AWS에서 권한 재정의](access_policies_last-accessed.md) 섹션을 참조하세요.

## IAM 사용자 제거(콘솔)
<a name="id_users_deleting_console"></a>

AWS Management Console을 사용하여 IAM 사용자를 제거하면 IAM에서 자동으로 다음 관련 정보를 삭제합니다.
+ IAM 사용자 식별자
+ 모든 그룹 멤버십(IAM 사용자가 속해 있던 모든 IAM 그룹에서 제거됨)
+ IAM 사용자와 연결된 모든 암호 
+ IAM 사용자에게 포함된 모든 인라인 정책(사용자 그룹 권한을 사용하여 IAM 사용자에게 적용되는 정책은 영향을 받지 않음) 
**참고**  
사용자를 삭제할 때 IAM은 IAM 사용자에 연결된 관리형 정책을 제거하지만 관리형 정책을 삭제하지는 않습니다.
+ 연결된 모든 MFA 디바이스

### IAM 사용자 제거(콘솔)
<a name="id_users_remove-section-1"></a>

------
#### [ Console ]

1. *AWS 로그인 사용 설명서*의 [AWS에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) 항목에 설명된 대로 사용자 유형에 맞는 로그인 절차를 따르세요.

1. **IAM 콘솔 홈** 페이지의 왼쪽 탐색 창에서 쿼리를 **IAM 검색** 텍스트 상자에 입력합니다.

1. 왼쪽 탐색 창에서 **사용자**를 선택한 후 삭제할 IAM 사용자 이름 옆에 있는 확인란을 선택하세요.

1. 페이지 상단에서 **삭제(Delete)**를 선택합니다.
**참고**  
사용자에게 활성 액세스 키가 있는 경우 사용자를 삭제하기 전에 액세스 키를 비활성화해야 합니다. 자세한 내용은 [IAM 사용자의 액세스 키 비활성화](access-keys-admin-managed.md#admin-deactivate-access-key) 섹션을 참조하세요.

1. 확인 대화 상자에서 텍스트 입력 필드에 사용자 이름을 입력하여 사용자 삭제를 확인합니다. **삭제**를 선택합니다.

콘솔에 IAM 사용자가 삭제되었다는 상태 알림이 표시됩니다.

------

## IAM 사용자 삭제(AWS CLI)
<a name="id_users_deleting_cli"></a>

AWS Management Console과 달리 AWS CLI로 IAM 사용자를 삭제할 때는 IAM 사용자에게 연결된 항목들을 수동으로 삭제해야 합니다. 다음 절차는 그 과정을 보여줍니다.

**AWS 계정(AWS CLI)에서 IAM 사용자 삭제**

1. 해당 사용자의 암호가 있으면 삭제합니다.

   `[aws iam delete-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-login-profile.html)`

1. 해당 사용자의 액세스 키가 있으면 삭제합니다.

   `[aws iam list-access-keys](https://docs.aws.amazon.com/cli/latest/reference/iam/list-access-keys.html)`(사용자의 액세스 키 나열) 및 `[aws iam delete-access-key](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-access-key.html)`

1. 사용자 서명 인증서를 삭제합니다. 보안 자격 증명을 삭제하면 영원히 지워져 검색할 수 없습니다.

   `[aws iam list-signing-certificates](https://docs.aws.amazon.com/cli/latest/reference/iam/list-signing-certificates.html)`(사용자의 서명 인증서 나열) 및 `[aws iam delete-signing-certificate](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-signing-certificate.html)`

1. 해당 사용자의 SSH 퍼블릭 키가 있으면 삭제합니다.

   `[aws iam list-ssh-public-keys](https://docs.aws.amazon.com/cli/latest/reference/iam/list-ssh-public-keys.html)`(사용자의 SSH 퍼블릭 키 나열) 및 `[aws iam delete-ssh-public-key](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-ssh-public-key.html)`

1. 사용자의 Git 자격 증명을 삭제합니다.

   `[aws iam list-service-specific-credentials](https://docs.aws.amazon.com/cli/latest/reference/iam/list-service-specific-credentials.html)`(사용자의 Git 자격 증명 나열) 및 `[aws iam delete-service-specific-credential](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-service-specific-credential.html)`

1. 해당 사용자의 Multi-Factor Authentication(MFA) 디바이스가 있으면 비활성화합니다.

   `[aws iam list-mfa-devices](https://docs.aws.amazon.com/cli/latest/reference/iam/list-mfa-devices.html)`(사용자의 MFA 디바이스 나열), `[aws iam deactivate-mfa-device](https://docs.aws.amazon.com/cli/latest/reference/iam/deactivate-mfa-device.html)`(디바이스 비활성화) 및 `[aws iam delete-virtual-mfa-device](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-virtual-mfa-device.html)`(가상 MFA 디바이스를 영구 삭제) 

1. 사용자의 인라인 정책을 삭제합니다.

   `[aws iam list-user-policies](https://docs.aws.amazon.com/cli/latest/reference/iam/list-user-policies.html)`(사용자에 대한 인라인 정책 나열) 및 [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-user-policy.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-user-policy.html)(정책 삭제) 

1. 사용자에 연결된 관리형 정책을 모두 분리합니다.

   `[aws iam list-attached-user-policies](https://docs.aws.amazon.com/cli/latest/reference/iam/list-attached-user-policies.html)`(사용자에게 연결된 관리형 정책 나열) 및 [https://docs.aws.amazon.com/cli/latest/reference/iam/detach-user-policy.html](https://docs.aws.amazon.com/cli/latest/reference/iam/detach-user-policy.html)(정책 분리) 

1. 사용자를 모든 IAM 그룹에서 제거합니다.

   `[aws iam list-groups-for-user](https://docs.aws.amazon.com/cli/latest/reference/iam/list-groups-for-user.html)`(사용자가 속한 IAM 그룹 나열) 및 `[aws iam remove-user-from-group](https://docs.aws.amazon.com/cli/latest/reference/iam/remove-user-from-group.html)` 

1. 사용자를 삭제합니다.

   `[aws iam delete-user](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-user.html)` 

## IAM 사용자 비활성화
<a name="id_users_deactivating"></a>

IAM 사용자가 잠시 회사를 떠나 있는 동안 IAM 사용자를 비활성화해야 할 수 있습니다. IAM 사용자 자격 증명을 그대로 두고 AWS 액세스를 계속 차단할 수 있습니다.

사용자를 비활성화하려면 AWS에 대한 사용자 액세스를 거부하는 정책을 생성하고 연결합니다. 나중에 사용자의 액세스 권한을 복원할 수 있습니다.

다음은 액세스를 거부하기 위해 사용자에게 연결할 수 있는 거부 정책의 두 가지 예입니다.

다음 정책에는 시간 제한이 포함되지 않습니다. 사용자의 액세스 권한을 복원하려면 정책을 제거해야 합니다.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [ 
      {
        "Effect": "Deny",
        "Action": "*",
        "Resource": "*"
      } 
   ]
}
```

------

다음 정책에는 2024년 12월 24일 오후 11:59(UTC)에 시작하여 2025년 2월 28일 오후 11:59(UTC)에 종료하는 조건이 포함되어 있습니다.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
      {
        "Effect": "Deny",
        "Action": "*",
        "Resource": "*",
        "Condition": {
          "DateGreaterThan": {"aws:CurrentTime": "2024-12-24T23:59:59Z"},
          "DateLessThan": {"aws:CurrentTime": "2025-02-28T23:59:59Z"}
          }
       }
   ]
}
```

------

# AWS Management Console에 대한 IAM 사용자 액세스 제어
<a name="console_controlling-access"></a>

AWS Management Console을 통해 AWS 계정에 로그인하는 권한이 있는 IAM 사용자는 AWS 리소스에 액세스할 수 있습니다. 다음 목록에서는 AWS Management Console을 통해 AWS 계정 리소스에 대한 액세스 권한을 IAM 사용자에게 부여하는 방법을 보여 줍니다. 또한 IAM 사용자가 AWS 웹 사이트를 통해 다른 AWS 계정 기능에 액세스할 보여 줍니다.

**참고**  
IAM 사용에는 요금이 부과되지 않습니다.

**AWS Management Console은**  
AWS Management Console에 액세스해야 하는 각 IAM 사용자에 대해 암호를 만듭니다. 사용자는 IAM 지원 AWS 계정 로그인 페이지를 통해 콘솔에 액세스합니다. 로그인 페이지 액세스에 대한 자세한 내용은 *AWS Sign-In 사용 설명서*의 [AWS 로그인 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)을 참조하세요. 암호 만들기에 대한 자세한 내용은 [AWS의 사용자 암호](id_credentials_passwords.md)을 참조하세요.  
사용자의 암호를 제거하여 IAM 사용자가 AWS Management Console에 액세스하지 못하도록 할 수 있습니다. 그러면 사용자는 자신의 로그인 보안 인증을 사용해 AWS Management Console에 로그인할 수 없습니다. 그렇더라도 사용자의 권한이 변경되거나 위임된 역할을 사용하여 콘솔에 액세스하지 못하게 되지는 않습니다. 사용자에게 활성 액세스 키가 있다면 해당 키는 계속 작동하고 AWS CLI, Tools for Windows PowerShell 또는 AWS API 또는 AWS Console Mobile Application을 통해 액세스를 허용합니다.

**Amazon EC2 인스턴스, Amazon S3 버킷 등의 AWS 리소스**  
IAM 사용자에게 암호가 있더라도 AWS 리소스에 액세스하려면 권한이 필요합니다. IAM 사용자를 만들 때 이 사용자에게는 기본적으로 권한이 없습니다. IAM 사용자에게 필요한 권한을 부여하려면 해당 사용자에게 정책을 연결합니다. 같은 리소스로 같은 작업을 수행할 IAM 사용자가 많은 경우 해당 IAM 사용자를 그룹에 할당할 수 있습니다. 이 그룹에 권한을 할당할 수 있습니다. IAM 사용자 및 그룹 만들기에 대한 자세한 내용은 [IAM 자격 증명](id.md)을 참조하세요. 권한 설정을 위한 정책 사용에 대한 자세한 내용은 [AWS리소스에 대한 액세스 관리](access.md)을 참조하세요.

**AWS 토론 포럼**  
누구나 [AWS 토론 포럼](https://forums.aws.amazon.com/)에서 게시물을 읽을 수 있습니다. AWS 토론 포럼에 질문이나 의견을 게시하고자 하는 사용자는 자신의 사용자 이름을 사용하여 그렇게 할 수 있습니다. 사용자가 처음으로 AWS 토론 포럼에 게시하면 별칭과 이메일 주소를 입력하라는 메시지가 표시됩니다. 해당 사용자만 AWS 토론 포럼에서 해당 별칭을 사용할 수 있습니다.

**AWS 계정 결제 및 사용 정보**  
AWS 계정 결제 및 사용 정보에 대한 액세스 권한을 사용자에게 부여할 수 있습니다. 자세한 내용은 *AWS Billing 사용 설명서*의 [결제 정보에 대한 액세스 제어](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/control-access-billing.html)를 참조하세요.

**AWS 계정 프로필 정보**  
사용자는 계정 소유자의 AWS 계정 프로필 정보에 액세스할 수 없습니다.

**AWS 계정 보안 인증 정보**  
사용자는 계정 소유자의 AWS 계정 보안 인증 정보에 액세스할 수 없습니다.

**참고**  
IAM 정책은 인터페이스와 관계없이 액세스를 제어합니다. 예를 들어 AWS Management Console에 액세스하기 위한 암호를 사용자에게 제공할 수 있습니다. 해당 사용자(또는 사용자가 속한 그룹)에 대한 정책은 사용자가 AWS Management Console에서 수행할 수 있는 작업을 제어합니다. 또는 AWS에 대해 API 호출을 실행하기 위한 AWS 액세스 키를 사용자에게 제공할 수 있습니다. 이렇게 하면 인증을 위해 해당 액세스 키를 사용하는 라이브러리 또는 클라이언트를 통해 사용자가 호출할 수 있는 작업이 정책을 통해 제어됩니다.

# IAM 사용자의 권한 변경
<a name="id_users_change-permissions"></a>

AWS 계정에서 IAM 사용자의 권한을 변경하려면 사용자의 그룹 멤버십을 변경하거나, 기존 사용자의 권한을 복사하거나, 사용자에 정책을 직접 연결하거나, [권한 경계](access_policies_boundaries.md)를 설정할 수 있습니다. 이 권한 경계는 사용자가 가질 수 있는 최대 권한을 관리합니다. 권한 경계는 고급 AWS 기능입니다.

사용자의 권한을 수정하기 위해 필요한 권한에 대한 자세한 내용은 [IAM 리소스에 액세스하는 데 필요한 권한](access_permissions-required.md) 섹션을 참조하세요.

**Topics**
+ [

## 사용자 액세스 보기
](#users-modify_prerequisites)
+ [

## 사용자의 액세스 활동을 기반으로 정책 생성
](#users_change_permissions-gen-policy)
+ [

## 사용자에 권한 추가(콘솔)
](#users_change_permissions-add-console)
+ [

## 사용자의 권한 변경(콘솔)
](#users_change_permissions-change-console)
+ [

## 사용자에게서 권한 정책 제거(콘솔)
](#users_change_permissions-remove-policy-console)
+ [

## 사용자에게서 권한 경계 제거(콘솔)
](#users_change_permissions-remove-boundary-console)
+ [

## 사용자 권한 추가 및 제거(AWS CLI 또는 AWS API)
](#users_change_permissions-add-programmatic)

## 사용자 액세스 보기
<a name="users-modify_prerequisites"></a>

사용자에 대한 권한을 변경하기 전에 최근 서비스 수준 활동을 검토해야 합니다. 이 기능은 사용 중인 보안 주체(사람 또는 애플리케이션)의 액세스 권한을 제거하지 않으려는 경우 중요합니다. 마지막으로 액세스한 정보 보기에 대한 자세한 내용은 [마지막으로 액세스한 정보를 사용하여 AWS에서 권한 재정의](access_policies_last-accessed.md) 섹션을 참조하세요.

## 사용자의 액세스 활동을 기반으로 정책 생성
<a name="users_change_permissions-gen-policy"></a>

때로는 IAM 엔터티(사용자 또는 역할)에 필요한 것보다 많은 권한을 부여할 수도 있습니다. 부여하는 권한을 세분화할 수 있도록 엔터티의 액세스 활동을 기반으로 IAM 정책을 생성할 수 있습니다. IAM Access Analyzer는 사용자의 AWS CloudTrail 로그를 검토하고 지정된 날짜 범위에 엔터티에서 사용한 권한을 포함하는 정책 템플릿을 생성합니다. 이 템플릿을 사용하여 세분화된 권한이 포함된 관리형 정책을 생성한 다음 IAM 엔터티에 연결할 수 있습니다. 이렇게 하면 특정 사용 사례에 사용자나 역할이 AWS 리소스와 상호 작용하는 데 필요한 권한만 부여됩니다. 자세한 내용은 [IAM Access Analyzer 정책 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)을 참조하세요.

## 사용자에 권한 추가(콘솔)
<a name="users_change_permissions-add-console"></a>

IAM은 사용자에 권한 정책을 추가하는 세 가지 방법을 제공합니다.
+ **IAM 그룹에 IAM 사용자 추가** - 사용자를 그룹의 구성원으로 만듭니다. 그룹의 정책은 사용자로 연결됩니다.
+ **기존 IAM 사용자의 권한 복사** - 소스 사용자의 모든 그룹 멤버십, 연결된 관리형 정책, 인라인 정책 및 모든 기존 권한 경계를 복사합니다.
+ **정책을 IAM 사용자에 직접 연결** - 관리형 정책을 사용자에 직접 연결합니다. 더 쉬운 권한 관리를 위해 정책을 그룹에 연결한 다음 IAM 사용자를 적절한 그룹의 멤버로 만드세요.

**중요**  
사용자에게 권한 경계가 있다면 권한 경계가 허용한 권한보다 더 많은 권한을 추가할 수 없습니다.

### IAM 사용자를 그룹에 추가하여 권한 추가
<a name="users_change_permissions-add-group-console"></a>

IAM 그룹에 IAM 사용자를 추가하면 사용자 권한이 그룹에 정의된 권한으로 즉시 업데이트됩니다.

------
#### [ Console ]

1. *AWS 로그인 사용 설명서*의 [AWS에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) 항목에 설명된 대로 사용자 유형에 맞는 로그인 절차를 따르세요.

1. **IAM 콘솔 홈** 페이지의 왼쪽 탐색 창에서 쿼리를 **IAM 검색** 텍스트 상자에 입력합니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. **사용자** 목록에서 IAM 사용자 이름을 선택합니다.

1. **그룹** 탭을 선택하면 현재 사용자를 포함하는 그룹 목록이 표시됩니다.

1. **그룹에 사용자 추가**를 선택합니다.

1. 사용자를 조인하려는 각 그룹의 확인란을 선택하세요. 그 목록에는 각 그룹의 이름과 사용자가 그 그룹의 구성원이 되면 받는 정책이 표시됩니다.

1. (선택 사항) **그룹 생성**을 선택하여 새 그룹을 정의할 수 있습니다. 이는 기존 그룹과 다른 정책이 연결된 그룹에 사용자를 추가하려는 경우 유용합니다.

   1. 새로운 탭에서 **사용자 그룹 이름**으로 새로운 그룹의 이름을 입력합니다.
**참고**  
AWS 계정의 IAM 리소스 수와 크기는 제한되어 있습니다. 자세한 내용은 [IAM 및 AWS STS 할당량](reference_iam-quotas.md) 섹션을 참조하세요. 그룹 이름에는 최대 128개의 알파벳, 숫자 및 더하기(\$1), 등호(=), 쉼표(,), 마침표(.), 앳(@), 그리고 하이픈(-) 조합을 사용할 수 있습니다. 이름은 계정 내에서 고유해야 합니다. 대소문자는 구별하지 않습니다. 예를 들어 *"TESTGROUP"*과 *"testgroup"*이라는 두 그룹을 만들 수는 없습니다.

   1. 그룹에 연결하려는 관리형 정책에 대해 하나 이상의 확인란을 선택하세요. **정책 생성**을 선택하여 새로운 관리형 정책을 만들 수도 있습니다. 이렇게 하는 경우, 새 정책이 완료되면 이 브라우저 탭 또는 창으로 돌아가 **새로 고침**을 선택한 다음, 그룹에 연결할 새로운 정책을 선택합니다. 자세한 내용은 [고객 관리형 정책으로 사용자 지정 IAM 권한 정의](access_policies_create.md) 섹션을 참조하세요.

   1. **사용자 그룹 만들기**를 선택합니다.

   1. 기존 탭으로 반환하고 그룹 목록을 새로 고침합니다. 그런 다음, 새로운 그룹에 대한 확인란을 선택하세요.

1. **그룹에 사용자 추가**를 선택합니다.

콘솔에 사용자가 지정한 그룹에 추가되었음을 알리는 상태 메시지가 표시됩니다.

------

### 다른 IAM 사용자에게서 복사하여 권한 추가
<a name="users_change_permissions-add-copy-console"></a>

권한을 복사하여 IAM 사용자에게 권한을 추가하는 경우 IAM은 지정된 사용자의 모든 그룹 멤버십, 연결된 관리형 정책, 인라인 정책 및 기존 권한 경계를 복사하여 현재 선택한 사용자에게 즉시 적용합니다.

------
#### [ Console ]

1. *AWS 로그인 사용 설명서*의 [AWS에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) 항목에 설명된 대로 사용자 유형에 맞는 로그인 절차를 따르세요.

1. **IAM 콘솔 홈** 페이지의 왼쪽 탐색 창에서 쿼리를 **IAM 검색** 텍스트 상자에 입력합니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. **사용자** 목록에서 IAM 사용자 이름을 선택합니다.

1. **권한** 탭에서 **권한 추가**를 선택합니다.

1. **권한 추가** 페이지에서 **권한 복사**를 선택합니다. 목록에는 사용 가능한 IAM 사용자들이 그들의 그룹 멤버십 및 연결된 정책과 함께 표시됩니다.

1. 복사하고자 하는 권한을 보유한 사용자 옆에 있는 라디오 버튼을 선택합니다.

1. **다음**을 선택하여 사용자에 대한 변경 사항의 목록을 확인합니다. 그런 다음 **Add permissions(권한 추가)**를 선택합니다.

콘솔에 지정한 IAM 사용자로부터 권한이 복사되었음을 알리는 상태 메시지가 표시됩니다.

------

### IAM 사용자에게 정책을 직접 연결하여 권한 추가
<a name="users_change_permissions-add-directly-console"></a>

관리형 정책을 IAM 사용자에게 직접 연결할 수 있습니다. 업데이트된 권한은 즉시 적용됩니다.

------
#### [ Console ]

1. *AWS 로그인 사용 설명서*의 [AWS에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) 항목에 설명된 대로 사용자 유형에 맞는 로그인 절차를 따르세요.

1. **IAM 콘솔 홈** 페이지의 왼쪽 탐색 창에서 쿼리를 **IAM 검색** 텍스트 상자에 입력합니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. **사용자** 목록에서 IAM 사용자 이름을 선택합니다.

1. **권한** 탭에서 **권한 추가**를 선택합니다.

1. **권한 추가** 페이지에서 **정책을 직접 연결**을 선택합니다. **권한 정책** 목록에는 사용 가능한 정책 유형 및 연결된 엔터티와 함께 사용 가능한 정책이 표시됩니다.

1. 연결하려는 **정책 이름** 옆에 있는 라디오 버튼을 선택합니다.

1. **다음**을 선택하여 사용자에 대한 변경 사항의 목록을 확인합니다. 그런 다음 **Add permissions(권한 추가)**를 선택합니다.

콘솔에 지정한 IAM 사용자에게 정책이 추가되었음을 알리는 상태 메시지가 표시됩니다.

------

### IAM 사용자에 대한 권한 경계 설정
<a name="users_change_permissions-set-boundary-console"></a>

권한 경계는 IAM 사용자가 가질 수 있는 최대 권한을 설정하는 데 사용되는 AWS의 권한을 관리하기 위한 고급 기능입니다. 권한 경계를 설정하면 부여된 다른 권한과 무관하게 IAM 사용자 권한이 경계로 즉시 제한됩니다.

------
#### [ Console ]

1. *AWS 로그인 사용 설명서*의 [AWS에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) 항목에 설명된 대로 사용자 유형에 맞는 로그인 절차를 따르세요.

1. **IAM 콘솔 홈** 페이지의 왼쪽 탐색 창에서 쿼리를 **IAM 검색** 텍스트 상자에 입력합니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. **사용자** 목록에서 권한 경계를 변경하려는 IAM 사용자의 이름을 선택합니다.

1. **권한** 탭을 선택합니다. 필요하다면 **권한 경계** 섹션을 열고 **권한 경계 설정**을 선택합니다.

1. **권한 경계 설정** 페이지의 **권한 정책**에서 권한 경계에 사용할 정책을 선택합니다.

1. **Set boundary(경계 설정)**을 선택합니다.

콘솔에 권한 경계가 추가되었음을 알리는 상태 메시지가 표시됩니다.

------

## 사용자의 권한 변경(콘솔)
<a name="users_change_permissions-change-console"></a>

IAM을 사용하면 다음과 같은 방법으로 사용자와 연결된 권한을 변경할 수 있습니다.
+ **권한 정책 편집** - 사용자 인라인 정책, 사용자 그룹의 인라인 정책을 편집하거나 사용자에 직접 연결되거나 그룹에서 연결된 관리형 정책을 편집합니다. 사용자에게 권한 경계가 있다면 권한 경계로 사용된 정책이 허용한 권한보다 더 많은 권한을 제공할 수 없습니다.
+ **권한 경계 변경** - 사용자의 권한 경계로 사용되는 정책을 변경합니다. 이로써 사용자가 가질 수 있는 최대 권한을 확장 또는 제한할 수 있습니다.

### 사용자에 연결된 권한 정책 편집
<a name="users_change_permissions-edit-policy-console"></a>

권한 변경으로 사용자 액세스는 바로 업데이트됩니다.

------
#### [ Console ]

1. *AWS 로그인 사용 설명서*의 [AWS에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) 항목에 설명된 대로 사용자 유형에 맞는 로그인 절차를 따르세요.

1. **IAM 콘솔 홈** 페이지의 왼쪽 탐색 창에서 쿼리를 **IAM 검색** 텍스트 상자에 입력합니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. **사용자** 목록에서 권한 경계를 변경하려는 IAM 사용자의 이름을 선택합니다.

1. **권한** 탭을 선택합니다. 필요하다면 **권한 경계** 섹션을 엽니다.

1. 정책에 대한 세부 정보를 보기 위해서 편집하고자 하는 정책 이름을 선택합니다. 정책을 편집하면 영향을 받을 수 있는 다른 엔터티(IAM 사용자, 그룹 및 역할)를 보려면 **연결된 엔터티** 탭을 선택합니다.

1. 그런 다음 **Permissions tab(권한 탭)**을 정책이 허용한 권한을 검토합니다. 권한을 변경하려면 **편집**을 선택합니다.

1. 정책을 편집하고 모든 [정책 검사](access_policies_policy-validator.md) 권장 사항을 해결합니다. 자세한 내용은 [IAM 정책 편집](access_policies_manage-edit.md) 섹션을 참조하세요.

1. **다음**을 선택한 다음 정책 요약을 검토한 후 **변경 사항 저장**을 선택합니다.

콘솔에 정책이 업데이트되었음을 알리는 상태 메시지가 표시됩니다.

------

### 사용자에 대한 권한 경계 변경
<a name="users_change_permissions-change-boundary-console"></a>

권한 경계 변경으로 사용자 액세스는 바로 업데이트됩니다.

------
#### [ Console ]

1. *AWS 로그인 사용 설명서*의 [AWS에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) 항목에 설명된 대로 사용자 유형에 맞는 로그인 절차를 따르세요.

1. **IAM 콘솔 홈** 페이지의 왼쪽 탐색 창에서 쿼리를 **IAM 검색** 텍스트 상자에 입력합니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. **사용자** 목록에서 권한 경계를 변경하려는 IAM 사용자의 이름을 선택합니다.

1. **권한** 탭을 선택합니다. 필요하다면 **Permissions boundary(권한 경계)** 섹션을 열고 **Change boundary(경계 변경)**을 선택합니다.

1. 정책을 선택하여 원하는 권한 경계를 사용하세요.

1. **Set boundary(경계 설정)**을 선택합니다.

콘솔에 권한 경계가 변경되었음을 알리는 상태 메시지가 표시됩니다.

------

## 사용자에게서 권한 정책 제거(콘솔)
<a name="users_change_permissions-remove-policy-console"></a>

권한 정책 제거로 사용자 액세스는 바로 업데이트됩니다.

------
#### [ Console ]

1. *AWS 로그인 사용 설명서*의 [AWS에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) 항목에 설명된 대로 사용자 유형에 맞는 로그인 절차를 따르세요.

1. **IAM 콘솔 홈** 페이지의 왼쪽 탐색 창에서 쿼리를 **IAM 검색** 텍스트 상자에 입력합니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. 권한 정책을 제거하려는 사용자의 이름을 선택합니다.

1. **권한** 탭을 선택합니다.

1. 기존 정책을 제거하여 권한을 제거하려면 **제거**를 선택하여 정책을 제거하기 전에 **연결 수단** 열을 보고 사용자가 해당 정책을 가져오는 방법을 파악합니다.
   + 그 정책이 그룹 멤버십 때문에 적용되는 경우, **제거**를 선택하면 사용자가 그룹에서 제거됩니다. 한 그룹에 여러 정책이 연결될 수 있습니다. 따라서 그룹에서 사용자를 제거할 경우 사용자는 그 그룹의 멤버십을 통해 받은 *모든* 정책에 대한 액세스 권한을 잃게 됩니다.
   + 정책이 사용자에 직접 연결된 관리형 정책인 경우 **제거**를 선택하면 정책이 사용자와 분리됩니다. 이렇게 해도 정책 자체 또는 그 정책이 연결되어 있을 수 있는 다른 개체에는 영향을 미치지 않습니다.
   + 정책이 인라인 포함 정책인 경우, **제거**를 선택하면 정책이 IAM에서 제거됩니다. 사용자에 직접 연결된 인라인 정책은 해당 사용자에만 존재합니다.

그룹 멤버십을 통해 정책이 사용자에게 부여된 경우 콘솔에 IAM 사용자가 IAM 그룹에서 제거되었음을 알리는 상태 메시지가 표시됩니다. 정책이 직접 연결되거나 인라인인 경우 정책이 제거되었음을 알리는 상태 메시지가 표시됩니다.

------

## 사용자에게서 권한 경계 제거(콘솔)
<a name="users_change_permissions-remove-boundary-console"></a>

권한 경계 제거로 사용자 액세스는 바로 업데이트됩니다.

------
#### [ Console ]

1. *AWS 로그인 사용 설명서*의 [AWS에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) 항목에 설명된 대로 사용자 유형에 맞는 로그인 절차를 따르세요.

1. **IAM 콘솔 홈** 페이지의 왼쪽 탐색 창에서 쿼리를 **IAM 검색** 텍스트 상자에 입력합니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. **사용자** 목록에서 권한 경계를 제거하려는 IAM 사용자의 이름을 선택합니다.

1. **권한** 탭을 선택합니다. 필요하다면 **권한 경계** 섹션을 엽니다.

1.  **Change boundary(경계 변경)**을 선택합니다. 권한 경계 제거를 확인하려면 확인 대화 상자에서 **경계 제거**를 선택합니다.

콘솔에 권한 경계가 제거되었음을 알리는 상태 메시지가 표시됩니다.

------

## 사용자 권한 추가 및 제거(AWS CLI 또는 AWS API)
<a name="users_change_permissions-add-programmatic"></a>

프로그래밍 방식으로 권한을 추가 또는 제거하려면 그룹 멤버십을 추가 또는 제거하거나 관리형 정책을 연결 또는 분리하거나 인라인 정책을 추가 또는 삭제해야 합니다. 자세한 정보는 다음 주제를 참조하세요.
+ [IAM 그룹의 사용자 편집](id_groups_manage_add-remove-users.md)
+ [IAM 자격 증명 권한 추가 및 제거](access_policies_manage-attach-detach.md)

# AWS의 사용자 암호
<a name="id_credentials_passwords"></a>

계정 IAM 사용자에 대한 암호를 관리할 수 있습니다. IAM 사용자는 AWS Management Console에 액세스하기 위해 암호가 필요합니다. 사용자가 AWS CLI, Tools for Windows PowerShell, AWS SDK 또는 API를 사용하여 프로그래밍 방식으로 AWS 리소스에 액세스하는 경우 암호가 필요 없습니다. 이러한 환경의 경우 IAM 사용자에게 [액세스 키](id_credentials_access-keys.md)를 할당하는 옵션이 있습니다. 그러나 액세스 키에 대한 다른 더 안전한 대안이 있습니다. 먼저 이를 고려해 보는 것이 좋습니다. 자세한 내용은 [AWS 보안 인증 정보](security-creds.md) 단원을 참조하십시오.

**참고**  
IAM 사용자 중 한 명이 암호를 분실하거나 잊어버린 경우 IAM에서 검색할 수 *없습니다*. 설정에 따라 사용자나 관리자가 새 암호를 생성해야 합니다.

**Topics**
+ [

# IAM 사용자의 계정 암호 정책 설정
](id_credentials_passwords_account-policy.md)
+ [

# IAM 사용자 암호 관리
](id_credentials_passwords_admin-change-user.md)
+ [

# IAM 사용자에게 자신의 암호 변경 허용
](id_credentials_passwords_enable-user-change.md)
+ [

# IAM 사용자가 자신의 암호를 변경하는 방법
](id_credentials_passwords_user-change-own.md)

# IAM 사용자의 계정 암호 정책 설정
<a name="id_credentials_passwords_account-policy"></a>

AWS 계정에서 사용자 지정 암호 정책을 설정하여 IAM 사용자 암호의 복잡성 요건과 의무적인 교체 주기를 지정할 수 있습니다. 사용자 지정 암호 정책을 설정하지 않은 경우 IAM 사용자 암호는 기본 AWS 암호 정책을 충족해야 합니다. 자세한 내용은 [사용자 지정 암호 정책 옵션](#password-policy-details) 섹션을 참조하세요.

**Topics**
+ [

## 암호 정책 설정에 대한 규칙
](#password-policy-rules)
+ [

## 암호 정책을 설정하는 데 필요한 권한
](#default-policy-permissions-required)
+ [

## 기본 암호 정책
](#default-policy-details)
+ [

## 사용자 지정 암호 정책 옵션
](#password-policy-details)
+ [

## 암호 정책 설정(콘솔)
](#IAMPasswordPolicy)
+ [

## 암호 정책 변경(콘솔)
](#id_credentials_passwords_account-policy-section-1)
+ [

## 사용자 지정 암호 정책을 삭제하려면 다음을 수행하세요(콘솔).
](#id_credentials_passwords_account-policy-section-2)
+ [

## 암호 정책 설정(AWS CLI)
](#PasswordPolicy_CLI)
+ [

## 암호 정책 설정(AWS API)
](#PasswordPolicy_API)

## 암호 정책 설정에 대한 규칙
<a name="password-policy-rules"></a>

IAM 암호 정책은 AWS 계정 루트 사용자 암호 또는 IAM 사용자 액세스 키에 적용되지 않습니다. 암호가 만료되면 IAM 사용자는 AWS Management Console에 로그인할 수 없지만 액세스 키를 계속 사용할 수 있습니다.

암호 정책을 생성 또는 변경하더라도 대부분의 암호 정책 설정은 사용자가 다음에 자신의 암호를 변경할 때 적용됩니다. 하지만 일부 설정은 바로 적용됩니다. 예: 
+ 최소 길이 및 문자 유형 요건이 변경되는 경우 이러한 설정은 다음 번에 사용자가 자신의 암호를 변경할 때 적용됩니다. 기존 암호가 업데이트된 암호 정책을 따르지 않는 경우에도 사용자들은 기존 암호를 변경할 필요는 없습니다.
+ 암호 만료 기간을 설정하면 만료 기간이 바로 적용됩니다. 예를 들어 암호 만료 기간을 90일로 설정한 경우, 기존 암호가 90일 이상된 모든 IAM 사용자의 암호가 만료됩니다. 이러한 사용자는 다음에 로그인할 때 암호를 변경해야 합니다.

지정된 횟수의 로그인 시도가 실패한 후에는 계정에서 사용자를 잠그는 "잠금 정책'을 생성할 수 없습니다. 보안을 강화하려면 멀티 팩터 인증(MFA)과 함께 강력한 암호 정책을 사용하는 것이 좋습니다. MFA에 대한 자세한 내용은 [IAM의 AWS 다중 인증](id_credentials_mfa.md) 섹션을 참조하세요.

## 암호 정책을 설정하는 데 필요한 권한
<a name="default-policy-permissions-required"></a>

IAM 엔터티(사용자 또는 역할)가 계정 암호 정책을 보거나 편집하도록 허용하려면 권한을 구성해야 합니다. IAM 정책에 다음과 같은 암호 정책 작업을 포함할 수 있습니다.
+ `iam:GetAccountPasswordPolicy` - 엔터티가 계정의 암호 정책을 볼 수 있도록 허용합니다.
+ `iam:DeleteAccountPasswordPolicy` - 엔터티가 계정의 사용자 지정 암호 정책을 삭제하고 기본 암호 정책으로 되돌릴 수 있도록 허용합니다.
+ `iam:UpdateAccountPasswordPolicy` - 엔터티가 계정의 사용자 지정 암호 정책을 생성하거나 변경할 수 있도록 허용합니다.

다음 정책은 계정 암호 정책을 보고 편집할 수 있는 모든 액세스 권한을 허용합니다. 이 예제 JSON 정책 문서를 사용하여 IAM 정책을 생성하는 방법에 대해 자세히 알아보려면 [JSON 편집기를 사용하여 정책 생성](access_policies_create-console.md#access_policies_create-json-editor) 섹션을 참조하세요.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "FullAccessPasswordPolicy",
            "Effect": "Allow",
            "Action": [
                "iam:GetAccountPasswordPolicy",
                "iam:DeleteAccountPasswordPolicy",
                "iam:UpdateAccountPasswordPolicy"
            ],
            "Resource": "*"
        }
    ]
}
```

------

IAM 사용자가 자신의 암호를 변경하는 데 필요한 권한에 대한 자세한 내용은 [IAM 사용자에게 자신의 암호 변경 허용](id_credentials_passwords_enable-user-change.md) 섹션을 참조하세요.

## 기본 암호 정책
<a name="default-policy-details"></a>

관리자가 사용자 지정 암호 정책을 설정하지 않은 경우 IAM 사용자 암호는 기본 AWS 암호 정책을 충족해야 합니다.

기본 암호 정책은 다음 조건을 적용합니다.
+ 최소 8자부터 최대 128자의 암호 길이
+ 대문자, 소문자, 숫자 및 영숫자가 아닌 문자(`! @ # $ % ^ & * ( ) _ + - = [ ] { } | '`) 중에서 세 가지 이상의 문자 유형 혼합
+ AWS 계정 이름 또는 이메일 주소와 동일하지 않아야 함
+ 암호 만료 안 함

## 사용자 지정 암호 정책 옵션
<a name="password-policy-details"></a>

계정에 대한 사용자 지정 암호 정책을 구성할 때 다음 조건을 지정할 수 있습니다.
+ **암호 최소 길이** - 최소 6자, 최대 128자를 지정할 수 있습니다.
+ **암호 강도**-다음 확인란을 선택하여 IAM 사용자 암호의 강도를 정의할 수 있습니다.
  + 라틴 문자에서 하나 이상의 대문자 필요(A\$1Z)
  + 라틴 문자에서 하나 이상의 소문자 필요(a\$1z)
  + 1개 이상의 숫자 필수
  + 영숫자가 아닌 하나 이상의 문자 필요(`! @ # $ % ^ & * ( ) _ + - = [ ] { } | '`) 
+ **Turn on password expiration**(암호 만료 활성화) - IAM 사용자 암호가 설정된 후 유효한 기간(최소 1일부터 최대 1,095일)을 선택하여 지정할 수 있습니다. 예를 들어 만료일을 90일로 지정하면 모든 사용자에게 즉시 영향을 미칩니다. 암호를 변경한 지 90일 이상인 사용자의 경우, 콘솔에 로그인할 때 새 암호를 설정해야 합니다. 75\$189일이 지난 암호를 사용 중인 사용자는 암호 만료에 대한 AWS Management Console 경고를 수신합니다. 권한이 있는 IAM 사용자는 언제든지 자신의 암호를 변경할 수 있습니다. 새 암호를 설정하면 암호 만료 기간이 다시 시작됩니다. IAM 사용자는 한 번에 유효 암호 하나만 사용할 수 있습니다.
+ **암호 만료 시 관리자 재설정 필요(Password expiration requires administrator reset)** - 암호가 만료된 후 IAM 사용자가 AWS Management Console을 사용하여 자신의 암호를 업데이트하지 못하도록 하려면 이 옵션을 선택합니다. 이 옵션을 선택하기 전에 AWS 계정에 IAM 사용자 암호 재설정을 위한 관리자 권한을 가진 사용자가 2명 이상인지 확인해야 합니다. `iam:UpdateLoginProfile` 권한이 있는 관리자는 IAM 사용자 암호를 재설정할 수 있습니다. `iam:ChangePassword` 권한과 활성 액세스 키가 있는 IAM 사용자는 프로그래밍 방식으로 자신의 IAM 사용자 콘솔 암호를 재설정할 수 있습니다. 이 확인란의 선택을 취소하면 암호가 만료된 IAM 사용자는 AWS Management Console에 액세스하기 전에 새 암호를 설정해야 합니다.
+ **사용자 자신의 암호 변경 허용(Allow users to change their own password)** - 계정의 모든 IAM 사용자가 자신의 암호를 변경하도록 허용할 수 있습니다. 이렇게 하면 사용자에게 해당 사용자의 `iam:ChangePassword` 작업과 `iam:GetAccountPasswordPolicy` 작업에 대한 액세스 권한만 부여됩니다. 이 옵션은 각 사용자에게 권한 정책을 연결하지 않습니다. 대신, IAM은 모든 사용자에 대해 계정 수준에서 권한을 적용합니다. 또는 일부 사용자만 자신의 암호를 관리하도록 허용할 수 있습니다. 이렇게 하려면 이 확인란을 선택 취소합니다. 암호 관리 제한 정책의 사용에 대한 자세한 내용은 [IAM 사용자에게 자신의 암호 변경 허용](id_credentials_passwords_enable-user-change.md) 섹션을 참조하세요.
+ **암호 재사용 제한** - IAM 사용자가 지정된 수의 이전 암호를 재사용하지 못하도록 제한할 수 있습니다. 최소 1부터 최대 24개의 반복할 수 없는 이전 암호를 지정할 수 있습니다.

## 암호 정책 설정(콘솔)
<a name="IAMPasswordPolicy"></a>

AWS Management Console에서 사용자 지정 암호 정책을 생성, 변경 또는 삭제할 수 있습니다. 암호 정책 변경 사항은 이 정책 변경 후 생성된 새 IAM 사용자와 암호를 변경할 때의 기존 IAM 사용자를 대상으로 적용됩니다.

------
#### [ Console ]

1. *AWS 로그인 사용 설명서*의 [AWS에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) 항목에 설명된 대로 사용자 유형에 맞는 로그인 절차를 따르세요.

1. **IAM 콘솔 홈** 페이지의 왼쪽 탐색 창에서 쿼리를 **IAM 검색** 텍스트 상자에 입력합니다.

1. 탐색 창에서 **계정 설정(Account settings)**를 선택합니다.

1. **Password policy**(암호 정책) 섹션에서 **Edit**(편집)를 선택합니다.

1. **Custom**(사용자 지정)을 선택하여 사용자 지정 암호 정책을 사용합니다.

1. 암호 정책에 적용할 옵션을 선택하고 [**변경 사항 저장(Save changes)**]을 선택합니다.

1. **Set custom**(사용자 지정 설정)을 선택하여 사용자 지정 암호 정책의 설정을 확인합니다.

콘솔에 IAM 사용자의 암호 요구 사항이 업데이트되었음을 알리는 상태 메시지가 표시됩니다.

------

## 암호 정책 변경(콘솔)
<a name="id_credentials_passwords_account-policy-section-1"></a>

AWS Management Console에서 사용자 지정 암호 정책을 생성, 변경 또는 삭제할 수 있습니다. 암호 정책 변경 사항은 이 정책 변경 후 생성된 새 IAM 사용자와 암호를 변경할 때의 기존 IAM 사용자를 대상으로 적용됩니다.

------
#### [ Console ]

1. *AWS 로그인 사용 설명서*의 [AWS에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) 항목에 설명된 대로 사용자 유형에 맞는 로그인 절차를 따르세요.

1. **IAM 콘솔 홈** 페이지의 왼쪽 탐색 창에서 쿼리를 **IAM 검색** 텍스트 상자에 입력합니다.

1. 탐색 창에서 **계정 설정(Account settings)**를 선택합니다.

1. **Password policy**(암호 정책) 섹션에서 **Edit**(편집)를 선택합니다.

1. 암호 정책에 적용할 옵션을 선택하고 [**변경 사항 저장(Save changes)**]을 선택합니다.

1. **Set custom**(사용자 지정 설정)을 선택하여 사용자 지정 암호 정책의 설정을 확인합니다.

콘솔에 IAM 사용자의 암호 요구 사항이 업데이트되었음을 알리는 상태 메시지가 표시됩니다.

------

## 사용자 지정 암호 정책을 삭제하려면 다음을 수행하세요(콘솔).
<a name="id_credentials_passwords_account-policy-section-2"></a>

AWS Management Console에서 사용자 지정 암호 정책을 생성, 변경 또는 삭제할 수 있습니다. 암호 정책 변경 사항은 이 정책 변경 후 생성된 새 IAM 사용자와 암호를 변경할 때의 기존 IAM 사용자를 대상으로 적용됩니다.

------
#### [ Console ]

1. *AWS 로그인 사용 설명서*의 [AWS에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) 항목에 설명된 대로 사용자 유형에 맞는 로그인 절차를 따르세요.

1. **IAM 콘솔 홈** 페이지의 왼쪽 탐색 창에서 쿼리를 **IAM 검색** 텍스트 상자에 입력합니다.

1. 탐색 창에서 **계정 설정(Account settings)**를 선택합니다.

1. **Password policy**(암호 정책) 섹션에서 **Edit**(편집)를 선택합니다.

1. **IAM default**(IAM 기본값)를 선택하여 사용자 지정 암호 정책을 삭제하고 **Save changes**(변경 사항 저장)를 선택합니다.

1. **Set default**(기본값 설정)를 선택하여 IAM 기본 암호 정책의 설정을 확인합니다.

콘솔에 암호 정책이 IAM 기본값으로 설정되었음을 알리는 상태 메시지가 표시됩니다.

------

## 암호 정책 설정(AWS CLI)
<a name="PasswordPolicy_CLI"></a>

AWS Command Line Interface를 사용하여 암호 정책을 설정할 수 있습니다.

**AWS CLI에서 사용자 지정 계정 암호 정책을 관리하려면**  
다음 명령을 실행합니다.
+ 사용자 지정 암호 정책을 생성하거나 변경하려면: [https://docs.aws.amazon.com/cli/latest/reference/iam/update-account-password-policy.html](https://docs.aws.amazon.com/cli/latest/reference/iam/update-account-password-policy.html)
+ 암호 정책을 보려면: [https://docs.aws.amazon.com/cli/latest/reference/iam/get-account-password-policy.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-account-password-policy.html) 
+ 사용자 지정 암호 정책을 삭제하려면: [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-account-password-policy.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-account-password-policy.html) 

## 암호 정책 설정(AWS API)
<a name="PasswordPolicy_API"></a>

AWS API 작업을 사용하여 암호 정책을 설정할 수 있습니다.

**AWS API에서 사용자 지정 계정 암호 정책을 관리하려면**  
다음 연산을 호출합니다.
+ 사용자 지정 암호 정책을 생성하거나 변경하려면: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccountPasswordPolicy.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccountPasswordPolicy.html)
+ 암호 정책을 보려면: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccountPasswordPolicy.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccountPasswordPolicy.html) 
+ 사용자 지정 암호 정책을 삭제하려면: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccountPasswordPolicy.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccountPasswordPolicy.html) 

# IAM 사용자 암호 관리
<a name="id_credentials_passwords_admin-change-user"></a>

AWS Management Console을 사용하여 AWS 리소스를 작업하는 IAM 사용자가 로그인하려면 암호가 필요합니다. AWS 계정에 속한 IAM 사용자의 암호를 생성, 변경 또는 삭제할 수 있습니다.

사용자에게 암호를 할당한 후 사용자는 다음과 같은 계정의 로그인 URL을 사용하여 AWS Management Console에 로그인할 수 있습니다.

```
https://12-digit-AWS-account-ID or alias.signin.aws.amazon.com/console
```

IAM 사용자가 AWS Management Console에 로그인하는 방법에 대한 자세한 내용은 *AWS Sign-In 사용 설명서*의 [AWS에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)을 참조하세요.

사용자에게 암호가 있더라도 AWS 리소스에 액세스하려면 권한이 필요합니다. 기본적으로 사용자에게는 권한이 없습니다. 사용자에게 필요한 권한을 부여하려면 해당 사용자 또는 사용자가 속한 그룹에 정책을 할당합니다. 사용자 및 그룹 만들기에 대한 자세한 내용은 [IAM 자격 증명](id.md)을 참조하세요. 권한 설정을 위한 정책 사용에 대한 자세한 내용은 [IAM 사용자의 권한 변경](id_users_change-permissions.md)을 참조하세요.

자신의 암호를 변경할 권한을 사용자에게 부여할 수 있습니다. 자세한 내용은 [IAM 사용자에게 자신의 암호 변경 허용](id_credentials_passwords_enable-user-change.md) 섹션을 참조하세요. 사용자가 계정 로그인 페이지에 액세스하는 방법에 대한 자세한 내용은 *AWS Sign-In 사용 설명서*의 [AWS에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)을 참조하세요.

**Topics**
+ [

## IAM 사용자 암호 생성, 변경 또는 삭제(콘솔)
](#id_credentials_passwords_admin-change-user_console)

## IAM 사용자 암호 생성, 변경 또는 삭제(콘솔)
<a name="id_credentials_passwords_admin-change-user_console"></a>

AWS Management Console을 사용하여 IAM 사용자의 암호를 관리할 수 있습니다.

사용자의 액세스 요구 사항은 시간에 따라 변경될 수 있습니다. CLI 액세스 대상 사용자의 콘솔 액세스 권한을 활성화하거나, 자격 증명이 포함된 이메일을 수신하기 때문에 사용자의 암호를 변경하거나, 조직을 떠나거나 더 이상 AWS 액세스 권한이 필요하지 않아 사용자를 삭제해야 하는 경우가 있습니다.

### IAM 사용자 암호 생성(콘솔)
<a name="id_credentials_passwords_admin-change-user-section-1"></a>

이 절차에 따라 사용자 이름과 연결된 암호를 생성하여 사용자 콘솔에 액세스할 수 있습니다.

------
#### [ Console ]

1. *AWS 로그인 사용 설명서*의 [AWS에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) 항목에 설명된 대로 사용자 유형에 맞는 로그인 절차를 따르세요.

1. **IAM 콘솔 홈** 페이지의 왼쪽 탐색 창에서 쿼리를 **IAM 검색** 텍스트 상자에 입력합니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. 암호를 생성하려는 사용자의 이름을 선택합니다.

1. **보안 자격 증명** 탭을 선택한 다음 **콘솔 로그인**에서 **콘솔 액세스 활성화**를 선택합니다.

1. **콘솔 액세스 활성화** 대화 상자에서 **암호 재설정**을 선택하고, IAM이 암호를 자동으로 생성할지, 아니면 사용자 지정 암호를 생성할지 여부를 선택합니다.
   + IAM에서 암호를 자동으로 생성하려면 **자동 생성 암호(Autogenerated password)**를 선택합니다.
   + 사용자 지정 암호를 만들려면 **사용자 지정 암호(Custom password)**를 선택하고 암호를 입력합니다.
**참고**  
생성하는 암호는 계정의 [암호 정책](id_credentials_passwords_account-policy.md)을 충족해야 합니다.

1. 사용자가 로그인할 때 새 암호를 만들도록 요구하려면 **다음 로그인 시 암호 변경 필요**를 선택합니다.

1. 사용자가 새 암호를 즉시 사용하도록 요구하려면 **활성 콘솔 세션 취소**를 선택합니다. 이렇게 하면 IAM 사용자에게 인라인 정책이 연결되고, 이 정책은 자격 증명이 정책에 지정된 시간보다 오래된 경우 리소스에 대한 사용자 액세스를 거부합니다.

1. **암호 재설정** 선택

1. **콘솔 암호** 대화 상자에서 사용자의 새 암호를 활성화했음을 알려줍니다. 암호를 확인하고 사용자와 공유하려면 **콘솔 암호** 대화 상자에서 **표시**를 선택합니다. **.csv 파일 다운로드**를 선택하여 사용자의 자격 증명이 포함된 파일을 다운로드합니다.
**중요**  
이 단계를 완료한 후에는 보안상의 이유로 암호에 액세스할 수 없지만, 언제든지 새 암호를 만들 수 있습니다.

콘솔에 콘솔 액세스가 활성화되었음을 알리는 상태 메시지가 표시됩니다.

------

### IAM 사용자의 암호를 변경하려면(콘솔)
<a name="id_credentials_passwords_admin-change-user-section-2"></a>

이 절차에 따라 사용자 이름과 연결된 암호를 업데이트합니다.

------
#### [ Console ]

1. *AWS 로그인 사용 설명서*의 [AWS에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) 항목에 설명된 대로 사용자 유형에 맞는 로그인 절차를 따르세요.

1. **IAM 콘솔 홈** 페이지의 왼쪽 탐색 창에서 쿼리를 **IAM 검색** 텍스트 상자에 입력합니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. 암호를 변경할 사용자의 이름을 선택합니다.

1. **보안 자격 증명** 탭을 선택한 다음 **콘솔 로그인**에서 **콘솔 액세스 관리**를 선택합니다.

1. **콘솔 액세스 관리** 대화 상자에서 **암호 재설정**을 선택하고, IAM이 암호를 자동으로 생성할지, 아니면 사용자 지정 암호를 생성할지 여부를 선택합니다.
   + IAM에서 암호를 자동으로 생성하려면 **자동 생성 암호(Autogenerated password)**를 선택합니다.
   + 사용자 지정 암호를 만들려면 **사용자 지정 암호(Custom password)**를 선택하고 암호를 입력합니다.
**참고**  
생성하는 암호는 계정의 [암호 정책](id_credentials_passwords_account-policy.md)을 충족해야 합니다.

1. 사용자가 로그인할 때 새 암호를 만들도록 요구하려면 **다음 로그인 시 암호 변경 필요**를 선택합니다.

1. 사용자가 새 암호를 즉시 사용하도록 요구하려면 **활성 콘솔 세션 취소**를 선택합니다. 이렇게 하면 IAM 사용자에게 인라인 정책이 연결되고, 이 정책은 자격 증명이 정책에 지정된 시간보다 오래된 경우 리소스에 대한 사용자 액세스를 거부합니다.

1. **암호 재설정** 선택

1. **콘솔 암호** 대화 상자에서 사용자의 새 암호를 활성화했음을 알려줍니다. 암호를 확인하고 사용자와 공유하려면 **콘솔 암호** 대화 상자에서 **표시**를 선택합니다. **.csv 파일 다운로드**를 선택하여 사용자의 자격 증명이 포함된 파일을 다운로드합니다.
**중요**  
이 단계를 완료한 후에는 보안상의 이유로 암호에 액세스할 수 없지만, 언제든지 새 암호를 만들 수 있습니다.

콘솔에 콘솔 액세스가 업데이트되었음을 알리는 상태 메시지가 표시됩니다.

------

### IAM 사용자 암호를 삭제(비활성화)하려면(콘솔)
<a name="id_credentials_passwords_admin-change-user-section-3"></a>

이 절차에 따라 사용자 이름과 연결된 암호를 삭제하여 사용자의 콘솔 액세스 권한을 제거합니다.

**중요**  
사용자의 암호를 제거하여 IAM 사용자가 AWS Management Console에 액세스하지 못하도록 할 수 있습니다. 그러면 사용자는 자신의 로그인 보안 인증을 사용해 AWS Management Console에 로그인할 수 없습니다. 그렇더라도 사용자의 권한이 변경되거나 위임된 역할을 사용하여 콘솔에 액세스하지 못하게 되지는 않습니다. 사용자에게 활성 액세스 키가 있다면 해당 키는 계속 작동하고 AWS CLI, Tools for Windows PowerShell 또는 AWS API 또는 AWS Console Mobile Application을 통해 액세스를 허용합니다.

------
#### [ Console ]

1. *AWS 로그인 사용 설명서*의 [AWS에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) 항목에 설명된 대로 사용자 유형에 맞는 로그인 절차를 따르세요.

1. **IAM 콘솔 홈** 페이지의 왼쪽 탐색 창에서 쿼리를 **IAM 검색** 텍스트 상자에 입력합니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. 암호를 삭제할 사용자의 이름을 선택합니다.

1. **보안 자격 증명** 탭을 선택한 다음 **콘솔 로그인**에서 **콘솔 액세스 관리**를 선택합니다.

1. 사용자가 콘솔 사용을 즉시 중지하도록 요구하려면 **활성 콘솔 세션 취소**를 선택합니다. 이렇게 하면 IAM 사용자에게 인라인 정책이 연결되고, 이 정책은 자격 증명이 정책에 지정된 시간보다 오래된 경우 리소스에 대한 사용자 액세스를 거부합니다.

1. **액세스 비활성화**를 선택합니다.

콘솔에 콘솔 액세스가 비활성화되었음을 알리는 상태 메시지가 표시됩니다.

------

### IAM 사용자 암호 생성, 변경 또는 삭제(AWS CLI)
<a name="Using_ManagingPasswordsCLIAPI"></a>

AWS CLI API를 이용해 IAM 사용자의 암호를 관리할 수 있습니다.

**암호를 생성하려면(AWS CLI)**

1. (선택 사항) 사용자에게 암호가 있는지 확인하려면 [aws iam get-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/get-login-profile.html) 명령을 실행합니다.

1. 암호를 생성하려면 [aws iam create-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/create-login-profile.html) 명령을 실행합니다.

**사용자의 암호를 변경하려면(AWS CLI)**

1. (선택 사항) 사용자에게 암호가 있는지 확인하려면 [aws iam get-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/get-login-profile.html) 명령을 실행합니다.

1. 암호를 변경하려면 [aws iam update-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/update-login-profile.html) 명령을 실행합니다.

**사용자의 암호를 삭제(비활성화)하려면(AWS CLI)**

1. (선택 사항) 사용자에게 암호가 있는지 확인하려면 [aws iam get-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/get-login-profile.html) 명령을 실행합니다.

1. (선택 사항) 사용자의 암호가 마지막으로 사용된 시간을 확인하려면 [aws iam get-user](https://docs.aws.amazon.com/cli/latest/reference/iam/get-user.html) 명령을 실행합니다.

1. 암호를 삭제하려면 [aws iam delete-login-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-login-profile.html) 명령을 실행합니다.

**중요**  
사용자의 암호를 삭제하면 해당 사용자가 더 이상 AWS Management Console에 로그인할 수 없습니다. 사용자에게 활성 액세스 키가 있다면 해당 키는 계속 작동하고 AWS CLI, Tools for Windows PowerShell 또는 AWS API 함수 호출을 통해 액세스를 허용합니다. AWS CLI, Tools for Windows PowerShell 또는 AWS API를 사용하여 AWS 계정에서 사용자를 삭제하는 경우 먼저 이 작업을 사용하여 암호를 삭제해야 합니다. 자세한 내용은 [IAM 사용자 삭제(AWS CLI)](id_users_remove.md#id_users_deleting_cli) 섹션을 참조하세요.

**지정된 시간 이전에 사용자의 활성 콘솔 세션을 취소하려면(AWS CLI)**

1. 지정된 시간 전에 IAM 사용자의 활성 콘솔 세션을 취소하는 인라인 정책을 내장하려면 다음 인라인 정책을 사용하고 [aws iam put-user-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-user-policy.html) 명령을 실행합니다.

   이 인라인 정책은 모든 권한을 거부하며 `aws:TokenIssueTime` 조건 키를 포함합니다. 인라인 정책의 `Condition` 요소에 지정된 시간이 지나기 전에 사용자의 활성 콘솔 세션을 취소합니다. `aws:TokenIssueTime` 조건 키 값을 사용자의 고유한 값으로 교체합니다.

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": {
       "Effect": "Deny",
       "Action": "*",
       "Resource": "*",
       "Condition": {
         "DateLessThan": {
           "aws:TokenIssueTime": "2014-05-07T23:47:00Z"
         }
       }
     }
   }
   ```

------

1. (선택 사항) IAM 사용자에게 포함된 인라인 정책의 이름을 나열하려면 [aws iam list-user-policies](https://docs.aws.amazon.com/cli/latest/reference/iam/list-user-policies.html) 명령을 실행하세요.

1. (선택 사항) IAM 사용자에 포함된 명명된 인라인 정책을 보려면 [aws iam get-user-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/get-user-policy.html) 명령을 실행합니다.

### IAM 사용자 암호 생성, 변경 또는 삭제(AWS API)
<a name="Using_ManagingPasswordsAPI"></a>

AWS API를 이용해 IAM 사용자의 암호를 관리할 수 있습니다.

**암호를 생성하려면(AWS API)**

1. (선택 사항) 사용자에게 암호가 있는지 확인하려면 [GetLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetLoginProfile.html) 연산을 호출합니다.

1. 암호를 생성하려면 [CreateLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateLoginProfile.html) 연산을 호출합니다.

**사용자의 암호를 변경하려면(AWS API)**

1. (선택 사항) 사용자에게 암호가 있는지 확인하려면 [GetLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetLoginProfile.html) 연산을 호출합니다.

1. 암호를 변경하려면 [UpdateLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateLoginProfile.html) 연산을 호출합니다.

**사용자의 암호를 삭제(비활성화)하려면(AWS API)**

1. (선택 사항) 사용자에게 암호가 있는지 확인하려면 [GetLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetLoginProfile.html) 명령을 실행합니다.

1. (선택 사항) 사용자의 암호가 마지막으로 사용된 시간을 확인하려면 [GetUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetUser.html) 명령을 실행합니다.

1. 암호를 삭제하려면 [DeleteLoginProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteLoginProfile.html) 명령을 실행합니다.

**중요**  
사용자의 암호를 삭제하면 해당 사용자가 더 이상 AWS Management Console에 로그인할 수 없습니다. 사용자에게 활성 액세스 키가 있다면 해당 키는 계속 작동하고 AWS CLI, Tools for Windows PowerShell 또는 AWS API 함수 호출을 통해 액세스를 허용합니다. AWS CLI, Tools for Windows PowerShell 또는 AWS API를 사용하여 AWS 계정에서 사용자를 삭제하는 경우 먼저 이 작업을 사용하여 암호를 삭제해야 합니다. 자세한 내용은 [IAM 사용자 삭제(AWS CLI)](id_users_remove.md#id_users_deleting_cli) 섹션을 참조하세요.

**지정된 시간 이전에 사용자의 활성 콘솔 세션을 취소하려면(AWS API)**

1. 지정된 시간 전에 IAM 사용자의 활성 콘솔 세션을 취소하는 인라인 정책을 내장하려면 다음 인라인 정책을 사용하고 [PutUserPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutUserPolicy.html) 명령을 실행하세요.

   이 인라인 정책은 모든 권한을 거부하며 `aws:TokenIssueTime` 조건 키를 포함합니다. 인라인 정책의 `Condition` 요소에 지정된 시간이 지나기 전에 사용자의 활성 콘솔 세션을 취소합니다. `aws:TokenIssueTime` 조건 키 값을 사용자의 고유한 값으로 교체합니다.

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": {
       "Effect": "Deny",
       "Action": "*",
       "Resource": "*",
       "Condition": {
         "DateLessThan": {
           "aws:TokenIssueTime": "2014-05-07T23:47:00Z"
         }
       }
     }
   }
   ```

------

1. (선택 사항) IAM 사용자에 포함된 인라인 정책의 이름을 나열하려면 [ListUserPolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListUserPolicies.html) 명령을 실행합니다.

1. (선택 사항) IAM 사용자에 포함된 명명된 인라인 정책을 보려면 [GetUserPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetUserPolicy.html) 명령을 실행합니다.

# IAM 사용자에게 자신의 암호 변경 허용
<a name="id_credentials_passwords_enable-user-change"></a>

**참고**  
페더레이션형 ID를 가진 사용자는 ID 제공업체가 정의한 프로세스를 사용하여 암호를 변경합니다. [가장 좋은 방법](best-practices.md)은 인간 사용자가 ID 제공업체와의 페더레이션을 사용하여 임시 보안 인증으로 AWS에 액세스하도록 하는 것입니다.

IAM 사용자에게 AWS Management Console에 로그인할 때 사용하는 자신의 암호를 변경할 권한을 부여할 수 있습니다. 이 작업을 두 가지 방법으로 수행할 수 있습니다.
+ [계정의 모든 IAM 사용자에게 자신의 암호 변경을 허용합니다](#proc_letalluserschangepassword).
+ [선택된 IAM 사용자에게만 자신의 암호 변경을 허용합니다](#proc_letselectuserschangepassword). 이 시나리오에서는 모든 사용자의 암호 변경 옵션을 비활성화한 후 IAM 정책을 사용하여 일부 사용자에게만 자신의 암호를 변경할 수 있는 권한을 부여합니다. 이 방법을 사용하면 사용자가 자신의 암호를 변경할 수 있으며 필요에 따라 액세스 키와 같은 다른 자격 증명을 변경할 수 있습니다.

**중요**  
IAM 사용자에게 강력한 암호를 생성할 것을 요구하는 [사용자 지정 암호 정책을 설정](id_credentials_passwords_account-policy.md)하는 것이 좋습니다.

## 모든 IAM 사용자에게 자신의 암호 변경을 허용하려면
<a name="proc_letalluserschangepassword"></a>

------
#### [ Console ]

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 [**계정 설정(Account settings)**]을 클릭합니다.

1. **Password policy**(암호 정책) 섹션에서 **Edit**(편집)를 선택합니다.

1. **Custom**(사용자 지정)을 선택하여 사용자 지정 암호 정책을 사용합니다.

1. **사용자 자신의 암호 변경 허용(Allow users to change their own password)**을 선택한 다음 **변경 사항 저장(Save changes)**을 선택합니다. 이렇게 하면 계정의 모든 사용자에게 해당 사용자의 `iam:ChangePassword` 작업과 `iam:GetAccountPasswordPolicy` 작업에 대한 액세스 권한만 허용됩니다.

1. 사용자에게 암호 변경에 대한 다음 지침을 제공합니다. [IAM 사용자가 자신의 암호를 변경하는 방법](id_credentials_passwords_user-change-own.md).

------
#### [ AWS CLI ]

다음 명령 실행:
+ `[aws iam update-account-password-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/update-account-password-policy.html)`

------
#### [ API ]

AWS Management Console 로그인 페이지 URL의 별칭을 만들려면 다음 연산을 호출합니다.
+ `[UpdateAccountPasswordPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccountPasswordPolicy.html)` 

------

## 선택된 IAM 사용자에게 자신의 암호 변경을 허용하려면
<a name="proc_letselectuserschangepassword"></a>

------
#### [ Console ]

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 [**계정 설정(Account settings)**]을 클릭합니다.

1. [**암호 정책(Password policy)**] 섹션에서 [**사용자 자신의 암호 변경 허용(Allow users to change their own password)**] 확인란이 선택 취소되어 있는지 확인합니다. 이 확인란을 선택하면 모든 사용자가 직접 암호를 변경할 수 있습니다. (위 절차 참조).

1. 암호 변경을 허용할 사용자가 아직 없다면 사용자를 만듭니다. 자세한 내용은 섹션을 참조하세요[AWS 계정에서 IAM 사용자 생성](id_users_create.md) 

1. (선택 사항) 직접 암호를 변경하게 할 IAM 사용자 그룹을 만든 다음 앞 단계에서 만든 사용자를 그룹에 추가합니다. 자세한 내용은 [IAM 사용자 그룹](id_groups.md)을 참조하세요.

1. 그룹에 다음 정책을 할당합니다. 자세한 내용은 [IAM 정책 관리](access_policies_manage.md) 섹션을 참조하세요.

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Allow",
         "Action": "iam:GetAccountPasswordPolicy",
         "Resource": "*"
       },
       {
         "Effect": "Allow",
         "Action": "iam:ChangePassword",
         "Resource": "arn:aws:iam::*:user/${aws:username}"
       }
     ]
   }
   ```

------

   이 정책은 [암호 변경](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ChangePassword.html) 작업에 대한 액세스 권한을 부여하여 사용자가 콘솔, AWS CLI, Tools for Windows PowerShell 또는 API로부터 본인의 암호만을 변경할 수 있게 합니다. 또한 사용자가 현재 암호 정책을 볼 수 있도록 [GetAccountPasswordPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccountPasswordPolicy.html) 작업에 대한 액세스 권한도 부여합니다. 이 권한은 사용자가 [**암호 변경(Change password)**] 페이지에서 계정 암호를 보는 데 필요합니다. 사용자가 현재 암호 정책을 읽고 변경된 암호가 정책의 요건을 충족하는지 확인할 수 있도록 허용해야 합니다.

1. 사용자에게 암호 변경에 대한 다음 지침을 제공합니다. [IAM 사용자가 자신의 암호를 변경하는 방법](id_credentials_passwords_user-change-own.md).

------

### 자세한 정보
<a name="HowToPwdIAMUser-moreinfo"></a>

자격 증명 관리에 대한 자세한 내용은 다음 주제를 참조하세요.
+ [IAM 사용자에게 자신의 암호 변경 허용](#id_credentials_passwords_enable-user-change) 
+ [AWS의 사용자 암호](id_credentials_passwords.md)
+ [IAM 사용자의 계정 암호 정책 설정](id_credentials_passwords_account-policy.md)
+ [IAM 정책 관리](access_policies_manage.md)
+ [IAM 사용자가 자신의 암호를 변경하는 방법](id_credentials_passwords_user-change-own.md)

# IAM 사용자가 자신의 암호를 변경하는 방법
<a name="id_credentials_passwords_user-change-own"></a>

자신의 IAM 사용자 암호를 변경할 수 있는 권한이 부여된 경우 AWS Management Console의 특별 페이지를 사용하여 이 작업을 수행할 수 있습니다. AWS CLI 또는 AWS API도 사용할 수 있습니다.

**Topics**
+ [

## 필요한 권한
](#change-own-passwords-permissions-required)
+ [

## IAM 사용자가 자신의 암호를 변경하는 방법(콘솔)
](#ManagingUserPwdSelf-Console)
+ [

## IAM 사용자가 자신의 암호를 변경하는 방법(AWS CLI 또는 AWS API)
](#ManagingUserPwdSelf-CLIAPI)

## 필요한 권한
<a name="change-own-passwords-permissions-required"></a>

자신의 IAM 사용자에 대한 암호를 변경하려면 [AWS: IAM 사용자가 보안 인증 페이지에서 자신의 콘솔 암호를 변경할 수 있도록 허용](reference_policies_examples_aws_my-sec-creds-self-manage-password-only.md) 정책에 따른 권한이 있어야 합니다.

## IAM 사용자가 자신의 암호를 변경하는 방법(콘솔)
<a name="ManagingUserPwdSelf-Console"></a>

다음 절차는 IAM 사용자가 AWS Management Console을 사용하여 자신의 암호를 변경하는 방법을 설명합니다.

**자신의 IAM 사용자 암호를 변경하려면(콘솔)**

1. AWS 계정 ID나 계정 별칭, IAM 사용자 이름 및 암호를 사용하여 [IAM 콘솔](https://console.aws.amazon.com/iam)에 로그인합니다.
**참고**  
사용자 편의를 위해 AWS 로그인 페이지는 브라우저 쿠키를 사용하여 IAM 사용자 이름 및 계정 정보를 기억합니다. 이전에 다른 사용자로 로그인한 경우 페이지 하단 근처의 **다른 계정에 로그인(Sign in to a different account)**을 선택하여 기본 로그인 페이지로 돌아갑니다. 여기서 AWS 계정 ID 또는 계정 별칭을 입력하면 계정의 IAM 사용자 로그인 페이지로 리디렉션됩니다.

   AWS 계정 ID를 받으려면 관리자에게 문의하세요.

1. 오른쪽 상단의 탐색 모음에서 사용자 이름을 선택한 다음 **Security credentials**(보안 자격 증명)를 선택합니다.  
![\[AWS Management Console 보안 자격 증명 링크\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. **AWS IAM 자격 증명** 탭에서 **암호 업데이트**를 선택합니다.

1. **Current password(현재 암호)**에 현재 암호를 입력합니다. **New password(새 암호)** 및 **Confirm new password(새 암호 확인)**에 새 암호를 입력합니다. 그런 다음 **암호 업데이트**를 선택합니다.
**참고**  
새 암호는 계정 암호 정책의 요건을 따라야 합니다. 자세한 내용은 [IAM 사용자의 계정 암호 정책 설정](id_credentials_passwords_account-policy.md) 섹션을 참조하세요.

## IAM 사용자가 자신의 암호를 변경하는 방법(AWS CLI 또는 AWS API)
<a name="ManagingUserPwdSelf-CLIAPI"></a>

다음 절차는 IAM 사용자가 AWS CLI 또는 AWS API를 사용하여 자신의 암호를 변경하는 방법을 설명합니다.

**자신의 IAM 암호를 변경하려면 다음을 사용하세요.**
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/change-password.html](https://docs.aws.amazon.com/cli/latest/reference/iam/change-password.html)
+ AWS API: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ChangePassword.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ChangePassword.html)

# IAM 사용자의 액세스 키 관리
<a name="id_credentials_access-keys"></a>

**중요**  
[모범 사례](best-practices.md)는 액세스 키와 같은 장기 보안 인증을 생성하는 대신 임시 보안 인증(예: IAM 역할)을 사용하는 것입니다. 액세스 키를 생성하기 전에 [장기 액세스 키의 대안](security-creds-programmatic-access.md#security-creds-alternatives-to-long-term-access-keys)을 검토합니다.

액세스 키는 IAM 사용자 또는 AWS 계정 루트 사용자에 대한 장기 보안 인증입니다. 액세스 키를 사용하여 AWS CLI 또는 AWS API에 대한 프로그래밍 요청에 서명할 수 있습니다(직접 또는 AWS SDK를 사용하여). 자세한 내용은 [AWS 보안 자격 증명을 사용한 프로그래밍 방식 액세스](security-creds-programmatic-access.md) 섹션을 참조하세요.

액세스 키는 액세스 키 ID(예: `AKIAIOSFODNN7EXAMPLE`)와 비밀 액세스 키(예: `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY`)의 두 가지 부분으로 구성됩니다. 액세스 키 ID와 보안 액세스 키를 함께 사용하여 요청을 인증해야 합니다.



액세스 키 페어를 생성할 때는 액세스 키 ID와 보안 액세스 키를 안전한 위치에 저장합니다. 시크릿 액세스 키는 생성할 때만 가져올 수 있습니다. 보안 액세스 키를 분실한 경우 액세스 키를 삭제하고 새 키를 생성해야 합니다. 자세한 지침은 [액세스 키 업데이트](id-credentials-access-keys-update.md) 섹션을 참조하세요.

사용자당 최대 2개의 액세스 키를 가질 수 있습니다.

**중요**  
액세스 키가 있는 IAM 사용자는 계정 보안 위험이 있습니다. 액세스 키를 안전하게 관리하세요. [계정 식별자를 찾는 데](https://docs.aws.amazon.com/general/latest/gr/acct-identifiers.html) 도움이 되더라도 액세스 키를 권한 없는 당사자에게 제공하지 마세요. 이로 인해 다른 사람에게 계정에 대한 영구 액세스를 제공하게 될 수 있습니다.  
다음은 액세스 키를 사용할 때 알아야 할 사항입니다.  
**금지 사항**. 액세스 키를 생성할 때는 계정의 루트 자격 증명을 사용하면 안 됩니다.
**금지 사항.** 애플리케이션 파일에 액세스 키나 자격 증명 정보를 넣으면 안 됩니다.
**금지 사항.** 프로젝트 영역에 액세스 키나 자격 증명 정보가 포함된 파일을 포함하면 안 됩니다.
공유 AWS 자격 증명 파일에 저장된 액세스 키 또는 자격 증명 정보는 일반 텍스트로 저장됩니다.

## 모니터링 권장 사항
<a name="monitor-access-keys"></a>

액세스 키 생성 후
+ AWS CloudTrail을 사용하여 액세스 키 사용량을 모니터링하고 무단 액세스 시도를 탐지합니다. 자세한 내용은 [AWS CloudTrail을 사용하여 IAM 및 AWS STS API 호출 로깅](cloudtrail-integration.md) 섹션을 참조하세요.
+ 악의적인 활동을 탐지하는 데 도움이 되도록 거부된 액세스 시도에 대해 관리자에게 알리도록 CloudWatch 경보를 설정합니다. 자세한 내용은 [Amazon CloudWatch 사용 설명서](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/)를 참조하세요.
+ 필요에 따라 액세스 키를 정기적으로 검토, 업데이트 및 삭제합니다.

다음 주제에서는 액세스 키와 관련된 관리 작업에 대한 자세한 정보를 제공합니다.

**Topics**
+ [

## 모니터링 권장 사항
](#monitor-access-keys)
+ [

# IAM 사용자에게 인라인 정책을 연결하여 액세스 키 사용 제어
](access-keys_inline-policy.md)
+ [

# 액세스 키를 관리하는 데 필요한 권한
](access-keys_required-permissions.md)
+ [

# IAM 사용자가 자체 액세스 키를 관리하는 방법
](access-key-self-managed.md)
+ [

# IAM 관리자가 IAM 사용자 액세스 키를 관리하는 방법
](access-keys-admin-managed.md)
+ [

# 액세스 키 업데이트
](id-credentials-access-keys-update.md)
+ [

# 액세스 키 보안
](securing_access-keys.md)

# IAM 사용자에게 인라인 정책을 연결하여 액세스 키 사용 제어
<a name="access-keys_inline-policy"></a>

[워크로드에서 IAM 역할과 함께 임시 보안 인증을 사용](best-practices.md#bp-workloads-use-roles)하여 AWS에 액세스하도록 하는 것이 좋습니다. 액세스 키가 있는 IAM 사용자에게는 최소 권한 액세스가 할당되어야 하며 [다중 인증(MFA)](id_credentials_mfa.md)이 활성화되어야 합니다. IAM 역할 위임하기에 대한 자세한 내용은 [역할 수임 방법](id_roles_manage-assume.md) 섹션을 참조하세요.

그러나 서비스 자동화 또는 기타 단기 사용 사례에 대한 개념 증명 테스트를 생성하고 액세스 키가 있는 IAM 사용자를 사용하여 워크로드를 실행하기로 선택하는 경우 [정책 조건을 사용하여 IAM 사용자 자격 증명의 액세스를 추가로 제한](best-practices.md#use-policy-conditions)하는 것이 좋습니다.

이 경우 지정된 시간 이후에 자격 증명이 만료되는 시간 제한 정책을 생성하거나, 보안 네트워크에서 워크로드를 실행하는 경우 IP 제한 정책을 사용할 수 있습니다.

이 두 사용 사례 모두 액세스 키가 있는 IAM 사용자에게 연결된 인라인 정책을 사용할 수 있습니다.

**IAM 사용자에 대한 시간 제한 정책을 구성하는 방법**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **사용자**를 선택한 다음, 단기 사용 사례를 위한 사용자의 이름을 선택합니다. 아직 사용자를 생성하지 않은 경우 지금 [사용자를 생성](getting-started-workloads.md)할 수 있습니다.

1. 사용자 **세부 정보** 페이지에서 **권한** 탭을 선택합니다.

1. **권한 추가**를 선택한 다음 **인라인 정책 생성**을 선택합니다.

1. **정책 편집기** 섹션에서 **JSON**을 선택하여 JSON 편집기를 표시합니다.

1. JSON 편집기에서 `aws:CurrentTime` 타임스탬프 값을 원하는 만료 날짜 및 시간으로 바꾸어 다음 정책을 입력합니다.

------
#### [ JSON ]

****  

   ```
   {
   "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Deny",
         "Action": "*",
         "Resource": "*",
         "Condition": {
         "DateGreaterThan": {
         "aws:CurrentTime": "2025-03-01T00:12:00Z"
           }
         }
       }
     ]
   }
   ```

------

   이 정책은 `Deny` 효과를 사용하여 지정된 날짜 이후의 모든 리소스에 대한 모든 작업을 제한합니다. `DateGreaterThan` 조건은 현재 시간을 설정된 타임스탬프와 비교합니다.

1. **다음**을 선택하여 **검토 및 생성** 페이지로 이동합니다. **정책** 세부 정보의 **정책 이름**에 정책의 이름을 입력한 다음 **정책 생성**을 선택합니다.

정책이 생성되면 사용자의 **권한** 탭에 표시됩니다. 현재 시간이 정책에 지정된 시간보다 크거나 같으면 사용자는 더 이상 AWS 리소스에 액세스할 수 없습니다. 워크로드 개발자에게 이러한 액세스 키에 지정된 만료 날짜에 대해 알려야 합니다.

**IAM 사용자에 대한 IP 제한 정책을 구성하는 방법**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **사용자**를 선택한 다음 보안 네트워크에서 워크로드를 실행할 사용자를 선택합니다. 아직 사용자를 생성하지 않은 경우 지금 [사용자를 생성](getting-started-workloads.md)할 수 있습니다.

1. 사용자 **세부 정보** 페이지에서 **권한** 탭을 선택합니다.

1. **권한 추가**를 선택한 다음 **인라인 정책 생성**을 선택합니다.

1. **정책 편집기** 섹션에서 **JSON**을 선택하여 JSON 편집기를 표시합니다.

1. 다음 IAM 정책을 JSON 편집기에 복사하고 퍼블릭 IPv4 또는 IPv6 주소 또는 범위를 필요에 따라 변경합니다. [https://checkip.amazonaws.com/](https://checkip.amazonaws.com/)을 사용하여 현재 퍼블릭 IP 주소를 확인할 수 있습니다. 슬래시 표기법을 사용하여 개별 IP 주소 또는 IP 주소 범위를 지정할 수 있습니다. 자세한 내용은 [aws:SourceIp](reference_policies_condition-keys.md#condition-keys-sourceip) 섹션을 참조하세요.
**참고**  
IP 주소는 VPN 또는 프록시 서버에서 난독화되지 않아야 합니다.

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Sid":"IpRestrictionIAMPolicyForIAMUser",
         "Effect": "Deny",
         "Action": "*",
         "Resource": "*",
         "Condition": {
           "NotIpAddress": {
             "aws:SourceIp": [
               "203.0.113.0/24",
               "2001:DB8:1234:5678::/64",
               "203.0.114.1"
             ]
           },
           "BoolIfExists": {
             "aws:ViaAWSService": "false"
           }
         }
       }
     ]
   }
   ```

------

   이 정책 예제에서는 요청이 네트워크(CIDR 표기법으로 지정) ‘203.0.113.0/24’, ‘2001:DB8:1234:5678::/64’ 또는 특정 IP 주소 ‘203.0.114.1’에서 시작되지 않는 한 이 정책이 적용된 IAM 사용자의 액세스 키 사용을 거부합니다.

1. **다음**을 선택하여 **검토 및 생성** 페이지로 이동합니다. **정책** 세부 정보의 **정책 이름**에 정책의 이름을 입력한 다음 **정책 생성**을 선택합니다.

정책이 생성되면 사용자의 **권한** 탭에 표시됩니다.

이 정책을 AWS Organizations의 여러 AWS 계정에 서비스 제어 정책(SCP)으로 적용할 수도 있습니다. 이 정책 설명을 이 SCP가 적용되는 AWS 계정 내의 IAM 사용자에게만 적용하려면 `aws:PrincipalArn` 추가 조건을 사용하는 것이 좋습니다. 다음 정책에는 해당 업데이트가 포함됩니다.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "IpRestrictionServiceControlPolicyForIAMUsers",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": [
            "203.0.113.0/24",
            "2001:DB8:1234:5678::/64",
            "203.0.114.1"
          ]
        },
        "BoolIfExists": {
          "aws:ViaAWSService": "false"
        },
        "ArnLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:user/*"
        }
      }
    }
  ]
}
```

------

# 액세스 키를 관리하는 데 필요한 권한
<a name="access-keys_required-permissions"></a>

**참고**  
`iam:TagUser`은 액세스 키에 설명을 추가하고 편집할 수 있는 선택적 권한입니다. 자세한 내용은 [IAM 사용자 태깅](id_tags_users.md) 섹션을 참조하세요.

자신의 IAM 사용자에 대한 액세스 키를 생성하려면 다음 정책에 따른 권한이 있어야 합니다.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "CreateOwnAccessKeys",
            "Effect": "Allow",
            "Action": [
                "iam:CreateAccessKey",
                "iam:GetUser",
                "iam:ListAccessKeys",
                "iam:TagUser"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        }
    ]
}
```

------

자신의 IAM 사용자에 대한 액세스 키를 업데이트하려면 다음 정책에 따른 권한이 있어야 합니다.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "ManageOwnAccessKeys",
            "Effect": "Allow",
            "Action": [
                "iam:CreateAccessKey",
                "iam:DeleteAccessKey",
                "iam:GetAccessKeyLastUsed",
                "iam:GetUser",
                "iam:ListAccessKeys",
                "iam:UpdateAccessKey",
                "iam:TagUser"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        }
    ]
}
```

------

# IAM 사용자가 자체 액세스 키를 관리하는 방법
<a name="access-key-self-managed"></a>

IAM 관리자는 [액세스 키를 관리하는 데 필요한 권한](access-keys_required-permissions.md)에 설명된 정책을 연결하여 IAM 사용자에게 액세스 키를 자체 관리할 수 있는 권한을 부여할 수 있습니다.

이러한 권한을 통해 IAM 사용자는 다음 절차를 사용하여 사용자 이름과 연결된 액세스 키를 생성, 활성화, 비활성화 및 삭제할 수 있습니다.

**Topics**
+ [

## 자체 액세스 키 생성(콘솔)
](#Using_CreateAccessKey)
+ [

## 액세스 키 비활성화(콘솔)
](#deactivate-access-key-seccreds)
+ [

## 액세스 키 활성화(콘솔)
](#activate-access-key-seccreds)
+ [

## 액세스 키 삭제(콘솔)
](#delete-access-key-seccreds)

## 자체 액세스 키 생성(콘솔)
<a name="Using_CreateAccessKey"></a>

적절한 권한이 부여된 경우 AWS Management Console을 사용하여 자체 액세스 키를 생성할 수 있습니다.

**자체 액세스 키 생성(콘솔)**

1. AWS 계정 ID나 계정 별칭, IAM 사용자 이름 및 암호를 사용하여 [IAM 콘솔](https://console.aws.amazon.com/iam)에 로그인합니다.
**참고**  
사용자 편의를 위해 AWS 로그인 페이지는 브라우저 쿠키를 사용하여 IAM 사용자 이름 및 계정 정보를 기억합니다. 이전에 다른 사용자로 로그인한 경우 페이지 하단 근처의 **다른 계정에 로그인(Sign in to a different account)**을 선택하여 기본 로그인 페이지로 돌아갑니다. 여기서 AWS 계정 ID 또는 계정 별칭을 입력하면 계정의 IAM 사용자 로그인 페이지로 리디렉션됩니다.

   AWS 계정 ID를 받으려면 관리자에게 문의하세요.

1. 오른쪽 상단의 탐색 모음에서 사용자 이름을 선택한 다음 **Security credentials**(보안 자격 증명)를 선택합니다.  
![\[AWS Management Console 보안 자격 증명 링크\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. **액세스 키** 섹션에서 **액세스 키 생성**을 선택합니다. 이미 두 개의 액세스 키가 있는 경우, 이 버튼은 비활성화되어 있으며 액세스 키를 삭제해야 새로 생성할 수 있습니다.

1. **Access key best practices & alternatives**(액세스 키 모범 사례 및 대안) 페이지에서 사용 사례를 선택하여 장기 액세스 키 생성 방지에 도움이 되는 추가 옵션에 대해 알아봅니다. 사용 사례에 여전히 액세스 키가 필요하다고 판단되면 **Other**(기타), **Next**(다음)를 차례로 선택합니다.

1. (선택 사항) 액세스 키에 대한 설명 태그 값을 설정합니다. 이렇게 하면 IAM 사용자에게 태그 키-값 페어가 추가됩니다. 이는 나중에 액세스 키를 식별하고 업데이트하는 데 도움이 됩니다. 태그 키는 액세스 키 ID로 설정됩니다. 태그 값은 사용자가 지정하는 액세스 키 설명으로 설정됩니다. 모두 마쳤으면 **Create access key**(액세스 키 생성)를 선택합니다.

1. **Retrieve access keys**(액세스 키 검색) 페이지에서 **Show**(표시)를 선택하여 사용자의 비밀 액세스 키 값을 표시하거나 **Download .csv file**(.csv 파일 다운로드)을 선택합니다. 이것이 비밀 액세스 키를 저장할 수 있는 유일한 기회입니다. 비밀 액세스 키를 안전한 위치에 저장한 후 **Done**(완료)을 선택합니다.

## 액세스 키 비활성화(콘솔)
<a name="deactivate-access-key-seccreds"></a>

적절한 권한이 부여된 경우 AWS Management Console을 사용하여 액세스 키를 비활성화할 수 있습니다.

**액세스 키를 비활성화하려면 다음을 수행하세요.**

1. AWS 계정 ID나 계정 별칭, IAM 사용자 이름 및 암호를 사용하여 [IAM 콘솔](https://console.aws.amazon.com/iam)에 로그인합니다.
**참고**  
사용자 편의를 위해 AWS 로그인 페이지는 브라우저 쿠키를 사용하여 IAM 사용자 이름 및 계정 정보를 기억합니다. 이전에 다른 사용자로 로그인한 경우 페이지 하단 근처의 **다른 계정에 로그인(Sign in to a different account)**을 선택하여 기본 로그인 페이지로 돌아갑니다. 여기서 AWS 계정 ID 또는 계정 별칭을 입력하면 계정의 IAM 사용자 로그인 페이지로 리디렉션됩니다.

   AWS 계정 ID를 받으려면 관리자에게 문의하세요.

1. 오른쪽 상단의 탐색 모음에서 사용자 이름을 선택한 다음 **Security credentials**(보안 자격 증명)를 선택합니다.  
![\[AWS Management Console 보안 자격 증명 링크\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. **Access keys**(액세스 키) 섹션에서 비활성화하려는 키를 찾은 다음 **Actions**(작업), **Deactivate**(비활성화)를 차례로 선택합니다. 확인 메시지가 나타나면 **Deactivate**(비활성화)를 클릭합니다. 비활성화된 액세스 키는 여전히 두 개의 액세스 키 제한에 포함됩니다.

## 액세스 키 활성화(콘솔)
<a name="activate-access-key-seccreds"></a>

적절한 권한이 부여된 경우 AWS Management Console을 사용하여 액세스 키를 활성화할 수 있습니다.

**액세스 키를 생성하려면 다음을 수행하세요.**

1. AWS 계정 ID나 계정 별칭, IAM 사용자 이름 및 암호를 사용하여 [IAM 콘솔](https://console.aws.amazon.com/iam)에 로그인합니다.
**참고**  
사용자 편의를 위해 AWS 로그인 페이지는 브라우저 쿠키를 사용하여 IAM 사용자 이름 및 계정 정보를 기억합니다. 이전에 다른 사용자로 로그인한 경우 페이지 하단 근처의 **다른 계정에 로그인(Sign in to a different account)**을 선택하여 기본 로그인 페이지로 돌아갑니다. 여기서 AWS 계정 ID 또는 계정 별칭을 입력하면 계정의 IAM 사용자 로그인 페이지로 리디렉션됩니다.

   AWS 계정 ID를 받으려면 관리자에게 문의하세요.

1. 오른쪽 상단의 탐색 모음에서 사용자 이름을 선택한 다음 **Security credentials**(보안 자격 증명)를 선택합니다.  
![\[AWS Management Console 보안 자격 증명 링크\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. **Access keys**(액세스 키) 섹션에서 활성화하려는 키를 찾은 다음 **Actions**(작업), **Activate**(활성화)를 차례로 선택합니다.

## 액세스 키 삭제(콘솔)
<a name="delete-access-key-seccreds"></a>

적절한 권한이 부여된 경우 AWS Management Console을 사용하여 액세스 키를 삭제화할 수 있습니다.

**더 이상 필요하지 않은 액세스 키를 삭제하려면 다음을 수행하세요.**

1. AWS 계정 ID나 계정 별칭, IAM 사용자 이름 및 암호를 사용하여 [IAM 콘솔](https://console.aws.amazon.com/iam)에 로그인합니다.
**참고**  
사용자 편의를 위해 AWS 로그인 페이지는 브라우저 쿠키를 사용하여 IAM 사용자 이름 및 계정 정보를 기억합니다. 이전에 다른 사용자로 로그인한 경우 페이지 하단 근처의 **다른 계정에 로그인(Sign in to a different account)**을 선택하여 기본 로그인 페이지로 돌아갑니다. 여기서 AWS 계정 ID 또는 계정 별칭을 입력하면 계정의 IAM 사용자 로그인 페이지로 리디렉션됩니다.

   AWS 계정 ID를 받으려면 관리자에게 문의하세요.

1. 오른쪽 상단의 탐색 모음에서 사용자 이름을 선택한 다음 **Security credentials**(보안 자격 증명)를 선택합니다.  
![\[AWS Management Console 보안 자격 증명 링크\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. **Access keys**(액세스 키) 섹션에서 삭제하려는 키를 찾은 다음 **Actions**(작업), **Delete**(삭제)를 차례로 선택합니다. 대화 상자의 지침에 따라 먼저 **Deactivate**(비활성화)를 수행한 다음 삭제를 확인합니다. 액세스 키를 영구적으로 삭제하기 전에 액세스 키가 더 이상 사용되고 있지 않은지 확인하는 것이 좋습니다.

# IAM 관리자가 IAM 사용자 액세스 키를 관리하는 방법
<a name="access-keys-admin-managed"></a>

IAM 관리자는 개별 IAM 사용자와 연결된 액세스 키를 생성, 활성화, 비활성화 및 삭제할 수 있습니다. 액세스 키가 있는 계정의 IAM 사용자를 나열하고 특정 액세스 키가 있는 IAM 사용자를 찾을 수도 있습니다.

**Topics**
+ [

## IAM 사용자의 액세스 키 생성
](#admin-create-access-key)
+ [

## IAM 사용자의 액세스 키 비활성화
](#admin-deactivate-access-key)
+ [

## IAM 사용자의 액세스 키 활성화
](#admin-activate-access-key)
+ [

## IAM 사용자의 액세스 키 삭제
](#admin-delete-access-key)
+ [

## IAM 사용자의 액세스 키 나열
](#admin-list-access-key)
+ [

## IAM 사용자의 액세스 키 나열
](#admin-list-access-key)
+ [

## 계정의 사용자에 대한 모든 액세스 키 ID 표시
](#admin-list-all-access-keys)
+ [

## 액세스 키 ID를 사용하여 사용자 찾기
](#admin-find-user-access-keys)
+ [

## 액세스 키 ID의 최근 사용 찾기
](#admin-find-most-recent-use-access-keys)

## IAM 사용자의 액세스 키 생성
<a name="admin-create-access-key"></a>

------
#### [ Console ]

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. 사용자 이름을 선택하여 사용자 세부 정보 페이지로 이동합니다.

1. **보안 자격 증명** 탭의 **액세스 키** 섹션에서 **액세스 키 생성**을 선택합니다.

   버튼이 비활성화된 경우 기존 키 중 하나를 삭제해야 새 키를 생성할 수 있습니다.

1. **Access key best practices & alternatives**(액세스 키 모범 사례 및 대안) 페이지에서 모범 사례와 대안을 검토합니다. 사용 사례를 선택하여 장기 액세스 키 생성 방지에 도움이 되는 추가 옵션에 대해 알아봅니다.

1. 사용 사례에 여전히 액세스 키가 필요하다고 판단되면 **Other**(기타), **Next**(다음)를 차례로 선택합니다.

1. **(선택 사항)** **설명 태그 설정** 페이지에서 액세스 키에 설명 태그를 추가하여 액세스 키를 추적할 수 있습니다. **액세스 키 생성**을 선택하세요.

1. **Retrieve access key page**(액세스 키 검색) 페이지에서 **Show**(표시)를 선택하여 사용자의 비밀 액세스 키 값을 표시합니다.

1. 액세스 키 ID 및 보안 액세스 키를 컴퓨터의 안전한 위치에 `.csv` 파일로 저장하려면 **Download .csv file**(.csv 파일 다운로드) 버튼을 선택합니다.
**중요**  
새로 생성된 액세스 키를 보거나 다운로드할 수 있는 유일한 때이며, 이 경우 복구할 수는 없습니다. 액세스 키를 안전하게 유지 관리해야 합니다.

사용자를 위한 액세스 키를 생성하면 해당 키 페어가 기본적으로 활성화되며 사용자는 이 페어를 즉시 사용할 수 있습니다.

------
#### [ AWS CLI ]

다음 명령 실행:
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/create-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/create-access-key.html)

------
#### [ API ]

다음 작업을 직접 호출:
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html) 

------

## IAM 사용자의 액세스 키 비활성화
<a name="admin-deactivate-access-key"></a>

------
#### [ Console ]

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. 사용자 이름을 선택하여 사용자 세부 정보 페이지로 이동합니다.

1. **보안 자격 증명** 탭의 **액세스 키** 섹션에서 **작업** 드롭다운 메뉴를 선택한 다음 **비활성화**를 선택합니다.

1. **비활성화** 대화 상자에서 **비활성화**를 선택하여 액세스 키 비활성화 여부를 확인합니다.

액세스 키가 비활성화된 후에는 API 직접 호출에서 더 이상 사용할 수 없습니다. 필요한 경우 다시 활성화할 수 있습니다.

------
#### [ AWS CLI ]

다음 명령 실행:
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/update-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/update-access-key.html)

------
#### [ API ]

다음 작업을 직접 호출:
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccessKey.html) 

------

## IAM 사용자의 액세스 키 활성화
<a name="admin-activate-access-key"></a>

------
#### [ Console ]

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. 사용자 이름을 선택하여 사용자 세부 정보 페이지로 이동합니다.

1. **보안 자격 증명** 탭의 **액세스 키** 섹션에서 **작업** 드롭다운 메뉴를 선택한 다음 **활성화**를 선택합니다.

액세스 키가 활성화되면 API 직접 호출에서 사용할 수 있습니다. 필요한 경우 다시 비활성화할 수 있습니다.

------
#### [ AWS CLI ]

다음 명령 실행:
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/update-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/update-access-key.html)

------
#### [ API ]

다음 작업을 직접 호출:
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccessKey.html) 

------

## IAM 사용자의 액세스 키 삭제
<a name="admin-delete-access-key"></a>

액세스 키가 비활성화된 후 더 이상 필요하지 않으면 삭제하세요.

------
#### [ Console ]

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. 사용자 이름을 선택하여 사용자 세부 정보 페이지로 이동합니다.

1. **보안 자격 증명** 탭의 **액세스 키** 섹션에서 비활성 액세스 키에 대한 **작업** 드롭다운 메뉴를 선택한 다음 **삭제**를 선택합니다.

1. **삭제** 대화 상자에서 텍스트 입력 필드에 액세스 키 ID를 입력한 다음 **삭제**를 선택하여 액세스 키 삭제 여부를 확인합니다.

액세스 키가 삭제된 후에는 복구할 수 없습니다.

------
#### [ AWS CLI ]

다음 명령 실행:
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-access-key.html)

------
#### [ API ]

다음 작업을 직접 호출:
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccessKey.html) 

------

## IAM 사용자의 액세스 키 나열
<a name="admin-list-access-key"></a>

IAM 사용자와 연결된 액세스 키 ID의 목록을 볼 수 있습니다.

------
#### [ Console ]

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. 사용자 이름을 선택하여 사용자 세부 정보 페이지로 이동합니다.

1. **보안 자격 증명** 탭의 **액세스 키** 섹션에는 사용자의 액세스 키가 나열됩니다.

각 IAM 사용자는 두 개의 액세스 키를 가질 수 있습니다.

------
#### [ AWS CLI ]

다음 명령 실행:
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/list-access-keys.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-access-keys.html)

------
#### [ API ]

다음 작업을 직접 호출:
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccessKeys.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccessKeys.html) 

------

## IAM 사용자의 액세스 키 나열
<a name="admin-list-access-key"></a>

IAM 사용자와 연결된 액세스 키 ID의 목록을 볼 수 있습니다.

------
#### [ Console ]

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. 사용자 이름을 선택하여 사용자 세부 정보 페이지로 이동합니다.

1. **보안 자격 증명** 탭의 **액세스 키** 섹션에는 표시된 각 키의 상태를 포함하여 사용자의 액세스 키 ID가 나열됩니다.
**참고**  
사용자의 액세스 키 ID만 표시됩니다. 비밀 액세스 키는 키를 만들 때만 가져올 수 있습니다.

각 IAM 사용자는 두 개의 액세스 키를 가질 수 있습니다.

------
#### [ AWS CLI ]

다음 명령 실행:
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/list-access-keys.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-access-keys.html)

------
#### [ API ]

다음 작업을 직접 호출:
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccessKeys.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccessKeys.html) 

------

## 계정의 사용자에 대한 모든 액세스 키 ID 표시
<a name="admin-list-all-access-keys"></a>

AWS 계정에서 사용자의 액세스 키 ID 목록을 볼 수 있습니다.

------
#### [ Console ]

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. 사용자 이름을 선택하여 사용자 세부 정보 페이지로 이동합니다.

1. 필요할 경우 다음 단계를 통해 사용자 테이블에 **액세스 키 ID** 열을 추가합니다.

   1. 테이블 위 맨 오른쪽에서 **기본 설정** 아이콘(![\[Preferences icon\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/console-settings-icon.console.png))을 선택합니다.

   1. **기본 설정** 대화 상자의 **표시되는 열 선택**에서 **액세스 키 ID**를 켭니다.

   1. **확인**을 선택하여 사용자 목록으로 돌아갑니다. 액세스 키 ID를 포함하도록 목록이 업데이트됩니다.

1. **액세스 키 ID** 열에는 각 액세스 키의 상태와 ID가 표시됩니다(예: **`Active - AKIAIOSFODNN7EXAMPLE`** 또는 **`Inactive - AKIAI44QH8DHBEXAMPLE`**).

   이 정보를 사용하여 한 개 또는 두 개의 액세스 키를 가진 사용자의 액세스 키 ID를 보고 복사할 수 있습니다. 액세스 키가 없는 사용자는 이 열에 **`-`** 기호가 표시됩니다.
**참고**  
비밀 액세스 키는 키를 만들 때만 가져올 수 있습니다.

각 IAM 사용자는 두 개의 액세스 키를 가질 수 있습니다.

------

## 액세스 키 ID를 사용하여 사용자 찾기
<a name="admin-find-user-access-keys"></a>

AWS 계정에서 액세스 키 ID를 사용하여 사용자를 찾을 수 있습니다.

------
#### [ Console ]

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창의 검색 상자에 **액세스 키 ID**(예: AKIAI44QH8DHBEXAMPLE)를 입력하세요.

1. 액세스 키 ID가 연결된 IAM 사용자가 탐색 창에 나타납니다. 사용자 이름을 선택하여 사용자 세부 정보 페이지로 이동합니다.

------

## 액세스 키 ID의 최근 사용 찾기
<a name="admin-find-most-recent-use-access-keys"></a>

액세스 키의 최근 사용은 IAM 사용자 페이지의 사용자 목록에 있는 사용자 세부 정보 페이지에 표시되며, 자격 증명 보고서의 일부분입니다.

------
#### [ Console ]

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 사용자 목록에서 **마지막으로 사용한 액세스 키** 열을 확인하세요.

   열이 표시되지 않으면 **기본 설정** 아이콘(![\[Preferences icon\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/console-settings-icon.console.png))을 선택하고 **표시되는 열 선택**에서 **마지막으로 사용한 액세스 키**를 켜면 열이 표시됩니다.

1. (선택 사항) 탐색 창의 **액세스 보고서**에서 **자격 증명 보고서**를 선택하여 계정의 모든 IAM 사용자에 대해 마지막으로 사용한 액세스 키 정보가 포함된 보고서를 다운로드합니다.

1. (선택 사항) IAM 사용자를 선택하여 사용자 세부 정보를 확인합니다. **요약** 섹션에는 액세스 키 ID, 상태 및 마지막으로 사용된 시간이 포함되어 있습니다.

------
#### [ AWS CLI ]

다음 명령 실행:
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html)

------
#### [ API ]

다음 작업을 직접 호출:
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html) 

------

# 액세스 키 업데이트
<a name="id-credentials-access-keys-update"></a>

보안 [모범 사례](best-practices.md#update-access-keys)로, 필요할 때(예: 직원 퇴사) IAM 사용자 액세스 키를 업데이트하는 것이 좋습니다. 필요한 권한이 부여되면 IAM 사용자는 자신의 액세스 키를 업데이트할 수 있습니다.

IAM 사용자에게 자신의 액세스 키를 업데이트할 수 있는 권한을 부여하는 방법에 대한 자세한 내용은 [AWS: IAM 사용자가 보안 인증 페이지에서 자신의 암호, 액세스 키 및 SSH 퍼블릭 키를 관리할 수 있도록 허용](reference_policies_examples_aws_my-sec-creds-self-manage-pass-accesskeys-ssh.md) 섹션을 참조하세요. 모든 IAM 사용자가 주기적으로 암호를 업데이트하도록 요구하는 암호 정책(빈도 포함)을 계정에 적용할 수도 있습니다. 자세한 내용은 [IAM 사용자의 계정 암호 정책 설정](id_credentials_passwords_account-policy.md) 섹션을 참조하세요.

**참고**  
보안 액세스 키를 분실한 경우 액세스 키를 삭제하고 새 키를 생성해야 합니다. 시크릿 액세스 키는 생성할 때만 가져올 수 있습니다. 이 절차를 사용하여 손실된 액세스 키를 비활성화하고, 새 자격 증명으로 바꿉니다.

**Topics**
+ [

## IAM 사용자 액세스 키 업데이트(콘솔)
](#rotating_access_keys_console)
+ [

## 액세스 키 업데이트(AWS CLI)
](#rotating_access_keys_cli)
+ [

## 액세스 키 업데이트(AWS API)
](#rotating_access_keys_api)

## IAM 사용자 액세스 키 업데이트(콘솔)
<a name="rotating_access_keys_console"></a>

AWS Management Console에서 액세스 키를 업데이트할 수 있습니다.

**애플리케이션을 중단하지 않고 IAM 사용자의 액세스 키를 업데이트하려면(콘솔)**

1. 최초 액세스 키가 활성 상태일 때 두 번째 액세스 키를 만듭니다.

   1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

   1. 탐색 창에서 **사용자**를 선택합니다.

   1. 해당 사용자의 이름을 선택한 후 **보안 자격 증명** 탭을 선택합니다.

   1. **액세스 키** 섹션에서 **액세스 키 생성**을 선택합니다. **Access key best practices & alternatives**(액세스 키 모범 사례 및 대안) 페이지에서 **Other**(기타), **Next**(다음)를 차례로 선택합니다.

   1. (선택 사항) 액세스 키에 대한 설명 태그 값을 설정하여 이 IAM 사용자에게 태그 키-값 페어를 추가합니다. 이는 나중에 액세스 키를 식별하고 업데이트하는 데 도움이 됩니다. 태그 키는 액세스 키 ID로 설정됩니다. 태그 값은 사용자가 지정하는 액세스 키 설명으로 설정됩니다. 모두 마쳤으면 **Create access key**(액세스 키 생성)를 선택합니다.

   1. **Retrieve access keys**(액세스 키 검색) 페이지에서 **Show**(표시)를 선택하여 사용자의 비밀 액세스 키 값을 표시하거나 **Download .csv file**(.csv 파일 다운로드)을 선택합니다. 이것이 비밀 액세스 키를 저장할 수 있는 유일한 기회입니다. 비밀 액세스 키를 안전한 위치에 저장한 후 **Done**(완료)을 선택합니다.

      사용자를 위한 액세스 키를 생성하면 해당 키 페어가 기본적으로 활성화되며 사용자는 이 페어를 즉시 사용할 수 있습니다. 따라서 사용자에게 두 개의 활성 액세스 키가 생깁니다.

1. 새 액세스 키를 사용하도록 모든 애플리케이션과 도구를 업데이트합니다.

1. <a name="id_credentials_access-keys-key-still-in-use"></a>가장 오래된 액세스 키의 **Last used**(마지막 사용) 정보를 검토하여 최초 액세스 키가 아직 사용 중인지 확인합니다. 한 가지 접근 방식은 며칠을 기다린 다음 계속하기 전에 사용된 적이 있는 기존 액세스 키가 있는지 확인하는 것입니다.

1. **Last used**(마지막 사용) 정보에 오래된 키가 사용된 적이 없다고 표시되더라도 최초 액세스 키를 바로 삭제하지 않는 것이 좋습니다. 대신 **Actions**(작업), **Deactivate**(비활성화)를 차례로 선택하여 첫 번째 액세스 키를 비활성화합니다.

1. 새 액세스 키만 사용하여 애플리케이션이 작동 중인지 확인합니다. 원래 액세스 키를 계속 사용하는 어떤 애플리케이션도 AWS 리소스에 더 이상 액세스할 수 없기 때문에 이 시점에 작업을 중단합니다. 그러한 애플리케이션 또는 도구를 찾는다면 최초 액세스 키를 다시 활성화할 수 있습니다. 그런 다음 [Step 3](#id_credentials_access-keys-key-still-in-use) 단원으로 돌아가 이 애플리케이션을 업데이트하여 새 키를 사용하세요.

1. 일정 기간 기다린 후 모든 애플리케이션과 도구가 업데이트되었는지 확인한 뒤에 최초 액세스 키를 삭제할 수 있습니다:

   1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

   1. 탐색 창에서 **사용자**를 선택합니다.

   1. 해당 사용자의 이름을 선택한 후 **보안 자격 증명** 탭을 선택합니다.

   1. **Access keys**(액세스 키) 섹션에서 삭제하려는 액세스 키에 대해 **Actions**(작업), **Delete**(삭제)를 차례로 선택합니다. 대화 상자의 지침에 따라 먼저 **Deactivate**(비활성화)를 수행한 다음 삭제를 확인합니다.

**업데이트하거나 삭제해야 하는 액세스 키를 결정하려면(콘솔)**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. 필요할 경우 다음 단계를 통해 사용자 테이블에 **Access key age(액세스 키 수명)** 열을 추가합니다.

   1. 테이블 위 맨 오른쪽에서 설정 아이콘(![\[Settings icon\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/console-settings-icon.console.png))을 선택합니다.

   1. **Manage Columns(열 관리)**에서 **Access key age(액세스 키 수명)**을 선택합니다.

   1. **닫기**를 선택하여 사용자 목록으로 돌아갑니다.

1. **Access key age(액세스 키 수명)** 열에는 가장 오래된 활성 액세스 키가 생성된 이후로 경과한 일수가 표시됩니다. 이 정보를 사용하여 업데이트하거나 삭제해야 하는 액세스 키를 소유한 사용자를 찾을 수 있습니다. 액세스 키가 없는 사용자는 이 열에 **없음**이라고 표시됩니다.

## 액세스 키 업데이트(AWS CLI)
<a name="rotating_access_keys_cli"></a>

AWS Command Line Interface에서 액세스 키를 업데이트할 수 있습니다.

**애플리케이션을 중단하지 않고 액세스 키를 업데이트하려면(AWS CLI)**

1. 최초 액세스 키가 활성 상태일 때 두 번째 액세스 키를 만들면 이 키도 기본적으로 활성 상태가 됩니다. 다음 명령을 실행합니다.
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/create-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/create-access-key.html)

     따라서 사용자에게 두 개의 활성 액세스 키가 생깁니다.

1. <a name="step-update-apps"></a>새 액세스 키를 사용하도록 모든 애플리케이션과 도구를 업데이트합니다.

1. <a name="step-determine-use"></a>다음 명령을 사용하여 최초 액세스 키가 아직 사용 중인지 확인합니다.
   +  [https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html)

   한 가지 접근 방식은 며칠을 기다린 다음 계속하기 전에 사용된 적이 있는 기존 액세스 키가 있는지 확인하는 것입니다.

1. [Step 3](#step-determine-use) 단계를 통해 기존 키를 사용한 적이 없다는 것이 밝혀진 경우 최초의 액세스 키를 즉시 삭제하지 말 것을 권장합니다. 그 대신 다음 명령을 사용하여 최초 액세스 키의 상태를 `Inactive`로 변경하세요.
   +  [https://docs.aws.amazon.com/cli/latest/reference/iam/update-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/update-access-key.html)

1. 새 액세스 키만 사용하여 애플리케이션이 작동 중인지 확인합니다. 원래 액세스 키를 계속 사용하는 어떤 애플리케이션도 AWS 리소스에 더 이상 액세스할 수 없기 때문에 이 시점에 작업을 중단합니다. 그러한 애플리케이션 또는 도구를 찾는다면 그 상태를 `Active`로 되돌려 최초 액세스 키를 다시 활성화할 수 있습니다. 그런 다음 [Step 2](#step-update-apps) 단계로 돌아가 이 애플리케이션을 업데이트해 새 키를 사용하세요.

1. 일정 기간 기다린 후 모든 애플리케이션과 도구가 업데이트되었는지 확인한 뒤에 다음 명령을 사용하여 최초 액세스 키를 삭제할 수 있습니다.
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-access-key.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-access-key.html)

## 액세스 키 업데이트(AWS API)
<a name="rotating_access_keys_api"></a>

AWS API를 사용하여 액세스 키를 업데이트할 수 있습니다.

**애플리케이션을 중단하지 않고 액세스 키를 업데이트하려면(AWS API)**

1. 최초 액세스 키가 활성 상태일 때 두 번째 액세스 키를 만들면 이 키도 기본적으로 활성 상태가 됩니다. 다음 작업을 직접 호출:
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateAccessKey.html)

     따라서 사용자에게 두 개의 활성 액세스 키가 생깁니다.

1. <a name="step-update-apps-2"></a>새 액세스 키를 사용하도록 모든 애플리케이션과 도구를 업데이트합니다.

1. <a name="step-determine-use-2"></a>다음 연산을 호출하여 최초 액세스 키가 아직 사용 중인지 확인합니다.
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html)

   한 가지 접근 방식은 며칠을 기다린 다음 계속하기 전에 사용된 적이 있는 기존 액세스 키가 있는지 확인하는 것입니다.

1. [Step 3](#step-determine-use-2) 단계를 통해 기존 키를 사용한 적이 없다는 것이 밝혀진 경우 최초의 액세스 키를 즉시 삭제하지 말 것을 권장합니다. 그 대신 다음 연산을 호출하여 최초 액세스 키의 상태를 `Inactive`로 변경하세요.
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAccessKey.html)

1. 새 액세스 키만 사용하여 애플리케이션이 작동 중인지 확인합니다. 원래 액세스 키를 계속 사용하는 어떤 애플리케이션도 AWS 리소스에 더 이상 액세스할 수 없기 때문에 이 시점에 작업을 중단합니다. 그러한 애플리케이션 또는 도구를 찾는다면 그 상태를 `Active`로 되돌려 최초 액세스 키를 다시 활성화할 수 있습니다. 그런 다음 [Step 2](#step-update-apps-2) 단계로 돌아가 이 애플리케이션을 업데이트해 새 키를 사용하세요.

1. 일정 기간 기다린 후 모든 애플리케이션과 도구가 업데이트되었는지 확인한 뒤에 다음 연산을 호출하여 최초 액세스 키를 삭제할 수 있습니다.
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccessKey.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteAccessKey.html)

# 액세스 키 보안
<a name="securing_access-keys"></a>

액세스 키를 보유한 사람은 누구든지 AWS 리소스에 대해 사용자와 동일한 권한으로 액세스할 수 있습니다. 따라서 AWS에서는 사용자의 액세스 키를 보호하기 위해 최선을 다하며, 사용자도 [Shared Responsibility Model](https://aws.amazon.com/compliance/shared-responsibility-model/)에 부합하도록 노력해야 합니다.

액세스 키를 보호하는 데 도움이 되는 지침을 보려면 다음 섹션을 확장하세요.

**참고**  
사용자 조직의 보안 요구 사항과 정책은 이 주제에 설명된 것과 다를 수 있습니다. 여기에 제공된 제안 사항은 일반적인 지침입니다.

## AWS 계정 루트 사용자 액세스 키 제거(또는 생성하지 않음)
<a name="root-password"></a>

**계정을 보호하는 가장 좋은 방법 중 하나는 AWS 계정 루트 사용자에 대한 액세스 키를 보유하지 않는 것입니다.** 매우 드물지만 루트 사용자 액세스 키가 필요한 경우를 제외하고는 액세스 키를 생성하지 않는 것이 좋습니다. 대신 일상적인 관리 작업을 위한 관리 사용자를 AWS IAM Identity Center에서 생성합니다. IAM Identity Center에서 관리 사용자를 생성하는 방법에 대한 자세한 내용은 *IAM Identity Center 사용 설명서*의 [Getting started](https://docs.aws.amazon.com//singlesignon/latest/userguide/getting-started.html)를 참조하세요.

계정에 대한 루트 사용자 액세스 키가 이미 있는 경우 해당 액세스 키(있는 경우)를 현재 사용 중인 애플리케이션의 위치를 확인하고 루트 사용자 액세스 키를 IAM 사용자 액세스 키로 교체하는 것이 좋습니다. 그런 다음 루트 사용자 액세스 키를 비활성화하고 제거합니다. 액세스 키 업데이트 방법에 대한 자세한 내용은 [액세스 키 업데이트](id-credentials-access-keys-update.md) 섹션을 참조하세요.



## 장기 액세스 키 대신 임시 보안 인증(IAM 역할) 사용
<a name="use-roles"></a>

대부분의 시나리오에서는 IAM 사용자와 같이 만료되지 않는 장기 액세스 키가 필요하지 않습니다. 대신, IAM 역할을 만들고 임시 보안 인증 정보를 생성할 수 있습니다. 임시 보안 자격 증명은 액세스 키 ID와 비밀 액세스 키로 구성되지만, 자격 증명이 만료되는 시간을 나타내는 보안 토큰을 포함합니다.

장기 액세스 키(IAM 사용자 및 루트 사용자에 연결된 액세스 키)는 수동으로 취소할 때까지 유효하게 유지됩니다. 하지만 IAM 역할과 AWS Security Token Service의 기타 기능을 통해 얻는 임시 보안 인증은 단기간 내에 만료됩니다. 임시 보안 자격 증명을 사용하면 자격 증명이 실수로 노출된 경우에 위험을 줄일 수 있습니다.

다음 시나리오에서는 IAM 역할과 임시 보안 인증을 사용합니다.
+ **Amazon EC2 인스턴스에서 실행 중인 애플리케이션 또는 AWS CLI 스크립트가 있는 경우.** 애플리케이션에서 액세스 키를 직접 사용하지 않도록 합니다. 액세스 키를 애플리케이션에 전달하거나, 애플리케이션에 포함하거나, 애플리케이션에서 소스로부터 액세스 키를 읽지 않도록 합니다. 대신, 애플리케이션에 대한 적절한 권한을 가진 IAM 역할을 정의하고 [EC2의 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)을 사용하여 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 시작합니다. 그러면 IAM 역할이 Amazon EC2 인스턴스에 연결됩니다. 이 방법을 통해 애플리케이션은 AWS에 대한 프로그래밍 방식의 직접 호출에 사용할 수 있는 임시 보안 인증을 얻을 수 있습니다. AWS SDK 및 AWS Command Line Interface(AWS CLI)에서는 역할에서 임시 보안 인증을 자동으로 가져올 수 있습니다.
+ **교차 계정 액세스 권한을 부여해야 합니다.** IAM 역할을 사용하여 계정 사이에 신뢰를 구축한 다음, 한 계정의 사용자에게 신뢰할 수 있는 계정에 액세스할 수 있는 제한된 권한을 부여합니다. 자세한 내용은 [튜토리얼: IAM 역할을 사용한 AWS 계정 간 액세스 권한 위임](tutorial_cross-account-with-roles.md) 섹션을 참조하세요.
+ **모바일 앱을 사용합니다.** 암호화된 스토리지를 포함하여 앱에 액세스 키를 포함하지 않도록 합니다. 대신, [Amazon Cognito](https://aws.amazon.com/cognito/)를 사용하여 앱에서 사용자 자격 증명을 관리합니다. 이 서비스를 사용하면 Login with Amazon, Facebook, Google 또는 OpenID Connect(OIDC) 호환 자격 증명 공급자를 통해 사용자를 인증할 수 있습니다. 그런 다음 Amazon Cognito 보안 인증 공급자를 사용하여 앱에서 AWS에 요청하는 데 사용하는 보안 인증을 관리할 수 있습니다.
+ **AWS에 연동하려고 하고 조직에서 SAML 2.0을 지원합니다.** SAML 2.0을 지원하는 자격 증명 공급자가 있는 조직에서 작업하는 경우 SAML을 사용하도록 공급자를 구성합니다. SAML을 사용하여 인증 정보를 AWS와 교환하고 임시 보안 자격 증명 세트를 다시 가져올 수 있습니다. 자세한 내용은 [SAML 2.0 연동](id_roles_providers_saml.md) 섹션을 참조하세요.
+ **AWS에 연동하려고 하고 조직에 온프레미스 자격 증명 스토어가 있습니다.** 사용자가 조직 내부에서 인증할 수 있는 경우 AWS 리소스에 액세스하기 위한 임시 보안 자격 증명을 발급하는 애플리케이션을 작성할 수 있습니다. 자세한 내용은 [AWS 콘솔에 대한 사용자 지정 ID 브로커 액세스 활성화](id_roles_providers_enable-console-custom-url.md) 섹션을 참조하세요.
+ **IAM 정책의 조건을 사용하여 예상 네트워크에서만 액세스를 허용합니다.** 퍼블릭 IP 주소 또는 가상 프라이빗 클라우드(VPC)와 같은 예상 네트워크만 지정하고 허용하는 [조건으로 IAM 정책](reference_policies_elements_condition_operators.md)을 구현하여 액세스 키의 사용 위치와 사용 방법을 제한할 수 있습니다. 이렇게 하면 액세스 키는 예상되고 허용 가능한 네트워크에서만 사용할 수 있습니다.

**참고**  
AWS 리소스에 프로그래밍 방식으로 액세스해야 하는 애플리케이션에서 Amazon EC2 인스턴스를 사용하고 있나요? 그렇다면 [EC2용 IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html)을 사용하세요.

## IAM 사용자 액세스 키의 올바른 관리
<a name="iam-user-access-keys"></a>

AWS에 대한 프로그래밍 방식 액세스를 위해 액세스 키를 생성해야 하는 경우 IAM 사용자를 위한 액세스 키를 생성하여 필요한 권한만 사용자에게 부여합니다.

IAM 사용자 액세스 키를 보호하려면 다음 예방 조치를 준수합니다.
+ **액세스 키를 코드에 직접 포함하지 마십시오.** [AWS SDK](https://aws.amazon.com/tools/#sdk) 및 [AWS 명령줄 도구](https://aws.amazon.com/tools/#cli)를 사용하여 액세스 키를 알려진 위치에 보관합니다. 그러면 코드에 포함할 필요가 없습니다.

  액세스 키를 다음 중 한 곳에 보관하십시오.
  + **AWS 자격 증명 파일.** AWS SDK 및 AWS CLI에서는 AWS 자격 증명 파일에 저장된 자격 증명을 자동으로 사용합니다.

    AWS 자격 증명 파일을 사용하는 방법에 대한 자세한 내용은 SDK 설명서를 참조하십시오. 예를 들어, *AWS SDK for Java 개발자 안내서*의 [Set AWS Credentials and Region](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/setup-credentials.html) 및 *AWS Command Line Interface 사용 설명서*의 [구성 및 보안 인증 파일](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html)을 참조하세요.

    AWS SDK for .NET 및 AWS Tools for Windows PowerShell에 대한 보안 인증을 저장하려면 SDK 스토어를 사용하는 것이 좋습니다. 자세한 내용은 *AWS SDK for .NET 개발자 안내서*의 [Using the SDK Store](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/sdk-store.html)를 참조하세요.
  + **환경 변수.** 다중 테넌트 시스템에서 시스템 환경 변수가 아닌 사용자 환경 변수를 선택합니다.

    환경 변수를 사용하여 보안 인증을 저장하는 방법에 대한 자세한 내용은 *AWS Command Line Interface 사용 설명서*의 [환경 변수](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-envvars.html)를 참조하세요.
+ **애플리케이션마다 서로 다른 액세스 키를 사용합니다.** 그러면 권한을 격리하고 액세스 키가 노출된 경우 개별 애플리케이션에 대해 액세스 키를 취소할 수 있습니다. 또한 애플리케이션별로 별도의 액세스 키를 사용하면 [AWS CloudTrail](https://aws.amazon.com/cloudtrail/) 로그 파일에 개별 항목이 생성됩니다. 이 구성을 사용하면 특정 작업을 수행한 애플리케이션을 쉽게 확인할 수 있습니다.
+ **필요한 경우 액세스 키를 업데이트합니다.** 액세스 키가 손상될 위험이 있는 경우 액세스 키를 업데이트하고 이전 액세스 키를 삭제합니다. 자세한 내용은 [액세스 키 업데이트](id-credentials-access-keys-update.md) 섹션을 참조하세요.
+ **미사용 액세스 키를 제거합니다.** 사용자가 조직을 떠나는 경우 해당 IAM 사용자를 제거합니다. 그러면 사용자는 해당 리소스에 더 이상 액세스할 수 없습니다. 액세스 키가 마지막으로 사용된 시간을 확인하려면 [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html) API(AWS CLI 명령: [https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html))를 사용합니다.
+ **가장 민감한 API 작업에 대해 임시 보안 인증을 사용하고 멀티 팩터 인증을 구성합니다.** 사용자가 호출할 수 있는 API 작업을 IAM 정책을 사용해 지정할 수 있습니다. 어떤 경우에는 특히 민감한 작업을 수행하도록 허용하기 전에 AWS MFA로 사용자를 인증하도록 요구하는 추가 보안이 필요할 수 있습니다. 예를 들어 사용자가 Amazon EC2 `RunInstances`, `DescribeInstances` 및 `StopInstances` 작업을 수행하도록 허용하는 정책이 있을 수 있습니다. 하지만 `TerminateInstances`처럼 안전하지 않은 작업의 경우 이를 제한해 사용자가 AWS MFA 디바이스에서 인증할 때만 작업을 수행하도록 해야 할 필요가 있을 수 있습니다. 자세한 내용은 [MFA를 통한 보안 API 액세스](id_credentials_mfa_configure-api-require.md) 섹션을 참조하세요.

## AWS 액세스 키를 사용하여 모바일 앱 액세스
<a name="access-keys-mobile-app"></a>

AWS 모바일 앱을 사용하여 일부 AWS 서비스 및 기능에 액세스할 수 있습니다. 모바일 앱을 사용하여 이동 중에도 인시던트 대응을 지원할 수 있습니다. 자세한 내용을 확인하고 앱을 다운로드하려면 [AWS 콘솔 모바일 애플리케이션](https://aws.amazon.com/console/mobile/)을 참조하십시오.

콘솔 암호 또는 액세스 키를 사용하여 모바일 앱에 로그인할 수 있습니다. 모범 사례로, 루트 사용자 액세스 키는 사용하지 않도록 합니다. 대신 모바일 디바이스에서 암호 또는 생체 인식 잠금을 사용하는 방법과 함께 모바일 앱을 사용하여 AWS 리소스 관리를 위한 특별히 IAM 사용자를 생성합니다. 모바일 디바이스를 분실한 경우 IAM 사용자의 액세스 권한을 제거할 수 있습니다.

**액세스 키를 사용하여 로그인하려면(모바일 앱)**

1. 모바일 디바이스에서 모바일 앱을 엽니다.

1. 디바이스에 ID를 처음 추가하는 경우 **Add an identity(ID 추가)**를 선택한 다음 **Access keys(액세스 키)**를 선택합니다.

   다른 ID를 사용하여 이미 로그인한 경우 메뉴 아이콘을 선택하고 **Switch identity(ID 전환)**를 선택합니다. 그러고 나서 **Sign in as a different identity(다른 ID로 로그인)**을 선택한 다음 **Access keys(액세스 키)**를 선택합니다.

1. **Access keys(액세스 키)** 페이지에 정보를 입력합니다.
   + **Access key ID** – 액세스 키 ID를 입력합니다.
   + **Secret access key** - 비밀 액세스 키를 입력합니다.
   + **Identity name** - 모바일 앱에 표시할 ID 이름을 입력합니다. IAM 사용자 이름과 일치하지 않아도 됩니다.
   + **Identity PIN** - 이후 로그인에 사용할 개인 식별 번호(PIN)를 생성합니다.
**참고**  
AWS 모바일 앱에 생체 인식을 활성화하면 PIN 대신 확인을 위해 지문 또는 안면 인식을 사용하라는 메시지가 표시됩니다. 생체 인식에 실패하면 PIN을 입력하라는 메시지가 대신 표시될 수 있습니다.

1. **Verify and add keys(확인하고 키 추가)**를 선택합니다.

   이제 모바일 앱을 사용하여 일부 리소스에 액세스할 수 있습니다.

## 관련 정보
<a name="more-resources"></a>

다음 주제에서는 액세스 키를 사용하도록 AWS SDK 및 AWS CLI를 설정하는 지침을 제공합니다.
+ *AWS SDK for Java 개발자 안내서*의 [Set AWS credentials and Region](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/setup-credentials.html)
+ *AWS SDK for .NET 개발자 안내서*의 [Using the SDK Store](https://docs.aws.amazon.com/sdk-for-net/v3/developer-guide/sdk-store.html)
+ *AWS SDK for PHP 개발자 안내서*의 [Providing Credentials to the SDK](https://docs.aws.amazon.com/aws-sdk-php/v2/guide/credentials.html)
+ Boto 3(Python용 AWS SDK) 문서의 [Configuration](https://boto3.amazonaws.com/v1/documentation/api/latest/guide/quickstart.html#configuration)
+ *AWS Tools for Windows PowerShell 사용 설명서*의 [AWS 보안 인증 사용](https://docs.aws.amazon.com/powershell/latest/userguide/specifying-your-aws-credentials.html) 
+ *AWS Command Line Interface 사용 설명서*의 [구성 및 보안 인증 파일](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html) 
+ *AWS SDK for .NET 개발자 안내서*의 [Granting access using an IAM role](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/net-dg-hosm.html)
+ *AWS SDK for Java 2.x*의 [Configure IAM roles for Amazon EC2](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java-dg-roles.html)

## 콘솔 액세스에 액세스 키 및 비밀 키 자격 증명 사용
<a name="console-access-security-keys"></a>

AWS CLI뿐만 아니라 AWS Management Console에 직접 액세스하는 데 액세스 키 및 비밀 키 자격 증명을 사용할 수 있습니다. AWS STS [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) API 직접 호출을 사용하면 가능합니다. `GetFederationToken`에서 제공하는 임시 자격 증명과 토큰을 사용하여 콘솔 URL을 구성하면 IAM 보안 주체가 콘솔에 액세스할 수 있습니다. 자세한 내용은 [AWS 콘솔에 대한 사용자 지정 ID 브로커 액세스 활성화](id_roles_providers_enable-console-custom-url.md) 섹션을 참조하세요.

MFA가 활성화된 상태에서 IAM 또는 루트 사용자 자격 증명을 사용하여 콘솔에 직접 로그인하는 경우 MFA가 필요합니다. 하지만 위에서 설명하는 방법(`GetFederationToken`에서 임시 자격 증명 사용)을 사용하는 경우 MFA가 필요하지 않습니다.



## 액세스 키 감사
<a name="Using_access-keys-audit"></a>

코드에서 AWS 액세스 키를 살펴보면 키가 자신의 계정에 속한 것인지 알 수 있습니다. 액세스 키 ID는 [https://docs.aws.amazon.com/cli/latest/reference/sts/get-access-key-info.html](https://docs.aws.amazon.com/cli/latest/reference/sts/get-access-key-info.html) AWS CLI 명령 또는 [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetAccessKeyInfo.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetAccessKeyInfo.html) AWS API 작업을 사용해 전달할 수 있습니다.

AWS CLI 및 AWS API 작업은 액세스 키가 속한 AWS 계정의 ID를 반환합니다. `AKIA`로 시작하는 액세스 키 ID는 IAM 사용자 또는 AWS 계정 루트 사용자을 위한 장기 자격 증명입니다. `ASIA`로 시작하는 액세스 키 ID는 AWS STS 작업으로 생성된 임시 자격 증명입니다. 응답으로 반환되는 계정이 자신의 소유라면 루트 사용자로 로그인하여 루트 사용자 액세스 키를 살펴볼 수 있습니다. 그런 다음 [자격 증명 보고서](id_credentials_getting-report.md)를 가져와서 키를 소유하고 있는 IAM 사용자를 알아볼 수 있습니다. `ASIA` 액세스 키의 경우 누가 임시 자격 증명을 요청했는지 알아보려면 CloudTrail 로그에서 AWS STS 이벤트를 확인하세요.

보안을 위해 [AWS CloudTrail 로그를 검토](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds)하여 AWS에서 누가 작업을 수행했는지 확인할 수 있습니다. 역할 신뢰 정책에서 `sts:SourceIdentity` 조건 키를 사용하여 사용자가 역할을 수임할 때 자격 증명을 지정하도록 요구할 수 있습니다. 예를 들어 IAM 사용자가 자신의 사용자 이름을 소스 자격 증명으로 지정하도록 요구할 수 있습니다. 이를 통해 AWS에서 특정 작업을 수행한 사용자를 확인할 수 있습니다. 자세한 내용은 [`sts:SourceIdentity`](reference_policies_iam-condition-keys.md#ck_sourceidentity) 섹션을 참조하세요.

이 작업은 액세스 키의 상태를 표시하지 않지만 키는 활성, 비활성 또는 삭제된 상태일 수 있습니다. 활성 키에도 작업을 실행할 수 있는 권한이 없는 경우도 있습니다. 삭제된 액세스 키를 입력하면 키가 존재하지 않는다는 오류 메시지가 반환될 수 있습니다.

# IAM의 AWS 다중 인증
<a name="id_credentials_mfa"></a>

보안 강화를 위해 멀티 팩터 인증(MFA)을 구성하여 AWS 리소스를 보호하는 것이 좋습니다. IAM 사용자는 물론, 독립 실행형 계정, 관리 계정, 멤버 계정을 포함한 모든 AWS 계정의 AWS 계정 루트 사용자에 대해 MFA를 활성화할 수 있습니다. 가능하면 패스키, 보안 키 등의 피싱 방지 MFA를 사용하는 것이 좋습니다. 이러한 FIDO 기반 인증자는 퍼블릭 키 암호화를 사용하며 피싱, 중간자 공격 및 재전송 공격에 강해 TOTP 기반 옵션보다 더 강력한 보안 수준을 제공합니다.

MFA는 루트 사용자의 모든 계정 유형에 적용됩니다. 자세한 내용은 [AWS Organizations 계정 루트 사용자 자격 증명 보호](root-user-best-practices.md#ru-bp-organizations) 섹션을 참조하세요.

루트 사용자에 대해 활성화한 MFA는 루트 사용자 자격 증명에만 영향을 줍니다. 계정의 IAM 사용자는 자신의 자격 증명에 더하여 별도로 자격 증명을 갖게 되며, 이 별도의 자격 증명에 고유의 MFA가 구성됩니다. MFA를 사용하여 루트 사용자를 보호하는 방법에 대한 자세한 내용은 [AWS 계정 루트 사용자에 대한 다중 인증](enable-mfa-for-root.md) 섹션을 참조하세요.

AWS 계정 루트 사용자 및 IAM 사용자는 어떤 유형이든 최대 8개의 MFA 디바이스를 등록할 수 있습니다. 여러 MFA 디바이스를 등록하면 유연성이 향상되고 디바이스가 분실 또는 손상된 경우에도 액세스가 중단될 위험을 줄일 수 있습니다. AWS Management Console에 로그인하거나 AWS CLI를 통해 세션을 생성하는 데 하나의 MFA 디바이스만 필요합니다.

**참고**  
인간 사용자가 AWS에 액세스할 때 임시 보안 인증을 사용하도록 하는 것이 좋습니다. AWS IAM Identity Center 사용을 고려해 보셨나요? IAM Identity Center를 사용하여 여러 AWS 계정에 대한 액세스를 중앙에서 관리하고 사용자에게 한 곳에서 할당된 모든 계정에 대한 MFA 보호 Single Sign-On 액세스를 제공할 수 있습니다. IAM Identity Center를 사용하면 IAM Identity Center에서 사용자 자격 증명을 생성하고 관리하거나 기존 SAML 2.0 호환 자격 증명 제공업체에 쉽게 연결할 수 있습니다. 자세한 정보는 *AWS IAM Identity Center 사용 설명서*의 [IAM Identity Center란 무엇인가요?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) 섹션을 참조하세요.

MFA는 AWS 웹 사이트 또는 서비스에 액세스할 때 사용자의 로그인 자격 증명 외에도 AWS가 지원되는 MFA 메커니즘의 고유 인증을 제출하라고 요청함으로써 보안을 더욱 강화합니다.

## MFA 유형
<a name="id_credentials_mfa-types"></a>

AWS는 다음과 같은 MFA 유형을 지원합니다.

**Contents**
+ [

### 패스키 및 보안 키
](#passkeys-security-keys-for-iam-users)
+ [

### 가상 인증 애플리케이션
](#virtual-auth-apps-for-iam-users)
+ [

### 하드웨어 TOTP 토큰
](#hardware-totp-token-for-iam-users)

### 패스키 및 보안 키
<a name="passkeys-security-keys-for-iam-users"></a>

AWS Identity and Access Management는 MFA용 패스키 및 보안 키를 지원합니다. FIDO 표준에 기반한 패스키는 퍼블릭 키 암호화 기법을 사용하여 암호보다 안전한 강력한 피싱 방지 인증을 제공합니다. AWS는 디바이스 바운드 패스키(보안 키)와 동기화된 패스키라는 두 가지 유형의 패스키를 지원합니다.
+ **보안 키**: YubiKey처럼 2차 인증 요소로 사용되는 물리적 디바이스입니다. 하나의 보안 키가 여러 루트 사용자 계정과 IAM 사용자를 지원할 수 있습니다.
+ **동기화된 패스키**: Google, Apple, Microsoft 계정 같은 공급자와 1Password, Dashlane, Bitwarden 같은 서드 파티 서비스의 자격 증명 관리자를 2차 인증 요소로 사용합니다.

Apple MacBook의 Touch ID와 같은 내장된 생체 인식 인증자를 사용하여 자격 증명 관리자의 잠금을 해제하고 AWS에 로그인할 수 있습니다. 패스키는 지문, 얼굴 또는 디바이스 PIN을 사용하여 선택한 공급자와 함께 생성됩니다. 또한 모바일 디바이스 또는 하드웨어 보안 키와 같은 한 디바이스에 있는 교차 디바이스 인증(CDA) 패스키로 노트북 등의 다른 디바이스에 로그인할 수 있습니다. 자세한 내용은 [교차 디바이스 인증](https://passkeys.dev/docs/reference/terms/#cross-device-authentication-cda)(CDA)을 참조하세요.

디바이스 간에 패스키를 동기화하여 AWS 로그인을 용이하게 하고 사용성과 복구 가능성을 높일 수 있습니다. 패스키 및 보안 키 활성화에 대한 자세한 내용은 [루트 사용자용 패스키 또는 보안 키 활성화(콘솔)](enable-fido-mfa-for-root.md) 섹션을 참조하세요.

FIDO Alliance는 FIDO 사양과 호환되는 모든 [FIDO 인증 제품](https://fidoalliance.org/certification/fido-certified-products/) 목록을 유지 관리합니다.

### 가상 인증 애플리케이션
<a name="virtual-auth-apps-for-iam-users"></a>

가상 인증 애플리케이션은 전화 또는 기타 디바이스에서 실행되고 물리적 디바이스를 에뮬레이트합니다. 가상 인증 앱은 [시간 기반 일회용 암호](https://datatracker.ietf.org/doc/html/rfc6238)(TOTP) 알고리즘을 구현하고 단일 디바이스에서 여러 토큰을 지원합니다. 사용자는 로그인 중에 안내에 따라 디바이스의 유효 코드를 입력해야 합니다. 사용자에게 할당된 각 토큰은 고유해야 합니다. 사용자는 다른 사용자의 토큰의 코드를 입력하여 인증할 수 없습니다.

가장 강력한 보호를 위해 [패스키나 보안 키](#passkeys-security-keys-for-iam-users) 등의 피싱 방지 MFA를 사용하는 것이 좋습니다. 아직 패스키나 보안 키를 사용할 수 없는 경우 하드웨어 구매 승인이나 하드웨어 도착을 기다리는 동안 임시 조치로 가상 MFA 디바이스를 사용하는 것이 좋습니다. 가상 MFA 디바이스로 사용할 수 있는 몇 가지 지원되는 앱의 목록은 [다중 인증(MFA)](https://aws.amazon.com/iam/features/mfa/?audit=2019q1) 섹션을 참조하세요.

IAM 사용자를 위한 가상 MFA 디바이스 설정 지침은 [AWS Management Console에서 가상 MFA 디바이스 할당](id_credentials_mfa_enable_virtual.md) 섹션을 참조하세요.

**참고**  
AWS 계정에서 할당되지 않은 가상 MFA 디바이스는 로그인 프로세스 중에 또는 AWS Management Console을 통해 새 가상 MFA 디바이스를 추가할 때 삭제됩니다. 할당되지 않은 가상 MFA 디바이스는 계정의 디바이스이지만 계정 루트 사용자 또는 IAM 사용자가 로그인 프로세스에 사용하지 않습니다. 새 가상 MFA 디바이스를 계정에 추가할 수 있도록 해당 디바이스는 삭제됩니다. 또한 디바이스 이름을 재사용할 수 있습니다.  
계정에서 할당되지 않은 가상 MFA 디바이스를 보려면 [list-virtual-mfa-devices](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-virtual-mfa-devices.html) AWS CLI 명령 또는 [API](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListVirtualMFADevices.html) 직접 호출을 사용할 수 있습니다.
가상 MFA 디바이스를 비활성화하려면 [deactivate-mfa-device](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/deactivate-mfa-device.html) AWS CLI 명령 또는 [API](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html) 직접 호출을 사용할 수 있습니다. 디바이스가 할당 해제됩니다.
할당되지 않은 가상 MFA 디바이스를 AWS 계정 루트 사용자 또는 IAM 사용자에게 연결하려면 [enable-mfa-device](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/enable-mfa-device.html) AWS CLI 명령 또는 [API](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html) 직접 호출과 함께 디바이스에서 생성된 인증 코드가 필요합니다.

### 하드웨어 TOTP 토큰
<a name="hardware-totp-token-for-iam-users"></a>

하드웨어 디바이스가 [시간 기반 일회용 암호(TOTP) 알고리즘](https://datatracker.ietf.org/doc/html/rfc6238)에 따라 6자리 숫자 코드를 생성합니다. 사용자는 로그인할 때 두 번째 웹페이지에서 디바이스의 유효 코드를 입력해야 합니다.

이러한 토큰은 AWS 계정에서만 사용됩니다. 고유한 토큰 시드가 AWS에 안전하게 공유된 토큰만 사용할 수 있습니다. 토큰 시드는 토큰 생성 시 생성되는 비밀 키입니다. 다른 소스에서 구매한 토큰은 IAM에서 작동하지 않습니다. 호환성 보장을 위해 [OTP 토큰](https://www.amazon.com/SafeNet-IDProve-Time-based-6-Digit-Services/dp/B002CRN5X8) 또는 [OTP 디스플레이 카드](https://www.amazon.com/SafeNet-IDProve-Card-Amazon-Services/dp/B00J4NGUO4) 링크 중 하나에서 하드웨어 MFA 디바이스를 구매해야 합니다.
+ 사용자에게 할당된 각 MFA 디바이스는 고유해야 합니다. 사용자는 다른 사용자의 디바이스의 코드를 입력하여 인증받을 수 없습니다. 지원되는 하드웨어 MFA 디바이스에 대한 자세한 내용은 [다중 인증(MFA)](https://aws.amazon.com/iam/features/mfa/?audit=2019q1) 섹션을 참조하세요.
+ 물리적 MFA 디바이스를 사용하려는 경우 하드웨어 TOTP 디바이스 대신 보안 키를 사용하는 것이 좋습니다. 보안 키는 배터리 요구 사항이 없고, 피싱 방지 기능이 있으며, 단일 디바이스에서 여러 사용자를 지원합니다.

패스키 또는 보안 키는 AWS Management Console에서만 활성화할 수 있으며, AWS CLI 또는 AWS API에서는 활성화할 수 없습니다. 보안 키를 활성화하려면 디바이스에 물리적으로 액세스할 수 있어야 합니다.

IAM 사용자를 위한 하드웨어 TOTP 토큰 설정 지침은 [AWS Management Console에서 하드웨어 TOTP 토큰 할당](id_credentials_mfa_enable_physical.md) 섹션을 참조하세요.

**참고**  
**SMS 문자 메시지 기반 MFA** - AWS는 SMS 다중 인증(MFA) 활성화에 대한 지원을 종료했습니다. SMS 문자 메시지 기반 MFA를 사용하는 IAM 사용자가 있는 고객은 [패스키 또는 보안 키](id_credentials_mfa_enable_fido.md), [가상(소프트웨어 기반) MFA 디바이스](id_credentials_mfa_enable_virtual.md) 또는 [하드웨어 MFA 디바이스](id_credentials_mfa_enable_physical.md)와 같은 대체 방법 중 하나로 전환하는 것이 좋습니다. 계정의 사용자 중에서 SMS MFA 디바이스가 할당된 사용자를 식별할 수 있습니다. IAM 콘솔의 탐색 창에서 **사용자(Users)**를 선택하고 표의 **MFA** 열에 **SMS**가 표시된 사용자를 찾습니다.

## MFA 권장 사항
<a name="id_credentials_mfa-recommendations"></a>

AWS 자격 증명을 안전하게 보호할 수 있도록 다음의 MFA 인증 권장 사항을 따르세요.
+ MFA 디바이스로 [패스키, 보안 키](#passkeys-security-keys-for-iam-users) 등의 피싱 방지 MFA를 사용하는 것이 좋습니다. 이러한 FIDO 기반 인증자는 피싱 등의 공격으로부터 가장 강력한 보호를 제공합니다.
+ AWS 계정 루트 사용자 및 AWS 계정의 IAM 사용자에 대해 여러 MFA 디바이스를 활성화하는 것이 좋습니다. 이를 통해 AWS 계정의 보안 기준을 높이고 AWS 계정 루트 사용자 등의 권한이 높은 사용자에 대한 액세스 관리를 간소화할 수 있습니다.
+ [현재 지원되는 MFA 유형](https://aws.amazon.com/iam/features/mfa/)을 조합하여 최대 **8**개의 MFA 디바이스를 AWS 계정 루트 사용자 및 IAM 사용자에게 등록할 수 있습니다. MFA 디바이스가 여러 개인 경우 AWS Management Console에 로그인하거나 해당 사용자로 AWS CLI를 통해 세션을 생성하는 데 하나의 MFA 디바이스만 필요합니다. 추가 MFA 디바이스를 활성화하거나 비활성화하려면 IAM 사용자가 기존 MFA 디바이스로 인증해야 합니다.
+ MFA 디바이스를 분실했거나, 도난당했거나, 액세스할 수 없는 경우 나머지 MFA 디바이스 중 하나를 사용하여 AWS 계정 복구 절차를 수행하지 않고 AWS 계정에 액세스할 수 있습니다. MFA 디바이스를 분실하거나 도난당한 경우 해당 디바이스와 연결된 IAM 보안 주체에서 연결을 해제해야 합니다.
+ 여러 MFA를 사용하면 지리적으로 분산된 위치에 있거나 원격으로 작업하는 경우 직원 간에 단일 하드웨어 디바이스의 물리적 교환을 조정할 필요 없이 하드웨어 기반 MFA를 사용하여 AWS에 액세스할 수 있습니다.
+ IAM 보안 주체에 추가 MFA 디바이스를 사용하면 일상적인 사용에 하나 이상의 MFA를 사용할 수 있으며, 백업 및 중복성을 위해 보관실 또는 금고와 같은 안전한 물리적 위치에 물리적 MFA 디바이스를 보관할 수 있습니다.

**참고**  
AWS STS API 작업에 보안 키나 패스키의 MFA 정보를 전달하여 임시 자격 증명을 요청할 수 없습니다. 보안 키나 패스키를 사용할 때 `aws login` 명령을 실행하여 AWS CLI 및 AWS SDK에서 사용할 자격 증명을 얻을 수 있습니다.
AWS CLI 명령 또는 AWS API 작업을 사용하여 [FIDO 보안 키](id_credentials_mfa_enable_fido.md)를 활성화할 수 없습니다.
둘 이상의 루트 사용자 또는 IAM MFA 디바이스에 동일한 이름을 사용할 수 없습니다.

## 추가 리소스
<a name="id_credentials_mfa-resources"></a>

다음 리소스는 MFA에 대해 자세히 알아보는 데 도움이 됩니다.
+ AWS를 사용하여 리소스에 액세스하는 방법에 대한 자세한 내용은 [MFA 지원 로그인](console_sign-in-mfa.md) 단원을 참조하세요.
+  IAM Identity Center를 활용하여 AWS 액세스 포털, IAM Identity Center 통합 앱, AWS CLI에 대한 보안 MFA 액세스를 활성화할 수 있습니다. 자세한 내용은 [IAM Identity Center에서 MFA 활성화](https://docs.aws.amazon.com/singlesignon/latest/userguide/mfa-getting-started.html)를 참조하세요.

# AWS Management Console에서 패스키 또는 보안 키 할당
<a name="id_credentials_mfa_enable_fido"></a>

패스키는 AWS 리소스를 보호하기 위해 사용할 수 있는 [다중 인증(MFA) 디바이스](id_credentials_mfa.md)의 한 유형입니다. AWS는 동기화된 패스키와 디바이스 바운드 패스키(보안 키라고도 함)를 지원합니다.

동기화된 패스키를 사용하면 IAM 사용자가 모든 계정에서 모든 디바이스를 다시 등록할 필요 없이 새 디바이스를 비롯한 여러 디바이스에서 FIDO 로그인 자격 증명에 액세스할 수 있습니다. 동기화된 패스키에는 Google, Apple, Microsoft 같은 퍼스트 파티 자격 증명 관리자와 1Password, Dashlane, Bitwarden 같은 서드 파티 자격 증명 관리자가 2차 인증 요소로 포함됩니다. 온디바이스 생체 인식(예: TouchID)을 사용하여 선택한 자격 증명 관리자의 잠금을 해제하여 패스키를 사용할 수도 있습니다.

또는 디바이스 바운드 패스키를 FIDO 보안 키에 바인딩하고 FIDO 보안 키를 컴퓨터의 USB 포트에 꽂은 다음 메시지가 표시되면 탭하여 로그인 절차를 안전하게 완료할 수 있습니다. 이미 다른 서비스에 FIDO 보안 키를 사용 중이고 [AWS가 지원되는 구성](id_credentials_mfa_fido_supported_configurations.md)(예: Yubico의 YubiKey 5 시리즈)을 보유한 경우 AWS에도 사용할 수 있습니다. 그렇지 않은 경우 AWS의 MFA에 WebAuthn을 사용하려면 FIDO 보안 키를 구입해야 합니다. 또한 FIDO 보안 키는 동일한 기기에서 여러 IAM 또는 루트 사용자를 지원하여 계정 보안을 위한 유틸리티를 강화할 수 있습니다. 두 디바이스 유형의 사양 및 구입 관련 정보는 [멀티 팩터 인증](https://aws.amazon.com/iam/details/mfa/) 섹션을 참조하세요.

[현재 지원되는 MFA 유형](https://aws.amazon.com/iam/features/mfa/)을 조합하여 최대 **8**개의 MFA 디바이스를 AWS 계정 루트 사용자 및 IAM 사용자에게 등록할 수 있습니다. MFA 디바이스가 여러 개인 경우 AWS Management Console에 로그인하거나 해당 사용자로 AWS CLI를 통해 세션을 생성하는 데 하나의 MFA 디바이스만 필요합니다. 여러 개의 MFA 디바이스를 등록하는 것이 좋습니다. 예를 들어 내장된 인증자를 등록하고 물리적으로 안전한 위치에 보관하는 보안 키를 등록할 수 있습니다. 내장된 인증자를 사용할 수 없는 경우 등록된 보안 키를 사용할 수 있습니다. 인증 애플리케이션의 경우 인증 앱이 포함된 디바이스를 분실하거나 고장이 발생한 경우 계정에 대한 액세스 권한을 잃지 않도록 해당 앱에서 클라우드 백업 또는 동기화 기능을 활성화하는 것이 좋습니다.

**참고**  
인간 사용자가 AWS에 액세스할 때 임시 보안 인증을 사용하도록 하는 것이 좋습니다. 사용자는 ID 제공업체와 함께 AWS에 연동하여 회사 보안 인증 및 MFA 구성으로 인증할 수 있습니다. AWS 및 비즈니스 애플리케이션에 대한 액세스를 관리하려면 IAM Identity Center를 사용하는 것이 좋습니다. 자세한 내용은 [IAM Identity Center 사용 설명서](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)를 참조하세요.

**Topics**
+ [

## 필요한 권한
](#enable-fido-mfa-for-iam-user-permissions-required)
+ [

## 자체 IAM 사용자 패스키 또는 보안 키 활성화(콘솔)
](#enable-fido-mfa-for-own-iam-user)
+ [

## 다른 IAM 사용자에 대한 패스키 또는 보안 키 활성화(콘솔)
](#enable-fido-mfa-for-iam-user)
+ [

## 패스키 또는 보안 키 교체
](#replace-fido-mfa)
+ [

# 패스키 및 보안 키 사용이 지원되는 구성
](id_credentials_mfa_fido_supported_configurations.md)

## 필요한 권한
<a name="enable-fido-mfa-for-iam-user-permissions-required"></a>

민감한 MFA 관련 작업을 보호하면서 자체 IAM 사용자의 FIDO 패스키를 관리하려면 다음 정책에 따른 권한이 있어야 합니다.

**참고**  
ARN 값은 정적 값이며 인증을 등록하는 데 사용된 프로토콜을 나타내는 지표가 아닙니다. U2F는 더 이상 사용되지 않으므로 모든 새 구현에서 WebAuthn을 사용합니다.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowManageOwnUserMFA",
            "Effect": "Allow",
            "Action": [
                "iam:DeactivateMFADevice",
                "iam:EnableMFADevice",
                "iam:GetUser",
                "iam:ListMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "DenyAllExceptListedIfNoMFA",
            "Effect": "Deny",
            "NotAction": [
                "iam:EnableMFADevice",
                "iam:GetUser",
                "iam:ListMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}
```

------

## 자체 IAM 사용자 패스키 또는 보안 키 활성화(콘솔)
<a name="enable-fido-mfa-for-own-iam-user"></a>

자체 IAM 사용자의 패스키 또는 보안 키는 AWS Management Console에서만 활성화할 수 있으며, AWS CLI 또는 AWS API에서는 활성화할 수 없습니다. 보안 키를 활성화하려면 디바이스에 물리적으로 액세스할 수 있어야 합니다.

**자체 IAM 사용자 패스키 또는 보안 키를 활성화하려면(콘솔)**

1. AWS 계정 ID나 계정 별칭, IAM 사용자 이름 및 암호를 사용하여 [IAM 콘솔](https://console.aws.amazon.com/iam)에 로그인합니다.
**참고**  
사용자 편의를 위해 AWS 로그인 페이지는 브라우저 쿠키를 사용하여 IAM 사용자 이름 및 계정 정보를 기억합니다. 이전에 다른 사용자로 로그인한 경우 페이지 하단 근처의 **다른 계정에 로그인(Sign in to a different account)**을 선택하여 기본 로그인 페이지로 돌아갑니다. 여기서 AWS 계정 ID 또는 계정 별칭을 입력하면 계정의 IAM 사용자 로그인 페이지로 리디렉션됩니다.

   AWS 계정 ID를 받으려면 관리자에게 문의하세요.

1. 오른쪽 상단의 탐색 모음에서 사용자 이름을 선택한 다음 **Security credentials**(보안 자격 증명)를 선택합니다.  
![\[AWS Management Console 보안 자격 증명 링크\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. 선택한 IAM 사용자의 페이지에서 **보안 자격 증명** 탭을 선택합니다.

1. **Multi-factor authentication (MFA)**(다중 인증(MFA)) 섹션에서 **Assign MFA device**(MFA 디바이스 할당)를 선택합니다.

1. **MFA 디바이스 이름** 페이지에서 **디바이스 이름**을 입력하고 **패스키 또는 보안 키**를 선택한 후 **다음**을 선택합니다.

1. **디바이스 설정**에서 패스키를 설정합니다. 얼굴이나 지문 같은 생체 인식 데이터 또는 디바이스 PIN을 사용하거나 컴퓨터의 USB 포트에 FIDO 보안 키를 삽입한 다음 탭하여 패스키를 생성합니다.

1. 브라우저의 지침을 따른 다음 **계속**을 선택합니다.

이제 AWS에서 사용할 패스키 또는 보안 키를 등록했습니다. AWS Management Console의 MFA 사용 방법에 대한 자세한 내용은 [MFA 지원 로그인](console_sign-in-mfa.md) 섹션을 참조하세요.

## 다른 IAM 사용자에 대한 패스키 또는 보안 키 활성화(콘솔)
<a name="enable-fido-mfa-for-iam-user"></a>

AWS Management Console에서만 다른 IAM 사용자에 대한 패스키 또는 보안 키를 활성화할 수 있으며, AWS CLI 또는 AWS API에서는 활성화할 수 없습니다.

**다른 IAM 사용자에 대한 패스키 또는 보안 키를 활성화하려면(콘솔)**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. **사용자**에서 MFA를 활성화하려는 사용자의 이름을 선택합니다.

1. 선택한 IAM 사용자 페이지에서 **보안 자격 증명**명 탭을 선택합니다.

1. **Multi-factor authentication (MFA)**(다중 인증(MFA)) 섹션에서 **Assign MFA device**(MFA 디바이스 할당)를 선택합니다.

1. **MFA 디바이스 이름** 페이지에서 **디바이스 이름**을 입력하고 **패스키 또는 보안 키**를 선택한 후 **다음**을 선택합니다.

1. **디바이스 설정**에서 패스키를 설정합니다. 얼굴이나 지문 같은 생체 인식 데이터 또는 디바이스 PIN을 사용하거나 컴퓨터의 USB 포트에 FIDO 보안 키를 삽입한 다음 탭하여 패스키를 생성합니다.

1. 브라우저의 지침을 따른 다음 **계속**을 선택합니다.

이제 AWS에서 사용할 다른 IAM 사용자의 패스키 또는 보안 키를 등록했습니다. AWS Management Console의 MFA 사용 방법에 대한 자세한 내용은 [MFA 지원 로그인](console_sign-in-mfa.md) 섹션을 참조하세요.

## 패스키 또는 보안 키 교체
<a name="replace-fido-mfa"></a>

[현재 지원되는 MFA 유형](https://aws.amazon.com/iam/features/mfa/)을 조합하여 한 번에 최대 8개의 MFA 디바이스를 사용자에게 AWS 계정 루트 사용자 및 IAM 사용자와 함께 할당할 수 있습니다. 사용자가 FIDO 인증을 분실했거나 어떤 이유로든 교체해야 하는 경우 먼저 이전 FIDO 인증을 비활성화해야 합니다. 그런 다음, 해당 사용자를 위한 새 MFA 디바이스를 추가할 수 있습니다.
+ 현재 IAM 사용자와 연결된 디바이스를 비활성화하는 방법은 [MFA 디바이스 비활성화](id_credentials_mfa_disable.md) 섹션을 참조하세요.
+ IAM 사용자에 대한 새 FIDO 보안 키를 추가하려면 [자체 IAM 사용자 패스키 또는 보안 키 활성화(콘솔)](#enable-fido-mfa-for-own-iam-user) 섹션을 참조하세요.

새로운 패스키 또는 보안 키에 대한 액세스 권한이 없는 경우 새로운 가상 MFA 디바이스 또는 하드웨어 TOTP 토큰을 활성화할 수 있습니다. 관련 지침을 보려면 다음 중 하나를 참조하세요.
+ [AWS Management Console에서 가상 MFA 디바이스 할당](id_credentials_mfa_enable_virtual.md) 
+ [AWS Management Console에서 하드웨어 TOTP 토큰 할당](id_credentials_mfa_enable_physical.md) 

# 패스키 및 보안 키 사용이 지원되는 구성
<a name="id_credentials_mfa_fido_supported_configurations"></a>

현재 지원되는 구성을 사용하여 IAM에서 FIDO2 디바이스 바운드 패스키(보안 키라고도 함)를 다중 인증(MFA) 방법으로 사용할 수 있습니다. 여기에는 IAM에서 지원하는 FIDO2 디바이스와 FIDO2를 지원하는 브라우저가 포함됩니다. FIDO2 장치를 등록하기 전에 최신 브라우저 및 운영 체제(OS) 버전을 사용하고 있는지 확인하세요. 기능은 브라우저, 인증자, OS 클라이언트마다 다르게 작동할 수 있습니다. 한 브라우저에서 디바이스 등록이 실패하는 경우 다른 브라우저로 등록을 시도할 수 있습니다.

FIDO2는 퍼블릭 키 암호화를 기반으로 동일한 높은 수준의 보안을 제공하는 개방형 인증 표준이자 FIDO U2F의 확장입니다. FIDO2는 W3C 웹 인증 사양(WebAuthn API)과 애플리케이션 계층 프로토콜인 FIDO Alliance CTAP(Client-to-Authenticator Protocol)로 구성됩니다. CTAP는 외부 인증자를 사용하여 브라우저나 운영 체제와 같은 플랫폼이나 클라이언트 간의 통신을 가능하게 합니다. AWS에서 FIDO 인증 인증자를 활성화하면 보안 키는 AWS에서만 사용할 새 키 페어를 생성합니다. 먼저 자격 증명을 입력합니다. 메시지가 나타나면 보안 키를 탭하여 AWS가 발급한 인증 챌린지에 응답합니다. FIDO2 표준에 대한 자세한 내용을 알아보려면 [FIDO2 Project](https://en.wikipedia.org/wiki/FIDO2_Project)(FIDO2 프로젝트)를 참조하세요.

## AWS에서 지원하는 FIDO2 디바이스
<a name="id_credentials_mfa_fido_supported_devices"></a>

IAM은 USB, Bluetooth 또는 NFC를 통해 디바이스에 연결하는 FIDO2 보안 디바이스를 지원합니다. IAM은 TouchID, FaceID 등의 플랫폼 인증자도 지원합니다. IAM은 Windows Hello에 대한 로컬 패스키 등록을 지원하지 않습니다. 패스키를 생성하고 사용하려면 Windows 사용자는 모바일 디바이스와 같은 한 디바이스의 패스키나 하드웨어 보안 키를 사용하여 노트북 등의 다른 디바이스에 로그인하는 [크로스 디바이스 인증](https://passkeys.dev/docs/reference/terms/#cross-device-authentication-cda)을 사용해야 합니다.

**참고**  
AWS의 경우 FIDO2 디바이스 검사를 위해 컴퓨터에 있는 물리적 USB 포트에 대한 액세스가 필요합니다. 보안 키는 가상 머신, 원격 연결 또는 브라우저의 익명 모드에서 작동하지 않습니다.

FIDO Alliance는 FIDO 사양과 호환되는 모든 [FIDO2 제품](https://fidoalliance.org/certification/fido-certified-products/) 목록을 유지 관리합니다.

## FIDO2 지원 브라우저
<a name="id_credentials_mfa_fido_browsers"></a>

웹 브라우저에서 실행되는 FIDO2 보안 장치의 사용 가능 여부는 어떤 브라우저와 운영 체제를 함께 사용하는지에 따라 달라집니다. 현재 보안 키 사용을 지원하는 브라우저는 다음과 같습니다.


****  

| 웹 브라우저 | macOS 10.15 이상 | Windows 10 | Linux | iOS 14.5 이상 | Android 7 이상 | 
| --- | --- | --- | --- | --- | --- | 
| Chrome | 예 | 예 | 예 | 예 | 아니요 | 
| Safari | 예 | 아니요 | 아니요 | 예 | 아니요 | 
| Edge | 예 | 예 | 아니요 | 예 | 아니요 | 
| Firefox | 예 | 예 | 아니요 | 예 | 아니요 | 

**참고**  
현재 FIDO2를 지원하는 대부분의 Firefox 버전에서는 기본적으로 지원을 활성화하지 않습니다. Firefox에서 FIDO2 지원을 활성하기 위한 지침은 [패스키 및 FIDO 보안 키 관련 문제 해결](troubleshoot_mfa-fido.md) 섹션을 참조하세요.  
macOS의 Firefox는 패스키에 대한 교차 디바이스 인증 워크플로를 완전히 지원하지 않을 수 있습니다. 교차 디바이스 인증을 진행하는 대신 보안 키를 터치하라는 프롬프트가 표시될 수 있습니다. macOS에서 패스키로 로그인하려면 Chrome 또는 Safari와 같은 다른 브라우저를 사용하는 것이 좋습니다.

FIDO2 인증 디바이스(예: YubiKey)의 브라우저 지원에 대한 자세한 내용은 [FIDO2 및 U2F에 대한 운영 체제 및 웹 브라우저 지원](https://support.yubico.com/hc/en-us/articles/360016615020-Operating-system-and-web-browser-support-for-FIDO2-and-U2F)을 참조하세요.

### 브라우저 플러그 인
<a name="id_credentials_mfa_fido_plugins"></a>

AWS는 FIDO2를 기본적으로 지원하는 브라우저만 지원합니다. AWS는 FIDO2 브라우저 지원을 추가하기 위한 플러그인 사용을 지원하지 않습니다. 일부 브라우저 플러그인은 FIDO2 표준과 호환되지 않으며 FIDO2 보안 키와 연결할 때 예기치 않은 결과를 초래할 수 있습니다.

브라우저 플러그인 비활성화 및 기타 문제 해결을 위한 자세한 내용은 [FIDO 보안 키를 활성화할 수 없습니다.](troubleshoot_mfa-fido.md#troubleshoot_mfa-fido-cant-enable) 섹션을 참조하세요.

## 디바이스 인증
<a name="id_credentials_mfa_fido_certifications"></a>

보안 키를 등록하는 동안에만 FIPS 검증 및 FIDO 인증 등급과 같은 디바이스 관련 인증을 캡처하고 할당합니다. 디바이스 인증은 [FIDO Alliance 메타데이터 서비스(MDS)](https://fidoalliance.org/metadata/)에서 가져옵니다. 보안 키의 인증 상태 또는 등급이 변경될 경우, 디바이스 태그에 자동으로 반영되지 않습니다. 디바이스의 인증 정보를 업데이트하려면 디바이스를 다시 등록하여 업데이트된 인증 정보를 가져와야 합니다.

AWS는 디바이스 등록 시 FIDO MDS에서 획득한 FIPS-140-2, FIPS-140-3 및 FIDO 인증 등급과 같은 인증 유형을 조건 키로 제공합니다. 선호하는 인증 유형 및 등급에 따라 IAM 정책에서 특정 인증자의 등록을 지정할 수 있습니다. 자세한 내용은 아래의 정책을 참조하세요.

### 디바이스 인증을 위한 예제 정책
<a name="id_credentials_mfa_fido_certifications_policies"></a>

다음 사용 사례는 FIPS 인증을 사용하여 MFA 디바이스를 등록할 수 있도록 허용하는 샘플 정책을 보여줍니다.

**Topics**
+ [

#### 사용 사례 1: FIPS-140-2 L2 인증을 받은 디바이스만 등록 허용
](#id_credentials_mfa_fido_certifications_policies_use_case_1)
+ [

#### 사용 사례 2: FIPS-140-2 L2 및 FIDO L1 인증을 받은 디바이스의 등록 허용
](#id_credentials_mfa_fido_certifications_policies_use_case_2)
+ [

#### 사용 사례 3: FIPS-140-2 L2 또는 FIPS-140-3 L2 인증을 받은 디바이스의 등록 허용
](#id_credentials_mfa_fido_certifications_policies_use_case_3)
+ [

#### 사용 사례 4: FIPS-140-2 L2 인증이 있고 가상 인증 및 하드웨어 TOTP와 같은 기타 MFA 유형을 지원하는 디바이스의 등록 허용
](#id_credentials_mfa_fido_certifications_policies_use_case_4)

#### 사용 사례 1: FIPS-140-2 L2 인증을 받은 디바이스만 등록 허용
<a name="id_credentials_mfa_fido_certifications_policies_use_case_1"></a>

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [{
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Create"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Activate",
                    "iam:FIDO-FIPS-140-2-certification": "L2"
                }
            }
        }
    ]
}
```

------

#### 사용 사례 2: FIPS-140-2 L2 및 FIDO L1 인증을 받은 디바이스의 등록 허용
<a name="id_credentials_mfa_fido_certifications_policies_use_case_2"></a>

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [{
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Create"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Activate",
                    "iam:FIDO-FIPS-140-2-certification": "L2",
                    "iam:FIDO-certification": "L1"
                }
            }
        }
    ]
}
```

------

#### 사용 사례 3: FIPS-140-2 L2 또는 FIPS-140-3 L2 인증을 받은 디바이스의 등록 허용
<a name="id_credentials_mfa_fido_certifications_policies_use_case_3"></a>

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [{
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Create"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Activate",
                    "iam:FIDO-FIPS-140-2-certification": "L2"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Activate",
                    "iam:FIDO-FIPS-140-3-certification": "L2"
                }
            }
        }
    ]
}
```

------

#### 사용 사례 4: FIPS-140-2 L2 인증이 있고 가상 인증 및 하드웨어 TOTP와 같은 기타 MFA 유형을 지원하는 디바이스의 등록 허용
<a name="id_credentials_mfa_fido_certifications_policies_use_case_4"></a>

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iam:EnableMFADevice",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "iam:RegisterSecurityKey": "Create"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": "iam:EnableMFADevice",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "iam:RegisterSecurityKey": "Activate",
          "iam:FIDO-FIPS-140-2-certification": "L2"
        }
      }
    },
    {
      "Effect": "Allow",
      "Action": "iam:EnableMFADevice",
      "Resource": "*",
      "Condition": {
        "Null": {
          "iam:RegisterSecurityKey": "true"
        }
      }
    }
  ]
}
```

------

## AWS CLI 및 AWS API
<a name="id_credentials_mfa_fido_cliapi"></a>

AWS는 AWS Management Console에서만 패스키 및 보안 키 사용을 지원합니다. MFA에서의 패스키 및 보안 키 사용은 [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/) 및 [AWS API](https://aws.amazon.com/tools/) 또는 [MFA 보호 API 작업](id_credentials_mfa_configure-api-require.md)에 대한 액세스에서는 지원되지 않습니다.

## 추가 리소스
<a name="id_credentials_mfa_fido_additional_resources"></a>
+ AWS에서의 패스키 및 보안 키 사용에 대한 자세한 내용은 [AWS Management Console에서 패스키 또는 보안 키 할당](id_credentials_mfa_enable_fido.md) 섹션을 참조하세요.
+ AWS에서의 패스키 및 보안 키 문제 해결에 대한 도움말은 [패스키 및 FIDO 보안 키 관련 문제 해결](troubleshoot_mfa-fido.md) 섹션을 참조하세요.
+ FIDO2 지원에 대한 일반적인 업계 정보는 [FIDO2 Project](https://en.wikipedia.org/wiki/FIDO2_Project)(FIDO2 프로젝트)를 참조하세요.

# AWS Management Console에서 가상 MFA 디바이스 할당
<a name="id_credentials_mfa_enable_virtual"></a>

**중요**  
AWS는 가능한 한 AWS에 대한 MFA에 패스키나 보안 키를 사용할 것을 권장합니다. 자세한 내용은 [AWS Management Console에서 패스키 또는 보안 키 할당](id_credentials_mfa_enable_fido.md) 섹션을 참조하세요.

스마트폰 또는 기타 디바이스를 가상 MFA 디바이스로 사용할 수 있습니다. 이를 위해서는 [표준 기반 TOTP(시간 기반 일회용 암호) 알고리즘인 RFC 6238](https://datatracker.ietf.org/doc/html/rfc6238)과 호환되는 모바일 앱을 설치해야 합니다. 이러한 앱에서는 6자리 인증 코드가 생성됩니다. 보안이 취약한 모바일 디바이스에서 인증자가 실행될 수 있고 권한이 없는 당사자와 코드가 공유될 수 있기 때문에 TOTP 기반의 MFA는 [FIDO2](https://en.wikipedia.org/wiki/FIDO_Alliance#FIDO2) 보안 키, 패스키 등의 피싱 방지 옵션과 동일한 수준의 보안을 제공하지 않습니다. 피싱 등의 공격으로부터 최대한 강력한 보호를 위해서는 MFA에 패스키나 보안 키를 사용하는 것이 좋습니다.

아직 패스키나 보안 키를 사용할 수 없는 경우 하드웨어 구매 승인이나 하드웨어 도착을 기다리는 동안 임시 조치로 가상 MFA 디바이스를 사용하는 것이 좋습니다.

대부분의 가상 MFA 앱은 여러 개의 가상 디바이스 생성을 지원하므로 여러 개의 AWS 계정이나 사용자에게 동일한 앱을 사용할 수 있습니다. [MFA 유형](https://aws.amazon.com/iam/features/mfa/)을 조합하여 최대 **8**개의 MFA 디바이스를 AWS 계정 루트 사용자 및 IAM 사용자에게 등록할 수 있습니다. AWS Management Console에 로그인하거나 AWS CLI를 통해 세션을 생성하는 데 하나의 MFA 디바이스만 필요합니다. 여러 개의 MFA 디바이스를 등록하는 것이 좋습니다. 인증 애플리케이션의 경우 디바이스를 분실하거나 고장이 발생한 경우 계정에 대한 액세스 권한을 잃지 않도록 클라우드 백업 또는 동기화 기능을 활성화하는 것이 좋습니다.

AWS에서 사용하려면 가상 MFA 앱이 6자리 OTP를 생성해야 합니다. 사용할 수 있는 가상 MFA 앱 목록은 [멀티 팩터 인증](https://aws.amazon.com/iam/features/mfa/?audit=2019q1) 섹션을 참조하세요.

**Topics**
+ [

## 필요한 권한
](#mfa_enable_virtual_permissions-required)
+ [

## IAM 사용자에 대한 가상 MFA 디바이스 활성화(콘솔)
](#enable-virt-mfa-for-iam-user)
+ [

## 가상 MFA 디바이스 교체
](#replace-virt-mfa)

## 필요한 권한
<a name="mfa_enable_virtual_permissions-required"></a>

IAM 사용자의 가상 MFA 디바이스를 관리하려면 [AWS: MFA 인증 IAM 사용자가 보안 인증 페이지에서 자신의 MFA 디바이스를 관리할 수 있도록 허용](reference_policies_examples_aws_my-sec-creds-self-manage-mfa-only.md) 정책에 따른 권한이 있어야 합니다.

## IAM 사용자에 대한 가상 MFA 디바이스 활성화(콘솔)
<a name="enable-virt-mfa-for-iam-user"></a>

AWS Management Console에서 IAM을 사용하여 계정의 IAM 사용자를 위한 가상 MFA 디바이스를 활성화 및 관리할 수 있습니다. 가상 MFA 디바이스를 비롯한 IAM 리소스에 태그를 연결하여 액세스를 식별, 구성 및 제어할 수 있습니다. AWS CLI 또는 AWS API를 사용하는 경우에만 가상 MFA 디바이스를 태깅할 수 있습니다. AWS CLI 또는 AWS API를 사용하여 MFA 장치를 활성화하고 관리하려면 [AWS CLI 또는 AWS API에서 MFA 디바이스 할당](id_credentials_mfa_enable_cliapi.md) 섹션을 참조하세요. IAM 리소스 태깅에 대한 자세한 내용은 [AWS Identity and Access Management 리소스용 태그](id_tags.md) 섹션을 참조하세요.

**참고**  
MFA를 구성하려면 사용자의 가상 MFA 디바이스가 호스팅되는 하드웨어에 대한 물리적 액세스가 필요합니다. 예를 들어, 스마트폰에서 가상 MFA 디바이스를 실행하는 사용자에게 MFA를 구성할 수 있습니다. 이 경우 마법사를 완료하기 위해 스마트폰을 사용할 수 있어야 합니다. 이러한 이유로 사용자가 자신의 가상 MFA 디바이스를 직접 구성 및 관리할 수 있도록 허용하는 것이 좋습니다. 이 경우에는 사용자에게 필요한 IAM 작업을 수행할 권한을 부여해야 합니다. 이러한 권한을 부여하는 IAM 정책에 대한 자세한 내용과 예는 [IAM 자습서: 사용자가 자신의 자격 증명 및 MFA 설정을 관리하도록 허용](tutorial_users-self-manage-mfa-and-creds.md) 및 예제 정책 [AWS: MFA 인증 IAM 사용자가 보안 인증 페이지에서 자신의 MFA 디바이스를 관리할 수 있도록 허용](reference_policies_examples_aws_my-sec-creds-self-manage-mfa-only.md)의 내용을 참조하세요.

**IAM 사용자에 대한 가상 MFA 디바이스를 활성화하려면(콘솔)**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. **사용자** 목록에서 IAM 사용자 이름을 선택합니다.

1. [**Security Credentials**] 탭을 선택합니다. **Multi-factor authentication (MFA)**(다중 인증(MFA)) 섹션에서 **Assign MFA device**(MFA 디바이스 할당)를 선택합니다.

1. 마법사에서 **디바이스 이름**을 입력하고 **인증 앱**을 선택한 후 **다음**을 선택합니다.

   IAM은 QR 코드 그래픽을 포함하여 가상 MFA 디바이스의 구성 정보를 생성 및 표시합니다. 그래픽은 QR 코드를 지원하지 않는 디바이스 상에서 수동 입력할 수 있는 '보안 구성 키'를 표시한 것입니다.

1. 가상 MFA 앱을 엽니다. 가상 MFA 디바이스의 호스팅에 사용되는 앱 목록은 [멀티 팩터 인증](https://aws.amazon.com/iam/details/mfa/)을 참조하세요.

   가상 MFA 앱이 다수의 가상 MFA 디바이스 또는 계정을 지원하는 경우 새로운 가상 MFA 디바이스 또는 계정을 생성하는 옵션을 선택합니다.

1. MFA 앱의 QR 코드 지원 여부를 결정한 후 다음 중 한 가지를 실행합니다.
   + 마법사에서 **Show QR code(QT 코드 표시)**를 선택한 다음 해당 앱을 사용하여 QR 코드를 스캔합니다. 디바이스의 카메라를 사용하여 코드를 스캔하는 카메라 아이콘 또는 **스캔 모드** 옵션이 있을 수 있습니다.
   + 마법사에서 **Show secret key**(보안 키 표시)를 선택한 다음 MFA 앱에 보안 키를 입력합니다.

   모든 작업을 마치면 가상 MFA 디바이스가 일회용 암호 생성을 시작합니다.

1. **MFA 디바이스 설정** 페이지의 **MFA 코드 1** 상자에 현재 가상 MFA 디바이스에 표시된 일회용 암호를 입력합니다. 디바이스가 새로운 일회용 암호를 생성할 때까지 최대 30초 기다립니다. 그런 다음 두 번째 일회용 암호를 **MFA code 2(MFA 코드 2)** 상자에 입력합니다. **Add MFA**(MFA 추가)를 선택합니다.
**중요**  
코드를 생성한 후 즉시 요청을 제출하세요. 코드를 생성한 후 너무 오래 기다렸다 요청을 제출할 경우 MFA 디바이스가 사용자와 연결은 되지만 MFA 디바이스가 동기화되지 않습니다. 이는 시간 기반 일회용 암호(TOTP)가 잠시 후에 만료되기 때문입니다. 이 경우, [디바이스를 재동기화](id_credentials_mfa_sync.md)할 수 있습니다.

이제 AWS에서 가상 MFA 디바이스를 사용할 준비가 끝났습니다. AWS Management Console의 MFA 사용 방법에 대한 자세한 내용은 [MFA 지원 로그인](console_sign-in-mfa.md) 섹션을 참조하세요.

**참고**  
AWS 계정에서 할당되지 않은 가상 MFA 디바이스는 로그인 프로세스 중에 또는 AWS Management Console을 통해 새 가상 MFA 디바이스를 추가할 때 삭제됩니다. 할당되지 않은 가상 MFA 디바이스는 계정의 디바이스이지만 계정 루트 사용자 또는 IAM 사용자가 로그인 프로세스에 사용하지 않습니다. 새 가상 MFA 디바이스를 계정에 추가할 수 있도록 해당 디바이스는 삭제됩니다. 또한 디바이스 이름을 재사용할 수 있습니다.  
계정에서 할당되지 않은 가상 MFA 디바이스를 보려면 [list-virtual-mfa-devices](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-virtual-mfa-devices.html) AWS CLI 명령 또는 [API](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListVirtualMFADevices.html) 직접 호출을 사용할 수 있습니다.
가상 MFA 디바이스를 비활성화하려면 [deactivate-mfa-device](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/deactivate-mfa-device.html) AWS CLI 명령 또는 [API](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html) 직접 호출을 사용할 수 있습니다. 디바이스가 할당 해제됩니다.
할당되지 않은 가상 MFA 디바이스를 AWS 계정 루트 사용자 또는 IAM 사용자에게 연결하려면 [enable-mfa-device](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/enable-mfa-device.html) AWS CLI 명령 또는 [API](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html) 직접 호출과 함께 디바이스에서 생성된 인증 코드가 필요합니다.

## 가상 MFA 디바이스 교체
<a name="replace-virt-mfa"></a>

MFA 유형을 조합하여 최대 **8개**의 MFA 디바이스를 AWS 계정 루트 사용자 및 IAM 사용자에게 등록할 수 있습니다. 사용자가 디바이스를 분실하거나 이유를 불문하고 교체할 필요가 있을 경우, 기존 디바이스를 비활성화해야 합니다. 그런 다음, 해당 사용자를 위한 새 디바이스를 추가할 수 있습니다.
+ 현재 다른 IAM 사용자와 연결되어 있는 디바이스를 비활성화하는 방법은 [MFA 디바이스 비활성화](id_credentials_mfa_disable.md) 섹션을 참조하세요.
+ 다른 IAM 사용자에 대해 교체용 가상 MFA 디바이스를 추가하려면 위의 [IAM 사용자에 대한 가상 MFA 디바이스 활성화(콘솔)](#enable-virt-mfa-for-iam-user) 절차에 나와 있는 단계를 따르세요.
+ AWS 계정 루트 사용자를 위한 교체용 가상 MFA 디바이스를 추가하려면 [루트 사용자용 가상 MFA 디바이스 활성화(콘솔)](enable-virt-mfa-for-root.md) 절차에 나와 있는 단계를 따릅니다.

# AWS Management Console에서 하드웨어 TOTP 토큰 할당
<a name="id_credentials_mfa_enable_physical"></a>

**중요**  
AWS는 가능한 한 AWS에 대한 MFA에 패스키나 보안 키를 사용할 것을 권장합니다. 자세한 내용은 [AWS Management Console에서 패스키 또는 보안 키 할당](id_credentials_mfa_enable_fido.md) 섹션을 참조하세요.

하드웨어 TOTP 토큰은 시간 기반 일회용 암호(TOTP) 알고리즘에 따라 6자리 숫자 코드를 생성합니다. 사용자는 로그인 과정 중 디바이스의 유효 코드를 입력해야 합니다. 사용자에게 할당된 각 MFA 디바이스는 고유해야 합니다. 사용자는 다른 사용자의 디바이스 코드를 입력하여 인증받을 수 없습니다. MFA 디바이스는 계정이나 사용자 간에 공유할 수 없습니다.

하드웨어 TOTP 토큰과 [FIDO 보안 키](id_credentials_mfa_enable_fido.md)는 모두 본인이 구입한 물리적 디바이스여야 합니다. 하드웨어 MFA 디바이스는 AWS에 로그인할 때 인증을 위한 TOTP 코드를 생성합니다. 이는 배터리를 사용하므로 시간이 지남에 따라 교체 및 AWS 재동기화가 필요할 수 있습니다. 공개 키 암호화를 활용하는 FIDO 보안 키는 배터리가 필요 없으며 원활한 인증 프로세스를 제공합니다. 피싱 방지를 위해 TOTP 장치보다 안전한 FIDO 보안 키를 사용하는 것이 좋습니다. 또한 FIDO 보안 키는 동일한 기기에서 여러 IAM 또는 루트 사용자를 지원하여 계정 보안을 위한 유틸리티를 강화할 수 있습니다. 두 디바이스 유형의 사양 및 구입 관련 정보는 [멀티 팩터 인증](https://aws.amazon.com/iam/details/mfa/) 섹션을 참조하세요.



AWS Management Console, 명령줄 또는 IAM API에서 IAM 사용자의 하드웨어 TOTP 토큰을 활성화할 수 있습니다. AWS 계정 루트 사용자에 따른 MFA 디바이스 활성화 방법은 [루트 사용자에 대해 하드웨어 TOTP 토큰 활성화(콘솔)](enable-hw-mfa-for-root.md) 단원을 참조하세요.

[현재 지원되는 MFA 유형](https://aws.amazon.com/iam/features/mfa/)을 조합하여 최대 **8**개의 MFA 디바이스를 AWS 계정 루트 사용자 및 IAM 사용자에게 등록할 수 있습니다. MFA 디바이스가 여러 개인 경우 AWS Management Console에 로그인하거나 해당 사용자로 AWS CLI를 통해 세션을 생성하는 데 하나의 MFA 디바이스만 필요합니다.

**중요**  
MFA 디바이스를 분실했거나 액세스할 수 없는 경우 사용자가 계정에 계속 액세스할 수 있도록 여러 MFA 디바이스를 활성화하는 것이 좋습니다.

**참고**  
명령줄에서 MFA 디바이스를 활성화하려는 경우 [https://docs.aws.amazon.com/cli/latest/reference/iam/enable-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/enable-mfa-device.html)를 사용합니다. IAM API를 사용하여 MFA 디바이스를 활성화하려면 [https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html) 작업을 사용합니다.

**Topics**
+ [

## 필요한 권한
](#enable-hw-mfa-for-iam-user-permissions-required)
+ [

## 자신의 IAM 사용자에 대해 하드웨어 TOTP 토큰 활성화(콘솔)
](#enable-hw-mfa-for-own-iam-user)
+ [

## 다른 IAM 사용자에 대해 하드웨어 TOTP 토큰 활성화(콘솔)
](#enable-hw-mfa-for-iam-user)
+ [

## 물리적 MFA 디바이스 교체
](#replace-phys-mfa)

## 필요한 권한
<a name="enable-hw-mfa-for-iam-user-permissions-required"></a>

중요한 MFA 관련 작업을 보호하면서 자신의 IAM 사용자에 대한 하드웨어 TOTP 토큰을 관리하려면 다음 정책에 따른 권한이 있어야 합니다.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowManageOwnUserMFA",
            "Effect": "Allow",
            "Action": [
                "iam:DeactivateMFADevice",
                "iam:EnableMFADevice",
                "iam:GetUser",
                "iam:ListMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "DenyAllExceptListedIfNoMFA",
            "Effect": "Deny",
            "NotAction": [
                "iam:EnableMFADevice",
                "iam:GetUser",
                "iam:ListMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}
```

------

## 자신의 IAM 사용자에 대해 하드웨어 TOTP 토큰 활성화(콘솔)
<a name="enable-hw-mfa-for-own-iam-user"></a>

 AWS Management Console에서 자신의 하드웨어 TOTP 토큰을 활성화할 수 있습니다.

**참고**  
하드웨어 TOTP 토큰을 활성화하려면 디바이스에 물리적으로 액세스할 수 있어야 합니다.

**자신의 IAM 사용자에 대해 하드웨어 TOTP 토큰을 활성화하려면 다음을 수행하세요(콘솔).**

1. AWS 계정 ID나 계정 별칭, IAM 사용자 이름 및 암호를 사용하여 [IAM 콘솔](https://console.aws.amazon.com/iam)에 로그인합니다.
**참고**  
사용자 편의를 위해 AWS 로그인 페이지는 브라우저 쿠키를 사용하여 IAM 사용자 이름 및 계정 정보를 기억합니다. 이전에 다른 사용자로 로그인한 경우 페이지 하단 근처의 **다른 계정에 로그인(Sign in to a different account)**을 선택하여 기본 로그인 페이지로 돌아갑니다. 여기서 AWS 계정 ID 또는 계정 별칭을 입력하면 계정의 IAM 사용자 로그인 페이지로 리디렉션됩니다.

   AWS 계정 ID를 받으려면 관리자에게 문의하세요.

1. 오른쪽 상단의 탐색 모음에서 사용자 이름을 선택한 다음 **Security credentials**(보안 자격 증명)를 선택합니다.  
![\[AWS Management Console 보안 자격 증명 링크\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. **AWS IAM credentials** 탭의 **Multi-factor authentication (MFA)**(다중 인증(MFA)) 섹션에서 **Assign MFA device**(MFA 디바이스 할당)를 선택합니다.

1. 마법사에서 **Device name**(디바이스 이름)을 입력하고 **Hardware TOTP token**(하드웨어 TOTP 토큰), **Next**(다음)를 차례로 선택합니다.

1. 디바이스 일련 번호를 입력합니다. 일련 번호는 보통 디바이스 후면에 있습니다.

1. **MFA code 1(MFA 코드 1)** 상자에 MFA 디바이스에 표시된 6자리 번호를 입력합니다. 디바이스 전면의 버튼을 눌러야 번호가 표시되는 경우도 있습니다.  
![\[IAM 대시보드, MFA 디바이스\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/MFADevice.png)

1. 디바이스가 코드를 새로 고칠 때까지 30초 동안 기다린 다음 **MFA code 2(MFA 코드 2)** 상자에 다음 6자리 번호를 입력합니다. 다시 디바이스 전면의 버튼을 눌러야 두 번째 번호가 표시되는 경우도 있습니다.

1. **Add MFA**(MFA 추가)를 선택합니다.
**중요**  
인증 코드를 생성한 후 바로 요청을 제출하세요. 코드를 생성한 후 너무 오래 기다렸다 요청을 제출할 경우 MFA 디바이스가 사용자와 연결은 되지만 MFA 디바이스가 동기화되지 않습니다. 이는 시간 기반 일회용 암호(TOTP)가 잠시 후에 만료되기 때문입니다. 이 경우, [디바이스를 재동기화](id_credentials_mfa_sync.md)할 수 있습니다.

이제 AWS에서 디바이스를 사용할 준비가 끝났습니다. AWS Management Console의 MFA 사용 방법에 대한 자세한 내용은 [MFA 지원 로그인](console_sign-in-mfa.md) 섹션을 참조하세요.

## 다른 IAM 사용자에 대해 하드웨어 TOTP 토큰 활성화(콘솔)
<a name="enable-hw-mfa-for-iam-user"></a>

 AWS Management Console에서 다른 IAM 사용자에 대해 하드웨어 TOTP 토큰을 활성화할 수 있습니다.

**다른 IAM 사용자에 대해 하드웨어 TOTP 토큰을 활성화하려면 다음을 수행하세요(콘솔).**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. MFA를 활성화하려는 사용자의 이름을 선택합니다.

1. [**Security Credentials**] 탭을 선택합니다. **Multi-factor authentication (MFA)**(다중 인증(MFA)) 섹션에서 **Assign MFA device**(MFA 디바이스 할당)를 선택합니다.

1. 마법사에서 **Device name**(디바이스 이름)을 입력하고 **Hardware TOTP token**(하드웨어 TOTP 토큰), **Next**(다음)를 차례로 선택합니다.

1. 디바이스 일련 번호를 입력합니다. 일련 번호는 보통 디바이스 후면에 있습니다.

1. **MFA code 1(MFA 코드 1)** 상자에 MFA 디바이스에 표시된 6자리 번호를 입력합니다. 디바이스 전면의 버튼을 눌러야 번호가 표시되는 경우도 있습니다.  
![\[IAM 대시보드, MFA 디바이스\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/MFADevice.png)

1. 디바이스가 코드를 새로 고칠 때까지 30초 동안 기다린 다음 **MFA code 2(MFA 코드 2)** 상자에 다음 6자리 번호를 입력합니다. 다시 디바이스 전면의 버튼을 눌러야 두 번째 번호가 표시되는 경우도 있습니다.

1. **Add MFA**(MFA 추가)를 선택합니다.
**중요**  
인증 코드를 생성한 후 바로 요청을 제출하세요. 코드를 생성한 후 너무 오래 기다렸다 요청을 제출할 경우 MFA 디바이스가 사용자와 연결은 되지만 MFA 디바이스가 동기화되지 않습니다. 이는 시간 기반 일회용 암호(TOTP)가 잠시 후에 만료되기 때문입니다. 이 경우, [디바이스를 재동기화](id_credentials_mfa_sync.md)할 수 있습니다.

이제 AWS에서 디바이스를 사용할 준비가 끝났습니다. AWS Management Console의 MFA 사용 방법에 대한 자세한 내용은 [MFA 지원 로그인](console_sign-in-mfa.md) 섹션을 참조하세요.

## 물리적 MFA 디바이스 교체
<a name="replace-phys-mfa"></a>

[현재 지원되는 MFA 유형](https://aws.amazon.com/iam/features/mfa/)을 조합하여 한 번에 최대 8개의 MFA 디바이스를 사용자에게 AWS 계정 루트 사용자 및 IAM 사용자와 함께 할당할 수 있습니다. 사용자가 디바이스를 분실하거나 이유를 불문하고 교체할 필요가 있을 경우, 먼저 기존 디바이스를 비활성화해야 합니다. 그런 다음, 해당 사용자를 위한 새 디바이스를 추가할 수 있습니다.
+ 현재 어떤 사용자와 연결되어 있는 디바이스를 비활성화하는 방법은 [MFA 디바이스 비활성화](id_credentials_mfa_disable.md) 섹션을 참조하세요.
+ IAM 사용자에 대해 교체 하드웨어 TOTP 토큰을 추가하려면, 이 주제 앞부분의 [다른 IAM 사용자에 대해 하드웨어 TOTP 토큰 활성화(콘솔)](#enable-hw-mfa-for-iam-user) 절차에 나오는 단계를 따르세요.
+ AWS 계정 루트 사용자 사용자에 대해 교체 하드웨어 TOTP 토큰을 추가하려면, 이 주제 앞부분의 절차 [루트 사용자에 대해 하드웨어 TOTP 토큰 활성화(콘솔)](enable-hw-mfa-for-root.md)에 나오는 단계를 따르세요.

# AWS CLI 또는 AWS API에서 MFA 디바이스 할당
<a name="id_credentials_mfa_enable_cliapi"></a>

AWS CLI 명령 또는 AWS API 작업을 사용하여 IAM 사용자를 위한 가상 MFA 디바이스를 활성화할 수 있습니다. AWS CLI, AWS API, Tools for Windows PowerShell 또는 기타 다른 명령줄 도구를 사용하면 AWS 계정 루트 사용자에 대해 MFA 디바이스를 활성화할 수 없습니다. 그러나 AWS Management Console을 사용하여 루트 사용자의 MFA 디바이스를 활성화할 수 있습니다.

AWS Management Console에서 MFA 디바이스를 활성화할 때 콘솔이 사용자를 대신해 여러 단계를 수행합니다. 대신 AWS CLI, Tools for Windows PowerShell 또는 AWS API를 사용해 가상 디바이스를 생성한다면 수동으로 올바른 순서에 따라 단계들을 수행해야 합니다. 예를 들어 가상 MFA 디바이스를 생성하려면 IAM 객체를 생성하고, 코드를 문자열이나 QR 코드 그래픽으로 추출해야 합니다. 그런 다음 디바이스를 동기화하여 IAM 사용자와 연결해야 합니다. 자세한 정보는 [New-IAMVirtualMFADevice](https://docs.aws.amazon.com/powershell/latest/reference/Index.html?page=New-IAMVirtualMFADevice.html&tocid=New-IAMVirtualMFADevice)의 **Examples** 섹션을 참조하세요. 물리적 디바이스를 위해서는 생성 단계를 건너뛰고 디바이스를 동기화하고 사용자에게 직접 연결합니다.

가상 MFA 디바이스를 비롯한 IAM 리소스에 태그를 연결하여 액세스를 식별, 구성 및 제어할 수 있습니다. AWS CLI 또는 AWS API를 사용하는 경우에만 가상 MFA 디바이스를 태깅할 수 있습니다.

SDK 또는 CLI를 사용하는 IAM 사용자는 [https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html)를 호출하여 추가 MFA 디바이스를 활성화하거나 [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html)를 호출하여 기존 MFA 디바이스를 비활성화할 수 있습니다. 이 작업을 성공적으로 수행하려면 먼저 [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html)을 호출하고 기존 MFA 디바이스로 MFA 코드를 제출해야 합니다. 이 호출은 MFA 인증이 필요한 API 작업에 서명하는 데 사용할 수 있는 임시 보안 자격 증명을 반환합니다. 요청 및 응답의 예는 [`GetSessionToken` - 신뢰할 수 없는 환경에 있는 사용자를 위한 임시 자격 증명](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#api_getsessiontoken)을 참조하세요.

**IAM에서 가상 디바이스 개체를 생성하여 가상 MFA 디바이스를 나타내려면**  
이러한 명령은 다음 명령의 많은 일련 번호 대신 사용되는 디바이스에 ARN을 제공합니다.
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/create-virtual-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/create-virtual-mfa-device.html) 
+ AWS API: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateVirtualMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateVirtualMFADevice.html) 

**AWS에서 사용할 목적으로 MFA 디바이스를 활성화하려면**  
다음 명령은 디바이스와 AWS를 동기화하여 사용자에 연결합니다. 디바이스가 가상이라면 가상 디바이스의 ARN을 일련 번호로 사용합니다.

**중요**  
인증 코드를 생성한 후 바로 요청을 제출하세요. 코드를 생성한 후 너무 오래 기다렸다 요청을 제출할 경우 MFA 디바이스가 사용자와 연결은 되지만 MFA 디바이스가 동기화되지 않습니다. 이는 시간 기반 일회용 암호(TOTP)가 잠시 후에 만료되기 때문입니다. 이 경우, 아래에서 설명하는 명령을 사용하여 디바이스를 재동기화할 수 있습니다.
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/enable-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/enable-mfa-device.html) 
+ AWS API: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableMFADevice.html) 

**디바이스를 비활성화하려면**  
다음 명령을 사용하여 디바이스를 사용자에게서 분리하고 비활성화합니다. 디바이스가 가상이라면 가상 디바이스의 ARN을 일련 번호로 사용합니다. 별도로 가상 디바이스 개체를 삭제해야 합니다.
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/deactivate-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/deactivate-mfa-device.html) 
+ AWS API: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html)

**가상 MFA 디바이스 개체를 표시하려면**  
다음 명령을 사용하여 가상 MFA 디바이스 개체의 목록을 봅니다.
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/list-virtual-mfa-devices.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-virtual-mfa-devices.html) 
+ AWS API: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListVirtualMFADevices.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListVirtualMFADevices.html) 

**가상 MFA 디바이스를 태깅하려면**  
다음 명령을 사용하여 가상 MFA 디바이스를 태깅합니다.
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/tag-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-mfa-device.html) 
+ AWS API: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagMFADevice.html) 

**가상 MFA 디바이스의 태그를 나열하려면**  
다음 명령을 사용하여 가상 MFA 디바이스에 연결된 태그를 나열합니다.
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/list-mfa-device-tags.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-mfa-device-tags.html) 
+ AWS API: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListMFADeviceTags.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListMFADeviceTags.html) 

**가상 MFA 디바이스를 태깅 해제하려면**  
다음 명령을 사용하여 가상 MFA 디바이스에 연결된 태그를 제거합니다.
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/untag-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-mfa-device.html) 
+ AWS API: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagMFADevice.html) 

**MFA 디바이스를 다시 동기화하려면**  
디바이스가 AWS에서 허용하지 않는 코드를 생성하는 경우 이러한 명령을 사용하세요. 디바이스가 가상이라면 가상 디바이스의 ARN을 일련 번호로 사용합니다.
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/resync-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/resync-mfa-device.html) 
+ AWS API: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ResyncMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ResyncMFADevice.html) 

**IAM에서 가상 MFA 디바이스 엔터티를 삭제하려면**  
디바이스가 사용자로부터 분리된 후에 디바이스 개체를 삭제할 수 있습니다.
+ AWS CLI: [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-virtual-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-virtual-mfa-device.html) 
+ AWS API: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteVirtualMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteVirtualMFADevice.html) 

**분실되었거나 작동하지 않는 가상 MFA 디바이스를 복구하는 방법**  
간혹 가상 MFA 앱이 호스팅된 사용자의 디바이스가 분실 또는 교체되었거나 작동하지 않는 경우가 있을 수 있습니다. 이러한 경우가 발생하면 사용자는 자체적으로 복구할 수 없습니다. 사용자는 관리자에게 문의하여 디바이스를 비활성화해야 합니다. 자세한 내용은 [IAM에서 MFA로 보호되는 ID 복구](id_credentials_mfa_lost-or-broken.md) 섹션을 참조하세요.

# MFA 상태 확인
<a name="id_credentials_mfa_checking-status"></a>

IAM 콘솔을 사용하여 AWS 계정 루트 사용자 또는 IAM 사용자가 유효한 MFA 디바이스를 활성화했는지를 확인할 수 있습니다.

**루트 사용자의 MFA 상태를 확인하려면**

1. 루트 사용자 자격 증명으로 AWS Management Console에 로그인한 다음 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 오른쪽 상단의 탐색 모음에서 사용자 이름을 선택한 다음 **Security credentials**(보안 자격 증명)를 선택합니다.

1. [**멀티 팩터 인증(MFA)(Multi-factor Authentication (MFA))**]에서 MFA가 활성화되었는지 비활성화되었는지 여부를 확인합니다. MFA가 활성화되어 있지 않으면 알림 기호(![\[Alert icon\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/console-alert-icon.console.png))가 표시됩니다.

계정에 대해 MFA를 활성화하고 싶다면 다음 중 하나를 참조하세요.
+ [루트 사용자용 가상 MFA 디바이스 활성화(콘솔)](enable-virt-mfa-for-root.md)
+ [루트 사용자용 패스키 또는 보안 키 활성화(콘솔)](enable-fido-mfa-for-root.md)
+ [루트 사용자에 대해 하드웨어 TOTP 토큰 활성화(콘솔)](enable-hw-mfa-for-root.md)

**IAM 사용자의 MFA 상태를 확인하려면**

1. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. 필요할 경우 다음 단계를 통해 사용자 테이블에 **MFA** 열을 추가합니다.

   1. 테이블 위 맨 오른쪽에서 설정 아이콘(![\[Settings icon\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/console-settings-icon.console.png))을 선택합니다.

   1. **열 관리(Manage Columns)**에서 **MFA**를 선택합니다.

   1. (선택 사항) 사용자 테이블에 표시하지 않으려는 열 제목의 확인란을 선택 취소하세요.

   1. **닫기**를 선택하여 사용자 목록으로 돌아갑니다.

1. **MFA** 열에는 활성화된 MFA 디바이스가 표시됩니다. 사용자에게 활성화되어 있는 MFA 디바이스가 없으면 콘솔에 **없음(None)**이라고 표시됩니다. 사용자에게 활성화된 MFA 디바이스가 있으면 **MFA** 열에 활성화된 디바이스의 유형이 **Virtual**(가상), **Security key**(보안 키), **Hardware**(하드웨어) 또는 **SMS** 값으로 표시됩니다.
**참고**  
AWS는 SMS 다중 인증(MFA) 활성화에 대한 지원을 종료했습니다. SMS 문자 메시지 기반 MFA를 사용하는 IAM 사용자가 있는 고객은 [가상(소프트웨어 기반) MFA 디바이스](id_credentials_mfa_enable_virtual.md), [FIDO 보안 키](id_credentials_mfa_enable_fido.md) 또는 [하드웨어 MFA 디바이스](id_credentials_mfa_enable_physical.md)와 같은 대체 방법 중 하나로 전환하는 것이 좋습니다. 계정의 사용자 중에서 SMS MFA 디바이스가 할당된 사용자를 식별할 수 있습니다. 이렇게 하려면 IAM 콘솔로 이동하여 탐색 창에서 **사용자**를 선택하고 표의 **MFA** 열에서 **SMS**가 표시된 사용자를 찾습니다.

1. 사용자의 MFA 디바이스에 대한 추가 정보를 보려면 MFA 상태를 확인하려는 사용자의 이름을 선택합니다. 그런 다음 **보안 자격 증명(Security credentials)** 탭을 선택합니다.

1. 사용자에게 활성화되어 있는 MFA 디바이스가 없으면 콘솔에 **MFA 디바이스 없음이라고 표시됩니다. **다중 인증(MFA)** 섹션에서 MFA 디바이스를 할당해 AWS 환경의 보안을 개선합니다**. 사용자가 MFA 디바이스를 활성화한 경우 **Multi-factor authentication (MFA)**(다중 인증(MFA)) 섹션에 디바이스에 대한 세부 정보가 표시됩니다.
   + 디바이스 이름
   + 디바이스 유형입니다.
   + 물리적 디바이스의 일련 번호 또는 가상 디바이스의 AWS ARN과 같은 디바이스 식별자
   + 디바이스가 생성된 시기

디바이스를 제거하거나 다시 동기화하려면 디바이스 옆에 있는 라디오 버튼을 선택하고 **Remove**(제거) 또는 **Resync**(다시 동기화)를 선택합니다.

MFA 활성화에 대한 자세한 내용은 다음을 참조하세요.
+ [AWS Management Console에서 가상 MFA 디바이스 할당](id_credentials_mfa_enable_virtual.md)
+ [AWS Management Console에서 패스키 또는 보안 키 할당](id_credentials_mfa_enable_fido.md)
+ [AWS Management Console에서 하드웨어 TOTP 토큰 할당](id_credentials_mfa_enable_physical.md)

# 가상 및 하드웨어 MFA 디바이스 재동기화
<a name="id_credentials_mfa_sync"></a>

AWS를 사용하여 가상 및 하드웨어 멀티 팩터 인증(MFA) 디바이스를 다시 동기화할 수 있습니다. 디바이스를 사용하려고 할 때 디바이스가 동기화되지 않으면 로그인 시도가 실패하고 디바이스를 다시 동기화하라는 메시지가 IAM에 표시됩니다.

**참고**  
FIDO 보안 키는 항상 동기화되어 있습니다. FIDO 보안 키를 분실했거나 도난당한 경우 비활성화할 수 있습니다. 모든 MFA 디바이스 유형의 비활성화에 대한 지침은 [다른 IAM 사용자에 대해 MFA 디바이스를 비활성화하려면(콘솔)](id_credentials_mfa_disable.md#deactivate-mfa-for-user) 섹션을 참조하세요.

AWS 관리자는 IAM 사용자의 가상 및 하드웨어 MFA 디바이스가 동기화 상태를 벗어난 경우 이를 재동기화할 수 있습니다.

AWS 계정 루트 사용자 MFA 디바이스가 작동하지 않는 경우 로그인 프로세스 완료 여부와 관계없이 IAM 콘솔을 사용하여 디바이스를 재동기화할 수 있습니다. 디바이스를 성공적으로 다시 동기화할 수 없는 경우 연결을 해제하고 다시 연결해야 할 수 있습니다. 이 작업을 수행하는 방법에 대한 자세한 내용은 [MFA 디바이스 비활성화](id_credentials_mfa_disable.md) 및 [IAM의 AWS 다중 인증](id_credentials_mfa.md) 섹션을 참조하세요.

**Topics**
+ [

## 필요한 권한
](#id_credentials_mfa_sync_console-permissions-required)
+ [

## 가상 및 하드웨어 MFA 디바이스 재동기화(IAM 콘솔)
](#id_credentials_mfa_sync_console)
+ [

## 가상 및 하드웨어 MFA 디바이스 재동기화(AWS CLI)
](#id_credentials_mfa_sync_cli)
+ [

## 가상 및 하드웨어 MFA 디바이스 재동기화(AWS API)
](#id_credentials_mfa_sync_api)

## 필요한 권한
<a name="id_credentials_mfa_sync_console-permissions-required"></a>

IAM 사용자의 가상 또는 하드웨어 MFA 장치를 다시 동기화하려면 다음 정책에 따른 권한이 있어야 합니다. 이 정책에서는 장치를 생성하거나 비활성화하는 것을 허용하지 않습니다.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowListActions",
            "Effect": "Allow",
            "Action": [
                "iam:ListVirtualMFADevices"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowUserToViewAndManageTheirOwnUserMFA",
            "Effect": "Allow",
            "Action": [
                "iam:ListMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "BlockAllExceptListedIfNoMFA",
            "Effect": "Deny",
            "NotAction": [
                "iam:ListMFADevices",
                "iam:ListVirtualMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}
```

------

## 가상 및 하드웨어 MFA 디바이스 재동기화(IAM 콘솔)
<a name="id_credentials_mfa_sync_console"></a>

IAM 콘솔을 사용하여 가상 및 하드웨어 MFA 디바이스를 재동기화할 수 있습니다.

**자신의 IAM 사용자에 대한 가상 또는 하드웨어 MFA 디바이스를 다시 동기화하려면(콘솔)**

1. AWS 계정 ID나 계정 별칭, IAM 사용자 이름 및 암호를 사용하여 [IAM 콘솔](https://console.aws.amazon.com/iam)에 로그인합니다.
**참고**  
사용자 편의를 위해 AWS 로그인 페이지는 브라우저 쿠키를 사용하여 IAM 사용자 이름 및 계정 정보를 기억합니다. 이전에 다른 사용자로 로그인한 경우 페이지 하단 근처의 **다른 계정에 로그인(Sign in to a different account)**을 선택하여 기본 로그인 페이지로 돌아갑니다. 여기서 AWS 계정 ID 또는 계정 별칭을 입력하면 계정의 IAM 사용자 로그인 페이지로 리디렉션됩니다.

   AWS 계정 ID를 받으려면 관리자에게 문의하세요.

1. 오른쪽 상단의 탐색 모음에서 사용자 이름을 선택한 다음 **Security credentials**(보안 자격 증명)를 선택합니다.  
![\[AWS Management Console 보안 자격 증명 링크\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/security-credentials-user.shared.console.png)

1. **AWS IAM 보안 인증** 탭의 **다중 인증(MFA)** 섹션에서 MFA 디바이스 옆의 라디오 버튼을 선택하고 **다시 동기화**를 선택합니다.

1. 디바이스에서 순차적으로 생성된 다음 2개의 코드를 **MFA code 1(MFA 코드 1)** 및 **MFA code 2(MFA 코드 2)**에 입력합니다. 그런 다음 **Resync**(다시 동기화)를 선택합니다.
**중요**  
코드를 생성한 후 즉시 요청을 제출하세요. 코드를 생성한 후 너무 오래 기다렸다 요청을 제출할 경우 요청이 처리되는 것으로 보이지만 디바이스가 동기화되지 않습니다. 이는 시간 기반 일회용 암호(TOTP)가 잠시 후에 만료되기 때문입니다.

**다른 IAM 사용자에 대한 가상 및 하드웨어 MFA 디바이스를 다시 동기화하려면(콘솔)**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **사용자**를 선택한 다음 MFA 디바이스를 재동기화해야 할 사용자의 이름을 선택합니다.

1. **Security credentials(보안 자격 증명)** 탭을 선택합니다. **다중 인증(MFA)** 섹션에서 MFA 디바이스 옆의 라디오 버튼을 선택하고 **다시 동기화**를 선택합니다.

1. 디바이스에서 순차적으로 생성된 다음 2개의 코드를 **MFA code 1(MFA 코드 1)** 및 **MFA code 2(MFA 코드 2)**에 입력합니다. 그런 다음 **Resync**(다시 동기화)를 선택합니다.
**중요**  
코드를 생성한 후 즉시 요청을 제출하세요. 코드를 생성한 후 너무 오래 기다렸다 요청을 제출할 경우 요청이 처리되는 것으로 보이지만 디바이스가 동기화되지 않습니다. 이는 시간 기반 일회용 암호(TOTP)가 잠시 후에 만료되기 때문입니다.

**로그인 전에 루트 사용자 MFA를 재동기화하려면(콘솔)**

1. **인증 디바이스로 Amazon Web Services 로그인(Amazon Web Services Sign In With Authentication Device)** 페이지에서 **인증 디바이스에 문제가 있나요?(Having problems with your authentication device?)를 선택합니다. 여기를 클릭하십시오.(Click here.)**
**참고**  
**MFA를 사용하여 로그인** 및 **인증 디바이스 문제 해결**과 같은 다른 텍스트가 나타날 수 있습니다. 그러나 동일한 기능이 제공됩니다.

1. **Re-Sync With Our Servers(서버를 통한 재동기화)** 섹션에서 디바이스에서 순차적으로 생성된 다음 2개의 코드를 **MFA code 1(MFA 코드 1)** 및 **MFA code 2(MFA 코드 2)**에 입력합니다. 그런 다음 **인증 디바이스 재동기화(Re-sync authentication device)**를 선택합니다.

1. 필요할 경우 암호를 다시 입력하고 **로그인**을 선택합니다. 그런 다음 MFA 디바이스를 사용하여 로그인을 완료합니다.

**로그인 이후 루트 사용자 MFA 디바이스를 재동기화하려면(콘솔)**

1. **루트 사용자**를 선택하고 AWS 계정 계정 이메일 주소를 입력하여 [IAM 콘솔](https://console.aws.amazon.com/iam/)에 계정 소유자로 로그인합니다. 다음 페이지에서 암호를 입력합니다.
**참고**  
루트 사용자는 **IAM 사용자로 로그인** 페이지에 로그인할 수 없습니다. **IAM 사용자로 로그인** 페이지가 보이면 페이지 하단에 있는 **루트 사용자 이메일을 사용하여 로그인**을 선택합니다. 루트 사용자로 로그인하는 데 도움이 필요하면 *AWS Sign-In 사용 설명서*의 [루트 사용자로 AWS Management Console 로그인](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-          root-user-sign-in-tutorial.html)을 참조하세요.

1. 탐색 모음의 오른쪽에서 계정 이름을 선택한 다음 **Security credentials**(보안 자격 증명)를 선택합니다. 필요한 경우 **Continue to Security Credentials**(보안 자격 증명으로 계속)를 선택합니다.  
![\[탐색 메뉴의 보안 자격 증명\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/security-credentials-root.shared.console.png)

1. 페이지의 **Multi-factor authentication (MFA)(멀티 팩터 인증(MFA))** 섹션을 확장합니다.

1. 디바이스 옆의 라디오 버튼을 선택하고 **Resync**(다시 동기화)를 선택합니다.

1. **Resync MFA device**(MFA 기기 다시 동기화) 대화 상자에서 디바이스에서 순차적으로 생성된 다음 2개의 코드를 **MFA code 1**(MFA 코드 1) 및 **MFA code 2**(MFA 코드 2)에 입력합니다. 그런 다음 **Resync**(다시 동기화)를 선택합니다.
**중요**  
코드를 생성한 후 즉시 요청을 제출하세요. 코드를 생성한 후 너무 오래 기다렸다 요청을 제출할 경우 MFA 디바이스가 사용자와 연결은 되지만 MFA 디바이스가 동기화되지 않습니다. 이는 시간 기반 일회용 암호(TOTP)가 잠시 후에 만료되기 때문입니다.

## 가상 및 하드웨어 MFA 디바이스 재동기화(AWS CLI)
<a name="id_credentials_mfa_sync_cli"></a>

AWS CLI에서 가상 및 하드웨어 MFA 디바이스를 재동기화할 수 있습니다.

**IAM 사용자에 대한 가상 및 하드웨어 MFA 디바이스를 재동기화하려면(AWS CLI)**  
명령 프롬프트에서 [aws iam resync-mfa-device](https://docs.aws.amazon.com/cli/latest/reference/iam/resync-mfa-device.html) 명령을 실행합니다.
+ 가상 MFA 디바이스: 디바이스의 Amazon 리소스 이름(ARN)을 일련 번호로 지정합니다.

  ```
  aws iam resync-mfa-device --user-name Richard --serial-number arn:aws:iam::123456789012:mfa/RichardsMFA --authentication-code1 123456 --authentication-code2 987654
  ```
+ 하드웨어 MFA 디바이스: 하드웨어 디바이스의 일련 번호를 일련 번호로 지정합니다. 형식은 공급업체에 따라 다릅니다. 예를 들어 Amazon에서는 gemalto 토큰을 구매할 수 있습니다. 이 토큰의 일련 번호는 일반적으로 문자 4개이며 그 뒤로 숫자 4개가 이어집니다.

  ```
  aws iam resync-mfa-device --user-name Richard --serial-number ABCD12345678 --authentication-code1 123456 --authentication-code2 987654
  ```

**중요**  
코드를 생성한 후 즉시 요청을 제출하세요. 코드를 생성한 후 너무 오래 기다렸다 요청을 제출할 경우 잠시 후 코드가 만료되기 때문에 요청이 실패합니다.

## 가상 및 하드웨어 MFA 디바이스 재동기화(AWS API)
<a name="id_credentials_mfa_sync_api"></a>

IAM에는 동기화를 수행하는 API 호출이 있습니다. 이러한 경우 가상 및 하드웨어 MFA 사용자에게 API 호출에 액세스할 수 있는 권한을 부여하는 것이 좋습니다. 이때 사용자가 필요할 때마다 디바이스를 재동기화할 수 있도록 API 호출 기반 도구를 구축해야 합니다.

**IAM 사용자에 대한 가상 및 하드웨어 MFA 디바이스를 재동기화하려면(AWS API)**
+ [ResyncMFADevice](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ResyncMFADevice.html) 요청을 보냅니다.

# MFA 디바이스 비활성화
<a name="id_credentials_mfa_disable"></a>

다중 인증(MFA) 디바이스를 사용하여 IAM 사용자로 로그인하는 데 문제가 있는 경우 관리자에게 문의하여 도움을 받으세요.

관리자는 다른 IAM 사용자에 대해 디바이스를 비활성화할 수 있습니다. 이 방법을 사용하면 MFA를 사용하지 않고 로그인할 수 있습니다. MFA 디바이스가 교체되는 중이거나 디바이스가 일시적으로 사용 불가능할 때 이 방법을 임시 해결 방법으로 사용할 수 있습니다. 그러나 최대한 빨리 사용자를 위한 새 디바이스를 활성화하는 것이 좋습니다. 새 MFA 디바이스를 활성화 하는 방법에 대한 자세한 내용은 [IAM의 AWS 다중 인증](id_credentials_mfa.md)를 참조하세요.

**참고**  
API 또는 AWS CLI를 사용하여 AWS 계정에서 사용자를 삭제하는 경우 사용자의 MFA 디바이스를 비활성화 또는 삭제해야 합니다. 이 변경 사항을 사용자 제거 과정의 일부로 활용합니다. 사용자 제거에 대한 자세한 내용은 [IAM 사용자 제거 또는 비활성화](id_users_remove.md)의 내용을 참조하세요.

**Topics**
+ [

## MFA 디바이스 비활성화(콘솔)
](#deactive-mfa-console)
+ [

## MFA 디바이스 비활성화(AWS CLI)
](#deactivate-mfa-cli)
+ [

## MFA 디바이스 비활성화(AWS API)
](#deactivate-mfa-api)

## MFA 디바이스 비활성화(콘솔)
<a name="deactive-mfa-console"></a><a name="deactivate-mfa-for-user"></a>

**다른 IAM 사용자에 대해 MFA 디바이스를 비활성화하려면(콘솔)**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. 사용자의 MFA 디바이스를 비활성화하려면 MFA를 제거하려는 사용자의 이름을 선택합니다.

1. **Security credentials(보안 자격 증명)** 탭을 선택합니다.

1. **다중 인증(MFA)**에서 MFA 디바이스 옆의 라디오 버튼을 선택하고 **제거**를 선택하고 **제거**를 선택합니다.

   디바이스가 AWS에서 제거됩니다. 디바이스는 다시 활성화되어 AWS 사용자 또는 AWS 계정 루트 사용자에 연결될 때까지는 로그인 또는 요청 인증에 사용할 수 없습니다.<a name="deactivate-mfa-for-root"></a>

**AWS 계정 루트 사용자의 MFA 디바이스를 비활성화하려면(콘솔)**

1. **루트 사용자**를 선택하고 AWS 계정 계정 이메일 주소를 입력하여 [IAM 콘솔](https://console.aws.amazon.com/iam/)에 계정 소유자로 로그인합니다. 다음 페이지에서 암호를 입력합니다.
**참고**  
루트 사용자는 **IAM 사용자로 로그인** 페이지에 로그인할 수 없습니다. **IAM 사용자로 로그인** 페이지가 보이면 페이지 하단에 있는 **루트 사용자 이메일을 사용하여 로그인**을 선택합니다. 루트 사용자로 로그인하는 데 도움이 필요하면 *AWS Sign-In 사용 설명서*의 [루트 사용자로 AWS Management Console 로그인](https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-          root-user-sign-in-tutorial.html)을 참조하세요.

1. 탐색 모음의 오른쪽에서 계정 이름을 선택한 다음 **Security credentials**(보안 자격 증명)를 선택합니다. 필요한 경우 **Continue to Security Credentials**(보안 자격 증명으로 계속)를 선택합니다.  
![\[탐색 메뉴의 보안 자격 증명\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/security-credentials-root.shared.console.png)

1. **Multi-factor authentication (MFA)**(다중 인증(MFA)) 섹션에서 비활성화하려는 MFA 디바이스 옆의 라디오 버튼을 선택하고 **Remove**(제거)를 선택합니다.

1. **** 제거를 선택합니다.

   AWS 계정의 MFA 디바이스가 비활성화됩니다. AWS 계정과 연결된 이메일로 Amazon Web Services의 확인 메시지가 왔는지 점검합니다. 이메일이 Amazon Web Services의 Multi-Factor Authentication(MFA)이 비활성화되었음을 알립니다. 메시지는 `@amazon.com` 또는 `@aws.amazon.com`에서 전송되어 옵니다.

**참고**  
AWS 계정에서 할당되지 않은 가상 MFA 디바이스는 로그인 프로세스 중에 또는 AWS Management Console을 통해 새 가상 MFA 디바이스를 추가할 때 삭제됩니다. 할당되지 않은 가상 MFA 디바이스는 계정의 디바이스이지만 계정 루트 사용자 또는 IAM 사용자가 로그인 프로세스에 사용하지 않습니다. 새 가상 MFA 디바이스를 계정에 추가할 수 있도록 해당 디바이스는 삭제됩니다. 또한 디바이스 이름을 재사용할 수 있습니다.

## MFA 디바이스 비활성화(AWS CLI)
<a name="deactivate-mfa-cli"></a>

**IAM 사용자에 대해 MFA 디바이스를 비활성화하려면(AWS CLI)**
+ 다음 명령을 실행합니다. [https://docs.aws.amazon.com/cli/latest/reference/iam/deactivate-mfa-device.html](https://docs.aws.amazon.com/cli/latest/reference/iam/deactivate-mfa-device.html) 

## MFA 디바이스 비활성화(AWS API)
<a name="deactivate-mfa-api"></a>

**IAM 사용자에 대해 MFA 디바이스를 비활성화하려면(AWS API)**
+ 다음 연산을 호출합니다. [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeactivateMFADevice.html) 

# IAM에서 MFA로 보호되는 ID 복구
<a name="id_credentials_mfa_lost-or-broken"></a>

[가상 MFA 디바이스](id_credentials_mfa_enable_virtual.md) 또는 [하드웨어 TOTP 토큰](id_credentials_mfa_enable_physical.md)이 정상적으로 작동하는 것처럼 같지만, 이것을 사용하여 AWS 리소스에 액세스하지 못하는 경우에는 AWS와 동기화되지 않는 것이 원인일 수 있습니다. 가상 MFA 디바이스 또는 하드웨어 MFA 디바이스의 동기화에 대한 자세한 내용은 [가상 및 하드웨어 MFA 디바이스 재동기화](id_credentials_mfa_sync.md) 섹션을 참조하세요. [FIDO 보안 키](id_credentials_mfa_enable_fido.md)는 항상 동기화되어 있습니다.

AWS 계정 루트 사용자용 [MFA 디바이스](id_credentials_mfa.md)가 분실 또는 손상되거나 작동하지 않는 경우, 계정에 대한 액세스를 복구할 수 있습니다. IAM 사용자는 관리자에게 문의하여 디바이스를 비활성화해야 합니다.

**중요**  
여러 개의 MFA 디바이스를 활성화하는 것이 좋습니다. 여러 개의 MFA 디바이스를 등록하면 디바이스의 분실 또는 고장이 발생한 경우에도 계속 액세스할 수 있습니다. AWS 계정 루트 사용자 및 IAM 사용자는 어떤 유형이든 최대 8개의 MFA 디바이스를 등록할 수 있습니다.

## 사전 조건 - 다른 MFA 디바이스 사용
<a name="mfa-lost-or-broken-prerequisites"></a>

[다중 인증(MFA) 디바이스](id_credentials_mfa.md)가 분실되었거나 손상되었거나 작동하지 않는 경우 동일한 루트 사용자 또는 IAM 사용자에게 등록된 다른 MFA 디바이스를 사용하여 로그인할 수 있습니다.

**다른 MFA 디바이스를 사용하여 로그인하는 방법**

1. AWS 계정 ID 또는 계정 별칭과 암호를 사용하여 [AWS Management Console](url-comsole-domain;iam)에 로그인합니다.

1. **추가 확인 필요** 페이지 또는 **복수 단계 인증** 페이지에서 **다른 MFA 방법 시도**를 선택합니다.

1. 선택한 MFA 디바이스 유형으로 인증합니다.

1. 다음 단계는 대체 MFA 디바이스를 사용해 성공적으로 로그인했는지 여부에 따라 달라집니다.
   + 로그인에 성공하면 [가상 및 하드웨어 MFA 디바이스 재동기화](id_credentials_mfa_sync.md)가 가능하며, 이를 통해 문제를 해결할 수 있습니다. MFA 디바이스가 분실되었거나 파손된 경우 비활성화할 수 있습니다. 모든 MFA 디바이스 유형의 비활성화에 대한 지침은 [MFA 디바이스 비활성화](id_credentials_mfa_disable.md) 섹션을 참조하세요.
   + MFA로 로그인할 수 없는 경우 [루트 사용자 MFA 디바이스 복구](#root-mfa-lost-or-broken) 또는 [IAM 사용자 MFA 디바이스 복구](#iam-user-mfa-lost-or-broken)의 단계를 사용하여 MFA로 보호된 자격 증명을 복구합니다.



## 루트 사용자 MFA 디바이스 복구
<a name="root-mfa-lost-or-broken"></a>

MFA 디바이스로 로그인할 수 없는 경우 대체 인증 방법을 통해 사용자 계정에 등록된 이메일 및 기본 연락처 전화번호로 사용자 자격 증명을 확인하여 로그인할 수 있습니다.

대체 인증 요소를 사용하여 루트 사용자로 로그인하기 전에 계정과 연결된 이메일 및 기본 연락처 전화번호에 액세스할 수 있는지 확인합니다. 기본 연락처 전화번호를 업데이트해야 하는 경우 루트 사용자 대신 **관리자 액세스 권한이 모두 있는 IAM 사용자로 로그인합니다. 계정 연락처 정보 업데이트에 대한 추가 지침은 *AWS Billing 사용설명서*의 [연락처 정보 편집](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-primary.html)을 참조하십시오. 이메일 및 기본 연락처 전화번호에 액세스할 수 없는 경우 [AWS Support](https://support.aws.amazon.com/#/contacts/aws-mfa-support)에 문의해야 합니다.

**중요**  
성공적인 계정 복구를 위해 루트 사용자에게 연결된 이메일 주소와 연락처 전화번호를 최신 상태로 유지하는 것이 좋습니다. 자세한 내용은 *AWS Account Management참조 안내서*에 있는 [AWS 계정의 기본 연락처 업데이트](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-primary.html)를 참조하세요.

**AWS 계정 루트 사용자로 다른 인증 요소를 사용하여 로그인하려면**

1.  **루트 사용자**를 선택하고 AWS 계정 이메일 주소를 입력하여 [AWS Management Console](https://console.aws.amazon.com/)에 계정 소유자로 로그인합니다. 다음 페이지에서 비밀번호를 입력합니다.

1. **추가 확인 필요(Additional verification required)** 페이지에서 인증할 MFA 방법을 선택하고 **다음(Next)**을 선택합니다.
**참고**  
**MFA를 사용하여 로그인(Sign in using MFA)**, **인증 디바이스 문제 해결(Troubleshoot your authentication device)**, **MFA 문제 해결(Troubleshoot MFA)**과 같은 대체 텍스트가 표시될 수 있지만 기능은 동일합니다. 대체 인증 요소를 사용하여 계정 이메일 주소와 기본 연락처 전화번호를 확인할 수 없는 경우 [AWS Support](https://support.aws.amazon.com/#/contacts/aws-mfa-support)에 문의하여 MFA 디바이스를 비활성하세요.

1. 사용 중인 MFA 유형에 따라 다른 페이지가 표시되지만 **MFA 문제 해결(Troubleshoot MFA)** 옵션은 동일하게 작동합니다. **추가 확인 필요(Additional verification required)** 페이지 또는 **복수 단계 인증(Multi-factor authentication)** 페이지에서 **MFA 문제 해결(Troubleshoot MFA)**을 선택합니다.

1. 필요할 경우 암호를 다시 입력하고 ** 로그인**을 선택합니다.

1. **디바이스 인증 문제 해결(Troubleshoot your authentication device)** 페이지에 있는 **대체 인증 팩터를 사용하여 로그인(Sign In Using Alternative Factors of Authentication)** 섹션에서 **대체 팩터를 사용하여 로그인(Sign in using alternative factors)**을 선택합니다.

1. **대체 인증 팩터를 사용하여 로그인(Sign In Using Alternative Factors of Authentication)** 페이지에서 이메일 주소를 확인하여 계정을 인증하고 **확인 이메일 보내기(Send verification email)**를 선택합니다.

1. AWS 계정과 연결된 이메일에서 Amazon Web Services(recover-mfa-no-reply@verify.signin.aws)의 메시지를 확인합니다. 이메일 지침을 따릅니다.

   계정에 이메일이 없는 경우에는 스팸 폴더를 확인하거나 브라우저로 돌아가 **이메일 재전송(Resend the email)**을 선택합니다.

1. 이메일 주소를 확인한 후에 계정 인증을 계속 진행할 수 있습니다. 기본 연락처 전화번호를 확인하려면 **지금 전화하기(Call me now)**를 선택합니다.

1. AWS 전화를 받고, 요구에 따라 AWS 웹사이트의 6자리 숫자를 전화 키패드에 입력합니다.

   AWS에서 전화가 오지 않을 경우에는 **로그인**을 선택하여 콘솔에 다시 로그인하고 처음부터 다시 시작합니다. 또는 [분실하거나 사용할 수 없는 다중 인증(MFA) 디바이스](https://support.aws.amazon.com/#/contacts/aws-mfa-support)(Lost or unusable Multi-Factor Authentication (MFA) device)를 참조하여 지원팀에 문의하세요.

1. 전화 번호를 확인한 후에는 **콘솔에 로그인(Sign in to the console)**을 선택하여 계정에 로그인할 수 있습니다.

1. 다음 단계는 사용 중인 MFA의 유형에 따라 다릅니다.
   + 가상 MFA 디바이스의 경우, 디바이스에서 계정을 제거합니다. 그런 다음 [AWS 보안 자격 증명](https://console.aws.amazon.com/iam/home?#security_credential) 페이지로 이동하여 기존 MFA 가상 디바이스 엔터티를 삭제한 다음 새 엔터티를 생성합니다.
   + FIDO 보안 키의 경우, [AWS 보안 인증](https://console.aws.amazon.com/iam/home?#security_credential) 페이지로 이동하여 기존 FIDO 보안 키를 비활성화한 다음 새 키를 활성화합니다.
   + 하드웨어 TOTP 토큰의 경우, 타사 제공업체에 연락해 디바이스 수리 또는 교체를 위한 도움을 받으세요. 새 디바이스를 받기 전까지 다른 인증 요소를 사용하여 계속 로그인할 수 있습니다. 하드웨어 MFA 디바이스를 새로 받은 후에는 [AWS 보안 자격 증명](https://console.aws.amazon.com/iam/home?#security_credential) 페이지로 이동하여 기존 MFA 디바이스를 삭제합니다.
**참고**  
잃어버렸거나 도난당한 MFA 디바이스를 동일한 유형의 디바이스로 대체해야 하는 것은 아닙니다. 예를 들어, FIDO 보안 키가 망가져 새로 주문한 경우, 새로운 FIDO 보안 키를 받을 때까지는 가상 MFA 또는 하드웨어 TOTP 토큰을 사용할 수 있습니다.

**중요**  
MFA 디바이스가 분실 또는 도난된 경우 로그인하고 대체 MFA 디바이스를 설정한 후 루트 사용자 암호를 변경하세요. 인증 디바이스를 훔친 공격자가 사용자의 현재 암호를 알고 있을 수 있습니다. 자세한 내용은 [AWS 계정 루트 사용자의 암호 변경](root-user-password.md) 섹션을 참조하세요.

## IAM 사용자 MFA 디바이스 복구
<a name="iam-user-mfa-lost-or-broken"></a>

MFA로 로그인할 수 없는 IAM 사용자인 경우 직접 MFA 디바이스를 복구할 수 없습니다. 해당 사용자는 관리자에 문의하여 디바이스를 비활성화해야 합니다. 그러면 새 디바이스를 활성화할 수 있습니다.

**IAM 사용자로 MFA 디바이스에 관한 도움을 받으려면**

1. AWS 관리자나 그 밖에 IAM 사용자의 사용자 이름 및 암호를 제공한 담당자에게 문의합니다. [MFA 디바이스 비활성화](id_credentials_mfa_disable.md) 설명대로 관리자가 MFA 디바이스를 비활성화해야 로그인할 수 있습니다.

1. 다음 단계는 사용 중인 MFA의 유형에 따라 다릅니다.
   + 가상 MFA 디바이스의 경우, 디바이스에서 계정을 제거합니다. 그런 다음 [AWS Management Console에서 가상 MFA 디바이스 할당](id_credentials_mfa_enable_virtual.md) 설명대로 가상 디바이스를 활성화합니다.
   + FIDO 보안 키의 경우, 타사 공급업체에 연락해 디바이스 교체를 위한 도움을 받으세요. 새로운 FIDO 보안 키를 받은 경우, [AWS Management Console에서 패스키 또는 보안 키 할당](id_credentials_mfa_enable_fido.md)에 설명된 대로 활성화합니다.
   + 하드웨어 TOTP 토큰의 경우, 타사 제공업체에 연락해 디바이스 수리 또는 교체를 위한 도움을 받으세요. 물리적 MFA 디바이스를 새로 받은 후에는 [AWS Management Console에서 하드웨어 TOTP 토큰 할당](id_credentials_mfa_enable_physical.md) 설명대로 디바이스를 활성화합니다.
**참고**  
잃어버렸거나 도난당한 MFA 디바이스를 동일한 유형의 디바이스로 대체해야 하는 것은 아닙니다. 어떤 조합이든 최대 8개의 MFA 디바이스를 보유할 수 있습니다. 예를 들어, FIDO 보안 키가 망가져 새로 주문한 경우, 새로운 FIDO 보안 키를 받을 때까지는 가상 MFA 또는 하드웨어 TOTP 토큰을 사용할 수 있습니다.

1. MFA 디바이스가 없거나 도난당한 경우에는 인증 디바이스를 훔친 공격자가 현재 암호를 알 수 있으므로 비밀번호도 변경하세요. 자세한 내용은 [IAM 사용자 암호 관리](id_credentials_passwords_admin-change-user.md) 섹션을 참조하세요.

# MFA를 통한 보안 API 액세스
<a name="id_credentials_mfa_configure-api-require"></a>

사용자가 호출할 수 있는 API 작업을 IAM 정책을 사용해 지정할 수 있습니다. 민감한 작업을 수행할 수 있도록 허용하기 전에 사용자가 다중 인증(MFA)으로 인증하도록 요구하는 추가 보안이 필요할 수 있습니다.

예를 들어 사용자가 Amazon EC2 `RunInstances`, `DescribeInstances` 및 `StopInstances` 작업을 수행하도록 허용하는 정책이 있을 수 있습니다. 하지만 `TerminateInstances`처럼 안전하지 않은 작업의 경우 이를 제한해 사용자가 AWS MFA 디바이스에서 인증할 때만 작업을 수행하도록 해야 할 필요가 있을 수 있습니다.

**Topics**
+ [

## 개요
](#MFAProtectedAPI-overview)
+ [

## 시나리오: 크로스 계정 위임에 대한 MFA 보호
](#MFAProtectedAPI-cross-account-delegation)
+ [

## 시나리오: 현재 계정의 API 작업에 대한 액세스를 위한 MFA 보호
](#MFAProtectedAPI-user-mfa)
+ [

## 시나리오: 리소스 기반 정책이 있는 리소스에 대한 MFA 보호
](#MFAProtectedAPI-resource-policies)

## 개요
<a name="MFAProtectedAPI-overview"></a>

API 작업에 MFA 보호를 추가하려면 다음과 같은 작업이 필요합니다.

1. 관리자는 MFA 인증이 필요한 API 요청을 해야 하는 각 사용자에 대해 AWS MFA 디바이스를 구성합니다. 자세한 내용은 [IAM의 AWS 다중 인증](id_credentials_mfa.md) 섹션을 참조하세요.

1. 관리자는 사용자가 AWS MFA 디바이스로 인증했는지 여부를 확인하는 `Condition` 요소가 포함된 사용자 정책을 생성합니다.

1. 사용자는 MFA 파라미터를 지원하는 AWS STS API 작업인 [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) 또는 [GetSessionToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) 중 하나를 호출합니다. 사용자는 사용자와 연결된 디바이스의 디바이스 식별자를 호출에 포함시킵니다. 또한 사용자는 디바이스에 생성하는 시간 기반 일회용 암호(TOTP)도 포함시킵니다. 각각의 경우, 사용자는 AWS에 추가 요청하는 데 사용하기 위해 임시 보안 자격 증명을 다시 가져옵니다.
**참고**  
서비스의 API 작업에 대한 MFA 보호 기능은 해당 서비스에서 임시 보안 자격 증명을 지원하는 경우에만 사용 가능합니다. 이러한 서비스 목록은 [임시 보안 자격 증명을 사용하여 AWS에 액세스](https://docs.aws.amazon.com/STS/latest/UsingSTS/UsingTokens.html)를 참조하세요.

권한 부여에 실패한 경우 AWS는 "액세스가 거부되었습니다."라는 오류 메시지를 반환합니다(무단 액세스의 경우와 동일). MFA 보호 API 정책이 적용되는 경우, 사용자가 유효한 MFA 인증 없이 API 작업을 호출하려 하면 AWS에서는 정책에 지정된 API 작업에 대한 액세스를 거부합니다. API 작업 요청의 타임스탬프가 정책에 지정된 허용 범위를 벗어난 경우에도 작업이 거부됩니다. 사용자는 MFA 코드와 디바이스 일련 번호로 새 임시 보안 자격 증명을 요청하여 MFA 인증을 다시 해야 합니다.

### MFA 조건이 포함된 IAM 정책
<a name="MFAProtectedAPI-policies"></a>

MFA 조건이 포함된 정책은 다음에 연결할 수 있습니다.
+ IAM 사용자 또는 그룹
+ Amazon S3 버킷, Amazon SQS 대기열, Amazon SNS 주제 등과 같은 리소스
+ 사용자가 수임할 수 있는 IAM 역할의 신뢰 정책

정책의 MFA 조건을 사용해 다음과 같은 속성을 확인할 수 있습니다.
+ 존재 - 사용자가 MFA로 인증했는지 간단히 확인하려면 `Bool` 조건에서 `aws:MultiFactorAuthPresent` 키가 `True`인지 확인합니다. 사용자가 단기 자격 증명으로 인증하는 경우에만 키가 있습니다. 액세스 키와 같은 장기 자격 증명에는 이 키가 포함되어 있지 않습니다.
+ 기간 - MFA 인증 이후 지정된 시간 내에서만 액세스 권한을 부여하고 싶은 경우, 숫자 조건 유형을 사용하여 `aws:MultiFactorAuthAge` 키의 기간과 값(예: 3600초)을 비교합니다. MFA가 사용되지 않는 경우 `aws:MultiFactorAuthAge` 키가 없습니다.

다음 예는 MFA 인증의 존재를 테스트하는 MFA 조건을 포함하는 IAM 역할의 신뢰 정책을 보여줍니다. 이 정책을 통해 `Principal` 요소(`ACCOUNT-B-ID`를 유효한 AWS 계정 ID로 대체)에 지정된 AWS 계정의 사용자는 이 정책이 연결된 역할을 수임할 수 있습니다. 그러나 이러한 사용자는 MFA를 사용하여 인증을 받은 경우에만 역할을 수임할 수 있습니다.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Principal": {"AWS": "ACCOUNT-B-ID"},
    "Action": "sts:AssumeRole",
    "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
  }
}
```

------

MFA의 조건 유형에 대한 자세한 내용은 [AWS 글로벌 조건 컨텍스트 키](reference_policies_condition-keys.md), [숫자 조건 연산자](reference_policies_elements_condition_operators.md#Conditions_Numeric) 및 [조건 키의 존재를 확인하는 조건 연산자](reference_policies_elements_condition_operators.md#Conditions_Null) 섹션을 참조하세요.

### GetSessionToken과 AssumeRole 중에서 선택
<a name="scenarios"></a>

AWS STS에서는 사용자가 MFA 정보를 전달할 수 있도록 `GetSessionToken`과 `AssumeRole`이라는 두 가지 API 작업을 제공합니다. 사용자가 임시 보안 자격 증명을 가져오기 위해 호출하는 API 작업은 다음 시나리오 중 어떤 것이 적용되느냐에 따라 달라집니다.

**다음 시나리오에는 `GetSessionToken`을 사용합니다.**
+ 요청을 수행하는 IAM 사용자와 동일한 AWS 계정의 리소스에 액세스하는 API 작업을 호출합니다. `GetSessionToken` 요청의 임시 자격 증명은 작업 증명 요청에 MFA 정보를 포함하는 경우에*만* IAM 및 AWS STS API 작업에 액세스할 수 있습니다. `GetSessionToken`에서 반환하는 임시 자격 증명에 MFA 정보가 포함되어 있으므로 자격 증명에서 수행하는 개별 API 작업에서 MFA를 확인할 수 있습니다.
+ MFA 조건이 포함된 리소스 기반 정책으로 보호되는 리소스에 액세스.

`GetSessionToken` 작업의 목적은 MFA를 사용하는 사용자를 인증하는 것입니다. 정책을 사용하여 인증 작업을 제어할 수는 없습니다.

**다음 시나리오에는 `AssumeRole`을 사용합니다.**
+ 같은 또는 다른 AWS 계정의 리소스에 액세스하는 API 작업을 호출합니다. API 호출은 모든 IAM 또는 AWS STS API를 포함할 수 있습니다. 액세스를 보호하기 위해 사용자가 역할을 수임하는 시각에 MFA를 적용한다는 것에 유의하세요. `AssumeRole`에서 반환하는 임시 자격 증명은 컨텍스트에 MFA 정보를 포함하고 있지 않으므로 MFA에 대한 개별 API 작업을 확인할 수 없습니다. 이것이 바로 `GetSessionToken`을 사용해 리소스 기반 정책에 의해 보호되는 리소스에 대한 액세스를 제한해야 하는 이유입니다.

**참고**  
IAM 사용자가 MFA로 로그인할 때 AWS CloudTrail 로그에 MFA 정보가 포함됩니다. IAM 사용자가 IAM 역할을 수임하는 경우 CloudTrail은 수임된 역할을 사용하여 수행된 작업에 대한 `sessionContext` 속성에서도 `mfaAuthenticated: true`를 기록합니다. 그러나 CloudTrail 로깅은 수임된 역할의 자격 증명으로 API를 직접 호출할 때 IAM에 필요한 것과는 별개입니다. 자세한 내용은 [CloudTrail userIdentity 요소](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html)을 참조하세요.

이러한 시나리오가 구현되는 방식에 대한 세부 정보는 이 문서의 후반부에 나와 있습니다.

### MFA 보호 API 액세스에 대한 중요 사항
<a name="MFAProtectedAPI-important-points"></a>

API 작업에 대한 MFA 보호가 지닌 다음과 같은 측면을 이해하는 것이 중요합니다.
+ MFA 보호는 임시 보안 자격 증명을 사용하는 경우에만 제공되며, 임시 보안 자격 증명은 `AssumeRole` 또는 `GetSessionToken`을 사용해 얻어야 합니다.
+ AWS 계정 루트 사용자 자격 증명으로는 MFA 보호 API 액세스를 사용할 수 없습니다.
+ U2F 보안 키로는 MFA 보호 API 액세스를 사용할 수 없습니다.
+ 페더레이션 사용자는 AWS 서비스에 사용할 MFA 디바이스를 할당받을 수 없으므로, MFA에서 제어하는 AWS 리소스에 액세스할 수 없습니다. (다음 참조.) 
+ 임시 자격 증명을 반환하는 다른 AWS STS API 작업에서는 MFA를 지원하지 않습니다. `AssumeRoleWithWebIdentity` 및 `AssumeRoleWithSAML`의 경우 사용자는 외부 공급자에 의해 인증되며 AWS에서는 그 공급자가 MFA를 요구했는지를 확인할 수 없습니다. `GetFederationToken`의 경우 MFA가 특정 사용자와 반드시 연결되는 것은 아닙니다.
+ 이와 마찬가지로 장기 자격 증명(IAM 사용자 액세스 키 및 루트 사용자 액세스 키)은 만료되지 않기 때문에 MFA 보호 API 액세스를 통해 사용할 수 없습니다.
+ 또한, `AssumeRole` 및 `GetSessionToken`은 MFA 정보 없이도 호출할 수 있습니다. 이 경우 호출자는 임시 보안 자격 증명을 다시 가져오지만, 그러한 임시 자격 증명의 세션 정보에는 사용자가 MFA로 인증했는지 나타나지 않습니다.
+ API 작업에 대해 MFA 보호를 설정하려면 정책에 MFA 조건을 추가하면 됩니다. MFA 사용을 적용하기 위해 정책에는 `aws:MultiFactorAuthPresent` 조건 키가 포함되어 있어야 합니다. 크로스 계정 위임을 위해 역할의 신뢰 정책에는 조건 키가 포함되어 있어야 합니다.
+ 다른 AWS 계정이 내 계정의 리소스에 액세스하도록 허용하는 경우, 리소스의 보안은 신뢰할 수 있는 계정, 즉 다른 계정(내 계정이 아님)의 구성에 따라 달라집니다. 이것은 멀티 팩터 인증이 필요할 때도 마찬가지입니다. 가상 MFA 디바이스를 생성할 권한이 있는 신뢰할 수 있는 계정 내의 어떤 자격 증명도 MFA 클레임을 생성하여 역할의 신뢰 정책의 해당 부분을 충족할 수 있습니다. 멀티 팩터 인증을 요구하는 AWS 리소스에 대한 액세스를 다른 계정의 멤버에게 허용하기 전에 신뢰할 수 있는 계정의 소유자가 보안 모범 사례를 따르도록 해야 합니다. 예를 들어 신뢰할 수 있는 계정에서는 MFA 디바이스 관리 API 작업과 같은 중요 API 작업에 대한 액세스를 신뢰할 수 있는 특정 자격 증명으로 제한해야 합니다.
+ 정책에 MFA 조건이 포함된 경우, 사용자가 MFA에 인증되지 않거나 잘못된 MFA 디바이스 식별자 또는 잘못된 TOTP를 제공하는 경우 요청이 거부됩니다.

## 시나리오: 크로스 계정 위임에 대한 MFA 보호
<a name="MFAProtectedAPI-cross-account-delegation"></a>

이 시나리오에서는 다른 계정의 IAM 사용자에게 액세스 권한을 위임하려고 합니다. 단 해당 사용자가 AWS MFA 디바이스로 인증된 경우에 한합니다. 교차 계정 위임에 대한 자세한 내용은 [역할 용어 및 개념](id_roles.md#id_roles_terms-and-concepts) 섹션을 참조하세요.

계정 A(액세스할 리소스를 소유한 신뢰하는 계정)에 관리자 권한이 있는 IAM 사용자 Anaya가 있다고 가정해 봅시다. 그녀는 계정 B(신뢰할 수 있는 계정)의 사용자 Richard에게 액세스 권한을 부여하고 싶지만, Richard가 MFA에 인증되었는지 확인한 후에 그가 역할을 수임하기를 원합니다.

1. 신뢰하는 계정 A에서 Anaya는 `CrossAccountRole`이라는 IAM 역할을 생성하고 해당 역할의 신뢰 정책에서 보안 주체를 계정 B의 계정 ID로 설정합니다. 이 신뢰 정책은 AWS STS `AssumeRole` 작업에 대한 권한을 부여합니다. 또한 Anaya는 다음 예와 같이 신뢰 정책에 MFA 조건을 추가합니다.

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": {
       "Effect": "Allow",
       "Principal": {"AWS": "ACCOUNT-B-ID"},
       "Action": "sts:AssumeRole",
       "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
     }
   }
   ```

------

1. Anaya는 역할이 수행할 수 있는 작업을 지정하는 역할에 권한 정책을 추가합니다. MFA 보호 기능이 포함된 역할의 권한 정책은 다른 역할 권한 정책과 다르지 않습니다. 다음 예제에서는 Anaya가 역할에 추가하는 정책을 보여줍니다. 역할을 수임한 사용자는 이 정책을 통해 계정 A의 `Books` 테이블에서 Amazon DynamoDB 작업을 수행할 수 있고, 아울러 콘솔에서 작업을 수행할 때 필요한 `dynamodb:ListTables` 작업을 할 수 있습니다.
**참고**  
권한 정책은 MFA 조건을 포함하지 않습니다. MFA 인증은 사용자가 역할을 수임할 수 있는지 여부를 결정하는 데에만 사용된다는 점을 알아두세요. 사용자가 역할을 수임하면 MFA 검사가 추가로 수행되지 않습니다.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Sid": "TableActions",
               "Effect": "Allow",
               "Action": "dynamodb:*",
               "Resource": "arn:aws:dynamodb:*:111122223333:table/Books"
           },
           {
               "Sid": "ListTables",
               "Effect": "Allow",
               "Action": "dynamodb:ListTables",
               "Resource": "*"
           }
       ]
   }
   ```

------

1. 신뢰할 수 있는 계정 B에서 관리자는 IAM 사용자 Richard가 AWS MFA 디바이스로 구성되었는지, 그리고 그가 이 디바이스의 ID를 알고 있는지 확인합니다. 디바이스 ID란 하드웨어 MFA 디바이스의 경우 일련 번호이며, 가상 MFA 디바이스의 경우 해당 디바이스의 ARN입니다.

1. 계정 B에서 관리자는 사용자 Richard(또는 그가 소속된 그룹)에게 `AssumeRole` 작업을 호출할 수 있도록 허용하는 다음과 같은 정책을 연결합니다. 리소스는 Anaya가 1단계에서 생성한 역할의 ARN으로 설정됩니다. 이 정책에는 MFA 조건이 포함되어 있지 않습니다.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": [
           {
               "Effect": "Allow",
               "Action": [
                   "sts:AssumeRole"
               ],
               "Resource": [
                   "arn:aws:iam::111122223333:role/CrossAccountRole"
               ]
           }
       ]
   }
   ```

------

1. 계정 B에서 Richard(또는 Richard가 실행하는 애플리케이션)는 `AssumeRole`을 호출합니다. API 호출에는 위임할 역할의 ARN(`arn:aws:iam::ACCOUNT-A-ID:role/CrossAccountRole`), MFA 디바이스의 ID 및 Richard가 자신의 디바이스에서 가져오는 현재 TOTP가 포함되어 있습니다.

   Richard가 `AssumeRole`을 호출하면, AWS에서 그가 MFA에 대한 요건을 포함해 유효한 자격 증명을 갖고 있는지 여부를 확인합니다. 만일 Richard가 유효한 자격 증명을 갖고 있다면 성공적으로 역할을 수임해 역할의 임시 자격 증명을 사용함과 동시에 계정 A에서 `Books`라는 테이블에 대해 어떤 DynamoDB 작업도 수행할 수 있습니다.

   `AssumeRole`을 호출하는 프로그램의 예는 [MFA 인증이 포함된 AssumeRole 호출](id_credentials_mfa_sample-code.md#MFAProtectedAPI-example-assumerole) 섹션을 참조하세요.

## 시나리오: 현재 계정의 API 작업에 대한 액세스를 위한 MFA 보호
<a name="MFAProtectedAPI-user-mfa"></a>

이 시나리오에서는 AWS 계정의 사용자가 AWS MFA 디바이스를 사용해 인증받은 경우에만 중요한 API 작업에 액세스할 수 있는지 확인해야 합니다.

계정 A에 EC2 인스턴스로 작업해야 하는 개발자 그룹이 있다고 가정해 봅시다. 일반적인 개발자들은 이 인스턴스를 사용할 수 있지만, `ec2:StopInstances` 또는 `ec2:TerminateInstances` 작업에 대한 권한은 없습니다. 그와 같은 "안전하지 않은" 권한이 있는 작업을 일부 신뢰할 수 있는 사용자만 액세스할 수 있게 제한하고자 하여, 이러한 민감한 Amazon EC2 작업을 허용하는 정책에 MFA 보호를 추가합니다.

이 시나리오에서 신뢰할 수 있는 사용자 중 한 명은 사용자 Sofía입니다. 사용자 Anaya는 계정 A의 관리자입니다.

1. Anaya는 Sofia가 AWS MFA 디바이스로 구성되었는지, 그리고 Sofia가 이 디바이스의 ID를 알고 있는지 확인합니다. 디바이스 ID란 하드웨어 MFA 디바이스의 경우 일련 번호이며, 가상 MFA 디바이스의 경우 해당 디바이스의 ARN입니다.

1. Anaya는 `EC2-Admins`라는 그룹을 생성하고 이 그룹에 사용자 Sofía를 추가합니다.

1. Anaya는 `EC2-Admins` 그룹에 다음과 같은 정책을 연결합니다. 이 정책은 사용자에게 Amazon EC2 `StopInstances` 및 `TerminateInstances` 작업을 호출할 권한을 부여하는데, 단 이 사용자가 MFA를 사용하여 인증되었을 경우에 한합니다.

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [{
       "Effect": "Allow",
       "Action": [
         "ec2:StopInstances",
         "ec2:TerminateInstances"
       ],
       "Resource": ["*"],
       "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
     }]
   }
   ```

------

1. 
**참고**  
이 정책의 효력이 발생하려면 사용자는 먼저 로그아웃한 한 후 다시 로그인해야 합니다.

   사용자 Sofía가 Amazon EC2 인스턴스를 중지하거나 종료해야 하는 경우, Sofia(또는 Sofia가 실행하는 애플리케이션)는 `GetSessionToken`을 호출합니다. 이 API 작업에서는 MFA 디바이스의 ID와 Sofia가 자신의 디바이스에서 가져오는 현재 TOTP를 전달합니다.

1. 사용자 Sofía(또는 Sofía가 사용하는 애플리케이션)는 `GetSessionToken`에서 제공하는 임시 자격 증명을 사용하여 Amazon EC2 `StopInstances` 또는 `TerminateInstances` 작업을 호출합니다.

   `GetSessionToken`을 호출하는 프로그램의 예는 이 문서의 후반부에 있는 [MFA 인증이 포함된 GetSessionToken 호출](id_credentials_mfa_sample-code.md#MFAProtectedAPI-example-getsessiontoken) 섹션을 참조하세요.

## 시나리오: 리소스 기반 정책이 있는 리소스에 대한 MFA 보호
<a name="MFAProtectedAPI-resource-policies"></a>

이 시나리오에서는 S3 버킷, SQS 대기열 또는 SNS 주제의 소유자입니다. 리소스에 액세스하는 모든 AWS 계정 사용자가 AWS MFA 디바이스로 인증되었는지 확인하려고 합니다.

이 시나리오는 사용자가 역할을 먼저 수임하지 않고도 크로스 계정 MFA 보호를 제공하는 방법을 설명합니다. 이 경우 사용자는 세 가지 조건이 충족되면 리소스에 액세스할 수 있습니다. 즉 사용자는 MFA로 인증을 받아야 하고, `GetSessionToken`에서 임시 보안 자격 증명을 가져올 수 있어야 하며, 리소스의 정책에서 신뢰하는 계정에 로그인해 있어야 합니다.

계정 A에 속해 있고 S3 버킷을 생성한다고 가정해 봅시다. 여러 AWS 계정에 속한 사용자에게 이 버킷에 대한 액세스를 부여하되, 사용자가 MFA로 인증한 경우에 한하고자 합니다.

이 시나리오에서 사용자 Anaya는 계정 A의 관리자입니다. 사용자 Nikhil은 계정 C의 IAM 사용자입니다.

1. 계정 A에서 Anaya는 `Account-A-bucket`이라는 버킷을 생성합니다.

1. Anaya는 이 버킷에 버킷 정책을 추가합니다. 이 정책은 계정 A, 계정 B 또는 계정 C의 모든 사용자가 이 버킷에서 Amazon S3 `PutObject` 및 `DeleteObject` 작업을 수행하도록 허용합니다. 이 정책에는 MFA 조건이 포함되어 있습니다.

------
#### [ JSON ]

****  

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [{
       "Effect": "Allow",
       "Principal": {"AWS": [
         "ACCOUNT-A-ID",
         "ACCOUNT-B-ID",
         "ACCOUNT-C-ID"
       ]},
       "Action": [
         "s3:PutObject",
         "s3:DeleteObject"
       ],
       "Resource": ["arn:aws:s3:::ACCOUNT-A-BUCKET-NAME/*"],
       "Condition": {"Bool": {"aws:MultiFactorAuthPresent": "true"}}
     }]
   }
   ```

------
**참고**  
Amazon S3는 *루트* 계정 액세스에 대해(서만) MFA Delete 기능을 제공합니다. 버킷의 버전 관리 상태를 설정할 때 Amazon S3 MFA Delete를 활성화할 수 있습니다. Amazon S3 MFA Delete는 IAM 사용자에 적용할 수 없으며 MFA 보호 API 액세스와 별개로 관리됩니다. 버킷을 삭제할 권한이 있는 IAM 사용자도 Amazon S3 MFA Delete가 활성화된 버킷은 삭제할 수 없습니다. Amazon S3 MFA Delete에 대한 자세한 내용은 [MFA Delete](https://docs.aws.amazon.com/AmazonS3/latest/dev/MultiFactorAuthenticationDelete.html)를 참조하세요.

1. 계정 C에서 관리자는 사용자 Nikhil이 AWS MFA 디바이스로 구성되어 있고 해당 디바이스의 ID를 알고 있는지 확인합니다. 디바이스 ID란 하드웨어 MFA 디바이스의 경우 일련 번호이며, 가상 MFA 디바이스의 경우 해당 디바이스의 ARN입니다.

1. 계정 C에서 Nikhil(또는 그가 실행하는 애플리케이션)은 `GetSessionToken`을 호출합니다. 이 호출에는 MFA 디바이스의 ID 또는 ARN과 Nikhil이 자신의 디바이스에서 가져오는 현재 TOTP가 포함되어 있습니다.

1. Nikhil(또는 그가 사용하는 애플리케이션)은 `GetSessionToken`에서 반환하는 임시 자격 증명을 사용하여 `Account-A-bucket`으로 파일을 업로드하는 Amazon S3 `PutObject` 작업을 호출합니다.

   `GetSessionToken`을 호출하는 프로그램의 예는 이 문서의 후반부에 있는 [MFA 인증이 포함된 GetSessionToken 호출](id_credentials_mfa_sample-code.md#MFAProtectedAPI-example-getsessiontoken) 섹션을 참조하세요.
**참고**  
`AssumeRole`이 반환하는 임시 자격 증명은 이 경우에는 유효하지 않습니다. 사용자는 역할 수임을 위해 MFA 정보를 제공할 수 있지만 `AssumeRole`에서 반환하는 임시 자격 증명에는 MFA 정보가 포함되어 있지 않습니다. 이 정보는 정책의 MFA 조건을 충족하기 위해 필요합니다.

# 샘플 코드: 멀티 팩터 인증이 포함된 자격 증명 요청
<a name="id_credentials_mfa_sample-code"></a>

다음 예에서는 `GetSessionToken` 및 `AssumeRole` 작업을 호출하고 MFA 인증 파라미터를 전달하는 방법을 보여줍니다. 권한이 없어도 `GetSessionToken`을 호출할 수 있지만, `AssumeRole`을 호출할 수 있게 허용하는 정책이 있어야 합니다. 반환된 자격 증명은 계정 내 모든 S3 버킷의 목록을 나열하는 데 사용됩니다.

## MFA 인증이 포함된 GetSessionToken 호출
<a name="MFAProtectedAPI-example-getsessiontoken"></a>

다음 예는 `GetSessionToken`을 호출하고 MFA 인증 정보를 전달하는 방법을 보여 줍니다. `GetSessionToken` 작업에서 반환하는 임시 보안 자격 증명은 이어서 계정 내 모든 S3 버킷의 목록을 나열하는 데 사용됩니다.

이 코드를 실행하는 사용자(또는 사용자가 속한 그룹)에게 연결된 정책에서는 반환된 임시 자격 증명에 대한 권한을 제공합니다. 이 코드 예의 경우 정책에서 사용자에게 Amazon S3 `ListBuckets` 작업을 요청할 수 있는 권한을 부여해야 합니다.

다음 코드 예시는 `GetSessionToken`의 사용 방법을 보여 줍니다.

------
#### [ CLI ]

**AWS CLI**  
**IAM ID용 단기 자격 증명 세트 가져오기**  
다음 `get-session-token` 명령은 직접 호출을 위한 IAM ID용 단기 자격 증명 세트를 가져옵니다. 정책에 따라 다중 인증(MFA)이 필요한 경우 요청에 이 자격 증명을 사용할 수 있습니다. 자격 증명은 생성 후 15분 뒤에 만료됩니다.  

```
aws sts get-session-token \
    --duration-seconds 900 \
    --serial-number "YourMFADeviceSerialNumber" \
    --token-code 123456
```
출력:  

```
{
    "Credentials": {
        "AccessKeyId": "ASIAIOSFODNN7EXAMPLE",
        "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY",
        "SessionToken": "AQoEXAMPLEH4aoAH0gNCAPyJxz4BlCFFxWNE1OPTgk5TthT+FvwqnKwRcOIfrRh3c/LTo6UDdyJwOOvEVPvLXCrrrUtdnniCEXAMPLE/IvU1dYUg2RVAJBanLiHb4IgRmpRV3zrkuWJOgQs8IZZaIv2BXIa2R4OlgkBN9bkUDNCJiBeb/AXlzBBko7b15fjrBs2+cTQtpZ3CYWFXG8C5zqx37wnOE49mRl/+OtkIKGO7fAE",
        "Expiration": "2020-05-19T18:06:10+00:00"
    }
}
```
자세한 내용은 *AWS IAM 사용자 안내서*의 [임시 보안 자격 증명 요청](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#api_getsessiontoken)을 참조하세요.  
+  API 세부 정보는 *AWS CLI 명령 참조*의 [GetSessionToken](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sts/get-session-token.html)을 참조하세요.

------
#### [ PowerShell ]

**Tools for PowerShell V4**  
**예제 1: 설정된 기간 동안 유효한 임시 자격 증명이 포함된 `Amazon.RuntimeAWSCredentials` 인스턴스를 반환합니다. 임시 자격 증명을 요청하는 데 사용되는 자격 증명은 현재 쉘 기본값에서 유추됩니다. 다른 자격 증명을 지정하려면 -ProfileName 또는 -AccessKey/-SecretKey 파라미터를 사용합니다.**  

```
Get-STSSessionToken
```
**출력:**  

```
AccessKeyId                             Expiration                              SecretAccessKey                        SessionToken
-----------                             ----------                              ---------------                        ------------
EXAMPLEACCESSKEYID                      2/16/2015 9:12:28 PM                    examplesecretaccesskey...              SamPleTokeN.....
```
**예제 2: 1시간 동안 유효한 임시 자격 증명이 포함된 `Amazon.RuntimeAWSCredentials` 인스턴스를 반환합니다. 요청에 사용되는 자격 증명은 지정된 프로파일에서 가져옵니다.**  

```
Get-STSSessionToken -DurationInSeconds 3600 -ProfileName myprofile
```
**출력:**  

```
AccessKeyId                             Expiration                              SecretAccessKey                        SessionToken
-----------                             ----------                              ---------------                        ------------
EXAMPLEACCESSKEYID                      2/16/2015 9:12:28 PM                    examplesecretaccesskey...              SamPleTokeN.....
```
**예제 3: 프로파일 'myprofilename'에 자격 증명이 지정된 계정과 연결된 MFA 디바이스의 식별 번호와 디바이스에서 제공한 값을 사용하여 1시간 동안 유효한 임시 자격 증명이 들어 있는 `Amazon.RuntimeAWSCredentials` 인스턴스를 반환합니다.**  

```
Get-STSSessionToken -DurationInSeconds 3600 -ProfileName myprofile -SerialNumber YourMFADeviceSerialNumber -TokenCode 123456
```
**출력:**  

```
AccessKeyId                             Expiration                              SecretAccessKey                        SessionToken
-----------                             ----------                              ---------------                        ------------
EXAMPLEACCESSKEYID                      2/16/2015 9:12:28 PM                    examplesecretaccesskey...              SamPleTokeN.....
```
+  API 세부 정보는 **AWS Tools for PowerShell Cmdlet 참조(V4)의 [GetSessionToken](https://docs.aws.amazon.com/powershell/v4/reference)을 참조하세요.

**Tools for PowerShell V5**  
**예제 1: 설정된 기간 동안 유효한 임시 자격 증명이 포함된 `Amazon.RuntimeAWSCredentials` 인스턴스를 반환합니다. 임시 자격 증명을 요청하는 데 사용되는 자격 증명은 현재 쉘 기본값에서 유추됩니다. 다른 자격 증명을 지정하려면 -ProfileName 또는 -AccessKey/-SecretKey 파라미터를 사용합니다.**  

```
Get-STSSessionToken
```
**출력:**  

```
AccessKeyId                             Expiration                              SecretAccessKey                        SessionToken
-----------                             ----------                              ---------------                        ------------
EXAMPLEACCESSKEYID                      2/16/2015 9:12:28 PM                    examplesecretaccesskey...              SamPleTokeN.....
```
**예제 2: 1시간 동안 유효한 임시 자격 증명이 포함된 `Amazon.RuntimeAWSCredentials` 인스턴스를 반환합니다. 요청에 사용되는 자격 증명은 지정된 프로파일에서 가져옵니다.**  

```
Get-STSSessionToken -DurationInSeconds 3600 -ProfileName myprofile
```
**출력:**  

```
AccessKeyId                             Expiration                              SecretAccessKey                        SessionToken
-----------                             ----------                              ---------------                        ------------
EXAMPLEACCESSKEYID                      2/16/2015 9:12:28 PM                    examplesecretaccesskey...              SamPleTokeN.....
```
**예제 3: 프로파일 'myprofilename'에 자격 증명이 지정된 계정과 연결된 MFA 디바이스의 식별 번호와 디바이스에서 제공한 값을 사용하여 1시간 동안 유효한 임시 자격 증명이 들어 있는 `Amazon.RuntimeAWSCredentials` 인스턴스를 반환합니다.**  

```
Get-STSSessionToken -DurationInSeconds 3600 -ProfileName myprofile -SerialNumber YourMFADeviceSerialNumber -TokenCode 123456
```
**출력:**  

```
AccessKeyId                             Expiration                              SecretAccessKey                        SessionToken
-----------                             ----------                              ---------------                        ------------
EXAMPLEACCESSKEYID                      2/16/2015 9:12:28 PM                    examplesecretaccesskey...              SamPleTokeN.....
```
+  API 세부 정보는 *AWS Tools for PowerShell Cmdlet 참조(V5)*의 [GetSessionToken](https://docs.aws.amazon.com/powershell/v5/reference)을 참조하세요.

------
#### [ Python ]

**SDK for Python(Boto3)**  
 GitHub에 더 많은 내용이 있습니다. [AWS 코드 예제 리포지토리](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/python/example_code/sts#code-examples)에서 전체 예제를 확인하고 설정 및 실행하는 방법을 알아보세요.
MFA 토큰을 전달하여 세션 토큰을 가져와 계정에 대한 Amazon S3 버킷을 나열하는 데 사용합니다.  

```
def list_buckets_with_session_token_with_mfa(mfa_serial_number, mfa_totp, sts_client):
    """
    Gets a session token with MFA credentials and uses the temporary session
    credentials to list Amazon S3 buckets.

    Requires an MFA device serial number and token.

    :param mfa_serial_number: The serial number of the MFA device. For a virtual MFA
                              device, this is an Amazon Resource Name (ARN).
    :param mfa_totp: A time-based, one-time password issued by the MFA device.
    :param sts_client: A Boto3 STS instance that has permission to assume the role.
    """
    if mfa_serial_number is not None:
        response = sts_client.get_session_token(
            SerialNumber=mfa_serial_number, TokenCode=mfa_totp
        )
    else:
        response = sts_client.get_session_token()
    temp_credentials = response["Credentials"]

    s3_resource = boto3.resource(
        "s3",
        aws_access_key_id=temp_credentials["AccessKeyId"],
        aws_secret_access_key=temp_credentials["SecretAccessKey"],
        aws_session_token=temp_credentials["SessionToken"],
    )

    print(f"Buckets for the account:")
    for bucket in s3_resource.buckets.all():
        print(bucket.name)
```
+  API 세부 정보는 *AWS SDK for Python (Boto3) API 참조*의 [GetSessionToken](https://docs.aws.amazon.com/goto/boto3/sts-2011-06-15/GetSessionToken)를 참조하세요.

------

## MFA 인증이 포함된 AssumeRole 호출
<a name="MFAProtectedAPI-example-assumerole"></a>

다음 예는 `AssumeRole`을(를) 호출하고 MFA 인증 정보를 전달하는 방법을 보여줍니다. `AssumeRole`에서 반환한 임시 보안 자격 증명은 계정의 모든 Amazon S3 버킷을 나열하는 데 사용됩니다.

이 시나리오에 대한 자세한 내용은 [시나리오: 크로스 계정 위임에 대한 MFA 보호](id_credentials_mfa_configure-api-require.md#MFAProtectedAPI-cross-account-delegation)를 참조하세요.

다음 코드 예시는 `AssumeRole`의 사용 방법을 보여 줍니다.

------
#### [ .NET ]

**SDK for .NET**  
 GitHub에 더 많은 내용이 있습니다. [AWS 코드 예제 리포지토리](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/dotnetv3/STS#code-examples)에서 전체 예제를 확인하고 설정 및 실행하는 방법을 알아보세요.

```
using System;
using System.Threading.Tasks;
using Amazon;
using Amazon.SecurityToken;
using Amazon.SecurityToken.Model;

namespace AssumeRoleExample
{
    class AssumeRole
    {
        /// <summary>
        /// This example shows how to use the AWS Security Token
        /// Service (AWS STS) to assume an IAM role.
        ///
        /// NOTE: It is important that the role that will be assumed has a
        /// trust relationship with the account that will assume the role.
        ///
        /// Before you run the example, you need to create the role you want to
        /// assume and have it trust the IAM account that will assume that role.
        ///
        /// See https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html
        /// for help in working with roles.
        /// </summary>

        // A region property may be used if the profile or credentials loaded do not specify a region,
        // or to use a specific region.
        private static readonly RegionEndpoint REGION = RegionEndpoint.USWest2;

        static async Task Main()
        {
            // Create the SecurityToken client and then display the identity of the
            // default user.
            var roleArnToAssume = "arn:aws:iam::123456789012:role/testAssumeRole";

            var client = new Amazon.SecurityToken.AmazonSecurityTokenServiceClient(REGION);

            // Get and display the information about the identity of the default user.
            var callerIdRequest = new GetCallerIdentityRequest();
            var caller = await client.GetCallerIdentityAsync(callerIdRequest);
            Console.WriteLine($"Original Caller: {caller.Arn}");

            // Create the request to use with the AssumeRoleAsync call.
            var assumeRoleReq = new AssumeRoleRequest()
            {
                DurationSeconds = 1600,
                RoleSessionName = "Session1",
                RoleArn = roleArnToAssume
            };

            var assumeRoleRes = await client.AssumeRoleAsync(assumeRoleReq);

            // Now create a new client based on the credentials of the caller assuming the role.
            var client2 = new AmazonSecurityTokenServiceClient(credentials: assumeRoleRes.Credentials, REGION);

            // Get and display information about the caller that has assumed the defined role.
            var caller2 = await client2.GetCallerIdentityAsync(callerIdRequest);
            Console.WriteLine($"AssumedRole Caller: {caller2.Arn}");
        }
    }
}
```
+  API 세부 정보는 *AWS SDK for .NET API 참조*의 [AssumeRole](https://docs.aws.amazon.com/goto/DotNetSDKV3/sts-2011-06-15/AssumeRole)을 참조하십시오.

------
#### [ Bash ]

**Bash 스크립트와 함께 AWS CLI사용**  
 GitHub에 더 많은 내용이 있습니다. [AWS 코드 예제 리포지토리](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/aws-cli/bash-linux/iam#code-examples)에서 전체 예제를 확인하고 설정 및 실행하는 방법을 알아보세요.

```
###############################################################################
# function iecho
#
# This function enables the script to display the specified text only if
# the global variable $VERBOSE is set to true.
###############################################################################
function iecho() {
  if [[ $VERBOSE == true ]]; then
    echo "$@"
  fi
}

###############################################################################
# function errecho
#
# This function outputs everything sent to it to STDERR (standard error output).
###############################################################################
function errecho() {
  printf "%s\n" "$*" 1>&2
}

###############################################################################
# function sts_assume_role
#
# This function assumes a role in the AWS account and returns the temporary
#  credentials.
#
# Parameters:
#       -n role_session_name -- The name of the session.
#       -r role_arn -- The ARN of the role to assume.
#
# Returns:
#       [access_key_id, secret_access_key, session_token]
#     And:
#       0 - If successful.
#       1 - If an error occurred.
###############################################################################
function sts_assume_role() {
  local role_session_name role_arn response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function sts_assume_role"
    echo "Assumes a role in the AWS account and returns the temporary credentials:"
    echo "  -n role_session_name -- The name of the session."
    echo "  -r role_arn -- The ARN of the role to assume."
    echo ""
  }

  while getopts n:r:h option; do
    case "${option}" in
      n) role_session_name=${OPTARG} ;;
      r) role_arn=${OPTARG} ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done

  response=$(aws sts assume-role \
    --role-session-name "$role_session_name" \
    --role-arn "$role_arn" \
    --output text \
    --query "Credentials.[AccessKeyId, SecretAccessKey, SessionToken]")

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports create-role operation failed.\n$response"
    return 1
  fi

  echo "$response"

  return 0
}
```
+  API 세부 정보는 *AWS CLI명령 참조*의 [AssumeRole](https://docs.aws.amazon.com/goto/aws-cli/sts-2011-06-15/AssumeRole)을 참조하십시오.

------
#### [ C\$1\$1 ]

**SDK for C\$1\$1**  
 GitHub에 더 많은 내용이 있습니다. [AWS 코드 예제 리포지토리](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/cpp/example_code/sts#code-examples)에서 전체 예제를 확인하고 설정 및 실행하는 방법을 알아보세요.

```
bool AwsDoc::STS::assumeRole(const Aws::String &roleArn,
                             const Aws::String &roleSessionName,
                             const Aws::String &externalId,
                             Aws::Auth::AWSCredentials &credentials,
                             const Aws::Client::ClientConfiguration &clientConfig) {
    Aws::STS::STSClient sts(clientConfig);
    Aws::STS::Model::AssumeRoleRequest sts_req;

    sts_req.SetRoleArn(roleArn);
    sts_req.SetRoleSessionName(roleSessionName);
    sts_req.SetExternalId(externalId);

    const Aws::STS::Model::AssumeRoleOutcome outcome = sts.AssumeRole(sts_req);

    if (!outcome.IsSuccess()) {
        std::cerr << "Error assuming IAM role. " <<
                  outcome.GetError().GetMessage() << std::endl;
    }
    else {
        std::cout << "Credentials successfully retrieved." << std::endl;
        const Aws::STS::Model::AssumeRoleResult result = outcome.GetResult();
        const Aws::STS::Model::Credentials &temp_credentials = result.GetCredentials();

        // Store temporary credentials in return argument.
        // Note: The credentials object returned by assumeRole differs
        // from the AWSCredentials object used in most situations.
        credentials.SetAWSAccessKeyId(temp_credentials.GetAccessKeyId());
        credentials.SetAWSSecretKey(temp_credentials.GetSecretAccessKey());
        credentials.SetSessionToken(temp_credentials.GetSessionToken());
    }

    return outcome.IsSuccess();
}
```
+  API 세부 정보는 *AWS SDK for C\$1\$1 API 참조*의 [AssumeRole](https://docs.aws.amazon.com/goto/SdkForCpp/sts-2011-06-15/AssumeRole)을 참조하세요.

------
#### [ CLI ]

**AWS CLI**  
**역할 수임**  
다음 `assume-role` 명령은 IAM 역할 `s3-access-example`에 대한 단기 자격 증명 세트를 가져옵니다.  

```
aws sts assume-role \
    --role-arn arn:aws:iam::123456789012:role/xaccounts3access \
    --role-session-name s3-access-example
```
출력:  

```
{
    "AssumedRoleUser": {
        "AssumedRoleId": "AROA3XFRBF535PLBIFPI4:s3-access-example",
        "Arn": "arn:aws:sts::123456789012:assumed-role/xaccounts3access/s3-access-example"
    },
    "Credentials": {
        "SecretAccessKey": "9drTJvcXLB89EXAMPLELB8923FB892xMFI",
        "SessionToken": "AQoXdzELDDY//////////wEaoAK1wvxJY12r2IrDFT2IvAzTCn3zHoZ7YNtpiQLF0MqZye/qwjzP2iEXAMPLEbw/m3hsj8VBTkPORGvr9jM5sgP+w9IZWZnU+LWhmg+a5fDi2oTGUYcdg9uexQ4mtCHIHfi4citgqZTgco40Yqr4lIlo4V2b2Dyauk0eYFNebHtYlFVgAUj+7Indz3LU0aTWk1WKIjHmmMCIoTkyYp/k7kUG7moeEYKSitwQIi6Gjn+nyzM+PtoA3685ixzv0R7i5rjQi0YE0lf1oeie3bDiNHncmzosRM6SFiPzSvp6h/32xQuZsjcypmwsPSDtTPYcs0+YN/8BRi2/IcrxSpnWEXAMPLEXSDFTAQAM6Dl9zR0tXoybnlrZIwMLlMi1Kcgo5OytwU=",
        "Expiration": "2016-03-15T00:05:07Z",
        "AccessKeyId": "ASIAJEXAMPLEXEG2JICEA"
    }
}
```
명령의 출력에는 AWS 인증에 사용할 수 있는 액세스 키, 시크릿 키 및 세션 토큰이 포함됩니다.  
AWS CLI를 사용하는 경우 역할과 연결된 이름이 지정된 프로파일을 설정할 수 있습니다. 프로파일을 사용하면 AWS CLI에서 assume-role을 호출하고 대신 자격 증명을 관리합니다. 자세한 내용은 *AWS IAM 사용자 안내서*의 [AWS CLI에서 IAM 역할 사용](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html)을 참조하세요.  
+  API 세부 정보는 *AWS CLI 명령 참조*의 [AssumeRole](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/sts/assume-role.html)을 참조하세요.

------
#### [ Java ]

**SDK for Java 2.x**  
 GitHub에 더 많은 내용이 있습니다. [AWS 코드 예제 리포지토리](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javav2/example_code/sts#code-examples)에서 전체 예제를 확인하고 설정 및 실행하는 방법을 알아보세요.

```
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.sts.StsClient;
import software.amazon.awssdk.services.sts.model.AssumeRoleRequest;
import software.amazon.awssdk.services.sts.model.StsException;
import software.amazon.awssdk.services.sts.model.AssumeRoleResponse;
import software.amazon.awssdk.services.sts.model.Credentials;
import java.time.Instant;
import java.time.ZoneId;
import java.time.format.DateTimeFormatter;
import java.time.format.FormatStyle;
import java.util.Locale;

/**
 * To make this code example work, create a Role that you want to assume.
 * Then define a Trust Relationship in the AWS Console. You can use this as an
 * example:
 *
 * {
 * "Version":"2012-10-17",		 	 	 
 * "Statement": [
 * {
 * "Effect": "Allow",
 * "Principal": {
 * "AWS": "<Specify the ARN of your IAM user you are using in this code example>"
 * },
 * "Action": "sts:AssumeRole"
 * }
 * ]
 * }
 *
 * For more information, see "Editing the Trust Relationship for an Existing
 * Role" in the AWS Directory Service guide.
 *
 * Also, set up your development environment, including your credentials.
 *
 * For information, see this documentation topic:
 *
 * https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/get-started.html
 */
public class AssumeRole {
    public static void main(String[] args) {
        final String usage = """

                Usage:
                    <roleArn> <roleSessionName>\s

                Where:
                    roleArn - The Amazon Resource Name (ARN) of the role to assume (for example, arn:aws:iam::000008047983:role/s3role).\s
                    roleSessionName - An identifier for the assumed role session (for example, mysession).\s
                """;

        if (args.length != 2) {
            System.out.println(usage);
            System.exit(1);
        }

        String roleArn = args[0];
        String roleSessionName = args[1];
        Region region = Region.US_EAST_1;
        StsClient stsClient = StsClient.builder()
                .region(region)
                .build();

        assumeGivenRole(stsClient, roleArn, roleSessionName);
        stsClient.close();
    }

    public static void assumeGivenRole(StsClient stsClient, String roleArn, String roleSessionName) {
        try {
            AssumeRoleRequest roleRequest = AssumeRoleRequest.builder()
                    .roleArn(roleArn)
                    .roleSessionName(roleSessionName)
                    .build();

            AssumeRoleResponse roleResponse = stsClient.assumeRole(roleRequest);
            Credentials myCreds = roleResponse.credentials();

            // Display the time when the temp creds expire.
            Instant exTime = myCreds.expiration();
            String tokenInfo = myCreds.sessionToken();

            // Convert the Instant to readable date.
            DateTimeFormatter formatter = DateTimeFormatter.ofLocalizedDateTime(FormatStyle.SHORT)
                    .withLocale(Locale.US)
                    .withZone(ZoneId.systemDefault());

            formatter.format(exTime);
            System.out.println("The token " + tokenInfo + "  expires on " + exTime);

        } catch (StsException e) {
            System.err.println(e.getMessage());
            System.exit(1);
        }
    }
}
```
+  API 세부 정보는 *AWS SDK for Java 2.x API 참조*의 [AssumeRole](https://docs.aws.amazon.com/goto/SdkForJavaV2/sts-2011-06-15/AssumeRole)을 참조하십시오.

------
#### [ JavaScript ]

**SDK for JavaScript (v3)**  
 GitHub에 더 많은 내용이 있습니다. [AWS 코드 예제 리포지토리](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javascriptv3/example_code/sts#code-examples)에서 전체 예제를 확인하고 설정 및 실행하는 방법을 알아보세요.
클라이언트를 생성합니다.  

```
import { STSClient } from "@aws-sdk/client-sts";
// Set the AWS Region.
const REGION = "us-east-1";
// Create an AWS STS service client object.
export const client = new STSClient({ region: REGION });
```
IAM 역할을 수임합니다.  

```
import { AssumeRoleCommand } from "@aws-sdk/client-sts";

import { client } from "../libs/client.js";

export const main = async () => {
  try {
    // Returns a set of temporary security credentials that you can use to
    // access Amazon Web Services resources that you might not normally
    // have access to.
    const command = new AssumeRoleCommand({
      // The Amazon Resource Name (ARN) of the role to assume.
      RoleArn: "ROLE_ARN",
      // An identifier for the assumed role session.
      RoleSessionName: "session1",
      // The duration, in seconds, of the role session. The value specified
      // can range from 900 seconds (15 minutes) up to the maximum session
      // duration set for the role.
      DurationSeconds: 900,
    });
    const response = await client.send(command);
    console.log(response);
  } catch (err) {
    console.error(err);
  }
};
```
+  API 세부 정보는 *AWS SDK for JavaScript API 참조*의 [AssumeRole](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/sts/command/AssumeRoleCommand)을 참조하십시오.

**SDK for JavaScript (v2)**  
 GitHub에 더 많은 내용이 있습니다. [AWS 코드 예제 리포지토리](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javascript/example_code/sts#code-examples)에서 전체 예제를 확인하고 설정 및 실행하는 방법을 알아보세요.

```
// Load the AWS SDK for Node.js
const AWS = require("aws-sdk");
// Set the region
AWS.config.update({ region: "REGION" });

var roleToAssume = {
  RoleArn: "arn:aws:iam::123456789012:role/RoleName",
  RoleSessionName: "session1",
  DurationSeconds: 900,
};
var roleCreds;

// Create the STS service object
var sts = new AWS.STS({ apiVersion: "2011-06-15" });

//Assume Role
sts.assumeRole(roleToAssume, function (err, data) {
  if (err) console.log(err, err.stack);
  else {
    roleCreds = {
      accessKeyId: data.Credentials.AccessKeyId,
      secretAccessKey: data.Credentials.SecretAccessKey,
      sessionToken: data.Credentials.SessionToken,
    };
    stsGetCallerIdentity(roleCreds);
  }
});

//Get Arn of current identity
function stsGetCallerIdentity(creds) {
  var stsParams = { credentials: creds };
  // Create STS service object
  var sts = new AWS.STS(stsParams);

  sts.getCallerIdentity({}, function (err, data) {
    if (err) {
      console.log(err, err.stack);
    } else {
      console.log(data.Arn);
    }
  });
}
```
+  API 세부 정보는 *AWS SDK for JavaScript API 참조*의 [AssumeRole](https://docs.aws.amazon.com/goto/AWSJavaScriptSDK/sts-2011-06-15/AssumeRole)을 참조하세요.

------
#### [ PowerShell ]

**Tools for PowerShell V4**  
**요청하는 사용자가 일반적으로 액세스할 수 없는 AWS 리소스에 액세스하는 데 1시간 동안 사용할 수 있는 임시 자격 증명(액세스 키, 비밀 키 및 세션 토큰) 세트를 반환합니다. 반환된 자격 증명에는 수임 중인 역할의 액세스 정책과 제공된 정책에 의해 허용되는 권한이 있습니다. 제공된 정책을 사용하여 수임 중인 역할의 액세스 정책에 의해 정의된 권한을 초과하는 권한을 부여할 수 없습니다.**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -Policy "...JSON policy..." -DurationInSeconds 3600
```
**예제 2: 수임된 역할의 액세스 정책에 정의된 것과 동일한 권한을 갖고 1시간 동안 유효한 임시 자격 증명 세트를 반환합니다.**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -DurationInSeconds 3600
```
**예제 3: cmdlet을 실행하는 데 사용되는 사용자 자격 증명과 연결된 MFA에서 생성된 토큰과 일련 번호를 제공하는 임시 자격 증명 세트를 반환합니다.**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -DurationInSeconds 3600 -SerialNumber "GAHT12345678" -TokenCode "123456"
```
**예제 4: 고객 계정에 정의된 역할을 수임한 임시 자격 증명 세트를 반환합니다. 타사에서 수임할 수 있는 각 역할에 대해 고객 계정은 역할이 수임될 때마다 -ExternalID 파라미터로 전달되는 식별자를 사용하여 역할을 생성해야 합니다.**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -DurationInSeconds 3600 -ExternalId "ABC123"
```
+  API 세부 정보는 **AWS Tools for PowerShell Cmdlet 참조(V4)의 [AssumeRole](https://docs.aws.amazon.com/powershell/v4/reference)을 참조하세요.

**Tools for PowerShell V5**  
**요청하는 사용자가 일반적으로 액세스할 수 없는 AWS 리소스에 액세스하는 데 1시간 동안 사용할 수 있는 임시 자격 증명(액세스 키, 비밀 키 및 세션 토큰) 세트를 반환합니다. 반환된 자격 증명에는 수임 중인 역할의 액세스 정책과 제공된 정책에 의해 허용되는 권한이 있습니다. 제공된 정책을 사용하여 수임 중인 역할의 액세스 정책에 의해 정의된 권한을 초과하는 권한을 부여할 수 없습니다.**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -Policy "...JSON policy..." -DurationInSeconds 3600
```
**예제 2: 수임된 역할의 액세스 정책에 정의된 것과 동일한 권한을 갖고 1시간 동안 유효한 임시 자격 증명 세트를 반환합니다.**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -DurationInSeconds 3600
```
**예제 3: cmdlet을 실행하는 데 사용되는 사용자 자격 증명과 연결된 MFA에서 생성된 토큰과 일련 번호를 제공하는 임시 자격 증명 세트를 반환합니다.**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -DurationInSeconds 3600 -SerialNumber "GAHT12345678" -TokenCode "123456"
```
**예제 4: 고객 계정에 정의된 역할을 수임한 임시 자격 증명 세트를 반환합니다. 타사에서 수임할 수 있는 각 역할에 대해 고객 계정은 역할이 수임될 때마다 -ExternalID 파라미터로 전달되는 식별자를 사용하여 역할을 생성해야 합니다.**  

```
Use-STSRole -RoleSessionName "Bob" -RoleArn "arn:aws:iam::123456789012:role/demo" -DurationInSeconds 3600 -ExternalId "ABC123"
```
+  API 세부 정보는 *AWS Tools for PowerShell Cmdlet 참조(V5)*의 [AssumeRole](https://docs.aws.amazon.com/powershell/v5/reference)을 참조하세요.

------
#### [ Python ]

**SDK for Python(Boto3)**  
 GitHub에 더 많은 내용이 있습니다. [AWS 코드 예제 리포지토리](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/python/example_code/sts#code-examples)에서 전체 예제를 확인하고 설정 및 실행하는 방법을 알아보세요.
MFA 토큰이 필요한 IAM 역할을 수임하고 임시 자격 증명을 사용하여 계정에 대한 Amazon S3 버킷을 나열합니다.  

```
def list_buckets_from_assumed_role_with_mfa(
    assume_role_arn, session_name, mfa_serial_number, mfa_totp, sts_client
):
    """
    Assumes a role from another account and uses the temporary credentials from
    that role to list the Amazon S3 buckets that are owned by the other account.
    Requires an MFA device serial number and token.

    The assumed role must grant permission to list the buckets in the other account.

    :param assume_role_arn: The Amazon Resource Name (ARN) of the role that
                            grants access to list the other account's buckets.
    :param session_name: The name of the STS session.
    :param mfa_serial_number: The serial number of the MFA device. For a virtual MFA
                              device, this is an ARN.
    :param mfa_totp: A time-based, one-time password issued by the MFA device.
    :param sts_client: A Boto3 STS instance that has permission to assume the role.
    """
    response = sts_client.assume_role(
        RoleArn=assume_role_arn,
        RoleSessionName=session_name,
        SerialNumber=mfa_serial_number,
        TokenCode=mfa_totp,
    )
    temp_credentials = response["Credentials"]
    print(f"Assumed role {assume_role_arn} and got temporary credentials.")

    s3_resource = boto3.resource(
        "s3",
        aws_access_key_id=temp_credentials["AccessKeyId"],
        aws_secret_access_key=temp_credentials["SecretAccessKey"],
        aws_session_token=temp_credentials["SessionToken"],
    )

    print(f"Listing buckets for the assumed role's account:")
    for bucket in s3_resource.buckets.all():
        print(bucket.name)
```
+  API 세부 정보는 *AWSSDK for Python (Boto3) API 참조*의 [AssumeRole](https://docs.aws.amazon.com/goto/boto3/sts-2011-06-15/AssumeRole)를 참조하십시오.

------
#### [ Ruby ]

**SDK for Ruby**  
 GitHub에 더 많은 내용이 있습니다. [AWS 코드 예제 리포지토리](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/ruby/example_code/iam#code-examples)에서 전체 예제를 확인하고 설정 및 실행하는 방법을 알아보세요.

```
  # Creates an AWS Security Token Service (AWS STS) client with specified credentials.
  # This is separated into a factory function so that it can be mocked for unit testing.
  #
  # @param key_id [String] The ID of the access key used by the STS client.
  # @param key_secret [String] The secret part of the access key used by the STS client.
  def create_sts_client(key_id, key_secret)
    Aws::STS::Client.new(access_key_id: key_id, secret_access_key: key_secret)
  end

  # Gets temporary credentials that can be used to assume a role.
  #
  # @param role_arn [String] The ARN of the role that is assumed when these credentials
  #                          are used.
  # @param sts_client [AWS::STS::Client] An AWS STS client.
  # @return [Aws::AssumeRoleCredentials] The credentials that can be used to assume the role.
  def assume_role(role_arn, sts_client)
    credentials = Aws::AssumeRoleCredentials.new(
      client: sts_client,
      role_arn: role_arn,
      role_session_name: 'create-use-assume-role-scenario'
    )
    @logger.info("Assumed role '#{role_arn}', got temporary credentials.")
    credentials
  end
```
+  API 세부 정보는 *AWS SDK for Ruby API 참조*의 [AssumeRole](https://docs.aws.amazon.com/goto/SdkForRubyV3/sts-2011-06-15/AssumeRole)을 참조하십시오.

------
#### [ Rust ]

**SDK for Rust**  
 GitHub에 더 많은 내용이 있습니다. [AWS 코드 예제 리포지토리](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/rustv1/examples/sts/#code-examples)에서 전체 예제를 확인하고 설정 및 실행하는 방법을 알아보세요.

```
async fn assume_role(config: &SdkConfig, role_name: String, session_name: Option<String>) {
    let provider = aws_config::sts::AssumeRoleProvider::builder(role_name)
        .session_name(session_name.unwrap_or("rust_sdk_example_session".into()))
        .configure(config)
        .build()
        .await;

    let local_config = aws_config::from_env()
        .credentials_provider(provider)
        .load()
        .await;
    let client = Client::new(&local_config);
    let req = client.get_caller_identity();
    let resp = req.send().await;
    match resp {
        Ok(e) => {
            println!("UserID :               {}", e.user_id().unwrap_or_default());
            println!("Account:               {}", e.account().unwrap_or_default());
            println!("Arn    :               {}", e.arn().unwrap_or_default());
        }
        Err(e) => println!("{:?}", e),
    }
}
```
+  API 세부 정보는 *AWS SDK for Rust API 참조*의 [AssumeRole](https://docs.rs/aws-sdk-sts/latest/aws_sdk_sts/client/struct.Client.html#method.assume_role)을 참조하십시오.

------
#### [ Swift ]

**SDK for Swift**  
 GitHub에 더 많은 내용이 있습니다. [AWS 코드 예제 리포지토리](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/swift/example_code/iam#code-examples)에서 전체 예제를 확인하고 설정 및 실행하는 방법을 알아보세요.

```
import AWSSTS

    public func assumeRole(role: IAMClientTypes.Role, sessionName: String)
        async throws -> STSClientTypes.Credentials
    {
        let input = AssumeRoleInput(
            roleArn: role.arn,
            roleSessionName: sessionName
        )
        do {
            let output = try await stsClient.assumeRole(input: input)

            guard let credentials = output.credentials else {
                throw ServiceHandlerError.authError
            }

            return credentials
        } catch {
            print("Error assuming role: ", dump(error))
            throw error
        }
    }
```
+  API 세부 정보는 *AWS SDK for Swift API 참조*의 [AssumeRole](https://sdk.amazonaws.com/swift/api/awssts/latest/documentation/awssts/stsclient/assumerole(input:))을 참조하십시오.

------

# IAM 사용자를 위한 서비스별 자격 증명
<a name="id_credentials_service-specific-creds"></a>

서비스별 자격 증명은 특정 AWS 서비스를 위해 설계된 특수 인증 메커니즘입니다. 해당 자격 증명은 표준 AWS 자격 증명에 비해 간소화된 인증을 제공하며 개별 AWS 서비스의 인증 요구 사항에 맞게 조정됩니다. 다수의 AWS 서비스에서 사용할 수 있는 액세스 키와는 다르게 서비스별 자격 증명은 해당 자격 증명이 생성된 서비스에서만 사용하도록 설계되었습니다. 이 타겟팅된 접근 방식은 자격 증명의 범위를 제한하여 보안을 강화합니다.

서비스별 자격 증명은 일반적으로 사용자 이름과 암호 쌍 또는 특정 서비스의 요구 사항에 따라 형식이 지정된 특수 API 키로 구성됩니다. 서비스별 자격 증명을 생성하면 기본적으로 활성화 상태이며 즉시 사용할 수 있습니다. IAM 사용자당 지원되는 각 서비스에 대해 최대 2개의 서비스별 보안 인증 세트를 보유할 수 있습니다. 이 제한을 통해, 필요한 경우 새 세트로 교체하는 동안 활성 세트 하나를 유지할 수 있습니다. 현재 AWS가 서비스별 자격 증명을 지원하는 서비스는 다음과 같습니다.

## 서비스별 자격 증명을 사용해야 하는 경우
<a name="id_credentials_service-specific-creds-usecase"></a>

서비스별 자격 증명은 AWS 자격 증명, AWS SDK 또는 AWS API와 기본적으로 호환되지 않는 타사 라이브러리, SDK, 도구 또는 애플리케이션과의 호환성을 위해 사용됩니다. 이러한 사용 사례에는 자체 호스팅 인프라나 다른 제공업체가 호스팅하는 서비스에서 AWS 서비스로 마이그레이션이 포함됩니다.

처음부터 시작할 때는 가능한 한 IAM 역할에서 제공하는 자격 증명과 같은 AWS 임시 자격 증명을 사용하여 AWS 임시 자격 증명을 지원하는 라이브러리나 AWS SDK를 통해 AWS 서비스로 인증하는 것이 좋습니다.

## 서비스별 자격 증명 교체
<a name="id_credentials_service-specific-creds-rotation"></a>

서비스별 자격 증명을 정기적으로 교체하는 것이 보안 모범 사례입니다. 애플리케이션을 중단하지 않고 자격 증명 교체:

1. 동일한 서비스 및 IAM 사용자에 대한 서비스별 자격 증명 두 번째 세트 생성

1. 모든 애플리케이션이 새 자격 증명을 사용하도록 업데이트하고 올바르게 작동하는지 확인합니다.

1. 기존 자격 증명의 상태를 '비활성화'로 변경합니다.

1. 모든 애플리케이션이 제대로 작동하는지 확인

1. 더 이상 필요하지 않다고 확인한 후 비활성화된 서비스별 자격 증명을 삭제합니다.

## 서비스별 자격 증명 모니터링
<a name="id_credentials_service-specific-creds-monitoring"></a>

AWS CloudTrail을 사용하여 AWS 계정의 서비스별 자격 증명 사용을 모니터링할 수 있습니다. 서비스별 자격 증명 사용과 관련된 CloudTrail 이벤트를 보려면 CloudTrail 로그에서 자격 증명이 사용된 서비스의 이벤트를 검토합니다. 자세한 내용은 [AWS CloudTrail을 사용하여 IAM 및 AWS STS API 호출 로깅](cloudtrail-integration.md) 섹션을 참조하세요.

추가 보안을 위해 CloudWatch 경보가 무단 액세스 또는 기타 보안 문제를 보여줄 수 있는 특정 자격 증명 사용 패턴을 알리도록 설정하는 것이 좋습니다. CloudWatch Logs에 대한 자세한 정보는 *AWS CloudTrail 사용 설명서*의 [Amazon CloudWatch Logs로 CloudTrail 로그 파일 모니터링](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/monitor-cloudtrail-log-files-with-cloudwatch-logs.html)을 참조하세요.

다음 주제에서는 서비스별 자격 증명에 대한 정보를 제공합니다.

**Topics**
+ [

## 서비스별 자격 증명을 사용해야 하는 경우
](#id_credentials_service-specific-creds-usecase)
+ [

## 서비스별 자격 증명 교체
](#id_credentials_service-specific-creds-rotation)
+ [

## 서비스별 자격 증명 모니터링
](#id_credentials_service-specific-creds-monitoring)
+ [

# Amazon Bedrock and Amazon CloudWatch Logs용 API 키
](id_credentials_bedrock_cloudwatchlogs.md)
+ [

# Amazon Keyspaces(Apache Cassandra용)와 함께 IAM 사용
](id_credentials_keyspaces.md)

# Amazon Bedrock and Amazon CloudWatch Logs용 API 키
<a name="id_credentials_bedrock_cloudwatchlogs"></a>

**참고**  
Amazon CloudWatch Logs API 키는 현재 미리 보기에서 사용할 수 있으며 향후 몇 주 내에 정식으로 출시될 예정입니다. Amazon CloudWatch Logs API 키는 이 페이지에 설명된 Amazon Bedrock 장기 API 키와 유사성이 매우 높습니다. Amazon CloudWatch Logs 장기 API 키에 대한 자세한 내용은 [HLC 엔드포인트를 사용하여 Amazon CloudWatch Logs로 로그 전송](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_HLC_Endpoint.html)을 참조하세요.

Amazon Bedrock은 선도적인 AI 회사 및 Amazon의 파운데이션 모델을 제공하는 완전관리형 서비스입니다. AWS Management Console을 통해 Amazon Bedrock에 액세스하고 AWS CLI, 또는 AWS API를 사용하여 프로그래밍 방식으로 액세스할 수 있습니다. 프로그래밍 방식으로 Amazon Bedrock에 요청을 할 때 [임시 보안 자격 증명](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html) 또는 Amazon Bedrock API 키를 사용하여 인증할 수 있습니다. Amazon Bedrock은 두 가지 유형의 API 키를 지원합니다.
+ **단기 API 키** - 단기 API 키는 AWS 서명 버전 4를 사용하는 미리 서명된 URL입니다. 단기 API 키는 API 키를 생성한 자격 증명과 동일한 권한 및 기한을 공유하며 최대 12시간 또는 콘솔 세션의 남은 시간 중 더 빨리 끝나는 기간 동안 유효합니다. Amazon Bedrock 콘솔, Python 패키지 `aws-bedrock-token-generator` 및 다른 프로그래밍 언어용 패키지를 사용하여 단기 API 키를 생성할 수 있습니다. 자세한 내용은 *Amazon Bedrock 사용 설명서*의 [Amazon Bedrock API에 쉽게 액세스할 수 있도록 Amazon Bedrock API 키 생성](https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys.html)을 참조하세요.
+ **장기 API 키** - 장기 API 키는 IAM 사용자와 연결되며 IAM [서비스별 자격 증명](id_credentials_service-specific-creds.md)을 사용하여 생성됩니다. 해당 자격 증명은 Amazon Bedrock에서만 사용하도록 설계되어 자격 증명 범위를 제한함으로써 보안을 강화합니다. 장기 API 키가 만료되는 만료 시간을 설정할 수 있습니다. IAM 또는 Amazon Bedrock 콘솔, AWS CLI 또는 AWS API를 사용하여 장기 API 키를 생성할 수 있습니다.

IAM 사용자는 Amazon Bedrock에 대해 최대 2개의 장기 API 키를 보유할 수 있으므로 보안 키 교체 사례 구현에 도움이 됩니다.

장기 API 키를 생성하면 자동으로 AWS 관리형 정책 [AmazonBedrockLimitedAccess](https://docs.aws.amazon.com/bedrock/latest/userguide/security-iam-awsmanpol.html#security-iam-awsmanpol-AmazonBedrockLimitedAccess)가 IAM 사용자에게 연결됩니다. 이 정책은 핵심 Amazon Bedrock API 작업에 대한 액세스 권한을 부여합니다. Amazon Bedrock 액세스가 추가로 필요한 경우 IAM 사용자의 권한을 수정할 수 있습니다. 권한 수정에 대한 자세한 내용은 [IAM 자격 증명 권한 추가 및 제거](access_policies_manage-attach-detach.md) 섹션을 참조하세요. Amazon Bedrock 키를 사용하는 방법에 대한 자세한 내용은 *Amazon Bedrock 사용 설명서*의 [Use an Amazon Bedrock API key](https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys-use.html)를 참조하세요.

**참고**  
장기 API 키는 단기 API 키에 비해 보안 위험도가 높습니다. 가능하면 단기 API 키 또는 임시 보안 자격 증명을 사용하는 것이 좋습니다. 장기 API 키를 사용하는 경우 키 교체를 정기적으로 수행하는 사례를 구현하는 것이 좋습니다.

## 사전 조건
<a name="id_credentials_bedrock_prerequisites"></a>

IAM 콘솔에서 Amazon Bedrock 장기 API 키를 생성하려면 먼저 다음 사전 조건을 충족해야 합니다.
+ 장기 API 키와 연결할 IAM 사용자입니다. IAM 사용자 생성 지침은 [AWS 계정에서 IAM 사용자 생성](id_users_create.md) 섹션을 참조하세요.
+ 다음과 같이 IAM 사용자의 서비스별 자격 증명을 관리할 수 있는 IAM 정책 권한을 보유해야 합니다. 예제 정책은 서비스별 자격 증명을 생성, 나열, 업데이트, 삭제하고 재설정할 수 있는 권한을 부여합니다. 리소스 요소의 `username` 값을 Amazon Bedrock API 키를 생성할 IAM 사용자의 이름으로 바꿉니다.

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Sid": "ManageBedrockServiceSpecificCredentials",
              "Effect": "Allow",
              "Action": [
                  "iam:CreateServiceSpecificCredential",
                  "iam:ListServiceSpecificCredentials",
                  "iam:UpdateServiceSpecificCredential",
                  "iam:DeleteServiceSpecificCredential",
                  "iam:ResetServiceSpecificCredential"
              ],
              "Resource": "arn:aws:iam::*:user/username"
          }
      ]
  }
  ```

------

## Amazon Bedrock에 대한 장기 API 키 생성(콘솔)
<a name="id_credentials_bedrock_console_create"></a>

**Amazon Bedrock 장기 API 키 생성(콘솔)**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. IAM 콘솔의 탐색 창에서 **사용자**를 선택합니다.

1. Amazon Bedrock 장기 API 키를 생성할 IAM 사용자를 선택합니다.

1. **보안 자격 증명** 탭을 선택합니다.

1. **Amazon Bedrock에 대한 API 키** 섹션에서 **API 키 생성**을 선택합니다.

1. **API 키 만료**가 된 경우 다음 중 하나를 수행하세요..
   + API 키 만료 기간을 **1**, **5**, **30**, **90** 또는 **365**일 중에서 선택합니다.
   + **사용자 지정 기간**을 선택하여 사용자 지정 API 키 만료 날짜를 지정합니다.
   + **만료 기간 없음**(권장되지 않음)을 선택합니다.

1. **API 키 생성**을 선택합니다.

1. API 키를 복사 또는 다운로드합니다. API 키 값을 볼 수 있는 것은 이 때가 유일합니다.
**중요**  
API 키를 안전하게 저장합니다. 대화 상자를 닫은 이후에는 API 키를 다시 검색할 수 없습니다. 시크릿 액세스 키를 분실하거나 잊어버린 경우 검색할 수 없습니다. 대신 새 액세스 키를 생성하고 이전 키를 비활성화하세요.

## Amazon Bedrock용 장기 API 키 생성(AWS CLI)
<a name="id_credentials_bedrock_cli_create"></a>

AWS CLI를 사용하여 Amazon Bedrock 장기 API 키를 생성하려면 다음 단계를 사용합니다.

1. [create-user](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-user.html) 명령을 사용해 Amazon Bedrock과 함께 사용할 IAM 사용자를 생성합니다.

   ```
   aws iam create-user \
       --user-name BedrockAPIKey_1
   ```

1. [attach-user-policy](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/attach-user-policy.html) 명령을 사용해 AWS 관리형 정책을 `AmazonBedrockLimitedAccess` Amazon Bedrock IAM 사용자에게 연결합니다.

   ```
   aws iam attach-user-policy --user-name BedrockAPIKey_1 \
       --policy-arn arn:aws:iam::aws:policy/AmazonBedrockLimitedAccess
   ```

1. [create-service-specific-credential](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-service-specific-credential.html) 명령을 사용해 Amazon Bedrock 장기 API 키를 생성합니다. 자격 증명 기간에는 1\$136600일 사이의 값을 지정할 수 있습니다. 자격 증명 기간을 지정하지 않으면 API 키가 만료되지 않습니다.

   만료 기간이 30일인 장기 API 키 생성:

   ```
   aws iam create-service-specific-credential \
       --user-name BedrockAPIKey_1 \
       --service-name bedrock.amazonaws.com \
       --credential-age-days 30
   ```

응답에 반환된 `ServiceApiKeyValue`는 장기 Amazon Bedrock API 키입니다. 나중에 검색할 수 없으므로 `ServiceApiKeyValue` 값을 안전하게 저장하세요.

### 장기 API 키 나열(AWS CLI)
<a name="id_credentials_bedrock_cli_list"></a>

특정 사용자의 Amazon Bedrock 장기 API 키 메타데이터를 나열하려면 [list-service-specific-credentials](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-service-specific-credentials.html) 명령을 `--user-name` 파라미터와 함께 사용합니다.

```
aws iam list-service-specific-credentials \
    --service-name bedrock.amazonaws.com \
    --user-name BedrockAPIKey_1
```

계정의 모든 Amazon Bedrock 장기 API 키 메타데이터를 나열하려면 [list-service-specific-credentials](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-service-specific-credentials.html) 명령을 `--all-users` 파라미터와 함께 사용합니다.

```
aws iam list-service-specific-credentials \
    --service-name bedrock.amazonaws.com \
    --all-users
```

### 장기 API 키 상태 업데이트(AWS CLI)
<a name="id_credentials_bedrock_cli_update"></a>

Amazon Bedrock에 대한 장기 API 키의 상태를 업데이트하려면 [update-service-specific-credential](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/update-service-specific-credential.html) 명령을 사용합니다.

```
aws iam update-service-specific-credential \
    --user-name "BedrockAPIKey_1" \
    --service-specific-credential-id "ACCA1234EXAMPLE1234" \
    --status Inactive|Active
```

## Amazon Bedrock용 장기 API 키 생성(AWS API)
<a name="id_credentials_bedrock_api"></a>

다음 API 작업을 사용하여 Amazon Bedrock에 대한 장기 API 키를 생성 및 관리할 수 있습니다.
+  [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceSpecificCredential.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceSpecificCredential.html) 
+  [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListServiceSpecificCredentials.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListServiceSpecificCredentials.html) 
+  [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateServiceSpecificCredential.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateServiceSpecificCredential.html) 
+  [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceSpecificCredential.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceSpecificCredential.html) 
+  [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ResetServiceSpecificCredential.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ResetServiceSpecificCredential.html) 

# Amazon Keyspaces(Apache Cassandra용)와 함께 IAM 사용
<a name="id_credentials_keyspaces"></a>

Amazon Keyspaces(Apache Cassandra용)는 고가용성의 확장 가능한 관리형 Apache Cassandra 호환 데이터베이스 서비스입니다. AWS Management Console을 통해 또는 프로그래밍 방식으로 Amazon Keyspaces에 액세스할 수 있습니다. 서비스별 자격 증명을 사용하여 프로그래밍 방식으로 Amazon Keyspaces에 액세스하려면 `cqlsh` 또는 오픈 소스 Cassandra 드라이버를 사용할 수 있습니다. *서비스별 자격 증명*에는 Cassandra가 인증 및 액세스 관리에 사용하는 것과 같은 사용자 이름과 암호가 포함됩니다. 사용자당 지원되는 각 서비스에 대해 최대 2개의 서비스별 보안 인증 세트를 보유할 수 있습니다.

AWS 액세스 키를 사용하여 프로그래밍 방식으로 Amazon Keyspaces에 액세스하려면 SigV4 플러그인과 함께 AWS SDK, AWS Command Line Interface(AWS CLI) 또는 오픈 소스 Cassandra 드라이버를 사용할 수 있습니다. 자세한 내용은 *Amazon Keyspaces (for Apache Cassandra) Developer Guide(Amazon Keyspaces(Apache Cassandra용) 개발자 안내서)*의 [Create and configure AWS credentials for Amazon Keyspaces(Amazon Keyspaces의 자격 증명 생성 및 구성)](https://docs.aws.amazon.com//keyspaces/latest/devguide/access.credentials.html)를 참조하세요.

**참고**  
콘솔을 통해서만 Amazon Keyspaces와 상호 작용하려는 경우에는 서비스별 자격 증명을 생성할 필요가 없습니다. 자세한 내용은 *Amazon Keyspaces (for Apache Cassandra) Developer Guide*(Amazon Keyspaces(Apache Cassandra용) 개발자 안내서)의 [Accessing Amazon Keyspaces using the console](https://docs.aws.amazon.com/keyspaces/latest/devguide/console_keyspaces.html)(콘솔을 사용하여 Amazon Keyspaces 액세스)을 참조하세요.

Amazon Keyspaces 액세스에 필요한 권한에 대한 자세한 내용은 *Amazon Keyspaces(Apache Cassandra용) 개발자 안내서*에서 [Amazon Keyspaces(Apache Cassandra용) 자격 증명 기반 정책 예](https://docs.aws.amazon.com/keyspaces/latest/devguide/security_iam_id-based-policy-examples.html#security_iam_id-based-policy-examples-console)를 참조하세요.

## Amazon Keyspaces 자격 증명 생성(콘솔)
<a name="keyspaces_credentials_console"></a>

AWS Management Console을 사용하여 IAM 사용자에 대한 Amazon Keyspaces(Apache Cassandra용) 자격 증명을 생성할 수 있습니다.

**Amazon Keyspaces 서비스별 자격 증명을 생성하려면(콘솔)**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **사용자**를 선택한 다음 자격 증명이 필요한 사용자의 이름을 선택합니다.

1. **보안 자격 증명(Security Credentials)** 탭의 **Amazon Keyspaces(Apache Cassandra용)에 대한 자격 증명(Credentials for Amazon Keyspaces (for Apache Cassandra))** 아래에서 **자격 증명 생성(Generate credentials)**을 선택합니다.

1. 이제 서비스별 자격 증명을 사용할 수 있습니다. 이 때가 암호를 보거나 다운로드 할 수 있는 유일한 시간입니다. 나중에 복구할 수 없습니다. 그러나 언제든지 암호를 재설정할 수 있습니다. 나중에 필요하므로 사용자와 암호를 안전한 위치에 저장하세요.

## Amazon Keyspaces 자격 증명 생성(AWS CLI)
<a name="keyspaces_credentials_cli"></a>

AWS CLI을 사용하여 IAM 사용자에 대한 Amazon Keyspaces(Apache Cassandra용) 자격 증명을 생성할 수 있습니다.

**Amazon Keyspaces 서비스별 자격 증명을 생성하려면(AWS CLI)**
+ 다음 명령을 사용합니다.
  + [aws iam create-service-specific-credential](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-specific-credential.html)

## Amazon Keyspaces 자격 증명 생성(AWS API)
<a name="keyspaces_credentials_api"></a>

AWS API를 사용하여 IAM 사용자에 대한 Amazon Keyspaces(Apache Cassandra용) 자격 증명을 생성할 수 있습니다.

**Amazon Keyspaces 서비스별 자격 증명을 생성하려면(AWS API)**
+ 다음 작업을 완료합니다.
  + [CreateServiceSpecificCredential](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceSpecificCredential.html) 

# 미사용 AWS 자격 증명 찾기
<a name="id_credentials_finding-unused"></a>

AWS 계정의 보안을 강화하려면 불필요한 IAM 사용자 보안 인증(암호와 액세스 키)을 제거합니다. 예를 들어, 사용자가 조직을 떠나거나 AWS 액세스가 더 이상 필요하지 않은 경우 해당 자격 증명을 찾아서 더 이상 작동하지 않도록 해야 합니다. 더 이상 필요 없는 자격 증명을 삭제하는 것이 가장 좋습니다. 나중에 필요한 경우가 생기면 언제든지 다시 생성할 수 있습니다. 적어도 암호를 변경하거나 액세스 키를 비활성화하여 이전 사용자가 더 이상 액세스할 수 없게 해야 합니다.

*미사용*은 이와는 다른 것으로 보통 특정 기간 동안 사용되지 않은 자격 증명을 뜻합니다.

## 미사용 암호 찾기
<a name="finding-unused-passwords"></a>

AWS Management Console을 사용하여 사용자의 암호 사용 정보를 볼 수 있습니다. 사용자 수가 많을 경우 콘솔을 사용하여 각 사용자가 자신의 콘솔 암호를 사용한 최종 시각에 대한 정보가 담긴 자격 증명 보고서를 다운로드할 수 있습니다. AWS CLI 또는 IAM API에서 해당 정보에 액세스할 수도 있습니다.

**미사용 암호를 확인하려면(콘솔)**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. 필요할 경우 사용자 테이블에 **Console last sign-in(콘솔 마지막 로그인)** 열을 추가합니다.

   1. 테이블 위 맨 오른쪽에서 설정 아이콘(![\[Settings icon\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/console-settings-icon.console.png))을 선택합니다.

   1. **표시되는 열 선택**에서 **콘솔 마지막 로그인**을 선택합니다.

   1. **확인**을 선택하여 사용자 목록으로 돌아갑니다.

1. [**Console last sign-in(콘솔 마지막 로그인)**] 열에 사용자가 콘솔을 통해 마지막으로 AWS에 로그인한 날짜가 표시됩니다. 이 정보를 통해 지정된 기간 이상 동안 암호를 사용하여 로그인하지 않은 사용자를 확인할 수 있습니다. 암호 사용자 중 로그인한 적이 없는 사용자는 이 열에 **없음**이라고 표시됩니다. **없음**은 암호가 없는 사용자를 나타냅니다. 최근에 사용된 적이 없는 암호는 삭제해야 할 자격 증명을 식별하기 위한 좋은 기준이 될 수 있습니다.
**중요**  
서비스 문제로 인해 암호가 마지막으로 사용된 데이터에 2018년 5월 3일 22:50 PDT \$1 2018년 5월 23일 14:08 PDT 사이의 암호 사용이 포함되어 있지 않습니다. 이는 IAM 콘솔에 표시되는 [마지막 로그인](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_finding-unused.html) 날짜, [IAM 자격 증명 보고서](https://docs.aws.amazon.com/IAM/latest/UserGuide/SupportedTypes.xmlid_credentials_getting-report.html)의 암호가 마지막으로 사용된 날짜와 [GetUser API 연산](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetUser.html)에 의해 반환되는 암호가 마지막으로 사용된 날짜에 영향을 줍니다. 사용자가 해당 기간에 로그인한 경우 반환되는 암호가 마지막으로 사용된 날짜는 사용자가 2018년 5월 3일 이전에 마지막으로 로그인한 날짜입니다. 사용자가 2018년 5월 23일 14:08 PDT 이후에 로그인한 경우 반환되는 암호가 마지막으로 사용된 날짜는 정확합니다.  
마지막으로 사용된 암호 정보를 사용하여 사용되지 않는 자격 증명을 식별하고 삭제하는 경우(예: 지난 90일 동안 AWS에 로그인하지 않은 사용자 삭제) 2018년 5월 23일 이후의 날짜를 포함하도록 평가 기간을 조정하는 것이 좋습니다. 또는 사용자가 액세스 키를 사용하여 AWS에 프로그래밍 방식으로 액세스하는 경우 액세스 키가 마지막으로 사용된 정보가 모든 날짜에 대해 정확하므로 해당 정보를 참조할 수 있습니다.

**자격 증명 보고서를 다운로드하여 미사용 암호를 찾으려면(콘솔)**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **자격 증명 보고서**를 선택합니다.

1. **보고서 다운로드**를 선택하여 `status_reports_<date>T<time>.csv`라는 쉼표 구분 값(CSV) 파일을 다운로드합니다. 5번째 열에는 날짜 또는 다음 중 하나가 있는 `password_last_used` 열이 포함됩니다.
   + **해당 없음** - 할당된 암호가 전혀 없는 사용자
   + **no\$1information** - IAM이 2014년 10월 20일에 암호 수명을 추적하기 시작한 이후 암호를 사용하지 않은 사용자

**미사용 암호를 찾으려면(AWS CLI)**  
미사용 암호를 찾으려면 다음 명령을 실행합니다.
+ `[aws iam list-users](https://docs.aws.amazon.com/cli/latest/reference/iam/list-users.html)`는 각자 `PasswordLastUsed` 값이 있는 사용자 목록을 반환합니다. 값이 비어 있는 경우 사용자에게 암호가 없거나 2014년 10월 20일 IAM이 암호 수명을 추적하기 시작한 이후 암호가 사용되지 않은 것입니다.

**미사용 암호를 찾으려면(AWS API)**  
미사용 암호를 찾으려면 다음 연산을 호출합니다.
+  ` [ListUsers](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListUsers.html)`는 각각 `<PasswordLastUsed>` 값이 있는 사용자의 집합을 반환합니다. 값이 비어 있는 경우 사용자에게 암호가 없거나 2014년 10월 20일 IAM이 암호 수명을 추적하기 시작한 이후 암호가 사용되지 않은 것입니다.

자격 증명 보고서를 다운로드하기 위한 명령어에 대한 자세한 내용은 [자격 증명 보고서 가져오기(AWS CLI)](id_credentials_getting-report.md#getting-credential-reports-cliapi)섹션을 참조하세요.

## 미사용 액세스 키 찾기
<a name="finding-unused-access-keys"></a>

AWS Management Console을 사용하여 사용자의 액세스 키 사용 정보를 볼 수 있습니다. 사용자 수가 많을 경우 콘솔을 사용하여 자격 증명 보고서를 다운로드하여 각 사용자가 자신의 액세스 키를 마지막으로 사용한 때를 알 수 있습니다. AWS CLI 또는 IAM API에서 해당 정보에 액세스할 수도 있습니다.

**미사용 액세스 키를 확인하려면(콘솔)**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **사용자**를 선택합니다.

1. 필요할 경우 사용자 테이블에 **Access key last used(마지막으로 사용한 액세스 키)** 열을 추가합니다.

   1. 테이블 위 맨 오른쪽에서 설정 아이콘(![\[Settings icon\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/console-settings-icon.console.png))을 선택합니다.

   1. **표시되는 열 선택**에서 **마지막으로 사용한 액세스 키**를 선택합니다.

   1. **확인**을 선택하여 사용자 목록으로 돌아갑니다.

1. **Access key last used(마지막으로 사용한 액세스 키)** 열에는 사용자가 프로그래밍 방식으로 AWS에 마지막으로 액세스한 때부터 경과한 일수가 표시됩니다. 이 정보를 통해 지정된 기간 이상 동안 액세스 키를 사용하지 않은 사용자를 확인할 수 있습니다. 액세스 키가 없는 사용자는 이 열에 **–**가 표시됩니다. 최근에 사용된 적이 없는 액세스 키는 삭제해야 할 자격 증명을 식별하기 위한 좋은 기준이 될 수 있습니다.

**자격 증명 보고서를 다운로드하여 미사용 액세스 키를 찾으려면(콘솔)**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **Credential Report(자격 증명 보고서)**를 선택합니다.

1. **보고서 다운로드**를 선택하여 `status_reports_<date>T<time>.csv`라는 쉼표 구분 값(CSV) 파일을 다운로드합니다. 열 11부터 13에는 액세스 키 1의 마지막 사용 날짜, 리전 및 서비스 정보가 표시됩니다. 열 16부터 18에는 액세스 키 2에 대해 동일한 정보가 표시됩니다. 값이 **해당 없음**으로 되어 있는 것은 사용자에게 액세스 키가 없거나 2015년 4월 22일 IAM이 액세스 키 수명을 추적하기 시작한 이후 사용자가 액세스 키를 사용하지 않았다는 것입니다.

**미사용 액세스 키를 확인하려면(AWS CLI)**  
미사용 액세스 키를 찾으려면 다음 명령을 실행합니다.
+ `[aws iam list-access-keys](https://docs.aws.amazon.com/cli/latest/reference/iam/list-access-keys.html)`는 `AccessKeyID`를 포함해 사용자의 액세스 키에 대한 정보를 반환합니다.
+ `[aws iam get-access-key-last-used](https://docs.aws.amazon.com/cli/latest/reference/iam/get-access-key-last-used.html)`는 액세스 키 ID를 받아들여 `LastUsedDate` 액세스 키의 마지막 사용 및 `Region` 마지막으로 요청된 서비스의 `ServiceName`을 포함하는 출력을 반환합니다. `LastUsedDate`가 없는 경우 2015년 4월 22일 IAM이 액세스 키 수명을 추적하기 시작한 이후 액세스 키가 사용되지 않은 것입니다.

**미사용 액세스 키를 확인하려면(AWS API)**  
미사용 액세스 키를 찾으려면 다음 연산을 호출합니다.
+ `[ListAccessKeys](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccessKeys.html)`는 지정된 사용자와 연결된 액세스 키에 대한 `AccessKeyID` 값의 목록을 반환합니다.
+ `[GetAccessKeyLastUsed](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccessKeyLastUsed.html)`는 액세스 키 ID를 받아들여 값의 집합을 반환합니다. `LastUsedDate`, 액세스 키가 마지막으로 사용된 `Region` 및 마지막으로 요청된 서비스의 `ServiceName`이 포함되어 있습니다. 값이 비어 있는 경우 사용자에게 액세스 키가 없거나 2015년 4월 22일 IAM이 액세스 키 수명을 추적하기 시작한 이후 액세스 키가 사용되지 않은 것입니다.

자격 증명 보고서를 다운로드하기 위한 명령어에 대한 자세한 내용은 [자격 증명 보고서 가져오기(AWS CLI)](id_credentials_getting-report.md#getting-credential-reports-cliapi)섹션을 참조하세요.

# AWS 계정의 자격 증명 보고서 생성
<a name="id_credentials_getting-report"></a>

계정의 모든 사용자와 암호, 액세스 키, MFA 디바이스 등 이들의 자격 증명 상태를 나열하는 *자격 증명 보고서*를 생성하고 다운로드할 수 있습니다. AWS Management Console, [AWS SDK](https://aws.amazon.com/tools) 및 [명령줄 도구](https://aws.amazon.com/tools/#Command_Line_Tools) 또는 IAM API에서 자격 증명 보고서를 가져올 수 있습니다.

**참고**  
IAM 자격 증명 보고서에는 암호, 사용자당 처음 두 개의 액세스 키, MFA 디바이스 및 X.509 서명 인증서와 같은 IAM 관리형 자격 증명만 포함됩니다. 서비스별 자격 증명(예: CodeCommit 암호 또는 Amazon Bedrock 장기 API 키, Amazon CloudWatch Logs 장기 API 키)이나 처음 두 개 이상의 다른 사용자 액세스 키는 보고서에 포함되지 않습니다. 완전한 자격 증명 가시성을 얻으려면 [ListServiceSpecificCredentials](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListServiceSpecificCredentials.html) 및 [ListAccessKeys](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAccessKeys.html) API를 사용합니다.

자격 증명 보고서를 사용하면 감사 및 규정 준수에 도움이 됩니다. 이 보고서를 통해 암호, 액세스 키 업데이트 등 보안 인증 수명 주기 요구 사항이 어떤 영향을 주는지 감사할 수 있습니다. 외부 감사자에게 이 보고서를 제공하거나 보고서를 직접 다운로드할 권한을 감사자에게 부여할 수 있습니다.

최소 네 시간에 한 번씩 자격 증명 보고서를 생성할 수 있습니다. 보고서를 요청하면 IAM은 먼저 해당 AWS 계정의 보고서가 4시간 이내에 생성되었는지 여부를 확인합니다. 네 시간 이내에 생성된 경우 최신 보고서를 다운로드하고, 계정의 최신 보고서가 생성된지 네 시간이 넘었거나 해당 계정에 대한 이전 보고서가 없는 경우 IAM이 새 보고서를 생성하고 다운로드합니다.

**Topics**
+ [

## 필수 권한
](#id_credentials_required_permissions)
+ [

## 보고서 형식 이해
](#id_credentials_understanding_the_report_format)
+ [

## 자격 증명 보고서 가져오기(콘솔)
](#getting-credential-reports-console)
+ [

## 자격 증명 보고서 가져오기(AWS CLI)
](#getting-credential-reports-cliapi)
+ [

## 자격 증명 보고서 가져오기(AWS API)
](#getting-credential-reports-api)

## 필수 권한
<a name="id_credentials_required_permissions"></a>

보고서를 생성하고 다운로드하려면 다음 권한이 필요합니다.
+ 자격 증명 보고서를 생성하려면 `iam:GenerateCredentialReport` 
+ 보고서를 다운로드하려면 `iam:GetCredentialReport`

## 보고서 형식 이해
<a name="id_credentials_understanding_the_report_format"></a>

자격 증명 보고서는 CSV(쉼표로 구분된 값) 파일 형식으로 되어 있습니다. 공통 스프레드시트 소프트웨어로 CSV 파일을 열어 분석을 수행하거나 CSV 파일을 프로그래밍 방식으로 사용하고 사용자 지정 분석을 수행하는 애플리케이션을 구축할 수 있습니다.

CSV 파일에는 다음 열이 포함되어 있습니다:

**user**  
사용자의 표시 이름입니다.

**arn**  
사용자의 Amazon 리소스 이름(ARN)입니다. ARN에 대한 자세한 내용은 [IAM ARN](reference_identifiers.md#identifiers-arns) 섹션을 참조하세요.

**user\$1creation\$1time**  
사용자가 생성된 날짜 및 시간([ISO 8601 날짜-시간 형식](https://en.wikipedia.org/wiki/ISO_8601))입니다.

**password\$1enabled**  
사용자에게 암호가 있는 경우 이 값은 `TRUE`입니다. 그렇지 않은 경우 이 값은 `FALSE`입니다. 조직의 일부로 생성된 새 멤버 계정에는 기본적으로 루트 사용자 자격 증명이 없으므로 이 값은 해당되는 새 멤버 계정에서 `FALSE`입니다.

**password\$1last\$1used**  
AWS 웹 사이트에 로그인하는 데 AWS 계정 루트 사용자 또는 사용자의 암호가 마지막으로 사용된 날짜 및 시간([ISO 8601 날짜-시간 형식](http://www.iso.org/iso/iso8601))입니다. 사용자의 마지막 로그인 시간을 캡처하는 AWS 웹 사이트는 AWS Management Console, AWS 토론 포럼, AWS Marketplace입니다. 암호가 5분 내에 두 번 이상 사용된 경우, 첫 번째 사용만 이 필드에 기록됩니다.  
+ 다음과 같은 경우 이 필드의 값은 `no_information`입니다.
  + 사용자의 암호가 사용된 적이 없는 경우.
  + 암호와 관련된 로그인 데이터가 없는 경우(예: IAM에서 2014년 10월 20일에 이 정보를 추적하기 시작한 이후로 사용자의 암호가 사용되지 않은 경우)
+ 사용자에게 암호가 없는 경우, 이 필드의 값은 `N/A`(해당 사항 없음)입니다.

**중요**  
서비스 문제로 인해 암호가 마지막으로 사용된 데이터에 2018년 5월 3일 22:50 PDT \$1 2018년 5월 23일 14:08 PDT 사이의 암호 사용이 포함되어 있지 않습니다. 이는 IAM 콘솔에 표시되는 [마지막 로그인](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_finding-unused.html) 날짜, [IAM 자격 증명 보고서](https://docs.aws.amazon.com/IAM/latest/UserGuide/SupportedTypes.xmlid_credentials_getting-report.html)의 암호가 마지막으로 사용된 날짜와 [GetUser API 연산](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetUser.html)에 의해 반환되는 암호가 마지막으로 사용된 날짜에 영향을 줍니다. 사용자가 해당 기간에 로그인한 경우 반환되는 암호가 마지막으로 사용된 날짜는 사용자가 2018년 5월 3일 이전에 마지막으로 로그인한 날짜입니다. 사용자가 2018년 5월 23일 14:08 PDT 이후에 로그인한 경우 반환되는 암호가 마지막으로 사용된 날짜는 정확합니다.  
마지막으로 사용된 암호 정보를 사용하여 사용되지 않는 자격 증명을 식별하고 삭제하는 경우(예: 지난 90일 동안 AWS에 로그인하지 않은 사용자 삭제) 2018년 5월 23일 이후의 날짜를 포함하도록 평가 기간을 조정하는 것이 좋습니다. 또는 사용자가 액세스 키를 사용하여 AWS에 프로그래밍 방식으로 액세스하는 경우 액세스 키가 마지막으로 사용된 정보가 모든 날짜에 대해 정확하므로 해당 정보를 참조할 수 있습니다.

**password\$1last\$1changed**  
사용자의 암호가 마지막으로 설정된 날짜 및 시간([ISO 8601 날짜-시간 형식)](https://en.wikipedia.org/wiki/ISO_8601)입니다. 사용자에게 암호가 없는 경우, 이 필드의 값은 `N/A`(해당 사항 없음)입니다.

**password\$1next\$1rotation**  
계정에 암호 교체를 요구하는 [암호 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/Using_ManagingPasswordPolicies.html)이 있는 경우, 사용자가 새 암호를 설정해야 할 때 이 필드에 날짜 및 시간([ISO 8601 날짜-시간 형식](https://en.wikipedia.org/wiki/ISO_8601))이 포함됩니다. AWS 계정(루트)의 값은 항상 `not_supported`입니다.

**mfa\$1active**  
사용자에 대해 [멀티 팩터 인증](id_credentials_mfa.md)(MFA) 디바이스를 사용하도록 설정된 경우, 이 값은 `TRUE`입니다. 그렇지 않은 경우 이 값은 `FALSE`입니다.

**access\$1key\$11\$1active**  
사용자에게 액세스 키가 있고 액세스 키의 상태가 `Active`이면, 이 값은 `TRUE`입니다. 그렇지 않은 경우 이 값은 `FALSE`입니다. 계정 루트 사용자와 IAM 사용자 모두에게 적용됩니다.

**access\$1key\$11\$1last\$1rotated**  
사용자의 액세스 키가 생성되었거나 마지막으로 변경된 날짜 및 시간([ISO 8601 날짜-시간 형식](https://en.wikipedia.org/wiki/ISO_8601))입니다. 사용자에게 활성 상태의 액세스 키가 없는 경우, 이 필드의 값은 `N/A`(해당 사항 없음)입니다. 계정 루트 사용자와 IAM 사용자 모두에게 적용됩니다.

**access\$1key\$11\$1last\$1used\$1date**  
사용자의 액세스 키를 AWS API 요청 서명에 마지막으로 사용한 날짜 및 시간([ISO 8601 날짜-시간 형식](https://en.wikipedia.org/wiki/ISO_8601))입니다. 액세스 키가 15분 내에 두 번 이상 사용된 경우, 첫 번째 사용만 이 필드에 기록됩니다. 계정 루트 사용자와 IAM 사용자 모두에게 적용됩니다.  
다음과 같은 경우 이 필드의 값은 `N/A`(해당 사항 없음)입니다.  
+ 사용자에게 액세스 키가 없는 경우.
+ 액세스 키가 사용된 적이 없는 경우.
+ IAM에서 2015년 4월 22일에 이 정보를 추적하기 시작한 이후로 액세스 키가 사용되지 않은 경우

**access\$1key\$11\$1last\$1used\$1region**  
액세스 키가 마지막으로 사용된 [AWS 리전](https://docs.aws.amazon.com/general/latest/gr/rande.html)입니다. 액세스 키가 15분 내에 두 번 이상 사용된 경우, 첫 번째 사용만 이 필드에 기록됩니다. 계정 루트 사용자와 IAM 사용자 모두에게 적용됩니다.  
다음과 같은 경우 이 필드의 값은 `N/A`(해당 사항 없음)입니다.  
+ 사용자에게 액세스 키가 없는 경우.
+ 액세스 키가 사용된 적이 없는 경우.
+ IAM에서 2015년 4월 22일에 이 정보의 추적을 시작하기 전에 액세스 키가 마지막으로 사용된 경우
+ 마지막으로 사용한 서비스가 리전 전용이 아닌 경우(예: Amazon S3)

**access\$1key\$11\$1last\$1used\$1service**  
액세스 키로 가장 최근에 액세스한 AWS 제품입니다. 이 필드의 값은 서비스의 네임스페이스를 사용합니다. 예를 들어 Amazon S3의 경우 `s3`, Amazon EC2의 경우 `ec2`를 사용합니다. 액세스 키가 15분 내에 두 번 이상 사용된 경우, 첫 번째 사용만 이 필드에 기록됩니다. 계정 루트 사용자와 IAM 사용자 모두에게 적용됩니다.  
다음과 같은 경우 이 필드의 값은 `N/A`(해당 사항 없음)입니다.  
+ 사용자에게 액세스 키가 없는 경우.
+ 액세스 키가 사용된 적이 없는 경우.
+ IAM에서 2015년 4월 22일에 이 정보의 추적을 시작하기 전에 액세스 키가 마지막으로 사용된 경우

**access\$1key\$12\$1active**  
사용자에게 두 번째 액세스 키가 있고 두 번째 키의 상태가 `Active`이면, 이 값은 `TRUE`입니다. 그렇지 않은 경우 이 값은 `FALSE`입니다. 계정 루트 사용자와 IAM 사용자 모두에게 적용됩니다.  
사용자는 쉽게 교체할 수 있도록 최대 2개의 액세스 키를 보유할 수 있습니다. 이 경우 키를 먼저 업데이트한 다음 이전 키를 삭제하면 됩니다. 액세스 키 업데이트에 대한 자세한 내용은 [액세스 키 업데이트](id-credentials-access-keys-update.md) 섹션을 참조하세요.

**access\$1key\$12\$1last\$1rotated**  
사용자의 두 번째 액세스 키가 생성되었거나 마지막으로 변경된 날짜 및 시간([ISO 8601 날짜-시간 형식](https://en.wikipedia.org/wiki/ISO_8601))입니다. 사용자에게 활성 상태의 두 번째 액세스 키가 있는 경우, 이 필드의 값은 `N/A`(해당 사항 없음)입니다. 계정 루트 사용자와 IAM 사용자 모두에게 적용됩니다.

**access\$1key\$12\$1last\$1used\$1date**  
AWS API 요청에 서명하는 데 사용자의 두 번째 액세스 키가 마지막으로 사용된 날짜 및 시간([ISO 8601 날짜-시간 형식](https://en.wikipedia.org/wiki/ISO_8601))입니다. 액세스 키가 15분 내에 두 번 이상 사용된 경우, 첫 번째 사용만 이 필드에 기록됩니다. 계정 루트 사용자와 IAM 사용자 모두에게 적용됩니다.  
다음과 같은 경우 이 필드의 값은 `N/A`(해당 사항 없음)입니다.  
+ 사용자에게 두 번째 액세스 키가 없는 경우.
+ 사용자의 두 번째 액세스 키가 사용된 적이 없는 경우.
+ IAM에서 2015년 4월 22일에 이 정보의 추적을 시작하기 전에 사용자의 두 번째 액세스 키가 마지막으로 사용된 경우

**access\$1key\$12\$1last\$1used\$1region**  
사용자의 두 번째 액세스 키가 마지막으로 사용된 [AWS 리전](https://docs.aws.amazon.com/general/latest/gr/rande.html)입니다. 액세스 키가 15분 내에 두 번 이상 사용된 경우, 첫 번째 사용만 이 필드에 기록됩니다. 계정 루트 사용자와 IAM 사용자 모두에게 적용됩니다. 다음과 같은 경우 이 필드의 값은 `N/A`(해당 사항 없음)입니다.  
+ 사용자에게 두 번째 액세스 키가 없는 경우.
+ 사용자의 두 번째 액세스 키가 사용된 적이 없는 경우.
+ IAM에서 2015년 4월 22일에 이 정보의 추적을 시작하기 전에 사용자의 두 번째 액세스 키가 마지막으로 사용된 경우
+ 마지막으로 사용한 서비스가 리전 전용이 아닌 경우(예: Amazon S3)

**access\$1key\$12\$1last\$1used\$1service**  
사용자의 두 번째 액세스 키로 가장 최근에 액세스한 AWS 서비스입니다. 이 필드의 값은 서비스의 네임스페이스를 사용합니다. 예를 들어 Amazon S3의 경우 `s3`, Amazon EC2의 경우 `ec2`를 사용합니다. 액세스 키가 15분 내에 두 번 이상 사용된 경우, 첫 번째 사용만 이 필드에 기록됩니다. 계정 루트 사용자와 IAM 사용자 모두에게 적용됩니다. 다음과 같은 경우 이 필드의 값은 `N/A`(해당 사항 없음)입니다.  
+ 사용자에게 두 번째 액세스 키가 없는 경우.
+ 사용자의 두 번째 액세스 키가 사용된 적이 없는 경우.
+ IAM에서 2015년 4월 22일에 이 정보의 추적을 시작하기 전에 사용자의 두 번째 액세스 키가 마지막으로 사용된 경우

**cert\$11\$1active**  
사용자에게 X.509 서명 인증서가 있고 해당 인증서의 상태가 `Active`인 경우, 이 값은 `TRUE`입니다. 그렇지 않은 경우 이 값은 `FALSE`입니다.

**cert\$11\$1last\$1rotated**  
사용자의 서명 인증서가 생성되었거나 마지막으로 변경된 날짜 및 시간([ISO 8601 날짜-시간 형식](https://en.wikipedia.org/wiki/ISO_8601))입니다. 사용자에게 활성 상태의 서명 인증서가 있는 경우, 이 필드의 값은 `N/A`(해당 사항 없음)입니다.

**cert\$12\$1active**  
사용자에게 두 번째 X.509 서명 인증서가 있고 해당 인증서의 상태가 `Active`인 경우, 이 값은 `TRUE`입니다. 그렇지 않은 경우 이 값은 `FALSE`입니다.  
사용자는 인증서 교체가 쉽도록 최대 두 개의 X.509 서명 인증서를 보유할 수 있습니다.

**cert\$12\$1last\$1rotated**  
사용자의 두 번째 서명 인증서가 생성되었거나 마지막으로 변경된 날짜 및 시간([ISO 8601 날짜-시간 형식](https://en.wikipedia.org/wiki/ISO_8601))입니다. 사용자에게 활성 상태의 두 번째 서명 인증서가 있는 경우, 이 필드의 값은 `N/A`(해당 사항 없음)입니다.

**additional\$1credentials\$1info**  
사용자에게 두 개 이상의 액세스 키 또는 인증서가 있는 경우 이 값은 추가 액세스 키 또는 인증서 수, 그리고 사용자와 연결된 액세스 키 또는 인증서를 나열하는 데 사용할 수 있는 작업이 됩니다.

## 자격 증명 보고서 가져오기(콘솔)
<a name="getting-credential-reports-console"></a>

AWS Management Console을 사용하여 자격 증명 보고서를 CSV(쉼표로 구분된 값) 파일로 다운로드할 수 있습니다.

**자격 증명 보고서를 다운로드하려면(콘솔)**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **자격 증명 보고서**를 선택합니다.

1. **보고서 다운로드**를 선택합니다.

## 자격 증명 보고서 가져오기(AWS CLI)
<a name="getting-credential-reports-cliapi"></a>

**자격 증명 보고서를 다운로드하려면(AWS CLI)**

1. 자격 증명 보고서를 생성합니다. AWS에는 단일 보고서가 저장됩니다. 보고서가 있는 경우 자격 증명 보고서를 생성하면 이전 보고서를 덮어씁니다. [https://docs.aws.amazon.com/cli/latest/reference/iam/generate-credential-report.html](https://docs.aws.amazon.com/cli/latest/reference/iam/generate-credential-report.html) 

1. 마지막으로 생성된 보고서를 봅니다. [https://docs.aws.amazon.com/cli/latest/reference/iam/get-credential-report.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-credential-report.html) 

## 자격 증명 보고서 가져오기(AWS API)
<a name="getting-credential-reports-api"></a>

**자격 증명 보고서를 다운로드하려면(AWS API)**

1. 자격 증명 보고서를 생성합니다. AWS에는 단일 보고서가 저장됩니다. 보고서가 있는 경우 자격 증명 보고서를 생성하면 이전 보고서를 덮어씁니다. [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GenerateCredentialReport.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GenerateCredentialReport.html) 

1. 마지막으로 생성된 보고서를 봅니다. [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetCredentialReport.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetCredentialReport.html) 

# CodeCommit용 IAM 자격 증명: Git 자격 증명, SSH 키 및 AWS 액세스 키
<a name="id_credentials_ssh-keys"></a>

CodeCommit은 AWS 클라우드에서 프라이빗 Git 리포지토리를 호스팅하는 관리형 버전 관리 서비스입니다. CodeCommit을 사용하려면 CodeCommit 리포지토리와 통신하도록 Git 클라이언트를 구성합니다. 이 구성의 일환으로 CodeCommit에서 사용자 인증에 사용할 수 있는 IAM 자격 증명을 제공합니다. IAM에서는 세 가지 유형의 자격 증명으로 CodeCommit을 지원합니다.
+ Git 자격 증명: HTTPS를 통해 CodeCommit 리포지토리와 통신하는 데 사용할 수 있는 IAM 생성 사용자 이름 및 암호 페어입니다.
+ SSH 키: SSH를 통해 CodeCommit 리포지토리와 통신하기 위해 IAM 사용자와 연결할 수 있는 로컬로 생성된 퍼블릭-프라이빗 키 페어입니다.
+  [AWS 액세스 키](id_credentials_access-keys.md): HTTPS를 통해 CodeCommit 리포지토리와 통신하기 위해 AWS CLI에 포함된 자격 증명 헬퍼와 함께 사용할 수 있습니다.

**참고**  
또 다른 AWS 계정에서 리포지토리에 액세스하기 위해 SSH 키나 Git 자격 증명을 사용할 수 없습니다. 다른 AWS 계정의 IAM 사용자 및 그룹에 대해 CodeCommit 리포지토리 액세스를 구성하는 방법을 알아보려면 *AWS CodeCommit 사용 설명서*에서 [역할을 사용하여 AWS CodeCommit 리포지토리에 대한 크로스 계정 액세스 구성](https://docs.aws.amazon.com/codecommit/latest/userguide/cross-account.html)을 참조하세요.

각 옵션에 대한 자세한 내용은 다음 섹션을 참조하세요.

## CodeCommit에 Git 자격 증명 및 HTTPS 사용(권장)
<a name="git-credentials-code-commit"></a>

Git 자격 증명을 사용하여 IAM 사용자에 대한 정적 사용자 이름 및 암호 페어를 생성한 다음 HTTPS 연결에 이러한 자격 증명을 사용합니다. 정적 Git 자격 증명을 지원하는 타사 도구 또는 IDE(통합 개발 환경)에서도 이러한 자격 증명을 사용할 수 있습니다.

이러한 자격 증명은 모든 지원되는 운영 체제에 공통적이고 대부분의 자격 증명 관리 시스템, 개발 환경 및 기타 소프트웨어 개발 도구와 호환되므로 이는 권장되는 방법입니다. 언제든지 Git 자격 증명에 대한 암호를 재설정할 수 있습니다. 또한 자격 증명이 더 이상 필요하지 않은 경우 자격 증명을 비활성화하거나 삭제할 수 있습니다.

**참고**  
Git 보안 인증 정보에 대해 본인의 사용자 이름 또는 암호를 선택할 수 없습니다. IAM에서는 사용자가 AWS에 대한 보안 표준을 준수하고 CodeCommit에서 리포지토리를 보호하도록 돕기 위해 이러한 자격 증명을 생성합니다. 자격 증명은 생성될 때 한 번만 다운로드할 수 있습니다. 따라서 자격 증명을 안전한 장소에 보관하세요. 필요한 경우 언제든지 암호를 재설정할 수 있지만, 그러면 이전 암호를 사용하여 구성된 연결은 무효화됩니다. 새 암호를 사용하여 연결하려면 연결을 다시 구성해야 합니다.

자세한 내용은 다음 주제 섹션을 참조하세요.
+ IAM 사용자를 생성하려면 [AWS 계정에서 IAM 사용자 생성](id_users_create.md) 섹션을 참조하세요 
+ CodeCommit에서 Git 자격 증명을 생성하고 사용하려면 *AWS CodeCommit 사용 설명서*의 [Git 자격 증명을 사용하는 HTTPS 사용자의 경우](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-gc.html)를 참조하세요.

**참고**  
Git 자격 증명을 생성한 이후에 IAM 사용자의 이름을 변경해도 Git 자격 증명의 사용자 이름은 변경되지 않습니다. 사용자 이름과 암호는 동일하게 유지되고 계속 유효합니다.

**서비스별 보안 인증을 업데이트하려면**

1. 현재 사용 중인 서비스별 자격 증명 세트 이외에 두 번째 세트를 만듭니다.

1. 새 자격 증명 세트를 사용하도록 모든 애플리케이션을 업데이트하고 애플리케이션이 작동하는지 확인합니다.

1. 원래 자격 증명의 상태를 "Inactive"로 변경합니다.

1. 모든 애플리케이션이 계속 작동하는지 확인합니다.

1. 비활성 서버별 자격 증명을 삭제합니다.

## CodeCommit에 SSH 키 및 SSH 사용
<a name="ssh-keys-code-commit"></a>

SSH 연결을 사용하여 Git 및 CodeCommit에서 SSH 인증에 사용하는 퍼블릭 및 프라이빗 키 파일을 로컬 시스템에서 생성합니다. 퍼블릭 키를 IAM 사용자와 연결하고 프라이빗 키를 로컬 시스템에 저장합니다. 자세한 내용은 다음 주제 섹션을 참조하세요.
+ IAM 사용자를 생성하려면 [AWS 계정에서 IAM 사용자 생성](id_users_create.md) 섹션을 참조하세요 
+ SSH 퍼블릭 키를 생성하여 IAM 사용자와 연결하려면 *AWS CodeCommit 사용 설명서*에서 [Linux, macOS 또는 Unix에서 SSH 연결의 경우](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-ssh-unixes.html) 또는 [Windows에서 SSH 연결의 경우](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-ssh-windows.html)를 참조하세요.

**참고**  
퍼블릭 키는 ssh-rsa 형식 또는 PEM 형식으로 인코딩해야 합니다. 퍼블릭 키의 최소 비트 길이는 2048비트이고 최대 길이는 16384비트입니다. 이것은 업로드하는 파일의 크기와는 별개입니다. 예를 들어 2048비트 키를 생성할 수 있으며 결과 PEM 파일의 길이는 1679바이트입니다. 퍼블릭 키를 다른 형식 또는 크기로 제공하면 키 형식이 잘못되었다는 오류 메시지가 표시됩니다.

## AWS CLI 자격 증명 헬퍼 및 CodeCommit에 HTTPS 사용
<a name="access-keys-code-commit"></a>

Git 자격 증명을 사용한 HTTPS 연결의 대안으로, Git에서 CodeCommit 리포지토리와 상호 작용하기 위해 AWS에 인증해야 할 때마다 암호화 방식으로 서명된 IAM 사용자 자격 증명 또는 Amazon EC2 인스턴스 역할을 사용하도록 허용할 수 있습니다. 이는 IAM 사용자 없이 CodeCommit 리포지토리에 연결할 수 있는 유일한 방법입니다. 또한 페더레이션 액세스 및 임시 자격 증명으로 작동되는 유일한 방법입니다. 자세한 내용은 다음 주제 섹션을 참조하세요.
+ 페더레이션 액세스에 대한 자세한 내용은 [ID 공급자 및 AWS로의 페더레이션](id_roles_providers.md) 및 [외부에서 인증된 사용자에 대한 액세스(ID 페더레이션)](id_roles_common-scenarios_federated-users.md) 단원을 참조하십시오.
+ 임시 자격 증명에 대한 자세한 내용은 [IAM의 임시 보안 자격 증명](id_credentials_temp.md) 및 [CodeCommit 리포지토리에 대한 임시 액세스](https://docs.aws.amazon.com/codecommit/latest/userguide/temporary-access.html)를 참조하세요.

AWS CLI Credential Helper는 Keychain Access, Windows Credential Management 등과 같은 다른 자격 증명 헬퍼 시스템과 호환되지 않습니다. HTTPS를 통한 자격 증명 헬퍼 연결을 구성할 때 고려해야 할 추가 사항이 있습니다. 자세한 내용은 *AWS CodeCommit 사용 설명서*에서 [AWS CLI 자격 증명 헬퍼를 사용한 Linux, macOS 또는 Unix에서 HTTPS 연결](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-https-unixes.html) 또는 [AWS CLI 자격 증명 헬퍼를 사용하여 Windows에서 HTTPS 연결](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-https-windows.html)을 참조하세요.

# IAM에서 서버 인증서 관리
<a name="id_credentials_server-certs"></a>

AWS에서 웹 사이트나 애플리케이션에 대한 HTTPS 연결을 활성화하려면 SSL/TLS *서버 인증서*가 필요합니다. AWS Certificate Manager(ACM)에서 지원되는 리전에서 사용되는 인증서의 경우, ACM을 사용하여 서버 인증서를 프로비저닝, 관리 및 배포하는 것이 좋습니다. 지원되지 않는 리전에서는 IAM을 인증서 관리자로 사용해야 합니다. ACM이 지원하는 리전을 알아보려면 **AWS 일반 참조의 [AWS Certificate Manager 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/acm.html)을 참조하세요.

**중요**  
ACM은 서버 인증서를 프로비저닝, 관리 및 배포하기 위한 기본 도구입니다. ACM을 사용하면 인증서를 요청하거나 기존 ACM 또는 외부 인증서를 AWS 리소스에 배포할 수 있습니다. ACM이 제공하는 인증서는 무료이고 자동으로 갱신됩니다. [지원되는 리전](https://docs.aws.amazon.com/general/latest/gr/acm.html)에서는 ACM을 사용하여 콘솔에서 또는 프로그래밍 방식으로 서버 인증서를 관리할 수 있습니다. ACM 사용에 대한 자세한 내용은 [https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html](https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html)를 참조하세요. ACM 인증서 요청에 대한 자세한 내용은 *AWS Certificate Manager 사용 설명서*의 [퍼블릭 인증서 요청](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html) 또는 [프라이빗 인증서 요청](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-private.html)을 참조하세요. 서드 파티 인증서를 ACM으로 가져오는 방법에 대한 자세한 내용은 *AWS Certificate Manager 사용 설명서*의 [인증서 가져오기](https://docs.aws.amazon.com/acm/latest/userguide/import-certificate.html)를 참조하세요.

[ACM에서 지원](https://docs.aws.amazon.com/general/latest/gr/acm.html)하지 않는 리전에서 HTTPS 연결을 지원해야 하는 경우에만 IAM을 인증서 관리자로 사용합니다. IAM은 프라이빗 키를 안전하게 암호화하고 암호화된 버전을 IAM SSL 인증서 스토리지에 저장합니다. IAM은 모든 리전에서 서버 인증서 배포를 지원하지만 외부 공급자로부터 AWS에서 사용할 인증서를 얻어야 합니다. ACM 인증서는 IAM에 업로드할 수 없습니다. 또한 IAM 콘솔에서 인증서를 관리할 수 없습니다.

서드 파티 인증서를 IAM에 업로드하는 방법에 대한 자세한 정보는 다음 주제를 참조하세요.

**Topics**
+ [

## 서버 인증서 업로드(AWS API)
](#upload-server-certificate)
+ [

## 서버 인증서를 위한 AWS API 작업
](#id_credentials_server-certs-api)
+ [

## 서버 인증서 문제 해결
](#server-certificate-troubleshooting)

## 서버 인증서 업로드(AWS API)
<a name="upload-server-certificate"></a>

IAM에 서버 인증서를 업로드하려면 인증서와 함께 그에 딸린 프라이빗 키를 제공해야 합니다. 인증서에 자체 서명이 되어 있지 않은 경우, 인증서 체인도 제공해야 합니다. (자체 서명된 인증서를 업로드하는 경우에는 인증서 체인이 필요하지 않습니다). 인증서를 업로드하기 전에 이 모든 항목이 있는지, 있다면 각 항목이 다음 기준을 충족하는지 확인하세요.
+ 인증서는 업로드 시점에 유효해야 합니다. 유효 기간이 시작되기 전(인증서의 `NotBefore` 날짜) 또는 만료된 후(인증서의 `NotAfter` 날짜)에는 인증서를 업로드할 수 없습니다.
+ 프라이빗 키는 암호화되지 않은 것이어야 합니다. 패스워드나 패스프레이즈로 보호된 프라이빗 키는 업로드할 수 없습니다. 암호화된 프라이빗 키의 해독에 대한 도움말은 [서버 인증서 문제 해결](#server-certificate-troubleshooting) 섹션을 참조하세요.
+ 인증서, 프라이빗 키 및 인증서 체인은 모두 PEM 인코딩되어야 합니다. 이 항목들을 PEM 형식으로 변환하는 작업에 대한 도움말은 [서버 인증서 문제 해결](#server-certificate-troubleshooting) 섹션을 참조하세요.

[IAM API](https://docs.aws.amazon.com/IAM/latest/APIReference/)를 사용하여 인증서를 업로드하려면 [UploadServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UploadServerCertificate.html) 요청을 전송합니다. 다음 예에서는 [AWS Command Line Interface(AWS CLI)](https://aws.amazon.com/cli/)에서 이 작업을 수행하는 방법을 보여줍니다. 이 예시에서는 다음과 같이 가정합니다.
+ PEM 인코딩된 인증서가 `Certificate.pem`이라는 파일에 저장되어 있다.
+ PEM 인코딩된 인증서 체인이 `CertificateChain.pem`이라는 파일에 저장되어 있다.
+ PEM 인코딩된 비암호화 프라이빗 키가 `PrivateKey.pem`이라는 파일에 저장되어 있다.
+ (선택 사항) 키 값 페어로 서버 인증서를 태깅하는 것이 좋습니다. 예를 들어 인증서를 식별하고 구성하는 데 도움이 되도록 태그 키 `Engineering`과 태그 값 `Department`를 추가할 수 있습니다.

다음 예제 명령을 사용하려면 이 같은 파일 이름을 고유한 이름으로 바꿉니다. *ExampleCertificate*를 업로드한 인증서의 이름으로 바꿉니다. 인증서를 태깅하려면 *ExampleKey* 및 *ExampleValue* 태그 키 값 페어를 고유한 값으로 바꿉니다. 하나의 연속선에 명령을 입력합니다. 다음 예시에는 가독성을 높여주는 줄바꿈과 추가 공백이 포함되어 있습니다.

```
aws iam upload-server-certificate --server-certificate-name ExampleCertificate
                                    --certificate-body file://Certificate.pem
                                    --certificate-chain file://CertificateChain.pem
                                    --private-key file://PrivateKey.pem
                                    --tags '{"Key": "ExampleKey", "Value": "ExampleValue"}'
```

선행 명령은 성공적으로 실행되는 경우 [Amazon Resource Name(ARN)](reference_identifiers.md#identifiers-arns), 표시 이름, 식별자(ID), 만료 날짜, 태그 등 업로드된 인증서에 대한 메타데이터를 반환합니다.

**참고**  
Amazon CloudFront에서 사용할 서버 인증서를 업로드하는 경우 `--path` 옵션을 사용하여 경로를 지정해야 합니다. 경로는 `/cloudfront`로 시작해야 하고 후행 슬래시를 포함해야 합니다(예: `/cloudfront/test/`).

AWS Tools for Windows PowerShell를 사용하여 인증서를 업로드하려면 [Publish-IAMServerCertificate](https://docs.aws.amazon.com/powershell/latest/reference/Index.html?page=Publish-IAMServerCertificate.html&tocid=Publish-IAMServerCertificate)를 사용하세요.

## 서버 인증서를 위한 AWS API 작업
<a name="id_credentials_server-certs-api"></a>

서버 인증서를 보고, 태그를 지정하고, 이름을 바꾸고, 삭제하려면 다음 명령을 사용합니다.
+ 인증서를 검색하려면 [GetServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServerCertificate.html)를 사용합니다. 이 요청은 인증서, 인증서 체인(업로드된 경우) 및 인증서 관련 메타데이터를 반환합니다.
**참고**  
업로드 후에는 IAM에서 프라이빗 키를 다운로드하거나 조회할 수 없습니다.
+ 인증서를 검색하려면 [Get-IAMServerCertificate](https://docs.aws.amazon.com/powershell/latest/reference/Index.html?page=Get-IAMServerCertificate.html&tocid=Get-IAMServerCertificate)를 사용합니다.
+ 업로드한 서버 인증서를 나열하려면 [ListServerCertificates](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListServerCertificates.html)를 사용합니다. 이 요청은 각 인증서 관련 메타데이터가 담긴 목록을 반환합니다.
+ 업로드한 서버 인증서의 목록을 나열하려면 [Get-IAMServerCertificates](https://docs.aws.amazon.com/powershell/latest/reference/Index.html?page=Get-IAMServerCertificates.html&tocid=Get-IAMServerCertificates)를 사용합니다.
+ 기존 서버 인증서에 태그를 지정하려면 [TagServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagServerCertificate.html)를 사용합니다.
+ 서버 인증서에서 태그를 해제하려면 [UntagServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagServerCertificate.html)를 사용합니다.
+ 서버 인증서의 이름을 바꾸거나 해당 경로를 업데이트하려면 [UpdateServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateServerCertificate.html)를 사용합니다.

   다음 예에서는 AWS CLI에서 이 작업을 수행하는 방법을 보여줍니다.

  다음 예시 명령을 사용하려면 기존 및 신규 인증서의 이름과 인증서 경로를 바꾸고 명령을 하나의 연속선에 입력해야 합니다. 다음 예시에는 가독성을 높여주는 줄바꿈과 추가 공백이 포함되어 있습니다.

  ```
  aws iam update-server-certificate --server-certificate-name ExampleCertificate
                                      --new-server-certificate-name CloudFrontCertificate
                                      --new-path /cloudfront/
  ```

  AWS Tools for Windows PowerShell을(를) 사용하여 서버 인증서의 이름을 변경하거나 경로를 업데이트하려면 [Update-IAMServerCertificate](https://docs.aws.amazon.com/powershell/latest/reference/Index.html?page=Update-IAMServerCertificate.html&tocid=Update-IAMServerCertificate)을 사용하세요.
+ 서버 인증서를 삭제하려면 [DeleteServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServerCertificate.html)를 사용합니다.

  AWS Tools for Windows PowerShell을 사용하여 서버 인증서를 삭제하려면 [Remove-IAMServerCertificate](https://docs.aws.amazon.com/powershell/latest/reference/Index.html?page=Remove-IAMServerCertificate.html&tocid=Remove-IAMServerCertificate)을 사용하세요.

## 서버 인증서 문제 해결
<a name="server-certificate-troubleshooting"></a>

IAM에 인증서를 업로드하려면 인증서, 프라이빗 키 및 인증서 체인이 모두 PEM으로 인코딩되어 있어야 합니다. 또한 프라이빗 키가 암호화되지 않은 것이어야 합니다. 다음 예시를 참조하세요.

**Example PEM으로 인코딩된 인증서 예시**  

```
-----BEGIN CERTIFICATE-----
Base64-encoded certificate
-----END CERTIFICATE-----
```

**Example PEM 인코딩된 비암호화 프라이빗 키 예시**  

```
-----BEGIN RSA PRIVATE KEY-----
Base64-encoded private key
-----END RSA PRIVATE KEY-----
```

**Example PEM 인코딩된 인증서 체인 예시**  
인증서 체인에는 한 개 이상의 인증서가 포함되어 있습니다. 텍스트 편집기, Windows의 copy 명령 또는 Linux의 cat 명령을 사용하여 여러 인증서 파일을 하나의 체인으로 연결할 수 있습니다. 여러 개의 인증서를 포함하는 경우 각 인증서가 앞에 지정된 인증서를 인증해야 합니다. 루트 CA 인증서를 포함하여 인증서를 연결함으로써 이를 달성합니다.  
다음 예시의 경우에는 세 개의 인증서가 포함되어 있지만, 사용자에 따라 인증서 체인에 포함된 인증서가 그보다 많거나 적을 수 있습니다.  

```
-----BEGIN CERTIFICATE-----
Base64-encoded certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64-encoded certificate
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
Base64-encoded certificate
-----END CERTIFICATE-----
```

이 항목들이 IAM에 업로드하기에 적합한 형식이 아닌 경우, [OpenSSL](https://openssl.org/)을 사용하여 적합한 형식으로 변환할 수 있습니다.

**인증서 또는 인증서 체인을 DER에서 PEM으로 변환하려면**  
다음 예시와 같이 [OpenSSL **x509** 명령](https://openssl.org/docs/manmaster/man1/x509.html)을 사용합니다. 다음 예시 명령에서 `Certificate.der`을 DER 인코딩된 인증서가 포함된 파일의 이름으로 대체합니다. `Certificate.pem`을, PEM 인코딩된 인증서를 포함할 출력 파일에 지정하려는 이름으로 바꿉니다.  

```
openssl x509 -inform DER -in Certificate.der -outform PEM -out Certificate.pem
```
 

**프라이빗 키를 DER에서 PEM으로 변환하려면**  
다음 예시와 같이 [OpenSSL **rsa** 명령](https://openssl.org/docs/manmaster/man1/rsa.html)을 사용합니다. 다음 예시 명령에서 `PrivateKey.der`을 DER 인코딩된 프라이빗 키가 포함된 파일의 이름으로 대체해야 합니다. `PrivateKey.pem`을, PEM 인코딩된 프라이빗 키를 포함할 출력 파일에 지정하려는 이름으로 바꿉니다.  

```
openssl rsa -inform DER -in PrivateKey.der -outform PEM -out PrivateKey.pem
```
 

**암호화된 프라이빗 키를 해독하려면(패스워드나 패스프레이즈 제거)**  
다음 예시와 같이 [OpenSSL **rsa** 명령](https://openssl.org/docs/manmaster/man1/rsa.html)을 사용합니다. 다음 예시 명령을 사용하려면 `EncryptedPrivateKey.pem`을 암호화된 프라이빗 키가 포함된 파일의 이름으로 대체해야 합니다. `PrivateKey.pem`을, PEM 인코딩된 비암호화 프라이빗 키를 포함할 출력 파일에 지정하려는 이름으로 바꿉니다.  

```
openssl rsa -in EncryptedPrivateKey.pem -out PrivateKey.pem
```
 

**인증서 번들을 PKCS\$112(PFX)에서 PEM으로 변환하려면**  
다음 예시와 같이 [OpenSSL **pkcs12** 명령](https://openssl.org/docs/manmaster/man1/pkcs12.html)을 사용합니다. 다음 예시 명령에서 `CertificateBundle.p12`를 PKCS\$112 인코딩된 인증서 번들이 포함된 파일의 이름으로 대체합니다. `CertificateBundle.pem`을, PEM 인코딩된 인증서 번들을 포함할 출력 파일에 지정하려는 이름으로 대체합니다.  

```
openssl pkcs12 -in CertificateBundle.p12 -out CertificateBundle.pem -nodes
```
 

**인증서 번들을 PKCS\$17에서 PEM으로 변환하려면**  
다음 예시와 같이 [OpenSSL **pkcs7** 명령](https://openssl.org/docs/manmaster/man1/pkcs7.html)을 사용합니다. 다음 예시 명령에서 `CertificateBundle.p7b`를 PKCS\$17 인코딩된 인증서 번들이 포함된 파일의 이름으로 대체합니다. `CertificateBundle.pem`을, PEM 인코딩된 인증서 번들을 포함할 출력 파일에 지정하려는 이름으로 대체합니다.  

```
openssl pkcs7 -in CertificateBundle.p7b -print_certs -out CertificateBundle.pem
```

# IAM 사용자 그룹
<a name="id_groups"></a>

IAM [*사용자 그룹*](#id_groups)은 IAM 사용자의 집합입니다. 사용자 그룹을 활용하면 다수의 사용자들에 대한 권한을 지정함으로써 해당 사용자들에 대한 권한을 더 쉽게 관리할 수 있습니다. 예를 들어, *Admins*라는 사용자 그룹이 있고 해당 사용자 그룹에 일반 관리자 권한을 부여할 수 있습니다. 해당 사용자 그룹의 모든 사용자는 자동으로 *Admins* 그룹 권한을 갖습니다. 관리자 권한을 필요로 하는 새로운 사용자가 조직에 들어올 경우 해당 사용자를 *Admins* 사용자 그룹에 추가하여 적절한 권한을 할당할 수 있습니다. 조직에서 직원의 업무가 바뀌면 해당 사용자의 권한을 편집하는 대신 이전 IAM 그룹에서 해당 사용자를 제거한 후 적절한 새 IAM 그룹에 추가하면 됩니다.

사용자 그룹의 모든 사용자가 정책의 권한을 받도록 아이덴티티 기반 정책을 사용자 그룹에 연결할 수 있습니다. 그룹은 인증이 아니라 권한과 관련이 있고 보안 주체는 인증된 IAM 엔터티이기 때문에 정책(예: 리소스 기반 정책)에서 사용자 그룹을 `Principal`로 식별할 수 없습니다. 정책 유형에 대한 자세한 정보는 [자격 증명 기반 정책 및 리소스 기반 정책](access_policies_identity-vs-resource.md) 섹션을 참조하세요.

다음은 IAM 그룹이 갖는 몇 가지 중요한 특징입니다.
+ 한 사용자 그룹에 여러 사용자가 포함될 수 있으며 한 사용자가 다중 사용자 그룹에 속할 수 있습니다.
+ 사용자 그룹은 중첩될 수 없습니다. 즉, IAM 그룹은 사용자만 포함할 수 있으며 다른 그룹은 포함할 수 없습니다.
+ AWS 계정의 모든 사용자를 자동으로 포함하는 기본 사용자 그룹은 없습니다. 이러한 사용자 그룹이 필요한 경우 하나 만들어 새로운 사용자를 각각 해당 그룹에 할당해야 합니다.
+ 그룹 수, 사용자가 멤버가 될 수 있는 그룹 수와 같이 AWS 계정에 있는 IAM 리소스의 수와 크기는 제한되어 있습니다. 자세한 내용은 [IAM 및 AWS STS 할당량](reference_iam-quotas.md) 단원을 참조하십시오.

다음 다이어그램에서는 어느 작은 회사의 간단한 예제를 보여줍니다. 회사 소유주는 `Admins` 사용자 그룹을 생성해 회사가 성장함에 따라 사용자들이 다른 사용자들을 생성하고 관리하도록 합니다. `Admins` 사용자 그룹은 `Developers` 사용자 그룹 및 `Test` 사용자 그룹을 생성합니다. 이러한 IAM 그룹은 각각 AWS와 상호 작용하는 사용자(사람 및 애플리케이션: Jim, Brad, DevApp1 등)들로 구성됩니다. 사용자마다 개별적인 보안 자격 증명 세트가 있습니다. 이 예제에서는 각 사용자가 단일 사용자 그룹에 속합니다. 하지만 사용자는 여러 IAM 그룹에 속할 수 있습니다.

![\[AWS 계정, 사용자 및 IAM 그룹 간 관계의 예\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/Relationship_Between_Entities_Example.diagram.png)


# IAM 그룹 생성
<a name="id_groups_create"></a>

**참고**  
[가장 좋은 방법](best-practices.md)은 인간 사용자가 ID 제공업체와의 페더레이션을 사용하여 임시 보안 인증으로 AWS에 액세스하도록 하는 것입니다. 이 방법을 따르는 경우 사용자가 IAM 사용자 및 그룹을 관리하지 않습니다. 대신 사용자와 그룹은 AWS 외부에서 관리되며 *페더레이션형 ID*로 AWS 리소스에 액세스할 수 있습니다. AWS 페더레이션형 ID는 엔터프라이즈 사용자 디렉터리, 웹 ID 제공업체, Directory Service, Identity Center 디렉터리의 사용자 또는 ID 소스를 통해 제공된 보안 인증을 사용하여 AWS 서비스에 액세스하는 모든 사용자입니다. 페더레이션형 ID는 ID 제공업체에서 정의한 그룹을 사용합니다. AWS IAM Identity Center를 사용하는 경우 IAM Identity Center에서 사용자 및 그룹 생성에 대한 자세한 내용은 *AWS IAM Identity Center User Guide*(SSO 사용 설명서)의 [Manage identities in IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-sso.html)(IAM Identity Center에서 ID 관리)를 참조하세요.

IAM 그룹을 생성하여 유사한 역할 또는 책임을 가진 여러 사용자의 액세스 권한을 관리합니다. 이러한 그룹에 정책을 연결하여 전체 사용자 집합에 대한 권한을 부여하거나 취소할 수 있습니다. 이렇게 하면 그룹의 권한에 대한 변경 사항이 해당 그룹의 모든 멤버에게 자동으로 적용되므로 보안 정책의 유지 관리가 간소화되어 일관된 액세스 제어가 보장됩니다. 그룹을 생성한 후 그룹의 IAM 사용자가 할 수 있는 작업 유형에 따라 그룹에 권한을 부여한 다음 그룹에 IAM 사용자를 추가합니다.

IAM 그룹을 생성하는 데 필요한 권한에 대한 자세한 내용은 [IAM 리소스에 액세스하는 데 필요한 권한](access_permissions-required.md) 섹션을 참조하세요.

## IAM 그룹 생성 및 정책 연결
<a name="id_groups_create-section-1"></a>

------
#### [ Console ]

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **사용자 그룹(User groups)**을 선택한 다음, **그룹 생성(Create group)**을 선택합니다.

1. **사용자 그룹 이름(User group name)**에 그룹의 이름을 입력합니다.
**참고**  
AWS 계정의 IAM 리소스 수와 크기는 제한되어 있습니다. 자세한 내용은 [IAM 및 AWS STS 할당량](reference_iam-quotas.md) 섹션을 참조하세요. 그룹 이름에는 최대 128개의 문자, 숫자 및 더하기(\$1), 등호(=), 쉼표(,), 마침표(.), 앳(@), 밑줄(\$1) 및 하이픈(-) 조합을 사용할 수 있습니다. 이름은 계정 내에서 고유해야 합니다. 대소문자를 구분하지 않습니다. 예를 들어 이름이 **ADMINS** 및 **admins**, 두 가지로 지정된 그룹을 만들 수는 없습니다.

1. 사용자 목록에서 그룹에 추가하고자 하는 각 사용자의 확인란을 선택합니다.

1. 정책 목록에서 그룹 멤버 전체에 적용하고자 하는 정책 이름마다 확인란을 선택합니다.

1. **그룹 생성**을 선택합니다.

------
#### [ AWS CLI ]

다음 명령 실행:
+ [aws iam create-group](https://docs.aws.amazon.com/cli/latest/reference/iam/create-group.html)

------
#### [ API ]

다음 작업을 직접 호출:
+ [CreateGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateGroup.html)

------

# IAM 그룹 보기
<a name="id_groups_manage_list"></a>

계정의 모든 IAM 그룹, 특정 사용자 그룹에 속한 사용자 및 특정 사용자가 속한 IAM 그룹을 나열할 수 있습니다. CLI 또는 API를 사용하는 경우 특정 경로 접두사를 사용해 전체 IAM 그룹을 나열할 수 있습니다.

------
#### [ Console ]

계정에 속한 모든 IAM 그룹 나열
+ 탐색 창에서 **사용자 그룹**을 선택합니다.

특정 IAM 그룹에 속한 IAM 사용자 나열
+ 탐색 창에서 **사용자 그룹**을 선택합니다. 그런 다음 그룹의 이름을 선택하여 그룹 세부 정보 페이지를 엽니다. **사용자** 탭을 검토하여 그룹 멤버십을 확인합니다.

사용자가 속한 모든 IAM 그룹 나열
+ 탐색 창에서 **사용자**를 선택합니다. 그런 다음 사용자 이름을 선택하여 사용자 세부 정보 페이지를 엽니다. **그룹** 탭을 선택하여 사용자가 속한 그룹 목록을 확인합니다.

------
#### [ AWS CLI ]

계정에 속한 모든 IAM 그룹 나열
+ [aws iam list-groups](https://docs.aws.amazon.com/cli/latest/reference/iam/list-groups.html)

특정 IAM 그룹에 속한 사용자 나열
+ [aws iam get-group](https://docs.aws.amazon.com/cli/latest/reference/iam/get-group.html)

사용자가 속한 모든 IAM 그룹 나열
+ [aws iam list-groups-for-user](https://docs.aws.amazon.com/cli/latest/reference/iam/list-groups-for-user.html)

------
#### [ API ]

계정에 속한 모든 IAM 그룹 나열
+ [ListGroups](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListGroups.html)

특정 IAM 그룹에 속한 사용자 나열
+ [GetGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetGroup.html)

사용자가 속한 모든 IAM 그룹 나열
+ [ListGroupsForUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListGroupsForUser.html)

------

# IAM 그룹의 사용자 편집
<a name="id_groups_manage_add-remove-users"></a>

IAM 그룹을 사용하여 한 번에 여러 사용자에게 동일한 권한 정책을 적용합니다. 그런 다음 IAM 그룹에서 사용자를 추가하거나 제거할 수 있습니다. 이 기능은 사람들이 조직에 들어오거나 조직을 떠날 때 유용합니다.

## 정책 액세스 검토
<a name="groups-remove_prerequisites"></a>

그룹을 제거하기 전에 그룹 세부 정보 페이지를 사용하여 그룹의 멤버(IAM 사용자)와 **권한** 탭에서 그룹에 연결된 정책을 검토하고 **마지막 액세스** 탭을 사용하여 최근 서비스 수준 활동을 검토합니다. 이렇게 하면 이를 사용하는 위탁자(개인 또는 애플리케이션)의 액세스 권한이 의도치 않게 제거되는 것을 방지하는 데 도움이 됩니다. 마지막으로 액세스한 정보 보기에 대한 자세한 내용은 [마지막으로 액세스한 정보를 사용하여 AWS에서 권한 재정의](access_policies_last-accessed.md) 섹션을 참조하세요.

## IAM 그룹에 IAM 사용자 추가
<a name="groups-add-remove-console"></a>

------
#### [ Console ]

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **사용자 그룹(User groups)**을 선택한 다음 그룹 이름을 선택합니다.

1. **사용자(Users)** 탭을 선택한 후 **사용자 추가(Add Users)**를 선택합니다. 추가할 사용자 옆에 있는 확인란을 선택합니다.

1. **사용자 추가(Add users)**를 선택합니다.

------
#### [ AWS CLI ]

다음 명령 실행:
+ `[aws iam add-user-to-group](https://docs.aws.amazon.com/cli/latest/reference/iam/add-user-to-group.html)`

------
#### [ API ]

다음 작업을 직접 호출:
+ `[AddUserToGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddUserToGroup.html)`

------

## IAM 그룹에서 IAM 사용자 제거
<a name="id_groups_manage_add-remove-users-section-1"></a>

------
#### [ Console ]

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **사용자 그룹(User groups)**을 선택한 다음 그룹 이름을 선택합니다.

1. **사용자** 탭을 선택합니다. 제거할 사용자 옆에 있는 확인란을 선택한 다음 **사용자 제거(Remove users)**를 선택합니다.

------
#### [ AWS CLI ]

다음 명령 실행:
+ `[aws iam remove-user-from-group](https://docs.aws.amazon.com/cli/latest/reference/iam/remove-user-from-group.html)`

------
#### [ API ]

다음 작업을 직접 호출:
+ `[RemoveUserFromGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_RemoveUserFromGroup.html)`

------

# IAM 사용자 그룹에 정책 연결
<a name="id_groups_manage_attach-policy"></a>

다음 단계에 설명된 대로 사용자 그룹에 [AWS 관리형 정책](access_policies_managed-vs-inline.md#aws-managed-policies), 즉 AWS가 제공하는 미리 작성된 정책을 연결할 수 있습니다. 고객 관리형 정책, 즉 사용자가 생성한 사용자 지정 권한이 있는 정책을 연결하려면 먼저 정책을 생성해야 합니다. 고객 관리형 정책 만들기에 대한 자세한 내용은 [고객 관리형 정책으로 사용자 지정 IAM 권한 정의](access_policies_create.md) 섹션을 참조하세요.

권한 및 정책에 대한 자세한 내용은 [AWS리소스에 대한 액세스 관리](access.md)을 참조하세요.

## IAM 그룹에 정책 연결
<a name="id_groups_manage_attach-policy-section-1"></a>

------
#### [ Console ]

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **사용자 그룹(User groups)**을 선택한 다음 그룹 이름을 선택합니다.

1. **권한** 탭을 선택합니다.

1. **권한 추가**를 선택한 다음, **정책 연결**을 선택합니다.

1. 사용자 그룹에 연결된 현재 정책이 **현재 권한 정책(Current permissions policies)** 목록에 표시됩니다. **기타 권한 정책(Other permissions policies)**의 목록에서 연결할 정책 이름 옆의 확인란을 선택합니다. 검색 상자를 사용하여 정책 목록을 유형 및 정책 이름별로 필터링할 수 있습니다.

1. IAM 그룹에 연결하려는 정책을 선택하고 **정책 연결**을 선택합니다.

------
#### [ AWS CLI ]

다음 명령 실행:
+ `[aws iam attach-group-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-group-policy.html)`

------
#### [ API ]

다음 작업을 직접 호출:
+ `[AttachGroupPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachGroupPolicy.html)`

------

# IAM 사용자 그룹 이름 변경
<a name="id_groups_manage_rename"></a>

사용자 그룹의 이름 또는 경로를 변경하면 다음과 같이 진행됩니다.
+ 사용자 그룹에 연결된 정책은 새 이름의 그룹에 그대로 유지됩니다.
+ 사용자 그룹의 모든 사용자도 새로운 이름의 그룹에 그대로 유지됩니다.
+ 사용자 그룹의 고유 ID는 변동 없이 유지됩니다. 고유 ID에 대한 자세한 내용은 [고유 식별자](reference_identifiers.md#identifiers-unique-ids) 섹션을 참조하세요.

해당 사용자 그룹을 리소스로 참조하는 정책은 새 이름을 사용하도록 IAM에서 자동으로 업데이트하지 않습니다. 따라서 사용자 그룹 이름을 변경할 때는 주의해야 합니다. 사용자 그룹의 이름을 바꾸기 전에 모든 정책을 수동으로 확인해 해당 사용자 그룹이 이름으로 언급된 모든 정책을 찾아야 합니다. Bob이라는 직원이 회사의 테스트 부서 관리자인 경우를 예로 들어 보겠습니다. Bob의 IAM 사용자 엔터티에는 정책이 연결되어 있고 이 정책에 따라 Bob은 테스트 사용자 그룹의 사용자를 추가하거나 제거할 수 있습니다. 관리자가 사용자 그룹의 이름이나 그룹 경로를 변경하는 경우, 관리자는 Bob에게 연결된 정책도 업데이트하여 새 이름이나 경로를 사용하도록 해야 합니다. 그러지 않으면 Bob은 사용자 그룹에 사용자를 추가할 수도 그룹에서 사용자를 제거할 수도 없습니다.

**IAM 그룹을 리소스로 참조하는 정책 찾기**

1. IAM 콘솔의 탐색 창에서 **정책(Policies)**을 선택합니다.

1. **유형(Type)** 열을 기준으로 정렬하여 **고객 관리형(Customer managed)** 사용자 지정 정책을 찾습니다.

1. 편집할 정책의 정책 이름을 선택합니다.

1. **권한** 탭을 선택한 후 **요약**을 선택합니다.

1. 서비스 목록에서 **IAM**이 있으면 선택합니다.

1. **리소스(Resource)** 열에서 사용자 그룹의 이름을 찾습니다.

1. **편집**을 선택하여 정책에서 사용자 그룹 이름을 변경합니다.

## IAM 사용자 그룹의 이름을 변경하려면
<a name="id_groups_manage_rename-section-1"></a>

------
#### [ Console ]

1. 탐색 창에서 **사용자 그룹**을 선택하고 그룹 이름을 선택합니다.

1. **편집**을 선택합니다. 새 사용자 그룹 이름을 입력한 다음 **변경 사항 저장(Save changes)**을 선택합니다.

------
#### [ AWS CLI ]

다음 명령 실행:
+ [aws iam update-group](https://docs.aws.amazon.com/cli/latest/reference/iam/update-group.html)

------
#### [ API ]

다음 작업을 직접 호출:
+ [UpdateGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateGroup.html)

------

# IAM 그룹 삭제
<a name="id_groups_manage_delete"></a>

콘솔에서 IAM 그룹을 삭제하면 콘솔은 모든 그룹 구성원을 자동으로 제거하고 연결된 모든 관리형 정책을 분리하며, 모든 인라인 정책들을 삭제합니다. 그러나 IAM은 IAM 그룹을 리소스로 참조하는 정책을 자동으로 삭제하지 않기 때문에 IAM 그룹을 삭제할 때 주의해야 합니다. IAM 그룹을 삭제하기 전에 정책을 수동으로 검토하여 해당 그룹이 이름으로 언급된 모든 정책을 찾습니다. 예를 들어, 테스트 팀 관리자인 John은 IAM 사용자 엔터티에 연결된 정책을 갖고 있어 테스트 사용자 그룹에서 사용자를 추가하고 제거할 수 있습니다. 관리자는 그룹을 삭제할 경우 John에게 연결된 정책도 삭제해야 합니다. 그렇지 않고 관리자가 삭제된 그룹을 다시 생성하고 동일한 이름을 지정하면 John이 테스트 팀을 떠나더라도 존의 권한은 그대로 유지됩니다.

반면에 CLI, SDK 또는 API를 사용하여 그룹을 삭제할 경우에는 먼저 그룹의 사용자를 제거합니다. 그런 다음 IAM 그룹에 포함된 인라인 정책을 삭제합니다. 그런 다음 그룹에 연결된 관리형 정책을 모두 분리합니다. 그런 다음 IAM 그룹 자체를 삭제할 수 있습니다.

------
#### [ Console ]

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **사용자 그룹(User groups)**을 선택합니다.

1. IAM 그룹 목록에서 삭제할 IAM 그룹 이름 옆의 확인란을 선택합니다. 검색 상자를 사용하여 IAM 그룹 목록을 유형, 권한 및 그룹 이름별로 필터링할 수 있습니다.

1. **삭제**를 선택합니다.

1. 확인 상자에서 단일 그룹을 삭제하려면 그룹 이름을 입력하고 **삭제**를 선택합니다. 여러 그룹을 삭제하려면 삭제할 IAM 그룹 수와 **user groups**를 차례로 입력하고 **삭제**를 선택합니다. 예를 들어 3개의 그룹을 삭제하려는 경우 **3 **user groups****를 입력합니다.

------
#### [ AWS CLI ]

1. IAM 그룹에서 모든 사용자를 제거합니다.
   + [aws iam get-group](https://docs.aws.amazon.com/cli/latest/reference/iam/get-group.html)(IAM 그룹의 사용자 목록을 가져오는 방법), [aws iam remove-user-from-group](https://docs.aws.amazon.com/cli/latest/reference/iam/remove-user-from-group.html)(IAM 그룹에서 사용자를 제거하는 방법)

1. IAM 그룹에 삽입된 인라인 정책을 모두 삭제합니다.
   + [aws iam list-group-policies](https://docs.aws.amazon.com/cli/latest/reference/iam/list-group-policies.html)(IAM 그룹의 인라인 정책 목록을 가져오는 방법), [aws iam delete-group-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-group-policy.html)(IAM 그룹의 인라인 정책을 삭제하는 방법)

1. IAM 그룹에 추가된 관리형 정책을 모두 분리합니다.
   + [aws iam list-attached-group-policies](https://docs.aws.amazon.com/cli/latest/reference/iam/list-attached-group-policies.html)(IAM 그룹에 추가된 관리형 정책 목록을 가져오는 방법), [aws iam detach-group-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/detach-group-policy.html)(IAM 그룹에서 관리형 정책을 분리하는 방법)

1. IAM 그룹을 삭제합니다.
   + [aws iam delete-group](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-group.html)

------
#### [ API ]

1. IAM 그룹에서 모든 사용자를 제거합니다.
   + [GetGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetGroup.html)(IAM 그룹의 사용자 목록 확인) 및 [RemoveUserFromGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_RemoveUserFromGroup.html)(IAM 그룹에서 사용자 제거)

1. IAM 그룹에 포함된 인라인 정책을 모두 삭제합니다.
   + [ListGroupPolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListGroupPolicies.html)(IAM 그룹의 인라인 정책 목록 확인) 및 [DeleteGroupPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteGroupPolicy.html)(IAM 그룹의 인라인 정책 삭제)

1. IAM 그룹에 추가된 관리형 정책을 모두 분리합니다.
   + [ListAttachedGroupPolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAttachedGroupPolicies.html)(IAM 그룹에 연결된 관리형 정책의 목록 확인) 및 [DetachGroupPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DetachGroupPolicy.html)(IAM 그룹에서 관리형 정책 연결 분리)

1. IAM 그룹을 삭제합니다.
   + [DeleteGroup](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteGroup.html)

------

# IAM 역할
<a name="id_roles"></a>

IAM *역할*은 계정에 생성할 수 있는, 특정 권한을 지닌 IAM 자격 증명입니다. AWS에서 자격 증명이 할 수 있는 것과 없는 것을 결정하는 권한 정책을 갖춘 AWS 자격 증명이라는 점에서 IAM 역할은 IAM 사용자와 유사합니다. 그러나 역할은 한 사람하고만 연관되지 않고 해당 역할이 필요한 사람이라면 누구든지 맡을 수 있어야 합니다. 또한 역할에는 그와 연관된 암호 또는 액세스 키와 같은 표준 장기 자격 증명이 없습니다. 대신에 역할을 맡은 사람에게는 해당 역할 세션을 위한 임시 보안 자격 증명이 제공됩니다.

역할을 사용하여 일반적으로 AWS 리소스에 액세스할 수 없는 사용자, 애플리케이션 또는 서비스에 액세스 권한을 위임할 수 있습니다. 예를 들어 AWS 계정의 사용자에게 이들이 대개 권한이 없는 리소스에 대한 액세스 권한을 부여하거나 한 AWS 계정의 사용자에게 다른 계정의 리소스에 대한 액세스 권한을 부여해야 할 경우가 있습니다. 또는 모바일 앱에서 AWS 리소스를 사용할 수 있도록 허용하되 앱에 AWS 키를 내장하길 원치 않는 경우(업데이트하기 어렵고 사용자가 추출할 가능성이 있음)도 있습니다. 때로는 기업 디렉터리에서처럼 AWS 외부에 정의된 자격 증명을 이미 보유하고 있는 사용자에게 AWS 액세스 권한을 부여해야 하는 경우도 있습니다. 또는 타사에 계정에 대한 액세스 권한을 부여하여 리소스에 대한 감사를 수행할 수 있도록 해야 할 경우도 있을 수 있습니다.

이러한 경우 *IAM 역할*을 사용하여 AWS 리소스에 대한 액세스 권한을 위임할 수 있습니다. 이 단원에서는 역할 및 역할을 사용할 수 있는 여러 가지 방법, 다양한 접근 방식을 선택하는 경우와 방법, 역할을 생성, 관리, 전환(또는 수임) 및 삭제하는 방법을 소개합니다.

**참고**  
AWS 계정을 처음 만들 때는 기본적으로 역할이 생성되지 않습니다. 계정에 서비스를 추가하면 서비스 연결 역할을 추가하여 사용 사례를 지원할 수 있습니다.  
 서비스 연결 역할은 AWS 서비스에 연결된 서비스 역할의 한 유형입니다. 서비스는 사용자를 대신하여 작업을 수행하기 위해 역할을 수임할 수 있습니다. 서비스 연결 역할은 AWS 계정에 나타나고, 서비스가 소유합니다. IAM 관리자는 서비스 연결 역할의 권한을 볼 수 있지만 편집은 할 수 없습니다.  
서비스 연결 역할을 삭제하려면 먼저 관련 리소스를 삭제해야 합니다. 이렇게 하면 리소스에 대한 액세스 권한을 부주의로 삭제할 수 없기 때문에 리소스가 보호됩니다.  
서비스 연결 역할의 사용을 지원하는 서비스에 대한 자세한 정보는 [AWS IAM으로 작업하는 서비스](reference_aws-services-that-work-with-iam.md)를 참조하고 **서비스 연결 역할** 열에 **예**가 있는 서비스를 찾습니다. 해당 서비스에 대한 서비스 연결 역할 설명서를 보려면 **예(Yes)** 링크를 선택합니다.

**Topics**
+ [

## IAM 사용자(역할이 아님)를 생성해야 하는 경우
](#id_which-to-choose)
+ [

## 역할 용어 및 개념
](#id_roles_terms-and-concepts)
+ [

## 추가 리소스
](#id_roles_additional-resources)
+ [

# 혼동된 대리자 문제
](confused-deputy.md)
+ [

# IAM 역할 관련 일반 시나리오
](id_roles_common-scenarios.md)
+ [

# IAM 역할 생성
](id_roles_create.md)
+ [

# IAM 역할 관리
](id_roles_manage.md)
+ [

# 역할 수임 방법
](id_roles_manage-assume.md)

## IAM 사용자(역할이 아님)를 생성해야 하는 경우
<a name="id_which-to-choose"></a>

ID 페더레이션에서 지원하지 않는 사용 사례에는 IAM 사용자만 사용하는 것이 좋습니다. 일부 사용 사례는 다음과 같습니다.
+ **IAM 역할을 사용할 수 없는 워크로드** - AWS에 액세스해야 하는 위치에서 워크로드를 실행할 수 있습니다. 일부 상황에서는 예를 들어, WordPress 플러그인에 대한 임시 보안 인증을 제공하기 위해 IAM 역할을 사용할 수 없습니다. 이러한 상황에서는 해당 워크로드에 IAM 사용자 장기 액세스 키를 사용하여 AWS에 대해 인증합니다.
+ **타사 AWS 클라이언트** – IAM Identity Center를 사용한 액세스를 지원하지 않는 도구를 사용하는 경우(예: AWS에서 호스팅되지 않은 타사 AWS 클라이언트 또는 공급업체) IAM 사용자 장기 액세스 키를 사용합니다.
+ **AWS CodeCommit 액세스** – CodeCommit을 사용하여 코드를 저장하는 경우 CodeCommit에 대한 SSH 키 또는 서비스별 보안 인증이 있는 IAM 사용자를 사용하여 리포지토리를 인증할 수 있습니다. 일반 인증에 IAM Identity Center 사용자를 사용하는 것 외에 이렇게 하는 것이 좋습니다. IAM Identity Center 사용자는 AWS 계정 또는 클라우드 애플리케이션에 대한 액세스 권한이 필요한 인력의 사용자입니다. IAM 사용자를 구성하지 않고 CodeCommit 리포지토리에 대한 액세스 권한을 사용자에게 부여하기 위해 **git-remote-codecommit** 유틸리티를 구성할 수 있습니다. IAM 및 CodeCommit에 대한 자세한 내용은 [CodeCommit용 IAM 자격 증명: Git 자격 증명, SSH 키 및 AWS 액세스 키](id_credentials_ssh-keys.md) 단원을 참조하세요. **git-remote-codecommit** 유틸리티 구성에 대한 자세한 내용은 *AWS CodeCommit 사용 설명서*의 [보안 인증을 교체하여 AWS CodeCommit 리포지토리에 연결](https://docs.aws.amazon.com/codecommit/latest/userguide/temporary-access.html#temporary-access-configure-credentials)을 참조하세요.
+ **Amazon Keyspaces(Apache Cassandra용) 액세스** – IAM Identity Center 사용자를 사용할 수 없는 상황(예: Cassandra 호환성 테스트 목적)의 경우 서비스별 보안 인증이 있는 IAM 사용자를 사용하여 Amazon Keyspaces로 인증할 수 있습니다. IAM Identity Center 사용자는 AWS 계정 또는 클라우드 애플리케이션에 대한 액세스 권한이 필요한 인력의 사용자입니다. 임시 보안 인증을 사용하여 Amazon Keyspaces 연결할 수도 있습니다. 자세한 내용은 *Amazon Keyspaces(Apache Cassandra용) 개발자 안내서*의 [임시 보안 인증과 IAM 역할 및 SigV4 플러그인을 사용하여 Amazon Keyspaces에 연결](https://docs.aws.amazon.com/keyspaces/latest/devguide/access.credentials.html#temporary.credentials.IAM)을 참조하세요.
+ **긴급 액세스** – ID 제공업체에 액세스할 수 없고 AWS 계정에 조치를 취해야 하는 상황인 경우입니다. 복원 계획에 긴급 액세스 IAM 사용자 설정을 포함할 수 있습니다. 다중 인증(MFA)을 사용하여 긴급 사용자 보안 인증을 엄격하게 제어하고 보호하는 것이 좋습니다.

## 역할 용어 및 개념
<a name="id_roles_terms-and-concepts"></a>

아래는 역할을 시작하는 데 도움이 되는 몇 가지 기본 용어들입니다.

****역할****  
계정에서 생성할 수 있는 특정 권한을 가진 IAM 자격 증명입니다. IAM 역할은 IAM 사용자와 몇 가지 점에서 유사합니다. 역할과 사용자 모두 AWS에서 자격 증명으로 할 수 있는 것과 할 수 없는 것을 결정하는 권한 정책을 포함하는 AWS 자격 증명입니다. 그러나 역할은 한 사람하고만 연관되지 않고 해당 역할이 필요한 사람이라면 누구든지 맡을 수 있어야 합니다. 또한 역할에는 그와 연관된 암호 또는 액세스 키와 같은 표준 장기 자격 증명이 없습니다. 대신에 역할을 맡은 사람에게는 해당 역할 세션을 위한 임시 보안 자격 증명이 제공됩니다.  
역할은 다음의 주체들이 수임할 수 있습니다.  
+ 동일한 AWS 계정 또는 다른 AWS 계정의 IAM 사용자
+ 동일한 계정의 IAM 역할
+ 다음과 같은 AWS 서비스 및 기능과 함께 사용할 수 있는 서비스 보안 주체:
  + Amazon EC2 또는 AWS Lambda와 같은 컴퓨팅 서비스에서 코드를 실행하도록 지원하는 서비스
  + Amazon S3 객체 복제와 같이 사용자를 대신하여 리소스에 작업을 수행하는 기능
  + IAM Roles Anywhere 또는 Amazon ECS Anywhere와 같이 AWS 외부에서 실행되는 애플리케이션에 임시 보안 자격 증명을 제공하는 서비스
+ SAML 2.0, OpenID Connect와 호환되는 ID 제공업체(idP) 서비스에 의해 인증된 외부 사용자

****AWS 서비스 ** 역할**  
 서비스 역할은 서비스가 사용자를 대신하여 작업을 수행하는 것으로 가정하는 [IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)입니다. IAM 관리자는 IAM 내에서 서비스 역할을 생성, 수정 및 삭제할 수 있습니다. 자세한 내용은 *IAM 사용 설명서*의 [Create a role to delegate permissions to an AWS 서비스](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)를 참조하세요.

****AWS 서비스 연결 역할****  
 서비스 연결 역할은 AWS 서비스에 연결된 서비스 역할의 한 유형입니다. 서비스는 사용자를 대신하여 작업을 수행하기 위해 역할을 수임할 수 있습니다. 서비스 연결 역할은 AWS 계정에 나타나고, 서비스가 소유합니다. IAM 관리자는 서비스 연결 역할의 권한을 볼 수 있지만 편집은 할 수 없습니다.  
서비스 연결 역할 지원을 시작할 때 이미 서비스를 사용하는 중이라면 계정의 새 역할에 대해 알려주는 이메일을 받게 될 수 있습니다. 이 경우 서비스에서 계정에 서비스 연결 역할을 자동으로 생성합니다. 이 역할을 지원하기 위해 어떤 작업도 수행할 필요가 없으며, 이 역할을 수동으로 삭제할 수 없습니다. 자세한 내용은 [내 AWS 계정에 표시되는 새 역할](troubleshoot_roles.md#troubleshoot_roles_new-role-appeared) 섹션을 참조하세요.
서비스 연결 역할의 사용을 지원하는 서비스에 대한 자세한 정보는 [AWS IAM으로 작업하는 서비스](reference_aws-services-that-work-with-iam.md)를 참조하고 **서비스 연결 역할** 열에 **예**가 있는 서비스를 찾으세요. 해당 서비스에 대한 서비스 연결 역할 설명서를 보려면 **예(Yes)** 링크를 선택합니다. 자세한 내용은 [서비스 연결 역할 생성](id_roles_create-service-linked-role.md) 섹션을 참조하세요.

****역할 함께 묶기****  
역할 체인은 역할을 사용하여 두 번째 역할을 수임하는 경우입니다. 역할, AWS CLI 또는 API를 전환하여 AWS Management Console을 통해 역할 체인을 수행할 수 있습니다. 예를 들어, `RoleA`에 `RoleB`를 수임할 권한이 있습니다. AssumeRole API 작업에서 User1의 장기 사용자 자격 증명을 사용하여 `RoleA`를 수임할 수 있습니다. 그러면 `RoleA` 단기 자격 증명이 반환됩니다. 역할 체인을 사용하면 `RoleA`의 단기 자격 증명을 사용하여 User1이 `RoleB`를 수임하도록 할 수 있습니다.  
역할을 맡을 때 세션 태그를 전달하고 태그를 전이적으로 설정할 수 있습니다. 전이적 세션 태그는 역할 체인의 모든 후속 세션에 전달됩니다. 세션 태그에 대한 자세한 내용은 [AWS STS에서 세션 태그 전달](id_session-tags.md) 섹션을 참조하세요.  
역할 체인을 사용하면 AWS Management Console, AWS CLI 또는 AWS API 역할 세션이 최대 1시간으로 제한됩니다. 개별 역할에 구성된 최대 세션 기간과 상관없이 적용됩니다. [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API 작업을 사용하여 역할을 수임할 때 `DurationSeconds` 파라미터를 사용하여 역할 세션 길이를 지정할 수 있습니다. 역할에 대한 [최대 세션 기간 설정](id_roles_update-role-settings.md#id_roles_update-session-duration)에 따라 파라미터 값을 최대 43200초(12시간)까지 지정할 수 있습니다. 그러나 역할 함께 묶기를 사용해 역할을 수임하고 1시간보다 큰 `DurationSeconds` 파라미터 값을 지정하면 작업이 실패합니다.  
AWS Management Console에서의 역할 전환에 대한 자세한 내용은 [사용자에서 IAM 역할로 전환(콘솔)](id_roles_use_switch-role-console.md) 섹션을 참조하세요.

****위임****  
제어하는 리소스에 대한 액세스를 허용하는 권한을 누군가에게 부여하는 것입니다. 위임은 두 계정 간에 신뢰를 설정하는 것을 포함합니다. 첫 번째는 리소스를 소유한 계정입니다(신뢰하는 계정). 두 번째는 리소스에 액세스해야 하는 사용자가 포함된 계정입니다(신뢰되는 계정). 신뢰받는 계정과 신뢰하는 계정은 다음 중 하나가 될 수 있습니다.  
+ 동일 계정
+ 조직에서 통제하는 별도의 계정
+ 서로 다른 조직이 소유한 2개의 계정
리소스에 액세스할 수 있는 권한을 위임하려면 두 개의 정책이 연결된 신뢰하는 계정에서 [IAM 역할을 생성](id_roles_create_for-user.md)합니다. *권한 정책*은 역할 사용자에게 리소스에 대해 의도한 작업을 수행하는 데 필요한 권한을 부여합니다. *신뢰 정책*은 역할을 위임하도록 허용된 신뢰할 수 있는 계정 멤버를 지정합니다.  
트러스트 정책을 생성할 때 와일드카드(\$1)를 주요 요소의 일부로 지정하고 ARN을 지정할 수 없습니다. 신뢰 정책은 신뢰하는 계정의 역할에 연결되어 있고 권한의 절반에 해당합니다. 나머지 절반은 [사용자에게 역할 전환 또는 위임을 허용하는](id_roles_use_permissions-to-switch.md) 신뢰받는 계정의 사용자에게 연결된 권한 정책입니다. 임시로 역할을 위임하는 사용자는 자신의 고유 권한을 포기하고 대신 해당 역할의 권한을 위임합니다. 사용자가 역할을 끝내거나 역할 사용을 중지하면 원래 사용자 권한이 자동으로 회복됩니다. [외부 ID](id_roles_common-scenarios_third-party.md#id_roles_third-party_external-id)라 불리는 부가적인 파라미터는 동일한 조직에 의해 제어되지 않는 계정 사이에서 역할을 안전하게 사용하도록 하는 데 도움이 됩니다.

****신뢰 정책****  
역할을 수임하도록 *신뢰*하는 보안 주체를 정의하는 [JSON 정책 문서](reference_policies_grammar.md)입니다. 역할 신뢰 정책은 IAM의 역할에 연결된 필수 [리소스 기반 정책](access_policies.md#policies_resource-based)입니다. 신뢰 정책에서 지정할 수 있는 [보안 주체](reference_policies_elements_principal.md)에는 사용자, 역할, 계정 및 서비스가 포함됩니다. 자세한 내용은 **AWS 보안 블로그의 [How to use trust policies in IAM roles](https://aws.amazon.com/blogs//security/how-to-use-trust-policies-with-iam-roles/)를 참조하세요.

****크로스 계정 액세스를 위한 역할****  
한 계정의 리소스에 대한 액세스 권한을 다른 계정의 신뢰할 수 있는 보안 주체에 부여하는 역할. 역할은 크로스 계정 액세스를 부여하는 기본적인 방법입니다. 그러나 일부 AWS 제품을 사용하면 (역할을 프록시로 사용하는 대신) 리소스에 직접 정책을 연결할 수 있습니다. 이를 리소스 기반 정책이라고 하며, 이 정책을 사용하여 다른 AWS 계정의 보안 주체에게 리소스에 대한 액세스 권한을 부여할 수 있습니다. 이러한 리소스에는 Amazon Simple Storage Service(S3) 버킷, Amazon Glacier 볼트, Amazon Simple Notification Service(SNS) 주제, Amazon Simple Queue Service(SQS) 대기열이 포함됩니다. 리소스 기반 정책을 지원하는 서비스에 대한 자세한 내용은 [AWS IAM으로 작업하는 서비스](reference_aws-services-that-work-with-iam.md) 섹션을 참조하세요. 리소스 기반 정책에 대한 자세한 내용은 [IAM의 크로스 계정 리소스 액세스](access_policies-cross-account-resource-access.md) 섹션을 참조하세요.

## 추가 리소스
<a name="id_roles_additional-resources"></a>

다음 리소스는 IAM 역할과 관련된 IAM 용어를 자세히 알아보는 데 도움이 됩니다.
+ **보안 주체**란 작업을 수행하고 리소스에 액세스할 수 있는 AWS의 엔터티입니다. 보안 주체는 AWS 계정 루트 사용자, IAM 사용자 또는 역할입니다. AWS 서비스의 ID를 나타내는 보안 주체는 [서비스 보안 주체](reference_policies_elements_principal.md#principal-services)입니다. 역할 신뢰 정책에서 보안 주체 요소를 사용하여 역할을 수임하도록 신뢰하는 보안 주체를 정의합니다.

   역할을 수임하도록 허용할 수 있는 보안 주체에 대한 자세한 내용 및 예시는 [AWS JSON 정책 요소: Principal](reference_policies_elements_principal.md) 단원을 참조하세요.
+ **ID 제공업체**는 외부 ID 제공업체 및 AWS 사이에 신뢰 관계를 구축합니다. 기존 OpenID Connect(OIDC) 또는 Security Assertion Markup Language(SAML) 2.0 제공업체를 사용하여 AWS 리소스에 액세스할 수 있는 사용자를 관리할 수 있습니다. OIDC 및 SAML 2.0을 사용해 이러한 외부 ID 제공업체와 AWS 사이에 신뢰 관계를 구성하면 사용자가 IAM 역할에 할당됩니다. 사용자는 임시 보안 자격 증명을 부여받아 AWS 리소스에 대한 액세스가 가능합니다.

  페더레이션 보안 주체에 대한 자세한 내용은 [ID 공급자 및 AWS로의 페더레이션](id_roles_providers.md) 섹션을 참조하세요.
+ ****페더레이션 보안 주체는 Directory Service, 엔터프라이즈 사용자 디렉터리 또는 OIDC 공급자의 기존 ID입니다. AWS는 [ID 공급자](id_roles_providers.md)를 통해 액세스가 요청될 때 페더레이션 보안 주체에 역할을 할당합니다.

  SAML 및 OIDC 페더레이션 보안 주체에 대한 자세한 내용은 [페더레이션 사용자 세션 및 역할](introduction_access-management.md#intro-access-roles) 섹션을 참조하세요.
+ **권한 정책**은 역할이 사용할 수 있는 작업 및 리소스를 정의하는 ID 기반 정책입니다. 이 문서는 IAM 정책 언어의 규칙에 따라 작성됩니다.

  자세한 내용은 [IAM JSON 정책 참조](reference_policies.md) 섹션을 참조하세요.
+ **권한 경계**는 ID 기반 정책이 역할에 부여할 수 있는 최대 권한을 제한하는 정책을 사용하는 고급 기능입니다. 서비스 연결 역할에 권한 경계를 적용할 수 없습니다.

  자세한 내용은 [IAM 엔터티의 권한 범위](access_policies_boundaries.md) 섹션을 참조하세요.

# 혼동된 대리자 문제
<a name="confused-deputy"></a>

혼동된 대리자 문제는 작업을 수행할 권한이 없는 엔터티가 권한이 더 많은 엔터티에게 작업을 수행하도록 강요할 수 있는 보안 문제입니다. 이를 방지하기 위해 AWS은(는) 계정의 리소스에 타사(*크로스 계정*) 또는 기타 AWS 서비스(*교차 서비스*) 액세스를 제공할 경우 계정을 보호하는 데 도움이 되는 도구를 제공합니다.

이따금 AWS 리소스에 대한 액세스를 타사에 부여해야 할 때가 있습니다(액세스 위임). 예를 들어 Example Corp이라는 서드파티를 고용해 AWS 계정을 모니터링하고 비용을 최적화하려고 합니다. 일일 경비를 추적하기 위해 Example Corp은 AWS 리소스에 접근해야 합니다. Example Corp 역시 다른 고객을 위해 다른 많은 AWS 계정을 모니터링합니다. IAM 역할을 사용하여 AWS 계정과 Example Corp 계정 사이에 신뢰 관계를 설정할 수 있습니다. 이 시나리오에서 한 가지 중요한 부분은 *외부 ID*입니다. 이 ID는 IAM 역할 신뢰 정책에서 역할을 수임할 수 있는 사람을 지정하는 데 사용할 수 있는 선택적 식별자입니다. 외부 ID의 주된 기능은 혼동된 대리자 문제를 해결하고 방지하는 것입니다.

일부 AWS 서비스(직접 호출하는 서비스)는 AWS 서비스 위탁자를 사용하여 다른 AWS 서비스(직접 호출되는 서비스)의 AWS 리소스에 액세스합니다. 이러한 서비스 상호 작용 중 일부에서 다른 AWS 계정에 있는 직접 호출되는 서비스의 리소스와 통신하도록 직접 호출하는 서비스를 구성할 수 있습니다. 이에 대한 예제로, 다른 AWS 계정에 있는 중앙 Amazon S3 버킷에 쓰도록 AWS CloudTrail을 구성하는 작업이 있습니다. 직접 호출 서비스인 CloudTrail에는 `cloudtrail.amazonaws.com`에 대한 allow 문을 추가하여 S3 버킷의 정책을 사용해 S3 버킷에 대한 액세스 권한이 부여됩니다.

직접 호출하는 서비스의 AWS 서비스 위탁자가 직접 호출되는 서비스의 리소스에 액세스하는 경우 직접 호출되는 서비스의 리소스 정책은 직접 호출하는 서비스를 구성한 액터가 아닌 AWS 서비스 위탁자에게만 권한을 부여합니다. 예를 들어 조건 없이 CloudTrail 서비스 위탁자를 신뢰하는 S3 버킷은 신뢰할 수 있는 관리자가 구성하는 AWS 계정에서 CloudTrail 로그를 수신할 수 있지만, 권한이 없는 액터가 S3 버킷의 이름을 알고 있다면 AWS 계정의 해당 액터로부터 CloudTrail 로그도 수신할 수 있습니다.

혼동된 대리자 문제는 액터가 AWS 서비스의 서비스 위탁자 신뢰를 이용해 원래 액세스를 허용하지 않으려던 리소스에 액세스할 때 발생합니다.

## 크로스 계정 혼동된 대리자 예방
<a name="mitigate-confused-deputy"></a>

다음 다이어그램은 크로스 계정 혼동된 대리자 문제를 보여줍니다.

![\[혼동된 대리자 문제에 대한 설명.\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/confuseddeputyproblem2.png)


이 시나리오에서는 다음과 같이 가정합니다.
+ **AWS1**은 사용자의 AWS 계정입니다.
+ **AWS1:ExampleRole**은 계정의 역할입니다. 이 역할의 신뢰 정책은 Example Corp의 AWS 계정의 역할을 위임할 수 있는 것으로 지정함으로써 Example Corp을 신뢰합니다.

다음은 무슨 일이 일어나는지에 대한 것입니다.

1. Example Corp 서비스 사용을 시작할 때 Example Corp에 **AWS1:ExampleRole**의 ARN을 제공합니다.

1. Example Corp은 그 ARN을 사용해 임시 보안 인증을 얻어 AWS 계정의 리소스에 액세스합니다. 이러한 방식으로 Example Corp을 대신 행위할 수 있는 "대리자"로 신뢰합니다.

1. 또 다른 AWS 고객도 Example Corp의 서비스를 사용하기 시작하고, 이 고객 역시 Example Corp가 사용할 **AWS1:ExampleRole**의 ARN을 제공합니다. 아마도 그 다른 고객은 비밀이 아닌 **AWS1:ExampleRole**을 알거나 짐작했을 것입니다.

1. 다른 고객이 Example Corp에게(자신의 것이라고 주장하는) 계정의 AWS 리소스에 액세스할 수 있는 권한을 요청하면, Example Corp는 **AWS1:ExampleRole**을 사용해 계정의 리소스에 액세스합니다.

이것이 바로 다른 고객이 리소스에 무단으로 액세스하는 과정입니다. 이 고객은 Example Corp이 자신도 모르게 리소스에 대한 작업을 하도록 속일 수 있었기 때문에 Example Corp은 이제 "혼동된 대리자"가 되었습니다.

Example Corp는 사용자가 역할의 신뢰 정책에 `ExternalId` 조건 확인을 포함하도록 요구하여 혼동된 대리자 문제를 해결합니다. Example Corp는 각 고객에 대해 고유 `ExternalId` 값을 생성하며 요청에 해당 값을 사용하여 역할을 수임합니다. `ExternalId` 값은 Example Corp의 고객 사이에서 고유해야 하며 고객이 아닌 Example Corp에 의해 제어되어야 합니다. 이것이 바로 Example Corp에서 외부 ID를 얻고 그것을 스스로 찾아내지 않는 이유입니다. 이로 인해 Example Corp이 혼동된 대리자가 되는 것을 예방하고 다른 계정의 AWS 리소스에 대한 액세스 권한을 부여하는 것을 방지합니다.

이 시나리오에서 Example Corp의 고유 식별자가 12345이고, 다른 고객에 대해서는 그 식별자가 67890이라고 가정합시다. 이러한 식별자는 이 시나리오를 위해 단순화된 것입니다. 일반적으로 이러한 식별자는 GUID입니다. 이 식별자가 Example Corp의 고객 사이에서 고유한 것이라고 가정할 때, 외부 ID를 위해 사용하기에 합리적인 값들입니다.

Example Corp은 12345라는 외부 ID 값을 부여합니다. 그런 다음 [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#condition-keys-sts](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#condition-keys-sts) 값이 12345가 되어야 한다고 요구하는 역할의 신뢰 정책에 `Condition` 요소를 다음과 같이 추가해야 합니다.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Principal": {
      "AWS": "Example Corp's AWS Account ID"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {
        "sts:ExternalId": "12345"
      }
    }
  }
}
```

------

이 정책의 조건 요소는 AssumeRole API 호출에 12345라는 외부 ID 값이 포함될 때만 Example Corp이 역할을 수임하도록 허용합니다. Example Corp은 고객을 대신해 역할을 위임할 때마다 항상 AssumeRole 호출에 해당 고객의 외부 ID 값을 포함하도록 보장합니다. 다른 고객이 Example Corp에게 ARN을 공급한다 하더라도 Example Corp이 AWS에 대한 요청 시 포함하는 외부 ID를 제어할 수 없습니다. 이는 권한을 부여받지 않은 고객이 리소스에 액세스하지 못하도록 방지하는 데 도움이 됩니다.

다음 다이어그램에서 이 방법을 보여줍니다.

![\[혼동된 대리자 문제를 완화하는 방법\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/confuseddeputymitigation2.png)


1. 전과 같이 Example Corp 서비스 사용을 시작할 때 Example Corp에 **AWS1:ExampleRole**의 ARN을 제공합니다.

1.  Example Corp가 그 ARN을 사용해 **AWS1:ExampleRole** 역할을 위임하는 경우 Example Corp는 AssumeRole API 호출에 외부 ID(12345)를 포함시킵니다. 외부 ID는 역할의 신뢰 정책과 일치하므로 AssumeRole API 호출은 성공하고 Example Corp는 임시 보안 인증을 획득해 AWS 계정의 리소스에 액세스합니다.

1. 또 다른 AWS 고객도 Example Corp의 서비스를 사용하기 시작하고, 전과 같이 이 고객 역시 Example Corp가 사용할 **AWS1:ExampleRole**의 ARN을 제공합니다.

1. 그러나 이번에는 Example Corp가 **AWS1:ExampleRole**이라는 역할을 위임하려 할 때 다른 고객과 연결된 외부 ID(67890)를 제공하므로 해당 고객은 이를 바꿀 방법이 없습니다. Example Corp이 이렇게 하는 이유는 역할을 사용하겠다는 요청이 다른 고객에게서 왔으므로, 67890은 Example Corp이 작용하고 있는 상황을 나타내기 때문입니다. **AWS1:ExampleRole**의 신뢰 정책에 자신의 외부 ID(12345)가 있는 조건을 추가했기 때문에 AssumeRole API 호출은 실패하고 다른 고객이 계정 리소스에 무단으로 액세스하는 것을 막을 수 있습니다(다이어그램의 빨간색 "X" 참조).

외부 ID는 다른 고객이 Example Corp을 속여 자신도 모르게 리소스에 액세스하지 못하도록 방지합니다.

## 교차 서비스 혼동된 대리자 방지
<a name="cross-service-confused-deputy-prevention"></a>

다음 다이어그램은 CloudTrail 및 Amazon S3 상호 작용 예제를 사용하여 교차 서비스 혼동된 대리자 문제를 보여줍니다. 여기에서는 권한이 없는 액터가 액세스 권한이 없는 Amazon S3 버킷에 CloudTrail 로그를 씁니다.

![\[권한이 없는 액터의 경우 CloudTrail 서비스 위탁자를 이용한 다른 계정의 Amazon S3 버킷에 대한 액세스가 허용됩니다.\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/cross-service-confused-deputy1.png)


권한이 없는 액터가 AWS 위탁자의 신뢰를 이용해 리소스에 액세스하지 못하도록 하기 위해 AWS 서비스 위탁자는 자신이 대리하는 AWS 리소스, AWS 계정 및 AWS 조직에 대한 정보를 포함합니다.

이 정보는 리소스 정책 또는 AWS 서비스 위탁자가 수행한 요청에 대한 리소스 제어 정책에서 사용할 수 있는 전역 조건 키 값으로 사용 가능합니다. AWS 서비스 위탁자에게 리소스 중 하나에 액세스할 권한이 부여되는 경우 항상 리소스 정책에 [aws:SourceArn](reference_policies_condition-keys.md#condition-keys-sourcearn), [aws:SourceAccount](reference_policies_condition-keys.md#condition-keys-sourceaccount), [aws:SourceOrgID](reference_policies_condition-keys.md#condition-keys-sourceorgid) 또는 [aws:SourceOrgPaths](reference_policies_condition-keys.md#condition-keys-sourceorgpaths)를 사용하는 것이 좋습니다. 이러한 조건 키를 사용하면 리소스 정책 또는 예상되는 AWS 리소스, AWS 계정 또는 AWS Organizations를 대신하여 리소스에 액세스하는 AWS 서비스 위탁자가 사용하는 리소스 제어 정책을 테스트할 수 있습니다.
+ `aws:SourceArn`을 사용하여 AWS 서비스 위탁자가 특정 AWS CloudTrail 추적 또는 AppStream 플릿과 같은 특정 리소스를 대신하여 리소스에 액세스할 수 있도록 허용합니다.
+ `aws:SourceAccount`를 사용하여 AWS 서비스 위탁자가 특정 AWS 계정를 대신하여 리소스에 액세스할 수 있도록 허용합니다.
+ `aws:SourceOrgID`를 사용하여 AWS 서비스 위탁자가 특정 AWS Organizations를 대신하여 리소스에 액세스할 수 있도록 허용합니다.
+ `aws:SourceOrgPaths`를 사용하여 AWS 서비스 위탁자가 특정 AWS Organizations 경로를 대신하여 리소스에 액세스할 수 있도록 허용합니다.

다음 다이어그램에서는 리소스가 `aws:SourceAccount` 전역 조건 컨텍스트 키로 구성되고 다른 계정의 권한이 없는 액터가 원래 액세스를 허용하지 않으려던 AWS 리소스에 액세스하려고 하는 교차 서비스 혼동된 대리자 시나리오를 보여줍니다.

![\[권한이 없는 액터의 경우 CloudTrail 서비스 위탁자를 이용한 다른 계정의 Amazon S3 버킷에 대한 액세스가 거부됩니다.\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/cross-service-confused-deputy2.png)


정책에서 `aws:SourceArn`, `aws:SourceAccount`, `aws:SourceOrgID` 및 `aws:SourceOrgPaths` 전역 조건 키를 사용하면 서비스 위탁자가 사용자를 대신하여 리소스에 액세스할 수 있습니다. 리소스 중 하나에 대한 액세스 권한이 AWS 서비스 위탁자에게 부여될 때마다 이러한 조건 키를 사용하는 것이 좋습니다.

**참고**  
일부 AWS 서비스 상호 작용에는 리소스에 대한 사용자 액세스를 테스트하는 교차 서비스 혼동된 대리자 문제를 방지하는 데 도움이 되는 추가 제어 기능이 있습니다. 예를 들어 KMS 키 부여가 AWS 서비스에 대해 실행되면 AWS KMS에서는 리소스와 연결된 암호화 컨텍스트 및 키 권한 부여를 통해 교차 서비스 혼동된 대리자 문제를 방지할 수 있습니다.  
교차 서비스 혼동된 대리자 위험을 방지하는 데 도움이 될 수 있는 서비스별 메커니즘과 `aws:SourceArn`, `aws:SourceAccount`, `aws:SourceOrgID`, `aws:SourceOrgPaths` 지원 여부에 대한 자세한 내용은 사용하는 서비스의 설명서를 참조하세요.

## 리소스 기반 정책을 사용하여 교차 서비스 혼동된 대리자 방지
<a name="cross-service-confused-deputy-prevention-resource"></a>

다음 예제 정책에서는 서비스 위탁자 `cloudtrail.amazonaws.com`이 AWS 계정 111122223333을 대신하여 작업하는 경우에만 Amazon S3 버킷(arn:aws:s3:::amzn-s3-demo-bucket1)에 대한 액세스 권한을 해당 서비스 위탁자에 부여합니다.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "CloudTrailAclCheck",
            "Effect": "Allow",
            "Principal": {"Service": "cloudtrail.amazonaws.com"},
            "Action": "s3:GetBucketAcl",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket1",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "111122223333"
                }
            }
        },
        {
            "Sid": "AWSCloudTrailWrite",
            "Effect": "Allow",
            "Principal": {"Service": "cloudtrail.amazonaws.com"},
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket1/[optionalPrefix]/Logs/myAccountID/*",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "111122223333"
                }
            }
        }
    ]
}
```

------

이 버킷 정책 예제에서는 `aws:SourceArn`으로 플릿 ARN을 지정하여 지정된 Amazon AppStream 플릿을 대신해 작업하는 경우에만 s3://amzn-s3-demo-bucket2 내에서 powershell 스크립트 examplefile.psh에 대한 액세스 권한을 서비스 위탁자 `appstream.amazonaws.com`에 부여합니다.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": [
                    "appstream.amazonaws.com"
                ]
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::amzn-s3-demo-bucket2/examplefile.psh",
            "Condition": {
                "ArnEquals": {
                    "aws:SourceArn": "arn:aws:appstream:us-east-1:111122223333:fleet/ExampleFleetName"
                } 
            }
        }
    ]
}
```

------

## 리소스 제어 정책을 사용하여 교차 서비스 혼동된 대리자 방지
<a name="cross-service-confused-deputy-prevention-resource-control"></a>

리소스 제어 정책(RCP)을 사용하여 지원되는 AWS 서비스의 리소스에 교차 서비스 혼동된 대리자 제어 기능을 적용할 수 있습니다. RCP를 사용하면 리소스에서 교차 서비스 혼동된 대리자 제어 기능을 중앙에서 적용할 수 있습니다. 특정 리소스 기반 정책에 명령문을 추가하지 않고도 조직의 AWS Organizations, 조직 단위(OU) 또는 AWS 계정에 연결된 RCP를 사용하여 `aws:SourceOrgId` 및 `aws:SourceOrgPaths`와 같은 조건 키를 사용할 수 있습니다. RCP 및 지원되는 서비스에 대한 자세한 내용은 *AWS Organizations 사용 설명서*의 [리소스 제어 정책(RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)을 참조하세요.

다음 예제 RCP에서는 `aws:SourceOrgID`가 o-ExampleOrg와 같지 않으면 멤버 계정에 있는 Amazon S3 버킷에 대한 AWS 서비스 위탁자의 액세스를 거부합니다. `SourceOrgID`가 o-ExampleOrg인 AWS 서비스 위탁자를 허용하려면 S3 버킷의 리소스 기반 정책에 해당 허용이 있어야 합니다.

이 정책은 `aws:SourceAccount` 키가 있는(`"Null": {"aws:SourceAccount": "false"}`) 서비스 위탁자(`"Bool": {"aws:PrincipalIsAWSService": "true"}`)의 요청에만 제어를 적용하므로 조건 키를 사용할 필요가 없는 서비스 통합 및 위탁자의 직접 호출에는 영향을 미치지 않습니다. 요청 컨텍스트에 `aws:SourceAccount` 조건 키가 있는 경우 Null 조건은 true로 평가되어 `aws:SourceOrgID`에 적용됩니다. Null 조건 연산자에서 `aws:SourceOrgID` 대신 `aws:SourceAccount`를 사용하여 요청이 조직에 속하지 않은 계정에서 시작된 경우에도 제어가 여전히 적용되도록 합니다.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Sid": "RCPEnforceConfusedDeputyProtectionForS3",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "s3:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEqualsIfExists": {
          "aws:SourceOrgID": "o-ExampleOrg"
        },
        "Null": {
          "aws:SourceAccount": "false"
        },
        "Bool": {
          "aws:PrincipalIsAWSService": "true"
        }
      }
    }
  ]
}
```

------

# IAM 역할 관련 일반 시나리오
<a name="id_roles_common-scenarios"></a>

대부분의 AWS 기능과 마찬가지로 역할 사용에는 일반적으로 두 가지 방법이 있습니다. 즉, IAM 콘솔에서 대화식으로 사용하는 것 또는 AWS CLI, Tools for Windows PowerShell이나 API에서 프로그래밍 방식으로 사용하는 것입니다.
+ IAM 콘솔을 사용하는 계정의 IAM 사용자가 역할을 *전환하여* 콘솔에서 해당 역할의 권한을 임시로 사용할 수 있습니다. 사용자는 자신의 원래 권한을 포기하고 역할에 할당된 권한을 수임합니다. 사용자가 역할을 끝내면 원래 권한이 복원됩니다.
+ AWS에서 제공하는 애플리케이션 또는 서비스(예: Amazon EC2)가 AWS에 프로그래밍 방식으로 요청할 때 사용할 역할의 임시 보안 자격 증명을 요청하여 역할을 *수임*할 수 있습니다. 역할을 이렇게 사용하면 리소스에 액세스해야 하는 각 엔터티를 위한 장기 보안 자격 증명을 공유하거나 유지(예: IAM 사용자 생성)할 필요가 없습니다.

**참고**  
이 안내서는 *역할로 전환합니다*와 *역할을 수임합니다*라는 표현을 서로 대치할 수 있는 동일한 의미로 사용합니다.

역할을 사용하는 가장 간단한 방법은 IAM 사용자에게 자신이나 다른 사용자의 AWS 계정에서 생성하는 역할로 전환할 권한을 부여하는 것입니다. IAM 사용자는 IAM 콘솔을 통해 역할을 쉽게 전환하여 일반적으로 부여받지 않은 권한을 사용한 다음 역할을 끝내 해당 권한을 포기할 수 있습니다. 이를 통해 중요한 리소스에 *잘못* 액세스하거나 이를 수정하는 일을 방지할 수 있습니다.

애플리케이션 및 서비스 또는 연동된 외부 사용자에게 액세스 권한을 부여하는 등 역할을 한층 복잡한 방식으로 사용하기 위해 `AssumeRole` API를 호출할 수 있습니다. 이 API 호출은 애플리케이션이 이후의 API 호출에 사용할 수 있는 일련의 임시 자격 증명 세트를 반환합니다. 임시 자격 증명을 사용하여 시도하는 작업에는 연결된 역할에서 부여한 권한만 있습니다. 애플리케이션에서는 콘솔에서 사용자가 하듯이 역할을 "끝낼" 필요가 없습니다. 단지 애플리케이션에서 임시 자격 증명 사용을 중지하고 원래 자격 증명으로 호출을 재개합니다.

페더레이션 사용자는 IdP(자격 증명 공급자)에서 제공하는 자격 증명을 사용하여 로그인합니다. 그 다음 AWS에서 신뢰받는 IdP에 임시 자격 증명을 제공하여 이후의 AWS 리소스 요청에 포함할 수 있도록 사용자에게 전달합니다. 그러한 자격 증명은 할당된 역할에 부여된 권한을 제공합니다.

이 섹션에서는 다음 시나리오의 개요를 제공합니다.
+ [소유한 AWS 계정의 IAM 사용자에게 소유한 다른 계정의 리소스에 액세스할 수 있는 권한 제공](id_roles_common-scenarios_aws-accounts.md)
+ [AWS 워크로드 이외 워크로드에 대한 액세스 권한 제공](id_roles_common-scenarios_non-aws.md)
+ [타사가 소유한 AWS 계정에 속한 IAM 사용자에 액세스 권한 제공](id_roles_common-scenarios_third-party.md)
+ [AWS가 제공하는 서비스를 위해 AWS 리소스에 대한 액세스 권한을 제공하는 경우](id_roles_common-scenarios_services.md)
+ [외부에서 인증된 사용자에게 액세스 권한 제공(아이덴티티 페더레이션)](id_roles_common-scenarios_federated-users.md)

# 소유한 다른 AWS 계정의 IAM 사용자에 대한 액세스
<a name="id_roles_common-scenarios_aws-accounts"></a>

IAM 사용자에게 AWS 계정 내의 역할 또는 소유하고 있는 다른 AWS 계정에 정의된 역할로 전환할 수 있는 권한을 부여할 수 있습니다.

**참고**  
소유하지 않은 또는 제어하지 않는 계정에 대한 액세스 권한을 부여하고자 하는 경우, 이 주제 뒷부분의 [타사가 소유한 AWS 계정에 액세스](id_roles_common-scenarios_third-party.md) 섹션을 참조하세요.

조직에 중요한 Amazon EC2 인스턴스가 있다고 가정해 봅시다. 사용자에게 인스턴스를 종료할 수 있는 권한을 직접 부여하지 않고, 이러한 권한이 있는 역할을 만들 수 있습니다. 그런 다음 관리자는 인스턴스를 종료해야 하는 경우 해당 역할로 전환할 수 있습니다. 그러면 이러한 인스턴스에 다음과 같은 보호 계층이 추가됩니다.
+ 사용자에게 역할을 수임할 권한을 명시적으로 부여해야 합니다.
+ 사용자는 AWS Management Console을 사용하여 해당 역할로 능동적으로 전환하거나 AWS CLI 또는 AWS API를 사용하여 역할을 수임해야 합니다.
+ 역할에 멀티 팩터 인증(MFA) 보호를 추가하여 MFA 디바이스로 로그인하는 사용자만 역할을 수임할 수 있도록 합니다. 역할을 수임한 사용자가 MFA(멀티 팩터 인증)를 사용하여 처음에 인증을 받도록 역할을 구성하는 방법을 알아보려면 [MFA를 통한 보안 API 액세스](id_credentials_mfa_configure-api-require.md) 섹션을 참조하세요.

이 방법을 사용하여 *최소 권한 원칙*을 적용하는 것이 좋습니다. 다시 말해, 특정 작업이 필요한 경우에만 승격된 권한을 사용하도록 제한하는 것입니다. 역할을 사용하여 중요한 환경을 실수로 변경하는 일을 방지할 수 있습니다. 특히 필요할 때만 역할이 사용되는지 확인하기 위해 중요한 환경을 [감사](cloudtrail-integration.md)와 결합하는 경우에 그렇습니다.

이러한 목적을 위해 역할을 만들려면 해당 역할의 신뢰 정책 `Principal` 요소에서 액세스가 필요한 사용자의 ID로 계정을 지정합니다. 그러면 그러한 다른 계정의 특정 사용자에게 해당 역할로 전환할 수 있는 권한을 부여할 수 있습니다. 해당 신뢰 영역(신뢰할 수 있는 조직 또는 계정) 외의 계정 내 보안 주체가 역할을 수임하는 권한이 있는지 자세히 알고 싶다면, [IAM Access Analyzer란 무엇인가요?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)를 참조하세요.

한 계정의 사용자는 동일한 또는 다른 계정의 역할로 전환할 수 있습니다. 사용자는 역할을 사용하는 동안 해당 작업만을 수행하고 해당 역할에서 허용한 리소스만 액세스할 수 있지만, 이들의 원래 사용자 권한은 일시 중지된 상태입니다. 사용자가 역할을 끝내면 원래 사용자 권한이 회복됩니다.

## 분리된 개발 및 프로덕션 계정을 사용한 예제 시나리오
<a name="id_roles_common-scenarios_aws-accounts-example"></a>

프로덕션 환경에서 개발 환경을 격리하기 위해 조직이 여러 개의 AWS 계정을 갖고 있다고 가정합시다. 개발 계정의 사용자는 프로덕션 계정의 리소스에 액세스해야 하는 경우가 있습니다. 예를 들어, 개발 환경에서 프로덕션 환경으로 업데이트를 승격하려는 경우 크로스 계정 액세스 권한이 필요할 수 있습니다. 두 계정을 모두 사용하는 사용자를 위해 별도의 자격 증명(및 암호)을 생성했다 해도 여러 계정에 대한 자격 증명을 관리할 경우 자격 증명 관리가 어려워집니다. 다음 그림을 보면 모든 사용자가 개발 계정에서 관리됩니다. 그러나 일부 개발자에게는 프로덕션 계정에 대한 제한된 액세스 권한이 필요합니다. 개발 계정에는 Testers와 Developers라는 두 개의 그룹이 있으며 각 그룹에는 고유의 정책이 있습니다.

![\[역할을 사용하여 다른 계정의 사용자에게 권한 위임\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/roles-usingroletodelegate.png)


1. 프로덕션 계정에서 관리자는 IAM을 사용하여 해당 계정에 `UpdateApp` 역할을 생성합니다. 관리자는 그 역할에서 개발 계정을 `Principal`로 지정하는 신뢰 정책을 정의합니다. 이는 개발 계정의 권한이 있는 사용자는 `UpdateApp` 역할을 사용할 수 있다는 것을 뜻합니다. 또한 관리자는 이 역할의 사용자가 `productionapp`이라는 Amazon S3 버킷에 대한 읽기 및 쓰기 권한을 보유하도록 지정하는 역할의 권한 정책을 정의합니다.

   그런 다음 관리자는 적절한 정보를 이 역할을 수임해야 하는 대상과 공유합니다. 그러한 정보로는 계정 번호와 역할 이름(AWS 콘솔 사용자들에 대한) 또는 Amazon 리소스 이름(ARN)(AWS CLI 또는 AWS API 액세스용)이 있습니다. 역할 ARN은 `arn:aws:iam::123456789012:role/UpdateApp`과 같은 형태를 띱니다. 여기에서 역할의 이름은 `UpdateApp`이고, 역할이 생성된 계정 번호는 123456789012입니다.
**참고**  
관리자는 역할을 수임하는 사용자가 먼저 멀티 팩터 인증(MFA)을 사용하여 인증을 받도록 역할을 구성할 수도 있습니다. 자세한 내용은 [MFA를 통한 보안 API 액세스](id_credentials_mfa_configure-api-require.md) 섹션을 참조하세요.

1. 개발 계정에서 관리자는 Developer 그룹의 구성원에게 이 역할로 전환할 수 있는 권한을 부여합니다. 이를 수행하려면 Developers 그룹에 `UpdateApp` 역할에 대한 AWS Security Token Service(AWS STS) `AssumeRole` API를 호출할 권한을 부여하면 됩니다. 이제 개발 계정의 Developers 그룹에 속한 모든 IAM 사용자는 프로덕션 계정의 `UpdateApp` 역할로 전환할 수 있습니다. Developer 그룹에 속하지 않은 다른 사용자는 이 역할로 전환할 수 있는 권한이 없으므로 프로덕션 계정의 S3 버킷에 액세스할 수 없습니다.

1. 사용자가 이 역할로의 전환을 요청:
   + AWS 콘솔: 탐색 표시줄에서 계정 이름을 선택하고 **Switch Role(역할 전환)**을 선택합니다. 계정 ID(또는 별칭) 및 역할 이름을 지정합니다. 아니면 사용자는 관리자가 이메일로 보낸 링크를 클릭해도 됩니다. 링크를 누르면 세부 정보가 이미 채워져 있는 **역할 전환** 페이지로 이동합니다.
   + AWS API/AWS CLI: 개발 계정의 Developers 그룹에 속한 사용자는 `AssumeRole` 함수를 호출하여 `UpdateApp` 역할에 대한 자격 증명을 가져옵니다. `UpdateApp` 역할의 ARN을 이 호출의 일부로 지정합니다. Testers 그룹의 사용자가 동일한 요청을 하는 경우에는 요청이 실패하는데, 이는 Testers가 `AssumeRole` 역할 ARN을 위해 `UpdateApp`을 호출할 권한이 없기 때문입니다.

1. AWS STS는 임시 자격 증명을 반환합니다.
   + AWS 콘솔: AWS STS에서 그 요청이 신뢰할 수 있는 대상(개발 계정)에서 온 것인지 확인하기 위해 그 요청에 대해 역할의 신뢰 정책을 확인합니다. 확인 후 AWS STS에서 AWS 콘솔로 [임시 보안 자격 증명](https://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html)을 반환합니다.
   + API/CLI: AWS STS에서 신뢰할 수 있는 대상(Development 계정)이 요청을 보낸 것인지 확인하기 위해 역할의 신뢰 정책에 대한 요청을 확인합니다. 확인 후 AWS STS에서 해당 애플리케이션으로 [임시 보안 자격 증명](https://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html)을 반환합니다.

1. 임시 자격 증명은 AWS 리소스에 대한 액세스를 허용합니다.
   + AWS 콘솔: AWS 콘솔은 이후의 모든 콘솔 작업에서 사용자를 대신하여 임시 자격 증명을 사용합니다. 이 경우에 그 작업이란 `productionapp` 버킷에 대한 읽기 및 쓰기입니다. 이 콘솔은 프로덕션 계정의 다른 리소스에는 액세스할 수 없습니다. 사용자가 역할을 끝내면 사용자의 권한은 이 역할로 전환하기 전에 보유한 원래의 권한으로 돌아갑니다.
   + API/CLI: 이 애플리케이션에서는 임시 보안 자격 증명을 사용하여 `productionapp` 버킷을 업데이트합니다. 이 애플리케이션은 임시 보안 자격 증명을 통해 `productionapp` 버킷에 대한 읽기 및 쓰기만 할 수 있으며 프로덕션 계정의 다른 리소스에는 액세스할 수 없습니다. 애플리케이션은 역할을 종료하지 않아도 되지만 대신에 임시 자격 증명 사용을 중지하고 이후의 API 호출에서 다시 원래의 자격 증명을 사용합니다.

## 추가 리소스
<a name="id_roles_common-scenarios_more-info"></a>

자세한 내용은 다음을 참조하세요.
+ [튜토리얼: IAM 역할을 사용한 AWS 계정 간 액세스 권한 위임](tutorial_cross-account-with-roles.md)

# 비AWS 워크로드 액세스
<a name="id_roles_common-scenarios_non-aws"></a>

[IAM 역할](id_roles.md)은 [권한](access_policies.md)이 할당된 AWS Identity and Access Management(IAM)의 객체입니다. IAM 자격 증명 또는 AWS 외부의 자격 증명을 사용하여 [역할을 맡은](id_roles_manage-assume.md) 경우 해당 역할 세션을 위한 임시 보안 자격 증명이 제공됩니다. AWS 리소스에 액세스해야 하는 데이터 센터 또는 AWS 외부의 기타 인프라에서 실행 중인 워크로드가 있을 수 있습니다. 장기 액세스 키를 생성, 배포 및 관리하는 대신 AWS Identity and Access Management Roles Anywhere(IAM Roles Anywhere)를 사용하여 AWS 이외 워크로드를 인증할 수 있습니다. IAM Roles Anywhere는 인증 기관(CA)의 X.509 인증서를 사용하여 자격 증명을 인증하고 IAM 역할에서 제공하는 임시 보안 인증을 사용하여 AWS 서비스에 대한 액세스 권한을 안전하게 제공합니다.

**IAM Roles Anywhere 사용**

1. [AWS Private Certificate Authority](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) 사용을 통해 CA를 설정하거나 자체 PKI 인프라의 CA를 사용합니다.

1. CA를 설정한 후 IAM Roles Anywhere에서 **트러스트 앵커라는 객체를 생성합니다. 이 앵커는 IAM Roles Anywhere와 CA 간에 인증을 위한 트러스트를 구축합니다.

1. 그런 다음 기존 IAM 역할을 구성하거나 IAM Roles Anywhere 서비스를 신뢰하는 새 역할을 생성할 수 있습니다.

1. 트러스트 앵커를 사용하여 비AWS 워크로드를 IAM Roles Anywhere에서 인증합니다. AWS에서는 IAM 역할에 비 AWS 워크로드 이미 자격 증명을 부여하고, 이를 통해 AWS 리소스에 액세스할 수 있습니다.

## 추가 리소스
<a name="id_roles_non-aws_additional_resources"></a>

다음 리소스는 비AWS 워크로드에 대한 액세스 제공에 대해 알아보는 데 도움이 될 수 있습니다.
+ IAM Roles Anywhere 구성에 대한 자세한 내용은 *IAM Roles Anywhere 사용 설명서*의 [AWS Identity and Access Management Roles Anywhere란 무엇입니까?](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)를 참조하세요.
+ IAM Roles Anywhere에서 퍼블릭 키 인프라(PKI)를 설정하는 방법을 알아보려면 **AWS 보안 블로그에서 [IAM Roles Anywhere with an external certificate authority](https://aws.amazon.com/blogs/)의 내용을 참조하세요.

# 타사가 소유한 AWS 계정에 액세스
<a name="id_roles_common-scenarios_third-party"></a>

타사가 조직의 AWS 리소스에 액세스해야 하는 경우 역할을 사용하여 해당 사용자에게 그에 대한 액세스 권한을 위임할 수 있습니다. 예를 들어, 타사가 AWS 리소스를 관리하는 서비스를 제공할 경우 IAM 역할을 사용하면 AWS 보안 자격 증명을 공유하지 않고 해당 타사에 AWS 리소스에 액세스할 수 있는 권한을 부여할 수 있습니다. 대신 타사는 귀하의 AWS 계정에 만든 역할로 가장하여 귀하의 AWS 리소스에 액세스할 수 있습니다. 해당 신뢰 영역(신뢰할 수 있는 조직 또는 계정) 외의 계정 내 보안 주체가 역할을 수임하는 권한이 있는지 자세히 알고 싶다면 [IAM Access Analyzer란 무엇인가요?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)를 참조하세요.

해당 사용자가 수임할 수 있는 역할을 생성하려면 타사가 다음 정보를 제공해야 합니다.
+ **타사의 AWS 계정 ID**. 역할에 대한 신뢰 정책을 정의할 때 AWS 계정 ID를 보안 주체로 지정합니다.
+ **역할을 고유하게 연결하는 데 사용하는 외부 ID**. 외부 ID는 여러분과 타사만이 알고 있는 임의의 식별자일 수 있습니다. 예를 들어, 여러분과 타사가 사용하는 인보이스 ID를 사용할 수 있지만 타사의 이름이나 전화번호와 같이 추측 가능한 것은 사용하지 마세요. 역할에 대한 신뢰 정책을 정의할 때 이 ID를 지정해야 합니다. 타사가 역할을 수임할 때 이 ID를 제공해야 합니다.
+ **AWS 리소스를 사용하기 위해 타사에 필요한 권한**. 역할의 권한 정책을 정의할 때 이러한 권한을 지정해야 합니다. 이 정책은 타사에서 수행할 수 있는 작업과 액세스할 수 있는 리소스를 정의합니다.

역할을 정의한 후에는 역할의 Amazon 리소스 이름(ARN)을 타사에 제공해야 합니다. 타사가 역할을 수임하려면 해당 역할의 ARN이 필요합니다.

**중요**  
타사에 AWS 리소스에 대한 액세스 권한을 부여하는 경우 타사는 여러분이 정책에서 지정하는 모든 리소스에 액세스할 수 있습니다. 타사의 리소스 사용에 대해서는 여러분에게 과금됩니다. 타사의 리소스 사용을 적절하게 제한해야 합니다.

## 타사 액세스를 위한 외부 ID
<a name="id_roles_third-party_external-id"></a>

외부 ID는 그 역할을 위임하고 있는 사용자가 자신이 활동하고 있는 상황을 어설션할 수 있도록 허용합니다. 또한, 계정 소유자가 특정 상황에서만 역할이 위임되도록 허용할 수 있는 방법을 제공합니다. 외부 ID의 주된 기능은 [혼동된 대리자 문제](confused-deputy.md)를 해결하고 방지하는 것입니다.

**중요**  
AWS는 외부 ID를 비밀로 취급하지 않습니다. AWS에서 액세스 키 페어 또는 암호와 같은 비밀 정보를 만든 후에는 다시 볼 수 없습니다. 역할의 외부 ID는 해당 역할을 볼 수 있는 권한을 가진 사람만 볼 수 있습니다.

## 언제 외부 ID를 사용해야 하나요?
<a name="external-id-use"></a>

다음 상황에서 외부 ID를 사용합니다.
+ AWS 계정 소유자가 자신의 계정뿐 아니라 다른 AWS 계정에도 액세스하는 타사를 위한 역할을 구성했습니다. 이 경우 타사에 역할을 위임할 때 포함하는 외부 ID를 요청해야 합니다. 그런 다음 역할의 신뢰 정책에서 외부 ID를 확인합니다. 이렇게 하여 외부 사용자를 대신해서 수행하는 경우에만 역할을 맡을 수 있도록 해야 합니다.
+ 이전 시나리오의 Example Corp와 같은 다른 고객을 대신하여 역할을 위임할 수 있습니다. 각 고객에게 고유한 외부 ID를 할당하고 외부 ID를 역할의 신뢰 정책에 추가하도록 지시해야 합니다. 그런 다음 역할 위임 요청에 정확한 외부 ID를 항상 포함하도록 해야 합니다.

  각 고객에 대한 고유한 식별자를 이미 갖고 있겠지만, 이 고유 ID는 외부 ID로 사용하기에 충분합니다. 외부 ID는 단지 이러한 목적을 위해 명시적으로 생성하거나 별도로 추적할 필요가 있는 특별한 값은 아닙니다.

  외부 ID는 항상 `AssumeRole` API 호출에 지정해야 합니다. 이 밖에도 고객이 역할 ARN을 부여할 때 정확한 외부 ID가 있든 없든 그 역할을 위임할 수 있는지 확인하세요. 정확한 외부 ID 없이 역할을 위임할 수 있는 경우 시스템에 고객의 역할 ARN을 저장하지 마세요. 고객이 정확한 외부 ID를 요구하도록 역할 신뢰 정책을 업데이트할 때까지 기다립니다. 이러한 방식으로 고객이 올바른 일을 할 수 있도록 돕고, 이는 양자 모두 혼동된 대리자 문제에서 보호받는 데 도움이 됩니다.

## 외부 ID를 사용하는 예제 시나리오
<a name="id_roles_third-party_example"></a>

예를 들어 Example Corp이라는 타사를 고용해 AWS 계정을 모니터링하고 비용을 최적화하기로 했다고 가정해봅시다. 일일 경비를 추적하기 위해 Example Corp은 AWS 리소스에 접근해야 합니다. Example Corp 역시 다른 고객을 위해 다른 많은 AWS 계정을 모니터링합니다.

AWS 계정의 IAM 사용자 및 해당 장기 자격 증명에 대한 액세스 권한을 Example Corp에게 제공하지 마세요. 대신 IAM 역할과 임시 보안 자격 증명을 사용합니다. IAM 역할은 장기 보안 인증(IAM 사용자 액세스 키 등)을 공유하지 않고도 AWS 리소스에 액세스할 수 있도록 허용하는 메커니즘을 타사에 제공합니다.

IAM 역할을 사용하여 AWS 계정과 Example Corp 계정 사이에 신뢰 관계를 설정할 수 있습니다. 이 관계가 설정된 후 Example Corp 계정의 멤버는 AWS Security Token Service [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API를 호출하여 임시 보안 자격 증명을 얻을 수 있습니다. Example Corp 멤버는 자격 증명을 사용하여 계정의 AWS 리소스에 액세스할 수 있습니다.

**참고**  
임시 보안 자격 증명을 얻기 위해 호출할 수 있는 AssumeRole 및 다른 AWS API 작업에 대한 자세한 내용은 다음([AWS STS 자격 증명 비교](id_credentials_sts-comparison.md))을 참조하세요.

이 시나리오에 대한 더 자세한 분석은 다음과 같습니다.

1. Example Corp을 고용해 고유한 사용자 지정 식별자를 생성하도록 합니다. 이 고유 고객 ID와 AWS 계정 번호를 제공합니다. 이 정보는 다음 단계에서 IAM 역할을 생성하는 데 필요합니다.
**참고**  
이 식별자가 Example Corp의 각 고객에게 고유한 것이라면 Example Corp는 ExternalId에 대해 그들이 원하는 어떤 문자열 값이라도 사용할 수 있습니다. 두 고객이 같은 값을 갖지 않는 한, 고객 계정 번호 또는 임의 문자열이 될 수 있습니다. 이는 '보안 유지'를 위한 것은 아닙니다. Example Corp은 각 고객에게 ExternalId 값을 제공해야 합니다. 가장 중요한 것은 각 외부 ID가 고유하도록, 고객이 ***아닌*** Example Corp이 이 값을 생성해야 한다는 것입니다.

1. AWS에 로그인해 Example Corp에 리소스에 대한 액세스 권한을 부여하는 IAM 역할을 생성합니다. IAM 역할과 마찬가지로 해당 역할에도 권한 정책과 신뢰 정책이라는 두 가지 정책이 있습니다. 그 역할의 신뢰 정책은 역할을 위임할 사용자를 지정합니다. 이 예시 시나리오에서 정책은 Example Corp의 AWS 계정 번호를 `Principal`로 지정합니다. 이렇게 하면 계정의 자격 증명이 그 역할을 수임하도록 허용합니다. 또한, `[Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Condition)` 요소를 신뢰 정책에 추가합니다. 이 `Condition`은 Example Corp의 고유 고객 ID와 일치하는지 확인하기 위해 `ExternalId` 컨텍스트 키를 테스트합니다.

   ```
       "Principal": {"AWS": "Example Corp's AWS 계정 ID"},
       "Condition": {"StringEquals": {"sts:ExternalId": "Unique ID Assigned by Example Corp"}}
   ```

1. 역할에 대한 권한 정책은 해당 역할이 누군가가 수행하도록 허용할 수 있는 작업을 지정합니다. 예를 들어 그 역할은 누군가에게 IAM 사용자나 그룹이 아닌 Amazon EC2 또는 Amazon RDS 리소스만을 관리할 수 있게 허용하도록 지정할 수 있습니다. 이 예시 시나리오에서는 권한 정책을 사용하여 Example Corp에게 계정의 리소스 전체에 대한 읽기 전용 액세스 권한을 부여합니다.

1. 역할을 정의한 후에는 역할의 Amazon 리소스 이름(ARN)을 Example Corp에 제공합니다.

1. Example Corp가 AWS 리소스에 액세스해야 할 때는 그 회사의 누군가가 AWS `sts:AssumeRole` API를 호출합니다. 이 호출에는 수임할 역할의 ARN과 사용자 지정 ID에 해당하는 ExternalId 파라미터가 포함되어 있습니다.

Example Corp의 AWS 계정을 사용하는 사람이 요청하는 경우와 역할 ARN 및 외부 ID가 올바른 경우에 요청이 성공합니다. 그 경우 요청은 역할이 허용하는 AWS 리소스에 액세스하기 위해 Example Corp이 사용할 수 있는 임시 보안 자격 증명을 제공합니다.

다시 말해서 역할 정책에 외부 ID가 포함된다면 그 역할을 수임하고자 하는 사용자는 누구든지 그 역할에서 보안 주체로 지정되어야 하고 정확한 외부 ID를 포함해야 합니다.

## 외부 ID의 요점
<a name="id_roles_third-party_key-points"></a>
+ 서로 다른 AWS 계정을 가진 여러 고객을 지원하는 다중 테넌트 환경에서는 AWS 계정당 하나의 외부 ID를 사용하는 것이 좋습니다. 이 ID는 타사에서 생성한 임의의 문자열이어야 합니다.
+ 역할을 수임할 때 타사에서 외부 ID를 제공하도록 요구하려면 해당 역할의 신뢰 정책을 선택한 외부 ID로 업데이트합니다.
+ 역할을 수임할 때 외부 ID를 제공하려면 AWS CLI 또는 AWS API를 사용하여 해당 역할을 수임합니다. 자세한 내용은 STS [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API 작업 또는 STS [assume-role](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html) CLI 작업을 참조하세요.
+ `ExternalId` 값은 최소 2자, 최대 1,224자여야 합니다. 이 값은 공백 없이 영숫자여야 합니다. 이 값은 더하기(\$1), 등호(=), 쉼표(,) 마침표(.), 기호(@), 콜론(:), 슬래시(/) 및 하이픈(-)과 같은 기호도 포함할 수 있습니다.

## 추가 리소스
<a name="id_roles_third-party_additional_resources"></a>

다음 리소스는 타사 소유의 AWS 계정에 대한 액세스 제공에 대해 알아보는 데 도움이 될 수 있습니다.
+ 다른 사용자가 AWS 계정에서 작업을 수행하도록 허용하는 방법을 알아보려면 [사용자 지정 트러스트 정책을 사용하여 역할 생성](id_roles_create_for-custom.md)의 내용을 참조하세요.
+ 역할로 전환할 수 있는 권한을 부여하는 방법을 알아보려면 [사용자에게 역할을 전환할 권한 부여](id_roles_use_permissions-to-switch.md)의 내용을 참조하세요.
+ 신뢰할 수 있는 사용자를 생성하고 임시 보안 자격 증명을 제공하는 방법을 알아보려면 [임시 보안 자격 증명에 대한 권한](id_credentials_temp_control-access.md)의 내용을 참조하세요.

# AWS 서비스 액세스
<a name="id_roles_common-scenarios_services"></a>

많은 AWS 서비스에서는 역할을 사용하여 해당 서비스가 액세스할 수 있는 대상을 제어해야 합니다. 서비스가 사용자를 대신하여 작업을 수행하기 위해 수임한 역할을 [서비스 역할](id_roles.md#iam-term-service-role)이라고 합니다. 역할이 서비스에 대해 특수한 목적을 수행하는 경우 [서비스 연결 역할](id_roles.md#iam-term-service-linked-role)로 분류될 수 있습니다. 서비스에서 역할을 사용하는지 여부와 서비스에서 사용할 역할을 할당하는 방법을 알아보려면 서비스별 [AWS 문서](https://docs.aws.amazon.com/)를 참조하세요.

역할을 생성해 AWS가 제공하는 서비스에 액세스 권한을 위임하는 것에 대한 자세한 내용은 [AWS 서비스에 대한 권한을 위임할 역할 생성](id_roles_create_for-service.md) 섹션을 참조하세요.

# 외부에서 인증된 사용자에 대한 액세스(ID 페더레이션)
<a name="id_roles_common-scenarios_federated-users"></a>

사용자는 이미 회사 디렉터리 등 AWS 외부에 자격 증명을 보유할 수 있습니다. 그러한 사용자가 AWS 리소스를 사용해야 하는 경우(또는 해당 리소스에 액세스하는 애플리케이션을 사용해야 하는 경우), 해당 사용자에게도 AWS 보안 자격 증명이 필요합니다. 자격 증명이 내 조직 또는 서드 파티 자격 증명 공급자(IdP)에서 페더레이션되는 사용자의 권한을 IAM 역할을 사용하여 지정할 수 있습니다.

**참고**  
보안 모범 사례로서, IAM 사용자를 생성하지 말고, 그 대신 아이덴티티 페더레이션을 사용하여 [IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/what-is.html)에서 사용자 액세스를 관리하는 것이 좋습니다. IAM 사용자가 필요한 특정 상황에 대한 자세한 내용은 [IAM 사용자(역할이 아님)를 생성해야 하는 경우](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose)를 참조하세요.

## Amazon Cognito를 사용하여 모바일 또는 웹 기반 앱 사용자 페더레이션
<a name="id_roles_common-scenarios_federated-users-cognito"></a>

AWS 리소스에 액세스하는 모바일 또는 웹 기반 앱을 생성하는 경우, 이 앱에는 AWS에 프로그래밍 방식으로 요청하기 위해 보안 자격 증명이 필요합니다. 대부분의 모바일 애플리케이션 시나리오의 경우 [Amazon Cognito](https://aws.amazon.com/cognito/) 사용을 권장합니다. 이 서비스와 함께 [AWS Mobile SDK for iOS](https://aws.amazon.com/sdkforios/) 및 [AWS Mobile SDK for Android and Fire OS](https://aws.amazon.com/sdkforandroid/)를 사용하면 사용자의 고유 자격 증명을 생성하고 사용자를 인증하여 AWS 리소스에 안전하게 액세스하도록 할 수 있습니다. Amazon Cognito는 다음 섹션에 나열된 자격 증명 공급자를 지원할 뿐만 아니라 [개발자 인증 자격 증명](https://aws.amazon.com/blogs/mobile/amazon-cognito-announcing-developer-authenticated-identities)과 인증되지 않은(게스트) 액세스까지 지원합니다. 또한, Amazon Cognito는 사용자가 디바이스 간에 이동할 때 데이터가 보존되도록 사용자 데이터를 동기화하기 위한 API 작업도 제공합니다. 자세한 내용은 [모바일 앱용 Amazon Cognito](id_federation_common_scenarios.md#id_roles_providers_oidc_cognito) 섹션을 참조하세요.

## 퍼블릭 자격 증명 서비스 공급자 또는 OpenID Connect를 사용하여 사용자 페더레이션
<a name="id_roles_common-scenarios_federated-users-openId"></a>

가능하면 항상 모바일 및 웹 기반 애플리케이션 시나리오에 Amazon Cognito를 사용합니다. Amazon Cognito는 퍼블릭 자격 증명 공급자 서비스를 통해 대부분의 백그라운드 작업을 수행합니다. 동일한 타사 서비스를 사용하며 익명 로그인을 지원하기도 합니다. 그러나 고급 시나리오의 경우에는 Login with Amazon, Facebook, Google, 또는 OpenID Connect(OIDC)와 호환되는 모든 IdP로 직접 작업할 수 있습니다. 이들 서비스 중 한 가지를 이용한 OIDC 페더레이션에 대한 자세한 내용은 [OIDC 페더레이션](id_roles_providers_oidc.md) 항목을 참조하세요.

## SAML 2.0으로 사용자 연동하기
<a name="id_roles_common-scenarios_federated-users-saml20"></a>

조직에서 SAML 2.0(Security Assertion Markup Language 2.0)을 지원하는 자격 증명 공급자 소프트웨어 패키지를 이미 사용하는 경우 IdP(자격 증명 공급자)인 조직과 서비스 공급자인 AWS 간에 신뢰를 형성할 수 있습니다. 그러면 SAML을 사용하여 사용자에게 AWS Management Console에 대한 연동 SSO(Single-Sing On) 또는 AWS API 작업을 호출하기 위한 페더레이션 액세스를 제공할 수 있습니다. 예를 들어 회사가 Microsoft Active Directory와 Active Directory Federation Services를 이용한다면, SAML 2.0을 사용해 연동할 수 있습니다. SAML 2.0를 이용한 사용자 연동에 대한 세부 정보는 [SAML 2.0 연동](id_roles_providers_saml.md)을 참조하세요.

## 사용자 지정 자격 증명 브로커 애플리케이션 생성에 의한 사용자 연동
<a name="id_roles_common-scenarios_federated-users-idbroker"></a>

자격 증명 스토어가 SAML 2.0과 호환되지 않는다면, 사용자 지정 자격 증명 브로커 애플리케이션을 구축해 비슷한 기능을 수행할 수 있습니다. 브로커 애플리케이션이 사용자를 인증하고, AWS에게 사용자를 위한 임시 자격 증명을 요청한 다음, 이를 사용자에게 제공해 AWS 리소스에 액세스하도록 합니다.

예를 들어 Example Corp.에 회사의 AWS 리소스에 액세스하는 내부 애플리케이션을 실행해야 하는 직원들이 많다고 합시다. 직원들은 이미 회사 자격 증명 및 인증 시스템에 자격 증명이 있어서 Example Corp는 각 직원의 IAM 사용자를 별도로 생성하길 원하지 않습니다.

Bob은 Example Corp의 개발자입니다. Example Corp 내부 애플리케이션에서 회사의 AWS 리소스에 액세스하도록 하기 위해 Bob은 사용자 지정 자격 증명 브로커 애플리케이션을 개발합니다. 그 애플리케이션은 직원들이 기존 Example Corp. 자격 증명 및 인증 시스템에 로그인된 상태인지 확인하는데, 그 시스템은 LDAP, Active Directory, 또는 다른 시스템을 사용할 수 있습니다. 그 다음에 자격 증명 브로커 애플리케이션은 직원들에 대한 임시 보안 자격 증명을 획득합니다. 이 시나리오는 이전 시나리오(사용자 지정 인증 시스템을 사용하는 모바일 앱)과 유사합니다. 단지 AWS 리소스에 액세스해야 하는 애플리케이션이 모두 회사 네트워크 내에서 실행되고 회사에 기존 인증 시스템이 있다는 점만 다릅니다.

임시 보안 자격 증명을 얻기 위해 자격 증명 브로커 애플리케이션은 밥(Bob)이 사용자들에 대한 정책을 어떻게 관리하고자 하는지, 그리고 임시 자격 증명이 언제 만료되는지에 따라 `AssumeRole` 또는 `GetFederationToken`을 호출해 임시 보안 자격 증명을 획득합니다. (이러한 API 작업 간의 차이점을 보려면 [IAM의 임시 보안 자격 증명](id_credentials_temp.md) 및 [임시 보안 자격 증명에 대한 권한](id_credentials_temp_control-access.md)를 참조하세요.) 호출은 AWS 액세스 키 ID, 보안 액세스 키, 세션 토큰으로 구성된 임시 보안 자격 증명을 반환합니다. 자격 증명 브로커 애플리케이션은 이 임시 보안 자격 증명을 내부 회사 애플리케이션에서도 사용할 수 있게 해줍니다. 그 앱은 그 임시 자격 증명을 사용해 AWS를 직접 호출할 수 있습니다. 그 앱은 자격 증명이 만료될 때까지 캐싱한 다음, 새로운 일련의 임시 자격 증명을 요청합니다. 다음은 이 시나리오를 설명한 그림입니다.

![\[사용자 지정 자격 증명 브로커 애플리케이션을 사용하는 샘플 워크플로우\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/enterprise-authentication-with-identity-broker-application.diagram.png)


이 시나리오에는 다음과 같은 속성이 있습니다.
+ 자격 증명 브로커 애플리케이션은 IAM의 보안 토큰 서비스(STS) API에 액세스하여 임시 보안 자격 증명을 생성할 수 있는 권한이 있습니다.
+ 신원 증명 브로커 애플리케이션을 통해 기존 인증 시스템 내에서 직원이 인증되었는지 확인할 수 있습니다.
+ 사용자는 AWS 관리 콘솔에 대한 액세스 권한을 제공하는 임시 URL(Single Sign-On이라고 함)을 가져올 수 있습니다.

임시 보안 자격 증명 생성에 대한 자세한 내용은 [AWS STS 자격 증명 비교](id_credentials_sts-comparison.md)를 참조하세요 . AWS 관리 콘솔에 대한 액세스 권한을 얻는 SAML 페더레이션 보안 주체에 대한 자세한 내용은 [SAML 2.0 페더레이션 위탁자의 AWS Management Console 액세스 활성화](id_roles_providers_enable-console-saml.md) 섹션을 참조하세요.

# IAM 역할 생성
<a name="id_roles_create"></a>

역할을 생성하려면 AWS Management Console, AWS CLI, Tools for Windows PowerShell 또는 IAM API를 사용할 수 있습니다.

AWS Management Console을 사용하는 경우 마법사가 역할 생성 절차를 단계별로 안내합니다. 마법사의 진행 단계는 생성하는 역할 대상이 AWS 서비스일 때, AWS 계정일 때, 혹은 SAML 또는 OIDC 페더레이션 보안 주체일 때에 따라 약간 다릅니다.

**IAM 사용자 역할**  
이 역할을 생성하여 AWS 계정 내에 또는 소유하고 있는 다른 AWS 계정에 정의된 역할에 권한을 위임합니다. 한 계정의 사용자는 동일한 또는 다른 계정의 역할로 전환할 수 있습니다. 사용자는 역할을 사용하는 동안 해당 작업만을 수행하고 해당 역할에서 허용한 리소스만 액세스할 수 있지만, 이들의 원래 사용자 권한은 일시 중지된 상태입니다. 사용자가 역할을 끝내면 원래 사용자 권한이 회복됩니다.

자세한 내용은 [IAM 사용자에게 권한을 부여할 역할 생성](id_roles_create_for-user.md) 섹션을 참조하세요.

크로스 계정 액세스 역할 생성에 대한 자세한 내용은 [사용자 지정 트러스트 정책을 사용하여 역할 생성](id_roles_create_for-custom.md)의 내용을 참조하세요.

**AWS 서비스 역할**  
이 역할을 생성하여 사용자 대신 작업을 수행할 권한을 부여하는 역할을 서비스에 위임합니다. 서비스에 전달하는 [서비스 역할](id_roles.md#iam-term-service-role)에는 서비스가 해당 서비스와 연결된 작업을 수행할 수 있도록 허용하는 권한이 포함된 IAM 정책이 있어야 합니다. 각 AWS 서비스마다 서로 다른 권한이 필요합니다.

서비스 역할 생성에 대한 자세한 내용은 [AWS 서비스에 대한 권한을 위임할 역할 생성](id_roles_create_for-service.md)의 내용을 참조하세요.

서비스 연결 역할 생성에 대한 자세한 내용은 [서비스 연결 역할 생성](id_roles_create-service-linked-role.md)의 내용을 참조하세요.

**ID 페더레이션 역할**  
이 역할을 생성하여 AWS 외부에 이미 ID가 있는 사용자에게 권한을 위임합니다. 자격 증명 공급자를 사용하면 사용자 지정 로그인 코드를 생성할 필요도, 그리고 자신의 사용자 자격 증명을 관리할 필요도 없습니다. 외부 사용자는 IdP를 통해 로그인하고, 이러한 외부 자격 증명에 계정의 AWS 리소스를 사용할 권한을 제공할 수 있습니다. ID 제공업체를 사용하면 애플리케이션에서 사용자 액세스 키 같은 장기 보안 자격 증명을 배포하거나 포함할 필요가 없으므로 AWS 계정을 안전하게 보호할 수 있습니다.

자세한 내용은 [타사 ID 공급자에 대한 역할 생성](id_roles_create_for-idp.md) 섹션을 참조하세요.

# IAM 사용자에게 권한을 부여할 역할 생성
<a name="id_roles_create_for-user"></a>

IAM 역할을 사용해 AWS 리소스에 대한 액세스 권한을 제공할 수 있습니다. IAM 역할을 사용해 *신뢰하는* 계정과 다른 AWS *신뢰받는* 계정 간에 신뢰 관계를 설정할 수 있습니다. 신뢰하는 계정은 액세스되는 리소스를 소유하고 신뢰받는 계정은 리소스에 대한 액세스가 필요한 사용자를 저장합니다. 그러나, 다른 계정이 해당 계정의 리소스를 소유할 수 있는 가능성이 있습니다. 예를 들어, 신뢰받는 계정은 신뢰 계정이 Amazon S3 버킷의 새로운 객체를 생성하는 것처럼 새로운 리소스를 생성하도록 허용할 수 있습니다. 이러한 경우, 리소스를 생성하는 계정은 리소스를 소유하고 누구에게 리소스에 대한 액세스를 부여할지 제어합니다.

신뢰 관계를 생성한 후 신뢰받는 계정의 IAM 사용자 또는 애플리케이션은 AWS Security Token Service(AWS STS) [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API 작업을 사용할 수 있습니다. 이 작업은 계정의 AWS 리소스에 액세스할 수 있는 임시 보안 자격 증명을 제공합니다.

계정은 둘 다 직접 제어할 수 있거나 사용자가 속한 계정의 경우 타사가 제어할 수 있습니다. 사용자가 있는 다른 계정이 귀하가 제어하지 않는 AWS 계정에 있는 경우 `externalId` 속성을 사용할 수 있습니다. 외부 ID는 나와 서드 파티 계정의 관리자 간에 합의한 숫자 또는 단어가 될 수 있습니다. 이 옵션은 요청에 올바른 `sts:ExternalID`가 포함된 경우에만 사용자가 역할을 맡을 수 있도록 허용하는 조건을 신뢰 정책에 자동으로 추가합니다. 자세한 내용은 [타사가 소유한 AWS 계정에 액세스](id_roles_common-scenarios_third-party.md) 섹션을 참조하세요.

역할을 사용해 권한을 위임하는 방법에 대한 자세한 내용은 [역할 용어 및 개념](id_roles.md#id_roles_terms-and-concepts) 섹션을 참조하세요. 서비스 연결을 사용하여 서비스가 해당 계정의 리소스에 액세스할 수 있도록 허용하는 방법은 [AWS 서비스에 대한 권한을 위임할 역할 생성](id_roles_create_for-service.md) 섹션을 참조하세요.

## IAM 역할 생성(콘솔)
<a name="roles-creatingrole-user-console"></a>

AWS Management Console을 사용하여 IAM 사용자가 수임할 수 있는 역할을 생성할 수 있습니다. 예를 들면 프로덕션 환경에서 개발 환경을 격리하기 위해 조직이 여러 개의 AWS 계정을 갖고 있다고 가정합시다. 개발 계정의 사용자가 프로덕션 계정의 리소스에 액세스할 수 있도록 하는 역할 생성에 대한 개괄적 정보는 [분리된 개발 및 프로덕션 계정을 사용한 예제 시나리오](id_roles_common-scenarios_aws-accounts.md#id_roles_common-scenarios_aws-accounts-example) 섹션을 참조하세요.

**최소 권한**  
다음 단계를 수행하려면 적어도 다음과 같은 IAM 권한이 있어야 합니다.  
`access-analyzer:ValidatePolicy`
`iam:AttachRolePolicy`
`iam:CreatePolicy`
`iam:CreateRole`
`iam:GetAccountSummary`
`iam:GetPolicy`
`iam:GetPolicyVersion`
`iam:GetRole`
`iam:ListAccountAliases`
`iam:ListAttachedRolePolicies`
`iam:ListOpenIDConnectProviders`
`iam:ListPolicies`
`iam:ListRolePolicies`
`iam:ListRoles`
`iam:ListRoleTags`
`iam:ListSAMLProviders`

------
#### [ Console ]

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 콘솔의 탐색 창에서 **역할**을 선택한 후 **역할 생성**을 선택합니다.

1. **AWS 계정** 역할 유형을 선택합니다.

1. 계정에 대한 역할을 생성하려면 **이 계정(This account)**을 선택합니다. 다른 계정에 대한 역할을 생성하려면 **다른 AWS 계정**을 선택하고 리소스에 대한 액세스 권한을 부여할 **계정 ID**를 입력합니다.

   지정된 계정의 관리자는 해당 계정의 IAM 사용자에게 이 역할을 수임할 수 있는 권한을 부여할 수 있습니다. 이를 위해 관리자는 `sts:AssumeRole` 작업에 대한 권한을 부여하는 정책을 사용자나 그룹에 연결합니다. 이 정책은 역할의 ARN을 `Resource`로 지정해야 합니다.

1. 통제권이 없는 계정의 사용자에게 권한을 부여하려면 사용자는 이 역할을 프로그래밍 방식으로 가정하고 **외부 ID 필요(Require external ID)**를 선택합니다. 외부 ID는 나와 서드 파티 계정의 관리자 간에 합의한 숫자 또는 단어가 될 수 있습니다. 이 옵션은 요청에 올바른 `sts:ExternalID`가 포함된 경우에만 사용자가 역할을 맡을 수 있도록 허용하는 조건을 신뢰 정책에 자동으로 추가합니다. 자세한 내용은 [타사가 소유한 AWS 계정에 액세스](id_roles_common-scenarios_third-party.md) 섹션을 참조하세요.
**중요**  
이 옵션을 선택하면 역할로의 액세스가 AWS CLI, Tools for Windows PowerShell 또는 AWS API를 통해서만 가능하도록 제한됩니다. 이는 AWS 콘솔을 사용해 해당 신뢰 정책에 `externalId` 조건이 있는 역할로 전환할 수 없기 때문입니다. 하지만 관련 SDK를 통해 스크립트나 애플리케이션을 작성하여 프로그래밍 방식으로 이러한 종류의 액세스를 만들 수 있습니다. 자세한 내용 및 샘플 스크립트는 AWS 보안 블로그의 [AWS Management Console에 대한 크로스 계정 액세스를 가능하게 하는 방법](https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console)을 참조하세요.

1. 멀티 팩터 인증(MFA)으로 로그인하는 사용자로 역할을 제한하려면, **Require MFA(MFA 필요)**를 선택합니다. 이렇게 하면 MFA 로그인을 확인하는 역할의 신뢰 정책에 조건이 추가됩니다. 역할을 맡으려는 사용자는 구성된 MFA 디바이스에서 임시 일회용 암호로 로그인해야 합니다. MFA 인증을 사용하지 않는 사용자는 역할을 맡을 수 없습니다. MFA에 대한 자세한 내용은 [IAM의 AWS 다중 인증](id_credentials_mfa.md) 섹션을 참조하세요.

1. **다음**을 선택합니다.

1. IAM은 계정의 AWS 관리형 또는 고객 관리형 정책 목록을 포함합니다. 권한 정책을 사용하기 위한 정책을 선택하거나 **정책 생성**을 선택하여 새 브라우저 탭을 열고 완전히 새로운 정책을 생성합니다. 자세한 내용은 [IAM 정책 생성](access_policies_create-console.md#access_policies_create-start) 섹션을 참조하세요. 정책을 생성하면 탭을 닫고 원래 탭으로 돌아갑니다. 역할을 위임하려는 대상에 제공할 권한 정책 옆의 확인란을 선택하세요. 원할 경우, 여기서 정책을 선택하지 않고 나중에 정책을 만들어서 역할에 연결할 수 있습니다. 기본적으로 역할은 권한이 없습니다.

1. (선택 사항) [권한 경계](access_policies_boundaries.md)를 선택합니다. 이는 고급 기능입니다.

   **권한 경계 설정** 섹션을 열고 **최대 역할 권한을 관리하기 위한 권한 경계 사용**을 선택합니다. 정책을 선택하여 권한 경계를 사용합니다.

1. **다음**을 선택합니다.

1. **역할 이름**에 역할의 이름을 입력합니다. 역할 이름은 AWS 계정 내에서 고유해야 합니다. 역할 이름이 정책에서 또는 ARN의 일부로 사용되는 경우 역할 이름은 대소문자를 구분합니다. 콘솔에서 고객에게 역할 이름이 표시되는 경우(예: 로그인 프로세스 중) 역할 이름은 대소문자를 구분하지 않습니다. 다양한 엔터티가 역할을 참조할 수 있기 때문에 역할이 생성된 후에는 역할 이름을 편집할 수 없습니다.

1. (선택 사항)**설명**에 새 역할에 대한 설명을 입력합니다.

1. **1단계: 신뢰할 수 있는 엔터티 선택(Step 1: Select trusted entities)** 또는 **2단계: 권한 추가(Step 2: Add permissions)** 섹션에서 **편집(Edit)**을 선택하여 역할에 대한 사용 사례와 권한을 편집합니다. 편집을 위해 이전 페이지로 돌아갑니다.

1. (선택 사항) 태그를 키 값 페어로 연결하여 메타데이터를 역할에 추가합니다. IAM에서의 태그 사용에 대한 자세한 내용은 [AWS Identity and Access Management 리소스용 태그](id_tags.md) 섹션을 참조하세요.

1. 역할을 검토한 다음 **역할 생성**을 선택합니다.
**중요**  
필요한 구성의 절반이 끝났습니다. 이제 신뢰할 수 있는 계정의 개별 사용자에게 콘솔의 역할로 전환하거나 역할을 프로그래밍 방식으로 위임할 수 있는 권한을 부여해야 합니다. 이 단계에 대한 자세한 내용은 [사용자에게 역할을 전환할 권한 부여](id_roles_use_permissions-to-switch.md) 섹션을 참조하세요.

------

## IAM 역할 생성(AWS CLI)
<a name="roles-creatingrole-user-cli"></a>

AWS CLI에서 역할을 만들려면 여러 단계를 거쳐야 합니다. 콘솔을 사용하여 역할을 만들 때는 많은 단계가 자동으로 수행되지만 AWS CLI를 사용하면 각 단계를 직접 명시적으로 수행해야 합니다. 역할을 만든 다음 권한 정책을 역할에 할당해야 합니다. 선택적으로 역할에 대한 [권한 경계](access_policies_boundaries.md)를 설정할 수 있습니다.

**크로스 계정 액세스에 대한 역할을 만들려면(AWS CLI)**

1. 역할 생성: [aws iam create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html)

1. 역할에 관리형 권한 정책 연결: [aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html)

    또는

   역할을 위한 인라인 권한 정책 생성: [aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html)

1. (선택 사항) 태그를 연결하여 사용자 지정 속성을 역할에 추가: [aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html)

   자세한 내용은 [IAM 역할의 태그 관리(AWS CLI 또는 AWS API)](id_tags_roles.md#id_tags_roles_procs-cli-api) 섹션을 참조하세요.

1. (선택 사항) 역할([aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html))에 대한 [권한 경계](access_policies_boundaries.md)를 설정합니다.

   이 권한 경계는 역할이 가질 수 있는 최대 권한을 관리합니다. 권한 경계는 고급 AWS 기능입니다.

다음 예는 단순한 환경에서 크로스 계정 역할을 생성하는 가장 일반적인 단계 중 첫 두 단계를 보여줍니다. 이 예제는 `123456789012` 계정에 있는 모든 사용자가 역할을 수임하고 `example_bucket` Amazon S3 버킷을 볼 수 있도록 허용합니다. 이 예제에서도 Windows가 구동되는 클라이언트 컴퓨터를 사용 중이며 명령줄 인터페이스를 계정 자격 증명 및 리전으로 이미 구성했다고 가정합니다. 자세한 내용은 [AWS 명령줄 인터페이스 구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)을 참조하세요.

이 예제는 역할을 생성할 경우 첫 번째 명령의 다음 신뢰 정책을 포함합니다. 이 신뢰 정책은 `123456789012` 계정에서 사용자가 `AssumeRole` 작업을 사용하여 역할을 가정할 수 있도록 허용합니다. 단, 사용자가 `SerialNumber` 및 `TokenCode` 파라미터를 사용하는 MFA 인증을 제공하는 경우에만 허용합니다. MFA에 대한 자세한 내용은 [IAM의 AWS 다중 인증](id_credentials_mfa.md) 섹션을 참조하세요.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
      {
          "Effect": "Allow",
          "Principal": { "AWS": "arn:aws:iam::123456789012:root" },
          "Action": "sts:AssumeRole",
          "Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }
      }
  ]
}
```

------

**중요**  
`Principal` 요소에 특정 IAM 역할 또는 사용자에 대한 ARN이 포함되어 있으면, 정책을 저장할 때 해당 ARN이 고유 보안 주체 ID로 변환됩니다. 그러면 누군가가 해당 역할 또는 사용자를 제거하고 다시 만들어 본인의 권한을 에스컬레이션할 위험을 완화할 수 있습니다. 일반적으로 콘솔에서는 이 ID가 보이지 않습니다. 신뢰 정책이 표시될 때 해당 ARN으로 다시 역변환되기 때문입니다. 그러나 역할 또는 사용자를 삭제할 경우, 보안 주체 ID가 콘솔에 표시됩니다. AWS에서 더 이상 이를 ARN에 다시 매핑할 수 없기 때문입니다. 따라서 신뢰 정책의 `Principal` 요소에서 참조된 사용자 또는 역할을 삭제하고 다시 생성하는 경우, ARN을 바꾸도록 역할을 편집해야 합니다.

두 번째 명령을 사용할 경우, 기존 관리형 정책을 역할에 연결해야 합니다. 다음 권한 정책에서는 역할을 수임하는 사용자가 `example_bucket` Amazon S3 버킷에서 `ListBucket` 작업만 수행하도록 허용합니다.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
      {
          "Effect": "Allow",
          "Action": "s3:ListBucket",
          "Resource": "arn:aws:s3:::example_bucket"
      }
  ]
}
```

------

이 `Test-UserAccess-Role` 역할을 생성하기 위해서는 이전 신뢰 정책을 `trustpolicyforacct123456789012.json` 이름으로 로컬 `policies` 드라이브의 `C:` 폴더에 먼저 저장해야 합니다. 그런 다음 이전 권한 정책을 고객 관리형 정책으로서 `PolicyForRole` 이름으로 AWS 계정에 저장합니다. 그러고 나면 다음 명령을 사용하여 역할을 만들고 관리형 정책을 연결합니다.

```
# Create the role and attach the trust policy file that allows users in the specified account to assume the role.
$ aws iam create-role --role-name Test-UserAccess-Role --assume-role-policy-document file://C:\policies\trustpolicyforacct123456789012.json

# Attach the permissions policy (in this example a managed policy) to the role to specify what it is allowed to do.
$ aws iam attach-role-policy --role-name Test-UserAccess-Role --policy-arn arn:aws:iam::123456789012:policy/PolicyForRole
```

**중요**  
필요한 구성의 절반이 끝났습니다. 이제 신뢰할 수 있는 계정의 개별 사용자에게 역할로 전환할 수 있는 권한을 부여해야 합니다. 이 단계에 대한 자세한 내용은 [사용자에게 역할을 전환할 권한 부여](id_roles_use_permissions-to-switch.md) 섹션을 참조하세요.

역할을 만든 다음 AWS 작업을 수행하거나 AWS 리소스에 액세스할 수 있는 권한을 부여해야 `123456789012` 계정의 사용자가 역할을 위임할 수 있습니다. 자세한 내용은 [IAM 역할로 전환(AWS CLI)](id_roles_use_switch-role-cli.md) 섹션을 참조하세요.

## IAM 역할 생성(AWS API)
<a name="roles-creatingrole-user-api"></a>

AWS API에서 역할을 만들려면 여러 단계를 거쳐야 합니다. 콘솔을 사용하여 역할을 만들 때는 많은 단계가 자동으로 수행되지만 API를 사용하면 각 단계를 직접 명시적으로 수행해야 합니다. 역할을 만든 다음 권한 정책을 역할에 할당해야 합니다. 선택적으로 역할에 대한 [권한 경계](access_policies_boundaries.md)를 설정할 수 있습니다.

**코드로 역할을 만들려면(AWS API)**

1. 역할 만들기: [CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html)

   역할의 신뢰 정책에 대해 파일 위치를 지정할 수 있습니다.

1. 역할에 관리형 권한 정책 연결: [AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html)

   또는

   역할을 위한 인라인 권한 정책 생성: [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html)
**중요**  
필요한 구성의 절반이 끝났습니다. 이제 신뢰할 수 있는 계정의 개별 사용자에게 역할로 전환할 수 있는 권한을 부여해야 합니다. 이 단계에 대한 자세한 내용은 [사용자에게 역할을 전환할 권한 부여](id_roles_use_permissions-to-switch.md) 섹션을 참조하세요.

1. (선택 사항) 태그를 연결하여 사용자 지정 속성을 사용자에게 추가: [TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html)

   자세한 내용은 [IAM 사용자의 태그 관리(AWS CLI 또는 AWS API)](id_tags_users.md#id_tags_users_procs-cli-api) 섹션을 참조하세요.

1. (선택 사항) 역할([PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html))에 대한 [권한 경계](access_policies_boundaries.md)를 설정합니다.

   이 권한 경계는 역할이 가질 수 있는 최대 권한을 관리합니다. 권한 경계는 고급 AWS 기능입니다.

역할을 만든 다음 AWS 작업을 수행하거나 AWS 리소스에 액세스할 수 있는 권한을 부여해야 계정의 사용자에게 권한을 부여하여 역할을 위임할 수 있습니다. 역할 위임하기에 대한 자세한 내용은 [IAM 역할로 전환(AWS API)](id_roles_use_switch-role-api.md) 섹션을 참조하세요.

## IAM 역할 생성(AWS CloudFormation)
<a name="roles_creatingrole-user-cloudformation"></a>

AWS CloudFormation에서 IAM 역할을 생성하는 방법에 대한 자세한 내용은 *AWS CloudFormation 사용 설명서*의 [리소스 및 속성 참조](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html)와 [예제](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html#aws-resource-iam-role--examples)를 참조하세요.

AWS CloudFormation의 IAM 템플릿에 관한 자세한 정보는 *AWS CloudFormation 사용 설명서*의 [AWS Identity and Access Management 템플릿 코드 조각](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/quickref-iam.html)을 참조하세요.

# AWS 서비스에 대한 권한을 위임할 역할 생성
<a name="id_roles_create_for-service"></a>

AWS 서비스는 역할을 사용하여 서비스가 사용자를 대신하여 다른 서비스의 리소스로 액세스할 수 있어야 합니다. 서비스가 사용자를 대신하여 작업을 수행하기 위해 수임한 역할을 [서비스 역할](id_roles.md#iam-term-service-role)이라고 합니다. 역할이 서비스에 대해 특수한 목적을 수행하는 경우 [서비스 연결 역할](id_roles.md#iam-term-service-linked-role)로 분류됩니다. 서비스 연결 역할을 사용하여 지원되는 서비스 또는 서비스가 임시 자격 증명의 형식을 지원하는지 여부를 확인하려면 [AWS IAM으로 작업하는 서비스](reference_aws-services-that-work-with-iam.md) 섹션을 참조하세요. 개별 서비스가 역할을 사용하는 방법을 알아보려면 테이블에서 서비스 이름을 선택하여 해당 서비스의 설명서를 확인합니다.

`PassRole` 권한을 설정할 때 사용자에게 부여하려는 역할보다 더 많은 권한이 있는 역할을 사용자가 넘기지 않도록 해야 합니다. 예를 들어 Alice가 Amazon S3 작업을 수행하는 것이 허용되지 않을 수 있습니다. Alice가 Amazon S3 작업을 허용하는 서비스에 역할을 넘길 수 있으면 해당 서비스에서 작업 실행 시 Alice를 대신하여 Amazon S3 작업을 수행할 수 있습니다.

역할을 통해 권한을 위임하는 방법에 대한 자세한 내용은 [역할 용어 및 개념](id_roles.md#id_roles_terms-and-concepts) 섹션을 참조하세요.

## 서비스 역할 권한
<a name="id_roles_create_service-permissions"></a>

IAM 엔터티(사용자 또는 역할)가 서비스 연결 역할을 작성하거나 편집할 수 있도록 권한을 구성해야 합니다.

**참고**  
서비스 연결 역할의 ARN에는 다음 정책에 `SERVICE-NAME.amazonaws.com`으로 표시된 서비스 보안 주체가 포함됩니다. 서비스 보안 주체는 대소문자를 구분하고 AWS 서비스마다 형식이 다를 수 있으므로 추측하지 마세요. 서비스의 보안 주체를 보려면 해당 서비스 링크된 역할 설명서 섹션을 참조하세요.

**IAM 엔터티가 특정 서비스 역할을 생성하도록 허용하려면**

서비스 역할을 생성해야 하는 IAM 엔터티에 다음 정책을 추가합니다. 이 정책으로 특정 서비스에 대하여 구체적인 이름이 있는 서비스 역할을 만들 수 있습니다. 그런 다음 관리형 또는 인라인 정책을 해당 역할에 연결할 수 있습니다.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:AttachRolePolicy",
                "iam:CreateRole",
                "iam:PutRolePolicy"
            ],
            "Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME"
        }
    ]
}
```

------

**IAM 엔터티가 모든 서비스 역할을 생성하도록 허용하려면**

AWS에서는 관리 사용자만 서비스 역할을 생성할 수 있도록 허용하는 것이 좋습니다. 역할을 생성하고 정책을 연결할 수 있는 권한이 있는 사람은 자신의 권한을 에스컬레이션할 수 있습니다. 대신 필요한 역할만 생성하거나 관리자가 대신 서비스 역할을 생성하도록 허용하는 정책을 만듭니다.

관리자가 사용자 전체 AWS 계정에 액세스할 수 있도록 허용하는 정책을 연결하려면 [AdministratorAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AdministratorAccess) AWS 관리형 정책을 사용합니다.

**IAM 엔터티가 서비스 역할을 편집할 수 있도록 허용하려면**

서비스 역할을 편집해야 하는 IAM 엔터티에 다음 정책을 추가합니다.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "EditSpecificServiceRole",
            "Effect": "Allow",
            "Action": [
                "iam:AttachRolePolicy",
                "iam:DeleteRolePolicy",
                "iam:DetachRolePolicy",
                "iam:GetRole",
                "iam:GetRolePolicy",
                "iam:ListAttachedRolePolicies",
                "iam:ListRolePolicies",
                "iam:PutRolePolicy",
                "iam:UpdateRole",
                "iam:UpdateRoleDescription"
            ],
            "Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME"
        },
        {
            "Sid": "ViewRolesAndPolicies",
            "Effect": "Allow",
            "Action": [
                "iam:GetPolicy",
                "iam:ListRoles"
            ],
            "Resource": "*"
        }
    ]
}
```

------

**IAM 엔터티가 특정 서비스 역할을 삭제하도록 허용하려면**

특정 서비스 역할을 삭제해야 하는 IAM 엔터티의 권한 정책에 다음 명령문을 추가합니다.

```
{
    "Effect": "Allow",
    "Action": "iam:DeleteRole",
    "Resource": "arn:aws:iam::*:role/SERVICE-ROLE-NAME"
}
```

**IAM 엔터티가 모든 서비스 역할을 삭제하도록 허용하려면**

AWS에서는 관리 사용자만 서비스 역할을 삭제할 수 있도록 허용하는 것이 좋습니다. 대신, 필요한 역할만 삭제하거나 관리자가 대신 서비스 역할을 삭제하도록 허용하는 정책을 만듭니다.

관리자가 사용자 전체 AWS 계정에 액세스할 수 있도록 허용하는 정책을 연결하려면 [AdministratorAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/AdministratorAccess) AWS 관리형 정책을 사용합니다.

## AWS 서비스에 대한 역할 생성(콘솔)
<a name="roles-creatingrole-service-console"></a>

AWS Management Console을 사용하여 서비스의 역할을 만들 수 있습니다. 일부 서비스는 두 개 이상의 서비스 역할을 지원하기 때문에 어떤 사용 사례를 선택할지 확인하려면 해당 서비스의 [AWS 설명서](https://docs.aws.amazon.com/) 섹션을 참조하세요. 서비스에서 역할을 위임할 수 있도록 역할에 필요한 신뢰 정책과 권한 정책을 할당하는 방법을 알아볼 수 있습니다. 역할에 대한 권한을 관리할 수 절차는 서비스가 어떻게 사용 사례를 정의하느냐와 서비스 링크된 역할을 생성할 수 있는지 여부에 따라 다양할 수 있습니다.

------
#### [ Console ]

**AWS 서비스의 역할을 생성하는 방법(IAM 콘솔)**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. IAM 콘솔의 탐색 창에서 **역할**을 선택하고 **역할 생성**을 선택합니다.

1. **신뢰할 수 있는 엔터티 유형**에서 **AWS 서비스**를 선택합니다.

1. **서비스 또는 사용 사례**의 경우 서비스를 선택한 다음, 사용 사례를 선택합니다. 사용 사례는 서비스에 필요한 신뢰 정책을 포함하도록 서비스에서 정의합니다.

1. **다음**을 선택합니다.

1. **권한 정책**의 경우 선택한 사용 사례에 따라 옵션이 달라집니다.
   + 서비스가 역할에 대한 권한을 정의하는 경우 권한 정책을 선택할 수 없습니다.
   + 제한된 권한 정책 세트에서 선택합니다.
   + 모든 권한 정책에서 선택합니다.
   + 권한 정책 없음을 선택하고 역할이 생성된 후 정책을 생성한 다음, 정책을 역할에 연결합니다.

1. (선택 사항) [권한 경계](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)를 선택합니다. 이는 서비스 역할에서 사용 가능한 고급 기능이며 서비스에 연결된 역할은 아닙니다.

   1. **권한 경계 설정** 섹션을 열고 **최대 역할 권한을 관리하기 위한 권한 경계 사용**을 선택합니다.

      IAM은 계정의 AWS 관리형 또는 고객 관리형 정책 목록을 포함합니다.

   1. 정책을 선택하여 권한 경계를 사용합니다.

1. **다음**을 선택합니다.

1. **역할 이름**의 경우 옵션은 서비스에 따라 달라집니다.
   + 서비스에서 역할 이름을 정의하는 경우 이 역할 이름을 편집할 수 없습니다.
   + 서비스에서 역할 이름에 대한 접두사를 정의하는 경우 사용자가 선택적 접미사를 입력할 수 있습니다.
   + 서비스에서 역할 이름을 정의하지 않는 경우 역할 이름을 지정할 수 있습니다.
**중요**  
역할 이름을 지정할 때는 다음 사항에 유의하세요.  
역할 이름은 AWS 계정 내에서 고유해야 하지만 대소문자를 구분하지는 않습니다.  
예를 들어, 이름이 **PRODROLE**과 **prodrole**, 두 가지로 지정된 역할을 만들지 마세요. 역할 이름이 정책 또는 ARN의 일부로 사용되는 경우 역할 이름은 대소문자를 구분합니다. 그러나 로그인 프로세스와 같이 콘솔에서 역할 이름이 고객에게 표시되는 경우에는 역할 이름이 대소문자를 구분하지 않습니다.
다른 엔터티가 역할을 참조할 수 있기 때문에 역할이 생성된 후에는 역할 이름을 편집할 수 없습니다.

1. (선택 사항) **설명**에 역할에 대한 설명을 입력합니다.

1. (선택 사항) 역할에 대한 사용 사례와 권한을 편집하려면 **1단계: 신뢰할 수 있는 엔터티 선택** 또는 **2단계: 권한 추가** 섹션에서 **편집**을 선택합니다.

1. (선택 사항) 역할을 식별, 구성 또는 검색하려면 태그를 키-값 페어로 추가합니다. IAM에서 태그 사용에 대한 자세한 내용은 *IAM 사용 설명서*의 [AWS Identity and Access Management 리소스용 태그](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_tags.html)를 참조하세요.

1. 역할을 검토한 다음 **역할 생성**을 선택합니다.

------

## 서비스에 대한 역할 생성(AWS CLI)
<a name="roles-creatingrole-service-cli"></a>

AWS CLI에서 역할을 만들려면 여러 단계를 거쳐야 합니다. 콘솔을 사용하여 역할을 만들 때는 많은 단계가 자동으로 수행되지만 AWS CLI를 사용하면 각 단계를 직접 명시적으로 수행해야 합니다. 역할을 만든 다음 권한 정책을 역할에 할당해야 합니다. 작업 중인 서비스가 Amazon EC2인 경우에도 인스턴스 프로파일을 생성하여 거기에 역할을 추가해야 합니다. 선택적으로 역할에 대한 [권한 경계](access_policies_boundaries.md)를 설정할 수 있습니다.

**AWS CLI에서 AWS 서비스에 대한 역할을 만들려면**

1. 다음 `[create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html)` 명령은 *Test-Role*이라는 역할을 생성하고 해당 역할에 신뢰 정책을 연결합니다.

   `aws iam create-role --role-name Test-Role --assume-role-policy-document file://Test-Role-Trust-Policy.json`

1. 역할에 관리형 권한 정책 연결: [aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html).

   예를 들어 `attach-role-policy` 명령은 `ReadOnlyAccess`라는 AWS 관리형 정책을 `ReadOnlyRole`이라는 IAM 역할에 연결합니다.

   `aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess --role-name ReadOnlyRole`

    또는

   역할을 위한 인라인 권한 정책 생성: [aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html)

   인라인 권한 정책을 추가하려면 다음 예제를 참조하세요.

    `aws iam put-role-policy --role-name Test-Role --policy-name ExamplePolicy --policy-document file://AdminPolicy.json`

1. (선택 사항) 태그를 연결하여 사용자 지정 속성을 역할에 추가: [aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html)

   자세한 내용은 [IAM 역할의 태그 관리(AWS CLI 또는 AWS API)](id_tags_roles.md#id_tags_roles_procs-cli-api) 섹션을 참조하세요.

1. (선택 사항) 역할([aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html))에 대한 [권한 경계](access_policies_boundaries.md)를 설정합니다.

   이 권한 경계는 역할이 가질 수 있는 최대 권한을 관리합니다. 권한 경계는 고급 AWS 기능입니다.

Amazon EC2 또는 Amazon EC2를 사용하는 다른 AWS 서비스에 대해 역할을 사용할 경우 인스턴스 프로파일에 역할을 저장해야 합니다. 인스턴스 프로파일은 시작할 때 Amazon EC2 인스턴스에 연결할 수 있는 역할을 위한 컨테이너입니다. 하나의 인스턴스 프로파일은 하나의 역할만 포함할 수 있으며 이 제한은 늘릴 수 없습니다. AWS Management Console을 사용하여 역할을 생성한 경우 역할과 동일한 이름을 지닌 인스턴스 프로파일이 자동으로 생성됩니다. 인스턴스 프로파일에 대한 자세한 내용은 [인스턴스 프로파일 사용](id_roles_use_switch-role-ec2_instance-profiles.md) 섹션을 참조하세요. 역할을 사용하여 EC2 인스턴스를 시작하는 방법에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [Amazon EC2 리소스에 대한 액세스 제어](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingIAM.html#UsingIAMrolesWithAmazonEC2Instances)를 참조하세요.

**인스턴스 프로파일을 만들고 여기에 역할을 저장하려면(AWS CLI)**

1. 인스턴스 프로파일 생성: [aws iam create-instance-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/create-instance-profile.html)

1. 인스턴스 프로파일에 역할 추가: [aws iam add-role-to-instance-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/add-role-to-instance-profile.html)

아래 AWS CLI 예제 명령 집합은 역할을 생성하고 권한을 연결하는 첫 두 단계를 보여줍니다. 인스턴스 프로파일을 생성하고 프로필에 역할을 추가하는 두 단계를 보여주기도 합니다. 이 예제 신뢰 정책은 Amazon EC2 서비스가 역할을 수임하고 `example_bucket` Amazon S3 버킷을 볼 수 있도록 허용합니다. 이 예제에서는 Windows를 실행하는 클라이언트 컴퓨터에서 실행 중이며 계정 자격 증명 및 리전으로 이미 명령줄 인터페이스를 구성했다고도 가정합니다. 자세한 내용은 [AWS 명령줄 인터페이스 구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)을 참조하세요.

이 예제는 역할을 생성할 경우 첫 번째 명령의 다음 신뢰 정책을 포함합니다. 이 신뢰 정책은 Amazon EC2 서비스가 역할을 수임하도록 허용합니다.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Principal": {"Service": "ec2.amazonaws.com"},
    "Action": "sts:AssumeRole"
  }
}
```

------

두 번째 명령을 사용할 경우, 권한 정책을 역할에 연결해야 합니다. 다음 예제 권한 정책에서는 역할이 `example_bucket` Amazon S3 버킷에서 `ListBucket` 작업만 수행하도록 허용합니다.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Action": "s3:ListBucket",
    "Resource": "arn:aws:s3:::example_bucket"
  }
}
```

------

이 `Test-Role-for-EC2` 역할을 생성하기 위해서는 먼저 이전 신뢰 정책을 `trustpolicyforec2.json` 이름으로, 이전 권한 정책을 `permissionspolicyforec2.json` 이름으로 로컬 `C:` 드라이브의 `policies` 디렉터리에 저장해야 합니다. 그러고 나면 다음 명령을 사용하여 역할을 만들고 인라인 정책을 연결, 인스턴스 프로파일 생성 및 인스턴스 프로파일에 역할을 추가합니다.

```
# Create the role and attach the trust policy that allows EC2 to assume this role.
$ aws iam create-role --role-name Test-Role-for-EC2 --assume-role-policy-document file://C:\policies\trustpolicyforec2.json

# Embed the permissions policy (in this example an inline policy) to the role to specify what it is allowed to do.
$ aws iam put-role-policy --role-name Test-Role-for-EC2 --policy-name Permissions-Policy-For-Ec2 --policy-document file://C:\policies\permissionspolicyforec2.json

# Create the instance profile required by EC2 to contain the role
$ aws iam create-instance-profile --instance-profile-name EC2-ListBucket-S3

# Finally, add the role to the instance profile
$ aws iam add-role-to-instance-profile --instance-profile-name EC2-ListBucket-S3 --role-name Test-Role-for-EC2
```

EC2 인스턴스를 시작할 때 AWS 콘솔을 사용하는 경우 **인스턴스 세부 정보 구성** 페이지에 인스턴스 프로파일 이름을 지정합니다. `aws ec2 run-instances` CLI 명령을 사용하는 경우 `--iam-instance-profile` 파라미터를 지정합니다.

## 서비스에 대한 역할 생성(AWS API)
<a name="roles-creatingrole-service-api"></a>

AWS API에서 역할을 만들려면 여러 단계를 거쳐야 합니다. 콘솔을 사용하여 역할을 만들 때는 많은 단계가 자동으로 수행되지만 API를 사용하면 각 단계를 직접 명시적으로 수행해야 합니다. 역할을 만든 다음 권한 정책을 역할에 할당해야 합니다. 작업 중인 서비스가 Amazon EC2인 경우에도 인스턴스 프로파일을 생성하여 거기에 역할을 추가해야 합니다. 선택적으로 역할에 대한 [권한 경계](access_policies_boundaries.md)를 설정할 수 있습니다.

**AWS 서비스에 대한 역학을 생성하려면(AWS API)**

1. 역할 만들기: [CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html)

   역할의 신뢰 정책에 대해 파일 위치를 지정할 수 있습니다.

1. 역할에 관리형 권한 정책 연결: [AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html)

    또는

   역할을 위한 인라인 권한 정책 생성: [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html)

1. (선택 사항) 태그를 연결하여 사용자 지정 속성을 사용자에게 추가: [TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html)

   자세한 내용은 [IAM 사용자의 태그 관리(AWS CLI 또는 AWS API)](id_tags_users.md#id_tags_users_procs-cli-api) 섹션을 참조하세요.

1. (선택 사항) 역할([PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html))에 대한 [권한 경계](access_policies_boundaries.md)를 설정합니다.

   이 권한 경계는 역할이 가질 수 있는 최대 권한을 관리합니다. 권한 경계는 고급 AWS 기능입니다.

Amazon EC2 또는 Amazon EC2를 사용하는 다른 AWS 서비스에 대해 역할을 사용할 경우 인스턴스 프로파일에 역할을 저장해야 합니다. 인스턴스 프로파일은 역할에 대한 컨테이너입니다. 각 인스턴스 프로파일은 하나의 역할만 포함할 수 있으며 이 제한은 늘릴 수 없습니다. AWS Management Console에서 역할을 생성한 경우 역할과 동일한 이름을 지닌 인스턴스 프로파일이 자동으로 생성됩니다. 인스턴스 프로파일에 대한 자세한 내용은 [인스턴스 프로파일 사용](id_roles_use_switch-role-ec2_instance-profiles.md)을 참조하세요. 역할을 사용하여 Amazon EC2 인스턴스를 시작하는 방법에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [Amazon EC2 리소스에 대한 액세스 제어](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/UsingIAM.html#UsingIAMrolesWithAmazonEC2Instances)를 참조하세요.

**인스턴스 프로파일을 만들고 여기에 역할을 저장하려면(AWS API)**

1. 인스턴스 프로파일 생성: [CreateInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateInstanceProfile.html)

1. 인스턴스 프로파일에 역할 추가: [AddRoleToInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddRoleToInstanceProfile.html)

# 서비스 연결 역할 생성
<a name="id_roles_create-service-linked-role"></a>

서비스 연결 역할은 AWS 서비스에 직접 연결된 고유한 유형의 IAM 역할입니다. 서비스 연결 역할은 해당 서비스에서 사전 정의하며 서비스에서 다른 AWS 서비스를 직접적으로 자동 호출하기 위해 필요한 모든 권한을 포함합니다. 또한 연결된 서비스는 서비스 연결 역할을 만들고 수정하며 삭제하는 방법을 정의합니다. 서비스는 역할을 자동으로 만들거나 삭제할 수 있습니다. 서비스의 프로세스나 마법사를 사용하여 사용자가 역할을 만들거나 수정하거나 삭제하도록 허용할 수도 있습니다. 또는 사용자가 IAM을 사용하여 역할을 생성하거나 삭제해야 할 수도 있습니다. 방법과 관계없이 서비스 연결 역할은 서비스 설정 프로세스를 단순화합니다. 서비스가 사용자를 대신하여 작업을 완료하도록 권한을 수동으로 추가할 필요가 없기 때문입니다.

**참고**  
서비스 역할은 서비스 연결 역할과 다르다는 점을 기억하세요. 서비스 역할은 서비스가 사용자를 대신하여 작업을 수행하는 것으로 가정하는 [IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)입니다. IAM 관리자는 IAM 내에서 서비스 역할을 생성, 수정 및 삭제할 수 있습니다. 자세한 내용은 *IAM 사용 설명서*의 [Create a role to delegate permissions to an AWS 서비스](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)를 참조하세요. 서비스 연결 역할은 AWS 서비스에 연결된 서비스 역할의 한 유형입니다. 서비스는 사용자를 대신하여 작업을 수행하기 위해 역할을 수임할 수 있습니다. 서비스 연결 역할은 AWS 계정에 나타나고, 서비스가 소유합니다. IAM 관리자는 서비스 연결 역할의 권한을 볼 수 있지만 편집은 할 수 없습니다.

연결된 서비스에서 서비스 연결 역할 권한을 정의하므로 정의되지 않은 경우에만 해당 역할로 서비스를 수행할 수 있습니다. 정의된 권한에는 신뢰 정책과 권한 정책이 포함되며 이 권한 정책은 다른 IAM 엔터티에 연결할 수 없습니다.

역할을 삭제하려면 먼저 관련 리소스를 삭제해야 합니다. 이렇게 하면 리소스에 액세스할 수 있는 권한이 실수로 제거되는 것을 방지할 수 있습니다.

**작은 정보**  
서비스 연결 역할의 사용을 지원하는 서비스에 대한 자세한 정보는 [AWS IAM으로 작업하는 서비스](reference_aws-services-that-work-with-iam.md)를 참조하고 **서비스 연결 역할** 열에 **예**가 있는 서비스를 찾습니다. 해당 서비스에 대한 서비스 연결 역할 설명서를 보려면 **예(Yes)** 링크를 선택합니다.

## 서비스 연결 역할 권한
<a name="service-linked-role-permissions"></a>

사용자 또는 역할이 서비스 연결 역할을 작성하거나 편집할 수 있도록 IAM​ 엔터티(사용자 또는 역할)의 권한을 구성해야 합니다.

**참고**  
서비스 링크된 역할에 대한 ARN은 정책에서 `SERVICE-NAME.amazonaws.com`으로 나타내지는 서비스 보안 주체를 포함합니다. 각 경우마다 다르고 AWS 서비스에 따라 형식이 다양하기 때문에 서비스 보안 주체를 알기 어렵습니다. 서비스의 보안 주체를 보려면 해당 서비스 링크된 역할 설명서 섹션을 참조하세요.

**IAM 엔터티가 특정 서비스 연결 역할을 만들 수 있도록 허용하려면**

서비스 연결 역할을 생성해야 하는 IAM 엔터티에 다음 정책을 추가합니다.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iam:CreateServiceLinkedRole",
            "Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*",
            "Condition": {"StringLike": {"iam:AWSServiceName": "SERVICE-NAME.amazonaws.com"}}
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:AttachRolePolicy",
                "iam:PutRolePolicy"
            ],
            "Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*"
        }
    ]
}
```

------

**IAM 엔터티가 서비스 연결 역할을 생성할 수 있도록 허용하려면**

서비스 연결 역할 또는 필요한 정책을 포함해야 하는 모든 서비스 역할을 생성해야 하는 IAM 엔터티의 권한 정책에 다음 명령문을 추가합니다. 이 정책 명령문은 IAM 엔터티가 역할에 정책을 연결하는 것을 허용하지 않습니다.

```
{
    "Effect": "Allow",
    "Action": "iam:CreateServiceLinkedRole",
    "Resource": "arn:aws:iam::*:role/aws-service-role/*"
}
```

**IAM 엔터티가 서비스 역할의 설명을 편집할 수 있도록 허용하려면**

서비스 연결 역할 또는 서비스 역할의 설명을 편집해야 하는 IAM 엔터티의 권한 정책에 다음 명령문을 추가합니다.

```
{
    "Effect": "Allow",
    "Action": "iam:UpdateRoleDescription",
    "Resource": "arn:aws:iam::*:role/aws-service-role/*"
}
```

**IAM 엔터티가 특정 서비스 연결 역할을 삭제하도록 허용하려면**

서비스 연결 역할을 삭제해야 하는 IAM 개엔터티의 권한 정책에 다음 명령문을 추가합니다.

```
{
    "Effect": "Allow",
    "Action": [
        "iam:DeleteServiceLinkedRole",
        "iam:GetServiceLinkedRoleDeletionStatus"
    ],
    "Resource": "arn:aws:iam::*:role/aws-service-role/SERVICE-NAME.amazonaws.com/SERVICE-LINKED-ROLE-NAME-PREFIX*"
}
```

**IAM 엔터티가 서비스 연결 역할을 삭제할 수 있도록 허용하려면**

서비스 연결 역할만 삭제하고 서비스 역할은 삭제하지 않는 IAM 엔터티의 권한 정책에 다음 명령문을 추가합니다.

```
{
    "Effect": "Allow",
    "Action": [
        "iam:DeleteServiceLinkedRole",
        "iam:GetServiceLinkedRoleDeletionStatus"
    ],
    "Resource": "arn:aws:iam::*:role/aws-service-role/*"
}
```

**IAM 엔터티가 기존 역할을 서비스에 전달하도록 허용하려면**

일부 AWS 서비스를 사용하면 새 서비스에 연결된 역할을 생성하지 않고, 그 대신에 서비스에 기존 역할을 전달할 수 있습니다. 이렇게 하려면 사용자에게 서비스에 *역할을 전달*할 수 있는 권한이 있어야 합니다. 역할을 생성해야 하는 IAM 엔터티의 권한 정책에 다음 명령문을 추가합니다. 또한 이 정책 설명에서는 엔터티가 전달할 역할을 선택할 수 있는 역할 목록을 볼 수 있도록 허용합니다. 자세한 내용은 [사용자에게 AWS 서비스에 역할을 전달할 권한 부여](id_roles_use_passrole.md) 섹션을 참조하세요.

```
{
  "Sid": "PolicyStatementToAllowUserToListRoles",
  "Effect": "Allow",
  "Action": ["iam:ListRoles"],
  "Resource": "*"
},
{
  "Sid": "PolicyStatementToAllowUserToPassOneSpecificRole",
  "Effect": "Allow",
  "Action": [ "iam:PassRole" ],
  "Resource": "arn:aws:iam::account-id:role/my-role-for-XYZ"
}
```

## 간접 권한과 서비스 연결 역할을 통한 간접 권한
<a name="create-service-linked-role-permissions-transfer"></a>

서비스 연결 역할에서 부여한 권한은 간접적으로 다른 사용자 및 역할에게 양도할 수 있습니다. AWS 서비스가 서비스 연결 역할을 사용하는 경우 해당 서비스 연결 역할은 자체 권한을 사용하여 다른 AWS 서비스를 호출할 수 있습니다. 즉, 서비스 연결 역할을 사용하는 서비스를 호출할 권한이 있는 사용자 및 역할은 해당 서비스 연결 역할로 액세스할 수 있는 서비스에 간접적으로 액세스할 수 있습니다.

예를 들어, Amazon RDS DB 인스턴스를 생성할 때 [RDS용 서비스 연결 역할](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAM.ServiceLinkedRoles.html)이 아직 존재하지 않는다면 자동으로 하나가 생성됩니다. 이렇게 생성된 서비스 연결 역할은 사용자가 DB 인스턴스를 편집할 때마다 RDS에게 사용자 대신 Amazon EC2, Amazon SNS, Amazon CloudWatch Logs 및 Amazon Kinesis를 호출하도록 허용합니다. 계정의 사용자 및 역할이 RDS 데이터베이스를 수정하거나 생성하도록 허용하면 RDS를 호출하여 Amazon EC2, Amazon SNS, Amazon CloudWatch Logs 로그 및 Amazon Kinesis 리소스와 간접적으로 상호 작용할 수 있습니다. RDS는 서비스 연결 역할을 사용하여 해당 리소스에 액세스하기 때문입니다.

### 서비스 연결 역할을 생성하는 방법
<a name="create-service-linked-role"></a>

서비스 연결 역할을 만드는 데 사용하는 방법은 서비스에 따라 다릅니다. 경우에 따라 서비스 연결 역할을 수동으로 만들 필요가 없습니다. 예를 들어 사용자가 서비스의 특정 작업(리소스 만들기 등)을 수행할 때 서비스가 서비스 연결 역할을 자동으로 생성할 수 있습니다. 또한, 서비스가 서비스 연결 역할 지원을 시작하기 전에 서비스를 사용한 경우에는 서비스가 자동으로 해당 계정에 역할을 생성했을 수 있습니다. 자세한 내용은 [내 AWS 계정에 표시되는 새 역할](troubleshoot_roles.md#troubleshoot_roles_new-role-appeared) 섹션을 참조하세요.

다른 경우에는 서비스에서 서비스 콘솔, API 또는 CLI를 사용하여 서비스 연결 역할을 수동으로 만들도록 허용할 수 있습니다. 서비스 연결 역할의 사용을 지원하는 서비스에 대한 자세한 정보는 [AWS IAM으로 작업하는 서비스](reference_aws-services-that-work-with-iam.md)를 참조하고 **서비스 연결 역할** 열에 **예**가 있는 서비스를 찾습니다. 서비스가 서비스 연결 역할 생성을 지원하는지 여부를 알아보려면 **예** 링크를 선택하여 해당 서비스의 서비스 연결 역할 설명서 섹션을 참조하세요.

서비스가 역할 생성을 지원하지 않는 경우에는 IAM을 사용하여 서비스 연결 역할을 생성할 수 있습니다.

**중요**  
서비스 연결 역할은 [AWS 계정의 IAM 역할](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html#reference_iam-quotas-entities) 제한을 계산하는 데 포함되지만, 한도에 도달한 경우에도 계정에 서비스 연결 역할을 생성할 수 있습니다. 한도를 초과해도 생성할 수 있는 역할은 서비스 연결 역할뿐입니다.

### 서비스 연결 역할 만들기(콘솔)
<a name="create-service-linked-role-iam-console"></a>

IAM에서 서비스 연결 역할을 생성하기 전에, 연결된 서비스가 서비스 역할을 자동으로 생성하는지 확인합니다. 또한 서비스의 콘솔, API, CLI 등에서 역할을 생성할 수 있는지를 알아봅니다.<a name="create-service-linked-role-iam-console"></a>

**서비스 연결 역할을 만드는 방법(콘솔)**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. IAM 콘솔의 탐색 창에서 **역할(Roles)**을 선택합니다. 그런 다음 **역할 생성**을 선택합니다.

1. **AWS 서비스** 역할 유형을 선택합니다.

1. 서비스의 사용 사례를 선택합니다. 사용 사례는 서비스에 필요한 신뢰 정책을 포함하기 위해 서비스에서 정합니다. 그리고 **다음(Next)**을 선택합니다.

1. 하나 이상의 권한 정책을 선택하여 역할에 연결합니다. 선택한 사용 사례에 따라 서비스에서 다음을 수행할 수 있습니다.
   + 역할에서 사용하는 권한을 정의할 수 있습니다.
   + 제한된 권한 세트에서 선택할 수 있습니다.
   + 모든 권한 중에서 선택할 수 있습니다.
   + 여기서 정책을 선택하지 않고, 나중에 정책을 만들어 역할에 연결할 수 있도록 허용합니다.

   역할에 제공하려는 권한을 할당하는 정책 옆에 있는 확인란을 선택한 후 **다음**을 선택하세요.
**참고**  
지정하는 권한은 역할을 사용하는 모든 주체가 사용할 수 있습니다. 기본적으로 역할은 권한이 없습니다.

1. **역할 이름**의 경우 역할 이름 사용자 지정 수준은 서비스에서 정합니다. 서비스에서 역할 이름을 정한 경우 이 옵션을 편집할 수 없습니다. 다른 경우에는 서비스에서 역할에 대한 접두사를 정의하고 사용자가 선택적 접미사를 입력할 수 있습니다.

   가능한 경우 기본 이름에 추가할 역할 이름 접미사를 입력합니다. 이 접미사는 이 역할의 목적을 파악하는 데 도움이 됩니다. 역할 이름은 AWS 계정 내에서 고유해야 합니다. 대소문자는 구별하지 않습니다. 예를 들어, 이름이 **<service-linked-role-name>\$1SAMPLE**과 **<service-linked-role-name>\$1sample**, 두 가지로 지정된 역할을 만들 수는 없습니다. 다양한 주체가 역할을 참조할 수 있기 때문에 역할이 생성된 후에는 역할 이름을 편집할 수 없습니다.

1. (선택 사항) **설명(Description)**에서 새로운 서비스 연결 역할에 대한 설명을 편집합니다.

1. 생성하는 동안에는 서비스 연결 역할에 태그를 연결할 수 없습니다. IAM에서의 태그 사용에 대한 자세한 내용은 [AWS Identity and Access Management 리소스용 태그](id_tags.md) 섹션을 참조하세요.

1. 역할을 검토한 다음 **역할 생성**을 선택합니다.

### 서비스 연결 역할 만들기(AWS CLI)
<a name="create-service-linked-role-iam-cli"></a>

IAM에서 서비스 연결 역할을 만들기 전에, 연결된 서비스가 서비스 역할을 자동으로 생성하는지 그리고 서비스의 CLI에서 사용자가 역할을 만들 수 있는지를 확인합니다. 서비스 CLI가 지원되지 않는 경우 IAM 명령을 사용하여 서비스가 역할을 위임하는 데 필요한 인라인 정책과 신뢰 정책을 포함하는 서비스 연결 역할을 생성할 수 있습니다.

**서비스 연결 역할(AWS CLI)을 만들려면**

다음 명령을 실행합니다.

```
aws iam [create-service-linked-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-service-linked-role.html) --aws-service-name SERVICE-NAME.amazonaws.com
```

### 서비스 연결 역할 만들기(AWS API)
<a name="create-service-linked-role-iam-api"></a>

IAM에서 서비스 연결 역할을 만들기 전에, 연결된 서비스가 서비스 역할을 자동으로 생성하는지 그리고 서비스의 API에서 사용자가 역할을 만들 수 있는지를 확인합니다. 서비스 API가 지원되지 않는 경우 AWS API를 사용하여 서비스가 역할을 위임하는 데 필요한 인라인 정책과 신뢰 정책을 포함하는 서비스 연결 역할을 만들 수 있습니다.

**서비스 연결 역할(AWS API)**을 만들려면

[CreateServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html) API 호출을 사용합니다. 요청 시 `SERVICE_NAME_URL.amazonaws.com` 서비스 이름을 지정합니다.

예를 들어 **Lex 봇** 서비스 연결 역할을 만들려면 `lex.amazonaws.com`을 사용합니다.

# 타사 ID 공급자에 대한 역할 생성
<a name="id_roles_create_for-idp"></a>

AWS 계정에 속하는 IAM 사용자를 생성하는 대신에 자격 증명 공급자를 사용할 수 있습니다. 자격 증명 공급자(IdP)를 사용하면 AWS 외부의 사용자 자격 증명을 관리할 수 있고 이 외부 사용자 자격 증명에 계정의 AWS 리소스에 대한 사용 권한을 부여할 수 있습니다. 연동 및 자격 증명 공급자에 대한 자세한 내용은 [ID 공급자 및 AWS로의 페더레이션](id_roles_providers.md) 섹션을 참조하세요.

## OIDC 및 SAML 페더레이션 보안 주체에 대한 역할 생성(콘솔)
<a name="roles-creatingrole-federated-users-console"></a>

페더레이션 사용자의 역할을 생성하는 절차는 타사 공급자 선택에 따라 다릅니다.
+ OIDC(OpenID Connect)에 대한 내용은 [OpenID Connect 페더레이션을 위한 역할 생성(콘솔)](id_roles_create_for-idp_oidc.md) 항목을 참조하세요.
+ SAML 2.0은 [SAML 2.0 페더레이션을 위한 역할 생성(콘솔)](id_roles_create_for-idp_saml.md) 섹션을 참조하세요.

## 페더레이션 액세스의 역할 만들기(AWS CLI)
<a name="roles-creatingrole-identityprovider-cli"></a>

AWS CLI에서 지원되는 자격 증명 공급자(OIDC 또는 SAML)의 역할을 만드는 절차는 동일합니다. 차이는 필수 선행 단계에서 생성하는 신뢰 정책의 내용에 있습니다. 사용하고 있는 공급자의 유형에 대한 **필수 선행 조건** 섹션에 나와 있는 절차에서부터 시작하세요.
+ OIDC 공급자의 경우 [OIDC 역할 생성을 위한 사전 조건](id_roles_create_for-idp_oidc.md#idp_oidc_Prerequisites) 섹션을 참조하세요.
+ SAML 공급자의 경우 [SAML 역할을 생성하기 위한 사전 조건](id_roles_create_for-idp_saml.md#idp_saml_Prerequisites) 섹션을 참조하세요.

AWS CLI에서 역할을 만들려면 여러 단계를 거쳐야 합니다. 콘솔을 사용하여 역할을 만들 때는 많은 단계가 자동으로 수행되지만 AWS CLI를 사용하면 각 단계를 직접 명시적으로 수행해야 합니다. 역할을 만든 다음 권한 정책을 역할에 할당해야 합니다. 선택적으로 역할에 대한 [권한 경계](access_policies_boundaries.md)를 설정할 수 있습니다.

**역할 생성(AWS CLI)**

1. 역할 생성: [aws iam create-role](https://docs.aws.amazon.com/cli/latest/reference/iam/create-role.html)

1. 역할에 권한 정책 연결: [aws iam attach-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-role-policy.html)

    또는

   역할을 위한 인라인 권한 정책 생성: [aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html)

1. (선택 사항) 태그를 연결하여 사용자 지정 속성을 역할에 추가: [aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html)

   자세한 내용은 [IAM 역할의 태그 관리(AWS CLI 또는 AWS API)](id_tags_roles.md#id_tags_roles_procs-cli-api) 섹션을 참조하세요.

1. (선택 사항) 역할([aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html))에 대한 [권한 경계](access_policies_boundaries.md)를 설정합니다.

   이 권한 경계는 역할이 가질 수 있는 최대 권한을 관리합니다. 권한 경계는 고급 AWS 기능입니다.

다음 예는 단순한 환경에서 자격 증명 공급자를 생성하는 가장 일반적인 단계 중 첫 두 단계를 보여줍니다. 이 예제는 `123456789012` 계정에 있는 모든 사용자가 역할을 수임하고 `example_bucket` Amazon S3 버킷을 볼 수 있도록 허용합니다. 또한 이 예는 Windows가 구동중인 컴퓨터에서 AWS CLI를 실행하고 있으며 자격 증명으로 AWS CLI를 이미 구성했다고 가정합니다. 자세한 내용은 [AWS Command Line Interface 구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html) 섹션을 참조하세요.

다음 예는 사용자가 Amazon Cognito를 사용하여 로그인하는 경우 모바일 앱에 대해 설계되는 신뢰 정책을 보여줍니다. 이 예제에서 *us-east:12345678-ffff-ffff-ffff-123456*은 Amazon Cognito에 의해 할당된 자격 증명 풀 ID를 나타냅니다.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": {
        "Sid": "RoleForCognito",
        "Effect": "Allow",
        "Principal": {"Federated": "cognito-identity.amazonaws.com"},
        "Action": "sts:AssumeRoleWithWebIdentity",
        "Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}
    }
}
```

------

다음 권한 정책에서는 역할을 수임하는 사용자가 `example_bucket` Amazon S3 버킷에서 `ListBucket` 작업만 수행하도록 허용합니다.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Action": "s3:ListBucket",
    "Resource": "arn:aws:s3:::example_bucket"
  }
}
```

------

이 `Test-Cognito-Role` 역할을 생성하기 위해서는 이전 신뢰 정책을 `trustpolicyforcognitofederation.json` 이름으로 이전 권한 정책을 `permspolicyforcognitofederation.json` 이름으로 로컬 `policies` 드라이브의 `C:` 폴더에 먼저 저장해야 합니다. 그러고 나면 다음 명령을 사용하여 역할을 만들고 인라인 정책을 연결합니다.

```
# Create the role and attach the trust policy that enables users in an account to assume the role.
$ aws iam create-role --role-name Test-Cognito-Role --assume-role-policy-document file://C:\policies\trustpolicyforcognitofederation.json

# Attach the permissions policy to the role to specify what it is allowed to do.
aws iam put-role-policy --role-name Test-Cognito-Role --policy-name Perms-Policy-For-CognitoFederation --policy-document file://C:\policies\permspolicyforcognitofederation.json
```

## 페더레이션 액세스의 역할 만들기(AWS API)
<a name="roles-creatingrole-identityprovider-api"></a>

AWS CLI에서 지원되는 자격 증명 공급자(OIDC 또는 SAML)의 역할을 만드는 절차는 동일합니다. 차이는 필수 선행 단계에서 생성하는 신뢰 정책의 내용에 있습니다. 사용하고 있는 공급자의 유형에 대한 **필수 선행 조건** 섹션에 나와 있는 절차에서부터 시작하세요.
+ OIDC 공급자의 경우 [OIDC 역할 생성을 위한 사전 조건](id_roles_create_for-idp_oidc.md#idp_oidc_Prerequisites) 섹션을 참조하세요.
+ SAML 공급자의 경우 [SAML 역할을 생성하기 위한 사전 조건](id_roles_create_for-idp_saml.md#idp_saml_Prerequisites) 섹션을 참조하세요.

**역할 생성(AWS API)**

1. 역할 만들기: [CreateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateRole.html)

1. 역할에 권한 정책 연결: [AttachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachRolePolicy.html)

    또는

   역할을 위한 인라인 권한 정책 생성: [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html)

1. (선택 사항) 태그를 연결하여 사용자 지정 속성을 사용자에게 추가: [TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html)

   자세한 내용은 [IAM 사용자의 태그 관리(AWS CLI 또는 AWS API)](id_tags_users.md#id_tags_users_procs-cli-api) 섹션을 참조하세요.

1. (선택 사항) 역할([PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html))에 대한 [권한 경계](access_policies_boundaries.md)를 설정합니다.

   이 권한 경계는 역할이 가질 수 있는 최대 권한을 관리합니다. 권한 경계는 고급 AWS 기능입니다.

# OpenID Connect 페더레이션을 위한 역할 생성(콘솔)
<a name="id_roles_create_for-idp_oidc"></a>

AWS 계정에 AWS Identity and Access Management 사용자를 생성하는 대신 OpenID Connect(OIDC) 페더레이션형 ID 제공업체를 사용할 수 있습니다. 자격 증명 공급자(IdP)를 사용하면 AWS 외부의 사용자 자격 증명을 관리할 수 있고 이 외부 사용자 자격 증명에 계정의 AWS 리소스에 대한 사용 권한을 부여할 수 있습니다. 페더레이션과 IdP에 대한 자세한 내용을 알아보려면 [ID 공급자 및 AWS로의 페더레이션](id_roles_providers.md) 섹션을 참조하세요.

## OIDC 역할 생성을 위한 사전 조건
<a name="idp_oidc_Prerequisites"></a>

OIDC 페더레이션을 위한 역할을 만들기 전에 먼저 다음 사전 조건 단계를 완료해야 합니다.<a name="oidc-prereqs"></a>

**OIDC 페더레이션을 위한 역할 생성 준비**

1. 페더레이션 OIDC ID를 제공하는 하나 이상의 서비스로 가입합니다. AWS 리소스로 액세스가 필요한 앱을 생성하면 공급자 정보로 앱도 구성합니다. 이렇게 하면 제공업체는 앱의 고유한 애플리케이션 및 시청자 ID를 제공합니다. (공급자마다 이 프로세스에 대해 다른 용어를 사용합니다. 이 가이드에서는 공급자에 앱을 식별하는 프로세스를 *구성*이라는 용어로 설명합니다.) 각 공급자로 여러 개의 앱을 구성하거나 단일 앱을 통해 다양한 공급자를 구성할 수 있습니다. 다음과 같이 ID 제공자에 대한 정보를 봅니다.
   + [Login with Amazon 개발자 센터](https://login.amazon.com/)
   + Facebook 개발자 사이트의 [앱 또는 웹 사이트에 Facebook 로그인 추가하기](https://developers.facebook.com/docs/facebook-login/v2.1)
   + Google 개발자 사이트의 [OAuth 2.0을 사용한 로그인(OpenID Connect)](https://developers.google.com/accounts/docs/OAuth2Login)

1. <a name="idpoidcstep2"></a>IdP로부터 필요한 정보를 받은 후 IAM에서 IdP를 생성합니다. 자세한 내용은 [IAM에서 OIDC(OpenID Connect) ID 공급자 생성](id_roles_providers_create_oidc.md) 단원을 참조하세요.
**중요**  
Google, Facebook 또는 Amazon Cognito의 OIDC IdP를 사용하는 경우 AWS Management Console에서 IAM IdP를 별도로 생성하지 마세요. 이러한 OIDC ID 제공자는 이미 AWS에 내장되어 있고 용도에 맞게 사용할 수 있습니다. 이 단계를 건너뛰고 다음 단계에서 IdP를 사용하여 새 역할을 생성합니다.

1. IdP를 통해 인증된 사용자가 맡을 역할에 대한 정책을 준비합니다. 다른 어떤 역할과 마찬가지로 모바일 앱을 위한 역할에는 2개의 정책이 포함됩니다. 하나는 역할을 위임할 사용자를 지정하는 신뢰 정책입니다. 다른 하나는 모바일 앱의 액세스가 허용 또는 거부되는 AWS 작업 및 리소스를 지정하는 권한 정책입니다.

   웹 IdP의 경우, [Amazon Cognito](https://aws.amazon.com/cognito/)를 사용하여 보안 인증을 관리하는 것이 좋습니다. 이 경우 이 예제와 비슷한 신뢰 정책을 사용합니다.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": {
           "Effect": "Allow",
           "Principal": {"Federated": "cognito-identity.amazonaws.com"},
           "Action": "sts:AssumeRoleWithWebIdentity",
           "Condition": {
               "StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east-2:12345678-abcd-abcd-abcd-123456"},
               "ForAnyValue:StringLike": {"cognito-identity.amazonaws.com:amr": "unauthenticated"}
           }
       }
   }
   ```

------

   `us-east-2:12345678-abcd-abcd-abcd-123456`을 Amazon Cognito에서 할당하는 아이덴티티 풀 ID로 바꿉니다.

   신뢰 정책을 생성할 때 OIDC IdP를 수동으로 구성하려면 자체 앱만이 이 역할을 수임한다고 보장하는 세 가지 값을 사용해야 합니다.
   + `Action` 요소에 대해서는 `sts:AssumeRoleWithWebIdentity` 작업을 사용하세요.
   + `Principal` 요소에 대해서는 `{"Federated":providerUrl/providerArn}` 문자열을 사용하세요.
     + 일부 범용 OIDC IdP의 경우, `providerUrl`이 URL입니다. 다음 예제는 일부 범용 IdP에 대해 보안 주체를 지정하는 방법을 포함합니다.

       `"Principal":{"Federated":"cognito-identity.amazonaws.com"}`

       `"Principal":{"Federated":"www.amazon.com"}`

       `"Principal":{"Federated":"graph.facebook.com"}`

       `"Principal":{"Federated":"accounts.google.com"}`
     + 다른 OIDC 제공업체의 경우, 다음 예제와 같이 [Step 2](#idpoidcstep2)에서 생성한 OIDC IdP의 Amazon 리소스 이름(ARN)을 사용합니다.

       `"Principal":{"Federated":"arn:aws:iam::123456789012:oidc-provider/server.example.com"}`
   + 권한을 제한하려면 `Condition` 요소에 `StringEquals` 조건을 사용합니다. 자격 증명 풀 ID(Amazon Cognito용) 또는 앱 ID(다른 공급자용)를 테스트합니다. 아이덴티티 풀 ID는 IdP를 통해 앱을 구성할 때 얻은 앱 ID와 일치해야 합니다. 이러한 ID 간의 일치는 요청이 앱에서 오는지 확인합니다.
**참고**  
Amazon Cognito 자격 증명 풀의 IAM 역할은 서비스 보안 주체 `cognito-identity.amazonaws.com`의 역할 수임을 신뢰합니다. 이 유형의 역할에는 역할을 수임할 수 있는 보안 주체를 제한하기 위한 조건 키가 하나 이상 포함되어야 합니다.  
[크로스 계정 IAM 역할](access_policies-cross-account-resource-access.md)을 수임하는 Amazon Cognito 자격 증명 풀에는 추가 고려 사항이 적용됩니다. 이러한 역할의 신뢰 정책은 `cognito-identity.amazonaws.com` 서비스 보안 주체를 수락해야 하며 의도한 자격 증명 풀의 사용자로 역할 수임을 제한하는 `aud` 조건 키를 포함해야 합니다. 이 조건 없이 Amazon Cognito 자격 증명 풀을 신뢰하는 정책은 의도하지 않은 자격 증명 풀의 사용자가 역할을 맡을 수 있는 위험을 야기합니다. 자세한 내용은 **Amazon Cognito 개발자 안내서의 [Trust policies for IAM roles in Basic (Classic) authentication](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html#trust-policies)을 참조하세요.

     사용하는 IdP에 따라 다음 예제 중 하나와 비슷한 조건 요소를 생성합니다.

     `"Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}`

     `"Condition": {"StringEquals": {"www.amazon.com:app_id": "amzn1.application-oa2-123456"}}`

     `"Condition": {"StringEquals": {"graph.facebook.com:app_id": "111222333444555"}}`

     `"Condition": {"StringEquals": {"accounts.google.com:aud": "66677788899900pro0"}}`

     OIDC 공급자의 경우 다음 예시와 같이 `aud` 컨텍스트 키로 OIDC IdP의 정규화된 URL을 사용합니다.

     `"Condition": {"StringEquals": {"server.example.com:aud": "appid_from_oidc_idp"}}`
**참고**  
역할의 신뢰 정책에서 보안 주체에 대한 값은 하나의 IdP에 고유합니다. OIDC 역할은 오직 하나의 보안 주체만을 지정할 수 있습니다. 따라서 모바일 앱이 사용자에게 1개 이상의 IdP에서 로그인할 수 있게 허용한다면 지원하고자 하는 각각의 IdP에 대한 개별 역할을 생성합니다. 각 IdP에 대한 개별 신뢰 정책을 생성합니다.

   사용자가 모바일 앱을 사용하여 Login with Amazon에서 로그인하는 경우 다음 예제 신뢰 정책이 적용됩니다. 예제에서 *amzn1.application-oa2-123456*은 Login with Amazon을 이용해 앱을 구성할 때 Amazon에서 할당하는 앱 ID를 나타냅니다.

------
#### [ JSON ]

****  

   ```
   {
         "Version":"2012-10-17",		 	 	 
         "Statement": [{
             "Sid": "RoleForLoginWithAmazon",
             "Effect": "Allow",
             "Principal": {"Federated": "www.amazon.com"},
             "Action": "sts:AssumeRoleWithWebIdentity",
             "Condition": {"StringEquals": {"www.amazon.com:app_id": "amzn1.application-oa2-123456"}}
         }]
     }
   ```

------

   사용자가 모바일 앱을 사용하여 Facebook에서 로그인하는 경우 다음 예제 신뢰 정책이 적용됩니다. 이 예제에서 *111222333444555*는 Facebook에서 할당하는 앱 ID를 나타냅니다.

------
#### [ JSON ]

****  

   ```
   {
         "Version":"2012-10-17",		 	 	 
         "Statement": [{
             "Sid": "RoleForFacebook",
             "Effect": "Allow",
             "Principal": {"Federated": "graph.facebook.com"},
             "Action": "sts:AssumeRoleWithWebIdentity",
             "Condition": {"StringEquals": {"graph.facebook.com:app_id": "111222333444555"}}
         }]
     }
   ```

------

   사용자가 모바일 앱을 사용하여 Google에서 로그인하는 경우 다음 예제 신뢰 정책이 적용됩니다. 이 예제에서 *666777888999000*은 Google에서 할당하는 앱 ID를 나타냅니다.

------
#### [ JSON ]

****  

   ```
   {
         "Version":"2012-10-17",		 	 	 
         "Statement": [{
             "Sid": "RoleForGoogle",
             "Effect": "Allow",
             "Principal": {"Federated": "accounts.google.com"},
             "Action": "sts:AssumeRoleWithWebIdentity",
             "Condition": {"StringEquals": {"accounts.google.com:aud": "666777888999000"}}
         }]
     }
   ```

------

   사용자가 모바일 앱을 사용하여 Amazon Cognito에서 로그인하는 경우 다음 예제 신뢰 정책이 적용됩니다. 이 예제에서 *us-east:12345678-ffff-ffff-ffff-123456*은 Amazon Cognito에서 할당하는 아이덴티티 풀 ID를 나타냅니다.

------
#### [ JSON ]

****  

   ```
   {
         "Version":"2012-10-17",		 	 	 
         "Statement": [{
             "Sid": "RoleForCognito",
             "Effect": "Allow",
             "Principal": {"Federated": "cognito-identity.amazonaws.com"},
             "Action": "sts:AssumeRoleWithWebIdentity",
             "Condition": {"StringEquals": {"cognito-identity.amazonaws.com:aud": "us-east:12345678-ffff-ffff-ffff-123456"}}
         }]
     }
   ```

------

## OIDC 역할 생성
<a name="idp_oidc_Create"></a>

사전 요구 사항을 완료한 후에는 IAM에서 역할을 생성할 수 있습니다. 인식된 공유 OpenID Connect(OIDC) ID 공급자(IdP)의 경우 IAM은 **ID 공급자 제어라고 하는 JSON 웹 토큰(JWT)의 특정 클레임을 명시적으로 평가해야 합니다. **ID 공급자 제어가 있는 OIDC IdP에 대한 자세한 내용은 [공유 OIDC 공급자의 ID 공급자 제어](id_roles_providers_oidc_secure-by-default.md) 섹션을 참조하세요.

다음 절차는 AWS Management Console에서 OIDC 페더레이션 역할을 생성하는 방법을 설명합니다. AWS CLI 또는 AWS API에 역할을 만들려면 [타사 ID 공급자에 대한 역할 생성](id_roles_create_for-idp.md)의 절차 섹션을 참조하세요.

**중요**  
Amazon Cognito를 사용하는 경우 Amazon Cognito 콘솔을 사용하여 역할을 설정합니다. 그 외에는 IAM 콘솔을 사용하여 OIDC 페더레이션의 역할을 생성합니다.

**OIDC 페더레이션을 위한 IAM 역할 생성**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **역할**을 선택한 후 **역할 생성**을 선택합니다.

1. 신뢰할 수 있는 엔터티 유형으로 **웹 자격 증명**을 선택하고 **다음**을 선택합니다.

1. **자격 증명 공급자(Identity provider)**에서 역할의 IdP를 선택합니다.
   + 개별 웹 IdP에 대한 역할을 생성하는 경우, **Login with Amazon**, **Facebook** 또는 **Google**을 선택합니다.
**참고**  
지원할 각 IdP에 대해 별도의 역할을 생성해야 합니다.
   + Amazon Cognito의 고급 시나리오 역할을 생성하려는 경우 **Amazon Cognito**를 선택합니다.
**참고**  
고급 시나리오에서 작업하는 경우에만 Amazon Cognito에서 사용할 역할을 수동으로 생성해야 합니다. 그렇지 않은 경우 Amazon Cognito가 역할을 대신 생성할 수 있습니다. 자세한 내용은 *Amazon Cognito 개발자 안내서*의 [자격 증명 풀(페더레이션 자격 증명) 외부 자격 증명 공급자](https://docs.aws.amazon.com/cognito/latest/developerguide/external-identity-providers.html)를 참조하세요.
   + GitHub 작업을 위한 역할을 만들려는 경우 먼저 GitHub OIDC 공급자를 IAM에 추가해야 합니다. IAM에 GitHub OIDC 공급자를 추가한 후 **token.actions.githubusercontent.com**을 선택합니다.
**참고**  
GitHub의 OIDC 제공자를 페더레이션형 ID로 신뢰하도록 AWS를 구성하는 방법에 대한 자세한 내용은 [GitHub Docs - Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)를 참조하세요. GitHub용 IAM IdP와 관련된 역할에 대한 액세스를 제한하는 모범 사례에 대한 자세한 내용은 이 페이지의 [GitHub OIDC ID 제공자의 역할 구성](#idp_oidc_Create_GitHub)을 참조하세요.
   + HashiCorp Cloud Platform(HCP) Terraform에 대한 역할을 생성하려면 먼저 Terraform OIDC 제공자를 IAM에 추가해야 합니다. IAM에 Terraform OIDC 제공자를 추가한 후 **app.terraform.io**를 선택합니다.
**중요**  
HashiCorp Cloud Platform(HCP) Terraform OIDC 제공자에 대한 IAM 역할은 역할 신뢰 정책에서 IAM 조건 키 `app.terraform.io:sub`를 평가해야 합니다. 이 조건 키는 역할을 수임할 수 있는 HCP Terraform 조직, 프로젝트, 워크스페이스 또는 실행 단계를 제한합니다. 이 조건 키가 없으면 신뢰 정책은 조직 외부의 ID로 역할 및 AWS 리소스에 대한 액세스 권한을 부여합니다. 이는 최소 권한 원칙에 부합하지 않습니다.  
AWS 계정의 HCP Terraform OIDC 제공자와 연결된 역할에 대한 역할 신뢰 정책을 설정하거나 수정하지만 IAM 조건 키 `app.terraform.io:sub`를 평가하지 않으면 오류가 발생합니다. 또한 AWS STS는 역할 신뢰 정책이 이 조건 키를 평가하지 않는 경우 권한 부여 요청을 거부합니다.

1. 요청된 정보는 선택한 OIDC 공급자에 따라 다릅니다.
   + 애플리케이션의 식별자를 입력합니다. 식별자의 레이블은 선택하는 제공업체를 기준으로 변경됩니다.
     + Login with Amazon용 역할을 생성하려는 경우 **애플리케이션 ID(Application ID)** 상자에 앱 ID를 입력합니다.
     + Facebook용 역할을 생성하려는 경우 **애플리케이션 ID(Application ID)** 상자에 앱 ID를 입력합니다.
     + Google용 역할을 생성하려는 경우 **대상(Audience)** 상자에 대상 사용자 이름을 입력합니다.
     + Amazon Cognito용 역할을 생성하려는 경우 Amazon Cognito 애플리케이션용으로 생성한 아이덴티티 풀의 ID를 **자격 증명 풀 ID(Identity Pool ID)** 상자에 입력합니다.
   + GitHub 작업을 위한 역할을 만들려는 경우 다음 세부 정보를 입력하세요.
     + **대상**에서 `sts.amazonaws.com`을 입력합니다.
     + **GitHub 조직**에 GitHub 조직 이름을 입력합니다. GitHub 조직 이름은 필수이며 대시(-)를 포함한 영숫자여야 합니다. GitHub 조직 이름에 와일드카드 문자(\$1 및?)는 사용할 수 없습니다.
     + (선택 사항) **GitHub 리포지토리**에 GitHub 리포지토리 이름을 입력합니다. 값을 지정하지 않을 경우 기본값은 와일드카드(`*`)입니다.
     + (선택 사항) **GitHub 브랜치**에 GitHub 브랜치 이름을 입력합니다. 값을 지정하지 않을 경우 기본값은 와일드카드(`*`)입니다.
   + HashiCorp Cloud Platform(HCP) Terraform에 대한 역할을 생성하려면 다음 세부 정보를 입력합니다.
     + **대상**에서 `aws.workload.identity`을 입력합니다.
     + **조직**에 조직 이름을 입력합니다. 모든 조직에 와일드카드 문자(`*`)를 지정할 수 있습니다.
     + **프로젝트**에 프로젝트 이름을 입력합니다. 모든 프로젝트에 와일드카드 문자(`*`)를 지정할 수 있습니다.
     + **WorkSpace**에 WorkSpace 이름을 입력합니다. 모든 워크스페이스에 와일드카드 문자(`*`)를 지정할 수 있습니다.
     + **실행 단계**에 실행 단계 이름을 입력합니다. 모든 실행 단계에 와일드카드 문자(`*`)를 지정할 수 있습니다.

1. (선택 사항) 애플리케이션 사용자가 역할에서 부여한 권한을 사용하기 위해 충족해야 하는 추가 조건을 만들려면 **조건(선택 사항)**에서 **조건 추가**를 클릭합니다. 예를 들어, 특정 IAM 사용자 ID에만 AWS 리소스에 대한 액세스 권한을 부여하는 조건을 추가할 수 있습니다. 역할을 만든 후에 신뢰 정책에 조건을 추가할 수도 있습니다. 자세한 내용은 [역할 트러스트 정책 업데이트](id_roles_update-role-trust-policy.md) 섹션을 참조하세요.

1. OIDC 정보를 검토하고 **다음**을 선택합니다.

1. IAM은 계정의 AWS관리형 또는 고객 관리형 정책 목록을 포함합니다. 권한 정책을 사용하기 위한 정책을 선택하거나 **정책 생성(Create policy)**을 선택하여 새 브라우저 탭을 열고 완전히 새로운 정책을 생성합니다. 자세한 내용은 [IAM 정책 생성](access_policies_create-console.md#access_policies_create-start) 섹션을 참조하세요. 정책을 생성하면 탭을 닫고 원래 탭으로 돌아갑니다. OIDC 사용자에게 제공하려는 권한 정책 옆의 확인란을 선택하세요. 원할 경우, 여기서 정책을 선택하지 않고 나중에 정책을 만들어서 역할에 연결할 수 있습니다. 기본적으로 역할은 권한이 없습니다.

1. (선택 사항) [권한 경계](access_policies_boundaries.md)를 선택합니다. 이는 고급 기능입니다.

   **권한 경계(Permissions boundary)** 섹션을 열고 **최대 역할 권한을 관리하기 위한 권한 경계 사용(Use a permissions boundary to control the maximum role permissions)**을 선택합니다. 정책을 선택하여 권한 경계를 사용합니다.

1. **다음**을 선택합니다.

1. **역할 이름(Role name)**에 역할 이름을 입력합니다. 역할 이름은 AWS 계정 내에서 고유해야 합니다. 대소문자를 구분하지 않습니다. 예를 들어, 이름이 **PRODROLE**과 **prodrole**, 두 가지로 지정된 역할을 만들 수는 없습니다. 다른 AWS 리소스가 역할을 참조할 수 있기 때문에 역할을 생성한 후에는 역할 이름을 편집할 수 없습니다.

1. (선택 사항) **설명(Description)**에 새 역할에 대한 설명을 입력합니다.

1. 역할에 대한 사용 사례와 권한을 편집하려면 **1단계: 신뢰할 수 있는 엔터티 선택(Step 1: Select trusted entities)** 또는 **2단계: 권한 추가(Step 2: Add permissions)** 섹션에서 **편집(Edit)**을 선택합니다.

1. (선택 사항) 역할에 메타데이터를 추가하려면 태그를 키-값 페어로 연결합니다. IAM에서의 태그 사용에 대한 자세한 내용은 [AWS Identity and Access Management 리소스용 태그](id_tags.md) 섹션을 참조하세요.

1. 역할을 검토한 다음 **역할 생성**을 선택합니다.

## GitHub OIDC ID 제공자의 역할 구성
<a name="idp_oidc_Create_GitHub"></a>

GitHub를 OIDC ID 제공업체(idP)로 사용하는 경우 IAM IdP와 연결된 역할을 수임할 수 있는 엔터티를 제한하는 것이 좋습니다. 신뢰 정책에 조건문을 포함하면 특정 GitHub 조직, 리포지토리 또는 분기로 역할을 제한할 수 있습니다. 문자열 조건 연산자가 있는 조건 키 `token.actions.githubusercontent.com:sub`을(를) 사용하여 액세스를 제한할 수 있습니다. 특정 리포지토리 또는 GitHub 조직 내 리포지토리 또는 분기 세트로 조건을 제한하는 것이 좋습니다. GitHub의 OIDC를 페더레이션형 ID로 신뢰하도록 AWS를 구성하는 방법에 대한 자세한 내용을 알아보려면 [GitHub Docs - Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)(GitHub 문서 - Amazon Web Services에서 OpenID Connect 구성)를 참조하세요.

작업 워크플로나 OIDC 정책에서 GitHub 환경을 사용하는 경우 보안을 강화하기 위해 환경에 보호 규칙을 추가하는 것이 좋습니다. 배포 브랜치와 태그를 사용하여 환경에 배포할 수 있는 브랜치와 태그를 제한하세요. 보호 규칙을 사용하여 환경을 구성하는 방법에 대한 자세한 내용은 GitHub의 *배포를 위한 환경 사용* 문서의 [배포 브랜치 및 태그](https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment#deployment-branches-and-tags)를 참조하세요.

GitHub의 OIDC IdP가 사용자 역할의 신뢰할 수 있는 보안 주체인 경우 IAM은 역할 신뢰 정책 조건을 검사하여 조건 키 `token.actions.githubusercontent.com:sub`이(가) 맞는지, 또 그 값이 와일드카드 문자(\$1 및 ?)만이거나 무효는 아닌지 확인합니다. IAM은 신뢰 정책이 생성되거나 업데이트될 때 이 검사를 수행합니다. 조건 키`token.actions.githubusercontent.com:sub`이(가) 존재하지 않거나 키 값이 언급된 값 기준을 충족하지 않으면 요청이 실패하고 오류가 반환됩니다.

**중요**  
조건 키 `token.actions.githubusercontent.com:sub`을(를) 특정 조직이나 리포지토리에 한정하지 않으면 제어할 수 없는 조직이나 리포지토리의 GitHub 작업이 AWS 계정의 GitHub IAM IdP와 연결된 역할을 수임할 수 있습니다.

다음 예제 신뢰 정책은 정의된 GitHub 조직, 리포지토리 및 분기에 대한 액세스를 제한합니다. 아래 예에서 조건 키 `token.actions.githubusercontent.com:sub` 값은 GitHub에서 문서화한 기본 주제 값 형식입니다.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::012345678910:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
          "token.actions.githubusercontent.com:sub": "repo:GitHubOrg/GitHubRepo:ref:refs/heads/GitHubBranch"
        }
      }
    }
  ]
}
```

------

다음 예제 조건은 정의된 GitHub 조직 및 리포지토리에 대한 액세스를 제한하지만 리포지토리 내의 모든 분기에 대한 액세스 권한을 부여합니다.

```
"Condition": {
  "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
  },
  "StringLike": {    
    "token.actions.githubusercontent.com:sub": "repo:GitHubOrg/GitHubRepo:*"
  }
}
```

다음 예제 조건은 정의된 GitHub 조직 내의 모든 리포지토리 또는 분기에 대한 액세스를 제한합니다. 조건 키 `token.actions.githubusercontent.com:sub`은(는) GitHub 조직 내에서 GitHub 작업에 대한 액세스를 제한하는 특정 값으로 제한하는 것이 좋습니다.

```
"Condition": {
  "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
  },
  "StringLike": {    
    "token.actions.githubusercontent.com:sub": "repo:GitHubOrg/*"
  }
}
```

정책에서 조건 확인을 위해 사용 가능한 OIDC 페더레이션 키에 대한 자세한 정보는 [AWS OIDC 페더레이션에서 사용 가능한 키](reference_policies_iam-condition-keys.md#condition-keys-wif) 섹션을 참조하세요.

# SAML 2.0 페더레이션을 위한 역할 생성(콘솔)
<a name="id_roles_create_for-idp_saml"></a>

 AWS 계정에 속하는 IAM 사용자를 생성하는 대신에 SAML 2.0 페더레이션을 사용할 수 있습니다. 자격 증명 공급자(IdP)를 사용하면 AWS 외부의 사용자 자격 증명을 관리할 수 있고 이 외부 사용자 자격 증명에 계정의 AWS 리소스에 대한 사용 권한을 부여할 수 있습니다. 연동 및 자격 증명 공급자에 대한 자세한 내용은 [ID 공급자 및 AWS로의 페더레이션](id_roles_providers.md) 섹션을 참조하세요.

**참고**  
페더레이션 복원력을 개선하려면 여러 SAML 로그인 엔드포인트를 지원하도록 IdP 및 AWS 페더레이션을 구성하는 것이 좋습니다. 자세한 내용은 AWS 보안 블로그 문서 [How to use regional SAML endpoints for failover](https://aws.amazon.com/blogs//security/how-to-use-regional-saml-endpoints-for-failover)(장애 조치에 리전 SAML 엔드포인트를 사용하는 방법)를 참조하세요.

## SAML 역할을 생성하기 위한 사전 조건
<a name="idp_saml_Prerequisites"></a>

SAML 2.0 페더레이션을 위한 역할을 만들기 전에 먼저 다음 필수 선행 단계를 완료해야 합니다.<a name="saml-prereqs"></a>

**SAML 2.0 연동을 위한 역할 생성을 준비하려면**

1. <a name="idpsamlstep1"></a>SAML 기반 페더레이션을 위한 역할을 생성하기 전에 IAM에서 SAML 공급자를 만들어야 합니다. 자세한 내용은 [IAM에서 SAML ID 공급자 생성](id_roles_providers_create_saml.md) 섹션을 참조하세요.

1. SAML 2.0 인증 사용자들이 수임할 역할에 대한 정책을 준비합니다. 다른 어떤 역할과 마찬가지로 SAML 연동을 위한 역할에는 2개의 정책이 포함됩니다. 하나는 역할을 맡을 수 있는 사용자를 지정하는 역할 신뢰 정책이고, 다른 하나는 SAML 페더레이션 보안 주체의 액세스가 허용 또는 거부되는 AWS 작업 및 리소스를 지정하는 IAM 권한 정책입니다.

   역할에 대한 신뢰 정책을 생성할 때 애플리케이션만 역할을 수임할 수 있도록 세 가지 값을 사용해야 합니다.
   + `Action` 요소에 대해서는 `sts:AssumeRoleWithSAML` 작업을 사용하세요.
   + `Principal` 요소에 대해서는 `{"Federated":ARNofIdentityProvider}` 문자열을 사용하세요. `ARNofIdentityProvider`를 [Step 1](#idpsamlstep1)에서 만든 [SAML 자격 증명 공급자](id_roles_providers_saml.md)의 ARN으로 바꿉니다.
   + `Condition` 요소의 경우 `StringEquals` 조건을 사용하여 SAML 응답의 `saml:aud` 속성이 콘솔에 로그인할 때 브라우저에 표시되는 URL과 일치하는지 테스트합니다. 이 로그인 엔드포인트 URL은 ID 제공업체의 SAML 수신자 속성입니다. 특정 리전 내에 로그인 URL을 포함할 수 있습니다. AWS에서는 페더레이션 복원력을 개선하기 위해 글로벌 엔드포인트 대신 리전별 엔드포인트를 사용할 것을 권장합니다. 가능한 *region-code* 값 목록은 [AWS 로그인 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)의 **리전(Region)** 열을 참조하세요.

     SAML 암호화가 필요한 경우 로그인 URL에는 AWS가 SAML 제공업체에 할당하는 고유 식별자가 포함되어야 합니다. IAM 콘솔에서 ID 제공업체를 선택해서 세부 정보 페이지를 표시하여 고유 식별자를 볼 수 있습니다.

     `https://region-code.signin.aws.amazon.com/saml/acs/IdP-ID`

   다음 예는 SAML 페더레이션 사용자를 위해 설계된 신뢰 정책입니다.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": {
           "Effect": "Allow",
           "Action": "sts:AssumeRoleWithSAML",
           "Principal": {
               "Federated": "arn:aws:iam::111122223333:saml-provider/PROVIDER-NAME"
           },
           "Condition": {
               "StringEquals": {
                   "SAML:aud": "https://region-code.signin.aws.amazon.com/saml"
               }
           }
       }
   }
   ```

------

   보안 주체 ARN을 IAM에서 만든 SAML 공급자의 실제 ARN으로 바꿉니다. ARN에는 고유의 계정 ID와 공급자 이름이 있습니다.

## SAML 역할 생성
<a name="idp_saml_Create"></a>

사전 조건 단계를 완료한 후에는 SAML 기반 연동을 위한 역할을 생성합니다.

**SAML 기반 연동을 위한 역할을 생성하려면**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. IAM 콘솔의 탐색 창에서 **역할**과 **역할 생성**을 차례대로 선택합니다.

1. **SAML 2.0 federation(SAML 2.0 연동)** 역할 유형을 선택합니다.

1. **SAML 공급자 선택(Select a SAML provider)**에서 역할의 제공업체를 선택합니다.

1. SAML 2.0 액세스 수준 방법을 선택합니다.
   + **Allow programmatic access only(프로그래밍 방식의 액세스만 허용)**을 선택하여 AWS API 또는 AWS CLI에서 프로그래밍 방식으로 위임할 수 있는 역할을 만듭니다.
   + 그런 다음 **프로그래밍 방식 및 AWS Management Console 액세스 허용**을 선택하여 AWS Management Console에서 프로그래밍 방식으로 수임할 수 있는 역할을 생성합니다.

   이렇게 생성된 두 역할은 비슷하지만 콘솔에서 위임할 수도 있는 역할에는 특정 조건을 포함하는 신뢰 정책을 포함합니다. 이 조건은 SAML 대상(`SAML:aud` 속성)이 SAML 제공업체에 대한 AWS 로그인 엔드포인트로 설정되도록 명시적으로 보장합니다.

1. 속성을 정의하는 절차는 액세스 유형에 따라 다릅니다.
   + 프로그래밍 방식 액세스를 위한 역할을 만드는 경우, **속성** 목록에서 속성을 선택합니다. 그런 다음 **값(Value)** 상자에 역할에 포함시킬 값을 입력합니다. 이렇게 하면 지정한 속성을 포함하는 SAML 인증 응답(어설션)을 소유한 자격 증명 공급자의 사용자로 역할 액세스가 제한됩니다. 하나 이상의 속성을 지정해야 역할이 조직의 일부 사용자 집합으로 제한됩니다.
   + 프로그래밍 방식 AWS Management Console 액세스를 위한 역할을 생성하는 경우 **로그인 엔드포인트** 섹션은 콘솔에 로그인할 때 브라우저에 표시되는 URL을 정의합니다. 이 엔드포인트는 [`saml:aud`](reference_policies_iam-condition-keys.md#condition-keys-saml) 컨텍스트 키에 매핑되는 ID 제공업체의 SAML 수신자 속성입니다. 자세한 내용은 [인증 응답에 대한 SAML 어설션 구성](id_roles_providers_create_saml_assertions.md) 섹션을 참조하세요.

     1. **리전별 엔드포인트** 또는 **비리전별 엔드포인트**를 선택합니다. 페더레이션 복원력을 개선하려면 여러 리전별 SAML 로그인 엔드포인트를 사용하는 것이 좋습니다.

     1. **리전**에서 SAML 제공업체가 AWS 로그인을 지원하는 리전을 선택합니다.

     1.  **고유 식별자를 포함하는 로그인 URL**에서 로그인 엔드포인트에 AWS가 SAML ID 제공업체에 할당하는 고유 식별자가 포함되는지 여부를 선택합니다. 이 옵션은 암호화된 SAML 어설션에 필요합니다. 자세한 내용은 [SAML 2.0 연동](id_roles_providers_saml.md) 섹션을 참조하세요.

1. 신뢰 정책에 속성 관련 조건을 더 추가하려면 **조건(선택 사항)(Condition (optional))**을 선택하고 추가 조건을 선택한 후 값을 지정합니다.
**참고**  
이 목록에는 가장 많이 사용되는 SAML 속성이 포함되어 있습니다. IAM은 조건을 생성하는 데 사용할 수 있는 추가 속성을 지원합니다. 지원되는 속성 목록은 [SAML 연동에 사용할 수 있는 키](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#condition-keys-saml)를 참조하세요. 목록에는 없지만 지원되는 SAML 속성의 조건이 필요한 경우, 해당 조건을 수동으로 추가할 수 있습니다. 이렇게 하려면 역할을 만든 후 신뢰 정책을 편집합니다.

1.  SAML 2.0 신뢰 정보를 검토한 후 **다음(Next)**을 선택합니다.

1. IAM은 계정의 AWS관리형 또는 고객 관리형 정책 목록을 포함합니다. 권한 정책을 사용하기 위한 정책을 선택하거나 **정책 생성(Create policy)**을 선택하여 새 브라우저 탭을 열고 완전히 새로운 정책을 생성합니다. 자세한 내용은 [IAM 정책 생성](access_policies_create-console.md#access_policies_create-start) 섹션을 참조하세요. 정책을 생성하면 탭을 닫고 원래 탭으로 돌아갑니다. SAML 페더레이션 사용자에게 제공하려는 권한 정책 옆의 확인란을 선택합니다. 원할 경우, 여기서 정책을 선택하지 않고 나중에 정책을 만들어서 역할에 연결할 수 있습니다. 기본적으로 역할은 권한이 없습니다.

1. (선택 사항) [권한 경계](access_policies_boundaries.md)를 선택합니다. 이는 고급 기능입니다.

   **권한 경계(Permissions boundary)** 섹션을 열고 **최대 역할 권한을 관리하기 위한 권한 경계 사용(Use a permissions boundary to control the maximum role permissions)**을 선택합니다. 정책을 선택하여 권한 경계를 사용합니다.

1. **다음**을 선택합니다.

1. **다음: 검토**를 선택합니다.

1. **역할 이름(Role name)**에 역할 이름을 입력합니다. 역할 이름은 AWS 계정 내에서 고유해야 합니다. 대소문자는 구별하지 않습니다. 예를 들어, 이름이 **PRODROLE**과 **prodrole**, 두 가지로 지정된 역할을 만들 수는 없습니다. 기타 AWS 리소스가 역할을 참조할 수 있기 때문에 역할이 생성된 후에는 역할 이름을 편집할 수 없습니다.

1. (선택 사항)**설명**에 새 역할에 대한 설명을 입력합니다.

1. **1단계: 신뢰할 수 있는 엔터티 선택(Step 1: Select trusted entities)** 또는 **2단계: 권한 추가(Step 2: Add permissions)** 섹션에서 **편집(Edit)**을 선택하여 역할에 대한 사용 사례와 권한을 편집합니다.

1. (선택 사항) 태그를 키 값 페어로 연결하여 메타데이터를 역할에 추가합니다. IAM에서의 태그 사용에 대한 자세한 내용은 [AWS Identity and Access Management 리소스용 태그](id_tags.md) 섹션을 참조하세요.

1. 역할을 검토한 다음 **역할 생성**을 선택합니다.

역할을 만든 후, AWS에 대한 정보로 자격 증명 공급자 소프트웨어를 구성하여 SAML 신뢰를 완료합니다. 이 정보는 SAML 페더레이션 사용자가 사용했으면 하는 역할을 포함합니다. 이를 가리켜 IdP와 AWS 간 신뢰 당사자 신뢰 구성이라고 합니다. 자세한 내용은 [신뢰 당사자 신뢰 및 클레임 추가를 통해 SAML 2.0 IdP 구성](id_roles_providers_create_saml_relying-party.md) 섹션을 참조하세요.

# 사용자 지정 트러스트 정책을 사용하여 역할 생성
<a name="id_roles_create_for-custom"></a>

사용자 지정 신뢰 정책을 생성하여 액세스를 위임하고 다른 사람이 AWS 계정에서 작업을 수행하도록 허용할 수 있습니다. 자세한 내용은 [IAM 정책 생성](access_policies_create-console.md#access_policies_create-start) 섹션을 참조하세요.

역할을 사용해 권한을 위임하는 방법에 대한 자세한 내용은 [역할 용어 및 개념](id_roles.md#id_roles_terms-and-concepts) 섹션을 참조하세요.

## 사용자 지정 신뢰 정책을 사용하여 IAM 역할 생성(콘솔)
<a name="roles-creatingrole-custom-trust-policy-console"></a>

AWS Management Console을 사용하여 IAM 사용자가 수임할 수 있는 역할을 생성할 수 있습니다. 예를 들면 프로덕션 환경에서 개발 환경을 격리하기 위해 조직이 여러 개의 AWS 계정을 갖고 있다고 가정합시다. 개발 계정의 사용자가 프로덕션 계정의 리소스에 액세스할 수 있도록 하는 역할 생성에 대한 개괄적 정보는 [분리된 개발 및 프로덕션 계정을 사용한 예제 시나리오](id_roles_common-scenarios_aws-accounts.md#id_roles_common-scenarios_aws-accounts-example) 섹션을 참조하세요.

**사용자 지정 신뢰 정책을 사용하여 역할 생성(콘솔)**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 콘솔의 탐색 창에서 **역할**을 선택한 후 **역할 생성**을 선택합니다.

1. **사용자 지정 신뢰 정책(Custom trust policy)** 역할 유형을 선택합니다.

1. **사용자 지정 신뢰 정책(Custom trust policy)** 섹션에서 역할의 사용자 지정 신뢰 정책을 입력하거나 붙여 넣습니다. 자세한 내용은 [IAM 정책 생성](access_policies_create-console.md#access_policies_create-start) 섹션을 참조하세요.

1. [정책 검증](access_policies_policy-validator.md) 동안 생성된 모든 보안 경고, 오류 또는 일반 경고를 해결하고 **다음**을 선택합니다.

1. (선택 사항) [권한 경계](access_policies_boundaries.md)를 선택합니다. 이는 서비스 역할에서 사용 가능한 고급 기능이며 서비스에 연결된 역할은 아닙니다.

   **권한 경계(Permissions boundary)** 섹션을 열고 **최대 역할 권한을 관리하기 위한 권한 경계 사용(Use a permissions boundary to control the maximum role permissions)**을 선택합니다. IAM은 계정의 AWS관리형 또는 고객 관리형 정책 목록을 포함합니다. 정책을 선택하여 권한 경계를 사용합니다.

1. **다음**을 선택합니다.

1. **역할 이름**의 경우 역할 이름 사용자 지정 수준은 서비스에서 정합니다. 서비스에서 역할 이름을 정한 경우 이 옵션을 편집할 수 없습니다. 다른 경우에는 서비스에서 역할 이름의 접두사를 정의하고 사용자가 선택적 접미사를 입력할 수 있습니다. 일부 서비스는 역할의 전체 이름을 지정할 수 있습니다.

   가능하다면 역할 이름 또는 역할 이름 접미사를 입력합니다. 역할 이름은 AWS 계정 내에서 고유해야 합니다. 대소문자는 구별하지 않습니다. 예를 들어, 이름이 **PRODROLE**과 **prodrole**, 두 가지로 지정된 역할을 만들 수는 없습니다. 기타 AWS 리소스가 역할을 참조할 수 있기 때문에 역할이 생성된 후에는 역할 이름을 편집할 수 없습니다.

1. (선택 사항)**설명**에 새 역할에 대한 설명을 입력합니다.

1. (선택 사항) **1단계: 신뢰할 수 있는 엔터티 선택** 또는 **2단계: 권한 추가** 섹션에서 **편집**을 선택하여 역할의 사용자 지정 정책과 권한을 편집합니다.

1. (선택 사항) 태그를 키 값 페어로 연결하여 메타데이터를 역할에 추가합니다. IAM에서의 태그 사용에 대한 자세한 내용은 [AWS Identity and Access Management 리소스용 태그](id_tags.md) 섹션을 참조하세요.

1. 역할을 검토한 다음 **역할 생성**을 선택합니다.

# 액세스 권한 위임을 위한 정책의 예
<a name="id_roles_create_policy-examples"></a>

다음 예제는 AWS 계정의 리소스에 대한 액세스를 AWS 계정에게 허용 또는 부여하는 방법을 보여줍니다. 이러한 예제 JSON 정책 문서를 사용하여 IAM 정책을 생성하는 방법에 대해 자세히 알아보려면 [JSON 편집기를 사용하여 정책 생성](access_policies_create-console.md#access_policies_create-json-editor) 섹션을 참조하세요.

**Topics**
+ [

## 역할을 사용하여 다른 AWS 계정의 리소스에 대한 액세스 권한 위임
](#example-delegate-xaccount-rolesapi)
+ [

## 정책을 사용하여 서비스에 대한 액세스 권한 위임
](#id_roles_create_policy-examples-access-to-services)
+ [

## 리소스 기반의 정책을 사용하여 다른 계정의 Amazon S3 버킷에 대한 액세스 권한 위임
](#example-delegate-xaccount-S3)
+ [

## 리소스 기반의 정책을 사용하여 다른 계정의 Amazon SQS 대기열에 대한 액세스 권한 위임
](#example-delegate-xaccount-SQS)
+ [

## 계정이 액세스 거부될 경우 액세스 권한을 위임할 수 없음
](#example-delegate-xaccount-SQS-denied)

## 역할을 사용하여 다른 AWS 계정의 리소스에 대한 액세스 권한 위임
<a name="example-delegate-xaccount-rolesapi"></a>

 IAM 역할을 사용하여 한 계정의 사용자에게 다른 계정의 AWS 리소스에 대한 액세스 권한을 부여하는 방법에 대한 자세한 내용은 [튜토리얼: IAM 역할을 사용한 AWS 계정 간 액세스 권한 위임](tutorial_cross-account-with-roles.md) 섹션을 참조하세요.

**중요**  
역할 신뢰 정책의 `Principal` 요소에 특정 역할이나 사용자에 대한 ARN을 포함할 수 있습니다. 정책을 저장하면 AWS가 ARN을 고유한 보안 주체 ID로 변환합니다. 그러면 누군가가 해당 역할 또는 사용자를 제거하고 다시 만들어 본인의 권한을 에스컬레이션할 위험을 완화할 수 있습니다. 일반적으로 콘솔에서는 이 ID가 보이지 않습니다. 신뢰 정책이 표시될 때 해당 ARN으로 다시 역변환되기 때문입니다. 그러나 해당 역할 또는 사용자를 삭제하면 관계가 깨집니다. 사용자 또는 역할을 다시 만들더라도 해당 정책이 더 이상 적용되지 않습니다. 신뢰 정책에 저장된 보안 주체 ID와 일치하지 않기 때문입니다. 이 경우 보안 주체 ID가 콘솔에 표시됩니다. AWS에서 더 이상 이를 ARN에 다시 매핑할 수 없기 때문입니다. 결과적으로 신뢰 정책의 `Principal` 요소에서 참조된 사용자 또는 역할을 삭제하고 다시 생성하는 경우, ARN을 바꾸도록 역할을 편집해야 합니다. 그러면 정책을 저장할 때 ARN이 새 보안 주체 ID로 변환됩니다.

## 정책을 사용하여 서비스에 대한 액세스 권한 위임
<a name="id_roles_create_policy-examples-access-to-services"></a>

다음 예제는 역할에 연결할 수 있는 정책을 보여줍니다. 이 정책은 Amazon EMR 서비스와 AWS Data Pipeline 서비스가 역할을 수행할 수 있도록 합니다. 그러면 서비스가 해당 역할에 할당된 권한 정책에서 부여한 모든 작업을 수행할 수 있습니다(표시되지 않음). 여러 서비스 보안 주체를 지정할 때 `Service` 요소를 두 개 지정하면 안 됩니다. 하나만 지정할 수 있습니다. 대신 여러 서비스 보안 주체의 배열을 하나의 `Service` 요소의 값으로 사용합니다.

------
#### [ JSON ]

****  

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

------

## 리소스 기반의 정책을 사용하여 다른 계정의 Amazon S3 버킷에 대한 액세스 권한 위임
<a name="example-delegate-xaccount-S3"></a>

이 예에서 계정 A는 리소스 기반 정책(Amazon S3 [버킷 정책](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingBucketPolicies.html))을 사용하여 계정 B에게 계정 A의 S3 버킷에 액세스할 수 있는 완전한 권한을 부여합니다. 그런 다음 계정 B는 IAM 사용자 정책을 생성하여 계정 A의 버킷에 대한 해당 액세스 권한을 계정 B의 사용자 중 하나에게 위임합니다.

계정 A의 S3 버킷 정책은 다음 정책과 같을 수 있습니다. 이 예제에서 계정 A의 S3 버킷 이름은 **amzn-s3-demo-bucket이고, 계정 B의 계정 번호는 111122223333입니다. 계정 B에서는 개별 사용자 또는 그룹을 지정하지 않고 오직 계정 자체만 지정할 뿐입니다.

------
#### [ JSON ]

****  

```
{
  "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)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/S3_ACLs_UsingACLs.html)을 사용하여 계정 B에 S3 버킷 또는 버킷 내 단일 객체에 대한 액세스 권한을 부여할 수 있습니다. 이 경우 유일한 변경 사항은 계정 A가 계정 B에게 액세스 권한을 부여하는 방식입니다. 이 예의 다음 부분에서 설명한 것처럼 계정 B는 여전히 정책을 사용하여 계정 B의 IAM 그룹에 액세스 권한을 위임합니다. S3 버킷 및 객체에 대한 액세스를 관리하는 방법에 대한 자세한 내용은 *Amazon Simple Storage Service 사용 설명서*의 [액세스 제어](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingAuthAccess.html)를 참조하세요.

계정 B의 관리자는 다음 정책 샘플을 생성할 수 있습니다. 이 정책은 계정 B의 그룹 또는 사용자에게 읽기 액세스를 허용하며, 이전 정책은 B 계정에 대한 액세스 권한을 부여합니다. 하지만 계정 B의 개별 그룹과 사용자는 그룹 또는 사용자 정책이 리소스에 대한 권한을 명시적으로 부여할 때까지는 그 리소스에 액세스할 수 없습니다. 이 정책의 권한은 이전 크로스 계정 정책에 있는 권한의 하위 집합에 불과할 수 있습니다. 계정 B는 첫 번째 정책에서 계정 A가 계정 B에게 부여한 권한보다 더 많은 권한을 자신의 그룹 또는 사용자에게 위임할 수 없습니다. 이 정책에서 `Action` 요소는 `List` 작업만을 허용하도록 명시적으로 정의되고 이 정책의 `Resource` 요소는 계정 A에 의해 적용되는 버킷 정책의 `Resource`와 일치합니다.

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

------
#### [ JSON ]

****  

```
{
  "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 name="example-delegate-xaccount-SQS"></a>

다음 예에서 계정 A에는 계정 B에 대한 액세스 권한을 대기열에 부여하기 위해 대기열에 연결된 리소스 기반 정책을 사용하는 Amazon SQS 대기열이 있습니다. 그러면 계정 B는 IAM 그룹 정책을 사용하여 계정 B의 그룹에 액세스 권한을 위임합니다.

다음 대기열 정책 예에서는 계정 B에 계정 A의 대기열 *queue1*에 대한 `SendMessage` 및 `ReceiveMessage` 작업을 2014년 11월 30일 정오부터 오후 3시까지만 수행할 수 있는 권한을 부여합니다. 계정 B의 계정 번호는 1111-2222-3333입니다. 계정 A는 Amazon SQS를 사용하여 이 정책을 구현합니다.

------
#### [ JSON ]

****  

```
{
  "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을 사용하여 이 정책을 그룹(또는 사용자)에게 연결합니다.

------
#### [ JSON ]

****  

```
{
  "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` 작업만 수행할 수 있습니다.

## 계정이 액세스 거부될 경우 액세스 권한을 위임할 수 없음
<a name="example-delegate-xaccount-SQS-denied"></a>

다른 계정에서 사용자의 상위 계정에 대한 액세스를 명시적으로 거부할 경우 AWS 계정은 다른 계정의 리소스에 대한 액세스 권한을 위임할 수 없습니다. 이 거부는 사용자가 액세스 권한을 부여하는 기존 정책을 가지고 있는지 여부에 상관없이 해당 계정의 사용자에게 전파됩니다.

계정 A가 계정 A의 S3 버킷에 계정 A의 버킷에 대한 계정 B의 액세스를 명시적으로 거부하는 버킷 정책을 계정 A의 S3 버킷에 작성하는 경우를 예로 들어 보겠습니다. 계정 B는 계정 B의 사용자에게 계정 A의 버킷에 대한 액세스 권한을 부여하는 IAM 사용자 정책을 작성합니다. 계정 A의 S3 버킷에 적용된 명시적 거부는 계정 B의 사용자에게 전파되고 계정 B의 사용자에게 액세스 권한을 부여하는 IAM 사용자 정책보다 우선합니다. (권한 평가 방식에 대한 자세한 내용은 [정책 평가 로직](reference_policies_evaluation-logic.md) 섹션을 참조하세요.) 

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

------
#### [ JSON ]

****  

```
{
  "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의 모든 정책을 재정의합니다.

# IAM 역할 관리
<a name="id_roles_manage"></a>

사용자, 애플리케이션 또는 서비스에서 사용자가 생성한 역할을 사용하려면 먼저 해당 역할로 전환할 수 있는 권한을 부여해야 합니다. 그룹 또는 사용자에게 추가된 어떤 정책도 필요한 권한을 부여하는 데 사용할 수 있습니다. 이 섹션에서는 사용자에게 역할을 사용할 권한을 부여하는 방법을 설명합니다. 또한 사용자가 AWS Management Console, Tools for Windows PowerShell, AWS Command Line Interface(AWS CLI) 및 [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API에서 역할로 전환하는 방법도 설명합니다.

**중요**  
IAM 콘솔 대신 프로그래밍 방식으로 역할을 생성하는 경우에는 사용자의 선택에 따라 최대 64자인 `RoleName`뿐만 아니라 최대 512자인 `Path`도 추가할 수 있습니다. 그러나 AWS Management Console에서 **역할 전환(Switch Role)** 기능이 있는 역할을 사용하려면 `Path`와 `RoleName`을 합해 64자를 초과할 수 없습니다.

**Topics**
+ [

## 역할 액세스 보기
](#roles-modify_prerequisites)
+ [

## 액세스 정보를 기반으로 정책 생성
](#roles-modify_gen-policy)
+ [

# 사용자에게 역할을 전환할 권한 부여
](id_roles_use_permissions-to-switch.md)
+ [

# 사용자에게 AWS 서비스에 역할을 전달할 권한 부여
](id_roles_use_passrole.md)
+ [

# IAM 역할 임시 보안 자격 증명 취소
](id_roles_use_revoke-sessions.md)
+ [

# 서비스 연결 역할 업데이트
](id_roles_update-service-linked-role.md)
+ [

# 역할 트러스트 정책 업데이트
](id_roles_update-role-trust-policy.md)
+ [

# 역할 권한 업데이트
](id_roles_update-role-permissions.md)
+ [

# 역할 설정 업데이트
](id_roles_update-role-settings.md)
+ [

# 역할 또는 인스턴스 프로파일 삭제
](id_roles_manage_delete.md)

## 역할 액세스 보기
<a name="roles-modify_prerequisites"></a>

역할에 대한 권한을 변경하기 전에 최근 서비스 수준 활동을 검토해야 합니다. 이 기능은 사용 중인 보안 주체(사람 또는 애플리케이션)의 액세스 권한을 제거하지 않으려는 경우 중요합니다. 마지막으로 액세스한 정보 보기에 대한 자세한 내용은 [마지막으로 액세스한 정보를 사용하여 AWS에서 권한 재정의](access_policies_last-accessed.md) 섹션을 참조하세요.

## 액세스 정보를 기반으로 정책 생성
<a name="roles-modify_gen-policy"></a>

때로는 IAM 엔터티(사용자 또는 역할)에 필요한 것보다 많은 권한을 부여할 수도 있습니다. 부여하는 권한을 세분화할 수 있도록 엔터티의 액세스 활동을 기반으로 IAM 정책을 생성할 수 있습니다. IAM Access Analyzer는 사용자의 AWS CloudTrail 로그를 검토하고 지정된 날짜 범위에 엔터티에서 사용한 권한을 포함하는 정책 템플릿을 생성합니다. 이 템플릿을 사용하여 세분화된 권한이 포함된 관리형 정책을 생성한 다음 IAM 엔터티에 연결할 수 있습니다. 이렇게 하면 특정 사용 사례에 사용자나 역할이 AWS 리소스와 상호 작용하는 데 필요한 권한만 부여됩니다. 자세한 내용은 [IAM Access Analyzer 정책 생성](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html)을 참조하세요.

# 사용자에게 역할을 전환할 권한 부여
<a name="id_roles_use_permissions-to-switch"></a>

관리자가[크로스 계정 액세스를 위한 역할을 생성](id_roles_create_for-user.md)할 때는 역할 및 리소스를 소유하는 계정(신뢰하는 계정)과 사용자를 포함하는 계정(신뢰받는 계정) 간의 신뢰를 설정합니다. 이렇게 하려면 신뢰하는 계정의 관리자가 역할의 신뢰 정책에 신뢰받는 계정 번호를 `Principal`로 지정합니다. 이렇게 하면 잠재적으로* *신뢰할 수 있는 계정의 모든 사용자가 역할을 수임할 수 있습니다. 구성을 완료하려면 신뢰 받는 계정의 관리자는 계정에 속한 특정 그룹 또는 사용자에게 역할 전환 권한을 부여해야 합니다.

**역할로 전환할 수 있는 권한을 부여하려면 다음을 수행하세요.**

1. 신뢰할 수 있는 계정의 관리자로서 사용자에 대한 새 정책을 생성하거나 기존 정책을 편집하여 필요한 요소를 추가합니다. 자세한 내용은 [정책 생성 또는 편집](#roles-usingrole-createpolicy)을 참조하세요.

1. 그런 다음 역할 정보를 공유할 방법을 선택합니다.
   + **Role link**(역할 링크): 이미 세부 정보가 모두 작성되어 있는 **Switch Role**(역할 전환) 페이지로 이동하는 링크를 사용자에게 보냅니다.
   + **Account ID or alias**(계정 ID 또는 별칭): 각 사용자에게 계정 ID 번호나 계정 별칭과 함께 역할 이름을 제공합니다. 이제 사용자는 **역할 전환** 페이지로 이동하여 세부 정보를 직접 입력합니다.

   자세한 내용은 [사용자에게 정보 제공](#roles-usingrole-giveuser)을 참조하세요.

IAM 사용자, SAML 페더레이션 역할 또는 웹 아이덴티티 페더레이션 역할로 로그인할 때만 역할을 전환할 수 있습니다. AWS 계정 루트 사용자로 로그인할 때는 역할을 바꿀 수 없습니다.

**중요**  
AWS Management Console에서의 역할을 [ExternalId](id_roles_common-scenarios_third-party.md#id_roles_third-party_external-id) 값이 필요한 역할로 전환할 수 없습니다. `ExternalId` 파라미터를 지원하는 [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API를 호출해야만 이러한 역할로 전환할 수 있습니다.

**참고**  
이 주제에서는 최종적으로 사용자**에게 태스크를 수행할 수 있는 권한을 부여하기 때문에 사용자에 대한 정책에 대해 설명합니다. 그러나 개별 사용자에게 직접 권한을 부여하지 않는 것이 좋습니다. 사용자가 역할을 수임하면 해당 역할과 관련된 권한이 할당됩니다.
AWS Management Console에서 역할을 전환하는 경우, 콘솔은 항상 원래 자격 증명을 사용하여 전환을 승인합니다. 이는 IAM 사용자, SAML 페더레이션 역할 또는 웹 자격 증명 페더레이션 역할 중 어느 것으로 로그인하는지 여부에 관계없이 적용됩니다. 예를 들어, RoleA로 전환하는 경우 IAM에서는 원래 사용자 보안 인증 또는 페더레이션 역할 보안 인증을 사용하여 RoleA를 부여할지 여부를 결정합니다. *RoleA를 사용하는 중에* RoleB로 전환하려는 경우, **원래** 사용자 또는 페더레이션 역할 자격 증명이 인증에 사용됩니다. RoleA의 자격 증명은 이 작업에 사용되지 않습니다.

**Topics**
+ [

## 정책 생성 또는 편집
](#roles-usingrole-createpolicy)
+ [

## 사용자에게 정보 제공
](#roles-usingrole-giveuser)

## 정책 생성 또는 편집
<a name="roles-usingrole-createpolicy"></a>

역할을 맡기 위한 사용자 권한을 부여하는 정책에는 다음에 적용되는 `Allow` 문이 포함되어야 합니다.
+ `sts:AssumeRole` 작업
+ `Resource` 요소에 있는 역할의 ARN(Amazon Resource Name)

정책을 가져오는 사용자는 나열된 리소스에 대한 역할을 전환할 수 있습니다(그룹 멤버십 또는 직접 연결을 통해).

**참고**  
`Resource`를 `*`로 설정하는 경우 사용자가 사용자 계정을 신뢰하는 어떤 계정의 어떤 역할이라도 수임할 수 있습니다. (즉, 역할의 신뢰 정책에서 사용자의 계정을 `Principal`로 지정합니다.) [최소 권한의 원칙](http://en.wikipedia.org/wiki/Principle_of_least_privilege)에 따라 사용자에게 필요한 역할에 대해서만 완전한 ARN을 지정하는 것이 좋습니다.

다음 예제에서는 단 한 개의 계정에서 사용자가 역할을 맡을 수 있는 정책을 보여 줍니다. 또한 이 정책은 와일드카드(\$1)를 사용하여 역할 이름이 `Test` 문자로 시작할 경우에만 사용자가 역할을 전환할 수 있도록 지정합니다.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": {
        "Effect": "Allow",
        "Action": "sts:AssumeRole",
        "Resource": "arn:aws:iam::111122223333:role/Test*"
    }
}
```

------

**참고**  
이 역할이 사용자에게 부여하는 권한은 사용자에게 이미 부여된 권한에 추가되지는 않습니다. 사용자가 어떤 역할로 전환할 때는 일시적으로 자신의 원래 권한을 버리고 그 역할이 부여하는 권한으로 갈아탑니다. 사용자가 역할을 끝내면 원래 사용자 권한이 자동으로 회복됩니다. 사용자 권한에서 Amazon EC2 인스턴스 작업을 허용하지만, 역할의 권한 정책이 해당 권한을 부여하지 않는 경우를 예로 들어 보겠습니다. 이 경우 역할을 사용할 때 사용자가 콘솔에서 Amazon EC2 인스턴스 작업을 수행할 수 없습니다. 또한 `AssumeRole`을 통해 얻은 임시 자격 증명은 프로그래밍 방식으로 Amazon EC2 인스턴스 작업을 수행할 수 없습니다.

## 사용자에게 정보 제공
<a name="roles-usingrole-giveuser"></a>

역할을 만들어 이 역할로 전환하는 권한을 사용자에게 부여한 후, 사용자에게 다음을 제공해야 합니다.
+ 역할의 이름
+ 해당 역할을 포함하는 계정의 ID 또는 별칭

계정 ID와 역할 이름으로 미리 구성된 링크를 보내 사용자의 액세스를 간소화할 수 있습니다. **역할 생성** 마법사를 완료한 후 **역할 보기** 배너를 선택하거나 크로스 계정이 활성화된 역할에 대한 **역할 요약** 페이지에서 역할 링크를 볼 수 있습니다.

다음 형식을 사용해 링크를 수동으로 구축할 수도 있습니다. 계정 ID 또는 별칭과 역할 이름을 다음 예제의 파라미터 두 개로 대치합니다.

`https://signin.aws.amazon.com/switchrole?account=your_account_ID_or_alias&roleName=optional_path/role_name`

사용자를 [사용자에서 IAM 역할로 전환(콘솔)](id_roles_use_switch-role-console.md) 섹션으로 안내하여 프로세스를 살펴보도록 하는 것이 좋습니다. 역할을 수임할 때 발생할 수 있는 일반적인 문제를 해결하려면 [역할을 수임할 수 없음](troubleshoot_roles.md#troubleshoot_roles_cant-assume-role) 섹션을 참조하세요.

**고려 사항**
+ 프로그래밍 방식으로 역할을 생성하는 경우에는, 경로와 이름을 사용하여 역할을 생성할 수 있습니다. 이 경우 사용자에게 전체 경로와 역할 이름을 제공해야만 사용자가 AWS Management Console의 **역할 전환** 페이지에 입력할 수 있습니다. 예를 들면 `division_abc/subdivision_efg/role_XYZ`입니다.
+ 프로그래밍 방식으로 역할을 생성하는 경우에는 최대 512자의 `Path`와 `RoleName`을 추가할 수 있습니다. 역할 이름은 최대 64자일 수 있습니다. 그러나 AWS Management Console에서 **역할 전환(Switch Role)** 기능을 통해 역할을 사용하려면 `Path`와 `RoleName`을 합해 64자를 초과할 수 없습니다.
+ 보안을 위해 [AWS CloudTrail 로그를 검토](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds)하여 AWS에서 누가 작업을 수행했는지 확인할 수 있습니다. 역할 신뢰 정책에서 `sts:SourceIdentity` 조건 키를 사용하여 사용자가 역할을 수임할 때 자격 증명을 지정하도록 요구할 수 있습니다. 예를 들어 IAM 사용자가 자신의 사용자 이름을 소스 자격 증명으로 지정하도록 요구할 수 있습니다. 이를 통해 AWS에서 특정 작업을 수행한 사용자를 확인할 수 있습니다. 자세한 내용은 [`sts:SourceIdentity`](reference_policies_iam-condition-keys.md#ck_sourceidentity) 섹션을 참조하세요. 역할 신뢰 정책에서 [`sts:RoleSessionName`](reference_policies_iam-condition-keys.md#ck_rolesessionname)을 사용하여 사용자가 역할을 수임할 때 세션 이름을 지정하도록 요구할 수 있습니다. 이렇게 하면 여러 보안 주체가 한 역할을 사용할 때 역할 세션 간을 구분할 수 있습니다.

# 사용자에게 AWS 서비스에 역할을 전달할 권한 부여
<a name="id_roles_use_passrole"></a>

다수의 AWS 서비스를 구성하려면 IAM 역할을 서비스에 *전달*해야 합니다. 그러면 서비스가 나중에 역할을 수임하고 사용자 대신 작업을 수행할 수 있습니다. 대부분의 서비스에서 설정 중 한 번만 서비스에 역할을 전달하면 됩니다. 서비스가 역할을 수임할 때마다 전달할 필요가 없습니다. 예를 들어 Amazon EC2 인스턴스에서 실행 중인 애플리케이션이 있다고 가정합니다. 해당 애플리케이션에는 인증을 위한 임시 자격 증명과 AWS에서 작업을 수행할 수 있는 애플리케이션을 승인할 권한이 필요합니다. 애플리케이션을 설정할 때는 역할을 Amazon EC2에 전달하여 해당 자격 증명을 제공하는 인스턴스와 함께 사용해야 합니다. IAM 정책을 역할에 연결하여 인스턴스에서 실행 중인 애플리케이션에 대한 권한을 정의합니다. 애플리케이션은 역할이 허용하는 작업을 수행해야 할 때마다 역할을 수임합니다.

AWS 서비스에 역할(및 그 권한)을 전달하려면 사용자에게 서비스에 *역할을 전달*할 권한이 있어야 합니다. 이를 통해 관리자는 승인된 사용자만 권한이 부여된 역할을 통해 서비스를 구성하도록 할 수 있습니다. 사용자가 AWS 서비스에 역할을 전달하도록 하려면 해당 사용자의 IAM 사용자, 역할 또는 그룹에 `PassRole` 권한을 부여해야 합니다.

**주의**  
같은 AWS 계정을 공유하는 서비스로 IAM 역할을 전달하기 위해서는 `PassRole` 권한만 이용할 수 있습니다. 계정 A의 역할을 계정 B의 서비스에 넘겨주려면 먼저 계정 A의 역할을 맡을 수 있는 IAM 역할을 계정 B에 생성한 다음 계정 B의 역할을 서비스에 넘겨야 합니다. 자세한 내용은 [IAM의 크로스 계정 리소스 액세스](access_policies-cross-account-resource-access.md)을 참조하세요.
역할에 태그를 지정한 다음 `iam:PassRole` 작업과 함께 정책의 `ResourceTag` 조건 키를 사용하는 것으로 역할을 전달할 수 있는 사람을 제어하려고 하지 마십시오. 이 접근법은 신뢰할 수 있는 결과를 가져오지 못합니다.

`PassRole` 권한을 설정할 때 사용자에게 부여하려는 역할보다 더 많은 권한이 있는 역할을 사용자가 넘기지 않도록 해야 합니다. 예를 들어 Alice가 Amazon S3 작업을 수행하는 것이 허용되지 않을 수 있습니다. Alice가 Amazon S3 작업을 허용하는 서비스에 역할을 넘길 수 있으면 해당 서비스에서 작업 실행 시 Alice를 대신하여 Amazon S3 작업을 수행할 수 있습니다.

서비스 연결 역할을 지정하는 경우 해당 역할을 서비스에 전달할 권한도 있어야 합니다. 일부 서비스는 서비스에서 작업을 수행할 때 계정에 서비스 연결 역할을 자동으로 생성합니다. 예를 들어, Amazon EC2 Auto Scaling에서는 사용자가 Auto Scaling 그룹을 처음으로 생성할 때 사용자를 대신해 `AWSServiceRoleForAutoScaling` 서비스 연결 역할을 생성합니다. Auto Scaling을 생성할 때 `iam:PassRole` 권한이 없는 상태에서 서비스 연결 역할을 지정하려고 하면 오류가 발생합니다. 역할을 명시적으로 지정하지 않는 경우에는 `iam:PassRole` 권한이 필요하지 않으며, 기본적으로 해당 그룹에 대해 수행하는 모든 작업에 `AWSServiceRoleForAutoScaling` 역할이 사용됩니다. 서비스 연결 역할을 지원하는 서비스를 알아보려면 [AWS IAM으로 작업하는 서비스](reference_aws-services-that-work-with-iam.md) 섹션을 참조하세요. 서비스에서 작업 수행 시 자동으로 서비스 연결 역할을 생성하는 서비스를 알아보려면 **예** 링크를 선택하고 해당 서비스에 대한 서비스 연결 역할 설명서를 확인합니다.

사용자는 역할을 사용하여 서비스에 권한을 할당하는 API 작업에서 파라미터로 역할 ARN을 전달할 수 있습니다. 그런 다음 서비스는 해당 사용자에게 `iam:PassRole` 권한이 있는지 확인합니다. 사용자가 승인된 역할만 전달하도록 제한하려면 IAM 정책 문의 `Resources` 요소로 `iam:PassRole` 권한을 필터링하면 됩니다.

JSON 정책의 `Condition` 요소를 사용하여 모든 AWS 요청의 요청 컨텍스트에 포함된 키 값을 테스트할 수 있습니다. 정책에서 조건 키를 사용하는 방법에 대한 자세한 내용은 [IAM JSON 정책 요소: Condition](reference_policies_elements_condition.md) 섹션을 참조하세요. `iam:PassedToService` 조건 키는 역할을 전달할 수 있는 서비스의 서비스 보안 주체를 지정하는 데 사용될 수 있습니다. 정책에서 `iam:PassedToService` 조건 키를 사용하는 방법에 대한 자세한 내용은 [iam:PassedToService](reference_policies_iam-condition-keys.md#ck_PassedToService)를 참조하세요.

**예제 1.**  
인스턴스를 시작한 후 사용자에게 Amazon EC2 서비스에 승인된 역할 집합을 전달할 수 있는 권한을 부여하려 한다고 가정하겠습니다. 다음 세 가지 요소가 필요합니다.
+ 역할이 수행할 수 있는 작업을 결정하는 역할에 연결된 IAM *권한 정책*입니다. 역할이 수행해야 하는 작업 및 역할이 그러한 작업을 수행하는 데 필요한 리소스만으로 권한을 한정할 수 있습니다. AWS 관리형 또는 고객이 생성한 IAM 권한 정책을 사용할 수 있습니다.

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": {
          "Effect": "Allow",
          "Action": [ "A list of the permissions the role is allowed to use" ],
          "Resource": [ "A list of the resources the role is allowed to access" ]
      }
  }
  ```

------
+ 서비스에서 역할을 위임하도록 허용하는 역할에 대한 *신뢰 정책*입니다. 예를 들어, `UpdateAssumeRolePolicy` 작업이 있는 역할에 다음과 같은 신뢰 정책을 연결할 수 있습니다. 이 신뢰 정책을 통해 Amazon EC2는 해당 역할 및 역할에 연결된 권한을 사용할 수 있습니다.

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": {
          "Sid": "TrustPolicyStatementThatAllowsEC2ServiceToAssumeTheAttachedRole",
          "Effect": "Allow",
          "Principal": { "Service": "ec2.amazonaws.com" },
         "Action": "sts:AssumeRole"
      }
  }
  ```

------
+ 사용자가 승인된 역할만 전달하도록 허용하는 IAM 사용자에 연결된 IAM *권한 정책*입니다. 일반적으로 `iam:GetRole`을(를) `iam:PassRole`에 추가하여 사용자가 전달할 역할의 세부 정보를 얻을 수 있습니다. 이 예제에서 사용자는 지정된 계정에 있으며 다음과 같이 이름이 `EC2-roles-for-XYZ-`(으)로 시작하는 역할만 전달할 수 있습니다.

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "iam:GetRole",
                  "iam:PassRole"
              ],
              "Resource": "arn:aws:iam::111122223333:role/EC2-roles-for-XYZ-*"
          }
      ]
  }
  ```

------

이제 사용자는 할당된 역할로 Amazon EC2 인스턴스를 시작할 수 있습니다. 이 인스턴스에서 실행되는 애플리케이션은 인스턴스 프로파일 메타데이터를 통해 역할의 임시 자격 증명에 액세스할 수 있습니다. 역할과 연결된 권한 정책은 인스턴스가 수행할 수 있는 작업을 결정합니다.

**예제 2.**  
Amazon Relational Database Service(Amazon RDS)는 **Enhanced Monitoring(확장 모니터링)**이라는 기능을 지원합니다. 이 기능을 사용하면 Amazon RDS에서 에이전트를 사용하여 데이터베이스 인스턴스를 모니터링할 수 있습니다. 또한 Amazon RDS가 Amazon CloudWatch Logs에 지표를 로그할 수도 있습니다. 이 기능을 사용하려면 서비스 역할을 생성하여 지표를 모니터링하고 로그에 작성할 수 있는 권한을 Amazon RDS에 부여해야 합니다.

**Amazon RDS 확장 모니터링을 위한 역할을 생성하려면**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. **역할**을 선택한 다음 **역할 생성**을 선택합니다.

1. **AWS 서비스** 역할 유형을 선택한 후 **다른 AWS 서비스의 사용 사례**에서 **RDS** 서비스를 선택합니다. **RDS - 확장 모니터링(RDS - Enhanced Monitoring)**과 **다음(Next)**을 차례로 선택합니다.

1. **AmazonRDSEnhancedMonitoringRole** 권한 정책을 선택합니다.

1. **다음**을 선택합니다.

1. **역할 이름(Role name)**에 이 역할의 목적을 나타내는 역할 이름을 입력합니다. 역할 이름은 AWS 계정 내에서 고유해야 합니다. 역할 이름이 정책에서 또는 ARN의 일부로 사용되는 경우 역할 이름은 대소문자를 구분합니다. 콘솔에서 고객에게 역할 이름이 표시되는 경우(예: 로그인 프로세스 중) 역할 이름은 대소문자를 구분하지 않습니다. 다양한 엔터티가 역할을 참조할 수 있기 때문에 역할이 생성된 후에는 역할 이름을 편집할 수 없습니다.

1. (선택 사항)**설명**에 새 역할에 대한 설명을 입력합니다.

1. (선택 사항) 태그를 키 값 페어로 연결하여 메타데이터를 사용자에게 추가합니다. IAM에서의 태그 사용에 대한 자세한 내용은 [AWS Identity and Access Management 리소스용 태그](id_tags.md) 섹션을 참조하세요.

1. 역할을 검토한 다음 **역할 생성**을 선택합니다.

그러면 역할이 `monitoring.rds.amazonaws.com` 서비스에 해당 역할을 수임할 권한을 부여하는 신뢰 정책을 자동으로 얻습니다. 그러면 Amazon RDS는 `AmazonRDSEnhancedMonitoringRole` 정책에서 허용하는 모든 작업을 수행할 수 있습니다.

Enhanced Monitoring에 액세스하려는 사용자는 다음과 같이 사용자가 RDS 역할을 나열하도록 허용하는 문과 역할을 전달할 수 있도록 허용하는 문이 포함된 정책이 필요합니다. 계정 번호를 사용하여 역할 이름을 6단계에서 입력한 이름으로 바꿉니다.

```
    {
      "Sid": "PolicyStatementToAllowUserToListRoles",
      "Effect": "Allow",
      "Action": ["iam:ListRoles"],
      "Resource": "*"
    },
    {
        "Sid": "PolicyStatementToAllowUserToPassOneSpecificRole",
        "Effect": "Allow",
        "Action": [ "iam:PassRole" ],
        "Resource": "arn:aws:iam::account-id:role/RDS-Monitoring-Role"
    }
```

이 문을 다른 정책의 문과 결합하거나 고유 정책에 포함시킬 수 있습니다. 사용자가 `RDS-`로 시작하는 모든 역할을 전달할 수 있도록 지정하려면 다음과 같이 리소스 ARN의 역할 이름을 와일드카드로 바꿉니다.

```
        "Resource": "arn:aws:iam::account-id:role/RDS-*"
```

## AWS CloudTrail 로그의 `iam:PassRole` 작업
<a name="id_roles_use_passrole_logs"></a>

 `PassRole`은 API 호출이 아닙니다. `PassRole`은 권한입니다. 즉, IAM `PassRole`에 대해 CloudTrail 로그가 생성되지 않습니다. CloudTrail에서 어떤 AWS 서비스에 어떤 역할이 전달되는지 검토하려면 역할을 받는 AWS 리소스를 생성하거나 수정한 CloudTrail 로그를 검토해야 합니다. 예를 들어, 역할은 생성 시 AWS Lambda 함수에 전달됩니다. `CreateFunction` 작업에 대한 로그에는 함수에 전달된 역할의 레코드가 표시됩니다.

# IAM 역할 임시 보안 자격 증명 취소
<a name="id_roles_use_revoke-sessions"></a>

**주의**  
이 페이지의 단계대로 수행하면, 역할을 수임하여 만들어진 현재 세션의 모든 사용자는 모든 AWS 작업 및 리소스에 액세스할 수 없게 됩니다. 이로 인해 사용자가 저장하지 않은 작업이 사라질 수 있습니다.

세션 지속 시간을 길게 하여(예: 12시간) 사용자가 AWS Management Console에 액세스할 수 있도록 하면 사용자의 임시 자격 증명이 금방 만료되지 않습니다. 사용자가 허가 받지 않은 제3자에게 실수로 보안 인증 정보를 노출한 경우, 해당 제3자는 세션의 지속 기간 동안 액세스 권한을 가지게 됩니다. 그러나 필요하다면 특정 시점 이전에 발행된 역할의 자격 증명에 대한 모든 권한을 즉시 취소할 수 있습니다. 그러면 지정한 시점 이전에 발행된 해당 역할의 임시 자격 증명은 모두 무효가 됩니다. 이에 따라 모든 사용자는 다시 인증을 받고 새 보안 인증 정보를 요청해야 합니다.

 

**참고**  
*[서비스 연결 역할](id_roles.md#iam-term-service-linked-role)*에 대한 세션은 취소할 수 없습니다.

이 주제의 절차에 따라 역할의 권한을 취소하면 AWS는 모든 작업에 대한 모든 권한을 거부하는 새 인라인 정책을 만들어 해당 역할에 연결합니다. 여기에는 권한을 취소한 시점 *이전에* 역할을 위임한 사용자에게만 제한을 가하는 조건이 포함됩니다. 권한을 취소한 *이후에* 역할을 위임한 사용자에게는 거부 정책이 적용되지 않습니다.

액세스 거부에 대한 자세한 내용은 [임시 보안 자격 증명에 대한 권한 비활성화](id_credentials_temp_control-access_disable-perms.md) 섹션을 참조하세요.

**중요**  
이 거부 정책은 콘솔 세션의 지속 기간이 긴 사용자만이 아니라 지정된 역할의 모든 사용자에게 적용됩니다.

## 역할의 세션 권한을 취소하기 위한 최소 권한
<a name="revoke-session-permissions"></a>

역할의 세션 권한을 취소하려면 해당 역할에 대한 `PutRolePolicy` 권한이 있어야 합니다. 이렇게 하면 해당 역할에 `AWSRevokeOlderSessions` 인라인 정책을 연결할 수 있게 됩니다.

## 세션 권한 취소
<a name="revoke-session"></a>

역할에서 세션 권한을 취소하여 역할을 수임한 사용자에게 모든 권한을 거부할 수 있습니다.

**참고**  
IAM Identity Center 권한 세트에서 생성된 역할은 IAM에서 편집할 수 없습니다. IAM Identity Center에서 사용자의 활성 권한 세트 세션을 취소해야 합니다. 자세한 내용은 *IAM Identity Center 사용 설명서*의 [권한 세트에 의해 생성된 활성 IAM 역할 세션 취소](https://docs.aws.amazon.com/singlesignon/latest/userguide/useraccess.html#revoke-user-permissions)를 참조하세요.

**역할 자격 증명의 현재 사용자에 대해 모든 권한을 즉시 거부하려면**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **역할**을 선택한 다음, 권한을 취소할 역할의 이름(확인란 아님)을 선택하세요.

1. 선택한 역할의 **요약** 페이지에서 **Revoke sessions(세션 취소)** 탭을 선택합니다.

1. **Revoke sessions(세션 취소)** 탭에서 **Revoke active sessions(활성 세션 취소)**를 선택합니다.

1. AWS에 작업 확인 메시지가 나타납니다. **이 역할에 대한 모든 활성 세션을 취소함을 인정합니다.** 확인란을 선택하고 대화 상자에서 **활성 세션 취소**를 선택하세요.

   그런 다음 IAM은 역할에 `AWSRevokeOlderSessions`라는 정책을 연결합니다. **Revoke active sessions**(활성 세션 취소)를 선택하면 정책은 과거에 해당 역할이 부여된 사용자에 대한 모든 액세스를 거부하고 이후의 약 30초 동안에도 액세스를 거부합니다. 이 미래 시간 선택은 특정 리전에 업데이트된 정책이 시행되기 전에 획득되거나 갱신된 새 세션을 처리하기 위해 정책의 전파 지연을 고려합니다. Revoke active sessions(활성 세션 취소)를 선택한 후 약 30초 이후에 역할이 부여되는 사용자는 영향을 받지 않습니다. 변경 사항이 즉시 표시되지 않는 이유를 알아보려면 [변경 사항이 매번 즉시 표시되는 것은 아닙니다](troubleshoot.md#troubleshoot_general_eventual-consistency) 섹션을 참조하세요.

**참고**  
나중에 **Revoke active sessions**(활성 세션 취소)를 다시 선택하는 경우, 정책의 날짜/시간 스탬프가 새로 고쳐지면서 새로 지정된 시간 이전에 역할을 부여된 모든 사용자의 모든 권한을 거부하게 됩니다.

이러한 식으로 세션이 취소된 유효한 사용자는 작업을 계속하려면 새 세션을 위한 임시 자격 증명을 가져와야 합니다. AWS CLI은(는) 보안 인증이 만료될 때까지 이를 캐시합니다. CLI가 더 이상 유효하지 않은 캐시된 자격 증명을 강제로 삭제하고 새로 고치게 하려면 다음 명령 중 하나를 실행합니다.

**Linux, macOS 또는 Unix**

```
$ rm -r ~/.aws/cli/cache
```

**Windows**

```
C:\> del /s /q %UserProfile%\.aws\cli\cache
```

## 지정된 시간 전에 세션 권한 취소
<a name="revoke-session-policy"></a>

 또한 AWS CLI 또는 SDK를 사용하여 정책의 조건 요소에서 `aws:TokenIssueTime` 키 값을 지정하여 원하는 시간에 세션 권한을 취소할 수도 있습니다.

이 정책은 `aws:TokenIssueTime`의 값이 지정된 날짜와 시각보다 이른 경우 모든 권한을 거부합니다. `aws:TokenIssueTime`의 값은 임시 보안 자격 증명이 생성된 정확한 시간과 일치합니다. `aws:TokenIssueTime` 값은 임시 보안 인증으로 로그인된 AWS 요청의 컨텍스트에서만 존재하므로 정책의 Deny 문은 IAM 사용자의 장기 보안 인증으로 로그인한 요청에는 영향을 미치지 않습니다.

이 정책도 역할에 연결할 수 있습니다. 이 경우 정책은 지정된 시각 및 날짜 이전에 그 역할에 의해 생성된 임시 보안 자격 증명에만 영향을 미칩니다.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "DateLessThan": {"aws:TokenIssueTime": "2014-05-07T23:47:00Z"}
    }
  }
}
```

------

이러한 식으로 세션이 취소된 유효한 사용자는 작업을 계속하려면 새 세션을 위한 임시 자격 증명을 가져와야 합니다. AWS CLI은(는) 보안 인증이 만료될 때까지 이를 캐시합니다. CLI가 더 이상 유효하지 않은 캐시된 자격 증명을 강제로 삭제하고 새로 고치게 하려면 다음 명령 중 하나를 실행합니다.

**Linux, macOS 또는 Unix**

```
$ rm -r ~/.aws/cli/cache
```

**Windows**

```
C:\> del /s /q %UserProfile%\.aws\cli\cache
```

# 서비스 연결 역할 업데이트
<a name="id_roles_update-service-linked-role"></a>

서비스 연결 역할을 편집하는 데 사용하는 방법은 서비스에 따라 다릅니다. 일부 서비스는 사용자가 서비스 콘솔, API 또는 CLI에서 서비스 연결 역할의 권한을 편집할 수 있도록 허용합니다. 하지만 서비스 연결 역할을 만든 후에는 다양한 개체가 역할을 참조할 수 있기 때문에 역할 이름을 변경할 수 없습니다. IAM 콘솔, API, CLI에서 역할의 설명을 편집할 수 있습니다.

서비스 연결 역할의 사용을 지원하는 서비스에 대한 자세한 정보는 [AWS IAM으로 작업하는 서비스](reference_aws-services-that-work-with-iam.md)를 참조하고 **서비스 연결 역할** 열에 **예**가 있는 서비스를 찾습니다. 서비스가 서비스 연결 역할 편집을 지원하는지 여부를 알아보려면 **예** 링크를 선택하여 해당 서비스의 서비스 연결 역할 설명서 섹션을 참조하세요.

## 서비스 연결 역할 설명 편집(콘솔)
<a name="edit-service-linked-role-iam-console"></a>

IAM 콘솔을 사용하여 서비스 연결 역할의 설명을 편집할 수 있습니다.

**서비스 연결 역할의 설명을 편집하는 방법(콘솔)**

1. IAM 콘솔의 탐색 창에서 **역할**을 선택합니다.

1. 변경할 역할 이름을 선택합니다.

1. **역할 설명**의 맨 오른쪽에서 **편집**을 선택합니다.

1. 상자에 새 설명을 입력하고 **저장**을 선택합니다.

## 서비스 연결 역할 설명 편집(AWS CLI)
<a name="edit-service-linked-role-iam-cli"></a>

AWS CLI에서 IAM 명령을 사용하여 서비스 연결 역할의 설명을 편집할 수 있습니다.

**서비스 연결 역할의 설명을 변경하려면(AWS CLI)**

1. (옵션) 역할의 현재 설명을 보려면 다음 명령 중 하나를 실행합니다.

   ```
   aws iam [get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html) --role-name ROLE-NAME
   ```

   CLI 명령에서 역할을 참조하려면 ARN이 아니라 역할 이름을 사용해야 합니다. 예를 들어, 어떤 역할의 ARN이 `arn:aws:iam::123456789012:role/myrole`인 경우 참조할 역할은 **myrole**입니다.

1. 서비스 연결 역할의 설명을 업데이트하려면 다음 명령을 실행합니다.

   ```
   aws iam [update-role](https://docs.aws.amazon.com/cli/latest/reference/iam/update-role.html) --role-name ROLE-NAME --description OPTIONAL-DESCRIPTION
   ```

## 서비스 연결 역할 설명 편집(AWS API)
<a name="edit-service-linked-role-iam-api"></a>

AWS API를 사용하여 서비스 연결 역할의 설명을 편집할 수 있습니다.

**서비스 연결 역할의 설명을 변경하려면(AWS API 사용)**

1. (옵션) 역할의 현재 설명을 보려면 다음 작업을 호출하고 역할 이름을 지정합니다.

   AWS API: [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) 

1. 역할의 설명을 업데이트하려면 다음 작업을 호출하고 역할 이름 및 설명(선택 사항)을 지정합니다.

   AWS API: [UpdateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRole.html) 

# 역할 트러스트 정책 업데이트
<a name="id_roles_update-role-trust-policy"></a>

역할을 맡을 수 있는 주체를 바꾸려면 역할의 신뢰 정책을 변경해야 합니다. *[서비스 연결 역할](id_roles.md#iam-term-service-linked-role)*에 대한 신뢰 정책을 수정할 수 없습니다.

**참고**  
사용자가 역할 신뢰 정책에 보안 주체로 나열되지만 역할을 수임할 수 없는 경우 사용자의 [권한 경계](access_policies_boundaries.md)를 확인하세요. 사용자에 대한 권한 경계가 설정된 경우 권한 경계에서 `sts:AssumeRole` 작업이 허용되어야 합니다.
사용자가 역할 세션 내에서 현재 역할을 다시 수임할 수 있도록 허용하려면 역할 ARN 또는 AWS 계정 ARN을 역할 신뢰 정책의 보안 주체로 지정합니다. Amazon EC2, Amazon ECS, Amazon EKS, Lambda와 같이 컴퓨팅 리소스를 제공하는 AWS 서비스는 임시 보안 인증을 제공하며 해당 보안 인증을 자동으로 업데이트합니다. 이렇게 하면 항상 유효한 자격 증명 집합을 가질 수 있습니다. 이러한 서비스의 경우 임시 자격 증명을 획득하기 위해 현재 역할을 다시 수임할 필요는 없습니다. 하지만 [세션 태그](id_session-tags.md) 또는 [세션 정책](access_policies.md#policies_session)을 전달하려는 경우 현재 역할을 다시 수임해야 합니다.


## 역할 트러스트 정책 업데이트(콘솔)
<a name="id_roles_update-trust-policy-console"></a>

**AWS Management Console에서 역할 트러스트 정책 변경**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. IAM 콘솔의 탐색 창에서 **역할(Roles)**을 선택합니다.

1. 계정의 역할 목록에서 변경할 역할의 이름을 선택합니다.

1. **신뢰 관계** 탭을 선택한 후 **신뢰 정책 편집**을 선택합니다.

1. 필요에 따라 신뢰 정책을 편집합니다. 역할을 위임할 수 있는 보안 주체를 추가하려면 `Principal` 요소에 해당 보안 주체를 지정하세요. 예를 들어 다음 정책 조각은 `Principal` 요소에서 AWS 계정 2개를 참조하는 방법을 나타냅니다.

   ```
   "Principal": {
     "AWS": [
       "arn:aws:iam::111122223333:root",
       "arn:aws:iam::444455556666:root"
     ]
   },
   ```

   다른 계정에서 보안 주체를 지정할 경우 역할의 신뢰 정책에 계정을 추가하는 것은 신뢰 관계 설정의 절반밖에 되지 않는다는 것을 유념하세요. 기본적으로 신뢰 계정의 어떠한 사용자도 역할을 위임할 수 없습니다. 새로이 신뢰받는 계정에 대한 관리자는 사용자가 역할을 수임할 수 있는 권한을 허용해야 합니다. 이를 위해 관리자는 사용자와 연결된 정책을 생성 또는 편집하여 `sts:AssumeRole` 작업에 대한 사용자 액세스를 허용합니다. 자세한 정보는 다음 절차 또는 [사용자에게 역할을 전환할 권한 부여](id_roles_use_permissions-to-switch.md) 섹션을 참조하세요.

   다음 정책 조각은 `Principal` 요소에서 두 가지 AWS 서비스를 참조하는 방법을 보여줍니다.

   ```
   "Principal": {
     "Service": [
       "opsworks.amazonaws.com",
       "ec2.amazonaws.com"
     ]
   },
   ```

1. 신뢰 정책 편집을 마쳤으면 **정책 업데이트(Update policy)**를 선택하여 변경 사항을 저장합니다.

   정책 구조 및 구문에 대한 자세한 정보는 [AWS Identity and Access Management의 정책 및 권한](access_policies.md) 단원과 [IAM JSON 정책 요소 참조](reference_policies_elements.md) 섹션을 참조하세요.

**신뢰할 수 있는 외부 계정의 사용자가 역할을 사용할 수 있도록 허용하려면(콘솔 사용)**

자세한 정보와 이 절차에 대한 세부 정보는 [사용자에게 역할을 전환할 권한 부여](id_roles_use_permissions-to-switch.md) 섹션을 참조하세요.

1. 신뢰할 수 있는 외부 AWS 계정에 로그인합니다.

1. 사용자 또는 그룹 중 권한을 어디에 추가할지 결정합니다. 결정에 따라 IAM 콘솔의 탐색 창에서 **사용자(Users)** 또는 **사용자 그룹(User groups)**을 선택합니다.

1. 액세스 권한을 부여하려는 사용자나 그룹의 이름을 선택한 후 **권한** 탭을 선택합니다.

1. 다음 중 하나를 수행하세요.
   + 고객 관리형 정책을 편집하려면 정책 이름을 선택하고 **정책 편집**을 선택한 다음 **JSON** 탭을 선택합니다. AWS 관리형 정책은 편집할 수 없습니다. AWS 관리형 정책은 AWS 아이콘(![\[Orange cube icon indicating a policy is managed by AWS.\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/policy_icon.png))으로 나타납니다. AWS 관리형 정책과 고객 관리형 정책의 차이점에 대한 자세한 정보는 [관리형 정책과 인라인 정책](access_policies_managed-vs-inline.md) 섹션을 참조하세요.
   + 인라인 정책을 편집하려면 정책 이름 옆에 있는 화살표를 선택하고 **정책 편집**을 선택합니다.

1. 정책 편집기에서 새로운 `Statement` 요소를 추가하여 다음과 같이 지정합니다.

   ```
   {
     "Effect": "Allow",
     "Action": "sts:AssumeRole",
     "Resource": "arn:aws:iam::ACCOUNT-ID:role/ROLE-NAME"
   }
   ```

   설명문의 ARN을 사용자가 수임할 수 있는 역할의 ARN으로 바꿉니다.

1. 화면의 메시지에 따라 정책 편집을 마칩니다.

## 역할 트러스트 정책 업데이트(AWS CLI)
<a name="id_roles-update-trust-policy-cli"></a>

AWS CLI를 사용하여 역할을 수임할 수 있는 주체를 변경할 수 있습니다.

**역할 신뢰 정책을 수정하려면(AWS CLI)**

1. (선택 사항) 수정할 역할의 이름을 모르는 경우 다음 명령을 실행하여 계정의 역할을 나열합니다.
   + [aws iam list-roles](https://docs.aws.amazon.com/cli/latest/reference/iam/list-roles.html)

1. (옵션) 현재 역할의 신뢰 정책을 확인하려면 다음 명령을 실행합니다.
   + [aws iam get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html)

1. 역할에 액세스할 수 있는 신뢰할 수 있는 보안 주체를 변경하려면 업데이트된 신뢰 정책을 추가하여 텍스트 파일을 생성합니다. 정책 구조를 작성할 때는 어떤 텍스트 편집기든 사용할 수 있습니다.

   예를 들어 다음 신뢰 정책 조각은 `Principal` 요소에서 AWS 계정 2개를 참조하는 방법을 나타냅니다. 사용자가 개별 AWS 계정 2개를 사용하도록 허용하여 이 역할을 수임하도록 합니다.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": {
           "Effect": "Allow",
           "Principal": {"AWS": [
               "arn:aws:iam::111122223333:root",
               "arn:aws:iam::444455556666:root"
           ]},
           "Action": "sts:AssumeRole"
       }
   }
   ```

------

   다른 계정에서 보안 주체를 지정할 경우 역할의 신뢰 정책에 계정을 추가하는 것은 신뢰 관계 설정의 절반밖에 되지 않는다는 것을 유념하세요. 기본적으로 신뢰 계정의 어떠한 사용자도 역할을 위임할 수 없습니다. 새로이 신뢰받는 계정에 대한 관리자는 사용자가 역할을 수임할 수 있는 권한을 허용해야 합니다. 이를 위해 관리자는 사용자와 연결된 정책을 생성 또는 편집하여 `sts:AssumeRole` 작업에 대한 사용자 액세스를 허용합니다. 자세한 정보는 다음 절차 또는 [사용자에게 역할을 전환할 권한 부여](id_roles_use_permissions-to-switch.md) 섹션을 참조하세요.

1. 방금 생성한 파일을 사용하여 신뢰 정책을 업데이트하려면 다음 명령을 실행합니다.
   + [aws iam update-assume-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/update-assume-role-policy.html)

**신뢰할 수 있는 외부 계정 사용자에게 역할 사용을 허용하려면(AWS CLI)**

자세한 정보와 이 절차에 대한 세부 정보는 [사용자에게 역할을 전환할 권한 부여](id_roles_use_permissions-to-switch.md) 섹션을 참조하세요.

1. 역할에 대한 권한 정책을 포함하는 JSON 파일을 생성하여 역할을 수임할 수 있는 권한을 허용합니다. 예를 들어 다음 정책에는 필요한 최소 권한이 포함되어 있습니다.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": {
           "Effect": "Allow",
           "Action": "sts:AssumeRole",
           "Resource": "arn:aws:iam::111122223333:role/ROLE-NAME"
       }
   }
   ```

------

   설명문의 ARN을 사용자가 수임할 수 있는 역할의 ARN으로 바꿉니다.

1. 다음 명령을 실행하여 신뢰 정책을 포함하는 JSON 파일을 IAM에 업로드합니다.
   + [aws iam create-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/create-policy.html)

   이 명령의 출력 화면에는 정책의 ARN이 포함됩니다. 이후 단계에서 사용해야 하므로 이 ARN을 기록해 두세요.

1. 정책을 연결할 사용자 또는 그룹을 결정합니다. 원하는 사용자 또는 그룹의 이름을 모르는 경우에는 다음 명령 중 하나를 사용하여 계정에 속한 사용자 또는 그룹 목록을 조회합니다.
   + [aws iam list-users](https://docs.aws.amazon.com/cli/latest/reference/iam/list-users.html)
   + [aws iam list-groups](https://docs.aws.amazon.com/cli/latest/reference/iam/list-groups.html)

1. 다음 명령 중 한 가지를 사용하여 이전 단계에서 생성한 정책을 사용자 또는 그룹에게 추가합니다.
   + [aws iam attach-user-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-user-policy.html)
   + [aws iam attach-group-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/attach-group-policy.html)

## 역할 트러스트 정책 업데이트(AWS API)
<a name="id_roles-update-trust-policy-api"></a>

AWS API를 사용하여 역할을 수임할 수 있는 주체를 변경할 수 있습니다.

**역할 신뢰 정책을 수정하려면(AWS API)**

1. (선택 사항) 변경할 역할의 이름을 모르는 경우 다음 연산을 호출하여 계정의 역할을 나열합니다.
   + [ListRoles](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListRoles.html)

1. (옵션) 현재 역할의 신뢰 정책을 확인하려면 다음 연산을 호출합니다.
   + [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)

1. 역할에 액세스할 수 있는 신뢰할 수 있는 보안 주체를 변경하려면 업데이트된 신뢰 정책을 추가하여 텍스트 파일을 생성합니다. 정책 구조를 작성할 때는 어떤 텍스트 편집기든 사용할 수 있습니다.

   예를 들어 다음 신뢰 정책 조각은 `Principal` 요소에서 AWS 계정 2개를 참조하는 방법을 나타냅니다. 사용자가 개별 AWS 계정 2개를 사용하도록 허용하여 이 역할을 수임하도록 합니다.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": {
           "Effect": "Allow",
           "Principal": {"AWS": [
               "arn:aws:iam::111122223333:root",
               "arn:aws:iam::444455556666:root"
           ]},
           "Action": "sts:AssumeRole"
       }
   }
   ```

------

   다른 계정에서 보안 주체를 지정할 경우 역할의 신뢰 정책에 계정을 추가하는 것은 신뢰 관계 설정의 절반밖에 되지 않는다는 것을 유념하세요. 기본적으로 신뢰 계정의 어떠한 사용자도 역할을 위임할 수 없습니다. 새로이 신뢰받는 계정에 대한 관리자는 사용자가 역할을 수임할 수 있는 권한을 허용해야 합니다. 이를 위해 관리자는 사용자와 연결된 정책을 생성 또는 편집하여 `sts:AssumeRole` 작업에 대한 사용자 액세스를 허용합니다. 자세한 정보는 다음 절차 또는 [사용자에게 역할을 전환할 권한 부여](id_roles_use_permissions-to-switch.md) 섹션을 참조하세요.

1. 방금 생성한 파일을 사용하여 신뢰 정책을 업데이트하려면 다음 작업을 호출합니다.
   + [UpdateAssumeRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateAssumeRolePolicy.html)

**신뢰할 수 있는 외부 계정 사용자에게 역할 사용을 허용하려면(AWS API)**

자세한 정보와 이 절차에 대한 세부 정보는 [사용자에게 역할을 전환할 권한 부여](id_roles_use_permissions-to-switch.md) 섹션을 참조하세요.

1. 역할에 대한 권한 정책을 포함하는 JSON 파일을 생성하여 역할을 수임할 수 있는 권한을 허용합니다. 예를 들어 다음 정책에는 필요한 최소 권한이 포함되어 있습니다.

------
#### [ JSON ]

****  

   ```
   {
       "Version":"2012-10-17",		 	 	 
       "Statement": {
           "Effect": "Allow",
           "Action": "sts:AssumeRole",
           "Resource": "arn:aws:iam::111122223333:role/ROLE-NAME"
       }
   }
   ```

------

   설명문의 ARN을 사용자가 수임할 수 있는 역할의 ARN으로 바꿉니다.

1. 다음 작업을 호출하여 신뢰 정책을 포함하는 JSON 파일을 IAM에 업로드합니다.
   + [CreatePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreatePolicy.html)

   이 연산의 출력 화면에는 정책의 ARN이 포함됩니다. 이후 단계에서 사용해야 하므로 이 ARN을 기록해 두세요.

1. 정책을 연결할 사용자 또는 그룹을 결정합니다. 원하는 사용자 또는 그룹의 이름을 모르는 경우에는 다음 작업 중 하나를 호출하여 계정에 속한 사용자 또는 그룹 목록을 조회합니다.
   + [ListUsers](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListUsers.html)
   + [ListGroups](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListGroups.html)

1. 다음 연산 중 하나를 호출하여 이전 단계에서 생성한 정책을 사용자 또는 그룹에게 추가합니다.
   +  API: [AttachUserPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachUserPolicy.html)
   + [AttachGroupPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AttachGroupPolicy.html)

# 역할 권한 업데이트
<a name="id_roles_update-role-permissions"></a>

다음 절차를 사용하여 역할의 권한 정책 및 권한 경계를 업데이트합니다.

## 사전 조건: 역할 액세스 보기
<a name="roles-modify_prerequisites"></a>

역할에 대한 권한을 변경하기 전에 최근 서비스 수준 활동을 검토해야 합니다. 이 기능은 사용 중인 보안 주체(사람 또는 애플리케이션)의 액세스 권한을 제거하지 않으려는 경우 중요합니다. 마지막으로 액세스한 정보 보기에 대한 자세한 내용은 [마지막으로 액세스한 정보를 사용하여 AWS에서 권한 재정의](access_policies_last-accessed.md) 섹션을 참조하세요.

## 역할의 권한 정책 업데이트
<a name="id_roles_update-role-permissions-policy"></a>

역할이 허용하는 권한을 변경하려면, 역할의 권한 정책을 수정합니다. IAM에서 *[서비스 연결 역할](id_roles.md#iam-term-service-linked-role)*에 대한 권한 정책을 수정할 수 없습니다. 역할에 따른 서비스 내 권한 정책을 수정할 수 있는 가능성이 있습니다. 서비스에서 이 기능을 지원하는지 여부를 알아보려면 [AWS IAM으로 작업하는 서비스](reference_aws-services-that-work-with-iam.md)를 참조하고 **서비스 연결 역할(Service-linked roles)** 열에 **예(Yes)**가 있는 서비스를 찾습니다. 해당 서비스에 대한 서비스 연결 역할 설명서를 보려면 **예(Yes)** 링크를 선택합니다.

### 역할 권한 정책 업데이트(콘솔)
<a name="id_roles_update-role-permissions-policy-console"></a>

**역할이 허용하는 권한을 변경하려면(콘솔 사용)**

1. IAM 콘솔([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/))을 엽니다.

1. IAM 콘솔의 탐색 창에서 **역할**을 선택합니다.

1. 수정하려는 역할의 이름을 선택한 후 **권한** 탭을 선택합니다.

1. 다음 중 하나를 수행하세요.
   + 기존의 고객 관리형 정책을 편집하려면 정책 이름을 선택한 후 **정책 편집**을 선택합니다.
**참고**  
AWS 관리형 정책은 편집할 수 없습니다. AWS 관리형 정책은 AWS 아이콘(![\[Orange cube icon indicating a policy is managed by AWS.\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/policy_icon.png))으로 나타납니다. AWS 관리형 정책과 고객 관리형 정책의 차이점에 대한 자세한 정보는 [관리형 정책과 인라인 정책](access_policies_managed-vs-inline.md) 섹션을 참조하세요.
   + 기존 관리형 정책을 역할에 연결하려면 **권한 추가(Add permissions)**를 선택한 다음 **정책 연결(Attach policies)**을 선택합니다.
   + 기존 인라인 정책을 편집하려면 정책을 확장하고 **편집(Edit)**을 선택합니다.
   + 새 인라인 정책을 포함하려면 **권한 추가(Add permissions)**를 선택한 다음 **인라인 정책 생성(Create inline policy)**을 선택합니다.
   + 역할에서 기존 정책을 제거하려면 정책 이름 옆의 확인란을 선택한 다음 **제거**를 선택합니다.

### 역할 권한 정책 업데이트(AWS CLI)
<a name="id_roles_update_permissions-policy-cli"></a>

역할이 허용하는 권한을 변경하려면, 역할의 권한 정책을 수정합니다. IAM에서 *[서비스 연결 역할](id_roles.md#iam-term-service-linked-role)*에 대한 권한 정책을 수정할 수 없습니다. 역할에 따른 서비스 내 권한 정책을 수정할 수 있는 가능성이 있습니다. 서비스에서 이 기능을 지원하는지 여부를 알아보려면 [AWS IAM으로 작업하는 서비스](reference_aws-services-that-work-with-iam.md)를 참조하고 **서비스 연결 역할(Service-linked roles)** 열에 **예(Yes)**가 있는 서비스를 찾습니다. 해당 서비스에 대한 서비스 연결 역할 설명서를 보려면 **예(Yes)** 링크를 선택합니다.

**역할에서 허용되는 권한을 변경하려면(AWS CLI)**

1. (옵션) 현재 역할과 연동되어 있는 권한을 확인하려면 다음 명령을 실행합니다.

   1. 인라인 정책을 나열하기 위한 [aws iam list-role-policies](https://docs.aws.amazon.com/cli/latest/reference/iam/list-role-policies.html)

   1. 관리형 정책을 나열하기 위한 [aws iam list-attached-role-policies](https://docs.aws.amazon.com/cli/latest/reference/iam/list-attached-role-policies.html)

1. 역할 권한의 업데이트 명령은 관리형 정책을 업데이트할 때와 인라인 정책을 업데이트할 때 서로 다릅니다.

   관리형 정책을 업데이트하려면 다음 명령을 실행하여 새로운 버전의 관리형 정책을 생성합니다.
   + [aws iam create-policy-version](https://docs.aws.amazon.com/cli/latest/reference/iam/create-policy-version.html)

   인라인 정책을 업데이트하려면 다음 명령을 실행합니다.
   + [aws iam put-role-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-policy.html)

### 역할 권한 정책 업데이트(AWS API)
<a name="id_roles_update_permissions-policy-api"></a>

역할이 허용하는 권한을 변경하려면, 역할의 권한 정책을 수정합니다. IAM에서 *[서비스 연결 역할](id_roles.md#iam-term-service-linked-role)*에 대한 권한 정책을 수정할 수 없습니다. 역할에 따른 서비스 내 권한 정책을 수정할 수 있는 가능성이 있습니다. 서비스에서 이 기능을 지원하는지 여부를 알아보려면 [AWS IAM으로 작업하는 서비스](reference_aws-services-that-work-with-iam.md)를 참조하고 **서비스 연결 역할(Service-linked roles)** 열에 **예(Yes)**가 있는 서비스를 찾습니다. 해당 서비스에 대한 서비스 연결 역할 설명서를 보려면 **예(Yes)** 링크를 선택합니다.

**역할에서 허용되는 권한을 변경하려면(AWS API)**

1. (옵션) 현재 역할과 연동되어 있는 권한을 확인하려면 다음 연산을 호출합니다.

   1. 인라인 정책을 나열하기 위한 [ListRolePolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListRolePolicies.html)

   1. 관리형 정책을 나열하기 위한 [ListAttachedRolePolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAttachedRolePolicies.html)

1. 역할 권한의 업데이트 작업은 관리형 정책을 업데이트할 때와 인라인 정책을 업데이트할 때 서로 다릅니다.

   관리형 정책을 업데이트하려면 다음 연산을 호출하여 새로운 버전의 관리형 정책을 생성합니다.
   + [CreatePolicyVersion](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreatePolicyVersion.html)

   인라인 정책을 업데이트하려면 다음 연산을 호출합니다.
   + [PutRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePolicy.html)

## 역할의 권한 경계 업데이트
<a name="id_roles_update-role-permissions-boundary"></a>

역할이 허용하는 최대 권한을 변경하려면, 역할의 [권한 경계](access_policies_boundaries.md)를 수정합니다.

### 역할 권한 경계 업데이트(콘솔)
<a name="id_roles_update-permissions-boundary-console"></a>

**역할에 대한 권한 경계 설정에 사용된 정책을 변경하려면**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **역할**을 선택합니다.

1. 변경하려는 [권한 경계](access_policies_boundaries.md)가 있는 역할의 이름을 선택합니다.

1. **권한** 탭을 선택합니다. 필요하다면 **Permissions boundary(권한 경계)** 섹션을 열고 **Change boundary(경계 변경)**을 선택합니다.

1. 정책을 선택하여 원하는 권한 경계를 사용하세요.

1. **Change boundary(경계 변경)**을 선택합니다.

   다음에 다른 사람이 이 역할을 수임할 때까지 변경 사항은 적용되지 않습니다.

### 역할 권한 경계 업데이트(AWS CLI)
<a name="id_roles_update_permissions-boundary-cli"></a>

**역할(AWS CLI)에 대한 권한 경계 설정에 사용된 관리형 정책을 변경하려면**

1. (선택 사항) 역할의 현재 [권한 경계](access_policies_boundaries.md)를 확인하려면 다음 명령을 실행합니다.
   + [aws iam get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html)

1. 다른 관리형 정책을 사용하여 역할에 대한 권한 경계를 업데이트하려면 다음 명령 중 하나를 실행합니다.
   + [aws iam put-role-permissions-boundary](https://docs.aws.amazon.com/cli/latest/reference/iam/put-role-permissions-boundary.html)

   역할은 권한 경계로서 하나의 관리형 정책만 가질 수 있습니다. 권한 경계를 변경하면 역할이 허용하는 최대 권한을 변경합니다.

### 역할 권한 경계 업데이트(AWS API)
<a name="id_roles_update-permissions-boundary-api"></a>

**역할(AWS API)에 대한 권한 경계 설정에 사용된 관리형 정책을 변경하려면**

1. (선택 사항) 역할의 현재 [권한 경계](access_policies_boundaries.md)를 확인하려면 다음 작업을 호출합니다.
   + [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)

1. 다른 관리형 정책을 사용하여 역할에 대한 권한 경계를 업데이트하려면 다음 작업 중 하나를 호출합니다.
   + [PutRolePermissionsBoundary](https://docs.aws.amazon.com/IAM/latest/APIReference/API_PutRolePermissionsBoundary.html)

   역할은 권한 경계로서 하나의 관리형 정책만 가질 수 있습니다. 권한 경계를 변경하면 역할이 허용하는 최대 권한을 변경합니다.

# 역할 설정 업데이트
<a name="id_roles_update-role-settings"></a>

다음 절차를 사용하여 역할 설명을 업데이트하거나 역할의 최대 세션 기간을 변경합니다.

## 역할 설명 업데이트
<a name="id_roles_update-description"></a>

역할의 설명을 변경하려면 설명 텍스트를 수정합니다.

### 역할 설명 업데이트(콘솔)
<a name="id_roles_update-description-console"></a>

**역할의 설명을 변경하려면(콘솔 사용)**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. IAM 콘솔의 탐색 창에서 **역할**을 선택합니다.

1. 변경할 역할 이름을 선택합니다.

1. **요약(Summary)** 섹션에서 **편집(Edit)**을 선택합니다.

1. 상자에 새 설명을 입력하고 **변경 사항 저장**을 선택합니다.

### 역할 설명 업데이트(AWS CLI)
<a name="id_roles_update-description-cli"></a>

**역할의 설명을 변경하려면(AWS CLI)**

1. (옵션) 역할의 현재 설명을 보려면 다음 명령을 실행합니다.
   + [aws iam get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html)

1. 역할의 설명을 업데이트하려면 설명 파라미터와 함께 다음 명령을 실행합니다.
   + [aws iam update-role](https://docs.aws.amazon.com/cli/latest/reference/iam/update-role.html)

### 역할 설명 업데이트(AWS API)
<a name="id_roles_update-description-api"></a>

**역할의 설명을 변경하려면(AWS API)**

1. (옵션) 현재 역할의 설명을 확인하려면 다음 연산을 호출합니다.
   + [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) 

1. 역할의 설명을 업데이트하려면 설명 파라미터와 함께 다음 연산을 호출합니다.
   + [UpdateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRole.html)

## 역할의 최대 세션 기간 업데이트
<a name="id_roles_update-session-duration"></a>

콘솔, AWS CLI 또는 AWS API를 사용하여 수임한 역할에 대한 최대 세션 기간 설정을 지정하려면 최대 세션 지속 시간 설정의 값을 수정합니다. 이 설정에는 1\$112시간의 값을 지정할 수 있습니다. 값을 지정하지 않으면 기본 최댓값인 1시간이 적용됩니다. 이 설정은 AWS 서비스에서 수임하는 세션을 제한하지 않습니다.

### 역할 최대 세션 기간 업데이트(콘솔)
<a name="id_roles_update-session-duration-console"></a><a name="id_roles_modify_max-session"></a>

**콘솔, AWS CLI 또는 AWS API를 사용하여 수임한 역할에 대한 최대 세션 지속 시간 설정을 변경하려면(콘솔)**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. IAM 콘솔의 탐색 창에서 **역할**을 선택합니다.

1. 변경할 역할 이름을 선택합니다.

1. **요약(Summary)** 섹션에서 **편집(Edit)**을 선택합니다.

1. **최대 세션 지속 시간(Maximum session duration)**에서 값을 선택합니다. 또는 **사용자 지정 기간(Custom duration)**을 선택하고 값(초)을 입력합니다.

1. **변경 사항 저장**을 선택합니다.

   다음에 다른 사람이 이 역할을 수임할 때까지 변경 사항은 적용되지 않습니다. 이 역할에 대한 기존 세션을 취소하는 방법을 알아보려면 [IAM 역할 임시 보안 자격 증명 취소](id_roles_use_revoke-sessions.md) 섹션을 참조하세요.

AWS Management Console에서 IAM 사용자 세션은 기본적으로 12시간입니다. 콘솔에서 역할을 전환하는 IAM 사용자에게는 역할 최대 세션 기간 또는 사용자 세션의 남은 시간 중 더 적은 시간이 부여됩니다.

AWS CLI 또는 AWS API에서 역할을 수임한 사람은 이 최대값까지 더 긴 세션을 요청할 수 있습니다. `MaxSessionDuration` 설정은 요청할 수 있는 역할 세션의 최대 지속 시간을 결정합니다.
+ AWS CLI을 사용하여 세션 지속 시간을 지정하려면 `duration-seconds` 파라미터를 사용합니다. 자세한 내용은 [IAM 역할로 전환(AWS CLI)](id_roles_use_switch-role-cli.md) 섹션을 참조하세요.
+ AWS API를 사용하여 세션 지속 시간을 지정하려면 `DurationSeconds` 파라미터를 사용합니다. 자세한 내용은 [IAM 역할로 전환(AWS API)](id_roles_use_switch-role-api.md) 섹션을 참조하세요.

### 역할 최대 세션 기간 업데이트(AWS CLI)
<a name="id_roles_update-session-duration-cli"></a>

**참고**  
AWS CLI 또는 API에서 역할을 수임한 사람은 누구나 `duration-seconds` CLI 파라미터 또는 `DurationSeconds` API 파라미터를 사용해 더 긴 세션을 요청할 수 있습니다. `MaxSessionDuration` 설정은 `DurationSeconds` 파라미터를 사용해 요청할 수 있는 역할 세션에 대한 최대 기간을 결정합니다. 사용자가 `DurationSeconds` 파라미터의 값을 지정하지 않으면 보안 자격 증명이 한 시간 동안 유효하게 됩니다.

**AWS CLI를 사용하여 수임한 역할에 대한 최대 세션 기간 설정을 변경하려면(AWS CLI)**

1. (옵션) 역할에 대한 현재 최대 세션 기간 설정을 확인하려면 다음 명령을 실행합니다.
   + [aws iam get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html)

1. 역할의 최대 세션 기간 설정을 업데이트하려면 `max-session-duration` CLI 파라미터 또는 `MaxSessionDuration` API 파라미터와 함께 다음 명령을 실행합니다.
   + [aws iam update-role](https://docs.aws.amazon.com/cli/latest/reference/iam/update-role.html)

   다음에 다른 사람이 이 역할을 수임할 때까지 변경 사항은 적용되지 않습니다. 이 역할에 대한 기존 세션을 취소하는 방법을 알아보려면 [IAM 역할 임시 보안 자격 증명 취소](id_roles_use_revoke-sessions.md) 섹션을 참조하세요.

### 역할 최대 세션 기간 업데이트(AWS API)
<a name="id_roles_update-session-duration-api"></a>

**참고**  
AWS CLI 또는 API에서 역할을 수임한 사람은 누구나 `duration-seconds` CLI 파라미터 또는 `DurationSeconds` API 파라미터를 사용해 더 긴 세션을 요청할 수 있습니다. `MaxSessionDuration` 설정은 `DurationSeconds` 파라미터를 사용해 요청할 수 있는 역할 세션에 대한 최대 기간을 결정합니다. 사용자가 `DurationSeconds` 파라미터의 값을 지정하지 않으면 보안 자격 증명이 한 시간 동안 유효하게 됩니다.

**API를 사용하여 수임한 역할에 대한 최대 세션 기간 설정을 변경하려면(AWS API)**

1. (옵션) 역할에 대한 현재 최대 세션 기간 설정을 확인하려면 다음 연산을 호출합니다.
   + [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) 

1. 역할의 최대 세션 기간 설정을 업데이트하려면 `max-sessionduration` CLI 파라미터 또는 `MaxSessionDuration` API 파라미터와 함께 다음 연산을 호출합니다.
   + [UpdateRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRole.html)

   다음에 다른 사람이 이 역할을 수임할 때까지 변경 사항은 적용되지 않습니다. 이 역할에 대한 기존 세션을 취소하는 방법을 알아보려면 [IAM 역할 임시 보안 자격 증명 취소](id_roles_use_revoke-sessions.md) 섹션을 참조하세요.

# 역할 또는 인스턴스 프로파일 삭제
<a name="id_roles_manage_delete"></a>

역할이 더 이상 필요하지 않은 경우 역할 및 연결된 권한을 삭제하는 것이 좋습니다. 그렇게 하면 적극적으로 모니터링하거나 유지 관리하지 않은 미사용 엔터티가 없습니다.

역할이 EC2 인스턴스와 연결된 경우 인스턴스 프로파일에서 해당 역할을 제거한 다음 인스턴스 프로파일을 삭제할 수도 있습니다.

**주의**  
삭제하려는 역할 또는 인스턴스 프로파일로 실행 중인 Amazon EC2 인스턴스가 없는지 확인합니다. 실행 중인 인스턴스와 연결된 역할 또는 인스턴스 프로파일을 삭제하면 인스턴스에서 실행 중인 모든 애플리케이션이 중단됩니다.

역할을 영구적으로 삭제하지 않으려면 역할을 비활성화하면 됩니다. 이렇게 하려면 역할 정책을 변경한 다음 현재 세션을 모두 취소합니다. 예를 들어 모든 AWS에 대한 액세스를 거부한 정책을 역할에 추가할 수 있습니다. 역할을 수임하려는 모든 사용자에 대한 액세스를 거부하도록 신뢰 정책을 편집할 수도 있습니다. 세션 취소에 대한 자세한 내용은 [IAM 역할 임시 보안 자격 증명 취소](id_roles_use_revoke-sessions.md) 섹션을 참조하세요.

**Topics**
+ [

## 역할 액세스 보기
](#roles-delete_prerequisites)
+ [

## 서비스 연결 역할 삭제
](#id_roles_manage_delete_slr)
+ [

## IAM 역할 삭제(콘솔)
](#roles-managingrole-deleting-console)
+ [

## IAM 역할 삭제(AWS CLI)
](#roles-managingrole-deleting-cli)
+ [

## IAM 역할 삭제(AWS API)
](#roles-managingrole-deleting-api)
+ [

## 관련 정보
](#roles-managingrole-deleting-related-info)

## 역할 액세스 보기
<a name="roles-delete_prerequisites"></a>

역할을 삭제하기 전에 역할이 마지막으로 사용된 시기를 검토하는 것이 좋습니다. AWS Management Console, AWS CLI 또는 AWS API를 사용하여 이 작업을 수행할 수 있습니다. 이 정보를 확인해야 하는 이유는 역할을 사용하는 사용자의 액세스 권한을 제거하지 않기 위해서입니다.

역할의 마지막 활동 날짜가 **마지막 액세스** 탭에 보고된 마지막 날짜와 일치하지 않을 수 있습니다. [**마지막 액세스**](access_policies_last-accessed-view-data.md) 탭은 역할의 권한 정책에서 허용하는 서비스에 대한 활동만 보고합니다. 역할의 마지막 활동 날짜에는 AWS의 모든 서비스에 액세스하려는 마지막 시도가 포함됩니다.

**참고**  
역할의 마지막 활동 및 마지막 액세스 데이터에 대한 추적 기간은 이후 400일입니다. 해당 리전이 이러한 기능 지원을 시작한 날짜가 작년이었다면 이 기간이 더 짧아질 수 있습니다. 이 역할이 400일 전에 사용되었을 수 있습니다. 추적 기간에 대한 자세한 내용은 [AWS에서 마지막으로 액세스한 정보를 추적하는 위치](access_policies_last-accessed.md#last-accessed_tracking-period) 섹션을 참조하세요.

**역할이 마지막으로 사용된 시기를 보려면(콘솔)**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **역할**을 선택합니다.

1. 활동을 보려는 역할의 행을 찾습니다. 검색 필드를 사용하여 결과를 좁힐 수 있습니다. **마지막 활동** 열에서 역할이 마지막으로 사용된 이후 일 수를 확인합니다. 역할이 추적 기간 내에 사용되지 않은 경우 테이블에 **없음**이 표시됩니다.

1. 자세한 정보를 볼 역할의 이름을 선택합니다. 역할의 **요약** 페이지에는 해당 역할이 마지막으로 사용된 날짜를 표시하는 **마지막 활동(Last activity)**도 포함되어 있습니다. 역할이 지난 400일 이내에 사용되지 않은 경우 **마지막 활동**에 **Not accessed in the tracking period(추적 기간 동안 액세스되지 않음)**가 표시됩니다.

**역할이 마지막으로 사용된 시기를 보려면(AWS CLI)**  
`[aws iam get-role](https://docs.aws.amazon.com/cli/latest/reference/iam/get-role.html)` - `RoleLastUsed` 객체를 포함하여 역할에 대한 정보를 반환하려면 이 명령을 실행합니다. 이 객체에는 역할이 마지막으로 사용된 `LastUsedDate` 및 `Region`이 있습니다. `RoleLastUsed`가 있지만 값을 포함하지 않는 경우 추적 기간 내에 해당 역할이 사용되지 않은 것입니다.

**역할이 마지막으로 사용된 시기를 보려면(AWS API)**  
`[GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/GetRole.html)` - `RoleLastUsed` 객체를 포함하여 역할에 대한 정보를 반환하려면 이 작업을 호출합니다. 이 객체에는 역할이 마지막으로 사용된 `LastUsedDate` 및 `Region`이 있습니다. `RoleLastUsed`가 있지만 값을 포함하지 않는 경우 추적 기간 내에 해당 역할이 사용되지 않은 것입니다.

## 서비스 연결 역할 삭제
<a name="id_roles_manage_delete_slr"></a>

서비스 연결 역할을 삭제하는 데 사용하는 방법은 서비스에 따라 다릅니다. 일부 경우에서는 서비스 연결 역할을 수동으로 삭제할 필요가 없습니다. 예를 들어, 서비스에서 특정 작업(예: 리소스 제거)을 완료하면 서비스에서 사용자의 서비스 연결 역할을 삭제할 수 있습니다. 서비스에서 서비스 연결 역할을 서비스 콘솔, API 또는 AWS CLI에서 수동으로 삭제하는 것이 지원되지 않는 경우도 있을 수 있습니다.

연결된 서비스의 **[서비스 연결 역할](id_roles.md#iam-term-service-linked-role) 관련 설명서를 참조하여 역할을 삭제하는 방법을 알아보세요. 콘솔의 IAM **역할** 페이지에서 계정의 서비스 연결 역할을 볼 수 있습니다. 서비스 연결 역할은 테이블의 **Trusted entities(신뢰할 수 있는 개체)** 열에 **(Service-linked role)((서비스 연결 역할))**로 표시됩니다. 역할의 **요약** 페이지 배너에도 해당 역할이 서비스 연결 역할임이 표시됩니다.

서비스에 서비스 연결 역할 삭제에 대한 설명서가 없는 경우 IAM 콘솔, AWS CLI 또는 API를 사용하여 역할을 삭제할 수 있습니다.

## IAM 역할 삭제(콘솔)
<a name="roles-managingrole-deleting-console"></a>

AWS Management Console를 사용하여 역할을 삭제하는 경우, IAM에서는 해당 역할과 관리형 정책을 자동으로 삭제합니다. 또한 역할과 연결된 모든 인라인 정책과 역할이 포함된 모든 Amazon EC2 인스턴스 프로파일도 자동으로 삭제됩니다.

**중요**  
경우에 따라 역할이 Amazon EC2 인스턴스 프로파일과 연결될 수 있으며, 역할과 인스턴스 프로파일의 이름이 같을 수 있습니다. 이 경우 AWS Management Console을 사용하여 역할 및 인스턴스 프로파일을 삭제할 수 있습니다. 이 연결은 콘솔에서 생성한 인스턴스 프로파일과 역할에서 자동으로 발생합니다. AWS CLI, Tools for Windows PowerShell 또는 AWS API에서 역할을 생성한 경우 역할과 인스턴스 프로파일의 이름이 서로 다를 수 있습니다. 이 경우 콘솔을 사용하여 역할과 인스턴스 프로파일을 삭제할 수 없습니다. 그 대신 AWS CLI, Tools for Windows PowerShell 또는 AWS API를 사용하여 먼저 인스턴스 프로파일에서 역할을 제거해야 합니다. 그런 다음 별도의 단계로 역할을 삭제해야 합니다.

**역할을 삭제하려면(콘솔 사용)**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **역할**을 선택한 다음 삭제할 역할 이름 옆에 있는 확인란을 선택합니다.

1. 페이지 상단에서 **삭제(Delete)**를 선택합니다.

1. 확인 대화 상자가 나타나면 마지막으로 액세스한 정보를 검토합니다. 이 정보는 선택한 각 역할이 AWS 서비스를 마지막으로 액세스한 일시를 보여줍니다. 이를 통해 역할이 현재 활성 상태인지 확인할 수 있습니다. 계속하려면 텍스트 입력 필드에 역할 이름을 입력하고 **삭제(Delete)**를 선택합니다. 확신한다면, 마지막으로 액세스한 정보가 로드되고 있을 때에도 삭제를 진행할 수 있습니다.

**참고**  
인스턴스 프로파일이 역할과 이름이 동일한 경우를 제외하고는 콘솔을 사용하여 인스턴스 프로파일을 삭제할 수 없습니다. 이전 절차에서 설명한 바와 같이 역할 삭제 과정의 일부로 인스턴스 프로파일도 삭제됩니다. 역할까지 삭제하지 않고 인스턴스 프로파일을 삭제하려면 AWS CLI 또는 AWS API를 사용해야 합니다. 자세한 내용은 다음 섹션을 참조하세요.

## IAM 역할 삭제(AWS CLI)
<a name="roles-managingrole-deleting-cli"></a>

AWS CLI를 사용하여 역할을 삭제하는 경우, 먼저 해당 역할과 연결된 인라인 정책을 삭제해야 합니다. 또한 역할과 연결된 관리형 정책을 분리해야 합니다. 해당 역할이 들어 있는 연결된 인스턴스 프로파일은 별도로 삭제해야 합니다.

**역할을 삭제하려면(AWS CLI)**

1. 삭제할 역할의 이름을 모르는 경우 다음 명령을 입력하여 계정의 역할을 나열합니다.

   ```
   aws iam list-roles
   ```

   목록에는 각 역할의 Amazon 리소스 이름(ARN)이 포함되어 있습니다. CLI 명령에서 역할을 참조하려면 ARN이 아니라 역할 이름을 사용해야 합니다. 예를 들어, 어떤 역할의 ARN이 `arn:aws:iam::123456789012:role/myrole`인 경우 참조할 역할은 **myrole**입니다.

1. 역할과 관련 있는 모든 인스턴스 프로파일에서 역할을 제거합니다.

   1. 역할이 연결된 모든 인스턴스 프로파일을 나열하려면 다음 명령을 입력합니다.

      ```
      aws iam list-instance-profiles-for-role --role-name role-name
      ```

   1. 인스턴스 프로파일에서 역할을 제거하려면 각 인스턴스 프로파일에 대해 다음 명령을 입력합니다.

      ```
      aws iam remove-role-from-instance-profile --instance-profile-name instance-profile-name --role-name role-name
      ```

1. 역할과 연결된 모든 정책을 삭제합니다.

   1. 해당 역할에 있는 모든 인라인 정책을 나열하려면 다음 명령을 입력합니다.

      ```
      aws iam list-role-policies --role-name role-name
      ```

   1. 역할에서 각 인라인 정책을 삭제하려면 각 정책에 대해 다음 명령을 입력합니다.

      ```
      aws iam delete-role-policy --role-name role-name --policy-name policy-name
      ```

   1. 해당 역할에 연계돼 있는 모든 관리형 정책을 나열하려면 다음 명령을 입력합니다.

      ```
      aws iam list-attached-role-policies --role-name role-name
      ```

   1. 역할에서 각 관리 정책을 분리하려면 각 정책에 대해 다음 명령을 입력합니다.

      ```
      aws iam detach-role-policy --role-name role-name --policy-arn policy-arn
      ```

1. 다음 명령을 입력하여 역할을 삭제합니다.

   ```
   aws iam delete-role --role-name role-name
   ```

1. 역할과 연결된 인스턴스 프로파일을 다시 사용할 계획이 없는 경우 다음 명령을 입력하여 삭제할 수 있습니다.

   ```
   aws iam delete-instance-profile --instance-profile-name instance-profile-name
   ```

## IAM 역할 삭제(AWS API)
<a name="roles-managingrole-deleting-api"></a>

IAM API를 사용하여 역할을 삭제하려면 먼저 해당 역할과 연결된 인라인 정책을 삭제해야 합니다. 또한 역할과 연결된 관리형 정책을 분리해야 합니다. 해당 역할이 들어 있는 연결된 인스턴스 프로파일은 별도로 삭제해야 합니다.

**역할을 삭제하려면(AWS API)**

1. 역할과 관련 있는 모든 인스턴스 프로파일을 나열하려면 [ListInstanceProfilesForRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListInstanceProfilesForRole.html)을 호출하세요.

   인스턴스 프로파일에서 해당 역할을 제거하려면 [RemoveRoleFromInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_RemoveRoleFromInstanceProfile.html)을 호출하세요. 역할 이름과 인스턴스 프로파일 이름을 전달해야 합니다.

   역할과 연결된 인스턴스 프로파일을 다시 사용하지 않을 경우 [DeleteInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteInstanceProfile.html)을 호출하여 삭제할 수 있습니다.

1. 역할에 대한 모든 인라인 정책을 나열하려면 [ListRolePolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListRolePolicies.html)를 호출하세요.

   역할과 연결된 모든 인라인 정책을 삭제하려면 [DeleteRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteRolePolicy.html)를 호출하세요. 역할 이름과 인라인 정책 이름을 전달해야 합니다.

1. 역할에 연결된 모든 관리형 정책을 나열하려면 [ListAttachedRolePolicies](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListAttachedRolePolicies.html)를 직접적으로 호출합니다.

   역할에 연결된 관리형 정책을 분리하려면 [DetachRolePolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DetachRolePolicy.html)를 직접적으로 호출합니다. 역할 이름과 관리형 정책 ARN을 전달해야 합니다.

1. [DeleteRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteRole.html)을 호출하여 역할을 삭제하세요.

## 관련 정보
<a name="roles-managingrole-deleting-related-info"></a>

인스턴스 프로파일에 대한 일반적인 정보는 [인스턴스 프로파일 사용](id_roles_use_switch-role-ec2_instance-profiles.md) 섹션을 참조하세요.

서비스 연결 역할에 대한 일반적인 내용은 [서비스 연결 역할 생성](id_roles_create-service-linked-role.md) 섹션을 참조하세요.

# 역할 수임 방법
<a name="id_roles_manage-assume"></a>

사용자, 애플리케이션 또는 서비스에서 사용자가 생성한 역할을 사용하려면 먼저 해당 역할로 [전환할 수 있는 권한을 부여](id_roles_use_permissions-to-switch.md)해야 합니다. 그룹 또는 사용자에게 추가된 어떤 정책도 필요한 권한을 부여하는 데 사용할 수 있습니다. 권한이 부여되면 사용자는 AWS Management Console, Tools for Windows PowerShell, AWS Command Line Interface(AWS CLI) 및 [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API에서 역할을 수임할 수 있습니다.

**중요**  
IAM 콘솔 대신 프로그래밍 방식으로 역할을 생성하는 경우에는 사용자의 선택에 따라 최대 64자인 `RoleName`뿐만 아니라 최대 512자인 `Path`도 추가할 수 있습니다. 그러나 AWS Management Console에서 **역할 전환(Switch Role)** 기능이 있는 역할을 사용하려면 `Path`와 `RoleName`을 합해 64자를 초과할 수 없습니다.

역할 수임에 사용한 방법에 따라 역할을 수임할 수 있는 사용자와 역할 세션의 지속 가능 기간이 결정됩니다. `AssumeRole*` API 작업을 사용하는 경우 여러분이 맡는 IAM 역할은 리소스입니다. `AssumeRole*` API 작업을 호출하는 사용자 또는 역할이 보안 주체입니다.

다음 테이블에서는 역할 수임 방법을 비교합니다.


|  역할을 수임하는 방법 |  **역할을 위임할 수 있는 사용자**  | **자격 증명의 수명을 지정하는 방법** |  **자격 증명의 수명(최소 \$1 최대 \$1 기본)**  | 
| --- | --- | --- | --- | 
| AWS Management Console | 사용자 또는 역할¹([역할 전환](id_roles_use_switch-role-console.md)) | 최대 세션 기간에 역할 요약 페이지에서 | 15분 \$1 최대 세션 기간 설정² \$1 1시간 | 
| [https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html) CLI 또는 [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API 작업 |  사용자 또는 역할¹ | duration-seconds CLI 또는 DurationSeconds API 파라미터 | 15분 \$1 최대 세션 기간 설정² \$1 1시간  | 
| [https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-saml.html](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-saml.html) CLI 또는 [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) API 작업 | SAML을 사용하여 인증된 모든 사용자 | duration-seconds CLI 또는 DurationSeconds API 파라미터 | 15분 \$1 최대 세션 기간 설정² \$1 1시간  | 
| [https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-web-identity.html](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-web-identity.html) CLI 또는 [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) API 작업 | OIDC 공급자를 사용하여 인증된 모든 사용자 | duration-seconds CLI 또는 DurationSeconds API 파라미터 | 15분 \$1 최대 세션 기간 설정² \$1 1시간  | 
| AssumeRole로 생성된 [콘솔 URL](id_roles_providers_enable-console-custom-url.md)  | 사용자 또는 역할 | URL의 SessionDuration HTML 파라미터 | 15분 \$1 12시간 \$1 1시간  | 
| AssumeRoleWithSAML로 생성된 [콘솔 URL](id_roles_providers_enable-console-custom-url.md)  | SAML을 사용하여 인증된 모든 사용자 | URL의 SessionDuration HTML 파라미터 | 15분 \$1 12시간 \$1 1시간 | 
| AssumeRoleWithWebIdentity로 생성된 [콘솔 URL](id_roles_providers_enable-console-custom-url.md)  | OIDC 공급자를 사용하여 인증된 모든 사용자 | URL의 SessionDuration HTML 파라미터 | 15분 \$1 12시간 \$1 1시간  | 

¹ 하나의 역할에서 자격 증명을 사용하여 다른 역할을 수임하는 것을 [역할 체인](id_roles.md#iam-term-role-chaining)이라고 합니다. 역할 체인을 사용하는 경우 역할의 세션 지속 시간은 1시간으로 제한됩니다. 이는 AWS Management Console 역할 전환, AWS CLI 및 API 작업에 적용됩니다. 이 제한은 사용자 자격 증명의 첫 역할 수임이나 인스턴스 프로파일을 사용하여 Amazon EC2 인스턴스에서 실행되는 애플리케이션에는 적용되지 않습니다.

² 이 설정에는 1\$112시간의 값을 지정할 수 있습니다. 최대 세션 기간 설정을 수정하는 방법에 대한 자세한 내용은 [IAM 역할 관리](id_roles_manage.md) 섹션을 참조하세요. 이 설정은 역할 자격 증명을 얻을 때 요청할 수 있는 최대 세션 기간을 결정합니다. 예를 들어 [AssumeRole\$1](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API 작업을 사용하여 역할을 위임할 때 `DurationSeconds` 파라미터를 사용하여 세션 길이를 지정할 수 있습니다. 이 파라미터를 사용하여 역할 세션 기간을 900초(15분)에서 해당 역할에 대한 최대 세션 기간 설정까지 지정합니다. 콘솔에서 역할을 전환하는 IAM 사용자에게는 최대 세션 기간 또는 사용자 세션의 남은 시간 중 더 적은 시간이 부여됩니다. 역할에서 최대 기간을 5시간으로 설정한다고 가정합니다. 콘솔에 10시간(기본 최대 12시간 중) 동안 로그인한 IAM 사용자가 해당 역할로 전환합니다. 이 경우 사용 가능한 역할 세션 기간은 2시간입니다. 역할에 대한 최댓값을 확인하는 방법을 알아보려면 이 페이지 뒷부분에 나오는 [역할의 최대 세션 기간 업데이트](id_roles_update-role-settings.md#id_roles_update-session-duration) 섹션을 참조하세요.

**Notes**  
최대 세션 기간 설정은 AWS 서비스에서 수임하는 세션을 제한하지 않습니다.
Amazon EC2 IAM 역할 자격 증명에는 역할에 구성된 최대 세션 기간이 적용되지 않습니다.
사용자가 역할 세션 내에서 현재 역할을 다시 수임할 수 있도록 허용하려면 역할 ARN 또는 AWS 계정 ARN을 역할 신뢰 정책의 보안 주체로 지정합니다. Amazon EC2, Amazon ECS, Amazon EKS, Lambda와 같이 컴퓨팅 리소스를 제공하는 AWS 서비스는 임시 보안 인증을 제공하며 해당 보안 인증을 자동으로 업데이트합니다. 이렇게 하면 항상 유효한 자격 증명 집합을 가질 수 있습니다. 이러한 서비스의 경우 임시 자격 증명을 획득하기 위해 현재 역할을 다시 수임할 필요는 없습니다. 하지만 [세션 태그](id_session-tags.md) 또는 [세션 정책](access_policies.md#policies_session)을 전달하려는 경우 현재 역할을 다시 수임해야 합니다. 보안 주체 역할 ARN 또는 AWS 계정 ARN을 추가하기 위해 역할 신뢰 정책을 수정하는 방법을 알아보려면 [역할 트러스트 정책 업데이트](id_roles_update-role-trust-policy.md)을 참조하세요.

**Topics**
+ [

# 사용자에서 IAM 역할로 전환(콘솔)
](id_roles_use_switch-role-console.md)
+ [

# IAM 역할로 전환(AWS CLI)
](id_roles_use_switch-role-cli.md)
+ [

# IAM 역할로 전환(Tools for Windows PowerShell)
](id_roles_use_switch-role-twp.md)
+ [

# IAM 역할로 전환(AWS API)
](id_roles_use_switch-role-api.md)
+ [

# IAM 역할을 사용하여 Amazon EC2 인스턴스에서 실행되는 애플리케이션에 권한 부여
](id_roles_use_switch-role-ec2.md)
+ [

# 인스턴스 프로파일 사용
](id_roles_use_switch-role-ec2_instance-profiles.md)

# 사용자에서 IAM 역할로 전환(콘솔)
<a name="id_roles_use_switch-role-console"></a>

IAM 사용자, IAM Identity Center의 사용자, SAML 페더레이션 역할 또는 웹 아이덴티티 페더레이션 역할로 로그인할 때 역할을 전환할 수 있습니다. *역할*은 필요한 AWS 리소스에 액세스하는 데 사용할 수 있는 일련의 권한을 지정합니다. 하지만 역할로 로그인하지는 못하지만, 일단 IAM 사용자로 로그인한 후에 IAM 역할로 전환할 수 있습니다. 이 경우 초기의 사용자 권한은 잠시 무효화되고 역할에게 할당된 권한이 부여됩니다. 역할은 자신의 계정 또는 그 밖의 다른 AWS 계정에 속한 것일 수 있습니다. 역할, 역할의 이점 및 생성 방법에 대한 자세한 내용은 다음([IAM 역할](id_roles.md) 및 [IAM 역할 생성](id_roles_create.md))을 참조하세요.

사용자의 권한과 전환 대상인 역할의 권한은 누적되지 않습니다. 한 번에 오직 하나의 권한 집합만이 활성화됩니다. 어떤 역할로 전환할 때 사용자 권한은 일시적으로 포기하고 역할에 할당된 권한을 가지고 작업합니다. 역할을 끝내면 사용자 권한이 자동으로 회복됩니다.

AWS Management Console에서 역할을 전환하는 경우, 콘솔은 항상 원래 자격 증명을 사용하여 전환을 승인합니다. 예를 들어, RoleA로 전환하는 경우 IAM에서는 원래 자격 증명을 사용하여 RoleA를 수임할 수 있는지 여부를 결정합니다. *RoleA를 사용하는 중에* RoleB로 전환하는 경우에도 AWS에서는 RoleA의 자격 증명이 아닌, **원래** 자격 증명을 사용하여 전환을 승인합니다.

**참고**  
세션을 시작할 때 IAM Identity Center의 사용자, SAML 페더레이션 역할 또는 웹 ID 페더레이션 역할로 로그인하는 경우 IAM 역할을 수임합니다. 예를 들어 IAM Identity Center의 사용자가 AWS 액세스 포털에 로그인할 때 AWS 리소스에 액세스하려면 먼저 역할과 관련된 권한 세트를 선택해야 합니다.

## 역할 세션
<a name="id_roles_iam_user-switch-role-sessions"></a>

역할을 전환할 때 AWS Management Console 세션은 기본적으로 1시간 동안 지속됩니다. IAM 사용자 세션은 기본적으로 12시간이며, 다른 사용자에게는 정의된 세션 기간이 다를 수 있습니다. 콘솔에서 역할을 전환할 때 최대 세션 기간 또는 사용자 세션의 남은 시간 중 더 적은 시간이 부여됩니다. 역할을 수임하여 세션 기간을 연장할 수 없습니다.

예를 들어 역할의 최대 세션 기간이 10시간으로 설정되어 있다고 가정합니다. 역할로 전환하기로 결정할 때까지 8시간 동안 콘솔에 로그인해 있었습니다. 사용자 세션에는 4시간이 남아 있으므로, 허용되는 역할 세션 기간은 4시간입니다(10시간의 최대 세션 지속 시간이 아님). 다음 표에서는 콘솔에서 역할을 전환할 때 IAM 사용자의 세션 기간을 결정하는 방법을 설명합니다.


| IAM 사용자 세션 남은 시간… | 역할 세션 기간… | 
| --- | --- | 
| 역할 최대 세션 기간보다 작음 | 사용자 세션의 남은 시간 | 
| 역할 최대 세션 기간보다 큼 | 최대 세션 기간 값 | 
| 역할 최대 세션 기간과 같음 | 최대 세션 기간 값(근사치) | 

하나의 역할에서 자격 증명을 사용하여 다른 역할을 수임하는 것을 [역할 체인](id_roles.md#iam-term-role-chaining)이라고 합니다. 역할 체인을 사용하는 경우 개별 역할에 대해 구성된 최대 세션 기간 설정에 관계없이 세션 기간은 1시간으로 제한됩니다. 이는 AWS Management Console 역할 전환, AWS CLI 및 API 작업에 적용됩니다.

**참고**  
일부 AWS 서비스 콘솔에서는 역할 세션이 만료되는 경우 아무 조치를 취하지 않아도 역할 세션을 자동으로 갱신할 수 있습니다. 또한 브라우저를 다시 로드하여 세션을 다시 인증하라는 메시지를 표시하는 경우도 있습니다.

## 고려 사항
<a name="id_roles_iam_user-switch-role-considerations"></a>
+ AWS 계정 루트 사용자로 로그인할 경우 역할을 전활할 수 없습니다.
+ 정책에 따라 사용자에게 역할 전환 권한을 부여해야 합니다. 지침은 [사용자에게 역할을 전환할 권한 부여](id_roles_use_permissions-to-switch.md) 섹션을 참조하세요.
+ AWS Management Console에서의 역할을 [ExternalId](id_roles_common-scenarios_third-party.md#id_roles_third-party_external-id) 값이 필요한 역할로 전환할 수 없습니다. `ExternalId` 파라미터를 지원하는 [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API를 호출해야만 이러한 역할로 전환할 수 있습니다.

## 역할을 전환하는 방법
<a name="id_roles_iam_user-switch-role-console-procedure"></a>

1. *AWS Sign-In 사용 설명서*의 [AWS Management Console에 로그인하는 방법](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) 항목에 설명된 대로 사용자 유형에 맞는 로그인 절차를 따르세요.

1. AWS Management Console에서 오른쪽 상단에 있는 탐색 표시줄에서 사용자 이름을 선택합니다. 일반적인 형식은 ***username*@*account\$1ID\$1number\$1or\$1alias***입니다.

1. 다음 방법 중 하나를 선택하여 역할 전환:
   + **역할 전환**을 선택합니다.
   + 다중 세션 지원을 옵트인한 경우 **세션 추가**를 선택하고 **역할 전환**을 선택합니다.
**참고**  
AWS Management Console의 단일 웹 브라우저에서 최대 5개의 서로 다른 자격 증명을 동시에 로그인할 수 있습니다. 자세한 내용은 *AWS Management Console 시작 안내서*의 [Signing in to multiple accounts](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/multisession.html)를 참조하세요.

1. **역할 전환** 페이지에서 계정 ID 번호 또는 계정 별칭 및 관리자가 제공한 역할 이름을 입력합니다.
**참고**  
관리자가 경로를 포함하여 역할을 생성한 경우(예: `division_abc/subdivision_efg/roleToDoX`)에는 **역할** 상자에 전체 경로와 이름을 입력해야 합니다. 역할 이름만 입력하는 경우 또는 결합된 `Path` 및 `RoleName`이 64자를 초과하는 경우 역할 전환에 실패합니다. 이것은 역할 이름을 저장하는 브라우저 쿠키의 한계입니다. 이러한 경우 관리자에게 문의해 경로 및 역할 이름의 크기를 줄여 달라고 요청하세요.

1. (선택 사항) 표시 이름을 입력하고 콘솔 탐색 표시줄에서 역할을 강조할 표시 색상을 선택할 수 있습니다.
   + **표시 이름**에는 이 역할이 활성 상태일 때 탐색 표시줄에 사용자 이름 대신 표시할 텍스트를 입력합니다. 이름은 계정 및 역할 정보에 따라 다르게 제시되지만 특별한 의미를 갖도록 직접 변경하는 것도 가능합니다.
   + **표시 색상**에서 표시 이름을 강조 표시할 색상을 선택합니다.

   이름과 색상은 이 역할이 활성화되어 권한이 변경되는 시점을 다시 한 번 알려줍니다. 예를 들어 테스트 환경에 대한 액세스 권한을 부여하는 역할에 대해 **표시 이름(Display name)**을 **Test**로 지정하고 **색상(Color)**은 녹색으로 선택합니다. 프로덕션에 대한 액세스 권한을 부여하는 역할에 대해서는 **표시 이름(Display name)**을 **Production**으로 지정하고 **색상(Color)**은 빨간색으로 선택합니다.

1. **역할 전환**을 선택합니다. 표시 이름과 색상이 탐색 표시줄에 사용자 이름 대신 나타나고, 역할에서 부여하는 권한을 사용하여 시작할 수 있습니다.

1. IAM 역할이 필요한 작업을 완료한 후 원래 세션으로 다시 전환할 수 있습니다. 이렇게 하면 역할에서 제공한 추가 권한이 제거되고 표준 권한으로 돌아갑니다.

   1. IAM 콘솔의 탐색 모음 오른쪽 위쪽에서 역할의 **표시 이름(Display name)**을 선택합니다.

   1. **다시 전환**을 선택합니다.

      예를 들어, 사용자 이름 `123456789012`을 사용하여 계정 번호 `Richard`로 로그인했다고 가정하십시다. `admin-role` 역할을 사용한 후, 사용자가 역할 사용을 중지하고 원래 사용자 권한으로 돌아가고자 합니다. 역할 사용을 중지하려면 **admin-role @ 123456789012**를 선택하고 **다시 전환**을 선택합니다.  
![\[IAM 역할 사용을 중지하고 원래 사용자에게 돌아가도록 다시 전환 기능을 찾는 그래픽.\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/role-stop-using.png)

**작은 정보**  
마지막으로 사용한 몇 가지 역할은 [] ] 메뉴에 표시됩니다. 다음에 이 중 하나로 역할을 전환하려는 경우 원하는 역할을 선택하기만 하면 됩니다. 역할이 메뉴에 표시되지 않으면 계정 및 역할 정보를 수동으로 입력하기만 하면 됩니다.

## 추가 리소스
<a name="id_roles_use_switch-role-console_additional_resources"></a>
+ [사용자에게 역할을 전환할 권한 부여](id_roles_use_permissions-to-switch.md)
+ [사용자에게 AWS 서비스에 역할을 전달할 권한 부여](id_roles_use_passrole.md)
+ [IAM 사용자에게 권한을 부여할 역할 생성](id_roles_create_for-user.md)
+ [AWS 서비스에 대한 권한을 위임할 역할 생성](id_roles_create_for-service.md)
+ [IAM 역할 문제 해결](troubleshoot_roles.md)

# IAM 역할로 전환(AWS CLI)
<a name="id_roles_use_switch-role-cli"></a>

*역할*은 필요한 AWS 리소스에 액세스하는 데 사용할 수 있는 일련의 권한을 지정합니다. 이러한 면에서 [AWS Identity and Access Management(IAM)의 사용자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html)와 비슷합니다. 사용자로 로그인할 때는 특정 권한이 부여됩니다. 하지만 역할로 로그인하지는 못하기 때문에 일단 사용자로 로그인한 후에 역할로 전환할 수 있습니다. 이 경우 초기의 사용자 권한은 잠시 무효화되고 역할에게 할당된 권한이 부여됩니다. 역할은 자신의 계정 또는 그 밖의 다른 AWS 계정에 속한 것일 수 있습니다. 역할과 역할의 이점, 역할 생성 및 구성 방법에 대한 자세한 내용은 [IAM 역할](id_roles.md) 및 [IAM 역할 생성](id_roles_create.md) 섹션을 참조하세요. 역할을 수임하는 데 사용할 수 있는 여러 방법을 알아보려면 [역할 수임 방법](id_roles_manage-assume.md) 섹션을 참조하세요.

**중요**  
IAM 사용자의 권한과 수임한 역할의 권한은 누적되지 않습니다. 한 번에 오직 하나의 권한 집합만이 활성화됩니다. 어떤 역할을 수임할 때 이전 사용자 또는 역할 권한은 일시적으로 포기하고 해당 역할에 할당된 권한을 가지고 작업합니다. 역할을 끝내면 사용자 권한이 자동으로 회복됩니다.

IAM 사용자로 로그인한 경우 역할을 사용하여 AWS CLI 명령을 실행할 수 있습니다. 역할을 이미 사용 중인 [외부에서 인증된 사용자](id_roles_providers.md)([SAML](id_roles_providers_saml.md) 또는 [OIDC](id_roles_providers_oidc.md))로 로그인한 경우에도 역할을 사용하여 AWS CLI 명령을 실행할 수 있습니다. 또한 인스턴스 프로파일 전체에서 명령에 연결된 Amazon EC2 인스턴스 내에서 역할을 사용하여 AWS CLI 명령을 실행할 수 있습니다. AWS 계정 루트 사용자로 로그인되어 있을 때는 역할을 수임할 수 없습니다.

[**역할 체인**](id_roles.md#iam-term-role-chaining) - 역할의 권한을 사용하여 두 번째 역할에 액세스하는 역할 체인을 사용할 수도 있습니다.

기본적으로 역할 세션은 한 시간 동안 지속됩니다. `assume-role*` CLI 작업을 사용하여 역할을 수임하는 경우 `duration-seconds` 파라미터에 대한 값을 지정할 수 있습니다. 이 값의 범위는 900초(15분)에서 해당 역할에 대한 최대 세션 기간 설정까지일 수 있습니다. 콘솔에서 역할을 전환하면 세션 시간이 최대 1시간으로 제한됩니다. 역할에 대한 최댓값을 확인하는 방법을 알아보려면 [역할의 최대 세션 기간 업데이트](id_roles_update-role-settings.md#id_roles_update-session-duration) 섹션을 참조하세요.

역할 함께 묶기를 사용하는 경우 세션 기간은 최대 1시간으로 제한됩니다. 그런 다음 `duration-seconds` 파라미터를 사용하여 1시간보다 큰 값을 입력하면 이 작업에 실패합니다.

## 예제 시나리오: 프로덕션 역할로 전환
<a name="switch-role-cli-scenario-prod-env"></a>

개발 환경에서 작업하는 IAM 사용자라고 가정합니다. [AWS CLI](https://aws.amazon.com/cli/)의 명령줄로 프로덕션 환경에서 작업해야 하는 경우가 종종 있습니다. 사용할 수 있는 액세스 키 자격 증명 세트가 이미 하나 있습니다. 이 세트는 표준 IAM 사용자에게 할당된 액세스 키 페어일 수도 있고, SAML 또는 OIDC 페더레이션 보안 주체로 로그인한 경우에는 초기에 할당된 역할에 대한 액세스 키 페어일 수도 있습니다. 현재 권한에 의해 특정 IAM 역할을 수임할 수 있는 능력이 부여되는 경우, AWS CLI 구성 파일의 ‘profile’에서 해당 역할을 식별할 수 있습니다. 그러면 해당 명령은 원래 자격 증명이 아닌 지정된 IAM 역할의 권한으로 실행됩니다. AWS CLI 명령에서 해당 프로파일을 지정하는 경우에는 새 역할을 사용하게 됩니다. 이 경우 개발 계정의 원래 권한을 동시에 사용할 수 없습니다. 한 번에 한 가지 권한 세트만 적용될 수 있기 때문입니다.

**참고**  
보안을 위해 관리자는 [AWS CloudTrail 로그를 검토](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds)하여 AWS에서 누가 작업을 수행했는지 확인할 수 있습니다. 관리자는 사용자가 역할을 수임할 때 소스 자격 증명이나 역할 세션 이름을 지정하도록 요구할 수 있습니다. 자세한 내용은 [`sts:SourceIdentity`](reference_policies_iam-condition-keys.md#ck_sourceidentity) 및 [`sts:RoleSessionName`](reference_policies_iam-condition-keys.md#ck_rolesessionname)을(를) 참조하세요.

**프로덕션 역할로 전환(AWS CLI)**

1. <a name="step-configure-default"></a>AWS CLI를 사용한 적이 없을 경우 먼저 기본 CLI 프로필을 구성해야 합니다. 명령 프롬프트를 열고 IAM 사용자 또는 페더레이션 역할의 액세스 키를 사용하도록 AWS CLI 설치를 설정합니다. 자세한 내용은 *AWS Command Line Interface 사용 설명서*의 [AWS Command Line Interface 구성](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-quick-configuration)을 참조하세요.

   다음과 같이 [aws configure](https://docs.aws.amazon.com/cli/latest/reference/configure/) 명령을 실행합니다.

   ```
   aws configure
   ```

   요청 메시지가 나타나면 다음 정보를 입력합니다.

   ```
   AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
   AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
   Default region name [None]: us-east-2
   Default output format [None]: json
   ```

1. Unix 또는 Linux의 `.aws/config` 파일, 또는 Windows의 `C:\Users\USERNAME\.aws\config` 파일에서 역할에 대한 새 프로필을 만듭니다. 다음 예에서는 `123456789012` 계정의 `ProductionAccessRole` 역할로 전환하는 `prodaccess`라는 프로필을 만듭니다. 해당 역할을 만든 계정 관리자에게서 역할 ARN을 받습니다. 이 프로필이 호출되면 AWS CLI에서는 `source_profile`의 자격 증명을 사용하여 해당 역할의 자격 증명을 요청합니다. 이로 인해 `role_arn`로 참조되는 자격 증명에는 `source_profile`에 지정된 역할에 대한 `sts:AssumeRole` 권한이 있어야 합니다.

   ```
   [profile prodaccess]
       role_arn = arn:aws:iam::123456789012:role/ProductionAccessRole
       source_profile = default
   ```

1. 새 프로필을 만든 후 `--profile prodaccess` 파라미터를 지정하는 AWS CLI 명령은 기본 사용자 대신 IAM 역할 `ProductionAccessRole`에 연결된 권한에 따라 실행됩니다.

   ```
   aws iam list-users --profile prodaccess
   ```

   이 명령은 `ProductionAccessRole`에 할당된 권한이 현재 AWS 계정에 사용자를 나열하는 것을 가능하게 하는 경우에 작동합니다.

1. 원래 자격 증명에 의해 부여된 권한으로 돌아가려면 명령을 `--profile` 파라미터 없이 실행합니다. AWS CLI에서 다시 기본 프로필의 자격 증명([Step 1](#step-configure-default)에서 구성)이 사용됩니다.

자세한 내용은 *AWS Command Line Interface 사용 설명서*의 [역할 수임](https://docs.aws.amazon.com/cli/latest/userguide/cli-roles.html)을 참조하세요.

## 예제 시나리오: 인스턴스 프로파일 역할이 다른 계정의 역할로 전환하도록 허용
<a name="switch-role-cli-scenario-ec2-instance"></a>

두 개의 AWS 계정을 사용 중이고 Amazon EC2 인스턴스에서 실행 중인 특정 애플리케이션이 두 계정 모두에서 [AWS CLI](https://aws.amazon.com/cli/) 명령을 실행하도록 허용하고자 한다고 가정합니다. EC2 인스턴스가 `111111111111` 계정에 존재한다고 가정합니다. 해당 인스턴스에는 애플리케이션이 동일한 `111111111111` 계정 내에 있는 `amzn-s3-demo-bucket1` 버킷에서 읽기 전용 Amazon S3 작업을 수행하도록 허용하는 `abcd` 인스턴스 프로파일 역할이 포함되어 있습니다. 하지만 애플리케이션은 `efgh` 크로스 계정 역할을 수임하여 `222222222222` 계정에서 작업을 수행하도록 허용되어야 합니다. 이를 위해 `abcd` EC2 인스턴스 프로파일 역할에 다음과 같은 권한 정책이 있어야 합니다.

***계정 111111111111 `abcd` 역할 권한 정책***

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowAccountLevelS3Actions",
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAccessPoints",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Sid": "AllowListAndReadS3ActionOnMyBucket",
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket1/*",
                "arn:aws:s3:::amzn-s3-demo-bucket1"
            ]
        },
        {
            "Sid": "AllowIPToAssumeCrossAccountRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::222222222222:role/efgh"
        }
    ]
}
```

------

`efgh` 크로스 계정 역할이 동일한 `222222222222` 계정 내에 있는 `amzn-s3-demo-bucket2` 버킷에서 읽기 전용 Amazon S3 작업을 수행할 수 있다고 가정합니다. 이를 위해 `efgh` 크로스 계정 역할에 다음과 같은 권한 정책이 있어야 합니다.

***계정 222222222222 `efgh` 역할 권한 정책***

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowAccountLevelS3Actions",
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAccessPoints",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Sid": "AllowListAndReadS3ActionOnMyBucket",
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket2/*",
                "arn:aws:s3:::amzn-s3-demo-bucket2"
            ]
        }
    ]
}
```

------

`efgh` 역할은 `abcd` 인스턴스 프로파일 역할이 이를 수임하도록 허용해야 합니다. 이를 위해 `efgh` 역할에 다음과 같은 신뢰 정책이 있어야 합니다.

***계정 222222222222 `efgh` 역할 신뢰 정책***

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "efghTrustPolicy",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Principal": {"AWS": "arn:aws:iam::111111111111:role/abcd"}
        }
    ]
}
```

------

계정 `222222222222`에서 AWS CLI 명령을 실행하려면 CLI 구성 파일을 업데이트해야 합니다. AWS CLI 구성 파일에서 `efgh` 역할을 “프로파일”로 식별하고 `abcd` EC2 인스턴스 프로파일 역할을 “자격 증명 소스”로 식별합니다. 그런 다음 CLI 명령은 기존의 `abcd` 역할이 아닌 `efgh` 역할의 권한을 사용하여 실행됩니다.

**참고**  
계정에서 보안을 목적으로 AWS CloudTrail을 사용해 계정의 역할 사용을 감사할 수 있습니다. CloudTrail 로그에서 여러 보안 주체가 한 역할을 사용할 때 역할 세션 간을 구분하려면 역할 세션 이름을 사용할 수 있습니다. 이 항목에서 설명하는 것처럼 AWS CLI에서 사용자를 대신해 역할을 수임하면 역할 세션 이름이 `AWS-CLI-session-nnnnnnnn`으로 자동으로 생성됩니다. 여기서 *nnnnnnnn*은 [Unix epoch time](http://wikipedia.org/wiki/Unix_time)(1970년 1월 1일 자정 UTC 이후 경과된 초 수)으로 시간을 나타낸 정수입니다. 자세한 내용은 *AWS CloudTrail 사용 설명서*의 [CloudTrail 이벤트 참조](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/eventreference.html)를 참조하세요.

**EC2 인스턴스 프로파일 역할의 크로스 계정 역할 전환 허용(AWS CLI)**

1. 기본 CLI 프로파일을 구성할 필요가 없습니다. 대신 EC2 인스턴스 프로파일 메타데이터에서 자격 증명을 불러올 수 있습니다. `.aws/config` 파일에서 역할에 대한 새 프로파일을 만듭니다. 다음 예에서는 `222222222222` 계정의 `efgh` 역할로 전환하는 `instancecrossaccount`라는 프로필을 만듭니다. 이 프로필이 호출되면 AWS CLI에서는 EC2 인스턴스 프로파일 메타데이터의 자격 증명을 사용하여 해당 역할의 자격 증명을 요청합니다. 이로 인해 EC2 인스턴스 프로파일 역할에는 `role_arn`에 지정된 역할에 대한 `sts:AssumeRole` 권한이 있어야 합니다.

   ```
   [profile instancecrossaccount]
   role_arn = arn:aws:iam::222222222222:role/efgh
   credential_source = Ec2InstanceMetadata
   ```

1. 새 프로필을 만든 후 `--profile instancecrossaccount` 파라미터를 지정하는 AWS CLI 명령은 `222222222222` 계정의 `efgh` 역할에 연결된 권한에 따라 실행됩니다.

   ```
   aws s3 ls amzn-s3-demo-bucket2 --profile instancecrossaccount
   ```

   이 명령은 `efgh` 역할에 할당된 권한이 현재 AWS 계정에 사용자를 나열하는 것을 허용하는 경우에 작동합니다.

1. `111111111111` 계정의 원래 EC2 인스턴스 프로파일 권한을 반환하려면 `--profile` 파라미터 없이 CLI 명령을 실행합니다.

자세한 내용은 *AWS Command Line Interface 사용 설명서*의 [역할 수임](https://docs.aws.amazon.com/cli/latest/userguide/cli-roles.html)을 참조하세요.

# IAM 역할로 전환(Tools for Windows PowerShell)
<a name="id_roles_use_switch-role-twp"></a>

*역할*은 필요한 AWS 리소스에 액세스하는 데 사용할 수 있는 일련의 권한을 지정합니다. 이러한 면에서 [AWS Identity and Access Management(IAM)의 사용자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html)와 비슷합니다. 사용자로 로그인할 때는 특정 권한이 부여됩니다. 하지만 역할로 로그인하지는 못하기 때문에 일단 로그인한 후에 역할로 전환할 수 있습니다. 이 경우 초기의 사용자 권한은 잠시 무효화되고 역할에게 할당된 권한이 부여됩니다. 역할은 자신의 계정 또는 그 밖의 다른 AWS 계정에 속한 것일 수 있습니다. 역할과 역할의 이점, 역할 생성 및 구성 방법에 대한 자세한 내용은 [IAM 역할](id_roles.md) 및 [IAM 역할 생성](id_roles_create.md) 섹션을 참조하세요.

**중요**  
IAM 사용자의 권한과 전환 대상인 역할의 권한은 누적되지 않습니다. 한 번에 오직 하나의 권한 집합만이 활성화됩니다. 어떤 역할로 전환할 때 사용자 권한은 일시적으로 포기하고 역할에 할당된 권한을 가지고 작업합니다. 역할을 끝내면 사용자 권한이 자동으로 회복됩니다.

이 섹션에서는 AWS Tools for Windows PowerShell에서 명령줄로 작업할 때 역할을 전환하는 방법에 대해 기술합니다.

개발 환경에서 계정을 하나 갖고 있는데 이따금 명령줄에서 [Tools for Windows PowerShell](https://aws.amazon.com/powershell/)을 사용하여 프로덕션 환경으로 작업해야 할 때가 있다고 가정합시다. 사용할 수 있는 액세스 키 자격 증명 세트가 이미 하나 있습니다. 이 세트는 표준 IAM 사용자에게 할당된 액세스 키 페어일 수도 있고, 아니면 SAML 또는 OIDC 페더레이션 보안 주체로 로그인한 경우에는 초기에 할당된 역할에 대한 액세스 키 페어일 수도 있습니다. 이 자격 증명을 사용해 새 역할의 ARN을 파라미터로 전달하는 `Use-STSRole` cmdlet을 실행할 수 있습니다. 해당 명령은 요청된 역할에 대한 임시 보안 자격 증명을 반환합니다. 그런 다음 생산 중인 리소스에 액세스할 수 있는 해당 역할의 권한으로 후속 PowerShell 명령에서 이 자격 증명을 사용할 수 있습니다. 한 번에 한 가지 권한 세트만 적용되기 때문에 해당 역할을 사용하는 동안에는 개발 계정의 사용자 권한을 사용할 수 없습니다.

**참고**  
보안을 위해 관리자는 [AWS CloudTrail 로그를 검토](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds)하여 AWS에서 누가 작업을 수행했는지 확인할 수 있습니다. 관리자는 사용자가 역할을 수임할 때 소스 자격 증명이나 역할 세션 이름을 지정하도록 요구할 수 있습니다. 자세한 내용은 [`sts:SourceIdentity`](reference_policies_iam-condition-keys.md#ck_sourceidentity) 및 [`sts:RoleSessionName`](reference_policies_iam-condition-keys.md#ck_rolesessionname)을(를) 참조하세요.

모든 액세스 키와 토큰은 예시일 뿐이며 표시된 대로 사용할 수 없습니다. 라이브 환경의 적절한 값으로 바꾸세요.

**역할로 전환하려면(Tools for Windows PowerShell)**

1. PowerShell 명령 프롬프트를 열고 현재 IAM 사용자 또는 페더레이션 역할의 액세스 키를 사용하도록 기본 프로필을 구성합니다. 이전에 Tools for Windows PowerShell을 사용했다면 이미 그렇게 했을 가능성이 큽니다. AWS 계정 루트 사용자가 아닌 IAM 사용자로 로그인한 경우에 한해 역할을 바꿀 수 있다는 것에 유의하십시오.

   ```
   PS C:\> Set-AWSCredentials -AccessKey AKIAIOSFODNN7EXAMPLE -SecretKey wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY -StoreAs MyMainUserProfile
   PS C:\> Initialize-AWSDefaults -ProfileName MyMainUserProfile -Region us-east-2
   ```

   자세한 내용은 *AWS Tools for PowerShell 사용 설명서*에서 [AWS 자격 증명 사용](https://docs.aws.amazon.com/powershell/latest/userguide/specifying-your-aws-credentials.html)을 참조하세요.

1. 새 역할에 대한 자격 증명을 가져오려면, 다음 명령을 실행하여 123456789012 계정의 `RoleName` 역할로 전환합니다. 해당 역할을 만든 계정 관리자에게서 역할 ARN을 받습니다. 그 명령은 세션 이름도 제공할 것을 요구합니다. 세션 이름에 대해서는 어떤 텍스트도 선택 가능합니다. 다음 명령은 자격 증명을 요청한 다음, 반환된 결과 객체로부터 `Credentials` 속성 객체를 캡쳐해 `$Creds` 변수에 저장합니다.

   ```
   PS C:\> $Creds = (Use-STSRole -RoleArn "arn:aws:iam::123456789012:role/RoleName" -RoleSessionName "MyRoleSessionName").Credentials
   ```

   `$Creds`는 다음 절차에서 필요한 `AccessKeyId`, `SecretAccessKey` 및 `SessionToken` 요소를 포함하는 객체입니다. 다음 샘플 명령은 전형적인 값을 보여줍니다.

   ```
   PS C:\> $Creds.AccessKeyId
   AKIAIOSFODNN7EXAMPLE
   
   PS C:\> $Creds.SecretAccessKey
   wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
   
   PS C:\> $Creds.SessionToken
   AQoDYXdzEGcaEXAMPLE2gsYULo+Im5ZEXAMPLEeYjs1M2FUIgIJx9tQqNMBEXAMPLECvSRyh0FW7jEXAMPLEW+vE/7s1HRp
   XviG7b+qYf4nD00EXAMPLEmj4wxS04L/uZEXAMPLECihzFB5lTYLto9dyBgSDyEXAMPLE9/g7QRUhZp4bqbEXAMPLENwGPy
   Oj59pFA4lNKCIkVgkREXAMPLEjlzxQ7y52gekeVEXAMPLEDiB9ST3UuysgsKdEXAMPLE1TVastU1A0SKFEXAMPLEiywCC/C
   s8EXAMPLEpZgOs+6hz4AP4KEXAMPLERbASP+4eZScEXAMPLEsnf87eNhyDHq6ikBQ==
   
   PS C:\> $Creds.Expiration
   Thursday, June 18, 2018 2:28:31 PM
   ```

1. 후속 명령에 대해 이 자격 증명을 사용하려면 `-Credential` 파라미터로 자격 증명을 포함시키세요. 예를 들어 다음 명령은 그 역할에 `iam:ListRoles` 권한이 부여되고, 따라서 `Get-IAMRoles` cmdlet을 실행할 수 있는 경우에 한해 역할에서 얻은 자격 증명을 사용하고 작동됩니다.

   ```
           PS C:\> get-iamroles -Credential $Creds
   ```

1. 원래 자격 증명으로 돌아가려면 `-Credentials $Creds` 파라미터 사용을 중지하고 PowerShell이 기본 프로필에 저장된 자격 증명으로 복귀할 수 있도록 허용하기만 하면 됩니다.

# IAM 역할로 전환(AWS API)
<a name="id_roles_use_switch-role-api"></a>

*역할*은 AWS 리소스에 액세스하는 데 사용할 수 있는 일련의 권한을 지정합니다. 이러한 면에서 [IAM 사용자](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html)와 비슷합니다. 보안 주체(개인 또는 애플리케이션)은 역할을 수임하여 필요한 작업을 수행하고 AWS 리소스와 상호작용할 수 있는 임시 권한을 부여받습니다. 역할은 자신의 계정 또는 그 밖의 다른 AWS 계정에 속한 것일 수 있습니다. 역할과 역할의 이점, 역할 생성 및 구성 방법에 대한 자세한 내용은 [IAM 역할](id_roles.md) 및 [IAM 역할 생성](id_roles_create.md) 섹션을 참조하세요. 역할을 수임하는 데 사용할 수 있는 여러 방법을 알아보려면 [역할 수임 방법](id_roles_manage-assume.md) 섹션을 참조하세요.

**중요**  
IAM 사용자의 권한과 수임한 역할의 권한은 누적되지 않습니다. 한 번에 오직 하나의 권한 집합만이 활성화됩니다. 어떤 역할을 수임할 때 이전 사용자 또는 역할 권한은 일시적으로 포기하고 해당 역할에 할당된 권한을 가지고 작업합니다. 이 역할을 끝내면 원래 권한이 자동으로 회복됩니다.

이때 역할 위임을 위해 애플리케이션은 AWS STS [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API 작업을 호출하고 사용할 역할의 ARN을 전달합니다. 이 작업은 임시 자격 증명으로 사용하여 새 세션을 생성합니다. 이 세션에는 해당 역할에 대한 자격 증명 기반 정책과 동일한 권한이 지정됩니다.

[https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) 호출 시 선택적으로 인라인 또는 관리형 [세션 정책](access_policies.md#policies_session)을 전달할 수 있습니다. 세션 정책은 역할 또는 페더레이션 사용자 세션에 대해 임시 자격 증명 세션을 프로그래밍 방식으로 생성할 때 파라미터로 전달하는 고급 정책입니다. `Policy` 파라미터를 사용하여 단일 JSON 인라인 세션 정책 문서를 전달할 수 있습니다. `PolicyArns` 파라미터를 사용하여 최대 10개까지 관리형 세션 정책을 지정할 수 있습니다. 결과적으로 얻는 세션의 권한은 엔터티의 자격 증명 기반 정책과 세션 정책의 교집합입니다 세션 정책은 다른 사람에게 역할의 임시 보안 자격 증명을 부여할 필요가 있을 때 유용합니다. 후속 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)


IAM 사용자 또는 역할을 이미 사용 중인 [외부에서 인증된 사용자](id_roles_providers.md)([SAML](id_roles_providers_saml.md) 또는 [OIDC](id_roles_providers_oidc.md))로 로그인한 경우 `AssumeRole`을 직접적으로 호출할 수 있습니다. 또한 역할을 사용해 두 번째 역할을 수임하는 [*역할 함께 묶기*](id_roles.md#iam-term-role-chaining)를 사용할 수도 있습니다. AWS 계정 루트 사용자로 로그인되어 있을 때는 역할을 수임할 수 없습니다.

기본적으로 역할 세션은 한 시간 동안 지속됩니다. AWS STS [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API 작업을 사용하여 역할을 수임하는 경우 `DurationSeconds` 파라미터에 대한 값을 지정할 수 있습니다. 이 값의 범위는 900초(15분)에서 해당 역할에 대한 최대 세션 기간 설정까지일 수 있습니다. 역할에 대한 최댓값을 확인하는 방법을 알아보려면 [역할의 최대 세션 기간 업데이트](id_roles_update-role-settings.md#id_roles_update-session-duration) 섹션을 참조하세요.

역할 함께 묶기를 사용하는 경우 세션은 최대 1시간으로 제한됩니다. 그런 다음 `DurationSeconds` 파라미터를 사용하여 1시간보다 큰 값을 입력하면 이 작업에 실패합니다.

**참고**  
보안을 위해 관리자는 [AWS CloudTrail 로그를 검토](cloudtrail-integration.md#cloudtrail-integration_signin-tempcreds)하여 AWS에서 누가 작업을 수행했는지 확인할 수 있습니다. 관리자는 사용자가 역할을 수임할 때 소스 자격 증명이나 역할 세션 이름을 지정하도록 요구할 수 있습니다. 자세한 내용은 [`sts:SourceIdentity`](reference_policies_iam-condition-keys.md#ck_sourceidentity) 및 [`sts:RoleSessionName`](reference_policies_iam-condition-keys.md#ck_rolesessionname)을(를) 참조하세요.

다음 코드 예제에서는 사용자를 생성하고 역할을 수임하는 방법을 보여줍니다.

**주의**  
보안 위험을 방지하려면 목적별 소프트웨어를 개발하거나 실제 데이터로 작업할 때 IAM 사용자를 인증에 사용하지 마세요. 대신 [AWS IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)과 같은 자격 증명 공급자를 통한 페더레이션을 사용하세요.
+ 권한이 없는 사용자를 생성합니다.
+ 계정에 대한 Amazon S3 버킷을 나열할 수 있는 권한을 부여하는 역할을 생성합니다.
+ 사용자가 역할을 수임할 수 있도록 정책을 추가합니다.
+ 역할을 수임하고 임시 자격 증명 정보를 사용하여 S3 버킷을 나열한 후 리소스를 정리합니다.

------
#### [ .NET ]

**SDK for .NET**  
 GitHub에 더 많은 내용이 있습니다. [AWS 코드 예제 리포지토리](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/dotnetv3/IAM#code-examples)에서 전체 예제를 확인하고 설정 및 실행하는 방법을 알아보세요.

```
global using Amazon.IdentityManagement;
global using Amazon.S3;
global using Amazon.SecurityToken;
global using IAMActions;
global using IamScenariosCommon;
global using Microsoft.Extensions.DependencyInjection;
global using Microsoft.Extensions.Hosting;
global using Microsoft.Extensions.Logging;
global using Microsoft.Extensions.Logging.Console;
global using Microsoft.Extensions.Logging.Debug;


namespace IAMActions;

public class IAMWrapper
{
    private readonly IAmazonIdentityManagementService _IAMService;

    /// <summary>
    /// Constructor for the IAMWrapper class.
    /// </summary>
    /// <param name="IAMService">An IAM client object.</param>
    public IAMWrapper(IAmazonIdentityManagementService IAMService)
    {
        _IAMService = IAMService;
    }

    /// <summary>
    /// Attach an IAM policy to a role.
    /// </summary>
    /// <param name="policyArn">The policy to attach.</param>
    /// <param name="roleName">The role that the policy will be attached to.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> AttachRolePolicyAsync(string policyArn, string roleName)
    {
        var response = await _IAMService.AttachRolePolicyAsync(new AttachRolePolicyRequest
        {
            PolicyArn = policyArn,
            RoleName = roleName,
        });

        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }


    /// <summary>
    /// Create an IAM access key for a user.
    /// </summary>
    /// <param name="userName">The username for which to create the IAM access
    /// key.</param>
    /// <returns>The AccessKey.</returns>
    public async Task<AccessKey> CreateAccessKeyAsync(string userName)
    {
        var response = await _IAMService.CreateAccessKeyAsync(new CreateAccessKeyRequest
        {
            UserName = userName,
        });

        return response.AccessKey;

    }


    /// <summary>
    /// Create an IAM policy.
    /// </summary>
    /// <param name="policyName">The name to give the new IAM policy.</param>
    /// <param name="policyDocument">The policy document for the new policy.</param>
    /// <returns>The new IAM policy object.</returns>
    public async Task<ManagedPolicy> CreatePolicyAsync(string policyName, string policyDocument)
    {
        var response = await _IAMService.CreatePolicyAsync(new CreatePolicyRequest
        {
            PolicyDocument = policyDocument,
            PolicyName = policyName,
        });

        return response.Policy;
    }


    /// <summary>
    /// Create a new IAM role.
    /// </summary>
    /// <param name="roleName">The name of the IAM role.</param>
    /// <param name="rolePolicyDocument">The name of the IAM policy document
    /// for the new role.</param>
    /// <returns>The Amazon Resource Name (ARN) of the role.</returns>
    public async Task<string> CreateRoleAsync(string roleName, string rolePolicyDocument)
    {
        var request = new CreateRoleRequest
        {
            RoleName = roleName,
            AssumeRolePolicyDocument = rolePolicyDocument,
        };

        var response = await _IAMService.CreateRoleAsync(request);
        return response.Role.Arn;
    }


    /// <summary>
    /// Create an IAM service-linked role.
    /// </summary>
    /// <param name="serviceName">The name of the AWS Service.</param>
    /// <param name="description">A description of the IAM service-linked role.</param>
    /// <returns>The IAM role that was created.</returns>
    public async Task<Role> CreateServiceLinkedRoleAsync(string serviceName, string description)
    {
        var request = new CreateServiceLinkedRoleRequest
        {
            AWSServiceName = serviceName,
            Description = description
        };

        var response = await _IAMService.CreateServiceLinkedRoleAsync(request);
        return response.Role;
    }


    /// <summary>
    /// Create an IAM user.
    /// </summary>
    /// <param name="userName">The username for the new IAM user.</param>
    /// <returns>The IAM user that was created.</returns>
    public async Task<User> CreateUserAsync(string userName)
    {
        var response = await _IAMService.CreateUserAsync(new CreateUserRequest { UserName = userName });
        return response.User;
    }


    /// <summary>
    /// Delete an IAM user's access key.
    /// </summary>
    /// <param name="accessKeyId">The Id for the IAM access key.</param>
    /// <param name="userName">The username of the user that owns the IAM
    /// access key.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> DeleteAccessKeyAsync(string accessKeyId, string userName)
    {
        var response = await _IAMService.DeleteAccessKeyAsync(new DeleteAccessKeyRequest
        {
            AccessKeyId = accessKeyId,
            UserName = userName,
        });

        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }


    /// <summary>
    /// Delete an IAM policy.
    /// </summary>
    /// <param name="policyArn">The Amazon Resource Name (ARN) of the policy to
    /// delete.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> DeletePolicyAsync(string policyArn)
    {
        var response = await _IAMService.DeletePolicyAsync(new DeletePolicyRequest { PolicyArn = policyArn });
        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }


    /// <summary>
    /// Delete an IAM role.
    /// </summary>
    /// <param name="roleName">The name of the IAM role to delete.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> DeleteRoleAsync(string roleName)
    {
        var response = await _IAMService.DeleteRoleAsync(new DeleteRoleRequest { RoleName = roleName });
        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }


    /// <summary>
    /// Delete an IAM role policy.
    /// </summary>
    /// <param name="roleName">The name of the IAM role.</param>
    /// <param name="policyName">The name of the IAM role policy to delete.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> DeleteRolePolicyAsync(string roleName, string policyName)
    {
        var response = await _IAMService.DeleteRolePolicyAsync(new DeleteRolePolicyRequest
        {
            PolicyName = policyName,
            RoleName = roleName,
        });

        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }


    /// <summary>
    /// Delete an IAM user.
    /// </summary>
    /// <param name="userName">The username of the IAM user to delete.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> DeleteUserAsync(string userName)
    {
        var response = await _IAMService.DeleteUserAsync(new DeleteUserRequest { UserName = userName });

        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }


    /// <summary>
    /// Delete an IAM user policy.
    /// </summary>
    /// <param name="policyName">The name of the IAM policy to delete.</param>
    /// <param name="userName">The username of the IAM user.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> DeleteUserPolicyAsync(string policyName, string userName)
    {
        var response = await _IAMService.DeleteUserPolicyAsync(new DeleteUserPolicyRequest { PolicyName = policyName, UserName = userName });

        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }


    /// <summary>
    /// Detach an IAM policy from an IAM role.
    /// </summary>
    /// <param name="policyArn">The Amazon Resource Name (ARN) of the IAM policy.</param>
    /// <param name="roleName">The name of the IAM role.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> DetachRolePolicyAsync(string policyArn, string roleName)
    {
        var response = await _IAMService.DetachRolePolicyAsync(new DetachRolePolicyRequest
        {
            PolicyArn = policyArn,
            RoleName = roleName,
        });

        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }


    /// <summary>
    /// Gets the IAM password policy for an AWS account.
    /// </summary>
    /// <returns>The PasswordPolicy for the AWS account.</returns>
    public async Task<PasswordPolicy> GetAccountPasswordPolicyAsync()
    {
        var response = await _IAMService.GetAccountPasswordPolicyAsync(new GetAccountPasswordPolicyRequest());
        return response.PasswordPolicy;
    }


    /// <summary>
    /// Get information about an IAM policy.
    /// </summary>
    /// <param name="policyArn">The IAM policy to retrieve information for.</param>
    /// <returns>The IAM policy.</returns>
    public async Task<ManagedPolicy> GetPolicyAsync(string policyArn)
    {

        var response = await _IAMService.GetPolicyAsync(new GetPolicyRequest { PolicyArn = policyArn });
        return response.Policy;
    }


    /// <summary>
    /// Get information about an IAM role.
    /// </summary>
    /// <param name="roleName">The name of the IAM role to retrieve information
    /// for.</param>
    /// <returns>The IAM role that was retrieved.</returns>
    public async Task<Role> GetRoleAsync(string roleName)
    {
        var response = await _IAMService.GetRoleAsync(new GetRoleRequest
        {
            RoleName = roleName,
        });

        return response.Role;
    }


    /// <summary>
    /// Get information about an IAM user.
    /// </summary>
    /// <param name="userName">The username of the user.</param>
    /// <returns>An IAM user object.</returns>
    public async Task<User> GetUserAsync(string userName)
    {
        var response = await _IAMService.GetUserAsync(new GetUserRequest { UserName = userName });
        return response.User;
    }


    /// <summary>
    /// List the IAM role policies that are attached to an IAM role.
    /// </summary>
    /// <param name="roleName">The IAM role to list IAM policies for.</param>
    /// <returns>A list of the IAM policies attached to the IAM role.</returns>
    public async Task<List<AttachedPolicyType>> ListAttachedRolePoliciesAsync(string roleName)
    {
        var attachedPolicies = new List<AttachedPolicyType>();
        var attachedRolePoliciesPaginator = _IAMService.Paginators.ListAttachedRolePolicies(new ListAttachedRolePoliciesRequest { RoleName = roleName });

        await foreach (var response in attachedRolePoliciesPaginator.Responses)
        {
            attachedPolicies.AddRange(response.AttachedPolicies);
        }

        return attachedPolicies;
    }


    /// <summary>
    /// List IAM groups.
    /// </summary>
    /// <returns>A list of IAM groups.</returns>
    public async Task<List<Group>> ListGroupsAsync()
    {
        var groupsPaginator = _IAMService.Paginators.ListGroups(new ListGroupsRequest());
        var groups = new List<Group>();

        await foreach (var response in groupsPaginator.Responses)
        {
            groups.AddRange(response.Groups);
        }

        return groups;
    }


    /// <summary>
    /// List IAM policies.
    /// </summary>
    /// <returns>A list of the IAM policies.</returns>
    public async Task<List<ManagedPolicy>> ListPoliciesAsync()
    {
        var listPoliciesPaginator = _IAMService.Paginators.ListPolicies(new ListPoliciesRequest());
        var policies = new List<ManagedPolicy>();

        await foreach (var response in listPoliciesPaginator.Responses)
        {
            policies.AddRange(response.Policies);
        }

        return policies;
    }


    /// <summary>
    /// List IAM role policies.
    /// </summary>
    /// <param name="roleName">The IAM role for which to list IAM policies.</param>
    /// <returns>A list of IAM policy names.</returns>
    public async Task<List<string>> ListRolePoliciesAsync(string roleName)
    {
        var listRolePoliciesPaginator = _IAMService.Paginators.ListRolePolicies(new ListRolePoliciesRequest { RoleName = roleName });
        var policyNames = new List<string>();

        await foreach (var response in listRolePoliciesPaginator.Responses)
        {
            policyNames.AddRange(response.PolicyNames);
        }

        return policyNames;
    }


    /// <summary>
    /// List IAM roles.
    /// </summary>
    /// <returns>A list of IAM roles.</returns>
    public async Task<List<Role>> ListRolesAsync()
    {
        var listRolesPaginator = _IAMService.Paginators.ListRoles(new ListRolesRequest());
        var roles = new List<Role>();

        await foreach (var response in listRolesPaginator.Responses)
        {
            roles.AddRange(response.Roles);
        }

        return roles;
    }


    /// <summary>
    /// List SAML authentication providers.
    /// </summary>
    /// <returns>A list of SAML providers.</returns>
    public async Task<List<SAMLProviderListEntry>> ListSAMLProvidersAsync()
    {
        var response = await _IAMService.ListSAMLProvidersAsync(new ListSAMLProvidersRequest());
        return response.SAMLProviderList;
    }


    /// <summary>
    /// List IAM users.
    /// </summary>
    /// <returns>A list of IAM users.</returns>
    public async Task<List<User>> ListUsersAsync()
    {
        var listUsersPaginator = _IAMService.Paginators.ListUsers(new ListUsersRequest());
        var users = new List<User>();

        await foreach (var response in listUsersPaginator.Responses)
        {
            users.AddRange(response.Users);
        }

        return users;
    }


    /// <summary>
    /// Update the inline policy document embedded in a role.
    /// </summary>
    /// <param name="policyName">The name of the policy to embed.</param>
    /// <param name="roleName">The name of the role to update.</param>
    /// <param name="policyDocument">The policy document that defines the role.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> PutRolePolicyAsync(string policyName, string roleName, string policyDocument)
    {
        var request = new PutRolePolicyRequest
        {
            PolicyName = policyName,
            RoleName = roleName,
            PolicyDocument = policyDocument
        };

        var response = await _IAMService.PutRolePolicyAsync(request);
        return response.HttpStatusCode == HttpStatusCode.OK;
    }


    /// <summary>
    /// Add or update an inline policy document that is embedded in an IAM user.
    /// </summary>
    /// <param name="userName">The name of the IAM user.</param>
    /// <param name="policyName">The name of the IAM policy.</param>
    /// <param name="policyDocument">The policy document defining the IAM policy.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> PutUserPolicyAsync(string userName, string policyName, string policyDocument)
    {
        var request = new PutUserPolicyRequest
        {
            UserName = userName,
            PolicyName = policyName,
            PolicyDocument = policyDocument
        };

        var response = await _IAMService.PutUserPolicyAsync(request);
        return response.HttpStatusCode == System.Net.HttpStatusCode.OK;
    }

    /// <summary>
    /// Wait for a new access key to be ready to use.
    /// </summary>
    /// <param name="accessKeyId">The Id of the access key.</param>
    /// <returns>A boolean value indicating the success of the action.</returns>
    public async Task<bool> WaitUntilAccessKeyIsReady(string accessKeyId)
    {
        var keyReady = false;

        do
        {
            try
            {
                var response = await _IAMService.GetAccessKeyLastUsedAsync(
                    new GetAccessKeyLastUsedRequest { AccessKeyId = accessKeyId });
                if (response.UserName is not null)
                {
                    keyReady = true;
                }
            }
            catch (NoSuchEntityException)
            {
                keyReady = false;
            }
        } while (!keyReady);

        return keyReady;
    }
}



using Microsoft.Extensions.Configuration;

namespace IAMBasics;

public class IAMBasics
{
    private static ILogger logger = null!;

    static async Task Main(string[] args)
    {
        // Set up dependency injection for the AWS service.
        using var host = Host.CreateDefaultBuilder(args)
            .ConfigureLogging(logging =>
                logging.AddFilter("System", LogLevel.Debug)
                    .AddFilter<DebugLoggerProvider>("Microsoft", LogLevel.Information)
                    .AddFilter<ConsoleLoggerProvider>("Microsoft", LogLevel.Trace))
            .ConfigureServices((_, services) =>
            services.AddAWSService<IAmazonIdentityManagementService>()
            .AddTransient<IAMWrapper>()
            .AddTransient<UIWrapper>()
            )
            .Build();

        logger = LoggerFactory.Create(builder => { builder.AddConsole(); })
            .CreateLogger<IAMBasics>();


        IConfiguration configuration = new ConfigurationBuilder()
            .SetBasePath(Directory.GetCurrentDirectory())
            .AddJsonFile("settings.json") // Load test settings from .json file.
            .AddJsonFile("settings.local.json",
                true) // Optionally load local settings.
            .Build();

        // Values needed for user, role, and policies.
        string userName = configuration["UserName"]!;
        string s3PolicyName = configuration["S3PolicyName"]!;
        string roleName = configuration["RoleName"]!;


        var iamWrapper = host.Services.GetRequiredService<IAMWrapper>();
        var uiWrapper = host.Services.GetRequiredService<UIWrapper>();

        uiWrapper.DisplayBasicsOverview();
        uiWrapper.PressEnter();

        // First create a user. By default, the new user has
        // no permissions.
        uiWrapper.DisplayTitle("Create User");
        Console.WriteLine($"Creating a new user with user name: {userName}.");
        var user = await iamWrapper.CreateUserAsync(userName);
        var userArn = user.Arn;

        Console.WriteLine($"Successfully created user: {userName} with ARN: {userArn}.");
        uiWrapper.WaitABit(15, "Now let's wait for the user to be ready for use.");

        // Define a role policy document that allows the new user
        // to assume the role.
        string assumeRolePolicyDocument = "{" +
          "\"Version\": \"2012-10-17\"," +
          "\"Statement\": [{" +
              "\"Effect\": \"Allow\"," +
              "\"Principal\": {" +
              $"	\"AWS\": \"{userArn}\"" +
              "}," +
              "\"Action\": \"sts:AssumeRole\"" +
          "}]" +
        "}";

        // Permissions to list all buckets.
        string policyDocument = "{" +
            "\"Version\": \"2012-10-17\"," +
            "	\"Statement\" : [{" +
                "	\"Action\" : [\"s3:ListAllMyBuckets\"]," +
                "	\"Effect\" : \"Allow\"," +
                "	\"Resource\" : \"*\"" +
            "}]" +
        "}";

        // Create an AccessKey for the user.
        uiWrapper.DisplayTitle("Create access key");
        Console.WriteLine("Now let's create an access key for the new user.");
        var accessKey = await iamWrapper.CreateAccessKeyAsync(userName);

        var accessKeyId = accessKey.AccessKeyId;
        var secretAccessKey = accessKey.SecretAccessKey;

        Console.WriteLine($"We have created the access key with Access key id: {accessKeyId}.");

        Console.WriteLine("Now let's wait until the IAM access key is ready to use.");
        var keyReady = await iamWrapper.WaitUntilAccessKeyIsReady(accessKeyId);

        // Now try listing the Amazon Simple Storage Service (Amazon S3)
        // buckets. This should fail at this point because the user doesn't
        // have permissions to perform this task.
        uiWrapper.DisplayTitle("Try to display Amazon S3 buckets");
        Console.WriteLine("Now let's try to display a list of the user's Amazon S3 buckets.");
        var s3Client1 = new AmazonS3Client(accessKeyId, secretAccessKey);
        var stsClient1 = new AmazonSecurityTokenServiceClient(accessKeyId, secretAccessKey);

        var s3Wrapper = new S3Wrapper(s3Client1, stsClient1);
        var buckets = await s3Wrapper.ListMyBucketsAsync();

        Console.WriteLine(buckets is null
            ? "As expected, the call to list the buckets has returned a null list."
            : "Something went wrong. This shouldn't have worked.");

        uiWrapper.PressEnter();

        uiWrapper.DisplayTitle("Create IAM role");
        Console.WriteLine($"Creating the role: {roleName}");

        // Creating an IAM role to allow listing the S3 buckets. A role name
        // is not case sensitive and must be unique to the account for which it
        // is created.
        var roleArn = await iamWrapper.CreateRoleAsync(roleName, assumeRolePolicyDocument);

        uiWrapper.PressEnter();

        // Create a policy with permissions to list S3 buckets.
        uiWrapper.DisplayTitle("Create IAM policy");
        Console.WriteLine($"Creating the policy: {s3PolicyName}");
        Console.WriteLine("with permissions to list the Amazon S3 buckets for the account.");
        var policy = await iamWrapper.CreatePolicyAsync(s3PolicyName, policyDocument);

        // Wait 15 seconds for the IAM policy to be available.
        uiWrapper.WaitABit(15, "Waiting for the policy to be available.");

        // Attach the policy to the role you created earlier.
        uiWrapper.DisplayTitle("Attach new IAM policy");
        Console.WriteLine("Now let's attach the policy to the role.");
        await iamWrapper.AttachRolePolicyAsync(policy.Arn, roleName);

        // Wait 15 seconds for the role to be updated.
        Console.WriteLine();
        uiWrapper.WaitABit(15, "Waiting for the policy to be attached.");

        // Use the AWS Security Token Service (AWS STS) to have the user
        // assume the role we created.
        var stsClient2 = new AmazonSecurityTokenServiceClient(accessKeyId, secretAccessKey);

        // Wait for the new credentials to become valid.
        uiWrapper.WaitABit(10, "Waiting for the credentials to be valid.");

        var assumedRoleCredentials = await s3Wrapper.AssumeS3RoleAsync("temporary-session", roleArn);

        // Try again to list the buckets using the client created with
        // the new user's credentials. This time, it should work.
        var s3Client2 = new AmazonS3Client(assumedRoleCredentials);

        s3Wrapper.UpdateClients(s3Client2, stsClient2);

        buckets = await s3Wrapper.ListMyBucketsAsync();

        uiWrapper.DisplayTitle("List Amazon S3 buckets");
        Console.WriteLine("This time we should have buckets to list.");
        if (buckets is not null)
        {
            buckets.ForEach(bucket =>
            {
                Console.WriteLine($"{bucket.BucketName} created: {bucket.CreationDate}");
            });
        }

        uiWrapper.PressEnter();

        // Now clean up all the resources used in the example.
        uiWrapper.DisplayTitle("Clean up resources");
        Console.WriteLine("Thank you for watching. The IAM Basics demo is complete.");
        Console.WriteLine("Please wait while we clean up the resources we created.");

        await iamWrapper.DetachRolePolicyAsync(policy.Arn, roleName);

        await iamWrapper.DeletePolicyAsync(policy.Arn);

        await iamWrapper.DeleteRoleAsync(roleName);

        await iamWrapper.DeleteAccessKeyAsync(accessKeyId, userName);

        await iamWrapper.DeleteUserAsync(userName);

        uiWrapper.PressEnter();

        Console.WriteLine("All done cleaning up our resources. Thank you for your patience.");
    }
}


namespace IamScenariosCommon;

using System.Net;

/// <summary>
/// A class to perform Amazon Simple Storage Service (Amazon S3) actions for
/// the IAM Basics scenario.
/// </summary>
public class S3Wrapper
{
    private IAmazonS3 _s3Service;
    private IAmazonSecurityTokenService _stsService;

    /// <summary>
    /// Constructor for the S3Wrapper class.
    /// </summary>
    /// <param name="s3Service">An Amazon S3 client object.</param>
    /// <param name="stsService">An AWS Security Token Service (AWS STS)
    /// client object.</param>
    public S3Wrapper(IAmazonS3 s3Service, IAmazonSecurityTokenService stsService)
    {
        _s3Service = s3Service;
        _stsService = stsService;
    }

    /// <summary>
    /// Assumes an AWS Identity and Access Management (IAM) role that allows
    /// Amazon S3 access for the current session.
    /// </summary>
    /// <param name="roleSession">A string representing the current session.</param>
    /// <param name="roleToAssume">The name of the IAM role to assume.</param>
    /// <returns>Credentials for the newly assumed IAM role.</returns>
    public async Task<Credentials> AssumeS3RoleAsync(string roleSession, string roleToAssume)
    {
        // Create the request to use with the AssumeRoleAsync call.
        var request = new AssumeRoleRequest()
        {
            RoleSessionName = roleSession,
            RoleArn = roleToAssume,
        };

        var response = await _stsService.AssumeRoleAsync(request);

        return response.Credentials;
    }


    /// <summary>
    /// Delete an S3 bucket.
    /// </summary>
    /// <param name="bucketName">Name of the S3 bucket to delete.</param>
    /// <returns>A Boolean value indicating the success of the action.</returns>
    public async Task<bool> DeleteBucketAsync(string bucketName)
    {
        var result = await _s3Service.DeleteBucketAsync(new DeleteBucketRequest { BucketName = bucketName });
        return result.HttpStatusCode == HttpStatusCode.OK;
    }

    /// <summary>
    /// List the buckets that are owned by the user's account.
    /// </summary>
    /// <returns>Async Task.</returns>
    public async Task<List<S3Bucket>?> ListMyBucketsAsync()
    {
        try
        {
            // Get the list of buckets accessible by the new user.
            var response = await _s3Service.ListBucketsAsync();

            return response.Buckets;
        }
        catch (AmazonS3Exception ex)
        {
            // Something else went wrong. Display the error message.
            Console.WriteLine($"Error: {ex.Message}");
            return null;
        }
    }

    /// <summary>
    /// Create a new S3 bucket.
    /// </summary>
    /// <param name="bucketName">The name for the new bucket.</param>
    /// <returns>A Boolean value indicating whether the action completed
    /// successfully.</returns>
    public async Task<bool> PutBucketAsync(string bucketName)
    {
        var response = await _s3Service.PutBucketAsync(new PutBucketRequest { BucketName = bucketName });
        return response.HttpStatusCode == HttpStatusCode.OK;
    }

    /// <summary>
    /// Update the client objects with new client objects. This is available
    /// because the scenario uses the methods of this class without and then
    /// with the proper permissions to list S3 buckets.
    /// </summary>
    /// <param name="s3Service">The Amazon S3 client object.</param>
    /// <param name="stsService">The AWS STS client object.</param>
    public void UpdateClients(IAmazonS3 s3Service, IAmazonSecurityTokenService stsService)
    {
        _s3Service = s3Service;
        _stsService = stsService;
    }
}


namespace IamScenariosCommon;

public class UIWrapper
{
    public readonly string SepBar = new('-', Console.WindowWidth);

    /// <summary>
    /// Show information about the IAM Groups scenario.
    /// </summary>
    public void DisplayGroupsOverview()
    {
        Console.Clear();

        DisplayTitle("Welcome to the IAM Groups Demo");
        Console.WriteLine("This example application does the following:");
        Console.WriteLine("\t1. Creates an Amazon Identity and Access Management (IAM) group.");
        Console.WriteLine("\t2. Adds an IAM policy to the IAM group giving it full access to Amazon S3.");
        Console.WriteLine("\t3. Creates a new IAM user.");
        Console.WriteLine("\t4. Creates an IAM access key for the user.");
        Console.WriteLine("\t5. Adds the user to the IAM group.");
        Console.WriteLine("\t6. Lists the buckets on the account.");
        Console.WriteLine("\t7. Proves that the user has full Amazon S3 access by creating a bucket.");
        Console.WriteLine("\t8. List the buckets again to show the new bucket.");
        Console.WriteLine("\t9. Cleans up all the resources created.");
    }

    /// <summary>
    /// Show information about the IAM Basics scenario.
    /// </summary>
    public void DisplayBasicsOverview()
    {
        Console.Clear();

        DisplayTitle("Welcome to IAM Basics");
        Console.WriteLine("This example application does the following:");
        Console.WriteLine("\t1. Creates a user with no permissions.");
        Console.WriteLine("\t2. Creates a role and policy that grant s3:ListAllMyBuckets permission.");
        Console.WriteLine("\t3. Grants the user permission to assume the role.");
        Console.WriteLine("\t4. Creates an S3 client object as the user and tries to list buckets (this will fail).");
        Console.WriteLine("\t5. Gets temporary credentials by assuming the role.");
        Console.WriteLine("\t6. Creates a new S3 client object with the temporary credentials and lists the buckets (this will succeed).");
        Console.WriteLine("\t7. Deletes all the resources.");
    }

    /// <summary>
    /// Display a message and wait until the user presses enter.
    /// </summary>
    public void PressEnter()
    {
        Console.Write("\nPress <Enter> to continue. ");
        _ = Console.ReadLine();
        Console.WriteLine();
    }

    /// <summary>
    /// Pad a string with spaces to center it on the console display.
    /// </summary>
    /// <param name="strToCenter">The string to be centered.</param>
    /// <returns>The padded string.</returns>
    public string CenterString(string strToCenter)
    {
        var padAmount = (Console.WindowWidth - strToCenter.Length) / 2;
        var leftPad = new string(' ', padAmount);
        return $"{leftPad}{strToCenter}";
    }

    /// <summary>
    /// Display a line of hyphens, the centered text of the title, and another
    /// line of hyphens.
    /// </summary>
    /// <param name="strTitle">The string to be displayed.</param>
    public void DisplayTitle(string strTitle)
    {
        Console.WriteLine(SepBar);
        Console.WriteLine(CenterString(strTitle));
        Console.WriteLine(SepBar);
    }

    /// <summary>
    /// Display a countdown and wait for a number of seconds.
    /// </summary>
    /// <param name="numSeconds">The number of seconds to wait.</param>
    public void WaitABit(int numSeconds, string msg)
    {
        Console.WriteLine(msg);

        // Wait for the requested number of seconds.
        for (int i = numSeconds; i > 0; i--)
        {
            System.Threading.Thread.Sleep(1000);
            Console.Write($"{i}...");
        }

        PressEnter();
    }
}
```
+ API 세부 정보는 *AWS SDK for .NET API 참조*의 다음 주제를 참조하세요.
  + [AttachRolePolicy](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/AttachRolePolicy)
  + [CreateAccessKey](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/CreateAccessKey)
  + [CreatePolicy](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/CreatePolicy)
  + [CreateRole](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/CreateRole)
  + [CreateUser](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/CreateUser)
  + [DeleteAccessKey](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/DeleteAccessKey)
  + [DeletePolicy](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/DeletePolicy)
  + [DeleteRole](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/DeleteRole)
  + [DeleteUser](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/DeleteUser)
  + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/DeleteUserPolicy)
  + [DetachRolePolicy](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/DetachRolePolicy)
  + [PutUserPolicy](https://docs.aws.amazon.com/goto/DotNetSDKV3/iam-2010-05-08/PutUserPolicy)

------
#### [ Bash ]

**Bash 스크립트와 함께 AWS CLI사용**  
 GitHub에 더 많은 내용이 있습니다. [AWS 코드 예제 리포지토리](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/aws-cli/bash-linux/iam#code-examples)에서 전체 예제를 확인하고 설정 및 실행하는 방법을 알아보세요.

```
###############################################################################
# function iam_create_user_assume_role
#
# Scenario to create an IAM user, create an IAM role, and apply the role to the user.
#
#     "IAM access" permissions are needed to run this code.
#     "STS assume role" permissions are needed to run this code. (Note: It might be necessary to
#           create a custom policy).
#
# Returns:
#       0 - If successful.
#       1 - If an error occurred.
###############################################################################
function iam_create_user_assume_role() {
  {
    if [ "$IAM_OPERATIONS_SOURCED" != "True" ]; then

      source ./iam_operations.sh
    fi
  }

  echo_repeat "*" 88
  echo "Welcome to the IAM create user and assume role demo."
  echo
  echo "This demo will create an IAM user, create an IAM role, and apply the role to the user."
  echo_repeat "*" 88
  echo

  echo -n "Enter a name for a new IAM user: "
  get_input
  user_name=$get_input_result

  local user_arn
  user_arn=$(iam_create_user -u "$user_name")

  # shellcheck disable=SC2181
  if [[ ${?} == 0 ]]; then
    echo "Created demo IAM user named $user_name"
  else
    errecho "$user_arn"
    errecho "The user failed to create. This demo will exit."
    return 1
  fi

  local access_key_response
  access_key_response=$(iam_create_user_access_key -u "$user_name")
  # shellcheck disable=SC2181
  if [[ ${?} != 0 ]]; then
    errecho "The access key failed to create. This demo will exit."
    clean_up "$user_name"
    return 1
  fi

  IFS=$'\t ' read -r -a access_key_values <<<"$access_key_response"
  local key_name=${access_key_values[0]}
  local key_secret=${access_key_values[1]}

  echo "Created access key named $key_name"

  echo "Wait 10 seconds for the user to be ready."
  sleep 10
  echo_repeat "*" 88
  echo

  local iam_role_name
  iam_role_name=$(generate_random_name "test-role")
  echo "Creating a role named $iam_role_name with user $user_name as the principal."

  local assume_role_policy_document="{
    \"Version\": \"2012-10-17\",
    \"Statement\": [{
        \"Effect\": \"Allow\",
        \"Principal\": {\"AWS\": \"$user_arn\"},
        \"Action\": \"sts:AssumeRole\"
        }]
    }"

  local role_arn
  role_arn=$(iam_create_role -n "$iam_role_name" -p "$assume_role_policy_document")

  # shellcheck disable=SC2181
  if [ ${?} == 0 ]; then
    echo "Created IAM role named $iam_role_name"
  else
    errecho "The role failed to create. This demo will exit."
    clean_up "$user_name" "$key_name"
    return 1
  fi

  local policy_name
  policy_name=$(generate_random_name "test-policy")
  local policy_document="{
                \"Version\": \"2012-10-17\",
                \"Statement\": [{
                    \"Effect\": \"Allow\",
                    \"Action\": \"s3:ListAllMyBuckets\",
                    \"Resource\": \"arn:aws:s3:::*\"}]}"

  local policy_arn
  policy_arn=$(iam_create_policy -n "$policy_name" -p "$policy_document")
  # shellcheck disable=SC2181
  if [[ ${?} == 0 ]]; then
    echo "Created  IAM policy named $policy_name"
  else
    errecho "The policy failed to create."
    clean_up "$user_name" "$key_name" "$iam_role_name"
    return 1
  fi

  if (iam_attach_role_policy -n "$iam_role_name" -p "$policy_arn"); then
    echo "Attached policy $policy_arn to role $iam_role_name"
  else
    errecho "The policy failed to attach."
    clean_up "$user_name" "$key_name" "$iam_role_name" "$policy_arn"
    return 1
  fi

  local assume_role_policy_document="{
                \"Version\": \"2012-10-17\",
                \"Statement\": [{
                    \"Effect\": \"Allow\",
                    \"Action\": \"sts:AssumeRole\",
                    \"Resource\": \"$role_arn\"}]}"

  local assume_role_policy_name
  assume_role_policy_name=$(generate_random_name "test-assume-role-")

  # shellcheck disable=SC2181
  local assume_role_policy_arn
  assume_role_policy_arn=$(iam_create_policy -n "$assume_role_policy_name" -p "$assume_role_policy_document")
  # shellcheck disable=SC2181
  if [ ${?} == 0 ]; then
    echo "Created  IAM policy named $assume_role_policy_name for sts assume role"
  else
    errecho "The policy failed to create."
    clean_up "$user_name" "$key_name" "$iam_role_name" "$policy_arn" "$policy_arn"
    return 1
  fi

  echo "Wait 10 seconds to give AWS time to propagate these new resources and connections."
  sleep 10
  echo_repeat "*" 88
  echo

  echo "Try to list buckets without the new user assuming the role."
  echo_repeat "*" 88
  echo

  # Set the environment variables for the created user.
  # bashsupport disable=BP2001
  export AWS_ACCESS_KEY_ID=$key_name
  # bashsupport disable=BP2001
  export AWS_SECRET_ACCESS_KEY=$key_secret

  local buckets
  buckets=$(s3_list_buckets)

  # shellcheck disable=SC2181
  if [ ${?} == 0 ]; then
    local bucket_count
    bucket_count=$(echo "$buckets" | wc -w | xargs)
    echo "There are $bucket_count buckets in the account. This should not have happened."
  else
    errecho "Because the role with permissions has not been assumed, listing buckets failed."
  fi

  echo
  echo_repeat "*" 88
  echo "Now assume the role $iam_role_name and list the buckets."
  echo_repeat "*" 88
  echo

  local credentials

  credentials=$(sts_assume_role -r "$role_arn" -n "AssumeRoleDemoSession")
  # shellcheck disable=SC2181
  if [ ${?} == 0 ]; then
    echo "Assumed role $iam_role_name"
  else
    errecho "Failed to assume role."
    export AWS_ACCESS_KEY_ID=""
    export AWS_SECRET_ACCESS_KEY=""
    clean_up "$user_name" "$key_name" "$iam_role_name" "$policy_arn" "$policy_arn" "$assume_role_policy_arn"
    return 1
  fi

  IFS=$'\t ' read -r -a credentials <<<"$credentials"

  export AWS_ACCESS_KEY_ID=${credentials[0]}
  export AWS_SECRET_ACCESS_KEY=${credentials[1]}
  # bashsupport disable=BP2001
  export AWS_SESSION_TOKEN=${credentials[2]}

  buckets=$(s3_list_buckets)

  # shellcheck disable=SC2181
  if [ ${?} == 0 ]; then
    local bucket_count
    bucket_count=$(echo "$buckets" | wc -w | xargs)
    echo "There are $bucket_count buckets in the account. Listing buckets succeeded because of "
    echo "the assumed role."
  else
    errecho "Failed to list buckets. This should not happen."
    export AWS_ACCESS_KEY_ID=""
    export AWS_SECRET_ACCESS_KEY=""
    export AWS_SESSION_TOKEN=""
    clean_up "$user_name" "$key_name" "$iam_role_name" "$policy_arn" "$policy_arn" "$assume_role_policy_arn"
    return 1
  fi

  local result=0
  export AWS_ACCESS_KEY_ID=""
  export AWS_SECRET_ACCESS_KEY=""

  echo
  echo_repeat "*" 88
  echo "The created resources will now be deleted."
  echo_repeat "*" 88
  echo

  clean_up "$user_name" "$key_name" "$iam_role_name" "$policy_arn" "$policy_arn" "$assume_role_policy_arn"

  # shellcheck disable=SC2181
  if [[ ${?} -ne 0 ]]; then
    result=1
  fi

  return $result
}
```
이 시나리오에 사용된 IAM 함수입니다.  

```
###############################################################################
# function iam_user_exists
#
# This function checks to see if the specified AWS Identity and Access Management (IAM) user already exists.
#
# Parameters:
#       $1 - The name of the IAM user to check.
#
# Returns:
#       0 - If the user already exists.
#       1 - If the user doesn't exist.
###############################################################################
function iam_user_exists() {
  local user_name
  user_name=$1

  # Check whether the IAM user already exists.
  # We suppress all output - we're interested only in the return code.

  local errors
  errors=$(aws iam get-user \
    --user-name "$user_name" 2>&1 >/dev/null)

  local error_code=${?}

  if [[ $error_code -eq 0 ]]; then
    return 0 # 0 in Bash script means true.
  else
    if [[ $errors != *"error"*"(NoSuchEntity)"* ]]; then
      aws_cli_error_log $error_code
      errecho "Error calling iam get-user $errors"
    fi

    return 1 # 1 in Bash script means false.
  fi
}

###############################################################################
# function iam_create_user
#
# This function creates the specified IAM user, unless
# it already exists.
#
# Parameters:
#       -u user_name  -- The name of the user to create.
#
# Returns:
#       The ARN of the user.
#     And:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_create_user() {
  local user_name response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_create_user"
    echo "Creates an AWS Identity and Access Management (IAM) user. You must supply a username:"
    echo "  -u user_name    The name of the user. It must be unique within the account."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "u:h" option; do
    case "${option}" in
      u) user_name="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$user_name" ]]; then
    errecho "ERROR: You must provide a username with the -u parameter."
    usage
    return 1
  fi

  iecho "Parameters:\n"
  iecho "    User name:   $user_name"
  iecho ""

  # If the user already exists, we don't want to try to create it.
  if (iam_user_exists "$user_name"); then
    errecho "ERROR: A user with that name already exists in the account."
    return 1
  fi

  response=$(aws iam create-user --user-name "$user_name" \
    --output text \
    --query 'User.Arn')

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports create-user operation failed.$response"
    return 1
  fi

  echo "$response"

  return 0
}

###############################################################################
# function iam_create_user_access_key
#
# This function creates an IAM access key for the specified user.
#
# Parameters:
#       -u user_name -- The name of the IAM user.
#       [-f file_name] -- The optional file name for the access key output.
#
# Returns:
#       [access_key_id access_key_secret]
#     And:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_create_user_access_key() {
  local user_name file_name response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_create_user_access_key"
    echo "Creates an AWS Identity and Access Management (IAM) key pair."
    echo "  -u user_name   The name of the IAM user."
    echo "  [-f file_name]   Optional file name for the access key output."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "u:f:h" option; do
    case "${option}" in
      u) user_name="${OPTARG}" ;;
      f) file_name="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$user_name" ]]; then
    errecho "ERROR: You must provide a username with the -u parameter."
    usage
    return 1
  fi

  response=$(aws iam create-access-key \
    --user-name "$user_name" \
    --output text)

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports create-access-key operation failed.$response"
    return 1
  fi

  if [[ -n "$file_name" ]]; then
    echo "$response" >"$file_name"
  fi

  local key_id key_secret
  # shellcheck disable=SC2086
  key_id=$(echo $response | cut -f 2 -d ' ')
  # shellcheck disable=SC2086
  key_secret=$(echo $response | cut -f 4 -d ' ')

  echo "$key_id $key_secret"

  return 0
}

###############################################################################
# function iam_create_role
#
# This function creates an IAM role.
#
# Parameters:
#       -n role_name -- The name of the IAM role.
#       -p policy_json -- The assume role policy document.
#
# Returns:
#       The ARN of the role.
#     And:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_create_role() {
  local role_name policy_document response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_create_user_access_key"
    echo "Creates an AWS Identity and Access Management (IAM) role."
    echo "  -n role_name   The name of the IAM role."
    echo "  -p policy_json -- The assume role policy document."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "n:p:h" option; do
    case "${option}" in
      n) role_name="${OPTARG}" ;;
      p) policy_document="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$role_name" ]]; then
    errecho "ERROR: You must provide a role name with the -n parameter."
    usage
    return 1
  fi

  if [[ -z "$policy_document" ]]; then
    errecho "ERROR: You must provide a policy document with the -p parameter."
    usage
    return 1
  fi

  response=$(aws iam create-role \
    --role-name "$role_name" \
    --assume-role-policy-document "$policy_document" \
    --output text \
    --query Role.Arn)

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports create-role operation failed.\n$response"
    return 1
  fi

  echo "$response"

  return 0
}

###############################################################################
# function iam_create_policy
#
# This function creates an IAM policy.
#
# Parameters:
#       -n policy_name -- The name of the IAM policy.
#       -p policy_json -- The policy document.
#
# Returns:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_create_policy() {
  local policy_name policy_document response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_create_policy"
    echo "Creates an AWS Identity and Access Management (IAM) policy."
    echo "  -n policy_name   The name of the IAM policy."
    echo "  -p policy_json -- The policy document."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "n:p:h" option; do
    case "${option}" in
      n) policy_name="${OPTARG}" ;;
      p) policy_document="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$policy_name" ]]; then
    errecho "ERROR: You must provide a policy name with the -n parameter."
    usage
    return 1
  fi

  if [[ -z "$policy_document" ]]; then
    errecho "ERROR: You must provide a policy document with the -p parameter."
    usage
    return 1
  fi

  response=$(aws iam create-policy \
    --policy-name "$policy_name" \
    --policy-document "$policy_document" \
    --output text \
    --query Policy.Arn)

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports create-policy operation failed.\n$response"
    return 1
  fi

  echo "$response"
}

###############################################################################
# function iam_attach_role_policy
#
# This function attaches an IAM policy to a tole.
#
# Parameters:
#       -n role_name -- The name of the IAM role.
#       -p policy_ARN -- The IAM policy document ARN..
#
# Returns:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_attach_role_policy() {
  local role_name policy_arn response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_attach_role_policy"
    echo "Attaches an AWS Identity and Access Management (IAM) policy to an IAM role."
    echo "  -n role_name   The name of the IAM role."
    echo "  -p policy_ARN -- The IAM policy document ARN."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "n:p:h" option; do
    case "${option}" in
      n) role_name="${OPTARG}" ;;
      p) policy_arn="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$role_name" ]]; then
    errecho "ERROR: You must provide a role name with the -n parameter."
    usage
    return 1
  fi

  if [[ -z "$policy_arn" ]]; then
    errecho "ERROR: You must provide a policy ARN with the -p parameter."
    usage
    return 1
  fi

  response=$(aws iam attach-role-policy \
    --role-name "$role_name" \
    --policy-arn "$policy_arn")

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports attach-role-policy operation failed.\n$response"
    return 1
  fi

  echo "$response"

  return 0
}

###############################################################################
# function iam_detach_role_policy
#
# This function detaches an IAM policy to a tole.
#
# Parameters:
#       -n role_name -- The name of the IAM role.
#       -p policy_ARN -- The IAM policy document ARN..
#
# Returns:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_detach_role_policy() {
  local role_name policy_arn response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_detach_role_policy"
    echo "Detaches an AWS Identity and Access Management (IAM) policy to an IAM role."
    echo "  -n role_name   The name of the IAM role."
    echo "  -p policy_ARN -- The IAM policy document ARN."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "n:p:h" option; do
    case "${option}" in
      n) role_name="${OPTARG}" ;;
      p) policy_arn="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$role_name" ]]; then
    errecho "ERROR: You must provide a role name with the -n parameter."
    usage
    return 1
  fi

  if [[ -z "$policy_arn" ]]; then
    errecho "ERROR: You must provide a policy ARN with the -p parameter."
    usage
    return 1
  fi

  response=$(aws iam detach-role-policy \
    --role-name "$role_name" \
    --policy-arn "$policy_arn")

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports detach-role-policy operation failed.\n$response"
    return 1
  fi

  echo "$response"

  return 0
}

###############################################################################
# function iam_delete_policy
#
# This function deletes an IAM policy.
#
# Parameters:
#       -n policy_arn -- The name of the IAM policy arn.
#
# Returns:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_delete_policy() {
  local policy_arn response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_delete_policy"
    echo "Deletes an AWS Identity and Access Management (IAM) policy"
    echo "  -n policy_arn -- The name of the IAM policy arn."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "n:h" option; do
    case "${option}" in
      n) policy_arn="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$policy_arn" ]]; then
    errecho "ERROR: You must provide a policy arn with the -n parameter."
    usage
    return 1
  fi

  iecho "Parameters:\n"
  iecho "    Policy arn:  $policy_arn"
  iecho ""

  response=$(aws iam delete-policy \
    --policy-arn "$policy_arn")

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports delete-policy operation failed.\n$response"
    return 1
  fi

  iecho "delete-policy response:$response"
  iecho

  return 0
}

###############################################################################
# function iam_delete_role
#
# This function deletes an IAM role.
#
# Parameters:
#       -n role_name -- The name of the IAM role.
#
# Returns:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_delete_role() {
  local role_name response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_delete_role"
    echo "Deletes an AWS Identity and Access Management (IAM) role"
    echo "  -n role_name -- The name of the IAM role."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "n:h" option; do
    case "${option}" in
      n) role_name="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  echo "role_name:$role_name"
  if [[ -z "$role_name" ]]; then
    errecho "ERROR: You must provide a role name with the -n parameter."
    usage
    return 1
  fi

  iecho "Parameters:\n"
  iecho "    Role name:  $role_name"
  iecho ""

  response=$(aws iam delete-role \
    --role-name "$role_name")

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports delete-role operation failed.\n$response"
    return 1
  fi

  iecho "delete-role response:$response"
  iecho

  return 0
}

###############################################################################
# function iam_delete_access_key
#
# This function deletes an IAM access key for the specified IAM user.
#
# Parameters:
#       -u user_name  -- The name of the user.
#       -k access_key -- The access key to delete.
#
# Returns:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_delete_access_key() {
  local user_name access_key response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_delete_access_key"
    echo "Deletes an AWS Identity and Access Management (IAM) access key for the specified IAM user"
    echo "  -u user_name    The name of the user."
    echo "  -k access_key   The access key to delete."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "u:k:h" option; do
    case "${option}" in
      u) user_name="${OPTARG}" ;;
      k) access_key="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$user_name" ]]; then
    errecho "ERROR: You must provide a username with the -u parameter."
    usage
    return 1
  fi

  if [[ -z "$access_key" ]]; then
    errecho "ERROR: You must provide an access key with the -k parameter."
    usage
    return 1
  fi

  iecho "Parameters:\n"
  iecho "    Username:   $user_name"
  iecho "    Access key:   $access_key"
  iecho ""

  response=$(aws iam delete-access-key \
    --user-name "$user_name" \
    --access-key-id "$access_key")

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports delete-access-key operation failed.\n$response"
    return 1
  fi

  iecho "delete-access-key response:$response"
  iecho

  return 0
}

###############################################################################
# function iam_delete_user
#
# This function deletes the specified IAM user.
#
# Parameters:
#       -u user_name  -- The name of the user to create.
#
# Returns:
#       0 - If successful.
#       1 - If it fails.
###############################################################################
function iam_delete_user() {
  local user_name response
  local option OPTARG # Required to use getopts command in a function.

  # bashsupport disable=BP5008
  function usage() {
    echo "function iam_delete_user"
    echo "Deletes an AWS Identity and Access Management (IAM) user. You must supply a username:"
    echo "  -u user_name    The name of the user."
    echo ""
  }

  # Retrieve the calling parameters.
  while getopts "u:h" option; do
    case "${option}" in
      u) user_name="${OPTARG}" ;;
      h)
        usage
        return 0
        ;;
      \?)
        echo "Invalid parameter"
        usage
        return 1
        ;;
    esac
  done
  export OPTIND=1

  if [[ -z "$user_name" ]]; then
    errecho "ERROR: You must provide a username with the -u parameter."
    usage
    return 1
  fi

  iecho "Parameters:\n"
  iecho "    User name:   $user_name"
  iecho ""

  # If the user does not exist, we don't want to try to delete it.
  if (! iam_user_exists "$user_name"); then
    errecho "ERROR: A user with that name does not exist in the account."
    return 1
  fi

  response=$(aws iam delete-user \
    --user-name "$user_name")

  local error_code=${?}

  if [[ $error_code -ne 0 ]]; then
    aws_cli_error_log $error_code
    errecho "ERROR: AWS reports delete-user operation failed.$response"
    return 1
  fi

  iecho "delete-user response:$response"
  iecho

  return 0
}
```
+ API 세부 정보는 **AWS CLI 명령 참조의 다음 토픽을 참조하세요.
  + [AttachRolePolicy](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/AttachRolePolicy)
  + [CreateAccessKey](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/CreateAccessKey)
  + [CreatePolicy](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/CreatePolicy)
  + [CreateRole](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/CreateRole)
  + [CreateUser](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/CreateUser)
  + [DeleteAccessKey](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/DeleteAccessKey)
  + [DeletePolicy](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/DeletePolicy)
  + [DeleteRole](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/DeleteRole)
  + [DeleteUser](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/DeleteUser)
  + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/DeleteUserPolicy)
  + [DetachRolePolicy](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/DetachRolePolicy)
  + [PutUserPolicy](https://docs.aws.amazon.com/goto/aws-cli/iam-2010-05-08/PutUserPolicy)

------
#### [ C\$1\$1 ]

**SDK for C\$1\$1**  
 GitHub에 더 많은 내용이 있습니다. [AWS 코드 예제 리포지토리](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/cpp/example_code/iam#code-examples)에서 전체 예제를 확인하고 설정 및 실행하는 방법을 알아보세요.

```
namespace AwsDoc {
    namespace IAM {
  
        //! Cleanup by deleting created entities.
        /*!
          \sa DeleteCreatedEntities
          \param client: IAM client.
          \param role: IAM role.
          \param user: IAM user.
          \param policy: IAM policy.
        */
        static bool DeleteCreatedEntities(const Aws::IAM::IAMClient &client,
                                          const Aws::IAM::Model::Role &role,
                                          const Aws::IAM::Model::User &user,
                                          const Aws::IAM::Model::Policy &policy);
    }

    static const int LIST_BUCKETS_WAIT_SEC = 20;

    static const char ALLOCATION_TAG[] = "example_code";
}

//! Scenario to create an IAM user, create an IAM role, and apply the role to the user.
// "IAM access" permissions are needed to run this code.
// "STS assume role" permissions are needed to run this code. (Note: It might be necessary to
//    create a custom policy).
/*!
  \sa iamCreateUserAssumeRoleScenario
  \param clientConfig: Aws client configuration.
  \return bool: Successful completion.
*/
bool AwsDoc::IAM::iamCreateUserAssumeRoleScenario(
        const Aws::Client::ClientConfiguration &clientConfig) {

    Aws::IAM::IAMClient client(clientConfig);
    Aws::IAM::Model::User user;
    Aws::IAM::Model::Role role;
    Aws::IAM::Model::Policy policy;

    // 1. Create a user.
    {
        Aws::IAM::Model::CreateUserRequest request;
        Aws::String uuid = Aws::Utils::UUID::RandomUUID();
        Aws::String userName = "iam-demo-user-" +
                               Aws::Utils::StringUtils::ToLower(uuid.c_str());
        request.SetUserName(userName);

        Aws::IAM::Model::CreateUserOutcome outcome = client.CreateUser(request);
        if (!outcome.IsSuccess()) {
            std::cout << "Error creating IAM user " << userName << ":" <<
                      outcome.GetError().GetMessage() << std::endl;
            return false;
        }
        else {
            std::cout << "Successfully created IAM user " << userName << std::endl;
        }

        user = outcome.GetResult().GetUser();
    }

    // 2. Create a role.
    {
        // Get the IAM user for the current client in order to access its ARN.
        Aws::String iamUserArn;
        {
            Aws::IAM::Model::GetUserRequest request;
            Aws::IAM::Model::GetUserOutcome outcome = client.GetUser(request);
            if (!outcome.IsSuccess()) {
                std::cerr << "Error getting Iam user. " <<
                          outcome.GetError().GetMessage() << std::endl;

                DeleteCreatedEntities(client, role, user, policy);
                return false;
            }
            else {
                std::cout << "Successfully retrieved Iam user "
                          << outcome.GetResult().GetUser().GetUserName()
                          << std::endl;
            }

            iamUserArn = outcome.GetResult().GetUser().GetArn();
        }

        Aws::IAM::Model::CreateRoleRequest request;

        Aws::String uuid = Aws::Utils::UUID::RandomUUID();
        Aws::String roleName = "iam-demo-role-" +
                               Aws::Utils::StringUtils::ToLower(uuid.c_str());
        request.SetRoleName(roleName);

        // Build policy document for role.
        Aws::Utils::Document jsonStatement;
        jsonStatement.WithString("Effect", "Allow");

        Aws::Utils::Document jsonPrincipal;
        jsonPrincipal.WithString("AWS", iamUserArn);
        jsonStatement.WithObject("Principal", jsonPrincipal);
        jsonStatement.WithString("Action", "sts:AssumeRole");
        jsonStatement.WithObject("Condition", Aws::Utils::Document());

        Aws::Utils::Document policyDocument;
        policyDocument.WithString("Version", "2012-10-17");

        Aws::Utils::Array<Aws::Utils::Document> statements(1);
        statements[0] = jsonStatement;
        policyDocument.WithArray("Statement", statements);

        std::cout << "Setting policy for role\n   "
                  << policyDocument.View().WriteCompact() << std::endl;

        // Set role policy document as JSON string.
        request.SetAssumeRolePolicyDocument(policyDocument.View().WriteCompact());

        Aws::IAM::Model::CreateRoleOutcome outcome = client.CreateRole(request);
        if (!outcome.IsSuccess()) {
            std::cerr << "Error creating role. " <<
                      outcome.GetError().GetMessage() << std::endl;

            DeleteCreatedEntities(client, role, user, policy);
            return false;
        }
        else {
            std::cout << "Successfully created a role with name " << roleName
                      << std::endl;
        }

        role = outcome.GetResult().GetRole();
    }

    // 3. Create an IAM policy.
    {
        Aws::IAM::Model::CreatePolicyRequest request;
        Aws::String uuid = Aws::Utils::UUID::RandomUUID();
        Aws::String policyName = "iam-demo-policy-" +
                                 Aws::Utils::StringUtils::ToLower(uuid.c_str());
        request.SetPolicyName(policyName);

        // Build IAM policy document.
        Aws::Utils::Document jsonStatement;
        jsonStatement.WithString("Effect", "Allow");
        jsonStatement.WithString("Action", "s3:ListAllMyBuckets");
        jsonStatement.WithString("Resource", "arn:aws:s3:::*");

        Aws::Utils::Document policyDocument;
        policyDocument.WithString("Version", "2012-10-17");

        Aws::Utils::Array<Aws::Utils::Document> statements(1);
        statements[0] = jsonStatement;
        policyDocument.WithArray("Statement", statements);

        std::cout << "Creating a policy.\n   " << policyDocument.View().WriteCompact()
                  << std::endl;

        // Set IAM policy document as JSON string.
        request.SetPolicyDocument(policyDocument.View().WriteCompact());

        Aws::IAM::Model::CreatePolicyOutcome outcome = client.CreatePolicy(request);
        if (!outcome.IsSuccess()) {
            std::cerr << "Error creating policy. " <<
                      outcome.GetError().GetMessage() << std::endl;

            DeleteCreatedEntities(client, role, user, policy);
            return false;
        }
        else {
            std::cout << "Successfully created a policy with name, " << policyName <<
                      "." << std::endl;
        }

        policy = outcome.GetResult().GetPolicy();
    }

    // 4. Assume the new role using the AWS Security Token Service (STS).
    Aws::STS::Model::Credentials credentials;
    {
        Aws::STS::STSClient stsClient(clientConfig);

        Aws::STS::Model::AssumeRoleRequest request;
        request.SetRoleArn(role.GetArn());
        Aws::String uuid = Aws::Utils::UUID::RandomUUID();
        Aws::String roleSessionName = "iam-demo-role-session-" +
                                      Aws::Utils::StringUtils::ToLower(uuid.c_str());
        request.SetRoleSessionName(roleSessionName);

        Aws::STS::Model::AssumeRoleOutcome assumeRoleOutcome;

        // Repeatedly call AssumeRole, because there is often a delay
        // before the role is available to be assumed.
        // Repeat at most 20 times when access is denied.
        int count = 0;
        while (true) {
            assumeRoleOutcome = stsClient.AssumeRole(request);
            if (!assumeRoleOutcome.IsSuccess()) {
                if (count > 20 ||
                    assumeRoleOutcome.GetError().GetErrorType() !=
                    Aws::STS::STSErrors::ACCESS_DENIED) {
                    std::cerr << "Error assuming role after 20 tries. " <<
                              assumeRoleOutcome.GetError().GetMessage() << std::endl;

                    DeleteCreatedEntities(client, role, user, policy);
                    return false;
                }
                std::this_thread::sleep_for(std::chrono::seconds(1));
            }
            else {
                std::cout << "Successfully assumed the role after " << count
                          << " seconds." << std::endl;
                break;
            }
            count++;
        }

        credentials = assumeRoleOutcome.GetResult().GetCredentials();
    }


    // 5. List objects in the bucket (This should fail).
    {
        Aws::S3::S3Client s3Client(
                Aws::Auth::AWSCredentials(credentials.GetAccessKeyId(),
                                          credentials.GetSecretAccessKey(),
                                          credentials.GetSessionToken()),
                Aws::MakeShared<Aws::S3::S3EndpointProvider>(ALLOCATION_TAG),
                clientConfig);
        Aws::S3::Model::ListBucketsOutcome listBucketsOutcome = s3Client.ListBuckets();
        if (!listBucketsOutcome.IsSuccess()) {
            if (listBucketsOutcome.GetError().GetErrorType() !=
                Aws::S3::S3Errors::ACCESS_DENIED) {
                std::cerr << "Could not lists buckets. " <<
                          listBucketsOutcome.GetError().GetMessage() << std::endl;
            }
            else {
                std::cout
                        << "Access to list buckets denied because privileges have not been applied."
                        << std::endl;
            }
        }
        else {
            std::cerr
                    << "Successfully retrieved bucket lists when this should not happen."
                    << std::endl;
        }
    }

    // 6. Attach the policy to the role.
    {
        Aws::IAM::Model::AttachRolePolicyRequest request;
        request.SetRoleName(role.GetRoleName());
        request.WithPolicyArn(policy.GetArn());

        Aws::IAM::Model::AttachRolePolicyOutcome outcome = client.AttachRolePolicy(
                request);
        if (!outcome.IsSuccess()) {
            std::cerr << "Error creating policy. " <<
                      outcome.GetError().GetMessage() << std::endl;

            DeleteCreatedEntities(client, role, user, policy);
            return false;
        }
        else {
            std::cout << "Successfully attached the policy with name, "
                      << policy.GetPolicyName() <<
                      ", to the role, " << role.GetRoleName() << "." << std::endl;
        }
    }

    int count = 0;
    // 7. List objects in the bucket (this should succeed).
    // Repeatedly call ListBuckets, because there is often a delay
    // before the policy with ListBucket permissions has been applied to the role.
    // Repeat at most LIST_BUCKETS_WAIT_SEC times when access is denied.
    while (true) {
        Aws::S3::S3Client s3Client(
                Aws::Auth::AWSCredentials(credentials.GetAccessKeyId(),
                                          credentials.GetSecretAccessKey(),
                                          credentials.GetSessionToken()),
                Aws::MakeShared<Aws::S3::S3EndpointProvider>(ALLOCATION_TAG),
                clientConfig);
        Aws::S3::Model::ListBucketsOutcome listBucketsOutcome = s3Client.ListBuckets();
        if (!listBucketsOutcome.IsSuccess()) {
            if ((count > LIST_BUCKETS_WAIT_SEC) ||
                listBucketsOutcome.GetError().GetErrorType() !=
                Aws::S3::S3Errors::ACCESS_DENIED) {
                std::cerr << "Could not lists buckets after " << LIST_BUCKETS_WAIT_SEC << " seconds. " <<
                          listBucketsOutcome.GetError().GetMessage() << std::endl;
                DeleteCreatedEntities(client, role, user, policy);
                return false;
            }

            std::this_thread::sleep_for(std::chrono::seconds(1));
        }
        else {

            std::cout << "Successfully retrieved bucket lists after " << count
                      << " seconds." << std::endl;
            break;
        }
        count++;
    }

    // 8. Delete all the created resources.
    return DeleteCreatedEntities(client, role, user, policy);
}

bool AwsDoc::IAM::DeleteCreatedEntities(const Aws::IAM::IAMClient &client,
                                        const Aws::IAM::Model::Role &role,
                                        const Aws::IAM::Model::User &user,
                                        const Aws::IAM::Model::Policy &policy) {
    bool result = true;
    if (policy.ArnHasBeenSet()) {
        // Detach the policy from the role.
        {
            Aws::IAM::Model::DetachRolePolicyRequest request;
            request.SetPolicyArn(policy.GetArn());
            request.SetRoleName(role.GetRoleName());

            Aws::IAM::Model::DetachRolePolicyOutcome outcome = client.DetachRolePolicy(
                    request);
            if (!outcome.IsSuccess()) {
                std::cerr << "Error Detaching policy from roles. " <<
                          outcome.GetError().GetMessage() << std::endl;
                result = false;
            }
            else {
                std::cout << "Successfully detached the policy with arn "
                          << policy.GetArn()
                          << " from role " << role.GetRoleName() << "." << std::endl;
            }
        }

        // Delete the policy.
        {
            Aws::IAM::Model::DeletePolicyRequest request;
            request.WithPolicyArn(policy.GetArn());

            Aws::IAM::Model::DeletePolicyOutcome outcome = client.DeletePolicy(request);
            if (!outcome.IsSuccess()) {
                std::cerr << "Error deleting policy. " <<
                          outcome.GetError().GetMessage() << std::endl;
                result = false;
            }
            else {
                std::cout << "Successfully deleted the policy with arn "
                          << policy.GetArn() << std::endl;
            }
        }

    }

    if (role.RoleIdHasBeenSet()) {
        // Delete the role.
        Aws::IAM::Model::DeleteRoleRequest request;
        request.SetRoleName(role.GetRoleName());

        Aws::IAM::Model::DeleteRoleOutcome outcome = client.DeleteRole(request);
        if (!outcome.IsSuccess()) {
            std::cerr << "Error deleting role. " <<
                      outcome.GetError().GetMessage() << std::endl;
            result = false;
        }
        else {
            std::cout << "Successfully deleted the role with name "
                      << role.GetRoleName() << std::endl;
        }
    }

    if (user.ArnHasBeenSet()) {
        // Delete the user.
        Aws::IAM::Model::DeleteUserRequest request;
        request.WithUserName(user.GetUserName());

        Aws::IAM::Model::DeleteUserOutcome outcome = client.DeleteUser(request);
        if (!outcome.IsSuccess()) {
            std::cerr << "Error deleting user. " <<
                      outcome.GetError().GetMessage() << std::endl;
            result = false;
        }
        else {
            std::cout << "Successfully deleted the user with name "
                      << user.GetUserName() << std::endl;
        }
    }

    return result;
}
```
+ API 세부 정보는 *AWS SDK for C\$1\$1 API 참조*의 다음 주제를 참조하세요.
  + [AttachRolePolicy](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/AttachRolePolicy)
  + [CreateAccessKey](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/CreateAccessKey)
  + [CreatePolicy](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/CreatePolicy)
  + [CreateRole](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/CreateRole)
  + [CreateUser](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/CreateUser)
  + [DeleteAccessKey](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/DeleteAccessKey)
  + [DeletePolicy](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/DeletePolicy)
  + [DeleteRole](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/DeleteRole)
  + [DeleteUser](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/DeleteUser)
  + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/DeleteUserPolicy)
  + [DetachRolePolicy](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/DetachRolePolicy)
  + [PutUserPolicy](https://docs.aws.amazon.com/goto/SdkForCpp/iam-2010-05-08/PutUserPolicy)

------
#### [ Go ]

**SDK for Go V2**  
 GitHub에 더 많은 내용이 있습니다. [AWS 코드 예제 리포지토리](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/gov2/iam#code-examples)에서 전체 예제를 확인하고 설정 및 실행하는 방법을 알아보세요.
명령 프롬프트에서 대화형 시나리오를 실행합니다.  

```
import (
	"context"
	"errors"
	"fmt"
	"log"
	"math/rand"
	"strings"
	"time"

	"github.com/aws/aws-sdk-go-v2/aws"
	"github.com/aws/aws-sdk-go-v2/config"
	"github.com/aws/aws-sdk-go-v2/credentials"
	"github.com/aws/aws-sdk-go-v2/service/iam"
	"github.com/aws/aws-sdk-go-v2/service/iam/types"
	"github.com/aws/aws-sdk-go-v2/service/s3"
	"github.com/aws/aws-sdk-go-v2/service/sts"
	"github.com/aws/smithy-go"
	"github.com/awsdocs/aws-doc-sdk-examples/gov2/demotools"
	"github.com/awsdocs/aws-doc-sdk-examples/gov2/iam/actions"
)

// AssumeRoleScenario shows you how to use the AWS Identity and Access Management (IAM)
// service to perform the following actions:
//
//  1. Create a user who has no permissions.
//  2. Create a role that grants permission to list Amazon Simple Storage Service
//     (Amazon S3) buckets for the account.
//  3. Add a policy to let the user assume the role.
//  4. Try and fail to list buckets without permissions.
//  5. Assume the role and list S3 buckets using temporary credentials.
//  6. Delete the policy, role, and user.
type AssumeRoleScenario struct {
	sdkConfig      aws.Config
	accountWrapper actions.AccountWrapper
	policyWrapper  actions.PolicyWrapper
	roleWrapper    actions.RoleWrapper
	userWrapper    actions.UserWrapper
	questioner     demotools.IQuestioner
	helper         IScenarioHelper
	isTestRun      bool
}

// NewAssumeRoleScenario constructs an AssumeRoleScenario instance from a configuration.
// It uses the specified config to get an IAM client and create wrappers for the actions
// used in the scenario.
func NewAssumeRoleScenario(sdkConfig aws.Config, questioner demotools.IQuestioner,
	helper IScenarioHelper) AssumeRoleScenario {
	iamClient := iam.NewFromConfig(sdkConfig)
	return AssumeRoleScenario{
		sdkConfig:      sdkConfig,
		accountWrapper: actions.AccountWrapper{IamClient: iamClient},
		policyWrapper:  actions.PolicyWrapper{IamClient: iamClient},
		roleWrapper:    actions.RoleWrapper{IamClient: iamClient},
		userWrapper:    actions.UserWrapper{IamClient: iamClient},
		questioner:     questioner,
		helper:         helper,
	}
}

// addTestOptions appends the API options specified in the original configuration to
// another configuration. This is used to attach the middleware stubber to clients
// that are constructed during the scenario, which is needed for unit testing.
func (scenario AssumeRoleScenario) addTestOptions(scenarioConfig *aws.Config) {
	if scenario.isTestRun {
		scenarioConfig.APIOptions = append(scenarioConfig.APIOptions, scenario.sdkConfig.APIOptions...)
	}
}

// Run runs the interactive scenario.
func (scenario AssumeRoleScenario) Run(ctx context.Context) {
	defer func() {
		if r := recover(); r != nil {
			log.Printf("Something went wrong with the demo.\n")
			log.Println(r)
		}
	}()

	log.Println(strings.Repeat("-", 88))
	log.Println("Welcome to the AWS Identity and Access Management (IAM) assume role demo.")
	log.Println(strings.Repeat("-", 88))

	user := scenario.CreateUser(ctx)
	accessKey := scenario.CreateAccessKey(ctx, user)
	role := scenario.CreateRoleAndPolicies(ctx, user)
	noPermsConfig := scenario.ListBucketsWithoutPermissions(ctx, accessKey)
	scenario.ListBucketsWithAssumedRole(ctx, noPermsConfig, role)
	scenario.Cleanup(ctx, user, role)

	log.Println(strings.Repeat("-", 88))
	log.Println("Thanks for watching!")
	log.Println(strings.Repeat("-", 88))
}

// CreateUser creates a new IAM user. This user has no permissions.
func (scenario AssumeRoleScenario) CreateUser(ctx context.Context) *types.User {
	log.Println("Let's create an example user with no permissions.")
	userName := scenario.questioner.Ask("Enter a name for the example user:", demotools.NotEmpty{})
	user, err := scenario.userWrapper.GetUser(ctx, userName)
	if err != nil {
		panic(err)
	}
	if user == nil {
		user, err = scenario.userWrapper.CreateUser(ctx, userName)
		if err != nil {
			panic(err)
		}
		log.Printf("Created user %v.\n", *user.UserName)
	} else {
		log.Printf("User %v already exists.\n", *user.UserName)
	}
	log.Println(strings.Repeat("-", 88))
	return user
}

// CreateAccessKey creates an access key for the user.
func (scenario AssumeRoleScenario) CreateAccessKey(ctx context.Context, user *types.User) *types.AccessKey {
	accessKey, err := scenario.userWrapper.CreateAccessKeyPair(ctx, *user.UserName)
	if err != nil {
		panic(err)
	}
	log.Printf("Created access key %v for your user.", *accessKey.AccessKeyId)
	log.Println("Waiting a few seconds for your user to be ready...")
	scenario.helper.Pause(10)
	log.Println(strings.Repeat("-", 88))
	return accessKey
}

// CreateRoleAndPolicies creates a policy that grants permission to list S3 buckets for
// the current account and attaches the policy to a newly created role. It also adds an
// inline policy to the specified user that grants the user permission to assume the role.
func (scenario AssumeRoleScenario) CreateRoleAndPolicies(ctx context.Context, user *types.User) *types.Role {
	log.Println("Let's create a role and policy that grant permission to list S3 buckets.")
	scenario.questioner.Ask("Press Enter when you're ready.")
	listBucketsRole, err := scenario.roleWrapper.CreateRole(ctx, scenario.helper.GetName(), *user.Arn)
	if err != nil {
		panic(err)
	}
	log.Printf("Created role %v.\n", *listBucketsRole.RoleName)
	listBucketsPolicy, err := scenario.policyWrapper.CreatePolicy(
		ctx, scenario.helper.GetName(), []string{"s3:ListAllMyBuckets"}, "arn:aws:s3:::*")
	if err != nil {
		panic(err)
	}
	log.Printf("Created policy %v.\n", *listBucketsPolicy.PolicyName)
	err = scenario.roleWrapper.AttachRolePolicy(ctx, *listBucketsPolicy.Arn, *listBucketsRole.RoleName)
	if err != nil {
		panic(err)
	}
	log.Printf("Attached policy %v to role %v.\n", *listBucketsPolicy.PolicyName,
		*listBucketsRole.RoleName)
	err = scenario.userWrapper.CreateUserPolicy(ctx, *user.UserName, scenario.helper.GetName(),
		[]string{"sts:AssumeRole"}, *listBucketsRole.Arn)
	if err != nil {
		panic(err)
	}
	log.Printf("Created an inline policy for user %v that lets the user assume the role.\n",
		*user.UserName)
	log.Println("Let's give AWS a few seconds to propagate these new resources and connections...")
	scenario.helper.Pause(10)
	log.Println(strings.Repeat("-", 88))
	return listBucketsRole
}

// ListBucketsWithoutPermissions creates an Amazon S3 client from the user's access key
// credentials and tries to list buckets for the account. Because the user does not have
// permission to perform this action, the action fails.
func (scenario AssumeRoleScenario) ListBucketsWithoutPermissions(ctx context.Context, accessKey *types.AccessKey) *aws.Config {
	log.Println("Let's try to list buckets without permissions. This should return an AccessDenied error.")
	scenario.questioner.Ask("Press Enter when you're ready.")
	noPermsConfig, err := config.LoadDefaultConfig(ctx,
		config.WithCredentialsProvider(credentials.NewStaticCredentialsProvider(
			*accessKey.AccessKeyId, *accessKey.SecretAccessKey, ""),
		))
	if err != nil {
		panic(err)
	}

	// Add test options if this is a test run. This is needed only for testing purposes.
	scenario.addTestOptions(&noPermsConfig)

	s3Client := s3.NewFromConfig(noPermsConfig)
	_, err = s3Client.ListBuckets(ctx, &s3.ListBucketsInput{})
	if err != nil {
		// The SDK for Go does not model the AccessDenied error, so check ErrorCode directly.
		var ae smithy.APIError
		if errors.As(err, &ae) {
			switch ae.ErrorCode() {
			case "AccessDenied":
				log.Println("Got AccessDenied error, which is the expected result because\n" +
					"the ListBuckets call was made without permissions.")
			default:
				log.Println("Expected AccessDenied, got something else.")
				panic(err)
			}
		}
	} else {
		log.Println("Expected AccessDenied error when calling ListBuckets without permissions,\n" +
			"but the call succeeded. Continuing the example anyway...")
	}
	log.Println(strings.Repeat("-", 88))
	return &noPermsConfig
}

// ListBucketsWithAssumedRole performs the following actions:
//
//  1. Creates an AWS Security Token Service (AWS STS) client from the config created from
//     the user's access key credentials.
//  2. Gets temporary credentials by assuming the role that grants permission to list the
//     buckets.
//  3. Creates an Amazon S3 client from the temporary credentials.
//  4. Lists buckets for the account. Because the temporary credentials are generated by
//     assuming the role that grants permission, the action succeeds.
func (scenario AssumeRoleScenario) ListBucketsWithAssumedRole(ctx context.Context, noPermsConfig *aws.Config, role *types.Role) {
	log.Println("Let's assume the role that grants permission to list buckets and try again.")
	scenario.questioner.Ask("Press Enter when you're ready.")
	stsClient := sts.NewFromConfig(*noPermsConfig)
	tempCredentials, err := stsClient.AssumeRole(ctx, &sts.AssumeRoleInput{
		RoleArn:         role.Arn,
		RoleSessionName: aws.String("AssumeRoleExampleSession"),
		DurationSeconds: aws.Int32(900),
	})
	if err != nil {
		log.Printf("Couldn't assume role %v.\n", *role.RoleName)
		panic(err)
	}
	log.Printf("Assumed role %v, got temporary credentials.\n", *role.RoleName)
	assumeRoleConfig, err := config.LoadDefaultConfig(ctx,
		config.WithCredentialsProvider(credentials.NewStaticCredentialsProvider(
			*tempCredentials.Credentials.AccessKeyId,
			*tempCredentials.Credentials.SecretAccessKey,
			*tempCredentials.Credentials.SessionToken),
		),
	)
	if err != nil {
		panic(err)
	}

	// Add test options if this is a test run. This is needed only for testing purposes.
	scenario.addTestOptions(&assumeRoleConfig)

	s3Client := s3.NewFromConfig(assumeRoleConfig)
	result, err := s3Client.ListBuckets(ctx, &s3.ListBucketsInput{})
	if err != nil {
		log.Println("Couldn't list buckets with assumed role credentials.")
		panic(err)
	}
	log.Println("Successfully called ListBuckets with assumed role credentials, \n" +
		"here are some of them:")
	for i := 0; i < len(result.Buckets) && i < 5; i++ {
		log.Printf("\t%v\n", *result.Buckets[i].Name)
	}
	log.Println(strings.Repeat("-", 88))
}

// Cleanup deletes all resources created for the scenario.
func (scenario AssumeRoleScenario) Cleanup(ctx context.Context, user *types.User, role *types.Role) {
	if scenario.questioner.AskBool(
		"Do you want to delete the resources created for this example? (y/n)", "y",
	) {
		policies, err := scenario.roleWrapper.ListAttachedRolePolicies(ctx, *role.RoleName)
		if err != nil {
			panic(err)
		}
		for _, policy := range policies {
			err = scenario.roleWrapper.DetachRolePolicy(ctx, *role.RoleName, *policy.PolicyArn)
			if err != nil {
				panic(err)
			}
			err = scenario.policyWrapper.DeletePolicy(ctx, *policy.PolicyArn)
			if err != nil {
				panic(err)
			}
			log.Printf("Detached policy %v from role %v and deleted the policy.\n",
				*policy.PolicyName, *role.RoleName)
		}
		err = scenario.roleWrapper.DeleteRole(ctx, *role.RoleName)
		if err != nil {
			panic(err)
		}
		log.Printf("Deleted role %v.\n", *role.RoleName)

		userPols, err := scenario.userWrapper.ListUserPolicies(ctx, *user.UserName)
		if err != nil {
			panic(err)
		}
		for _, userPol := range userPols {
			err = scenario.userWrapper.DeleteUserPolicy(ctx, *user.UserName, userPol)
			if err != nil {
				panic(err)
			}
			log.Printf("Deleted policy %v from user %v.\n", userPol, *user.UserName)
		}
		keys, err := scenario.userWrapper.ListAccessKeys(ctx, *user.UserName)
		if err != nil {
			panic(err)
		}
		for _, key := range keys {
			err = scenario.userWrapper.DeleteAccessKey(ctx, *user.UserName, *key.AccessKeyId)
			if err != nil {
				panic(err)
			}
			log.Printf("Deleted access key %v from user %v.\n", *key.AccessKeyId, *user.UserName)
		}
		err = scenario.userWrapper.DeleteUser(ctx, *user.UserName)
		if err != nil {
			panic(err)
		}
		log.Printf("Deleted user %v.\n", *user.UserName)
		log.Println(strings.Repeat("-", 88))
	}

}

// IScenarioHelper abstracts input and wait functions from a scenario so that they
// can be mocked for unit testing.
type IScenarioHelper interface {
	GetName() string
	Pause(secs int)
}

const rMax = 100000

type ScenarioHelper struct {
	Prefix string
	Random *rand.Rand
}

// GetName returns a unique name formed of a prefix and a random number.
func (helper *ScenarioHelper) GetName() string {
	return fmt.Sprintf("%v%v", helper.Prefix, helper.Random.Intn(rMax))
}

// Pause waits for the specified number of seconds.
func (helper ScenarioHelper) Pause(secs int) {
	time.Sleep(time.Duration(secs) * time.Second)
}
```
계정 작업을 래핑하는 구조체를 정의합니다.  

```
import (
	"context"
	"log"

	"github.com/aws/aws-sdk-go-v2/service/iam"
	"github.com/aws/aws-sdk-go-v2/service/iam/types"
)

// AccountWrapper encapsulates AWS Identity and Access Management (IAM) account actions
// used in the examples.
// It contains an IAM service client that is used to perform account actions.
type AccountWrapper struct {
	IamClient *iam.Client
}



// GetAccountPasswordPolicy gets the account password policy for the current account.
// If no policy has been set, a NoSuchEntityException is error is returned.
func (wrapper AccountWrapper) GetAccountPasswordPolicy(ctx context.Context) (*types.PasswordPolicy, error) {
	var pwPolicy *types.PasswordPolicy
	result, err := wrapper.IamClient.GetAccountPasswordPolicy(ctx,
		&iam.GetAccountPasswordPolicyInput{})
	if err != nil {
		log.Printf("Couldn't get account password policy. Here's why: %v\n", err)
	} else {
		pwPolicy = result.PasswordPolicy
	}
	return pwPolicy, err
}



// ListSAMLProviders gets the SAML providers for the account.
func (wrapper AccountWrapper) ListSAMLProviders(ctx context.Context) ([]types.SAMLProviderListEntry, error) {
	var providers []types.SAMLProviderListEntry
	result, err := wrapper.IamClient.ListSAMLProviders(ctx, &iam.ListSAMLProvidersInput{})
	if err != nil {
		log.Printf("Couldn't list SAML providers. Here's why: %v\n", err)
	} else {
		providers = result.SAMLProviderList
	}
	return providers, err
}
```
정책 작업을 래핑하는 구조체를 정의합니다.  

```
import (
	"context"
	"encoding/json"
	"log"

	"github.com/aws/aws-sdk-go-v2/aws"
	"github.com/aws/aws-sdk-go-v2/service/iam"
	"github.com/aws/aws-sdk-go-v2/service/iam/types"
)

// PolicyWrapper encapsulates AWS Identity and Access Management (IAM) policy actions
// used in the examples.
// It contains an IAM service client that is used to perform policy actions.
type PolicyWrapper struct {
	IamClient *iam.Client
}



// ListPolicies gets up to maxPolicies policies.
func (wrapper PolicyWrapper) ListPolicies(ctx context.Context, maxPolicies int32) ([]types.Policy, error) {
	var policies []types.Policy
	result, err := wrapper.IamClient.ListPolicies(ctx, &iam.ListPoliciesInput{
		MaxItems: aws.Int32(maxPolicies),
	})
	if err != nil {
		log.Printf("Couldn't list policies. Here's why: %v\n", err)
	} else {
		policies = result.Policies
	}
	return policies, err
}



// PolicyDocument defines a policy document as a Go struct that can be serialized
// to JSON.
type PolicyDocument struct {
	Version   string
	Statement []PolicyStatement
}

// PolicyStatement defines a statement in a policy document.
type PolicyStatement struct {
	Effect    string
	Action    []string
	Principal map[string]string `json:",omitempty"`
	Resource  *string           `json:",omitempty"`
}

// CreatePolicy creates a policy that grants a list of actions to the specified resource.
// PolicyDocument shows how to work with a policy document as a data structure and
// serialize it to JSON by using Go's JSON marshaler.
func (wrapper PolicyWrapper) CreatePolicy(ctx context.Context, policyName string, actions []string,
	resourceArn string) (*types.Policy, error) {
	var policy *types.Policy
	policyDoc := PolicyDocument{
		Version: "2012-10-17",
		Statement: []PolicyStatement{{
			Effect:   "Allow",
			Action:   actions,
			Resource: aws.String(resourceArn),
		}},
	}
	policyBytes, err := json.Marshal(policyDoc)
	if err != nil {
		log.Printf("Couldn't create policy document for %v. Here's why: %v\n", resourceArn, err)
		return nil, err
	}
	result, err := wrapper.IamClient.CreatePolicy(ctx, &iam.CreatePolicyInput{
		PolicyDocument: aws.String(string(policyBytes)),
		PolicyName:     aws.String(policyName),
	})
	if err != nil {
		log.Printf("Couldn't create policy %v. Here's why: %v\n", policyName, err)
	} else {
		policy = result.Policy
	}
	return policy, err
}



// GetPolicy gets data about a policy.
func (wrapper PolicyWrapper) GetPolicy(ctx context.Context, policyArn string) (*types.Policy, error) {
	var policy *types.Policy
	result, err := wrapper.IamClient.GetPolicy(ctx, &iam.GetPolicyInput{
		PolicyArn: aws.String(policyArn),
	})
	if err != nil {
		log.Printf("Couldn't get policy %v. Here's why: %v\n", policyArn, err)
	} else {
		policy = result.Policy
	}
	return policy, err
}



// DeletePolicy deletes a policy.
func (wrapper PolicyWrapper) DeletePolicy(ctx context.Context, policyArn string) error {
	_, err := wrapper.IamClient.DeletePolicy(ctx, &iam.DeletePolicyInput{
		PolicyArn: aws.String(policyArn),
	})
	if err != nil {
		log.Printf("Couldn't delete policy %v. Here's why: %v\n", policyArn, err)
	}
	return err
}
```
역할 작업을 래핑하는 구조체를 정의합니다.  

```
import (
	"context"
	"encoding/json"
	"log"

	"github.com/aws/aws-sdk-go-v2/aws"
	"github.com/aws/aws-sdk-go-v2/service/iam"
	"github.com/aws/aws-sdk-go-v2/service/iam/types"
)

// RoleWrapper encapsulates AWS Identity and Access Management (IAM) role actions
// used in the examples.
// It contains an IAM service client that is used to perform role actions.
type RoleWrapper struct {
	IamClient *iam.Client
}



// ListRoles gets up to maxRoles roles.
func (wrapper RoleWrapper) ListRoles(ctx context.Context, maxRoles int32) ([]types.Role, error) {
	var roles []types.Role
	result, err := wrapper.IamClient.ListRoles(ctx,
		&iam.ListRolesInput{MaxItems: aws.Int32(maxRoles)},
	)
	if err != nil {
		log.Printf("Couldn't list roles. Here's why: %v\n", err)
	} else {
		roles = result.Roles
	}
	return roles, err
}



// CreateRole creates a role that trusts a specified user. The trusted user can assume
// the role to acquire its permissions.
// PolicyDocument shows how to work with a policy document as a data structure and
// serialize it to JSON by using Go's JSON marshaler.
func (wrapper RoleWrapper) CreateRole(ctx context.Context, roleName string, trustedUserArn string) (*types.Role, error) {
	var role *types.Role
	trustPolicy := PolicyDocument{
		Version: "2012-10-17",
		Statement: []PolicyStatement{{
			Effect:    "Allow",
			Principal: map[string]string{"AWS": trustedUserArn},
			Action:    []string{"sts:AssumeRole"},
		}},
	}
	policyBytes, err := json.Marshal(trustPolicy)
	if err != nil {
		log.Printf("Couldn't create trust policy for %v. Here's why: %v\n", trustedUserArn, err)
		return nil, err
	}
	result, err := wrapper.IamClient.CreateRole(ctx, &iam.CreateRoleInput{
		AssumeRolePolicyDocument: aws.String(string(policyBytes)),
		RoleName:                 aws.String(roleName),
	})
	if err != nil {
		log.Printf("Couldn't create role %v. Here's why: %v\n", roleName, err)
	} else {
		role = result.Role
	}
	return role, err
}



// GetRole gets data about a role.
func (wrapper RoleWrapper) GetRole(ctx context.Context, roleName string) (*types.Role, error) {
	var role *types.Role
	result, err := wrapper.IamClient.GetRole(ctx,
		&iam.GetRoleInput{RoleName: aws.String(roleName)})
	if err != nil {
		log.Printf("Couldn't get role %v. Here's why: %v\n", roleName, err)
	} else {
		role = result.Role
	}
	return role, err
}



// CreateServiceLinkedRole creates a service-linked role that is owned by the specified service.
func (wrapper RoleWrapper) CreateServiceLinkedRole(ctx context.Context, serviceName string, description string) (
	*types.Role, error) {
	var role *types.Role
	result, err := wrapper.IamClient.CreateServiceLinkedRole(ctx, &iam.CreateServiceLinkedRoleInput{
		AWSServiceName: aws.String(serviceName),
		Description:    aws.String(description),
	})
	if err != nil {
		log.Printf("Couldn't create service-linked role %v. Here's why: %v\n", serviceName, err)
	} else {
		role = result.Role
	}
	return role, err
}



// DeleteServiceLinkedRole deletes a service-linked role.
func (wrapper RoleWrapper) DeleteServiceLinkedRole(ctx context.Context, roleName string) error {
	_, err := wrapper.IamClient.DeleteServiceLinkedRole(ctx, &iam.DeleteServiceLinkedRoleInput{
		RoleName: aws.String(roleName)},
	)
	if err != nil {
		log.Printf("Couldn't delete service-linked role %v. Here's why: %v\n", roleName, err)
	}
	return err
}



// AttachRolePolicy attaches a policy to a role.
func (wrapper RoleWrapper) AttachRolePolicy(ctx context.Context, policyArn string, roleName string) error {
	_, err := wrapper.IamClient.AttachRolePolicy(ctx, &iam.AttachRolePolicyInput{
		PolicyArn: aws.String(policyArn),
		RoleName:  aws.String(roleName),
	})
	if err != nil {
		log.Printf("Couldn't attach policy %v to role %v. Here's why: %v\n", policyArn, roleName, err)
	}
	return err
}



// ListAttachedRolePolicies lists the policies that are attached to the specified role.
func (wrapper RoleWrapper) ListAttachedRolePolicies(ctx context.Context, roleName string) ([]types.AttachedPolicy, error) {
	var policies []types.AttachedPolicy
	result, err := wrapper.IamClient.ListAttachedRolePolicies(ctx, &iam.ListAttachedRolePoliciesInput{
		RoleName: aws.String(roleName),
	})
	if err != nil {
		log.Printf("Couldn't list attached policies for role %v. Here's why: %v\n", roleName, err)
	} else {
		policies = result.AttachedPolicies
	}
	return policies, err
}



// DetachRolePolicy detaches a policy from a role.
func (wrapper RoleWrapper) DetachRolePolicy(ctx context.Context, roleName string, policyArn string) error {
	_, err := wrapper.IamClient.DetachRolePolicy(ctx, &iam.DetachRolePolicyInput{
		PolicyArn: aws.String(policyArn),
		RoleName:  aws.String(roleName),
	})
	if err != nil {
		log.Printf("Couldn't detach policy from role %v. Here's why: %v\n", roleName, err)
	}
	return err
}



// ListRolePolicies lists the inline policies for a role.
func (wrapper RoleWrapper) ListRolePolicies(ctx context.Context, roleName string) ([]string, error) {
	var policies []string
	result, err := wrapper.IamClient.ListRolePolicies(ctx, &iam.ListRolePoliciesInput{
		RoleName: aws.String(roleName),
	})
	if err != nil {
		log.Printf("Couldn't list policies for role %v. Here's why: %v\n", roleName, err)
	} else {
		policies = result.PolicyNames
	}
	return policies, err
}



// DeleteRole deletes a role. All attached policies must be detached before a
// role can be deleted.
func (wrapper RoleWrapper) DeleteRole(ctx context.Context, roleName string) error {
	_, err := wrapper.IamClient.DeleteRole(ctx, &iam.DeleteRoleInput{
		RoleName: aws.String(roleName),
	})
	if err != nil {
		log.Printf("Couldn't delete role %v. Here's why: %v\n", roleName, err)
	}
	return err
}
```
사용자 작업을 래핑하는 구조체를 정의합니다.  

```
import (
	"context"
	"encoding/json"
	"errors"
	"log"

	"github.com/aws/aws-sdk-go-v2/aws"
	"github.com/aws/aws-sdk-go-v2/service/iam"
	"github.com/aws/aws-sdk-go-v2/service/iam/types"
	"github.com/aws/smithy-go"
)

// UserWrapper encapsulates user actions used in the examples.
// It contains an IAM service client that is used to perform user actions.
type UserWrapper struct {
	IamClient *iam.Client
}



// ListUsers gets up to maxUsers number of users.
func (wrapper UserWrapper) ListUsers(ctx context.Context, maxUsers int32) ([]types.User, error) {
	var users []types.User
	result, err := wrapper.IamClient.ListUsers(ctx, &iam.ListUsersInput{
		MaxItems: aws.Int32(maxUsers),
	})
	if err != nil {
		log.Printf("Couldn't list users. Here's why: %v\n", err)
	} else {
		users = result.Users
	}
	return users, err
}



// GetUser gets data about a user.
func (wrapper UserWrapper) GetUser(ctx context.Context, userName string) (*types.User, error) {
	var user *types.User
	result, err := wrapper.IamClient.GetUser(ctx, &iam.GetUserInput{
		UserName: aws.String(userName),
	})
	if err != nil {
		var apiError smithy.APIError
		if errors.As(err, &apiError) {
			switch apiError.(type) {
			case *types.NoSuchEntityException:
				log.Printf("User %v does not exist.\n", userName)
				err = nil
			default:
				log.Printf("Couldn't get user %v. Here's why: %v\n", userName, err)
			}
		}
	} else {
		user = result.User
	}
	return user, err
}



// CreateUser creates a new user with the specified name.
func (wrapper UserWrapper) CreateUser(ctx context.Context, userName string) (*types.User, error) {
	var user *types.User
	result, err := wrapper.IamClient.CreateUser(ctx, &iam.CreateUserInput{
		UserName: aws.String(userName),
	})
	if err != nil {
		log.Printf("Couldn't create user %v. Here's why: %v\n", userName, err)
	} else {
		user = result.User
	}
	return user, err
}



// CreateUserPolicy adds an inline policy to a user. This example creates a policy that
// grants a list of actions on a specified role.
// PolicyDocument shows how to work with a policy document as a data structure and
// serialize it to JSON by using Go's JSON marshaler.
func (wrapper UserWrapper) CreateUserPolicy(ctx context.Context, userName string, policyName string, actions []string,
	roleArn string) error {
	policyDoc := PolicyDocument{
		Version: "2012-10-17",
		Statement: []PolicyStatement{{
			Effect:   "Allow",
			Action:   actions,
			Resource: aws.String(roleArn),
		}},
	}
	policyBytes, err := json.Marshal(policyDoc)
	if err != nil {
		log.Printf("Couldn't create policy document for %v. Here's why: %v\n", roleArn, err)
		return err
	}
	_, err = wrapper.IamClient.PutUserPolicy(ctx, &iam.PutUserPolicyInput{
		PolicyDocument: aws.String(string(policyBytes)),
		PolicyName:     aws.String(policyName),
		UserName:       aws.String(userName),
	})
	if err != nil {
		log.Printf("Couldn't create policy for user %v. Here's why: %v\n", userName, err)
	}
	return err
}



// ListUserPolicies lists the inline policies for the specified user.
func (wrapper UserWrapper) ListUserPolicies(ctx context.Context, userName string) ([]string, error) {
	var policies []string
	result, err := wrapper.IamClient.ListUserPolicies(ctx, &iam.ListUserPoliciesInput{
		UserName: aws.String(userName),
	})
	if err != nil {
		log.Printf("Couldn't list policies for user %v. Here's why: %v\n", userName, err)
	} else {
		policies = result.PolicyNames
	}
	return policies, err
}



// DeleteUserPolicy deletes an inline policy from a user.
func (wrapper UserWrapper) DeleteUserPolicy(ctx context.Context, userName string, policyName string) error {
	_, err := wrapper.IamClient.DeleteUserPolicy(ctx, &iam.DeleteUserPolicyInput{
		PolicyName: aws.String(policyName),
		UserName:   aws.String(userName),
	})
	if err != nil {
		log.Printf("Couldn't delete policy from user %v. Here's why: %v\n", userName, err)
	}
	return err
}



// DeleteUser deletes a user.
func (wrapper UserWrapper) DeleteUser(ctx context.Context, userName string) error {
	_, err := wrapper.IamClient.DeleteUser(ctx, &iam.DeleteUserInput{
		UserName: aws.String(userName),
	})
	if err != nil {
		log.Printf("Couldn't delete user %v. Here's why: %v\n", userName, err)
	}
	return err
}



// CreateAccessKeyPair creates an access key for a user. The returned access key contains
// the ID and secret credentials needed to use the key.
func (wrapper UserWrapper) CreateAccessKeyPair(ctx context.Context, userName string) (*types.AccessKey, error) {
	var key *types.AccessKey
	result, err := wrapper.IamClient.CreateAccessKey(ctx, &iam.CreateAccessKeyInput{
		UserName: aws.String(userName)})
	if err != nil {
		log.Printf("Couldn't create access key pair for user %v. Here's why: %v\n", userName, err)
	} else {
		key = result.AccessKey
	}
	return key, err
}



// DeleteAccessKey deletes an access key from a user.
func (wrapper UserWrapper) DeleteAccessKey(ctx context.Context, userName string, keyId string) error {
	_, err := wrapper.IamClient.DeleteAccessKey(ctx, &iam.DeleteAccessKeyInput{
		AccessKeyId: aws.String(keyId),
		UserName:    aws.String(userName),
	})
	if err != nil {
		log.Printf("Couldn't delete access key %v. Here's why: %v\n", keyId, err)
	}
	return err
}



// ListAccessKeys lists the access keys for the specified user.
func (wrapper UserWrapper) ListAccessKeys(ctx context.Context, userName string) ([]types.AccessKeyMetadata, error) {
	var keys []types.AccessKeyMetadata
	result, err := wrapper.IamClient.ListAccessKeys(ctx, &iam.ListAccessKeysInput{
		UserName: aws.String(userName),
	})
	if err != nil {
		log.Printf("Couldn't list access keys for user %v. Here's why: %v\n", userName, err)
	} else {
		keys = result.AccessKeyMetadata
	}
	return keys, err
}
```
+ API 세부 정보는 *AWS SDK for Go API 참조*의 다음 주제를 참조하세요.
  + [AttachRolePolicy](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.AttachRolePolicy)
  + [CreateAccessKey](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.CreateAccessKey)
  + [CreatePolicy](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.CreatePolicy)
  + [CreateRole](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.CreateRole)
  + [CreateUser](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.CreateUser)
  + [DeleteAccessKey](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.DeleteAccessKey)
  + [DeletePolicy](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.DeletePolicy)
  + [DeleteRole](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.DeleteRole)
  + [DeleteUser](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.DeleteUser)
  + [DeleteUserPolicy](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.DeleteUserPolicy)
  + [DetachRolePolicy](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.DetachRolePolicy)
  + [PutUserPolicy](https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/iam#Client.PutUserPolicy)

------
#### [ Java ]

**SDK for Java 2.x**  
 GitHub에 더 많은 내용이 있습니다. [AWS 코드 예제 리포지토리](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javav2/example_code/iam#code-examples)에서 전체 예제를 확인하고 설정 및 실행하는 방법을 알아보세요.
IAM 사용자 작업을 래핑하는 함수를 생성합니다.  

```
/*
  To run this Java V2 code example, set up your development environment, including your credentials.

  For information, see this documentation topic:

  https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/get-started.html

  This example performs these operations:

  1. Creates a user that has no permissions.
  2. Creates a role and policy that grants Amazon S3 permissions.
  3. Creates a role.
  4. Grants the user permissions.
  5. Gets temporary credentials by assuming the role.  Creates an Amazon S3 Service client object with the temporary credentials.
  6. Deletes the resources.
 */

public class IAMScenario {
    public static final String DASHES = new String(new char[80]).replace("\0", "-");
    public static final String PolicyDocument = "{" +
            "  \"Version\": \"2012-10-17\"," +
            "  \"Statement\": [" +
            "    {" +
            "        \"Effect\": \"Allow\"," +
            "        \"Action\": [" +
            "            \"s3:*\"" +
            "       ]," +
            "       \"Resource\": \"*\"" +
            "    }" +
            "   ]" +
            "}";

    public static String userArn;

    public static void main(String[] args) throws Exception {

        final String usage = """

                Usage:
                    <username> <policyName> <roleName> <roleSessionName> <bucketName>\s

                Where:
                    username - The name of the IAM user to create.\s
                    policyName - The name of the policy to create.\s
                    roleName - The name of the role to create.\s
                    roleSessionName - The name of the session required for the assumeRole operation.\s
                    bucketName - The name of the Amazon S3 bucket from which objects are read.\s
                """;

        if (args.length != 5) {
            System.out.println(usage);
            System.exit(1);
        }

        String userName = args[0];
        String policyName = args[1];
        String roleName = args[2];
        String roleSessionName = args[3];
        String bucketName = args[4];

        Region region = Region.AWS_GLOBAL;
        IamClient iam = IamClient.builder()
                .region(region)
                .build();

        System.out.println(DASHES);
        System.out.println("Welcome to the AWS IAM example scenario.");
        System.out.println(DASHES);

        System.out.println(DASHES);
        System.out.println(" 1. Create the IAM user.");
        User createUser = createIAMUser(iam, userName);

        System.out.println(DASHES);
        userArn = createUser.arn();

        AccessKey myKey = createIAMAccessKey(iam, userName);
        String accessKey = myKey.accessKeyId();
        String secretKey = myKey.secretAccessKey();
        String assumeRolePolicyDocument = "{" +
                "\"Version\": \"2012-10-17\"," +
                "\"Statement\": [{" +
                "\"Effect\": \"Allow\"," +
                "\"Principal\": {" +
                "	\"AWS\": \"" + userArn + "\"" +
                "}," +
                "\"Action\": \"sts:AssumeRole\"" +
                "}]" +
                "}";

        System.out.println(assumeRolePolicyDocument);
        System.out.println(userName + " was successfully created.");
        System.out.println(DASHES);
        System.out.println("2. Creates a policy.");
        String polArn = createIAMPolicy(iam, policyName);
        System.out.println("The policy " + polArn + " was successfully created.");
        System.out.println(DASHES);

        System.out.println(DASHES);
        System.out.println("3. Creates a role.");
        TimeUnit.SECONDS.sleep(30);
        String roleArn = createIAMRole(iam, roleName, assumeRolePolicyDocument);
        System.out.println(roleArn + " was successfully created.");
        System.out.println(DASHES);

        System.out.println(DASHES);
        System.out.println("4. Grants the user permissions.");
        attachIAMRolePolicy(iam, roleName, polArn);
        System.out.println(DASHES);

        System.out.println(DASHES);
        System.out.println("*** Wait for 30 secs so the resource is available");
        TimeUnit.SECONDS.sleep(30);
        System.out.println("5. Gets temporary credentials by assuming the role.");
        System.out.println("Perform an Amazon S3 Service operation using the temporary credentials.");
        assumeRole(roleArn, roleSessionName, bucketName, accessKey, secretKey);
        System.out.println(DASHES);

        System.out.println(DASHES);
        System.out.println("6 Getting ready to delete the AWS resources");
        deleteKey(iam, userName, accessKey);
        deleteRole(iam, roleName, polArn);
        deleteIAMUser(iam, userName);
        System.out.println(DASHES);

        System.out.println(DASHES);
        System.out.println("This IAM Scenario has successfully completed");
        System.out.println(DASHES);
    }

    public static AccessKey createIAMAccessKey(IamClient iam, String user) {
        try {
            CreateAccessKeyRequest request = CreateAccessKeyRequest.builder()
                    .userName(user)
                    .build();

            CreateAccessKeyResponse response = iam.createAccessKey(request);
            return response.accessKey();

        } catch (IamException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
            System.exit(1);
        }
        return null;
    }

    public static User createIAMUser(IamClient iam, String username) {
        try {
            // Create an IamWaiter object
            IamWaiter iamWaiter = iam.waiter();
            CreateUserRequest request = CreateUserRequest.builder()
                    .userName(username)
                    .build();

            // Wait until the user is created.
            CreateUserResponse response = iam.createUser(request);
            GetUserRequest userRequest = GetUserRequest.builder()
                    .userName(response.user().userName())
                    .build();

            WaiterResponse<GetUserResponse> waitUntilUserExists = iamWaiter.waitUntilUserExists(userRequest);
            waitUntilUserExists.matched().response().ifPresent(System.out::println);
            return response.user();

        } catch (IamException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
            System.exit(1);
        }
        return null;
    }

    public static String createIAMRole(IamClient iam, String rolename, String json) {

        try {
            CreateRoleRequest request = CreateRoleRequest.builder()
                    .roleName(rolename)
                    .assumeRolePolicyDocument(json)
                    .description("Created using the AWS SDK for Java")
                    .build();

            CreateRoleResponse response = iam.createRole(request);
            System.out.println("The ARN of the role is " + response.role().arn());
            return response.role().arn();

        } catch (IamException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
            System.exit(1);
        }
        return "";
    }

    public static String createIAMPolicy(IamClient iam, String policyName) {
        try {
            // Create an IamWaiter object.
            IamWaiter iamWaiter = iam.waiter();
            CreatePolicyRequest request = CreatePolicyRequest.builder()
                    .policyName(policyName)
                    .policyDocument(PolicyDocument).build();

            CreatePolicyResponse response = iam.createPolicy(request);
            GetPolicyRequest polRequest = GetPolicyRequest.builder()
                    .policyArn(response.policy().arn())
                    .build();

            WaiterResponse<GetPolicyResponse> waitUntilPolicyExists = iamWaiter.waitUntilPolicyExists(polRequest);
            waitUntilPolicyExists.matched().response().ifPresent(System.out::println);
            return response.policy().arn();

        } catch (IamException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
            System.exit(1);
        }
        return "";
    }

    public static void attachIAMRolePolicy(IamClient iam, String roleName, String policyArn) {
        try {
            ListAttachedRolePoliciesRequest request = ListAttachedRolePoliciesRequest.builder()
                    .roleName(roleName)
                    .build();

            ListAttachedRolePoliciesResponse response = iam.listAttachedRolePolicies(request);
            List<AttachedPolicy> attachedPolicies = response.attachedPolicies();
            String polArn;
            for (AttachedPolicy policy : attachedPolicies) {
                polArn = policy.policyArn();
                if (polArn.compareTo(policyArn) == 0) {
                    System.out.println(roleName + " policy is already attached to this role.");
                    return;
                }
            }

            AttachRolePolicyRequest attachRequest = AttachRolePolicyRequest.builder()
                    .roleName(roleName)
                    .policyArn(policyArn)
                    .build();

            iam.attachRolePolicy(attachRequest);
            System.out.println("Successfully attached policy " + policyArn + " to role " + roleName);

        } catch (IamException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
            System.exit(1);
        }
    }

    // Invoke an Amazon S3 operation using the Assumed Role.
    public static void assumeRole(String roleArn, String roleSessionName, String bucketName, String keyVal,
            String keySecret) {

        // Use the creds of the new IAM user that was created in this code example.
        AwsBasicCredentials credentials = AwsBasicCredentials.create(keyVal, keySecret);
        StsClient stsClient = StsClient.builder()
                .region(Region.US_EAST_1)
                .credentialsProvider(StaticCredentialsProvider.create(credentials))
                .build();

        try {
            AssumeRoleRequest roleRequest = AssumeRoleRequest.builder()
                    .roleArn(roleArn)
                    .roleSessionName(roleSessionName)
                    .build();

            AssumeRoleResponse roleResponse = stsClient.assumeRole(roleRequest);
            Credentials myCreds = roleResponse.credentials();
            String key = myCreds.accessKeyId();
            String secKey = myCreds.secretAccessKey();
            String secToken = myCreds.sessionToken();

            // List all objects in an Amazon S3 bucket using the temp creds retrieved by
            // invoking assumeRole.
            Region region = Region.US_EAST_1;
            S3Client s3 = S3Client.builder()
                    .credentialsProvider(
                            StaticCredentialsProvider.create(AwsSessionCredentials.create(key, secKey, secToken)))
                    .region(region)
                    .build();

            System.out.println("Created a S3Client using temp credentials.");
            System.out.println("Listing objects in " + bucketName);
            ListObjectsRequest listObjects = ListObjectsRequest.builder()
                    .bucket(bucketName)
                    .build();

            ListObjectsResponse res = s3.listObjects(listObjects);
            List<S3Object> objects = res.contents();
            for (S3Object myValue : objects) {
                System.out.println("The name of the key is " + myValue.key());
                System.out.println("The owner is " + myValue.owner());
            }

        } catch (StsException e) {
            System.err.println(e.getMessage());
            System.exit(1);
        }
    }

    public static void deleteRole(IamClient iam, String roleName, String polArn) {

        try {
            // First the policy needs to be detached.
            DetachRolePolicyRequest rolePolicyRequest = DetachRolePolicyRequest.builder()
                    .policyArn(polArn)
                    .roleName(roleName)
                    .build();

            iam.detachRolePolicy(rolePolicyRequest);

            // Delete the policy.
            DeletePolicyRequest request = DeletePolicyRequest.builder()
                    .policyArn(polArn)
                    .build();

            iam.deletePolicy(request);
            System.out.println("*** Successfully deleted " + polArn);

            // Delete the role.
            DeleteRoleRequest roleRequest = DeleteRoleRequest.builder()
                    .roleName(roleName)
                    .build();

            iam.deleteRole(roleRequest);
            System.out.println("*** Successfully deleted " + roleName);

        } catch (IamException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
            System.exit(1);
        }
    }

    public static void deleteKey(IamClient iam, String username, String accessKey) {
        try {
            DeleteAccessKeyRequest request = DeleteAccessKeyRequest.builder()
                    .accessKeyId(accessKey)
                    .userName(username)
                    .build();

            iam.deleteAccessKey(request);
            System.out.println("Successfully deleted access key " + accessKey +
                    " from user " + username);

        } catch (IamException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
            System.exit(1);
        }
    }

    public static void deleteIAMUser(IamClient iam, String userName) {
        try {
            DeleteUserRequest request = DeleteUserRequest.builder()
                    .userName(userName)
                    .build();

            iam.deleteUser(request);
            System.out.println("*** Successfully deleted " + userName);

        } catch (IamException e) {
            System.err.println(e.awsErrorDetails().errorMessage());
            System.exit(1);
        }
    }
}
```
+ API 세부 정보는 *AWS SDK for Java 2.x API 참조*의 다음 주제를 참조하세요.
  + [AttachRolePolicy](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/AttachRolePolicy)
  + [CreateAccessKey](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/CreateAccessKey)
  + [CreatePolicy](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/CreatePolicy)
  + [CreateRole](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/CreateRole)
  + [CreateUser](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/CreateUser)
  + [DeleteAccessKey](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/DeleteAccessKey)
  + [DeletePolicy](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/DeletePolicy)
  + [DeleteRole](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/DeleteRole)
  + [DeleteUser](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/DeleteUser)
  + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/DeleteUserPolicy)
  + [DetachRolePolicy](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/DetachRolePolicy)
  + [PutUserPolicy](https://docs.aws.amazon.com/goto/SdkForJavaV2/iam-2010-05-08/PutUserPolicy)

------
#### [ JavaScript ]

**SDK for JavaScript (v3)**  
 GitHub에 더 많은 내용이 있습니다. [AWS 코드 예제 리포지토리](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javascriptv3/example_code/iam#code-examples)에서 전체 예제를 확인하고 설정 및 실행하는 방법을 알아보세요.
Amazon S3 버킷을 나열할 수 있는 권한을 부여하는 역할과 IAM 사용자를 생성합니다. 사용자는 역할을 수임할 수 있는 권한만 있습니다. 역할을 수임한 후 임시 자격 증명을 사용하여 계정의 버킷을 나열합니다.  

```
import {
  CreateUserCommand,
  GetUserCommand,
  CreateAccessKeyCommand,
  CreatePolicyCommand,
  CreateRoleCommand,
  AttachRolePolicyCommand,
  DeleteAccessKeyCommand,
  DeleteUserCommand,
  DeleteRoleCommand,
  DeletePolicyCommand,
  DetachRolePolicyCommand,
  IAMClient,
} from "@aws-sdk/client-iam";
import { ListBucketsCommand, S3Client } from "@aws-sdk/client-s3";
import { AssumeRoleCommand, STSClient } from "@aws-sdk/client-sts";
import { retry } from "@aws-doc-sdk-examples/lib/utils/util-timers.js";
import { ScenarioInput } from "@aws-doc-sdk-examples/lib/scenario/index.js";

// Set the parameters.
const iamClient = new IAMClient({});
const userName = "iam_basic_test_username";
const policyName = "iam_basic_test_policy";
const roleName = "iam_basic_test_role";

/**
 * Create a new IAM user. If the user already exists, give
 * the option to delete and re-create it.
 * @param {string} name
 */
export const createUser = async (name, confirmAll = false) => {
  try {
    const { User } = await iamClient.send(
      new GetUserCommand({ UserName: name }),
    );
    const input = new ScenarioInput(
      "deleteUser",
      "Do you want to delete and remake this user?",
      { type: "confirm" },
    );
    const deleteUser = await input.handle({}, { confirmAll });
    // If the user exists, and you want to delete it, delete the user
    // and then create it again.
    if (deleteUser) {
      await iamClient.send(new DeleteUserCommand({ UserName: User.UserName }));
      await iamClient.send(new CreateUserCommand({ UserName: name }));
    } else {
      console.warn(
        `${name} already exists. The scenario may not work as expected.`,
      );
      return User;
    }
  } catch (caught) {
    // If there is no user by that name, create one.
    if (caught instanceof Error && caught.name === "NoSuchEntityException") {
      const { User } = await iamClient.send(
        new CreateUserCommand({ UserName: name }),
      );
      return User;
    }
    throw caught;
  }
};

export const main = async (confirmAll = false) => {
  // Create a user. The user has no permissions by default.
  const User = await createUser(userName, confirmAll);

  if (!User) {
    throw new Error("User not created");
  }

  // Create an access key. This key is used to authenticate the new user to
  // Amazon Simple Storage Service (Amazon S3) and AWS Security Token Service (AWS STS).
  // It's not best practice to use access keys. For more information, see https://aws.amazon.com/iam/resources/best-practices/.
  const createAccessKeyResponse = await iamClient.send(
    new CreateAccessKeyCommand({ UserName: userName }),
  );

  if (
    !createAccessKeyResponse.AccessKey?.AccessKeyId ||
    !createAccessKeyResponse.AccessKey?.SecretAccessKey
  ) {
    throw new Error("Access key not created");
  }

  const {
    AccessKey: { AccessKeyId, SecretAccessKey },
  } = createAccessKeyResponse;

  let s3Client = new S3Client({
    credentials: {
      accessKeyId: AccessKeyId,
      secretAccessKey: SecretAccessKey,
    },
  });

  // Retry the list buckets operation until it succeeds. InvalidAccessKeyId is
  // thrown while the user and access keys are still stabilizing.
  await retry({ intervalInMs: 1000, maxRetries: 300 }, async () => {
    try {
      return await listBuckets(s3Client);
    } catch (err) {
      if (err instanceof Error && err.name === "InvalidAccessKeyId") {
        throw err;
      }
    }
  });

  // Retry the create role operation until it succeeds. A MalformedPolicyDocument error
  // is thrown while the user and access keys are still stabilizing.
  const { Role } = await retry(
    {
      intervalInMs: 2000,
      maxRetries: 60,
    },
    () =>
      iamClient.send(
        new CreateRoleCommand({
          AssumeRolePolicyDocument: JSON.stringify({
            Version: "2012-10-17",
            Statement: [
              {
                Effect: "Allow",
                Principal: {
                  // Allow the previously created user to assume this role.
                  AWS: User.Arn,
                },
                Action: "sts:AssumeRole",
              },
            ],
          }),
          RoleName: roleName,
        }),
      ),
  );

  if (!Role) {
    throw new Error("Role not created");
  }

  // Create a policy that allows the user to list S3 buckets.
  const { Policy: listBucketPolicy } = await iamClient.send(
    new CreatePolicyCommand({
      PolicyDocument: JSON.stringify({
        Version: "2012-10-17",
        Statement: [
          {
            Effect: "Allow",
            Action: ["s3:ListAllMyBuckets"],
            Resource: "*",
          },
        ],
      }),
      PolicyName: policyName,
    }),
  );

  if (!listBucketPolicy) {
    throw new Error("Policy not created");
  }

  // Attach the policy granting the 's3:ListAllMyBuckets' action to the role.
  await iamClient.send(
    new AttachRolePolicyCommand({
      PolicyArn: listBucketPolicy.Arn,
      RoleName: Role.RoleName,
    }),
  );

  // Assume the role.
  const stsClient = new STSClient({
    credentials: {
      accessKeyId: AccessKeyId,
      secretAccessKey: SecretAccessKey,
    },
  });

  // Retry the assume role operation until it succeeds.
  const { Credentials } = await retry(
    { intervalInMs: 2000, maxRetries: 60 },
    () =>
      stsClient.send(
        new AssumeRoleCommand({
          RoleArn: Role.Arn,
          RoleSessionName: `iamBasicScenarioSession-${Math.floor(
            Math.random() * 1000000,
          )}`,
          DurationSeconds: 900,
        }),
      ),
  );

  if (!Credentials?.AccessKeyId || !Credentials?.SecretAccessKey) {
    throw new Error("Credentials not created");
  }

  s3Client = new S3Client({
    credentials: {
      accessKeyId: Credentials.AccessKeyId,
      secretAccessKey: Credentials.SecretAccessKey,
      sessionToken: Credentials.SessionToken,
    },
  });

  // List the S3 buckets again.
  // Retry the list buckets operation until it succeeds. AccessDenied might
  // be thrown while the role policy is still stabilizing.
  await retry({ intervalInMs: 2000, maxRetries: 120 }, () =>
    listBuckets(s3Client),
  );

  // Clean up.
  await iamClient.send(
    new DetachRolePolicyCommand({
      PolicyArn: listBucketPolicy.Arn,
      RoleName: Role.RoleName,
    }),
  );

  await iamClient.send(
    new DeletePolicyCommand({
      PolicyArn: listBucketPolicy.Arn,
    }),
  );

  await iamClient.send(
    new DeleteRoleCommand({
      RoleName: Role.RoleName,
    }),
  );

  await iamClient.send(
    new DeleteAccessKeyCommand({
      UserName: userName,
      AccessKeyId,
    }),
  );

  await iamClient.send(
    new DeleteUserCommand({
      UserName: userName,
    }),
  );
};

/**
 *
 * @param {S3Client} s3Client
 */
const listBuckets = async (s3Client) => {
  const { Buckets } = await s3Client.send(new ListBucketsCommand({}));

  if (!Buckets) {
    throw new Error("Buckets not listed");
  }

  console.log(Buckets.map((bucket) => bucket.Name).join("\n"));
};
```
+ API 세부 정보는 *AWS SDK for JavaScript API 참조*의 다음 주제를 참조하세요.
  + [AttachRolePolicy](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/AttachRolePolicyCommand)
  + [CreateAccessKey](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/CreateAccessKeyCommand)
  + [CreatePolicy](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/CreatePolicyCommand)
  + [CreateRole](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/CreateRoleCommand)
  + [CreateUser](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/CreateUserCommand)
  + [DeleteAccessKey](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/DeleteAccessKeyCommand)
  + [DeletePolicy](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/DeletePolicyCommand)
  + [DeleteRole](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/DeleteRoleCommand)
  + [DeleteUser](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/DeleteUserCommand)
  + [DeleteUserPolicy](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/DeleteUserPolicyCommand)
  + [DetachRolePolicy](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/DetachRolePolicyCommand)
  + [PutUserPolicy](https://docs.aws.amazon.com/AWSJavaScriptSDK/v3/latest/client/iam/command/PutUserPolicyCommand)

------
#### [ Kotlin ]

**SDK for Kotlin**  
 GitHub에 더 많은 내용이 있습니다. [AWS 코드 예제 리포지토리](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/kotlin/services/iam#code-examples)에서 전체 예제를 확인하고 설정 및 실행하는 방법을 알아보세요.
IAM 사용자 작업을 래핑하는 함수를 생성합니다.  

```
suspend fun main(args: Array<String>) {
    val usage = """
    Usage:
        <username> <policyName> <roleName> <roleSessionName> <fileLocation> <bucketName> 

    Where:
        username - The name of the IAM user to create. 
        policyName - The name of the policy to create. 
        roleName - The name of the role to create. 
        roleSessionName - The name of the session required for the assumeRole operation. 
        fileLocation - The file location to the JSON required to create the role (see Readme). 
        bucketName - The name of the Amazon S3 bucket from which objects are read. 
    """

    if (args.size != 6) {
        println(usage)
        exitProcess(1)
    }

    val userName = args[0]
    val policyName = args[1]
    val roleName = args[2]
    val roleSessionName = args[3]
    val fileLocation = args[4]
    val bucketName = args[5]

    createUser(userName)
    println("$userName was successfully created.")

    val polArn = createPolicy(policyName)
    println("The policy $polArn was successfully created.")

    val roleArn = createRole(roleName, fileLocation)
    println("$roleArn was successfully created.")
    attachRolePolicy(roleName, polArn)

    println("*** Wait for 1 MIN so the resource is available.")
    delay(60000)
    assumeGivenRole(roleArn, roleSessionName, bucketName)

    println("*** Getting ready to delete the AWS resources.")
    deleteRole(roleName, polArn)
    deleteUser(userName)
    println("This IAM Scenario has successfully completed.")
}

suspend fun createUser(usernameVal: String?): String? {
    val request =
        CreateUserRequest {
            userName = usernameVal
        }

    IamClient { region = "AWS_GLOBAL" }.use { iamClient ->
        val response = iamClient.createUser(request)
        return response.user?.userName
    }
}

suspend fun createPolicy(policyNameVal: String?): String {
    val policyDocumentValue = """
    {
        "Version":"2012-10-17",		 	 	 
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "s3:*"
                ],
                "Resource": "*"
            }
        ]
    }
    """.trimIndent()

    val request =
        CreatePolicyRequest {
            policyName = policyNameVal
            policyDocument = policyDocumentValue
        }

    IamClient.fromEnvironment { region = "AWS_GLOBAL" }.use { iamClient ->
        val response = iamClient.createPolicy(request)
        return response.policy?.arn.toString()
    }
}

suspend fun createRole(
    rolenameVal: String?,
    fileLocation: String?,
): String? {
    val jsonObject = fileLocation?.let { readJsonSimpleDemo(it) } as JSONObject

    val request =
        CreateRoleRequest {
            roleName = rolenameVal
            assumeRolePolicyDocument = jsonObject.toJSONString()
            description = "Created using the AWS SDK for Kotlin"
        }

    IamClient { region = "AWS_GLOBAL" }.use { iamClient ->
        val response = iamClient.createRole(request)
        return response.role?.arn
    }
}

suspend fun attachRolePolicy(
    roleNameVal: String,
    policyArnVal: String,
) {
    val request =
        ListAttachedRolePoliciesRequest {
            roleName = roleNameVal
        }

    IamClient.fromEnvironment { region = "AWS_GLOBAL" }.use { iamClient ->
        val response = iamClient.listAttachedRolePolicies(request)
        val attachedPolicies = response.attachedPolicies

        // Ensure that the policy is not attached to this role.
        val checkStatus: Int
        if (attachedPolicies != null) {
            checkStatus = checkMyList(attachedPolicies, policyArnVal)
            if (checkStatus == -1) {
                return
            }
        }

        val policyRequest =
            AttachRolePolicyRequest {
                roleName = roleNameVal
                policyArn = policyArnVal
            }
        iamClient.attachRolePolicy(policyRequest)
        println("Successfully attached policy $policyArnVal to role $roleNameVal")
    }
}

fun checkMyList(
    attachedPolicies: List<AttachedPolicy>,
    policyArnVal: String,
): Int {
    for (policy in attachedPolicies) {
        val polArn = policy.policyArn.toString()

        if (polArn.compareTo(policyArnVal) == 0) {
            println("The policy is already attached to this role.")
            return -1
        }
    }
    return 0
}

suspend fun assumeGivenRole(
    roleArnVal: String?,
    roleSessionNameVal: String?,
    bucketName: String,
) {
    val stsClient = StsClient.fromEnvironment { region = "us-east-1" }
    val roleRequest =
        AssumeRoleRequest {
            roleArn = roleArnVal
            roleSessionName = roleSessionNameVal
        }

    val roleResponse = stsClient.assumeRole(roleRequest)
    val myCreds = roleResponse.credentials
    val key = myCreds?.accessKeyId
    val secKey = myCreds?.secretAccessKey
    val secToken = myCreds?.sessionToken

    val staticCredentials = StaticCredentialsProvider {
        accessKeyId = key
        secretAccessKey = secKey
        sessionToken = secToken
    }

    // List all objects in an Amazon S3 bucket using the temp creds.
    val s3 = S3Client.fromEnvironment {
        region = "us-east-1"
        credentialsProvider = staticCredentials
    }

    println("Created a S3Client using temp credentials.")
    println("Listing objects in $bucketName")

    val listObjects =
        ListObjectsRequest {
            bucket = bucketName
        }

    val response = s3.listObjects(listObjects)
    response.contents?.forEach { myObject ->
        println("The name of the key is ${myObject.key}")
        println("The owner is ${myObject.owner}")
    }
}

suspend fun deleteRole(
    roleNameVal: String,
    polArn: String,
) {
    val iam = IamClient.fromEnvironment { region = "AWS_GLOBAL" }

    // First the policy needs to be detached.
    val rolePolicyRequest =
        DetachRolePolicyRequest {
            policyArn = polArn
            roleName = roleNameVal
        }

    iam.detachRolePolicy(rolePolicyRequest)

    // Delete the policy.
    val request =
        DeletePolicyRequest {
            policyArn = polArn
        }

    iam.deletePolicy(request)
    println("*** Successfully deleted $polArn")

    // Delete the role.
    val roleRequest =
        DeleteRoleRequest {
            roleName = roleNameVal
        }

    iam.deleteRole(roleRequest)
    println("*** Successfully deleted $roleNameVal")
}

suspend fun deleteUser(userNameVal: String) {
    val iam = IamClient.fromEnvironment { region = "AWS_GLOBAL" }
    val request =
        DeleteUserRequest {
            userName = userNameVal
        }

    iam.deleteUser(request)
    println("*** Successfully deleted $userNameVal")
}

@Throws(java.lang.Exception::class)
fun readJsonSimpleDemo(filename: String): Any? {
    val reader = FileReader(filename)
    val jsonParser = JSONParser()
    return jsonParser.parse(reader)
}
```
+ API 세부 정보는 *AWS SDK for Kotlin API 참조*의 다음 주제를 참조하세요.
  + [AttachRolePolicy](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [CreateAccessKey](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [CreatePolicy](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [CreateRole](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [CreateUser](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [DeleteAccessKey](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [DeletePolicy](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [DeleteRole](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [DeleteUser](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [DeleteUserPolicy](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [DetachRolePolicy](https://sdk.amazonaws.com/kotlin/api/latest/index.html)
  + [PutUserPolicy](https://sdk.amazonaws.com/kotlin/api/latest/index.html)

------
#### [ PHP ]

**SDK for PHP**  
 GitHub에 더 많은 내용이 있습니다. [AWS 코드 예제 리포지토리](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/php/example_code/iam#code-examples)에서 전체 예제를 확인하고 설정 및 실행하는 방법을 알아보세요.

```
namespace Iam\Basics;

require 'vendor/autoload.php';

use Aws\Credentials\Credentials;
use Aws\S3\Exception\S3Exception;
use Aws\S3\S3Client;
use Aws\Sts\StsClient;
use Iam\IAMService;

echo("\n");
echo("--------------------------------------\n");
print("Welcome to the IAM getting started demo using PHP!\n");
echo("--------------------------------------\n");

$uuid = uniqid();
$service = new IAMService();

$user = $service->createUser("iam_demo_user_$uuid");
echo "Created user with the arn: {$user['Arn']}\n";

$key = $service->createAccessKey($user['UserName']);
$assumeRolePolicyDocument = "{
                \"Version\": \"2012-10-17\",
                \"Statement\": [{
                    \"Effect\": \"Allow\",
                    \"Principal\": {\"AWS\": \"{$user['Arn']}\"},
                    \"Action\": \"sts:AssumeRole\"
                }]
            }";
$assumeRoleRole = $service->createRole("iam_demo_role_$uuid", $assumeRolePolicyDocument);
echo "Created role: {$assumeRoleRole['RoleName']}\n";

$listAllBucketsPolicyDocument = "{
                \"Version\": \"2012-10-17\",
                \"Statement\": [{
                    \"Effect\": \"Allow\",
                    \"Action\": \"s3:ListAllMyBuckets\",
                    \"Resource\": \"arn:aws:s3:::*\"}]
}";
$listAllBucketsPolicy = $service->createPolicy("iam_demo_policy_$uuid", $listAllBucketsPolicyDocument);
echo "Created policy: {$listAllBucketsPolicy['PolicyName']}\n";

$service->attachRolePolicy($assumeRoleRole['RoleName'], $listAllBucketsPolicy['Arn']);

$inlinePolicyDocument = "{
                \"Version\": \"2012-10-17\",
                \"Statement\": [{
                    \"Effect\": \"Allow\",
                    \"Action\": \"sts:AssumeRole\",
                    \"Resource\": \"{$assumeRoleRole['Arn']}\"}]
}";
$inlinePolicy = $service->createUserPolicy("iam_demo_inline_policy_$uuid", $inlinePolicyDocument, $user['UserName']);
//First, fail to list the buckets with the user
$credentials = new Credentials($key['AccessKeyId'], $key['SecretAccessKey']);
$s3Client = new S3Client(['region' => 'us-west-2', 'version' => 'latest', 'credentials' => $credentials]);
try {
    $s3Client->listBuckets([
    ]);
    echo "this should not run";
} catch (S3Exception $exception) {
    echo "successfully failed!\n";
}

$stsClient = new StsClient(['region' => 'us-west-2', 'version' => 'latest', 'credentials' => $credentials]);
sleep(10);
$assumedRole = $stsClient->assumeRole([
    'RoleArn' => $assumeRoleRole['Arn'],
    'RoleSessionName' => "DemoAssumeRoleSession_$uuid",
]);
$assumedCredentials = [
    'key' => $assumedRole['Credentials']['AccessKeyId'],
    'secret' => $assumedRole['Credentials']['SecretAccessKey'],
    'token' => $assumedRole['Credentials']['SessionToken'],
];
$s3Client = new S3Client(['region' => 'us-west-2', 'version' => 'latest', 'credentials' => $assumedCredentials]);
try {
    $s3Client->listBuckets([]);
    echo "this should now run!\n";
} catch (S3Exception $exception) {
    echo "this should now not fail\n";
}

$service->detachRolePolicy($assumeRoleRole['RoleName'], $listAllBucketsPolicy['Arn']);
$deletePolicy = $service->deletePolicy($listAllBucketsPolicy['Arn']);
echo "Delete policy: {$listAllBucketsPolicy['PolicyName']}\n";
$deletedRole = $service->deleteRole($assumeRoleRole['Arn']);
echo "Deleted role: {$assumeRoleRole['RoleName']}\n";
$deletedKey = $service->deleteAccessKey($key['AccessKeyId'], $user['UserName']);
$deletedUser = $service->deleteUser($user['UserName']);
echo "Delete user: {$user['UserName']}\n";
```
+ API 세부 정보는 *AWS SDK for PHP API 참조*의 다음 주제를 참조하세요.
  + [AttachRolePolicy](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/AttachRolePolicy)
  + [CreateAccessKey](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/CreateAccessKey)
  + [CreatePolicy](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/CreatePolicy)
  + [CreateRole](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/CreateRole)
  + [CreateUser](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/CreateUser)
  + [DeleteAccessKey](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/DeleteAccessKey)
  + [DeletePolicy](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/DeletePolicy)
  + [DeleteRole](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/DeleteRole)
  + [DeleteUser](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/DeleteUser)
  + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/DeleteUserPolicy)
  + [DetachRolePolicy](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/DetachRolePolicy)
  + [PutUserPolicy](https://docs.aws.amazon.com/goto/SdkForPHPV3/iam-2010-05-08/PutUserPolicy)

------
#### [ Python ]

**SDK for Python (Boto3)**  
 GitHub에 더 많은 내용이 있습니다. [AWS 코드 예제 리포지토리](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/python/example_code/iam#code-examples)에서 전체 예제를 확인하고 설정 및 실행하는 방법을 알아보세요.
Amazon S3 버킷을 나열할 수 있는 권한을 부여하는 역할과 IAM 사용자를 생성합니다. 사용자는 역할을 수임할 수 있는 권한만 있습니다. 역할을 수임한 후 임시 자격 증명을 사용하여 계정의 버킷을 나열합니다.  

```
import json
import sys
import time
from uuid import uuid4

import boto3
from botocore.exceptions import ClientError


def progress_bar(seconds):
    """Shows a simple progress bar in the command window."""
    for _ in range(seconds):
        time.sleep(1)
        print(".", end="")
        sys.stdout.flush()
    print()


def setup(iam_resource):
    """
    Creates a new user with no permissions.
    Creates an access key pair for the user.
    Creates a role with a policy that lets the user assume the role.
    Creates a policy that allows listing Amazon S3 buckets.
    Attaches the policy to the role.
    Creates an inline policy for the user that lets the user assume the role.

    :param iam_resource: A Boto3 AWS Identity and Access Management (IAM) resource
                         that has permissions to create users, roles, and policies
                         in the account.
    :return: The newly created user, user key, and role.
    """
    try:
        user = iam_resource.create_user(UserName=f"demo-user-{uuid4()}")
        print(f"Created user {user.name}.")
    except ClientError as error:
        print(
            f"Couldn't create a user for the demo. Here's why: "
            f"{error.response['Error']['Message']}"
        )
        raise

    try:
        user_key = user.create_access_key_pair()
        print(f"Created access key pair for user.")
    except ClientError as error:
        print(
            f"Couldn't create access keys for user {user.name}. Here's why: "
            f"{error.response['Error']['Message']}"
        )
        raise

    print(f"Wait for user to be ready.", end="")
    progress_bar(10)

    try:
        role = iam_resource.create_role(
            RoleName=f"demo-role-{uuid4()}",
            AssumeRolePolicyDocument=json.dumps(
                {
                    "Version":"2012-10-17",		 	 	 
                    "Statement": [
                        {
                            "Effect": "Allow",
                            "Principal": {"AWS": user.arn},
                            "Action": "sts:AssumeRole",
                        }
                    ],
                }
            ),
        )
        print(f"Created role {role.name}.")
    except ClientError as error:
        print(
            f"Couldn't create a role for the demo. Here's why: "
            f"{error.response['Error']['Message']}"
        )
        raise

    try:
        policy = iam_resource.create_policy(
            PolicyName=f"demo-policy-{uuid4()}",
            PolicyDocument=json.dumps(
                {
                    "Version":"2012-10-17",		 	 	 
                    "Statement": [
                        {
                            "Effect": "Allow",
                            "Action": "s3:ListAllMyBuckets",
                            "Resource": "arn:aws:s3:::*",
                        }
                    ],
                }
            ),
        )
        role.attach_policy(PolicyArn=policy.arn)
        print(f"Created policy {policy.policy_name} and attached it to the role.")
    except ClientError as error:
        print(
            f"Couldn't create a policy and attach it to role {role.name}. Here's why: "
            f"{error.response['Error']['Message']}"
        )
        raise

    try:
        user.create_policy(
            PolicyName=f"demo-user-policy-{uuid4()}",
            PolicyDocument=json.dumps(
                {
                    "Version":"2012-10-17",		 	 	 
                    "Statement": [
                        {
                            "Effect": "Allow",
                            "Action": "sts:AssumeRole",
                            "Resource": role.arn,
                        }
                    ],
                }
            ),
        )
        print(
            f"Created an inline policy for {user.name} that lets the user assume "
            f"the role."
        )
    except ClientError as error:
        print(
            f"Couldn't create an inline policy for user {user.name}. Here's why: "
            f"{error.response['Error']['Message']}"
        )
        raise

    print("Give AWS time to propagate these new resources and connections.", end="")
    progress_bar(10)

    return user, user_key, role


def show_access_denied_without_role(user_key):
    """
    Shows that listing buckets without first assuming the role is not allowed.

    :param user_key: The key of the user created during setup. This user does not
                     have permission to list buckets in the account.
    """
    print(f"Try to list buckets without first assuming the role.")
    s3_denied_resource = boto3.resource(
        "s3", aws_access_key_id=user_key.id, aws_secret_access_key=user_key.secret
    )
    try:
        for bucket in s3_denied_resource.buckets.all():
            print(bucket.name)
        raise RuntimeError("Expected to get AccessDenied error when listing buckets!")
    except ClientError as error:
        if error.response["Error"]["Code"] == "AccessDenied":
            print("Attempt to list buckets with no permissions: AccessDenied.")
        else:
            raise


def list_buckets_from_assumed_role(user_key, assume_role_arn, session_name):
    """
    Assumes a role that grants permission to list the Amazon S3 buckets in the account.
    Uses the temporary credentials from the role to list the buckets that are owned
    by the assumed role's account.

    :param user_key: The access key of a user that has permission to assume the role.
    :param assume_role_arn: The Amazon Resource Name (ARN) of the role that
                            grants access to list the other account's buckets.
    :param session_name: The name of the STS session.
    """
    sts_client = boto3.client(
        "sts", aws_access_key_id=user_key.id, aws_secret_access_key=user_key.secret
    )
    try:
        response = sts_client.assume_role(
            RoleArn=assume_role_arn, RoleSessionName=session_name
        )
        temp_credentials = response["Credentials"]
        print(f"Assumed role {assume_role_arn} and got temporary credentials.")
    except ClientError as error:
        print(
            f"Couldn't assume role {assume_role_arn}. Here's why: "
            f"{error.response['Error']['Message']}"
        )
        raise

    # Create an S3 resource that can access the account with the temporary credentials.
    s3_resource = boto3.resource(
        "s3",
        aws_access_key_id=temp_credentials["AccessKeyId"],
        aws_secret_access_key=temp_credentials["SecretAccessKey"],
        aws_session_token=temp_credentials["SessionToken"],
    )
    print(f"Listing buckets for the assumed role's account:")
    try:
        for bucket in s3_resource.buckets.all():
            print(bucket.name)
    except ClientError as error:
        print(
            f"Couldn't list buckets for the account. Here's why: "
            f"{error.response['Error']['Message']}"
        )
        raise




def teardown(user, role):
    """
    Removes all resources created during setup.

    :param user: The demo user.
    :param role: The demo role.
    """
    try:
        for attached in role.attached_policies.all():
            policy_name = attached.policy_name
            role.detach_policy(PolicyArn=attached.arn)
            attached.delete()
            print(f"Detached and deleted {policy_name}.")
        role.delete()
        print(f"Deleted {role.name}.")
    except ClientError as error:
        print(
            "Couldn't detach policy, delete policy, or delete role. Here's why: "
            f"{error.response['Error']['Message']}"
        )
        raise

    try:
        for user_pol in user.policies.all():
            user_pol.delete()
            print("Deleted inline user policy.")
        for key in user.access_keys.all():
            key.delete()
            print("Deleted user's access key.")
        user.delete()
        print(f"Deleted {user.name}.")
    except ClientError as error:
        print(
            "Couldn't delete user policy or delete user. Here's why: "
            f"{error.response['Error']['Message']}"
        )


def usage_demo():
    """Drives the demonstration."""
    print("-" * 88)
    print(f"Welcome to the IAM create user and assume role demo.")
    print("-" * 88)
    iam_resource = boto3.resource("iam")
    user = None
    role = None
    try:
        user, user_key, role = setup(iam_resource)
        print(f"Created {user.name} and {role.name}.")
        show_access_denied_without_role(user_key)
        list_buckets_from_assumed_role(user_key, role.arn, "AssumeRoleDemoSession")
    except Exception:
        print("Something went wrong!")
    finally:
        if user is not None and role is not None:
            teardown(user, role)
        print("Thanks for watching!")


if __name__ == "__main__":
    usage_demo()
```
+ API 세부 정보는 *AWS SDK for Python (Boto3) API 참조*의 다음 주제를 참조하세요.
  + [AttachRolePolicy](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/AttachRolePolicy)
  + [CreateAccessKey](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/CreateAccessKey)
  + [CreatePolicy](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/CreatePolicy)
  + [CreateRole](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/CreateRole)
  + [CreateUser](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/CreateUser)
  + [DeleteAccessKey](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/DeleteAccessKey)
  + [DeletePolicy](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/DeletePolicy)
  + [DeleteRole](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/DeleteRole)
  + [DeleteUser](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/DeleteUser)
  + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/DeleteUserPolicy)
  + [DetachRolePolicy](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/DetachRolePolicy)
  + [PutUserPolicy](https://docs.aws.amazon.com/goto/boto3/iam-2010-05-08/PutUserPolicy)

------
#### [ Ruby ]

**SDK for Ruby**  
 GitHub에 더 많은 내용이 있습니다. [AWS 코드 예제 리포지토리](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/ruby/example_code/iam#code-examples)에서 전체 예제를 확인하고 설정 및 실행하는 방법을 알아보세요.
Amazon S3 버킷을 나열할 수 있는 권한을 부여하는 역할과 IAM 사용자를 생성합니다. 사용자는 역할을 수임할 수 있는 권한만 있습니다. 역할을 수임한 후 임시 자격 증명을 사용하여 계정의 버킷을 나열합니다.  

```
# Wraps the scenario actions.
class ScenarioCreateUserAssumeRole
  attr_reader :iam_client

  # @param [Aws::IAM::Client] iam_client: The AWS IAM client.
  def initialize(iam_client, logger: Logger.new($stdout))
    @iam_client = iam_client
    @logger = logger
  end

  # Waits for the specified number of seconds.
  #
  # @param duration [Integer] The number of seconds to wait.
  def wait(duration)
    puts('Give AWS time to propagate resources...')
    sleep(duration)
  end

  # Creates a user.
  #
  # @param user_name [String] The name to give the user.
  # @return [Aws::IAM::User] The newly created user.
  def create_user(user_name)
    user = @iam_client.create_user(user_name: user_name).user
    @logger.info("Created demo user named #{user.user_name}.")
  rescue Aws::Errors::ServiceError => e
    @logger.info('Tried and failed to create demo user.')
    @logger.info("\t#{e.code}: #{e.message}")
    @logger.info("\nCan't continue the demo without a user!")
    raise
  else
    user
  end

  # Creates an access key for a user.
  #
  # @param user [Aws::IAM::User] The user that owns the key.
  # @return [Aws::IAM::AccessKeyPair] The newly created access key.
  def create_access_key_pair(user)
    user_key = @iam_client.create_access_key(user_name: user.user_name).access_key
    @logger.info("Created accesskey pair for user #{user.user_name}.")
  rescue Aws::Errors::ServiceError => e
    @logger.info("Couldn't create access keys for user #{user.user_name}.")
    @logger.info("\t#{e.code}: #{e.message}")
    raise
  else
    user_key
  end

  # Creates a role that can be assumed by a user.
  #
  # @param role_name [String] The name to give the role.
  # @param user [Aws::IAM::User] The user who is granted permission to assume the role.
  # @return [Aws::IAM::Role] The newly created role.
  def create_role(role_name, user)
    trust_policy = {
      Version: '2012-10-17',
      Statement: [{
        Effect: 'Allow',
        Principal: { 'AWS': user.arn },
        Action: 'sts:AssumeRole'
      }]
    }.to_json
    role = @iam_client.create_role(
      role_name: role_name,
      assume_role_policy_document: trust_policy
    ).role
    @logger.info("Created role #{role.role_name}.")
  rescue Aws::Errors::ServiceError => e
    @logger.info("Couldn't create a role for the demo. Here's why: ")
    @logger.info("\t#{e.code}: #{e.message}")
    raise
  else
    role
  end

  # Creates a policy that grants permission to list S3 buckets in the account, and
  # then attaches the policy to a role.
  #
  # @param policy_name [String] The name to give the policy.
  # @param role [Aws::IAM::Role] The role that the policy is attached to.
  # @return [Aws::IAM::Policy] The newly created policy.
  def create_and_attach_role_policy(policy_name, role)
    policy_document = {
      Version: '2012-10-17',
      Statement: [{
        Effect: 'Allow',
        Action: 's3:ListAllMyBuckets',
        Resource: 'arn:aws:s3:::*'
      }]
    }.to_json
    policy = @iam_client.create_policy(
      policy_name: policy_name,
      policy_document: policy_document
    ).policy
    @iam_client.attach_role_policy(
      role_name: role.role_name,
      policy_arn: policy.arn
    )
    @logger.info("Created policy #{policy.policy_name} and attached it to role #{role.role_name}.")
  rescue Aws::Errors::ServiceError => e
    @logger.info("Couldn't create a policy and attach it to role #{role.role_name}. Here's why: ")
    @logger.info("\t#{e.code}: #{e.message}")
    raise
  end

  # Creates an inline policy for a user that lets the user assume a role.
  #
  # @param policy_name [String] The name to give the policy.
  # @param user [Aws::IAM::User] The user that owns the policy.
  # @param role [Aws::IAM::Role] The role that can be assumed.
  # @return [Aws::IAM::UserPolicy] The newly created policy.
  def create_user_policy(policy_name, user, role)
    policy_document = {
      Version: '2012-10-17',
      Statement: [{
        Effect: 'Allow',
        Action: 'sts:AssumeRole',
        Resource: role.arn
      }]
    }.to_json
    @iam_client.put_user_policy(
      user_name: user.user_name,
      policy_name: policy_name,
      policy_document: policy_document
    )
    puts("Created an inline policy for #{user.user_name} that lets the user assume role #{role.role_name}.")
  rescue Aws::Errors::ServiceError => e
    @logger.info("Couldn't create an inline policy for user #{user.user_name}. Here's why: ")
    @logger.info("\t#{e.code}: #{e.message}")
    raise
  end

  # Creates an Amazon S3 resource with specified credentials. This is separated into a
  # factory function so that it can be mocked for unit testing.
  #
  # @param credentials [Aws::Credentials] The credentials used by the Amazon S3 resource.
  def create_s3_resource(credentials)
    Aws::S3::Resource.new(client: Aws::S3::Client.new(credentials: credentials))
  end

  # Lists the S3 buckets for the account, using the specified Amazon S3 resource.
  # Because the resource uses credentials with limited access, it may not be able to
  # list the S3 buckets.
  #
  # @param s3_resource [Aws::S3::Resource] An Amazon S3 resource.
  def list_buckets(s3_resource)
    count = 10
    s3_resource.buckets.each do |bucket|
      @logger.info "\t#{bucket.name}"
      count -= 1
      break if count.zero?
    end
  rescue Aws::Errors::ServiceError => e
    if e.code == 'AccessDenied'
      puts('Attempt to list buckets with no permissions: AccessDenied.')
    else
      @logger.info("Couldn't list buckets for the account. Here's why: ")
      @logger.info("\t#{e.code}: #{e.message}")
      raise
    end
  end

  # Creates an AWS Security Token Service (AWS STS) client with specified credentials.
  # This is separated into a factory function so that it can be mocked for unit testing.
  #
  # @param key_id [String] The ID of the access key used by the STS client.
  # @param key_secret [String] The secret part of the access key used by the STS client.
  def create_sts_client(key_id, key_secret)
    Aws::STS::Client.new(access_key_id: key_id, secret_access_key: key_secret)
  end

  # Gets temporary credentials that can be used to assume a role.
  #
  # @param role_arn [String] The ARN of the role that is assumed when these credentials
  #                          are used.
  # @param sts_client [AWS::STS::Client] An AWS STS client.
  # @return [Aws::AssumeRoleCredentials] The credentials that can be used to assume the role.
  def assume_role(role_arn, sts_client)
    credentials = Aws::AssumeRoleCredentials.new(
      client: sts_client,
      role_arn: role_arn,
      role_session_name: 'create-use-assume-role-scenario'
    )
    @logger.info("Assumed role '#{role_arn}', got temporary credentials.")
    credentials
  end

  # Deletes a role. If the role has policies attached, they are detached and
  # deleted before the role is deleted.
  #
  # @param role_name [String] The name of the role to delete.
  def delete_role(role_name)
    @iam_client.list_attached_role_policies(role_name: role_name).attached_policies.each do |policy|
      @iam_client.detach_role_policy(role_name: role_name, policy_arn: policy.policy_arn)
      @iam_client.delete_policy(policy_arn: policy.policy_arn)
      @logger.info("Detached and deleted policy #{policy.policy_name}.")
    end
    @iam_client.delete_role({ role_name: role_name })
    @logger.info("Role deleted: #{role_name}.")
  rescue Aws::Errors::ServiceError => e
    @logger.info("Couldn't detach policies and delete role #{role.name}. Here's why:")
    @logger.info("\t#{e.code}: #{e.message}")
    raise
  end

  # Deletes a user. If the user has inline policies or access keys, they are deleted
  # before the user is deleted.
  #
  # @param user [Aws::IAM::User] The user to delete.
  def delete_user(user_name)
    user = @iam_client.list_access_keys(user_name: user_name).access_key_metadata
    user.each do |key|
      @iam_client.delete_access_key({ access_key_id: key.access_key_id, user_name: user_name })
      @logger.info("Deleted access key #{key.access_key_id} for user '#{user_name}'.")
    end

    @iam_client.delete_user(user_name: user_name)
    @logger.info("Deleted user '#{user_name}'.")
  rescue Aws::IAM::Errors::ServiceError => e
    @logger.error("Error deleting user '#{user_name}': #{e.message}")
  end
end

# Runs the IAM create a user and assume a role scenario.
def run_scenario(scenario)
  puts('-' * 88)
  puts('Welcome to the IAM create a user and assume a role demo!')
  puts('-' * 88)
  user = scenario.create_user("doc-example-user-#{Random.uuid}")
  user_key = scenario.create_access_key_pair(user)
  scenario.wait(10)
  role = scenario.create_role("doc-example-role-#{Random.uuid}", user)
  scenario.create_and_attach_role_policy("doc-example-role-policy-#{Random.uuid}", role)
  scenario.create_user_policy("doc-example-user-policy-#{Random.uuid}", user, role)
  scenario.wait(10)
  puts('Try to list buckets with credentials for a user who has no permissions.')
  puts('Expect AccessDenied from this call.')
  scenario.list_buckets(
    scenario.create_s3_resource(Aws::Credentials.new(user_key.access_key_id, user_key.secret_access_key))
  )
  puts('Now, assume the role that grants permission.')
  temp_credentials = scenario.assume_role(
    role.arn, scenario.create_sts_client(user_key.access_key_id, user_key.secret_access_key)
  )
  puts('Here are your buckets:')
  scenario.list_buckets(scenario.create_s3_resource(temp_credentials))
  puts("Deleting role '#{role.role_name}' and attached policies.")
  scenario.delete_role(role.role_name)
  puts("Deleting user '#{user.user_name}', policies, and keys.")
  scenario.delete_user(user.user_name)
  puts('Thanks for watching!')
  puts('-' * 88)
rescue Aws::Errors::ServiceError => e
  puts('Something went wrong with the demo.')
  puts("\t#{e.code}: #{e.message}")
end

run_scenario(ScenarioCreateUserAssumeRole.new(Aws::IAM::Client.new)) if $PROGRAM_NAME == __FILE__
```
+ API 세부 정보는 *AWS SDK for Ruby API 참조*의 다음 주제를 참조하십시오.
  + [AttachRolePolicy](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/AttachRolePolicy)
  + [CreateAccessKey](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/CreateAccessKey)
  + [CreatePolicy](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/CreatePolicy)
  + [CreateRole](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/CreateRole)
  + [CreateUser](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/CreateUser)
  + [DeleteAccessKey](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/DeleteAccessKey)
  + [DeletePolicy](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/DeletePolicy)
  + [DeleteRole](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/DeleteRole)
  + [DeleteUser](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/DeleteUser)
  + [DeleteUserPolicy](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/DeleteUserPolicy)
  + [DetachRolePolicy](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/DetachRolePolicy)
  + [PutUserPolicy](https://docs.aws.amazon.com/goto/SdkForRubyV3/iam-2010-05-08/PutUserPolicy)

------
#### [ Rust ]

**SDK for Rust**  
 GitHub에 더 많은 내용이 있습니다. [AWS 코드 예제 리포지토리](https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/rustv1/examples/iam#code-examples)에서 전체 예제를 확인하고 설정 및 실행하는 방법을 알아보세요.

```
use aws_config::meta::region::RegionProviderChain;
use aws_sdk_iam::Error as iamError;
use aws_sdk_iam::{config::Credentials as iamCredentials, config::Region, Client as iamClient};
use aws_sdk_s3::Client as s3Client;
use aws_sdk_sts::Client as stsClient;
use tokio::time::{sleep, Duration};
use uuid::Uuid;

#[tokio::main]
async fn main() -> Result<(), iamError> {
    let (client, uuid, list_all_buckets_policy_document, inline_policy_document) =
        initialize_variables().await;

    if let Err(e) = run_iam_operations(
        client,
        uuid,
        list_all_buckets_policy_document,
        inline_policy_document,
    )
    .await
    {
        println!("{:?}", e);
    };

    Ok(())
}

async fn initialize_variables() -> (iamClient, String, String, String) {
    let region_provider = RegionProviderChain::first_try(Region::new("us-west-2"));

    let shared_config = aws_config::from_env().region(region_provider).load().await;
    let client = iamClient::new(&shared_config);
    let uuid = Uuid::new_v4().to_string();

    let list_all_buckets_policy_document = "{
                \"Version\": \"2012-10-17\",
                \"Statement\": [{
                    \"Effect\": \"Allow\",
                    \"Action\": \"s3:ListAllMyBuckets\",
                    \"Resource\": \"arn:aws:s3:::*\"}]
    }"
    .to_string();
    let inline_policy_document = "{
                \"Version\": \"2012-10-17\",
                \"Statement\": [{
                    \"Effect\": \"Allow\",
                    \"Action\": \"sts:AssumeRole\",
                    \"Resource\": \"{}\"}]
    }"
    .to_string();

    (
        client,
        uuid,
        list_all_buckets_policy_document,
        inline_policy_document,
    )
}

async fn run_iam_operations(
    client: iamClient,
    uuid: String,
    list_all_buckets_policy_document: String,
    inline_policy_document: String,
) -> Result<(), iamError> {
    let user = iam_service::create_user(&client, &format!("{}{}", "iam_demo_user_", uuid)).await?;
    println!("Created the user with the name: {}", user.user_name());
    let key = iam_service::create_access_key(&client, user.user_name()).await?;

    let assume_role_policy_document = "{
        \"Version\": \"2012-10-17\",
                \"Statement\": [{
                    \"Effect\": \"Allow\",
                    \"Principal\": {\"AWS\": \"{}\"},
                    \"Action\": \"sts:AssumeRole\"
                }]
            }"
    .to_string()
    .replace("{}", user.arn());

    let assume_role_role = iam_service::create_role(
        &client,
        &format!("{}{}", "iam_demo_role_", uuid),
        &assume_role_policy_document,
    )
    .await?;
    println!("Created the role with the ARN: {}", assume_role_role.arn());

    let list_all_buckets_policy = iam_service::create_policy(
        &client,
        &format!("{}{}", "iam_demo_policy_", uuid),
        &list_all_buckets_policy_document,
    )
    .await?;
    println!(
        "Created policy: {}",
        list_all_buckets_policy.policy_name.as_ref().unwrap()
    );

    let attach_role_policy_result =
        iam_service::attach_role_policy(&client, &assume_role_role, &list_all_buckets_policy)
            .await?;
    println!(
        "Attached the policy to the role: {:?}",
        attach_role_policy_result
    );

    let inline_policy_name = format!("{}{}", "iam_demo_inline_policy_", uuid);
    let inline_policy_document = inline_policy_document.replace("{}", assume_role_role.arn());
    iam_service::create_user_policy(&client, &user, &inline_policy_name, &inline_policy_document)
        .await?;
    println!("Created inline policy.");

    //First, fail to list the buckets with the user.
    let creds = iamCredentials::from_keys(key.access_key_id(), key.secret_access_key(), None);
    let fail_config = aws_config::from_env()
        .credentials_provider(creds.clone())
        .load()
        .await;
    println!("Fail config: {:?}", fail_config);
    let fail_client: s3Client = s3Client::new(&fail_config);
    match fail_client.list_buckets().send().await {
        Ok(e) => {
            println!("This should not run. {:?}", e);
        }
        Err(e) => {
            println!("Successfully failed with error: {:?}", e)
        }
    }

    let sts_config = aws_config::from_env()
        .credentials_provider(creds.clone())
        .load()
        .await;
    let sts_client: stsClient = stsClient::new(&sts_config);
    sleep(Duration::from_secs(10)).await;
    let assumed_role = sts_client
        .assume_role()
        .role_arn(assume_role_role.arn())
        .role_session_name(format!("iam_demo_assumerole_session_{uuid}"))
        .send()
        .await;
    println!("Assumed role: {:?}", assumed_role);
    sleep(Duration::from_secs(10)).await;

    let assumed_credentials = iamCredentials::from_keys(
        assumed_role
            .as_ref()
            .unwrap()
            .credentials
            .as_ref()
            .unwrap()
            .access_key_id(),
        assumed_role
            .as_ref()
            .unwrap()
            .credentials
            .as_ref()
            .unwrap()
            .secret_access_key(),
        Some(
            assumed_role
                .as_ref()
                .unwrap()
                .credentials
                .as_ref()
                .unwrap()
                .session_token
                .clone(),
        ),
    );

    let succeed_config = aws_config::from_env()
        .credentials_provider(assumed_credentials)
        .load()
        .await;
    println!("succeed config: {:?}", succeed_config);
    let succeed_client: s3Client = s3Client::new(&succeed_config);
    sleep(Duration::from_secs(10)).await;
    match succeed_client.list_buckets().send().await {
        Ok(_) => {
            println!("This should now run successfully.")
        }
        Err(e) => {
            println!("This should not run. {:?}", e);
            panic!()
        }
    }

    //Clean up.
    iam_service::detach_role_policy(
        &client,
        assume_role_role.role_name(),
        list_all_buckets_policy.arn().unwrap_or_default(),
    )
    .await?;
    iam_service::delete_policy(&client, list_all_buckets_policy).await?;
    iam_service::delete_role(&client, &assume_role_role).await?;
    println!("Deleted role {}", assume_role_role.role_name());
    iam_service::delete_access_key(&client, &user, &key).await?;
    println!("Deleted key for {}", key.user_name());
    iam_service::delete_user_policy(&client, &user, &inline_policy_name).await?;
    println!("Deleted inline user policy: {}", inline_policy_name);
    iam_service::delete_user(&client, &user).await?;
    println!("Deleted user {}", user.user_name());

    Ok(())
}
```
+ API 세부 정보는 *AWS SDK for Rust API 참조*의 다음 주제를 참조하세요.
  + [AttachRolePolicy](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.attach_role_policy)
  + [CreateAccessKey](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.create_access_key)
  + [CreatePolicy](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.create_policy)
  + [CreateRole](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.create_role)
  + [CreateUser](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.create_user)
  + [DeleteAccessKey](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.delete_access_key)
  + [DeletePolicy](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.delete_policy)
  + [DeleteRole](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.delete_role)
  + [DeleteUser](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.delete_user)
  + [DeleteUserPolicy](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.delete_user_policy)
  + [DetachRolePolicy](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.detach_role_policy)
  + [PutUserPolicy](https://docs.rs/aws-sdk-iam/latest/aws_sdk_iam/client/struct.Client.html#method.put_user_policy)

------

# IAM 역할을 사용하여 Amazon EC2 인스턴스에서 실행되는 애플리케이션에 권한 부여
<a name="id_roles_use_switch-role-ec2"></a>

Amazon EC2 인스턴스에서 실행되는 애플리케이션에는 AWS API 요청에 AWS 보안 인증 정보가 포함되어 있어야 합니다. 개발자에게 Amazon EC2 인스턴스 내에서 직접 AWS 보안 인증 정보를 저장하고 해당 인스턴스의 애플리케이션에서 해당 보안 인증 정보를 사용하는 것을 허용하도록 했을 수 있습니다. 그러나 개발자는 그런 다음에 보안 인증을 관리해야 하며, 각 인스턴스에 보안 인증을 안전하게 전달하고 보안 인증을 업데이트해야 할 때 각 Amazon EC2 인스턴스를 업데이트해야 합니다. 이처럼 여기에는 많은 작업이 요구됩니다.

이렇게 하는 대신 IAM 역할을 사용하여 Amazon EC2 인스턴스에서 실행되는 애플리케이션에 대한 *임시* 보안 인증 정보를 관리할 수 있고 또 그렇게 해야 합니다. 역할을 사용할 때 Amazon EC2 인스턴스에 장기 보안 인증 정보(예: 로그인 보안 인증 정보 또는 액세스 키)를 배포하지 않아도 됩니다. 그 대신 역할은 애플리케이션에서 다른 AWS 리소스에 호출할 때 사용할 수 있는 임시 권한을 제공합니다. Amazon EC2 인스턴스를 시작할 때 인스턴스와 연결할 IAM 역할을 지정합니다. 그러면 이 인스턴스에서 실행되는 애플리케이션은 역할 제공 임시 자격 증명을 사용하여 API 요청에 서명할 수 있습니다.

역할을 사용하여 Amazon EC2 인스턴스에서 실행되는 애플리케이션에 권한을 부여하기 위해서는 약간의 추가적인 구성이 필요합니다. Amazon EC2 인스턴스에서 실행되는 애플리케이션은 가상화된 운영 체제에 의해 AWS에서 추상화됩니다. 이러한 추가적인 분리로 인해 Amazon EC2 인스턴스에 AWS 역할 및 관련 권한을 할당하고 이를 그 애플리케이션도 사용 가능하게 만들려면 추가 절차가 필요합니다. 여기서 추가 절차란 인스턴스에 연결된 *[인스턴스 프로파일](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2_instance-profiles.html)*을 생성하는 것입니다. 그러면 인스턴스 프로필은 해당 역할을 포함하게 되며 인스턴스에서 실행되는 애플리케이션에 이 역할의 임시 자격 증명을 제공할 수 있습니다. 이 임시 자격 증명은 애플리케이션의 API 호출에 사용되어 리소스에 액세스하고 이 역할이 지정하는 리소스에 대해서만 액세스를 제한할 수 있습니다.

**참고**  
한 번에 하나의 역할만 Amazon EC2 인스턴스에 할당할 수 있으며, 인스턴스의 모든 애플리케이션은 동일한 역할과 권한을 공유한다는 점에 유의하세요. Amazon ECS를 활용하여 Amazon EC2 인스턴스를 관리하는 경우 실행 중인 Amazon EC2 인스턴스의 역할과 구별되는 역할을 Amazon ECS 작업에 할당할 수 있습니다. 각 작업에 역할을 할당하면 최소 권한 액세스 원칙에 부합하며, 작업과 리소스를 보다 정밀하게 제어할 수 있습니다.  
자세한 내용은 *Amazon Elastic Container Service 모범 사례 가이드*의 [Amazon ECS 작업에 IAM 역할 사용](https://docs.aws.amazon.com/AmazonECS/latest/bestpracticesguide/security-iam-roles.html)을 참조하세요.

이러한 방식으로 역할을 사용하면 여러 가지 장점이 있습니다. 역할 보안 인증은 임시 정보이며 자동으로 업데이트되므로 보안 인증을 관리하지 않아도 될 뿐만 아니라 장기적인 보안 위험을 염려하지 않아도 됩니다. 또한, 여러 인스턴스에 대해 역할을 하나만 사용하는 경우 그 역할을 변경할 수 있는데, 변경 사항은 모든 인스턴스에 자동으로 전파됩니다.

**참고**  
일반적으로 역할은 Amazon EC2 인스턴스를 시작할 때 할당되지만, 현재 실행 중인 Amazon EC2 인스턴스에도 연결될 수 있습니다. 실행 중인 인스턴스에 역할을 연결하는 방법을 알아보려면 [Amazon EC2의 IAM 역할](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role) 섹션을 참조하세요.

**Topics**
+ [

## Amazon EC2 인스턴스의 역할은 어떻게 작동하나요?
](#roles-usingrole-ec2instance-roles)
+ [

## Amazon EC2로 역할을 사용하는 데 필요한 권한
](#roles-usingrole-ec2instance-permissions)
+ [

## 어떻게 시작할 수 있습니까?
](#roles-usingrole-ec2instance-get-started)
+ [

## 관련 정보
](#roles-usingrole-ec2instance-related-info)

## Amazon EC2 인스턴스의 역할은 어떻게 작동하나요?
<a name="roles-usingrole-ec2instance-roles"></a>

다음 그림에서는 개발자가 `amzn-s3-demo-bucket-photos`라는 S3 버킷에 대한 액세스 권한이 필요한 Amazon EC2 인스턴스에서 애플리케이션을 실행하고 있습니다. 관리자가 `Get-pics` 서비스 역할을 생성해 Amazon EC2 인스턴스에 연결합니다. 이 역할에는 지정된 S3 버킷에 대한 읽기 전용 액세스 권한을 부여하는 권한 정책이 포함되어 있습니다. 또한 Amazon EC2 인스턴스가 해당 역할을 수임하고 임시 보안 인증 정보를 가져오도록 허용하는 신뢰 정책도 포함되어 있습니다. 애플리케이션이 인스턴스에서 실행되면 역할의 임시 자격 증명을 사용하여 photos 버킷에 액세스할 수 있습니다. 관리자는 개발자 권한을 부여하지 않아도 photos 버킷에 액세스할 수 있고 개발자는 자격 증명을 공유하거나 관리할 필요가 전혀 없습니다.

![\[AWS 리소스에 액세스하는 Amazon EC2 인스턴스의 애플리케이션\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/roles-usingrole-ec2roleinstance.png)


1. 관리자가 IAM을 사용하여 **Get-pics** 역할을 생성합니다. 역할의 신뢰 정책에서 관리자는 Amazon EC2 인스턴스만이 역할을 맡을 수 있도록 지정합니다. 역할의 권한 정책에서 관리자는 `amzn-s3-demo-bucket-photos` 버킷에 읽기 전용 권한을 지정합니다.

1. 개발자는 Amazon EC2 인스턴스를 시작하고 이 인스턴스에 `Get-pics` 역할을 할당합니다.
**참고**  
IAM 콘솔을 사용하는 경우, 인스턴스 프로파일은 콘솔에서 관리하고 대개 사용자가 파악하기 쉽습니다. 그러나 AWS CLI 또는 API를 사용하여 역할 및 Amazon EC2 인스턴스를 만들고 관리하는 경우 사용자는 인스턴스 프로파일을 만들고 별도 절차에 따라 여기에 역할을 할당해야 합니다. 그런 다음 인스턴스를 시작할 때 역할 이름이 아닌 인스턴스 프로파일 이름을 지정해야 합니다.

1. 애플리케이션이 실행되면 [인스턴스 메타데이터에서 보안 자격 증명 검색](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#instance-metadata-security-credentials)에 설명된 대로 Amazon EC2 [인스턴스 메타데이터](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)에서 임시 보안 자격 증명을 가져옵니다. 이러한 자격 증명은 제한된 시간 동안에만 유효한 [임시 보안 자격 증명](id_credentials_temp.md)으로 역할을 나타냅니다.

   개발자는 몇몇 [AWS SDK](https://aws.amazon.com/tools/)를 사용하여 임시 보안 자격 증명을 투명하게 관리하는 공급자를 사용할 수 있습니다. (자격 증명 관리를 위해 해당 SDK가 지원하는 기능에 대한 설명은 각각의 AWS SDK 설명서를 참조하세요.)

   또는 애플리케이션이 Amazon EC2 인스턴스의 인스턴스 메타데이터에서 임시 보안 인증 정보를 가져올 수 있습니다. 자격 증명과 관련 값은 메타데이터의 `iam/security-credentials/role-name` 범주(이 경우 `iam/security-credentials/Get-pics`)에서 구할 수 있습니다. 애플리케이션이 인스턴스 메타데이터에서 자격 증명을 가져오면 자격 증명을 캐시할 수 있습니다.

1. 애플리케이션은 가져온 임시 자격 증명을 사용하여 photo 버킷에 액세스합니다. **Get-pics** 역할에 연결된 정책으로 인해 이 애플리케이션에는 읽기 전용 권한만 있습니다.

   인스턴스에서 사용 가능한 임시 보안 인증은 만료되기 전에 자동으로 업데이트되므로 항상 유효한 설정을 사용할 수 있습니다. 애플리케이션은 현재 자격 증명이 만료되기 전에 인스턴스 메타데이터에서 새 자격 증명을 가져와야 합니다. AWS SDK를 사용해 자격 증명을 관리하도록 함으로써 애플리케이션이 자격 증명을 새로 고치기 위해 추가적인 로직을 포함할 필요가 없게 할 수도 있습니다. 예를 들어 클라이언트를 인스턴스 프로필 자격 증명 공급자로 인스턴스화하면 됩니다. 그러나 애플리케이션이 인스턴스 메타데이터에서 임시 보안 자격 증명을 가져와 캐시한 경우, 현재 자격 증명이 만료되기 전에 한 시간 또는 최소 15분마다 갱신한 자격 증명을 가져와야 합니다. 만료 시간은 `iam/security-credentials/role-name` 카테고리에 반환되는 정보에 포함되어 있습니다.

## Amazon EC2로 역할을 사용하는 데 필요한 권한
<a name="roles-usingrole-ec2instance-permissions"></a>

역할을 사용하여 인스턴스를 시작하려면 개발자에게 Amazon EC2 인스턴스를 시작할 수 있는 권한과 IAM 역할을 전달할 수 있는 권한이 있어야 합니다.

다음과 같은 샘플 정책은 사용자가 AWS Management Console을 사용하여 역할로 인스턴스를 시작할 수 있도록 허용합니다. 정책에 와일드카드(`*`)가 포함되어 있어 사용자가 어떤 역할이든 전달하고 나열된 Amazon EC2 작업을 수행할 수 있도록 허용합니다. `ListInstanceProfiles` 작업을 수행하면 사용자는 AWS 계정에서 제공되는 모든 역할을 볼 수 있습니다.

**Example 사용자에게 Amazon EC2 콘솔을 사용하여 임의의 역할로 인스턴스를 시작할 권한을 부여하는 정책 예**    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "IamPassRole",
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:PassedToService": "ec2.amazonaws.com"
                }
            }
        },
        {
            "Sid": "ListEc2AndListInstanceProfiles",
            "Effect": "Allow",
            "Action": [
                "iam:ListInstanceProfiles",
                "ec2:Describe*",
                "ec2:Search*",
                "ec2:Get*"
            ],
            "Resource": "*"
        }
    ]
}
```

### Amazon EC2 인스턴스로 전달할 수 있는 역할 제한(PassRole 사용)
<a name="roles-usingrole-ec2instance-passrole"></a>

`PassRole` 권한을 사용하여 사용자가 Amazon EC2 인스턴스를 시작할 때 이 인스턴스에 전달할 수 있는 역할을 제한할 수 있습니다. 이를 통해 사용자가 자신이 받은 권한보다 더 많은 권한이 있는 애플리케이션을 실행하지 않도록, 즉 높은 권한을 가져오지 않도록 할 수 있습니다. 예를 들어 사용자 Alice는 Amazon EC2 인스턴스를 시작하고 Amazon S3 버킷을 사용할 권한만 있지만, 그녀가 Amazon EC2 인스턴스에 전달하는 역할에는 IAM 및 Amazon DynamoDB를 사용할 권한이 있다고 가정합니다. 이 경우 Alice는 인스턴스를 시작하고 여기에 로그인하여 임시 보안 자격 증명을 가져온 다음 그녀에게 권한이 없는 IAM 또는 DynamoDB 작업을 수행할 수도 있습니다.

사용자가 Amazon EC2 인스턴스에 전달할 수 있는 역할 중 어떤 것을 제한하려면 `PassRole` 작업을 허용하는 정책을 생성합니다. 그런 다음 그 정책을 Amazon EC2 인스턴스를 시작할 사용자(또는 사용자가 속한 IAM 그룹)에게 연결합니다. 이 정책의 `Resource` 요소에서 사용자가 Amazon EC2 인스턴스에 전달할 수 있는 역할을 나열합니다. 사용자가 인스턴스를 시작하고 역할을 인스턴스에 연결하면 Amazon EC2에서 사용자가 해당 역할을 전달할 수 있는지 확인합니다. 물론 사용자가 전달할 수 있는 역할에 사용자가 보유하고 있을 것으로 추정되는 권한보다 더 많은 권한이 포함되어 있지 않은지도 확인해야 합니다.

**참고**  
`PassRole`은 `RunInstances` 또는 `ListInstanceProfiles`와 동일한 방식의 API 작업이 아닙니다. 역할 ARN이 API에 대한 파라미터로 전달될 때마다 AWS에서 검사하는 권한입니다(또는 사용자 대신 콘솔이 이 기능을 수행). 관리자가 어느 사용자가 어느 역할을 전달할 수 있는지를 제어할 수 있습니다. 이 경우 사용자가 Amazon EC2 인스턴스에 특정 역할을 연결할 수 있습니다.

**Example 사용자에게 특정 역할로 Amazon EC2 인스턴스를 시작할 권한을 부여하는 정책의 예**  
다음과 같은 샘플 정책은 사용자가 Amazon EC2 API를 사용하여 역할로 인스턴스를 시작할 수 있도록 허용합니다. `Resource` 요소는 역할의 Amazon 리소스 이름(ARN)을 지정합니다. ARN을 지정함으로써 정책은 사용자에게 `Get-pics` 역할만을 전달할 권한을 부여합니다. 사용자가 인스턴스를 시작할 때 다른 역할을 지정하려는 경우 작업이 실패합니다. 사용자는 역할을 전달하는지와 관계없이 모든 인스턴스를 실행할 권한이 있습니다.    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "ec2:RunInstances",
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "iam:PassRole",
            "Resource": "arn:aws:iam::111122223333:role/Get-pics"
        }
    ]
}
```

### 인스턴스 프로파일 역할이 다른 계정의 역할로 전환하도록 허용
<a name="switch-role-ec2-another-account"></a>

Amazon EC2 인스턴스에서 실행 중인 애플리케이션에서 다른 계정에 있는 명령을 실행하도록 허용할 수 있습니다. 이를 위해 첫 번째 계정에 있는 Amazon EC2 인스턴스 역할이 두 번째 계정의 역할로 전환하도록 허용해야 합니다.

두 개의 AWS 계정을 사용 중이고 Amazon EC2 인스턴스에서 실행 중인 특정 애플리케이션이 두 계정 모두에서 [AWS CLI](https://aws.amazon.com/cli/) 명령을 실행하도록 허용하고자 한다고 가정합니다. Amazon EC2 인스턴스가 `111111111111` 계정에 존재한다고 가정합니다. 해당 인스턴스에는 애플리케이션이 동일한 `111111111111` 계정 내에 있는 `amzn-s3-demo-bucket1` 버킷에서 읽기 전용 Amazon S3 작업을 수행하도록 허용하는 `abcd` 인스턴스 프로파일 역할이 포함되어 있습니다. 하지만 애플리케이션은 `efgh` 크로스 계정 역할을 수임하여 `222222222222` 계정의 `amzn-s3-demo-bucket2` Amazon S3 버킷에 액세스하도록 허용되어야 합니다.

![\[다이어그램은 개발자가 Amazon S3 버킷의 사진에 액세스할 수 있는 역할로 Amazon EC2 인스턴스를 시작하는 방법을 보여줍니다.\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/roles-instance-profile-cross-account.png)


애플리케이션이 `abcd` Amazon S3 버킷에 액세스하도록 허용하려면 `amzn-s3-demo-bucket1` Amazon EC2 인스턴스 프로파일 역할에 다음과 같은 권한 정책이 있어야 합니다.

***계정 111111111111 `abcd` 역할 권한 정책***

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowAccountLevelS3Actions",
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAccessPoints",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Sid": "AllowListAndReadS3ActionOnMyBucket",
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket1/*",
                "arn:aws:s3:::amzn-s3-demo-bucket1"
            ]
        },
        {
            "Sid": "AllowIPToAssumeCrossAccountRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "arn:aws:iam::222222222222:role/efgh"
        }
    ]
}
```

------

`abcd` 역할은 Amazon EC2 서비스가 역할을 수임하도록 신뢰해야 합니다. 이를 위해 `abcd` 역할에 다음과 같은 신뢰 정책이 있어야 합니다.

***계정 111111111111 `abcd` 역할 신뢰 정책***

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "abcdTrustPolicy",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Principal": {"Service": "ec2.amazonaws.com"}
        }
    ]
}
```

------

`efgh` 크로스 계정 역할이 동일한 `222222222222` 계정 내에 있는 `amzn-s3-demo-bucket2` 버킷에서 읽기 전용 Amazon S3 작업을 수행할 수 있다고 가정합니다. 이를 위해 `efgh` 크로스 계정 역할에 다음과 같은 권한 정책이 있어야 합니다.

***계정 222222222222 `efgh` 역할 권한 정책***

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowAccountLevelS3Actions",
            "Effect": "Allow",
            "Action": [
                "s3:GetBucketLocation",
                "s3:GetAccountPublicAccessBlock",
                "s3:ListAccessPoints",
                "s3:ListAllMyBuckets"
            ],
            "Resource": "arn:aws:s3:::*"
        },
        {
            "Sid": "AllowListAndReadS3ActionOnMyBucket",
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": [
                "arn:aws:s3:::amzn-s3-demo-bucket2/*",
                "arn:aws:s3:::amzn-s3-demo-bucket2"
            ]
        }
    ]
}
```

------

`efgh` 역할은 `abcd` 인스턴스 프로파일 역할이 이를 수임하도록 신뢰해야 합니다. 이를 위해 `efgh` 역할에 다음과 같은 신뢰 정책이 있어야 합니다.

***계정 222222222222 `efgh` 역할 신뢰 정책***

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "efghTrustPolicy",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Principal": {"AWS": "arn:aws:iam::111111111111:role/abcd"}
        }
    ]
}
```

------

## 어떻게 시작할 수 있습니까?
<a name="roles-usingrole-ec2instance-get-started"></a>

역할이 Amazon EC2 인스턴스와 연동하는 방식을 이해하려면 IAM 콘솔을 사용하여 역할을 만들고 해당 역할을 사용하는 Amazon EC2 인스턴스를 시작한 다음에 실행 중인 인스턴스를 검사해야 합니다. 해당 역할의 임시 자격 증명이 인스턴스에서 사용되는 방식을 보기 위해 [인스턴스 메타데이터](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)를 검토할 수 있습니다. 또한, 인스턴스에서 실행되는 애플리케이션이 어떻게 역할을 사용하는지도 알 수 있습니다. 다음 리소스에서 자세히 알아보세요.
+ [Amazon EC2 인스턴스의 IAM 역할 자습서](https://www.youtube.com/watch?v=TlCuOjviOhk). 링크된 다음 동영상에서는 Amazon EC2 인스턴스로 IAM 역할을 사용하여 애플리케이션이 이 인스턴스에서 실행될 때 수행할 수 있는 작업을 제어하는 방법을 보여줍니다. 또한 이 애플리케이션(AWS SDK로 작성)이 역할을 통해 임시 보안 자격 증명을 가져오는 방법도 보여줍니다.
+ SDK 설명입니다. AWS SDK 설명서에 Amazon S3 버킷을 읽기 위해 역할에 임시 자격 증명을 사용하는 Amazon EC2 인스턴스에서 실행되는 애플리케이션을 보여주는 자세한 안내가 포함되어 있습니다. 다음과 같은 각 설명에서는 여러 프로그래밍 언어를 사용하여 비슷한 절차를 제시합니다.
  + *AWS SDK for Java 개발자 안내서*의 [SDK for Java를 사용하여 Amazon EC2용 IAM 역할 구성](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java-dg-roles.html) 
  + [AWS SDK for .NET 개발자 안내서](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/run-instance.html)의 *SDK for .NET을 사용하여 Amazon EC2 인스턴스 시작*
  + *AWS SDK for Ruby 개발자 안내서*의 [SDK for Ruby를 사용하여 Amazon EC2 인스턴스 생성](https://docs.aws.amazon.com/sdk-for-ruby/latest/developer-guide/ec2-example-create-instance.html)

## 관련 정보
<a name="roles-usingrole-ec2instance-related-info"></a>

역할 생성 및 Amazon EC2 인스턴스의 역할에 대한 자세한 내용은 다음 정보를 참조하세요.
+ [Amazon EC2 인스턴스에 IAM 역할을 사용](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html)하는 방법에 대한 자세한 내용은 *Amazon EC2 사용 설명서*를 참조하세요.
+ 역할을 만들려면 [IAM 역할 생성](id_roles_create.md) 섹션을 참조하세요.
+ 임시 보안 자격 증명의 사용에 관한 자세한 내용은 [IAM의 임시 보안 자격 증명](id_credentials_temp.md)을 확인하세요.
+ IAM API 또는 CLI를 사용하는 경우, IAM 인스턴스 프로파일을 생성 및 관리해야 합니다. 인스턴스 프로파일에 대한 자세한 내용은 섹션을 참조하세요[인스턴스 프로파일 사용](id_roles_use_switch-role-ec2_instance-profiles.md)
+ 인스턴스 메타데이터의 역할을 위한 임시 보안 자격 증명에 대한 자세한 내용은 *Amazon EC2 사용 설명서*의 [인스턴스 메타데이터에서 보안 자격 증명 검색](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#instance-metadata-security-credentials)을 참조하세요.

# 인스턴스 프로파일 사용
<a name="id_roles_use_switch-role-ec2_instance-profiles"></a>

인스턴스 프로파일을 사용하여 EC2 인스턴스에 IAM 역할을 전달합니다. 자세한 내용은 *Amazon EC2 사용 설명서*의 [Amazon EC2의 IAM 역할](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html)을 참조하세요.

## 인스턴스 프로파일 관리(콘솔)
<a name="instance-profiles-manage-console"></a>

AWS Management Console을 사용하여 Amazon EC2 역할을 생성하는 경우, 콘솔이 자동으로 인스턴스 프로파일을 생성하여 해당 역할과 동일한 이름을 부여합니다. 그런 다음 Amazon EC2 콘솔을 사용하여 IAM 역할로 인스턴스를 실행할 때는 인스턴스와 연결할 역할을 선택할 수 있습니다. 콘솔에 표시되는 목록이 실제로 인스턴스 프로파일 이름의 목록입니다. 콘솔은 Amazon EC2와 연결되지 않은 역할의 인스턴스 프로파일은 생성하지 않습니다.

역할과 인스턴스 프로파일의 이름이 같으면 AWS Management Console을 사용하여 Amazon EC2의 IAM 역할 및 인스턴스 프로파일을 삭제할 수 있습니다. 인스턴스 프로파일 삭제에 대한 자세한 내용은 [역할 또는 인스턴스 프로파일 삭제](id_roles_manage_delete.md) 섹션을 참조하세요.

**참고**  
인스턴스에 대한 권한을 업데이트하려면 해당 인스턴스 프로파일을 교체합니다. 이 변경 사항이 적용되기까지 최대 1시간이 지연되므로 인스턴스 프로파일에서 역할을 제거하는 것은 권장되지 않습니다.

## 인스턴스 프로파일 관리(AWS CLI 또는 AWS API)
<a name="instance-profiles-manage-cli-api"></a>

AWS CLI 또는 AWS API에서 역할을 관리할 경우 별도의 작업으로 역할 및 인스턴스 프로파일을 생성합니다. 역할 및 인스턴스 프로파일의 이름이 서로 다를 수 있으므로 인스턴스 프로파일 이름은 물론이고 프로파일이 속하는 역할 이름까지 알고 있어야 합니다. 그러면 EC2 인스턴스를 시작할 때 올바른 인스턴스 프로파일을 선택할 수 있습니다.

인스턴스 프로파일을 비롯한 IAM 리소스에 태그를 연결하여 해당 리소스에 대한 액세스를 식별, 구성 및 제어할 수 있습니다. AWS CLI 또는 AWS API를 사용하는 경우에만 인스턴스 프로파일을 태깅할 수 있습니다.

**참고**  
하나의 인스턴스 프로파일은 하나의 IAM 역할만 포함할 수 있습니다. 하지만 한 역할이 여러 인스턴스 프로파일에 포함될 수 있습니다. 이 인스턴스 프로파일당 역할 1개 제한은 늘릴 수 없습니다. 기존 역할을 제거하고 나서 인스턴스 프로파일에 다른 역할을 추가할 수 있습니다. [최종 일관성](https://en.wikipedia.org/wiki/Eventual_consistency)으로 인해 모든 AWS에 변경 사항이 적용될 때까지 기다려야 합니다. 변경을 적용하려면 [인스턴스 프로파일 연결을 해제](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DisassociateIamInstanceProfile.html)하고 나서 [인스턴스 프로파일을 연결하거나](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AssociateIamInstanceProfile.html), 인스턴스를 중지했다가 다시 시작합니다.

### 인스턴스 프로파일 관리(AWS CLI)
<a name="instance-profiles-manage-cli"></a>

AWS 계정의 인스턴스 프로파일 작업을 할 때는 다음 AWS CLI 명령을 사용할 수 있습니다.
+ 인스턴스 프로파일을 생성합니다: [https://docs.aws.amazon.com/cli/latest/reference/iam/create-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/create-instance-profile.html)
+ 인스턴스 프로파일 태깅: [https://docs.aws.amazon.com/cli/latest/reference/iam/tag-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-instance-profile.html)
+ 인스턴스 프로파일의 태그 나열: [https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profile-tags.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profile-tags.html)
+ 인스턴스 프로파일 태깅 해제: [https://docs.aws.amazon.com/cli/latest/reference/iam/untag-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-instance-profile.html)
+ 인스턴스 프로파일에 역할 추가: [https://docs.aws.amazon.com/cli/latest/reference/iam/add-role-to-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/add-role-to-instance-profile.html) 
+ 인스턴스 프로파일 표시: [https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profiles.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profiles.html), [https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profiles-for-role.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profiles-for-role.html) 
+ 인스턴스 프로파일 정보 가져오기: [https://docs.aws.amazon.com/cli/latest/reference/iam/get-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-instance-profile.html) 
+ 인스턴스 프로파일에서 역할 제거: [https://docs.aws.amazon.com/cli/latest/reference/iam/remove-role-from-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/remove-role-from-instance-profile.html)
+ 인스턴스 프로파일 삭제: [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-instance-profile.html) 

다음 명령을 사용하여 이미 실행 중인 EC2 인스턴스에 역할을 연결할 수도 있습니다. 자세한 내용은 [Amazon EC2의 IAM 역할](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role)을 참조하세요.
+ 역할이 있는 인스턴스 프로파일을 중지되었거나 실행 중인 EC2 인스턴스에 연결: [https://docs.aws.amazon.com/cli/latest/reference/ec2/associate-iam-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/associate-iam-instance-profile.html) 
+ EC2 인스턴스에 연결된 인스턴스 프로파일에 대한 정보 가져오기: [https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-iam-instance-profile-associations.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-iam-instance-profile-associations.html) 
+ 역할이 있는 인스턴스 프로파일을 중지되었거나 실행 중인 EC2 인스턴스에서 분리: [https://docs.aws.amazon.com/cli/latest/reference/ec2/disassociate-iam-instance-profile.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/disassociate-iam-instance-profile.html) 

### 인스턴스 프로파일 관리(AWS API)
<a name="instance-profiles-manage-api"></a>

AWS 계정의 인스턴스 프로파일 작업을 할 때는 다음 AWS API 연산을 호출할 수 있습니다.
+ 인스턴스 프로파일을 생성합니다: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateInstanceProfile.html) 
+ 인스턴스 프로파일 태깅: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html) 
+ 인스턴스 프로필의 태그 나열: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html) 
+ 인스턴스 프로파일 태깅 해제: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html) 
+ 인스턴스 프로파일에 역할 추가: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddRoleToInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddRoleToInstanceProfile.html) 
+ 인스턴스 프로파일 표시: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListInstanceProfiles.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListInstanceProfiles.html), [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListInstanceProfilesForRole.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListInstanceProfilesForRole.html) 
+ 인스턴스 프로파일 정보 가져오기: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetInstanceProfile.html) 
+ 인스턴스 프로파일에서 역할 제거: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_RemoveRoleFromInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_RemoveRoleFromInstanceProfile.html) 
+ 인스턴스 프로파일 삭제: [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteInstanceProfile.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteInstanceProfile.html) 

다음 연산을 호출하여 이미 실행 중인 EC2 인스턴스에 역할을 연결할 수도 있습니다. 자세한 내용은 [Amazon EC2의 IAM 역할](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role)을 참조하세요.
+ 역할이 있는 인스턴스 프로파일을 중지되었거나 실행 중인 EC2 인스턴스에 연결: [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AssociateIamInstanceProfile.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AssociateIamInstanceProfile.html) 
+ EC2 인스턴스에 연결된 인스턴스 프로파일에 대한 정보 가져오기: [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeIamInstanceProfileAssociations.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeIamInstanceProfileAssociations.html) 
+ 역할이 있는 인스턴스 프로파일을 중지되었거나 실행 중인 EC2 인스턴스에서 분리: [https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DisassociateIamInstanceProfile.html](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DisassociateIamInstanceProfile.html) 

# ID 공급자 및 AWS로의 페더레이션
<a name="id_roles_providers"></a>

가장 좋은 방법은 AWS 계정에서 개별 IAM 사용자를 생성하는 대신 인간 사용자가 ID 제공업체와의 페더레이션을 사용하여 AWS 리소스에 액세스하는 것입니다. 자격 증명 공급자(IdP)를 사용하면 AWS 외부의 사용자 자격 증명을 관리할 수 있고 이 외부 사용자 자격 증명에 계정의 AWS 리소스에 대한 사용 권한을 부여할 수 있습니다. 기업 사용자 디렉터리처럼 조직 내에 이미 고유의 자격 증명 시스템이 있다면 이 방법이 유용합니다. 그 밖에 AWS 리소스에 액세스해야 하는 모바일 앱이나 웹 애플리케이션을 개발할 때도 효과적입니다.

**참고**  
IAM에서 SAML 페더레이션을 사용하는 대신 외부 SAML ID 제공업체를 사용하여 [IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/what-is.html)에서 사용자 액세스를 관리할 수 있습니다. ID 제공업체와 IAM Identity Center 페더레이션을 통해 조직의 여러 AWS 계정과 여러 AWS 애플리케이션에 대한 액세스를 제공할 수 있습니다. IAM 사용자가 필요한 특정 상황에 대한 자세한 내용은 [IAM 사용자(역할이 아님)를 생성해야 하는 경우](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose)를 참조하세요.

IAM Identity Center를 활성화하지 않고 단일 AWS 계정을 사용하려는 경우 [OpenID Connect(OIDC)](http://openid.net/connect/) 또는 [SAML 2.0(Security Assertion Markup Language 2.0)](https://wiki.oasis-open.org/security)을 사용하여 ID 정보를 AWS에 제공하는 외부 IdP와 IAM을 함께 사용할 수 있습니다. OIDC는 AWS에서 실행되지 않는 GitHub Actions와 같은 애플리케이션을 AWS 리소스에 연결합니다. 잘 알려진 SAML ID 제공업체의 예로는 Shibboleth 및 Active Directory Federation Services가 있습니다.

자격 증명 공급자를 사용하면 사용자 지정 로그인 코드를 생성할 필요도, 그리고 자신의 사용자 자격 증명을 관리할 필요도 없습니다. IdP에서 이러한 작업을 대신 수행합니다. 외부 사용자는 IdP를 통해 로그인하고, 이러한 외부 자격 증명에 계정의 AWS 리소스를 사용할 권한을 제공할 수 있습니다. ID 제공업체를 사용하면 애플리케이션에서 사용자 액세스 키 같은 장기 보안 인증을 배포하거나 포함할 필요가 없으므로 AWS 계정을 안전하게 보호할 수 있습니다.

다음 표를 검토하면 IAM, IAM Identity Center 또는 Amazon Cognito 중에서 사용 사례에 가장 적합한 IAM 페더레이션 유형이 무엇인지 파악하는 데 도움이 됩니다. 다음 요약 및 표는 사용자가 AWS 리소스에 대한 페더레이션 액세스를 얻기 위해 사용할 수 있는 방법에 대한 개요를 제공합니다.


| IAM 페더레이션 유형 | 계정 유형 | 액세스 관리.. | 지원되는 ID 소스 | 
| --- | --- | --- | --- | 
|  IAM Identity Center와의 페더레이션  |  AWS Organizations에서 관리하는 여러 계정  |  인력의 인간 사용자  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_roles_providers.html)  | 
|  IAM과의 페더레이션  |  단일, 독립 실행형 계정  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_roles_providers.html)  | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_roles_providers.html)  | 
|  Amazon Cognito 자격 증명 풀과의 페더레이션  |  임의  |  리소스에 액세스하기 위해 IAM 인증이 필요한 앱 사용자  | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_roles_providers.html)  | 

## IAM Identity Center와의 페더레이션
<a name="id_roles_providers_identity-center"></a>

인간 사용자의 중앙 액세스 관리를 위해 [IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)를 사용하여 계정에 대한 액세스 권한과 해당 계정 내 권한을 관리하는 것이 좋습니다. IAM Identity Center의 사용자에게는 AWS 리소스에 대한 단기 보안 인증이 부여됩니다. Active Directory, 외부 IdP(ID 제공업체) 또는 IAM Identity Center 디렉터리를 사용자 및 그룹의 ID 소스로 사용하여 AWS 리소스에 대한 액세스 권한을 할당할 수 있습니다.

IAM Identity Center는 SAML(Security Assertion Markup Language) 2.0과의 ID 페더레이션을 지원하여 AWS 액세스 포털 내에서 애플리케이션을 사용할 권한이 있는 사용자에게 페더레이션된 Single Sign-On 액세스를 제공합니다. 이후 사용자는 Microsoft 365, SAP Concur, Salesforce와 같은 AWS Management Console 및 타사 애플리케이션을 포함하여 SAML을 지원하는 서비스에 Single Sign-On을 할 수 있습니다.

## IAM과의 페더레이션
<a name="id_roles_providers_iam"></a>

IAM Identity Center에서 인간 사용자를 관리하는 것이 좋지만, 단기간의 소규모 배포에서는 인간 사용자를 위해 IAM과의 페더레이션 보안 주체 액세스를 활성화할 수 있습니다. IAM을 사용하면 별도의 SAML 2.0 및 OIDC(Open ID Connect) IdP를 사용하고 페더레이션 보안 주체 속성을 액세스 제어에 사용할 수 있습니다. IAM을 사용하면 IDP에서 AWS로 비용 센터, 제목 또는 로케일과 같은 사용자 속성을 전달하고, 이러한 속성을 기반으로 세분화된 액세스 권한을 구현할 수 있습니다.

*워크로드*란 애플리케이션이나 백엔드 프로세스같이 비즈니스 가치를 창출하는 리소스 및 코드 모음을 말합니다. 워크로드에서 AWS 서비스, 애플리케이션, 운영 도구 및 구성 요소에 요청을 보내려면 IAM ID가 필요할 수 있습니다. 이러한 자격 증명에는 AWS 환경에서 실행되는 컴퓨터가 포함됩니다(예: Amazon EC2 인스턴스 또는 AWS Lambda 함수).

또한 액세스 권한이 필요한 외부 당사자를 위해 시스템 자격 증명을 관리할 수도 있습니다. 시스템 자격 증명에 대한 액세스 권한을 부여하기 위해 IAM 역할을 사용할 수 있습니다. IAM 역할에는 특정 권한이 있으며 역할 세션과 함께 임시 보안 인증을 사용하여 AWS에 대한 액세스 방법을 제공합니다. 또한 AWS 외부에 AWS 환경에 대한 액세스 권한이 필요한 시스템이 있을 수 있습니다. AWS 외부에서 실행되는 시스템의 경우 [IAM Roles Anywhere](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)를 사용할 수 있습니다. 역할에 대한 자세한 내용은 [IAM 역할](id_roles.md) 섹션을 참조하세요. 역할을 사용하여 AWS 계정 전체에서 액세스 권한을 위임하는 방법에 대한 자세한 내용은 [튜토리얼: IAM 역할을 사용한 AWS 계정 간 액세스 권한 위임](tutorial_cross-account-with-roles.md)을(를) 참조하세요.

IdP를 IAM과 직접 연결하려면 ID 제공업체 엔터티를 생성하여 AWS 계정과 IdP 간에 신뢰 관계를 설정합니다. IAM은 [OpenID Connect(OIDC)](http://openid.net/connect/) 또는 [SAML 2.0(Security Assertion Markup Language 2.0)](https://wiki.oasis-open.org/security)과 호환되는 IdP를 지원합니다. AWS에서 해당 IdP 중 하나를 사용하는 것에 대한 자세한 정보는 다음을 참조하세요.
+ [OIDC 페더레이션](id_roles_providers_oidc.md)
+ [SAML 2.0 연동](id_roles_providers_saml.md)

## Amazon Cognito 자격 증명 풀과의 페더레이션
<a name="id_roles_providers_cognito"></a>

Amazon Cognito는 모바일 및 웹 앱에서 사용자를 인증하고 권한을 부여하고자 하는 개발자를 위해 설계되었습니다. Amazon Cognito 사용자 풀은 앱에 로그인 및 가입 기능을 추가하고, 자격 증명 풀은 AWS에서 관리하는 보호되는 리소스에 대한 액세스 권한을 사용자에게 부여하는 IAM 보안 인증 정보를 제공합니다. 자격 증명 풀은 [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) API 작업을 통해 임시 세션의 보안 인증 정보를 획득합니다.

Amazon Cognito는 SAML 및 OpenID Connect를 지원하는 외부 ID 제공업체, 그리고 Facebook, Google 및 Amazon과 소셜 ID 제공업체와 협력합니다. 앱은 사용자 풀 또는 외부 IdP로 사용자를 로그인한 다음, IAM 역할의 사용자 지정 임시 세션을 통해 리소스를 대신 검색할 수 있습니다.

## 추가 리소스
<a name="id_roles_providers_additional_resources"></a>
+ 조직의 인증 시스템을 사용하여 AWS Management Console로 Single Sign-On(SSO)을 활성화하는 사용자 지정 페더레이션 프록시를 생성하는 방법에 대한 데모를 보려면 [AWS 콘솔에 대한 사용자 지정 ID 브로커 액세스 활성화](id_roles_providers_enable-console-custom-url.md) 단원을 참조하세요.

# 일반적인 시나리오
<a name="id_federation_common_scenarios"></a>

**참고**  
인간 사용자가 AWS에 액세스할 때 임시 보안 인증을 사용하도록 하는 것이 좋습니다. AWS IAM Identity Center 사용을 고려해 보셨나요? IAM Identity Center를 사용하여 여러 AWS 계정에 대한 액세스를 중앙에서 관리하고 사용자에게 한 곳에서 할당된 모든 계정에 대한 MFA 보호 Single Sign-On 액세스를 제공할 수 있습니다. IAM Identity Center를 사용하면 IAM Identity Center에서 사용자 자격 증명을 생성하고 관리하거나 기존 SAML 2.0 호환 자격 증명 제공업체에 쉽게 연결할 수 있습니다. 자세한 정보는 *AWS IAM Identity Center 사용 설명서*의 [IAM Identity Center란 무엇인가요?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) 섹션을 참조하세요.

외부 ID 제공업체(IdP)를 사용하여 AWS 외부 및 외부 IdP에서 사용자 ID를 관리할 수 있습니다. 외부 IdP는 OpenID Connect(OIDC) 또는 Security Assertion Markup Language(SAML)을 사용하여 AWS에 ID 정보를 제공할 수 있습니다. OIDC는 일반적으로 AWS에서 실행되지 않는 애플리케이션이 AWS 리소스에 액세스해야 할 때 사용됩니다.

외부 idP와의 페더레이션을 구성하려는 경우 IAM *ID 제공업체*를 생성하여 외부 IdP 및 구성에 대해 AWS에 알려줍니다. 이를 통해 AWS 계정과 외부 IdP 사이에 신뢰가 구축됩니다. 다음 항목에서는 IAM ID 공급자를 사용하는 일반적인 시나리오를 제공합니다.

**Topics**
+ [

## 모바일 앱용 Amazon Cognito
](#id_roles_providers_oidc_cognito)
+ [

## 모바일 앱용 OIDC 페더레이션
](#id_roles_providers_oidc_manual)

## 모바일 앱용 Amazon Cognito
<a name="id_roles_providers_oidc_cognito"></a>

OIDC 페더레이션을 사용하는 기본 방법은 [Amazon Cognito](https://aws.amazon.com/cognito/)를 사용하는 것입니다. 예를 들어 개발자 Adele이 점수, 프로필과 같은 사용자 데이터가 Amazon S3와 Amazon DynamoDB에 저장되는 모바일 디바이스를 위한 게임을 만들고 있다고 합시다. 또한 Adele은 이 데이터를 디바이스에 로컬로 저장하고 Amazon Cognito를 사용해 여러 디바이스 간에 동기화된 상태로 유지할 수 있습니다. Adele은 보안 및 유지 보수 상의 이유로 장기 AWS 보안 자격 증명은 게임과 함께 배포되어서는 안 된다는 것을 알고 있습니다. 또한, 게임 사용자가 아주 많을 수도 있다는 것을 알고 있습니다. 이 모든 이유로 Adele은 각 플레이어에 대해 IAM에서 새로운 사용자 자격 증명을 생성하길 원하지 않습니다. 대신에 사용자가 **Login with Amazon**, **Facebook**, **Google** 또는 **OpenID Connect**(OIDC) 호환 자격 증명 공급자(IdP)와 같은 널리 알려진 외부 IdP를 통해 이미 설정한 자격 증명을 사용해 로그인할 수 있도록 게임을 구축합니다. Adele의 게임은 이러한 공급자 중 하나의 인증 메커니즘을 이용해 사용자의 자격 증명을 확인할 수 있습니다.

모바일 앱이 자신의 AWS 리소스에 액세스할 수 있도록 하기 위해 Adele은 먼저 선택한 IdP에 개발자 ID를 등록합니다. Adele은 이들 각 공급자로 애플리케이션을 구성하기도 합니다. Adele은 게임용 Amazon S3 버킷 및 DynamoDB 테이블을 포함하는 AWS 계정에서 Amazon Cognito를 사용해 게임에 필요한 권한을 정확하게 정의하는 IAM 역할을 생성합니다. Adele이 OIDC IdP를 사용하는 경우 IAM OIDC ID 제공자 엔터티도 생성하여 AWS 계정의 [Amazon Cognito 아이덴티티 풀](https://docs.aws.amazon.com/cognito/latest/developerguide/external-identity-providers.html)과 IdP 간에 신뢰를 구축합니다.

앱의 코드에서 Adele은 자신이 이전에 구성한 IdP에 대한 로그인 인터페이스를 호출합니다. IdP는 사용자가 로그인하도록 허용하는 모든 세부 정보를 처리하고 앱은 공급자에게서 OAuth 액세스 토큰 또는 OIDC ID 토큰을 얻습니다. Adele의 앱은 이 인증 정보를 주고 AWS 액세스 키 ID, 보안 액세스 키 및 세션 토큰으로 구성된 임시 보안 자격 증명 집합을 얻을 수 있습니다. 그러면 앱은 이러한 자격 증명을 사용하여 AWS가 제공하는 웹 서비스에 액세스할 수 있습니다. 앱은 수임하는 역할에 정의된 권한으로 제한됩니다.

다음 그림은 Login with Amazon을 IdP로 사용하는 경우 이것이 어떻게 작동하는지 그 흐름을 단순화해 보여줍니다. 2단계에서 앱은 Facebook, Google 또는 OIDC 호환 IdP를 사용할 수도 있지만, 여기에서는 생략했습니다.

![\[모바일 애플리케이션을 위해 Amazon Cognito를 사용하여 사용자를 페더레이션하는 샘플 워크플로우\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/mobile-app-web-identity-federation.diagram.png)


 

1. 고객은 모바일 디바이스에서 앱을 시작합니다. 앱은 사용자에게 로그인하도록 요청합니다.

1. 앱은 Login with Amazon 리소스를 사용해 사용자의 자격 증명을 수락합니다.

1. 앱이 Amazon Cognito API 작업 `GetId` 및 `GetCredentialsForIdentity`를 사용하여 Login with Amazon ID 토큰을 Amazon Cognito 토큰으로 교환합니다. Login with Amazon 프로젝트를 신뢰하도록 구성된 Amazon Cognito는 AWS STS와의 임시 세션 자격 증명과 교환하는 토큰을 생성합니다.

1. 앱은 Amazon Cognito에서 임시 보안 자격 증명을 받습니다. 또한 앱은 Amazon Cognito의 기본(클래식) 워크플로를 사용하여 `AssumeRoleWithWebIdentity`로 AWS STS에서 토큰을 검색할 수 있습니다. 자세한 내용은 Amazon Cognito 개발자 안내서의 [자격 증명 풀(페더레이션 아이덴티티) 인증 흐름](https://docs.aws.amazon.com/cognito/latest/developerguide/authentication-flow.html)을 참조하세요.

1. 임시 보안 자격 증명은 앱에 의해 사용됨으로써 앱이 작동을 요청하는 어떤 AWS 리소스에도 액세스할 수 있습니다. 임시 보안 자격 증명과 연결된 역할 및 할당된 정책에 따라 액세스할 수 있는 항목이 결정됩니다.

다음 절차에 따라 Amazon Cognito를 사용해 사용자를 인증하도록 앱을 구성하고 앱에 AWS 리소스에 대한 액세스 권한을 부여합니다. 이 시나리오를 완수하기 위한 특정 단계에 대해서는 Amazon Cognito 설명서를 참조하세요.

1. (선택 사항) Login with Amazon, Facebook, Google 또는 기타 OpenID Connect(OIDC) 호환 IdP에 개발자로 가입하여 해당 공급자를 통해 1개 이상의 앱을 구성합니다. Amazon Cognito에서는 사용자의 인증되지 않은(게스트) 액세스도 지원하므로 이 단계는 선택 사항입니다.

1. [AWS Management Console에서 Amazon Cognito](https://console.aws.amazon.com/cognito/home)로 이동합니다. Amazon Cognito 마법사를 사용해 자격 증명 풀을 생성합니다. 이 풀은 Amazon Cognito가 앱을 위해 최종 사용자 자격 증명을 정돈된 상태로 유지할 목적으로 사용하는 컨테이너입니다. 앱 간에 자격 증명 풀을 공유할 수 있습니다. 자격 증명 풀을 설정할 때 Amazon Cognito는 사용자에 대한 권한을 정의하는 1\$12개의 IAM 역할(인증된 자격 증명용 한 개, 인증되지 않은 "게스트" 자격 증명용 한 개)을 생성합니다.

1. [AWS](https://docs.amplify.aws)Amplify를 앱과 통합하고 Amazon Cognito를 사용하는 데 필요한 파일을 가져옵니다.

1. 자격 증명 풀 ID, AWS 계정 번호 및 자격 증명 풀과 연결한 역할의 Amazon 리소스 이름(ARN)을 전달하여 Amazon Cognito 보안 인증 공급자의 인스턴스를 생성합니다. AWS Management Console의 Amazon Cognito 마법사에서 제공하는 샘플 코드를 사용하면 시작하는 데 도움이 됩니다.

1. 앱이 AWS 리소스에 액세스할 때 클라이언트 객체에 자격 증명 공급자 인스턴스를 전달합니다. 이렇게 하면 클라이언트에 임시 보안 자격 증명이 전달됩니다. 자격 증명에 대한 권한은 앞서 정의한 역할 또는 역할들에 기반을 두고 있습니다.

자세한 내용은 다음을 참조하세요.
+ AWS Amplify Framework Documentation의 [로그인(Android)](https://docs.amplify.aws/lib/auth/signin/q/platform/android/).
+ AWS Amplify Framework Documentation( 프레임워크 설명서)의 [Sign in (iOS)](https://docs.amplify.aws/lib/auth/signin/q/platform/ios/)(로그인(iOS))

## 모바일 앱용 OIDC 페더레이션
<a name="id_roles_providers_oidc_manual"></a>

최상의 결과를 얻으려면 거의 모든 OIDC 페더레이션 시나리오에서 Amazon Cognito를 ID 브로커로 사용하는 것이 좋습니다. Amazon Cognito는 사용하기 쉽고 익명(인증되지 않은) 액세스, 디바이스 및 공급자 간에 사용자 데이터 동기화 등의 추가 기능을 제공합니다. 그러나 이미 수동으로 `AssumeRoleWithWebIdentity` API를 호출하여 OIDC 페더레이션을 사용하는 앱을 생성한 경우에는 계속 사용할 수 있으며 앱이 계속 정상적으로 작동합니다.

Amazon Cognito를 ***사용하지 않고*** OIDC 페더레이션을 사용하는 프로세스의 경우 다음과 같은 일반적인 개요를 따릅니다 

1. 외부 자격 증명 공급자(IdP)에서 개발자로 로그인하여 앱을 위한 고유 ID를 부여하는 IdP에서 앱을 구성합니다. (IdP마다 이 프로세스에 대해 다른 용어를 사용합니다. 이 개요에서는 IdP에 앱을 식별하는 프로세스를 *구성*이라는 용어로 설명합니다.) 각 IdP는 IdP 고유의 앱 ID를 제공함으로써, 동일한 앱을 다수의 IdP로 구성하는 경우 앱은 여러 개의 앱 ID를 갖게 됩니다. 각 공급자로 여러 개의 앱을 구성할 수 있습니다.

   다음 외부 링크는 흔히 사용되는 자격 증명 공급자(IdP) 중 일부를 사용하는 것에 대한 정보를 제공합니다.
   + [Login with Amazon 개발자 센터](https://login.amazon.com/) 
   + Facebook 개발자 사이트의 [앱 또는 웹 사이트에 Facebook 로그인 추가하기](https://developers.facebook.com/docs/facebook-login/v2.1) 
   + Google 개발자 사이트의 [OAuth 2.0을 사용한 로그인(OpenID Connect)](https://developers.google.com/accounts/docs/OAuth2Login)
**중요**  
Google, Facebook 또는 Amazon Cognito의 OIDC 자격 증명 공급자를 사용하는 경우 AWS Management Console에서 IAM 자격 증명 공급자를 별도로 생성하지 마세요. AWS에 내장된 OIDC 자격 증명 공급자를 사용하면 됩니다. 다음 단계를 건너뛰고 자격 증명 공급자를 사용하여 새 역할을 생성하는 단계로 바로 이동합니다.

1. Google, Facebook 또는 Amazon Cognito 외에 OIDC와 호환되는 다른 IdP를 사용하는 경우 IdP를 위한 IAM 자격 증명 공급자 엔터티를 생성합니다.

1. IAM에서 [하나 이상의 역할을 생성](id_roles_create_for-idp.md)합니다. 각 역할에 대해 그 역할을 위임할 수 있는 대상(신뢰 정책)과 앱 사용자가 가지는 권한(권한 정책)을 정의합니다. 일반적으로 앱이 지원하는 각 IdP마다 하나의 역할을 생성합니다. 예를 들면 사용자가 Login with Amazon을 통해 로그인할 때 앱이 수임할 수 있는 역할, 사용자가 Facebook을 통해 로그인하는 경우 동일한 앱의 두 번째 역할, 사용자가 Google을 통해 로그인하는 경우 앱의 세 번째 역할 등을 생성할 수 있습니다. 신뢰 관계를 위해서는 IdP(예: Amazon.com)를 `Principal`(신뢰받는 개체)로 지정하고 앱 ID에 할당된 IdP와 일치하는 `Condition`을 포함시키세요. 여러 공급자의 역할에 대한 예는 [타사 ID 공급자에 대한 역할 생성](id_roles_create_for-idp.md)에 설명되어 있습니다.

1. 애플리케이션에서 IdP로 사용자를 인증하세요. 이렇게 하는 방법의 구체적인 내용은 사용 중인 IdP(Login with Amazon, Facebook 또는 Google)와 앱이 실행되는 플랫폼에 따라 달라집니다. 예를 들어 Android 앱의 인증 방법은 iOS 앱 또는 JavaScript 기반 웹 앱과 다를 수 있습니다.

   일반적으로 사용자가 아직 로그인하지 않은 경우 IdP가 로그인 페이지 표시를 처리합니다. IdP가 사용자를 인증한 후에 IdP는 사용자에 대한 정보가 담긴 인증 토큰을 앱에 반환합니다. 포함된 정보의 내용은 IdP가 노출하는 것과 사용자가 공유하고자 하는 정보가 무엇인지에 달려 있습니다. 앱에서 이 정보를 사용할 수 있습니다.

1. 앱에서 `AssumeRoleWithWebIdentity` 작업에 대한 *서명되지 않은* 호출을 수행하여 임시 보안 자격 증명을 요청합니다. 요청 시 IdP의 인증 토큰을 전달하고 해당 IdP에 대해 생성한 IAM 역할의 Amazon 리소스 이름(ARN)을 지정합니다. AWS는 그 토큰이 신뢰할 수 있고 유효한지 확인하여, 그럴 경우에는 요청에서 명명하는 역할에 대한 권한을 포함하는 임시 보안 자격 증명을 앱에 반환합니다. 그 응답에는 IdP가 사용자에게 연결하는 고유 사용자 ID와 같은, IdP에서 오는 사용자에 대한 메타데이터도 포함되어 있습니다.

1. `AssumeRoleWithWebIdentity` 응답의 임시 보안 자격 증명을 사용하여 앱에서 AWS API 작업에 대한 서명된 요청을 생성합니다. IdP의 사용자 ID 정보는 앱에서 사용자를 구분할 수 있습니다. 예를 들어 사용자 ID가 접두사 또는 접미사로 포함된 Amazon S3 폴더에 객체를 넣을 수 있습니다. 이렇게 함으로써 폴더를 잠그는 액세스 제어 정책을 생성해 그 ID를 지닌 사용자만 그 폴더에 액세스할 수 있게 됩니다. 자세한 내용은 [AWS STS 페더레이션 사용자 보안 주체](reference_policies_elements_principal.md#sts-session-principals) 섹션을 참조하세요.

1. 앱은 AWS에 요청할 필요가 있을 때마다 새 임시 보안 자격 증명을 받지 않아도 되도록 임시 보안 자격 증명을 캐시해야 합니다. 기본적으로 자격 증명은 1시간 동안 유효합니다. 자격 증명이 만료되면(또는 그 전에) `AssumeRoleWithWebIdentity`에 또 한 번 호출을 하여 새로운 임시 보안 자격 증명 집합을 얻으세요. IdP의 토큰 역시 보통 설정된 시간이 지나면 만료되기 때문에, IdP 및 IdP가 토큰을 어떻게 관리하느냐에 따라 `AssumeRoleWithWebIdentity`에 새로운 호출을 하기 전에 IdP의 토큰을 갱신해야 할 수도 있습니다. AWS SDK for iOS 또는 AWS SDK for Android를 사용하는 경우 [AmazonSTSCredentialsProvider](https://aws.amazon.com/blogs/mobile/using-the-amazoncredentialsprovider-protocol-in-the-aws-sdk-for-ios) 작업을 사용해 IAM 임시 자격 증명을 필요에 따라 갱신하는 등 관리할 수 있습니다.

# OIDC 페더레이션
<a name="id_roles_providers_oidc"></a>

워크플로를 사용하여 Amazon S3 및 DynamoDB에 액세스하는 GitHub Actions와 같은 AWS 리소스에 액세스하는 애플리케이션을 구축하는 상황을 가정해 보겠습니다.

이러한 워크플로를 사용할 때는 AWS 액세스 키로 서명해야 하는 AWS 서비스에 요청을 하게 됩니다. 하지만 AWS 자격 증명을 AWS 외부의 애플리케이션에 장기적으로 저장하지 **않는** 것을 **강력하게** 권장합니다. 대신 OIDC 페더레이션을 사용하여 필요할 때 임시 AWS 보안 자격 증명을 동적으로 요청하도록 애플리케이션을 구성합니다. 제공되는 임시 자격 증명은 애플리케이션에 필요한 작업을 수행하는 데 필요한 권한만 있는 AWS 역할에 매핑됩니다.

OIDC 페더레이션을 사용하면 사용자 정의 로그인 코드를 생성하거나 자신의 사용자 보안 인증을 관리할 필요가 없습니다. 대신, GitHub Actions 또는 기타 [OIDC(OpenID Connect)](http://openid.net/connect/)와 호환되는 IdP와 같은 애플리케이션에서 OIDC를 사용하여 AWS에 인증할 수 있습니다. 이러한 애플리케이션은 JWT(JSON 웹 토큰)라는 인증 토큰을 수신한 후 이 토큰을 AWS에서 임시 보안 자격 증명으로 교환하여 AWS 계정의 특정 리소스를 사용할 수 있는 권한이 있는 IAM 역할에 매핑합니다. IdP를 사용하면 애플리케이션에 장기 보안 자격 증명을 포함하거나 배포할 필요가 없으므로 AWS 계정을(를) 안전하게 유지할 수 있습니다.

OIDC 페더레이션은 M2M(Machine-to-Machine) 인증(예: CI/CD 파이프라인, 자동 스크립트, 서버리스 애플리케이션)과 인간 사용자 인증을 모두 지원합니다. 사용자 가입, 로그인, 사용자 프로필을 관리해야 하는 인간 사용자 인증 시나리오의 경우 [Amazon Cognito](https://aws.amazon.com/cognito/)를 ID 브로커로 사용하는 것이 좋습니다. OIDC에서 Amazon Cognito를 사용하는 방법에 대한 자세한 내용은 [모바일 앱용 Amazon Cognito](id_federation_common_scenarios.md#id_roles_providers_oidc_cognito) 섹션을 참조하세요.

**참고**  
OpenID Connect(OIDC) ID 제공업체에서 발행하는 JWT(JSON 웹 토큰)에는 토큰이 만료되는 시기를 지정하는 `exp` 클레임에 만료 시간이 포함되어 있습니다. IAM은 [OpenID Connect(OIDC) Core 1.0 표준](https://openid.net/specs/openid-connect-core-1_0.html)에서 허용하는 대로 클럭 스큐를 고려하여 JWT에 지정된 만료 시간 이후 5분의 기간을 제공합니다. 즉, 만료 시간 이후 5분 이내에 IAM이 수신한 OIDC JWT가 추가 평가 및 처리를 위해 승인됩니다.

**Topics**
+ [

## OIDC 페더레이션 관련 추가 리소스
](#id_roles_providers_oidc_resources)
+ [

# IAM에서 OIDC(OpenID Connect) ID 공급자 생성
](id_roles_providers_create_oidc.md)
+ [

# OpenID Connect ID 공급자에 대한 지문 얻기
](id_roles_providers_create_oidc_verify-thumbprint.md)
+ [

# 공유 OIDC 공급자의 ID 공급자 제어
](id_roles_providers_oidc_secure-by-default.md)

## OIDC 페더레이션 관련 추가 리소스
<a name="id_roles_providers_oidc_resources"></a>

다음 리소스는 OIDC 페더레이션에 대해 자세히 알아보는 데 도움이 됩니다.
+ [Amazon Web Services에서 OpenID Connect를 구성](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)하여 GitHub 워크플로 내에서 OpenID Connect 사용
+ Android용 Amplify 라이브러리 가이드의[Amazon Cognito 아이덴티티](https://docs.amplify.aws/lib/auth/advanced/q/platform/android/)와 Swift용 Amplify 라이브러리 가이드의 [Amazon Cognito 아이덴티티](https://docs.amplify.aws/lib/auth/advanced/q/platform/ios/)를 참조하십시오.
+ *AWS 보안 블로그*의 [AWS 리소스에 대한 액세스 권한을 부여할 때 외부 ID를 사용하는 방법](https://aws.amazon.com/blogs/security/how-to-use-external-id-when-granting-access-to-your-aws-resources/)은 교차 계정 액세스 및 외부 ID 페더레이션을 안전하게 구성하는 방법에 대한 지침을 제공합니다.

# IAM에서 OIDC(OpenID Connect) ID 공급자 생성
<a name="id_roles_providers_create_oidc"></a>

*IAM OIDC 자격 증명 공급자*는 IAM의 엔터티로서 Google이나 Salesforce와 같은 [OpenID Connect](http://openid.net/connect/)(OIDC) 표준을 지원하는 외부 자격 증명 공급자(IdP) 서비스를 설명합니다. IAM OIDC 자격 증명 공급자는 OIDC 호환 IdP와 AWS 계정 간에 신뢰를 구축하려 할 때 사용합니다. 예를 들어 AWS 리소스에 액세스하는 데 필요한 모바일 앱이나 웹 애플리케이션을 개발하면서 사용자 지정 로그인 코드를 생성하거나 자신의 사용자 자격 증명을 관리하지 않을 때 유용합니다. 이 시나리오에 대한 자세한 내용은 [OIDC 페더레이션](id_roles_providers_oidc.md)를 참조하세요.

AWS Management Console, AWS Command Line Interface, Tools for Windows PowerShell 또는 IAM API 호출을 사용하여 IAM OIDC 자격 증명 공급자를 생성하고 관리할 수 있습니다.

IAM OIDC 자격 증명 공급자를 생성한 후 1개 이상의 IAM 역할을 생성해야 합니다. 역할은 AWS의 자격 증명으로서 자신만의 고유한 자격 증명이 없지만(사용자가 그러하듯이), 이 컨텍스트에서는 조직의 IdP에서 인증한 OIDC 페더레이션 보안 주체에게 역할이 동적으로 할당됩니다. 그 역할은 조직의 IdP가 AWS에 액세스하기 위해 임시 보안 자격 증명을 요청할 수 있도록 허용합니다. 역할에 할당된 정책은 사용자가 AWS에서 허용된 작업이 무엇인지 결정합니다. 서드 파티 자격 증명 공급자에 대한 역할을 생성하려면 [타사 ID 공급자에 대한 역할 생성](id_roles_create_for-idp.md) 섹션을 참조하세요.

**중요**  
`oidc-provider` 리소스를 지원하는 작업에 대해 ID 기반 정책을 구성하는 경우. IAM은 지정된 경로를 포함한 전체 OIDC ID 공급자 URL을 평가합니다. OIDC ID 공급자 URL에 경로가 있는 경우 그 경로를 `oidc-provider`ARN에 `Resource` 요소 값으로 포함해야 합니다. URL 도메인에 슬래시와 와일드카드(`/*`)를 추가할 수도 있고 URL 경로의 어느 지점에서든 와일드카드 문자(`*` 및`?`)를 사용할 수도 있습니다. 요청의 OIDC ID 공급자 URL이 정책의 `Resource` 요소에 설정된 값과 일치하지 않는 경우 요청은 실패합니다.

IAM OIDC 페더레이션과 관련된 일반적인 문제를 해결하려면 AWS re:Post의 [OIDC 관련 오류 해결](https://repost.aws/knowledge-center/iam-oidc-idp-federation)을 참조하세요.

**Topics**
+ [

## 필수 조건: 자격 증명 공급자의 구성 검증
](#manage-oidc-provider-prerequisites)
+ [

## OIDC 공급자 생성 및 관리(콘솔)
](#manage-oidc-provider-console)
+ [

## IAM OIDC 자격 증명 공급자 생성 및 관리(AWS CLI)
](#manage-oidc-provider-cli)
+ [

## OIDC 자격 증명 공급자 생성 및 관리(AWS API)
](#manage-oidc-provider-api)

## 필수 조건: 자격 증명 공급자의 구성 검증
<a name="manage-oidc-provider-prerequisites"></a>

IAM OIDC 자격 증명 공급자를 생성하려면 IdP에서 다음 정보를 가져와야 합니다. OIDC 공급자 구성 정보를 얻는 방법에 대한 자세한 정보는 해당 IdP 설명서를 참조하세요.

1. 공개적으로 사용 가능한 OIDC 자격 증명 공급자 URL을 확인하세요. URL은 https://로 시작해야 합니다. OIDC 표준에 따라 경로 구성 요소는 허용되지만 쿼리 파라미터는 허용되지 않습니다. 일반적으로 URL은 https://server.example.org 또는 https://example.com 같은 하나의 호스트 이름으로만 구성됩니다. URL은 포트 번호를 포함하지 않아야 합니다.

1. OIDC 자격 증명 공급자의 URL 끝에 **/.well-known/openid-configuration**을 추가하면 공개적으로 사용 가능한 공급자 구성 문서와 메타데이터를 확인할 수 있습니다. [OpenID Connect 공급자 검색 엔드포인트 URL](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig)에서 검색할 수 있는 공급자의 구성 문서 및 메타데이터가 포함된 JSON 형식의 검색 문서가 있어야 합니다.

1. 공급자의 구성 정보에 다음 값이 포함되어 있는지 확인하세요. openid-configuration에 다음 필드 중 하나라도 없는 경우 검색 문서를 업데이트해야 합니다. 이 프로세스는 자격 증명 공급자에 따라 다를 수 있으므로 IdP의 설명서에 따라 이 작업을 완료하세요.
   + issuer: 도메인의 URL입니다.
   + jwks\$1uri: IAM이 퍼블릭 키를 가져오는 JSON Web Key Set(JWKS) 엔드포인트입니다. 자격 증명 공급자는 openid-configuration에 JSON Web Key Set(JWKS) 엔드포인트를 포함해야 합니다. 이 URI는 자격 증명 공급자의 서명된 토큰을 확인하는 데 사용되는 퍼블릭 키를 가져올 위치를 정의합니다.
**참고**  
JSON 웹 키 세트(JWKS)에는 하나 이상의 키가 포함되어야 하며 최대 100개의 RSA 키와 100개의 EC 키를 보유할 수 있습니다. OIDC ID 제공업체의 JWKS에 100개가 넘는 RSA 키 또는 100개가 넘는 EC 키가 포함된 경우 100개 키 제한을 초과하는 키 유형으로 서명된 JWT와 함께 [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) API 작업을 사용하면 `InvalidIdentityToken` 예외가 반환됩니다. 예를 들어 JWT가 RSA 알고리즘으로 서명되고 제공업체의 JWKS에 100개가 넘는 RSA 키가 있는 경우 `InvalidIdentityToken` 예외가 반환됩니다.
   + claim s\$1supported: AWS가 IAM 정책에서 OIDC 페더레이션 보안 주체의 권한 검사에 사용하는 필수 속성이 IdP의 OIDC 인증 응답에 포함되어 있는지 확인하도록 도와주는 사용자 관련 정보입니다. 클레임에 사용할 수 있는 IAM 조건 키 목록은 [AWS OIDC 페더레이션에서 사용 가능한 키](reference_policies_iam-condition-keys.md#condition-keys-wif)를 참조하세요.
     + aud: IdP가 JSON Web Token(JWT)으로 발급하는 audience 클레임 값을 확인해야 합니다. audience(aud) 클레임은 애플리케이션별로 다르며 토큰의 의도된 수신자를 식별합니다. 모바일 또는 웹 앱을 OpenID Connect 공급자에 등록하면 애플리케이션을 식별하는 클라이언트 ID가 설정됩니다. 클라이언트 ID는 인증을 위해 aud 클레임에 전달되는 앱의 고유 식별자입니다. IAM OIDC 자격 증명 공급자를 생성할 때 aud 클레임이 Audience 값과 일치해야 합니다.
     + iat: 클레임에는 ID 토큰이 발급된 시간을 나타내는 `iat` 값이 포함되어야 합니다.
     + iss: 자격 증명 공급자의 URL입니다. URL은 https://로 시작해야 하며 IAM에 제공된 공급자 URL과 일치해야 합니다. OIDC 표준에 따라 경로 구성 요소는 허용되지만 쿼리 파라미터는 허용되지 않습니다. 일반적으로 URL은 https://server.example.org 또는 https://example.com 같은 하나의 호스트 이름으로만 구성됩니다. URL은 포트 번호를 포함하지 않아야 합니다.
   + response\$1types\$1supported: id\$1token
   + subject\$1types\$1supported: public
   + id\$1token\$1signing\$1alg\$1values\$1supported: RS256, RS384, RS512, ES256, ES384, ES512
**참고**  
아래 예제에서 `my_custom_claim`과 같은 추가 클레임을 포함할 수 있지만 AWS STS는 이 클레임을 무시합니다.  

   ```
   {
     "issuer": "https://example-domain.com",
     "jwks_uri": "https://example-domain.com/jwks/keys",
     "claims_supported": [
       "aud",
       "iat",
       "iss",
       "name",
       "sub",
       "my_custom_claim"
     ],
     "response_types_supported": [
       "id_token"
     ],
     "id_token_signing_alg_values_supported": [
       "RS256",
       "RS384",
       "RS512",
       "ES256",
       "ES384",
       "ES512"
     ],
     "subject_types_supported": [
       "public"
     ]
   }
   ```

## OIDC 공급자 생성 및 관리(콘솔)
<a name="manage-oidc-provider-console"></a>

다음 지침에 따라 AWS Management Console에서 IAM OIDC 자격 증명 공급자를 생성 및 관리합니다.

**중요**  
Google, Facebook 또는 Amazon Cognito의 OIDC 자격 증명 공급자를 사용하는 경우 이 절차에 따라 IAM 자격 증명 공급자를 별도로 생성하지 마세요. 이러한 OIDC 자격 증명 공급자는 이미 AWS에 내장되어 있고 용도에 맞게 사용할 수 있습니다. 대신 단계에 따라 자격 증명 공급자의 새 역할을 생성합니다. 자세한 내용은 [OpenID Connect 페더레이션을 위한 역할 생성(콘솔)](id_roles_create_for-idp_oidc.md) 섹션을 참조하세요.

**IAM OIDC 자격 증명 공급자를 생성하려면(콘솔)**

1. <a name="idpoidcstep1"></a>IAM OIDC 자격 증명 공급자를 생성하려면 먼저 애플리케이션을 IdP에 등록하여 *클라이언트 ID*를 받아야 합니다. 클라이언트 ID(*사용자*라고도 불림)는 앱을 IdP에 등록할 때 발급되는 고유의 앱 식별자입니다. 클라이언트 ID를 얻는 방법에 대한 자세한 정보는 해당 IdP에 대한 설명서를 참조하세요.
**참고**  
AWS는 신뢰할 수 있는 루트 CA(인증 기관) 라이브러리를 사용해 OIDC ID 공급자(IdP)와의 통신을 보호하여 JWKS(JSON 웹 키 세트) 엔드포인트의 TLS 인증서를 확인합니다. OIDC IdP가 이러한 신뢰할 수 있는 CA 중 하나에서 서명하지 않은 인증서를 사용하는 경우에만 IdP의 구성에 설정된 지문을 사용하여 통신을 보호합니다. AWS는 TLS 인증서를 검색할 수 없거나 TLS v1.3이 필요한 경우 지문 확인으로 대체합니다.

1. IAM 콘솔([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/))을 엽니다.

1. 탐색 창에서 [**자격 증명 공급자**(Identity providers)]를 선택한 다음 [**공급자 추가**(Add provider)]를 선택합니다.

1. [**공급자 구성(Configure provider)**]에 대해 [**OpenID Connect**]를 선택합니다.

1. **Provider URL(공급자 URL)**에서 IdP의 URL을 입력합니다. URL은 다음과 같은 제한을 준수해야 합니다.
   + URL은 대/소문자를 구분합니다.
   + URL은 **https://**로 시작해야 합니다.
   + URL은 포트 번호를 포함하지 않아야 합니다.
   + AWS 계정 내에서 각 IAM OIDC 자격 증명 공급자는 고유한 URL을 사용해야 합니다. AWS 계정에서 OpenID Connect 공급자에 이미 사용된 URL을 제출하려고 하면 오류가 발생합니다.

1. **대상(Audience)** 필드에 IdP를 등록하고 [Step 1](#idpoidcstep1)에서 받은 애플리케이션의 클라이언트 ID를 입력하면 AWS에게도 요청됩니다. IdP에 등록한 클라이언트 ID(*사용자들*이라고도 불림)가 더 있는 경우 나중에 공급자 세부 정보 페이지에서 추가할 수 있습니다.
**참고**  
IdP JWT 토큰에 `azp` 클레임이 포함된 경우 이 값을 Audience 값으로 입력하세요.  
OIDC ID 제공업체는 토큰에 `aud` 및 `azp` 클레임을 모두 설정하고, AWS STS에서는 `azp` 클레임의 값을 `aud` 클레임으로 사용합니다.

1. (선택 사항) **태그 추가(Add tags)**에 키 값 페어를 추가하여 IdP를 식별하고 구성할 수 있습니다. 태그를 사용하여 AWS 리소스에 대한 액세스를 제어할 수도 있습니다. IAM OIDC 자격 증명 공급자 태깅에 대한 자세한 내용은 [OpenID Connect(OIDC) ID 제공업체 태깅](id_tags_oidc.md) 섹션을 참조하세요. **태그 추가**를 선택합니다. 각 태그 키 값 페어의 값을 입력합니다.

1. 제공한 정보를 확인합니다. 완료되면 [**공급자 추가(Add provider)**]를 선택합니다. IAM에서는 OIDC IdP 서버 인증서의 최상위 중간 CA 지문을 검색하고 사용하여 IAM OIDC ID 제공업체를 생성하려고 시도합니다.
**참고**  
OIDC ID 제공업체의 인증서 체인은 도메인 또는 발급자 URL로 시작하고, 그다음으로 중간 인증서, 마지막으로는 루트 인증서여야 합니다. 인증서 체인 순서가 다른 경우 또는 중복되거나 추가 인증서가 포함된 경우 서명 불일치 오류가 발생하고 STS는 JSON 웹 토큰(JWT) 유효성 검사에 실패합니다. 서버에서 반환된 체인의 인증서 순서를 수정하여 오류를 해결하세요. 인증서 체인 표준에 대한 자세한 내용은 RFC 시리즈 웹 사이트에서 [RFC 5246의 certificate\$1list](https://www.rfc-editor.org/rfc/rfc5246#section-7.4.2)를 참조하세요.

1. 자격 증명 공급자에 IAM 역할을 할당하여 자격 증명 공급자가 관리하는 외부 사용자 자격 증명에 계정의 AWS 리소스에 대한 액세스 권한을 부여합니다. ID 연동을 위한 역할을 생성하는 방법에 대한 자세한 내용은 [타사 ID 공급자에 대한 역할 생성](id_roles_create_for-idp.md) 섹션을 참조하세요.
**참고**  
역할 신뢰 정책에 사용되는 OIDC IdP는 이를 신뢰하는 역할과 동일한 계정에 있어야 합니다.

**IAM OIDC 자격 증명 공급자에 대한 지문을 추가하거나 제거하려면(콘솔)**
**참고**  
AWS는 신뢰할 수 있는 루트 CA(인증 기관) 라이브러리를 사용해 OIDC ID 공급자(IdP)와의 통신을 보호하여 JWKS(JSON 웹 키 세트) 엔드포인트의 TLS 인증서를 확인합니다. OIDC IdP가 이러한 신뢰할 수 있는 CA 중 하나에서 서명하지 않은 인증서를 사용하는 경우에만 IdP의 구성에 설정된 지문을 사용하여 통신을 보호합니다. AWS는 TLS 인증서를 검색할 수 없거나 TLS v1.3이 필요한 경우 지문 확인으로 대체합니다.

1. IAM 콘솔([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/))을 엽니다.

1. 탐색 창에서 [**자격 증명 공급자(Identity providers)**]를 선택합니다. 그런 다음 업데이트할 IAM 자격 증명 공급자의 이름을 선택합니다.

1. **엔드포인트 확인** 탭을 선택한 다음 **지문** 섹션에서 **관리**를 선택합니다. 새 지문 값을 입력하려면 [**지문 추가(Add thumbprint)**]를 선택합니다. 지문을 제거하려면 삭제할 지문 옆에 있는 [**제거(Remove)**]를 선택합니다.
**참고**  
IAM OIDC 자격 증명 공급자마다 한 개 이상의 지문이 있어야 하며 최대 5개까지 가능합니다.

    작업을 마쳤으면 [**변경 사항 저장(Save changes)**]을 선택합니다.

**IAM OIDC 자격 증명 공급자에 대한 대상을 추가하려면(콘솔)**

1. 탐색 창에서 **자격 증명 공급자(Identity providers)**를 선택한 다음 업데이트할 IAM 자격 증명 공급자의 이름을 선택합니다.

1. [**대상(Audiences)**] 섹션에서 [**작업(Actions)**]을 선택하고 [**대상 추가(Add audience)**]를 선택합니다.

1. IdP에 등록하고 [Step 1](#idpoidcstep1)에서 받은 애플리케이션의 클라이언트 ID를 입력하면 AWS로 요청이 전송됩니다. 그런 다음 [**대상 추가(Add audience)**]를 선택합니다.
**참고**  
IAM OIDC 자격 증명 공급자마다 한 명 이상의 사용자가 있어야 하며 최대 100명까지 가능합니다.

**IAM OIDC 자격 증명 공급자에 대한 대상을 제거하려면(콘솔)**

1. 탐색 창에서 **자격 증명 공급자(Identity providers)**를 선택한 다음 업데이트할 IAM 자격 증명 공급자의 이름을 선택합니다.

1. [**대상(Audiences)**] 섹션에서 제거할 대상 옆에 있는 라디오 단추를 선택한 다음 [**작업(Actions)**]을 선택합니다.

1.  [**대상 제거(Remove audience)**]를 선택합니다. 새 창이 열립니다.

1. 대상을 제거하면 해당 대상과 연동된 자격 증명에서 해당 대상에 연결된 역할을 수임할 수 없습니다. 창에서 경고를 읽고 필드에 `remove`라는 단어를 입력하여 대상 제거를 확인합니다.

1. [**제거(Remove)**]를 선택하여 대상을 제거합니다.

**IAM OIDC 자격 증명 공급자를 삭제하려면(콘솔)**

1. IAM 콘솔([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/))을 엽니다.

1. 탐색 창에서 [**자격 증명 공급자(Identity providers)**]를 선택합니다.

1. 삭제하려는 할 IAM ID 제공업체 옆의 확인란을 선택하세요. 새 창이 열립니다.

1. 필드에 단어 `delete`를 입력하여 공급자 삭제를 확인합니다. 그런 다음 **삭제**를 선택합니다.

## IAM OIDC 자격 증명 공급자 생성 및 관리(AWS CLI)
<a name="manage-oidc-provider-cli"></a>

다음 AWS CLI 명령을 사용하여 IAM OIDC 자격 증명 공급자를 생성하고 관리할 수 있습니다.

**IAM OIDC 자격 증명 공급자를 생성하려면(AWS CLI)**

1. (선택 사항) AWS 계정의 전체 IAM OIDC 자격 증명 공급자 목록을 가져오려면 다음 명령을 실행합니다.
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-providers.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-providers.html)

1. 새 IAM OIDC 자격 증명 공급자를 생성하려면 다음 명령을 실행합니다.
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/create-open-id-connect-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/create-open-id-connect-provider.html)

**기존 IAM OIDC 자격 증명 공급자의 서버 인증서 지문 목록을 업데이트하려면(AWS CLI)**
+ IAM OIDC 자격 증명 공급자의 서버 인증서 지문 목록을 업데이트하려면 다음 명령을 실행합니다.
  + [https://docs.aws.amazon.com/cli/latest/reference/iam/update-open-id-connect-provider-thumbprint.html](https://docs.aws.amazon.com/cli/latest/reference/iam/update-open-id-connect-provider-thumbprint.html)

**기존 IAM OIDC 자격 증명 공급자를 태깅하려면(AWS CLI)**
+ 기존 IAM OIDC 자격 증명 공급자를 태깅하려면 다음 명령을 실행합니다.
  + [https://docs.aws.amazon.com/cli/latest/reference/iam/tag-open-id-connect-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-open-id-connect-provider.html)

**기존 IAM OIDC 자격 증명 공급자의 태그를 나열하려면(AWS CLI)**
+ 기존 IAM OIDC 자격 증명 공급자의 태그를 나열하려면 다음 명령을 실행합니다.
  + [https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-provider-tags.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-provider-tags.html)

**IAM OIDC 자격 증명 공급자에서 태그를 제거하려면(AWS CLI)**
+ 기존 IAM OIDC 자격 증명 공급자에서 태그를 제거하려면 다음 명령을 실행합니다.
  + [https://docs.aws.amazon.com/cli/latest/reference/iam/untag-open-id-connect-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-open-id-connect-provider.html)

**기존 IAM OIDC 자격 증명 공급자에서 클라이언트 ID를 추가하거나 제거하려면(AWS CLI)**

1. (선택 사항) AWS 계정의 전체 IAM OIDC 자격 증명 공급자 목록을 가져오려면 다음 명령을 실행합니다.
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-providers.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-providers.html)

1. (선택 사항) IAM OIDC 자격 증명 공급자에 대한 자세한 정보를 보려면 다음 명령을 실행합니다.
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/get-open-id-connect-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-open-id-connect-provider.html)

1. 기존 IAM OIDC 자격 증명 공급자에 새로운 클라이언트 ID를 추가하려면 다음 명령을 실행합니다.
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/add-client-id-to-open-id-connect-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/add-client-id-to-open-id-connect-provider.html)

1. 기존 IAM OIDC 자격 증명 공급자에서 클라이언트를 제거하려면 다음 명령을 실행합니다.
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/remove-client-id-from-open-id-connect-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/remove-client-id-from-open-id-connect-provider.html)

**IAM OIDC 자격 증명 공급자를 삭제하려면(AWS CLI)**

1. (선택 사항) AWS 계정의 전체 IAM OIDC 자격 증명 공급자 목록을 가져오려면 다음 명령을 실행합니다.
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-providers.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-providers.html)

1. (선택 사항) IAM OIDC 자격 증명 공급자에 대한 자세한 정보를 보려면 다음 명령을 실행합니다.
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/get-open-id-connect-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-open-id-connect-provider.html)

1. IAM OIDC 자격 증명 공급자를 삭제하려면 다음 명령을 실행합니다.
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-open-id-connect-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-open-id-connect-provider.html)

## OIDC 자격 증명 공급자 생성 및 관리(AWS API)
<a name="manage-oidc-provider-api"></a>

다음 IAM API 명령을 사용하여 OIDC 공급자를 생성하고 관리할 수 있습니다.

**IAM OIDC 자격 증명 공급자를 생성하려면(AWS API)**

1. (선택 사항) AWS 계정의 전체 IAM OIDC 자격 증명 공급자 목록을 가져오려면 다음 작업을 호출합니다.
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviders.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviders.html)

1. 새로운 IAM OIDC 자격 증명 공급자를 생성하려면 다음 작업을 호출합니다.
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateOpenIDConnectProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateOpenIDConnectProvider.html)

**기존 IAM OIDC 자격 증명 공급자의 서버 인증서 지문 목록을 업데이트하려면(AWS API)**
+ IAM OIDC 자격 증명 공급자의 서버 인증서 지문 목록을 업데이트하려면 다음 작업을 호출합니다.
  + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateOpenIDConnectProviderThumbprint.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateOpenIDConnectProviderThumbprint.html)

**기존 IAM OIDC 자격 증명 공급자를 태깅하려면(AWS API)**
+ 기존 IAM OIDC 자격 증명 공급자를 태깅하려면 다음 작업을 호출합니다.
  + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagOpenIDConnectProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagOpenIDConnectProvider.html)

**기존 IAM OIDC 자격 증명 공급자의 태그를 나열하려면(AWS API)**
+ 기존 IAM OIDC 자격 증명 공급자의 태그를 나열하려면 다음 작업을 호출합니다.
  + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviderTags.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviderTags.html)

**기존 IAM OIDC 자격 증명 공급자에서 태그를 제거하려면(AWS API)**
+ 기존 IAM OIDC 자격 증명 공급자에서 태그를 제거하려면 다음 작업을 호출합니다.
  + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagOpenIDConnectProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagOpenIDConnectProvider.html)

**기존 IAM OIDC 자격 증명 공급자에서 클라이언트 ID를 추가하거나 제거하려면(AWS API)**

1. (선택 사항) AWS 계정의 전체 IAM OIDC 자격 증명 공급자 목록을 가져오려면 다음 작업을 호출합니다.
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviders.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviders.html)

1. (선택 사항) IAM OIDC 자격 증명 공급자에 대한 자세한 정보를 보려면 다음 작업을 호출합니다.
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetOpenIDConnectProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetOpenIDConnectProvider.html)

1. 기존 IAM OIDC 자격 증명 공급자에 새로운 클라이언트 ID를 추가하려면 다음 작업을 호출합니다.
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddClientIDToOpenIDConnectProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_AddClientIDToOpenIDConnectProvider.html)

1. 기존 IAM OIDC 자격 증명 공급자에서 클라이언트 ID를 제거하려면 다음 작업을 호출합니다.
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_RemoveClientIDFromOpenIDConnectProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_RemoveClientIDFromOpenIDConnectProvider.html)

**IAM OIDC 자격 증명 공급자를 삭제하려면(AWS API)**

1. (선택 사항) AWS 계정의 전체 IAM OIDC 자격 증명 공급자 목록을 가져오려면 다음 작업을 호출합니다.
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviders.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviders.html)

1. (선택 사항) IAM OIDC 자격 증명 공급자에 대한 자세한 정보를 보려면 다음 작업을 호출합니다.
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetOpenIDConnectProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetOpenIDConnectProvider.html)

1. IAM OIDC 자격 증명 공급자를 삭제하려면 다음 작업을 호출합니다.
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteOpenIDConnectProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteOpenIDConnectProvider.html)

# OpenID Connect ID 공급자에 대한 지문 얻기
<a name="id_roles_providers_create_oidc_verify-thumbprint"></a>

IAM에서 [OpenID Connect(OIDC) ID 제공업체](id_roles_providers_create_oidc.md)를 생성할 때는 외부 ID 제공업체(idP)에서 사용한 인증서에 서명한 중간 인증 기관(CA)의 지문이 IAM에 필요합니다. 지문은 OIDC 호환 IdP에 대한 인증서 발급에 사용되는 CA에 대한 서명입니다. IAM OIDC 자격 증명 공급자를 생성하는 경우 해당 IdP에 의해 인증된 자격 증명이 자신의 AWS 계정에 액세스할 수 있도록 신뢰하는 것입니다. CA의 인증서 지문을 사용함으로써 등록된 것과 DNS 이름이 동일한 CA에서 발급한 모든 인증서를 신뢰하게 됩니다. 이를 통해 IdP의 서명 인증서를 갱신할 때 각 계정의 신뢰를 업데이트할 필요가 없습니다.

**중요**  
대부분의 경우 연동 서버는 두 가지 다른 인증서를 사용합니다.  
첫 번째는 AWS 및 IdP 사이의 HTTPS 연결을 설정합니다. 이는 잘 알려진 퍼블릭 루트 CA(예: AWS Certificate Manager)에서 발급해야 합니다. 이렇게 하면 클라이언트가 인증서의 안정성과 상태를 확인할 수 있습니다.
두 번째는 토큰을 암호화하는 데 사용되며 프라이빗 또는 퍼블릭 *루트* CA가 서명해야 합니다.

[AWS Command Line Interface, Tools for Windows PowerShell 또는 IAM API](id_roles_providers_create_oidc.md#manage-oidc-provider-cli)를 사용하여 IAM OIDC 자격 증명 공급자를 생성할 수 있습니다. 이러한 방법을 사용하면 수동으로 지문을 제공하는 옵션이 생깁니다. 지문을 포함하지 않기로 선택하면 IAM은 OIDC IdP 서버 인증서의 최상위 임시 CA 지문을 검색합니다. 지문을 포함하도록 선택한 경우 지문을 수동으로 획득하여 AWS에 제공해야 합니다.

[IAM 콘솔](id_roles_providers_create_oidc.md)을 사용하여 OIDC ID 제공업체를 생성하면 IAM에서는 자동으로 OIDC IdP 서버 인증서의 최상위 중간 CA 지문 검색을 시도합니다.

또한, OIDC IdP의 지문을 수동으로 가져와서 IAM에서 올바른 지문을 검색했는지 확인하는 것이 좋습니다. 인증서 지문을 얻는 방법에 대한 자세한 내용은 다음 섹션을 참조하세요.

**참고**  
AWS는 신뢰할 수 있는 루트 CA(인증 기관) 라이브러리를 사용해 OIDC ID 공급자(IdP)와의 통신을 보호하여 JWKS(JSON 웹 키 세트) 엔드포인트의 TLS 인증서를 확인합니다. OIDC IdP가 이러한 신뢰할 수 있는 CA 중 하나에서 서명하지 않은 인증서를 사용하는 경우에만 IdP의 구성에 설정된 지문을 사용하여 통신을 보호합니다. AWS는 TLS 인증서를 검색할 수 없거나 TLS v1.3이 필요한 경우 지문 확인으로 대체합니다.

## 인증서 지문 얻기
<a name="oidc-obtain-thumbprint"></a>

웹 브라우저와 OpenSSL 명령줄 도구를 사용하여 OIDC 공급자의 인증서 지문을 얻습니다. 하지만 수동으로 인증서 지문을 얻어서 IAM OIDC ID 공급자를 생성할 필요는 없습니다. 다음 절차를 통해 OIDC 공급자의 인증서 지문을 얻을 수 있습니다.

**OIDC IdP의 지문을 얻으려면**

1. OIDC IdP의 지문을 얻으려면, 먼저 OpenSSL 명령줄 도구를 얻어야 합니다. 이 도구를 사용하여 OIDC IdP 인증서 체인을 다운로드하고 인증서 체인에 있는 마지막 인증서의 지문을 생성합니다. OpenSSL을 설치 및 구성해야 하는 경우 [OpenSSL 설치](#oidc-install-openssl) 및 [OpenSSL 구성](#oidc-configure-openssl)의 지침을 따르세요.

1. OIDC IdP URL(예: `https://server.example.com`)로 시작한 다음 `/.well-known/openid-configuration`을 추가하여 다음과 같이 OIDC IdP의 구성 문서에 대한 URL을 만듭니다.

   **https://*server.example.com*/.well-known/openid-configuration**

   웹 브라우저에서 이 URL을 열 때 *server.example.com*을 IdP 서버 이름으로 바꾸어 엽니다.

1. <a name="thumbstep2"></a>표시되는 문서에서 웹 브라우저 **찾기** 기능을 사용하여 `"jwks_uri"` 텍스트를 찾습니다. `"jwks_uri"` 텍스트 바로 뒤에 콜론(:)과 URL이 보입니다. 그 URL의 정규화된 도메인 이름을 복사합니다. `https://` 또는 최상위 도메인 다음에 오는 경로는 포함하지 마세요.

   ```
   {
    "issuer": "https://accounts.example.com",
    "authorization_endpoint": "https://accounts.example.com/o/oauth2/v2/auth",
    "device_authorization_endpoint": "https://oauth2.exampleapis.com/device/code",
    "token_endpoint": "https://oauth2.exampleapis.com/token",
    "userinfo_endpoint": "https://openidconnect.exampleapis.com/v1/userinfo",
    "revocation_endpoint": "https://oauth2.exampleapis.com/revoke",
    "jwks_uri": "https://www.exampleapis.com/oauth2/v3/certs",
   ...
   ```

1. OpenSSL 명령줄 도구를 사용하여 다음 명령을 실행합니다. 이때 *keys.example.com*을 [Step 3](#thumbstep2)에서 얻은 도메인 이름으로 바꿉니다.

   ```
   openssl s_client -servername keys.example.com -showcerts -connect keys.example.com:443
   ```

1. 명령 창에서 다음 예제와 비슷한 인증서가 보일 때까지 위로 스크롤합니다. 인증서가 두 개 이상 있을 경우 명령 출력의 하단에서 표시된 마지막 인증서를 찾습니다. 여기에는 인증 기관 체인의 최상위 중간 CA 인증서가 포함됩니다.

   ```
   -----BEGIN CERTIFICATE-----
    MIICiTCCAfICCQD6m7oRw0uXOjANBgkqhkiG9w0BAQUFADCBiDELMAkGA1UEBhMC
    VVMxCzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6
    b24xFDASBgNVBAsTC0lBTSBDb25zb2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAd
    BgkqhkiG9w0BCQEWEG5vb25lQGFtYXpvbi5jb20wHhcNMTEwNDI1MjA0NTIxWhcN
    MTIwNDI0MjA0NTIxWjCBiDELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMRAwDgYD
    VQQHEwdTZWF0dGxlMQ8wDQYDVQQKEwZBbWF6b24xFDASBgNVBAsTC0lBTSBDb25z
    b2xlMRIwEAYDVQQDEwlUZXN0Q2lsYWMxHzAdBgkqhkiG9w0BCQEWEG5vb25lQGFt
    YXpvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMaK0dn+a4GmWIWJ
    21uUSfwfEvySWtC2XADZ4nB+BLYgVIk60CpiwsZ3G93vUEIO3IyNoH/f0wYK8m9T
    rDHudUZg3qX4waLG5M43q7Wgc/MbQITxOUSQv7c7ugFFDzQGBzZswY6786m86gpE
    Ibb3OhjZnzcvQAaRHhdlQWIMm2nrAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAtCu4
    nUhVVxYUntneD9+h8Mg9q6q+auNKyExzyLwaxlAoo7TJHidbtS4J5iNmZgXL0Fkb
    FFBjvSfpJIlJ00zbhNYS5f6GuoEDmFJl0ZxBHjJnyp378OD8uTs7fLvjx79LjSTb
    NYiytVbZPQUQ5Yaxu2jXnimvw3rrszlaEXAMPLE=
    -----END CERTIFICATE-----
   ```

   인증서를 복사해(`-----BEGIN CERTIFICATE-----` 및 `-----END CERTIFICATE-----` 줄 포함) 텍스트 파일에 붙여 넣습니다. 그 다음에 그 파일을 **certificate.crt**라는 이름으로 저장합니다.
**참고**  
OIDC ID 제공업체의 인증서 체인은 도메인 또는 발급자 URL로 시작하고, 중간 인증서(있는 경우)를 포함하고, 루트 인증서로 끝나야 합니다. 인증서 체인 순서가 다른 경우 또는 중복되거나 추가 인증서가 포함된 경우 서명 불일치 오류가 발생하고 STS는 JSON 웹 토큰(JWT) 유효성 검사에 실패합니다. 서버에서 반환된 체인의 인증서 순서를 수정하여 오류를 해결하세요. 인증서 체인 표준에 대한 자세한 내용은 RFC 시리즈 웹 사이트에서 [RFC 5246의 certificate\$1list](https://www.rfc-editor.org/rfc/rfc5246#section-7.4.2)를 참조하세요.

1. OpenSSL 명령줄 도구를 사용하여 다음 명령을 실행합니다.

   ```
   openssl x509 -in certificate.crt -fingerprint -sha1 -noout
   ```

   다음 예제와 비슷한 인증서 지문이 명령 창에 표시됩니다.

   ```
   SHA1 Fingerprint=99:0F:41:93:97:2F:2B:EC:F1:2D:DE:DA:52:37:F9:C9:52:F2:0D:9E
   ```

   이 문자열에서 콜론 문자(:)를 제거하여 다음과 같은 최종 지문을 생성합니다.

   ```
   990F4193972F2BECF12DDEDA5237F9C952F20D9E
   ```

1. AWS CLI, Tools for Windows PowerShell 또는 IAM API를 사용하여 IAM OIDC ID 제공업체를 생성하는 경우에는 지문 제공이 선택 사항입니다. 생성하는 동안 지문을 포함하지 않기로 선택하면 IAM에서는 OIDC IdP 서버 인증서의 최상위 임시 CA 지문을 검색합니다. IAM OIDC ID 제공업체가 생성되면 이 지문을 IAM에서 검색한 지문과 비교할 수 있습니다.

   IAM 콘솔에서 IAM OIDC ID 제공업체를 생성하면 콘솔에서는 자동으로 OIDC IdP 서버 인증서의 최상위 중간 CA 지문 검색을 시도합니다. 이 지문을 IAM에서 검색한 지문과 비교할 수 있습니다. IAM OIDC ID 제공업체가 생성되면 OIDC 제공업체 **요약** 콘솔 페이지의 **엔드포인트 확인** 탭에서 IAM OIDC ID 제공업체의 지문을 볼 수 있습니다.
**중요**  
가져온 지문이 IAM OIDC ID 제공업체 지문 세부 정보에 표시되는 지문과 일치하지 않으면 OIDC 제공업체를 사용하지 않아야 합니다. 그 대신에, 생성된 OIDC 제공업체를 삭제한 다음에 시간이 조금 지난 후 OIDC 제공업체 생성을 다시 시도해야 합니다. 제공업체를 사용하기 전에 지문이 일치하는지 확인하세요. 두 번째 시도 후에도 지문이 여전히 일치하지 않을 경우에는 [IAM 포럼](https://forums.aws.amazon.com/forum.jspa?forumID=76)을 통해 AWS에 문의하세요.

## OpenSSL 설치
<a name="oidc-install-openssl"></a>

아직 OpenSSL을 설치하지 않았다면 이 단원에 나오는 지침을 따르세요.

**Linux 또는 Unix에서 OpenSSL을 설치하려면**

1. [OpenSSL: Source, Tarballs](https://openssl.org/source/)(https://openssl.org/source/)로 이동합니다.

1. 최신 소스를 다운로드하여 패키지를 생성합니다.

**Windows에서 OpenSSL을 설치하려면**

1. Windows 버전을 설치할 수 있는 사이트 목록을 보려면 [OpenSSL: Binary Distributions](https://wiki.openssl.org/index.php/Binaries)(https://wiki.openssl.org/index.php/Binaries)로 이동합니다.

1. 선택한 사이트의 지침을 따라 설치를 시작합니다.

1. **Microsoft Visual C\$1\$1 2008 재배포 가능 패키지** 설치를 묻는 메시지가 표시되고 아직 시스템에 설치되지 않았다면 환경에 적합한 다운로드 링크를 선택합니다. **Microsoft Visual C\$1\$1 2008 재배포 가능 패키지 설치 마법사**의 지시를 따릅니다.
**참고**  
시스템에 Microsoft Visual C\$1\$1 2008 Redistributables가 설치되어 있는지 알 수 없는 경우 OpenSSL을 먼저 설치합니다. Microsoft Visual C\$1\$1 2008 Redistributables가 설치되지 않은 경우에는 OpenSSL 설치 관리자에 알림이 표시됩니다. 설치할 OpenSSL 버전에 해당하는 아키텍처(32비트 또는 64비트)를 설치해야 합니다.

1. Microsoft Visual C\$1\$1 2008 Redistributables를 설치한 후에는 환경에 맞는 OpenSSL 바이너리를 선택하고 파일을 로컬 위치에 저장합니다. **OpenSSL 설치 마법사**를 시작합니다.

1. **OpenSSL 설치 마법사**의 지시에 따릅니다.

## OpenSSL 구성
<a name="oidc-configure-openssl"></a>

OpenSSL 명령을 사용하려면 OpenSSL이 설치된 위치 정보가 담기도록 운영 체제를 구성해야 합니다.

**Linux 또는 Unix에서 OpenSSL을 구성하려면**

1. 명령줄에서 `OpenSSL_HOME` 변수를 OpenSSL 설치 위치로 설정합니다.

   ```
   $ export OpenSSL_HOME=path_to_your_OpenSSL_installation
   ```

1. OpenSSL 설치가 포함되도록 경로를 설정합니다.

   ```
   $ export PATH=$PATH:$OpenSSL_HOME/bin
   ```
**참고**  
`export` 명령을 사용하여 변경한 환경 변수는 현재 세션에만 유효합니다. 쉘 구성 파일에서 설정하면 환경 변수의 영구 변경이 가능합니다. 자세한 내용은 운영 체제 설명서를 참조하세요.

**Windows에서 OpenSSL을 구성하려면**

1. **명령 프롬프트** 창을 엽니다.

1. `OpenSSL_HOME` 변수를 OpenSSL 설치 위치로 설정합니다.

   ```
   C:\> set OpenSSL_HOME=path_to_your_OpenSSL_installation
   ```

1. `OpenSSL_CONF` 변수를 OpenSSL 설치에 있는 구성 파일 위치로 설정합니다.

   ```
   C:\> set OpenSSL_CONF=path_to_your_OpenSSL_installation\bin\openssl.cfg
   ```

1. OpenSSL 설치가 포함되도록 경로를 설정합니다.

   ```
   C:\> set Path=%Path%;%OpenSSL_HOME%\bin
   ```
**참고**  
**명령 프롬프트** 창에서 변경한 Windows 환경 변수는 현재 명령줄 세션에만 유효합니다. 환경 변수를 시스템 속성으로 설정하면 환경 변수의 영구 변경이 가능합니다. 정확한 절차는 사용 중인 Windows 버전에 따라 달라집니다. 예를 들어 Windows 7에서는 **제어판**, **시스템 및 보안**, **시스템**을 연 다음 **고급 시스템 설정**, **고급** 탭, **환경 변수(Environment Variables)**를 선택합니다. 자세한 내용은 Windows 설명서를 참조하세요.

# 공유 OIDC 공급자의 ID 공급자 제어
<a name="id_roles_providers_oidc_secure-by-default"></a>

인식된 공유 OpenID Connect(OIDC) ID 공급자(IdP)의 경우 IAM은 역할 신뢰 정책의 특정 클레임을 명시적으로 평가해야 합니다. **ID 공급자 제어라고 하는 이러한 필수 클레임은 역할 생성 및 신뢰 정책 업데이트 중에 IAM에 의해 평가됩니다. 역할 신뢰 정책에서 공유 OIDC IdP에 필요한 제어를 평가하지 않으면 역할 생성 또는 업데이트가 실패합니다. 이를 통해 의도한 조직의 승인된 자격 증명만 역할을 수임하고 AWS 리소스에 액세스할 수 있습니다. 이 보안 제어는 OIDC 공급자가 여러 AWS 고객 사이에서 공유되는 경우 매우 중요합니다.



ID 공급자 제어는 IAM에서 기존 OIDC 역할 신뢰 정책에 대해 평가하지 않습니다. 기존 OIDC 역할의 역할 신뢰 정책을 수정하는 경우 IAM은 ID 공급자 제어를 역할 신뢰 정책에 포함해야 합니다.

## OIDC 공급자 유형
<a name="id_roles_providers_oidc_idp_types"></a>

IAM은 OIDC ID 공급자를 ****프라이빗 및 ****공유라는 두 가지 개별 유형으로 분류합니다. 프라이빗 OIDC IdP는 단일 조직에서 소유 및 관리하거나 해당 조직에 고유한 식별자 역할을 하는 OIDC 발행자 URL을 포함하는 SaaS 공급자의 테넌트일 수 있습니다. 반대로 공유 OIDC IdP는 여러 조직에서 사용되고, OIDC 발행자 URL은 해당 ID 공급자를 사용하는 모든 조직에서 동일할 수 있습니다.

아래 표에는 프라이빗 OIDC 공급자와 공유 OIDC 공급자 사이의 주요 차이점이 요약되어 있습니다.


| 기능 | 프라이빗 OIDC 공급자 | 공유 OIDC 공급자 | 
| --- | --- | --- | 
|  Issuer  |  조직에 고유함  |  여러 조직에서 공유  | 
|  테넌시 정보  |  고유 발행자를 통해 전달됨  |  JWT에서 클레임을 통해 전달됨  | 
|  신뢰 정책 요구 사항  |  특정 클레임 평가 불필요  |  특정 클레임 평가 필요  | 

## ID 공급자 제어가 포함된 공유 OIDC ID 공급자
<a name="id_roles_providers_oidc_idp_shared_oidc_secure_support"></a>

IAM에서 OIDC 공급자를 생성하거나 수정할 때 시스템은 인식된 공유 OIDC 공급자에 필요한 클레임을 자동으로 식별하고 평가합니다. 역할 신뢰 정책에 ID 공급자 제어가 구성되지 않은 경우 역할 생성 또는 업데이트가 실패하고 MalformedPolicyDocument 오류가 발생합니다.

다음 표에는 역할 신뢰 정책에서 ID 제공업체 제어가 필요한 공유 OIDC 제공업체 및 ID 제공업체 제어를 구성하는 데 도움이 되는 추가 정보가 나와 있습니다.


| OIDC IdP | OIDC URL | 테넌시 클레임 | 필수 클레임 | 
| --- | --- | --- | --- | 
| [Amazon Cognito](https://docs.aws.amazon.com/cognito/latest/developerguide/iam-roles.html) |  `cognito-identity.amazonaws.com`  | aud |  `cognito-identity.amazonaws.com:aud`  | 
| [Azure Sentinel](https://learn.microsoft.com/en-us/azure/defender-for-cloud/sentinel-connected-aws) |  https://sts.windows.net/33e01921-4d64-4f8c-a055-5bdaffd5e33d  |  sts:RoleSessionName  |  sts:RoleSessionName  | 
| [Buildkite](https://buildkite.com/docs/pipelines/security/oidc/aws) |  https://agent.buildkite.com  |  sub  |  agent.buildkite.com:sub  | 
| [Codefresh SaaS](https://codefresh.io/docs/docs/integrations/oidc-pipelines/) | https://oidc.codefresh.io | sub |  oidc.codefresh.io:sub  | 
| [DVC Studio](https://dvc.org/doc/studio/user-guide/openid-connect) | https://studio.datachain.ai/api | sub |  studio.datachain.ai/api:sub  | 
| [GitHub 작업](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services) | https://token.actions.githubusercontent.com | sub |  token.actions.githubusercontent.com:sub  | 
| [GitHub 감사 로그 스트리밍](https://docs.github.com/en/enterprise-cloud@latest/admin/monitoring-activity-in-your-enterprise/reviewing-audit-logs-for-your-enterprise/streaming-the-audit-log-for-your-enterprise) | https://oidc-configuration.audit-log.githubusercontent.com | sub |  oidc-configuration.audit-log.githubusercontent.com:sub  | 
| [GitHub vstoken](https://docs.github.com/en/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services) | https://vstoken.actions.githubusercontent.com | sub |  vstoken.actions.githubusercontent.com:sub  | 
| [GitLab](https://docs.gitlab.com/ci/cloud_services/aws/) | https://gitlab.com | sub |  gitlab.com:sub  | 
| [IBM Turbonomic SaaS\$1](https://www.ibm.com/docs/en/tarm/8.16.x?topic=turbonomic-setting-up-aws-iam-role-saas-deployments) |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_roles_providers_oidc_secure-by-default.html)  | sub |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_roles_providers_oidc_secure-by-default.html)  | 
| [Pulumi Cloud](https://www.pulumi.com/docs/pulumi-cloud/deployments/oidc/aws/) | https://api.pulumi.com/oidc | aud |  api.pulumi.com/oidc:aud  | 
| [sandboxes.cloud](https://docs.sandboxes.cloud/docs/cloud-resources-setup) | https://sandboxes.cloud | aud |  sandboxes.cloud:aud  | 
| [Scalr](https://docs.scalr.io/docs/aws) | https://scalr.io | sub |  scalr.io:sub  | 
| [Shisho Cloud](https://shisho.dev/docs/g/getting-started/integrate-apps/aws/) | https://tokens.cloud.shisho.dev | sub |  tokens.cloud.shisho.dev:sub  | 
| [Terraform Cloud](https://developer.hashicorp.com/terraform/cloud-docs/workspaces/dynamic-provider-credentials/aws-configuration) | https://app.terraform.io | sub |  app.terraform.io:sub  | 
| [Upbound](https://docs.upbound.io/providers/provider-aws/authentication/) | https://proidc.upbound.io | sub |  proidc.upbound.io:sub  | 
| [Vercel 글로벌 엔드포인트](https://vercel.com/docs/oidc/reference) | https://oidc.vercel.com | aud |  oidc.vercel.com:aud  | 

\$1 IBM Turbonomic은 주기적으로 OIDC 발행자 URL을 플랫폼의 새 버전으로 업데이트합니다. 필요에 따라 범위에 Turbonomic OIDC 발행자가 공유 공급자로 추가될 예정입니다.

IAM에서 공유로 식별하는 새 OIDC IdP의 경우 역할 신뢰 정책에 필요한 ID 공급자 제어가 유사한 방식으로 문서화 및 적용됩니다.

## 추가 리소스
<a name="concept_additional_resources"></a>

추가 리소스:
+ OIDC 페더레이션을 IAM 역할 생성에 대한 자세한 정보는 [OpenID Connect 페더레이션을 위한 역할 생성(콘솔)](id_roles_create_for-idp_oidc.md) 섹션을 참조하세요.
+ 클레임에 사용할 수 있는 IAM 조건 키 목록은 [AWS OIDC 페더레이션에서 사용 가능한 키](reference_policies_iam-condition-keys.md#condition-keys-wif)를 참조하세요.

# SAML 2.0 연동
<a name="id_roles_providers_saml"></a>

AWS는 많은 자격 증명 공급자(IdP)가 사용하는 개방형 표준인 [SAML 2.0(Security Assertion Markup Language 2.0)](https://wiki.oasis-open.org/security)이라는 아이덴티티 페더레이션을 지원합니다. 이 기능은 페더레이션 Single Sign-On(SSO)을 활성화하므로 조직의 모든 구성원에 대해 IAM 사용자를 생성하지 않아도 사용자가 AWS Management Console에 로그인하거나 AWS API 작업을 호출할 수 있습니다. SAML을 사용함으로써 AWS로 연동을 구성하는 과정을 단순화할 수 있는데, 이는 [사용자 지정 자격 증명 프록시 코드](https://docs.aws.amazon.com/STS/latest/UsingSTS/CreatingFedTokens.html)를 작성하는 대신 IdP의 서비스를 사용할 수 있기 때문입니다.

**참고**  
IAM SAML ID 페더레이션은 SAML 기반 페더레이션 ID 제공업체(IdP)의 암호화된 SAML 응답을 지원합니다. IAM Identity Center와 Amazon Cognito는 IAM SAML 자격 증명 공급자의 암호화된 SAML 어설션을 지원하지 않습니다.  
Amazon Cognito 사용자 풀을 사용하여 Amazon Cognito 자격 증명 풀 페더레이션에 암호화된 SAML 어설션 지원을 간접적으로 추가할 수 있습니다. 사용자 풀에는 IAM SAML 페더레이션과 독립적이며 [SAML 서명 및 암호화](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-SAML-signing-encryption.html)를 지원하는 SAML 페더레이션이 있습니다. 이 기능이 자격 증명 풀로 직접 확장되지는 않지만 사용자 풀은 자격 증명 풀의 IdP가 될 수 있습니다. 자격 증명 풀에서 SAML 암호화를 사용하려면 암호화가 적용된 SAML 공급자를 자격 증명 풀의 IdP인 사용자 풀에 추가하세요.  
SAML 공급자는 사용자 풀이 제공하는 키를 사용하여 SAML 어설션을 암호화할 수 있어야 합니다. 사용자 풀은 IAM이 제공한 인증서로 암호화된 어설션을 수락하지 않습니다.

IAM 페더레이션은 다음과 같은 사용 사례를 지원합니다.
+ [**조직의 사용자 또는 애플리케이션이 AWS API 작업을 호출할 수 있도록 허용하는 페더레이션 액세스**](#CreatingSAML-configuring). 이 사용 사례는 다음 섹션에서 설명합니다. 조직에서 생성되는 SAML 어설션(인증 응답의 일부)을 사용해 임시 보안 자격 증명을 얻습니다. 이 시나리오는 [임시 보안 자격 증명 요청](id_credentials_temp_request.md) 및 [OIDC 페더레이션](id_roles_providers_oidc.md)에 기술된 것과 같이 IAM이 지원하는 다른 페더레이션 시나리오와 유사합니다. 그러나 조직의 SAML 2.0 기반 IdP가 인증 수행 및 권한 부여 확인을 위한 세부 사항을 런타임에 대부분 처리합니다.
+ [**조직에서 AWS Management Console로 이루어지는 웹 기반 SSO(Single Sign-On)**](id_roles_providers_enable-console-saml.md). 사용자가 SAML 2.0 호환 IdP에서 호스팅하는 조직의 포털에 로그인하고 AWS로 이동하는 옵션을 선택하면 추가 로그인 정보를 제공하지 않고도 콘솔에 리디렉션될 수 있습니다. 타사 SAML IdP를 사용하여 콘솔에 SSO 액세스하거나 사용자 지정 IdP를 만들어 외부 사용자의 콘솔 액세스를 허용할 수 있습니다. 사용자 지정 IdP를 구축하는 방법에 대한 자세한 정보는 [AWS 콘솔에 대한 사용자 지정 ID 브로커 액세스 활성화](id_roles_providers_enable-console-custom-url.md)를 참조하세요.

**Topics**
+ [

## AWS에 대한 API 액세스를 위해 SAML 기반 페더레이션 사용
](#CreatingSAML-configuring)
+ [

## SAML 2.0 기반 페더레이션 구성 개요
](#CreatingSAML-configuring-IdP)
+ [

## AWS 리소스에 대한 SAML 페더레이션 액세스를 허용하는 역할 개요
](#CreatingSAML-configuring-role)
+ [

## SAML 기반 페더레이션에서 사용자를 고유하게 식별
](#CreatingSAML-userid)
+ [

# IAM에서 SAML ID 공급자 생성
](id_roles_providers_create_saml.md)
+ [

# 신뢰 당사자 신뢰 및 클레임 추가를 통해 SAML 2.0 IdP 구성
](id_roles_providers_create_saml_relying-party.md)
+ [

# 서드 파티 SAML 솔루션 공급자를 AWS와 통합
](id_roles_providers_saml_3rd-party.md)
+ [

# 인증 응답에 대한 SAML 어설션 구성
](id_roles_providers_create_saml_assertions.md)
+ [

# SAML 2.0 페더레이션 위탁자의 AWS Management Console 액세스 활성화
](id_roles_providers_enable-console-saml.md)
+ [

# 브라우저에서 SAML 응답 보기
](troubleshoot_saml_view-saml-response.md)

## AWS에 대한 API 액세스를 위해 SAML 기반 페더레이션 사용
<a name="CreatingSAML-configuring"></a>

직원들에게 자신의 컴퓨터에서 백업 폴더로 데이터를 복사하는 방법을 제공하려 한다고 가정해 봅시다. 사용자가 컴퓨터에서 실행하는 애플리케이션을 구축합니다. 이 애플리케이션은 백엔드에서 Amazon S3 버킷에 있는 객체를 읽고 씁니다. 사용자는 AWS에 직접 액세스할 수 없습니다. 그 대신 다음 프로세스를 사용합니다.

![\[SAML 어설션에 기반을 두어 임시 보안 자격 증명 얻기\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/saml-based-federation-diagram.png)


1. 조직 내 사용자가 클라이언트 앱을 사용해 조직의 IdP로부터 인증을 요청합니다.

1. IdP가 조직의 자격 증명 스토어를 이용하여 사용자를 인증합니다.

1. IdP가 사용자에 대한 정보로 SAML 어설션을 만들어 클라이언트 앱으로 보냅니다. IAM SAML IdP에 SAML 암호화를 활성화하면 이 어설션이 외부 IdP에 의해 암호화됩니다.

1. 클라이언트 앱이 AWS STS[https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) API를 호출하면서 SAML 공급자의 ARN, 수임할 역할의 ARN, IdP로부터 받은 SAML 어설션을 전달합니다. 암호화가 활성화된 경우 클라이언트 앱을 통해 전달되는 어설션은 전송 중에도 암호화된 상태로 유지됩니다.

1. (선택 사항) AWS STS는 외부 IdP에서 업로드한 프라이빗 키를 사용하여 암호화된 SAML 어설션을 복호화합니다.

1. 클라이언트 앱에 대한 API 응답에는 임시 보안 자격 증명이 포함되어 있습니다.

1. 클라이언트 앱이 임시 보안 자격 증명을 사용하여 Amazon S3 API 작업을 호출합니다.

## SAML 2.0 기반 페더레이션 구성 개요
<a name="CreatingSAML-configuring-IdP"></a>

앞의 시나리오와 다이어그램을 통해 설명한 대로 SAML 2.0 기반 페더레이션을 사용하기 전에, 서로를 신뢰하도록 조직의 IdP와 AWS 계정을 구성해야 합니다. 이 신뢰를 구성하는 일반적인 프로세스는 다음 단계에서 설명합니다. 조직 내에는 Microsoft Active Directory 연동 서비스(AD FS, Windows Server의 일부), Shibboleth 또는 기타 호환 가능한 SAML 2.0 공급자와 같이 [SAML 2.0을 지원하는 IdP](id_roles_providers_saml_3rd-party.md)가 반드시 있어야 합니다.

**참고**  
페더레이션 복원력을 개선하려면 여러 SAML 로그인 엔드포인트를 지원하도록 IdP 및 AWS 페더레이션을 구성하는 것이 좋습니다. 자세한 내용은 AWS 보안 블로그 문서 [How to use regional SAML endpoints for failover](https://aws.amazon.com/blogs//security/how-to-use-regional-saml-endpoints-for-failover)(장애 조치에 리전 SAML 엔드포인트를 사용하는 방법)를 참조하세요.

**조직의 IdP와 AWS가 서로 신뢰하도록 구성**

1. AWS를 조직의 IdP에 서비스 제공업체(SP)로 등록합니다. `https://region-code.signin.aws.amazon.com/static/saml-metadata.xml` 의 SAML 메타데이터 문서를 사용합니다.

   가능한 *region-code* 값 목록은 [AWS 로그인 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)의 **리전(Region)** 열을 참조하세요.

   필요에 따라 `https://signin.aws.amazon.com/static/saml-metadata.xml` 에서 SAML 메타데이터 문서를 사용할 수 있습니다.

1. <a name="createxml"></a>조직의 IdP를 사용하여 IdP를 AWS에서 IAM ID 제공업체로 기술할 수 있는 동등한 SAML 메타데이터 XML 파일을 생성합니다. 그 파일에는 발급자 이름, 생성 일자, 만료 일자 및 AWS가 조직에서 오는 인증 응답의 유효성을 검증하는 데 사용할 수 있는 키가 포함되어 있어야 합니다.

   암호화된 SAML 어설션이 외부 IdP에서 전송되도록 허용하는 경우 조직의 IdP를 사용하여 프라이빗 키 파일을 생성하고 이 파일을 IAM SAML 구성에 .pem 파일 형식으로 업로드해야 합니다. AWS STS는 IdP에 업로드된 퍼블릭 키에 해당하는 SAML 응답을 복호화하기 위해 이 프라이빗 키가 필요합니다.
**참고**  
[SAML V2.0 Metadata Interoperability Profile Version 1.0](https://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-iop-os.html)의 정의에 따라, IAM은 SAML 메타데이터 문서의 X.509 인증서 만료를 평가하거나 이에 대해 조치를 취하지 않습니다. 만료된 X.509 인증서가 우려되는 경우 조직의 거버넌스 및 보안 정책에 따라 인증서 만료 날짜를 모니터링하고 인증서를 교체하는 것이 좋습니다.

1. <a name="samlovrcreateentity"></a>IAM 콘솔에서 SAML 자격 증명 공급자를 생성합니다. 이 과정에서 SAML 메타데이터 문서와 조직의 IdP가 [Step 2](#createxml)에서 생성한 프라이빗 복호화 키를 업로드합니다. 자세한 내용은 [IAM에서 SAML ID 공급자 생성](id_roles_providers_create_saml.md) 섹션을 참조하세요.

1. <a name="samlovrcreaterole"></a>IAM에서 하나 이상의 IAM 역할을 생성합니다. 역할의 신뢰 정책에서 SAML 공급자를 보안 주체로 설정함으로써 조직과 AWS 사이에 신뢰 관계를 설정합니다. 역할의 권한 정책은 조직의 사용자가 AWS에서 하도록 허용된 것을 설정합니다. 자세한 내용은 [타사 ID 공급자에 대한 역할 생성](id_roles_create_for-idp.md) 섹션을 참조하세요.
**참고**  
역할 신뢰 정책에 사용되는 SAML IDP는 해당 역할이 속한 계정과 동일한 계정에 있어야 합니다.

1. 조직의 IdP에서 조직의 사용자 또는 그룹을 IAM 역할로 매핑하는 어설션을 정의합니다. 조직의 다양한 사용자 및 그룹은 서로 다른 IAM 역할에 매핑될 수 있다는 점에 유의하세요. 매핑 수행을 위한 정확한 절차는 사용하고 있는 IdP에 따라 다릅니다. 사용자의 경우 Amazon S3 폴더에 대한 [앞의 시나리오](#CreatingSAML-configuring)에서 모든 사용자가 Amazon S3 권한을 제공하는 동일한 역할에 매핑될 수 있습니다. 자세한 내용은 [인증 응답에 대한 SAML 어설션 구성](id_roles_providers_create_saml_assertions.md) 섹션을 참조하세요.

   IdP가 AWS 콘솔에 대한 SSO를 지원하는 경우, 콘솔 세션의 최대 지속 기간을 구성할 수 있습니다. 자세한 내용은 [SAML 2.0 페더레이션 위탁자의 AWS Management Console 액세스 활성화](id_roles_providers_enable-console-saml.md) 섹션을 참조하세요.

1. 생성 중인 애플리케이션에서 AWS Security Token Service `AssumeRoleWithSAML` API를 호출해 그것을 [Step 3](#samlovrcreateentity) 단계에서 생성한 SAML 공급자의 ARN, [Step 4](#samlovrcreaterole) 단계에서 생성한 수임할 역할의 ARN 및 IdP에서 얻는 현재 사용자에 대한 SAML 어설션으로 전달합니다. AWS는 역할 수임 요청이 SAML 공급자에서 참조된 IdP로부터 오는지 확인합니다.

   자세한 내용은 *AWS Security Token Service API 참조*의 [AssumeRoleWithSAML](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html)을 참조하세요.

1. 요청이 성공하면 API는 일련의 임시 보안 자격 증명을 반환하고 애플리케이션은 이를 사용해 AWS에 서명된 요청을 보냅니다. 애플리케이션은 현재 사용자에 대한 정보를 갖고 있어서 이전 시나리오에 설명된 대로 Amazon S3의 사용자별 폴더에 액세스할 수 있습니다.

## AWS 리소스에 대한 SAML 페더레이션 액세스를 허용하는 역할 개요
<a name="CreatingSAML-configuring-role"></a>

IAM에서 생성하는 역할에서는 조직의 SAML 페더레이션 보안 주체가 AWS에서 무엇을 할 수 있는지를 정의합니다. 역할에 대한 신뢰 정책을 생성할 때 앞서 생성한 SAML 공급자를 `Principal`로 지정합니다. `Condition`으로 신뢰 정책을 추가로 자세히 살펴봄으로써 특정 SAML 속성과 일치하는 사용자만 그 역할에 액세스하도록 허용할 수 있습니다. 예를 들어 다음 샘플 정책에 설명되어 있듯이 SAML 소속이 `staff`(https://openidp.feide.no에 의해 어설션되듯이)인 사용자만이 그 역할에 액세스할 수 있도록 지정할 수 있습니다.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Federated": "arn:aws:iam::111122223333:saml-provider/ExampleOrgSSOProvider"},
    "Action": "sts:AssumeRoleWithSAML",
    "Condition": {
      "StringEquals": {
        "saml:aud": "https://us-east-1.signin.aws.amazon.com/saml",
        "saml:iss": "https://openidp.feide.no"
      },
      "ForAllValues:StringLike": {"saml:edupersonaffiliation": ["staff"]}
    }
  }]
}
```

------

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws-cn:iam::111122223333:saml-provider/ExampleOrgSSOProvider"
            },
            "Action": "sts:AssumeRoleWithSAML",
            "Condition": {
                "StringEquals": {
                    "saml:aud": "https://ap-east-1.signin.amazonaws.cn/saml",
                    "saml:iss": "https://openidp.feide.no"
                },
                "ForAllValues:StringLike": {
                    "saml:edupersonaffiliation": [
                        "staff"
                    ]
                }
            }
        }
    ]
}
```

------

**참고**  
역할 신뢰 정책에 사용되는 SAML IDP는 해당 역할이 속한 계정과 동일한 계정에 있어야 합니다.

정책의 `saml:aud` 컨텍스트 키는 콘솔에 로그인할 때 브라우저에서 표시하는 URL을 지정합니다. 이 로그인 엔드포인트 URL은 ID 제공업체의 수신자 속성과 일치해야 합니다. 특정 리전 내에 로그인 URL을 포함할 수 있습니다. AWS에서는 페더레이션 복원력을 개선하기 위해 글로벌 엔드포인트 대신 리전별 엔드포인트를 사용할 것을 권장합니다. 엔드포인트가 하나만 구성되면 엔드포인트를 사용할 수 없게 되는 드문 경우 AWS에 페더레이션할 수 없습니다. 가능한 *region-code* 값 목록은 [AWS 로그인 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)의 **리전(Region)** 열을 참조하세요.

다음 예제에서는 선택 사항인 `region-code`가 포함된 로그인 URL 형식을 보여줍니다.

`https://region-code.signin.aws.amazon.com/saml`

SAML 암호화가 필요한 경우 로그인 URL에는 AWS가 SAML 공급업체에 할당하는 고유 식별자가 포함되어야 하며, 이 식별자는 ID 제공업체 세부 정보 페이지에서 확인할 수 있습니다. 다음 예제에서 로그인 URL에는 로그인 경로에 /acs/를 추가해야 하는 IdP 고유 식별자가 포함됩니다.

`https://region-code.signin.aws.amazon.com/saml/acs/IdP-ID`

해당 역할의 권한 정책에 대해서는, 역할에 사용하는 방식으로 권한을 지정합니다. 예를 들어 조직의 사용자가 Amazon Elastic Compute Cloud 인스턴스를 관리할 수 있는 경우 **AmazonEC2FullAccess** 관리형 정책에서처럼 권한 정책에서 Amazon EC2 작업을 명시적으로 허용해야 합니다.

정책에서 확인할 수 있는 SAML 키에 대한 자세한 정보는 [SAML 기반 AWS STS 연동에 사용할 수 있는 키](reference_policies_iam-condition-keys.md#condition-keys-saml) 섹션을 참조하세요.

## SAML 기반 페더레이션에서 사용자를 고유하게 식별
<a name="CreatingSAML-userid"></a>

IAM에서 액세스 정책을 생성할 때 사용자의 자격 증명을 기반으로 권한을 지정할 수 있으면 종종 쓸모가 있습니다. 예를 들어 SAML을 사용하여 페더레이션된 사용자의 경우 애플리케이션에서 Amazon S3에 정보를 다음과 같은 구조를 사용하여 저장할 수 있습니다.

```
amzn-s3-demo-bucket/app1/user1
amzn-s3-demo-bucket/app1/user2
amzn-s3-demo-bucket/app1/user3
```

버킷(`amzn-s3-demo-bucket`)과 폴더(`app1`)는 정적 값이므로 Amazon S3 콘솔 또는 AWS CLI를 통해 생성할 수 있습니다. 그러나 사용자 고유 폴더(*user1*, *user2*, *user3* 등)는 사용자가 연동 프로세스를 통해 최초로 로그인할 때까지 사용자를 식별하는 값이 알려지지 않기 때문에 코드를 사용해 런타임에 생성되어야 합니다.

사용자 고유의 세부 정보를 리소스 이름의 일부로 참조하는 정책을 작성하려면, 정책 조건에서 사용될 수 있는 SAML 키에서 사용자 자격 증명이 사용 가능해야 합니다. 다음 키는 IAM 정책에서 사용할 SAML 2.0 기반 페더레이션에 사용할 수 있습니다. 다음 키에서 반환되는 값을 사용하여 Amazon S3 폴더와 같은 리소스의 고유한 사용자 식별자를 생성할 수 있습니다.
+ `saml:namequalifier`. `Issuer` 응답 값(`saml:iss`)과 `AWS` 계정 ID 및 IAM에서 SAML 공급자의 표시 이름(ARN의 마지막 부분)을 포함하는 문자열의 연결을 기반으로 하는 해시 값 계정 ID와 SAML 공급자 표시 이름의 연결을 IAM 정책에서 `saml:doc` 키로 사용할 수 있습니다. 계정 ID와 공급자 이름을 "/123456789012/provider\$1name"처럼 '/'로 구분해야 합니다. 자세한 정보는 `saml:doc`의 [SAML 기반 AWS STS 연동에 사용할 수 있는 키](reference_policies_iam-condition-keys.md#condition-keys-saml) 키를 참조하세요.

  `NameQualifier`와 `Subject`의 조합은 SAML 페더레이션 보안 주체를 고유한 이름으로 식별하는 데 사용할 수 있습니다. 다음 유사 코드는 이 값이 계산되는 방식을 보여줍니다. 이 유사 코드에서 `+`는 연결을 나타내고, `SHA1`는 SHA-1을 사용해 메시지 다이제스트를 생성하는 기능을 나타내며, `Base64`는 해시 출력의 Base-64 인코딩 버전을 생성하는 기능을 나타냅니다.

   `Base64 ( SHA1 ( "https://example.com/saml" + "123456789012" + "/MySAMLIdP" ) )` 

   SAML 기반 연동에 사용 가능한 정책 키에 대한 자세한 정보는 다음([SAML 기반 AWS STS 연동에 사용할 수 있는 키](reference_policies_iam-condition-keys.md#condition-keys-saml))을 참조하세요.
+ `saml:sub` (문자열). 이것은 클레임의 주체로서 여기에는 조직 내 사용자 개개인을 식별할 수 있는 고유 값이 포함됩니다(예: `_cbb88bf52c2510eabe00c1642d4643f41430fe25e3`).
+ `saml:sub_type` (문자열). 이 키는 `persistent`, `transient`, 또는 SAML 어설션에서 사용되는 `Format` 및 `Subject` 요소의 전체 `NameID` URI일 수 있습니다. `persistent`라는 값은 `saml:sub`의 값이 모든 세션에 걸쳐 사용자에게 동일하다는 것을 나타냅니다. 값이 `transient`인 경우 각 세션마다 사용자의 `saml:sub` 값이 다릅니다. `NameID` 요소의 `Format` 속성에 대한 자세한 내용은 [인증 응답에 대한 SAML 어설션 구성](id_roles_providers_create_saml_assertions.md) 섹션을 참조하세요.

다음 예에서는 앞의 키를 사용하여 Amazon S3의 사용자별 폴더에 대한 권한을 부여하는 권한 정책을 보여줍니다. 해당 정책에서는 `saml:namequalifier` 및 `saml:sub`를 모두 포함하는 접두사를 사용하여 Amazon S3 객체를 식별한다고 가정합니다. `Condition` 요소에는 `saml:sub_type`이 `persistent`로 설정되어 있는지 확인하는 테스트가 포함되어 있다는 것에 유의하세요. `transient`로 설정되어 있다면 사용자에 대한 `saml:sub` 값은 각 세션마다 다를 수 있고 값의 조합은 사용자 고유 폴더를 식별하는 데 사용되어서는 안 됩니다.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:PutObject",
      "s3:DeleteObject"
    ],
    "Resource": [
      "arn:aws:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}",
      "arn:aws:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}/*"
    ],
    "Condition": {"StringEquals": {"saml:sub_type": "persistent"}}
  }
}
```

------

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": {
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:PutObject",
      "s3:DeleteObject"
    ],
    "Resource": [
      "arn:aws-cn:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}",
      "arn:aws-cn:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}/*"
    ],
    "Condition": {"StringEquals": {"saml:sub_type": "persistent"}}
  }
}
```

------

IdP의 어설션을 정책 키에 매핑하는 것에 대한 자세한 정보는 [인증 응답에 대한 SAML 어설션 구성](id_roles_providers_create_saml_assertions.md) 섹션을 참조하세요.

# IAM에서 SAML ID 공급자 생성
<a name="id_roles_providers_create_saml"></a>

IAM SAML 2.0 자격 증명 공급자는 [SAML 2.0(Security Assertion Markup Language 2.0)](https://wiki.oasis-open.org/security) 표준을 지원하는 외부 자격 증명 공급자(IdP) 서비스를 기술하는 IAM의 엔터티입니다. 사용자가 AWS 리소스에 액세스할 수 있도록 Shibboleth 또는 Active Directory 페더레이션 서비스와 같은 SAML 호환 IdP와 AWS 간에 신뢰를 구축하고자 할 때 IAM ID 제공업체를 사용합니다. IAM SAML 자격 증명 공급자는 IAM 신뢰 정책에서 보안 주체로 사용됩니다.

이 시나리오에 대한 자세한 내용은 [SAML 2.0 연동](id_roles_providers_saml.md)를 참조하세요.

AWS Management Console에서 또는 AWS CLI, Tools for Windows PowerShell 또는 AWS API 호출을 사용하여 IAM 자격 증명 공급자를 생성하고 관리할 수 있습니다.

SAML 공급자를 생성한 후에는 1개 이상의 IAM 역할을 생성해야 합니다. 역할은 AWS의 자격 증명으로서 자신만의 고유한 자격 증명이 없지만(사용자가 그러하듯이), 이 컨텍스트에서는 IdP에서 인증한 SAML 페더레이션 보안 주체에게 역할이 동적으로 할당됩니다. 그 역할은 조직의 IdP가 AWS에 액세스하기 위해 임시 보안 인증을 요청할 수 있도록 허용합니다. 역할에 할당된 정책은 사용자가 AWS에서 허용된 작업이 무엇인지 결정합니다. SAML 연동을 위한 역할을 생성하려면 [타사 ID 공급자에 대한 역할 생성](id_roles_create_for-idp.md) 섹션을 참조하세요.

마지막으로 역할을 만든 후에는 AWS에 대한 정보와 SAML 페더레이션 보안 주체가 사용하기를 원하는 역할로 IdP를 구성하여 SAML 신뢰를 완료합니다. 이를 가리켜 IdP와 AWS 간 신뢰 당사자 신뢰 구성이라고 합니다. 신뢰 당사자 신뢰를 구성하려면 [신뢰 당사자 신뢰 및 클레임 추가를 통해 SAML 2.0 IdP 구성](id_roles_providers_create_saml_relying-party.md) 섹션을 참조하세요.

**Topics**
+ [

## 사전 조건
](#idp-manage-identityprovider-prerequisites)
+ [

## IAM SAML 자격 증명 공급자 생성 및 관리(콘솔)
](#idp-manage-identityprovider-console)
+ [

## SAML 암호화 키 관리
](#id_federation_manage-saml-encryption)
+ [

## IAM SAML 자격 증명 공급자 생성(AWS CLI)
](#idp-create-identityprovider-CLI)
+ [

## IAM SAML 자격 증명 공급자 생성 및 관리(AWS API)
](#idp-create-identityprovider-API)
+ [

## 다음 단계
](#id_roles_create-for-saml-next-steps)

## 사전 조건
<a name="idp-manage-identityprovider-prerequisites"></a>

SAML 자격 증명 공급자를 생성하려면 IdP에서 가져온 다음 정보가 있어야 합니다.
+ IdP에서 SAML 메타데이터 문서를 가져옵니다. 이 문서에는 발급자 이름, 만료 정보 및 IdP에서 가져온 SAML 인증 응답(어설션)을 확인하는 데 사용할 수 있는 키가 포함되어 있습니다. 메타데이터 문서를 생성하려면 외부 IdP가 제공하는 자격 증명 관리 소프트웨어를 사용하세요.
**중요**  
이 메타데이터 파일에는 발급자 이름, 만료 정보 및 IdP에서 가져온 SAML 인증 응답(어설션)을 확인하는 데 사용할 수 있는 키가 포함되어 있습니다. 메타데이터 파일은 바이트 순서 표시(BOM)가 없는 UTF-8 형식으로 인코딩되어야 합니다. BOM을 제거하려면 Notepad\$1\$1와 같은 텍스트 편집 도구를 사용해 파일을 UTF-8로 인코딩합니다.  
SAML 메타데이터 문서의 일부로 포함된 X.509 인증서는 1,024비트 이상의 키 크기를 사용해야 합니다. 또한 X.509 인증서에는 반복되는 확장이 없어야 합니다. 확장을 사용할 수 있지만 확장은 인증서에 한 번만 나타날 수 있습니다. X.509 인증서가 두 조건 중 하나를 충족하지 못하면 IdP 생성에 실패하고 'Unable to parse metadata' 오류를 반환합니다.  
[SAML V2.0 Metadata Interoperability Profile Version 1.0](https://docs.oasis-open.org/security/saml/Post2.0/sstc-metadata-iop-os.html)의 정의에 따라, IAM은 SAML 메타데이터 문서의 X.509 인증서 만료를 평가하거나 이에 대해 조치를 취하지 않습니다. 만료된 X.509 인증서가 우려되는 경우 조직의 거버넌스 및 보안 정책에 따라 인증서 만료 날짜를 모니터링하고 인증서를 교체하는 것이 좋습니다.
+ SAML 암호화를 사용하도록 선택하는 경우 IdP를 사용하여 프라이빗 키 파일을 생성하고 이 파일을 .pem 파일 형식으로 IAM SAML 구성에 업로드해야 합니다. AWS STS는 IdP가 사용하는 퍼블릭 키에 해당하는 SAML 응답을 복호화하기 위해 이 프라이빗 키가 필요합니다. 다음 알고리즘은 지원됩니다.
  + 암호화 알고리즘
    + AES-128
    + AES-256
    + RSA-OAEP
  + 키 전송 알고리즘
    + AES-CBC
    + AES-GCM

  프라이빗 키를 생성하는 단계는 ID 제공업체의 설명서를 참조하세요.
**참고**  
IAM Identity Center와 Amazon Cognito는 IAM SAML 자격 증명 공급자의 암호화된 SAML 어설션을 지원하지 않습니다. Amazon Cognito 사용자 풀을 사용하여 Amazon Cognito 자격 증명 풀 페더레이션에 암호화된 SAML 어설션 지원을 간접적으로 추가할 수 있습니다. 사용자 풀에는 IAM SAML 페더레이션과 독립적이며 [SAML 서명 및 암호화](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-SAML-signing-encryption.html)를 지원하는 SAML 페더레이션이 있습니다. 이 기능이 자격 증명 풀로 직접 확장되지는 않지만 사용자 풀은 자격 증명 풀의 IdP가 될 수 있습니다. 자격 증명 풀에서 SAML 암호화를 사용하려면 암호화가 적용된 SAML 공급자를 자격 증명 풀의 IdP인 사용자 풀에 추가하세요.  
SAML 공급자는 사용자 풀이 제공하는 키를 사용하여 SAML 어설션을 암호화할 수 있어야 합니다. 사용자 풀은 IAM이 제공한 인증서로 암호화된 어설션을 수락하지 않습니다.

필요한 SAML 메타데이터 문서를 생성하는 방법을 비롯해, 사용 가능한 다수의 IdP를 구성하여 AWS에서 작동되도록 하는 방법에 대한 지침은 [서드 파티 SAML 솔루션 공급자를 AWS와 통합](id_roles_providers_saml_3rd-party.md) 섹션을 참조하세요.

SAML 페더레이션에 대한 도움이 필요하면 [SAML 페더레이션 문제 해결](troubleshoot_saml.md)을 참조하세요.

## IAM SAML 자격 증명 공급자 생성 및 관리(콘솔)
<a name="idp-manage-identityprovider-console"></a>

AWS Management Console을 사용하여 IAM SAML 자격 증명 공급자를 생성, 업데이트, 삭제할 수 있습니다. SAML 페더레이션에 대한 도움이 필요하면 [SAML 페더레이션 문제 해결](troubleshoot_saml.md)을 참조하세요.

**IAM SAML 자격 증명 공급자를 생성하려면(콘솔)**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 [**자격 증명 공급자(Identity providers)**]를 선택한 다음 [**공급자 추가(Add provider)**]를 선택합니다.

1. [**공급자 구성(Configure provider)**]에 대해 [**SAML**]을 선택합니다.

1. 자격 증명 공급자의 이름을 입력합니다.

1. [**메타데이터 문서(Metadata document)**에서 [**파일 선택(Choose file)**을 선택하고 [사전 조건](#idp-manage-identityprovider-prerequisites)에서 다운로드한 SAML 메터데이터 문서를 지정합니다.
**참고**  
SAML 메타데이터 문서의 `validUntil` 또는 `cacheDuration` 속성은 ID 공급자의 **유효 종료** 날짜를 정의합니다. SAML 메타데이터 문서에 유효 기간 속성이 포함되어 있지 않으면 **유효 종료** 날짜가 X.509 인증서 만료 날짜와 일치하지 않습니다.  
IAM은 SAML 메타데이터 문서에서 X.509 인증서 만료를 평가하거나 조치를 취하지 않습니다. 만료된 X.509 인증서가 우려되는 경우 조직의 거버넌스 및 보안 정책에 따라 인증서 만료 날짜를 모니터링하고 인증서를 교체하는 것이 좋습니다.

1. (선택 사항) **SAML 암호화**에서 **파일 선택**을 선택하고 [사전 조건](#idp-manage-identityprovider-prerequisites)에서 생성한 프라이빗 키 파일을 선택합니다. IdP로부터 암호화된 요청만 수락하려면 **암호화 필요**를 선택합니다.

1. (선택 사항) **태그 추가(Add tags)**에 키 값 페어를 추가하여 IdP를 식별하고 구성할 수 있습니다. 태그를 사용하여 AWS 리소스에 대한 액세스를 제어할 수도 있습니다. SAML 자격 증명 공급자의 태깅에 대한 자세한 내용은 [IAM SAML ID 제공업체 태깅](id_tags_saml.md) 섹션을 참조하세요.

   **태그 추가**를 선택합니다. 각 태그 키 값 페어의 값을 입력합니다.

1. 제공한 정보를 확인합니다. 완료되면 [**공급자 추가(Add provider)**]를 선택합니다.

1. ID 제공업체에 IAM 역할을 할당하세요. 이 역할은 자격 증명 공급자가 관리하는 외부 사용자 자격 증명에 계정의 AWS 리소스에 대한 액세스 권한을 부여합니다. ID 연동을 위한 역할을 생성하는 방법에 대한 자세한 내용은 [타사 ID 공급자에 대한 역할 생성](id_roles_create_for-idp.md) 섹션을 참조하세요.
**참고**  
역할 신뢰 정책에 사용되는 SAML IDP는 해당 역할이 속한 계정과 동일한 계정에 있어야 합니다.

**SAML 공급자를 삭제하려면(콘솔)**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 [**자격 증명 공급자(Identity providers)**]를 선택합니다.

1. 삭제할 자격 증명 공급자 옆의 라디오 버튼을 선택합니다.

1. **삭제**를 선택합니다. 새 창이 열립니다.

1. 필드에 단어 `delete`를 입력하여 공급자 삭제를 확인합니다. 그런 다음 **삭제**를 선택합니다.

## SAML 암호화 키 관리
<a name="id_federation_manage-saml-encryption"></a>

외부 IdP의 SAML 응답에서 암호화된 어설션을 수신하도록 IAM SAML 공급자를 구성할 수 있습니다. 사용자는 `[sts:AssumeRoleWithSAML](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html)` 호출을 통해 암호화된 SAML 어설션을 사용하여 AWS에서 역할을 맡을 수 있습니다.

SAML 암호화는 어설션이 중개자 또는 서드 파티를 통해 전달될 때 보안을 유지합니다. 또한 이 기능을 사용하면 FedRAMP 또는 SAML 어설션의 암호화를 요구하는 내부 규정 준수 정책 요구 사항을 충족할 수 있습니다.

IAM SAML 자격 증명 공급자를 구성하려면 [IAM에서 SAML ID 공급자 생성](#id_roles_providers_create_saml) 섹션을 참조하세요. SAML 페더레이션에 대한 도움이 필요하면 [SAML 페더레이션 문제 해결](troubleshoot_saml.md)을 참조하세요.

### SAML 암호화 키 교체
<a name="id_federation_manage-saml-keys-rotate"></a>

IAM은 사용자가 IAM SAML 제공업체에 업로드한 프라이빗 키를 사용하여 IdP의 암호화된 SAML 어설션을 복호화합니다. 각 자격 증명 공급자마다 최대 2개의 프라이빗 키 파일을 저장할 수 있으므로 필요에 따라 프라이빗 키를 교체할 수 있습니다. 2개의 파일이 저장되면 각 요청이 먼저 가장 최근의 **다음에 추가됨** 날짜로 복호화를 시도한 다음 IAM이 가장 오래된 **다음에 추가됨** 날짜로 요청 복호화를 시도합니다.

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 탐색 창에서 **자격 증명 공급자**를 선택한 다음 목록에서 공급자를 선택합니다.

1. **SAML 암호화** 탭을 선택하고 **새 키 추가**를 선택합니다.

1. **파일 선택**을 선택하고 IdP에서 다운로드한 프라이빗 키를 .pem 파일로 업로드한 다음 **키 추가**를 선택합니다.

1. **SAML 복호화를 위한 프라이빗 키** 섹션에서 만료된 프라이빗 키 파일을 선택하고 **제거**를 선택합니다. 첫 번째 어설션 복호화 시도가 성공하려면 새 프라이빗 키를 추가한 후 만료된 프라이빗 키를 제거하는 것이 좋습니다.

## IAM SAML 자격 증명 공급자 생성(AWS CLI)
<a name="idp-create-identityprovider-CLI"></a>

AWS CLI를 사용하여 SAML 공급자를 생성, 업데이트, 삭제할 수 있습니다. SAML 페더레이션에 대한 도움이 필요하면 [SAML 페더레이션 문제 해결](troubleshoot_saml.md)을 참조하세요.

**IAM 자격 증명 공급자를 생성하고 메타데이터 문서를 업로드하려면(AWS CLI)**
+ 다음 명령을 실행합니다. [https://docs.aws.amazon.com/cli/latest/reference/iam/create-saml-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/create-saml-provider.html) 

**IAM SAML 자격 증명 공급자를 업데이트하려면(AWS CLI)**

메타데이터 파일과 SAML 암호화 설정을 업데이트하고 IAM SAML 공급자의 프라이빗 키 복호화 파일을 교체할 수 있습니다. 프라이빗 키를 교체하려면 새 프라이빗 키를 추가한 다음 별도의 요청에서 이전 키를 제거합니다. 프라이빗 키 교체에 대한 자세한 내용은 [SAML 암호화 키 관리](#id_federation_manage-saml-encryption) 섹션을 참조하세요.
+ 다음 명령을 실행합니다. [https://docs.aws.amazon.com/cli/latest/reference/iam/update-saml-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/update-saml-provider.html) 

**기존 IAM 자격 증명 공급자를 태깅하려면(AWS CLI)**
+ 다음 명령을 실행합니다. [https://docs.aws.amazon.com/cli/latest/reference/iam/tag-saml-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-saml-provider.html) 

**기존 IAM 자격 증명 공급자의 태그를 나열하려면(AWS CLI)**
+ 다음 명령을 실행합니다. [https://docs.aws.amazon.com/cli/latest/reference/iam/list-saml-provider-tags.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-saml-provider-tags.html) 

**기존 IAM 자격 증명 공급자에서 태그를 제거하려면(AWS CLI)**
+ 다음 명령을 실행합니다. [https://docs.aws.amazon.com/cli/latest/reference/iam/untag-saml-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-saml-provider.html) 

**IAM SAML 자격 증명 공급자를 삭제하려면(AWS CLI)**

1. (선택 사항) ARN, 생성 날짜, 만료 등 모든 공급자에 대한 정보를 나열하려면 다음 명령을 실행합니다.
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/list-saml-providers.html](https://docs.aws.amazon.com/cli/latest/reference/iam/list-saml-providers.html)

1. (선택 사항) ARN, 생성 날짜, 만료 날짜, 암호화 설정, 프라이빗 키 정보 등 특정 공급자에 대한 정보를 얻으려면 다음 명령을 실행합니다.
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/get-saml-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/get-saml-provider.html)

1. IAM 자격 증명 공급자를 삭제하려면 다음 명령을 실행합니다.
   + [https://docs.aws.amazon.com/cli/latest/reference/iam/delete-saml-provider.html](https://docs.aws.amazon.com/cli/latest/reference/iam/delete-saml-provider.html)

## IAM SAML 자격 증명 공급자 생성 및 관리(AWS API)
<a name="idp-create-identityprovider-API"></a>

AWS API를 사용하여 SAML 공급자를 생성, 업데이트, 삭제할 수 있습니다. SAML 페더레이션에 대한 도움이 필요하면 [SAML 페더레이션 문제 해결](troubleshoot_saml.md)을 참조하세요.

**IAM 자격 증명 공급자를 생성하고 메타데이터 문서를 업로드하려면(AWS API)**
+ 다음 연산을 호출합니다. [https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateSAMLProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateSAMLProvider.html) 

**IAM SAML 자격 증명 공급자를 업데이트하려면(AWS API)**

메타데이터 파일과 SAML 암호화 설정을 업데이트하고 IAM SAML 공급자의 프라이빗 키 복호화 파일을 교체할 수 있습니다. 프라이빗 키를 교체하려면 새 프라이빗 키를 추가한 다음 별도의 요청에서 이전 키를 제거합니다. 프라이빗 키 교체에 대한 자세한 내용은 [SAML 암호화 키 관리](#id_federation_manage-saml-encryption) 섹션을 참조하세요.
+ 다음 연산을 호출합니다. [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateSAMLProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateSAMLProvider.html) 

**기존 IAM 자격 증명 공급자를 태깅하려면(AWS API)**
+ 다음 연산을 호출합니다. [https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagSAMLProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagSAMLProvider.html) 

**기존 IAM 자격 증명 공급자의 태그를 나열하려면(AWS API)**
+ 다음 연산을 호출합니다. [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListSAMLProviderTags.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListSAMLProviderTags.html) 

**기존 IAM 자격 증명 공급자에서 태그를 제거하려면(AWS API)**
+ 다음 연산을 호출합니다. [https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagSAMLProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagSAMLProvider.html) 

**IAM 자격 증명 공급자를 삭제하려면(AWS API)**

1. (선택 사항)ARN, 생성 날짜, 만료 등 모든 IdP에 대한 정보를 나열하려면 다음 연산을 호출합니다.
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListSAMLProviders.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListSAMLProviders.html)

1. (선택 사항) ARN, 생성 날짜, 만료 날짜, 암호화 설정, 프라이빗 키 정보 등 특정 공급자에 대한 정보를 얻으려면 다음 연산을 호출합니다.
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetSAMLProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetSAMLProvider.html)

1. IdP를 삭제하려면 다음 연산을 호출합니다.
   + [https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteSAMLProvider.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteSAMLProvider.html)

## 다음 단계
<a name="id_roles_create-for-saml-next-steps"></a>

SAML ID 제공업체를 생성한 후 IdP와의 신뢰 당사자 트러스트를 설정합니다. IdP의 인증 응답에서 가져온 클레임을 정책에서 사용하여 역할에 대한 액세스를 제어할 수도 있습니다.
+ IdP에 서비스 공급자로서 AWS의 정보를 알려야 합니다. 이를 가리켜 IdP와 AWS 간 신뢰 당사자 트러스트 추가라고 합니다. 신뢰 당사자 신뢰를 추가하기 위한 정확한 프로세스는 사용 중인 IdP에 따라 달라집니다. 자세한 내용은 [신뢰 당사자 신뢰 및 클레임 추가를 통해 SAML 2.0 IdP 구성](id_roles_providers_create_saml_relying-party.md)을 참조하세요.
+ IdP가 AWS에 클레임이 포함된 리소스를 전송하는 경우 수신 클레임 중 다수가 AWS 콘텍스트 키에 매핑됩니다. Condition 요소를 사용하여 IAM 정책에서 이러한 컨텍스트 키를 사용하고 역할에 대한 액세스를 제어할 수 있습니다. 자세한 내용은 [인증 응답에 대한 SAML 어설션 구성](id_roles_providers_create_saml_assertions.md) 섹션을 참조하세요.

# 신뢰 당사자 신뢰 및 클레임 추가를 통해 SAML 2.0 IdP 구성
<a name="id_roles_providers_create_saml_relying-party"></a>

SAML 액세스를 위한 IAM 자격 증명 공급자 및 역할을 생성한다는 것은 외부 자격 증명 공급자(IdP)와 관련 사용자에게 허용된 작업을 AWS에 알려주는 것입니다. 그 다음 단계는 IdP에게 서비스 공급자인 AWS에 대해 알려주는 것입니다. 이를 가리켜 IdP와 AWS 간 *신뢰 당사자 신뢰* 추가라고 합니다. 신뢰 당사자 신뢰를 추가하기 위한 정확한 프로세스는 사용 중인 IdP에 따라 달라집니다. 자세한 정보는 자격 증명 관리 소프트웨어의 설명서를 참조하세요.

오늘날 IdP는 신뢰 당사자 정보와 인증서가 저장된 XML 문서를 IdP가 읽을 수 있도록 URL 지정을 허용하는 곳이 많습니다. AWS의 경우 로그인 엔드포인트 URL을 사용합니다. 다음 예제에서는 선택 사항인 `region-code`가 포함된 URL 형식을 보여줍니다.

`https://region-code.signin.aws.amazon.com/static/saml-metadata.xml`

SAML 암호화가 필요한 경우 URL에는 AWS가 SAML 공급업체에 할당하는 고유 식별자가 포함되어야 하며, 이 식별자는 ID 제공업체 세부 정보 페이지에서 확인할 수 있습니다. 다음 예제에서는 고유 식별자가 포함된 리전 로그인 URL을 보여줍니다.

`https://region-code.signin.aws.amazon.com/static/saml/IdP-ID/saml-metadata.xml`

가능한 *region-code* 값 목록은 [AWS 로그인 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)의 **리전(Region)** 열을 참조하세요. AWS 값의 경우 비리전별 엔드포인트 `https://signin.aws.amazon.com/saml`을 사용할 수도 있습니다.

URL을 직접 지정할 수 없는 경우 위 URL에서 XML 문서를 다운로드하여 IdP 소프트웨어로 가져오면 됩니다.

또한, AWS를 신뢰 당사자로 지정하는 IdP에서는 적절한 클레임 규칙을 생성해야 합니다. IdP가 AWS 엔드포인트에 보내는 SAML 응답에는 *클레임*이 하나 이상 있는 SAML *어셜션*이 포함됩니다. 클레임은 사용자 및 사용자 소속 그룹에 대한 정보입니다. 클레임 규칙은 그 정보를 SAML 속성에 매핑합니다. 이는 IAM 정책에서 AWS가 SAML 페더레이션 보안 주체의 권한을 검사하는 데 필요한 속성이 IdP의 SAML 인증 응답에 저장되어 있는지 확인하도록 해줍니다. 자세한 내용은 다음 항목을 참조하세요.
+  [AWS 리소스에 대한 SAML 페더레이션 액세스를 허용하는 역할 개요](id_roles_providers_saml.md#CreatingSAML-configuring-role). 이 주제에서는 IAM 정책의 SAML별 키 사용을 비롯해 이 키를 사용하여 SAML 페더레이션 보안 주체의 권한을 제한하는 방법에 대해 살펴봅니다.
+ [인증 응답에 대한 SAML 어설션 구성](id_roles_providers_create_saml_assertions.md). 이 주제에서는 사용자에 대한 정보가 포함된 SAML 클레임을 구성하는 방법에 대해 살펴봅니다. 그 클레임은 SAML 어설션에 번들링되어 있으며 AWS로 전동되는 SAML 응답에 포함되어 있습니다. AWS 정책에 필요한 그 정보가 AWS가 인식하고 사용할 수 있는 형식으로 SAML 어설션에 반드시 포함되도록 해야 합니다.
+  [서드 파티 SAML 솔루션 공급자를 AWS와 통합](id_roles_providers_saml_3rd-party.md). 이 주제에서는 아이덴티티 솔루션과 AWS의 통합 방법에 대한 타사 설명서 링크를 제공합니다.

**참고**  
페더레이션 복원력을 개선하려면 여러 SAML 로그인 엔드포인트를 지원하도록 IdP 및 AWS 페더레이션을 구성하는 것이 좋습니다. 자세한 내용은 AWS 보안 블로그 문서 [How to use regional SAML endpoints for failover](https://aws.amazon.com/blogs//security/how-to-use-regional-saml-endpoints-for-failover)(장애 조치에 리전 SAML 엔드포인트를 사용하는 방법)를 참조하세요.

# 서드 파티 SAML 솔루션 공급자를 AWS와 통합
<a name="id_roles_providers_saml_3rd-party"></a>

**참고**  
인간 사용자가 AWS에 액세스할 때 임시 보안 인증을 사용하도록 하는 것이 좋습니다. AWS IAM Identity Center 사용을 고려해 보셨나요? IAM Identity Center를 사용하여 여러 AWS 계정에 대한 액세스를 중앙에서 관리하고 사용자에게 한 곳에서 할당된 모든 계정에 대한 MFA 보호 Single Sign-On 액세스를 제공할 수 있습니다. IAM Identity Center를 사용하면 IAM Identity Center에서 사용자 자격 증명을 생성하고 관리하거나 기존 SAML 2.0 호환 자격 증명 제공업체에 쉽게 연결할 수 있습니다. 자세한 정보는 *AWS IAM Identity Center 사용 설명서*의 [IAM Identity Center란 무엇인가요?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) 섹션을 참조하세요.

다음 링크는 AWS 연동을 처리할 타사 SAML 2.0 자격 증명 공급자(IdP) 솔루션을 구성하는 데 도움이 됩니다. 자격 증명 공급자에 문의하여 SAML 토큰 암호화를 지원하는지 확인하세요. SAML 암호화 요구 사항은 [SAML 암호화 키 관리](id_roles_providers_create_saml.md#id_federation_manage-saml-encryption) 섹션을 참조하세요.

**작은 정보**  
AWS Support 엔지니어는 타사 소프트웨어를 사용하는 몇 가지 통합 작업과 함께 비즈니스 및 엔터프라이즈 지원 계획이 있는 고객을 지원할 수 있습니다. 지원되는 플랫폼 및 애플리케이션의 최신 목록은 *AWS Support FAQ*에서 [지원되는 타사 소프트웨어는 무엇입니까?](https://aws.amazon.com/premiumsupport/faqs/#what3rdParty)를 참조하세요.


****  

| Solution | 추가 정보 | 
| --- | --- | 
| Auth0 |  [Amazon Web Services와 통합](https://auth0.com/docs/integrations/aws) - Auth0 설명서 웹 사이트의 이 페이지에는 AWS Management Console에서 통합 인증(SSO)을 설정하는 방법을 설명하는 리소스에 대한 링크가 있으며, JavaScript 예제가 포함되어 있습니다. [세션 태그](id_session-tags.md)를 전달하도록 Auth0을 구성할 수 있습니다. 자세한 내용은 [Auth0, IAM 세션 태그에 관한 AWS와의 파트너십 발표](https://auth0.com/blog/auth0-partners-with-aws-for-iam-session-tags/)를 참조하세요. | 
| Microsoft Entra |  [자습서: AWS 단일 계정 액세스와 Microsoft Entra SSO 통합](https://learn.microsoft.com/en-us/azure/active-directory/saas-apps/amazon-web-service-tutorial) - Microsoft 웹 사이트의 이 자습서에서는 SAML 페더레이션을 사용하여 Microsoft Entra(이전 Azure AD)를 ID 제공업체(IdP)로 설정하는 방법을 설명합니다. | 
| Centrify | [Centrify 구성 및 AWS에 SSO용 SAML 사용](https://docs.centrify.com/Content/Applications/AppsWeb/AmazonSAML.htm) - Centrify 웹 사이트의 이 페이지는 Centrify를 구성해 SSO를 위한 SAML을 AWS에 사용하는 방법에 대해 설명합니다. | 
| CyberArk | [CyberArk](https://docs.cyberark.com/Product-Doc/OnlineHelp/Idaptive/Latest/en/Content/Applications/AppsWeb/AmazonSAML.htm)를 구성하여 CyberArk 사용자 포털에서 SAML 통합 인증(SSO)을 통해 로그인하는 사용자에게 Amazon Web Services(AWS) 액세스를 제공합니다. | 
| ForgeRock | [ForgeRock Identity Platform](https://backstage.forgerock.com/docs/am/6.5/saml2-guide/#saml2-create-hosted-idp)이 AWS와 통합됩니다. [세션 태그](id_session-tags.md)를 전달하도록 ForgeRock을 구성할 수 있습니다. 자세한 내용은 [Amazon Web Services의 속성 기반 액세스 제어](https://www.forgerock.com/blog/attribute-based-access-control-amazon-web-services)를 참조하세요. | 
| Google Workspace | [Amazon Web Services 클라우드 애플리케이션](https://support.google.com/a/answer/6194963) - Google Workspace Admin Help 사이트에 있는 이 문서는 AWS를 서비스 공급자로 하여 Google Workspace를 SAML 2.0 IdP로 구성하는 방법을 설명합니다. | 
| IBM | [세션 태그](id_session-tags.md)를 전달하도록 IBM을 구성할 수 있습니다. 자세한 내용은 [AWS 세션 태그를 지원하는 최초 제품 중 하나인 IBM Cloud Identity IDaaS](https://community.ibm.com/community/user/security/blogs/adam-case/2019/11/25/ibm-cloud-identity-idaas-one-of-first-to-support-aws-session-tags)를 참조하세요. | 
| JumpCloud |  [Amazon AWS에서 Single Sign On(SSO)을 위한 IAM 역할을 통해 액세스 권한 부여](https://support.jumpcloud.com/support/s/article/Granting-Access-via-IAM-Roles-for-Single-Sign-On-SSO-with-Amazon-AWS) - JumpCloud 웹 사이트의 이 문서에서는 AWS의 IAM 역할을 기반으로 SSO를 설정하고 활성화하는 방법을 설명합니다. | 
| Matrix42 | [MyWorkspace 시작 안내서](https://myworkspace.matrix42.com/documents/MyWorkspace-Getting-Started-with-AWS.pdf) - 이 안내서에서는 AWS Identity 서비스를 Matrix42 MyWorkspace와 통합하는 방법에 대해 설명합니다. | 
| Microsoft AD FS(Active Directory Federation Services) |  [Field Notes: Integrating Active Directory Federation Service with AWS IAM Identity Center](https://aws.amazon.com/blogs/architecture/field-notes-integrating-active-directory-federation-service-with-aws-single-sign-on/)(필드 노트: Active Directory Federation Service와 SSO 통합) - AWS 아키텍처 블로그의 이 게시물에서는 AD FS와 AWS IAM Identity Center(IAM Identity Center) 간의 인증 흐름을 설명합니다. IAM Identity Center는 SAML 2.0을 통한 아이덴티티 페더레이션을 지원하므로 AD FS 솔루션과의 통합이 가능합니다. 사용자는 회사 보안 인증을 사용하여 IAM Identity Center 포털에 로그인할 수 있으므로 IAM Identity Center에서 별도의 보안 인증을 유지 관리하는 관리 오버헤드를 줄일 수 있습니다. [세션 태그](id_session-tags.md)를 전달하도록 AD FS를 구성할 수도 있습니다. 자세한 내용은 [AD FS에서 속성 기반 액세스 제어를 사용하여 IAM 권한 관리 간소화](https://aws.amazon.com/blogs/security/attribute-based-access-control-ad-fs-simplify-iam-permissions-management/)를 참조하세요.  | 
| miniOrange | [AWS용 ](http://miniorange.com/amazon-web-services-%28aws%29-single-sign-on-%28sso%29) - miniOrange 웹 사이트의 이 페이지에서는 기업용 AWS에 대한 보안 액세스 및 AWS 애플리케이션에 대한 완전한 액세스 제어를 설정하는 방법을 설명합니다. | 
| Okta |  [Okta를 사용하여 Amazon Web Services 명령줄 인터페이스 통합](https://support.okta.com/help/Documentation/Knowledge_Article/Integrating-the-Amazon-Web-Services-Command-Line-Interface-Using-Okta) - Okta 지원 사이트의 이 페이지에서는 Okta를 AWS와 함께 사용하도록 구성하는 방법을 알아볼 수 있습니다. [세션 태그](id_session-tags.md)를 전달하도록 Okta를 구성할 수 있습니다. 자세한 내용은 [Okta 및 AWS 파트너, 세션 태그를 통해 액세스 간소화](https://www.okta.com/blog/2019/11/okta-and-aws-partner-to-simplify-access-via-session-tags/)를 참조하세요. | 
| Okta | [AWS 계정 페더레이션](https://help.okta.com/oie/en-us/Content/Topics/DeploymentGuides/AWS/aws-deployment.htm) – Okta 웹사이트의 이 섹션은 AWS에 대해 IAM Identity Center를 설정하고 지원하는 방법을 설명합니다. | 
| OneLogin | [OneLogin Knowledgebase](https://onelogin.service-now.com/support)에서 SAML AWS라는 검색어를 입력하여 단일 역할 및 다중 역할 시나리오를 위해 OneLogin과 AWS 사이에 IAM Identity Center 기능을 설정하는 방법이 설명된 일련의 문서를 찾습니다. [세션 태그](id_session-tags.md)를 전달하도록 OneLogin을 구성할 수 있습니다. 자세한 내용은 [OneLogin 및 세션 태그: AWS 리소스에 대한 속성 기반 액세스 제어](https://www.onelogin.com/blog/aws-session-tags-integration)를 참조하세요. | 
| Ping Identity |  [PingFederate AWS 커넥터](https://support.pingidentity.com/s/marketplace-integration-details?recordId=a7i1W0000004HBwQAM) - 통합 인증(SSO) 및 프로비저닝 연결을 쉽게 설정할 수 있는 빠른 연결 템플릿인 PingFederate AWS 커텍터에 대한 세부 정보를 봅니다. 설명서를 읽고 AWS와의 통합을 위한 최신 PingFederate AWS Connector를 다운로드합니다. [세션 태그](id_session-tags.md)를 전달하도록 Ping ID를 구성할 수 있습니다. 자세한 내용은 [AWS에서 속성 기반 액세스 제어를 위한 Ping Identity 지원 발표](https://support.pingidentity.com/s/document-item?bundleId=integrations&topicId=pon1571779451105.html)를 참조하세요.  | 
| RadiantLogic | [Radiant Logic 기술 파트너](http://www.radiantlogic.com/about/partners/technology-partners/) - Radiant Logic의 RadiantOne 페더레이션 자격 증명 서비스를 AWS와 통합하여 SAML 기반의 SSO를 위한 자격 증명 허브를 구축할 수 있습니다. | 
| RSA | [Amazon Web Services - RSA Ready Implementation Guide](https://community.rsa.com/s/article/Amazon-Web-Services-RSA-Ready-Implementation-Guide)에서는 AWS 및 RSA 구현 안내를 제공합니다. SAML 구성에 대한 자세한 내용은 [Amazon Web Services - SAML My Page SSO Configuration - RSA Ready Implementation Guide](https://community.rsa.com/s/article/Amazon-Web-Services-SAML-My-Page-SSO-Configuration-RSA-Ready-Implementation-Guide)를 참조하세요. | 
| Salesforce.com |  [Salesforce에서 AWS와의 SSO를 구성하는 방법](https://developer.salesforce.com/page/Configuring-SAML-SSO-to-AWS) - Salesforce.com 개발자 사이트에 실린 이 사용 방법 설명서에서는 Salesforce에 IdP(자격 증명 공급자)를 설정하고 AWS를 서비스 공급자로 구성하는 방법을 설명합니다. | 
| SecureAuth |  [AWS - SecureAuth SAML SSO](https://docs.secureauth.com/2104/en/amazon-web-services--aws---idp-initiated--integration-guide.html) - SecureAuth 웹 사이트 관련에 관한 이 문서는 SecureAuth 어플라이언스를 위해 SAML과 AWS의 통합을 설정하는 방법을 설명합니다. | 
| Shibboleth |  [AWS Management Console에 대한 SSO를 위해 Shibboleth를 사용하는 방법](https://aws.amazon.com/blogs/security/how-to-use-shibboleth-for-single-sign-on-to-the-aws-management-console) - AWS 보안 블로그의 이 항목에서는 Shibboleth를 설정하고 이를 AWS에 대한 자격 증명 공급자로 구성하는 방법을 단계별로 안내합니다. [세션 태그](id_session-tags.md)를 전달하도록 Shibboleth를 구성할 수 있습니다. | 

자세한 정보는 AWS 웹 사이트의 [IAM 파트너](https://aws.amazon.com/iam/partners/) 페이지를 참조하세요.

# 인증 응답에 대한 SAML 어설션 구성
<a name="id_roles_providers_create_saml_assertions"></a>

조직에서 사용자의 ID를 확인한 후 외부 ID 제공업체(idP)가 AWS 로그인 엔드포인트 URL로 인증 응답을 전송합니다. 이 응답은 [SAML 2.0을 위한 HTTP POST 바인딩](http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf) 표준을 준수하고 다음 요소 또는 *클레임*이 저장된 SAML 토큰을 포함하는 POST 요청입니다. SAML 호환 IdP에서 이 클레임들을 구성합니다. 이 클레임들을 입력하는 방법에 대한 지침에 대해서는 귀하의 IdP를 위한 문서를 참고하세요.

IdP가 AWS에 클레임이 포함된 리소스를 전송하는 경우 수신 클레임 중 다수가 AWS 콘텍스트 키에 매핑됩니다. 이러한 컨텍스트 키는 `Condition` 요소를 사용하여 IAM 정책에서 확인할 수 있습니다. 사용 가능한 매핑 목록은 [SAML 속성을 AWS 신뢰 정책 컨텍스트 키에 매핑](#saml-attribute-mapping) 섹션에 나와 있습니다.

## `Subject` 및 `NameID`
<a name="saml_subject-name-id"></a>

응답에 `SubjectConfirmation` 속성과 `SubjectConfirmationData` 속성을 둘 다 포함하는 `NotOnOrAfter` 요소와 함께 정확하게 `Recipient` 요소가 하나 있어야 합니다. 수신자 속성에는 AWS 로그인 엔드포인트 URL과 일치하는 값이 포함되어야 합니다. IdP는 이 속성을 참조하기 위해 `ACS`, `Recipient` 또는 `Target`이라는 용어를 사용할 수 있습니다.

SAML 암호화가 필요한 경우 로그인 URL에는 AWS가 SAML 공급업체에 할당하는 고유 식별자가 포함되어야 하며, 이 식별자는 ID 제공업체 세부 정보 페이지에서 확인할 수 있습니다. 다음 예제에서는 선택 사항인 `region-code`가 포함된 로그인 URL 형식을 보여줍니다.

`https://region-code.signin.aws.amazon.com/saml`

다음 예제에서 로그인 URL에는 로그인 경로에 /acs/를 추가해야 하는 고유 식별자가 포함됩니다.

`https://region-code.signin.aws.amazon.com/saml/acs/IdP-ID`

가능한 *region-code* 값 목록은 [AWS 로그인 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)의 **리전(Region)** 열을 참조하세요. AWS 값의 경우 글로벌 로그인 엔드포인트 `https://signin.aws.amazon.com/saml`을 사용할 수도 있습니다.

`NameID` 요소는 영구 값, 임시 값을 갖거나 IdP 솔루션에서 제공한 전체 형식 URI로 구성될 수 있습니다. 영구 값은 `NameID`의 값이 세션 간 사용자에서도 동일하다는 것을 나타냅니다. 임시 값인 경우 각 세션마다 사용자의 `NameID` 값이 다릅니다. 싱글 사인온 상호작용은 다음과 같은 유형의 식별자를 지원합니다.
+ `urn:oasis:names:tc:SAML:2.0:nameid-format:persistent`
+ `urn:oasis:names:tc:SAML:2.0:nameid-format:transient`
+ `urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress`
+ `urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified`
+ `urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName`
+ `urn:oasis:names:tc:SAML:1.1:nameid-format:WindowsDomainQualifiedName`
+ `urn:oasis:names:tc:SAML:2.0:nameid-format:kerberos`
+ `urn:oasis:names:tc:SAML:2.0:nameid-format:entity`

다음 발췌문은 한 가지 예를 보여줍니다. 자신의 값을 표시된 것으로 대치합니다.

```
<Subject>
  <NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent">_cbb88bf52c2510eabe00c1642d4643f41430fe25e3</NameID>
  <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
    <SubjectConfirmationData NotOnOrAfter="2013-11-05T02:06:42.876Z" Recipient="https://region-code.signin.aws.amazon.com/saml/SAMLSP4SHN3UIS2D558H46"/>
  </SubjectConfirmation>
</Subject>
```

**중요**  
`saml:aud` 콘텍스트 키는 SAML *수신자* 속성에서 온 것으로, 그 이유는 이 속성이 `accounts.google.com:aud`와 같은 OIDC 대상 필드와 동일한 SAML이기 때문입니다.

## `PrincipalTag` SAML 속성
<a name="saml_role-session-tags"></a>

(선택 사항) `Name` 속성이 `https://aws.amazon.com/SAML/Attributes/PrincipalTag:{TagKey}`로 설정된 `Attribute` 요소를 사용할 수 있습니다. 이 요소를 사용하면 속성을 SAML 어설션에 세션 태그로 전달할 수 있습니다. 세션 태그에 대한 자세한 내용은 [AWS STS에서 세션 태그 전달](id_session-tags.md) 섹션을 참조하세요.

속성을 세션 태그로 전달하려면 태그 값을 지정하는 `AttributeValue` 요소를 포함합니다. 예를 들어, 태그 키 값 페어 `Project` = `Marketing` 및 `CostCenter` = `12345`를 전달하려면 다음 속성을 사용합니다. 각 태그에 대해 별도의 `Attribute` 요소를 포함합니다.

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:Project">
  <AttributeValue>Marketing</AttributeValue>
</Attribute>
<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:CostCenter">
  <AttributeValue>12345</AttributeValue>
</Attribute>
```

위의 태그를 전이적으로 설정하려면 `Name` 속성이 `https://aws.amazon.com/SAML/Attributes/TransitiveTagKeys`로 설정된 다른 `Attribute` 요소를 포함합니다. 세션 태그를 전이적으로 설정하는 선택적 다중 값 속성입니다. 전이적 태그는 SAML 세션을 사용하여 AWS에서 다른 역할을 맡을 때 유지됩니다. 이를 [역할 체인](id_roles.md#iam-term-role-chaining)이라고 합니다. 예를 들어, `Principal` 및 `CostCenter` 태그를 전이적으로 설정하려면 다음 속성을 사용하여 키를 지정합니다.

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/TransitiveTagKeys">
  <AttributeValue>Project</AttributeValue>
  <AttributeValue>CostCenter</AttributeValue>
</Attribute>
```

## `Role` SAML 속성
<a name="saml_role-attribute"></a>

`Name` 속성이 `https://aws.amazon.com/SAML/Attributes/Role`로 설정된 `Attribute` 요소를 사용할 수 있습니다. 이 요소는 IdP에 의해 사용자가 매핑되는 IAM 자격 증명 공급자 및 역할을 나열하는 `AttributeValue` 요소를 한 개 이상 포함합니다. IAM 역할 및 IAM 자격 증명 공급자는 [AssumeRoleWithSAML](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html)에 전달되는 `RoleArn` 및 `PrincipalArn` 파라미터와 동일한 형식의 쉼표로 구분된 ARN 쌍으로 지정됩니다. 이 요소는 하나 이상의 역할 공급자 페어(`AttributeValue` 요소)를 포함해야 하며 여러 페어를 포함할 수 있습니다. 요소가 다수의 페어를 포함하는 경우 사용자가 WebSSO를 사용하여 AWS Management Console에 로그인할 때 어떤 역할을 수임할지 선택하라는 메시지가 표시됩니다.

**중요**  
`Name` 태그의 `Attribute` 속성 값은 대/소문자를 구분합니다. 정확하게 `https://aws.amazon.com/SAML/Attributes/Role`로 설정해야 합니다.

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/Role">
  <AttributeValue>arn:aws:iam::account-number:role/role-name1,arn:aws:iam::account-number:saml-provider/provider-name</AttributeValue>
  <AttributeValue>arn:aws:iam::account-number:role/role-name2,arn:aws:iam::account-number:saml-provider/provider-name</AttributeValue>
  <AttributeValue>arn:aws:iam::account-number:role/role-name3,arn:aws:iam::account-number:saml-provider/provider-name</AttributeValue>
</Attribute>
```

## `RoleSessionName` SAML 속성
<a name="saml_role-session-attribute"></a>

`Name` 속성이 `https://aws.amazon.com/SAML/Attributes/RoleSessionName`로 설정된 `Attribute` 요소를 사용할 수 있습니다. 이 요소에는 역할을 수임할 때 발급된 임시 자격 증명의 식별자를 제공하는 `AttributeValue` 요소가 하나 포함되어 있습니다. 이 요소를 사용하여 임시 자격 증명을 애플리케이션을 사용하는 사용자와 연결할 수 있습니다. 이 요소는 AWS Management Console 콘솔에서 사용자 정보를 표시하는 데 사용됩니다. `AttributeValue` 요소의 값은 2\$164자여야 하며 영숫자, 밑줄 및 다음 문자만 포함할 수 있습니다. **. , \$1 = @ -**(하이픈). 공백은 포함할 수 없습니다. 값은 일반적으로 사용자 ID(`john`) 또는 이메일 주소(`johndoe@example.com`)입니다. 사용자의 표시 이름(`John Doe`)과 같이 값이 공백을 포함하면 안 됩니다.

**중요**  
`Name` 태그의 `Attribute` 속성 값은 대/소문자를 구분합니다. 정확하게 `https://aws.amazon.com/SAML/Attributes/RoleSessionName`로 설정해야 합니다.

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/RoleSessionName">
  <AttributeValue>user-id-name</AttributeValue>
</Attribute>
```

## `SessionDuration` SAML 속성
<a name="saml_role-session-duration"></a>

(선택 사항) `Name` 속성이 `https://aws.amazon.com/SAML/Attributes/SessionDuration"`로 설정된 `Attribute` 요소를 사용할 수 있습니다. 이 요소에는 사용자가 AWS Management Console에 액세스할 수 있는 기간을 지정하는 `AttributeValue` 요소가 한 개 포함되어 있습니다. 이 시간이 지나면 새로운 임시 자격 증명을 요청해야 합니다. 이 값은 세션에 대한 기간(초)을 나타내는 정수입니다. 이 값은 900초(15분)\$143200초(12시간)일 수 있습니다. 이 속성이 없으면 자격 증명은 한 시간 동안 지속됩니다(`DurationSeconds` API의 `AssumeRoleWithSAML` 파라미터 기본값).

이 속성을 사용하려면 `https://region-code.signin.aws.amazon.com/saml`에서 콘솔 로그인 웹 엔드포인트를 통해 AWS Management Console에 대한 SSO(Single Sign-On) 액세스를 제공하도록 SAML 공급자를 구성해야 합니다. 가능한 *region-code* 값 목록은 [AWS 로그인 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)의 **리전(Region)** 열을 참조하세요. URL `https://signin.aws.amazon.com/static/saml`을 사용할 수 있습니다. 이 속성은 AWS Management Console에 대해서만 세션을 연장할 수 있습니다. 다른 자격 증명의 수명을 늘릴 수는 없습니다. 그러나 `AssumeRoleWithSAML` API 호출에 존재하는 경우 세션 기간을 *단축*하는 데 사용할 수 있습니다. 호출에 의해 반환되는 자격 증명의 기본 수명은 60분입니다.

`SessionNotOnOrAfter` 속성도 정의된 경우 콘솔 세션 중 두 속성 `SessionDuration` 또는 `SessionNotOnOrAfter` 중 ***더 작은*** 값으로 최대값이 설정됩니다.

지속 기간을 더 늘려 콘솔 세션을 활성화하면 자격 증명이 손상될 위험이 높아집니다. 이러한 위험을 줄이려면 IAM 콘솔의 **역할 요약** 페이지에서 **세션 취소(Revoke Sessions)**를 선택하여 원하는 역할의 활성 콘솔 세션을 즉시 비활성화하면 됩니다. 자세한 내용은 [IAM 역할 임시 보안 자격 증명 취소](id_roles_use_revoke-sessions.md) 섹션을 참조하세요.

**중요**  
`Name` 태그의 `Attribute` 속성 값은 대/소문자를 구분합니다. 정확하게 `https://aws.amazon.com/SAML/Attributes/SessionDuration`로 설정해야 합니다.

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/SessionDuration">
  <AttributeValue>1800</AttributeValue>
</Attribute>
```

## `SourceIdentity` SAML 속성
<a name="saml_sourceidentity"></a>

(선택 사항) `Name` 속성이 `https://aws.amazon.com/SAML/Attributes/SourceIdentity`로 설정된 `Attribute` 요소를 사용할 수 있습니다. 이 요소에는 하나의 IAM 역할을 사용하는 사용자 또는 애플리케이션에 식별자를 제공하는 `AttributeValue` 요소가 포함됩니다. 소스 자격 증명의 값은 SAML 세션을 사용하여 AWS에서 다른 역할을 수임할 때([역할 체인](id_roles.md#iam-term-role-chaining)이라고 함) 유지됩니다. 소스 자격 증명 값은 역할 세션 중에 수행된 모든 작업의 요청에 표시됩니다. 역할 세션 중에는 설정된 값을 변경할 수 없습니다. 그런 다음 관리자는 AWS CloudTrail 로그를 통해 소스 자격 증명 정보를 모니터링하고 감사하여 공유 역할로 작업을 수행한 사용자를 결정합니다.

`AttributeValue` 요소의 값은 2\$164자여야 하며 영숫자, 밑줄 및 다음 문자만 포함할 수 있습니다. **. , \$1 = @ -**(하이픈). 공백은 포함할 수 없습니다. 이 값은 일반적으로 사용자 ID(`john`) 또는 이메일 주소(`johndoe@example.com`) 등 사용자와 연결된 속성입니다. 사용자의 표시 이름(`John Doe`)과 같이 값이 공백을 포함하면 안 됩니다. 소스 자격 증명 사용에 대한 자세한 내용은 [위임된 역할로 수행한 작업 모니터링 및 제어](id_credentials_temp_control-access_monitor.md) 섹션을 참조하세요.

**중요**  
[`SourceIdentity`](#saml_sourceidentity) 속성을 사용하도록 SAML 어설션이 구성된 경우 역할 신뢰 정책에도 `sts:SetSourceIdentity` 작업이 포함되어야 합니다. 그러지 않으면 수임 역할 작업이 실패합니다. 소스 자격 증명 사용에 대한 자세한 내용은 [위임된 역할로 수행한 작업 모니터링 및 제어](id_credentials_temp_control-access_monitor.md) 섹션을 참조하세요.

소스 자격 증명 속성을 전달하려면 소스 자격 증명의 값을 지정하는 `AttributeValue` 요소를 포함합니다. 예를 들어, 소스 자격 증명 `Diego`를 전달하려면 다음 속성을 사용합니다.

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/SourceIdentity">
  <AttributeValue>Diego</AttributeValue>
```

## SAML 속성을 AWS 신뢰 정책 컨텍스트 키에 매핑
<a name="saml-attribute-mapping"></a>

이 섹션의 표들은 흔히 사용되는 SAML 속성들을 나열하고, 그 속성들이 AWS에서 신뢰 정책 조건 콘텍스트 키에 어떻게 매핑되는지 보여줍니다. 이러한 키를 사용하여 역할에 대한 액세스를 제어할 수 있습니다. 이렇게 하려면 키를 SAML 액세스 요청과 함께 제공되는 어설션에 포함된 값과 비교합니다.

**중요**  
이런 키는 IAM 신뢰 정책(역할을 수임할 수 있는 사용자를 결정하는 정책)에서만 사용할 수 있고, 권한 정책에는 적용할 수 없습니다.

eduPerson 및 eduOrg 속성 표에서 값은 문자열 또는 문자열 목록의 형태로 입력됩니다. 문자열 값의 경우, `StringEquals` 또는 `StringLike` 조건을 이용해 IAM 신뢰 정책에서 이러한 값을 테스트할 수 있습니다. 문자열 목록이 포함된 값의 경우에는 `ForAnyValue` 및 `ForAllValues` [정책 설정 연산자](reference_policies_condition-single-vs-multi-valued-context-keys.md#reference_policies_condition-multi-valued-context-keys)를 사용해 신뢰 정책에서 값을 테스트합니다.

**참고**  
AWS 컨텍스트 키당 하나의 클레임만을 포함해야 합니다. 하나 이상의 클레임을 포함하는 경우, 하나의 클레임만 매핑됩니다.

다음 표는 eduPerson 및 eduOrg 속성을 보여줍니다.


| eduPerson 또는 eduOrg 속성(`Name` 키) | 이 AWS 콘텍스트 키(`FriendlyName` 키)에 매핑 | Type | 
| --- | --- | --- | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.1`   |   `eduPersonAffiliation`   |  문자열 목록  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.2`   |   `eduPersonNickname`   |  문자열 목록  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.3`   |   `eduPersonOrgDN`   |  문자열  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.4`   |   `eduPersonOrgUnitDN`   |  문자열 목록  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.5`   |   `eduPersonPrimaryAffiliation`   |  문자열  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.6`   |   `eduPersonPrincipalName`   |  문자열  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.7`   |   `eduPersonEntitlement`   |  문자열 목록  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.8`   |   `eduPersonPrimaryOrgUnitDN`   |  문자열  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.9`   |   `eduPersonScopedAffiliation`   |  문자열 목록  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.10`   |   `eduPersonTargetedID`   |  문자열 목록  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.1.1.11`   |   `eduPersonAssurance`   |  문자열 목록  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.2.1.2`   |   `eduOrgHomePageURI`   |  문자열 목록  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.2.1.3`   |   `eduOrgIdentityAuthNPolicyURI`   |  문자열 목록  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.2.1.4`   |   `eduOrgLegalName`   |  문자열 목록  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.2.1.5`   |   `eduOrgSuperiorURI`   |  문자열 목록  | 
|   `urn:oid:1.3.6.1.4.1.5923.1.2.1.6`   |   `eduOrgWhitePagesURI`   |  문자열 목록  | 
|   `urn:oid:2.5.4.3`   |   `cn`   |  문자열 목록  | 

다음 표는 Active Directory 속성을 보여줍니다.


| AD 속성 | 이 AWS 컨텍스트 키에 매핑 | Type | 
| --- | --- | --- | 
|  `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name`  |  `name`  |  문자열  | 
|  `http://schemas.xmlsoap.org/claims/CommonName`  |  `commonName`  |  문자열  | 
|  `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname`  |  `givenName`  |  문자열  | 
|  `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname`  |  `surname`  |  문자열  | 
|  `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress`  |  `mail`  |  문자열  | 
|  `http://schemas.microsoft.com/ws/2008/06/identity/claims/primarygroupsid`  |  `uid`  |  문자열  | 

다음 표는 X.500 속성을 보여줍니다.


| X.500 속성 | 이 AWS 컨텍스트 키에 매핑 | Type | 
| --- | --- | --- | 
|  `2.5.4.3`  |  `commonName`  |  문자열  | 
|  `2.5.4.4`  |  `surname`  |  문자열  | 
|  `2.4.5.42`  |  `givenName`  |  문자열  | 
|  `2.5.4.45`  |  `x500UniqueIdentifier`  |  문자열  | 
|  `0.9.2342.19200300100.1.1`  |  `uid`  |  문자열  | 
|  `0.9.2342.19200300100.1.3`  |  `mail`  |  문자열  | 
|  `0.9.2342.19200300.100.1.45`  |  `organizationStatus`  |  문자열  | 

# SAML 2.0 페더레이션 위탁자의 AWS Management Console 액세스 활성화
<a name="id_roles_providers_enable-console-saml"></a>

역할을 사용해 SAML 2.0 호환 ID 공급자(IdP) 및 AWS를 구성하여 SAML 페더레이션 보안 주체가 AWS Management Console에 액세스하도록 허용할 수 있습니다. 역할은 콘솔에서 작업을 수행할 수 있는 권한을 사용자에게 부여합니다. SAML 페더레이션 보안 주체가 다른 방법으로 AWS에 액세스할 수 있게 하려면 다음 주제 중 하나를 참조하세요.
+ AWS CLI: [IAM 역할로 전환(AWS CLI)](id_roles_use_switch-role-cli.md)
+ Tools for Windows PowerShell: [IAM 역할로 전환(Tools for Windows PowerShell)](id_roles_use_switch-role-twp.md)
+ AWS API: [IAM 역할로 전환(AWS API)](id_roles_use_switch-role-api.md)

## 개요
<a name="enable-console-saml-overview"></a>

다음 다이어그램은 SAML 지원 Single Sign-On의 흐름을 보여줍니다.

**참고**  
이와 같은 SAML의 특수한 사용이 [SAML 2.0 연동](id_roles_providers_saml.md)에 설명된 더 일반적인 사용과 차이가 나는 이유는, 이 워크플로우가 사용자를 대신해 AWS Management Console을 열기 때문입니다. 이를 위해서는 `AssumeRoleWithSAML` API를 직접 호출하는 대신 AWS 로그인 엔드포인트를 사용해야 합니다. 엔드포인트는 사용자를 위해 API를 호출하고 사용자의 브라우저를 AWS Management Console로 자동 리디렉션하는 URL을 반환합니다.

![\[SAML을 이용한 AWS 관리 콘솔에 대한 통합 인증(SSO)\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/saml-based-sso-to-console.diagram.png)


다이어그램은 다음 단계들을 보여줍니다.

1. 사용자는 검색을 통해 조직의 포털에 이르러 옵션을 선택해 AWS Management Console로 갑니다. 조직에서 포털은 일반적으로, 조직과 AWS 간의 신뢰 교환을 처리하는 IdP 기능입니다. 예를 들어 Active Directory Federation Services에서 포털 URL은 `https://ADFSServiceName/adfs/ls/IdpInitiatedSignOn.aspx`입니다.

1. 포털은 사용자의 조직 내 자격 증명을 확인합니다.

1. 포털은 사용자를 식별하고 사용자에 대한 속성을 포함하는 어설션이 포함된 SAML 인증 응답을 생성합니다. 콘솔 세션의 유효 기간을 지정하는 `SessionDuration`이라는 SAML 어설션 속성을 포함하여 IdP를 구성할 수도 있습니다. 속성을 [세션 태그](id_session-tags.md)로 전달하도록 IdP를 구성할 수도 있습니다. 포털은 이 응답을 클라이언트 브라우저로 전송합니다.

1. 클라이언트 브라우저는 AWS Single Sign-On 엔드포인트로 리디렉션되고 SAML 어설션을 게시합니다.

1. 엔드포인트는 사용자 대신 임시 보안 자격 증명을 요청하고 그 자격 증명을 사용하는 콘솔 로그인 URL을 생성합니다.

1. AWS는 리디렉션으로 클라이언트에게 로그인 URL을 반송합니다.

1. 클라이언트 브라우저는 AWS Management Console로 리디렉션됩니다. SAML 인증 응답이 여러 개의 IAM 역할에 매핑되는 속성을 포함하는 경우 사용자는 콘솔에 액세스하는 데 사용할 역할을 선택하라는 메시지를 먼저 받습니다.

사용자의 시점에서는 그 과정을 투명하게 들여다볼 수 있습니다. 사용자는 조직의 내부 포털에서 시작하여 AWS 자격 증명을 제공할 필요 없이 AWS Management Console에서 마칩니다.

세부 단계들에 대한 링크를 따라 이 행동을 구성하는 방법을 개관하시려면 다음 섹션들을 참조하세요.

## AWS에 대한 SAML 공급자로 네트워크 구성하기
<a name="fedconsole-config-network-as-saml"></a>

귀하의 조직 네트워크의 내부에서 자격 증명 스토어(Windows Active Directory 등)를 구성해 Windows Active Directory Federation Services, Shibboleth와 같은 SAML 기반 IdP로 작업합니다. IdP를 사용하여 귀하의 조직을 IdP로 기술하고 인증 키를 포함하는 메타데이터 문서를 생성합니다. 또한 조직의 포털을 구성해, AWS Management Console에 대한 사용자 요청을 SAML 어설션을 이용한 인증을 위해 AWS SAML 엔드포인트로 라우팅합니다. metadata.xml 파일을 생성하기 위해 IdP를 어떻게 구성하는가는 IdP에 따라 다릅니다. 지침을 보시려면 IdP의 문서를 참고하시거나 지원되는 SAML 공급자들 중 다수의 웹 문서 링크가 있는 [서드 파티 SAML 솔루션 공급자를 AWS와 통합](id_roles_providers_saml_3rd-party.md)를 참조하세요.

## IAM에서 SAML 공급자 생성
<a name="fedconsole-create-saml-provider"></a>

그 다음에는 AWS Management Console에 로그인하여 IAM 콘솔로 이동합니다. 그곳에서 새로운 SAML 공급자를 생성합니다. 그 공급자는 조직의 Idp에 대한 정보를 담고 있는 IAM의 엔터티입니다. 이 과정의 일부로 이전 섹션에서 조직의 IdP 소프트웨어가 생성한 메타데이터 문서를 업로드합니다. 자세한 내용은 [IAM에서 SAML ID 공급자 생성](id_roles_providers_create_saml.md) 섹션을 참조하세요.

## AWS에서 SAML 페더레이션 보안 주체 대한 권한 구성
<a name="fedconsole-grantperms"></a>

다음 단계는 조직의 IdP와 IAM 간에 신뢰 관계를 수립하는 IAM 역할을 생성하는 것입니다. 이 역할은 연동을 위해 IdP를 보안 주체(신뢰할 수 있는 엔터티)로 식별해야 합니다. 그 역할은 조직의 IdP에 의해 인증된 사용자들이 AWS에서 할 수 있도록 허용되는 것이 무엇인지 정의하기도 합니다. IAM 콘솔을 사용하여 이 역할을 생성할 수 있습니다. 역할을 수임할 수 있는 사용자를 나타내는 신뢰 정책을 생성할 때 이전에 IAM에서 생성한 SAML 공급자를 지정합니다. 또한 역할을 맡을 수 있도록 사용자가 일치해야 하는 SAML 속성을 하나 이상 지정합니다. 예를 들어 SAML `[eduPersonOrgDN](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#ck_edupersonorgdn)` 값이 `ExampleOrg`인 사용자에게만 로그인을 허용하도록 구성할 수 있습니다. 그 역할 마법사는 조건을 자동으로 추가해 `saml:aud` 속성을 테스트함으로써 그 역할이 AWS Management Console에 로그인하는 것을 위해서만 위임되는 것인지 확인합니다.

SAML 암호화가 필요한 경우 로그인 URL에는 AWS가 SAML 공급업체에 할당하는 고유 식별자가 포함되어야 하며, 이 식별자는 ID 제공업체 세부 정보 페이지에서 확인할 수 있습니다. 그 역할을 위한 신뢰 정책은 다음과 같을 수 있습니다.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::111122223333:saml-provider/ExampleOrgSSOProvider"
            },
            "Action": "sts:AssumeRoleWithSAML",
            "Condition": {
                "StringEquals": {
                    "saml:edupersonorgdn": "ExampleOrg",
                    "saml:aud": "https://region-code.signin.aws.amazon.com/saml/acs/SAMLSP4SHN3UIS2D558H46"
                }
            }
        }
    ]
}
```

------

**참고**  
역할 신뢰 정책에 사용되는 SAML IDP는 해당 역할이 속한 계정과 동일한 계정에 있어야 합니다.

`https://region-code.signin.aws.amazon.com/static/saml-metadata.xml`에서 `saml:aud` 속성에 대해 리전별 엔드포인트를 사용하는 것이 좋습니다. 가능한 *region-code* 값 목록은 [AWS 로그인 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)의 **리전(Region)** 열을 참조하세요.

역할의 [권한 정책](access_policies.md)에 대해 어떤 역할, 사용자, 또는 그룹에 사용하는 방식으로 권한을 지정합니다. 예를 들어, 조직의 사용자가 Amazon EC2 인스턴스를 관리하도록 허용될 경우 권한 정책에서 명시적으로 Amazon EC2 작업을 허용합니다. 이렇게 하려면 **Amazon EC2 모든 액세스** 관리형 정책과 같은 [관리형 정책](access_policies_manage-attach-detach.md)을 할당합니다.

SAML IdP를 위한 역할 생성에 관한 자세한 정보는 [SAML 2.0 페더레이션을 위한 역할 생성(콘솔)](id_roles_create_for-idp_saml.md)을 참조하세요.

## 구성 완료 및 SAML 어설션 생성
<a name="fedconsole-configassertions"></a>

`https://region-code.signin.aws.amazon.com/static/saml-metadata.xml` 또는 `https://signin.aws.amazon.com/static/saml-metadata.xml`에 있는 `saml-metadata.xml` 파일을 설치하여 AWS가 서비스 제공업체임을 SAML IdP에 알립니다. SAMl 암호화가 필요한 경우 파일은 `https://region-code.signin.aws.amazon.com/static/saml/SAMLSP4SHN3UIS2D558H46/saml-metadata.xml`에서 찾을 수 있습니다.

가능한 *region-code* 값 목록은 [AWS 로그인 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)의 **리전(Region)** 열을 참조하세요.

그 파일의 설치 방법은 IdP에 따라 다릅니다. 어떤 IdP는 URL을 입력할 수 있는 옵션을 제공하고, 그 결과 IdP가 그 파일을 획득하고 설치해 줍니다. 다른 IdP들의 경우에는 URL에서 파일을 내려받은 다음 로컬 파일로 제공해야 합니다. 세부 정보를 보시려면 IdP의 문서를 참고하시거나 지원되는 SAML 공급자들 중 다수의 웹 문서 링크가 있는 [서드 파티 SAML 솔루션 공급자를 AWS와 통합](id_roles_providers_saml_3rd-party.md)를 참조하세요.

또한, IdP가 인증 응답의 일부로 AWS에 SAML 속성으로 전달하기 원하는 정보를 구성합니다. 이 정보의 대부분은 정책에서 평가할 수 있는 조건 컨텍스트 키로 AWS에 나타납니다. 이러한 조건 키를 사용하면 올바른 컨텍스트의 승인된 사용자에게만 AWS 리소스에 액세스할 수 있는 권한이 부여됩니다. 콘솔을 사용할 수 있는 시간을 제한하는 시간 창을 지정할 수 있습니다. 또한 사용자가 콘솔에 액세스할 수 있는 최대 시간(최대 12시간)을 지정할 수 있습니다. 사용자는 이 시간 이후에 자신의 자격 증명을 새로 고쳐야 합니다. 자세한 내용은 [인증 응답에 대한 SAML 어설션 구성](id_roles_providers_create_saml_assertions.md) 섹션을 참조하세요.

# 브라우저에서 SAML 응답 보기
<a name="troubleshoot_saml_view-saml-response"></a>

다음 절차에서는 SAML 2.0 관련 문제를 해결할 때 브라우저에서 서비스 공급자의 SAML 응답을 보는 방법에 대해 설명합니다.

브라우저에서 문제를 재현할 수 있는 페이지로 이동합니다. 그런 다음 해당 브라우저의 단계를 따릅니다.

**Topics**
+ [

## Google Chrome
](#chrome)
+ [

## Mozilla Firefox
](#firefox)
+ [

## Apple Safari
](#safari)
+ [

## Base64 인코딩 SAML 응답에 대해 해야 할 작업
](#whatnext)

## Google Chrome
<a name="chrome"></a>

**Chrome에서 SAML 응답을 보려면**

이 단계는 Google Chrome의 버전 106.0.5249.103(공식 빌드)(arm64)을 사용하여 테스트되었습니다. 다른 버전을 사용할 경우 그에 맞게 단계를 적용해야 할 수 있습니다.

1. **F12**를 눌러 **Developer Tools**(개발자 도구) 콘솔을 시작합니다.

1. **Network**(네트워크) 탭을 선택한 다음 **Developer Tools**(개발자 도구) 창의 왼쪽 상단에서 **Preserve log**(로그 보존)을 선택합니다.

1. 문제를 재현합니다.

1. (선택 사항) **Developer Tools**(개발자 도구) **Network**(네트워크) 로그 창에 **Method**(메서드) 열이 보이지 않는 경우 아무 열 레이블에서 마우스 오른쪽 버튼으로 클릭하고 **Method**(메서드)를 선택하여 열을 추가할 수 있습니다.

1. **Developer Tools**(개발자 도구) **Network**(네트워크) 로그 창에서 **SAML Post**(SAML 게시물)을 찾습니다. 해당 행을 선택하고 상단에서 **Payload**(페이로드) 탭을 봅니다. 인코딩된 요청을 포함하는 **SAMLResponse** 요소를 확인합니다. 연결된 값은 Base64 인코딩 응답입니다.

## Mozilla Firefox
<a name="firefox"></a>

**Firefox에서 SAML 응답을 보려면**

이 절차는 Mozilla Firefox 버전 105.0.3(64-bit)에서 테스트했습니다. 다른 버전을 사용할 경우 그에 맞게 단계를 적용해야 할 수 있습니다.

1. **F12**를 눌러 **Web Developer Tools**(웹 개발자 도구) 콘솔을 시작합니다.

1. **네트워크** 탭을 선택합니다.

1. **Web Developer Tools**(웹 개발자 도구) 창 상단 오른쪽에서 옵션(작은 기어 모양 아이콘)을 클릭합니다. **Persist logs**(로그 유지)를 선택합니다.

1. 문제를 재현합니다.

1. (선택 사항) **Web Developer Tools**(웹 개발자 도구) **Network**(네트워크) 로그 창에 **Method**(메서드) 열이 보이지 않는 경우 아무 열 레이블에서 마우스 오른쪽 버튼으로 클릭하고 **Method**(메서드)를 선택하여 열을 추가할 수 있습니다.

1. 테이블에서 **POST** **SAML**을 확인합니다. 해당 행을 선택한 다음 **Request**(요청) 탭을 보고 **SAMLResponse** 요소를 찾습니다. 연결된 값은 Base64 인코딩 응답입니다.

## Apple Safari
<a name="safari"></a>

**Safari에서 SAML 응답을 보려면**

이 단계는 Apple Safari 버전 16.0(17614.1.25.9.10, 17614)을 사용하여 테스트되었습니다. 다른 버전을 사용할 경우 그에 맞게 단계를 적용해야 할 수 있습니다.

1. Safari에서 Web Inspector를 사용하도록 설정합니다. **기본 설정** 창을 열고 **고급** 탭을 선택한 후 **메뉴 표시줄에 Develop 메뉴 표시(Show Develop menu in the menu bar)**를 선택합니다.

1. 이제 Web Inspector를 열 수 있습니다. 메뉴 막대에서 **Develop**(개발)을 선택한 다음 **Show Web Inspector**(Web Inspector 표시)를 선택합니다.

1. **네트워크** 탭을 선택합니다.

1. **Web Inspector** 창의 왼쪽 상단에서 옵션(세 개의 수평선이 포함된 작은 원형 아이콘)을 선택합니다. **Preserve Log**(로그 보존)을 선택합니다.

1. (선택 사항) **Web Inspector** **Network**(네트워크) 로그 창에 **Method**(메서드) 열이 보이지 않는 경우 아무 열 레이블에서 마우스 오른쪽 버튼으로 클릭하고 **Method**(메서드)를 선택하여 열을 추가할 수 있습니다.

1. 문제를 재현합니다.

1. 테이블에서 **POST** **SAML**을 확인합니다. 해당 행을 선택하고 헤더(Headers) 탭을 봅니다.

1. 인코딩된 요청을 포함하는 **SAMLResponse** 요소를 확인합니다. 아래로 스크롤하여 `Request Data`라는 `SAMLResponse`를 확인합니다. 연결된 값은 Base64 인코딩 응답입니다.

## Base64 인코딩 SAML 응답에 대해 해야 할 작업
<a name="whatnext"></a>

브라우저에서 Base64 인코딩 SAML 응답 요소를 확인했으면 복사한 후 Base-64 디코딩 도구에서 사용하여 XML 태그 응답을 추출합니다.

**보안 팁**  
표시되는 SAML 응답 데이터에는 중요한 보안 데이터가 포함되어 있을 수 있으므로 *온라인* base64 디코더를 사용하지 않을 것을 권장합니다. 대신 로컬 컴퓨터에 설치된 도구를 사용하십시오. 로컬 컴퓨터에 설치된 도구는 네트워크를 통해 SAML 데이터를 전송하지 않습니다.

**Windows 시스템용 내장 옵션(PowerShell):**

```
PS C:\> [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String("base64encodedtext"))
```

**MacOS 및 Linux 시스템용 내장 옵션:**

```
$ echo "base64encodedtext" | base64 --decode
```

**디코딩된 파일의 값 검토**  
디코딩된 SAML 응답 파일의 값을 검토합니다.
+ saml:NameID 속성 값이 인증된 사용자의 사용자 이름과 일치하는지 확인합니다.
+ https://aws.amazon.com/SAML/Attributes/Role 값을 검토합니다. ARN과 SAML 공급자는 대소문자를 구분하며 [ARN](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html)은 계정의 리소스와 일치해야 합니다.
+ https://aws.amazon.com/SAML/Attributes/RoleSessionName 값을 검토합니다. 값은 [클레임 규칙](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml_relying-party.html)에 있는 값과 일치해야 합니다.
+ 이메일 주소 또는 계정 이름의 속성 값을 구성하는 경우 값이 올바른지 확인합니다. 값은 인증된 사용자의 이메일 주소 또는 계정 이름과 일치해야 합니다.

**오류 확인 및 구성 확인**  
값에 오류가 있는지 확인하고 다음 구성이 올바른지 확인합니다.
+ 클레임 규칙이 필수 요소를 충족하고 모든 ARN이 정확합니다. 자세한 내용은 [신뢰 당사자 신뢰 및 클레임 추가를 통해 SAML 2.0 IdP 구성](id_roles_providers_create_saml_relying-party.md) 섹션을 참조하세요.
+ SAML 공급자에서 IdP의 최신 메타데이터 파일을 AWS에 업로드했습니다. 자세한 내용은 [SAML 2.0 페더레이션 위탁자의 AWS Management Console 액세스 활성화](id_roles_providers_enable-console-saml.md) 섹션을 참조하세요.
+ IAM 역할의 신뢰 정책을 올바르게 구성했습니다. 자세한 내용은 [역할 수임 방법](id_roles_manage-assume.md) 섹션을 참조하세요.

# AWS ID를 외부 서비스에 페더레이션
<a name="id_roles_providers_outbound"></a>

IAM 아웃바운드 ID 페더레이션은 AWS 워크로드가 장기 자격 증명을 저장하지 않고도 외부 서비스에 안전하게 액세스할 수 있게 합니다. AWS 워크로드는 [GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html) API를 직접 호출하여 AWS Security Token Service(AWS STS)에서 수명이 짧은 JSON 웹 토큰(JWT)을 요청할 수 있습니다. 이러한 토큰은 암호화 방식으로 서명되고 공개적으로 확인 가능하며 AWS 워크로드의 ID를 외부 서비스에 주장하는 포괄적인 클레임 세트를 포함합니다. 이러한 토큰은 다양한 서드 파티 클라우드 공급자, SaaS 플랫폼 및 자체 호스팅 애플리케이션에서 사용할 수 있습니다. 외부 서비스는 잘 알려진 엔드포인트에 게시된 AWS의 검증 키를 사용하여 토큰의 신뢰성을 확인하고 토큰의 정보를 사용하여 인증 및 권한 부여 결정을 내립니다.

아웃바운드 ID 페더레이션을 사용하면 애플리케이션 코드 또는 환경 변수에 API 키 또는 암호와 같은 장기 자격 증명을 저장할 필요가 없으므로 보안 태세가 강화됩니다. IAM 정책을 사용하여 토큰 생성에 대한 액세스를 제어하고 서명 알고리즘, 허용된 대상 및 기간 등의 토큰 속성을 적용할 수 있습니다. 모든 토큰 요청은 AWS에 로깅되어 보안 모니터링 및 규정 준수 보고를 위한 전체 감사 추적을 제공합니다. 사용자 지정 클레임으로 표시되는 태그로 토큰을 사용자 지정하여 외부 서비스가 세분화된 속성 기반 액세스 제어를 구현할 수 있습니다.

## 일반 사용 사례
<a name="outbound-federation-use-cases"></a>

아웃바운드 ID 페더레이션을 사용하면 AWS 워크로드가 안전하게 다음을 수행할 수 있습니다.
+ 외부 클라우드 공급자의 리소스 및 서비스에 액세스합니다. 예를 들어 Lambda 함수 처리 데이터는 외부 클라우드 공급자의 스토리지 서비스에 결과를 쓰거나 데이터베이스를 쿼리할 수 있습니다.
+ 분석, 데이터 처리, 모니터링 등을 위해 외부 서비스형 소프트웨어(SaaS) 공급자와 통합합니다. 예를 들어 Lambda 함수는 관찰성 플랫폼에 지표를 전송할 수 있습니다.
+ AWS, 외부 클라우드 공급자 또는 온프레미스 데이터 센터에서 호스팅되는 자체 애플리케이션으로 인증하여 안전한 하이브리드 및 멀티 클라우드 아키텍처를 지원합니다. 예를 들어 AWS 워크로드는 온프레미스 Kubernetes 클러스터에서 실행되는 컨테이너화된 애플리케이션과 상호 작용할 수 있습니다.

## 작동 방식
<a name="outbound-federation-how-it-works"></a>

![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/outbound-use-cases.png)


1. Lambda 함수는 [GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html) API를 직접 호출하여 AWS Security Token Service(AWS STS)에서 JSON 웹 토큰(JWT)을 요청합니다.

1. AWS STS는 요청을 검증하고 서명된 JWT를 Lambda 함수에 반환합니다.

1. Lambda 함수는 JWT를 외부 서비스에 전송합니다.

1. 외부 서비스는 토큰에서 발급자 URL을 추출하고, 알려진 신뢰할 수 있는 발급자와 일치하는지 확인하고, OIDC 검색 엔드포인트에서 AWS의 검증 키와 메타데이터를 가져옵니다.

1. 외부 서비스는 검증 키를 사용하여 토큰의 서명을 확인하고 만료 시간, 주체, 대상 등의 클레임을 검증합니다.

1. 검증에 성공하면 외부 서비스는 Lambda 함수에 대한 액세스 권한을 부여합니다.

# 아웃바운드 ID 페더레이션 시작하기
<a name="id_roles_providers_outbound_getting_started"></a>

이 가이드에서는 AWS 계정에 대해 아웃바운드 ID 페더레이션을 활성화하고 첫 번째 JSON 웹 토큰(JWT)([GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html) API 사용)을 가져오는 방법을 보여줍니다. 기능을 활성화하고, 외부 서비스와 신뢰 관계를 설정하고, IAM 권한을 구성하고, AWS CLI 또는 AWS SDK for Python(Boto3)을 사용하여 토큰을 요청합니다.

## 사전 조건
<a name="outbound-federation-prerequisites"></a>

시작하기 전에 다음을 갖추었는지 확인하세요.
+ 최신 버전의 AWS CLI 또는 Python 3.8(또는 이상) 및 Boto3 설치(AWSSDK 예시용)
+ 신뢰 관계를 구성할 수 있는 외부 서비스 계정(예: 외부 클라우드 공급자, SaaS 공급자 또는 테스트 애플리케이션)

**참고**  
`GetWebIdentityToken` API는 STS Global 엔드포인트에서 사용할 수 없습니다.
`GetWebIdentityToken` API에 의해 생성된 JSON 웹 토큰(JWT)은 AWS([AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) API를 통해)에 대한 OpenID Connect(OIDC) 페더레이션에 사용할 수 없습니다.

## 계정에 대한 아웃바운드 ID 페더레이션 활성화
<a name="enable-outbound-federation"></a>

토큰을 요청하려면 먼저 아웃바운드 ID 페더레이션을 활성화해야 합니다. AWS Management Console을 사용하거나 프로그래밍 방식으로 [EnableOutboundWebIdentityFederation](https://docs.aws.amazon.com/IAM/latest/APIReference/API_EnableOutboundWebIdentityFederation.html) API를 사용하여 기능을 활성화할 수 있습니다.

### AWS CLI 사용
<a name="enable-using-cli"></a>

```
aws iam enable-outbound-web-identity-federation
```

### AWS SDK for Python 사용
<a name="enable-using-sdk"></a>

```
import boto3

# Create IAM client
iam_client = boto3.client('iam')

# Enable outbound identity federation
response = iam_client.enable_outbound_web_identity_federation()
print(f"Feature enabled. Issuer URL: {response['IssuerUrl']}")
print(f"Status: {response['Status']}")
```

### AWS 콘솔 사용
<a name="enable-using-console"></a>

IAM으로 이동하여 왼쪽 탐색 메뉴의 **액세스 관리** 섹션에서 **계정 설정**을 선택합니다.

![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/outbound-screen-1.png)


기능을 활성화한 후 계정별 발급자 URL을 기록해 둡니다. 외부 서비스에서 신뢰 관계를 구성할 때 이 URL을 사용합니다. [GetOutboundWebIdentityFederationInfo](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetOutboundWebIdentityFederationInfo.html) API를 사용하여 필요에 따라 이 발급자 URL을 검색할 수도 있습니다.

![\[alt text not found\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/outbound-screen-2.png)


## 외부 서비스에서 신뢰 관계 설정
<a name="establish-trust-relationship"></a>

AWS 계정에서 발급한 토큰을 신뢰하고 수락하도록 외부 서비스를 구성합니다. 구체적인 단계는 서비스에 따라 다르지만 일반적으로 다음을 포함합니다.
+ AWS 계정 발급자 URL을 신뢰할 수 있는 ID 공급자로 등록
+ 검증할 클레임 구성(대상, 주제 패턴)
+ 토큰 클레임을 외부 서비스의 권한에 매핑

자세한 구성 지침은 외부 서비스 설명서를 참조하세요.

## IAM 권한 구성
<a name="configure-iam-permissions"></a>

[GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html) API를 직접 호출할 권한을 부여하는 IAM 정책을 생성하고 토큰을 생성해야 하는 IAM 역할에 정책을 연결합니다.

이 예시 정책은 특정 제한이 있는 토큰 생성에 대한 액세스 권한을 부여합니다. 대상인 ‘https://api.example.com’에 대해서만 토큰을 요청할 수 있으며, 최대 토큰 수명은 5분(300초)입니다. 토큰 속성을 적용하는 데 사용할 수 있는 조건 키 목록은 [IAM 및 AWS STS 조건 컨텍스트 키](reference_policies_iam-condition-keys.md) 섹션을 참조하세요.

### IAM 정책 예제
<a name="example-iam-policy"></a>

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:GetWebIdentityToken",
            "Resource": "*",
            "Condition": {
                "ForAllValues:StringEquals": {
                    "sts:IdentityTokenAudience": "https://api.example.com"
                },
                "NumericLessThanEquals": {
                    "sts:DurationSeconds": 300
                }
            }
        }
    ]
}
```

## 첫 번째 JSON 웹 토큰(JWT) 요청
<a name="request-first-jwt"></a>

[GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html) API를 사용하여 JSON 웹 토큰을 요청할 수 있습니다. API를 직접적으로 호출할 때 다음 파라미터를 지정할 수 있습니다.
+ **Audience(필수):** 토큰의 의도된 수신자입니다. 이 값은 JWT의 ‘aud’ 클레임을 채웁니다. 외부 서비스는 토큰이 의도한 것인지 확인하기 위해 이 클레임을 검증합니다.
+ **SigningAlgorithm(필수):** 토큰에 서명하는 데 사용되는 암호화 알고리즘입니다. 유효한 값은 ES384와 RS256입니다. 최적의 보안과 성능이 요구되는 경우 ES384를 사용하고, ECDSA를 지원하지 않는 시스템과의 광범위한 호환성이 요구되는 경우 RS256을 사용합니다.
+ **DurationSeconds(선택 사항):** 초 단위의 토큰 수명입니다. 유효한 값의 범위는 60\$13600입니다. 기본값은 300(5분)입니다. 보안을 강화하려면 토큰 수명을 단축하는 것이 좋습니다.
+ **Tags(선택 사항):** 토큰에 사용자 지정 클레임으로 포함할 키-값 페어의 목록입니다. 외부 서비스는 이러한 클레임을 세분화된 권한 부여에 사용할 수 있습니다.

API는 다음 필드를 반환합니다.
+ **IdentityToken:** base64url 인코딩 문자열로 서명된 JWT입니다. 외부 서비스에 대한 요청에 이 토큰을 포함합니다.
+ **Expiration:** 토큰이 만료될 시점의 UTC 타임스탬프입니다.

### AWS CLI 사용
<a name="using-aws-cli"></a>

```
aws sts get-web-identity-token \
    --audience "https://api.example.com" \
    --signing-algorithm ES384 \
    --duration-seconds 300 \
    --tags Key=team,Value=data-engineering \
           Key=environment,Value=production \
           Key=cost-center,Value=analytics
```

### AWS SDK for Python 사용
<a name="using-aws-sdk-python"></a>

```
import boto3

sts_client = boto3.client('sts')

response = sts_client.get_web_identity_token(
    Audience=['https://api.example.com'],
    DurationSeconds=300,
    SigningAlgorithm='RS256',
    Tags=[
        {'Key': 'team', 'Value': 'data-engineering'},
        {'Key': 'environment', 'Value': 'production'},
        {'Key': 'cost-center', 'Value': 'analytics'}
    ]
)

token = response['WebIdentityToken']
```

JWT를 디코딩하여 PyJWT, Python-jose for Python, Nimbus JOSE\$1JWT for Java, 디버거(예: jwt.io) 등의 표준 JWT 라이브러리를 사용하여 콘텐츠를 검사할 수도 있습니다. 토큰에 포함된 클레임에 대한 자세한 내용은 [토큰 클레임 이해](id_roles_providers_outbound_token_claims.md) 섹션을 참조하세요.

## 외부 서비스와 함께 토큰 사용
<a name="use-token-with-external-service"></a>

토큰을 받은 후 외부 서비스에 대한 요청에 포함합니다. 메서드는 서비스에 따라 다르지만 대부분의 서비스는 권한 부여 헤더에서 토큰을 수락합니다. 외부 서비스는 발급자의 잘 알려진 엔드포인트에서 JWKS 키를 가져오고, 토큰의 서명을 확인하고, AWS 워크로드에 대한 액세스 권한을 부여하기 전에 필수 클레임을 검증하는 토큰 검증 로직을 구현해야 합니다.

## OpenID Connect(OIDC) 엔드포인트에서 검증 키 및 메타데이터 가져오기
<a name="fetch-verification-keys"></a>

AWS 계정의 고유한 발급자 URL은 토큰 확인에 필요한 검증 키와 메타데이터가 포함된 OpenID Connect(OIDC) 검색 엔드포인트를 호스팅합니다.

OIDC 검색 엔드포인트 URL에는 일부 공급자가 토큰을 확인하는 데 사용하는 메타데이터가 포함되어 있습니다. 다음에서 사용할 수 있습니다.

```
{issuer_url}/.well-known/openid-configuration
```

JWKS(JSON 웹 키 세트) 엔드포인트에는 토큰 서명을 확인하는 데 사용되는 키가 포함되어 있습니다. 다음에서 사용할 수 있습니다.

```
{issuer_url}/.well-known/jwks.json
```

### curl을 사용하여 JWKS 가져오기
<a name="fetch-jwks-curl"></a>

```
curl https://{issuer_url}/.well-known/jwks.json
```

응답:

```
{
  "keys": [
    {
      "kty": "EC",
      "use": "sig",
      "kid": "key-id-1",
      "alg": "ES384",
      "crv": "P-384",
      "x": "base64-encoded-x-coordinate",
      "y": "base64-encoded-y-coordinate"
    },
    {
      "kty": "RSA",
      "use": "sig",
      "kid": "key-id-2",
      "n": "base64-encoded-modulus",
      "e": "AQAB"
    }
  ]
}
```

### AWS SDK for Python 사용
<a name="fetch-using-sdk"></a>

```
import requests

# Fetch Openid Configuration
open_id_config_response = requests.get("https://{issuer_url}/.well-known/openid-configuration")
open_id_config = open_id_config_response.json()

# Fetch JWKS
jwks_response = requests.get("https://{issuer_url}/.well-known/jwks.json")
jwks = jwks_response.json()
```

토큰을 검증할 때마다 키를 가져올 필요가 없도록 이러한 키를 캐싱하는 것이 좋습니다.

### 필수 클레임 검증
<a name="essential-claim-validations"></a>
+ **Subject (sub):** 제목 클레임에 예상 IAM 위탁자 ARN 패턴이 포함되어 있는지 확인합니다.
+ **Expiration (exp):** 토큰이 만료되지 않았는지 확인합니다. JWT 라이브러리는 일반적으로 이를 자동으로 처리합니다.
+ **Audience (aud):** 대상이 예상 값과 일치하는지 확인합니다. 이렇게 하면 다른 서비스용 토큰이 사용자의 토큰과 함께 사용되지 않습니다.
+ **Issuer (iss):** 발급자가 신뢰하는 AWS 계정과 일치하는지 확인합니다. 신뢰할 수 있는 발급자 URL의 목록을 유지 관리합니다.

가능하면 추가 AWS 관련 클레임을 검증하여 외부 서비스에서 세분화된 액세스 제어를 구현해야 합니다. 예를 들어 AWS 조직의 IAM 위탁자에 대한 액세스를 제한하려면 org\$1id 클레임을 검증하고, 속성 기반 액세스 제어를 적용하려면 principal\$1tags를 확인하고(예: 프로덕션 환경 또는 특정 팀만 허용), 컴퓨팅 리소스를 기반으로 액세스를 제한하려면 lambda\$1source\$1function\$1arn 또는 ec2\$1instance\$1source\$1vpc와 같은 세션 컨텍스트 클레임을 확인합니다. 토큰에 포함된 전체 클레임 목록은 [토큰 클레임 이해](id_roles_providers_outbound_token_claims.md)를 참조하세요.

# 토큰 클레임 이해
<a name="id_roles_providers_outbound_token_claims"></a>

[GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html) API를 직접적으로 호출하면 AWS Security Token Service는 IAM 위탁자의 ID를 나타내는 클레임 세트가 포함된 서명된 JSON 웹 토큰(JWT)을 반환합니다. 이러한 토큰은 [RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519)와 호환됩니다. 이러한 토큰의 구조와 내용을 이해하면 보안 인증 흐름을 구현하고, 외부 서비스에서 적절한 클레임 검증을 구성하고, 세분화된 액세스 제어를 위해 사용자 지정 클레임을 효과적으로 사용할 수 있습니다.

JWT에는 주제(‘sub’), 대상(‘aud’), 발급자(‘iss’)와 같은 표준 OpenID Connect(OIDC) 클레임이 포함되어 있어 다양한 외부 서비스 간의 상호 운용성을 지원합니다. AWS STS는 해당하는 경우 토큰을 자격 AWS 증명별 클레임(예: AWS 계정 ID 및 위탁자 태그) 및 세션 컨텍스트 클레임(예: EC2 인스턴스 ARN)으로 채웁니다. 사용자 지정 클레임을 [GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html) API에 요청 태그로 전달하여 토큰에 추가할 수도 있습니다. 자격 AWS 증명별 클레임, 세션 컨텍스트 클레임 및 사용자 지정 클레임은 토큰의 ‘https://sts.amazonaws.com/’ 네임스페이스 아래에 중첩됩니다.

토큰에 포함된 클레임 목록은 아래 샘플 토큰을 참조하세요. 이러한 모든 클레임이 토큰에 동시에 존재하지 않을 수 있습니다.

```
{
  "iss": "https://abc123-def456-ghi789-jkl012.tokens.sts.global.api.aws",
  "aud": "https://api.example.com",
  "sub": "arn:aws:iam::123456789012:role/DataProcessingRole",
  "iat": 1700000000,
  "exp": 1700000900,
  "jti": "xyz123-def456-ghi789-jkl012",
  "https://sts.amazonaws.com/": {
    "aws_account": "123456789012",
    "source_region": "us-east-1",
    "org_id": "o-abc1234567",
    "ou_path": "o-a1b2c3d4e5/r-ab12/ou-ab12-11111111/ou-ab12-22222222/",
    "principal_tags": {
      "environment": "production",
      "team": "data-engineering",
      "cost-center": "engineering"
    },
    "lambda_source_function_arn": "arn:aws:lambda:us-east-1:123456789012:function:process-data",
    "request_tags": {
        "job-id": "job-2024-001",
        "priority": "high",
        "data-classification": "sensitive"
    }
  }
}
```

## 표준 클레임
<a name="standard-claims"></a>

토큰에 있는 표준 OIDC 클레임은 광범위한 외부 서비스와의 상호 운용성을 지원합니다. 이러한 클레임은 대부분의 JWT 라이브러리를 사용하여 검증할 수 있습니다.


| Claim | 이름 | 설명 | 예제 값 | 
| --- | --- | --- | --- | 
| iss | Issuer | 계정별 발급자 URL입니다. 외부 서비스는 이 클레임을 검증하여 신뢰할 수 있는 발급자와 일치하는지 확인합니다. | https://abc123-def456-ghi789-jkl012.tokens.sts.global.api.aws | 
| aud | 대상 | [GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html) 요청에 지정된 토큰의 의도된 수신자입니다. | https://api.example.com | 
| sub | 제목 | 토큰을 요청한 IAM 위탁자의 ARN입니다. | arn:aws:iam::123456789012:role/DataProcessingRole | 
| iat | Issued At | JWT가 발급된 시간을 식별하는 NumericDate 값입니다. | 1700000000 | 
| exp | Expiration | NumericDate 값은 JWT가 처리에 허용되지 않아야 하는 만료 시간을 식별합니다. | 1700000900 | 
| jti | JWT ID | 이 토큰 인스턴스의 고유 식별자입니다. | xyz123-def456-ghi789-jkl012 | 

## 사용자 지정 클레임
<a name="custom-claims"></a>

AWS STS는 표준 OIDC 클레임 외에도 해당하는 경우 ID 및 세션 컨텍스트에 대한 클레임을 추가합니다. 요청 태그로 토큰을 전달하여 토큰에 자체 클레임을 추가할 수도 있습니다. 사용자 지정 클레임은 https://sts.amazonaws.com/ 네임스페이스 아래에 중첩됩니다.

### AWS ID 클레임
<a name="aws-identity-claims"></a>

이러한 클레임은 AWS 계정, 조직 구조 및 IAM 위탁자에 대한 자세한 정보를 제공합니다.


| Claim | 설명 | 조건 키에 매핑 | 예제 값 | 
| --- | --- | --- | --- | 
| aws\$1account | AWS 계정 ID. | [aws:PrincipalAccount](reference_policies_condition-keys.md#condition-keys-principalaccount) | 123456789012 | 
| source\$1region | 토큰이 요청된 AWS 리전 | [aws:RequestedRegion](reference_policies_condition-keys.md#condition-keys-requestedregion) | us-east-1 | 
| org\$1id | 사용자의 AWS Organizations ID(계정이 조직의 일부인 경우) | [aws:PrincipalOrgID](reference_policies_condition-keys.md#condition-keys-principalorgid) | o-abc1234567 | 
| ou\$1path | 조직 단위 경로(해당하는 경우) | [aws:PrincipalOrgPaths](reference_policies_condition-keys.md#condition-keys-principalorgpaths) | o-a1b2c3d4e5/r-ab12/ou-ab12-11111111/ou-ab12-22222222/ | 
| principal\$1tags | IAM 위탁자 또는 수임된 역할 세션에 연결된 태그입니다. 요청 IAM 위탁자에 위탁자 태그와 세션 태그가 모두 있는 토큰이 요청되면 세션 태그가 JWT에 표시됩니다. | [aws:PrincipalTag/<tag-key>](reference_policies_condition-keys.md#condition-keys-principaltag) | \$1"environment": "production", "team": "data-engineering", "cost-center":"engineering"\$1 | 

### 세션 컨텍스트 클레임
<a name="session-context-claims"></a>

이러한 클레임은 토큰 요청이 시작된 컴퓨팅 환경 및 세션에 대한 정보를 제공합니다. AWS AWS STS는 요청 주체의 세션 컨텍스트에 따라 해당하는 경우 이러한 클레임을 자동으로 포함합니다.


| Claim | 설명 | 조건 키에 매핑 | 예제 값 | 
| --- | --- | --- | --- | 
| original\$1session\$1exp | 원래 역할 세션 자격 증명이 만료되는 시기(위임된 역할의 경우) | 해당 사항 없음 | 2024-01-15T10:00:00Z | 
| federated\$1provider | 페더레이션 세션의 ID 공급자 이름 | [aws:FederatedProvider](reference_policies_condition-keys.md#condition-keys-federatedprovider) | arn:aws:iam::111122223333:oidc-provider/your\$1oidc\$1provider | 
| identity\$1store\$1user\$1id | IAM Identity Center 사용자 ID | [identitystore:UserId](reference_policies_condition-keys.md#condition-keys-identity-store-user-id) | user-abc123def456 | 
| identity\$1store\$1arn | Identity Center ID 스토어의 ARN | [identitystore:IdentityStoreArn](https://docs.aws.amazon.com/singlesignon/latest/userguide/condition-context-keys-sts-idc.html#condition-keys-identity-store-arn) | arn:aws:identitystore::123456789012:identitystore/d-abc1234567 | 
| ec2\$1source\$1instance\$1arn | 요청하는 EC2 인스턴스의 ARN | [ec2:SourceInstanceArn](reference_policies_condition-keys.md#condition-keys-ec2-source-instance-arn) | arn:aws:ec2:us-east-1:123456789012:instance/i-abc123def456 | 
| ec2\$1instance\$1source\$1vpc | EC2 역할 자격 증명이 전달된 VPC ID | [aws:Ec2InstanceSourceVpc](reference_policies_condition-keys.md#condition-keys-ec2instancesourcevpc) | vpc-abc123def456 | 
| ec2\$1instance\$1source\$1private\$1ipv4 | EC2 인스턴스의 프라이빗 IPv4 주소 | [aws:Ec2InstanceSourcePrivateIPv4](reference_policies_condition-keys.md#condition-keys-ec2instancesourceprivateip4) | 10.0.1.25 | 
| ec2\$1role\$1delivery | 인스턴스 메타데이터 서비스 버전 | [ec2:RoleDelivery](reference_policies_condition-keys.md#condition-keys-ec2-role-delivery) | 2 | 
| source\$1identity | 위탁자가 설정한 소스 ID | [aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity) | admin-user | 
| lambda\$1source\$1function\$1arn | 직접 호출하는 Lambda 함수의 ARN | [lambda:SourceFunctionArn](reference_policies_condition-keys.md#condition-keys-lambda-source-function-arn) | arn:aws:lambda:us-east-1:123456789012:function:my-function | 
| glue\$1credential\$1issuing\$1service | Glue 작업의 AWS Glue 서비스 식별자 | [glue:CredentialIssuingService](reference_policies_condition-keys.md#condition-keys-glue-credential-issuing) | glue.amazonaws.com | 

### 요청 태그
<a name="request-tags"></a>

[GetWebIdentityToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetWebIdentityToken.html) API 요청에서 태그를 지정하여 토큰에 사용자 지정 클레임을 추가할 수 있습니다. 이러한 클레임은 토큰의 request\$1tags 필드 아래에 표시되며 외부 서비스가 세분화된 권한 부여 결정에 사용할 수 있는 특정 정보를 전달할 수 있습니다. 요청당 최대 50개의 태그를 지정할 수 있습니다.

요청 예제:

```
response = sts_client.get_web_identity_token(
    Audience=['https://api.example.com'],
    SigningAlgorithm='ES384'
    Tags=[
        {'Key': 'team', 'Value': 'data-engineering'},
        {'Key': 'cost-center', 'Value': 'analytics'},
        {'Key': 'environment', 'Value': 'production'}
    ]
)
```

토큰의 결과 클레임:

```
{
  "request_tags": {
    "team": "data-engineering",
    "cost-center": "analytics",
    "environment": "production"
  }
}
```

# IAM 정책을 사용하여 액세스 제어
<a name="id_roles_providers_outbound_policies"></a>

IAM은 아웃바운드 ID 페더레이션 기능에 대한 액세스를 제어하는 여러 정책 유형을 제공합니다. [ID 기반 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html)을 사용하여 토큰을 요청할 수 있는 IAM 위탁자를 제어하고 대상, 수명 및 서명 알고리즘과 같은 특정 토큰 속성을 적용할 수 있습니다. [서비스 제어 정책](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)(SCP)을 사용하면 AWS Organizations의 모든 계정에서 토큰 생성에 대해 조직 전체의 제한을 적용할 수 있습니다. [리소스 제어 정책](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)(RCP) 리소스 수준에서 액세스를 제어합니다. 또한 [VPC 엔드포인트 정책](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html)을 사용하여 VPC 엔드포인트를 통해 AWS STS `GetWebIdentityToken` API에 액세스할 수 있는 위탁자를 제한하여 보안 태세에 네트워크 수준 제어를 추가할 수 있습니다. 이 섹션에서는 이러한 정책 유형 및 조건 키를 사용하여 세분화된 액세스 제어를 구현하는 방법을 설명합니다.

ID 토큰을 요청하려면 IAM 위탁자에게 `sts:GetWebIdentityToken` 권한이 있어야 합니다. IAM 사용자 또는 역할에 연결된 ID 정책을 통해 이 권한을 부여합니다. 태그(키, 값 페어)가 GetWebIdentityToken 직접 호출에 전달되도록 허용하려면 IAM 위탁자에게 `sts:TagGetWebIdentityToken` 권한이 있어야 합니다.
+ [sts:IdentityTokenAudience](reference_policies_iam-condition-keys.md#ck_identitytokenaudience) 조건 키를 사용하여 토큰을 받을 수 있는 외부 서비스를 제한합니다.
+ [sts:DurationSeconds](reference_policies_iam-condition-keys.md#ck_durationseconds) 조건 키를 사용하여 최대 토큰 수명을 적용합니다.
+ [sts:SigningAlgorithm](reference_policies_iam-condition-keys.md#ck_signingalgorithm) 조건 키를 사용하여 특정 암호화 알고리즘을 요구합니다.
+ [aws:RequestTag](reference_policies_condition-keys.md#condition-keys-requesttag) 조건 키를 사용하여 요청에서 전달된 태그 키 값 페어를 정책에서 지정한 태그 페어와 비교합니다.
+ [aws:TagKeys](reference_policies_condition-keys.md#condition-keys-tagkeys) 조건 키를 사용하여 요청의 태그 키를 정책에서 지정한 키와 비교합니다.

IAM 정책에서 사용할 수 있는 조건 키에 대한 자세한 내용은 [IAM 및 AWS STS](reference_policies_iam-condition-keys.md) 조건 키를 참조하세요.

이 샘플 ID 정책은 여러 조건 키를 결합합니다.

```
{
    "Version": "2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowTokenGenerationWithRestrictions",
            "Effect": "Allow",
            "Action": "sts:GetWebIdentityToken",
            "Resource": "*",
            "Condition": {
                "ForAnyValue:StringEquals": {
                    "sts:IdentityTokenAudience": [
                        "https://api1.example.com",
                        "https://api2.example.com"
                    ]
                },
                "NumericLessThanEquals": {
                    "sts:DurationSeconds": 300
                },
                "StringEquals": {
                    "sts:SigningAlgorithm": "ES384"
                }
            }
        }
    ]
}
```

## 모범 사례
<a name="outbound-best-practices"></a>

다음 권장 사항에 따라 AWS ID를 외부 서비스에 안전하게 페더레이션합니다.
+ **짧은 토큰 수명 사용:** 운영 요구 사항을 충족하는 수명이 가장 짧은 토큰을 요청합니다.
+ **IAM 정책을 사용하여 최소 권한 액세스 구현 및 토큰 속성 제한:** 권한이 필요한 IAM 위탁자에게만 `sts:GetWebIdentityToken` 권한을 부여합니다. 조건 키를 사용하여 필요에 따라 서명 알고리즘, 허용된 토큰 대상 및 최대 토큰 수명을 지정합니다.
+ **외부 서비스의 클레임 검증:** 보안을 위해 항상 제목('sub'), 대상('aud') 등의 관련 클레임을 검증하여 예상 값과 일치하는지 확인합니다. 가능한 경우 사용자 지정 클레임을 검증하여 외부 서비스에서 세분화된 권한 부여 결정을 가능하게 합니다.

# IAM의 임시 보안 자격 증명
<a name="id_credentials_temp"></a>

AWS Security Token Service(AWS STS)를 사용하면 AWS 리소스에 대한 액세스를 제어할 수 있는 임시 보안 자격 증명을 생성하여 신뢰받는 사용자에게 제공할 수 있습니다. 임시 보안 인증은 다음과 같은 차이점을 제외하고는 장기 액세스 키 보안 인증과 거의 동일한 효력을 지닙니다.
+ 임시 보안 자격 증명은 그 이름이 암시하듯 *단기적*입니다. 이 자격 증명은 몇 분에서 몇 시간까지 지속되도록 구성할 수 있습니다. 자격 증명이 만료된 후 AWS는 더는 그 자격 증명을 인식하지 못하거나 그 자격 증명을 사용한 API 요청으로부터 이루어지는 어떤 종류의 액세스도 허용하지 않습니다.
+ 임시 보안 자격 증명은 사용자와 함께 저장되지 않지만 동적으로 생성되어 요청시 사용자에게 제공됩니다. 임시 보안 자격 증명이 만료되었을 때(심지어는 만료 전이라도) 사용자는 새 자격 증명을 요청할 수 있습니다. 단, 자격 증명을 요청하는 해당 사용자에게 그렇게 할 수 있는 권한이 있어야 합니다.

따라서 임시 보안 인증은 장기 보안 인증보다 다음과 같은 이점이 있습니다.
+ 애플리케이션으로 장기 AWS 보안 자격 증명을 배포 또는 포함할 필요가 없습니다.
+ 사용자에 대한 AWS 자격 증명을 정의하지 않고도 AWS 리소스에 대한 액세스 권한을 사용자에게 제공할 수 있습니다. 임시 자격 증명은 [역할](id_roles.md) 및 [ID 페더레이션](id_roles_providers.md)의 기반입니다.
+ 임시 보안 인증은 수명이 제한되어 있어서, 더 이상 필요하지 않을 때 업데이트하거나 명시적으로 취소할 필요가 없습니다. 임시 보안 자격 증명이 만료된 후에는 다시 사용할 수 없습니다. 그 자격 증명에 대해 유효 기간을 최대 한계까지 지정할 수 있습니다.

## AWS STS 및 AWS 리전
<a name="sts-regionalization"></a>

임시 보안 자격 증명은 AWS STS에 의해 생성됩니다. 기본적으로 AWS STS는 `https://sts.amazonaws.com`에 단일 엔드포인트가 있는 전역적 서비스입니다. 그러나 지원되는 기타 다른 리전에서 엔드포인트에 대한 AWS STS API 호출을 할 수도 있습니다. 이렇게 지리적으로 더 가까운 리전에 있는 서버로 요청을 전송함으로써 지연 시간(서버 랙)을 단축할 수 있습니다. 자격 증명은 어떤 리전에서 오는지 상관없이 전역적으로 유효합니다. 자세한 내용은 [AWS 리전에서 AWS STS 관리](id_credentials_temp_enable-regions.md) 섹션을 참조하세요.

## 임시 자격 증명과 관련된 일반적인 시나리오
<a name="sts-introduction"></a>

임시 자격 증명은 아이덴티티 페더레이션, 위임, 크로스 계정 액세스, IAM 역할 등의 시나리오에서 유용합니다.

### 아이덴티티 페더레이션
<a name="id-federation"></a>

AWS 밖의 외부 시스템에서 사용자 자격 증명을 관리할 수 있고 해당 시스템을 통해 로그인하는 사용자에게 액세스 권한을 부여하여 AWS 작업을 수행하고 AWS 리소스에 액세스할 수 있습니다. IAM은 두 가지 아이덴티티 페더레이션 유형을 지원합니다. 두 경우 모두 자격 증명은 AWS 외부에 저장됩니다. 외부 시스템이 상주하는 위치, 즉 데이터 센터 또는 웹의 외부 타사에 따라 구분됩니다. ID 페더레이션을 위한 임시 보안 자격 증명의 기능을 비교하려면 [AWS STS 자격 증명 비교](id_credentials_sts-comparison.md) 섹션을 참조하세요.

외부 자격 증명 공급자에 대한 자세한 내용은 [ID 공급자 및 AWS로의 페더레이션](id_roles_providers.md) 섹션을 참조하세요.
+ **OIDC(OpenID Connect) 페더레이션** - 사용자가 Amazon, Facebook 또는 Google로 로그인 또는 모바일 또는 웹 애플리케이션용 OIDC 2.0 호환 공급자와 같은 잘 알려진 타사 ID 공급자를 사용하여 로그인하도록 할 수 있으므로 사용자 지정 로그인 코드를 만들거나 자체 사용자 ID를 관리할 필요가 없습니다. OIDC 페더레이션을 사용하면 IAM 사용자 액세스 키와 같은 장기 보안 자격 증명을 애플리케이션에 배포할 필요가 없으므로 AWS 계정의 보안을 유지하는 데 도움이 됩니다. 자세한 내용은 [OIDC 페더레이션](id_roles_providers_oidc.md) 섹션을 참조하세요.

  AWS STS OIDC 페더레이션은 Amazon, Facebook 및 Google로 로그인과 모든 OIDC(OpenID Connect) 호환 ID 공급자를 지원합니다.
**참고**  
모바일 애플리케이션의 경우 Amazon Cognito를 사용하는 것이 좋습니다. 이 서비스와 함께 모바일 개발용 AWS SDK를 사용하면 사용자의 고유 자격 증명을 생성하고 인증하여 AWS 리소스에 안전하게 액세스하도록 할 수 있습니다. Amazon Cognito는 AWS STS와 동일한 자격 증명 공급자를 지원하고 인증되지 않은(게스트) 액세스도 지원하며 사용자가 로그인할 때 사용자 데이터를 마이그레이션할 수 있습니다. 또한, Amazon Cognito는 사용자가 디바이스 간에 이동할 때 데이터가 보존되도록 사용자 데이터를 동기화하기 위한 API 작업도 제공합니다. 자세한 내용은 *Amplify 설명서*의 [Amplify를 사용한 인증](https://docs.amplify.aws/lib/auth/getting-started/q/platform/js/#authentication-with-amplify)을 참조하세요.
+ **SAML 페더레이션** - 조직의 네트워크에서 사용자를 인증한 다음, 해당 사용자에게 새로운 AWS ID를 만들거나 다른 로그인 자격 증명을 사용하여 로그인하도록 요구하지 않고도 해당 사용자에게 AWS에 대한 액세스 권한을 제공할 수 있습니다. 이는 임시 액세스 권한에 대한 *Single Sign-On* 접근 방식으로 알려져 있습니다. AWS STS는 SAML 2.0(Security Assertion Markup Language 2.0)과 같은 개방형 표준을 지원합니다. 이를 통해 Microsoft AD FS를 사용해 Microsoft Active Directory를 최대한 활용할 수 있습니다. 또한, SAML 2.0을 사용해 사용자 자격 증명 연동을 위한 자신만의 솔루션을 관리할 수 있습니다. 자세한 내용은 [SAML 2.0 연동](id_roles_providers_saml.md) 섹션을 참조하세요.
  + **사용자 지정 페더레이션 브로커** - 조직의 인증 시스템을 사용해 AWS 리소스에 대한 액세스 권한을 부여할 수 있습니다. 시나리오 예시는 [AWS 콘솔에 대한 사용자 지정 ID 브로커 액세스 활성화](id_roles_providers_enable-console-custom-url.md) 섹션을 참조하세요.
  + **SAML 2.0을 사용한 페더레이션** - 조직의 인증 시스템과 SAML을 사용해 AWS 리소스에 대한 액세스 권한을 부여할 수 있습니다. 자세한 내용과 시나리오 예시는 [SAML 2.0 연동](id_roles_providers_saml.md) 섹션을 참조하세요.

### 크로스 계정 액세스를 위한 역할
<a name="role_cross-account"></a>

많은 조직이 1개 이상의 AWS 계정을 유지합니다. 역할 및 크로스 계정 액세스를 사용하면 하나의 계정에서 사용자 자격 증명을 정의하고 그 자격 증명을 사용해 조직에 속한 다른 계정의 AWS 리소스에 액세스할 수 있습니다. 이는 임시 액세스 권한에 대한 *위임* 접근 방식으로 알려져 있습니다. 크로스 계정 역할 생성에 대한 자세한 내용은 [IAM 사용자에게 권한을 부여할 역할 생성](id_roles_create_for-user.md) 섹션을 참조하세요. 해당 신뢰 영역(신뢰할 수 있는 조직 또는 계정) 외의 계정 내 보안 주체가 역할을 수임하는 권한이 있는지 자세히 알고 싶다면, [IAM Access Analyzer란 무엇일까요?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)를 참조하세요.

### Amazon EC2의 역할
<a name="role_ec2"></a>

Amazon EC2 인스턴스에서 애플리케이션을 실행할 때 그 애플리케이션이 AWS 리소스에 대한 액세스 권한이 필요한 경우 인스턴스 시작 시 인스턴스에 대한 임시 보안 자격 증명을 제공할 수 있습니다. 이 임시 보안 자격 증명은 인스턴스에서 실행되는 모든 애플리케이션에서 사용 가능하므로 그 인스턴스에 어떤 장기 자격 증명도 저장할 필요가 없습니다. 자세한 내용은 [IAM 역할을 사용하여 Amazon EC2 인스턴스에서 실행되는 애플리케이션에 권한 부여](id_roles_use_switch-role-ec2.md) 섹션을 참조하세요.

IAM Amazon EC2 역할 자격 증명에 대한 자세한 내용은 **Amazon Elastic Compute Cloud 사용 설명서의 [Amazon EC2의 IAM 역할](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html)을 참조하세요.

### 기타 AWS 서비스
<a name="other-services"></a>

임시 보안 보안 인증을 사용해 대부분의 AWS 서비스에 액세스할 수 있습니다. 임시 보안 자격 증명을 수락하는 서비스의 목록은 [AWS IAM으로 작업하는 서비스](reference_aws-services-that-work-with-iam.md) 섹션을 참조하세요.

## 임시 자격 증명을 사용하는 샘플 애플리케이션
<a name="id_credentials_temp_sample-apps"></a>

AWS Security Token Service(AWS STS)를 사용하면 AWS 리소스에 대한 액세스를 제어할 수 있는 임시 보안 자격 증명을 생성하여 신뢰받는 사용자에게 제공할 수 있습니다. 에 대한 자세한 내용은 AWS STS 섹션을 참조하세요.[IAM의 임시 보안 자격 증명](#id_credentials_temp). AWS STS를 사용해 임시 보안 자격 증명을 관리하는 방법에 대해 알아보려면, 완전한 샘플 시나리오를 구현하는 다음과 같은 샘플 애플리케이션을 다운로드하세요.
+ [Windows Active Directory, ADFS 및 SAML 2.0을 사용하여 AWS에 대한 페더레이션 활성화](https://aws.amazon.com/blogs/security/enabling-federation-to-aws-using-windows-active-directory-adfs-and-saml-2-0/). Windows Active Directory(AD), Active Directory Federation Services(ADFS) 2.0 및 SAML(Security Assertion Markup Language) 2.0을 사용하여 엔터프라이즈 페더레이션을 사용하여 AWS에 액세스를 위임하는 방법을 보여 줍니다.
+ [AWS 콘솔에 대한 사용자 지정 ID 브로커 액세스 활성화](id_roles_providers_enable-console-custom-url.md). Single-Sign-On(SSO)을 가능케 하는 사용자 지정 페더레이션 프록시를 생성해 기존 Active Directory 사용자가 AWS Management Console에 로그인할 수 있게 하는 방법을 보여줍니다.
+ [AWS Management Console에 대한 Single-Sign-On(SSO)에 대해 Shibboleth를 사용하는 방법.](https://aws.amazon.com/blogs/security/how-to-use-shibboleth-for-single-sign-on-to-the-aws-management-console/). [Shibboleth](http://shibboleth.net/) 및 [SAML](id_roles_providers_saml.md)을 사용해 사용자에게 AWS Management Console에 대한 SSO(Single-Sign-On) 액세스 권한을 제공하는 방법을 보여줍니다.

### OIDC 페더레이션의 샘플
<a name="sts-sample-apps-wif"></a>

다음 샘플 애플리케이션은 Login with Amazon, Amazon Cognito, Facebook 또는 Google 같은 공급자를 통해 OIDC 페더레이션을 사용하는 방법을 보여 줍니다. 이러한 임시 AWS 보안 자격 증명에 대해 이러한 공급자의 인증을 얻고 AWS 서비스에 액세스할 수 있습니다.
+ [Amazon Cognito 튜토리얼](https://docs.aws.amazon.com/cognito/latest/developerguide/tutorials.html) - 모바일 개발용 AWS SDK와 함께 Amazon Cognito를 사용하는 것이 좋습니다. Amazon Cognito는 모바일 앱을 위한 자격 증명을 관리하는 가장 간단한 방법으로서, 동기화 및 교차 디바이스 자격 증명과 같은 부가 기능을 제공합니다. Amazon Cognito에 대한 자세한 내용은 *Amplify 설명서*의 [Amplify를 사용한 인증](https://docs.amplify.aws/lib/auth/getting-started/q/platform/js/#authentication-with-amplify)을 참조하세요.

## 임시 보안 자격 증명에 관한 추가 리소스
<a name="id_credentials_temp_related-topics"></a>

다음 시나리오 및 애플리케이션은 임시 보안 자격 증명 사용 방법을 안내합니다.
+ [AWS STSSourceIdentity를 ID 공급자와 통합하는 방법](https://aws.amazon.com/blogs/security/how-to-integrate-aws-sts-sourceidentity-with-your-identity-provider/). 이 게시물에서는 Okta, Ping 또는 OneLogin을 IdP로 사용할 때 AWS STS `SourceIdentity` 속성을 설정하는 방법을 보여줍니다.
+  [OIDC 페더레이션](id_roles_providers_oidc.md). 이 섹션에서는 OIDC 페더레이션 및 `AssumeRoleWithWebIdentity` API를 사용할 때 IAM 역할을 구성하는 방법을 설명합니다.
+ [MFA를 통한 보안 API 액세스](id_credentials_mfa_configure-api-require.md)이 주제는 역할을 사용해 멀티 팩터 인증(MFA)이 계정에서 민감한 API 작업을 보호하도록 요구하는 방법을 설명합니다.

AWS의 정책 및 권한에 대한 자세한 내용은 다음 주제를 참조하세요.
+ [AWS리소스에 대한 액세스 관리](access.md)
+ [정책 평가 로직](reference_policies_evaluation-logic.md).
+ *Amazon Simple Storage Service 사용 설명서*의 [Amazon S3 리소스에 대한 액세스 권한 관리](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-access-control.html)를 참조하세요.
+  해당 신뢰 영역(신뢰할 수 있는 조직 또는 계정) 외의 계정 내 보안 주체가 역할을 수임하는 권한이 있는지 자세히 알고 싶다면, [IAM Access Analyzer란 무엇일까요?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)를 참조하세요.

# AWS STS 자격 증명 비교
<a name="id_credentials_sts-comparison"></a>

다음 표는 임시 보안 자격 증명을 반환하는 AWS STS의 API 작업이 수행하는 기능을 비교해 보여줍니다. 역할을 수임해 임시 보안 자격 증명을 요청하는 데 사용할 수 있는 여러 방법을 알아보려면 [역할 수임 방법](id_roles_manage-assume.md) 섹션을 참조하세요. 세션 태그를 전달할 수 있는 다양한 AWS STS API 작업에 대한 자세한 내용은 [AWS STS에서 세션 태그 전달](id_session-tags.md) 섹션을 참조하세요.

**참고**  
전역 엔드포인트 또는 리전 엔드포인트 중 하나에 AWS STS API 호출을 전송할 수 있습니다. 더 가까이 있는 엔드포인트를 선택하면 지연 시간을 단축해 API 호출의 성능을 향상시킬 수 있습니다. 또한 원래 엔드포인트와 더 이상 통신하지 할 수 없는 경우 대체 리전 엔드포인트에 호출을 직접 보내는 방법을 선택할 수 있습니다. 다양한 AWS SDK 중 하나를 사용하고 있다면 API 호출 전에 해당 SDK 방법을 사용해 리전을 지정합니다. HTTP API 요청을 수동으로 구축하는 경우 그 요청을 정확한 엔드포인트에 직접 전송해야 합니다. 자세한 내용은 [https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region) 및 [AWS 리전에서 AWS STS 관리](id_credentials_temp_enable-regions.md) 섹션을 참조하세요.


|  **AWS STS API**  |  **호출할 수 있는 사용자**  |  **자격 증명의 수명(최소 \$1 최대 \$1 기본)**  |  **MFA 지원**¹  |  **세션 정책 지원**²  |  **결과로 얻은 임시 자격 증명에 대한 제한**  | 
| --- | --- | --- | --- | --- | --- | 
|  [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)  | IAM 사용자 또는 기존 임시 보안 자격 증명이 있는 IAM 역할  | 15분 \$1 최대 세션 기간 설정³ \$1 1시간  | 예  | 예 |  `GetFederationToken` 또는 `GetSessionToken` 호출 불가  | 
|  [AssumeRoleWithSAML](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html)  | 어떤 사용자나 호출자도 잘 알려진 자격 증명 공급자의 인증을 나타내는 SAML 인증 응답을 반드시 전달해야 합니다. | 15분 \$1 최대 세션 기간 설정³ \$1 1시간  | 아니요 | 예 |  `GetFederationToken` 또는 `GetSessionToken` 호출 불가  | 
|  [AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)  | 모든 사용자, 호출자는 알려진 ID 공급자의 인증을 나타내는 OIDC 호환 JWT 토큰을 반드시 전달해야 합니다. | 15분 \$1 최대 세션 기간 설정³ \$1 1시간  | 아니요 | 예 |  `GetFederationToken` 또는 `GetSessionToken` 호출 불가  | 
| [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) | IAM 사용자 또는 AWS 계정 루트 사용자 |  IAM 사용자: 15분 \$1 36시간 \$1 12시간 루트 사용자: 15분 \$1 1시간 \$1 1시간  | 아니요  | 예  |  AWS CLI 또는 AWS API를 사용하여 IAM 작업을 호출할 수 없습니다. 이 제한은 콘솔 세션에는 적용되지 않습니다. `GetCallerIdentity`를 제외한 AWS STS 작업을 호출할 수 없습니다.⁴ 콘솔로의 SSO가 허용됩니다.⁵  | 
| [GetSessionToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) | IAM 사용자 또는 AWS 계정 루트 사용자 |  IAM 사용자: 15분 \$1 36시간 \$1 12시간 루트 사용자: 15분 \$1 1시간 \$1 1시간  | 예  | 아니요  |  요청에 MFA 정보를 포함되지 않으면 IAM API 작업을 호출할 수 없습니다. `AssumeRole` 또는 `GetCallerIdentity`를 제외한 AWS STS API 작업 호출 불가 콘솔로의 SSO는 허용되지 않습니다.⁶  | 

 ¹ ** MFA 지원**. AssumeRole 및 GetSessionToken API 작업을 호출할 때 멀티 팩터 인증(MFA)에 대한 정보를 포함시킬 수 있습니다. 이는 API 호출의 결과물인 임시 보안 자격 증명을 MFA 디바이스로 인증된 사용자들만 사용할 수 있게 해줍니다. 자세한 내용은 [MFA를 통한 보안 API 액세스](id_credentials_mfa_configure-api-require.md) 섹션을 참조하세요.

 ² ** 세션 정책 지원**. 세션 정책은 역할 또는 AWS STS 페더레이션 사용자 세션에 대해 임시 세션을 프로그래밍 방식으로 생성할 때 파라미터로 전달하는 정책입니다. 이 정책은 세션에 할당된 역할/사용자 자격 증명 기반 정책의 권한을 제한합니다. 결과적으로 얻는 세션의 권한은 엔터티의 자격 증명 기반 정책과 세션 정책의 교집합입니다 세션 정책을 사용하여 수임된 역할의 자격 증명 기반 정책에서 허용되는 것보다 더 많은 권한을 부여할 수는 없습니다. 역할 세션 권한에 대한 자세한 정보는 [세션 정책](access_policies.md#policies_session) 섹션을 참조하세요.

³ ** 최대 세션 기간 설정**. `DurationSeconds` 파라미터를 사용하여 역할 세션 기간을 900초(15초)에서 해당 역할에 대한 최대 세션 기간 설정까지 지정합니다. 역할에 대한 최댓값을 확인하는 방법을 알아보려면 [역할의 최대 세션 기간 업데이트](id_roles_update-role-settings.md#id_roles_update-session-duration) 섹션을 참조하세요.

⁴ **GetCallerIdentity**. 이 작업을 실행하는 데 따로 권한이 필요하지 않습니다. 관리자가 `sts:GetCallerIdentity` 작업에 대한 액세스를 명시적으로 거부하는 정책을 IAM 사용자 또는 역할에게 추가하더라도 이 작업을 계속해서 실행할 수 있습니다. 권한이 필요하지 않은 이유는 IAM 사용자 또는 역할의 액세스가 거부되어도 반환되는 정보는 동일하기 때문입니다. 응답 예제를 보려면 [iam:DeleteVirtualMFADevice를 수행할 권한이 없음](troubleshoot.md#troubleshoot_general_access-denied-delete-mfa) 섹션을 참조하세요.

⁵ **콘솔로 SSO(Single Sign-On)하기** SSO를 지원하기 위해 AWS는 페더레이션 엔드포인트(`https://signin.aws.amazon.com/federation`)를 호출해 임시 보안 자격 증명을 전달할 수 있게 해줍니다. 엔드포인트는 암호 없이도 사용자를 콘솔에 바로 로그인시켜주는 URL을 구성하는 데 사용 가능한 토큰을 반환합니다. 자세한 내용은 AWS 보안 블로그에서 [SAML 2.0 페더레이션 위탁자의 AWS Management Console 액세스 활성화](id_roles_providers_enable-console-saml.md) 및 [AWS 관리 콘솔에 대한 크로스 계정 액세스를 활성화하는 방법](https://aws.amazon.com/blogs/security/how-to-enable-cross-account-access-to-the-aws-management-console)을 참조하세요.

⁶ 임시 자격 증명을 검색한 이후에 연동 SSO 엔드포인트로 자격 증명을 전달하여 ​AWS Management Console에 액세스할 수 없습니다. 자세한 내용은 [AWS 콘솔에 대한 사용자 지정 ID 브로커 액세스 활성화](id_roles_providers_enable-console-custom-url.md) 섹션을 참조하세요.

# 서비스 보유자 토큰
<a name="id_credentials_bearer"></a>

일부 AWS 서비스의 경우 프로그래밍 방식으로 리소스에 액세스하기 전에 AWS STS 서비스 보유자 토큰을 가져올 수 있는 권한이 있어야 합니다. 이러한 서비스는 기존의 [API 요청용 AWS Signature Version 4](reference_sigv.md)를 사용하는 대신 보유자 토큰을 사용해야 하는 프로토콜을 지원합니다. 보유자 토큰이 필요한 AWS CLI 또는 AWS API 작업을 수행할 때 AWS 서비스는 사용자를 대신하여 보유자 토큰을 요청합니다. 이 서비스는 토큰을 제공하므로 해당 서비스에서 후속 작업을 수행하는 데 사용할 수 있습니다.

AWS STS 서비스 보유자 토큰에는 권한에 영향을 줄 수 있는 원래 보안 주체 인증 정보가 포함됩니다. 이 정보에는 보안 주체 태그, 세션 태그 및 세션 정책이 포함될 수 있습니다. 토큰의 액세스 키 ID는 `ABIA` 접두사로 시작합니다. 이렇게 하면 CloudTrail 로그에서 서비스 보유자 토큰을 사용하여 수행된 작업을 식별할 수 있습니다.

**중요**  
보유자 토큰은 이 토큰을 생성하는 서비스에 대한 호출과 이 토큰이 생성된 리전에서만 사용할 수 있습니다. 보유자 토큰을 사용하여 다른 서비스 또는 리전에서 작업을 수행할 수 없습니다.

보유자 토큰을 지원하는 서비스의 예는 AWS CodeArtifact입니다. NPM, Maven 또는 PIP와 같은 패키지 관리자를 사용하여 AWS CodeArtifact와 상호 작용하기 전에 `aws codeartifact get-authorization-token` 작업을 호출해야 합니다. 이 작업은 AWS CodeArtifact 작업을 수행하는 데 사용할 수 있는 보유자 토큰을 반환합니다. 또는 동일한 작업을 완료한 다음 클라이언트를 자동으로 구성하는 `aws codeartifact login` 명령을 사용할 수 있습니다.

AWS 서비스에서 보유자 토큰을 생성하는 작업을 수행하는 경우 IAM 정책에 다음 권한이 있어야 합니다.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowServiceBearerToken",
            "Effect": "Allow",
            "Action": "sts:GetServiceBearerToken",
            "Resource": "*"
        }
    ]
}
```

------

서비스 보유자 토큰의 예는 *AWS CodeArtifact* 사용 설명서의 [AWS CodeArtifact에 대한 자격 증명 기반 정책 사용](https://docs.aws.amazon.com/codeartifact/latest/ug/auth-and-access-control-iam-identity-based-access-control.html) 섹션을 참조하세요.

# 임시 보안 자격 증명 요청
<a name="id_credentials_temp_request"></a>

임시 보안 자격 증명을 요청하려면 AWS API에서 AWS Security Token Service(AWS STS) 작업을 사용할 수 있습니다. 이러한 작업에는 AWS 리소스에 대한 액세스를 제어할 수 있는 임시 보안 자격 증명을 생성하여 신뢰할 수 있는 사용자에게 제공할 수 있습니다. 에 대한 자세한 내용은 AWS STS 섹션을 참조하세요.[IAM의 임시 보안 자격 증명](id_credentials_temp.md). 역할을 수임해 임시 보안 자격 증명을 요청하는 데 사용할 수 있는 여러 방법을 알아보려면 [역할 수임 방법](id_roles_manage-assume.md) 섹션을 참조하세요.

API 작업을 호출하려면 [AWS SDK](https://aws.amazon.com/tools/) 중 하나를 사용할 수 있습니다. SDK는 Java, .NET, Python, Ruby, Android 및 iOS 등 다양한 프로그래밍 언어 및 환경에서 사용할 수 있습니다. SDK는 요청에 암호화 방식으로 서명, 필요한 경우 요청 재시도, 오류 응답 처리와 같은 작업들을 다룹니다. [AWS Security Token Service API 참조](https://docs.aws.amazon.com/STS/latest/APIReference/)에 설명된 AWS STS 쿼리 API를 사용할 수도 있습니다. 마지막으로, [AWS Command Line Interface](https://aws.amazon.com/documentation/cli) 및 [AWS Tools for Windows PowerShell](https://aws.amazon.com/documentation/powershell)의 두 가지 명령 줄 도구에서 AWS STS 명령을 지원합니다.

AWS STS API 작업은 액세스 키 페어 및 세션 토큰을 포함하는 임시 보안 자격 증명을 사용하여 새 세션을 생성합니다. 액세스 키 페어는 액세스 키 ID와 보안 키로 구성되어 있습니다. 사용자(또는 사용자가 실행하는 애플리케이션)는 이 자격 증명을 사용해 리소스에 액세스할 수 있습니다. AWS STS API 작업을 사용하여 프로그래밍 방식으로 역할 세션을 생성하고 세션 정책 및 세션 태그를 전달할 수 있습니다. 결과적으로 얻는 세션의 권한은 사용자 또는 역할의 자격 증명 기반 정책의 교집합과 세션 정책입니다. 세션 정책에 대한 자세한 정보는 [세션 정책](access_policies.md#policies_session) 섹션을 참조하세요. 세션 태그에 대한 자세한 내용은 [AWS STS에서 세션 태그 전달](id_session-tags.md) 섹션을 참조하세요.

**참고**  
AWS STS API 작업이 반환하는 세션 토큰의 크기는 고정적이지 않습니다. 따라서 최대 크기를 가정하지 않는 것이 좋습니다. 일반적인 토큰 크기는 4096바이트 미만이나 경우에 따라 다를 수 있습니다.

## AWS 리전에서 AWS STS 사용하기
<a name="using_sts_regions"></a>

전역 엔드포인트 또는 리전 엔드포인트 중 하나에 AWS STS API 호출을 전송할 수 있습니다. 더 가까이 있는 엔드포인트를 선택하면 지연 시간을 단축해 API 호출의 성능을 향상시킬 수 있습니다. 또한 원래 엔드포인트와 더 이상 통신하지 할 수 없는 경우 대체 리전 엔드포인트에 호출을 직접 보내는 방법을 선택할 수 있습니다. 다양한 AWS SDK 중 하나를 사용하고 있다면 API 호출 전에 해당 SDK 방법을 사용해 리전을 지정합니다. HTTP API 요청을 수동으로 구축하는 경우 그 요청을 정확한 엔드포인트에 직접 전송해야 합니다. 자세한 내용은 [https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region) 및 [AWS 리전에서 AWS STS 관리](id_credentials_temp_enable-regions.md) 섹션을 참조하세요.

다음은 AWS 환경 및 애플리케이션에서 사용할 임시 자격 증명을 획득하는 데 사용할 수 있는 API 작업입니다.

## 사용자 지정 ID 브로커를 통해 크로스 계정 위임 및 페더레이션을 위한 자격 증명 요청
<a name="api_assumerole"></a>

[https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html) API 작업은 기존 IAM 사용자가 아직 액세스 권한이 없는 AWS 리소스에 액세스할 수 있도록 허용하는 데 유용합니다. 예를 들어 사용자가 다른 AWS 계정의 리소스에 액세스해야 할 수 있습니다. 또한 멀티 팩터 인증(MFA)을 제공하는 것과 같이 일시적으로 액세스 권한을 얻는 수단으로도 유용합니다. 활성 자격 증명을 사용해 이 API를 호출해야 합니다. 이 작업을 호출할 수 있는 사용자를 알아보려면 [AWS STS 자격 증명 비교](id_credentials_sts-comparison.md)을(를) 참조하세요. 자세한 내용은 [IAM 사용자에게 권한을 부여할 역할 생성](id_roles_create_for-user.md) 및 [MFA를 통한 보안 API 액세스](id_credentials_mfa_configure-api-require.md)(을)를 참조하세요.

**사용자 지정 ID 브로커를 통해 크로스 계정 위임 및 페더레이션을 위한 임시 보안 자격 증명을 요청하는 방버**

1. AWS 보안 자격 증명으로 인증합니다. 이 호출에는 반드시 유효한 AWS 보안 자격 증명을 사용해야 합니다.

1. [https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com//STS/latest/APIReference/API_AssumeRole.html) 작업을 직접적으로 호출합니다.

다음 예제에서는 `AssumeRole`을 사용한 샘플 요청 및 응답을 보여줍니다. 이 예제 요청에서는 지정된 기간 동안 [세션 정책](access_policies.md#policies_session), [세션 태그](id_session-tags.md), [외부 ID](id_roles_common-scenarios_third-party.md) 및[소스 자격 증명](id_credentials_temp_control-access_monitor.md)이 포함된 `demo` 역할을 가정합니다. 결과 세션의 이름이 `John-session`으로 지정됩니다.

**Example 요청 예제**  

```
https://sts.amazonaws.com/
?Version=2011-06-15
&Action=AssumeRole
&RoleSessionName=John-session
&RoleArn=arn:aws::iam::123456789012:role/demo
&Policy=%7B%22Version%22%3A%222012-10-17		 	 	 %22%2C%22Statement%22%3A%5B%7B%22Sid%22%3A%20%22Stmt1%22%2C%22Effect%22%3A%20%22Allow%22%2C%22Action%22%3A%20%22s3%3A*%22%2C%22Resource%22%3A%20%22*%22%7D%5D%7D
&DurationSeconds=1800
&Tags.member.1.Key=Project
&Tags.member.1.Value=Pegasus
&Tags.member.2.Key=Cost-Center
&Tags.member.2.Value=12345
&ExternalId=123ABC
&SourceIdentity=DevUser123
&AUTHPARAMS
```

이전 예제의 정책 값은 다음 정책을 URL로 인코딩한 버전입니다.

------
#### [ JSON ]

****  

```
{"Version":"2012-10-17",		 	 	 "Statement":[{"Sid":"Stmt1","Effect":"Allow","Action":"s3:*","Resource":"*"}]}
```

------

예시의 `AUTHPARAMS` 파라미터는 *서명*에 대한 자리 표시자입니다. 서명은 AWS HTTP API 요청에 포함해야 하는 인증 정보입니다. [AWS SDK](https://aws.amazon.com/tools/)를 사용하여 API 요청을 생성하는 것이 좋습니다. 이렇게 하면 SDK가 요청 서명을 대신 처리한다는 장점이 있습니다. API 요청을 수동으로 생성하고 서명해야 하는 경우 요청에 서명하는 방법을 알아보려면 **Amazon Web Services 일반 참조의 [Signature Version 4를 사용하여 AWS 요청에 서명](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html)을 참조하세요.

그 응답에는 임시 보안 자격 증명뿐만 아니라 페더레이션 사용자 및 자격 증명 만료 시간에 대한 Amazon 리소스 이름(ARN)이 포함되어 있습니다.

**Example 응답의 예**  

```
<AssumeRoleResponse xmlns="https://sts.amazonaws.com/doc/2011-06-15/">
<AssumeRoleResult>
<SourceIdentity>DevUser123</SourceIdentity>
<Credentials>
  <SessionToken>
   AQoDYXdzEPT//////////wEXAMPLEtc764bNrC9SAPBSM22wDOk4x4HIZ8j4FZTwdQW
   LWsKWHGBuFqwAeMicRXmxfpSPfIeoIYRqTflfKD8YUuwthAx7mSEI/qkPpKPi/kMcGd
   QrmGdeehM4IC1NtBmUpp2wUE8phUZampKsburEDy0KPkyQDYwT7WZ0wq5VSXDvp75YU
   9HFvlRd8Tx6q6fE8YQcHNVXAkiY9q6d+xo0rKwT38xVqr7ZD0u0iPPkUL64lIZbqBAz
   +scqKmlzm8FDrypNC9Yjc8fPOLn9FX9KSYvKTr4rvx3iSIlTJabIQwj2ICCR/oLxBA==
  </SessionToken>
  <SecretAccessKey>
   wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY
  </SecretAccessKey>
  <Expiration>2019-07-15T23:28:33.359Z</Expiration>
  <AccessKeyId>AKIAIOSFODNN7EXAMPLE</AccessKeyId>
</Credentials>
<AssumedRoleUser>
  <Arn>arn:aws:sts::123456789012:assumed-role/demo/John</Arn>
  <AssumedRoleId>ARO123EXAMPLE123:John</AssumedRoleId>
</AssumedRoleUser>
<PackedPolicySize>8</PackedPolicySize>
</AssumeRoleResult>
<ResponseMetadata>
<RequestId>c6104cbe-af31-11e0-8154-cbc7ccf896c7</RequestId>
</ResponseMetadata>
</AssumeRoleResponse>
```

**참고**  
AWS 변환은 전달된 세션 정책과 세션 태그를 별도의 제한이 있는 압축된 이진 형식으로 압축합니다. 일반 텍스트가 다른 요구 사항을 충족하는 경우에도 이 제한으로 인해 요청이 실패할 수 있습니다. `PackedPolicySize` 응답 요소는 요청에 대한 정책 및 태그가 상위 크기 제한과 얼마나 가까운지를 백분율로 나타냅니다.

## OIDC 공급자를 통해 자격 증명 요청
<a name="api_assumerolewithwebidentity"></a>

[https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) API 작업은 JSON 웹 토큰(JWT) 대신 임시 AWS 보안 자격 증명 세트를 반환합니다. 여기에는 Login with Amazon, Facebook, Google과 같은 퍼블릭 ID 제공업체와 GitHub 작업 또는 Azure Devops와 같이 OpenID Connect(OIDC) 검색과 호환되는 JWT를 발급하는 제공업체가 포함됩니다. 자세한 내용은 [OIDC 페더레이션](id_roles_providers_oidc.md) 섹션을 참조하세요.

**참고**  
`AssumeRoleWithWebIdentity` 요청은 서명되지 않으며 AWS 자격 증명이 필요하지 않습니다.

**OIDC 공급자를 통해 자격 증명 요청**

1. [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) 작업을 직접적으로 호출합니다.

   `AssumeRoleWithWebIdentity`를 직접 호출하는 경우 AWS에서는 IdP의 JSON 웹 키 세트(JWKS)를 통해 사용할 수 있는 퍼블릭 키를 사용해 디지털 서명을 확인함으로써 제시된 토큰의 유효성을 검증합니다. 토큰이 유효하고 IAM 역할 신뢰 정책에 명시된 모든 조건이 충족되면 AWS에서는 다음 정보를 반환합니다.
   + 일련의 임시 보안 자격 증명 이러한 임시 보안 자격 증명은 액세스 키 ID, 보안 액세스 키 및 세션 토큰으로 이루어져 있습니다.
   + 위임된 역할의 역할 ID 및 ARN
   + 고유한 사용자 ID를 포함하는 `SubjectFromWebIdentityToken` 값

1. 그러면 애플리케이션에서는 응답에서 반환된 임시 보안 자격 증명을 사용하여 AWS API를 직접 호출할 수 있습니다. 이는 장기 보안 자격 증명을 사용한 AWS API 호출과 동일한 프로세스입니다. 차이점은 AWS에서 임시 보안 자격 증명이 유효한지 확인하도록 하는 세션 토큰을 포함해야 한다는 점입니다.

애플리케이션은 AWS STS에서 반환한 자격 증명을 캐시하고 필요에 따라 새로 고쳐야 합니다. 애플리케이션이 AWS SDK를 사용하여 빌드된 경우 SDK에는 `AssumeRoleWithWebIdentity`를 직접 호출하고 만료되기 전에 AWS 자격 증명을 새로 고치는 작업을 처리할 수 있는 자격 증명 제공업체가 있습니다. 자세한 내용은 *AWS SDKs and Tools 참조 안내서*의 [AWS SDKs and Tools standardized credential providers](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html)를 참조하세요.

## SAML 2.0 ID 제공업체를 통해 자격 증명 요청
<a name="api_assumerolewithsaml"></a>

[https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) API 작업은 조직의 기존 ID 시스템을 통해 인증된 SAML 페더레이션 보안 주체의 임시 보안 자격 증명 세트를 반환합니다. 또한 사용자는 [SAML](https://www.oasis-open.org/standards#samlv2.0) 2.0(Security Assertion Markup Language)을 사용하여 AWS에 인증 및 권한 부여 정보를 전달해야 합니다. 이 API 작업은 자격 증명 시스템(예: Windows Active Directory 또는 OpenLDAP)을 SAML 어설션을 생성할 수 있는 소프트웨어와 통합한 조직에 유용합니다. 이러한 통합은 사용자 자격 증명 및 권한에 대한 정보를 제공합니다(예: Active Directory Federation Services 또는 Shibboleth). 자세한 내용은 [SAML 2.0 연동](id_roles_providers_saml.md) 섹션을 참조하세요.

1. [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) 작업을 직접적으로 호출합니다.

   이는 서명되지 않은 직접 호출로, 요청하기 전에 AWS 보안 자격 증명을 인증할 필요가 없습니다.
**참고**  
`AssumeRoleWithSAML`에 대한 호출이 서명(암호화)되지 않았습니다. 따라서 요청이 신뢰할 수 있는 중개자를 통해 전송된 경우에만 선택적 세션 정책을 포함해야 합니다. 이러한 경우 누군가가 정책을 변경해 제한을 제거할 수 있습니다.

1. `AssumeRoleWithSAML`을 호출하면 AWS가 SAML 어설션의 신뢰성을 확인합니다. 자격 증명 공급자가 어설션을 확인한다고 가정하면, AWS는 다음 정보를 반환합니다.
   + 일련의 임시 보안 자격 증명 이러한 임시 보안 자격 증명은 액세스 키 ID, 보안 액세스 키 및 세션 토큰으로 이루어져 있습니다.
   + 위임된 역할의 역할 ID 및 ARN 
   + SAML 어설션의 `Audience` 요소의 `Recipient` 속성 값을 포함하는 `SubjectConfirmationData` 값
   + SAML 어설션의 `Issuer` 요소 값을 포함하는 `Issuer` 값
   + `Issuer` 값, AWS 계정 ID, SAML 공급자의 표시 이름으로 구축된 해시 값을 포함하는 `NameQualifier` 요소 `Subject` 요소와 결합되면 SAML 페더레이션 보안 주체를 고유한 이름으로 식별할 수 있습니다.
   + SAML 어설션의 `Subject` 요소에 있는 `NameID` 요소의 값을 포함하는 `Subject` 요소
   + `SubjectType` 요소의 형식을 나타내는 `Subject` 요소 그 값은 `persistent`, `transient`, 또는 SAML 어설션에서 사용되는 `Format` 및 `Subject` 요소의 전체 `NameID` URI일 수 있습니다. `NameID` 요소의 `Format` 속성에 대한 자세한 내용은 [인증 응답에 대한 SAML 어설션 구성](id_roles_providers_create_saml_assertions.md) 섹션을 참조하세요.

1. 응답에서 반환된 임시 보안 자격 증명을 사용하여 AWS API를 직접 호출합니다. 이는 장기 보안 자격 증명을 사용한 AWS API 호출과 동일한 프로세스입니다. 차이점은 AWS에서 임시 보안 자격 증명이 유효한지 확인하도록 하는 세션 토큰을 포함해야 한다는 점입니다.

앱은 자격 증명을 캐싱해야 합니다. 자격 증명은 한 시간 후에 만료되도록 기본 설정되어 있습니다. AWS SDK에서 [AmazonSTSCredentialsProvider](https://aws.amazon.com/blogs/mobile/using-the-amazoncredentialsprovider-protocol-in-the-aws-sdk-for-ios) 작업을 사용하지 않는 경우 사용자 및 사용자 앱에서 `AssumeRoleWithSAML`을 다시 호출해야 합니다. 이전 자격 증명이 만료되기 전에 이 작업을 호출하여 임시 보안 자격 증명 세트를 새로 받으세요.

## 사용자 지정 ID 브로커를 통해 자격 증명 요청
<a name="api_getfederationtoken"></a>

[https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) API 작업은 AWS STS 페더레이션 사용자 보안 주체에게 임시 보안 자격 증명 세트를 반환합니다. 이 API는 기본 만료 기간이 상당히 길다는 점이(1시간이 아니라12시간) `AssumeRole`과 다릅니다. 또한 `DurationSeconds` 파라미터를 사용하여 임시 보안 자격 증명이 유효하게 남아 있을 기간을 지정할 수 있습니다. 결과 보안 인증 정보는 900초(15분)\$1129,600초(36시간)의 지정된 기간 동안 유효합니다. 만료 기간이 길어지면 새 보안 인증 정보를 자주 받을 필요가 없으므로 AWS에 대한 호출 수를 줄이는 데 도움이 될 수 있습니다.

1. 특정 IAM 사용자의 AWS 보안 자격 증명으로 인증합니다. 이 호출에는 반드시 유효한 AWS 보안 자격 증명을 사용해야 합니다.

1. [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) 작업을 직접적으로 호출합니다.

`GetFederationToken` 호출은 세션 토큰, 액세스 키, 보안 키, 만료로 구성된 임시 보안 자격 증명을 반환합니다. 조직 내에서 권한을 관리하고 싶다면 `GetFederationToken`을 사용할 수 있습니다(예: 프록시 애플리케이션을 사용할 권한 할당).

다음 예에서는 `GetFederationToken`을 사용한 샘플 요청 및 응답을 보여줍니다. 이 요청 예제에서는 지정된 기간 동안 호출 사용자를 [세션 정책](access_policies.md#policies_session) ARN 및 [세션 태그](id_session-tags.md)와 연동합니다. 결과 세션의 이름이 `Jane-session`으로 지정됩니다.

**Example 요청 예제**  

```
https://sts.amazonaws.com/
?Version=2011-06-15
&Action=GetFederationToken
&Name=Jane-session
&PolicyArns.member.1.arn==arn%3Aaws%3Aiam%3A%3A123456789012%3Apolicy%2FRole1policy
&DurationSeconds=1800
&Tags.member.1.Key=Project
&Tags.member.1.Value=Pegasus
&Tags.member.2.Key=Cost-Center
&Tags.member.2.Value=12345
&AUTHPARAMS
```

앞의 예시에서 표시된 정책 ARN에는 다음과 같은 URL 인코딩 ARN이 포함되어 있습니다.

`arn:aws:iam::123456789012:policy/Role1policy`

또한 이 예제의 `&AUTHPARAMS` 파라미터는 인증 정보의 자리 표시자로 사용됩니다. 이는 *서명*이며 AWS HTTP API 요청과 함께 포함되어야 합니다. [AWS SDK](https://aws.amazon.com/tools/)를 사용하여 API 요청을 생성하는 것이 좋습니다. 이렇게 하면 SDK가 요청 서명을 대신 처리한다는 장점이 있습니다. API 요청을 수동으로 생성하고 서명해야 하는 경우 요청에 서명하는 방법을 알아보려면 **Amazon Web Services 일반 참조의 [Signature Version 4를 사용하여 AWS 요청에 서명](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html)을 참조하세요.

그 응답에는 임시 보안 자격 증명뿐만 아니라 페더레이션 사용자 및 자격 증명 만료 시간에 대한 Amazon 리소스 이름(ARN)이 포함되어 있습니다.

**Example 응답의 예**  

```
<GetFederationTokenResponse xmlns="https://sts.amazonaws.com/doc/2011-06-15/">
<GetFederationTokenResult>
<Credentials>
  <SessionToken>
   AQoDYXdzEPT//////////wEXAMPLEtc764bNrC9SAPBSM22wDOk4x4HIZ8j4FZTwdQW
   LWsKWHGBuFqwAeMicRXmxfpSPfIeoIYRqTflfKD8YUuwthAx7mSEI/qkPpKPi/kMcGd
   QrmGdeehM4IC1NtBmUpp2wUE8phUZampKsburEDy0KPkyQDYwT7WZ0wq5VSXDvp75YU
   9HFvlRd8Tx6q6fE8YQcHNVXAkiY9q6d+xo0rKwT38xVqr7ZD0u0iPPkUL64lIZbqBAz
   +scqKmlzm8FDrypNC9Yjc8fPOLn9FX9KSYvKTr4rvx3iSIlTJabIQwj2ICCEXAMPLE==
  </SessionToken>
  <SecretAccessKey>
  wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY
  </SecretAccessKey>
  <Expiration>2019-04-15T23:28:33.359Z</Expiration>
  <AccessKeyId>AKIAIOSFODNN7EXAMPLE;</AccessKeyId>
</Credentials>
<FederatedUser>
  <Arn>arn:aws:sts::123456789012:federated-user/Jean</Arn>
  <FederatedUserId>123456789012:Jean</FederatedUserId>
</FederatedUser>
<PackedPolicySize>4</PackedPolicySize>
</GetFederationTokenResult>
<ResponseMetadata>
<RequestId>c6104cbe-af31-11e0-8154-cbc7ccf896c7</RequestId>
</ResponseMetadata>
</GetFederationTokenResponse>
```

**참고**  
AWS 변환은 전달된 세션 정책과 세션 태그를 별도의 제한이 있는 압축된 이진 형식으로 압축합니다. 일반 텍스트가 다른 요구 사항을 충족하는 경우에도 이 제한으로 인해 요청이 실패할 수 있습니다. `PackedPolicySize` 응답 요소는 요청에 대한 정책 및 태그가 상위 크기 제한과 얼마나 가까운지를 백분율로 나타냅니다.

AWS는 리소스 수준에서 권한을 부여할 것을 권장합니다(예: Amazon S3 버킷에 리소스 기반 정책 연결). `Policy` 파라미터는 생략할 수 있습니다. 하지만 AWS STS 페더레이션 사용자 보안 주체에 대한 정책을 포함하지 않으면, 임시 보안 자격 증명은 어떤 권한도 부여하지 않을 것입니다. 이 경우 *반드시* 리소스 정책을 사용해 페더레이션 사용자에게 AWS 리소스에 대한 액세스 권한을 부여해야 합니다.

예를 들어, 내 AWS 계정 번호가 111122223333이고 Susan이 액세스하도록 허용하려는 Amazon S3 버킷을 내가 가지고 있다고 가정해 보겠습니다. Susan의 임시 보안 자격 증명에는 버킷에 대한 정책은 포함되어 있지 않습니다. 이러한 경우 버킷에 Susan의 ARN과 일치하는 ARN과 관련된 정책이 있는지 확인해야 합니다(예: `arn:aws:sts::111122223333:federated-user/Susan`).

## 신뢰할 수 없는 환경의 사용자를 위한 자격 증명 요청
<a name="api_getsessiontoken"></a>

[https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) API 작업은 기존 IAM 사용자에게 일련의 임시 보안 자격 증명을 반환합니다. 예를 들어 MFA가 IAM 사용자에 대해 활성화된 경우에만 AWS 요청을 허용하면 보안을 강화하는 데 유용합니다. 자격 증명은 일시적이므로 덜 안전한 환경을 통해 리소스에 액세스하는 IAM 사용자가 있을 때 보안을 강화하는 역할을 합니다. 덜 안전한 환경의 예시로는 모바일 디바이스 또는 웹 브라우저가 있습니다.

1. 특정 IAM 사용자의 AWS 보안 자격 증명으로 인증합니다. 이 호출에는 반드시 유효한 AWS 보안 자격 증명을 사용해야 합니다.

1. [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html) 작업을 직접적으로 호출합니다.

1. `GetSessionToken`은 세션 토큰, 액세스 키 ID 및 비밀 액세스 키로 구성된 임시 보안 자격 증명을 반환합니다.

기본적으로 IAM 사용자에 대한 임시 보안 자격 증명은 최대 12시간 동안 유효합니다. 그러나 `DurationSeconds` 파라미터를 사용하여 이 기간을 15분만큼 짧게 또는 36시간만큼 길게 요청할 수 있습니다. 보안상의 이유로 AWS 계정 루트 사용자의 토큰은 1시간의 유효 기간으로 제한됩니다.

다음 예제에서는 `GetSessionToken`을 사용한 샘플 요청 및 응답을 보여줍니다. 응답에는 임시 보안 자격 증명의 만료 시간도 포함되어 있습니다.

**Example 요청 예제**  

```
https://sts.amazonaws.com/
?Version=2011-06-15
&Action=GetSessionToken
&DurationSeconds=1800
&AUTHPARAMS
```

예시의 `AUTHPARAMS` 파라미터는 *서명*에 대한 자리 표시자입니다. 서명은 AWS HTTP API 요청에 포함해야 하는 인증 정보입니다. [AWS SDK](https://aws.amazon.com/tools/)를 사용하여 API 요청을 생성하는 것이 좋습니다. 이렇게 하면 SDK가 요청 서명을 대신 처리한다는 장점이 있습니다. API 요청을 수동으로 생성하고 서명해야 하는 경우 요청에 서명하는 방법을 알아보려면 **Amazon Web Services 일반 참조의 [Signature Version 4를 사용하여 AWS 요청에 서명](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html)을 참조하세요.

**Example 응답의 예**  

```
<GetSessionTokenResponse xmlns="https://sts.amazonaws.com/doc/2011-06-15/">
<GetSessionTokenResult>
<Credentials>
  <SessionToken>
   AQoEXAMPLEH4aoAH0gNCAPyJxz4BlCFFxWNE1OPTgk5TthT+FvwqnKwRcOIfrRh3c/L
   To6UDdyJwOOvEVPvLXCrrrUtdnniCEXAMPLE/IvU1dYUg2RVAJBanLiHb4IgRmpRV3z
   rkuWJOgQs8IZZaIv2BXIa2R4OlgkBN9bkUDNCJiBeb/AXlzBBko7b15fjrBs2+cTQtp
   Z3CYWFXG8C5zqx37wnOE49mRl/+OtkIKGO7fAE
  </SessionToken>
  <SecretAccessKey>
  wJalrXUtnFEMI/K7MDENG/bPxRfiCYzEXAMPLEKEY
  </SecretAccessKey>
  <Expiration>2011-07-11T19:55:29.611Z</Expiration>
  <AccessKeyId>AKIAIOSFODNN7EXAMPLE</AccessKeyId>
</Credentials>
</GetSessionTokenResult>
<ResponseMetadata>
<RequestId>58c5dbae-abef-11e0-8cfe-09039844ac7d</RequestId>
</ResponseMetadata>
</GetSessionTokenResponse>
```

선택 사항으로 `GetSessionToken` 요청은 AWS 멀티 팩터 인증(MFA) 확인에 대한 `SerialNumber` 및 `TokenCode` 값을 포함할 수 있습니다. 제공한 값이 유효하면 AWS STS에서는 MFA 인증 상태가 포함된 임시 보안 자격 증명을 제공합니다. 그런 다음 임시 보안 자격 증명은 MFA 인증이 유효한 동안 MFA로 보호되는 API 작업 또는 AWS 웹 사이트에 액세스하는 데 사용할 수 있습니다.

다음 예는 MFA 확인 코드 및 디바이스 일련 번호를 포함하는 `GetSessionToken` 요청을 보여줍니다.

```
https://sts.amazonaws.com/
?Version=2011-06-15
&Action=GetSessionToken
&DurationSeconds=7200
&SerialNumber=YourMFADeviceSerialNumber
&TokenCode=123456
&AUTHPARAMS
```

**참고**  
AWS STS에 대한 호출은 전역 엔드포인트 또는 AWS 계정이 활성화된 리전 엔드포인트 어느 곳으로도 이루어질 수 있습니다. 자세한 내용은 [https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region](https://docs.aws.amazon.com/general/latest/gr/rande.html#sts_region)의 AWS STS 섹션을 참조하세요.  
예시의 `AUTHPARAMS` 파라미터는 *서명*에 대한 자리 표시자입니다. 서명은 AWS HTTP API 요청에 포함해야 하는 인증 정보입니다. [AWS SDK](https://aws.amazon.com/tools/)를 사용하여 API 요청을 생성하는 것이 좋습니다. 이렇게 하면 SDK가 요청 서명을 대신 처리한다는 장점이 있습니다. API 요청을 수동으로 생성하고 서명해야 하는 경우 요청에 서명하는 방법을 알아보려면 **Amazon Web Services 일반 참조의 [Signature Version 4를 사용하여 AWS 요청에 서명](https://docs.aws.amazon.com/general/latest/gr/sigv4_signing.html)을 참조하세요.

# AWS 리소스에서 임시 자격 증명 사용
<a name="id_credentials_temp_use-resources"></a>

임시 보안 자격 증명을 사용해 AWS CLI 또는 AWS API에서 AWS 리소스를 프로그래밍 방식으로 요청할 수 있습니다([AWS SDK](https://aws.amazon.com/tools/) 사용). 임시 보안 자격 증명은 IAM 사용자 자격 증명과 같은 장기 보안 자격 증명을 사용하는 것과 동일한 권한을 제공합니다. 그러나 몇 가지 차이점이 있습니다.
+ 임시 보안 자격 증명을 사용해 호출할 경우 그 호출에 반드시 세션 토큰이 포함되어야 하는데, 이 세션 토큰은 임시 자격 증명과 함께 반환됩니다. AWS는 세션 토큰을 사용해 임시 보안 자격 증명의 유효성을 검증합니다.
+ 임시 자격 증명은 지정된 간격 후에 만료됩니다. 임시 자격 증명이 만료된 후에는 그 자격 증명을 사용한 어떤 요청도 실패할 것이므로 일련의 새로운 임시 자격 증명을 생성해야 합니다. 임시 자격 증명을 원래 지정된 간격 이상으로 확장하거나 새로 고칠 수 없습니다.
+ 임시 자격 증명을 사용하여 요청하면 보안 주체에 태그 세트가 포함될 수 있습니다. 이러한 태그는 세션 태그와 사용자가 맡은 역할에 연결된 태그에서 가져옵니다. 세션 태그에 대한 자세한 내용은 [AWS STS에서 세션 태그 전달](id_session-tags.md) 섹션을 참조하세요.

[AWS SDK](https://aws.amazon.com/tools), [AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/) (AWS CLI) 또는 [Tools for Windows PowerShell](https://aws.amazon.com/powershell)을 사용하는 경우 임시 보안 자격 증명을 가져오고 사용하는 방법은 컨텍스트에 따라 다릅니다. EC2 인스턴스 내부에서 코드, AWS CLI 또는 Tools for Windows PowerShell 명령을 실행 중이라면 Amazon EC2에 대한 역할을 이용할 수 있습니다. 그렇지 않은 경우 [AWS STS API](https://docs.aws.amazon.com/STS/latest/APIReference/)를 호출해 임시 자격 증명을 얻은 다음, 그 자격 증명을 사용해 AWS 서비스를 명시적으로 호출할 수 있습니다.

**참고**  
AWS Security Token Service(AWS STS)를 사용하면 AWS 리소스에 대한 액세스를 제어할 수 있는 임시 보안 자격 증명을 생성하여 신뢰받는 사용자에게 제공할 수 있습니다. AWS STS에 대한 자세한 정보는 [IAM의 임시 보안 자격 증명](id_credentials_temp.md) 섹션을 참조하세요. AWS STS는 `https://sts.amazonaws.com`에 기본 엔드포인트가 있는 전역적 서비스입니다. 이 엔드포인트는 미국 동부(버지니아 북부) 리전에 있지만 이 엔드포인트 및 다른 엔드포인트에서 얻은 자격 증명은 전역적으로 유효합니다. 이러한 자격 증명은 모든 리전의 서비스 및 리소스에서 작동합니다. 지원되는 리전에서 엔드포인트에 대한 AWS STS API 호출을 할 수도 있습니다. 이렇게 지리적으로 더 가까운 리전에 있는 서버에서 요청함으로써 지연 시간을 단축할 수 있습니다. 자격 증명은 어떤 리전에서 오는지 상관없이 전역적으로 유효합니다. 자세한 내용은 [AWS 리전에서 AWS STS 관리](id_credentials_temp_enable-regions.md) 섹션을 참조하세요.

**Contents**
+ [

## Amazon EC2 인스턴스에서 임시 자격 증명 사용
](#using-temp-creds-sdk-ec2-instances)
+ [

## AWS SDK에서 임시 보안 자격 증명 사용
](#using-temp-creds-sdk)
+ [

## AWS CLI에서 임시 보안 자격 증명 사용
](#using-temp-creds-sdk-cli)
+ [

## API 작업을 통해 임시 보안 자격 증명 사용
](#RequestWithSTS)
+ [

## 추가 정보
](#using-temp-creds-more-info)

## Amazon EC2 인스턴스에서 임시 자격 증명 사용
<a name="using-temp-creds-sdk-ec2-instances"></a>

EC2 인스턴스 내에서 AWS CLI 명령 또는 코드를 실행하고자 하는 경우 자격 증명을 얻는 바람직한 방법은 [Amazon EC2에 대한 역할을](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) 사용하는 것입니다. EC2 인스턴스 상에서 실행되는 애플리케이션에 부여하고 싶은 권한을 지정하는 IAM 역할을 생성합니다. 인스턴스를 시작할 때 그 역할을 인스턴스에 연결합니다.

인스턴스 상에서 실행되는 애플리케이션, AWS CLI 및 Tools for Windows PowerShell 명령은 인스턴스 메타데이터로부터 자동 임시 보안 자격 증명을 얻을 수 있습니다. 임시 보안 자격 증명을 명시적으로 가져올 필요는 없습니다. AWS SDK, AWS CLI 및 Tools for Windows PowerShell은 EC2 인스턴스 메타데이터 서비스(IMDS)에서 보안 인증 정보를 자동으로 가져와서 사용합니다. 임시 자격 증명은 그 인스턴스에 연결된 역할에 대해 정의한 권한이 있습니다.

자세한 내용 및 예시는 다음을 참조하세요.
+  [Amazon Elastic Compute Cloud에서 IAM 역할을 사용하여 AWS 리소스에 대한 액세스 권한 부여](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/java-dg-roles.html) - AWS SDK for Java
+  [IAM 역할을 사용하여 액세스 권한 부여](https://docs.aws.amazon.com/sdk-for-net/latest/developer-guide/net-dg-hosm.html) - AWS SDK for .NET 
+  [역할 생성](https://docs.aws.amazon.com/sdk-for-ruby/latest/developer-guide/iam-example-create-role.html) - AWS SDK for Ruby

## AWS SDK에서 임시 보안 자격 증명 사용
<a name="using-temp-creds-sdk"></a>

코드에서 임시 보안 자격 증명을 사용하려면 `AssumeRole`과 같이 AWS STS API를 프로그래밍 방식으로 호출하고 결과 자격 증명 및 세션 토큰을 추출합니다. 그런 다음 해당 값을 AWS에 대한 후속 호출을 위한 자격 증명으로 사용하면 됩니다. 다음 예는 AWS SDK를 사용할 경우 임시 보안 자격 증명을 사용하는 방법에 대한 유사 코드를 보여줍니다.

```
assumeRoleResult = AssumeRole(role-arn);
tempCredentials = new SessionAWSCredentials(
   assumeRoleResult.AccessKeyId, 
   assumeRoleResult.SecretAccessKey, 
   assumeRoleResult.SessionToken);
s3Request = CreateAmazonS3Client(tempCredentials);
```

Python으로 작성된 예제([AWS SDK for Python (Boto)](https://aws.amazon.com/sdk-for-python/) 사용)는 [IAM 역할로 전환(AWS API)](id_roles_use_switch-role-api.md) 섹션을 참조하세요. 이 예제에서는 `AssumeRole`을 호출하여 임시 보안 자격 증명을 가져온 다음 해당 자격 증명을 사용하여 Amazon S3를 호출하는 방법을 보여줍니다.

`AssumeRole`, `GetFederationToken` 및 기타 API 작업을 호출하는 방법에 대한 자세한 내용은 [AWS Security Token Service API 참조](https://docs.aws.amazon.com/STS/latest/APIReference/)를 참조하세요. 이러한 호출의 결과에서 임시 보안 자격 증명 및 세션 토큰을 얻는 방법에 대한 자세한 내용은 사용하고 있는 SDK의 설명서를 참조하세요. 기본 [AWS 설명서 페이지](https://aws.amazon.com/documentation)의 **SDK 및 도구 키트** 섹션에서 모든 AWS SDK에 대한 설명서를 확인할 수 있습니다.

이전 자격 증명이 만료되기 전에 반드시 새로운 일련의 자격 증명을 얻도록 해야 합니다. 일부 SDK에서는 자격 증명 갱신 프로세스를 관리해주는 공급자를 사용할 수 있습니다. 사용하고 있는 SDK의 설명서를 확인하세요.

## AWS CLI에서 임시 보안 자격 증명 사용
<a name="using-temp-creds-sdk-cli"></a>

AWS CLI에서 임시 보안 자격 증명을 사용할 수 있습니다. 이 임시 보안 자격 증명은 정책을 테스트하는 데 유용합니다.

[AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/)를 사용하여 `AssumeRole` 또는 `GetFederationToken`과 같은 [AWS STS API](https://docs.aws.amazon.com/STS/latest/APIReference/)를 호출한 다음 결과 출력을 캡처할 수 있습니다. 다음 예는 파일에 출력을 전송하는 `AssumeRole`에 대한 호출을 보여줍니다. 이 예제에서 `profile` 파라미터는 AWS CLI 구성 파일의 프로파일로 간주됩니다. 또한 역할을 수임할 권한이 있는 IAM 사용자의 자격 증명을 참조하는 것으로 간주됩니다.

```
aws sts assume-role --role-arn arn:aws:iam::123456789012:role/role-name --role-session-name "RoleSession1" --profile IAM-user-name > assume-role-output.txt
```

명령이 끝나면 라우팅한 위치에서 액세스 키 ID, 보안 액세스 키 및 세션 토큰을 추출할 수 있습니다. 수동으로 또는 스크립트를 사용하여 이 작업을 수행할 수 있습니다. 그런 다음 이 값을 환경 변수에 할당할 수 있습니다.

AWS CLI 명령을 실행할 때 AWS CLI는 환경 변수로 시작하여 구성 파일로 넘어가는 특정 순서로 자격 증명을 찾습니다. 따라서 임시 자격 증명을 환경 변수에 넣은 후에 AWS CLI는 그 자격 증명을 기본 값으로 사용합니다. (명령에 `profile` 파라미터를 지정한다면 AWS CLI는 환경 변수를 건너뜁니다. 대신 AWS CLI는 구성 파일을 검색합니다. 이로써 필요한 경우 환경 변수에서 자격 증명을 무시할 수 있게 됩니다.) 

다음 예는 임시 보안 자격 증명에 대한 환경 변수를 설정한 다음, AWS CLI 명령을 호출하는 방법을 보여줍니다. `profile` 파라미터는 AWS CLI 명령에 포함되어 있지 않기 때문에 AWS CLI는 먼저 환경 변수에서 자격 증명을 검색하고, 따라서 임시 자격 증명을 사용합니다.

**Linux**

```
$ export AWS_ACCESS_KEY_ID=ASIAIOSFODNN7EXAMPLE
$ export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
$ export AWS_SESSION_TOKEN=AQoDYXdzEJr...<remainder of session token>
$ aws ec2 describe-instances --region us-west-1
```

**Windows**

```
C:\> SET AWS_ACCESS_KEY_ID=ASIAIOSFODNN7EXAMPLE
C:\> SET AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
C:\> SET AWS_SESSION_TOKEN=AQoDYXdzEJr...<remainder of token> 
C:\> aws ec2 describe-instances --region us-west-1
```

## API 작업을 통해 임시 보안 자격 증명 사용
<a name="RequestWithSTS"></a>

AWS로 직접 HTTPS API 요청을 하는 경우, AWS Security Token Service(AWS STS)에서 가져오는 임시 보안 자격 증명으로 그러한 요청에 서명할 수 있습니다. 이렇게 하려면 AWS STS에서 받은 보안 액세스 키와 액세스 키 ID를 사용합니다. 장기 자격 증명을 사용하는 것과 동일한 방식으로 액세스 키 ID 및 보안 액세스 키를 사용하여 요청에 서명합니다. 또한 AWS STS로부터 받는 세션 토큰을 API 요청에 추가합니다. 그 세션 토큰을 HTTP 헤더 또는 `X-Amz-Security-Token`이라는 쿼리 문자열 파라미터에 추가합니다. 그 세션 토큰을 HTTP 헤더 *또는* 쿼리 문자열 파라미터에 추가하되, 하나에만 추가해야 합니다. HTTPS API 요청 서명에 대한 자세한 내용은 **AWS 일반 참조의 [AWS API 요청에 서명](https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html)을 참조하세요.

## 추가 정보
<a name="using-temp-creds-more-info"></a>

다른 AWS 서비스와 함께 AWS STS를 사용하는 방법에 대한 자세한 내용은 다음 링크를 참조하세요.
+ **Amazon S3**. *Amazon Simple Storage Service 사용 설명서*에서 [IAM 사용자 임시 보안 인증을 사용하여 요청](https://docs.aws.amazon.com/AmazonS3/latest/userguide/AuthUsingTempSessionToken.html) 또는 [페더레이션 사용자 임시 보안 인증을 사용하여 요청](https://docs.aws.amazon.com/AmazonS3/latest/userguide/AuthUsingTempFederationToken.html)을 참조하세요.
+ **Amazon SNS** **Amazon Simple Notification Service 개발자 안내서의 [Amazon SNS로 자격 증명 기반 정책 사용](https://docs.aws.amazon.com/sns/latest/dg/UsingIAMwithSNS.html#UsingTemporarySecurityCredentials_SNS)을 참조하세요.
+ **Amazon SQS**. **Amazon Simple Queue Service 개발자 안내서의 [Amazon SQS의 Identity and Access Management](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/UsingIAM.html#UsingTemporarySecurityCredentials_SQS)를 참조하세요.
+ **Amazon SimpleDB** *Amazon SimpleDB 개발자 안내서*의 [임시 보안 자격 증명 사용](https://docs.aws.amazon.com/AmazonSimpleDB/latest/DeveloperGuide/index.html?UsingTemporarySecurityCredentials_SDB.html)을 참조하세요.

# 임시 보안 자격 증명에 대한 권한
<a name="id_credentials_temp_control-access"></a>

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에 대한 권한
<a name="id_credentials_temp_control-access_assumerole"></a>

수임된 역할에 대한 권한 정책은 `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을 사용한 권한 할당
<a name="permissions-assume-role-example"></a>

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

### 역할 권한 정책
<a name="permissions-assume-role-example-role-access-policy"></a>

이 예에서는 선택 사항인 `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/*"
    }
  ]
}
```

### 파라미터로 전달되는 세션 정책
<a name="permissions-assume-role-example-passed-policy"></a>

사용자에게 이전 예제와 동일한 역할을 수임하도록 허용하려 한다고 가정해 보겠습니다. 하지만 이 경우 역할 세션에 대해 `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/*"
    }
  ]
}
```

### 리소스 기반 정책
<a name="permissions-assume-role-example-resource-based-policy"></a>

일부 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) 섹션을 참조하세요.

# 위임된 역할로 수행한 작업 모니터링 및 제어
<a name="id_credentials_temp_control-access_monitor"></a>

[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)

## 소스 자격 증명을 사용하도록 설정
<a name="id_credentials_temp_control-access_monitor-setup"></a>

소스 자격 증명을 사용하도록 설정하는 방법은 역할을 수임할 때 사용하는 방법에 따라 다릅니다. 예를 들어 IAM 사용자는 `AssumeRole` 작업을 사용하여 역할을 수임할 수 있습니다. 엔터프라이즈 자격 증명(인력 자격 증명이라고도 함)이 있으면 `AssumeRoleWithSAML`을 사용하여 AWS 리소스에 액세스할 수 있습니다. 최종 사용자가 모바일 또는 웹 애플리케이션에 액세스하는 경우 `AssumeRoleWithWebIdentity`를 사용하여 설정할 수 있습니다. 다음은 기존 환경에서 소스 자격 증명 정보를 활용하도록 설정하는 방법을 이해하는 데 도움이 되는 간략한 작업 흐름의 개요입니다.

1. **테스트 사용자 및 역할 구성** - 프로덕션 이전 환경을 사용하여 테스트 사용자 및 역할을 구성하고 소스 자격 증명을 설정할 수 있도록 정책을 구성합니다.

   페더레이션 자격 증명을 위해 자격 증명 공급자(IdP)를 사용하는 경우 어설션 또는 토큰으로 원하는 소스 자격 증명의 사용자 속성을 전달하도록 IdP를 구성합니다.

1. **역할 수임** - 테스트를 위해 설정한 사용자와 역할을 사용하여 역할 수임과 소스 자격 증명 전달을 테스트합니다.

1. **CloudTrail 검토** - CloudTrail 로그에서 테스트 역할의 소스 자격 증명 정보를 검토합니다.

1. **사용자 교육** - 프로덕션 이전 환경에서 테스트한 후에는 필요한 경우 소스 자격 증명 정보를 전달하는 방법을 사용자에게 알려야 합니다. 사용자가 프로덕션 환경에서 소스 자격 증명을 제공해야 하는 시기의 기한을 설정합니다.

1. **프로덕션 정책 구성** - 프로덕션 환경의 정책을 구성한 다음 프로덕션 사용자 및 역할에 추가합니다.

1. **활동 모니터링** - CloudTrail 로그를 사용하여 프로덕션 역할 활동을 모니터링합니다.

## 소스 자격 증명에 대해 알아야 할 사항
<a name="id_credentials_temp_control-access_monitor-know"></a>

소스 자격 증명 사용 시 다음 사항에 유의하세요.
+ 자격 증명 공급자(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` 작업을 호출하고 소스 자격 증명 파라미터를 지정할 수 있습니다.

## 소스 자격 증명 설정에 필요한 권한
<a name="id_credentials_temp_control-access_monitor-perms"></a>

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`가 포함되어 있습니다.

## 역할을 수임할 때 소스 자격 증명 지정
<a name="id_credentials_temp_control-access_monitor-specify-sourceid"></a>

AWS STS `AssumeRole*` API 작업 중 하나를 사용하여 역할의 임시 보안 자격 증명을 가져올 때 소스 자격 증명을 지정할 수 있습니다. 사용하는 API 작업은 사용 사례에 따라 다릅니다. 예를 들어 IAM 역할을 사용하여 IAM 사용자에게 보통은 액세스할 수 없는 AWS 리소스에 대한 액세스 권한을 부여하는 경우 `AssumeRole` 작업을 사용할 수 있습니다. 엔터프라이즈 ID 페더레이션을 사용하여 인력 사용자를 관리하는 경우 `AssumeRoleWithSAML` 작업을 사용할 수 있습니다. OIDC 페더레이션을 사용하여 최종 사용자가 모바일 또는 웹 애플리케이션에 액세스할 수 있도록 허용하는 경우 `AssumeRoleWithWebIdentity` 작업을 사용할 수 있습니다. 다음 섹션에서는 각 작업에 소스 자격 증명을 사용하는 방법을 설명합니다. 임시 자격 증명의 일반적인 시나리오에 대한 자세한 내용은 [임시 자격 증명과 관련된 일반적인 시나리오](id_credentials_temp.md#sts-introduction) 섹션을 참조하세요.

## AssumeRole에 소스 자격 증명 사용
<a name="id_credentials_temp_control-access_monitor-assume-role"></a>

`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에 소스 자격 증명 사용
<a name="id_credentials_temp_control-access_monitor-assume-role-saml"></a>

`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 어설션의 코드 조각 예**  

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/SourceIdentity">
<AttributeValue>DiegoRamirez</AttributeValue>
</Attribute>
```

## AssumeRoleWithWebIdentity에 소스 자격 증명 사용
<a name="id_credentials_temp_control-access_monitor-assume-role-web-id"></a>

`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"
}
```

## 소스 자격 증명 정보를 사용하여 액세스 제어
<a name="id_credentials_temp_control-access_monitor-control-access"></a>

소스 자격 증명이 처음 설정되면 [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"
          ]
        }
      }
    }
  ]
}
```

------

### 역할 체인 및 교차 계정 요구 사항
<a name="id_credentials_temp_control-access_monitor-chain"></a>

`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에서 소스 자격 증명 보기
<a name="id_credentials_temp_control-access_monitor-ct"></a>

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에 대한 권한
<a name="id_credentials_temp_control-access_getfederationtoken"></a>

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을 사용한 권한 할당
<a name="permissions-get-federation-token-example"></a>

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

### IAM 사용자에게 연결된 정책은 다음과 같습니다.
<a name="permissions-get-federation-token-example-iam-user"></a>

이 예시에는 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 페더레이션 사용자에게는 유효한 권한이 없습니다.

### 파라미터로 전달되는 세션 정책
<a name="permissions-get-federation-token-example-passed-policy"></a>

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/*"]
    }
  ]
}
```

### 리소스 기반 정책
<a name="permissions-get-federation-token-resource-based-policy"></a>

일부 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에 대한 권한
<a name="id_credentials_temp_control-access_getsessiontoken"></a>

`GetSessionToken` API 작업 또는 `get-session-token` CLI 명령을 호출해야 하는 기본적인 경우는 사용자가 멀티 팩터 인증(MFA)으로 인증되어야 할 때입니다. MFA로 인증된 사용자가 요청하는 경우에 한해 특정 작업들을 허용하는 정책을 작성하는 것도 가능합니다. MFA 권한 부여 확인을 성공적으로 통과하려면 사용자는 먼저 `GetSessionToken`을 호출하여 선택 사항인 `SerialNumber` 및 `TokenCode` 파라미터를 포함해야 합니다. 사용자가 MFA 디바이스를 통해 인증을 받으면 `GetSessionToken` API 작업에서 반환하는 자격 증명에는 MFA 컨텍스트가 포함됩니다. 이 컨텍스트에서는 사용자가 MFA 디바이스를 통해 인증을 받았고 MFA 인증이 필요한 API 작업에 대한 권한이 있음을 표시합니다.

## GetSessionToken에 필요한 권한
<a name="getsessiontoken-permissions-required"></a>

사용자는 권한이 없어도 세션 토큰을 얻을 수 있습니다. `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에서 부여하는 권한
<a name="getsessiontoken-permissions-granted"></a>

`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) 섹션을 참조하세요.

# 임시 보안 자격 증명에 대한 권한 비활성화
<a name="id_credentials_temp_control-access_disable-perms"></a>

임시 보안 인증 정보는 만료될 때까지 유효합니다. 이러한 보안 인증 정보는 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 역할 세션에 대한 액세스 거부
<a name="deny-access-to-all-sessions"></a>

이 절차는 역할과 연결된 **모든** 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 역할 세션에 대한 액세스 거부
<a name="deny-access-to-specific-session"></a>

모두 거부 정책을 사용하여 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/)을 참조하세요.

## 조건 컨텍스트 키를 사용하여 임시 보안 인증 정보 세션에 대한 액세스 거부
<a name="deny-access-to-specific-session-condition-key"></a>

보안 인증 정보를 생성한 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
<a name="deny-access-condition-key-principalarn"></a>

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
<a name="deny-access-condition-key-sourceidentity"></a>

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",
            "<source identity value>"
          ]
        }
      }
    }
  ]
}
```

------

### aws:userid
<a name="deny-access-condition-key-userid"></a>

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:<caller-specified-role-session-name>`은 수임한 역할 세션의 고유 식별자를 나타냅니다. 수임한 역할 고유 식별자의 호출자 지정 역할 세션 이름 부분에서 StringLike 조건 연산자가 사용되는 경우 역할 세션 이름 또는 와일드카드 문자를 지정할 수 있습니다. 역할 세션 이름을 지정하면 보안 인증 정보를 생성한 역할의 권한에 영향을 미치지 않으면서 명명된 역할 세션을 거부합니다. 역할 세션 이름에 와일드카드 문자를 지정하면 해당 역할과 연결된 모든 세션을 거부합니다.
**참고**  
수임한 역할 세션의 고유 식별자에 속하는 호출자 지정 역할 세션 이름은 역할 체인 중에 변경될 수 있습니다. 역할 체인은 한 역할이 다른 역할을 수임할 때 발생합니다. 보안 주체가 AWS STS `AssumeRole` API 작업을 사용하여 역할을 수임할 때 `RoleSessionName` 요청 파라미터를 사용하여 역할 세션 이름이 설정됩니다.
+ `account-id:<federated-user-caller-specified-name>`은 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:<caller-specified-role-session-name>",
            "123456789012:<federated-user-caller-specified-name>"
          ]
        }
      }
    }
  ]
}
```

------

key values 키 값의 구체적인 예제는 [보안 주체 키 값](reference_policies_variables.md#principaltable) 섹션을 참조하세요. IAM 고유 식별자와 이를 가져오는 방법에 대한 자세한 내용은 [고유 식별자](reference_identifiers.md#identifiers-unique-ids) 섹션을 참조하세요.

## 리소스 기반 정책을 사용하여 특정 보안 주체에 대한 액세스 거부
<a name="deny-access-with-resource-based"></a>

리소스 기반 정책을 사용하여 특정 보안 주체에 대한 액세스를 제한하려면 `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",
          "<source identity value>"
        ]
      }
    }
  }
}
```

------

보안 주체에 대한 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. 작업을 저장합니다.

# 임시 보안 자격 증명을 생성할 수 있는 권한 부여
<a name="id_credentials_temp_control-access_enable-create"></a>

기본적으로 IAM 사용자는 AWS STS 페더레이션 사용자 세션 및 역할을 위한 임시 보안 자격 증명을 생성할 수 있는 권한이 없습니다. 사용자에게 이러한 권한을 제공하려면 정책을 사용해야 합니다. 사용자에게 직접 권한을 부여할 수 있지만, 그룹에게 권한을 부여할 것을 강력히 권고합니다. 그렇게 하면 권한 관리가 훨씬 쉬워집니다. 어떤 사용자가 권한에 연결된 작업을 수행할 필요가 더 이상 없는 경우에는 그룹에서 그 사용자를 삭제하기만 하면 됩니다. 다른 어떤 사용자가 그 작업을 수행해야 한다면 해당 그룹에 추가해 권한을 부여하면 됩니다.

AWS STS 페더레이션 사용자 세션 또는 역할에 대한 임시 보안 자격 증명을 생성할 수 있는 권한을 IAM 그룹에 부여하려면 다음 권한 중 하나 또는 둘 다를 부여하는 정책을 연결하면 됩니다.
+ OIDC 및 SAML 페더레이션 보안 주체가 IAM 역할에 액세스하려면 AWS STS `AssumeRole`에 대한 액세스 권한을 부여합니다.
+ <a name="para_gsy_hxg_1t"></a>역할이 필요하지 않은 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 강화 콘솔 세션을 사용하는 권한 부여
<a name="id_credentials_temp_control-access_sts-setcontext"></a>

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"
        }
    ]
}
```

------

# AWS 리전에서 AWS STS 관리
<a name="id_credentials_temp_enable-regions"></a>

리전 엔드포인트는 AWS 웹 서비스의 특정 리전 내 진입점의 URL입니다. AWS에서는 전역 엔드포인트 대신 리전별 AWS Security Token Service(AWS STS) 엔드포인트를 사용하여 지연 시간을 줄이고, 중복으로 구축하고, 세션 토큰 유효성을 높일 것을 권장합니다. 전역(레거시) AWS STS 엔드포인트(`https://sts.amazonaws.com`)은 가용성이 높지만 단일 AWS 리전인 미국 동부(버지니아 북부)에서 호스팅되며 다른 엔드포인트와 마찬가지로 다른 리전의 엔드포인트로 자동 장애 조치를 제공하지는 않습니다.
+ **지연 시간 감소** - 서비스 및 애플리케이션에서 지리적으로 더 가까운 엔드포인트에 AWS STS 호출을 함으로써 지연 시간 및 응답 시간을 단축하며 AWS STS 서비스에 액세스할 수 있습니다.
+ **중복 구축** - 워크로드 내에서 발생하는 장애의 영향을 예측 가능한 영향 억제 범위를 가진 한정된 수의 구성 요소로 제한할 수 있습니다. 리전별 AWS STS 엔드포인트를 사용하면 구성 요소의 범위를 세션 토큰의 범위에 맞출 수 있습니다. 이 신뢰성 요소에 대한 자세한 내용은 **AWS Well-Architected Framework의 [장애 격리를 사용하여 워크로드 보호](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html)를 참조하세요.
+ **세션 토큰 유효성 증가** - 리전별 AWS STS 엔드포인트의 세션 토큰은 모든 AWS 리전에서 유효합니다. 전역 STS 엔드포인트의 세션 토큰은 기본적으로 STS가 활성화된 AWS 리전에서만 유효합니다. 계정에 대해 새 리전을 활성화하려는 경우 리전별 AWS STS 엔드포인트의 세션 토큰을 사용할 수 있습니다. 전역 엔드포인트를 사용하는 경우 전역 엔드포인트에 대한 AWS STS 세션 토큰의 리전 호환성을 변경해야 합니다. 이를 통해 토큰이 모든 AWS 리전에서 유효합니다.

AWS STS 리전의 목록은 [AWS STS 리전 및 엔드포인트](id_credentials_temp_region-endpoints.md) 섹션을 참조하세요.

**참고**  
AWS에서는 복원력과 성능을 향상시키기 위해 [기본적으로 활성화된](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) 리전에서 AWS Security Token Service(AWS STS) 글로벌 엔드포인트(`https://sts.amazonaws.com`)를 변경했습니다. 글로벌 엔드포인트에 대한 AWS STS 요청은 워크로드와 동일한 AWS 리전에서 자동으로 처리됩니다. 이러한 변경 사항은 옵트인 리전에 배포되지 않습니다. 해당되는 AWS STS 리전 엔드포인트를 사용하는 것이 좋습니다. 자세한 내용은 [AWS STS 글로벌 엔드포인트 변경 사항](id_credentials_temp_region-endpoints.md#reference_sts_global_endpoint_changes) 섹션을 참조하세요.

**Topics**
+ [

## AWS 리전에서 AWS STS 활성화 및 비활성화
](#sts-regions-activate-deactivate)
+ [

## AWS STS 리전 사용을 위한 코드 작성
](#id_credentials_temp_enable-regions_writing_code)
+ [

## 전역 엔드포인트 세션 토큰 관리
](#sts-regions-manage-tokens)

## AWS 리전에서 AWS STS 활성화 및 비활성화
<a name="sts-regions-activate-deactivate"></a>

리전에 대한 AWS STS 엔드포인트를 활성화할 때 AWS STS에서 AWS STS 요청을 수행하는 계정의 사용자 및 역할에 임시 자격 증명을 발급할 수 있습니다. 이러한 자격 증명은 기본적으로 활성화되었거나 수동으로 활성화된 모든 리전에서 사용할 수 있습니다. 기본적으로 활성화된 리전의 경우, 임시 자격 증명이 생성되는 계정에서 리전별 AWS STS 엔드포인트를 활성화해야 합니다. 요청 시 사용자가 동일한 계정으로 로그인하거나 각기 다른 계정으로 로그인하는지 여부는 중요하지 않습니다. 수동으로 활성화된 리전을 사용하여 다른 AWS 계정에서 역할에 대한 임시 자격 증명을 요청하는 경우 대상 계정(역할이 포함된 계정)은 AWS STS 작업을 위해 해당 리전을 활성화해야 합니다. 이렇게 하면 임시 보안 자격 증명을 올바르게 생성할 수 있습니다.

예를 들어, 계정 A의 사용자가 [AWS STS 리전 엔드포인트](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_region-endpoints.html)로 `sts:AssumeRole` API 요청을 보내려 할 수 있습니다. `https://sts.ap-southeast-3.amazonaws.com` 이는 계정 B의 `Developer` 역할에 대한 임시 자격 증명을 요청하기 위한 것입니다. 이 요청은 계정 B의 엔터티에 대한 자격 증명을 만들기 위한 것이기 때문에 계정 B는 `ap-southeast-3` 리전을 활성화해야 합니다. 계정 A(또는 다른 계정)의 사용자는 자신의 계정에서 리전이 활성화되었는지 여부와 상관없이 `ap-southeast-3` AWS STS 엔드포인트를 호출하여 계정 B의 자격 증명을 요청할 수 있습니다. 자세한 내용은 [Enable or disable AWS 리전 in your account](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)를 참조하세요.

**참고**  
활성 리전은 해당 계정의 임시 자격 증명을 이용하는 모두가 이용할 수 있습니다. 어떤 IAM 사용자 또는 역할이 리전에 액세스할 수 있는지 여부를 제어하려면 권한 정책에서 `aws:RequestedRegion` 조건 키를 사용합니다.

**기본적으로 활성화된 리전에서 AWS STS 활성화 또는 비활성화(콘솔)**

1. 루트 사용자 또는 IAM 관리 작업을 수행할 권한이 있는 사용자로 로그인합니다.

1. [IAM 콘솔](https://console.aws.amazon.com/iam/home?#home)을 열고 탐색 창에서 [https://console.aws.amazon.com/iam/home?#account_settings](https://console.aws.amazon.com/iam/home?#account_settings)을 선택합니다.

1. **Security Token Service (STS)**(Security Token Service(STS)) 섹션의 **Endpoints**(엔드포인트)에서 구성하려는 리전을 찾은 다음 **STS status**(STS 상태) 열에서 **Active**(활성) 또는 **Inactive**(비활성)를 선택합니다.

1. 열리는 대화 상자에서 **Activate**(활성화) 또는 **Deactivate**(비활성화)를 선택합니다.

활성화해야 하는 리전의 경우 리전을 활성화하면 AWS STS가 자동으로 활성화됩니다. 리전을 활성화한 후에는 AWS STS가 해당 리전에 대해 항상 활성화되어 있으며 비활성화할 수 없습니다. 기본적으로 비활성화된 리전을 활성화하는 방법에 대해 알아보려면 **AWS Account Management 참조 안내서의 [계정에서 사용할 수 있는 AWS 리전 지정](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)을 참조하세요.

## AWS STS 리전 사용을 위한 코드 작성
<a name="id_credentials_temp_enable-regions_writing_code"></a>

리전을 활성화한 후에 AWS STS API 호출을 그 리전으로 보낼 수 있습니다. 다음 Java 코드 조각은 `AWSSecurityTokenService` 객체를 구성해 유럽(밀라노)(eu-south-1) 리전으로 요청하는 방법을 보여줍니다.

```
EndpointConfiguration regionEndpointConfig = new EndpointConfiguration("https://sts.eu-south-1.amazonaws.com", "eu-south-1");
AWSSecurityTokenService stsRegionalClient = AWSSecurityTokenServiceClientBuilder.standard()
.withCredentials(credentials)
.withEndpointConfiguration(regionEndpointConfig)
.build();
```

AWS STS에서는 리전 엔드포인트에 호출할 것을 권장합니다. 리전을 수동으로 활성화하는 방법에 대해 알아보려면 **AWS Account Management 참조 안내서의 [계정에서 사용할 수 있는 AWS 리전 지정](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)을 참조하세요.

이 예에서 첫 번째 줄은 `regionEndpointConfig`라는 `EndpointConfiguration` 객체를 인스턴스화하여 엔드포인트의 URL과 AWS 리전을 파라미터로 전달합니다.

AWS SDK의 환경 변수를 사용해 AWS STS 리전 엔드포인트를 설정하는 방법은 *AWS SDK 및 도구 참조 가이드*의 [AWS STS 리전화된 엔드포인트](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html)를 참조하세요.

다른 모든 언어 및 프로그래밍 환경의 조합에 대해서는 [해당 SDK 문서](https://aws.amazon.com/tools/)를 참조하세요.

## 전역 엔드포인트 세션 토큰 관리
<a name="sts-regions-manage-tokens"></a>

대부분의 AWS 리전은 기본적으로 모든 AWS 서비스의 작업이 활성화되어 있습니다. 이러한 리전은 AWS STS 사용이 자동으로 활성화됩니다. 아시아 태평양(홍콩)과 같은 일부 리전은 수동으로 활성화해야 합니다. AWS 리전 활성화 및 비활성화에 대한 자세한 내용은 **AWS Account Management 참조 안내서의 [계정에서 사용할 수 있는 AWS 리전 지정](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html)을 참조하세요. 이러한 AWS 리전을 활성화할 때 자동으로 AWS STS 사용이 활성화됩니다. 비활성화된 리전에 대한 AWS STS 엔드포인트를 활성화할 수는 없습니다. 모든 AWS 리전에서 유효한 세션 토큰에는 기본적으로 활성화된 리전에서 유효한 토큰보다 많은 문자가 포함되어 있습니다. 이 설정을 변경하면 토큰을 임시로 저장한 기존 시스템에 영향을 미칠 수 있습니다.

AWS Management Console, AWS CLI 또는 AWS API를 사용하여 이 설정을 변경할 수 있습니다.

**전역 엔드포인트에 대한 세션 토큰의 리전 호환성 변경(콘솔)**

1. 루트 사용자 또는 IAM 관리 작업을 수행할 권한이 있는 사용자로 로그인합니다. 세션 토큰의 호환성을 변경하려면 `iam:SetSecurityTokenServicePreferences` 작업을 허용하는 정책이 있어야 합니다.

1. [IAM 콘솔](https://console.aws.amazon.com/iam/home?#home)을 엽니다. 탐색 창에서 **계정 설정(Account settings)**를 선택합니다.

1. **Security Token Service (STS)**(Security Token Service (STS)) 섹션의 **Session Tokens from the STS endpoints**(STS 엔드포인트의 세션 토큰). **Global endpoint**(글로벌 엔드포인트)는 `Valid only in AWS 리전 enabled by default`를 나타냅니다. **변경**을 선택합니다.

1. **Change region compatibility**(리전 호환성 변경) 대화 상자에서 **All AWS 리전**를 선택합니다. **변경 사항 저장(Save changes)**을 선택합니다.
**참고**  
모든 AWS 리전에서 유효한 세션 토큰에는 기본적으로 활성화된 리전에서 유효한 토큰보다 많은 문자가 포함되어 있습니다. 이 설정을 변경하면 토큰을 임시로 저장한 기존 시스템에 영향을 미칠 수 있습니다.

**전역 엔드포인트에 대한 세션 토큰의 리전 호환성 변경(AWS CLI)**  
세션 토큰 버전을 설정합니다. 버전 1 토큰은 기본적으로 이용 가능한 AWS 리전에서만 유효합니다. 이러한 토큰은 아시아 태평양(홍콩)과 같이 수동으로 활성화된 리전에서 작동하지 않습니다. 버전 2는 모든 리전에서 유효합니다. 하지만 버전 2 토큰에 포함된 문자가 더 많고 일시적으로 토큰을 저장하는 시스템에 영향을 미칠 수 있습니다.
+ [https://docs.aws.amazon.com/cli/latest/reference/iam/set-security-token-service-preferences.html](https://docs.aws.amazon.com/cli/latest/reference/iam/set-security-token-service-preferences.html)

**전역 엔드포인트에 대한 세션 토큰의 리전 호환성 변경(AWS API)**  
세션 토큰 버전을 설정합니다. 버전 1 토큰은 기본적으로 이용 가능한 AWS 리전에서만 유효합니다. 이러한 토큰은 아시아 태평양(홍콩)과 같이 수동으로 활성화된 리전에서 작동하지 않습니다. 버전 2는 모든 리전에서 유효합니다. 하지만 버전 2 토큰에 포함된 문자가 더 많고 일시적으로 토큰을 저장하는 시스템에 영향을 미칠 수 있습니다.
+ [https://docs.aws.amazon.com/IAM/latest/APIReference/API_SetSecurityTokenServicePreferences.html](https://docs.aws.amazon.com/IAM/latest/APIReference/API_SetSecurityTokenServicePreferences.html) 

# AWS STS 리전 및 엔드포인트
<a name="id_credentials_temp_region-endpoints"></a>

**참고**  
AWS에서는 복원력과 성능을 향상시키기 위해 [기본적으로 활성화된](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) 리전에서 AWS Security Token Service(AWS STS) 글로벌 엔드포인트(`https://sts.amazonaws.com`)를 변경했습니다. 글로벌 엔드포인트에 대한 AWS STS 요청은 워크로드와 동일한 AWS 리전에서 자동으로 처리됩니다. 이러한 변경 사항은 옵트인 리전에 배포되지 않습니다. 해당되는 AWS STS 리전 엔드포인트를 사용하는 것이 좋습니다. 자세한 내용은 [AWS STS 글로벌 엔드포인트 변경 사항](#reference_sts_global_endpoint_changes) 섹션을 참조하세요.

다음 표에서는 해당 리전과 그 엔드포인트를 나열합니다. 기본적으로 어떤 것들이 활성화되며, 어떤 것을 활성화 또는 비활성화할 수 있는지를 보여줍니다.

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/id_credentials_temp_region-endpoints.html)

¹리전을 사용하려면 [리전을 활성화](https://docs.aws.amazon.com/general/latest/gr/rande-manage.html)해야 합니다. 그러면 AWS STS가 자동으로 활성화됩니다. 이러한 리전에서는 수동으로 AWS STS를 활성화하거나 비활성화할 수 없습니다.

²중국에서 AWS를 사용하려면 중국 AWS와 관련된 계정 및 보안 인증이 있어야 합니다.

## AWS STS 글로벌 엔드포인트 변경 사항
<a name="reference_sts_global_endpoint_changes"></a>

AWS에서는 복원력과 성능을 향상시키기 위해 [기본적으로 활성화된](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) 리전에서 AWS Security Token Service(AWS STS) 글로벌 엔드포인트(`https://sts.amazonaws.com`)를 변경했습니다. 이전에는 AWS STS 글로벌 엔드포인트에 대한 모든 요청이 단일 AWS 리전인 미국 동부(버지니아 북부)에서 처리되었습니다. 이제 [기본적으로 활성화된](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-regions.html) 리전에서 AWS STS 글로벌 엔드포인트에 대한 요청은 미국 동부(버지니아 북부) 리전이 아닌 요청이 발생한 리전에서 자동으로 처리됩니다. 이러한 변경 사항은 옵트인 리전에 배포되지 않습니다.

이러한 변경 사항에 따라 AWS STS에서는 발생 리전 및 사용된 DNS 해석기를 기반으로 요청을 처리합니다. AWS STS 글로벌 엔드포인트에 대한 DNS 요청이 기본적으로 활성화된 리전의 Amazon DNS 서버에서 처리되는 경우 AWS STS 글로벌 엔드포인트에 대한 요청은 AWS 배포 워크로드와 동일한 리전에서 처리됩니다. 요청이 옵트인 리전에서 발생했거나 요청이 Amazon DNS 서버 이외의 DNS 해석기를 사용하여 해석된 경우 AWS STS 글로벌 엔드포인트에 대한 요청은 미국 동부(버지니아 북부) 리전에서 계속 처리됩니다. Amazon DNS에 자세한 내용은 **Amazon Virtual Private Cloud 사용 설명서의 [Amazon DNS 서버](https://docs.aws.amazon.com/vpc/latest/userguide/AmazonDNS-concepts.html#AmazonDNS)를 참조하세요.

다음 표는 DNS 공급자를 기반으로 AWS STS 글로벌 엔드포인트에 대한 요청이 라우팅되는 방식을 보여줍니다.


| DNS 해석기 | AWS STS 글로벌 엔드포인트에 대한 요청이 로컬 AWS 리전으로 라우팅되는지 여부 | 
| --- | --- | 
|  기본적으로 활성화된 리전의 Amazon VPC에 있는 Amazon DNS 해석기  |  예  | 
|  옵트인 리전의 Amazon VPC에 있는 Amazon DNS 해석기  |  아니요, 요청은 미국 동부(버지니아 북부) 리전으로 라우팅됩니다.  | 
|  ISP, 퍼블릭 DNS 공급자 또는 기타 DNS 공급자가 제공하는 DNS 해석기  |  아니요, 요청은 미국 동부(버지니아 북부) 리전으로 라우팅됩니다.  | 

기존 프로세스의 중단을 최소화하기 위해 AWS에서 다음 조치를 구현했습니다.
+ AWS STS 글로벌 엔드포인트에 대한 요청의 AWS CloudTrail 로그는 미국 동부(버지니아 북부) 리전으로 전송됩니다. AWS STS 리전 엔드포인트에서 처리하는 요청의 CloudTrail 로그는 CloudTrail의 해당 리전에 계속 로깅됩니다.
+ AWS STS 글로벌 엔드포인트 및 리전 엔드포인트에서 수행하는 작업에 대한 CloudTrail 로그에는 요청을 처리한 엔드포인트 및 리전을 나타내는 `endpointType` 및 `awsServingRegion` 필드가 추가로 있습니다. CloudTrail 로그 예제는 [CloudTrail 로그 파일의 글로벌 엔드포인트를 사용한 AWS STS API 이벤트 예제](cloudtrail-integration.md#stscloudtrailexample-assumerole-sts-global-endpoint) 섹션을 참조하세요.
+ AWS STS 글로벌 엔드포인트에 대한 요청의 값은 요청을 처리한 리전과 무관하게 `aws:RequestedRegion` 조건 키에 대해 `us-east-1`입니다.
+ AWS STS 글로벌 엔드포인트에서 처리하는 요청은 리전 AWS STS 엔드포인트와 초당 요청 할당량을 공유하지 않습니다.

옵트인 리전에 워크로드가 있고 AWS STS 글로벌 엔드포인트를 계속 사용하는 경우 복원력과 성능을 개선하기 위해 AWS STS 리전 엔드포인트로 마이그레이션하는 것이 좋습니다. 리전 AWS STS 엔드포인트 구성에 대한 자세한 내용은 **AWS SDK 및 도구 참조 안내서의 [AWS STS 리전 엔드포인트](https://docs.aws.amazon.com/sdkref/latest/guide/feature-sts-regionalized-endpoints.html)를 참조하세요.

## AWS CloudTrail 및 리전 엔드포인트
<a name="sts-regions-cloudtrail"></a>

리전 및 글로벌 엔드포인트에 대한 호출은 AWS CloudTrail의 `tlsDetails` 필드에 로그인됩니다. `us-east-2.amazonaws.com`와(과) 같은 리전 및 엔드포인트에 대한 호출은 CloudTrail에서 해당 지역으로 기록됩니다. 전역적 엔드포인트 `sts.amazonaws.com`에 대한 호출은 글로벌 서비스에 대한 호출로 로깅됩니다. 글로벌 AWS STS 엔드포인트의 이벤트는 us-east-1에 기록됩니다.

**참고**  
 이 필드를 지원하는 서비스에 대해서만 `tlsDetails`을(를) 볼 수 있습니다. *AWS CloudTrail 사용 설명서*의 [CloudTrail에서 TLS 세부 정보를 지원하는 서비스](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-supported-tls-details.html)를 참조하십시오  
자세한 내용은 [AWS CloudTrail을 사용하여 IAM 및 AWS STS API 호출 로깅](cloudtrail-integration.md) 섹션을 참조하세요.

# AWS 콘솔에 대한 사용자 지정 ID 브로커 액세스 활성화
<a name="id_roles_providers_enable-console-custom-url"></a>

코드를 작성하고 실행해 조직 네트워크에 로그인하는 사용자가 AWS Management Console에 안전하게 액세스할 수 있게 하는 URL을 생성할 수 있습니다. URL에는 AWS에서 얻고 AWS에 사용자를 인증하는 로그인 토큰이 포함되어 있습니다. 결과 콘솔 세션에는 페더레이션으로 인해 별도의 `AccessKeyId`이(가) 포함될 수 있습니다. [관련 CloudTrail 이벤트를 통해 페더레이션 로그인을 위한 액세스 키 사용을 추적하려면 [AWS CloudTrail을 사용하여 IAM 및 AWS STS API 호출 로깅](cloudtrail-integration.md) 및 AWS Management Console 로그인 이벤트](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-aws-console-sign-in-events.html)를 참조하세요.

**참고**  
조직에서 SAML과 호환이 되는 자격 증명 공급자(IdP)를 사용한다면, 코드를 작성하지 않고도 콘솔에 대한 액세스를 설정할 수 있습니다. 이는 Microsoft의 Active Directory Federation Services 또는 오픈 소스 Shibboleth와 같은 공급자와 함께 작동합니다. 자세한 내용은 섹션을 참조하세요[SAML 2.0 페더레이션 위탁자의 AWS Management Console 액세스 활성화](id_roles_providers_enable-console-saml.md) 

조직의 사용자가 AWS Management Console에 액세스할 수 있도록 하려는 경우 다음 단계를 수행하여 사용자 지정 *자격 증명 브로커*를 생성할 수 있습니다.

1. 사용자가 로컬 자격 증명 시스템에 의해 인증되는지 확인합니다.

1. AWS Security Token Service(AWS STS) [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)(권장) 또는 [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) API 작업을 호출하여 사용자를 위한 임시 보안 자격 증명을 얻을 수 있습니다. 역할을 수임하는 데 사용할 수 있는 여러 방법을 알아보려면 [역할 수임 방법](id_roles_manage-assume.md) 섹션을 참조하세요. 보안 자격 증명을 획득할 때 선택적 세션 태그를 전달하는 방법은 [AWS STS에서 세션 태그 전달](id_session-tags.md) 섹션을 참조하세요.
   + 역할에 대한 임시 보안 자격 증명을 얻기 위해 `AssumeRole*` API 작업 중 하나를 사용한 경우 이 호출에는 `DurationSeconds` 파라미터를 포함할 수 있습니다. 이 파라미터는 역할 세션 기간을 900초(15초)에서 해당 역할에 대한 최대 세션 기간 설정까지 지정합니다. `AssumeRole*` 작업에서 `DurationSeconds`를 사용하는 경우에는 장기 자격 증명이 있는 IAM 사용자로 호출해야 합니다. 그렇지 않으면 3단계의 연동 엔드포인트 호출에 실패합니다. 역할에 대한 최댓값을 확인 또는 변경하는 방법을 알아보려면 [역할의 최대 세션 기간 업데이트](id_roles_update-role-settings.md#id_roles_update-session-duration) 섹션을 참조하세요.
   + 보안 자격 증명을 얻기 위해 `GetFederationToken` API 작업을 사용한 경우 이 호출에는 `DurationSeconds` 파라미터를 포함할 수 있습니다. 이 파라미터는 역할 세션에 대한 기간을 지정합니다. 이 값은 900초(15분)\$1129,600초(36시간)일 수 있습니다. IAM 사용자의 장기 AWS 보안 자격 증명을 사용하는 경우에만 이 API를 호출할 수 있습니다. AWS 계정 루트 사용자 자격 증명을 사용하여 호출할 수도 있지만 권장되는 방법은 아닙니다. 루트 사용자로 호출한 경우 기본 세션은 한 시간 동안 지속됩니다. 또는 900초(15분)에서 최대 3,600초(1시간)로 세션을 지정할 수 있습니다.

1. AWS 연동 엔드포인트를 호출하고 임시 보안 자격 증명을 제공하여 로그인 토큰을 요청하세요.

1. 토큰을 포함하는 콘솔에 대한 URL을 생성합니다:
   + URL에 `AssumeRole*` API 작업 중 하나를 사용하는 경우 `SessionDuration` HTTP 파라미터를 포함할 수 있습니다. 이 파라미터는 콘솔 세션 시간을 900초(15분)\$143200초(12시간)로 지정합니다.
   + URL에 `GetFederationToken` API 작업을 사용하는 경우 `DurationSeconds` 파라미터를 포함할 수 있습니다. 이 파라미터는 연동된 콘솔 세션에 대한 기간을 지정합니다. 이 값은 900초(15분)\$1129,600초(36시간)일 수 있습니다.
**참고**  
`SessionDuration`은 수임 중인 역할의 최대 세션 기간 설정보다 크거나 같을 수 없습니다. 예를 들어 수임하려는 역할의 최대 세션 기간을 5시간으로 설정합니다. `SessionDuration` 파라미터는 16,524초 또는 4시간 59초일 수 있습니다.
`GetFederationToken`을 사용하여 임시 자격 증명을 가져온 경우 `SessionDuration` HTTP 파라미터를 사용하지 마세요. 작업이 실패합니다.
하나의 역할이 자격 증명을 사용하여 다른 역할을 수임하는 것을 [*역할 체인*](id_roles.md#iam-term-role-chaining)이라고 합니다. 역할 함께 묶기를 사용하는 경우 새 자격 증명의 유효 기간은 최대 1시간으로 제한됩니다. 역할을 사용하여 [EC2 인스턴스에서 실행되는 애플리케이션에 권한을 부여](id_roles_use_switch-role-ec2.md)하는 경우, 이러한 애플리케이션에는 이 제한이 적용되지 않습니다.
역할 체인을 통해 임시 자격 증명을 가져온 경우 `SessionDuration` HTTP 파라미터를 사용하지 마세요. 작업이 실패합니다.

1. 사용자에게 URL을 부여하거나 사용자 대신 URL을 호출합니다.

연동 엔드포인트가 제공하는 URL은 생성된 후 15분 동안 유효합니다. 이 시간은 URL과 연결된 임시 보안 자격 증명 세션의 기간(초)과 다릅니다. 이러한 자격 증명은 생성된 시각을 시작으로 생성 시 지정한 기간 동안 유효합니다.

**중요**  
URL은 연결된 임시 보안 자격 증명에서 권한을 허용한 경우 AWS을 통해 AWS Management Console 리소스에 대한 액세스 권한을 부여한다는 것에 유의하세요. 이러한 이유 때문에 URL은 비밀로 취급해야 합니다. 예를 들어 SSL 연결을 통해 302 HTTP 응답 상태 코드를 사용함으로써 안전한 리디렉션을 통해 URL을 반환하는 것이 좋습니다. 302 HTTP 응답 상태 코드에 대한 자세한 정보는 [RFC 2616, 단원 10.3.3](https://datatracker.ietf.org/doc/html/rfc2616#section-10.3.3)을 참조하세요.

이 작업을 완료하려면 [AWS Identity and Access Management(IAM)를 위한 HTTPS 쿼리 API](https://docs.aws.amazon.com/IAM/latest/APIReference/) 및 [AWS Security Token Service(AWS STS)](https://docs.aws.amazon.com/STS/latest/APIReference/)를 참조하세요. 아니면 적절한 [AWS SDK](https://aws.amazon.com/tools/)와 함께 Java, Ruby 또는 C\$1과 같은 프로그래밍 언어를 사용할 수도 있습니다. 다음 주제에서는 이러한 각 메서드를 설명합니다.

**Topics**
+ [

## IAM 쿼리 API 작업을 사용한 예제 코드
](#STSConsoleLink_manual)
+ [

## Python을 사용한 예제 코드
](#STSConsoleLink_programPython)
+ [

## Java를 사용한 예제 코드
](#STSConsoleLink_programJava)
+ [

## URL을 생성하는 방법을 보여주는 예(Ruby)
](#STSConsoleLink_programRuby)

## IAM 쿼리 API 작업을 사용한 예제 코드
<a name="STSConsoleLink_manual"></a>

역할 및 페더레이션 보안 주체에게 AWS Management Console에 대한 직접 액세스를 부여하는 URL을 생성할 수 있습니다. 이 작업은 IAM 및 AWS STS HTTPS Query API를 사용합니다. 쿼리 요청에 대한 자세한 정보는 [쿼리 요청 실행](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAM_UsingQueryAPI.html) 섹션을 참조하세요.

**참고**  
다음 절차에는 텍스트 문자열에 대한 예시가 있습니다. 가독성을 증진하기 위해 일부 긴 예시에는 줄 바꿈이 추가되었습니다. 자신만이 쓸 용도로 이러한 문자열을 생성할 때는 줄 바꿈을 모두 빼야 합니다.

**AWS Management Console에서 역할 및 페더레이션 보안 주체에게 리소스 액세스 권한 부여**

1. 자격 증명 및 인증 시스템에서 사용자를 인증합니다.

1. 사용자에 대한 임시 보안 자격 증명을 얻습니다. 임시 자격 증명은 액세스 키 ID, 비밀 액세스 키 및 세션 토큰으로 구성됩니다. 임시 자격 증명 생성에 대한 자세한 정보는 다음([IAM의 임시 보안 자격 증명](id_credentials_temp.md))을 참조하세요.

   임시 자격 증명을 얻으려면 AWS STS [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API(권장) 또는 [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) API를 호출하면 됩니다. 이러한 API 작업 간의 차이에 대한 자세한 정보는 AWS 보안 블로그에서 [AWS 계정에 대한 액세스 권한을 안전하게 위임하기 위한 API 옵션 이해하기](https://aws.amazon.com/blogs/security/understanding-the-api-options-for-securely-delegating-access-to-your-aws-account)를 참조하세요.
**중요**  
[GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) API를 사용하여 임시 보안 자격 증명을 생성한 경우 해당 역할을 수임한 사용자에게 자격 증명을 부여하는 권한을 지정해야 합니다. `AssumeRole*`로 시작하는 API 작업 중 어느 것에 대해서도 IAM 역할을 사용해 권한을 할당할 수 있습니다. 다른 API 작업의 경우 그 메커니즘이 API에 따라 달라집니다. 자세한 내용은 [임시 보안 자격 증명에 대한 권한](id_credentials_temp_control-access.md) 섹션을 참조하세요. 또한 `AssumeRole*` API 작업을 사용하는 경우 장기 자격 증명을 사용하여 IAM 사용자로 호출해야 합니다. 그렇지 않으면 3단계의 연동 엔드포인트 호출에 실패합니다.  


1. 임시 보안 자격 증명을 획득한 후에는 자격 증명을 JSON 세션 문자열로 구성해 로그인 토큰과 교환합니다. 다음 예에서는 자격 증명을 인코딩하는 방법을 보여줍니다. 자리 표시자 텍스트를 이전 단계에서 받는 자격 증명의 적절한 값들로 교체합니다.

   ```
   {"sessionId":"*** temporary access key ID ***",
   "sessionKey":"*** temporary secret access key ***",
   "sessionToken":"*** session token ***"}
   ```

1. [URL encode](https://en.wikipedia.org/wiki/Percent-encoding) 이전 단계의 세션 문자열. 인코딩하고 있는 정보가 지닌 중요성으로 인해 이러한 인코딩에는 웹 서비스를 사용하지 않는 것이 좋습니다. 대신 개발 도구 키트에 로컬로 설치된 함수 또는 기능을 사용하여 이 정보를 안전하게 인코딩합니다. Python의 `urllib.quote_plus` 함수, Java의 `URLEncoder.encode` 함수 또는 Ruby의 `CGI.escape` 함수를 사용할 수 있습니다. 이 주제 후반의 예제를 참조하세요.

1. <a name="STSConsoleLink_manual_step5"></a>
**참고**  
AWS에서는 여기에서 POST 요청을 지원합니다.

   AWS 페더레이션 엔드포인트로 요청을 전송하세요.

   `https://region-code.signin.aws.amazon.com/federation` 

   가능한 *region-code* 값 목록은 [AWS 로그인 엔드포인트](https://docs.aws.amazon.com/general/latest/gr/signin-service.html)의 **리전(Region)** 열을 참조하세요. 선택적으로 기본 AWS 로그인 페더레이션 엔드포인트를 사용할 수 있습니다.

   `https://signin.aws.amazon.com/federation` 

   요청에는 `Action` 및 `Session` 파라미터가 포함되어야 하며, [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API 사용했다면 다음 예제의 `SessionDuration` HTTP 파라미터를 선택적으로 포함시킬 수 있습니다.

   ```
   Action = getSigninToken
   SessionDuration = time in seconds
   Session = *** the URL encoded JSON string created in steps 3 & 4 ***
   ```
**참고**  
이 단계의 다음 지침은 GET 요청을 사용하는 경우에만 작동합니다.

   `SessionDuration` HTTP 파라미터는 연동된 콘솔 세션에 대한 기간을 지정합니다. 이 기간은 `DurationSeconds` 파라미터를 사용하여 지정하는 임시 자격 증명의 기간과는 다릅니다. `SessionDuration`의 최댓값은 43200(12시간)까지 지정할 수 있습니다. `SessionDuration` 파라미터가 없을 때는 2단계에서 AWS STS에서 검색한 자격 증명의 지속 시간을 세션의 기본값으로 사용합니다(기본 1시간). `AssumeRole` 파라미터를 사용하여 기간을 지정하는 방법에 대한 자세한 정보는 [`DurationSeconds` API 관련 문서](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)를 참조하세요. 연동 엔드포인트의 `getSigninToken` 작업을 이용하면 한 시간보다 긴 콘솔 세션을 만들 수 있습니다.
**참고**  
`SessionDuration`은 수임 중인 역할의 최대 세션 기간 설정보다 크거나 같을 수 없습니다. 예를 들어 수임하려는 역할의 최대 세션 기간을 5시간으로 설정합니다. `SessionDuration` 파라미터는 16,524초 또는 4시간 59초일 수 있습니다.
`GetFederationToken`을 사용하여 임시 자격 증명을 가져온 경우 `SessionDuration` HTTP 파라미터를 사용하지 마세요. 작업이 실패합니다.
하나의 역할이 자격 증명을 사용하여 다른 역할을 수임하는 것을 [*역할 체인*](id_roles.md#iam-term-role-chaining)이라고 합니다. 역할 함께 묶기를 사용하는 경우 새 자격 증명의 유효 기간은 최대 1시간으로 제한됩니다. 역할을 사용하여 [EC2 인스턴스에서 실행되는 애플리케이션에 권한을 부여](id_roles_use_switch-role-ec2.md)하는 경우, 이러한 애플리케이션에는 이 제한이 적용되지 않습니다.
역할 체인을 통해 임시 자격 증명을 가져온 경우 `SessionDuration` HTTP 파라미터를 사용하지 마세요. 작업이 실패합니다.

   기간이 연장된 콘솔 세션을 활성화하면 자격 증명이 노출될 위험이 높아집니다. 이러한 위험을 줄이려면 IAM 콘솔의 **역할 요약** 페이지에서 **세션 취소(Revoke Sessions)**를 선택하여 원하는 역할의 활성 콘솔 세션을 즉시 비활성화하면 됩니다. 자세한 내용은 [IAM 역할 임시 보안 자격 증명 취소](id_roles_use_revoke-sessions.md) 섹션을 참조하세요.

    다음은 요청에 대한 예시입니다. 가독성을 위해 줄바꿈이 되어 있지만 한 줄로 된 문자열로 제출해야 합니다.

   ```
   https://signin.aws.amazon.com/federation
   ?Action=getSigninToken
   &SessionDuration=1800
   &Session=%7B%22sessionId%22%3A+%22ASIAJUMHIZPTOKTBMK5A%22%2C+%22sessionKey%22
   %3A+%22LSD7LWI%2FL%2FN%2BgYpan5QFz0XUpc8s7HYjRsgcsrsm%22%2C+%22sessionToken%2
   2%3A+%22FQoDYXdzEBQaDLbj3VWv2u50NN%2F3yyLSASwYtWhPnGPMNmzZFfZsL0Qd3vtYHw5A5dW
   AjOsrkdPkghomIe3mJip5%2F0djDBbo7SmO%2FENDEiCdpsQKodTpleKA8xQq0CwFg6a69xdEBQT8
   FipATnLbKoyS4b%2FebhnsTUjZZQWp0wXXqFF7gSm%2FMe2tXe0jzsdP0O12obez9lijPSdF1k2b5
   PfGhiuyAR9aD5%2BubM0pY86fKex1qsytjvyTbZ9nXe6DvxVDcnCOhOGETJ7XFkSFdH0v%2FYR25C
   UAhJ3nXIkIbG7Ucv9cOEpCf%2Fg23ijRgILIBQ%3D%3D%22%7D
   ```

   연동 엔드포인트의 응답은 `SigninToken` 값이 있는 JSON 문서입니다. 다음의 예와 유사합니다.

   ```
   {"SigninToken":"*** the SigninToken string ***"}
   ```

1. 
**참고**  
AWS에서는 여기에서 POST 요청을 지원합니다.

   마지막으로 사용자가 AWS Management Console에 액세스하는 데 사용할 수 있는 URL을 생성합니다. 그 URL은 다음 파라미터와 함께 [Step 5](#STSConsoleLink_manual_step5)에서 사용한 것과 동일한 연동 URL 엔드포인트입니다.

   ```
   ?Action = login
   &Issuer = *** the form-urlencoded URL for your internal sign-in page ***
   &Destination = *** the form-urlencoded URL to the desired AWS console page ***
   &SigninToken = *** the value of SigninToken received in the previous step ***
   ```
**참고**  
이 단계의 다음 지침은 GET API를 사용하는 경우에만 작동합니다.

   다음 예는 최종 URL이 결국 어떤 모양을 갖추게 되는지 보여줍니다. 이 URL은 생성된 시각으로부터 15분 동안 유효합니다. URL에 내장된 콘솔 세션과 임시 보안 자격 증명은 이를 처음 요청할 때 `SessionDuration` HTTP 파라미터에 지정한 지속 기간만큼 유효합니다.

   ```
   https://signin.aws.amazon.com/federation
   ?Action=login
   &Issuer=https%3A%2F%2Fexample.com
   &Destination=https%3A%2F%2Fconsole.aws.amazon.com%2F
   &SigninToken=VCQgs5qZZt3Q6fn8Tr5EXAMPLEmLnwB7JjUc-SHwnUUWabcRdnWsi4DBn-dvC
   CZ85wrD0nmldUcZEXAMPLE-vXYH4Q__mleuF_W2BE5HYexbe9y4Of-kje53SsjNNecATfjIzpW1
   WibbnH6YcYRiBoffZBGExbEXAMPLE5aiKX4THWjQKC6gg6alHu6JFrnOJoK3dtP6I9a6hi6yPgm
   iOkPZMmNGmhsvVxetKzr8mx3pxhHbMEXAMPLETv1pij0rok3IyCR2YVcIjqwfWv32HU2Xlj471u
   3fU6uOfUComeKiqTGX974xzJOZbdmX_t_lLrhEXAMPLEDDIisSnyHGw2xaZZqudm4mo2uTDk9Pv
   9l5K0ZCqIgEXAMPLEcA6tgLPykEWGUyH6BdSC6166n4M4JkXIQgac7_7821YqixsNxZ6rsrpzwf
   nQoS14O7R0eJCCJ684EXAMPLEZRdBNnuLbUYpz2Iw3vIN0tQgOujwnwydPscM9F7foaEK3jwMkg
   Apeb1-6L_OB12MZhuFxx55555EXAMPLEhyETEd4ZulKPdXHkgl6T9ZkIlHz2Uy1RUTUhhUxNtSQ
   nWc5xkbBoEcXqpoSIeK7yhje9Vzhd61AEXAMPLElbWeouACEMG6-Vd3dAgFYd6i5FYoyFrZLWvm
   0LSG7RyYKeYN5VIzUk3YWQpyjP0RiT5KUrsUi-NEXAMPLExMOMdoODBEgKQsk-iu2ozh6r8bxwC
   RNhujg
   ```

## Python을 사용한 예제 코드
<a name="STSConsoleLink_programPython"></a>

다음 예제는 Python을 사용해 사용자에게 AWS Management Console에 대한 직접 액세스 권한을 부여하는 URL을 프로그래밍 방식으로 생성하는 방법을 보여줍니다. 다음과 같은 두 가지 예제가 있습니다.
+ GET 요청을 통해 AWS에 페더레이션
+ POST 요청을 통해 AWS에 페더레이션

두 예제 모두 [AWS SDK for Python (Boto3)](https://aws.amazon.com/tools/)과 [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API를 사용해 임시 보안 자격 증명을 가져옵니다.

역할 체인에서 `AssumeRoleSession` 자격 증명을 가져온 경우 `SessionDuration`을 포함하지 마세요. `SessionDuration`을 포함하면 작업에 실패합니다.

### GET 요청 사용
<a name="post-api-py-example"></a>

```
import urllib, json, sys
import requests # 'pip install requests'
import boto3 # AWS SDK for Python (Boto3) 'pip install boto3'

# Step 1: Authenticate user in your own identity system.

# Step 2: Using the access keys for an IAM user in your AWS 계정,
# call "AssumeRole" to get temporary access keys for the role or federated principal

# Note: Calls to AWS STS AssumeRole must be signed using the access key ID 
# and secret access key of an IAM user or using existing temporary credentials.
# The credentials can be in Amazon EC2 instance metadata, in environment variables, 
# or in a configuration file, and will be discovered automatically by the 
# client('sts') function. For more information, see the Python SDK docs:
# http://boto3.readthedocs.io/en/latest/reference/services/sts.html
# http://boto3.readthedocs.io/en/latest/reference/services/sts.html#STS.Client.assume_role
sts_connection = boto3.client('sts')

assumed_role_object = sts_connection.assume_role(
    RoleArn="arn:aws:iam::account-id:role/ROLE-NAME",
    RoleSessionName="AssumeRoleSession",
)

# Step 3: Format resulting temporary credentials into JSON
url_credentials = {}
url_credentials['sessionId'] = assumed_role_object.get('Credentials').get('AccessKeyId')
url_credentials['sessionKey'] = assumed_role_object.get('Credentials').get('SecretAccessKey')
url_credentials['sessionToken'] = assumed_role_object.get('Credentials').get('SessionToken')
json_string_with_temp_credentials = json.dumps(url_credentials)

# Step 4. Make request to AWS federation endpoint to get sign-in token. Construct the parameter string with
# the sign-in action request, a 12-hour session duration, and the JSON document with temporary credentials 
# as parameters.
request_parameters = "?Action=getSigninToken"
request_parameters += "&SessionDuration=43200"
if sys.version_info[0] < 3:
    def quote_plus_function(s):
        return urllib.quote_plus(s)
else:
    def quote_plus_function(s):
        return urllib.parse.quote_plus(s)
request_parameters += "&Session=" + quote_plus_function(json_string_with_temp_credentials)
request_url = "https://signin.aws.amazon.com/federation" + request_parameters
r = requests.get(request_url)
# Returns a JSON document with a single element named SigninToken.
signin_token = json.loads(r.text)

# Step 5: Create URL where users can use the sign-in token to sign in to 
# the console. This URL must be used within 15 minutes after the
# sign-in token was issued.
request_parameters = "?Action=login" 
request_parameters += "&Issuer=Example.org" 
request_parameters += "&Destination=" + quote_plus_function("https://console.aws.amazon.com/")
request_parameters += "&SigninToken=" + signin_token["SigninToken"]
request_url = "https://signin.aws.amazon.com/federation" + request_parameters

# Send final URL to stdout
print (request_url)
```

### POST 요청 사용
<a name="get-api-py-example-1"></a>

```
import urllib, json, sys
import requests # 'pip install requests'
import boto3 # AWS SDK for Python (Boto3) 'pip install boto3'
import os
from selenium import webdriver # 'pip install selenium', 'brew install chromedriver'

# Step 1: Authenticate user in your own identity system.

# Step 2: Using the access keys for an IAM user in your AAWS 계정,
# call "AssumeRole" to get temporary access keys for the role or federated principal

# Note: Calls to AWS STS AssumeRole must be signed using the access key ID 
# and secret access key of an IAM user or using existing temporary credentials.
# The credentials can be in Amazon EC2 instance metadata, in environment variables, 

# or in a configuration file, and will be discovered automatically by the 
# client('sts') function. For more information, see the Python SDK docs:
# http://boto3.readthedocs.io/en/latest/reference/services/sts.html
# http://boto3.readthedocs.io/en/latest/reference/services/sts.html#STS.Client.assume_role
if sys.version_info[0] < 3:
    def quote_plus_function(s):
        return urllib.quote_plus(s)
else:
    def quote_plus_function(s):
        return urllib.parse.quote_plus(s)

sts_connection = boto3.client('sts')

assumed_role_object = sts_connection.assume_role(
    RoleArn="arn:aws:iam::account-id:role/ROLE-NAME",
    RoleSessionName="AssumeRoleDemoSession",
)

# Step 3: Format resulting temporary credentials into JSON
url_credentials = {}
url_credentials['sessionId'] = assumed_role_object.get('Credentials').get('AccessKeyId')
url_credentials['sessionKey'] = assumed_role_object.get('Credentials').get('SecretAccessKey')
url_credentials['sessionToken'] = assumed_role_object.get('Credentials').get('SessionToken')
json_string_with_temp_credentials = json.dumps(url_credentials)

# Step 4. Make request to AWS federation endpoint to get sign-in token. Construct the parameter string with
# the sign-in action request, a 12-hour session duration, and the JSON document with temporary credentials 
# as parameters.
request_parameters = {}
request_parameters['Action'] = 'getSigninToken'
request_parameters['SessionDuration'] = '43200'
request_parameters['Session'] = json_string_with_temp_credentials

request_url = "https://signin.aws.amazon.com/federation"
r = requests.post( request_url, data=request_parameters)

# Returns a JSON document with a single element named SigninToken.
signin_token = json.loads(r.text)

# Step 5: Create a POST request where users can use the sign-in token to sign in to 
# the console. The POST request must be made within 15 minutes after the
# sign-in token was issued.
request_parameters = {}
request_parameters['Action'] = 'login'
request_parameters['Issuer']='Example.org'
request_parameters['Destination'] = 'https://console.aws.amazon.com/'
request_parameters['SigninToken'] =signin_token['SigninToken']

jsrequest = '''
var form = document.createElement('form');
form.method = 'POST';
form.action = '{request_url}';
request_parameters = {request_parameters}
for (var param in request_parameters) {{
    if (request_parameters.hasOwnProperty(param)) {{
        const hiddenField = document.createElement('input');
        hiddenField.type = 'hidden';
        hiddenField.name = param;
        hiddenField.value = request_parameters[param];
        form.appendChild(hiddenField);
    }}
}}
document.body.appendChild(form);
form.submit();
'''.format(request_url=request_url, request_parameters=request_parameters)

driver = webdriver.Chrome()
driver.execute_script(jsrequest)
input("Press Enter to close the browser window...")
```

## Java를 사용한 예제 코드
<a name="STSConsoleLink_programJava"></a>

다음 예제는 Java를 사용해 사용자에게 AWS Management Console에 대한 직접 액세스 권한을 부여하는 URL을 프로그래밍 방식으로 생성하는 방법을 보여줍니다. 다음 코드 조각은 [AWS SDK for Java](https://aws.amazon.com/documentation/sdkforjava/)를 사용합니다.

```
import java.net.URLEncoder;
import java.net.URL;
import java.net.URLConnection;
import java.io.BufferedReader;
import java.io.InputStreamReader;
// Available at http://www.json.org/java/index.html
import org.json.JSONObject;
import com.amazonaws.auth.AWSCredentials;
import com.amazonaws.auth.BasicAWSCredentials;
import com.amazonaws.services.securitytoken.AWSSecurityTokenServiceClient;
import com.amazonaws.services.securitytoken.model.Credentials;
import com.amazonaws.services.securitytoken.model.GetFederationTokenRequest;
import com.amazonaws.services.securitytoken.model.GetFederationTokenResult;


/* Calls to AWS STS API operations must be signed using the access key ID 
   and secret access key of an IAM user or using existing temporary 
   credentials. The credentials should not be embedded in code. For 
   this example, the code looks for the credentials in a 
   standard configuration file.
*/
AWSCredentials credentials = 
  new PropertiesCredentials(
         AwsConsoleApp.class.getResourceAsStream("AwsCredentials.properties"));

AWSSecurityTokenServiceClient stsClient = 
  new AWSSecurityTokenServiceClient(credentials);

GetFederationTokenRequest getFederationTokenRequest = 
  new GetFederationTokenRequest();
getFederationTokenRequest.setDurationSeconds(1800);
getFederationTokenRequest.setName("UserName");

// A sample policy for accessing Amazon Simple Notification Service (Amazon SNS) in the console.

String policy = "{\"Version\":\"2012-10-17\",		 	 	 \"Statement\":[{\"Action\":\"sns:*\"," +
  "\"Effect\":\"Allow\",\"Resource\":\"*\"}]}";

getFederationTokenRequest.setPolicy(policy);

GetFederationTokenResult federationTokenResult = 
  stsClient.getFederationToken(getFederationTokenRequest);

Credentials federatedCredentials = federationTokenResult.getCredentials();

// The issuer parameter specifies your internal sign-in
// page, for example https://mysignin.internal.mycompany.com/.
// The console parameter specifies the URL to the destination console of the
// AWS Management Console. This example goes to Amazon SNS. 
// The signin parameter is the URL to send the request to.

String issuerURL = "https://mysignin.internal.mycompany.com/";
String consoleURL = "https://console.aws.amazon.com/sns";
String signInURL = "https://signin.aws.amazon.com/federation";
  
// Create the sign-in token using temporary credentials,
// including the access key ID,  secret access key, and session token.
String sessionJson = String.format(
  "{\"%1$s\":\"%2$s\",\"%3$s\":\"%4$s\",\"%5$s\":\"%6$s\"}",
  "sessionId", federatedCredentials.getAccessKeyId(),
  "sessionKey", federatedCredentials.getSecretAccessKey(),
  "sessionToken", federatedCredentials.getSessionToken());
              
// Construct the sign-in request with the request sign-in token action, a
// 12-hour console session duration, and the JSON document with temporary 
// credentials as parameters.

String getSigninTokenURL = signInURL + 
                           "?Action=getSigninToken" +
                           "&DurationSeconds=43200" + 
                           "&SessionType=json&Session=" + 
                           URLEncoder.encode(sessionJson,"UTF-8");

URL url = new URL(getSigninTokenURL);

// Send the request to the AWS federation endpoint to get the sign-in token
URLConnection conn = url.openConnection ();

BufferedReader bufferReader = new BufferedReader(new 
  InputStreamReader(conn.getInputStream()));  
String returnContent = bufferReader.readLine();

String signinToken = new JSONObject(returnContent).getString("SigninToken");

String signinTokenParameter = "&SigninToken=" + URLEncoder.encode(signinToken,"UTF-8");

// The issuer parameter is optional, but recommended. Use it to direct users
// to your sign-in page when their session expires.

String issuerParameter = "&Issuer=" + URLEncoder.encode(issuerURL, "UTF-8");

// Finally, present the completed URL for the AWS console session to the user

String destinationParameter = "&Destination=" + URLEncoder.encode(consoleURL,"UTF-8");
String loginURL = signInURL + "?Action=login" +
                     signinTokenParameter + issuerParameter + destinationParameter;
```

## URL을 생성하는 방법을 보여주는 예(Ruby)
<a name="STSConsoleLink_programRuby"></a>

다음 예제는 Ruby를 사용해 사용자에게 AWS Management Console에 대한 직접 액세스 권한을 부여하는 URL을 프로그래밍 방식으로 생성하는 방법을 보여줍니다. 이 코드 조각은 [AWS SDK for Ruby](https://aws.amazon.com/documentation/sdkforruby/)를 사용합니다.

```
require 'rubygems'
require 'json'
require 'open-uri'
require 'cgi'
require 'aws-sdk'

# Create a new STS instance
# 
# Note: Calls to AWS STS API operations must be signed using an access key ID 
# and secret access key. The credentials can be in EC2 instance metadata 
# or in environment variables and will be automatically discovered by
# the default credentials provider in the AWS Ruby SDK. 
sts = Aws::STS::Client.new()

# The following call creates a temporary session that returns 
# temporary security credentials and a session token.
# The policy grants permissions to work
# in the AWS SNS console.

session = sts.get_federation_token({
  duration_seconds: 1800,
  name: "UserName",
  policy: "{\"Version\":\"2012-10-17\",		 	 	 \"Statement\":{\"Effect\":\"Allow\",\"Action\":\"sns:*\",\"Resource\":\"*\"}}",
})

# The issuer value is the URL where users are directed (such as
# to your internal sign-in page) when their session expires.
#
# The console value specifies the URL to the destination console.
# This example goes to the Amazon SNS console.
#
# The sign-in value is the URL of the AWS STS federation endpoint.
issuer_url = "https://mysignin.internal.mycompany.com/"
console_url = "https://console.aws.amazon.com/sns"
signin_url = "https://signin.aws.amazon.com/federation"

# Create a block of JSON that contains the temporary credentials
# (including the access key ID, secret access key, and session token).
session_json = {
  :sessionId => session.credentials[:access_key_id],
  :sessionKey => session.credentials[:secret_access_key],
  :sessionToken => session.credentials[:session_token]
}.to_json

# Call the federation endpoint, passing the parameters
# created earlier and the session information as a JSON block. 
# The request returns a sign-in token that's valid for 15 minutes.
# Signing in to the console with the token creates a session 
# that is valid for 12 hours.
get_signin_token_url = signin_url + 
                       "?Action=getSigninToken" + 
                       "&SessionType=json&Session=" + 
                       CGI.escape(session_json)

returned_content = URI.parse(get_signin_token_url).read

# Extract the sign-in token from the information returned
# by the federation endpoint.
signin_token = JSON.parse(returned_content)['SigninToken']
signin_token_param = "&SigninToken=" + CGI.escape(signin_token)

# Create the URL to give to the user, which includes the
# sign-in token and the URL of the console to open.
# The "issuer" parameter is optional but recommended.
issuer_param = "&Issuer=" + CGI.escape(issuer_url)
destination_param = "&Destination=" + CGI.escape(console_url)
login_url = signin_url + "?Action=login" + signin_token_param + 
  issuer_param + destination_param
```

# AWS Identity and Access Management 리소스용 태그
<a name="id_tags"></a>

*태그*는 사용자 또는 AWS 리소스에 할당할 수 있는 사용자 지정 속성 레이블입니다. 각 태그에는 다음 두 가지 부분이 있습니다.
+ **태그 키(예: `CostCenter`, `Environment`, `Project` 또는 `Purpose`).
+ **태그 값(예: `111122223333`, `Production` 또는 팀 이름)으로 알려진 선택적 필드. 태그 값을 생략하는 것은 빈 문자열을 사용하는 것과 같습니다.

태그 키와 태그 값을 합해서 키 값 페어라고 합니다. IAM 리소스에 사용할 수 있는 태그 수에 대한 제한은 [IAM 및 AWS STS 할당량](reference_iam-quotas.md) 섹션을 참조하세요.

**참고**  
태그 키 및 태그 키 값의 대소문자 구분에 대한 자세한 내용은 [Case sensitivity](#case-sensitivity)을(를) 참조하세요.

태그를 사용하면 AWS 리소스를 식별하고 구성하는 데 도움이 됩니다. 많은 AWS 서비스가 태그 지정을 지원하므로 다른 서비스의 리소스에 동일한 태그를 할당하여 해당 리소스의 관련 여부를 나타낼 수 있습니다. 예를 들어 Amazon S3 버킷에 할당한 것과 동일한 태그를 IAM 역할에 할당할 수 있습니다. 태깅 전략에 대한 자세한 내용은 [태깅 AWS 리소스](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html) 사용자 안내서를 참조하세요.

태그로 IAM 리소스를 식별, 구성 및 추적하는 것 외에도 IAM 정책의 태그를 사용하여 리소스를 보고 상호 작용할 수 있는 사용자를 제어할 수 있습니다. 태그를 사용하여 액세스를 제어하는 방법에 대한 자세한 내용은 [태그를 사용하여 IAM 사용자 및 역할에 대한 액세스 제어](access_iam-tags.md) 섹션을 참조하세요.

역할을 수임하거나 사용자를 연동할 때 AWS STS에서 태그를 사용하여 사용자 지정 속성을 추가할 수도 있습니다. 자세한 내용은 [AWS STS에서 세션 태그 전달](id_session-tags.md) 섹션을 참조하세요.

**Topics**
+ [

## AWS 태그 이름 지정 규칙 선택
](#id_tags_naming)
+ [

## IAM 및 AWS STS의 태그 지정 규칙
](#id_tags_rules)
+ [

# IAM 사용자 태깅
](id_tags_users.md)
+ [

# IAM 역할 태깅
](id_tags_roles.md)
+ [

# 고객 관리형 정책 태깅
](id_tags_customer-managed-policies.md)
+ [

# OpenID Connect(OIDC) ID 제공업체 태깅
](id_tags_oidc.md)
+ [

# IAM SAML ID 제공업체 태깅
](id_tags_saml.md)
+ [

# Amazon EC2 역할에 대한 인스턴스 프로파일 태깅
](id_tags_instance-profiles.md)
+ [

# 서버 인증서 태깅
](id_tags_server-certificates.md)
+ [

# 가상 MFA 디바이스 태깅
](id_tags_virtual-mfa.md)
+ [

# AWS STS에서 세션 태그 전달
](id_session-tags.md)

## AWS 태그 이름 지정 규칙 선택
<a name="id_tags_naming"></a>

IAM 리소스에 태그 연결을 시작할 때 태그 이름 지정 규칙을 신중하게 선택합니다. 모든 AWS 태그에 동일한 규칙을 적용합니다. 정책에서 태그를 사용하여 AWS 리소스에 대한 액세스를 제어하는 경우 특히 중요합니다. AWS에서 태그를 이미 사용하고 있다면 이름 지정 규칙을 검토하고 적절하게 조정합니다.

**참고**  
계정이 AWS Organizations의 멤버인 경우 AWS Organizations에서의 태그 사용에 대한 자세한 내용은 AWS Organizations 사용 설명서의 [태그 정책](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html)을 참조하세요.

### 태그 이름 지정 모범 사례
<a name="id_tags_naming_best_practices"></a>

다음은 태그에 대한 몇 가지 모범 사례 및 명명 규칙입니다.

태그 이름은 동일하게 사용해야 합니다. 예를 들어 태그 `CostCenter`와 `costcenter`는 서로 다르므로 하나는 재무 분석 및 보고를 위한 비용 할당 태그로 구성되고 다른 하나는 그렇지 않을 수 있습니다. 마찬가지로, `Name` 태그는 많은 리소스에서 AWS 콘솔에 나타나지만 `name` 태그는 그렇지 않습니다. 태그 키 및 태그 키 값의 대소문자 구분에 대한 자세한 내용은 [Case sensitivity](#case-sensitivity)을(를) 참조하세요.

여러 태그가 AWS에서 미리 정의되거나 다양한 AWS 서비스에서 자동으로 생성됩니다. 다수의 AWS 정의 태그 이름은 단어를 구분하는 하이픈과 함께 모두 소문자를 사용하며, 접두사로 태그의 소스 서비스를 식별합니다. 예: 
+ `aws:ec2spot:fleet-request-id`는 인스턴스를 시작한 Amazon EC2 스팟 인스턴스 요청을 식별합니다.
+ `aws:cloudformation:stack-name`은 리소스를 생성한 CloudFormation 스택을 식별합니다.
+ `elasticbeanstalk:environment-name`은 리소스를 생성한 애플리케이션을 식별합니다.

태그 이름은 모두 소문자를 사용하여 지정하는 것이 좋으며, 단어를 구분하는 하이픈과 조직 이름 또는 축약된 이름을 나타내는 접두사를 함께 사용합니다. 예를 들어, 이름이 *AnyCompany*인 가상의 회사에 대해 다음과 같은 태그를 정의할 수 있습니다.
+ 내부 비용 센터 코드를 식별하는 `anycompany:cost-center` 
+ 환경이 개발, 테스트 또는 프로덕션인지 식별하는 `anycompany:environment-type`
+ 리소스가 생성된 애플리케이션을 식별하는 `anycompany:application-id` 

접두사를 사용하면 태그가 AWS 또는 사용 중인 타사 도구가 아닌 조직에서 정의한 것으로 명확하게 식별됩니다. 구분 기호에 하이픈과 함께 모두 소문자를 사용하면 태그 이름을 대문자로 표시하는 방법에 대한 혼동을 피할 수 있습니다. 예를 들어, `anycompany:project-id`는 `ANYCOMPANY:ProjectID`,`anycompany:projectID` 또는`Anycompany:ProjectId`보다 간단하게 기억할 수 있습니다.

## IAM 및 AWS STS의 태그 지정 규칙
<a name="id_tags_rules"></a>

IAM 및 AWS STS에서 태그의 생성과 적용을 관리하는 규칙은 여러 가지가 있습니다.

### 태그 이름 지정
<a name="id_tags_rules_creating"></a>

IAM 리소스, AWS STS assume-role 세션 및 AWS STS 페더레이션 사용자 세션에 대한 태그 이름 지정 규칙을 공식화하는 경우 다음 규칙을 준수합니다.

**문자 요구 사항** - 태그 키 및 값은 문자, 숫자, 공백 및 \$1 . : / = \$1 - @ 기호를 포함할 수 있습니다.

**대소문자 구분** - 태그 키의 대소문자 구분은 태깅된 IAM 리소스의 유형에 따라 다릅니다. IAM 사용자 및 역할의 태그 키 값은 대소문자를 구분하지 않지만 대소문자는 유지됩니다. 즉, 별도의 **Department** 및 **department** 태그 키를 가질 수 없음을 의미합니다. **Department=finance** 태그로 사용자 태그를 지정하고 **department=hr** 태그를 추가하면 첫 번째 태그가 바뀝니다. 두 번째 태그는 추가되지 않습니다.

다른 IAM 리소스 유형의 경우 태그 키 값은 대소문자를 구분합니다. 즉, **Costcenter** 태그 키와 **costcenter** 태그 키를 별도로 지정할 수 있습니다. 예를 들어 고객 관리형 정책에 **Costcenter = 1234** 태그를 지정하고 **costcenter = 5678** 태그를 추가하면 정책에는 **Costcenter** 및 **costcenter** 태그 키가 모두 포함됩니다.

모범 사례로서, 대소문자가 일치하지 않는 유사한 태그를 사용하지 않는 것이 좋습니다. 태그를 대문자로 사용하는 전략을 세우고 이러한 전략을 모든 리소스 유형에 대해 일관되게 구현하는 것이 좋습니다. 태깅 모범 사례에 대한 자세한 내용은 AWS 일반 참조의 [AWS 리소스 태깅](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html)을 참조하세요.

다음 목록은 IAM 리소스에 연결된 태그 키의 대소문자 구분 차이점을 보여줍니다.

태그 키 값이 대소문자를 **구분하지 않습니다** .
+ IAM 역할
+ IAM 사용자

태그 키 값이 대소문자를 구분합니다.
+ 고객 관리형 정책
+ 인스턴스 프로파일
+ OpenID Connect 자격 증명 공급자
+ SAML 자격 증명 공급자
+ 서버 인증서
+ 가상 MFA 디바이스

또한 다음 규칙이 적용됩니다.
+ **aws:**로 시작하는 태그 키 또는 값을 생성할 수 없습니다. 이 태그 접두사는 AWS 내부 전용으로 예약되어 있습니다.
+ **phoneNumber = **와 같이 값이 비어 있는 태그를 만들 수 있습니다. 빈 태그 키는 생성할 수 없습니다.
+ 단일 태그에 여러 값을 지정할 수 없지만 단일 값으로 사용자 지정 다중 값 구조를 생성할 수 있습니다. 예를 들어 사용자 Zhang이 엔지니어링 팀과 QA 팀에서 근무한다고 가정합니다. **team = Engineering** 태그를 연결하고 **team = QA** 태그를 연결한 경우 태그 값을 **Engineering**에서 **QA**로 변경합니다 . 대신 사용자 지정 구분자를 사용하여 단일 태그에 여러 값을 포함할 수 있습니다. 이 예에서는 Zhang에게 **team = Engineering:QA** 태그를 연결할 수 있습니다.
**참고**  
이 예제에서 **team** 태그를 사용하여 엔지니어에 대한 액세스를 제어하려면 **Engineering:QA**를 포함하여 **Engineering**을 포함할 수 있는 모든 구성을 허용하는 정책을 만들어야 합니다. 정책에서의 태그 사용에 대한 자세한 내용은 [태그를 사용하여 IAM 사용자 및 역할에 대한 액세스 제어](access_iam-tags.md) 섹션을 참조하세요.

### 태그 적용 및 편집
<a name="id_tags_rules_applying"></a>

태그를 IAM 리소스에 연결할 때는 다음 규칙을 준수합니다.
+ 대부분의 IAM 리소스에 태그를 지정할 수 있지만 그룹, 수임한 역할, 액세스 보고서 또는 하드웨어 기반 MFA 디바이스에는 태그를 지정할 수 있습니다.
+ Tag Editor를 사용하여 IAM 리소스에 태깅할 수 없습니다. Tag Editor는 IAM 태그를 지원하지 않습니다. Tag Editor를 다른 서비스와 함께 사용하는 방법에 대한 자세한 내용은 *AWS Resource Groups 사용 설명서*에서 [Tag Editor 작업](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/tag-editor.html)을 참조하세요.
+ IAM 리소스를 태깅하려면 특정 권한이 있어야 합니다. 리소스를 태깅하거나 태깅 해제하려면 태그를 나열할 수 있는 권한이 있어야 합니다. 자세한 내용은 이 페이지 끝에 있는 각 IAM 리소스에 대한 주제 목록을 참조하세요.
+ AWS 계정의 IAM 리소스 수와 크기는 제한되어 있습니다. 자세한 내용은 [IAM 및 AWS STS 할당량](reference_iam-quotas.md) 섹션을 참조하세요.
+ 여러 IAM 리소스에 동일한 태그를 적용할 수 있습니다. 예를 들어, 12명의 멤버가 있는 `AWS_Development` 부서가 있다고 가정합니다. 태그 키 **department** 및 값 **awsDevelopment**(**department = awsDevelopment**)를 가진 12명의 사용자와 역할이 있을 수 있습니다. [태그 지정을 지원하는 다른 서비스](reference_aws-services-that-work-with-iam.md)의 리소스에도 동일한 태그를 사용할 수 있습니다.
+ IAM 엔터티(사용자 또는 역할)에는 태그 키가 같은 인스턴스가 여러 개 있을 수 없습니다. 예를 들어 태그 키 값 페어 **costCenter = 1234**가 지정된 사용자가 있는 경우 태그 키 값 페어 **costCenter = 5678**을 연결할 수 있습니다. IAM은 **costCenter** 태그의 값을 **5678**로 업데이트합니다.
+ IAM 엔터티(사용자 또는 역할)에 연결된 태그를 편집하려면 새 값으로 태그를 연결하여 기존 태그를 덮어씁니다. 예를 들어, 태그 키 값 페어 **department = Engineering**을 가진 사용자가 있다고 가정합니다. 사용자를 QA 부서로 이동해야 하는 경우 **department = QA** 태그 키 값 페어를 사용자에게 연결할 수 있습니다. 결과적으로 **department** 태그 키의 **Engineering** 값이 **QA** 값으로 대체됩니다.

# IAM 사용자 태깅
<a name="id_tags_users"></a>

IAM 태그 키 값 페어를 사용하여 IAM 사용자에 사용자 지정 속성을 추가할 수 있습니다. 예를 들어 사용자에게 위치 정보를 추가하려면 태그 키 **location** 및 태그 값 **us\$1wa\$1seattle**을 추가할 수 있습니다. 또는 세 개의 개별 위치 태그 키 값 페어 **loc-country = us**, **loc-state = wa** 및 **loc-city = seattle**을 사용할 수도 있습니다. 태그를 사용하여 리소스에 대한 사용자의 액세스를 제어하거나 사용자에게 연결할 수 있는 태그를 제어할 수 있습니다. 태그를 사용하여 액세스를 제어하는 방법에 대한 자세한 내용은 [태그를 사용하여 IAM 사용자 및 역할에 대한 액세스 제어](access_iam-tags.md) 섹션을 참조하세요.

역할을 수임하거나 사용자를 연동할 때 AWS STS에서 태그를 사용하여 사용자 지정 속성을 추가할 수도 있습니다. 자세한 내용은 [AWS STS에서 세션 태그 전달](id_session-tags.md) 섹션을 참조하세요.

## IAM 사용자 태깅에 필요한 권한
<a name="id_tags_users_permissions"></a>

IAM 사용자가 다른 사용자에 태깅할 수 있도록 권한을 구성해야 합니다. IAM 정책에서 다음 IAM 태그 작업 중 하나 또는 모두를 지정할 수 있습니다.
+ `iam:ListUserTags`
+ `iam:TagUser`
+ `iam:UntagUser`

**IAM 사용자가 특정 사용자의 태그를 추가, 나열 또는 제거하도록 허용하려면**  
태그를 관리해야 하는 IAM 사용자의 권한 정책에 다음 명령문을 추가합니다. 계정 번호를 사용하고 *<username>*을 태그를 관리해야 하는 사용자의 이름으로 바꿉니다. 이 예제 JSON 정책 문서를 사용하여 정책을 생성하는 방법에 대해 자세히 알아보려면 [JSON 편집기를 사용하여 정책 생성](access_policies_create-console.md#access_policies_create-json-editor) 섹션을 참조하세요.

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListUserTags",
        "iam:TagUser",
        "iam:UntagUser"
    ],
    "Resource": "arn:aws:iam::<account-number>:user/<username>"
}
```

**IAM 사용자가 태그를 자체 관리할 수 있게 하려면**  
사용자가 자신의 태그를 관리할 수 있도록 권한 정책에 다음 명령문을 추가합니다. 이 예제 JSON 정책 문서를 사용하여 정책을 생성하는 방법에 대해 자세히 알아보려면 [JSON 편집기를 사용하여 정책 생성](access_policies_create-console.md#access_policies_create-json-editor) 섹션을 참조하세요.

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListUserTags",
        "iam:TagUser",
        "iam:UntagUser"
    ],
    "Resource": "arn:aws:iam::user/${aws:username}"
}
```

**IAM 사용자가 특정 사용자에 태그를 추가하도록 허용하려면**  
특정 사용자에 태그를 추가하기만 하고 제거하지는 않으려면 IAM 사용자의 권한 정책에 다음 명령문을 추가합니다.

**참고**  
`iam:TagUser` 작업을 수행하려면 `iam:ListUserTags` 작업도 포함해야 합니다.

이 정책을 사용하려면 *<username>*을 태그를 관리해야 하는 사용자의 이름으로 바꿉니다. 이 예제 JSON 정책 문서를 사용하여 정책을 생성하는 방법에 대해 자세히 알아보려면 [JSON 편집기를 사용하여 정책 생성](access_policies_create-console.md#access_policies_create-json-editor) 섹션을 참조하세요.

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListUserTags",
        "iam:TagUser"
    ],
    "Resource": "arn:aws:iam::<account-number>:user/<username>"
}
```

또는 [IAMFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/IAMFullAccess) 등의 AWS 관리형 정책을 사용하여 IAM에 모든 액세스 권한을 제공할 수 있습니다.

## IAM 사용자의 태그 관리(콘솔)
<a name="id_tags_users_procs-console"></a>

AWS Management Console에서 IAM 사용자의 태그를 관리할 수 있습니다.

**사용자의 태그를 관리하려면(콘솔)**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 콘솔의 탐색 창에서 [**사용자(Users)**]를 선택한 다음 편집할 사용자의 이름을 선택합니다.

1. **태그** 탭을 선택하고 다음 작업 중 하나를 완료하세요.
   + 사용자에게 아직 태그가 없는 경우 **새 태그 추가**를 선택합니다.
   + 기존 태그 세트를 관리하려면 **태그 관리(Manage tags)**를 선택합니다.

1. 태그를 추가하거나 제거하여 태그 세트를 완성합니다. **변경 사항 저장(Save changes)**을 선택합니다.

## IAM 사용자의 태그 관리(AWS CLI 또는 AWS API)
<a name="id_tags_users_procs-cli-api"></a>

IAM 사용자의 태그를 나열, 연결 또는 제거할 수 있습니다. AWS CLI 또는 AWS API를 사용하여 IAM 사용자의 태그를 관리할 수 있습니다.

**IAM 사용자에 현재 연결된 태그를 나열하려면(AWS CLI 또는 AWS API)**
+ AWS CLI: [aws iam list-user-tags](https://docs.aws.amazon.com/cli/latest/reference/iam/list-user-tags.html)
+ AWS API: [ListUserTags](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListUserTags.html)

**IAM 사용자에 태그를 연결하려면(AWS CLI 또는 AWS API)**
+ AWS CLI: [aws iam tag-user](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-user.html)
+ AWS API: [TagUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagUser.html)

**IAM 사용자의 태그를 제거하려면(AWS CLI 또는 AWS API)**
+ AWS CLI: [aws iam untag-user](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-user.html)
+ AWS API: [UntagUser](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagUser.html)

다른 AWS 서비스의 리소스에 대한 태그 연결 정보는 해당 서비스의 설명서를 참조하세요.

IAM 권한 정책에 태그를 사용하여 보다 세분화된 권한을 설정하는 방법에 대한 자세한 내용은 [IAM 정책 요소: 변수 및 태그](reference_policies_variables.md) 섹션을 참조하세요.

# IAM 역할 태깅
<a name="id_tags_roles"></a>

IAM 태그 키 값 페어를 사용하여 IAM 역할에 사용자 지정 속성을 추가할 수 있습니다. 예를 들어 역할에 위치 정보를 추가하려는 경우 태그 키 **location**과 태그 값 **us\$1wa\$1seattle**을 추가할 수 있습니다. 또는 세 개의 개별 위치 태그 키 값 페어 **loc-country = us**, **loc-state = wa** 및 **loc-city = seattle**을 사용할 수도 있습니다. 태그를 사용하여 리소스에 대한 역할의 액세스를 제어하거나 역할에 연결할 수 있는 태그를 제어할 수 있습니다. 태그를 사용하여 액세스를 제어하는 방법에 대한 자세한 내용은 [태그를 사용하여 IAM 사용자 및 역할에 대한 액세스 제어](access_iam-tags.md) 섹션을 참조하세요.

역할을 수임하거나 사용자를 연동할 때 AWS STS에서 태그를 사용하여 사용자 지정 속성을 추가할 수도 있습니다. 자세한 내용은 [AWS STS에서 세션 태그 전달](id_session-tags.md) 섹션을 참조하세요.

## IAM 역할 태깅에 필요한 권한
<a name="id_tags_roles_permissions"></a>

IAM 역할이 다른 엔터티(사용자 또는 역할)에 태깅할 수 있도록 권한을 구성해야 합니다. IAM 정책에서 다음 IAM 태그 작업 중 하나 또는 모두를 지정할 수 있습니다.
+ `iam:ListRoleTags`
+ `iam:TagRole`
+ `iam:UntagRole`
+ `iam:ListUserTags`
+ `iam:TagUser`
+ `iam:UntagUser`

**IAM 역할이 특정 사용자의 태그를 추가, 나열 또는 제거하도록 허용하려면**  
태그를 관리해야 하는 IAM 역할의 권한 정책에 다음 명령문을 추가합니다. 계정 번호를 사용하고 *<username>*을 태그를 관리해야 하는 사용자의 이름으로 바꿉니다. 이 예제 JSON 정책 문서를 사용하여 정책을 생성하는 방법에 대해 자세히 알아보려면 [JSON 편집기를 사용하여 정책 생성](access_policies_create-console.md#access_policies_create-json-editor) 섹션을 참조하세요.

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListUserTags",
        "iam:TagUser",
        "iam:UntagUser"
    ],
    "Resource": "arn:aws:iam::<account-number>:user/<username>"
}
```

**IAM 역할이 특정 사용자에 태그를 추가하도록 허용하려면**  
특정 사용자에 태그를 추가하기만 하고 제거하지는 않으려면 IAM 역할의 권한 정책에 다음 명령문을 추가합니다.

이 정책을 사용하려면 *<username>*을 태그를 관리해야 하는 사용자의 이름으로 바꿉니다. 이 예제 JSON 정책 문서를 사용하여 정책을 생성하는 방법에 대해 자세히 알아보려면 [JSON 편집기를 사용하여 정책 생성](access_policies_create-console.md#access_policies_create-json-editor) 섹션을 참조하세요.

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListUserTags",
        "iam:TagUser"
    ],
    "Resource": "arn:aws:iam::<account-number>:user/<username>"
}
```

**IAM 역할이 특정 역할의 태그를 추가, 나열 또는 제거하도록 허용하려면**  
태그를 관리해야 하는 IAM 역할의 권한 정책에 다음 명령문을 추가합니다. *<rolename>*을 태그를 관리해야 하는 역할의 이름으로 바꿉니다. 이 예제 JSON 정책 문서를 사용하여 정책을 생성하는 방법에 대해 자세히 알아보려면 [JSON 편집기를 사용하여 정책 생성](access_policies_create-console.md#access_policies_create-json-editor) 섹션을 참조하세요.

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListRoleTags",
        "iam:TagRole",
        "iam:UntagRole"
    ],
    "Resource": "arn:aws:iam::<account-number>:role/<rolename>"
}
```

또는 [IAMFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/IAMFullAccess) 등의 AWS 관리형 정책을 사용하여 IAM에 모든 액세스 권한을 제공할 수 있습니다.

## IAM 역할의 태그 관리(콘솔)
<a name="id_tags_roles_procs-console"></a>

AWS Management Console에서 IAM 역할의 태그를 관리할 수 있습니다.

**역할의 태그를 관리하려면(콘솔)**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 콘솔의 탐색 창에서 [**역할(Roles)**]을 선택한 다음 편집할 역할의 이름을 선택합니다.

1. **태그** 탭을 선택하고 다음 작업 중 하나를 완료하세요.
   + 역할에 아직 태그가 없는 경우 **새 태그 추가(Add new tag)**를 선택합니다.
   + 기존 태그 세트를 관리하려면 **태그 관리(Manage tags)**를 선택합니다.

1. 태그를 추가하거나 제거하여 태그 세트를 완성합니다. 그런 다음 **Save changes**(변경 사항 저장)을 선택합니다.

## IAM 역할의 태그 관리(AWS CLI 또는 AWS API)
<a name="id_tags_roles_procs-cli-api"></a>

IAM 역할의 태그를 나열, 연결 또는 제거할 수 있습니다. AWS CLI 또는 AWS API를 사용하여 IAM 역할의 태그를 관리할 수 있습니다.

**IAM 역할에 현재 연결된 태그를 나열하려면(AWS CLI 또는 AWS API)**
+ AWS CLI: [aws iam list-role-tags](https://docs.aws.amazon.com/cli/latest/reference/iam/list-role-tags.html)
+ AWS API: [ListRoleTags](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListRoleTags.html)

**IAM 역할에 태그를 연결하려면(AWS CLI 또는 AWS API)**
+ AWS CLI: [aws iam tag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-role.html)
+ AWS API: [TagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagRole.html)

**IAM 역할에서 태그를 제거하려면(AWS CLI 또는 AWS API)**
+ AWS CLI: [aws iam untag-role](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-role.html)
+ AWS API: [UntagRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagRole.html)

다른 AWS 서비스의 리소스에 대한 태그 연결 정보는 해당 서비스의 설명서를 참조하세요.

IAM 권한 정책에 태그를 사용하여 보다 세분화된 권한을 설정하는 방법에 대한 자세한 내용은 [IAM 정책 요소: 변수 및 태그](reference_policies_variables.md) 섹션을 참조하세요.

# 고객 관리형 정책 태깅
<a name="id_tags_customer-managed-policies"></a>

IAM 태그 키 값 페어를 사용하여 고객 관리형 정책에 사용자 지정 속성을 추가할 수 있습니다. 예를 들어 부서 정보를 정책에 태깅하려는 경우 태그 키 **Department**와 태그 값 **eng**를 추가할 수 있습니다. 또는 정책에 태깅하여 **Environment = lab**과 같은 특정 환경을 위한 정책을 지정할 수 있습니다. 태그를 사용하여 리소스에 대한 액세스를 제어하거나 리소스에 연결할 수 있는 태그를 제어할 수 있습니다. 태그를 사용하여 액세스를 제어하는 방법에 대한 자세한 내용은 [태그를 사용하여 IAM 사용자 및 역할에 대한 액세스 제어](access_iam-tags.md) 섹션을 참조하세요.

역할을 수임하거나 사용자를 연동할 때 AWS STS에서 태그를 사용하여 사용자 지정 속성을 추가할 수도 있습니다. 자세한 내용은 [AWS STS에서 세션 태그 전달](id_session-tags.md) 섹션을 참조하세요.

## 고객 관리형 정책을 태깅하는 데 필요한 권한
<a name="id_tags_customer-managed-policies_permissions"></a>

IAM 엔터티(사용자 또는 역할)가 고객 관리형 정책을 태깅할 수 있도록 권한을 구성해야 합니다. IAM 정책에서 다음 IAM 태그 작업 중 하나 또는 모두를 지정할 수 있습니다.
+ `iam:ListPolicyTags`
+ `iam:TagPolicy`
+ `iam:UntagPolicy`

**IAM 엔터티(사용자 또는 역할)가 고객 관리형 정책의 태그를 추가, 나열 또는 제거하도록 허용하려면**  
태그를 관리해야 하는 IAM 엔터티의 권한 정책에 다음 명령문을 추가합니다. 계정 번호를 사용하고 *<policyname>*을 태그를 관리해야 하는 정책의 이름으로 바꿉니다. 이 예시 JSON 정책 문서를 사용하여 정책을 생성하는 방법에 대해 자세히 알아보려면 [JSON 편집기를 사용하여 정책 생성](access_policies_create-console.md#access_policies_create-json-editor) 섹션을 참조하세요.

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListPolicyTags",
        "iam:TagPolicy",
        "iam:UntagPolicy"
    ],
    "Resource": "arn:aws:iam::<account-number>:policy/<policyname>"
}
```

**IAM 엔터티(사용자 또는 역할)가 특정 고객 관리형 정책에 태그를 추가하도록 허용하려면**  
특정 정책의 태그를 추가하기만 하고 제거하지는 않으려면 IAM 엔터티의 권한 정책에 다음 명령문을 추가합니다.

**참고**  
`iam:TagPolicy` 작업을 수행하려면 `iam:ListPolicyTags` 작업도 포함해야 합니다.

이 정책을 사용하려면 *<policyname>*을 태그를 관리해야 하는 정책의 이름으로 바꿉니다. 이 예시 JSON 정책 문서를 사용하여 정책을 생성하는 방법에 대해 자세히 알아보려면 [JSON 편집기를 사용하여 정책 생성](access_policies_create-console.md#access_policies_create-json-editor) 섹션을 참조하세요.

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListPolicyTags",
        "iam:TagPolicy"
    ],
    "Resource": "arn:aws:iam::<account-number>:policy/<policyname>"
}
```

또는 [IAMFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/IAMFullAccess) 등의 AWS 관리형 정책을 사용하여 IAM에 모든 액세스 권한을 제공할 수 있습니다.

## IAM 고객 관리형 정책의 태그 관리(콘솔)
<a name="id_tags_customer-managed-policies_procs-console"></a>

AWS Management Console에서 IAM 고객 관리형 정책의 태그를 관리할 수 있습니다.

**고객 관리형 정책의 태그를 관리하려면(콘솔)**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 콘솔의 탐색 창에서 [**정책(Policies)**]을 선택한 다음 편집할 고객 관리형 정책의 이름을 선택합니다.

1. **태그** 탭을 선택한 후 **태그 관리**를 선택합니다.

1. 태그를 추가하거나 제거하여 태그 세트를 완성합니다. **변경 사항 저장(Save changes)**을 선택합니다.

## IAM 고객 관리형 정책의 태그 관리(AWS CLI 또는 AWS API)
<a name="id_tags_customer-managed-policies_procs-cli-api"></a>

IAM 고객 관리형 정책의 태그를 나열, 연결 또는 제거할 수 있습니다. AWS CLI 또는 AWS API를 사용하여 IAM 고객 관리형 정책의 태그를 관리할 수 있습니다.

**IAM 고객 관리형 정책에 현재 연결된 태그를 나열하려면(AWS CLI 또는 AWS API)**
+ AWS CLI: [aws iam list-policy-tags](https://docs.aws.amazon.com/cli/latest/reference/iam/list-policy-tags.html)
+ AWS API: [ListPolicyTags](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListPolicyTags.html)

**IAM 고객 관리형 정책에 태그를 연결하려면(AWS CLI 또는 AWS API)**
+ AWS CLI: [aws iam tag-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-policy.html)
+ AWS API: [TagPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagPolicy.html)

**IAM 고객 관리형 정책에서 태그를 제거하려면(AWS CLI 또는 AWS API)**
+ AWS CLI: [aws iam untag-policy](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-policy.html)
+ AWS API: [UntagPolicy](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagPolicy.html)

다른 AWS 서비스의 리소스에 대한 태그 연결 정보는 해당 서비스의 설명서를 참조하세요.

IAM 권한 정책에 태그를 사용하여 보다 세분화된 권한을 설정하는 방법에 대한 자세한 내용은 [IAM 정책 요소: 변수 및 태그](reference_policies_variables.md) 섹션을 참조하세요.

# OpenID Connect(OIDC) ID 제공업체 태깅
<a name="id_tags_oidc"></a>

IAM 태그 키 값을 사용하여 IAM OpenID Connect(OIDC) 자격 증명 공급자에 사용자 지정 속성을 추가할 수 있습니다. 예를 들어 OIDC 자격 증명 공급자를 식별하기 위해 태그 키 **google**과 태그 값 **oidc**를 추가할 수 있습니다. 태그를 사용하여 리소스에 대한 액세스를 제어하거나 객체에 연결할 수 있는 태그를 제어할 수 있습니다. 태그를 사용하여 액세스를 제어하는 방법에 대한 자세한 내용은 [태그를 사용하여 IAM 사용자 및 역할에 대한 액세스 제어](access_iam-tags.md) 섹션을 참조하세요.

## IAM OIDC 자격 증명 공급자를 태깅하는 데 필요한 권한
<a name="id_tags_oidc_permissions"></a>

IAM 엔터티(사용자 또는 역할)가 IAM OIDC 자격 증명 공급자를 태깅할 수 있도록 권한을 구성해야 합니다. IAM 정책에서 다음 IAM 태그 작업 중 하나 또는 모두를 지정할 수 있습니다.
+ `iam:ListOpenIDConnectProviderTags`
+ `iam:TagOpenIDConnectProvider`
+ `iam:UntagOpenIDConnectProvider`

**IAM 엔터티가 IAM OIDC ID 제공업체의 태그를 추가, 나열 또는 제거하도록 허용하려면**  
태그를 관리해야 하는 IAM 엔터티의 권한 정책에 다음 명령문을 추가합니다. 계정 번호를 사용하고 *<OIDCProviderName>*를 태그를 관리해야 하는 OIDC 공급자의 이름으로 바꿉니다. 이 예제 JSON 정책 문서를 사용하여 정책을 생성하는 방법에 대해 자세히 알아보려면 [JSON 편집기를 사용하여 정책 생성](access_policies_create-console.md#access_policies_create-json-editor) 섹션을 참조하세요.

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListOpenIDConnectProviderTags",
        "iam:TagOpenIDConnectProvider",
        "iam:UntagOpenIDConnectProvider"
    ],
    "Resource": "arn:aws:iam::<account-number>:oidc-provider/<OIDCProviderName>"
}
```

**IAM 엔터티(사용자 또는 역할)가 특정 IAM OIDC 자격 증명 공급자에 태그를 추가하도록 허용하려면**  
특정 자격 증명 공급자의 태그를 추가하기만 하고 제거하지는 않으려면 IAM 엔터티의 권한 정책에 다음 명령문을 추가합니다.

**참고**  
`iam:TagOpenIDConnectProvider` 작업을 수행하려면 `iam:ListOpenIDConnectProviderTags` 작업도 포함해야 합니다.

이 정책을 사용하려면 *<OIDCProviderName>*을 태그를 관리해야 하는 OIDC 공급자의 이름으로 바꿉니다. 이 예제 JSON 정책 문서를 사용하여 정책을 생성하는 방법에 대해 자세히 알아보려면 [JSON 편집기를 사용하여 정책 생성](access_policies_create-console.md#access_policies_create-json-editor) 섹션을 참조하세요.

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListOpenIDConnectProviderTags",
        "iam:TagOpenIDConnectProvider"
    ],
    "Resource": "arn:aws:iam::<account-number>:oidc-provider/<OIDCProviderName>"
}
```

또는 [IAMFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/IAMFullAccess) 등의 AWS 관리형 정책을 사용하여 IAM에 모든 액세스 권한을 제공할 수 있습니다.

## IAM OIDC 자격 증명 공급자의 태그 관리(콘솔)
<a name="id_tags_oidc_procs-console"></a>

AWS Management Console에서 IAM OIDC 자격 증명 공급자의 태그를 관리할 수 있습니다.

**OIDC 자격 증명 공급자의 태그를 관리하려면(콘솔)**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 콘솔의 탐색 창에서 [**자격 증명 공급자(Identity providers)**]를 선택한 다음 편집할 자격 증명 공급자의 이름을 선택합니다.

1. **태그** 탭을 선택한 다음 **태그** 섹션에서 **태그 관리**를 선택하고 다음 작업 중 하나를 완료합니다.
   + OIDC 자격 증명 공급자에 아직 태그가 없거나 새 태그를 추가하려면 [**태그 추가(Add tag)**]를 선택합니다.
   + 기존 태그 키 및 값을 편집합니다.
   + 태그를 제거하려면 [**태그 제거(Remove tag)**]를 선택합니다.

1. **변경 사항 저장(Save changes)**을 선택합니다.

## IAM OIDC 자격 증명 공급자의 태그 관리(AWS CLI 또는 AWS API)
<a name="id_tags_oidc_procs-cli-api"></a>

IAM OIDC 자격 증명 공급자의 태그를 나열, 연결 또는 제거할 수 있습니다. AWS CLI 또는 AWS API를 사용하여 IAM OIDC 자격 증명 공급자의 태그를 관리할 수 있습니다.

**IAM OIDC 자격 증명 공급자에 현재 연결된 태그를 나열하려면(AWS CLI 또는 AWS API)**
+ AWS CLI: [aws iam list-open-id-connect-provider-tags](https://docs.aws.amazon.com/cli/latest/reference/iam/list-open-id-connect-provider-tags.html)
+ AWS API: [ListOpenIDConnectProviderTags](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListOpenIDConnectProviderTags.html)

**IAM OIDC 자격 증명 공급자에 태그를 연결하려면(AWS CLI 또는 AWS API)**
+ AWS CLI: [aws iam tag-open-id-connect-provider](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-open-id-connect-provider.html)
+ AWS API: [TagOpenIDConnectProvider](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagOpenIDConnectProvider.html)

**IAM OIDC 자격 증명 공급자에서 태그를 제거하려면(AWS CLI 또는 AWS API)**
+ AWS CLI: [aws iam untag-open-id-connect-provider](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-open-id-connect-provider.html)
+ AWS API: [UntagOpenIDConnectProvider](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagOpenIDConnectProvider.html)

다른 AWS 서비스의 리소스에 대한 태그 연결 정보는 해당 서비스의 설명서를 참조하세요.

IAM 권한 정책에 태그를 사용하여 보다 세분화된 권한을 설정하는 방법에 대한 자세한 내용은 [IAM 정책 요소: 변수 및 태그](reference_policies_variables.md) 섹션을 참조하세요.

# IAM SAML ID 제공업체 태깅
<a name="id_tags_saml"></a>

IAM 태그 키 값 페어를 사용하여 SAML 자격 증명 공급자에 사용자 지정 속성을 추가할 수 있습니다. 예를 들어 공급자를 식별하기 위해 태그 키 **okta**와 태그 값 **saml**을 추가할 수 있습니다. 태그를 사용하여 리소스에 대한 액세스를 제어하거나 객체에 연결할 수 있는 태그를 제어할 수 있습니다. 태그를 사용하여 액세스를 제어하는 방법에 대한 자세한 내용은 [태그를 사용하여 IAM 사용자 및 역할에 대한 액세스 제어](access_iam-tags.md) 섹션을 참조하세요.

## SAML 자격 증명 공급자를 태깅하는 데 필요한 권한
<a name="id_tags_saml_permissions"></a>

IAM 엔터티(사용자 또는 역할)가 SAML 2.0 기반 자격 증명 공급자(IdP)를 태깅할 수 있도록 권한을 구성해야 합니다. IAM 정책에서 다음 IAM 태그 작업 중 하나 또는 모두를 지정할 수 있습니다.
+ `iam:ListSAMLProviderTags`
+ `iam:TagSAMLProvider`
+ `iam:UntagSAMLProvider`

**IAM 엔터티(사용자 또는 역할)가 SAML 자격 증명 공급자의 태그를 추가, 나열 또는 제거하도록 허용하려면**  
태그를 관리해야 하는 IAM 엔터티의 권한 정책에 다음 명령문을 추가합니다. 계정 번호를 사용하고 *<SAMLProviderName>*를 태그를 관리해야 하는 SAML 공급자의 이름으로 바꿉니다. 이 예제 JSON 정책 문서를 사용하여 정책을 생성하는 방법에 대해 자세히 알아보려면 [JSON 편집기를 사용하여 정책 생성](access_policies_create-console.md#access_policies_create-json-editor) 섹션을 참조하세요.

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListSAMLProviderTags",
        "iam:TagSAMLProvider",
        "iam:UntagSAMLProvider"
    ],
    "Resource": "arn:aws:iam::<account-number>:saml-provider/<SAMLProviderName>"
}
```

**IAM 엔터티(사용자 또는 역할)가 특정 SAML 자격 증명 공급자에 태그를 추가하도록 허용하려면**  
특정 SAML 공급자의 태그를 추가하기만 하고 제거하지는 않으려면 IAM 엔터티의 권한 정책에 다음 명령문을 추가합니다.

**참고**  
`iam:TagSAMLProvider` 작업을 수행하려면 `iam:ListSAMLProviderTags` 작업도 포함해야 합니다.

이 정책을 사용하려면 *<SAMLProviderName>*을 태그를 관리해야 하는 SAML 공급자의 이름으로 바꿉니다. 이 예제 JSON 정책 문서를 사용하여 정책을 생성하는 방법에 대해 자세히 알아보려면 [JSON 편집기를 사용하여 정책 생성](access_policies_create-console.md#access_policies_create-json-editor) 섹션을 참조하세요.

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListSAMLProviderTags",
        "iam:TagSAMLProvider"
    ],
    "Resource": "arn:aws:iam::<account-number>:saml-provider/<SAMLProviderName>"
}
```

또는 [IAMFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/IAMFullAccess) 등의 AWS 관리형 정책을 사용하여 IAM에 모든 액세스 권한을 제공할 수 있습니다.

## IAM SAML 자격 증명 공급자의 태그 관리(콘솔)
<a name="id_tags_saml_procs-console"></a>

AWS Management Console에서 IAM SAML 자격 증명 공급자의 태그를 관리할 수 있습니다.

**SAML 자격 증명 공급자의 태그를 관리하려면(콘솔)**

1. AWS Management Console에 로그인하여 [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)에서 IAM 콘솔을 엽니다.

1. 콘솔의 탐색 창에서 [**자격 증명 공급자(Identity providers)**]를 선택한 다음 편집할 SAML 자격 증명 공급자의 이름을 선택합니다.

1. **태그** 탭을 선택한 다음 **태그** 섹션에서 **태그 관리**를 선택하고 다음 작업 중 하나를 완료합니다.
   + SAML 자격 증명 공급자에 아직 태그가 없거나 새 태그를 추가하려면 [**태그 추가(Add tag)**]를 선택합니다.
   + 기존 태그 키 및 값을 편집합니다.
   + 태그를 제거하려면 [**태그 제거(Remove tag)**]를 선택합니다.

1. 태그를 추가하거나 제거하여 태그 세트를 완성합니다. **변경 사항 저장(Save changes)**을 선택합니다.

## IAM SAML 자격 증명 공급자의 태그 관리(AWS CLI 또는 AWS API)
<a name="id_tags_saml_procs-cli-api"></a>

IAM SAML 자격 증명 공급자의 태그를 나열, 연결 또는 제거할 수 있습니다. AWS CLI 또는 AWS API를 사용하여 IAM SAML 자격 증명 공급자의 태그를 관리할 수 있습니다.

**SAML 자격 증명 공급자에 현재 연결된 태그를 나열하려면(AWS CLI 또는 AWS API)**
+ AWS CLI: [aws iam list-saml-provider-tags](https://docs.aws.amazon.com/cli/latest/reference/iam/list-saml-provider-tags.html)
+ AWS API: [ListSAMLProviderTags](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListSAMLProviderTags.html)

**SAML 자격 증명 공급자에 태그를 연결하려면(AWS CLI 또는 AWS API)**
+ AWS CLI: [aws iam tag-saml-provider](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-saml-provider.html)
+ AWS API: [TagSAMLProvider](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagSAMLProvider.html)

**SAML 자격 증명 공급자에서 태그를 제거하려면(AWS CLI 또는 AWS API)**
+ AWS CLI: [aws iam untag-saml-provider](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-saml-provider.html)
+ AWS API: [UntagSAMLProvider](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagSAMLProvider.html)

다른 AWS 서비스의 리소스에 대한 태그 연결 정보는 해당 서비스의 설명서를 참조하세요.

IAM 권한 정책에 태그를 사용하여 보다 세분화된 권한을 설정하는 방법에 대한 자세한 내용은 [IAM 정책 요소: 변수 및 태그](reference_policies_variables.md) 섹션을 참조하세요.

# Amazon EC2 역할에 대한 인스턴스 프로파일 태깅
<a name="id_tags_instance-profiles"></a>

Amazon EC2 인스턴스를 시작할 때 인스턴스와 연결할 IAM 역할을 지정합니다. 인스턴스 프로파일이란 IAM 역할을 위한 컨테이너로서 인스턴스 시작 시 Amazon EC2 인스턴스에 역할 정보를 전달하는 데 사용됩니다. AWS CLI 또는 AWS API를 사용할 경우 인스턴스 프로파일을 태깅할 수 있습니다.

IAM 태그 키 값 페어를 사용하여 인스턴스 프로파일에 사용자 지정 속성을 추가할 수 있습니다. 예를 들어 인스턴스 프로파일에 부서 정보를 추가하려면 태그 키 **access-team**과 태그 값 **eng**를 추가할 수 있습니다. 이렇게 하면 일치하는 태그가 있는 보안 주체가 동일한 태그를 가진 인스턴스 프로파일에 액세스할 수 있습니다. **access-team = eng ** 및 **project = peg**와 같이 여러 태그 키 값 페어를 사용하여 팀과 프로젝트를 지정할 수 있습니다. 태그를 사용하여 리소스에 대한 사용자의 액세스를 제어하거나 사용자에게 연결할 수 있는 태그를 제어할 수 있습니다. 태그를 사용하여 액세스를 제어하는 방법에 대한 자세한 내용은 [태그를 사용하여 IAM 사용자 및 역할에 대한 액세스 제어](access_iam-tags.md) 섹션을 참조하세요.

역할을 수임하거나 사용자를 연동할 때 AWS STS에서 태그를 사용하여 사용자 지정 속성을 추가할 수도 있습니다. 자세한 내용은 [AWS STS에서 세션 태그 전달](id_session-tags.md) 섹션을 참조하세요.

## 인스턴스 프로파일을 태깅하는 데 필요한 권한
<a name="id_tags_instance-profiles_permissions"></a>

IAM 엔터티(사용자 또는 역할)가 인스턴스 프로파일을 태깅할 수 있도록 권한을 구성해야 합니다. IAM 정책에서 다음 IAM 태그 작업 중 하나 또는 모두를 지정할 수 있습니다.
+ `iam:ListInstanceProfileTags`
+ `iam:TagInstanceProfile`
+ `iam:UntagInstanceProfile`

**IAM 엔터티(사용자 또는 역할)가 인스턴스 프로파일의 태그를 추가, 나열 또는 제거하도록 허용하려면**  
태그를 관리해야 하는 IAM 엔터티의 권한 정책에 다음 명령문을 추가합니다. 계정 번호를 사용하고 *<InstanceProfileName>*을 태그를 관리해야 하는 인스턴스 프로파일의 이름으로 바꿉니다. 이 예제 JSON 정책 문서를 사용하여 정책을 생성하는 방법에 대해 자세히 알아보려면 [JSON 편집기를 사용하여 정책 생성](access_policies_create-console.md#access_policies_create-json-editor) 섹션을 참조하세요.

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListInstanceProfileTags",
        "iam:TagInstanceProfile",
        "iam:UntagInstanceProfile"
    ],
    "Resource": "arn:aws:iam::<account-number>:instance-profile/<InstanceProfileName>"
}
```

**IAM 엔터티(사용자 또는 역할)가 특정 인스턴스 프로파일에 태그를 추가하도록 허용하려면**  
특정 인스턴스 프로파일의 태그를 추가하기만 하고 제거하지는 않으려면 IAM 엔터티의 권한 정책에 다음 명령문을 추가합니다.

**참고**  
`iam:TagInstanceProfile` 작업을 수행하려면 `iam:ListInstanceProfileTags` 작업도 포함해야 합니다.

이 정책을 사용하려면 *<InstanceProfileName>*을 태그를 관리해야 하는 인스턴스 프로파일의 이름으로 바꿉니다. 이 예제 JSON 정책 문서를 사용하여 정책을 생성하는 방법에 대해 자세히 알아보려면 [JSON 편집기를 사용하여 정책 생성](access_policies_create-console.md#access_policies_create-json-editor) 섹션을 참조하세요.

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListInstanceProfileTags",
        "iam:TagInstanceProfile"
    ],
    "Resource": "arn:aws:iam::<account-number>:instance-profile/<InstanceProfileName>"
}
```

또는 [IAMFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/IAMFullAccess) 등의 AWS 관리형 정책을 사용하여 IAM에 모든 액세스 권한을 제공할 수 있습니다.

## 인스턴스 프로파일의 태그 관리(AWS CLI 또는 AWS API)
<a name="id_tags_instance-profile_procs-cli-api"></a>

인스턴스 프로파일의 태그를 나열, 연결 또는 제거할 수 있습니다. AWS CLI 또는 AWS API를 사용하여 인스턴스 프로파일의 태그를 관리할 수 있습니다.

**인스턴스 프로파일에 현재 연결된 태그를 나열하려면(AWS CLI 또는 AWS API)**
+ AWS CLI: [aws iam list-instance-profile-tags](https://docs.aws.amazon.com/cli/latest/reference/iam/list-instance-profile-tags.html)
+ AWS API: [ListInstanceProfileTags](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListInstanceProfileTags.html)

**인스턴스 프로파일에 태그를 연결하려면(AWS CLI 또는 AWS API)**
+ AWS CLI: [aws iam tag-instance-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-instance-profile.html)
+ AWS API: [TagInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagInstanceProfile.html)

**인스턴스 프로파일에서 태그를 제거하려면(AWS CLI 또는 AWS API)**
+ AWS CLI: [aws iam untag-instance-profile](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-instance-profile.html)
+ AWS API: [UntagInstanceProfile](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagInstanceProfile.html)

다른 AWS 서비스의 리소스에 대한 태그 연결 정보는 해당 서비스의 설명서를 참조하세요.

IAM 권한 정책에 태그를 사용하여 보다 세분화된 권한을 설정하는 방법에 대한 자세한 내용은 [IAM 정책 요소: 변수 및 태그](reference_policies_variables.md) 섹션을 참조하세요.

# 서버 인증서 태깅
<a name="id_tags_server-certificates"></a>

IAM을 사용하여 SSL/TLS 인증서를 관리하는 경우 AWS CLI 또는 AWS API를 사용하여 IAM의 서버 인증서를 태깅할 수 있습니다. AWS Certificate Manager(ACM)에서 지원하는 리전의 인증서인 경우, IAM 대신 ACM을 사용하여 서버 인증서를 프로비저닝, 관리 및 배포하는 것이 좋습니다. 지원되지 않는 리전에서는 IAM을 인증서 관리자로 사용해야 합니다. ACM이 지원하는 리전을 알아보려면 **AWS 일반 참조의 [AWS Certificate Manager 엔드포인트 및 할당량](https://docs.aws.amazon.com/general/latest/gr/acm.html)을 참조하세요.

IAM 태그 키 값 페어를 사용하여 서버 인증서에 사용자 지정 속성을 추가할 수 있습니다. 예를 들어 서버 인증서의 소유자 또는 관리자에 대한 정보를 추가하기 위해 태그 키 **owner**와 태그 값 **net-eng**를 추가합니다. 또는 태그 키 **CostCenter**와 태그 값 **1234**를 추가하여 비용 센터를 지정할 수도 있습니다. 태그를 사용하여 리소스에 대한 액세스를 제어하거나 리소스에 연결할 수 있는 태그를 제어할 수 있습니다. 태그를 사용하여 액세스를 제어하는 방법에 대한 자세한 내용은 [태그를 사용하여 IAM 사용자 및 역할에 대한 액세스 제어](access_iam-tags.md) 섹션을 참조하세요.

역할을 수임하거나 사용자를 연동할 때 AWS STS에서 태그를 사용하여 사용자 지정 속성을 추가할 수도 있습니다. 자세한 내용은 [AWS STS에서 세션 태그 전달](id_session-tags.md) 섹션을 참조하세요.

## 서버 인증서를 태깅하는 데 필요한 권한
<a name="id_tags_server-certificates_permissions"></a>

IAM 엔터티(사용자 또는 역할)가 서버 인증서를 태깅할 수 있도록 권한을 구성해야 합니다. IAM 정책에서 다음 IAM 태그 작업 중 하나 또는 모두를 지정할 수 있습니다.
+ `iam:ListServerCertificateTags`
+ `iam:TagServerCertificate`
+ `iam:UntagServerCertificate`

**IAM 엔터티(사용자 또는 역할)가 서버 인증서의 태그를 추가, 나열 또는 제거하도록 허용하려면**  
태그를 관리해야 하는 IAM 엔터티의 권한 정책에 다음 명령문을 추가합니다. 계정 번호를 사용하고 *<CertificateName>*을 태그를 관리해야 하는 서버 인증서의 이름으로 바꿉니다. 이 예제 JSON 정책 문서를 사용하여 정책을 생성하는 방법에 대해 자세히 알아보려면 [JSON 편집기를 사용하여 정책 생성](access_policies_create-console.md#access_policies_create-json-editor) 섹션을 참조하세요.

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListServerCertificateTags",
        "iam:TagServerCertificate",
        "iam:UntagServerCertificate"
    ],
    "Resource": "arn:aws:iam::<account-number>:server-certificate/<CertificateName>"
}
```

**IAM 엔터티(사용자 또는 역할)가 특정 서버 인증서에 태그를 추가하도록 허용하려면**  
특정 서버 인증서의 태그를 추가하기만 하고 제거하지는 않으려면 IAM 엔터티의 권한 정책에 다음 명령문을 추가합니다.

**참고**  
`iam:TagServerCertificate` 작업을 수행하려면 `iam:ListServerCertificateTags` 작업도 포함해야 합니다.

이 정책을 사용하려면 *<CertificateName>*을 태그를 관리해야 하는 서버 인증서의 이름으로 바꿉니다. 이 예제 JSON 정책 문서를 사용하여 정책을 생성하는 방법에 대해 자세히 알아보려면 [JSON 편집기를 사용하여 정책 생성](access_policies_create-console.md#access_policies_create-json-editor) 섹션을 참조하세요.

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListServerCertificateTags",
        "iam:TagServerCertificate"
    ],
    "Resource": "arn:aws:iam::<account-number>:server-certificate/<CertificateName>"
}
```

또는 [IAMFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/IAMFullAccess) 등의 AWS 관리형 정책을 사용하여 IAM에 모든 액세스 권한을 제공할 수 있습니다.

## 서버 인증서의 태그 관리(AWS CLI 또는 AWS API)
<a name="id_tags_server-certificates_procs-cli-api"></a>

서버 인증서의 태그를 나열, 연결 또는 제거할 수 있습니다. AWS CLI 또는 AWS API를 사용하여 서버 인증서의 태그를 관리할 수 있습니다.

**서버 인증서에 현재 연결된 태그를 나열하려면(AWS CLI 또는 AWS API)**
+ AWS CLI: [aws iam list-server-certificate-tags](https://docs.aws.amazon.com/cli/latest/reference/iam/list-server-certificate-tags.html)
+ AWS API: [ListServerCertificateTags](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListServerCertificateTags.html)

**서버 인증서에 태그를 연결하려면(AWS CLI 또는 AWS API)**
+ AWS CLI: [aws iam tag-server-certificate](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-server-certificate.html)
+ AWS API: [TagServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagServerCertificate.html)

**서버 인증서에서 태그를 제거하려면(AWS CLI 또는 AWS API)**
+ AWS CLI: [aws iam untag-server-certificate](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-server-certificate.html)
+ AWS API: [UntagServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagServerCertificate.html)

다른 AWS 서비스의 리소스에 대한 태그 연결 정보는 해당 서비스의 설명서를 참조하세요.

IAM 권한 정책에 태그를 사용하여 보다 세분화된 권한을 설정하는 방법에 대한 자세한 내용은 [IAM 정책 요소: 변수 및 태그](reference_policies_variables.md) 섹션을 참조하세요.

# 가상 MFA 디바이스 태깅
<a name="id_tags_virtual-mfa"></a>

IAM 태그 키 값 페어를 사용하여 가상 MFA 디바이스에 사용자 지정 속성을 추가할 수 있습니다. 예를 들어 사용자의 가상 MFA 디바이스에 대한 비용 센터 정보를 추가하려는 경우 태그 키 **CostCenter**와 태그 값 **1234**를 추가할 수 있습니다. 태그를 사용하여 리소스에 대한 액세스를 제어하거나 객체에 연결할 수 있는 태그를 제어할 수 있습니다. 태그를 사용하여 액세스를 제어하는 방법에 대한 자세한 내용은 [태그를 사용하여 IAM 사용자 및 역할에 대한 액세스 제어](access_iam-tags.md) 섹션을 참조하세요.

역할을 수임하거나 사용자를 연동할 때 AWS STS에서 태그를 사용하여 사용자 지정 속성을 추가할 수도 있습니다. 자세한 내용은 [AWS STS에서 세션 태그 전달](id_session-tags.md) 섹션을 참조하세요.

## 가상 MFA 디바이스를 태깅하는 데 필요한 권한
<a name="id_tags_virtual-mfa_permissions"></a>

IAM 엔터티(사용자 또는 역할)가 가상 MFA 디바이스를 태깅할 수 있도록 권한을 구성해야 합니다. IAM 정책에서 다음 IAM 태그 작업 중 하나 또는 모두를 지정할 수 있습니다.
+ `iam:ListMFADeviceTags`
+ `iam:TagMFADevice`
+ `iam:UntagMFADevice`

**IAM 엔터티(사용자 또는 역할)가 가상 MFA 디바이스의 태그를 추가, 나열 또는 제거하도록 허용하려면**  
태그를 관리해야 하는 IAM 엔터티의 권한 정책에 다음 명령문을 추가합니다. 계정 번호를 사용하고 *<MFATokenID>*를 태그를 관리해야 하는 가상 MFA 디바이스의 이름으로 바꿉니다. 이 예제 JSON 정책 문서를 사용하여 정책을 생성하는 방법에 대해 자세히 알아보려면 [JSON 편집기를 사용하여 정책 생성](access_policies_create-console.md#access_policies_create-json-editor) 섹션을 참조하세요.

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListMFADeviceTags",
        "iam:TagMFADevice",
        "iam:UntagMFADevice"
    ],
    "Resource": "arn:aws:iam::<account-number>:mfa/<MFATokenID>"
}
```

**IAM 엔터티(사용자 또는 역할)가 특정 가상 MFA 디바이스에 태그를 추가하도록 허용하려면**  
특정 MFA 디바이스의 태그를 추가하기만 하고 제거하지는 않으려면 IAM 엔터티의 권한 정책에 다음 명령문을 추가합니다.

**참고**  
`iam:TagMFADevice` 작업을 수행하려면 `iam:ListMFADeviceTags` 작업도 포함해야 합니다.

이 정책을 사용하려면 *<MFATokenID>*를 태그를 관리해야 하는 가상 MFA 디바이스의 이름으로 바꿉니다. 이 예제 JSON 정책 문서를 사용하여 정책을 생성하는 방법에 대해 자세히 알아보려면 [JSON 편집기를 사용하여 정책 생성](access_policies_create-console.md#access_policies_create-json-editor) 섹션을 참조하세요.

```
{
    "Effect": "Allow",
    "Action": [
        "iam:ListMFADeviceTags",
        "iam:TagMFADevice"
    ],
    "Resource": "arn:aws:iam::<account-number>:mfa/<MFATokenID>"
}
```

또는 [IAMFullAccess](https://console.aws.amazon.com/iam/home#policies/arn:aws:iam::aws:policy/IAMFullAccess) 등의 AWS 관리형 정책을 사용하여 IAM에 모든 액세스 권한을 제공할 수 있습니다.

## 가상 MFA 디바이스의 태그 관리(AWS CLI 또는 AWS API)
<a name="id_tags_virtual-mfa_procs-cli-api"></a>

가상 MFA 디바이스의 태그를 나열, 연결 또는 제거할 수 있습니다. AWS CLI 또는 AWS API를 사용하여 가상 MFA 디바이스의 태그를 관리할 수 있습니다.

**가상 MFA 디바이스에 현재 연결된 태그를 나열하려면(AWS CLI 또는 AWS API)**
+ AWS CLI: [aws iam list-mfa-device-tags](https://docs.aws.amazon.com/cli/latest/reference/iam/list-mfa-device-tags.html)
+ AWS API: [ListMFADeviceTags](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ListMFADeviceTags.html)

**가상 MFA 디바이스에 태그를 연결하려면(AWS CLI 또는 AWS API)**
+ AWS CLI: [aws iam tag-mfa-device](https://docs.aws.amazon.com/cli/latest/reference/iam/tag-mfa-device.html)
+ AWS API: [TagMFADevice](https://docs.aws.amazon.com/IAM/latest/APIReference/API_TagMFADevice.html)

**가상 MFA 디바이스에서 태그를 제거하려면(AWS CLI 또는 AWS API)**
+ AWS CLI: [aws iam untag-mfa-device](https://docs.aws.amazon.com/cli/latest/reference/iam/untag-mfa-device.html)
+ AWS API: [UntagMFADevice](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UntagMFADevice.html)

다른 AWS 서비스의 리소스에 대한 태그 연결 정보는 해당 서비스의 설명서를 참조하세요.

IAM 권한 정책에 태그를 사용하여 보다 세분화된 권한을 설정하는 방법에 대한 자세한 내용은 [IAM 정책 요소: 변수 및 태그](reference_policies_variables.md) 섹션을 참조하세요.

# AWS STS에서 세션 태그 전달
<a name="id_session-tags"></a>

세션 태그는 AWS STS에서 IAM 역할을 수임하거나 사용자를 페더레이션할 때 전달하는 키 값 페어 속성입니다. AWS STS 또는 자격 증명 공급자(IdP)를 통해 AWS CLI 또는 AWS API를 요청하면 됩니다. AWS STS를 사용하여 임시 보안 자격 증명을 요청하면 세션이 생성됩니다. 세션은 만료되고 액세스 키 페어 및 세션 토큰과 같은 [자격 증명](https://docs.aws.amazon.com/STS/latest/APIReference/API_Credentials.html)을 갖습니다. 세션 자격 증명을 사용하여 후속 요청을 하면 [요청 컨텍스트](reference_policies_elements_condition.md#AccessPolicyLanguage_RequestContext)에 `aws:PrincipalTag` 컨텍스트 키가 포함됩니다. 정책의 `Condition` 요소에서 `aws:PrincipalTag` 키를 사용하여 해당 태그를 기반으로 액세스를 허용하거나 거부할 수 있습니다.

임시 자격 증명을 사용하여 요청하면 보안 주체에 태그 세트가 포함될 수 있습니다. 이러한 태그는 다음 소스에서 가져옵니다.

1. **세션 태그** - AWS CLI 또는 AWS API를 사용하여 역할을 수임하거나 사용자를 페더레이션할 때 전달되는 태그입니다. 이러한 작업에 대한 자세한 내용은 [세션 태그 지정 작업](#id_session-tags_operations) 섹션을 참조하세요.

1. **수신 전이적 세션 태그** - 역할 체인의 이전 세션에서 상속되는 태그입니다. 자세한 내용은 이 주제의 후반부에서 [세션 태그를 사용하는 역할 체인](#id_session-tags_role-chaining) 섹션을 참조하세요.

1. **IAM 태그** - IAM 수임된 역할에 연결된 태그입니다.

**Topics**
+ [

## 세션 태그 지정 작업
](#id_session-tags_operations)
+ [

## 세션 태그에 대해 알아야 할 사항
](#id_session-tags_know)
+ [

## 세션 태그를 추가하는 데 필요한 권한
](#id_session-tags_permissions-required)
+ [

## AssumeRole을 사용하여 세션 태그 전달
](#id_session-tags_adding-assume-role)
+ [

## AssumeRoleWithSAML을 사용하여 세션 태그 전달
](#id_session-tags_adding-assume-role-saml)
+ [

## AssumeRoleWithWebIdentity를 사용하여 세션 태그 전달
](#id_session-tags_adding-assume-role-idp)
+ [

## GetFederationToken을 사용하여 세션 태그 전달
](#id_session-tags_adding-getfederationtoken)
+ [

## 세션 태그를 사용하는 역할 체인
](#id_session-tags_role-chaining)
+ [

## ABAC에 세션 태그 사용
](#id_session-tags_using-abac)
+ [

## CloudTrail에서 세션 태그 보기
](#id_session-tags_ctlogs)

## 세션 태그 지정 작업
<a name="id_session-tags_operations"></a>

AWS STS에서 다음 AWS CLI 또는 AWS API 작업을 사용하여 세션 태그를 전달할 수 있습니다. *AWS Management Console **[역할 전환](id_roles_use_switch-role-console.md)** 기능을 사용하여 세션 태그를 전달할 수 없습니다.*

세션 태그를 전이적으로 설정할 수도 있습니다. 전이적 태그는 역할 체인 동안 지속됩니다. 자세한 내용은 [세션 태그를 사용하는 역할 체인](#id_session-tags_role-chaining) 섹션을 참조하세요.

다음 표에서는 세션 태그 전달 방법을 비교합니다.


|  연산 |  **역할을 위임할 수 있는 사용자**  | **태그를 전달하는 방법** |  **전이적 태그를 설정하는 방법**  | 
| --- | --- | --- | --- | 
| [https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html) CLI 또는 [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API 작업 | IAM 사용자 또는 세션 | Tags API 파라미터 또는 --tags CLI 옵션 | TransitiveTagKeys API 파라미터 또는 --transitive-tag-keys CLI 옵션 | 
| [https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-saml.html](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-saml.html) CLI 또는 [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html) API 작업 | SAML 자격 증명 공급자를 사용하여 인증된 모든 사용자 | PrincipalTag SAML 속성 | TransitiveTagKeys SAML 속성 | 
| [https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-web-identity.html](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-web-identity.html) CLI 또는 [https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html) API 작업 | OIDC 공급자를 사용하여 인증된 모든 사용자 | PrincipalTag OIDC 토큰 | TransitiveTagKeys OIDC 토큰 | 
| [https://docs.aws.amazon.com/cli/latest/reference/sts/get-federation-token.html](https://docs.aws.amazon.com/cli/latest/reference/sts/get-federation-token.html) CLI 또는 [https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html) API 작업 | IAM 사용자 또는 루트 사용자 | Tags API 파라미터 또는 --tags CLI 옵션 | 지원되지 않음 | 

다음 조건에서는 세션 태그 지정을 지원하는 작업이 실패할 수 있습니다.
+ 50개 이상의 세션 태그를 전달하는 경우
+ 세션 태그 키의 일반 텍스트가 128자를 초과하는 경우
+ 세션 태그 값의 일반 텍스트가 256자를 초과하는 경우
+ 세션 정책의 일반 텍스트 총 크기가 2048자를 초과하는 경우
+ 세션 정책과 태그를 합친 총 압축 크기가 너무 큰 경우. 작업이 실패할 경우 오류 메시지에 정책과 태그를 합친 크기가 크기 상한에 얼마나 가까운지가 백분율로 표시됩니다.

## 세션 태그에 대해 알아야 할 사항
<a name="id_session-tags_know"></a>

세션 태그를 사용하기 전에 세션 및 태그에 대한 다음 세부 정보를 검토합니다.
+ 세션 태그를 사용하는 경우 태그를 전달하는 자격 증명 공급자(IdP)에 연결된 모든 역할의 신뢰 정책에 [`sts:TagSession`](#id_session-tags_permissions-required) 권한이 있어야 합니다. 역할의 신뢰 정책에 이 권한이 없는 경우 `AssumeRole` 작업이 실패합니다.
+ 세션을 요청할 때 보안 주체 태그를 세션 태그로 지정할 수 있습니다. 태그는 세션의 자격 증명을 사용하여 생성한 요청에 적용됩니다.
+ 세션 태그는 키 값 페어를 사용합니다. 예를 들어, 세션에 연락처 정보를 추가하려면 세션 태그 키 `email` 및 태그 값 `johndoe@example.com`을 추가할 수 있습니다.
+ 세션 태그는[IAM 및 AWS STS의 태그 이름 지정 규칙](id_tags.md#id_tags_rules_creating)을 따라야 합니다. 이 주제에는 세션 태그에 적용되는 대/소문자 구분 및 제한된 접두사에 대한 정보가 포함되어 있습니다.
+ 새 세션 태그는 대소문자에 관계없이 동일한 태그 키의 기존에 맡은 역할 또는 페더레이션 사용자 세션 태그를 재정의합니다.
+ AWS Management Console을 사용하여 세션 태그를 전달할 수는 없습니다.
+ 세션 태그는 현재 세션에서만 유효합니다.
+ 세션 태그는 [역할 체인](id_roles.md#iam-term-role-chaining)을 지원합니다. 기본적으로 AWS STS에서는 후속 역할 세션에 태그를 전달하지 않습니다. 그러나 세션 태그를 전이적으로 설정할 수 있습니다. 전이적 태그는 역할 체인 중 유지되고 역할 신뢰 정책 평가 이후 일치하는 `ResourceTag` 값을 대체합니다. 자세한 내용은 [세션 태그를 사용하는 역할 체인](#id_session-tags_role-chaining) 섹션을 참조하세요.
+ 세션 태그를 사용하여 리소스에 대한 액세스를 제어하거나 후속 세션에 전달할 수 있는 태그를 제어할 수 있습니다. 자세한 내용은 [IAM 튜토리얼: ABAC에 SAML 세션 태그 사용](tutorial_abac-saml.md) 섹션을 참조하세요.
+ AWS CloudTrail 로그에서 세션 태그를 비롯하여 세션의 보안 주체 태그를 볼 수 있습니다. 자세한 내용은 [CloudTrail에서 세션 태그 보기](#id_session-tags_ctlogs) 섹션을 참조하세요.
+ 각 세션 태그에는 단일 값을 전달해야 합니다. AWS STS에서는 다중 값 세션 태그를 지원하지 않습니다.
+ 최대 50개의 세션 태그를 전달할 수 있습니다. AWS 계정의 IAM 리소스 수와 크기는 제한되어 있습니다. 자세한 내용은 [IAM 및 AWS STS 할당량](reference_iam-quotas.md) 섹션을 참조하세요.
+ AWS 변환은 전달된 세션 정책과 세션 태그를 별도의 제한이 있는 압축된 이진 형식으로 압축합니다. 이 제한을 초과할 경우 AWS CLI 또는 AWS API 오류 메시지에 결합된 정책과 태그가 크기 상한에 얼마나 가까운지가 백분율로 표시됩니다.

## 세션 태그를 추가하는 데 필요한 권한
<a name="id_session-tags_permissions-required"></a>

API 작업과 일치하는 작업 외에도 정책에는 다음과 같은 권한 전용 작업이 있어야 합니다.

```
sts:TagSession
```

**중요**  
세션 태그를 사용하는 경우 자격 증명 공급자(IdP)에 연결된 모든 역할에 대한 역할 신뢰 정책에 `sts:TagSession` 권한이 있어야 합니다. 이 권한 없이 세션 태그를 전달하는 IdP에 연결된 모든 역할의 경우 `AssumeRole` 작업이 실패합니다. 각 역할에 대한 역할 신뢰 정책을 업데이트하지 않으려는 경우 세션 태그를 전달하는 데 개별 IdP 인스턴스를 사용할 수 있습니다. 그런 다음 개별 IdP에 연결된 역할에만 `sts:TagSession` 권한을 추가합니다.

`sts:TagSession` 작업을 다음 조건 키와 함께 사용할 수 있습니다.
+ `aws:PrincipalTag` - 이 키를 사용하여 요청한 보안 주체에 연결된 태그를 정책에서 지정한 태그와 비교합니다. 예를 들어, 요청을 하는 보안 주체에 지정된 태그가 있는 경우에만 보안 주체가 세션 태그를 전달하도록 허용할 수 있습니다.
+ `aws:RequestTag` - 요청에서 전달된 태그 키 값 페어를 정책에서 지정한 태그 페어와 비교합니다. 예를 들어, 보안 주체가 지정된 세션 태그를 전달할 수는 있지만, 지정된 값만 사용하도록 허용할 수 있습니다.
+ `aws:ResourceTag` - 정책에서 지정한 태그 키 값 페어를 리소스에 연결된 키 값 페어와 비교합니다. 예를 들어, 보안 주체가 수임하고 있는 역할에 지정된 태그가 포함된 경우에만 보안 주체가 세션 태그를 전달하도록 허용할 수 있습니다.
+ `aws:TagKeys` - 요청의 태그 키를 정책에서 지정한 키와 비교합니다. 예를 들어, 보안 주체가 지정된 태그 키를 가진 세션 태그만 전달하도록 허용할 수 있습니다. 이 조건 키는 전달할 수 있는 최대 세션 태그 세트를 제한합니다.
+ `sts:TransitiveTagKeys` - 요청의 전이적 세션 태그 키와 정책에 지정된 전이적 세션 태그 키를 비교합니다. 예를 들어, 보안 주체가 특정 태그만 전이적으로 설정하도록 허용하는 정책을 작성할 수 있습니다. 전이적 태그는 역할 체인 동안 지속됩니다. 자세한 내용은 [세션 태그를 사용하는 역할 체인](#id_session-tags_role-chaining) 섹션을 참조하세요.

예를 들어, 다음 [역할 신뢰 정책](id_roles.md#term_trust-policy)은 `test-session-tags` 사용자가 정책이 연결된 역할을 수임할 수 있도록 허용합니다. 해당 사용자가 역할을 맡는 경우 AWS CLI 또는 AWS API를 사용하여 세 개의 필수 세션 태그와 필수 [외부 ID](id_roles_common-scenarios_third-party.md#id_roles_third-party_external-id)를 전달해야 합니다. 또한 사용자는 `Project` 및 `Department` 태그를 전이적으로 설정하도록 선택할 수 있습니다.

**Example 세션 태그에 대한 역할 신뢰 정책의 예**    
****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Sid": "AllowIamUserAssumeRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Principal": {"AWS": "arn:aws:iam::123456789012:user/test-session-tags"},
            "Condition": {
              "StringLike": {
                    "aws:RequestTag/Project": "*",
                    "aws:RequestTag/CostCenter": "*",
                    "aws:RequestTag/Department": "*"
                },
                "StringEquals": {"sts:ExternalId": "Example987"}
            }
        },
        {
            "Sid": "AllowPassSessionTagsAndTransitive",
            "Effect": "Allow",
            "Action": "sts:TagSession",
            "Principal": {"AWS": "arn:aws:iam::123456789012:user/test-session-tags"},
            "Condition": {
                "StringLike": {
                    "aws:RequestTag/Project": "*",
                    "aws:RequestTag/CostCenter": "*"
                },
                "StringEquals": {
                    "aws:RequestTag/Department": [
                        "Engineering",
                        "Marketing"
                    ]
                },
                "ForAllValues:StringEquals": {
                    "sts:TransitiveTagKeys": [
                        "Project",
                        "Department"
                    ]
                }
            }
        }
    ]
}
```

**이 정책이 하는 일은 무엇입니까?**
+ `AllowIamUserAssumeRole` 문은 `test-session-tags` 사용자가 정책이 연결된 역할을 수임할 수 있도록 허용합니다. 해당 사용자가 역할을 맡을 때는 필수 세션 태그 및 [외부 ID](id_roles_common-scenarios_third-party.md#id_roles_third-party_external-id)를 전달해야 합니다.
  + 이 문의 첫 번째 조건 블록의 경우 사용자가 `Project`, `CostCenter` 및 `Department` 세션 태그를 전달해야 합니다. 이 문에서 태그 값은 중요하지 않으므로 태그 값에 와일드카드(\$1)를 사용할 수 있습니다. 이 블록의 경우 사용자가 적어도 이 세 개의 세션 태그를 전달해야 하며 그렇지 않으면 작업이 실패합니다. 사용자는 추가 태그를 전달할 수 있습니다.
  + 두 번째 조건 블록의 경우 사용자가 `Example987` 값의 [외부 ID](id_roles_common-scenarios_third-party.md#id_roles_third-party_external-id)를 전달해야 합니다.
+ `AllowPassSessionTagsAndTransitive` 문은 `sts:TagSession` 권한 전용 작업을 허용합니다. 이 작업을 허용해야 사용자가 세션 태그를 전달할 수 있습니다. 정책에 두 번째 문은 없고 첫 번째 문만 포함되어 있는 경우 사용자는 역할을 맡을 수 없습니다.
  + 이 문의 첫 번째 조건 블록은 사용자가 `CostCenter` 및 `Project` 세션 태그에 대한 값을 전달하도록 허용합니다. 정책의 태그 값에 와일드카드(\$1)를 사용하여 이 작업을 수행하려면 [StringLike](reference_policies_elements_condition_operators.md#Conditions_String) 조건 연산자를 사용해야 합니다.
  + 두 번째 조건 블록은 사용자가 `Department` 세션 태그의 `Engineering` 또는 `Marketing` 값만 전달하도록 허용합니다.
  + 세 번째 조건 블록은 전이적으로 설정할 수 있는 최대 태그 세트를 나열합니다. 사용자는 하위 세트를 설정하거나 태그를 전이적으로 설정하지 않도록 선택할 수 있습니다. 그러나 추가 태그를 전이적으로 설정할 수는 없습니다. `"Null":{"sts:TransitiveTagKeys":"false"}`를 포함하는 다른 조건 블록을 추가하여 태그 중 하나 이상을 전이적으로 설정하도록 요구할 수 있습니다.

## AssumeRole을 사용하여 세션 태그 전달
<a name="id_session-tags_adding-assume-role"></a>

`AssumeRole` 작업은 AWS 리소스에 액세스하는 데 사용할 수 있는 임시 자격 증명 세트를 반환합니다. IAM 사용자 또는 역할 자격 증명을 사용하여 `AssumeRole`을 호출할 수 있습니다. 역할을 맡는 동안 세션 태그를 전달하려면 `--tags` AWS CLI 옵션 또는 `Tags` AWS API 파라미터를 사용합니다.

태그를 전이적으로 설정하려면 `--transitive-tag-keys` AWS CLI 옵션 또는 `TransitiveTagKeys` AWS API 파라미터를 사용합니다. 전이적 태그는 역할 체인 동안 지속됩니다. 자세한 내용은 [세션 태그를 사용하는 역할 체인](#id_session-tags_role-chaining) 섹션을 참조하세요.

다음 예제에서는 `AssumeRole`을 사용하는 샘플 요청을 보여 줍니다. 이 예제에서는 `my-role-example` 역할을 맡을 때 `my-session`이라는 세션을 생성합니다. 세션 태그 키 값 페어 `Project` = `Automation`, `CostCenter` = `12345` 및 `Department` = `Engineering`을 추가합니다. 또한 해당 키를 지정하여 `Project` 및 `Department` 태그를 전이적으로 설정합니다. 각 세션 태그에는 단일 값을 전달해야 합니다. AWS STS에서는 다중 값 세션 태그를 지원하지 않습니다.

**Example AssumeRole CLI 요청의 예**  

```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/my-role-example \
--role-session-name my-session \
--tags Key=Project,Value=Automation Key=CostCenter,Value=12345 Key=Department,Value=Engineering \
--transitive-tag-keys Project Department \
--external-id Example987
```

## AssumeRoleWithSAML을 사용하여 세션 태그 전달
<a name="id_session-tags_adding-assume-role-saml"></a>

`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. [AWS에 대한 SAML 공급자로 네트워크 구성](id_roles_providers_saml_3rd-party.md)

1. [IAM에서 SAML 공급자 생성](id_roles_providers_create_saml.md)

1. [SAML 2.0 페더레이션을 위한 역할 생성(콘솔)](id_roles_create_for-idp_saml.md)

1. [SAML IdP 구성을 완료하고 SAML 인증 응답에 대한 어설션 생성하기](id_roles_providers_create_saml_assertions.md)

AWS에는 자격 증명 솔루션에 세션 태그에 대한 인증된 엔드 투 엔드 환경이 있는 파트너가 포함되어 있습니다. 이러한 자격 증명 공급자를 사용하여 세션 태그를 구성하는 방법은 [서드 파티 SAML 솔루션 공급자를 AWS와 통합](id_roles_providers_saml_3rd-party.md) 섹션을 참조하세요.

SAML 속성을 세션 태그로 전달하려면 `Name` 속성이 `https://aws.amazon.com/SAML/Attributes/PrincipalTag:{TagKey}`로 설정된 `Attribute` 요소를 포함합니다. `AttributeValue` 요소를 사용하여 태그 값을 지정합니다. 각 세션 태그마다 별도의 `Attribute` 요소를 포함합니다.

예를 들어, 다음 자격 증명 속성을 세션 태그로 전달한다고 가정합니다.
+ `Project:Automation`
+ `CostCenter:12345`
+ `Department:Engineering`

이러한 속성을 전달하려면 SAML 어설션에 다음 요소를 포함합니다.

**Example SAML 어설션의 코드 조각 예**  

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:Project">
  <AttributeValue>Automation</AttributeValue>
</Attribute>
<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:CostCenter">
  <AttributeValue>12345</AttributeValue>
</Attribute>
<Attribute Name="https://aws.amazon.com/SAML/Attributes/PrincipalTag:Department">
  <AttributeValue>Engineering</AttributeValue>
</Attribute>
```

앞의 태그를 전이적으로 설정하려면 `Name` 속성이 `https://aws.amazon.com/SAML/Attributes/TransitiveTagKeys`로 설정된 다른 `Attribute` 요소를 포함합니다. 전이적 태그는 역할 체인 동안 지속됩니다. 자세한 내용은 [세션 태그를 사용하는 역할 체인](#id_session-tags_role-chaining) 섹션을 참조하세요.

`Project` 및 `Department` 태그를 전이적으로 설정하려면 다음과 같은 다중 값 속성을 사용합니다.

**Example SAML 어설션의 코드 조각 예**  

```
<Attribute Name="https://aws.amazon.com/SAML/Attributes/TransitiveTagKeys">
  <AttributeValue>Project</AttributeValue>
  <AttributeValue>Department</AttributeValue>
</Attribute>
```

## AssumeRoleWithWebIdentity를 사용하여 세션 태그 전달
<a name="id_session-tags_adding-assume-role-idp"></a>

OIDC(OpenID Connect) 호환 페더레이션을 사용하여 `AssumeRoleWithWebIdentity` 작업을 인증합니다. 이 작업은 AWS 리소스에 액세스하는 데 사용할 수 있는 임시 자격 증명 세트를 반환합니다. AWS Management Console 액세스를 위해 웹 아이덴티티 페더레이션을 사용하는 방법에 대한 자세한 내용은 [OIDC 페더레이션](id_roles_providers_oidc.md) 섹션을 참조하세요.

OIDC(OpenID Connect)에서 세션 태그를 전달하려면 `AssumeRoleWithWebIdentity` 요청을 제출할 때 JSON 웹 토큰(JWT)에 세션 태그를 포함해야 합니다. OIDC 토큰 및 클레임에 대한 자세한 내용은 *Amazon Cognito 개발자 안내서*의 [사용자 풀과 함께 토큰 사용](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)을 참조하세요.

AWS는 JWT에 세션 태그를 포함하기 위한 두 가지 클레임 형식을 지원합니다.
+ 중첩된 클레임 형식
+ 평면화된 클레임 형식

### 중첩된 클레임 형식
<a name="id_session-tags_adding-assume-role-idp-nested-format"></a>

중첩된 클레임 형식은 JWT의 `https://aws.amazon.com/tags` 네임스페이스 내 구조를 사용합니다. 이 형식에서,
+ 위탁자 태그는 `principal_tags` 키 아래에 중첩된 객체로 표시됩니다.
+ 각 위탁자 태그는 단일 문자열 값입니다.
+ 전이적 태그 키는 `transitive_tag_keys` 키 아래에 배열로 표시됩니다.
+ `principal_tags`와 `transitive_tag_keys`는 둘 다 `https://aws.amazon.com/tags` 네임스페이스 아래에 중첩됩니다.

다음의 예제는 중첩된 객체 형식을 사용하는 디코딩된 JWT를 보여줍니다.

**Example 중첩된 클레임 형식을 사용하는 디코딩된 JSON 웹 토큰의 예**  

```
{
    "sub": "johndoe",
    "aud": "ac_oic_client",
    "jti": "ZYUCeRMQVtqHypVPWAN3VB",
    "iss": "https://xyz.com",
    "iat": 1566583294,
    "exp": 1566583354,
    "auth_time": 1566583292,
    "https://aws.amazon.com/tags": {
        "principal_tags": {
            "Project": ["Automation"],
            "CostCenter": ["987654"],
            "Department": ["Engineering"]
        },
        "transitive_tag_keys": [
            "Project",
            "CostCenter"
        ]
    }
}
```

### 평면화된 클레임 형식
<a name="id_session-tags_adding-assume-role-idp-flattened-format"></a>

평면화된 클레임 형식은 Microsoft Entra ID와 같이 JWT 클레임에서 중첩된 객체를 지원하지 않는 ID 제공업체와 호환됩니다. 이 형식에서,
+ 위탁자 태그는 `https://aws.amazon.com/tags/principal_tags/` 접두사가 지정된 별도의 클레임으로 표시됩니다.
+ 각 위탁자 태그는 단일 문자열 값입니다.
+ 전이적 태그 키는 단일 클레임에서 `https://aws.amazon.com/tags/transitive_tag_keys` 접두사가 지정된 문자열 배열로 표시됩니다.

이제 플랫 클레임 형식을 사용하여 동일한 정보가 어떻게 표현되는지 살펴보겠습니다.

**Example 평면화된 클레임 형식을 사용하는 디코딩된 JSON 웹 토큰의 예**  

```
{
    "sub": "johndoe",
    "aud": "ac_oic_client",
    "jti": "ZYUCeRMQVtqHypVPWAN3VB",
    "iss": "https://xyz.com",
    "iat": 1566583294,
    "exp": 1566583354,
    "auth_time": 1566583292,
    "https://aws.amazon.com/tags/principal_tags/Project": "Automation",
    "https://aws.amazon.com/tags/principal_tags/CostCenter": "987654",
    "https://aws.amazon.com/tags/principal_tags/Department": "Engineering",
    "https://aws.amazon.com/tags/transitive_tag_keys": [
        "Project",
        "CostCenter"
    ]
}
```

디코딩된 JWT 예제는 둘 다 `Project`, `CostCenter` 및 `Department` 세션 태그를 사용한 `AssumeRoleWithWebIdentity` 직접적인 호출을 보여줍니다. 두 토큰 모두 `Project` 및 `CostCenter` 태그를 전이적 태그로 설정합니다. 전이적 태그는 역할 체인 동안 지속됩니다. 자세한 내용은 [세션 태그를 사용하는 역할 체인](#id_session-tags_role-chaining) 섹션을 참조하세요.

평면화된 클레임 형식은 중첩된 클레임 형식과 동일한 결과를 얻지만 태그에 평면화된 구조를 사용합니다. 이를 통해 JWT 클레임에서 중첩된 JSON 객체가 지원되지 않는 환경에서 세션 태그를 포함할 수 있습니다. 두 형식 중 하나를 사용할 때는 ID 제공업체가 적절한 클레임 구조의 토큰을 발행하도록 구성되어 있는지 확인하세요. AWS는 두 클레임 형식을 모두 지원하므로 ID 제공업체의 특정 요구 사항에 가장 적합한 형식을 선택할 수 있습니다.

## GetFederationToken을 사용하여 세션 태그 전달
<a name="id_session-tags_adding-getfederationtoken"></a>

`GetFederationToken`을 사용하면 사용자를 페더레이션할 수 있습니다. 이 작업은 AWS 리소스에 액세스하는 데 사용할 수 있는 임시 자격 증명 세트를 반환합니다. 페더레이션 사용자 세션에 태그를 추가하려면 `--tags` AWS CLI 옵션 또는 `Tags` AWS API 파라미터를 사용합니다. `GetFederationToken`을 사용할 경우 세션 태그를 전이적으로 설정할 수 없습니다. 임시 자격 증명을 사용하여 역할을 수임할 수 없기 때문입니다. 이 경우 역할 체인을 사용할 수 없습니다.

다음 예제에서는 `GetFederationToken`을 사용하는 샘플 요청을 보여 줍니다. 이 예제에서는 토큰을 요청할 때 `my-fed-user`라는 세션을 생성합니다. 세션 태그 키 값 페어 `Project` = `Automation` 및 `Department` = `Engineering`을 추가합니다.

**Example GetFederationToken CLI 요청의 예**  

```
aws sts get-federation-token \
--name my-fed-user \
--tags key=Project,value=Automation key=Department,value=Engineering
```

`GetFederationToken` 작업에서 반환되는 임시 자격 증명을 사용하는 경우 세션의 보안 주체 태그에 사용자의 태그와 전달된 세션 태그가 포함됩니다.

## 세션 태그를 사용하는 역할 체인
<a name="id_session-tags_role-chaining"></a>

한 역할을 맡은 다음 임시 자격 증명을 사용하여 다른 역할을 맡을 수 있습니다. 이러한 작업을 세션 간에 계속할 수 있습니다. 이를 [역할 체인](id_roles.md#iam-term-role-chaining)이라고 합니다. 역할을 맡는 동안 세션 태그를 전달하면 키를 전이적으로 설정할 수 있습니다. 이렇게 하면 해당 세션 태그가 역할 체인의 후속 세션에 전달됩니다. 역할 태그를 전이적으로 설정할 수 없습니다. 이러한 태그를 후속 세션에 전달하려면 세션 태그로 지정합니다.

**참고**  
전이적 태그는 역할 체인 중 유지되고 역할 신뢰 정책 평가 이후 일치하는 `ResourceTag` 값을 대체합니다.

다음 예제에서는 AWS STS에서 세션 태그, 전이적 태그 및 역할 태그를 역할 체인의 후속 세션에 전달하는 방식을 보여줍니다.

이 역할 체인 시나리오 예제에서는 AWS CLI에서 IAM 사용자 액세스 키를 사용하여 `Role1`이라는 역할을 수임합니다. 그런 다음 결과 세션 자격 증명을 사용하여 `Role2`라는 두 번째 역할을 맡습니다. 그런 다음 두 번째 세션 자격 증명을 사용하여 `Role3`라는 세 번째 역할을 맡을 수 있습니다. 이러한 요청은 세 가지 개별 작업으로 발생합니다. IAM에서는 각 역할은 이미 태깅되어 있습니다. 그리고 각 요청 중에 추가 세션 태그를 전달합니다.

![\[역할 함께 묶기\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/session-tags-chaining-simple.png)


역할을 체인할 때 이전 세션의 태그가 이후 세션에서도 유지되도록 할 수 있습니다. `assume-role` CLI 명령을 사용하여 이 작업을 수행하려면 태그를 세션 태그로 전달하고 전이적으로 설정해야 합니다. 태그 `Star` = `1`을 세션 태그로 전달합니다. 또한 이 명령은 태그 `Heart` = `1`을 역할에 연결하고 세션을 사용할 때 보안 주체 태그로 적용합니다. 그러나 `Heart` = `1` 태그가 두 번째 또는 세 번째 세션에 자동으로 전달되도록 할 수도 있습니다. 이를 수행하려면 수동으로 세션 태그로 포함합니다. 결과 세션 보안 주체 태그에는 이러한 두 태그가 모두 포함되며 전이적으로 설정됩니다.

![\[역할 체인의 첫 번째 역할 맡기\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/session-tags-chaining-role1.png)


다음 AWS CLI 명령을 사용하여 이 요청을 수행합니다.

**Example AssumeRole CLI 요청의 예**  

```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/Role1 \
--role-session-name Session1 \
--tags Key=Star,Value=1 Key=Heart,Value=1 \
--transitive-tag-keys Star Heart
```

그런 다음 해당 세션에 대한 자격 증명을 사용하여 `Role2`를 맡습니다. 이 명령은 태그 `Sun` = `2`를 두 번째 역할에 연결하고 두 번째 세션을 사용할 때 보안 주체 태그로 적용합니다. `Heart` 및 `Star` 태그는 첫 번째 세션의 전이적 세션 태그를 상속합니다. 두 번째 세션의 결과 보안 주체 태그는 `Heart` = `1`, `Star` = `1` 및 `Sun` = `2`입니다. `Heart` 및 `Star`는 계속 전이적으로 유지됩니다. `Role2`에 연결된 `Sun` 태그는 세션 태그가 아니므로 전이적으로 표시되지 않습니다. 향후 세션에서는 이 태그를 상속하지 않습니다.

![\[역할 체인의 두 번째 역할 맡기\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/session-tags-chaining-role2.png)


다음 AWS CLI 명령을 사용하여 이 두 번째 요청을 수행합니다.

**Example AssumeRole CLI 요청의 예**  

```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/Role2 \
--role-session-name Session2
```

그런 다음 두 번째 세션 자격 증명을 사용하여 `Role3`를 맡습니다. 세 번째 세션의 보안 주체 태그는 새 세션 태그, 상속된 전이적 세션 태그 및 역할 태그에서 가져옵니다. 두 번째 세션의 `Heart` = `1` 및 `Star` = `1` 태그는 첫 번째 세션의 전이적 세션 태그에서 상속됩니다. `Sun` = `2` 세션 태그를 전달하려고 하면 작업이 실패합니다. 상속된 `Star` = 1 세션 태그는 역할의 `Star` = `3` 태그를 재정의합니다. 역할 체인에서 전이적 태그의 값은 역할 신뢰 정책 평가 후에 `ResourceTag` 값과 일치하는 역할을 재정의합니다. 이 예제에서는 `Role3`이 `Star`를 역할 신뢰 정책에서 `ResourceTag`로 사용하는 경우 `ResourceTag` 값을 호출 역할 세션의 전이 태그 값으로 설정합니다. 역할의 `Lightning` 태그는 세 번째 세션에도 적용되며 전이적으로 설정되지 않습니다.

![\[역할 체인의 세 번째 역할 맡기\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/session-tags-chaining-role3.png)


다음 AWS CLI 명령을 사용하여 세 번째 요청을 수행합니다.

**Example AssumeRole CLI 요청의 예**  

```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/Role3 \
--role-session-name Session3
```

## ABAC에 세션 태그 사용
<a name="id_session-tags_using-abac"></a>

속성 기반 액세스 제어(ABAC)는 태그 속성을 기반으로 권한을 정의하는 권한 부여 전략을 사용합니다.

회사에서 OIDC 또는 SAML 기반 자격 증명 공급자(IdP)를 사용하여 사용자 자격 증명을 관리하는 경우 세션 태그를 AWS에 전달하도록 어설션을 구성할 수 있습니다. 예를 들어 회사 사용자 자격 증명을 사용하면 직원이 AWS로 페더레이션할 때 AWS는 해당 속성을 결과 보안 주체에 적용합니다. 그런 다음 ABAC를 사용하여 이러한 속성에 따라 권한을 허용하거나 거부할 수 있습니다. 자세한 내용은 [IAM 튜토리얼: ABAC에 SAML 세션 태그 사용](tutorial_abac-saml.md) 섹션을 참조하세요.

ABAC에 IAM Identity Center를 사용하는 방법에 대한 자세한 내용은 *AWS IAM Identity Center 사용 설명서*의 [액세스 제어를 위한 속성](https://docs.aws.amazon.com/singlesignon/latest/userguide/attributesforaccesscontrol.html)을 참조하세요.

## CloudTrail에서 세션 태그 보기
<a name="id_session-tags_ctlogs"></a>

AWS CloudTrail을 사용하여 역할을 수임하거나 사용자를 페더레이션하는 데 사용되는 요청을 볼 수 있습니다. CloudTrail 로그 파일에는 수임한 역할 또는 페더레이션 사용자 세션의 보안 주체 태그에 대한 정보가 포함됩니다. 자세한 내용은 [AWS CloudTrail을 사용하여 IAM 및 AWS STS API 호출 로깅](cloudtrail-integration.md) 섹션을 참조하세요.

예를 들어, AWS STS `AssumeRoleWithSAML` 요청을 하고 세션 태그를 전달하고 해당 태그를 전이적으로 설정한다고 가정합니다. CloudTrail 로그에서 다음 정보를 찾을 수 있습니다.

**Example AssumeRoleWithSAML CloudTrail 로그의 예**  

```
    "requestParameters": {
        "sAMLAssertionID": "_c0046cEXAMPLEb9d4b8eEXAMPLE2619aEXAMPLE",
        "roleSessionName": "MyRoleSessionName",
        "principalTags": {
            "CostCenter": "987654",
            "Project": "Unicorn"
        },
        "transitiveTagKeys": [
            "CostCenter",
            "Project"
        ],
        "durationSeconds": 3600,
        "roleArn": "arn:aws:iam::123456789012:role/SAMLTestRoleShibboleth",
        "principalArn": "arn:aws:iam::123456789012:saml-provider/Shibboleth"
    },
```

다음 CloudTrail 로그 예제에서 세션 태그를 사용하는 이벤트를 볼 수 있습니다.
+ [CloudTrail 로그 파일의 AWS STS 역할 체인 API 이벤트의 예](cloudtrail-integration.md#stscloudtrailexample-assumerole)
+ [CloudTrail 로그 파일의 SAML AWS STS API 이벤트의 예](cloudtrail-integration.md#stscloudtrailexample_saml)
+ [CloudTrail 로그 파일의 예시 OIDC AWS STS API 이벤트](cloudtrail-integration.md#stscloudtrailexample_web-identity)