序章ポリシーでの変数の使用ポリシー変数としてのタグポリシー変数を使用する場所値のないポリシー変数ポリシー変数に使用可能なリクエスト情報デフォルト値の指定詳細情報

IAM ポリシーの要素: 変数とタグ

ポリシーを記述するときにリソースや条件キーの正確な値がわからない場合、AWS Identity and Access Management (IAM) のポリシー変数をプレースホルダーとして使用します。

注記

AWS が変数を解決できない場合は、これによってステートメント全体が無効になる可能性があります。たとえば、aws:TokenIssueTime 変数を使用する場合は、リクエスタが一時的な認証情報 (IAM ロール) を使用して認証した場合にのみ、変数は値に解決されます。変数が無効なステートメントを発生させないようにするには、...IfExists 条件演算子を使用します。

序章

IAM ポリシーでは、アクセスを制御する特定のリソースに対して名前を指定することが多くのアクセションで許可されています。例えば、以下のポリシーでは、ユーザーは、marketing プロジェクトの S3 バケット DOC-EXAMPLE-BUCKET 内のオブジェクトの一覧表示、読み取り、および書き込みができます。


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],      
      "Resource": ["arn:aws:s3:::DOC-EXAMPLE-BUCKET"],
      "Condition": {"StringLike": {"s3:prefix": ["marketing/*"]}}
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],      
      "Resource": ["arn:aws:s3:::DOC-EXAMPLE-BUCKET/marketing/*"]
    }
  ]
}

場合によっては、ポリシーを書く際に対象リソースの正確な名前が分からないときがあります。ポリシーを汎用化して多くのユーザーが共用できるようにすると、ユーザーごとにポリシーの一意なコピーを作成する必要がなくなります。ユーザーごとの個別のポリシーを作成するのではなく、そのグループに属するすべてのユーザーに対して機能する単一のグループポリシーを作成することをお勧めします。

ポリシーでの変数の使用

ポリシーにプレースホルダーを設定するポリシー変数を使用して、ポリシー内で動的な値を定義できます。

変数は、$ プレフィックスを使用してマークされ、その後に、リクエストに値がある変数名が、中括弧 ({ }) で囲まれて続きます。

ポリシーの評価時に、ポリシー変数はリクエスト自体の条件コンテキストから取得された値に置き換えられます。変数は、ID ベースのポリシー、リソースポリシー、サービスコントロールポリシー、セッションポリシー、VPC エンドポイントポリシーで使用できます。アクセス許可の境界として使用される ID ベースのポリシーは、ポリシー変数もサポートします。

グローバル条件コンテキストキーは、AWS サービス間のリクエストの変数として使用できます。サービス固有の条件キーは、AWS リソースを操作するときの変数としても使用できますが、それらをサポートするリソースに対してリクエストが行われた場合にのみ使用できます。各 AWS サービスとリソースで使用可能なコンテキストキーのリストについては、サービス認証リファレンスをご覧ください。特定の状況では、グローバル条件コンテキストキーに値を設定できません。詳細については、「AWS グローバル条件コンテキストキー」を参照してください。

重要

キー名では大文字と小文字は区別されません。たとえば、aws:CurrentTime と AWS:currenttime は同じです。
単一値の条件キーは、変数として使用できます。複数値の条件キーは、変数としては使用できません。

次の例は、特定のリソース名をポリシー変数に置き換える IAM ロールまたはユーザー用のポリシーを示しています。このポリシーは、aws:PrincipalTag 条件キーを利用して再利用できます。このポリシーが評価されると、${aws:PrincipalTag/team} では、バケット名が team プリンシパルタグのチーム名で終わる場合にのみアクションが許可されます。


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],      
      "Resource": ["arn:aws:s3:::DOC-EXAMPLE-BUCKET"],
      "Condition": {"StringLike": {"s3:prefix": ["${aws:PrincipalTag/team}/*"]}}
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],      
      "Resource": ["arn:aws:s3:::DOC-EXAMPLE-BUCKET/${aws:PrincipalTag/team}/*"]
    }
  ]
}

変数は、$ プレフィックスの後に波かっこ ({ }) を付けることでマークできます。${ } 文字の内部には、ポリシーで使用する値の名前をリクエストから取得して含めることができます。使用できる値については、このページの後半で説明します。

このグローバル条件キーの詳細については、グローバル条件キーのリストの「aws:PrincipalTag/tag-key」を参照してください。

注記

ポリシー変数を使用するには、ステートメントに Version 要素を含めて、ポリシー変数をサポートするバージョンに設定する必要があります。変数はバージョン 2012-10-17 から導入されました。旧バージョンでのポリシー言語では、ポリシー変数をサポートしていません。Version 要素を含めず、適切なバージョンの日付に設定しない場合、${aws:username} などの変数はポリシー内のリテラル文字列として扱われます。

Version ポリシー要素は、ポリシーバージョンとは異なります。Version ポリシー要素は、ポリシー内で使用され、ポリシー言語のバージョンを定義します。一方で、ポリシーバージョンは、IAM でカスタマー管理ポリシーを変更すると作成されます。変更されたポリシーによって既存のポリシーが上書きされることはありません。代わりに、IAM は管理ポリシーの新しいバージョンを作成します。Version ポリシー要素の詳細については、「IAM JSON ポリシー要素Version」を参照してください。ポリシーのバージョンの詳細については、「IAM ポリシーのバージョニング」を参照してください。

プリンシパルが S3 バケットの /David パスからオブジェクトを取得することを許可するポリシーは次のようになります。


{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],    
    "Resource": ["arn:aws:s3::DOC-EXAMPLE-BUCKET/David/*"]
  }]
}

このポリシーがユーザー David にアタッチされている場合、そのユーザーは自身の S3 バケットからオブジェクトを取得しますが、このユーザー名を含む各ユーザーには別のポリシーを作成する必要があります。その後、各ポリシーを個々のユーザーに関連付ける必要があります。

ポリシー変数を使用することで、再利用できるポリシーを作成できます。次のポリシーでは、aws:PrincipalTag のタグキー値がリクエストで渡されたタグキーの owner 値と一致する場合、ユーザーは Amazon S3 バケットからオブジェクトを取得できます。


{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowUnlessOwnedBySomeoneElse",
    "Effect": "Allow",
    "Action": ["s3:GetObject"],    
    "Resource": ["*"],
    "Condition": {
        "StringEquals": {
          "${s3:ExistingObjectTag/owner}": "${aws:PrincipalTag/owner}"
        }
      }
    }
  ]
}

このようにユーザーのところにポリシー変数を使用することで、ユーザーごとに別々のポリシーを作成する必要がなくなります。次の例では、プロダクトマネージャーが一時的なセキュリティ認証情報を使用して引き受ける IAM ロールにポリシーをアタッチしています。ユーザーが Amazon S3 オブジェクトへのアクセスをリクエストした場合、IAM では ${aws:PrincipalTag} 変数を現在のリクエストから取得した dept タグ値に置き換えてポリシーを評価します。


{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowOnlyDeptS3Prefix",
    "Effect": "Allow",
    "Action": ["s3:GetObject"],    
    "Resource": ["arn:aws:s3:::DOC-EXAMPLE-BUCKET/${aws:PrincipalTag/dept}/*"],    
    }
  ]
}

ポリシー変数としてのタグ

一部の AWS サービスでは、それらのサービスによって作成されたリソースに独自のカスタム属性をアタッチできます。例えば、Amazon S3 バケットや IAM ユーザーにタグを適用できます。これらのタグはキーバリューのペアです。タグキー名と、そのキー名に関連付けられた値とを定義します。たとえば、department キーと Human Resources 値を持つタグを作成します。IAM エンティティのタグ付けの詳細については、「IAM リソースのタグ付け」を参照してください。他の AWS サービスによって作成されるリソースのタグ付けについては、そのサービスのドキュメントを参照してください。タグエディタの使用については、「AWS Management Console ユーザーガイド」の「タグエディタの使用」を参照してください。

IAM リソースにタグ付けすることで、IAM リソースの検出、整理、および追跡を簡単に行うことができます。また、IAM アイデンティティにタグ付けして、リソースまたはタグ付け自体へのアクセスを制御することもできます。タグを使用したアクセスの制御については、「タグを使用した IAM ユーザーおよびロールへのアクセスとそのユーザーおよびロールのアクセスの制御」を参照してください。

ポリシー変数を使用する場所

Resource 要素のポリシー変数、および Condition 要素の文字列比較を活用できます。

リソースの要素

ポリシー変数は Resource 要素で使用できますが、ARN のリソース部分でのみ使用できます。ARN のこの部分は、5 番目のコロン (:) の後に表示されます。サービスやアカウントなど 5 番目のコロンよりも前の ARN の部分は、変数を使用して置き換えることはできません。ARN 形式の詳細については、IAM ARNを参照してください。

ARN の一部をタグ値で置き換えるには、プレフィックスとキー名を ${ } で囲みます。例えば、次のリソース要素は、リクエストしているユーザーの部門タグの値と同じ名前のバケットのみを参照します。

"Resource": ["arn:aws::s3:::bucket/${aws:PrincipalTag/department}"]

多くの AWS リソースは、ユーザーが作成した名前を含む ARN を使用します。以下の IAM ポリシーでは、アクセスプロジェクト、アクセスアプリケーション、アクセス環境のタグ値が一致する対象ユーザーのみがリソースを変更できるようにしています。さらに、* ワイルドカードマッチを使用すると、カスタムリソース名のサフィックスを指定できます。


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAccessBasedOnArnMatching",
      "Effect": "Allow",
      "Action": [
        "sns:CreateTopic",
        "sns:DeleteTopic"],      
      "Resource": ["arn:aws:sns:*:*:${aws:PrincipalTag/access-project}-${aws:PrincipalTag/access-application}-${aws:PrincipalTag/access-environment}-*"
      ]
    }
  ]
}

条件の要素

ポリシー変数は、文字列演算子または ARN 演算子を含む任意の条件の Condition の値に使用できます。文字列演算子には StringEquals、StringLike、StringNotLike などが含まれます。ARN 演算子には ArnEquals と ArnLike が含まれます。ポリシー変数は Numeric、Date、Boolean、Binary、IP Address、または Null など、他の演算子では使用できません。条件演算子の詳細については、「IAM JSON ポリシー要素: 条件演算子」を参照してください。

Condition 要素式のタグを参照するときは、関連する接頭辞とキー名を条件キーとして使用します。次に、条件値でテストする値を使用します。

例えば、次のポリシー例では、ユーザーにフルアクセスが許可されていますが、タグ costCenter がユーザーにアタッチされている場合に限ります。タグの値は、12345 または 67890 である必要があります。タグ値が設定されていない場合、またはそれ以外の値の場合、リクエストは失敗します。


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
          "iam:*user*"
       ],
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "iam:ResourceTag/costCenter": [ "12345", "67890" ]
        }
      }
    }
  ]
}

値のないポリシー変数

ポリシー変数が、値のない、またはリクエストの承認コンテキストに存在しない条件コンテキストキーを参照する場合、その値は事実上 null になります。同等または同等の価値はありません。以下の場合、条件コンテキストキーが認可コンテキストに存在しない可能性があります。

その条件キーをサポートしていないリソースへのリクエストで、サービス固有の条件コンテキストキーを使用しています。
IAM プリンシパル、セッション、リソース、またはリクエストのタグは存在しません。
AWS グローバル条件コンテキストキー内の各グローバル条件コンテキストキーにリストされているその他の状況。

IAM ポリシーの条件要素に値のない変数を使用すると（「IAM JSON ポリシー要素: 条件演算子いいね」StringEquals または「StringLike一致しない」）、ポリシーステートメントが有効になりません。

StringNotEquals または StringNotLike などの逆条件演算子は、テスト対象の条件キーの値が実際の NULL 値と等しくないか、等しくないため、null 値とマッチします。

例えば、アクセスを許可するには aws:principaltag/Team が s3:ExistingObjectTag/Team と等しい必要があります。aws:principaltag/Team が設定されていない場合、アクセスは明示的に拒否されます。承認コンテキストに値のない変数をポリシーの Resource または NotResource 要素の一部として使用すると、値のないポリシー変数を含むリソースはどのリソースとも一致しません。


{
  "Version": "2012-10-17",
  "Statement": [
   {
    "Effect": "Deny", 
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::/example-bucket/*",
    "Condition": {
      "StringNotEquals": {
        "s3:ExistingObjectTag/Team": "${aws:PrincipalTag/Team}"
       }
      }
    }
  ]
}

ポリシー変数に使用可能なリクエスト情報

JSON ポリシーの Condition 要素を使用して、リクエストコンテキストのキーを、ポリシーで指定したキーバリューと比較できます。ポリシー変数を使用する場合、AWS は、ポリシー内の変数の代わりにリクエストコンテキストキーの値を置換します。

プリンシパルキーの値

aws:username、aws:userid、および aws:PrincipalType の値は、リクエストを開始したプリンシパルの値によって異なります。例えば、IAM ユーザー、IAM ロール、または AWS アカウントのルートユーザーの認証情報を使用してリクエストを行うことができます。以下の表は、様々な種類のプリンシパルに対するキーの値を示しています。

Principal	`aws:username`	`aws:userid`	`aws:PrincipalType`
AWS アカウントのルートユーザー	(なし)	AWS アカウント ID	`Account`
IAM ユーザー	`IAM-user-name`	一意の ID	`User`
委任ユーザー	(なし)	`account`:`caller-specified-name`	`FederatedUser`
ウェブフェデレーティッドユーザー (Login with Amazon、Amazon Cognito、Facebook、Google) ウェブ ID フェデレーションを使用するときに利用可能なポリシーキーの詳細については、「OIDC フェデレーションでユーザーを識別する」を参照してください。	(なし)	`role-id`:`caller-specified-role-name` ここで、`role-id` はロールの一意の ID であり、caller-specified-role-name は AssumeRoleWithWebIdentity リクエストに渡される RoleSessionName パラメータによって指定されます。	`AssumedRole`
SAML フェデレーションユーザー SAML フェデレーションを使用するときに利用可能なポリシーキーの詳細については、「SAML ベースのフェデレーションでユーザーを一意に識別する」を参照してください。	(なし)	`role-id`:`caller-specified-role-name` ここで、r`role-id` はロールの一意の ID です。caller-specified-role-name は Attribute 要素によって指定され、Name 属性は https://aws.amazon.com/SAML/attributes/RoleSessionName に設定されています。	`AssumedRole`
委任されたロール	(なし)	`role-id`:`caller-specified-role-name` ここで、`role-id` はロールの一意の ID であり、caller-specified-role-name は AssumeRole リクエストに渡される RoleSessionName パラメータです。	`AssumedRole`
Amazon EC2 インスタンスに割り当てられたロール	(なし)	`role-id`:`ec2-instance-id` ここで、`role-id` はロールの一意の ID であり、ec2-instance-id は EC2 インスタンスの一意の識別子です。	`AssumedRole`
匿名呼び出し元 (Amazon SQS、Amazon SNS、および Amazon S3 のみ)	(なし)	`anonymous`	`Anonymous`

このテーブルのについては、次の点に注意してください。

なしである場合、値が現在のリクエスト情報内に存在しないために値を一致させる試みが失敗し、ステートメントが無効になることを意味します。
role-id は、作成時に各ロールに割り当てられる一意の識別子です。次の AWS CLI コマンドでロール ID を表示できます: aws iam get-role --role-name rolename
caller-specified-name および caller-specified-role-name は、一時的認証情報を取得するための呼び出し元プロセス (アプリケーションまたはサービスなど) によって渡された名前です。
ec2-instance-id は、インスタンスにその起動時に割り当てられ、Amazon EC2 コンソールの [Instances (インスタンス)] ページに表示される値です。インスタンス ID を表示するには、次の AWS CLI コマンドを実行します: aws ec2 describe-instances

フェデレーティッドユーザーがリクエストで利用可能な情報

フェデレーションユーザーとは、IAM 以外のシステムを使用して認証されたユーザーです。たとえば、ある企業が AWS に発信する社内用のアプリケーションを使用しているとします。このアプリケーションを使用する社内すべてのユーザーに IAM ID を発行することは実際的ではありません。代わりに、単一の IAM ID を持つプロキシ (中間層) アプリケーションを使用するか、SAML ID プロバイダー (IdP) を使用することができます。プロキシアプリケーションまたは SAML IdP は、企業ネットワークを使用して個々のユーザーを認証します。プロキシアプリケーションは、その IAM ID を使用して、個々のユーザーの一時的セキュリティ認証情報を取得できます。SAML IdP は、実際には AWS 一時的セキュリティ認証情報の ID に置き換えることができます。次に、一時的な認証情報を使用して、AWS リソースにアクセスできます。

同様に、AWS リソースへのアクセスが必要なモバイルデバイス用アプリを作成することもできます。この場合、「OIDC フェデレーション」を使用すると、アプリケーションで、Login with Amazon、Amazon Cognito、Facebook、Google などのよく知られた ID プロバイダーを使用するユーザーを認証できます。その後、アプリはこれらのプロバイダーから取得したユーザーの認証情報を用いて、AWS リソースにアクセスするための一時認証情報を取得します。

OIDC フェデレーションを使用する場合は、Amazon Cognito と AWS Mobile SDK を利用することをお勧めします。詳細については、次を参照してください:

特殊文字

それ以外の場合は特別な意味を持つ文字を表すことのできる、固定値を持つ事前定義された特殊なポリシー変数がいくつかあります。これらの特殊文字が、一致を試みている文字列、またリテラルに挿入した文字列の一部である場合、これらは誤って解釈されます。たとえば、文字列に挿入されたアスタリスク (*) は、リテラルな * としてではなく、任意の文字列を指定するワイルドカードとして解釈されます。この場合、事前定義した次のポリシー変数を使用できます。

${*} - * (アスタリスク) が必要な場合に使用します。
${?} - ? (疑問符) が必要な場合に使用します。
${$} - $ (ドル記号) が必要な場合に使用します。

これらの事前定義されたポリシー変数は、正規のポリシー変数を使用できるすべての文字列で使用できます。

デフォルト値の指定

変数にデフォルト値を追加するには、デフォルト値を一重引用符 (' ') で囲み、変数テキストとデフォルト値をコンマとスペース (, ) で区切ります。

例えば、プリンシパルが team=yellow でタグ付けされている場合、DOC-EXAMPLE-BUCKET-yellow という名前で ExampleCorp's のAmazon S3 バケットにアクセスできます。このリソースを使用するポリシーでは、チームメンバーがチームのバケットにアクセスすることは許可されますが、他のチームのリソースにアクセスすることはできません。チームタグのないユーザーの場合、company-wide のデフォルト値をバケットの名前として設定します。これらのユーザーは DOC-EXAMPLE-BUCKET-company-wide バケットにのみアクセスでき、チームへの参加方法などの一般的な情報を確認できます。


"Resource":"arn:aws:s3:::DOC-EXAMPLE-BUCKET-${aws:PrincipalTag/team, 'company-wide'}"

詳細情報

ポリシーの詳細については、以下を参照してください。

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

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

ドキュメントの表記規則

単一値のコンテキストキーポリシーの例

サポートされているデータ型