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 de cliente, consulte Configurar el 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 de línea de comando adicional:

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

Secretos y variables de entorno

Utilice 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, utilice MDB_MCP_API_CLIENT_ID y MDB_MCP_API_CLIENT_SECRET para la configuración del cliente 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 controlar 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 hay una nueva versión de MCP Server disponible, los usuarios pueden descargar e instalar el software. Esto puede provocar que los usuarios utilicen 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 cliente se conectan al servidor MCP a través de la red y utilizan HTTP Streamable. Esto proporciona un entorno compartido centralizado, accesible para múltiples 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 conlleva riesgos de seguridad adicionales y requiere una configuración segura.

• Como mínimo, debe configurar el aislamiento de la red, la autenticación en el servidor MCP y configurar la gestión de secretos en la nube o en las instalaciones.

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 contar con un servidor de autorización (AS) OAuth protegido por cuentas de usuario autenticadas y un proxy frente al servidor MCP que funcione como servidor de recursos (RS) OAuth. El agente funciona como un cliente OAuth.

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

1. El agente solicita acceso al servidor MCP. Este servidor 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 a acceder al RS, que es el proxy que protege el servidor MCP.

4. Al agente se le proporciona 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. Se confía en el proxy para proteger el servidor MCP. Omitir el proxy pone en riesgo el acceso al servidor MCP y a las bases de datos a las que este puede acceder.

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:

• Sólo se identifica el agente, no el usuario para el cual actúa el agente.

• No existe ningún método para auditar quién está realizando qué acción a través del servidor MCP.

• El acceso normalmente se controla de forma centralizada para todos los usuarios o directamente en el proxy.

Suplantación de identidad de usuario

No utilice la suplantación de usuario.

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

• Solo se identifica al usuario. Se oculta que el agente actúa en su nombre.

• Las credenciales de usuario se filtran a sistemas intermedios, lo que pone en riesgo las cuentas de usuario.

• 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 se pueden suplantar de identidad ni reproducir no pueden funcionar.

Autenticación de paso a través

No utilice autenticación de paso a través.

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 potencialmente omitir 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 predeterminada para proporcionar una autenticación de contraseña segura.

• Autenticación de certificadomTLS 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 de colección adicional para limitar el acceso a la colección.

Seguridad de red

Recomendaciones para el aislamiento de la red:

• Implemente clústeres en una VPC o VNet privada sin acceso directo a Internet.

• Conexiones seguras a la red privada en la nube con peering VPC y puntos finales 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 MongoDB únicamente a servidores de aplicaciones autorizados.

• Configure reglas de firewall en la nube con grupos de seguridad y una ACL para el tráfico de red entrante y saliente.

• Deshabilite los puertos no cifrados y aplique 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. Proteja estos directorios con permisos del sistema de archivos, ya que pueden contener información confidencial.