IAM で使用可能なキー AWS ウェブ ID フェデレーションで利用可能なキー SAML ベースの AWS STS フェデレーションに利用可能なキー AWS STS に利用可能なキー

IAM および AWS STS の条件コンテキストキー

JSON ポリシーの Condition 要素を使用して、すべての AWS リクエストのリクエストコンテキストに含まれるキーの値をテストできます。これらのキーは、リクエスト自体、またはリクエストが参照するリソースに関する情報を示します。ユーザーが要求したアクションを許可する前に、キーが指定された値を持っているかどうかを確認できます。これにより、JSON ポリシーステートメントが着信リクエストと照合するとき、しないときを細かく制御できます。JSON ポリシーで Condition 要素を使用する方法の詳細については、「IAM JSON ポリシー要素: Condition」を参照してください。

このトピックでは、IAM サービス (iam: プレフィックス付き) および AWS Security Token Service (AWS STS) サービス (sts: プレフィックス付き) で定義および提供されているキーについて説明します。他のいくつかの AWS サービスは、そのサービスによって定義されたアクションおよびリソースに関連するサービス固有のキーも提供します。詳細については、「AWS のサービスのアクション、リソース、および条件キー」を参照してください。条件キーをサポートするサービスのドキュメントには、追加情報がある場合があります。例えば、Amazon S3 リソースのポリシーで使用できるキーについては、Amazon Simple Storage Service ユーザーガイドの「Amazon S3 ポリシーキー」を参照してください。

トピック

IAM で使用可能なキー
AWS ウェブ ID フェデレーションで利用可能なキー
SAML ベースの AWS STS フェデレーションに利用可能なキー
AWS STS に利用可能なキー

IAM で使用可能なキー

IAM リソースへのアクセスを制御するポリシーで以下の条件キーを使用できます。

iam:AssociatedResourceArn

ARN 演算子で動作します。

宛先サービスでこのロールが関連付けられるリソースの ARN を指定します。通常、リソースは、プリンシパルがロールを渡すサービスに属します。場合によっては、リソースが 3 番目のサービスに属することがあります。たとえば、Amazon EC2 インスタンスで使用するロールを Amazon EC2 Auto Scaling に渡すことができます。この場合、条件は Amazon EC2 インスタンスの ARN と一致します。

この条件キーは、ポリシーの PassRole アクションにのみ適用されます。他のアクションを制限するために使用することはできません。

エンティティがロールを渡すことを許可するには、ポリシーでこの条件キーを使用しますが、そのロールが指定されたリソースに関連付けられている場合に限ります。ワイルドカード (*) を使用すると、リージョンまたはリソース ID を制限することなく、特定の種類のリソースに対して操作を実行できます。たとえば、IAM ユーザーまたはロールが、リージョン us-east-1 または us-west-1 のインスタンスで使用する任意のロールを Amazon EC2 サービスに渡すことを許可できます。IAM ユーザーまたはロールは、ロールを他のサービスに渡すことはできません。さらに、Amazon EC2 が他のリージョンのインスタンスでロールを使用することも許可しません。


{
    "Effect": "Allow",
    "Action": "iam:PassRole",
    "Resource": "*",
    "Condition": {
        "StringEquals": {"iam:PassedToService": "ec2.amazonaws.com"},
        "StringLike": {
            "iam:AssociatedResourceARN": [
                "arn:aws:ec2:us-east-1:111122223333:instance/*",
                "arn:aws:ec2:us-west-1:111122223333:instance/*"
            ]
        }
    }
}

注記

iam:PassedToService をサポートする AWS サービスは、この条件キーもサポートします。

iam:AWSServiceName

文字列演算子で動作します。

このロールがアタッチされる AWS のサービスを指定します。

この例では、サービス名が access-analyzer.amazonaws.com である場合、エンティティがサービスにリンクされたロールを作成することを許可します。


{
   "Version": "2012-10-17",
   "Statement": [{
       "Effect": "Allow",
       "Action": "iam:CreateServiceLinkedRole",
       "Resource": "*",
       "Condition": {
         "StringLike": {
           "iam:AWSServiceName": "access-analyzer.amazonaws.com"
         }
       }
     }]
 }

iam:OrganizationsPolicyId

文字列演算子で動作します。

指定された AWS Organizations IDを持つポリシーがリクエストで使用されたポリシーと一致するかどうかを確認します。この条件キーを使用する IAM ポリシーの例を表示するには、「IAM: Organizations ポリシーのサービスの最終アクセス情報を表示」を参照してください。

iam:PassedToService

文字列演算子で動作します。

ロールを渡すことができるサービスのサービスプリンシパルを指定します。この条件キーは、ポリシーの PassRole アクションにのみ適用されます。他のアクションを制限するために使用することはできません。

ポリシーでこの条件キーを使用する場合は、サービスプリンシパルを使用してサービスを指定します。サービスプリンシパルは、ポリシーの Principal 要素で指定できるサービスの名前です。通常の形式は、SERVICE_NAME_URL.amazonaws.com です。

特定のサービスにのみロールを渡すことができるようにユーザーを制限するには、iam:PassedToService を使用します。たとえば、ユーザーは、代理で Amazon S3 バケットにログデータを書き込むために CloudWatch を信頼するサービスロールを作成する場合があります。次に、ユーザーは新しいサービスロールにアクセス許可ポリシーと信頼ポリシーをアタッチする必要があります。この場合、信頼ポリシーで、cloudwatch.amazonaws.com 要素の Principal を指定する必要があります。ユーザーが CloudWatch にロールを渡すことを許可するポリシーを表示するには、「IAM: IAM ロールを特定の AWS のサービスに渡す」を参照してください。

この条件キーを使用することで、ユーザーは、指定したサービスにのみ、サービスロールを作成することができます。たとえば、前述のポリシーを持つユーザーが Amazon EC2 のサービスロールを作成しようとすると、オペレーションは失敗します。このエラーは、ユーザーにロールを Amazon EC2 に渡すアクセス許可がないために発生します。

ロールをサービスに渡し、次に別のサービスにロールを渡すことがあります。iam:PassedToService には、ロールを引き受ける最終サービスのみが含まれ、ロールを渡す中間サービスは含まれません。

注記

AWS CodeBuild や AWS CodeCommit などの一部のサービスでは、この条件キーをサポートしていません。

iam:PermissionsBoundary

文字列演算子で動作します。

指定したポリシーが IAM プリンシパルリソースのアクセス許可の境界としてアタッチされていることを確認します。詳細については、「IAM エンティティのアクセス許可境界」を参照してください。

iam:PolicyARN

ARN 演算子で動作します。

管理ポリシーを含むリクエストの管理ポリシーの Amazon リソースネーム (ARN) を確認します。詳細については、「ポリシーへのアクセスの制御」を参照してください。

iam:ResourceTag/key-name

文字列演算子で動作します。

リソース (ユーザーまたはロール) を識別するためにアタッチされたタグが、指定されたキーの名前および値と一致するかどうかをチェックします。

注記

IAM と AWS STS は iam:ResourceTag IAM 条件キーと aws:ResourceTagグローバル条件キーの両方をサポートします。

カスタム属性は、キーバリューのペアの形式で IAM リソースに追加できます。IAM リソースのタグ付けの詳細については、「IAM リソースのタグ付け」を参照してください。ResourceTag リソース (IAM リソースを含む) へのアクセスを制御するには AWS を使用します。ただし、IAM ではグループのタグをサポートしていないため、タグを使用してグループへのアクセスを制御することはできません。

この例は、status=terminated タグを持つユーザーの削除を許可する ID ベースポリシーを作成する方法を示しています。このポリシーを使用するには、サンプルポリシーのイタリック体のプレースホルダーテキストを独自の情報に置き換えます。次に、ポリシーの作成またはポリシーの編集の手順に従います。


{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": "iam:DeleteUser",
        "Resource": "*",
        "Condition": {"StringEquals": {"iam:ResourceTag/status": "terminated"}}
    }]
}

AWS ウェブ ID フェデレーションで利用可能なキー

ウェブ ID フェデレーションを使用して、ID プロバイダー (IdP) を通じて認証されたユーザーに一時的なセキュリティ認証情報を付与できます。このようなプロバイダーの例として、Login with Amazon、Amazon Cognito、Google、Facebook があります。その場合、一時的なセキュリティ認証情報を使用してリクエストするときに、他にも条件キーを使用することができます。これらのキーを使用して、フェデレーティッドユーザーの特定のプロバイダー、アプリケーション、またはユーザーに関連付けられたリソースへのアクセスを制限するポリシーを作成できます。これらのキーは、通常、ロールの信頼ポリシーで使用されます。

amr

文字列演算子で動作します。

例: cognito-identity.amazonaws.com:amr

ウェブ ID フェデレーションに Amazon Cognito を使用する場合、cognito-identity.amazonaws.com:amr キー（認証方法リファレンス）にユーザーのログイン情報が含まれます。このキーには複数の値が含まれるため、条件 set 演算子を使用してポリシーでキーをテストします。キーには、次の値が含まれている可能性があります。

ユーザーが認証されていない場合、キーには unauthenticated のみが含まれています。
ユーザーが認証されている場合、キーには authenticated という値と、呼び出しで使用されるログインプロバイダーの名前 (graph.facebook.com、accounts.google.com、または www.amazon.com) が含まれています。

たとえば、Amazon Cognito ロールの信頼ポリシーの次の条件では、ユーザーが認証されていないかどうかをテストします。


"Condition": {
  "StringEquals": 
    { "cognito-identity.amazonaws.com:aud": "us-east-2:identity-pool-id" },
  "ForAnyValue:StringLike": 
    { "cognito-identity.amazonaws.com:amr": "unauthenticated" }
}

aud

文字列演算子で動作します。

aud 条件キーを使用して、Google クライアント ID または Amazon Cognito ID プール ID が、ポリシーで指定したものと一致することを確認します。aud キーは、同じ ID プロバイダーの sub キーで使用できます。

例:

accounts.google.com:aud
cognito-identity.amazonaws.com:aud

accounts.google.com:aud 条件キーは、次の Google ID トークンのフィールドと一致します。

azp フィールドが設定されていない場合の、アプリケーションの aud for OAuth 2.0 Google クライアント ID。azp フィールドが設定されると、aud フィールドは accounts.google.com:oaud 条件キーと一致します。
azp フィールドが設定されている場合の azp。これは、ウェブアプリケーションおよび Android アプリに異なる OAuth 2.0 Google クライアント ID があるが同じ Google API プロジェクトを共有している、ハイブリッドアプリで発生する可能性があります。

Google aud フィールドおよび azp フィールドの詳細については、Google Identity Platform OpenID 接続ガイドを参照してください。

accounts.google.com:aud 条件キーを使用してポリシーを記述する場合、アプリが azp フィールドを設定するハイブリッドアプリであるかどうかを知る必要があります。

azp フィールドが設定されていません

次のサンプルポリシーは、azp フィールドを設定しない非ハイブリッドアプリケーションに対して機能します。この場合、Google ID トークン aud フィールドの値は、accounts.google.com:aud および accounts.google.com:oaud 条件キーの両方の値に一致します。


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {"Federated": "accounts.google.com"},
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "accounts.google.com:aud": "aud-value",
                    "accounts.google.com:oaud": "aud-value",
                    "accounts.google.com:sub": "sub-value"
                }
            }
        }
    ]
}

azp フィールドが設定されました

次のサンプルポリシーは、azp フィールドを設定するハイブリッドアプリケーションに対して機能します。この場合、Google ID トークン aud フィールドの値は accounts.google.com:oaud 条件キーの値にのみ一致します。azp フィールドの値は accounts.google.com:aud 条件キーの値と一致します。


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {"Federated": "accounts.google.com"},
            "Action": "sts:AssumeRoleWithWebIdentity",
            "Condition": {
                "StringEquals": {
                    "accounts.google.com:aud": "azp-value",
                    "accounts.google.com:oaud": "aud-value",
                    "accounts.google.com:sub": "sub-value"
                }
            }
        }
    ]
}

id

文字列演算子で動作します。

例:

graph.facebook.com:app_id
graph.facebook.com:id
www.amazon.com:app_id
www.amazon.com:user_id

これらのキーを使用して、アプリケーション（またはサイト）ID またはユーザー ID が、ポリシーで指定したものと一致することを確認します。これは Facebook または Login with Amazon で機能します。app_id キーは、同じ ID プロバイダーの id キーで使用できます。

oaud

文字列演算子で動作します。

例: accounts.google.com:oaud

ウェブ ID フェデレーションに Google を使用する場合、このキーはこの ID トークンの対象となるアカウントの Google 対象者 (aud) を指定します。アプリケーションの OAuth 2.0 クライアント ID のひとつである必要があります。

sub

文字列演算子で動作します。

例:

accounts.google.com:sub
cognito-identity.amazonaws.com:sub

これらのキーを使用して、ユーザー ID がポリシーで指定したものと一致することを確認します。sub キーは、同じ ID プロバイダーの aud キーで使用できます。

ウェブ ID フェデレーションの詳細

ウェブ ID フェデレーションの詳細については、以下を参照してください。

開発者ガイドの「AWS Mobile SDK for AndroidAmazon Cognito の概要」
開発者ガイドの「AWS Mobile SDK for iOSAmazon Cognito の概要」
ウェブ ID フェデレーションについて

SAML ベースの AWS STS フェデレーションに利用可能なキー

AWS Security Token Service (AWS STS) を使用して SAML ベースのフェデレーションを操作する場合、追加の条件キーをポリシーに含めることができます。

SAML ロールの信頼ポリシー

ロールの信頼ポリシーには、以下のキーを含めることができます。これらのキーは、ロールの引き受け許可を発信者に与えるかどうかを規定するのに役立ちます。saml:doc を除いて、すべての値が SAML アサーションから派生します。条件付きのポリシーを作成または編集すると、リスト内のすべての項目が IAM コンソールのビジュアルエディタで使用できるようになります。[] とマークされている項目は、指定された型のリストである値を持つことができます。

saml:aud

文字列演算子で動作します。

SAML アサーションの提供先のエンドポイント URL。このキーの値は、アサーションの SAML Recipient フィールドから取得されます。Audience フィールドから取得された値ではありません。

saml:commonName[]

文字列演算子で動作します。

これは commonName 属性です。

saml:cn[]

文字列演算子で動作します。

これは eduOrg 属性です。

saml:doc

文字列演算子で動作します。

これは、ロールの引き受けに使用されたプリンシパルを表します。形式は、account-ID/provider-friendly-name です (123456789012/SAMLProviderName など)。account-ID 値は、SAML プロバイダーを所有するアカウントを参照します。

saml:edupersonaffiliation[]

文字列演算子で動作します。

これは eduPerson 属性です。

saml:edupersonassurance[]

文字列演算子で動作します。

これは eduPerson 属性です。

saml:edupersonentitlement[]

文字列演算子で動作します。

これは eduPerson 属性です。

saml:edupersonnickname[]

文字列演算子で動作します。

これは eduPerson 属性です。

saml:edupersonorgdn

文字列演算子で動作します。

これは eduPerson 属性です。

saml:edupersonorgunitdn[]

文字列演算子で動作します。

これは eduPerson 属性です。

saml:edupersonprimaryaffiliation

文字列演算子で動作します。

これは eduPerson 属性です。

saml:edupersonprimaryorgunitdn

文字列演算子で動作します。

これは eduPerson 属性です。

saml:edupersonprincipalname

文字列演算子で動作します。

これは eduPerson 属性です。

saml:edupersonscopedaffiliation[]

文字列演算子で動作します。

これは eduPerson 属性です。

saml:edupersontargetedid[]

文字列演算子で動作します。

これは eduPerson 属性です。

saml:eduorghomepageuri[]

文字列演算子で動作します。

これは eduOrg 属性です。

saml:eduorgidentityauthnpolicyuri[]

文字列演算子で動作します。

これは eduOrg 属性です。

saml:eduorglegalname[]

文字列演算子で動作します。

これは eduOrg 属性です。

saml:eduorgsuperioruri[]

文字列演算子で動作します。

これは eduOrg 属性です。

saml:eduorgwhitepagesuri[]

文字列演算子で動作します。

これは eduOrg 属性です。

saml:givenName[]

文字列演算子で動作します。

これは givenName 属性です。

saml:iss

文字列演算子で動作します。

発行者。URN で表されます。

saml:mail[]

文字列演算子で動作します。

これは mail 属性です。

saml:name[]

文字列演算子で動作します。

これは name 属性です。

saml:namequalifier

文字列演算子で動作します。

SAML プロバイダーのフレンドリ名に基づくハッシュ値。値は、次の値を順番に連結し、'/' 文字で区切ります。

Issuer 応答値 (saml:iss)
AWS アカウント ID
IAM の SAML プロバイダーのフレンドリ名（ARN の最後の部分）

SAML プロバイダーのアカウント ID とフレンドリ名の連結は、キー saml:doc として IAM ポリシーで使用できます。詳細については、「SAML ベースのフェデレーションでユーザーを一意に識別する」を参照してください。

saml:organizationStatus[]

文字列演算子で動作します。

これは organizationStatus 属性です。

saml:primaryGroupSID[]

文字列演算子で動作します。

これは primaryGroupSID 属性です。

saml:sub

文字列演算子で動作します。

* これはクレームの件名です。組織内の個々のユーザーを一意に識別する値が含まれます（例: _cbb88bf52c2510eabe00c1642d4643f41430fe25e3）。

saml:sub_type

文字列演算子で動作します。

このキーの値は、persistent か transient、または SAML アサーションで使用されている Format と Subject 要素の完全な NameID URI で構成されます。persistent の値は、saml:sub 値がセッション間のユーザーでも同じことを意味します。値が transient の場合、ユーザーの saml:sub 値はセッションごとに異なります。NameID 要素の Format 属性の詳細については、「認証レスポンスの SAML アサーションを設定する」を参照してください。

saml:surname[]

文字列演算子で動作します。

これは surnameuid 属性です。

saml:uid[]

文字列演算子で動作します。

これは uid 属性です。

saml:x500UniqueIdentifier[]

文字列演算子で動作します。

これは x500UniqueIdentifier 属性です。

eduPerson および eduOrg 属性に関する一般的な情報については、REFEDS Wiki ウェブサイトを参照してください。eduPerson 属性のリストについては、「eduPerson オブジェクトクラス仕様 (201602)」を参照してください。

リストタイプの条件キーには、複数の値を含めることができます。リスト値のポリシー内で条件を作成するには、set 演算子 (ForAllValues、ForAnyValue) を使用できます。たとえば、所属先が「faculty」または「staff」である（ただし、「student」ではない）すべてのユーザーを許可するには、次のような条件を使用します。


"Condition": {
   "ForAllValues:StringLike": {
     "saml:edupersonaffiliation":[ "faculty", "staff"] 
   }
}

SAML ロールのアクセス許可ポリシー

ユーザーが AWS で許可されている操作を定義する SAML フェデレーションのアクセス許可ポリシーには、次のキーを追加することができます。

saml:namequalifier

文字列演算子で動作します。

これには、saml:doc 値と saml:iss 値の組み合わせを表すハッシュ値が含まれます。これは名前空間の限定子として使用されます。saml:namequalifier と saml:sub の組み合わせによってユーザーが識別されます。

saml:sub

文字列演算子で動作します。

* これはクレームの件名です。組織内の個々のユーザーを一意に識別する値が含まれます（例: _cbb88bf52c2510eabe00c1642d4643f41430fe25e3）。

saml:sub_type

文字列演算子で動作します。

これらのキーの使用の詳細については、「SAML 2.0 ベースのフェデレーションについて」を参照してください。

AWS STS に利用可能なキー

AWS Security Token Service (AWS STS) オペレーションを使用して引き受けたロールについては、IAM ロール信頼ポリシーで以下の条件キーを使用できます。

sts:AWSServiceName

文字列演算子で動作します。

ベアラートークンを使用できるサービスを指定するには、このキーを使用します。ポリシーでこの条件キーを使用する場合は、サービスプリンシパルを使用してサービスを指定します。サービスプリンシパルは、ポリシーの Principal 要素で指定できるサービスの名前です。たとえば、codeartifact.amazonaws.com は AWS CodeArtifact サービスプリンシパルです。

一部の AWS のサービスでは、プログラムでリソースにアクセスする前に、AWS STS サービスベアラートークンを取得するアクセス許可が必要です。たとえば、AWS CodeArtifact では、プリンシパルがベアラートークンを使用して一部のオペレーションを実行する必要があります。aws codeartifact get-authorization-token コマンドは、ベアラートークンを返します。その後、ベアラートークンを使用して AWS CodeArtifact オペレーションを実行できます。ベアラートークンの詳細については、「ベアラートークンを使用する」を参照してください。

可用性 – このキーは、ベアラートークンを取得するリクエストに含まれています。AWS STS を直接呼び出してベアラートークンを取得することはできません。他のサービスでいくつかのオペレーションを実行すると、自動的にベアラートークンがリクエストされます。

この条件キーを使用すると、プリンシパルが特定のサービスで使用するベアラートークンを取得することを許可できます。

sts:DurationSeconds

桁演算子で動作します。

AWS STS ベアラートークンを取得するときにプリンシパルが使用できる時間 (秒) を指定するには、このキーを使用します。

可用性 – このキーは、ベアラートークンを取得するリクエストに含まれています。AWS STS を直接呼び出してベアラートークンを取得することはできません。他のサービスでいくつかのオペレーションを実行すると、自動的にベアラートークンがリクエストされます。このキーは、AWS STS assume-role オペレーションには含まれていません。

sts:ExternalId

文字列演算子で動作します。

IAM ロールを引き受けるときにプリンシパルが特定の識別子を提供するように要求するには、このキーを使用します。

可用性 – このキーは、AWS CLI または AWS API を使用してロールを引き受ける際にプリンシパルが外部 ID を提供するときにリクエストに含まれています。

別のアカウントでロールを引き受ける際に必要になる場合がある一意の ID。ロールが属するアカウントの管理者から外部 ID が提供された場合は、その値を ExternalId パラメータに指定します。この値は、パスフレーズやアカウント番号などの任意の文字列とすることができます。外部 ID の最も重要な機能は、混乱した代理問題の防止と対処です。外部 ID と混乱した代理問題の詳細については、「AWS リソースへのアクセス権を第三者に付与するときに外部 ID を使用する方法」を参照してください。

ExternalId の値は、2～1,224 文字で構成されている必要があります。この値は、空白のない英数字にする必要があります。次の記号を含めることもできます。プラス記号 (+)、等号 (=)、カンマ (,)、ピリオド (.)、アットマーク (@)、コロン (:)、スラッシュ (/)、およびハイフン (-)。

sts:RoleSessionName

文字列演算子で動作します。

このキーを使用して、ロールを引き受けるときにプリンシパルが指定するセッション名と、ポリシーで指定されている値を比較します。

可用性 – このキーは、プリンシパルが AWS Management Console、assume-role CLI コマンド、または AWS STS AssumeRole API オペレーションを使用してロールを引き受けるときにリクエストに含まれています。

ロール信頼ポリシーでこのキーを使用すると、ユーザーがロールを引き受けるときに特定のセッション名を指定するように要求できます。たとえば、IAM ユーザーがセッション名として自分のユーザー名を指定するように要求できます。IAM ユーザーがロールを引き受けると、ユーザー名と一致するセッション名とともにアクティビティがAWS CloudTrail ログに表示されます。これにより、管理者がロールを異なるプリンシパルで使用する場合に、ロールセッションを区別しやすくなります。

次のロール信頼ポリシーは、アカウント 111122223333 の IAM ユーザーがロールを引き受けるときに、セッション名としてユーザー名を指定することを要求します。この要件は、条件キーの aws:username 条件変数を使用して適用されます。このポリシーにより、IAM ユーザーはポリシーがアタッチされているロールを引き受けることができます。このポリシーでは、username 変数が IAM ユーザーのみに存在するため、一時的な認証情報を使用するどのユーザーもロールを引き受けることはできません。

重要

単一値の条件キーは、変数として使用できます。複数値の条件キーは、変数としては使用できません。


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RoleTrustPolicyRequireUsernameForSessionName",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Principal": {"AWS": "arn:aws:iam::111122223333:root"},
            "Condition": {
                "StringLike": {"sts:RoleSessionName": "${aws:username}"}
            }
        }
    ]
}

管理者がアクションの AWS CloudTrail ログを表示すると、セッション名とアカウントのユーザー名を比較できます。次の例では、matjac という名前のユーザーが MateoRole というロールを使用してオペレーションを実行しました。管理者は、matjac という名前のユーザーを持っている Mateo Jackson に連絡することができます。


    "assumedRoleUser": {
        "assumedRoleId": "AROACQRSTUVWRAOEXAMPLE:matjac",
        "arn": "arn:aws:sts::111122223333:assumed-role/MateoRole/matjac"
    }

ロールを使用したクロスアカウントアクセスを許可した場合、あるアカウントのユーザーが別のアカウントのロールを引き受けることができます。CloudTrail に一覧表示されている引き受けたロールユーザーの ARN には、そのロールが存在するアカウントが含まれます。ロールを引き受けるユーザーのアカウントは含まれません。ユーザーはアカウント内でのみ一意です。したがって、自分が管理しているアカウントのユーザーが引き受けたロールの CloudTrail ログを確認する場合のみこの方法を使用することをお勧めします。ユーザーは、複数のアカウントで同じユーザー名を使用していることがあります。

ST: 送信元アイデンティティ

文字列演算子で動作します。

このキーを使用して、ロールを引き受けるときにプリンシパルが指定するセッション名と、ポリシーで指定されている値を比較します。

可用性 — このキーは、AWS STS assume-role CLI コマンドまたは AWS STS AssumeRole API オペレーションを使用してロールを引き受けるときに、プリンシパルがソース ID を提供するときに要求に存在します。

ロール信頼ポリシーでこのキーを使用して、ユーザーがロールを引き受けるときに特定のセッション名を設定するように要求できます。たとえば、従業員またはフェデレーション ID にソース ID の値を指定するように要求できます。ユーザー名や電子メールなど、ユーザーに関連付けられている属性の 1 つをソース ID として使用するように ID プロバイダ (IdP) を設定できます。次に、IdP は、AWS に送信するアサーションまたはクレームの属性としてソース ID を渡します。ソース ID 属性の値は、ロールを引き受けるユーザーまたはアプリケーションを識別します。

ユーザーがロールを引き受けると、設定されたソース ID 値とともにアクティビティがAWS CloudTrail ログに表示されます。これにより、管理者は、AWS のロールで誰がどういったアクションを実行したかを簡単に判断できます。IDがソースIDを設定できるようにするには、sts:SetSourceIdentity アクションのアクセス許可を付与する必要があります。

sts:RoleSessionName とは異なり、ソースIDを設定した後は、値を変更できません。これは、ソース ID によってロールで実行されたすべてのアクションのリクエストコンテキストに存在します。この値は、セッション認証情報を使用して別のロールを引き受けるときに、後続のロールセッションに保持されます。別のロールからあるロールを引き受けると、ロールの連鎖と呼ばれます。

aws:SourceIdentityグローバル条件キーを使用して、後続の要求のソースIDの値に基づいて AWS リソースへのアクセスをさらに制御できます。

次のロール信頼ポリシーにより、IAM ユーザー AdminUser はアカウント 111122223333 でロールを引き受けることができます。また、ソース ID セットが AdminUser である限り、DiegoRamirez にソースIDを設定する権限を付与します。


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowAdminUserAssumeRole",
            "Effect": "Allow",
            "Principal": {"AWS": " arn:aws:iam::111122223333:user/AdminUser"},
            "Action": [
                "sts:AssumeRole",
                "sts:SetSourceIdentity"
            ],
            "Condition": {
                "StringEquals": {"sts:SourceIdentity": "DiegoRamirez"}
            }
        }
    ]
}

ソース ID 情報の使用の詳細については、「引き受けたロールで実行されるアクションのモニタリングと制御」を参照してください。

sts:TransitiveTagKeys

文字列演算子で動作します。

このキーを使用して、リクエスト内の推移的なセッションタグキーとポリシーで指定されたセッションタグキーを比較します。

可用性 – このキーは、一時的なセキュリティ認証情報を使用してリクエストを作成するときにリクエストに含まれます。これらの認証情報には、assume-role オペレーションまたは GetFederationToken オペレーションを使用して作成されたものが含まれます。

一時的なセキュリティ認証情報を使用してリクエストを行う場合、リクエストコンテキストには aws:PrincipalTag コンテキストキーが含まれます。このキーには、セッションタグ、推移的セッションタグ、およびロールタグのリストが含まれます。推移的セッションタグは、セッション認証情報を使用して別のロールを引き受けるときに、後続のすべてのセッションに保持されるタグです。別のロールからあるロールを引き受けると、ロールの連鎖と呼ばれます。

この条件キーをポリシーで使用すると、ロールの引き受け時またはユーザーのフェデレーション時に、特定のセッションタグを推移的として設定するよう要求できます。

ブラウザで JavaScript が無効になっているか、使用できません。

AWS ドキュメントを使用するには、JavaScript を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

グローバル条件キー

アクション、リソース、および条件キー