開発アカウント（Account A）のLambda関数が本番アカウント（Account B）のDynamoDBテーブルにデータを書き込む必要がある。Lambda関数の実行ロールはAccount Aに存在する。最小権限の原

Question

開発アカウント（Account A）のLambda関数が本番アカウント（Account B）のDynamoDBテーブルにデータを書き込む必要がある。Lambda関数の実行ロールはAccount Aに存在する。最小権限の原則に従ってクロスアカウントアクセスを安全に実装する方法はどれか。

Accepted Answer

正解: Account BにIAMロールを作成しAccount AのLambda実行ロールARNを信頼ポリシーに追加し、Lambda内でSTS AssumeRoleを呼び出して一時認証情報を取得する。AWSのクロスアカウントアクセス推奨パターンはSTS AssumeRole。Account Bのロール信頼ポリシーにAccount AのLambda実行ロールARNを設定し、Lambda関数がAssumeRoleで一時認証情報を取得する。

Answer

Account BのDynamoDBテーブルにリソースベースポリシーをアタッチし、Account AのLambda実行ロールARNをPrincipalに指定してSTS AssumeRoleなしで直接アクセスを許可する — DynamoDBはリソースベースポリシーをサポートしており技術的には可能だが、リソース側ポリシーとAccount A側IAMポリシーの双方向管理が必要になりSTS AssumeRoleを用いたロールベース委任より権限の一元管理が難しい。

Answer

Account AのLambda実行ロールにAccount BのDynamoDBテーブルへの書き込み権限を追加し、AWSが自動的にクロスアカウントルーティングでAPI呼び出しを処理する — IAMロールのポリシーにクロスアカウントリソースを記述しても、対象アカウント（Account B）での信頼関係設定なしにAWSが自動的にアクセスを許可することはない。

Answer

Account BにIAMユーザーを作成してアクセスキーを発行し、Account AのSecrets Managerにキーを保存してLambda関数から動的に取得してDynamoDBを操作する — IAMユーザーの長期アクセスキーはローテーション管理リスクがあり、Secrets Managerに保存してもSTS一時認証情報を使うAssumeRoleよりセキュリティリスクが高い。

解説