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

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 値は、設定後は変更できません。また、ロールセッションで実行される追加のアクションでも保持されます。セッションタグとロールセッション名の使用方法は次のとおりです。

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

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

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

ソースアイデンティティについて知っておくべきこと

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

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

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

sts:SetSourceIdentity

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

{
  "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 値を定義します。

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

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 を使用する方法について説明します。一時的な認証情報の一般的なシナリオの詳細については、「一時的な認証情報の一般的なシナリオ」を参照してください。。

AssumeRole でのソース ID の使用

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

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 STS AssumeRoleWithSAML オペレーションを使用しての AWS フェデレーションを許可できます。これを行うには、以下のタスクを完了する必要があります。

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

SourceIdentity:DiegoRamirez

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

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

AssumeRoleWithWebIdentity によるソース ID の使用

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

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

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

{
    "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 アクションを実行するための条件付き承認を付与するポリシーを作成できます。

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

{
  "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 によってユーザーが認証される場合、信頼ポリシーは次のようになります。

{
  "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は、ロールの連鎖を 2 番目のロール、CriticalRole_2別のアカウントで。ロールは、アカウントの境界を越えて引き継がれています。したがって、sts:SetSourceIdentityのアクセス許可は、CriticalRole のアクセス許可ポリシーとCriticalRole_2のロール信頼ポリシーの両方で付与する必要があります。

{
  "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 を設定します。

{
  "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 が想定された場合、ロールの引き受けリクエストは拒否されます。

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 コールのログ記録」を参照してください。

例えば、ユーザーが AWS STS AssumeRole リクエストを行い、ソースIDを設定するとします。sourceIdentity 情報は、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 ログに追加します。

{
  "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 イベントリファレンス」を参照してください。