Azure App ServiceでMCPサーバーを公開している、またはこれから公開するAzure利用者は、認証なしのMCPエンドポイントを作らないこと、App Service認証（Easy Auth）とMicrosoft Entra IDを有効にすること、下流サービスにはクライアントのトークンをそのまま渡さずマネージドIDで接続することを優先して確認してください。
2026年6月24日に公開または更新された「Only 8.5% of MCP Servers Use OAuth – Here’s How to Host One Securely on App Service」は、新機能の一般提供というより、MCPサーバーをApp Serviceで安全にホストするための実装・運用上の注意喚起に近い内容です。公式ソース上の分類はNoticeであり、Azure利用者にとっての要点は「MCPを便利なデモ構成のまま本番公開しない」ことです。
Only 8.5% of MCP Servers Use OAuth は何が変わったのか
今回のApps on Azure Blogは、MCPサーバーの公開時に見落とされやすい認証・認可・シークレット管理・ネットワーク分離・監視を、Azure App Service上でどう組み合わせるかを整理した内容です。
ブログでは、Astrix Researchの調査としてOAuthを使うMCPサーバーが8.5%にとどまり、多くが静的APIキーまたは認証なしに依存している点が紹介されています。また、mcp-remoteやMCP Inspectorに関連するRCE脆弱性にも触れ、MCPサーバーをインターネットに直接公開するリスクを強調しています。(TECHCOMMUNITY.MICROSOFT.COM)
重要なのは、MCPそのものが「自動的に安全にしてくれる仕組み」ではない点です。MCPの認可仕様では、認可は実装によって扱われるものであり、HTTPベースのMCPサーバーではOAuth 2.0 Protected Resource Metadataを使って認可サーバーを発見できるようにすることが求められています。(Model Context Protocol)
Azure利用者向けの変更点まとめ
| 確認項目 | 今回のポイント | Azure利用者が取るべき対応 |
|---|---|---|
| MCPサーバーの公開方法 | 認証なしのRPCエンドポイント公開が危険視されている | App Service認証を有効化し、匿名アクセスを拒否する |
| OAuth対応 | MCPクライアントが認可サーバーを発見できる構成が重要 | Protected Resource Metadataを有効化する |
| 呼び出し元の識別 | 誰がツールを実行したかをアプリ側で扱う必要がある | X-MS-CLIENT-PRINCIPAL などのヘッダーを確認する |
| シークレット管理 | 静的APIキーや接続文字列の直書きがリスクになる | マネージドIDとKey Vault参照を使う |
| ネットワーク境界 | 認証だけでは不十分 | Private Endpoint、APIM、レート制限を検討する |
| 監視 | ツール呼び出しの急増は攻撃や暴走の兆候になる | Application InsightsやAzure Monitorで検知する |
影響を受ける対象者
今回のNoticeで特に確認すべきなのは、Azure App Service、Azure Functions、API Management、Key Vault、Microsoft Entra IDを組み合わせて、MCPサーバーやAIエージェント向けのツールAPIを公開しているチームです。
具体的には、次のような環境が対象になります。
- Claude、VS Code、GitHub Copilot、独自AIエージェントなどから呼び出すMCPサーバーをAzure上で動かしている
- App Service上のFastAPI、Node.js、.NETなどでMCPエンドポイントを公開している
- 社内API、データベース、Key Vault、Storage、Azure OpenAIなどへMCPツール経由でアクセスさせている
- PoCで作ったMCPサーバーを、そのままチーム内または社外からアクセス可能な状態にしている
- APIキーや接続文字列をアプリ設定、環境変数、
.env、コード内に置いている
逆に、ローカル端末内だけで動く検証用MCPサーバーでも、ブラウザや開発ツール経由で意図せず外部から到達できる設定になっていないかは確認が必要です。MCP Inspectorの脆弱性では、認証不足のローカル開発ツールがRCEにつながる可能性が指摘されています。(NVD)
まず確認したいApp Service認証の設定
最初に見るべき設定は、App Serviceの「認証」です。
App Service認証では、未認証リクエストを許可するか、拒否するかを選べます。Microsoft Learnでは、「認証が必要」を選ぶと、認証されていないアプリへのトラフィックを拒否でき、アプリ側で認証コードを書かずにアクセス制限を実現できると説明されています。(Microsoft Learn)
MCPサーバーでは、ブラウザ向けのログイン画面へリダイレクトするより、APIとして明確に401を返す構成が扱いやすいケースが多くなります。Apps on Azure Blogのサンプルでも、unauthenticatedClientAction を Return401 にして、認証されていない呼び出しを拒否する構成が示されています。(TECHCOMMUNITY.MICROSOFT.COM)
確認ポイント
| 設定 | 推奨される確認内容 |
|---|---|
| IDプロバイダー | Microsoft Entra IDが設定されているか |
| 未認証要求 | 許可ではなく拒否になっているか |
| 返却動作 | API用途ではリダイレクトではなく401を返す設計か |
| audience | MCPサーバー向けに発行されたトークンだけを受け付けるか |
| 許可クライアント | 実際に接続するMCPクライアントのアプリIDを許可しているか |
特に注意したいのは、App Serviceが作成したEntraアプリ登録の既定状態だけでは、実際のMCPクライアントからの接続でつまずく場合がある点です。ブログでは、実際のMCPクライアントを接続するには、クライアントIDを許可ポリシーに追加し、アプリ登録側で事前承認する必要があると説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
Protected Resource Metadataを有効にする意味
今回の内容で見落としやすいのが、単に「401を返せばよい」わけではない点です。
MCPクライアントがOAuthフローを開始するには、どの認可サーバーを使うべきか、どのスコープが必要かを発見できる必要があります。そのために使われるのがProtected Resource Metadataです。MCP仕様では、MCPサーバーがOAuth 2.0 Protected Resource Metadataを実装し、authorization_servers を含むメタデータを返すことが求められています。(Model Context Protocol)
App Serviceでは、プレビュー期間中、WEBSITE_AUTH_PRM_DEFAULT_WITH_SCOPES アプリ設定を使って既定のProtected Resource Metadataドキュメントを有効化できるとMicrosoft Learnに記載されています。(Microsoft Learn)
たとえば、MCPサーバーを api://<client-id>/user_impersonation のようなスコープで保護している場合、MCPクライアントはPRMを見て認可サーバーと必要スコープを把握し、OAuthフローを進められます。
ここを設定していないと、MCPクライアント側から見ると「ただ401が返るだけ」のサーバーになり、手動トークン貼り付けや独自設定に頼る運用になりがちです。これはセキュリティだけでなく、運用性の面でも避けたい状態です。
X-MS-CLIENT-PRINCIPALで呼び出し元を確認する
認証を有効にしただけでは、アプリの中で「誰がどのツールを呼んだか」を判断できません。App Service認証を使う場合、認証済みユーザーの情報はHTTPヘッダーとしてアプリへ渡されます。
Microsoft Learnでは、X-MS-CLIENT-PRINCIPAL にBase64エンコードされたJSON形式の要求情報が入り、X-MS-CLIENT-PRINCIPAL-ID、X-MS-CLIENT-PRINCIPAL-NAME、X-MS-CLIENT-PRINCIPAL-IDP なども利用できると説明されています。(Microsoft Learn)
MCPサーバーでは、この情報を使って次のような制御を行えます。
- 管理者だけが実行できるツールを分ける
- 読み取り専用ツールと更新系ツールで必要なロールを変える
- 誰がどのツールを呼んだかを監査ログに残す
- 想定外のユーザーやアプリからの呼び出しを拒否する
ただし、ヘッダー値をそのまま信用する設計には注意が必要です。App Service認証を通過した後にApp Serviceが注入したヘッダーとして扱うことが前提です。App Serviceをバイパスしてアプリに直接到達できる経路があると、ヘッダー偽装のリスクが残ります。そのため、App Service本体をPrivate Endpoint配下に置き、APIMやFront Doorなど正規の入口だけを許可する構成が有効です。
シークレットは返さない、保存しない、渡さない
MCPサーバーは「ツールを実行できるAPI」です。つまり、設計を誤ると、便利な管理ツールではなく「資格情報を取り出せるAPI」になってしまいます。
Apps on Azure Blogでは、App Serviceのシステム割り当てマネージドIDを使い、Key Vault、Storage、Azure OpenAIなどへ資格情報なしで接続する構成が示されています。また、MCPクライアントが提示したトークンはMCPサーバー向けのものであり、Key Vault向けにそのまま転送してはいけないという考え方も説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
Microsoft Learnでも、App ServiceのマネージドIDにより、Azure Key VaultなどMicrosoft Entraで保護されたリソースへアクセスでき、AzureプラットフォームがIDを管理するため、シークレットを用意したりローテーションしたりする必要がないと説明されています。(Microsoft Learn)
やってはいけない例
| NGな実装 | なぜ危険か |
|---|---|
get_secret ツールでKey Vaultの値をそのまま返す | MCPクライアントやLLM経由で資格情報が漏れる |
.env にAPIキーを置いたまま本番デプロイする | リポジトリ流出や設定参照で漏えいしやすい |
| クライアントのBearerトークンを下流APIへ転送する | audience違い、権限混同、Confused Deputyの原因になる |
| ユーザー入力をそのままファイルパスやシェルコマンドに連結する | パストラバーサルやコマンドインジェクションにつながる |
| すべてのツールを同じ高権限IDで実行する | 1つのツール侵害が横展開につながる |
Key Vault参照をApp Serviceのアプリ設定で使う場合も、Key Vault側でマネージドIDに読み取り権限を与える必要があります。Microsoft Learnでは、Key Vault参照は既定でアプリのシステム割り当てIDを使い、Azure RBACではKey Vault Secrets Userロールを割り当てる方法が案内されています。(Microsoft Learn)
ネットワークと入口の設計も確認する
認証を入れていても、MCPサーバーをそのままパブリックに置くと攻撃面は広くなります。特に本番環境では、App Serviceに直接アクセスさせるのではなく、API Managementなどを前段に置き、App Service本体はPrivate Endpointで閉じる構成を検討してください。
Apps on Azure Blogでは、App ServiceとKey VaultにPrivate Endpointを使い、App Serviceのパブリックアクセスを無効化し、APIMを唯一の入口にする構成が紹介されています。APIM側ではJWT検証、呼び出し元ごとのレート制限、バックエンドルーティングを行い、さらにApp Service側でもEasy Authで再検証する防御層を作る考え方です。(TECHCOMMUNITY.MICROSOFT.COM)
小規模な社内PoCなら、最初からAPIMまで入れると重い場合もあります。その場合でも、少なくとも次の順で段階的に固めると現実的です。
- App Service認証を有効化し、匿名アクセスを拒否する
- Entra IDの許可クライアントとaudienceを確認する
- マネージドIDでKey VaultやAzureリソースへ接続する
- ツールごとにロール・スコープ・入力検証を入れる
- Application Insightsでツール呼び出しを記録する
- 本番公開前にPrivate Endpoint、APIM、レート制限を追加する
運用で失敗しやすいポイント
MCPサーバーのセキュリティは、デプロイ時だけでなく運用中にも崩れやすい領域です。特に次の失敗は起きやすいため、チェックリスト化しておくと安全です。
| 失敗しやすいポイント | 確認方法 |
|---|---|
| PoC用の匿名エンドポイントが残っている | 認証なしcurlで401になるか確認する |
| MCPクライアントのアプリIDが未登録 | VS CodeやClaudeなど実際のクライアントでOAuth接続を試す |
| PRMが返らない | /.well-known/oauth-protected-resource または401チャレンジを確認する |
| ツールが秘密値を返している | ツール一覧と戻り値をレビューする |
| 管理者向けツールに一般ユーザーが到達できる | ロール・スコープ別に実行テストする |
| App Serviceに直接到達できる | App Serviceの公開アクセス、Private Endpoint、APIM経由制御を確認する |
| 監査ログが残らない | ツール名、呼び出し元、結果、失敗理由をApplication Insightsに記録する |
特に、MCPサーバーでは「ツール名が便利そうだから返している情報」ほど危険になる場合があります。たとえば、read_secret、run_command、read_file、query_database のようなツールは、入力検証・権限制御・戻り値制御が不十分だと被害が大きくなります。
Azure利用者が今すぐ行うべき確認
今回のNoticeを受けて、Azure管理者や開発チームは、まず既存のMCPサーバーやAIエージェント用APIを棚卸ししてください。
最低限、次の5点を確認すると優先度を判断しやすくなります。
| 優先度 | 確認内容 | 判断基準 |
|---|---|---|
| 高 | インターネットから到達できるMCPエンドポイントがあるか | ある場合は認証とネットワーク制限を最優先 |
| 高 | 匿名アクセスでツール呼び出しができないか | できる場合は即時停止または認証追加 |
| 高 | APIキーや接続文字列を環境変数・コードに保存していないか | 保存している場合はKey VaultとマネージドIDへ移行 |
| 中 | MCPクライアント向けOAuth discoveryが機能するか | PRMとスコープ設定を確認 |
| 中 | ツール呼び出しの監査ログがあるか | ない場合はApplication Insightsへ記録 |
本番環境に出すMCPサーバーは、通常のWeb APIよりも慎重に扱うべきです。理由は、MCPサーバーがAIエージェントから自動的に呼び出され、ファイル、API、データベース、クラウドリソースに対する操作を連鎖的に実行できるためです。
今回のポイントは、新しいAzure機能を急いで有効化することではありません。すでにApp Serviceにある認証、マネージドID、Key Vault、Private Endpoint、API Management、Application Insightsを組み合わせ、MCPサーバーを「デモ構成」から「本番に出せる構成」へ引き上げることです。まずは、匿名アクセスの有無、シークレット管理、呼び出し元の識別、ログの4点から確認を始めてください。
コメント