Azure MCP Server は、AI エージェントを Azure サービスに接続し、ユーザーに代わってツールを実行し、各呼び出しを承認するトークンを介してAzure リソースへのアクセスを仲介します。 Azure MCP サーバーはエージェントとクラウド リソースの間にあるため、Azure MCP サーバー自体、アクセスを承認するトークン、およびエージェントを通過するツールの入力と出力を保護する必要があります。
この記事では、Azure MCP サーバーの展開を最適にセキュリティで保護する方法に関するガイダンスを提供します。
認証と承認
Azure MCP サーバーは、Azure ID ライブラリを介してMicrosoft Entra IDを使用して呼び出し元を認証します。 MCP 承認仕様には OAuth 2.1 が必要であるため、Azure MCP サーバーを OAuth 2.1 リソース サーバーとして扱います。 クライアントは、承認コード フローを実行するときに PKCE (コード Exchangeの証明キー) を使用する必要があります。 次のプラクティスを適用します。
すべての承認トークンを検証します。 ツールの実行を許可する前に、各受信承認トークンの発行者、対象ユーザー、有効期限を確認します。 必要な要求がないか、別のリソースに対して発行されたトークンを信頼しないでください。
承認トークンを目的の対象ユーザーにバインドします。 あるサービスに対して発行されたトークンを別のサービスに対して再生できないように、対象ユーザーバインド トークンを使用します。
厳密なリダイレクト URI 照合とクライアントごとの同意を適用します。 承認コード フローの場合は、事前登録された正確なリダイレクト URI のみを許可し、クライアントごとの同意を必要とするため、インターセプトされた承認コードを別のクライアントで引き換えることはできません。
最小特権 RBAC に従います。 各呼び出し元に、タスクに必要なAzure RBAC ロールのみを付与します。 Azure MCP サーバーには、Azure サブスクリプションのアクセス許可が反映されます。広範なサブスクリプション アクセス権を持つ呼び出し元は、広範なツールセットを呼び出すことができます。 ロールの割り当てを可能な限り狭くスコープします。 到達可能なすべてのツールが攻撃対象領域に追加されるため、各呼び出し元が必要とするツールのみを有効にします。
ワークロード ID を優先します。 エージェントシナリオでは、有効期間の長いシークレットや共有資格情報ではなく、マネージド ID またはワークロード ID を使用します。 静的な資格情報が避けられない場合 (ワークロード ID をサポートしていないサード パーティのサービスの API キーなど) は、Azure Key Vaultに格納し、デプロイ構成から参照します。 資格情報をソース コードまたはプレーンテキスト構成ファイルに保存し、定期的にローテーションしないでください。
混乱した副パターンは避けてください。 Azure MCP サーバーの独自のAzure ID とアクセス許可を、動作に必要な最小限の範囲に設定します。 低い特権を持つ呼び出し元に広範な特権を付与する代理としてサーバーを機能させないでください。つまり、サーバーの実行 ID を呼び出し元の承認から分離し、サーバー自身の資格情報のみに依存するのではなく、呼び出し元ごとのアクセス許可チェックを適用します。
リモート Azure MCP サーバー保護
Azure MCP Server をリモートのセルフホステッド サーバーとして展開する場合は、Azure API Management (APIM) の背後に強制ゲートウェイとして配置することを検討してください。
Azure MCP サーバーを強制ゲートウェイの背後に配置します。 APIM は、要求が Azure MCP Server に到達する前にEntra IDトークンを検証できるため、アプリケーション コードでトークンを検査する必要がなくなります。
レート制限と監査にゲートウェイ ポリシーを適用します。 APIM ポリシーを使用して、呼び出し元が要求を行うことができる頻度を制限し、許可されたツール パスを制限し、監査のためにすべての要求をログに記録します。
1 つのチョーク ポイントでアクセス制御を一元化します。 ゲートウェイは、複数のダウンストリーム MCP ツール間でアクセス制御と可観測性を実現する単一のチョーク ポイントを提供します。
MCP サーバー クライアントが接続Azureエンドポイントを保護します。 置換された URL またはスプーフィングされた URL は、ツール実行要求を受信し、資格情報またはAzureリソース データを公開できます。 そのリスクを軽減するには:
信頼された Azure MCP サーバー エンドポイントにのみ接続します。 プロビジョニングしたエンドポイント、または APIM を介してチームが公開するエンドポイントのみを使用します。 ユーザー指定の入力または認証されていない検出応答から、Azure MCP サーバー URL を派生しないでください。
Azure MCP サーバーの TLS 証明書を確認します。 エンドポイントが想定されるホストと一致していることを確認します。 APIM を使用する場合は、ゲートウェイ経由でクライアントをルーティングし、バッキング エンドポイントをサイレント リダイレクトできないようにします。
証明書エラーで閉じられました。 MCP Server 証明書をバイパスする警告ではなく、未確認または認識されないAzure接続エラーとして扱います。
セルフホスティング オプションについては、セルフホステッド Azure MCP サーバーのデプロイに関するページを参照してください。
ローカル デプロイのセキュリティ強化
ローカル Azure MCP サーバーは、開発環境で開発用に実行されます。 Azure ID で動作する可能性があるため、エージェントをAzureリソースに接続する前に、サインインしているアカウントがアクセスできる内容を確認します。
Azureのアクセス許可を確認します。 開発者アカウントに割り当てられているAzure RBAC ロールを確認し、タスクに必要のない広範なサブスクリプションまたは管理グループのアクセス許可を削除します。
ローカル アクセスを制限します。 信頼されたワークステーションまたはコンテナーからローカル Azure MCP サーバーを実行し、信頼されていないネットワークやコンピューター上の他のユーザーにローカル エンドポイントを公開しないでください。
ローカル サーバーを最新の状態に保ちます。 特に非運用Azure リソースに対してテストする前に、現在の Azure MCP Server パッケージと修正プログラムが適用された依存関係を使用します。
サンドボックスローカル実行。 ファイルシステムとネットワーク アクセスが制限されたコンテナーまたはサンドボックスでローカル Azure MCP サーバーを実行し、ツールチェーンにパッチを適用して、ツールがサブプロセスを生成するときのコマンドインジェクションとパス トラバーサルの影響を制限します。
運用データや運用資格情報を処理するために、ローカル Azure MCP サーバーを使用しないでください。
ツールの中毒と迅速な注入
MCP ツールの説明とツールの応答は、エージェントのコンテキストへの入力です。 ツールのメタデータまたはツールの出力が悪意のある場合、Azure MCP Server ツールにアクセスできるエージェントとその背後にあるAzureのアクセス許可に影響を与える可能性があります。
Azure MCP サーバーの展開でこのリスクを軽減するには、次の手順を実行します。
MCP サーバー Azure、公式のMicrosoft保守を優先します。 同様のAzure ツールを公開する未確認のサーバーではなく、Azure サービス用のファースト パーティ Azure MCP サーバーを使用します。 ツール スキーマの変更は、レビューを必要とする依存関係の変更として扱います。
ツール コンテキストを信頼して検証します。 ツールの説明と応答を、エージェントへの信頼されていない入力として扱います。 運用環境で使用する前にツール定義を確認し、ツールの応答がエージェント コンテキストに戻るデータを検証またはサニタイズします。
変更制御ツールの定義。 既知の適切なツールのスキーマと説明を確認してピン留めし、更新されたツール メタデータが有効になるまでに再承認が必要になるため、サーバーは承認後に動作をサイレントに変更できません (サプライ チェーンの "ラグ プル")。
アーキテクチャに合ったAzureセキュリティ コントロールを使用します。 Microsoftセキュリティ コントロールのコントロールを評価して、エージェント コンテキストの検査、機密データ フローの検出、AI ワークロードAzure監視します。 運用環境で使用する前に、各統合パスを確認します。
サード パーティ製 MCP サーバーの信頼
多くの開発者環境では、複数の MCP サーバーが同時に実行されます。 Azure作業の場合は、Azure サービスのコミュニティの代替手段よりも、公式のMicrosoft保守Azure MCP Server を優先します。
Azure MCP サーバーの横にサードパーティの MCP サーバーを追加する場合:
発行元と更新プログラムのパスを確認します。 パブリック セキュリティ連絡先を持つ信頼できる発行元のサーバーを使用します。 MCP サーバー ツールにもアクセスできるエージェント環境にサード パーティ製サーバーを許可する前に、変更ログとパッケージの更新Azure確認します。
資格情報コンテキストは別々に保持します。 未確認のサーバーが、Azure MCP サーバーによって使用される資格情報、ファイルシステム、またはネットワーク アクセスを共有しないようにします。 分離された環境で、最小限の特権で信頼されていないサーバーを実行します。
完全なエージェント コンテキスト全体でツールを確認します。 悪意のあるサーバーは、そのツールの説明を使用して、MCP サーバーなど、同じコンテキスト内の他の信頼されたサーバーに対するエージェントの動作Azure影響を与えることができます。 Azure ツールだけでなく、構成するすべてのサーバーのツールの説明を監査します。
ガバナンスと監視
環境内で実行されている MCP Server インスタンスAzureを追跡し、そのアクティビティを監視します。
承認されたサーバーのインベントリ。 Azure API センターなど、登録済みの Azure MCP サーバー エンドポイントの既知の適切なベースラインを維持して、ガバナンスの外部にある未登録の "シャドウ" サーバーを検出できるようにします。
アクティビティを監視し、証拠を保持します。 Microsoft Sentinel Azure MCP Server アクティビティを関連付け、監査ログMicrosoft Purview保持して、疑わしいツール呼び出しを調査できるようにします。
セキュリティ制御のMicrosoft
次のMicrosoftセキュリティ サービスを使用して、Azure MCP Server ワークロードの多層防御を追加します。 各コントロールを特定のデプロイに適用できるかどうかは、アーキテクチャによって異なります。 独自の環境のコンテキストで各コントロールを評価します。
プロンプト シールドを使用してエージェント コンテキストを検査します。 Azure AI Content Safety プロンプト シールドを使用して、エージェントのコンテキストに入るコンテンツ (ツールの説明やツールの出力など) を検査し、プロンプト挿入の試行の可能性を検出します。 動的に読み込まれたツール メタデータを使用している場合は、エージェント パイプラインに Prompt Shields を統合することを検討してください。 詳細については、「 プロンプト シールド」を参照してください。
Purview DLP を使用して機密データ フローを検出します。 ワークロードがMicrosoft Purviewと明示的に統合されている場合は、Purview データ損失防止ポリシーを使用して、エージェントに関連付けられているデータ フロー内の機密データを検出してフラグを設定します。 任意のツール呼び出しパラメーターのカバレッジは自動ではありません。デプロイ アーキテクチャと、ワークロードで使用する Purview コネクタによって異なります。 エージェント ワークロードに DLP を使用する前に、特定の統合パスで必要なコントロールがサポートされているかどうかを評価します。 詳細については、 Microsoft Purview のドキュメントを参照してください。
Defender for Cloudを使用して AI ワークロードを監視します。 Microsoft Defender for Cloud AI 脅威保護を使用して、Azure OpenAI での疑わしいアクティビティに関するアラートや、AI モデル推論サービス API 呼び出しAzureなど、AI ワークロードでの実行時の脅威検出を行います。 カバレッジは、任意の MCP ツール出力には自動的に拡張されません。これは、アーキテクチャ内の Azure AI サービス レイヤーに適用されます。 詳細については、「 AI 脅威の保護」を参照してください。
Note
前述のコントロールは、セキュリティ サービスAzure一般的です。 運用環境で有効にする前に、各コントロールの統合パスが特定の Azure MCP Server デプロイ アーキテクチャでサポートされていることを確認します。