30秒サマリー
- AWSがAmazon QuickのMCPツール連携における「多層防御（Defense-in-Depth）認可」の実装方法を公式ブログで詳解
- MFA検証・地理的制限・グループRBAC・ツールレベル許可の4ゲートをJWTクレーム評価で順次実施する設計を紹介
- 金融・医療・政府など厳格なコンプライアンスが求められる組織向けのアーキテクチャパターンとして提示
何が起きたか
AWSは公式のMachine Learning Blogにおいて、Amazon Quick上のMCPツール呼び出しに対する多層防御認可パターンの実装方法を解説する記事を公開した。記事では「認証済み（authenticated）」と「認可済み（authorized）」は別物であるという前提から出発し、有効なSSOトークンだけではツールレベルの権限制御には不十分であると説明している。
解説されるパターンは、Amazon Bedrock AgentCore GatewayとAWS LambdaのREQUESTインターセプターを組み合わせ、OpenID Connect（OIDC）のJWTクレームを4つのゲートで順番に評価する設計だ。ゲートは①MFA検証（IDプロバイダーによる条件付きアクセスポリシーとamrクレームの二重確認）、②国別地理フェンス（ctryクレーム）、③グループベースのRBAC（groupsクレーム）、④ツールレベルの許可リスト確認、の順で処理される。ゲート③④は常時有効なコアゲートで、①②は環境変数で有効・無効を切り替えられる条件付きゲートと位置付けられている。いずれかのゲートで失敗したリクエストはHTTP 403で拒否され、ビジネスロジックには到達しない。
記事はAnyCompany Global Servicesという架空企業を例に取り、Amazon DynamoDB上のリスク台帳へのMCPツールアクセスを題材にしている。IDプロバイダーにはMicrosoft Entra IDを使用し、アプリ登録・APIスコープ設定・条件付きアクセスポリシーの構成手順が詳述されている。なお記事では、AWS側コンポーネント（Gateway・Lambda関数・DynamoDBテーブル）はすでにデプロイ済みであることを前提とし、IDプロバイダー側の設定に焦点を当てている。
原典ハイライト
「MCPツールの呼び出しはそれぞれアクセスイベントであり、有効なトークンに加えて、ツールおよびパラメーターレベルの多層防御認可が必要になり得る。細かい制御がなければ、誤設定された1つの権限がコンプライアンス上必要なアクセス要件を回避する可能性がある」（原文より要約）
出典: AWS Machine Learning Blog（公式ブログ）
So What?（なぜ重要か）
MCPがエンタープライズ環境で普及するにつれ、「誰がログインしているか」の認証だけでなく「何を実行してよいか」の認可が独立した制御レイヤーとして不可欠になることをAWSが公式に示したものだ。標準のOAuth 2.0検証のみでは、ツールやパラメーター単位の権限境界を引けないという設計上の盲点がある。この多層防御パターンは、コンプライアンス監査証跡（ミューテーション時のイミュータブル記録）まで含めた、エンタープライズ向けの参照アーキテクチャとして機能する。
日本企業への示唆
AIエージェントに社内データソースをMCP経由で接続する検討を進めている日本企業は、「SSOで認証が通れば十分」という前提を見直す必要がある。特に金融・医療・製造など規制産業では、ツール単位・パラメーター単位の認可制御と監査ログの両立が求められる場面が多い。今回解説されたパターンはMicrosoft Entra IDを前提としているが、OIDC対応のIDプロバイダーであれば原則適用可能とされており、既存のAzure AD基盤を持つ企業は比較的導入しやすい。アーキテクチャ設計段階でRBAC・地理制限・MFA強制の有効化範囲をコンプライアンス要件に合わせて定義しておくことが先決となる。
背景・経緯
Model Context Protocol（MCP）はアプリケーションと社内ツール・データベース・APIを接続するオープンプロトコルとして普及しつつある。Amazon QuickはAmazon Bedrock AgentCore Gatewayを介してMCPツールを利用する構成を持つ。原文では、AWS側のインフラ（Gateway・Lambda・DynamoDB）のデプロイ方法は本記事の対象外とされており、別途実装済みであることが前提とされている。
