수임된 역할로 수행한 작업 모니터링·제어
수임된 역할로 수행한 작업 모니터링·제어 (Monitor and control actions taken with assumed roles)
IAM 역할은 권한이 할당된 IAM의 객체예요. IAM 아이덴티티나 AWS 밖의 아이덴티티로 그 역할을 수임하면, 역할에 할당된 권한을 가진 세션을 받아요.
출처: 문서
본문
AWS에서 작업을 수행할 때, 세션에 대한 정보는 계정 관리자가 모니터링할 수 있도록 AWS CloudTrail에 기록될 수 있어요. 관리자는 역할이 AWS에서 작업을 수행하는 사람이나 애플리케이션을 식별하는 커스텀 문자열을 전달하도록 요구하도록 역할을 구성할 수 있어요. 이 아이덴티티 정보는 AWS CloudTrail에 **소스 아이덴티티(source identity)**로 저장돼요. 관리자가 CloudTrail에서 활동을 검토할 때 소스 아이덴티티 정보를 보고 누가(또는 무엇이) 수임 역할 세션으로 작업을 수행했는지 확인할 수 있어요.
소스 아이덴티티가 설정된 후에는 역할 세션 동안 수행하는 어떤 AWS 작업의 요청에도 그 값이 존재해요. 설정된 값은 AWS CLI나 AWS API를 통해 역할이 다른 역할을 수임할 때(역할 체이닝, role chaining)도 유지돼요. 설정된 값은 역할 세션 동안 변경할 수 없어요.
관리자는 소스 아이덴티티의 존재나 값을 기반으로 세분화된 권한을 구성해서, 공유 역할로 수행되는 AWS 작업을 추가로 제어할 수 있어요. 소스 아이덴티티 속성을 사용할 수 있는지, 필수인지, 어떤 값을 사용할 수 있는지 결정할 수 있어요.
소스 아이덴티티를 사용하는 방식은 역할 세션 이름이나 세션 태그와 한 가지 중요한 점에서 달라요. 소스 아이덴티티 값은 설정된 후 변경할 수 없으며, 역할 세션으로 수행하는 추가 작업에도 유지돼요. 세션 태그와 역할 세션 이름은 이렇게 사용할 수 있어요.
- 세션 태그 — 역할을 수임하거나 사용자를 페더레이션할 때 세션 태그를 전달할 수 있어요. 역할을 수임하면 세션 태그가 존재해요. 태그 조건 키를 사용하는 정책을 정의해 프린시펄의 태그를 기반으로 권한을 부여할 수 있어요. 그런 다음 CloudTrail로 역할 수임·사용자 페더레이션에 사용된 요청을 볼 수 있어요. 세션 태그에 대해 더 알아보려면 AWS STS에서 세션 태그 전달을 참고하세요.
- 역할 세션 이름 — 역할 트러스트 정책에서
sts:RoleSessionName조건 키를 사용해, 사용자가 역할을 수임할 때 특정 세션 이름을 제공하도록 요구할 수 있어요. 역할 세션 이름은 역할이 다른 프린시펄에 의해 사용될 때 역할 세션을 구분하는 데 사용할 수 있어요. 역할 세션 이름에 대해 더 알아보려면sts:RoleSessionName을 참고하세요.
역할을 수임하는 아이덴티티를 제어하려면 소스 아이덴티티를 사용하길 권장해요. 소스 아이덴티티는 CloudTrail 로그를 분석해 누가 역할로 작업을 수행했는지 확인하는 데도 유용해요.
다루는 주제
- 소스 아이덴티티 사용 설정
- 소스 아이덴티티에 대해 알아야 할 사항
- 소스 아이덴티티 설정에 필요한 권한
- 역할 수임 시 소스 아이덴티티 지정
- AssumeRole과 함께 소스 아이덴티티 사용
- AssumeRoleWithSAML과 함께 소스 아이덴티티 사용
- AssumeRoleWithWebIdentity와 함께 소스 아이덴티티 사용
- 소스 아이덴티티 정보로 접근 제어
- CloudTrail에서 소스 아이덴티티 보기
소스 아이덴티티 사용 설정
소스 아이덴티티 사용을 설정하는 방식은 역할이 수임되는 방식에 따라 달라져요. 예를 들어 IAM 사용자가 AssumeRole 작업으로 직접 역할을 수임할 수 있어요. 엔터프라이즈 아이덴티티(워크포스 아이덴티티라고도 함)가 있다면 AssumeRoleWithSAML로 AWS 리소스에 접근할 수 있어요. 최종 사용자가 모바일·웹 애플리케이션에 접근한다면 AssumeRoleWithWebIdentity로 접근할 수 있어요. 다음은 기존 환경에서 소스 아이덴티티 정보를 활용하도록 설정하는 방법을 이해할 수 있는 높은 수준의 워크플로 개요예요.
- 테스트 사용자·역할 구성 — 사전 프로덕션 환경을 사용해 테스트 사용자와 역할을 구성하고, 소스 아이덴티티 설정을 허용하도록 정책을 구성해요.
- 페더레이션 아이덴티티에 IdP를 사용한다면, 어서션 또는 토큰의 소스 아이덴티티로 원하는 사용자 속성을 전달하도록 IdP를 구성해요.
- 역할 수임 — 테스트용으로 설정한 사용자·역할로 역할 수임과 소스 아이덴티티 전달을 테스트해요.
- CloudTrail 검토 — CloudTrail 로그에서 테스트 역할의 소스 아이덴티티 정보를 검토해요.
- 사용자 교육 — 사전 프로덕션 환경에서 테스트한 후, 필요시 사용자가 소스 아이덴티티 정보를 전달하는 방법을 알도록 보장해요. 프로덕션 환경에서 소스 아이덴티티를 요구할 시점의 기한을 설정해요.
- 프로덕션 정책 구성 — 프로덕션 환경용 정책을 구성한 뒤 프로덕션 사용자·역할에 추가해요.
- 활동 모니터링 — CloudTrail 로그로 프로덕션 역할 활동을 모니터링해요.
소스 아이덴티티에 대해 알아야 할 사항
소스 아이덴티티를 작업할 때 다음을 염두에 두세요.
- IdP에 연결된 모든 역할의 트러스트 정책에
sts:SetSourceIdentity권한이 있어야 해요. 역할 트러스트 정책에 이 권한이 없는 역할은AssumeRole*작업이 실패해요. 각 역할의 트러스트 정책을 갱신하고 싶지 않다면, 소스 아이덴티티 전달 전용으로 별도의 IdP 인스턴스를 사용할 수 있어요. 그리고sts:SetSourceIdentity권한을 그 별도 IdP에 연결된 역할에만 추가하면 돼요. - 아이덴티티가 소스 아이덴티티를 설정하면 요청에
sts:SourceIdentity키가 존재해요. 역할 세션 동안 수행하는 후속 작업에는 요청에aws:SourceIdentity키가 존재해요. AWS는sts:SourceIdentity또는aws:SourceIdentity키 어느 쪽의 소스 아이덴티티 값도 제어하지 않아요. 소스 아이덴티티를 요구하기로 선택했다면, 사용자나 IdP가 제공하길 원하는 속성을 선택해야 해요. 보안 목적으로 그 값이 어떻게 제공되는지 제어할 수 있어야 해요. - 소스 아이덴티티의 값은 길이가 2~256자여야 하며, 영숫자 문자, 밑줄, 그리고
. , + = @ -(하이픈) 문자만 포함할 수 있어요.aws:텍스트로 시작하는 값은 사용할 수 없어요. 이 접두사는 AWS 내부 사용용으로 예약되어 있어요. - AWS 서비스 또는 서비스 연결 역할이 페더레이션·워크포스 아이덴티티를 대신해 작업을 수행할 때는 소스 아이덴티티 정보가 CloudTrail에 캡처되지 않아요.
중요
AWS Management Console에서는, 수임 시 소스 아이덴티티 설정을 요구하는 역할로 전환할 수 없어요. 그런 역할을 수임하려면 AWS CLI나 AWS API로 AssumeRole 작업을 호출하고 source-identity 파라미터를 지정해야 해요.
소스 아이덴티티 설정에 필요한 권한
API 작업과 일치하는 작업 외에도 정책에 다음 권한 전용 작업이 있어야 해요.
sts:SetSourceIdentity
소스 아이덴티티를 지정하려면 프린시펄(IAM 사용자·역할)이 sts:SetSourceIdentity 권한이 있어야 해요. 관리자로서 이를 역할 트러스트 정책과 프린시펄의 권한 정책에서 구성할 수 있어요.
역할로 다른 역할을 수임할 때(역할 체이닝), sts:SetSourceIdentity 권한이 역할을 수임하는 프린시펄의 권한 정책과 대상 역할의 역할 트러스트 정책 둘 다에 필요해요. 그렇지 않으면 역할 수임 작업이 실패해요.
소스 아이덴티티를 사용할 때 IdP에 연결된 모든 역할의 역할 트러스트 정책에 sts:SetSourceIdentity 권한이 있어야 해요. 이 권한이 없는 IdP에 연결된 역할은 AssumeRole* 작업이 실패해요. 각 역할의 트러스트 정책을 갱신하고 싶지 않다면 소스 아이덴티티 전달 전용으로 별도의 IdP 인스턴스를 사용하고, sts:SetSourceIdentity 권한을 그 별도 IdP에 연결된 역할에만 추가하면 돼요.
계정 경계를 넘어 소스 아이덴티티를 설정하려면 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가 요청을 평가하면 요청 컨텍스트에 sts:SourceIdentity가 DevUser로 포함돼요.
역할 수임 시 소스 아이덴티티 지정
역할에 대한 임시 보안 자격 증명을 얻기 위해 AWS STS AssumeRole* API 작업 중 하나를 사용할 때 소스 아이덴티티를 지정할 수 있어요. 사용하는 API 작업은 사용 사례에 따라 달라져요.
예를 들어 IAM 역할로 IAM 사용자에게 평소엔 접근할 수 없는 AWS 리소스에 접근을 준다면 AssumeRole 작업을 쓸 수 있어요. 엔터프라이즈 아이덴티티 페더레이션으로 워크포스 사용자를 관리한다면 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 Security Blog의 Active Directory Federation Services(ADFS)를 통한 AWS 페더레이션 인증을 참고하세요.
관리자로서 회사 디렉터리 구성원이 AWS STS AssumeRoleWithSAML 작업으로 AWS에 페더레이션하도록 허용할 수 있어요. 그러려면 다음 작업을 완료해야 해요.
- 조직에 SAML 프로바이더 구성
- IAM에 SAML 프로바이더 생성
- AWS에서 SAML 페더레이션 프린시펄용 역할과 그 권한 구성
- SAML IdP 구성 마무리 및 SAML 인증 응답용 어서션 생성
소스 아이덴티티용 SAML 속성을 설정하려면 Name 속성이 https://aws.amazon.com/SAML/Attributes/SourceIdentity로 설정된 Attribute 요소를 포함해요. 소스 아이덴티티의 값을 지정하려면 AttributeValue 요소를 사용해요. 예를 들어 다음 아이덴티티 속성을 소스 아이덴티티로 전달한다고 해 보죠.
SourceIdentity:DiegoRamirez
이 속성을 전달하려면 SAML 어서션에 다음 요소를 포함해요.
SAML 어서션 스니펫 예시
<Attribute Name="https://aws.amazon.com/SAML/Attributes/SourceIdentity">
<AttributeValue>DiegoRamirez</AttributeValue>
</Attribute>
AssumeRoleWithWebIdentity와 함께 소스 아이덴티티 사용
AssumeRoleWithWebIdentity 작업을 호출하는 프린시펄은 OpenID Connect(OIDC) 호환 페더레이션으로 인증돼요. 이 작업은 AWS 리소스에 접근하는 데 쓸 수 있는 임시 자격 증명 집합을 반환해요. AWS Management Console 접근에 OIDC 페더레이션을 사용하는 방법은 OIDC 페더레이션을 참고하세요.
OpenID Connect(OIDC)에서 소스 아이덴티티를 전달하려면 JSON 웹 토큰(JWT)에 소스 아이덴티티를 포함해야 해요. AssumeRoleWithWebIdentity 요청을 보낼 때 토큰의 https://aws.amazon.com/source_identity 네임스페이스에 소스 아이덴티티를 포함해요. OIDC 토큰과 클레임에 대해 더 알아보려면 Amazon Cognito 개발자 가이드의 User Pools와 토큰 사용을 참고하세요.
예를 들어 다음 디코딩된 JWT는 Admin 소스 아이덴티티로 AssumeRoleWithWebIdentity를 호출하는 데 사용되는 토큰이에요.
디코딩된 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 키가 존재해요. 소스 아이덴티티가 설정된 후에는 역할 세션 동안 이루어지는 모든 후속 요청에 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://region-code.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 이벤트 참조를 참고하세요.
더 알아보기 (Learn more)
- 임시 보안 자격 증명의 권한 — 임시 자격 증명 권한 주제 모음을 확인해 보세요.
- AWS STS에서 세션 태그 전달 — 세션 태그의 개념을 살펴보세요.
- 임시 보안 자격 증명 요청 — 자격 증명 요청 방법을 참고하세요.