ある SaaS 企業は、マルチテナント型のユーザープロフィール管理システムを Amazon DynamoDB で構築しています。テーブルのパーティションキーは userId であり、各ユーザーはセッションごとに発行された

Question

ある SaaS 企業は、マルチテナント型のユーザープロフィール管理システムを Amazon DynamoDB で構築しています。テーブルのパーティションキーは userId であり、各ユーザーはセッションごとに発行された IAM 一時認証情報を使ってアクセスします。セキュリティ要件として、各ユーザーは自分の userId に一致するアイテムのみにアクセス可能とし、他ユーザーのデータには一切アクセスできないようにする必要があります。アプリケーションコードの変更を最小限に抑えつつ、IAM レベルでこのアイテム単位のアクセス制御を実現する方法として最も適切なものはどれですか？

Accepted Answer

正解: IAMポリシーの dynamodb:LeadingKeys 条件に ${aws:PrincipalTag/userId} を指定し、セッションタグの userId と一致するアイテムへのアクセスのみを許可する。DynamoDB Fine-Grained Access Control（FGAC）では、IAMポリシーの条件キー dynamodb:LeadingKeys を使用することでアイテムレベルのアクセス制御が実現できます。${aws:PrincipalTag/userId} と組み合わせると、STS の AssumeRoleWithWebIdentity などでセッションタグを付与し、そのタグ値と一致するパーティションキーのアイテムのみに自動的にアクセスを制限できます。IAM ポリシーレベルで制御するため、アプリケーションコードの変更なしに実現可能です。

選択肢Bのテーブル分割アプローチは、テナント数が増えるほど管理リソース数が増大し、スケーラビリティと運用コストの面で非効率です。
選択肢CのLambdaオーソライザーはアプリケーション層での実装変更が必要で、IAM レベルの制御という要件を満たしません。
選択肢DのCognito ID プールはWebアプリの認証フローには適していますが、テーブル全体への読み取り権限付与ではアイテムレベルの分離ができず要件を満たしません。

Answer

DynamoDB テーブルをテナントごとに分割し、各テナント向けに個別の IAM ロールとリソースベースのポリシーを作成してアクセスを制御・管理する — テーブルをテナントごとに分割するとテナント数分のリソースとIAMロールが必要となり、スケールアウト時の管理コストが増大します。DynamoDB FGACを使えば一つのテーブルでアイテムレベルの分離を効率的に実現できます。

Answer

AWS Lambda オーソライザーでリクエストを検証し、userId の一致を確認した後に DynamoDB GetItem を実行するようアプリケーションアーキテクチャを変更して制御する — Lambdaオーソライザーはアプリケーション層でのコード変更が必要で、「アプリケーションコードの変更を最小限に抑える」という要件に反します。IAMポリシーの条件キーで対応できる要件に対して実装コストが不必要に高くなります。

Answer

Amazon Cognito ユーザープールのカスタム属性に userId を格納し、Cognito ID プールで認証後に DynamoDB テーブル全体への読み取り権限をユーザーセッションに付与する — Cognito ID プールは認証後の一時認証情報発行に使用できますが、DynamoDB アイテムレベルのアクセス分離はIAMポリシーの dynamodb:LeadingKeys で実装する必要があります。テーブル全体への読み取り許可では他テナントのデータにアクセス可能になります。

解説

解説