Sécuriser votre déploiement de serveur MCP Azure

Azure MCP Server connecte des agents IA à des services Azure, exécute des outils en votre nom et les répartiteurs accèdent à vos ressources Azure via les jetons qui autorisent chaque appel. Étant donné que le serveur MCP Azure se trouve entre vos agents et vos ressources cloud, vous devez protéger les Azure serveur MCP lui-même, les jetons qui autorisent l’accès, ainsi que les entrées et sorties de l’outil qui transitent par vos agents.

Cet article fournit des conseils sur la meilleure sécurisation de votre déploiement de serveur MCP Azure.

Authentification et autorisation

Le serveur MCP Azure utilise Microsoft Entra ID via la bibliothèque Azure Identity pour authentifier les appelants. La spécification d’autorisation MCP nécessite OAuth 2.1. Traitez donc le serveur MCP Azure comme un serveur de ressources OAuth 2.1. Les clients doivent utiliser PKCE (Proof Key for Code Exchange) lors de l’exécution de flux de code d’autorisation. Appliquez les pratiques suivantes :

• Validez chaque jeton d’autorisation. Vérifiez l’émetteur, l’audience et l’expiration sur chaque jeton d’autorisation entrant avant d’autoriser l’exécution de l’outil. N’approuvez pas les jetons manquants ou émis pour une autre ressource.

• Lier des jetons d’autorisation à leur audience prévue. Utilisez des jetons liés à l’audience afin qu’un jeton émis pour un service ne puisse pas être relecté par rapport à un autre.

• Appliquez la correspondance stricte de redirect-URI et le consentement par client. Pour les flux de code d’autorisation, autorisez uniquement les URI de redirection préinscrirés, exacts et exigez le consentement par client. Par conséquent, un code d’autorisation intercepté ne peut pas être utilisé par un autre client.

• Suivez le contrôle d’accès en fonction du contrôle d’accès en fonction du privilège minimum. Accordez à chaque appelant uniquement les rôles RBAC Azure requis pour sa tâche. Le serveur MCP Azure reflète vos autorisations d’abonnement Azure : les appelants disposant d’un accès étendu aux abonnements peuvent appeler un large ensemble d’outils. Attributions de rôles d’étendue aussi étroites que possible. Activez uniquement les outils dont chaque appelant a besoin, car chaque outil accessible est ajouté à votre surface d’attaque.

• Préférez les identités de charge de travail. Dans les scénarios agentiques, utilisez des identités managées ou des identités de charge de travail plutôt que des secrets de longue durée ou des informations d’identification partagées. Lorsque les informations d'identification statiques sont inévitables ( par exemple, les clés API pour les services tiers qui ne prennent pas en charge l'identité de charge de travail) stockent-les dans Azure Key Vault et les référencent à partir de votre configuration de déploiement. Ne stockez jamais les informations d’identification dans le code source ou les fichiers de configuration en texte brut et faites-les pivoter selon une planification régulière.

• Évitez le modèle d’adjoint confus. Limitez l'Azure l'identité et les autorisations Azure du serveur MCP au minimum dont il a besoin pour fonctionner. Ne laissez pas le serveur agir comme un adjoint qui prête ses privilèges généraux à un appelant à privilèges inférieurs : séparez l’identité d’exécution du serveur de l’autorisation de l’appelant et appliquez les vérifications d’autorisation par appelant plutôt que de s’appuyer uniquement sur les propres informations d’identification du serveur.

Protection du serveur MCP à distance Azure

Lorsque vous déployez Azure serveur MCP en tant que serveur auto-hébergé distant, envisagez de le placer derrière Gestion des API Azure (APIM) comme passerelle d’application :

• Placez le serveur MCP Azure derrière une passerelle d’application. APIM peut valider Entra ID jetons avant que les requêtes atteignent votre serveur MCP Azure, ce qui supprime la nécessité pour votre code d’application d’inspecter les jetons.

• Appliquez des stratégies de passerelle pour la limitation et l’audit de débit. Utilisez des stratégies APIM pour limiter la fréquence à laquelle les appelants peuvent effectuer des requêtes, restreindre les chemins d’accès aux outils autorisés et journaliser chaque requête à des fins d’audit.

• Centraliser le contrôle d’accès à un seul point d’étranglement. Une passerelle fournit un point de choke unique pour le contrôle d’accès et l’observabilité sur plusieurs outils MCP en aval.

Protégez le point de terminaison auquel se connectent les clients mcP Server Azure. Une URL substituée ou usurpée peut recevoir des demandes d’exécution d’outils et exposer des informations d’identification ou des données de ressources Azure. Pour réduire ce risque :

• Connectez-vous uniquement aux points de terminaison de serveur MCP approuvés Azure. Utilisez uniquement les points de terminaison que vous avez provisionnés ou que votre équipe expose via APIM. Ne dérivez pas l'URL du serveur MCP Azure à partir des réponses de découverte fournies par l'utilisateur ou non authentifiées.

• Vérifiez le certificat TLS du serveur MCP Azure. Vérifiez que le point de terminaison correspond à l’hôte attendu. Lorsque vous utilisez APIM, routez les clients via la passerelle afin que le point de terminaison de stockage ne puisse pas être redirigé en mode silencieux.

• Échec de la fermeture des erreurs de certificat. Traitez un certificat Azure de serveur MCP non vérifié ou non reconnu comme un échec de connexion, et non un avertissement de contournement.

Pour obtenir des options d’auto-hébergement, consultez Déployer un serveur MCP auto-hébergé Azure.

Renforcement du déploiement local

Un serveur MCP local Azure s’exécute dans votre environnement de développement pour une utilisation de développement. Étant donné qu’il peut agir avec votre identité de Azure, passez en revue ce que votre compte connecté peut accéder avant de connecter un agent à Azure ressources :

• Passez en revue vos autorisations de Azure. Vérifiez les Azure rôles RBAC attribués à votre compte de développeur et supprimez les autorisations d'abonnement ou de groupe d'administration étendues qui ne sont pas nécessaires pour la tâche.

• Limitez l’accès local. Exécutez le serveur MCP local Azure à partir d'une station de travail ou d'un conteneur approuvé et n'exposez pas le point de terminaison local à des réseaux non approuvés ou à d'autres utilisateurs sur l'ordinateur.

• Conservez le serveur local actif. Utilisez les packages MCP Server actuels Azure et les dépendances corrigées, en particulier avant de tester les ressources de non-production Azure.

• Exécution locale du bac à sable. Exécutez le serveur MCP local Azure dans un conteneur ou un bac à sable avec un système de fichiers restreint et un accès réseau, et conservez la chaîne d’outils corrigée, afin de limiter l’impact de l’injection de commandes et du chemin d’accès lorsque les outils génèrent des sous-processus.

N'utilisez pas de serveur MCP local Azure pour gérer les données de production ou les informations d'identification de production.

Empoisonnement des outils et injection rapide

Les descriptions des outils MCP et les réponses aux outils sont des entrées dans le contexte de votre agent. Si les métadonnées de l’outil ou la sortie de l’outil sont malveillantes, il peut influencer un agent qui a accès à Azure outils MCP Server et les autorisations de Azure derrière eux.

Pour réduire ce risque pour les déploiements de serveur MCP Azure :

• Préférez le serveur MCP Microsoft officiel géré Azure. Utilisez le serveur MCP Azure premier tiers pour les services Azure au lieu d’un serveur non vérifié qui expose des outils Azure similaires. Traitez les modifications de schéma de l’outil en tant que modifications de dépendance qui nécessitent une révision.

• Faites confiance, mais vérifiez le contexte de l’outil. Traitez les descriptions et réponses des outils comme une entrée non approuvée à l’agent. Passez en revue les définitions d’outils avant l’utilisation de la production, puis validez ou désinfectez les données que les réponses des outils passent dans le contexte de l’agent.

• Définitions d’outils de contrôle des modifications. Passez en revue et épinglez les schémas et descriptions des outils connus et exigez une nouvelle approbation avant que les métadonnées de l’outil mises à jour prennent effet, afin qu’un serveur ne puisse pas modifier silencieusement le comportement après approbation (une chaîne d’approvisionnement « pull de tapis »).

• Utilisez Azure contrôles de sécurité où ils correspondent à votre architecture. Évaluez les contrôles dans Microsoft contrôles de sécurité pour inspecter le contexte de l’agent, détecter les flux de données sensibles et surveiller Azure charges de travail IA. Vérifiez chaque chemin d’intégration avant de l’utiliser en production.

Approbation de serveur MCP tierce

De nombreux environnements de développement exécutent plusieurs serveurs MCP en même temps. Pour Azure travail, préférez les Microsoft officiels gérés Azure MCP Server par des alternatives de communauté pour les services Azure.

Si vous ajoutez un serveur MCP tiers en regard de Azure serveur MCP :

• Vérifiez le chemin d’accès de l’éditeur et de la mise à jour. Utilisez des serveurs à partir d’éditeurs approuvés avec un contact de sécurité publique. Passez en revue les journaux de modification et les mises à jour de package avant d’autoriser le serveur tiers dans un environnement d’agent qui peut également atteindre Azure outils mcP Server.

• Séparez les contextes d’informations d’identification. Ne laissez pas un serveur non vérifié partager les informations d'identification, le système de fichiers ou l'accès réseau utilisé par Azure serveur MCP. Exécutez des serveurs non approuvés avec des privilèges minimum dans un environnement isolé.

• Passez en revue les outils dans le contexte complet de l’agent. Un serveur malveillant peut utiliser ses descriptions d’outils pour influencer le comportement de l’agent vers d’autres serveurs approuvés dans le même contexte, y compris Azure serveur MCP. Auditez les descriptions des outils pour chaque serveur que vous configurez, et non seulement les outils Azure.

Gouvernance et surveillance

Suivez les Azure instances de serveur MCP exécutées dans votre environnement et surveillez leur activité :

• Inventaire des serveurs approuvés. Conservez une base de référence connue des points de terminaison de serveur MCP inscrits Azure, par exemple avec Azure Centre d’API, afin de détecter les serveurs « fantômes » non inscrits qui se trouvent en dehors de la gouvernance.

• Surveillez l’activité et conservez les preuves. Mettre en corrélation Azure activité du serveur MCP dans Microsoft Sentinel et conserver les journaux d’audit Microsoft Purview afin de pouvoir examiner les appels d’outils suspects.

contrôles de sécurité Microsoft

Utilisez les services de sécurité Microsoft suivants pour ajouter la défense en profondeur pour Azure charges de travail du serveur MCP. L’applicabilité de chaque contrôle à votre déploiement spécifique dépend de votre architecture. Évaluez chaque contrôle dans le contexte de votre propre environnement :

• Inspectez le contexte de l’agent avec les boucliers d’invite. Utilisez Azure AI Sécurité du Contenu Boucliers d'invite pour inspecter le contenu entrant dans le contexte de votre agent, y compris les descriptions des outils et les sorties des outils, et détecter les tentatives potentielles d'injection d'invite. Envisagez d’intégrer des boucliers d’invite dans votre pipeline d’agent lorsque vous utilisez des métadonnées d’outil chargées dynamiquement. Pour plus d’informations, consultez Boucliers d’invite.

• Détecter les flux de données sensibles avec Purview DLP. Lorsque votre charge de travail est explicitement intégrée à Microsoft Purview, utilisez des stratégies Purview Data Loss Prevention pour détecter et marquer des données sensibles dans les flux de données associés à vos agents. La couverture des paramètres d’appel d’outils arbitraires n’est pas automatique : elle dépend de votre architecture de déploiement et des connecteurs Purview utilisés par votre charge de travail. Déterminez si votre chemin d’intégration spécifique prend en charge les contrôles dont vous avez besoin avant de vous appuyer sur DLP pour les charges de travail de l’agent. Pour plus d’informations, consultez la documentation Microsoft Purview.

• Surveillez les charges de travail IA avec Defender for Cloud. Utilisez Microsoft Defender for Cloud protection contre les menaces IA pour la détection des menaces d’exécution sur les charges de travail IA, y compris les alertes sur les activités suspectes dans Azure OpenAI et Azure appels d’API du service d’inférence du modèle IA. La couverture ne s'étend pas automatiquement aux sorties arbitraires de l'outil MCP : elle s'applique à la couche de service IA Azure dans votre architecture. Pour plus d’informations, consultez protection contre les menaces ia.

Contenu connexe

• Qu’est-ce que le serveur Azure MCP ?

• Concepts du serveur Azure MCP

• Déployer un serveur MCP auto-hébergé Azure