翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
詳細に設定されたアクセスコントロールのための IAM ポリシー条件の使用
DynamoDB で許可を付与するときは、許可ポリシーを有効にする方法を決める条件を指定できます。
概要
DynamoDB では、IAM ポリシー (Amazon DynamoDB の Identity and Access Management を参照) を使用して許可を付与するとき、条件を指定することもできます。たとえば、以下のことが可能です。
-
テーブル内またはセカンダリインデックスの特定の項目と属性に対する読み込み専用アクセスをユーザーに許可する許可を付与します。
-
ユーザーのアイデンティティに基づいて、テーブルの特定の属性への書き込み専用アクセスのアクセス権限をユーザーに付与します。
DynamoDB では、次のセクションのユースケースに示すように、条件キーを使用して IAM ポリシーの条件を指定できます。
注記
AWS 一部のサービスはタグベースの条件もサポートしていますが、DynamoDB はサポートしていません。
アクセス権限のユースケース
DynamoDB API アクションへのアクセスを制御するだけでなく、個別のデータ項目と属性へのアクセスも制御できます。例えば、次の操作を実行できます。
-
テーブルでアクセス権限を付与しますが、特定のプライマリキー値に基づいて、そのテーブル内の特定の項目へのアクセスを制限します。この例として、ゲーム用のソーシャルネットワーキングアプリケーションがあります。次の図に示すように、すべてのユーザーのゲームデータは 1 つのテーブルに保存されますが、いずれのユーザーも、自分が所有していないデータ項目にアクセスすることはできません。
-
属性のサブセットのみがユーザー表示されるように、情報を非表示にします。この例として、ユーザーの位置に基づいて、近くの空港の運航便データを表示するアプリケーションがあります。航空会社名、到着時間、出発時間、および運航便番号がすべて表示されます。ただし、次の図に示すように、パイロット名や乗客数などの属性は非表示になります。
このような種類のきめ細かなアクセス制御を実装するには、セキュリティ認証情報と関連する許可にアクセスするための条件を指定した IAM 許可ポリシーを書き込みます。次に、IAM コンソールを使用して作成する ユーザー、グループ、またはロールにそのポリシーを適用します。IAM ポリシーによって、テーブルの個別項目へのアクセス、その項目の属性へのアクセス、またはその両方へのアクセスを同時に制御できます。
必要に応じて、ウェブアイデンティティフェデレーションを使用して、Login with Amazon、Facebook、または Google によって認証されるユーザーによるアクセスを制御できます。詳細については、「」を参照してくださいウェブ ID フェデレーションの使用
IAM の Condition 要素を使用して、詳細なアクセスコントロールポリシーを実装できます。Condition 要素を許可ポリシーに追加することで、特定のビジネス要件に基づいて、DynamoDB テーブルとインデックスの項目と属性へのアクセスを許可または拒否できます。
例として、プレーヤーがさまざまなゲームを選択してプレイできるモバイルゲームアプリケーションを考えてみます。このアプリケーションでは、GameScores という名前の DynamoDB テーブルを使用して、高スコアなどのユーザーデータを記録します。テーブルの各項目は、ユーザー ID とユーザーがプレイしたゲームの名前で一意に識別されます。GameScores テーブルには、パーティションキー (UserId) およびソートキー (GameTitle) で構成されているプライマリキーがあります。ユーザーは、そのユーザー ID に関連付けられたゲームデータだけにアクセスできます。ゲームをプレイするユーザーは、GameRole という名前の IAM ロールに属する必要があります。このロールには、セキュリティポリシーが添付されています。
このアプリケーションのユーザーアクセス権限を管理するには、次のようなアクセス権限ポリシーを記述できます。
{ "Version":"2012-10-17", "Statement":[ { "Sid":"AllowAccessToOnlyItemsMatchingUserID", "Effect":"Allow", "Action":[ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem" ], "Resource":[ "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores" ], "Condition":{ "ForAllValues:StringEquals":{ "dynamodb:LeadingKeys":[ "${www.amazon.com:user_id}" ], "dynamodb:Attributes":[ "UserId", "GameTitle", "Wins", "Losses", "TopScore", "TopScoreDateTime" ] }, "StringEqualsIfExists":{ "dynamodb:Select":"SPECIFIC_ATTRIBUTES" } } } ] }
GameScores テーブル (Resource 要素) の特定の DynamoDB アクション (Action 要素) に対する許可の付与に加えて、Condition 要素は、次のように許可を制限する DynamoDB に固有の次の条件キーを使用します。
-
dynamodb:LeadingKeys– この条件キーにより、ユーザーはパーティションのキーバリューがユーザー ID に一致する項目にのみアクセスできます。この ID、${www.amazon.com:user_id}は、置換変数です。置換変数の詳細については、「ウェブ ID フェデレーションの使用」を参照してください。 -
dynamodb:Attributes– この条件キーは指定された属性へのアクセスを制限し、許可ポリシーにリストされたアクションのみが、これらの属性の値を返すことができるようにします。さらに、StringEqualsIfExists句は、アプリケーションが常に対象となる特定の属性のリストを提供し、すべての属性をリクエストできないようにします。
IAM ポリシーが評価されると、結果は必ず true (アクセス許可) または false (アクセス拒否) になります。Condition 要素のいずれかの部分が false の場合、ポリシー全体が false と評価され、アクセスは拒否されます。
重要
dynamodb:Attributes を使用する場合、ポリシーでリストに記載されているテーブルとすべてのセカンダリインデックスについて、すべてのプライマリキー属性とインデックスキー属性の名前を指定する必要があります。指定しなかった場合、DynamoDB は、このキー属性を使用して、リクエストされたアクションを実行できません。
IAM ポリシードキュメントには、次の Unicode 文字のみを含めることができます。水平タブ (U+0009)、ラインフィード (U+000A)、キャリッジリターン (U+000D)、および U+0020～U+00FF の範囲内の文字。
条件の指定: 条件キーの使用
AWS アクセスコントロール用の IAM AWS をサポートするすべてのサービスに、定義済みの条件キー (AWS-wide 条件キー) のセットが用意されています。たとえば、aws:SourceIp 条件キーを使用して、リクエスタの IP アドレスを確認してから、アクションの実行を許可できます。詳細と AWS-wide キーのリストについては、IAM ユーザーガイドの「条件に使用できるキー」を参照してください。
以下の表では、DynamoDB に適用される DynamoDB サービス固有の条件キーを示しています。
| DynamoDB 条件キー | 説明 |
|---|---|
dynamodb:LeadingKeys |
テーブルの最初のキー属性、つまりパーティションキーを表します。キーが 1 つの項目のアクションで使用される場合も、キー名 |
dynamodb:Select |
|
dynamodb:Attributes |
リクエスト内の属性名のリスト、またはリクエストから返される属性を表します。
|
dynamodb:ReturnValues |
リクエストの
|
dynamodb:ReturnConsumedCapacity |
リクエストの
|
ユーザーアクセスの制限
多くの IAM アクセス権限ポリシーでは、パーティションキーの値がユーザー識別子と一致するテーブルの項目へのアクセスのみをユーザーに許可します。たとえば、前述のゲームアプリケーションは、この方法でアクセスを制限し、ユーザーは自分のユーザー ID に関連付けらたゲームデータのみにアクセスできるようにします。IAM 置換変数 ${www.amazon.com:user_id}、${graph.facebook.com:id}、および ${accounts.google.com:sub} には、Login with Amazon、Facebook、および Google のユーザー識別子が格納されます。アプリケーションがこのようなアイデンティティプロバイダーのいずれかにログインし、この識別子を取得する方法については、「ウェブ ID フェデレーションの使用」を参照してください。
注記
以下のセクションの各例では、Effect 句を Allow に設定し、許可されるアクション、リソース、およびパラメータのみを指定します。IAM ポリシーで明示的に指定されたものへのアクセスだけが許可されます。
場合によっては、拒否ベースとなるようにこのポリシーを書き直すことができます。つまり、Effect 句を Deny に設定して、ポリシーのすべてのロジックを逆にします。ただし、拒否ベースのポリシーを DynamoDB で使用しないことをお勧めします。このようなポリシーは、許可ベースのポリシーと比べて、正しく書き込むことが難しいためです。また、DynamoDB API への将来の変更 (または、既存の API 入力への変更) が原因で、拒否ベースのポリシーが機能しなくなる可能性があります。
ポリシー例: きめ細かなアクセスコントロールのための IAM ポリシー条件の使用
このセクションでは、DynamoDB テーブルとインデックスに対してきめ細かなアクセス制御を実装するための一部のポリシーについて説明します。
注記
すべての例で、us-west-2 リージョンを使用し、架空のアカウント ID を含めています。
1: 特定のパーティションのキー値を持つ項目へのアクセスを制限するアクセス権限の付与
以下の許可ポリシーは、GamesScore テーブルで一連の DynamoDB アクションに対する許可を付与します。このポリシーは dynamodb:LeadingKeys 条件キーを使用して、UserID パーティションキーの値が、このアプリケーション用の Login with Amazon の一意のユーザー ID と一致する項目のみでユーザーアクションを制限します。
重要
Scan 用のアクセス権限は、アクションのリストに含まれていません。これは、Scan が主要なキーにかかわらずすべての項目を返すためです。
{ "Version":"2012-10-17", "Statement":[ { "Sid":"FullAccessToUserItems", "Effect":"Allow", "Action":[ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem" ], "Resource":[ "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores" ], "Condition":{ "ForAllValues:StringEquals":{ "dynamodb:LeadingKeys":[ "${www.amazon.com:user_id}" ] } } } ] }
注記
ポリシー変数を使用する場合は、2012-10-17 をポリシー内で明示的に指定する必要があります。アクセスポリシー言語のデフォルトバージョン、2008-10-17 では、ポリシー変数をサポートしていません。
読み取りアクセスを実装するには、データを変更可能なアクションを削除します。次のポリシーでは、読み込み専用アクセスを提供するアクションだけが条件に追加されています。
{ "Version":"2012-10-17", "Statement":[ { "Sid":"ReadOnlyAccessToUserItems", "Effect":"Allow", "Action":[ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query" ], "Resource":[ "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores" ], "Condition":{ "ForAllValues:StringEquals":{ "dynamodb:LeadingKeys":[ "${www.amazon.com:user_id}" ] } } } ] }
重要
dynamodb:Attributes を使用する場合、ポリシーでリストに記載されているテーブルとあらゆるセカンダリインデックスについて、すべてのプライマリキー属性とインデックスキー属性の名前を指定する必要があります。指定しなかった場合、DynamoDB は、このキー属性を使用して、リクエストされたアクションを実行できません。
2: テーブルの特定の属性へのアクセスを制限するアクセス権限の付与
次のアクセス権限ポリシーは、dynamodb:Attributes 条件キーを追加して、テーブルの 2 つの特定の属性のみへアクセスを許可します。この属性に対して、読み込み、書き込み、または条件付き書き込みまたはスキャンフィルタでの評価を実行できます。
{ "Version":"2012-10-17", "Statement":[ { "Sid":"LimitAccessToSpecificAttributes", "Effect":"Allow", "Action":[ "dynamodb:UpdateItem", "dynamodb:GetItem", "dynamodb:Query", "dynamodb:BatchGetItem", "dynamodb:Scan" ], "Resource":[ "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores" ], "Condition":{ "ForAllValues:StringEquals":{ "dynamodb:Attributes":[ "UserId", "TopScore" ] }, "StringEqualsIfExists":{ "dynamodb:Select":"SPECIFIC_ATTRIBUTES", "dynamodb:ReturnValues":[ "NONE", "UPDATED_OLD", "UPDATED_NEW" ] } } } ] }
注記
このポリシーでは、許可リスト手法を使用し、列挙された一連の属性へのアクセスを許可します。代わりに、他の属性へのアクセスを拒否する同等のポリシーを記述することもできますが、この拒否リスト手法はお勧めしません。ユーザーは、ウィキペディア (http://en.wikipedia.org/wiki/Principle_of_least_privilege
このポリシーでは、PutItem、DeleteItem、または BatchWriteItem は許可されません。これらのアクションでは常に前の項目全体が置き換えられ、アクセスが許可されていない属性の以前の値を、ユーザーが削除できる可能性があるためです。
アクセス権限ポリシーの StringEqualsIfExists 句により、以下を実施することができます。
-
ユーザーが
Selectパラメータを指定する場合、その値はSPECIFIC_ATTRIBUTESである必要があります。この要件により、インデックスの射影からなど、API アクションが許可されていない属性を返さないようにします。 -
ユーザーが
ReturnValuesパラメータを指定する場合、その値は、NONE、UPDATED_OLD、またはUPDATED_NEWにする必要があります。これが必要なのは、UpdateItemアクションでは、置換する前に項目が存在するかどうかをチェックするために、および、リクエストされた場合に前の属性値を返すことができるように、暗黙的な読み込みオペレーションが実行されるためです。ReturnValuesをこのように制限することで、確実にユーザーが許可された属性だけを読み込むまたは書き込むことができるようにします。 -
StringEqualsIfExists節により、許可されたアクションのコンテキストで、リクエストごとにSelectまたはReturnValuesパラメータのいずれか 1 つだけを使用できるようにすることができます。
次に、このポリシーのバリエーションをいくつか示します。
-
読み込みアクションだけを許可するには、許可されるアクションのリストから
UpdateItemを削除できます。残りのどのアクションもReturnValuesを受け付けないので、条件からReturnValuesを削除できます。また、StringEqualsIfExistsパラメーターには必ず値 (特に指定のない限り、StringEquals) があるので、SelectをALL_ATTRIBUTESに変更できます。 -
書き込みアクションだけを許可するには、許可されるアクションのリストから、
UpdateItemを除くすべてのアクションを削除します。UpdateItemではSelectパラメーターを使用しないので、条件からSelectを削除できます。また、StringEqualsIfExistsパラメーターには必ず値 (特に指定のない限り、StringEquals) があるので、ReturnValuesをNONEに変更する必要があります。 -
名前がパターンに一致するすべての属性を許可するには、
StringLikeではなくStringEqualsを使用し、複数文字パターン照合ワイルドカード文字 (*) を使用します。
3: 特定の属性で更新を回避するアクセス権限の付与
以下のアクセス権限のポリシーでは、dynamodb:Attributes 条件キーによって識別される特定の属性のみを更新するようユーザーアクセスを制限します。StringNotLike 条件によって、アプリケーションが、dynamodb:Attributes 条件キーを使用して指定された属性を更新できないようになります。
{ "Version":"2012-10-17", "Statement":[ { "Sid":"PreventUpdatesOnCertainAttributes", "Effect":"Allow", "Action":[ "dynamodb:UpdateItem" ], "Resource":"arn:aws:dynamodb:us-west-2:123456789012:table/GameScores", "Condition":{ "ForAllValues:StringNotLike":{ "dynamodb:Attributes":[ "FreeGamesAvailable", "BossLevelUnlocked" ] }, "StringEquals":{ "dynamodb:ReturnValues":[ "NONE", "UPDATED_OLD", "UPDATED_NEW" ] } } } ] }
次の点に注意してください。
-
UpdateItemアクションは、他の書き込みアクションと同じように、更新前の値と更新後の値を返すことができるように、項目への読み取りアクセスを必要とします。ポリシーでは、dynamodb:ReturnValues条件キーを指定して、更新が許可される属性のみにアクセスするようアクションを制限します。条件キーは、リクエストのReturnValuesを制限してNONE、UPDATED_OLD、またはUPDATED_NEWのみを指定し、ALL_OLDまたはALL_NEWは含まれません。 -
PutItemおよびDeleteItemアクションは項目全体を置き換えるため、アプリケーションは任意の属性を変更することができます。したがって、特定の属性のみを更新するようアプリケーションを制限するときは、それらの API 用のアクセス権限を付与しないようにします。
4: インデックスで射影された属性のみのクエリを実行するアクセス権限の付与
以下の許可ポリシーでは、dynamodb:Attributes 条件キーを使用して、セカンダリインデックス (TopScoreDateTimeIndex) でクエリを許可します。また、このポリシーでは、インデックスに射影された特定の属性だけをリクエストするようクエリを制限します。
アプリケーションがクエリで属性のリストを指定するよう要求するには、ポリシーで dynamodb:Select 条件キーを指定して、DynamoDB Query アクションの Select パラメータが SPECIFIC_ATTRIBUTES であることを要求します。属性のリストは、dynamodb:Attributes 条件キーを使用して提供される特定のリストに制限されます。
{ "Version":"2012-10-17", "Statement":[ { "Sid":"QueryOnlyProjectedIndexAttributes", "Effect":"Allow", "Action":[ "dynamodb:Query" ], "Resource":[ "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores/index/TopScoreDateTimeIndex" ], "Condition":{ "ForAllValues:StringEquals":{ "dynamodb:Attributes":[ "TopScoreDateTime", "GameTitle", "Wins", "Losses", "Attempts" ] }, "StringEquals":{ "dynamodb:Select":"SPECIFIC_ATTRIBUTES" } } } ] }
次のアクセス権限ポリシーは、似ていますが、クエリでは、インデックスに射影されたすべての属性をリクエストする必要があります。
{ "Version":"2012-10-17", "Statement":[ { "Sid":"QueryAllIndexAttributes", "Effect":"Allow", "Action":[ "dynamodb:Query" ], "Resource":[ "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores/index/TopScoreDateTimeIndex" ], "Condition":{ "StringEquals":{ "dynamodb:Select":"ALL_PROJECTED_ATTRIBUTES" } } } ] }
5: 特定の属性とパーティションキー値へのアクセスを制限するアクセス権限の付与
以下の許可ポリシーでは、特定の DynamoDB アクション (Action 要素で指定) をテーブルとテーブルインデックス (Resource 要素で指定) で許可します。このポリシーは、dynamodb:LeadingKeys 条件キーを使用して、パーティションキーの値がユーザーの Facebook ID に一致する項目のみにアクセス権限を制限します。
{ "Version":"2012-10-17", "Statement":[ { "Sid":"LimitAccessToCertainAttributesAndKeyValues", "Effect":"Allow", "Action":[ "dynamodb:UpdateItem", "dynamodb:GetItem", "dynamodb:Query", "dynamodb:BatchGetItem" ], "Resource":[ "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores", "arn:aws:dynamodb:us-west-2:123456789012:table/GameScores/index/TopScoreDateTimeIndex" ], "Condition":{ "ForAllValues:StringEquals":{ "dynamodb:LeadingKeys":[ "${graph.facebook.com:id}" ], "dynamodb:Attributes":[ "attribute-A", "attribute-B" ] }, "StringEqualsIfExists":{ "dynamodb:Select":"SPECIFIC_ATTRIBUTES", "dynamodb:ReturnValues":[ "NONE", "UPDATED_OLD", "UPDATED_NEW" ] } } } ] }
次の点に注意してください。
-
ポリシー (
UpdateItem) によって許可された書き込みアクションでは、attribute-Aまたはattribute-Bのみを変更できます。 -
ポリシーでは
UpdateItemが許可されるため、アプリケーションは新しい項目を挿入でき、その非表示の属性は、新しい項目では null として表示されます。この属性がTopScoreDateTimeIndexに射影されている場合、テーブルからのフェッチを引き起こすクエリを防止するという利点がポリシーに追加されます。 -
アプリケーションは、
dynamodb:Attributesに列挙されている属性以外の属性を読み込むことができません。このポリシーにより、アプリケーションは、読み込みリクエストでSelectパラメータをSPECIFIC_ATTRIBUTESに設定する必要があり、許可リストの属性だけをリクエストすることができます。書き込みリクエストの場合、アプリケーションは、ReturnValuesをALL_OLDまたはALL_NEWに設定できません。また、他の属性に基づく条件付き書き込みオペレーションを実行できません。
関連トピック
