Azure App ServiceのMCPサーバー安全対策｜OAuth対応と管理者向け確認事項

Azure App ServiceでMCPサーバーを公開している管理者が最初に確認すべきことは、認証なしのMCPエンドポイントがインターネットに出ていないか、Microsoft Entra IDによるOAuth認証、App Service認証、API Management、マネージドID、Key Vault、Application Insightsの監査がそろっているかです。

2026年6月24日の「Only 8.5% of MCP Servers Use OAuth — Here’s How to Host One Securely on App Service」は、新機能の強制適用や廃止告知というより、Azure上でMCPサーバーを安全に本番運用するためのNoticeです。Astrix Researchの調査では、MCPサーバーのうちOAuthを使っているものは8.5%にとどまり、静的APIキーやPAT、環境変数経由の資格情報に依存する実装が多いとされています。(TECHCOMMUNITY.MICROSOFT.COM)

この記事では、Azure管理者が確認すべき影響範囲、権限、監査、移行、社内周知ポイントを実務目線で整理します。結論から言えば、MCPサーバーは「動くこと」よりも「誰が、どのツールを、どの権限で、どこから実行したかを追えること」を本番化の条件にするべきです。

Only 8.5% of MCP Servers Use OAuthの要点

今回のApps on Azure Blogが伝えている主なメッセージは、MCPサーバーを便利なデモ構成のまま公開しないことです。MCPはAIエージェントにファイル、API、データベース、業務システムなどへの操作口を与える仕組みです。認証や権限設計が弱いまま公開すると、単なるWeb APIの公開よりも被害が広がりやすくなります。

Microsoftの投稿では、Azure App Service上のMCPサーバーを、App Service認証、Microsoft Entra ID、マネージドID、Key Vault、パブリックネットワーク制限、API Management、Application Insightsアラートと組み合わせて堅牢化する方向性が示されています。(TECHCOMMUNITY.MICROSOFT.COM)

管理者が押さえるべきポイントは次の通りです。

確認テーマ	管理者が見るべきこと	優先度
認証	App Service認証またはAPI Managementで匿名アクセスを遮断しているか	高
認可	ユーザー、アプリ、ツール単位でスコープやロールを分けているか	高
資格情報	APIキーやPATをアプリ設定や環境変数に平文で置いていないか	高
ネットワーク	App Serviceを直接公開せず、APIMやPrivate Endpointで制御しているか	高
監査	誰がどのMCPツールを呼んだか、失敗・拒否を追跡できるか	高
移行	既存MCPクライアントへのURL変更、再同意、権限変更を周知しているか	中

今回のNoticeは「今すぐAzureサービスの仕様が変わる」という話ではありません。むしろ、MCPサーバーをApp Serviceで公開している組織に対して、本番運用の最低ラインを見直すきっかけと考えるべきです。

影響を受けるAzure環境

影響を受けやすいのは、Azure App ServiceまたはAzure FunctionsでHTTPベースのMCPサーバーを動かしている環境です。特に、社内ツールやAIエージェントから使うために一時的に作ったMCPサーバーを、そのまま公開している場合は確認が必要です。

MCPの認可ガイドでは、ユーザー固有データ、管理操作、監査、企業向けアクセス制御、レート制限が必要な場合に認可を強く推奨しています。HTTPベースでリモートホストされるMCPサーバーでは、OAuthを使ってユーザーがサーバーへアクセスできることを確立する設計が前提になります。(Model Context Protocol)

対象	具体例	確認ポイント
App Service上のMCPサーバー	/mcp、/sse、/messagesなどのエンドポイントを持つWebアプリ	匿名アクセス不可、HTTPS強制、認証失敗時はAPI向けに401
Azure Functions上のMCP機能	HTTPトリガーでツール呼び出しを受ける関数	Function keyだけに依存していないか
AIエージェント連携	VS Code、社内エージェント、チャットUI、Copilot連携	接続先URLと認可フローを管理対象にしているか
下流Azureリソース	Key Vault、Storage、Azure SQL、Azure OpenAI、Microsoft Graph	クライアントの長期キーではなくマネージドIDを使っているか
APIゲートウェイ	Azure API Management、Front Door、Application Gateway	バイパス経路が残っていないか

注意したいのは、MCPサーバーが「社内向け」と言われていても、App Serviceの既定ホスト名が外部から到達可能なままになっているケースです。社内利用のつもりでも、アクセス制限がなければ実質的には公開APIです。

管理者向けチェックリスト

まずは次の表で現状を棚卸ししてください。すべてを一度に直す必要はありませんが、「匿名公開」「長期キー」「監査なし」の3つが重なっている場合は、優先的に停止または制限する判断が必要です。

確認項目	合格基準	Azureで見る場所	NGの場合の対応
MCPエンドポイントの棚卸し	App Service、Functions、APIM上のMCP URLを一覧化している	Resource Graph、App Service一覧、APIM API一覧	所有者、用途、公開範囲、データ分類を記録
匿名アクセス	本番MCP APIは匿名で呼べない	App Service > Authentication	Require authenticationを設定
認証プロバイダー	Microsoft Entra IDまたは許可済みIdPを使用	App Service > Authentication	App registrationを作成し、IdPを追加
トークンの宛先	audが対象APIに限定されている	App Service Authentication、Entra app registration	Allowed token audiencesを設定
認可	ロール、スコープ、ツール単位の制御がある	アプリコード、APIMポリシー、Entraアプリ	roles、scp、グループなどを検証
PRM対応	MCPクライアントが認可サーバーを発見できる	App Service設定、MCPサーバー実装	Protected Resource Metadataを検証
シークレット	APIキーやPATを平文設定に置いていない	App Service > Configuration、Key Vault	Key Vault参照またはマネージドIDへ移行
ネットワーク	App Service直アクセスを制限している	Networking、Access restrictions、Private Endpoint	APIM経由、Private Endpoint、アクセス制限を適用
監査	401、403、429、5xx、ツール実行履歴を追える	Application Insights、Log Analytics、APIMログ	診断設定とアラートを追加
スロット分離	dev、staging、prodで認証情報を共有していない	Deployment slots、App registration	環境ごとにアプリ登録と権限を分離

認証はApp Service認証とMicrosoft Entra IDを基本にする

Azure App Serviceには、組み込みの認証と承認機能があります。一般にEasy Authとも呼ばれ、Webアプリ、REST API、Functionsに対して、アプリコードを大きく変更せずに認証を追加できます。Microsoft Learnでは、Microsoft Entra IDなど複数のIDプロバイダーと統合できること、未認証リクエストをサインインへ誘導または拒否できることが説明されています。(Microsoft Learn)

MCPサーバーをAPIとして使う場合は、未認証リクエストに対してリダイレクトではなく401を返す設計が扱いやすくなります。ブラウザー向けWebサイトなら302リダイレクトが自然ですが、MCPクライアントやエージェントが相手の場合、401で認可チャレンジを返した方が原因を切り分けやすいためです。App Service認証のドキュメントでも、APIではHTTP 401 Unauthorizedが推奨される選択肢として示されています。(Microsoft Learn)

Allowed token audiencesを必ず確認する

MCPサーバーを守るうえで見落としやすいのが、トークンの宛先です。Microsoft Entra IDのトークンを受け付けていても、対象API向けではないトークンを受け入れてしまう設計は危険です。

App ServiceのMicrosoft Entra認証では、Allowed token audiencesを使って、受け入れるアクセストークンをaudクレームで制限できます。Application ID URIやアプリ登録のクライアントIDを明示し、MCPサーバー向けに発行されたトークンだけを受け付けるようにしてください。(Microsoft Learn)

確認時の判断基準は次の通りです。

状態	判断
Allowed token audiencesが空または意図不明	要確認。どのAPI向けトークンを受け入れるのか明文化する
開発、検証、本番で同じaudを使っている	原則見直し。環境分離が難しくなる
複数クライアントを許可している	クライアントごとにスコープ、ロール、監査を分ける
APIMとApp Serviceの両方で検証している	望ましい。ただし設定不一致による拒否に注意

MCP向けにはProtected Resource Metadataも確認する

MCPの認可仕様では、保護されたMCPサーバーはOAuth 2.0 Protected Resource Metadata、つまりRFC 9728に基づくメタデータを実装し、MCPクライアントが認可サーバーを発見できるようにする必要があります。仕様では、MCPサーバーがOAuth 2.1のリソースサーバーとして動作し、MCPクライアントがアクセストークンを使って保護リソースへアクセスする流れが説明されています。(Model Context Protocol)

App Service認証には、OAuth 2.0 Protected Resource Metadataを提供するプレビュー機能があり、MCPサーバー認可に必要とされています。プレビュー期間中は、WEBSITE_AUTH_PRM_DEFAULT_WITH_SCOPESアプリ設定でスコープ一覧を指定する構成が案内されていますが、プレビュー機能のため設定方法が変わる可能性があります。(Microsoft Learn)

管理者は、次の観点で確認してください。

確認項目	具体的な見方
401応答	WWW-Authenticateに認可情報が含まれるか
well-known URL	/.well-known/oauth-protected-resource相当のメタデータが取得できるか
scopes	MCPツールに必要なスコープが過剰でないか
authorization_servers	想定したEntraテナントまたは認可サーバーだけが示されているか
クライアント互換性	利用するMCPクライアントがPRM検出に対応しているか

ここでのポイントは、OAuth対応を「ログインできる」だけで終わらせないことです。MCPクライアントがどの認可サーバーへ行き、どのスコープを要求し、どのリソース向けトークンを取得するのかを確認してください。

認可はアプリ側でも判断する

App Service認証を有効にすると、認証済みユーザーやクライアントの情報がアプリへ渡されます。Microsoft Learnでは、App Serviceがクレームを要求ヘッダーに注入し、X-MS-CLIENT-PRINCIPAL、X-MS-CLIENT-PRINCIPAL-ID、X-MS-CLIENT-PRINCIPAL-NAMEなどをアプリコードで利用できることが説明されています。(Microsoft Learn)

ただし、ここで重要なのは、App Service認証だけで業務上の認可がすべて完了するわけではない点です。App Service認証は認証済みかどうかを判断できますが、「このユーザーがこのMCPツールを実行してよいか」「このクライアントアプリが管理系ツールを呼べるか」は、アプリコードやAPIMポリシーで明示的に制御する必要があります。Microsoft Learnでも、App Service認証は既定では認証を提供するものであり、追加の認可判断が必要になる場合があると説明されています。(Microsoft Learn)

特にサービス間通信では注意が必要です。App Serviceへデーモンアプリがクライアント資格情報フローでアクセスする場合、アプリロールを定義してアクセストークンにrolesクレームを含められますが、そのロールを検証するのはApp Service認証ではなく、対象アプリのコード側です。(Microsoft Learn)

実務では、次のように分けると管理しやすくなります。

MCPツールの種類	認可の考え方
読み取り専用ツール	mcp.readなどの低権限スコープで許可
更新系ツール	mcp.writeや業務ロールを要求
管理系ツール	管理者グループまたはアプリロールを必須にする
外部API呼び出し	ユーザー委任が必要か、サーバー側マネージドIDでよいかを分ける
危険操作	追加確認、承認フロー、レート制限、監査を必須にする

「認証済みユーザーなら全ツール実行可」は避けるべきです。MCPではツール単位で実行できる操作が大きく変わるため、API単位ではなくツール単位の認可設計が必要になります。

API Managementで入口を統制する

Azure API Managementを前段に置くと、MCPサーバーの入口を統制しやすくなります。APIMでは、validate-jwtポリシーによりJWTの存在と有効性を検証できます。また、Microsoft Entra IDが発行したJWTを検証する場合は、validate-azure-ad-tokenポリシーも利用できます。(Microsoft Learn)

APIMを使う場合の基本方針は、次の通りです。

APIMで行うこと	目的
JWTまたはEntraトークン検証	無効なトークンをApp Serviceへ到達させない
audience、issuer、scopeの検証	別API向けトークンの流用を防ぐ
レート制限	エージェント暴走やプロンプト経由の大量呼び出しを抑える
メソッド制限	想定外のHTTPメソッドを拒否する
リクエストサイズ制限	大量ペイロードやログ汚染を抑える
ログ付与	correlation ID、クライアントID、ユーザーIDを追跡する

APIMのサブスクリプションキーだけをMCPサーバーの認証として扱うのは不十分です。サブスクリプションキーは呼び出し元アプリや契約単位の制御には使えますが、ユーザー本人の委任、スコープ、ロール、トークン期限、同意履歴の代わりにはなりません。

App Serviceを直接公開しない

MCPサーバーをApp Serviceでホストする場合、認証だけでなくネットワーク経路も確認してください。App Serviceのアクセス制限は、受信アクセスをブロックまたはフィルターするファイアウォールに相当します。既定のエントリポイントは公開されるため、制限がない場合はインターネットから到達できる可能性があります。(Microsoft Learn)

Private Endpointを使うと、クライアントはAzure Private Link経由でApp Serviceへ接続でき、パブリックインターネットへの露出をなくす構成を取れます。Microsoft Learnでは、Private Endpointとパブリックネットワークアクセス無効化により公開露出を排除できると説明されています。(Microsoft Learn)

ただし、Private Endpointを作っただけで完了ではありません。DNS、SCM/Kuduエンドポイント、デプロイ経路、APIMやFront Doorからのバックエンド到達性を合わせて確認してください。

よくある抜け漏れ	影響	対応
App Serviceの既定ホスト名が直接到達可能	APIMを迂回される	Public network access無効化またはアクセス制限
Kudu/SCMが公開されたまま	デプロイ面やファイル操作面が狙われる	SCM側にもアクセス制限を適用
Private DNS未設定	内部から名前解決できず403や接続失敗	Private DNS Zoneを構成
APIMだけで認証しApp Service側は匿名	バイパス時に無防備	App Service側にも認証またはネットワーク制限
検証スロットだけ公開	本番同等データにアクセスされる	スロットごとに認証とアクセス制限を確認

シークレットはKey VaultとマネージドIDへ寄せる

Astrix Researchの調査では、静的APIキーやPATへの依存、環境変数経由の資格情報利用が多いことが指摘されています。APIキーやPATは長期化しやすく、漏えい時に権限範囲が大きくなりがちです。(Astrix Security)

Azure App Serviceでは、マネージドIDを使うことで、Microsoft Entra IDで保護されたリソースへシークレットを自前管理せずにアクセスできます。Microsoft Learnでは、マネージドIDによりAzureプラットフォームがIDを管理し、シークレットのプロビジョニングやローテーションが不要になると説明されています。(Microsoft Learn)

また、App ServiceのKey Vault参照を使うと、Key Vault内のシークレットをアプリ設定や接続文字列として参照できます。Key Vault参照では、既定でシステム割り当てマネージドIDを使用し、Key Vault Secrets UserロールまたはGet権限を付与する構成が案内されています。(Microsoft Learn)

管理者は、次の順番で見直すと安全です。

手順	作業	注意点
棚卸し	App ServiceのConfigurationからAPIキー、PAT、接続文字列を確認	名前だけでなく値の参照先も確認
分類	すぐ廃止できるキー、移行が必要なキー、外部SaaS連携キーに分ける	影響先を記録
移行	Azureリソース向けはマネージドIDへ移行	RBACは最小権限
格納	外部サービスのシークレットはKey Vaultへ移す	アプリ設定にはKey Vault参照を置く
ローテーション	既存キーを更新し、古いキーを無効化	ログやCI/CD変数も確認
監査	Key Vaultの取得失敗、異常なSecretGetを監視	正常時の頻度を把握

「環境変数に入れているから安全」とは考えないでください。環境変数はコード直書きよりは扱いやすいものの、長期キーを複数環境に配布している時点で漏えい時の影響は残ります。

必要な権限を事前に整理する

MCPサーバーの堅牢化では、App Service、Microsoft Entra ID、Key Vault、API Management、Azure Monitorにまたがる変更が発生します。作業者に広すぎる権限を一時付与すると、作業後に戻し忘れるリスクが出ます。

マネージドID関連のMicrosoft Learnでは、システム割り当てIDの作成にはApp Serviceへの書き込み権限、ユーザー割り当てIDの作成にはManaged Identity Contributor、IDの割り当てにはManaged Identity Operator、RBACロール割り当てにはRole Based Access Control AdministratorまたはUser Access Administratorなどが例示されています。(Microsoft Learn)

作業	必要になりやすい権限	運用上の注意
App Service認証設定	Webアプリの構成変更権限	本番反映前にスロットで検証
Entraアプリ登録	アプリ登録を作成・更新できる権限	所有者を個人だけにしない
APIアクセス許可・同意	管理者同意が必要な場合あり	影響するスコープを事前レビュー
マネージドID作成	Managed Identity Contributorなど	作業後の不要IDを削除
RBAC割り当て	RBAC管理権限	リソースグループ全体ではなく対象スコープへ
Key Vault権限	Key Vault管理またはRBAC管理権限	読み取り対象シークレットを限定
APIMポリシー変更	API Managementの編集権限	変更前後のポリシーを保存
監視設定	Azure Monitor、Log Analyticsの設定権限	アクショングループの通知先も確認

本番環境では、作業担当者、承認者、レビュー担当者を分けるのが理想です。特にEntraアプリ登録とKey Vault権限は、MCPサーバーの実効権限に直結します。

監査ログとアラートで見るべき項目

MCPサーバーは、通常のAPIよりも「どのツールを呼んだか」が重要です。HTTPリクエスト単位の成功・失敗だけでは、実際に何が実行されたのか判断できません。

Azure App Serviceは、Azure Monitor、Application Insights、ログストリーム、メトリック、アラート、アクティビティログなど複数の監視手段を提供します。Microsoft Learnでは、Azure Monitorがメトリックとログを収集し、可用性、パフォーマンス、回復性の把握と通知に使えると説明されています。(Microsoft Learn)

Application Insightsは、OpenTelemetryによるテレメトリ収集、可用性、失敗、パフォーマンス、アラート、ログ、Workbooksなどを利用できます。AIエージェント向けの監視ビューにも触れられており、MCPサーバーのようなエージェント連携の監視基盤としても候補になります。(Microsoft Learn)

最低限、次のログ項目を設計してください。

ログ項目	理由
呼び出し元ユーザーIDまたはクライアントID	誰が実行したかを追跡する
認証プロバイダー	Entra、外部IdP、アプリ認証を区別する
MCPツール名	実行された操作を把握する
スコープまたはロール	認可判断の根拠を残す
対象リソース	ファイル、DB、API、Key Vaultなどの影響範囲を追う
成功・失敗・拒否理由	調査時の切り分けに使う
correlation ID	APIM、App Service、下流APIのログをつなぐ
レイテンシとサイズ	異常な大量呼び出しや過負荷を検知する

Log Analyticsでの初期確認には、次のようなKQLを用意しておくと便利です。実際のテーブル名やカスタムディメンション名は、導入しているApplication Insightsの設定に合わせて調整してください。

requests
| where timestamp > ago(24h)
| where url has "/mcp" or operation_Name has "mcp"
| summarize
    total=count(),
    failed=countif(success == false),
    p95_duration_ms=percentile(duration, 95)
  by bin(timestamp, 15m), resultCode
| order by timestamp desc

ツール名をカスタムイベントとして記録している場合は、次のように異常な呼び出し増加を見つけられます。

customEvents
| where timestamp > ago(24h)
| where name == "mcp.tool.invoke"
| summarize count() by tostring(customDimensions.toolName), tostring(customDimensions.principalId), bin(timestamp, 1h)
| order by count_ desc

アラートは、まず次の5種類から始めると実用的です。

アラート	目安
401、403の急増	認証設定ミス、攻撃、期限切れトークンを検知
429の急増	エージェント暴走や自動リトライを検知
5xxの急増	認証変更後のアプリ側エラーを検知
Key Vaultアクセス拒否	マネージドIDやRBAC設定ミスを検知
管理系ツールの実行	高権限操作の監査通知

移行は段階的に進める

既存のMCPサーバーをいきなり完全なOAuth構成へ変えると、クライアント側の接続が止まる可能性があります。移行は、公開制限、認証追加、シークレット移行、監査強化の順で段階的に進めるのが安全です。

フェーズ	目的	実施内容
現状把握	影響範囲を明確にする	MCPサーバー、クライアント、ツール、下流リソースを一覧化
緊急制限	匿名公開を止める	IP制限、APIM経由化、一時的なアクセス制限
認証導入	OAuth/Entra認証を追加	App Service認証、Allowed token audiences、401応答を設定
認可整理	誰が何をできるか決める	スコープ、アプリロール、グループ、ツール単位の制御を設計
シークレット移行	長期キー依存を減らす	マネージドID、Key Vault参照、キーのローテーション
ネットワーク分離	バイパスをなくす	Private Endpoint、Public network access無効化、APIMバックエンド化
監視強化	異常を検知する	Application Insights、Log Analytics、アラート、ダッシュボード
本番切替	利用者影響を抑える	段階リリース、ロールバック手順、周知を実施

App Service認証では、環境ごとにアプリ登録や権限を分けることが推奨されています。ドキュメントでも、デプロイスロットごとに別のアプリ登録を使い、環境間で権限や同意を共有しないことが、テストの問題を本番へ波及させないために有効と説明されています。(Microsoft Learn)

社内周知で伝えるべきこと

MCPサーバーのセキュリティ見直しは、Azure管理者だけでは完結しません。開発者、AIエージェント利用者、セキュリティ担当、ヘルプデスクへ事前に伝える必要があります。

開発者向けには、次の内容を周知してください。

今後、本番または本番データへ接続するMCPサーバーは、匿名公開を禁止します。Azure App Serviceで公開する場合は、App Service認証またはAPI ManagementでMicrosoft Entra IDによる認証を必須とし、ツール単位のスコープまたはロールを設計してください。APIキーやPATをアプリ設定、環境変数、README、CI/CDログに残す構成は原則禁止します。

利用者向けには、接続URLや再サインイン、同意画面の変更を説明します。

MCPサーバーのセキュリティ強化に伴い、接続URLがAPI Management経由のURLへ変わる場合があります。初回接続時にMicrosoft Entra IDでのサインインや権限同意が求められることがあります。接続できない場合は、利用しているMCPクライアント名、表示されたエラー、時刻を添えて問い合わせてください。

セキュリティ・運用担当には、監査観点を共有します。

MCPサーバーでは、通常のAPIログに加えて、ツール名、呼び出し元、スコープ、下流リソース、拒否理由を監査対象にします。401、403、429、5xx、Key Vaultアクセス拒否、管理系ツール実行をアラート対象にしてください。

失敗しやすいポイント

MCPサーバーの安全対策では、設定したつもりでも抜け道が残ることがあります。特に次のミスは本番前に潰してください。

失敗例	何が危険か	対策
App Service認証を有効にしたが匿名許可のまま	認証が必須になっていない	Require authenticationを確認
APIMで認証しているがApp Service直URLが生きている	APIMを迂回される	Public network access無効化またはアクセス制限
audを検証していない	別API向けトークンを受ける可能性	Allowed token audiencesを設定
アプリロールを作ったがコードで見ていない	ロールが実効制御にならない	rolesやscpをアプリで検証
Key Vaultへ移したが広すぎる権限を付けた	漏えい時の影響が大きい	対象シークレット単位、最小権限にする
環境変数のAPIキーを残した	旧キーが使われ続ける	ローテーションと無効化を完了
ログにトークンやプロンプト全文を出している	機密情報が監査ログに残る	マスキングとログ設計を見直す
devとprodで同じEntraアプリ登録を使う	テスト変更が本番に影響する	環境ごとに分離
Kudu/SCMを制限していない	管理面が攻撃対象になる	SCM側のアクセス制限も設定
MCPクライアントのPRM対応を見ていない	認可フローで接続失敗する	クライアントごとに検証

特に「APIMを置いたから安全」という判断は危険です。App Serviceの直アクセス、Kudu/SCM、検証スロット、旧URL、古いAPIキーが残っていれば、そこが迂回経路になります。

管理者が次に取るべき行動

まず、Azure上のMCPサーバーを棚卸しし、匿名公開、長期キー、監査なしの有無を確認してください。該当するサーバーがある場合は、公開範囲を制限し、App Service認証またはAPI ManagementでMicrosoft Entra IDによる認証を入れることを優先します。

次に、マネージドIDとKey Vaultへ資格情報を移し、トークンのaud、スコープ、ロール、PRM対応を確認します。最後に、Application InsightsとLog Analyticsで、MCPツールの実行履歴、拒否ログ、異常な呼び出し増加を追える状態にしてください。

今回のNoticeは、MCPを使うなという話ではありません。MCPを本番で使うなら、AIエージェント用の特別なAPIとして扱い、認証、認可、ネットワーク、シークレット、監査を最初から設計に含めるべきだという警告です。Azure App ServiceでMCPサーバーを運用している管理者は、まず「誰でも呼べるMCPエンドポイントが残っていないか」から確認を始めましょう。