Mejores prácticas de seguridad del servidor MCP de MongoDB

Ejemplo de archivo de configuración JSON

El siguiente ejemplo muestra --readOnly en el archivo de configuración JSON del cliente MCP para la aplicación de cliente Claude Desktop:

{
   "mcpServers": {
      "MongoDB": {
         "type": "stdio",
         "command": "npx",
         "args": [
            "-y",
            "mongodb-mcp-server@latest",
            "--readOnly"
         ],
         "env": {
            "MDB_MCP_CONNECTION_STRING":
            "mongodb://localhost:27017/myDatabase"
         }
      }
   }
}

Para ver otros ejemplos de archivos de configuración JSON del cliente, consulte Configurar archivo del servidor MCP.

Ejemplo de la línea de comandos

El siguiente ejemplo define la cadena de conexión del servidor MCP en una variable de entorno Unix para conectarse a un clúster Atlas:

export MDB_MCP_CONNECTION_STRING="mongodb://localhost:27017/myDatabase"

El siguiente ejemplo utiliza la variable de entorno anterior y también establece una opción adicional de línea de comandos:

npx -y mongodb-mcp-server@latest --readOnly

Secretos y variables de entorno

Utiliza variables de entorno en lugar de argumentos de línea de comandos para configuraciones sensibles, como credenciales de inicio de sesión e información de conexión. Por ejemplo, use MDB_MCP_API_CLIENT_ID y MDB_MCP_API_CLIENT_SECRET para la configuración del cliente de API, y MDB_MCP_CONNECTION_STRING para las cadenas de conexión.

Las variables de entorno son más seguras que los argumentos en la línea de comandos. Los argumentos en la línea de comandos pueden ser rastreados, almacenados en caché, incluidos en listas de procesos y registrados en diversas ubicaciones.

El siguiente ejemplo establece la variable de entorno MDB_MCP_READ_ONLY en true y establece la variable de entorno MDB_MCP_CONNECTION_STRING:

"MongoDB": {
   "type": "stdio",
   "command": "npx",
   "args": [
      "-y",
      "mongodb-mcp-server@latest",
   ],
   "env": {
      "MDB_MCP_READ_ONLY": "true",
      "MDB_MCP_CONNECTION_STRING":
      "mongodb://127.0.0.1:27019/?directConnection=true"
   }
}

Para obtener más información sobre las variables de entorno, consulte Definición de variables de entorno del servidor MCP en el sistema operativo.

Servidor MCP local

En un servidor MCP local, el servidor MCP y la aplicación cliente se ejecutan en el mismo ordenador.

Un servidor MCP local permite el control sobre el entorno de instalación:

• Configuración y dependencias: gestionas las dependencias del software MCP Server. Para definir los parámetros del Servidor MCP y las conexiones a bases de datos, edita los archivos en el equipo local.

• Seguridad de credenciales: la información confidencial de las claves API y las cadenas de conexión se almacena localmente en archivos de configuración o variables de entorno. Usted protege las credenciales.

• Actualizaciones manuales de software: Cuando esté disponible una nueva versión de MCP Server, los usuarios pueden descargar e instalar el software MCP Server. Esto puede hacer que los usuarios ejecuten diferentes versiones de MCP Server.

Servidor MCP remoto

En una implementación de servidor MCP remoto, el servidor MCP se ejecuta en una computadora en la nube o en un servidor local.

Las aplicaciones del cliente se conectan al servidor MCP a través de la red y utilizan HTTP Transferible. Esto proporciona un entorno compartido central que es accesible para varios usuarios, sistemas automatizados, aplicaciones y agentes de IA.

Tenga en cuenta los siguientes puntos para las implementaciones remotas del servidor MCP:

• La implementación remota tiene riesgos de seguridad adicionales y requiere una configuración segura.

• Como mínimo, necesitas configurar el aislamiento de la red, la autenticación con el Servidor MCP y establecer la gestión de secretos en la nube o on-premises.

Autorización delegada

En la autorización delegada, el usuario delega un subconjunto de su autoridad a un agente. MongoDB recomienda el uso de OAuth 2.1 con el servidor MCP.

Para operar con el Servidor MCP, una implementación debe tener un servidor de autorización OAuth (AS) protegido por cuentas de usuario autenticadas, y un proxy frente al servidor MCP que funcione como servidor de recursos OAuth (RS). El agente funciona como cliente OAuth.

La delegación de OAuth funciona de la siguiente manera:

1. El agente solicita acceso al servidor MCP. El Servidor MCP está protegido por un proxy.

2. El proxy envía el agente al AS, que inicia una solicitud de autorización

3. El usuario inicia sesión en el AS y autoriza al agente para acceder al RS, que es el proxy que protege el servidor MCP.

4. Se le da al agente un token de acceso para acceder al RS.

5. El agente utiliza el token de acceso para llamar al servidor MCP a través del proxy.

6. El proxy valida el token de acceso y permite la llamada al servidor MCP.

7. El servidor MCP recibe la solicitud de proxy y ejecuta el comando en la base de datos a través de la conexión segura configurada de forma estática.

El servidor MCP y la base de datos nunca leen el token de acceso. El proxy se considera protegido para proteger el Servidor MCP. Pasar por alto el proxy implica el riesgo de acceder al Servidor MCP y a las bases de datos a las que puede acceder el Servidor MCP.

El formato del token está oculto. LosJWT son un formato común que permite al proxy verificar de forma independiente el token emitido por el AS.

Autenticación directa

No se recomienda la autenticación directa.

Con la autenticación directa, el agente proporciona credenciales al proxy. El proxy autentica las credenciales. Las credenciales pueden ser una clave API u otra credencial que identifique al agente. El patrón es simple pero presenta los siguientes problemas:

• Solo se identifica al agente, no al usuario para el que actúa el agente.

• No hay ningún método para auditar quién está tomando qué acción a través del Servidor MCP.

• El acceso generalmente se controla de manera centralizada para todos los usuarios, o directamente en el proxy.

Suplantación de usuario

No use la suplantación de identidad de usuario.

Con la suplantación de usuarios, el usuario proporciona sus credenciales directamente al agente. El agente envía las credenciales al proxy para autenticación. La suplantación de identidad de usuario presenta los siguientes problemas:

• Solo se identifica al usuario. El hecho de que el agente actúe en nombre del usuario está oculto.

• Las credenciales del usuario se filtran a sistemas intermedios. Esto pone en riesgo las cuentas de los usuarios.

• Las acciones que el usuario puede realizar están permitidas para el agente y la liberación limitada de funciones es imposible.

• Desconectar un agente requiere rotación de credenciales de usuario, lo que interrumpe cuentas de usuario y sistemas.

• Las credenciales que no pueden ser objeto de suplantación de identidad ni pueden ser reproducidas no pueden operar.

Autenticación Passthrough

No utilice la autenticación pass-through.

En la autenticación de paso a través, el agente obtiene y transfiere las credenciales para acceder a la base de datos al proxy. El proxy valida las credenciales y las transfiere al servidor MCP. Este utiliza las credenciales para conectarse a la base de datos. La autenticación de paso a través presenta los siguientes problemas:

• Sólo pueden funcionar credenciales copiables y reproducibles, lo que limita las conexiones a opciones de baja seguridad.

• La cadena de conexión está oculta al sistema.

• Cualquiera puede omitir potencialmente la siguiente parte de la cadena.

Autenticación y autorización de bases de datos

El servidor MCP admite los siguientes métodos de autenticación de bases de datos:

• Autenticación empresarial con LDAP, certificados X.509, OIDC y Kerberos.

• Autenticación SCRAM-SHA-256 por defecto para proporcionar una autenticación de contraseña segura.

• Autenticación de certificados mTLS para cuentas de servicio y comunicación entre clústeres.

La base de datos MongoDB admite los siguientes métodos de autorización:

• RBAC para limitar el acceso a la base de datos.

• Permisos detallados de la base de datos para limitar el acceso a bases de datos específicas, colecciones individuales y operaciones como lectura, guardado y acciones administrativas.

• Roles de base de datos personalizados para equipos. Por ejemplo, acceso de solo lectura para el equipo de análisis y acceso de lectura y escritura para el equipo de operaciones.

• Seguridad adicional de la colección para limitar el acceso a la colección.

Seguridad de red

Recomendaciones para el aislamiento de la red:

• Desplegar clústeres en un VPC privado o en un VNet sin acceso directo a Internet.

• Conexiones seguras a la red privada de la nube con VPC emparejamiento y nodos privados.

• Restringir el acceso a la base de datos a direcciones IP específicas o bloques CIDR.

Recomendaciones para la configuración del firewall:

• Restrinja el acceso al puerto 27017 del servidor de MongoDB solo a los servidores de aplicaciones autorizados.

• Configure las reglas del firewall en la nube con Grupos de Seguridad y una ACL para el tráfico entrante y saliente de la red.

• Desactiva los puertos no cifrados y aplica TLS 1.2+ para todas las conexiones.

Seguridad del sistema de archivos

El servidor MCP utiliza directorios para almacenar registros y archivos de datos exportados. Protege estos directorios con permisos del sistema de archivos, ya que podrían contener información sensible.