DEAデータのセキュリティとガバナンス
あるスタートアップは、モバイルアプリの数百万ユーザーのプロファイルを単一の Amazon DynamoDB テーブル（パーティションキー: UserId）に保存しています。各ユーザーは Amazon Cognito で認証され、自分の UserId に一致するアイテムのみ読み書きでき、他ユーザーのアイテムには一切アクセスできないようにする必要があります。テーブル数の増加を避けつつ、最小の運用負荷でこのアクセス制御を実現する方法はどれですか。
AIAM ポリシーで dynamodb:LeadingKeys 条件キーを使い、許可するパーティションキーを Cognito ID に限定する
✓ 正解
dynamodb:LeadingKeys 条件キーは、リクエストのパーティションキーが指定値と一致する場合のみ操作を許可する FGAC 機能。Cognito ID を割り当てれば単一テーブルのまま各ユーザーを自分のアイテムに限定でき、追加インフラ不要で運用負荷も最小になる。
Bユーザーごとに個別の DynamoDB テーブルを作成し、各テーブル ARN を指定した IAM ポリシーをユーザーに付与する
ユーザーごとのテーブル作成は数百万のテーブルとアカウント制限・管理コストを生み、現実的にスケールしない。FGAC を使えば単一テーブルで同じ分離を実現できるため、テーブル分割は不要かつ運用負荷が過大になる。
Cすべてのリクエストを Lambda 関数経由にし、関数内でリクエスト元の UserId とアイテムを照合してフィルタリングする
Lambda 経由で照合する方式は要件を満たせるが、認可ロジックの実装・テスト・保守を自前で抱えることになる。IAM 条件キーで宣言的に制御できる FGAC に比べ運用負荷が高く、最小運用負荷という条件に反する。
Dテーブルに KMS カスタマーマネージドキーを設定し、キーポリシーの条件でユーザーごとにアイテムを制限する
KMS カスタマーマネージドキーとキーポリシーは保存データの暗号化と鍵使用権限を制御するもので、テーブル内の特定アイテム（行）へのアクセス可否は制御できない。データレベルのアクセス分離の要件には機能的に対応しない。
解説
DynamoDB のファイングレインドアクセスコントロール（FGAC）は、IAM ポリシーの dynamodb:LeadingKeys 条件キーでアクセス可能なパーティションキーを制限できます。
値を Cognito ID（${cognito-identity.amazonaws.com:sub}）と一致させることで、各ユーザーは自分の UserId のアイテムのみ操作でき、単一テーブルのまま追加インフラなしで実現できます。
選択肢のユーザーごとのテーブル作成は、数百万テーブルとなりスケール・管理が破綻する。
選択肢の Lambda 経由フィルタリングは、独自ロジックの実装・運用が必要で運用負荷が高い。
選択肢の KMS キーポリシーは、暗号化のアクセス制御でありアイテム単位のデータアクセス制御には使えない。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDEAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →