Amazon Quick上のMCPツール利用における「多層防御認可」の実装パターンをAWSが解説
要点
-
AWSは、Amazon Quick上でModel Context Protocol（MCP）ツールを利用する際のアクセス制御を強化する多層防御認可パターンを公開した。
-
単一のSSO認証にとどまらず、ツールやパラメータ単位で権限を検証する4段階の認可ゲートを設ける仕組みを提示している。
-
Microsoft Entra IDとAmazon Bedrock AgentCore Gatewayを連携させ、MFA、地理的制限、ロール、ツール権限を順次判定する。
-
金融や医療、政府機関など、機密データの保護と厳格なコンプライアンス監査が求められる組織向けの実装例とされている。
-
米Amazon Web Services（AWS）は2026年9月17日、公式の機械学習ブログ「AWS ML Blog」において、同社のサービス「Amazon Quick」上でModel Context Protocol（MCP）ツールを実行する際のセキュリティ設計に関する記事を公開した。記事では、OpenID Connect（OIDC）のトークン情報を活用し、ツールやパラメータ単位でアクセス権限を厳格に判定する「多層防御認可（Defense-in-Depth Authorization）」の実装パターンが紹介されている。
SSO認証だけでは防げない機密データアクセスのリスク
近年普及が進むModel Context Protocol（MCP）は、各種アプリケーションを社内ツールやデータベース、APIと連携させるためのオープンプロトコルだ。個別のカスタム統合を減らせる利点がある一方、Amazon Quickなどのインターフェースを通じて機密性の高いデータソースへ接続する場合には、アクセス制御の設計が極めて重要になる。
AWSの解説によると、シングルサインオン（SSO）による一般的な認証は「呼び出し元が誰であるか」を確認するだけであり、「その利用者がどのツールを使い、何を実行してよいか」という認可までは保証しないという。仮に広範な権限を持つトークンが1つでも存在したり設定の不備があったりした場合、利用者の本来の役割を超えて機密データに到達してしまう恐れがあり、コンプライアンス上の監査要件を満たせなくなるリスクがあると指摘している。
4つのゲートで段階的に検証するマルチゲート認可
こうした課題に対し、ブログ記事では「認証済み（Authenticated）」と「認可済み（Authorized）」を明確に区別し、呼び出しごとに多段階で評価を行う「マルチゲート認可パターン」を提案している。
このパターンでは、インターセプター（リクエストの検証処理）がOpenID ConnectのJSON Web Token（JWT）に含まれるクレーム（属性情報）を読み取り、以下の4つのゲートを順番に評価していく。
- 多要素認証（MFA）の確認: サインイン時に適切なMFAが行われているかを検証する。
- 地理的制限の判定: 許可されていない国や地域からのアクセスを遮断する。
- グループからロールへのマッピング: ユーザーが所属するグループ情報を適切な実行ロールへと変換する。
- ツールレベルの権限チェック: 各ツールの実行可否に加え、指定されたパラメータ単位の属性チェックを実施する。
これにより、ロールベースアクセス制御（RBAC：役割に応じた制御）と属性ベースアクセス制御（ABAC：属性に応じた制御）を組み合わせた細やかな管理が可能となり、自社のコンプライアンス基準に合わせたセキュリティポリシーを適用できるとしている。
Amazon Bedrock AgentCore Gatewayを活用した構成
実装アーキテクチャでは、IdP（IDプロバイダー）として「Microsoft Entra ID」を使用し、Amazon QuickとバックエンドのMCPツールの間に「Amazon Bedrock AgentCore Gateway」を配置する構成が示された。
Amazon Bedrock AgentCore Gatewayは、Amazon Bedrock AgentCoreが提供する機能の1つであり、クライアントとツールの間でHTTPエンドポイントの提供とJWTの検証層を担う。実際の判定処理はインターセプター用のAWS Lambda関数が実行し、検証を通過したリクエストのみが各ツールの処理を受け持つLambda関数やデータストア（Amazon DynamoDBなど）へ到達する仕組みとなっている。
これにより、ユーザーが入力する自然言語のリクエストとバックエンドのビジネスロジックの間に、監査可能で柔軟に構成できるセキュリティレイヤーを介在させることができると説明している。
規制産業を想定した検証シナリオ
記事内では、金融サービスや医療、公共機関といった厳格なアクセス制御が求められる業界を想定し、「AnyCompany Global Services」という架空の企業を例にした検証手順も紹介されている。
この例では、Amazon DynamoDB上に構築されたマルチテナントのリスク管理台帳に対し、Amazon QuickのMCPツール経由でアクセスするシナリオが設定されている。権限の異なる複数のユーザー属性（ペルソナ）でサインインを行い、意図した通りのアクセス許可や制限が各ゲートで正しく機能するかをテストできるという。