# 위임된 역할로 수행한 작업 모니터링 및 제어 [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)를 참조하세요.