引き受けたロールで実行されるアクションのモニタリングと制御 - AWS Identity and Access Management

引き受けたロールで実行されるアクションのモニタリングと制御

IAM ロールは、アクセス許可が割り当てられている IAM 内のオブジェクトです。IAM IDまたは AWS の外部からのIDを使用してそのロールを引き受けると、ロールに割り当てられたアクセス許可を持つセッションを受け取ります。

AWS でアクションを実行すると、セッションに関する情報を AWS CloudTrail に記録して、アカウント管理者が監視できるようになります。管理者は、AWS でアクションを実行する個人またはアプリケーションを識別するカスタム文字列を渡すように ID を要求するようにロールを設定できます。この ID 情報は、ソース ID として AWS CloudTrail に保存されます。管理者は CloudTrail のアクティビティを確認すると、ソース ID 情報を表示して、引き受けたロールセッションでアクションを実行したユーザーやアクションを判断できます。

ソースIDが設定されると、ロールセッション中に実行されるすべての AWS アクションの要求に存在します。設定された値は、ロールが AWS CLI または AWS APIを介して別のロールを引き受けるために使用される場合、ロール連鎖と呼ばれます。設定される値は、ロールセッション中に変更できません。管理者は、ソース ID の存在または値に基づいて詳細なアクセス許可を構成して、共有ロールで実行される AWS アクションをさらに制御できます。ソース ID 属性を使用できるかどうか、必須かどうか、どの値を使用できるかを決定できます。

ソース ID の使用方法は、ロールセッション名およびセッションタグとは重要な点で異なります。ソース ID 値は、設定後は変更できません。また、ロールセッションで実行される追加のアクションでも保持されます。セッションタグとロールセッション名の使用方法は次のとおりです。

  • セッションタグ – ロールを引き受けるとき、またはユーザーをフェデレートするときに セッションタグ を渡すこともできます。セッションタグは、ロールを引き受けるときに存在します。タグ条件キーを使用して、タグに基づいてプリンシパルにアクセス許可を付与するポリシーを定義できます。次に、CloudTrail を使用して、ロールを引き受けるか、ユーザーをフェデレートするために行われたリクエストを表示できます。セッションタグの詳細については、「AWS STS でのセッションタグの受け渡し」を参照してください。

  • ロールセッション名 – ロール信頼ポリシーで sts:RoleSessionName 条件キーを使用して、ユーザーがロールを引き受けるときに特定のセッション名を提供するように要求できます。ロールセッション名は、ロールが異なるプリンシパルによって使用される場合に、ロールセッションを区別するために使用できます。ロールセッション名の詳細については、「sts:RoleSessionName」を参照してください。。

ロールを引き受ける ID を制御する場合は、ソース ID を使用することをお勧めします。ソースアイデンティティは、CloudTrail ログをマイニングして、アクションを実行するためにロールを使用したユーザーを特定する場合にも役立ちます。

ソース ID を使用するための設定

ソース ID を使用するように設定する方法は、ロールを引き受けるときに使用される方法によって異なります。たとえば、IAMユーザーは、AssumeRole オペレーションを直接使用してロールを引き受ける場合があります。エンタープライズ ID (ワークフォースIDとも呼ばれる) がある場合、AWS を使用して AssumeRoleWithSAML リソースにアクセスする可能性があります。エンドユーザーがモバイルまたはWebアプリケーションにアクセスする場合、AssumeRoleWithWebIdentity を使用してアクセスする可能性があります。次に、既存の環境でソース ID 情報を利用するためのを設定する方法を理解するのに役立つ概要のワークフローの概要を示します。

  1. テストユーザーおよびロールの構成 — 運用前環境を使用して、テストユーザーおよびロールを構成し、ソースアイデンティティを設定できるようにポリシーを構成します。

    フェデレーション ID に ID プロバイダー (IdP) を使用する場合は、アサーションまたはトークンでソース ID に選択したユーザー属性を渡すように IdP を設定します。

  2. ロールを引き受けるには – ロールを想定し、テスト用に設定したユーザーとロールにソース ID を渡します。

  3. CloudTrail の確認 — CloudTrail ログでテストロールのソース ID 情報を確認します。

  4. ユーザーのトレーニング — 運用前の環境でテストした後、必要に応じて、ソース ID 情報を渡す方法をユーザーが把握していることを確認します。本番環境でソース ID の提供をユーザーに要求する期限を設定します。

  5. 本番ポリシーの設定:本番環境のポリシーを構成し、本番ユーザーおよびロールに追加します。

  6. アクティビティのモニタリング— 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 文字の長さである必要があり、英数字、アンダースコア、および 、. , + = @ -(ハイフン) のみを含めることができます。テキスト aws: から開始するタグキーや値を作成することはできません。このプレフィックスは AWS の内部使用のために予約されています。

  • AWS サービスまたはサービスにリンクされたロールがフェデレーション ID またはワーカー ID に代わってアクションを実行する場合、ソース ID 情報は CloudTrail によってキャプチャされません。

重要

AWS Management Console でロールを切り替えるには、ロールを引き受けるときにソース ID を設定する必要があります。このようなロールを引き受けるには、AWS CLI または AWS API を呼び出して AssumeRole オペレーションを実行し、ソース ID パラメーターを指定します。

ソース ID を設定するために必要なアクセス許可

API オペレーションに一致するアクションに加えて、ポリシーには次のアクセス許可のみのアクションが必要です。

sts:SetSourceIdentity
  • ソース ID を指定するには、プリンシパル (IAM ユーザーとロール) に sts:SetSourceIdentity へのアクセス許可が必要です。管理者は、ロールの信頼ポリシーとプリンシパルのアクセス許可ポリシーでこれを設定できます。

  • 別のロールでロールを引き受ける場合、ロールの連鎖アクセス許可sts:SetSourceIdentityは、ロールを引き受けるプリンシパルのアクセス許可ポリシーと、ターゲットロールのロール信頼ポリシーの両方で必要です。そうしない場合、ロールの引き受け操作は失敗します。

  • ソース ID を使用している場合、ID プロバイダー (IdP) に接続されているすべてのロールの信頼ポリシーに sts:SetSourceIdentity アクセス許可が必要です。このアクセス許可なしで IdP に接続されているロールでは、AssumeRole* オペレーションは失敗します。各ロールのロール信頼ポリシーを更新しない場合は、ソース ID を渡すために個別の IdP インスタンスを使用し、sts:SetSourceIdentity アクセス許可は、個別の IdP に接続されているロールにのみ付与されます。

  • アカウントの境界を越えてソースIDを設定するには、2 箇所に sts:SetSourceIdentity アクセス許可を含める必要があります。これは、元のアカウントのプリンシパルのアクセス許可ポリシーと、ターゲットアカウントのロールのロール信頼ポリシーにある必要があります。たとえば、ロールがロールの連鎖を使用して別のアカウントでロールを引き受けるために使用される場合、これを行う必要がある場合があります。

アカウント管理者として、アカウントの IAM ユーザーDevUserが同じアカウントの Developer_Role を引き継ぐことを許可したいとします。ただし、ユーザーがソース ID を自分の IAM ユーザー名に設定している場合にのみ、このアクションを許可します。その場合、IAM ユーザーに以下のポリシーをアタッチできます。

例 DevUser にアタッチされた ID ベースのポリシーの例

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AssumeRole", "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::123456789012:role/Developer_Role" }, { "Sid": "Set_AWSUserName_as_SourceIdentity", "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 値を定義します。

例 ソース ID のロール信頼ポリシーの例

{ "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 を受け入れようとしています。

例 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:SourceIdentityDevUser が含まれます。

ロールを引き受けるときのソース ID の指定

AWS STS AssumeRole* API操作の1つを使用してロールの一時的なセキュリティクレデンシャルを取得するときに、ソースIDを指定できます。使用する API オペレーションは、ユースケースによって異なります。たとえば、IAMロールを使用して、IAMユーザーに通常はアクセスできない AWS リソースへのアクセスを許可する場合は、AssumeRole オペレーションを使用できます。エンタープライズ ID フェデレーションを使用してワークフォースユーザーを管理する場合は、この AssumeRoleWithSAML オペレーションを使用できます。Web IDフェデレーションを使用して、エンドユーザーがモバイルまたはWebアプリケーションにアクセスできるようにする場合は、AssumeRoleWithWebIdentity オペレーションを使用できます。このセクションでは、オペレーションごとにソース ID を使用する方法について説明します。一時的な認証情報の一般的なシナリオの詳細については、「一時的な認証情報の一般的なシナリオ」を参照してください。。

AssumeRole でのソース ID の使用

AssumeRole オペレーションは、AWS リソースへのアクセスに使用できる一時的な認証情報のセットを返します。IAM ユーザーまたはロールの認証情報を使用して AssumeRole を呼び出すことができます。ロールを引き受けるときにセッションタグを渡すには、-–source-identity AWS CLI オプションまたは SourceIdentity AWS API パラメータを使用します。次の例は、AWS CLI を使用してソースIDを指定する方法を示しています。

例 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 Management Console にアクセスする方法の詳細については、「SAML 2.0 フェデレーティッドユーザーが AWS Management Consoleにアクセス可能にする」を参照してください。AWS CLI または AWS API アクセスの詳細については、「SAML 2.0 ベースのフェデレーションについて」を参照してください。Active Directory ユーザーの SAML フェデレーションを設定するチュートリアルについては、AWS セキュリティブログの「Active Directory フェデレーションサービスを使用した AWS フェデレーション認証 (ADFS)」を参照してください。

管理者は、企業ディレクトリのメンバーに AWS AWS STS オペレーションを使用しての AssumeRoleWithSAML フェデレーションを許可できます。これを行うには、以下のタスクを完了する必要があります。

ソース ID の SAML 属性を設定するには、Attribute 属性が Name に設定されている https://aws.amazon.com/SAML/Attributes/SourceIdentity 要素を含めます。AttributeValue 要素を使用して、ソース ID の値を指定します。たとえば、次の ID 属性をソース ID として渡すとします。

SourceIdentity:DiegoRamirez

これらの属性を渡すには、SAML アサーションに以下の要素を含めます。

例 SAML アサーションのスニペットの例

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

AssumeRoleWithWebIdentity によるソース ID の使用

AssumeRoleWithWebIdentity オペレーションを呼び出すプリンシパルは、OpenID Connect (OIDC) 準拠の Web ID フェデレーションを使用して認証されます。このオペレーションは、AWS リソースへのアクセスに使用できる一時的な認証情報のセットを返します。AWS Management Console アクセスにウェブ ID フェデレーションを使用する方法の詳細については、「ウェブ ID フェデレーションについて」を参照してください。

OpenID Connect (OIDC) からソース ID を渡すには、JSON ウェブトークン (JWT) にソース ID を含める必要があります。AssumeRoleWithWebIdentity リクエストを送信するときに、トークンの http://aws.amazon.com/source_identity 名前空間にセッションタグを含めます。OIDC トークンとクレームの詳細については、Amazon Cognito 開発者ガイドの「ユーザープールでのトークンの使用」を参照してください。

たとえば、次のデコードされた JWT は、AssumeRoleWithWebIdentity ソースIDで Admin を呼び出すために使用されるトークンです。

例 デコードされた 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" }

ソース ID 情報を使用してアクセスを制御する

ソース ID が最初に設定されると、sts:SourceIdentityキーがリクエストに存在します。ソース ID が設定されると、aws: ソースアイデンティティキーは、ロールセッション中に行われた後続のすべての要求に存在します。管理者は、ソース ID 属性の存在または値に基づいて AWS アクションを実行するための条件付き承認を付与するポリシーを作成できます。

開発者にソースIDを設定して、本番環境の重要な AWS リソースへの書き込み権限を持つ重要なロールを引き受けるようにリクエストするとします。また、AWS を使用してワークフォース ID への AssumeRoleWithSAML アクセスを許可するとします。上級開発者の Saanvi と Diego にロールへのアクセス権のみを与えるため、ロールに対して次の信頼ポリシーを作成します。

例 ソース ID のロール信頼ポリシーの例

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AssumeRoleAndSetSourceIdentity", "Effect": "Allow", "Principal": { "AWS": " arn:aws:iam::111111111111:role/CriticalRole" }, "Action": [ "sts:AssumeRoleWithSAML", "sts:SetSourceIdentity" ], "Condition": { "StringLike": { "sts:SourceIdentity": ["Saanvi", "Diego"] } } } ] }

信頼ポリシーには、sts:SourceIdentityで、重要なロールを引き受けるには Saanvi または Diego に設定されているソース ID が必要です。

ロールチェーンとクロスアカウント要件

CriticalRole を想定したユーザーが別のアカウントで CriticalRole_2 を想定できるようにしたいとします。引き受けるために取得されたロールセッションの資格情報CriticalRoleは、ロールの連鎖を 2 番目のロール、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" } ] }

アカウントの境界を越えてソースIDの設定を保護するために、次のロール信頼ポリシーは、CriticalRole のロールプリンシパルのみを信頼してソース ID を設定します。

例 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 を引き受けることで取得したロールセッション資格情報を使用して、次の呼び出しを行います。ソース ID は、CriticalRole の仮定時に設定されているので、明示的に再度設定する必要はありません。ユーザーがソース ID を設定しようとした場合、CriticalRole が想定された場合、ロールの引き受けリクエストは拒否されます。

例 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 STS AssumeRole リクエストを行い、ソースIDを設定するとします。sourceIdentity 情報は、CloudTrail ログの requestParameters キーで見つけることができます。

例 AWS CloudTrail ログの requestParameters セクションの例

"eventVersion": "1.05", "userIdentity": { "type": "AWSAccount", "principalId": "AIDAJ45Q7YFFAREXAMPLE", "accountId": "123456789012" }, "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/Assumed_Role", "roleSessionName": "Test1", "sourceIdentity": "source-identity-value-set", },

ユーザーが引き受けたロールセッションを使用してアクションを実行する場合、ソース ID 情報は userIdentity キーを CloudTrail ログに追加します。

例 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 ログファイルに含まれる情報の詳細については、AWS CloudTrail ユーザーガイド の「CloudTrail イベントリファレンス」を参照してください。