# 引き受けたロールで実行されるアクションのモニタリングと制御
[IAM ロール](id_roles.md)は、[アクセス許可](access_policies.md)が割り当てられている IAM 内のオブジェクトです。IAM IDまたは AWS の外部からのIDを使用して[そのロールを引き受ける](id_roles_manage-assume.md)と、ロールに割り当てられたアクセス許可を持つセッションを受け取ります。
AWS でアクションを実行すると、セッションに関する情報を AWS CloudTrail にログ記録して、アカウント管理者がモニタリングできるようになります。管理者は、AWS でアクションを実行する個人またはアプリケーションを識別するカスタム文字列を渡すように ID を要求するようにロールを設定できます。この ID 情報は、*ソース ID* として AWS CloudTrail に保存されます。管理者は CloudTrail のアクティビティを確認すると、ソース ID 情報を表示して、引き受けたロールセッションでアクションを実行したユーザーやアクションを判断できます。
ソースIDが設定されると、ロールセッション中に実行されるすべての AWS アクションの要求に存在します。設定された値は、ロールが AWS CLI または AWS APIを介して別のロールを引き受けるために使用される場合、[ロール連鎖](id_roles.md#iam-term-role-chaining)と呼ばれます。設定される値は、ロールセッション中に変更できません。管理者は、ソース ID の存在または値に基づいて詳細なアクセス許可を構成して、共有ロールで実行される AWS アクションをさらに制御できます。ソース ID 属性を使用できるかどうか、必須かどうか、どの値を使用できるかを決定できます。
ソース ID の使用方法は、ロールセッション名およびセッションタグとは重要な点で異なります。ソース ID 値は、設定後は変更できません。また、ロールセッションで実行される追加のアクションでも保持されます。セッションタグとロールセッション名の使用方法は次のとおりです。
+ **セッションタグ** – ロールを引き受けるとき、またはユーザーをフェデレートするときに セッションタグ を渡すこともできます。セッションタグは、ロールを引き受けるときに存在します。タグ条件キーを使用して、タグに基づいてプリンシパルにアクセス許可を付与するポリシーを定義できます。次に、CloudTrail を使用して、ロールを引き受けるか、ユーザーをフェデレートするために行われたリクエストを表示できます。セッションタグの詳細については、「[AWS STS でセッションタグを渡します](id_session-tags.md)」を参照してください。
+ **ロールセッション名** – ロール信頼ポリシーで `sts:RoleSessionName` 条件キーを使用して、ユーザーがロールを引き受けるときに特定のセッション名を提供するように要求できます。ロールセッション名は、ロールが異なるプリンシパルによって使用される場合に、ロールセッションを区別するために使用できます。ロールセッション名の詳細については、「[sts:RoleSessionName](reference_policies_iam-condition-keys.md#ck_rolesessionname)」を参照してください。。
ロールを引き受ける ID を制御する場合は、ソース ID を使用することをお勧めします。ソースアイデンティティは、CloudTrail ログをマイニングして、アクションを実行するためにロールを使用したユーザーを特定する場合にも役立ちます。
**Topics**
+ [ソース ID を使用するための設定](#id_credentials_temp_control-access_monitor-setup)
+ [ソースアイデンティティについて知っておくべきこと](#id_credentials_temp_control-access_monitor-know)
+ [ソース ID を設定するために必要なアクセス許可](#id_credentials_temp_control-access_monitor-perms)
+ [ロールを引き受けるときのソース ID の指定](#id_credentials_temp_control-access_monitor-specify-sourceid)
+ [AssumeRole でのソース ID の使用](#id_credentials_temp_control-access_monitor-assume-role)
+ [AssumeRoleWithSAML を使用したソース ID の使用](#id_credentials_temp_control-access_monitor-assume-role-saml)
+ [AssumeRoleWithWebIdentity によるソース ID の使用](#id_credentials_temp_control-access_monitor-assume-role-web-id)
+ [ソース ID 情報を使用してアクセスを制御する](#id_credentials_temp_control-access_monitor-control-access)
+ [CloudTrail でのソースアイデンティティの表示](#id_credentials_temp_control-access_monitor-ct)
## ソース ID を使用するための設定
ソース ID を使用するように設定する方法は、ロールを引き受けるときに使用される方法によって異なります。例えば、IAMユーザーは、`AssumeRole` オペレーションを直接使用してロールを引き受ける場合があります。エンタープライズ ID (ワークフォースIDとも呼ばれる) がある場合、AWS を使用して `AssumeRoleWithSAML` リソースにアクセスする可能性があります。エンドユーザーがモバイルまたはWebアプリケーションにアクセスする場合、`AssumeRoleWithWebIdentity` を使用してアクセスする可能性があります。次に、既存の環境でソース ID 情報を利用するためのを設定する方法を理解するのに役立つ概要のワークフローの概要を示します。
1. **テストユーザーおよびロールの構成** — 運用前環境を使用して、テストユーザーおよびロールを構成し、ソースアイデンティティを設定できるようにポリシーを構成します。
フェデレーション ID に ID プロバイダー (IdP) を使用する場合は、アサーションまたはトークンでソース ID に選択したユーザー属性を渡すように IdP を設定します。
1. **ロールを引き受けるには** – ロールを想定し、テスト用に設定したユーザーとロールにソース ID を渡します。
1. **CloudTrail の確認** — CloudTrail ログでテストロールのソース ID 情報を確認します。
1. **ユーザーのトレーニング** — 運用前の環境でテストした後、必要に応じて、ソース ID 情報を渡す方法をユーザーが把握していることを確認します。本番環境でソース ID の提供をユーザーに要求する期限を設定します。
1. **本番ポリシーの設定**：本番環境のポリシーを構成し、本番ユーザーおよびロールに追加します。
1. **アクティビティのモニタリング**— CloudTrail ログを使用して、本番ロールのアクティビティをモニタリングします。
## ソースアイデンティティについて知っておくべきこと
ソース ID を使用する際には、次の点に注意してください。
+ ID プロバイダー (IdP) に接続されているすべてのロールの信頼ポリシーに `sts:SetSourceIdentity` アクセス許可が必要です。ロール信頼ポリシーでこのアクセス許可を持たないロールの場合、`AssumeRole*` オペレーションは失敗します。各ロールのロール信頼ポリシーを更新しない場合は、ソース ID を渡すために個別の IdP インスタンスを使用できます。その後、個別の IdP に接続されているロールにのみ `sts:SetSourceIdentity` アクセス許可を追加します。
+ アイデンティティーがソースアイデンティティを設定する場合、`sts:SourceIdentity` キーはリクエストに存在します。ロールセッション中に実行される後続のアクションでは、`aws:SourceIdentity` キーがリクエストに存在します。AWS は、`sts:SourceIdentity` または `aws:SourceIdentity` キーのソース ID の値を制御しません。ソース ID を要求する場合は、ユーザーまたは IdP に提供する属性を選択する必要があります。セキュリティ上の理由から、これらの値の提供方法を制御できることを確認する必要があります。
+ ソース ID の値は、2 〜 64 文字の長さである必要があり、英数字、アンダースコア、および 、**. , \$1 = @ -**(ハイフン) のみを含めることができます。テキスト **aws:** から開始するタグキーや値を作成することはできません。このプレフィックスは AWS の内部使用のために予約されています。
+ AWS サービスまたはサービスにリンクされたロールがフェデレーション ID またはワーカー ID に代わってアクションを実行する場合、ソース ID 情報は CloudTrail によってキャプチャされません。
**重要**
AWS マネジメントコンソール でロールを切り替えるには、ロールを引き受けるときにソース ID を設定する必要があります。このようなロールを引き受けるには、AWS CLI または AWS API を呼び出して `AssumeRole` オペレーションを実行し、ソース ID パラメーターを指定します。
## ソース ID を設定するために必要なアクセス許可
API オペレーションに一致するアクションに加えて、ポリシーには次のアクセス許可のみのアクションが必要です。
```
sts:SetSourceIdentity
```
+ ソース ID を指定するには、プリンシパル (IAM ユーザーとロール) に `sts:SetSourceIdentity` へのアクセス許可が必要です。管理者は、ロールの信頼ポリシーとプリンシパルのアクセス許可ポリシーでこれを設定できます。
+ 別のロールでロールを引き受ける場合、[ロールの連鎖](id_roles.md#iam-term-role-chaining)と呼ばれるアクセス許可 `sts:SetSourceIdentity` は、ロールを引き受けるプリンシパルのアクセス許可ポリシーと、ターゲットロールのロール信頼ポリシーの両方で必要です。そうしない場合、ロールの引き受け操作は失敗します。
+ ソース ID を使用している場合、ID プロバイダー (IdP) に接続されているすべてのロールの信頼ポリシーに `sts:SetSourceIdentity` アクセス許可が必要です。このアクセス許可なしで IdP に接続されているロールでは、`AssumeRole*` オペレーションは失敗します。各ロールのロール信頼ポリシーを更新しない場合は、ソース ID を渡すために個別の IdP インスタンスを使用し、`sts:SetSourceIdentity` アクセス許可は、個別の IdP に接続されているロールにのみ付与されます。
+ アカウントの境界を越えてソースIDを設定するには、2 箇所に `sts:SetSourceIdentity` アクセス許可を含める必要があります。これは、元のアカウントのプリンシパルのアクセス許可ポリシーと、ターゲットアカウントのロールのロール信頼ポリシーにある必要があります。例えば、ロールが[ロールの連鎖](id_roles.md#iam-term-role-chaining)を使用して別のアカウントでロールを引き受けるために使用される場合、これを行う必要がある場合があります。
アカウント管理者として、アカウントの IAM ユーザー`DevUser`が同じアカウントの `Developer_Role` を引き継ぐことを許可したいとします。ただし、ユーザーがソース ID を自分の IAM ユーザー名に設定している場合にのみ、このアクションを許可します。その場合、IAM ユーザーに以下のポリシーをアタッチできます。
**Example DevUser にアタッチされた ID ベースのポリシーの例**
****
```
{
"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}"
}
}
}
]
}
```
許容可能なソース ID 値を適用するには、次のロール信頼ポリシーを設定します。このポリシーは、IAM ユーザー `DevUser` にロールを引き受けてソースIDを設定するためのアクセス許可を与えます。`sts:SourceIdentity`条件キーは、許容可能なソース ID 値を定義します。
**Example ソース ID のロール信頼ポリシーの例**
------
#### [ 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` の認証情報を使用して、次の `DeveloperRole` リクエストを使用して、AWS CLI を受け入れようとしています。
**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 がリクエストを評価するとき、リクエストコンテキストには `sts:SourceIdentity` の `DevUser` が含まれます。
## ロールを引き受けるときのソース ID の指定
AWS STS `AssumeRole*` API操作の1つを使用してロールの一時的なセキュリティクレデンシャルを取得するときに、ソースIDを指定できます。使用する API オペレーションは、ユースケースによって異なります。例えば、IAMロールを使用して、IAMユーザーに通常はアクセスできない AWS リソースへのアクセスを許可する場合は、`AssumeRole` オペレーションを使用できます。エンタープライズ ID フェデレーションを使用してワークフォースユーザーを管理する場合は、この `AssumeRoleWithSAML` オペレーションを使用できます。OIDC フェデレーションを使用して、エンドユーザーがモバイルまたはウェブアプリケーションにアクセスできるようにする場合は、`AssumeRoleWithWebIdentity` オペレーションを使用できます。このセクションでは、オペレーションごとにソース ID を使用する方法について説明します。一時的な認証情報の一般的なシナリオの詳細については、「[一時的な認証情報の一般的なシナリオ](id_credentials_temp.md#sts-introduction)」を参照してください。。
## AssumeRole でのソース ID の使用
`AssumeRole` オペレーションは、AWS リソースへのアクセスに使用できる一時的な認証情報のセットを返します。IAM ユーザーまたはロールの認証情報を使用して `AssumeRole` を呼び出すことができます。ロールを引き受けるときにセッションタグを渡すには、`-–source-identity` AWS CLI オプションまたは `SourceIdentity` AWS API パラメータを使用します。次の例は、AWS CLI を使用してソースIDを指定する方法を示しています。
**Example AssumeRole CLI リクエストの例**
```
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/developer \
--role-session-name Audit \
--source-identity Admin \
```
## AssumeRoleWithSAML を使用したソース ID の使用
`AssumeRoleWithSAML` オペレーションを呼び出すプリンシパルは、SAMLベースのフェデレーションを使用して認証されます。このオペレーションは、AWS リソースへのアクセスに使用できる一時的な認証情報のセットを返します。SAML ベースのフェデレーションを使用して AWS マネジメントコンソール にアクセスする方法の詳細については、「[SAML 2.0 フェデレーティッドプリンシパルを有効にして AWS マネジメントコンソール にアクセス](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 フェデレーションサービスを使用した AWS フェデレーション認証 (ADFS)](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)
ソース ID の SAML 属性を設定するには、`Attribute` 属性が `Name` に設定されている `https://aws.amazon.com/SAML/Attributes/SourceIdentity` 要素を含めます。`AttributeValue` 要素を使用して、ソース ID の値を指定します。例えば、次の ID 属性をソース ID として渡すとします。
`SourceIdentity:DiegoRamirez`
これらの属性を渡すには、SAML アサーションに以下の要素を含めます。
**Example SAML アサーションのスニペットの例**
```
DiegoRamirez
```
## AssumeRoleWithWebIdentity によるソース ID の使用
`AssumeRoleWithWebIdentity` オペレーションを呼び出すプリンシパルは、OpenID Connect (OIDC) 準拠のフェデレーションを使用して認証されます。このオペレーションは、AWS リソースへのアクセスに使用できる一時的な認証情報のセットを返します。AWS マネジメントコンソール アクセスに OIDC フェデレーションを使用する方法の詳細については、「[OIDC フェデレーション](id_roles_providers_oidc.md)」を参照してください。
OpenID Connect (OIDC) からソース ID を渡すには、JSON ウェブトークン (JWT) にソース ID を含める必要があります。`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 は、`AssumeRoleWithWebIdentity` ソースIDで `Admin` を呼び出すために使用されるトークンです。
**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"
}
```
## ソース ID 情報を使用してアクセスを制御する
ソース ID が最初に設定されると、[sts:SourceIdentity](reference_policies_iam-condition-keys.md#ck_sourceidentity)キーがリクエストに存在します。ソース ID が設定されると、[aws:SourceIdentity](reference_policies_condition-keys.md#condition-keys-sourceidentity)キーは、ロールセッション中に行われた後続のすべての要求に存在します。管理者は、ソース ID 属性の存在または値に基づいて AWS アクションを実行するための条件付き承認を付与するポリシーを作成できます。
開発者にソースIDを設定して、本番環境の重要な AWS リソースへの書き込み権限を持つ重要なロールを引き受けるようにリクエストするとします。また、AWS を使用してワークフォース ID への `AssumeRoleWithSAML` アクセスを許可するとします。上級開発者の Saanvi と Diego にロールへのアクセス権のみを与えるため、ロールに対して次の信頼ポリシーを作成します。
**Example ソース ID のロール信頼ポリシーの例 (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 のソース ID を必要とする、`sts:SourceIdentity` の条件が含まれています。
または、OIDC フェデレーションに OIDC プロバイダーを使用していて、`AssumeRoleWithWebIdentity` によってユーザーが認証される場合、信頼ポリシーは次のようになります。
**Example ソース ID のロール信頼ポリシーの例 (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`は、[ロールの連鎖](id_roles.md#iam-term-role-chaining)を 2 番目のロール、`CriticalRole_2`別のアカウントで。ロールは、アカウントの境界を越えて引き継がれています。したがって、`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"
}
]
}
```
------
アカウントの境界を越えてソースIDの設定を保護するために、次のロール信頼ポリシーは、`CriticalRole` のロールプリンシパルのみを信頼してソース ID を設定します。
**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 を引き受けることで取得したロールセッション資格情報を使用して、次の呼び出しを行います。ソース ID は、CriticalRole の仮定時に設定されているので、明示的に再度設定する必要はありません。ユーザーがソース ID を設定しようとした場合、`CriticalRole` が想定された場合、ロールの引き受けリクエストは拒否されます。
**Example AssumeRole CLI リクエストの例**
```
aws sts assume-role \
--role-arn arn:aws:iam::222222222222:role/CriticalRole_2 \
--role-session-name Audit \
```
呼び出し元プリンシパルがロールを引き受けると、リクエスト内のソース ID は、最初に引き受けたロールセッションから保持されます。したがって、`aws:SourceIdentity` キー と `sts:SourceIdentity` キーの両方がリクエストコンテキストに存在します
## CloudTrail でのソースアイデンティティの表示
CloudTrail を使用して、ロールを引き受けるか、ユーザーをフェデレートするために行われたリクエストを表示できます。AWS でアクションを実行するための役割またはユーザーのリクエストを表示することもできます。CloudTrail ログファイルには、引き受けたロールまたはフェデレーティッドユーザーセッションのプリンシパルタグに関する情報が含まれます。詳細については、[AWS CloudTrail による IAM および AWS STS の API コールのログ記録](cloudtrail-integration.md)を参照してください。
例えば、ユーザーが AWS STS `AssumeRole` リクエストを行い、ソースIDを設定するとします。`sourceIdentity` 情報は、CloudTrail ログの `requestParameters` キーで見つけることができます。
**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"
}
```
ユーザーが引き受けたロールセッションを使用してアクションを実行する場合、ソース ID 情報は `userIdentity` キーを CloudTrail ログに追加します。
**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"
}
}
}
```
AWS STS CloudTrail ログの API イベントの例を見るには、「[CloudTrail ログの IAM API イベントの例](cloudtrail-integration.md#cloudtrail-integration_examples-iam-api)」を参照してください。CloudTrail ログファイルに含まれる情報の詳細については、[AWS CloudTrail ユーザーガイド](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/eventreference.html) の「*CloudTrail イベントリファレンス*」を参照してください。