Protección de la implementación del servidor MCP de Azure

Azure servidor MCP conecta los agentes de IA a Azure servicios, ejecuta herramientas en su nombre y agentes acceden a los recursos de Azure a través de los tokens que autorizan cada llamada. Dado que el servidor MCP de Azure se encuentra entre los agentes y los recursos en la nube, debe proteger el servidor MCP Azure, los tokens que autorizan el acceso y las entradas y salidas de la herramienta que fluyen a través de los agentes.

En este artículo se proporcionan instrucciones sobre cómo proteger mejor la implementación del servidor MCP de Azure.

Autenticación y autorización

El servidor MCP de Azure usa Microsoft Entra ID a través de la biblioteca de identidades de Azure para autenticar a los autores de llamadas. La especificación de autorización de MCP requiere OAuth 2.1, por lo que trata el Azure servidor MCP como servidor de recursos de OAuth 2.1. Los clientes deben usar PKCE (clave de prueba para código Exchange) al realizar flujos de código de autorización. Aplique los procedimientos siguientes:

  • Valide cada token de autorización. Compruebe el emisor, la audiencia y la expiración en cada token de autorización entrante antes de permitir la ejecución de la herramienta. No confíe en los tokens que faltan notificaciones necesarias o que se emitieron para un recurso diferente.

  • Enlazar tokens de autorización a su público previsto. Use tokens enlazados a audiencia para que un token emitido para un servicio no se pueda reproducir en otro.

  • Aplique la coincidencia estricta de URI de redirección y consentimiento por cliente. En el caso de los flujos de código de autorización, permita solo los URI de redirección exactos y requiera el consentimiento por cliente, por lo que un código de autorización interceptado no se puede canjear por otro cliente.

  • Siga RBAC con privilegios mínimos. Conceda a cada autor de llamada solo los roles de RBAC de Azure necesarios para su tarea. El Azure servidor MCP refleja los permisos de suscripción de Azure: los autores de llamadas que tienen acceso amplio a la suscripción pueden invocar un amplio conjunto de herramientas. Las asignaciones de roles de ámbito son lo más estrechas posible. Habilite solo las herramientas que necesita cada llamador, ya que cada herramienta accesible se agrega a la superficie expuesta a ataques.

  • Se prefieren identidades de carga de trabajo. En escenarios agente, use identidades administradas o identidades de carga de trabajo en lugar de secretos de larga duración o credenciales compartidas. Cuando las credenciales estáticas son inevitables( por ejemplo, claves de API para servicios de terceros que no admiten la identidad de carga de trabajo), almacénelas en Azure Key Vault y haga referencia a ellas desde la configuración de implementación. Nunca almacene las credenciales en el código fuente o en los archivos de configuración de texto sin formato y gire las credenciales según una programación normal.

  • Evite el patrón de adjunto confuso. Ámbito de la identidad y los permisos de Azure del servidor MCP del Azure al mínimo que necesita para funcionar. No deje que el servidor actúe como un adjunto que preste sus amplios privilegios a un autor de llamada con privilegios inferiores: separe la identidad de ejecución del servidor de la autorización del autor de la llamada y aplique comprobaciones de permisos por autor de llamada en lugar de confiar únicamente en las credenciales propias del servidor.

Protección remota del servidor MCP de Azure

Al implementar Azure servidor MCP como un servidor autohospedado remoto, considere la posibilidad de colocarlo detrás de Azure API Management (APIM) como puerta de enlace de cumplimiento:

  • Coloque el Azure servidor MCP detrás de una puerta de enlace de cumplimiento. APIM puede validar Entra ID tokens antes de que las solicitudes lleguen al servidor MCP de Azure, lo que elimina la necesidad de que el código de la aplicación inspeccione los tokens.

  • Aplique directivas de puerta de enlace para limitar la velocidad y la auditoría. Use directivas de APIM para limitar la frecuencia con la que los autores de llamadas pueden realizar solicitudes, restringir las rutas de acceso de herramientas permitidas y registrar cada solicitud con fines de auditoría.

  • Centralice el control de acceso en un único punto de ahogo. Una puerta de enlace proporciona un único punto de ahogo para el control de acceso y la observabilidad en varias herramientas de MCP de nivel inferior.

Proteja el punto de conexión al que Azure se conectan los clientes del servidor MCP. Una dirección URL sustituida o suplantada puede recibir solicitudes de ejecución de herramientas y exponer credenciales o datos de recursos Azure. Para reducir ese riesgo:

  • Conéctese solo a puntos de conexión de servidor MCP de confianza Azure. Use solo los puntos de conexión que aprovisionó o que el equipo expone a través de APIM. No derive la dirección URL del servidor MCP de Azure de las respuestas de detección proporcionadas por el usuario o no autenticadas.

  • Compruebe el certificado TLS del servidor MCP de Azure. Asegúrese de que el punto de conexión coincide con el host esperado. Al usar APIM, enrute los clientes a través de la puerta de enlace para que el punto de conexión de respaldo no se pueda redirigir de forma silenciosa.

  • Error cerrado en los errores de certificado. Trate un certificado de servidor MCP no comprobado o no reconocido Azure como un error de conexión, no una advertencia para omitir.

Para obtener opciones de autohospedado, consulte Implementación de un servidor MCP de Azure autohospedado.

Protección de la implementación local

Un Azure servidor MCP local se ejecuta en el entorno de desarrollador para su uso de desarrollo. Dado que puede actuar con la identidad de Azure, revise el acceso a la cuenta que ha iniciado sesión antes de conectar un agente a Azure recursos:

  • Revise los permisos de Azure. Compruebe los roles de RBAC de Azure asignados a su cuenta de desarrollador y quite permisos amplios de suscripción o grupo de administración que no sean necesarios para la tarea.

  • Limitar el acceso local. Ejecute el Azure servidor MCP local desde una estación de trabajo o contenedor de confianza y no exponga el punto de conexión local a redes que no son de confianza u otros usuarios del equipo.

  • Mantenga el servidor local actual. Use los paquetes actuales Azure servidor MCP y las dependencias revisadas, especialmente antes de realizar pruebas con recursos que no sean de producción Azure.

  • Ejecución local del espacio aislado. Ejecute el Azure servidor MCP local en un contenedor o espacio aislado con acceso de red y sistema de archivos restringido y mantenga la cadena de herramientas revisada, para limitar el impacto de la inserción de comandos y el recorrido de ruta de acceso cuando las herramientas generan subprocesos.

No use una Azure servidor MCP local para controlar los datos de producción o las credenciales de producción.

Intoxicación por herramienta e inyección rápida

Las descripciones de la herramienta MCP y las respuestas de herramientas son entradas para el contexto del agente. Si los metadatos de la herramienta o la salida de la herramienta son malintencionados, puede influir en un agente que tenga acceso a Azure herramientas del servidor MCP y los permisos de Azure detrás de ellos.

Para reducir este riesgo para las implementaciones de Azure servidor MCP:

  • Prefiere el servidor MCP oficial Microsoft mantenido Azure. Use el servidor MCP de Azure de primera entidad para servicios de Azure en lugar de un servidor no comprobado que exponga herramientas de Azure similares. Trate los cambios de esquema de la herramienta como cambios de dependencia que requieren revisión.

  • Confiar pero comprobar el contexto de la herramienta. Trate las descripciones y respuestas de la herramienta como entrada que no es de confianza para el agente. Revise las definiciones de herramientas antes del uso de producción y valide o sane los datos que las respuestas de la herramienta pasan al contexto del agente.

  • Definiciones de herramientas de control de cambios. Revise y ancle los esquemas y descripciones de herramientas conocidos, y requiera volver a aprobar antes de que los metadatos de la herramienta actualizados surtan efecto, por lo que un servidor no puede cambiar el comportamiento silenciosamente después de la aprobación (una "extracción de alfombras" de cadena de suministro).

  • Use Azure controles de seguridad en los que se ajusten a la arquitectura. Evalúe los controles de Microsoft controles de seguridad para inspeccionar el contexto del agente, detectar flujos de datos confidenciales y supervisar las cargas de trabajo de inteligencia artificial Azure. Compruebe cada ruta de integración antes de confiar en ella en producción.

Confianza de servidor MCP de terceros

Muchos entornos de desarrollador ejecutan varios servidores MCP al mismo tiempo. Para Azure trabajo, prefiere las alternativas oficiales de Microsoft Azure MCP Server a través de las alternativas de la comunidad para los servicios de Azure.

Si agrega un servidor MCP de terceros junto a Azure servidor MCP:

  • Compruebe el publicador y la ruta de acceso de actualización. Use servidores de editores de confianza con un contacto de seguridad pública. Revise los registros de cambios y las actualizaciones de paquetes antes de permitir que el servidor de terceros entre en un entorno de agente que también pueda acceder a Azure herramientas del servidor MCP.

  • Mantenga separados los contextos de credenciales. No permita que un servidor no comprobado comparta las credenciales, el sistema de archivos o el acceso a la red que usa Azure servidor MCP. Ejecute servidores que no son de confianza con privilegios mínimos en un entorno aislado.

  • Revise las herramientas en el contexto completo del agente. Un servidor malintencionado puede usar sus descripciones de herramientas para influir en el comportamiento del agente hacia otros servidores de confianza en el mismo contexto, incluido Azure servidor MCP. Audite las descripciones de herramientas de cada servidor que configure, no solo las herramientas de Azure.

Gobernanza y supervisión

Realice un seguimiento de los Azure instancias del servidor MCP que se ejecutan en su entorno y supervise su actividad:

  • Servidores aprobados por el inventario. Mantenga una base de referencia correcta conocida de los puntos de conexión de servidor MCP registrados Azure, por ejemplo, con el Centro de API de Azure, por lo que puede detectar servidores "shadow" no registrados que se encuentran fuera de la gobernanza.

  • Supervise la actividad y conserve la evidencia. Correlacionar Azure actividad del servidor MCP en Microsoft Sentinel y conservar los registros de auditoría de Microsoft Purview para poder investigar llamadas sospechosas a herramientas.

controles de seguridad de Microsoft

Use los siguientes servicios de seguridad Microsoft para agregar defensa en profundidad para Azure cargas de trabajo del servidor MCP. La aplicabilidad de cada control a la implementación específica depende de la arquitectura. Evalúe cada control en el contexto de su propio entorno:

  • Inspeccione el contexto del agente con Prompt Shields. Use Seguridad del contenido de Azure AI Prompt Shields para inspeccionar el contenido que entra en el contexto del agente ( incluidas las descripciones de herramientas y las salidas de herramientas) y detectar posibles intentos de inyección de mensajes. Considere la posibilidad de integrar Prompt Shields en la canalización del agente cuando se usan metadatos de herramientas cargados dinámicamente. Para obtener más información, consulte Prompt Shields.

  • Detectar flujos de datos confidenciales con DLP de Purview. Cuando la carga de trabajo se integre explícitamente con Microsoft Purview, use directivas de prevención de pérdida de datos de Purview para ayudar a detectar y marcar datos confidenciales en flujos de datos asociados a los agentes. La cobertura de parámetros arbitrarios de llamada a herramientas no es automática; depende de la arquitectura de implementación y de los conectores de Purview que usa la carga de trabajo. Evalúe si la ruta de acceso de integración específica admite los controles que necesita antes de confiar en DLP para cargas de trabajo del agente. Para obtener más información, consulte la documentación de Microsoft Purview.

  • Supervise las cargas de trabajo de IA con Defender for Cloud. Use Microsoft Defender para la nube protección contra amenazas de IA para la detección de amenazas en tiempo de ejecución en cargas de trabajo de IA, incluidas las alertas sobre la actividad sospechosa en Azure OpenAI y las llamadas api del servicio de inferencia del modelo de IA Azure. La cobertura no se extiende automáticamente a las salidas arbitrarias de la herramienta MCP; se aplica al nivel de servicio de inteligencia artificial de Azure en la arquitectura. Para más información, consulte Protección contra amenazas de IA.

Note

Los controles enumerados anteriormente son servicios de seguridad generales Azure. Compruebe que la ruta de integración de cada control es compatible con la arquitectura de implementación específica del servidor MCP de Azure antes de habilitarla en producción.

Contenido relacionado

  • Last updated on