MicrosoftがAzure公式ブログで、Model Context Protocol（MCP）サーバーをAzure App Service上に安全にホストするためのリファレンスアーキテクチャを公開した。背景にあるのは、MCPサーバーの大多数が認証を実装していないという衝撃的な調査結果だ。

MCPサーバーのセキュリティ実態：数字が示す危機

Astrix Researchが発表した「State of MCP Server Security 2025」によると、OAuthを実装しているMCPサーバーはわずか8.5%。残りの91.5%は静的なAPIキーのみか、認証自体が存在しない状態でインターネットに公開されている。

これは机上の話ではない。すでにCVEが複数発行されている。

  • CVE-2025-6514（CVSS 9.6）：mcp-remoteにおけるOSコマンドインジェクション。悪意あるMCPサーバーに接続したクライアントのマシン上でリモートコード実行（RCE）が可能。約50万ダウンロードが影響を受けた
  • CVE-2025-49596：MCP Inspectorの開発ツールが認証なしのローカルWebUIを公開しており、細工されたWebページからRCEが可能

問題の根本はMCPプロトコル仕様が認証をオプションとして定義している点にある。仕様書には「認可は実装依存」と明記されており、セキュリティの責任は開発者側にある。「簡単に立ち上げられる」というMCPの魅力が、そのままセキュリティリスクに直結している。

Azure App Serviceによる5層防御アーキテクチャ

Microsoftが公開したサンプルリポジトリ（seligj95/app-service-secure-mcp）は、azd up一発でセキュアなMCPサーバーを展開できる構成になっている。5つの防御層を見ていこう。

1. Easy Auth——自前実装不要のOAuth

App Serviceの組み込み認証（Easy Auth）をMicrosoft Entra IDと連携させることで、アプリケーションコードが動き出す前にプラットフォームレベルでトークン検証が完了する。

重要なのがProtected Resource Metadata（PRM）の公開だ。WEBSITE_AUTH_PRM_DEFAULT_WITH_SCOPESという1つのアプリ設定を追加するだけで、MCPクライアントが認可サーバーを自動検出してOAuthフローを完結できるようになる。8.5%しか実装できていないOAuth準拠を、コードを書かずに達成できる。

globalValidation: { requireAuthentication: true unauthenticatedClientAction: ‘Return401’ }

また、App ServiceがX-MS-CLIENT-PRINCIPALヘッダーにクライアントのクレームを注入し、クライアントが偽装しようとした場合は上書きして除去するため、ツール側で「誰が呼んでいるか」を安全に確認できる。

2. マネージドID——秘密情報を一切保存しない

システム割り当てマネージドIDにより、App ServiceはAzureが管理するEntra IDのIDを取得する。Key VaultやAzure OpenAIへの認証に格納された認証情報が一切不要になる。

重要な原則：クライアントが提示したトークンはあくまで「このMCPサーバーへのアクセス権」であり、Key Vaultへのアクセス権ではない。そのトークンをそのままダウンストリームに転送するのは脆弱性だ。マネージドIDによる委譲が正しい実装パターンになる。

3. Key Vaultシークレット参照——そして「返してはいけない」設計

アプリ設定にKey VaultのURIを参照させることで、平文のシークレットがリポジトリにも設定画面にも現れない。

ただし見落としがちな点がある。シークレットを読めるツールが、その値を返してはいけない。サンプルコードのread_secret_metadataツールは、マネージドIDによるアクセスが機能することを確認しつつ、返すのはバージョン情報と値の文字数のみ。値本体は意図的に除外されている。

シークレットを返すget_secretツールは、見かけが親切でも実態は「資格情報流出API」だ。

4. プライベートエンドポイント＋API Management——インターネットから姿を消す

App ServiceとKey Vaultにプライベートエンドポイントを設定し、パブリックネットワークアクセスを無効化する。インターネットから唯一見えるのはAPI Management（APIM）のゲートウェイのみ。

APIMがトラフィックの入口でEntra JWT検証とレートリミットを実行し、その先のプライベートエンドポイントでもEasy Authが再度トークン検証を行う。攻撃者はパブリックゲートウェイのJWT検証とレートリミットを突破した上で、さらに認証が要求されるプライベートエンドポイントに到達しなければならない。

5. Application Insights——インシデント前に検知する

Azure Monitor OpenTelemetryによる自動計装に加え、ツール呼び出しごとに構造化イベントを記録する。5分間の呼び出し数が閾値（サンプルは100回）を超えたらアラートを発火させる設定で、エージェントのループや不審なプロービングを事後のフォレンジックではなくリアルタイムで検知できる。

日本のエンジニア・IT管理者への実務インパクト

今すぐ確認すべき点：

社内で稼働中のMCPサーバーを棚卸しする：誰かが「とりあえず試してみた」サーバーがインターネットに公開されていないか確認する。mcp-remoteを使っているなら、CVE-2025-6514のパッチ適用状況を確認すること

開発ツールのMCP Inspectorに注意：CVE-2025-49596はローカルの開発環境でも影響する。未パッチのバージョンを使いながら外部サイトを閲覧するだけでRCEのリスクがある

新規MCP構築はこのアーキテクチャを起点に：azd up一発で展開できるサンプルが公開されているため、デモ用の「とりあえず動く」構成をそのまま本番に持ち込む事故を防ぐハードルが下がった

コンプライアンス監査対応：金融・医療・公共分野でMCPを活用する場合、認証なしのエンドポイントはほぼ間違いなく指摘事項になる。Easy Auth＋マネージドID構成は監査証跡としても機能する

筆者の見解

MCPは確かに「AI時代のUSB-C」になりつつある。ツールを接続する標準インターフェースとして普及速度は速く、エコシステムの拡大も目覚ましい。だからこそ、認証なしで91.5%が稼働しているという数字は見逃せない。

セキュリティ界隈は細かいことを指摘する人が多くて正直得意ではないが、今回の問題は技術的にシンプルで本質的だ。MCPプロトコルが認証をオプションにしたのは設計として理解できる選択だが、現場では「オプション＝後回し」になりやすい。CVEに番号とCVSSスコアがついた時点で、もはや「あとで対応すればいい話」ではない。

Microsoftのアプローチは実直だと思う。Easy AuthによるOAuth実装、マネージドIDによる資格情報レス化、APIMによる多層防御——どれもAzureのプラットフォーム機能をMCPのセキュリティモデルに正面からマッピングしたものだ。NHI（Non-Human Identity）管理の文脈で言えば、マネージドIDによるエージェント認証の基盤としてMicrosoft Entra IDが機能するこの設計は、長期的に見ても理にかなっている。

ひとつ正直に言うと、APIMのプロビジョニングに30〜45分かかり、デプロイ検証もゲートウェイ経由になるという摩擦は、開発者が「デモ構成で十分」と判断する誘惑に負けるリスクを生む。この摩擦を下げる方向の改善があれば、セキュアな構成の採用率は確実に上がるはずだ。実力はある、あとは導入障壁の問題だと思って見ている。

MCPを使う組織で「禁止」という方向に向かうのは現実的ではない。それよりも、公式の安全な構成が「一番楽な選択肢」になる状況を整える方が長続きする。今回のサンプルリポジトリはその方向への一歩として評価している。

出典: この記事は Only 8.5% of MCP Servers Use OAuth — Here’s How to Host One Securely on App Service の内容をもとに、筆者の見解を加えて独自に執筆したものです。