Conectar de forma segura los agentes de IA al servidor MCP de Webship

# Conectar de forma segura los agentes de IA al servidor MCP de Webship

Una conexión MCP a un servidor web no es un widget de chat. Es una interfaz de operaciones que puede inspeccionar el estado de producción, cambiar la política de enrutamiento y seguridad, recargar certificados, activar versiones estáticas, coordinar cambios en la flota e instalar una actualización Webship firmada.

Trátelo en consecuencia: como una API administrativa privilegiada. La configuración más segura de Webship mantiene el oyente MCP fuera del plano de datos público, lo vincula al bucle local, lo protege con TLS 1.3 y un token portador fuerte, y se accede a él a través de un túnel SSH autenticado.

Esta guía construye esa configuración, explica por qué existe cada límite y te proporciona una lista de verificación para operarla sin convertir la conveniencia en exposición.

Comience con el límite de confianza

El tráfico público de Webship y el tráfico de MCP utilizan escuchas separados. El plano de control de MCP está deshabilitado por defecto y nunca comparte el listener normal de HTTP, HTTP/2, HTTP/3 o WebTransport. Cuando está habilitado, sirve MCP a través de un endpoint dedicado de TLS 1.3 HTTP/1.1.

Un despliegue seguro tiene cuatro controles independientes:

1. Alcance de la red: el oyente MCP se vincula a 127.0.0.1, no a una dirección pública ni de LAN privada.
2. Identidad del transporte: el cliente verifica un certificado emitido por una CA en la que confía.
3. Autenticación de la aplicación: cada solicitud lleva un token portador fuerte.
4. Acceso administrativo: los operadores acceden al receptor de loopback a través de una cuenta SSH autenticada y un túnel.

Ninguno de estos controles reemplaza a otro. TLS sin una ruta de red privada todavía expone una superficie de autenticación. Un túnel sin verificación de certificados hace que la identidad del endpoint sea ambigua. Un token portador dentro de un archivo accesible públicamente no es un secreto.

Prepara el certificado y el token

Emita un certificado MCP dedicado desde su CA interna. Para el túnel mostrado a continuación, incluya localhost y 127.0.0.1 en los nombres alternativos del sujeto del certificado, luego instale la CA emisora en el almacén de confianza de la máquina cliente MCP. No resuelva un error de confianza con una opción de TLS insegura.

Crea un token único con al menos 32 bytes ASCII imprimibles y sin espacios en blanco. Un valor aleatorio de 32 bytes codificado en hexadecimal te da 64 caracteres seguros:

umask 077
openssl rand -hex 32

Webship actualmente lee el token MCP directamente de la configuración protegida TOML; token_file no es compatible. Almacene el resultado en un archivo de configuración que solo pueda leer la cuenta de servicio Webship y su grupo administrativo. No coloque el token en una unidad systemd, historial de shell, ticket, mensaje de chat o en un aviso enviado a un modelo de IA.

En un host típico de Debian:

sudo chown root:webship /etc/webship/production.toml
sudo chmod 0640 /etc/webship/production.toml
sudo chown root:webship /etc/webship/mcp-cert.pem /etc/webship/mcp-key.pem
sudo chmod 0644 /etc/webship/mcp-cert.pem
sudo chmod 0640 /etc/webship/mcp-key.pem

Adapte el usuario y el grupo del servicio a su instalación. La clave privada y la configuración deben ser legibles por Webship, pero no por cuentas no relacionadas.

Habilitar el oyente aislado

Agregue esta sección a la configuración activa Webship:

[security.mcp]
enabled = true
listen = "127.0.0.1:9443"
token = "replace-with-your-generated-64-character-token"
allowed_ips = []
expose_remote = false

[security.mcp.tls]
cert = "/etc/webship/mcp-cert.pem"
key = "/etc/webship/mcp-key.pem"

Una lista allowed_ips vacía no abre el endpoint. Los clientes de loopback permanecen permitidos por defecto. expose_remote = false hace explícito el límite previsto: si alguien más adelante cambia listen a una dirección no loopback, Webship rechaza la configuración en lugar de publicar silenciosamente el plano de control.

Webship también rechaza un oyente MCP habilitado sin TLS, sin un token, con un token corto o que contenga espacios, o con rutas de certificado vacías. Los tokens de marcador público se rechazan antes de la exposición remota.

Validar antes de reiniciar

El oyente MCP, la identidad TLS y los cambios de token reconstruyen el plano de control, por lo que requieren un reinicio del proceso. Valide la configuración completa primero:

/usr/local/bin/webship --check-config --config /etc/webship/production.toml
sudo systemctl restart webship
sudo systemctl status webship --no-pager

Confirme que el oyente existe solo en el bucle de retorno:

ss -ltn | grep '127.0.0.1:9443'

No agregue el puerto 9443 a las reglas de firewall públicas del host. El siguiente paso lo alcanzará a través de SSH.

Crear el túnel privado

Desde la estación de trabajo del administrador, reenvíe un puerto local al escuchador de bucle invertido de Webship:

ssh -N \
  -L 127.0.0.1:19443:127.0.0.1:9443 \
  webship-admin@edge.example.com

El cliente MCP ahora se conecta a https://localhost:19443/mcp. TCP llega al servidor SSH, SSH transporta la conexión al host, y el host abre la conexión final a Webship en el loopback. Cerrar la sesión SSH elimina esa ruta de inmediato.

Utilice autenticación SSH basada en clave, restrinja qué administradores pueden abrir el túnel y aplique sus controles normales de acceso a hosts. Si se requiere un host de salto, mantenga el receptor MCP en la interfaz de bucle invertido del host Webship y extienda la ruta SSH en lugar de ampliar el receptor.

Configurar el cliente MCP

Los formatos de configuración del cliente difieren, pero una entrada típica de HTTP MCP se ve así:

{
  "mcpServers": {
    "webship-production": {
      "url": "https://localhost:19443/mcp",
      "headers": {
        "Authorization": "Bearer <your-token>"
      }
    }
  }
}

Use el mecanismo secreto protegido del cliente cuando tenga uno. De lo contrario, restrinja la configuración del cliente a la cuenta del sistema operativo actual. El cliente HTTP, no el modelo, debe adjuntar el encabezado de autorización. Nunca pegue el token en vivo en una conversación.

Mantenga activada la verificación del certificado. Si el cliente rechaza el certificado, repare los nombres alternativos del sujeto del certificado o instale la CA interna correcta. No agregue una omisión permanente.

Haz que la primera sesión sea de solo lectura

Después de que el túnel y el cliente estén conectados, comience con el descubrimiento y la inspección:

1. Solicite tools/list; su respuesta es el esquema de argumentos autorizado para la versión en ejecución.
2. Llame a webship.get_config y registre la versión actual de la configuración.
3. Inspeccione webship.reverse_proxy.get_status, webship.security.get_status, webship.ddos.get_status y webship.tls.get_status según corresponda.
4. Use webship.policy.explain o webship.security.simulate antes de cambiar una política.
5. Confirme que la configuración devuelta redacta los tokens de portador.

Solo entonces prueba una mutación en un entorno que no sea de producción. Las mutaciones de configuración de Webship requieren el ID de versión actual. Se rechaza una escritura obsoleta en lugar de sobrescribir un cambio más reciente. La política candidata puede verificarse con verificación sombra y escenarios de laboratorio de tráfico antes de la activación.

Webship también rechaza las degradaciones de seguridad en vivo seleccionadas. Una solicitud MCP no puede desactivar un WAF activo, capa DDoS, API Shield, desafío de bots, política de autenticación en el borde o capa de encabezado de respuesta. Los cambios de listener, protocolo, trabajador, tiempo de ejecución y autenticación MCP vinculados al proceso requieren un reinicio deliberado.

Esos guardias reducen errores; no hacen que cada acción autorizada sea inofensiva. El token otorga una superficie de control poderosa, incluyendo operaciones de actualización y liberación. Revise las llamadas a herramientas propuestas tal como revisaría el comando de shell de un administrador.

Si la vinculación remota es inevitable

Loopback más SSH es el diseño recomendado. Si su entorno requiere un receptor de red privada, haga explícita la excepción:

[security.mcp]
enabled = true
listen = "10.20.0.15:9443"
expose_remote = true
allowed_ips = ["10.20.10.0/24"]
token = "replace-with-your-generated-64-character-token"

Mantén el bloque TLS del ejemplo anterior, usa un certificado que coincida con el nombre de DNS privado y aplica el mismo rango de origen en los firewalls del host y de la red. Nunca uses 0.0.0.0/0 o ::/0 como una lista de permitidos por conveniencia. Recuerda que una lista de permitidos de aplicación ve la dirección de origen que realmente llega a Webship; verifica el comportamiento cuando un balanceador de carga, una puerta de enlace NAT o una malla de servicios se encuentran delante de él.

La exposición remota aumenta el valor de los registros de acceso centralizados, las ventanas operativas cortas y la rotación rápida. No es necesaria únicamente porque el cliente MCP se ejecute en otra máquina; eso es exactamente lo que resuelve el túnel SSH.

Operar el plano de control deliberadamente

Utilice esta lista de verificación para la producción:

• Mantenga MCP deshabilitado donde ningún agente u operador lo necesite.
• Vincúlate al bucle local y usa un túnel SSH por defecto.
• Utilice una identidad TLS dedicada y mantenga habilitada la verificación del certificado.
• Genera un token de portador único para cada entorno Webship.
• Proteja el TOML, la configuración del cliente, la clave TLS y las claves SSH con permisos del sistema de archivos.
• Credenciales separadas para desarrollo, pruebas y producción.
• Inicie sesiones con herramientas de simulación de estado y políticas antes de las mutaciones.
• Conservar y revisar los eventos de auditoría de seguridad de Webship.
• Gire el token y reinicie Webship después de una posible exposición.
• Cierre los túneles cuando termine la sesión administrativa.

Para la respuesta a incidentes, cierre los túneles activos, restrinja la cuenta SSH, reemplace el token MCP en el TOML protegido, reinicie Webship y revise los registros recientes de auditoría de seguridad y de versiones de configuración. Si la clave privada TLS puede estar expuesta, emita un nuevo certificado y clave como parte del mismo reinicio. Después, pruebe el token antiguo y confirme que sea rechazado.

Un plano de control debe seguir siendo un plano de control

MCP es útil porque un agente puede inspeccionar el estado real y aplicar cambios validados sin enrutar esas operaciones a través de la ruta de solicitud pública. Esa ventaja desaparece si el oyente de control se convierte en otro punto final de internet.

Mantenga el límite simple: un receptor separado, accesibilidad de retorno, TLS verificado, una credencial de portador protegida, un túnel autenticado, cambios verificados por versión y un proceso de revisión humana para operaciones potentes. Webship proporciona el protocolo y las salvaguardas; el operador decide quién puede acceder a ellos.

Esta guía se basa en la documentación del operador Webship 1.3.1, ejemplos de configuración enviados, la validación y el código de transporte MCP, las protecciones de configuración en tiempo de ejecución y el catálogo de herramientas. Revise la documentación actual de Webship y la respuesta tools/list del servidor en funcionamiento antes de aplicarla a otra versión.