설정 알아야 할 것들 소스 자격 증명 설정에 필요한 권한 역할을 수임할 때 소스 자격 증명 지정 AssumeRole AssumeRoleWithSAML AssumeRoleWithWebIdentity 소스 자격 증명을 사용하여 액세스 제어 AWS CloudTrail에서 소스 자격 증명 보기

위임된 역할로 수행한 작업 모니터링 및 제어

IAM 역할은 권한이 할당된 IAM의 객체입니다. IAM 자격 증명 또는 AWS 외부의 자격 증명을 사용하여 해당 역할을 수임하면 역할에 할당된 권한이 있는 세션을 받습니다.

AWS에서 작업을 수행하는 경우 세션에 대한 정보를 AWS CloudTrail에 로깅하여 계정 관리자가 모니터링하도록 할 수 있습니다. 관리자는 AWS에서 작업을 수행하는 사용자 또는 애플리케이션을 식별하는 사용자 지정 문자열을 전달하기 위해 자격 증명을 요구하도록 역할을 구성할 수 있습니다. 이 자격 증명 정보는 AWS CloudTrail에 소스 자격 증명으로 저장됩니다. 관리자가 CloudTrail에서 활동을 검토할 때 소스 자격 증명 정보를 보고 수임된 역할 세션에서 누가 또는 어떤 작업을 수행했는지 확인할 수 있습니다.

소스 자격 증명은 설정된 후에는 역할 세션 중 수행되는 모든 AWS 작업에 대해 요청에 표시됩니다. 설정된 값은 역할이 AWS CLI 또는 AWS API를 통해 다른 역할을 수임(역할 체인이라고 함)할 때 유지됩니다. 역할 세션 중에는 설정된 값을 변경할 수 없습니다. 관리자는 소스 자격 증명의 존재 여부나 값에 따라 세분화된 권한을 구성하여 공유 역할로 수행되는 AWS 작업을 보다 효과적으로 제어할 수 있습니다. 소스 자격 증명 속성을 사용할 수 있는지 여부, 필요한지 여부 및 사용할 수 있는 값을 결정할 수 있습니다.

소스 자격 증명을 사용하는 방법은 역할 세션 이름 및 세션 태그와 크게 다릅니다. 소스 자격 증명 값은 설정한 후에는 변경할 수 없고 역할 세션에서 수행되는 추가 작업에 대해 유지됩니다. 세션 태그와 역할 세션 이름을 사용하는 방법은 다음과 같습니다.

세션 태그 - 역할을 수임하거나 사용자를 페더레이션할 때 세션 태그를 전달할 수 있습니다. 세션 태그는 역할을 수임할 때 표시됩니다. 태그 조건 키를 사용하여 해당 태그를 기반으로 보안 주체에 권한을 부여하는 정책을 정의할 수 있습니다. 그런 다음 CloudTrail을 사용하여 역할을 수임하거나 사용자를 페더레이션하기 위한 요청을 볼 수 있습니다. 세션 태그에 대한 자세한 내용은 AWS STS에서 세션 태그 전달 섹션을 참조하세요.
역할 세션 이름 - 역할 신뢰 정책에서 sts:RoleSessionName 조건 키를 사용하여 사용자가 역할을 수임할 때 특정 세션 이름을 제공하도록 요구할 수 있습니다. 여러 보안 주체가 한 역할을 사용할 때 역할 세션 간을 구분하기 위해 역할 세션 이름을 사용할 수 있습니다. 역할 세션 이름에 대한 자세한 내용은 sts:RoleSessionName을 참조하세요.

역할을 수임하는 자격 증명을 제어하려는 경우 소스 자격 증명을 사용하는 것이 좋습니다. 또한 소스 자격 증명은 CloudTrail 로그를 마이닝하여 누가 역할을 사용하여 작업을 수행했는지 확인하는 데에도 유용합니다.

소스 자격 증명을 사용하도록 설정

소스 자격 증명을 사용하도록 설정하는 방법은 역할을 수임할 때 사용하는 방법에 따라 다릅니다. 예를 들어 IAM 사용자는 AssumeRole 작업을 사용하여 역할을 수임할 수 있습니다. 엔터프라이즈 자격 증명(인력 자격 증명이라고도 함)이 있으면 AssumeRoleWithSAML을 사용하여 AWS 리소스에 액세스할 수 있습니다. 최종 사용자가 모바일 또는 웹 애플리케이션에 액세스하는 경우 AssumeRoleWithWebIdentity를 사용하여 설정할 수 있습니다. 다음은 기존 환경에서 소스 자격 증명 정보를 활용하도록 설정하는 방법을 이해하는 데 도움이 되는 간략한 작업 흐름의 개요입니다.

테스트 사용자 및 역할 구성 - 프로덕션 이전 환경을 사용하여 테스트 사용자 및 역할을 구성하고 소스 자격 증명을 설정할 수 있도록 정책을 구성합니다.

페더레이션 자격 증명을 위해 자격 증명 공급자(IdP)를 사용하는 경우 어설션 또는 토큰으로 원하는 소스 자격 증명의 사용자 속성을 전달하도록 IdP를 구성합니다.
역할 수임 - 테스트를 위해 설정한 사용자와 역할을 사용하여 역할 수임과 소스 자격 증명 전달을 테스트합니다.
CloudTrail 검토 - CloudTrail 로그에서 테스트 역할의 소스 자격 증명 정보를 검토합니다.
사용자 교육 - 프로덕션 이전 환경에서 테스트한 후에는 필요한 경우 소스 자격 증명 정보를 전달하는 방법을 사용자에게 알려야 합니다. 사용자가 프로덕션 환경에서 소스 자격 증명을 제공해야 하는 시기의 기한을 설정합니다.
프로덕션 정책 구성 - 프로덕션 환경의 정책을 구성한 다음 프로덕션 사용자 및 역할에 추가합니다.
활동 모니터링 - CloudTrail 로그를 사용하여 프로덕션 역할 활동을 모니터링합니다.

소스 자격 증명에 대해 알아야 할 사항

소스 자격 증명 사용 시 다음 사항에 유의하세요.

자격 증명 공급자(IdP)에 연결된 모든 역할에 대한 역할 신뢰 정책에 sts:SetSourceIdentity 권한이 있어야 합니다. 역할 신뢰 정책에 이 권한이 없는 역할의 경우 AssumeRole* 작업이 실패합니다. 각 역할에 대한 역할 신뢰 정책을 업데이트하지 않으려는 경우 소스 자격 증명을 전달하는 데 개별 IdP 인스턴스를 사용할 수 있습니다. 그런 다음 개별 IdP에 연결된 역할에만 sts:SetSourceIdentity 권한을 추가합니다.
자격 증명이 소스 자격 증명을 설정하는 경우 sts:SourceIdentity 키가 요청에 있습니다. 역할 세션 중에 수행된 후속 작업의 경우 aws:SourceIdentity 키가 요청에 있습니다. AWS에서는 sts:SourceIdentity 또는 aws:SourceIdentity 키에 있는 소스 자격 증명 값을 제어하지 않습니다. 소스 자격 증명을 요구하도록 선택한 경우 사용자 또는 IIdP에서 제공할 속성을 선택해야 합니다. 보안을 위해 이러한 값이 제공되는 방식을 제어할 수 있어야 합니다.
소스 자격 증명의 값은 2~64자여야 하며 영숫자, 밑줄 및 다음 문자만 포함할 수 있습니다. . , + = @ -(하이픈). aws: 텍스트로 시작하는 값은 사용할 수 없습니다. 이 접두사는 AWS 내부 전용으로 예약되어 있습니다.
AWS 서비스 또는 서비스 연결 역할이 페더레이션 또는 인력 자격 증명 대신 작업을 수행하는 경우에는 소스 자격 증명 정보가 CloudTrail에 의해 캡처되지 않습니다.

중요

역할을 수임할 때 소스 자격 증명을 설정해야 하는 역할로는 AWS Management Console에서 전환할 수 없습니다. 이러한 역할을 수임하려면 AWS CLI 또는 AWS API를 사용하여 AssumeRole 작업을 호출하고 소스 자격 증명 파라미터를 지정할 수 있습니다.

소스 자격 증명 설정에 필요한 권한

API 작업과 일치하는 작업 외에도 정책에는 다음과 같은 권한 전용 작업이 있어야 합니다.


sts:SetSourceIdentity

소스 자격 증명을 지정하려면 보안 주체(IAM 사용자 및 역할)에 sts:SetSourceIdentity에 대한 권한이 있어야 합니다. 관리자는 역할 신뢰 정책과 보안 주체의 사용 권한 정책에서 이를 구성할 수 있습니다.
다른 역할이 있는 역할을 수임할 때(역할 체인이라고 함) 역할을 맡는 보안 주체의 권한 정책 및 대상 역할을 역할 신뢰 정책 모두에서 sts:SetSourceIdentity에 대한 권한이 필요합니다. 그렇지 않으면 역할 수임 작업이 실패합니다.
소스 자격 증명을 사용하는 경우 IdP에 연결된 모든 역할에 대한 역할 신뢰 정책에 sts:SetSourceIdentity 권한이 있어야 합니다. 이 권한 없이 IdP에 연결된 모든 역할의 경우 AssumeRole* 작업이 실패합니다. 각 역할에 대한 역할 신뢰 정책을 업데이트하지 않으려는 경우 소스 자격 증명을 전달하는 데 개별 IdP 인스턴스를 사용하고 별도의 IdP에 연결된 역할에만 sts:SetSourceIdentity 권한을 추가할 수 있습니다.
계정 경계에 걸쳐 소스 자격 증명을 설정하려면 두 위치에 sts:SetSourceIdentity 권한을 포함해야 합니다. 원본 계정에 있는 보안 주체의 권한 정책과 대상 계정에 있는 역할의 역할 신뢰 정책에 있어야 합니다. 예를 들어 역할 체인을 통해 역할이 다른 계정의 역할을 수임하는 데 사용되는 경우 이렇게 해야 할 수 있습니다.

계정 관리자로서, 자기 계정의 IAM 사용자 DevUser가 동일한 계정의 Developer_Role을 수임하도록 허용하려 한다고 가정합니다. 하지만 사용자가 소스 자격 증명을 IAM 사용자 이름으로 설정한 경우에만 이 작업을 허용하려고 합니다. IAM 사용자에 다음 정책을 연결할 수 있습니다.

예 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 조건 키는 허용 가능한 소스 자격 증명 값을 정의합니다.

예 소스 자격 증명에 대한 역할 신뢰 정책의 예


{
  "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을 수임하려고 합니다.

예 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 작업을 사용할 수 있습니다. 다음 섹션에서는 각 작업에 소스 자격 증명을 사용하는 방법을 설명합니다. 임시 자격 증명의 일반적인 시나리오에 대한 자세한 내용은 임시 자격 증명과 관련된 일반적인 시나리오 섹션을 참조하세요.

AssumeRole에 소스 자격 증명 사용

AssumeRole 작업은 AWS 리소스에 액세스하는 데 사용할 수 있는 임시 자격 증명 세트를 반환합니다. IAM 사용자 또는 역할 자격 증명을 사용하여 AssumeRole을 호출할 수 있습니다. 역할을 수임하는 동안 소스 자격 증명을 전달하려면 -–source-identity AWS CLI 옵션 또는 SourceIdentity AWS API 파라미터를 사용합니다. 다음 예제에서는 AWS CLI를 사용하여 소스 자격 증명을 지정하는 방법을 보여줍니다.

예 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에 액세스할 수 있게 하기 섹션을 참조하세요. AWS CLI 또는 AWS API 액세스에 대한 자세한 내용은 SAML 2.0 연동 섹션을 참조하세요. Active Directory 사용자를 위한 SAML 연동을 설정하는 방법에 대한 튜토리얼은 AWS 보안 블로그의 Active Directory Federation Services(ADFS)를 사용한 AWS 페더레이션 인증을 참조하세요.

관리자는 회사 디렉터리의 멤버가 AWS STS AssumeRoleWithSAML 작업을 사용하여 AWS로 연동하도록 허용할 수 있습니다. 이렇게 하려면 다음 작업을 완료해야 합니다.

소스 자격 증명에 대해 SAML 속성을 설정하려면 Name 속성과 함께 Attribute 요소를 https://aws.amazon.com/SAML/Attributes/SourceIdentity로 설정합니다. AttributeValue 요소를 사용하여 소스 자격 증명 값을 지정합니다. 예를 들어, 다음 자격 증명 속성을 소스 자격 증명으로 전달한다고 가정합니다.

SourceIdentity:DiegoRamirez

이러한 속성을 전달하려면 SAML 어설션에 다음 요소를 포함합니다.

예 SAML 어설션의 코드 조각 예


<Attribute Name="https://aws.amazon.com/SAML/Attributes/SourceIdentity">
<AttributeValue>DiegoRamirez</AttributeValue>
</Attribute>

AssumeRoleWithWebIdentity에 소스 자격 증명 사용

AssumeRoleWithWebIdentity 작업을 호출하는 보안 주체는 OIDC(OpenID Connect) 호환 페더레이션을 사용하여 인증됩니다. 이 작업은 AWS 리소스에 액세스하는 데 사용할 수 있는 임시 자격 증명 세트를 반환합니다. AWS Management Console 액세스를 위해 OIDC 페더레이션을 사용하는 방법에 대한 자세한 내용은 OIDC 페더레이션 섹션을 참조하세요.

OpenID Connect(OIDC)에서 소스 자격 증명을 전달하려면 JSON 웹 토큰(JWT)에 소스 자격 증명을 포함시켜야 합니다. AssumeRoleWithWebIdentity 요청을 제출할 때 토큰의 https://aws.amazon.com/source_identity 네임스페이스에 소스 자격 증명을 포함합니다. OIDC 토큰 및 클레임에 대한 자세한 내용은 Amazon Cognito 개발자 안내서의 사용자 풀과 함께 토큰 사용을 참조하세요.

예를 들어, 다음의 디코딩된 JWT는 Admin 소스 자격 증명과 함께 AssumeRoleWithWebIdentity를 호출하는 데 사용되는 토큰입니다.

예 디코딩된 JSON 웹 토큰의 예


{
    "sub": "johndoe",
    "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 키가 요청에 표시됩니다. 소스 자격 증명이 설정된 후 aws:SourceIdentity 키는 역할 세션 중에 수행된 모든 후속 요청에 표시됩니다. 관리자는 소스 자격 증명의 존재 또는 속성의 값에 따라 AWS 작업을 수행할 조건부 권한 부여를 부여하는 정책을 작성할 수 있습니다.

개발자가 프로덕션 크리티컬 AWS 리소스에 쓰기 권한이 있는 중요한 역할을 수임하는 소스 자격 증명을 설정하도록 요구한다고 가정해 봅시다. 또한 AssumeRoleWithSAML을 사용하는 인력 자격 증명에 AWS 액세스 권한을 부여한다고 가정합니다. 수석 개발자 Saanvi 및 Diego만 역할에 액세스하게 만들고 싶기 때문에 역할에 대해 다음과 같은 신뢰 정책을 생성합니다.

예 소스 자격 증명에 대한 역할 신뢰 정책의 예(SAML)


{
  "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로 인증되는 경우의 역할 신뢰 정책은 다음과 같습니다.

예 소스 자격 증명에 대한 역할 신뢰 정책의 예(OIDC 공급자)


{
  "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로의 역할 체인에 사용됩니다. 역할이 계정 경계를 건너서 수임되고 있습니다. 따라서 sts:SetSourceIdentity 권한은 CriticalRole에 대한 권한 정책 및 CriticalRole_2에 대한 역할 신뢰 정책 모두에 대해 부여되어야 합니다.

예 CriticalRole에 대한 권한 정책 예


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AssumeRoleAndSetSourceIdentity",
      "Effect": "Allow",
      "Action": [
        "sts:AssumeRole",
        "sts:SetSourceIdentity"
      ],
      "Resource": "arn:aws:iam::222222222222:role/CriticalRole_2"
    }
  ]
}

계정 경계에 걸친 소스 자격 증명 설정을 보호하기 위해 다음 역할 신뢰 정책은 CriticalRole에 대한 역할 보안 주체만을 신뢰합니다.

예 CriticalRole_2에 대한 역할 신뢰 정책의 예제


{
  "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이 수임될 때 사용자가 다음과 같이 설정된 값과 다른 소스 자격 증명을 설정하려고 시도하면 역할 수임 요청이 거부됩니다.

예 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 호출 로깅 단원을 참조하세요.

예를 들어 사용자가 AWS STS AssumeRole 요청을 만들고 소스 자격 증명을 설정한다고 가정합니다. CloudTrail 로그에서 requestParameters 키에서 sourceIdentity 정보를 찾을 수 있습니다.

예 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 키에 표시됩니다.

예 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 로그 파일에 저장된 정보에 대한 자세한 내용은 AWS CloudTrail 사용 설명서의 CloudTrail 이벤트 참조를 참조하세요.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

AssumeRole API 작업에 대한 권한

GetFederationToken에 대한 권한