Amazon Bedrock AgentCore Identity Deep Dive

Transcript

1. Amazon Bedrock AgentCore Identity Deep Dive Fusic Tech Live vol.32 AWS Ambassador・TopEngineer・Jr.Champion大集結 2026.08.04 佐藤 礼央奈 X: @xthixsl_ml ©Fusic Co., Ltd. 0
2. はじめに 自己紹介 佐藤 礼央奈 R E O N A S AT O 株式会社Fusic エンジニア/チームリーダー 新卒2年目・MLOpsエンジニア 2026 Japan AWS Jr. Champion 2026 Japan All AWS Certifications Engineer 2026 AWS Community Builder AI Engineering 最近ハマっていること：Kaggle ©Fusic Co., Ltd. 1
3. 1. ユースケース 2. AgentCore Identity での解決策 3. アプリに残る責任と拒否テスト 4. まとめ ©Fusic Co., Ltd. 2
4. 1 ユースケース ©Fusic Co., Ltd. 3
5. ユースケース 社内の利用者 エージェント 受注管理API 「先月の受注をまとめて」と頼む AgentCore Runtimeで動く 共有APIキーで認証する この時、決めなければならないこと 01 誰に取得を許すか 02 どこに保管するか 03 どう追跡するか 04 どう更新するか workload単位で取得権限を 絞りたい コードや環境変数には置き たくない 資格情報取得と外部API呼び 出しを紐付けしたい 再デプロイせずに差し替え たい ©Fusic Co., Ltd. 4
6. 2 AgentCore Identity での解決策 ©Fusic Co., Ltd. 5
7. AgentCore Identity の解決策① 自前でやる 環境変数に1本のキー AgentCore Identity に任せる 01 どのworkloadが 取得したか 全員が同じ 1 本のキーを共有する 指定したCredential Providerに保存された共有の1 本を、権限のあるworkloadだけが取得できる 02 どこに置くか 環境変数に平文で置きっぱなしになる Token Vault が預かり、必要な時だけ渡す 03 誰が呼んだか 外部のログでは全員が同じ呼び出し元 アプリがtrace/request/session/user情報を伝播す れば、取得ログと外部呼び出しログを相関できる 04 止められるか 失効や入れ替えに再デプロイが要る Credential Providerの設定を変えれば、次回の取 得から反映される 変わるのは「どのworkloadが、いつ、どこから資格情報を受け取るか」だけ。外部への通信はアプリの責任の まま ©Fusic Co., Ltd. 6
8. AgentCore Identity の解決策② 01 02 03 04 アプリ AgentCore Identity アプリ 外部サービス WATとAPI key credential provider名を添えて、資 格情報を求める Token Vault から、指定し たproviderに保存された APIキーを返す 外部サービスが決めた形 に付け直して送る 資格情報と権限を見て 200 / 401 / 403 を返す やり取りされるもの WAT ＋ credential provider名 されたAPIキー ログの取り方 → 指定したproviderに保存 資格情報の取得と、外部サービスの呼び出しは別イベントと して記録する Runtimeから直接HTTPする構成では、AgentCore Identityが担当するのは②まで ③の送信先やヘッダー、④で通るかどうかは、アプリと外部サービスの責任で決まる （Gatewayを使う構成では、③④の一部もGatewayが担える） ©Fusic Co., Ltd. 7
9. AgentCore Identity の解決策③ Runtime で動かす場合（おまかせ） 自前のサーバーで動かす場合（自己管理） 1 本人が確定した状態をつくる ログイン済みのJWT、または信頼できるuserIdを用意する 2 アプリが自分でトークンを取る JWT方式・userId方式のどちらかを選んで呼ぶ 3 資格情報の窓口へ提示する トークンを添えて提示する（受け取り方の詳細は②へ） 1 利用者のログイン情報が届く 呼び出し元からRuntimeへ、IdPが発行した署名付きJWTア クセストークンが渡る 2 AgentCore Identity が検証する JWTを検証し、WAT（Workload Access Token）を発行す る 3 エージェントのコードに届く WorkloadAccessTokenというpayload headerに載って渡る ので、自分で取りに行かなくてよい ! 注意 ! 注意 アプリから直接トークンを取りに行くことは制限される IAM 権限は対象のディレクトリとワークロードまで絞る Gatewayでは挙動が異なる（資格情報の取得・注入・呼び 出しまで担う） ©Fusic Co., Ltd. 8
10. 3 アプリに残る責任と拒否テスト ©Fusic Co., Ltd. 9
11. アプリに残る責任と拒否テスト userId方式（ユーザーIDをそのまま渡す方式） JWT方式（IdPが発行した署名付きアクセストークンを渡 す方式） GetWorkloadAccessTokenForUserId GetWorkloadAccessTokenForJWT ID基盤（Cognito など） 呼び出し元のアプリ 「誰として動くか」を、ただの文字列として渡す AgentCore Identity その文字列が本人かどうかは確かめず、そのまま受け取る（呼び 出し元には対象workloadへのIAM権限が必要） ログインしたユーザーに、改ざんを検知できる署名付きのJWTア クセストークンを渡す AgentCore Identity 署名・発行元・有効期限を確認し、本人を特定する WATを発行 WATを発行 userIdの正しさはアプリ側の本人確認に依存する。API keyプロバ イダの場合、返るキーはuserIdに関わらずprovider共通 確認済みの本人に紐づくので、誰の資格情報かを後から説明でき る 検証で確かめたこと：任意のuserIdでも、対象workloadへのIAM権限があればWATが発行された（仕様どおり） 本人確認は AgentCore Identity ではなく、アプリ側の責任 ©Fusic Co., Ltd. 10
12. アプリに残る責任と拒否テスト 01 02 アプリ AgentCore Identity WATとAPI key credential provider名を添えて、資 格情報を求める Token Vault から、指定 したproviderに保存され たAPIキーを返す 03 アプリ 04 外部サービスが決めた形 （header名やquery parameterはAPIごとに異 なる）に付け直して送る 外部サービス 資格情報と権限を見て 200 / 401 / 403 を返す ② が成功しても、④ が 401 / 403 になることはある 「資格情報が取れた」は「外部API呼び出しが成功した」ではない。分けてログに残し、分けてテスト する ©Fusic Co., Ltd. 11
13. アプリに残る責任と拒否テスト 無効な API キー 401/403 外部サービスによって401／403など判定は異なる。AgentCore側のトークン取得は成功のまま なので、ここで初めて失敗が見える 外部サービス側で 無効と判定された OAuth トークン 外部サービスがトークンを無効と判定すると401になる（有効期限切れでもRefresh Tokenが有 効なら自動的に再取得される場合がある）。一方、別ユーザーの有効なトークンを渡すと、そ のユーザーとして受理されてしまう点に注意 403 allow-list 外の接続先 アプリが用意したallow-listに無い宛先を指定しても、固定した通信先の外には出られない （AgentCore Identityの機能ではなくアプリ独自の制御） レート制限・タイムアウト 429 / 5xx 429/5xxはレスポンスとして返るが、タイムアウトはHTTP statusが返らないまま失敗すること もある。リトライと構造化ログで検知し、認証情報そのものはログに残さない 4つとも AgentCore が肩代わりしてくれない、アプリ側で閉じるべき責任 ©Fusic Co., Ltd. 12
14. 4 まとめ ©Fusic Co., Ltd. 13
15. まとめ Point.01 AgentCore Identityに任せるのは、WATによる資格情報取得と、OAuthトークン／APIキー の安全な保管。 Point.02 アプリに残るのは、userId方式の本人確認と、Runtimeから直接HTTPする構成での送信 先・header/query・timeout/retry・外部ログ。 Point.03 成功ケースだけでなく、拒否されるべきケースが拒否されることをテストする。 ©Fusic Co., Ltd. 14
16. CONFIDENTIAL OSEKKAI × TECHNOLOGY ココロと技術で、ぴったりも、びっくりも。 ©Fusic Co., Ltd. 15