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