Amazon ECS で Amazon Bedrock AgentCore Identity を使用して AI エージェントを保護

本番環境における AI エージェントは、外部サービスへの安全なアクセスを必要とします。スタンドアロンサービスとして利用可能な Amazon Bedrock AgentCore Identity は、AI エージェントが [Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html)、[Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html)、[AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html) といった計算プラットフォーム上で動作する場合や、オンプレミス環境で動作する場合にかかわらず、外部サービスへのアクセス方法を保護します。 以前の [投稿](https://aws.amazon.com/blogs/security/securing-ai-agents-with-amazon-bedrock-agentcore-identity/) では、AI エージェント向けの AgentCore Identity による資格情報管理について取り上げました。ECS などの計算環境上でエージェントを実行する際、2 つの重要な問いが生じます。すなわち、「アプリケーション所有のセッションバインディングエンドポイントをどのように構築するか」および「ワークロードアクセストークンのライフサイクルをどのように管理するか」という点です。 本投稿では、Amazon ECS 上で安全なセッションバインディングとスコープ付きトークンを用いた Authorization Code Grant（3 レイヤー OAuth）の実装を行います。本稿は以下の機能を持つ動作実装を提供します： - CSRF およびブラウザの乗り換え攻撃を防ぐための安全なセッションバインディング - 最小権限の原則に従い、各ユーザーセッションごとにスコープが設定された認証トークン - エージェントワークロードとセッションバインディングサービスとの間の関心の分離 ## OAuth 2.0 と OIDC を用いた認証と認可 本ソリューションでは、OAuth 2.0（[RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749)）および OpenID Connect（OIDC）を利用します。OIDC はユーザーの身元（誰であるか）を認証し、OAuth 2.0 はその行動（何ができるか）に対する権限付与を行います。 ここでは、ユーザー委任アクセスのための「認可コードグラント」に焦点を当てます。ユーザーはアイデンティティプロバイダで認証を行い、同意を与えます。その後、アプリケーションは認可コードと交換してアクセストークンを取得し、監査証跡を作成します。このフローでは、ユーザーがアイデンティティプロバイダで認証し、エージェントが代わりに特定のリソースにアクセスするための同意を与えます。アプリケーションは生成された認可コードをスコープ付きのアクセストークンと交換し、Amazon Bedrock AgentCore Identity がこれをトークン vault に保存します。各トークンは明示的な同意を持つ特定のユーザーアイデンティティに紐付けられているため、本ソリューションではユーザー認証からエージェントアクションに至るまで監査可能な連鎖を維持します。 認可コードグラントは、ユーザーの代わりに動作するアジェンティックワークロードに適しています。これは、エージェントが行動する前にユーザーの同意を得られること、承認リクエストを開始したユーザーと同意を与えたユーザーが同一であることを検証する[セッションバインディング](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/oauth2-authorization-url-session-binding.html)、およびユーザーが承認した権限のみをエージェントに制限するスコープ付き委任を提供するためです。 ## コールバック URL とセッションバインディング URL この文脈では、Authorization Code Grant フローはしばしば混同される 2 つの URL を使用します: - コールバック URL: AgentCore Identity で OAuth クライアントを作成する際に自動的に生成されます。これは AgentCore Identity を指し、ユーザー認証後に認可コードが送信されるリダイレクト先として、認可サーバーに登録する必要があります。 - セッションバインディング URL: 認証されたユーザーと OAuth フロー間のセッションバインディングを完了させる、顧客が管理するサービスへの戻り先を示す URL です。このエンドポイントは顧客によって実装・ホストされます。 ## ソリューションの概要 このアーキテクチャ図は、AgentCore Identity が Amazon ECS 上のセルフホスト型 AI エージェントをどのように保護するかを示しています。このウォークスルーでは Microsoft Entra ID をアイデンティティプロバイダーとして使用しますが、他の OIDC 準拠プロバイダーもサポートされています。本ウォークスルーの完全なソースコードと前提条件は、添付の [GitHub リポジトリ](https://github.com/awslabs/agentcore-samples/tree/main/01-tutorials/03-AgentCore-identity/07-Outbound_Auth_3LO_ECS_Fargate) で利用可能です。 本ソリューションは、アプリケーションロードバランサーの背後に Amazon ECS で 2 つのサービスを展開します。Agentic Workload は AI エージェントを実行し、ユーザーリクエストを処理します。Session Binding Service は OAuth のコールバックを処理して、ユーザーセッションとサードパーティのアクセストークンをリンクさせます。両方のサービスは、Amazon Bedrock AgentCore Identity を使用して、OIDC を経由して入力されるユーザーの認証および、その代わりにアウトバウンドアクションを実行する権限付与を行います。図中の番号付き注釈は、以下の説明に対応しています。 ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/04/29/ML-20517-image-1.png) - 入力認証とトラフィックルーティング：リクエストは Amazon Application Load Balancer (ALB) に到達し、ALB の組み込み OIDC 認証フローを通じてユーザーが認証されます。トラフィックは AWS Certificate Manager から取得した証明書を使用した HTTPS で暗号化され、Amazon Route 53 パブリックホストドメインのエイリアス A レコードがロードバランサーへトラフィックをルーティングします。OIDC を介してユーザーを認証した後、ALB はリクエストを Amazon ECS クラスターに転送します。ALB は、JWT 形式でユーザーのクレームを含む `x-amzn-oidc-data` ヘッダーを注入し、`sub` フィールドがユーザーを一意に識別します。 - エージェントワークロード：Agentic Workload は、sessionId とメッセージを受け付ける `/invocations` エンドポイントを備えた FastAPI サーバーを公開しています。FastAPI サーバーはこれらを Strands Agents で構築されたエージェントに渡します。サーバーはエージェントフレームワークとは独立してリクエストを処理するため、LangChain や他のエージェント SDK も使用可能です。エージェントは Amazon Bedrock 上の大規模言語モデル (LLM) を呼び出しますが、他のモデルプロバイダーも利用できます。エージェントはセッション状態を Amazon S3 バケットに保存し、ユーザー間のセッションを分離するために `sub` クレームをキープレフィックスとして使用します。また、エージェントには GitHub でユーザーの代わりにアクションを実行するためのツールがあり、これにはユーザーの OAuth アクセストークンが必要です。 - AgentCore Identity を用いた出力認証：エージェントが GitHub などのサードパーティサービスでユーザーの代わりに行動する必要がある場合、AgentCore Identity を通じて OAuth アクセストークンを要求します。有効なトークンが存在しない場合、AgentCore Identity は認可コード付与フローを開始し、ユーザーにアクセス権限の付与を求めます。 - OAuth コールバック処理：ユーザーがアクセス権限を付与した後、Session Binding Service が AgentCore Identity を介して正しいユーザーセッションへの認証バインディングを行うことで、OAuth フローを完了します。 - ユーザーインターフェース：エージェントワークロードをホストする FastAPI サーバーは `/docs` エンドポイントを公開しており、これは OpenAPI 仕様を対話形式の HTML ページとしてレンダリングします。エンドユーザーはこのページを通じてエージェントと対話し、デモンストレーション用の最小限の UI が提供されます。 Amazon CloudWatch がログをキャプチャし、専用の S3 バケットがロードバランサーおよびデータバケットの両方のアクセスログを保存します。ECS は Amazon ECR からコンテナイメージを取得します。一般的な Web 攻撃に対する基本的な保護を提供するため、一連の AWS WAF ルールがロードバランサーに付与されます。Amazon KMS カスタマー管理キー (CMK) がデータを暗号化しますが、アクセスログ用バケットは例外であり、こちらは Amazon S3 マネージド暗号化 (SSE-S3) を必要とします。 ## Amazon Bedrock AgentCore Identity: 認可コードグラント このチュートリアルでは、ALB を認証に使用し、専用のセッションバインディングサービスを持ち、AgentCore SDK およびランタイムの代わりに直接 API 呼び出しを行うセルフホスト型アーキテクチャ向けに、[一般的な AgentCore Identity セッションバインディングフロー](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/oauth2-authorization-url-session-binding.html) を適応させたものです。 シーケンス図は、[AgentCore Identity のワークロードアイデンティティ](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/understanding-agent-identities.html)、[ワークロードアクセストークン](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/get-workload-access-token.html)、および [OAuth 2.0 クレデンシャルプロバイダ](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/resource-providers.html) が、ユーザーに代わってエージェントに対して OAuth トークンを安全に提供するためにどのように連携するかを示しています。このフローは、認証済みユーザーがまだエージェントにリソースへのアクセスを許可していないことを前提としており、[AgentCore Identity トークン vault](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/key-features-and-benefits.html#secure-credential-storage) 内に有効なトークンは存在しない状態です。 ## - 認証されたユーザーがエージェントワークロードに対してリクエストを送信します。エージェントワークロードは、ALB署名付きJWT（x-amzn-oidc-data ヘッダー）内の sub クレームからユーザーIDを抽出し、ユーザーを識別します。 - エージェントワークロードは、GetWorkloadAccessTokenForUserId API を呼び出し、userId と workloadName を渡して、このユーザーにスコープされたエージェントのアイデンティティを表すワークロードアクセストークンを取得します。 - AgentCore Identity は、ワークロードアクセストークンをエージェントワークロードに返します。 - エージェントワークロードは、GetResourceOauth2Token API を呼び出し、ワークロードアクセストークン、設定された OAuth 2.0 クレデンシャルプロバイダーのプロバイダー名、セッションバインディング URL（callbackUrl パラメータを参照）、および必要なスコープ（例：GitHub の read:user スコープ）を渡します。これにより、サードパーティサービス（この場合は GitHub）の OAuth トークンを要求します。 - このユーザーに対して有効なトークンが存在しないため、AgentCore Identity は、OAuth 2.0 認証プロセス中の後続のリクエストとレスポンス全体にわたって承認フローの状態を追跡する sessionURI を作成します。 - AgentCore Identity は、承認 URL とセッション URI をワークロードに返します。 - エージェントワークロードは、ユーザーに対してアクセスの承認を促すために、承認 URL をユーザーに返します。 - ユーザーは承認 URL をクリックし、サードパーティプロバイダーの同意画面でエージェントへの権限付与を行います。 - 認証サーバーは、承認コードを AgentCore Identity に送信します。 - AgentCore Identity は、セッション URI を追加したセッションバインディング URL を介してユーザーをリダイレクトし、セッションバインディングサービスへルーティングします。 - ユーザーのブラウザは、セッションバインディング URL を経由してセッションバインディングサービスへのリダイレクトに従います。ALB は x-amzn-oidc-data ヘッダーに JWT を注入します。 - セッションバインディングサービスは、CompleteResourceTokenAuth API を呼び出し、セッション URI とユーザー ID（JWT から抽出）を渡して、完了した承認を正しいユーザーセッションにバインドします。成功した場合、承認が正常に行われたことを確認する静的なアプリケーション所有の HTML ページを返します。 - AgentCore Identity は、認証サーバーと承認コードを交換し、OAuth2 アクセストークンを取得します。 - 認証サーバーは OAuth2 アクセストークンを返します。 - AgentCore Identity は、トークン vault にトークンを保存します。 - AgentCore Identity は、セッションバインディングサービスに成功を通知します。 - セッションバインディングサービスは、ユーザーに対して「承認完了」を表示します。 後続のリクエストにおいて、ユーザーが再承認を行う必要があるかどうかは、認証サーバーが発行した資格情報によります。AgentCore Identity は、アクセストークンとリフレッシュトークン（利用可能な場合）の両方をトークン vault に保存します。リフレッシュトークンが存在する場合（GitHub でユーザーからサーバーへのトークンの有効期限切れが有効になっている場合など）、AgentCore Identity は元のトークンが期限切れになると自動的にリフレッシュトークンを使用して新しいアクセストークンを取得し、ユーザーに再度プロンプトを表示しません。リフレッシュトークンが発行されず、アクセストークンが期限切れになった場合は、ユーザーに再承認を求められます。なお、トークンはプロバイダー側で取り消される場合もあります。そのような場合には、forceAuthentication: true を設定することで、新しい認証フローを強制します。 **セッションバインディング:** セッションバインディングは、2 つのセキュリティ脅威から保護します: **クロスサイトリクエストフォージェリ (CSRF):** 攻撃者が自分の OAuth トークンを被害者の ID に紐付けようとし、被害者のエージェントが知らないうちに攻撃者のリソースにアクセスすることで、データの窃取や注入を可能にします。 **ブラウザ置換攻撃:** 攻撃者が被害者に代わって同意させるように仕向け、被害者の OAuth トークンを攻撃者の ID に紐付けることで、攻撃者に被害者のリソースへの直接アクセス権を与えてしまいます。 セッションバインディングは、エージェントワークロードのユーザー ID とセッションバインディングサービスのユーザー ID が一致することを保証し、両方の ID を認証チェーンを通じて暗号学的に検証することで、これらの攻撃を防止します。 AgentCore Identity はまた、[GetResourceOauth2Token](https://docs.aws.amazon.com/bedrock-agentcore/latest/APIReference/API_GetResourceOauth2Token.html) API にオプションの customState パラメータをサポートしており、OAuth 2.0 仕様に推奨されている通り、CSRF 攻撃からコールバックエンドポイントを保護するために暗号学的にランダムな nonce を渡すために使用できます。 ## AWS ALB と Microsoft Entra ID を使用して GetWorkloadAccessTokenForUserId を使用する理由 ワークロードアクセストークンを取得するための推奨 API は [GetWorkloadAccessTokenForJWT](https://docs.aws.amazon.com/bedrock-agentcore/latest/APIReference/API_GetWorkloadAccessTokenForJWT.html) です。しかし、このソリューションでは代わりに [GetWorkloadAccessTokenForUserId](https://docs.aws.amazon.com/bedrock-agentcore/latest/APIReference/API_GetWorkloadAccessTokenForUserId.html) を使用しています。 [GetWorkloadAccessTokenForJWT](https://docs.aws.amazon.com/bedrock-agentcore/latest/APIReference/API_GetWorkloadAccessTokenForJWT.html) には、ランタイムで発行元の公開署名鍵に対して検証可能な署名を持つ動的に有効な JWT と、アプリケーションの aud クレームが一致するトークンが必要です。Microsoft Entra ID からこのようなトークンを取得するには、OIDC 認可リクエストのスコープにアプリケーション ID を含める必要があります。詳細については [AgentCore Microsoft インバウンドドキュメント](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/identity-idp-microsoft.html#identity-idp-microsoft-inbound) を参照してください。 ***しかし、これは AWS ALB の OIDC フローとは互換性がありません。*** OIDC ハンドシェイクの一部として（[ALB OIDC ドキュメント](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html#authentication-flow)を参照）、ALB はアクセス トークンを Entra の UserInfo エンドポイントに送信し、認証されたユーザーのクレームを取得します。これは ALB の認証フローにおける必須ステップです。この UserInfo エンドポイントは Microsoft Graph（[https://graph.microsoft.com/oidc/userinfo](https://graph.microsoft.com/oidc/userinfo)）上でホストされており、Microsoft Graph にスコープされたトークンしか受け付けません。スコープにアプリケーション ID を含めると、生成されるアクセス トークンのオーディエンスはあなたのアプリケーションとなり、UserInfo エンドポイントは 401 で拒否し、ALB は 561 を返します。 もしスコープからアプリケーション ID を削除すると、Entra はデフォルトでアクセス トークンのオーディエンスを Microsoft Graph（00000003-0000-0000-c000-000000000000）に設定します。ALB のハンドシェイクは成功しますが、生成された JWT は AgentCore で動的に検証できず、[GetWorkloadAccessTokenForJWT](https://docs.aws.amazon.com/bedrock-agentcore/latest/APIReference/API_GetWorkloadAccessTokenForJWT.html) では使用できません。 このソリューションでは、ALB が Graph スコープのトークンを使用してハンドシェイクを完了します。ALB は、ユーザー情報エンドポイントからのユーザーの主張（claims）を含む x-amzn-oidc-data ヘッダーに、ALB 署名付き JWT を転送します。これには、認証されたユーザーを一意に識別する sub クレームも含まれています。私たちは、AWS が公開した署名鍵を使用してこの ALB 署名付き JWT を検証し、sub を抽出して [GetWorkloadAccessTokenForUserId](https://docs.aws.amazon.com/bedrock-agentcore/latest/APIReference/API_GetWorkloadAccessTokenForUserId.html) に渡します。 ## 実装 完全なコードは [GitHub リポジトリ](https://github.com/awslabs/amazon-bedrock-agentcore-samples/tree/main/01-tutorials/03-AgentCore-identity/07-Outbound_Auth_3LO_ECS_Fargate) でご覧ください。 ## ワークロードアクセストークンの取得 サーバーは JWT の sub クレームからユーザー ID を抽出し、AgentCore Identity からワークロードアクセストークンを要求します。その後、サーバーはこのトークン、セッション ID、およびメッセージを使用して、ユーザーに代わってエージェントを呼び出します。ここでいうセッション ID は、認証フローからの OAuth セッション URI ではなく、エージェントの会話セッションを指す点にご注意ください。 @router.post("/invocations") async def invoke_agent( request: InvocationRequest, user_id: str = Depends(get_current_user), settings: Settings = Depends(get_settings), agent_service: AgentService = Depends(get_agent_service), ) -> StreamingResponse: """ストリーミングレスポンスでエージェントを呼び出します。""" try: agentcore = boto3.client("bedrock-agentcore", region_name=settings.identity_aws_region) response = agentcore.get_workload_access_token_for_user_id( workloadName=settings.workload_identity_name, us

Amazon ECS で Amazon Bedrock AgentCore Identity を使用して AI エージェントを保護

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト