大企業の中央AIプラットフォームチームがAWSアカウントA（Account A）でAmazon Bedrock Provisioned Throughput（専用キャパシティ）を管理しています。複数の事業部門アプリケーシ

Question

大企業の中央AIプラットフォームチームがAWSアカウントA（Account A）でAmazon Bedrock Provisioned Throughput（専用キャパシティ）を管理しています。複数の事業部門アプリケーションがAWSアカウントB（Account B）からこのモデルをInvokeする必要があります。AWSのセキュリティベストプラクティスと最小権限の原則に従い、永続的な認証情報を共有せずにクロスアカウントアクセスを実現する最も適切な方法はどれですか？

Accepted Answer

正解: Account AでIAMロール（bedrock:InvokeModel権限付き）を作成してAccount BのプリンシパルをTrusted Entityに設定し、Account BはSTS AssumeRoleで取得した一時認証情報を使ってBedrockを呼び出す。クロスアカウントアクセスの実現方法を選択肢ごとに解説します。

選択肢AはIAMユーザーのアクセスキーを設定ファイルに保存する方法であり、永続的な認証情報の漏洩リスクが高くセキュリティアンチパターンです。

選択肢BはSTS AssumeRoleを使ったクロスアカウントIAMロール引き受けで、一時認証情報（デフォルト1時間で失効）を使用するためキー漏洩リスクが低く、最小権限の原則を守りながらアクセスを付与できるAWSのベストプラクティスです。

選択肢CはBedrock Provisioned ThroughputモデルのリソースベースポリシーでPrincipalをワイルドカード（*）に設定する方法であり、最小権限の原則に反します。

選択肢DはSystems Manager Parameter StoreにIAMユーザー認証情報を保存する方法であり、永続的な認証情報を管理するアーキテクチャ自体がセキュリティアンチパターンです。

Answer

Account AでIAMユーザーを作成しアクセスキーを発行し、Account BのアプリケーションのAWS SDK設定ファイルにそのアクセスキーを保存してBedrockを呼び出す — IAMユーザーのアクセスキーをSDK設定ファイルに静的に保存する方法は、漏洩時の影響が大きくローテーションも困難です。永続的なキーの配布・保存はAWSのセキュリティベストプラクティスに反するアンチパターンです。

Answer

Bedrock Provisioned ThroughputモデルのリソースベースポリシーでPrincipalをワイルドカード（*）に設定し、Account BのIPアドレス範囲のみにアクセスを制限するConditionを追加する — Principalをワイルドカード（*）に設定すると誰でもモデルを呼び出せる状態になり最小権限の原則に反します。IPアドレス制限のみでは十分なアクセス制御にならずセキュリティ上のリスクが残ります。

Answer

Account BのEC2インスタンスにAWS Systems Manager Parameter Storeを使用してAccount AのIAMユーザー認証情報を安全に保存し、アプリケーション起動時に取得してBedrockを呼び出す — Parameter StoreでIAMユーザーの永続的なアクセスキーを保管する設計は認証情報の適切な管理を複雑にし漏洩リスクも残します。一時認証情報を活用するSTS AssumeRoleパターンに設計を変更すべきです。