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

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

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

AWS でアクションを実行すると、アカウント管理者がモニタリングできるように、セッションに関する情報をログとして AWS CloudTrail に記録できます。管理者は、AWS でアクションを実行しているユーザーまたはアプリケーションを識別するカスタム文字列を渡すために ID を必須とするようロールを設定できます。この ID 情報は、ソース ID として AWS CloudTrail に保存されます。管理者は、CloudTrail でのアクティビティを確認するときに、ソース ID 情報を表示して、引き受けたロールセッションで誰が (または何が) アクションを実行したかを判断できます。

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

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

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

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

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

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

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

  1. テストユーザーとロールを設定 – 運用前の環境を使用して、テストユーザーとロールを設定し、ソース ID の設定を許可するようにポリシーを設定します。

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

  2. ロールの引き受け – テスト用にセットアップしたユーザーとロールで、ロールの引き受けとソース ID の受け渡しをテストします。

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

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

  5. 運用ポリシーの設定 – 運用環境のポリシーを設定し、運用ユーザーとロールに追加します。

  6. アクティビティのモニタリング – CloudTrail ログを使用して、運用ロールのアクティビティをモニタリングします。

ソース ID について知っておくべきこと

ソース ID を使用する際には、次の点に注意してください。

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

  • ID がソース ID を設定する場合、sts:SourceIdentity キーはリクエストの中に存在します。ロールセッション中に実行される後続のアクションでは、aws:SourceIdentity キーはリクエストの中に存在します。AWS は、sts:SourceIdentity キーまたは aws:SourceIdentity キーのソース ID の値を制御しません。ソース ID を要求する場合は、ユーザーまたは IdP に提供させる属性を選択する必要があります。セキュリティ上の理由から、これらの値の提供方法を制御できることを確認する必要があります。

  • ソース ID の値は、長さが 2~64 文字で、英数字、アンダースコア、および次の記号のみを使用できます: . , + = @ - (ハイフン)。aws: という文字列で始まる値を使用することはできません 。このプレフィックスは AWS が内部使用するために予約されています。

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

重要

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

ソース ID の設定に必要なアクセス許可

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

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

  • ロールの連鎖と呼ばれる別のロールを持つロールを引き受ける場合、そのロールを引き受けるプリンシパルのアクセス許可ポリシーと、ターゲットロールのロール信頼ポリシーの両方で、sts:SetSourceIdentity のアクセス許可が必要になります。そうしないと、ロールを引き受けるオペレーションは失敗します。

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

  • アカウントの境界を越えてソース 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 値を適用することができます。このポリシーで、ロールを引き受け、ソース ID を設定するためのアクセス許可が IAM ユーザー DevUser に付与されます。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 の認証情報を使用して、ユーザーは次の 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 がリクエストを評価すると、リクエストのコンテキストには DevUsersts:SourceIdentity が含まれます。

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

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

AssumeRole でのソース ID の使用

AssumeRole オペレーションは、AWS リソースへのアクセスに使用できる一時的な認証情報のセットを返します。IAM ユーザーまたはロールの認証情報を使用して AssumeRole を呼び出すことができます。ロールを引き受けるときにソース ID を渡すには、-–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 フェデレーションサービス (ADFS) を使用した AWS フェデレーション認証」を参照してください。

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

ソース ID の SAML 属性を設定するには、Name 属性を https://aws.amazon.com/SAML/Attributes/SourceIdentity に設定した Attribute 要素を含めます 。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) 準拠のウェブ ID フェデレーションを使用して認証されます。このオペレーションは、AWS リソースへのアクセスに使用できる一時的な認証情報のセットを返します。AWS Management Console アクセスにウェブ ID フェデレーションを使用する方法の詳細については、「ウェブ ID フェデレーションについて」を参照してください。

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

たとえば、次のデコードされた JWT は、Admin ソース ID で 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" }

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

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

運用に重要な AWS リソースへの書き込み許可を持つ重要なロールを引き受けるために、デベロッパーにソース ID を設定するように要求するとします。また、AssumeRoleWithSAML を使用してワークフォース ID AWS へのアクセスを許可するとします。上級デベロッパー 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"] } } } ] }

信頼ポリシーには、重要な役割を引き受けるために Saanvi または Diego に設定されているソース ID に必要な sts:SourceIdentity の条件が含まれています。

ロール連鎖とクロスアカウントの要件

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 の引き受け時に設定されているため、再度明示的に設定する必要はありません。ユーザーが CriticalRole を引き受けたときに設定された値とは異なるソース ID を設定しようとすると、ロール引き受けリクエストは拒否されます。

例 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 でのソース ID の表示

CloudTrail を使用して、ロールを引き受けるため、またはユーザーをフェデレートするために行われたリクエストを表示できます。AWS でアクションを実行することを要求するロールまたはユーザのリクエストを表示することもできます。CloudTrail ログファイルには、引き受けたロールまたはフェデレーティッドユーザーセッションのために設定されたソース ID に関する情報が含まれます。詳細については、次を参照してください。

例えば、ユーザーが AWS STS AssumeRole リクエストを行い、ソース ID を設定するとします。CloudTrail ログ内の requestParameters キーの sourceIdentity 情報を見つけることができます。

例 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情報は 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 User Guide』の「CloudTrail イベントリファレンス」を参照してください。