IAM で使用可能なキー OIDC AWS フェデレーションで使用できるキークロスサービス OIDC AWS フェデレーションコンテキストキー SAML ベースの AWS STS フェデレーションに利用可能なキークロスサービス 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 で使用可能なキー
OIDC AWS フェデレーションで使用できるキー
クロスサービス OIDC AWS フェデレーションコンテキストキー
SAML ベースの AWS STS フェデレーションに利用可能なキー
クロスサービス 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"},
        "ArnLike": {
            "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:FIDO-certification

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

FIDO セキュリティキーの登録時に MFA デバイスの FIDO 証明書レベルをチェックします。デバイス証明書は FIDO Alliance Metadata Service (MDS) から取得できます。FIDO セキュリティキーの証明書ステータスまたはレベルが変更されても、デバイスを登録し直して更新された証明書情報を取得しない限り、FIDO セキュリティキーが更新されることはありません。

L1、L1plus、L2、L2plus、L3、L3plus に使用できる値

この例では、セキュリティキーを登録し、デバイスの FIDO レベル1 plus 証明書を取得します。


{
      "Version": "2012-10-17",
      "Statement": [{
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Create"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Activate",
                    "iam:FIDO-certification": "L1plus"
                }
            }
        }
    ]
                  
 }

iam:FIDO-FIPS-140-2-certification

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

FIDO セキュリティキーの登録時に MFA デバイスの FIPS-140-2 検証証明書レベルをチェックします。デバイス証明書は FIDO Alliance Metadata Service (MDS) から取得できます。FIDO セキュリティキーの証明書ステータスまたはレベルが変更されても、デバイスを登録し直して更新された証明書情報を取得しない限り、FIDO セキュリティキーが更新されることはありません。

L1、L2、L3、L4 に使用できる値

この例では、セキュリティキーを登録し、デバイスの FIPS-140-2 レベル2 証明書を取得します。


{
      "Version": "2012-10-17",
      "Statement": [{
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Create"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Activate",
                    "iam:FIDO-FIPS-140-2-certification": "L2"
                }
            }
        }
    ]
                  
 }

iam:FIDO-FIPS-140-3-certification

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

FIDO セキュリティキーの登録時に MFA デバイスの FIPS-140-3 検証証明書レベルをチェックします。デバイス証明書は FIDO Alliance Metadata Service (MDS) から取得できます。FIDO セキュリティキーの証明書ステータスまたはレベルが変更されても、デバイスを登録し直して更新された証明書情報を取得しない限り、FIDO セキュリティキーが更新されることはありません。

L1、L2、L3、L4 に使用できる値

この例では、セキュリティキーを登録し、デバイスの FIPS-140-3 レベル3 証明書を取得します。


{
      "Version": "2012-10-17",
      "Statement": [{
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Create"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Activate",
                    "iam:FIDO-FIPS-140-3-certification": "L3"
                }
            }
        }
    ]
                  
 }

iam:RegisterSecurityKey

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

MFA デバイス有効化の現在の状態をチェックします。

Create または Activate に使用できる値です。

この例では、セキュリティキーを登録し、デバイスの FIPS-140-3 レベル1 証明書を取得します。


{
      "Version": "2012-10-17",
      "Statement": [{
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Create"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "iam:EnableMFADevice",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:RegisterSecurityKey" : "Activate",
                    "iam:FIDO-FIPS-140-3-certification": "L1"
                }
            }
        }
    ]
                  
 }

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 には、ロールを引き受ける最終サービスのみが含まれ、ロールを渡す中間サービスは含まれません。

注記

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

iam:PermissionsBoundary

ARN 演算子で動作します。

指定したポリシーが 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"}}
    }]
}

OIDC AWS フェデレーションで使用できるキー

OIDC フェデレーションを使用して、OpenID Connect 準拠の OpenID プロバイダー (OP) を介して認証されたユーザーに AWS アカウントの IAM OpenID Connect (OIDC) ID プロバイダーから一時的なセキュリティ認証情報を付与できます。このようなプロバイダーの例として、Login with Amazon、Amazon Cognito、Google、Facebook があります。Amazon Elastic Kubernetes Service クラスターのサービスアカウントに発行された id_tokens だけでなく、独自の OpenID OP から取得したアイデンティティトークン (id_tokens) も使用できます。その場合、一時的なセキュリティ認証情報を使用してリクエストするときに、他にも条件キーを使用することができます。これらのキーを使用して、フェデレーティッドユーザーの特定のプロバイダー、アプリケーション、またはユーザーに関連付けられたリソースへのアクセスを制限するポリシーを作成できます。これらのキーは、通常、ロールの信頼ポリシーで使用されます。OIDC プロバイダーの名前の後にクレーム (:aud、:azp、:amr、:sub) を付けて条件キーを定義します。Amazon Cognito が使用するロールの場合、キーはクレームの後に cognito-identity.amazonaws.com を使用して定義されます。

amr

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

例: cognito-identity.amazonaws.com:amr

OIDC フェデレーションに 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 キーで使用できます。

例:

graph.facebook.com:app_id
accounts.google.com:aud
cognito-identity.amazonaws.com:aud

graph.facebook.com:app_id フィールドは、他の ID プロバイダーが使用する 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: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

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

sub

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

例:

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

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


{
    "Version": "2012-10-17",
    "Statement": [
        "Condition": {
              "StringEquals": {
                  "oidc.eks.us-east-1.amazonaws.com/id/111122223333:aud": "sts.amazonaws.com",
                  "oidc.eks.us-east-1.amazonaws.com/id/111122223333:sub": "system:serviceaccount:default:assumer"
               }
            }
    ]
      }

OIDC フェデレーションに関する追加情報

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

クロスサービス OIDC AWS フェデレーションコンテキストキー

一部の OIDC フェデレーション条件キーは、ロールの信頼ポリシーで使用して、他の AWS サービスへのアクセスを許可するユーザーを定義することができます。フェデレーテッドプリンシパルが別のロールを引き受けるときのロール信頼ポリシーや、フェデレーションプリンシパルによるリソースアクセスを許可する他の AWS サービスのリソースポリシーで使用できる条件キーは以下のとおりです。OIDC フェデレーションに Amazon Cognito を使用する場合、これらのキーはユーザーの認証時に使用できます。

条件キーを選択すると、説明が表示されます。

注記

ID プロバイダー (IdP) による認証と最初の AssumeRoleWithWebIdentity 操作の承認後は、他のウェブ 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 STS フェデレーションコンテキストキー

SAML ベースのフェデレーション条件キーの中には、後続のリクエストで使用することで、他のサービスや AssumeRole 呼び出しで AWS の操作を許可できるものがあります。フェデレーテッドプリンシパルが別のロールを引き受けるときのロール信頼ポリシーや、フェデレーションプリンシパルによるリソースアクセスを許可する他の AWS サービスのリソースポリシーで使用できる条件キーは以下のとおりです。これらのキーの使用に関する詳細は、「SAML 2.0 ベースのフェデレーションについて」を参照してください。

条件キーを選択すると、説明が表示されます。

saml:namequalifier
saml:sub
saml:sub_type

注記

最初の外部 ID プロバイダー (IdP) 認証レスポンスの後は、他の SAML ベースのフェデレーション条件キーは使用できません。

AWS STS に利用可能なキー

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

saml:sub

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

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

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:RequestContext/context-key

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

このキーを使用して、リクエストで渡された信頼されたトークン発行者の署名付きコンテキストアサーションに埋め込まれているセッションコンテキストのキーと値のペアを、ロールの信頼ポリシーで指定されたコンテキストキー値と比較します。

可用性 — このキーは、AWS STS AssumeRole API 操作を使用してロールを引き受けるときに、ProvidedContexts リクエストパラメータでコンテキストアサーションが提供されるときに、リクエストに含まれます。

このコンテキストキーは "sts:RequestContext/context-key":"context-value" の形式になります。ここで、context-key と context-value はコンテキストキーと値のペアです。複数のコンテキストキーがリクエストで渡された署名付きコンテキストアサーションに埋め込まれると、キーと値のペアごとに 1 つのコンテキストキーが存在します。結果のセッショントークンにプリンシパルがコンテキストキーを設定できるようにするには、ロールの信頼ポリシーで sts:SetContext アクションのアクセス権限を付与する必要があります。

ロール信頼ポリシーでこのキーを使用すると、ユーザーがロールを引き受けるときに、ユーザーまたはその属性に基づいてきめ細かいアクセス制御を実施できます。例えば、Amazon Redshift を IAM アイデンティティセンターアプリケーションとして設定して、従業員またはフェデレーテッドアイデンティティに代わって Amazon S3 リソースにアクセスできます。

次のロール信頼ポリシーにより、Amazon Redshift サービスはアカウント 111122223333 でロールを引き受けることができます。また、identitystore:UserId コンテキストキー値が 1111-22-3333-44-5555 に設定されている限り、リクエストにコンテキストキーを設定するアクセス許可を Amazon Redshift サービスプリンシパルに付与します。ロールを引き継ぐと、コンテキストプロバイダがロール割り当てリクエストで設定したセッションコンテキストのキーと値のペアを含むアクティビティが AdditionalEventData 要素内の AWS CloudTrail ログに表示されます。これにより、管理者がロールを異なるプリンシパルで使用する場合に、ロールセッションを区別しやすくなります。キーと値のペアは、AWS CloudTrail または AWS STS ではなく、指定されたコンテキストプロバイダーによって設定されます。これにより、コンテキストプロバイダーは、CloudTrail ログとセッション情報に含まれるコンテキストを制御できます。


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "redshift.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:SetContext"
            ],
            "Condition": {
                "ForAllValues:ArnEquals": {
                    "sts:RequestContextProviders": [
                        "arn:aws:iam::aws:contextProvider/IdentityCenter"
                    ]
                },
                "StringEquals": {
                    "aws:SourceAccount": "111122223333",
                    "sts:RequestContext/identitystore:UserId": "1111-22-3333-44-5555"
                }
            }
        }
    ]
}

sts:RequestContextProviders

ARN 演算子で動作します。

このキーを使用して、リクエスト内のコンテキストプロバイダー ARN をロールの信頼ポリシーで指定されたコンテキストプロバイダー ARN と比較します。

次の条件例では、リクエストで渡されたコンテキストプロバイダー ARN が、ロールの信頼ポリシー条件で指定された ARN と一致することを確認します。


      "Condition": {
        "ForAllValues:ArnEquals": {
          "sts:RequestContextProviders": [
            "arn:aws:iam::aws:contextProvider/IdentityCenter"
          ]
        }
      }

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 を有効にする必要があります。手順については、使用するブラウザのヘルプページを参照してください。

ドキュメントの表記規則

グローバル条件キー

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