ひとことで言うと
IAM 自体は生成AI固有のサービスではありません。Bedrock・エージェント・Knowledge Base が何にアクセスできるかを決める、権限の最終防衛線です。
要するに、又貸し禁止の合鍵です。Bedrock サービスに「エージェント実行ロール」という合鍵を渡すとき、渡しっぱなしにはしません。信頼ポリシーに「この合鍵は自分のアカウントの、このエージェントIDのためだけに使ってよい」という条件を刻みます。刻まなければ、理屈の上では他人の建物でもこの合鍵が使える状態になります。
なぜ生まれたか
| IAM が無いと | IAM 側の受け皿 |
|---|---|
| Bedrock サービス自体に無制限の権限を持たせるしかない | サービスロール（実行ロール）に必要な権限だけを列挙 |
| 別アカウントの誰かが自分のロールを勝手に引き受けられる（混乱した代理人問題） | 信頼ポリシーに aws:SourceAccount / ArnLike の AWS:SourceArn 条件 |
| エージェントの Lambda アクションが誰からでも呼べてしまう | Lambda 側のリソースベースポリシーで呼び出し元を Bedrock かつ特定エージェントに限定 |
Bedrock のエージェント・Knowledge Base はいずれも AWS が自動生成するデフォルトロールを持ちますが、公式ドキュメントは「必要な権限だけを含めるカスタムロールを作る」ことを前提に手順を示しています。デフォルトのまま使うと、想定より広い権限が残ることがあります。
何に使うか
| 用途 | 使い方 | 関連ドメイン |
|---|---|---|
| Bedrock サービスロールの信頼ポリシー | bedrock.amazonaws.com を Principal にし、sts:AssumeRole を許可 | D2 |
| モデル呼び出しの権限 | bedrock:InvokeModel を特定の基盤モデル ARN に限定 | D1・D2 |
| エージェントの Lambda 呼び出し許可 | Lambda のリソースベースポリシーで AWS:SourceArn をエージェント ARN に限定 | D2 |
| ガードレール・KMS キーの利用許可 | bedrock:ApplyGuardrail や kms:Decrypt を個別に付与 | D3 |
試験でどう問われるか
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| エージェントが想定外のS3バケットまで触れてしまう | 権限が広すぎる → サービスロールを用途ごとに分離し必要な ARN だけ許可 | 1つの共通ロールに全権限をまとめて使い回す |
| 他アカウントが自分のBedrockロールを引き受けられないか心配 | 混乱した代理人対策 → 信頼ポリシーに aws:SourceAccount と ArnLike の AWS:SourceArn | ロールのARNを非公開にするだけで対策とする |
| エージェントのアクショングループ（Lambda）を誰でも呼べる状態にしたくない | Lambda 側のリソースベースポリシーで呼び出し元をBedrock＋エージェントARNに限定 | エージェントの実行ロールにLambda呼び出し権限を足すだけで済ませる |
| ガードレールをKMSで暗号化していて、エージェントから使うと失敗する | 実行ロールに kms:Decrypt が個別に必要 | ガードレールを紐づけるだけで暗号化キーの権限は不要と考える |
IAM は D2（実装・統合）と D3（安全性・セキュリティ・ガバナンス）の両方に顔を出します。シナリオが「動かない・繋がらない」なら D2 寄り、「漏れる・奪われる」なら D3 寄りの文脈で権限設計を読むと選択肢が絞りやすくなります。
実務でどう使うか
- エージェント・Knowledge Base は用途別にサービスロールを分ける。 1つのロールに全アクショングループ・全データソースの権限を積むと、事故時の影響範囲がそのまま全体になります
- 信頼ポリシーの
{{*}}は本番では具体的なリソースIDに絞る。 公式手順もワイルドカードは作成直後の一時的なものとして案内しています - KMS で暗号化したガードレール・Knowledge Base・データソースを使うたびに、対応する
kms:Decrypt系の権限を個別に足す必要があります。 ガードレールやKBを紐づけただけでは復号権限は付与されません
Knowledge Base のカスタムサービスロール自体には、KMSキーポリシー側の権限は不要です（キーポリシーは「誰がロールを作れるか」を制御し、ロールが実際にデータを扱う権限は別に付与します）。両者を混同すると、権限は足りているのに動かない原因を見誤ります。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| IAM Identity Center | IAM は AWS内部のプリンシパル（サービスロール等）の権限。Identity Center は人間のワークフォースが複数アカウントへサインインする仕組み |
| Amazon Cognito | Cognito はアプリのエンドユーザーの認証・認可。IAM は AWSリソース側（Bedrock・Lambda等）の権限 |
| AWS Secrets Manager | IAM は「誰が何をできるか」の許可。Secrets Manager は値そのもの（APIキー・パスワード）の保管 |
| IAM Access Analyzer | IAM はポリシーを設定する側。Access Analyzer は設定されたポリシーの結果を事後に検査する側 |
想起チェック
Q1. Bedrock がエージェント実行ロールを引き受けるとき、他アカウントに悪用されないようにする条件は？
信頼ポリシーの Condition に aws:SourceAccount（自アカウントID）と ArnLike の AWS:SourceArn（特定のエージェントARN） を指定します。これが無いと、理論上は他アカウントのBedrockからもこのロールを引き受けられる状態になります。
Q2. エージェントのアクショングループ用Lambda関数を、Bedrock以外から呼び出せないようにするには？
Lambda のリソースベースポリシーに、Principal を bedrock.amazonaws.com、AWS:SourceArn をエージェントARNとする条件を付けて lambda:InvokeFunction を許可します。実行ロール側の権限だけでは、呼び出し元を制限できません。