DEAデータのセキュリティとガバナンス
あるゲーム企業は、プレイヤーのプロフィールを Amazon DynamoDB の Players テーブル（パーティションキーが UserId）に保存しています。モバイルアプリは Amazon Cognito で認証され、各プレイヤーは自分の UserId に一致する項目のみ読み書きできる必要があります。最小の運用負荷でこのアクセス制御を実現する方法はどれですか。
ADynamoDB テーブルに対し、Cognito ID をキーとする項目レベルの暗号化を AWS KMS で個別に適用する
項目レベルの KMS 暗号化はデータ保護には有効だが、特定プレイヤーが自分の項目のみアクセスできるという認可制御は実現できない。暗号化とアクセス制御は別の課題であり、要件を満たさない。
BIAM ロールの信頼ポリシーで Cognito を許可し、ポリシー条件に dynamodb:LeadingKeys と ${cognito-identity.amazonaws.com:sub} を指定する
✓ 正解
DynamoDB の条件キー dynamodb:LeadingKeys にCognito の sub を指定すると、認証 ID とパーティションキーが一致する項目のみアクセスを許可できる。コード不要で FGAC を実現でき運用負荷が最小のため要件に最適。
C各プレイヤーごとに専用の DynamoDB テーブルを作成し、テーブル単位の IAM ポリシーでアクセスを分離する
プレイヤーごとにテーブルを作る設計は項目分離は可能だが、ユーザー数に比例してテーブルが増え管理不能になる。スケーラビリティと運用負荷の両面で不適切。
DLambda オーソライザーを介して全リクエストを検証し、UserId が一致しない場合は拒否するロジックを実装する
Lambda オーソライザーで UserId を検証する方式は実現可能だが、認可ロジックを自前で実装・維持する必要があり、ネイティブの FGAC を使う方法に比べ運用負荷が大きい。
解説
DynamoDB のファイングレインドアクセスコントロール（FGAC）は、IAM ポリシーの条件キー dynamodb:LeadingKeys を使って、リクエスト元の認証済み ID をパーティションキーの値と一致させることで項目レベルのアクセスを制御できる。
Cognito ID プールが発行する一時認証情報の ${cognito-identity.amazonaws.com:sub} を LeadingKeys に紐づければ、各プレイヤーは自分の UserId 項目のみアクセス可能となり、追加コードやインフラが不要で運用負荷が最小となる。
選択肢Aの項目レベル KMS 暗号化は、データの暗号化はできるがアクセス権限の分離（誰がどの項目を読めるか）の制御はできない。
選択肢Cのプレイヤーごとのテーブル作成は、テーブル数が膨大になりスケールせず運用負荷が極めて高い。
選択肢Dの Lambda オーソライザーは、カスタムロジックの実装・保守が必要で、FGAC を使う方法より運用負荷が大きい。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでDEAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →