詳細に設定されたアクセスコントロールのための IAM ポリシー条件の使用
DynamoDB で許可を付与するときは、許可ポリシーを有効にする方法を決める条件を指定できます。
概要
DynamoDB では、IAM ポリシー (Amazon DynamoDB の Identity and Access Management を参照) を使用して許可を付与するとき、条件を指定することもできます。たとえば、以下のことが可能です。
-
テーブル内またはセカンダリインデックスの特定の項目と属性に対する読み込み専用アクセスをユーザーに許可する許可を付与します。
-
ユーザーのアイデンティティに基づいて、テーブルの特定の属性への書き込み専用アクセスのアクセス権限をユーザーに付与します。
DynamoDB では、次のセクションのユースケースに示すように、条件キーを使用して IAM ポリシーの条件を指定できます。
アクセス権限のユースケース
DynamoDB API アクションへのアクセスを制御するだけでなく、個別のデータ項目と属性へのアクセスも制御できます。例えば、次の操作を実行できます。
-
テーブルでアクセス権限を付与しますが、特定のプライマリキー値に基づいて、そのテーブル内の特定の項目へのアクセスを制限します。この例として、ゲーム用のソーシャルネットワーキングアプリケーションがあります。次の図に示すように、すべてのユーザーのゲームデータは 1 つのテーブルに保存されますが、いずれのユーザーも、自分が所有していないデータ項目にアクセスすることはできません。
-
属性のサブセットのみがユーザー表示されるように、情報を非表示にします。この例として、ユーザーの位置に基づいて、近くの空港の運航便データを表示するアプリケーションがあります。航空会社名、到着時間、出発時間、および運航便番号がすべて表示されます。ただし、次の図に示すように、パイロット名や乗客数などの属性は非表示になります。
このような種類のきめ細かなアクセス制御を実装するには、セキュリティ認証情報と関連する許可にアクセスするための条件を指定した IAM 許可ポリシーを書き込みます。次に、IAM コンソールを使用して作成する ユーザー、グループ、またはロールにそのポリシーを適用します。IAM ポリシーによって、テーブルの個別項目へのアクセス、その項目の属性へのアクセス、またはその両方へのアクセスを同時に制御できます。
必要に応じて、ウェブアイデンティティフェデレーションを使用して、Login with Amazon、Facebook、または Google によって認証されるユーザーによるアクセスを制御できます。詳細については、「」を参照してくださいウェブ ID フェデレーションの使用
IAM の Condition 要素を使用して、詳細なアクセスコントロールポリシーを実装できます。Condition 要素を許可ポリシーに追加することで、特定のビジネス要件に基づいて、DynamoDB テーブルとインデックスの項目と属性へのアクセスを許可または拒否できます。
次の動画では、IAM ポリシー条件を使用した DynamoDB でのきめ細かなアクセスコントロールについて説明します。
DynamoDB でのきめ細かなアクセスコントロールを理解する
DynamoDB でのきめ細かなアクセスコントロールにより、複数のレベルで正確なアクセス許可の境界を作成できます。
-
項目レベルのアクセスコントロール: 通常は、ID またはアクセス許可の範囲と一致する特定のキー値を含む項目のみにユーザーによるアクセスを制限します。
-
属性レベルのアクセスコントロール: ユーザーが表示または変更できる属性 (列) を制限し、機密情報を保護しながら、同じ項目内の非機密データへのアクセスを許可します。
-
オペレーション固有のコントロール: 実行するオペレーションのタイプに基づいて異なるアクセス許可ルールを適用します。
これらのコントロールは、DynamoDB 固有の条件キーを使用して IAM ポリシーを通じて実装されます。
条件の指定: 条件キーの使用
AWS には、アクセス制御のために IAM をサポートするすべての AWS サービスに合わせて事前定義された一連の条件キー (AWS 全体に対する条件キー) が用意されています。たとえば、aws:SourceIp 条件キーを使用して、リクエスタの IP アドレスを確認してから、アクションの実行を許可できます。AWS 全体を対象とするキーの詳細およびリストについては、IAM ユーザーガイドの使用可能な条件キーを参照してください。
以下は、DynamoDB に適用される DynamoDB サービス固有の条件キーを示しています。
dynamodb:LeadingKeys-
テーブルの最初のキー属性、つまりパーティションキーを表します。キーが 1 つの項目のアクションで使用される場合も、キー名
LeadingKeysは複数形になります。また、条件でForAllValuesを使用するときには、LeadingKeys修飾子を使用する必要があります。 dynamodb:Select-
リクエストの
Selectパラメータを表します。Selectには次のいずれかの値を指定できます。-
ALL_ATTRIBUTES -
ALL_PROJECTED_ATTRIBUTES -
SPECIFIC_ATTRIBUTES -
COUNT
注記
多くの場合、この条件キーはクエリおよびスキャンオペレーションに関連付けられますが、項目属性を返すすべての DynamoDB オペレーションに適用され、すべての API アクションで属性アクセスを制御するために不可欠です。この条件キーに StringEqualsIfExists または同様の制約を使用すると、この条件キーが適用されるオペレーションに制約が適用され、適用されないオペレーションでは制約が無視されます。
-
dynamodb:Attributes-
リクエストによってアクセスされる最上位属性のリストを表します。最上位属性は、それ自身かその入れ子の属性がリクエストパラメータで指定されている場合、リクエストによってアクセスされます。例えば、
"Name, Address.City"のProjectionExpressionを指定するGetItemリクエストの場合、dynamodb:Attributesリストには「名前」と「住所」が含まれます。Attributesパラメータがきめ細かなアクセスコントロールポリシーで列挙されている場合は、GetItem、Query、Scanなどの複数の API アクションで指定された属性へのアクセスが制限されるように、ReturnValuesパラメータとSelectパラメータも制限することを検討してください。注記
この条件は、レスポンスの属性ではなく、リクエストで指定された属性 (ProjectionExpression など) に対してのみ評価されます。リクエストに ProjectionExpression が指定されていない場合、ポリシーの属性制限に関係なく、すべての属性が返されます。属性アクセスを適切に保護する方法の詳細については、以下の「属性ベースの制限を確実に適用する」セクションを参照してください。
dynamodb:ReturnValues-
リクエストの
ReturnValuesパラメータを表します。API アクションに応じて、ReturnValuesは次のいずれかの値になります。-
ALL_OLD -
UPDATED_OLD -
ALL_NEW -
UPDATED_NEW -
NONE
-
dynamodb:ReturnConsumedCapacity-
リクエストの
ReturnConsumedCapacityパラメータを表します。ReturnConsumedCapacityには次のいずれかの値を指定できます。-
TOTAL -
NONE
-
dynamodb:FirstPartitionKeyValues-
テーブルの最初のキー属性、つまり最初のパーティションキーを表します。キーが 1 つの項目のアクションで使用される場合も、キー名
FirstPartitionKeyValuesは複数形になります。また、条件でFirstPartitionKeyValuesを使用するときには、ForAllValues修飾子を使用する必要があります。FirstPartitionKeyValuesとLeadingKeysの使用は交換可能です。 dynamodb:SecondPartitionKeyValues-
dynamodb:FirstPartitionKeyValuesと同様です。リソースの 2 番目のパーティションキーを表します。キーが 1 つの項目のアクションで使用される場合も、キー名SecondPartitionKeyValuesは複数形になります。 dynamodb:ThirdPartitionKeyValues-
dynamodb:FirstPartitionKeyValuesと同様です。リソースの 3 番目のパーティションキーを表します。キーが 1 つの項目のアクションで使用される場合も、キー名ThirdPartitionKeyValuesは複数形になります。 dynamodb:FourthPartitionKeyValues-
dynamodb:FirstPartitionKeyValuesと同様です。リソースの 4 番目のパーティションキーを表します。キーが 1 つの項目のアクションで使用される場合も、キー名FourthPartitionKeyValuesは複数形になります。
属性ベースの制限を確実に適用する
属性ベースの条件を使用して特定の属性へのアクセスを制限する場合は、これらの条件がどのように評価されるかを理解することが重要です。
-
レスポンスの属性ではなく、属性条件は、リクエストで指定された属性でのみ評価されます。
-
ProjectionExpression を使用しない読み取りオペレーション (GetItem、Query、Scan など) の場合、ポリシーの属性制限に関係なく、すべての属性が返されます。この機密データの潜在的な漏洩を防ぐには、属性条件 (
dynamodb:Attributes) と特定の属性を必要とする条件 (dynamodb:Select) の両方を実装する必要があります。 -
書き込みオペレーション (PutItem、UpdateItem、DeleteItem) の場合、ReturnValues パラメータは完全な項目を返すことができ、書き込みオペレーション自体がポリシーに準拠している場合でも、制限された属性が公開される可能性があります。この露出を防ぐには、ポリシーに属性条件 (
dynamodb:Attributes) と ReturnValues (dynamodb:ReturnValues) の制限の両方を実装します。
ユーザーアクセスの制限
多くの IAM アクセス権限ポリシーでは、パーティションキーの値がユーザー識別子と一致するテーブルの項目へのアクセスのみをユーザーに許可します。たとえば、前述のゲームアプリケーションは、この方法でアクセスを制限し、ユーザーは自分のユーザー ID に関連付けらたゲームデータのみにアクセスできるようにします。IAM 置換変数 ${www.amazon.com:user_id}、${graph.facebook.com:id}、および ${accounts.google.com:sub} には、Login with Amazon、Facebook、および Google のユーザー識別子が格納されます。アプリケーションがこのようなアイデンティティプロバイダーのいずれかにログインし、この識別子を取得する方法については、「ウェブ ID フェデレーションの使用」を参照してください。
重要
グローバルテーブルのレプリケーションを制限する場合、きめ細かなアクセスコントロールはサポートされていません。グローバルテーブルのレプリケーションに使用される DynamoDB サービスプリンシパルまたはサービスにリンクされたロールにきめ細かなアクセスコントロールのポリシー条件を適用すると、グローバルテーブル内のレプリケーションが中断される可能性があります。
注記
以下のセクションの各例では、Effect 句を Allow に設定し、許可されるアクション、リソース、およびパラメータのみを指定します。IAM ポリシーで明示的に指定されたものへのアクセスだけが許可されます。
場合によっては、拒否ベースとなるようにこのポリシーを書き直すことができます。つまり、Effect 句を Deny に設定して、ポリシーのすべてのロジックを逆にします。ただし、拒否ベースのポリシーを DynamoDB で使用しないようお勧めします。このようなポリシーは、許可ベースのポリシーと比べて、正しく記述するのが難しいためです。また、DynamoDB API への将来の変更 (または、既存の API 入力への変更) が原因で、拒否ベースのポリシーが機能しなくなる可能性があります。
ポリシー例: きめ細かなアクセスコントロールのための IAM ポリシー条件の使用
このセクションでは、DynamoDB テーブルとインデックスに対してきめ細かなアクセス制御を実装するための一部のポリシーについて説明します。
注記
すべての例で、us-west-2 リージョンを使用し、架空のアカウント ID を含めています。
例 1。属性制限付きの基本的なパーティションキーベースのアクセスコントロール
例として、プレーヤーがさまざまなゲームを選択してプレイできるモバイルゲームアプリケーションを考えてみます。このアプリケーションでは、GameScores という名前の DynamoDB テーブルを使用して、高スコアなどのユーザーデータを記録します。テーブルの各項目は、ユーザー ID とユーザーがプレイしたゲームの名前で一意に識別されます。GameScores テーブルには、パーティションキー (UserId) およびソートキー (GameTitle) で構成されているプライマリキーがあります。ユーザーは、そのユーザー ID に関連付けられたゲームデータだけにアクセスできます。ゲームをプレイするユーザーは、GameRole という名前の IAM ロールに属する必要があります。このロールには、セキュリティポリシーが添付されています。
このアプリケーションのユーザーアクセス権限を管理するには、次のようなアクセス権限ポリシーを記述できます。
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 の範囲内の文字。
例 2: 特定のパーティションのキー値を持つ項目へのアクセスを制限するアクセス許可の付与
以下の許可ポリシーは、GamesScore テーブルで一連の DynamoDB アクションに対する許可を付与します。このポリシーは dynamodb:LeadingKeys 条件キーを使用して、UserID パーティションキーの値が、このアプリケーション用の Login with Amazon の一意のユーザー ID と一致する項目のみでユーザーアクションを制限します。
重要
Scan 用のアクセス権限は、アクションのリストに含まれていません。これは、Scan が主要なキーにかかわらずすべての項目を返すためです。
注記
ポリシー変数を使用する場合は、ポリシーでバージョン 2012-10-17 を明示的に指定する必要があります。アクセスポリシー言語のデフォルトバージョンは 2008−10−17 です。このバージョンでは、ポリシー変数をサポートしていません。
読み取りアクセスを実装するには、データを変更可能なアクションを削除します。次のポリシーでは、読み込み専用アクセスを提供するアクションだけが条件に追加されています。
重要
dynamodb:Attributes を使用する場合、ポリシーでリストに記載されているテーブルとあらゆるセカンダリインデックスについて、すべてのプライマリキー属性とインデックスキー属性の名前を指定する必要があります。指定しなかった場合、DynamoDB は、このキー属性を使用して、リクエストされたアクションを実行できません。
例 3: テーブルの特定の属性へのアクセスを制限するアクセス許可の付与
次のアクセス権限ポリシーは、dynamodb:Attributes 条件キーを追加して、テーブルの 2 つの特定の属性のみへアクセスを許可します。この属性に対して、読み込み、書き込み、または条件付き書き込みまたはスキャンフィルタでの評価を実行できます。
注記
このポリシーでは、許可リスト手法を使用し、列挙された一連の属性へのアクセスを許可します。代わりに、他の属性へのアクセスを拒否する同等のポリシーを記述することもできますが、この拒否リスト手法はお勧めしません。ユーザーは、ウィキペディア (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を使用し、複数文字パターン照合ワイルドカード文字 (*) を使用します。
例 4: 特定の属性で更新を回避するアクセス許可の付与
以下のアクセス権限のポリシーでは、dynamodb:Attributes 条件キーによって識別される特定の属性のみを更新するようユーザーアクセスを制限します。StringNotLike 条件によって、アプリケーションが、dynamodb:Attributes 条件キーを使用して指定された属性を更新できないようになります。
次の点に注意してください。
-
UpdateItemアクションは、他の書き込みアクションと同じように、更新前の値と更新後の値を返すことができるように、項目への読み取りアクセスを必要とします。ポリシーでは、dynamodb:ReturnValues条件キーを指定して、更新が許可される属性のみにアクセスするようアクションを制限します。条件キーは、リクエストのReturnValuesを制限してNONE、UPDATED_OLD、またはUPDATED_NEWのみを指定し、ALL_OLDまたはALL_NEWは含まれません。 -
StringEqualsIfExists演算子は、リクエストにdynamodb:Selectまたはdynamodb:ReturnValuesが存在する場合、指定された値と一致することを保証します。これにより、オペレーションが完全な項目を返すのを防ぐことができます。 -
属性の更新を制限するときは、どのデータを返すことができるかを制御して、保護された属性の情報開示を防ぐ必要があります。
-
PutItemおよびDeleteItemアクションは項目全体を置き換えるため、アプリケーションは任意の属性を変更することができます。したがって、特定の属性のみを更新するようアプリケーションを制限するときは、それらの API 用のアクセス権限を付与しないようにします。
例 5: インデックスで射影された属性のみのクエリを実行するアクセス許可の付与
以下の許可ポリシーでは、dynamodb:Attributes 条件キーを使用して、セカンダリインデックス (TopScoreDateTimeIndex) でクエリを許可します。また、このポリシーでは、インデックスに射影された特定の属性だけをリクエストするようクエリを制限します。
アプリケーションがクエリで属性のリストを指定するよう要求するには、ポリシーで dynamodb:Select 条件キーを指定して、DynamoDB Query アクションの Select パラメータが SPECIFIC_ATTRIBUTES であることを要求します。属性のリストは、dynamodb:Attributes 条件キーを使用して提供される特定のリストに制限されます。
次のアクセス権限ポリシーは、似ていますが、クエリでは、インデックスに射影されたすべての属性をリクエストする必要があります。
例 6: 特定の属性とパーティションキー値へのアクセスを制限するアクセス許可の付与
以下の許可ポリシーでは、特定の DynamoDB アクション (Action 要素で指定) をテーブルとテーブルインデックス (Resource 要素で指定) で許可します。このポリシーは、dynamodb:LeadingKeys 条件キーを使用して、パーティションキーの値がユーザーの Facebook ID に一致する項目のみにアクセス許可を制限します。
次の点に注意してください。
-
ポリシー (
UpdateItem) によって許可された書き込みアクションでは、attribute-A または attribute-B のみを変更できます。 -
ポリシーでは
UpdateItemが許可されるため、アプリケーションは新しい項目を挿入でき、その非表示の属性は、新しい項目では null として表示されます。この属性がTopScoreDateTimeIndexに射影されている場合、テーブルからのフェッチを引き起こすクエリを防止するという利点がポリシーに追加されます。 -
アプリケーションは、
dynamodb:Attributesに列挙されている属性以外の属性を読み込むことができません。このポリシーにより、アプリケーションは、読み込みリクエストでSelectパラメータをSPECIFIC_ATTRIBUTESに設定する必要があり、許可リストの属性だけをリクエストすることができます。書き込みリクエストの場合、アプリケーションは、ReturnValuesをALL_OLDまたはALL_NEWに設定できません。また、他の属性に基づく条件付き書き込みオペレーションを実行できません。
例 7: テーブルの特定の属性へのアクセスを制限するアクセス許可の拒否
次のポリシーは、機密属性へのアクセスを拒否し、射影式を省略してこの制限を回避できないようにします。これにより、CustomerData テーブルへの一般的なアクセスを許可しますが、SSN および CreditCardNumber 属性へのアクセスは明示的に拒否します。