Esta página describe las mejores prácticas de seguridad para el servidor MongoDB MCP.
Modo de solo lectura del servidor MCP
El Servidor MCP --readOnly option habilita el modo de solo lectura. --readOnly restringe el Servidor MCP para que solo ejecute herramientas que realicen operaciones de lectura, conexión y metadatos.
Por defecto, el modo de solo lectura no está habilitado y el servidor MCP permite operaciones de escritura en el clúster. Para mejorar la seguridad, habilite el modo de solo lectura del Servidor MCP y utilice un usuario de base de datos de solo lectura para conectarse a los clústeres.
El modo de solo lectura previene modificaciones accidentales o maliciosas de datos realizadas con el Servidor MCP.
Para habilitar el modo de solo lectura, incluye --readOnly en el archivo de configuración JSON de la aplicación cliente MCP o en la línea de comandos, o configura la variable de entorno del sistema operativo MDB_MCP_READ_ONLY en true. Las siguientes secciones muestran ejemplos de cada método.
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 otros archivos de configuración de JSON del cliente como ejemplo, consulta Configurar archivo de 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 de Unix para conectarse a un clúster de 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.
Acceso de solo lectura a la base de datos
Para una implementación segura, utiliza acceso de solo lectura a la base de datos con el servidor MCP:
Crea usuarios dedicados de bases de datos en modo lectura para conexiones con MCP servidores.
Utiliza el rol
readde la base de datos o crea un rol personalizado de solo lectura para los usuarios de base de datos.Nunca utilices las credenciales de la base de datos
writecon el MCP servidor.
Casos de uso para el acceso de solo lectura a la base de datos:
Análisis de datos: query y analiza datos de producción sin riesgo de modificación.
Reporte: genera informes a partir de datos en vivo.
Supervisión: examinar métricas de bases de datos e indicadores de desempeño.
Soporte de desarrollo: permitir que los desarrolladores hagan query de datos de producción con fines de depuración sin permitir el acceso de escritura.
Además, utiliza la opción Servidor MCP --readOnly para garantizar el acceso a los datos de solo lectura. Para detalles, consulte la sección anterior
Modo de solo lectura del servidor MCP.
Se recomienda el acceso a la base de datos en modo de solo lectura para la producción. Pero, considera un acceso de escritura limitado para los siguientes casos de uso:
Entornos de desarrollo y de prueba.
Realice tareas administrativas con la autorización adecuada.
Clústeres de pruebas aislados con datos no críticos.
Opciones de implementación del servidor MCP
Puede implementar el Servidor MCP local o remotamente.
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 sensible como las claves de API y las cadenas de conexión se almacena localmente en archivos de configuración o variables de entorno. Aseguras 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.
Cuándo implementar el servidor MCP localmente
Implementa un MCP Server local para los siguientes escenarios:
Se requiere una configuración sencilla para comenzar con MCP servidor en tu computadora.
Gestiona tu propia configuración y actualizaciones.
Uso de diferentes protocolos de transporte
Los protocolos de transporte MCP habilitan la comunicación de mensajes entre la aplicación del cliente y el Servidor MCP. Para un servidor MCP local, utiliza uno de los siguientes protocolos de transporte:
STDIO (Entrada/Salida Estándar): la aplicación cliente inicia el MCP servidor como un proceso hijo y se comunica usando pipes estándar del sistema operativo (
stdinystdout). MongoDB recomienda el protocolo de transporte STDIO para implementaciones locales.HTTP transmitido: El servidor MCP inicia un servidor en
localhost. El cliente se comunica con el MCP Server utilizando solicitudes HTTP streamable, lo que crea una sesión persistente. Se incluye un ID de sesión único en el encabezado de un mensaje para mantener el estado y el contexto de la interacción.
Advertencia
Con Streamable HTTP, el MCP servidor está vinculado a localhost
(127.0.0.1) por defecto. Esto garantiza que el MCP servidor sólo acepte conexiones que se originen en el mismo ordenador.
Vincular a 0.0.0.0 expone el servidor MCP a toda la red local, lo que permite que otros dispositivos en la misma red potencialmente accedan al servidor MCP. Este es un riesgo de seguridad y podría permitir el acceso no autorizado a tu contexto de base de datos. Si necesita exponer el servidor MCP fuera de localhost, implemente la autenticación de seguridad descrita en Protección de las conexiones al servidor MCP.
Ventajas y desventajas de los diferentes protocolos de transporte
STDIO crea un enlace directo entre la aplicación cliente y el Servidor MCP. STDIO es la mejor opción si solo una aplicación se comunica con el Servidor MCP, ya que la aplicación y el Servidor MCP están estrechamente vinculados entre sí. Cuando uses STDIO, el servidor MCP debe estar ejecutándose en el mismo equipo que la aplicación cliente.
Streamable HTTP es flexible y funciona como un servidor privado en su computadora. Varios clientes pueden conectarse al servidor MCP. El HTTP transmisible es fácil de probar. A diferencia de STDIO, Streamable HTTP también permite implementar remotamente y localmente el Servidor MCP.
Servidor MCP remoto
En una implementación remota del Servidor MCP, el Servidor MCP se ejecuta en una computadora en la nube o en un servidor on-premises.
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.
Ten en cuenta los siguientes puntos para las implementaciones remotas del MCP Server:
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.
Mejores prácticas de seguridad para HTTP transmitible
La comunicación en una implementación remota de MCP servidor generalmente utiliza Streamable HTTP. Ten en cuenta los siguientes puntos para Streamable HTTP:
Conservar la vinculación del servidor MCP a
localhost(127.0.0.1) para las conexiones, que es la opción por defecto.Vincular a
localhostrequiere que los administradores agreguen un proxy inverso delante del servidor MCP. Por ejemplo, utiliza un proxy inverso Nginx.El Servidor MCP depende del proxy inverso para detener el tráfico malicioso antes de que llegue al Servidor MCP.
Ventajas del servidor MCP remoto
Gestión centralizada: las políticas de seguridad, el registro, el control de versiones y el control de acceso se gestionan en un solo lugar.
Soporta automatización: Los pipelines de CI/CD, los marcos de pruebas automatizadas y otros agentes pueden funcionar como clientes para flujos de trabajo automatizados.
Desventajas del servidor remoto MCP
Hardware adicional: se requiere infraestructura de red y servidor dedicado.
Seguridad compleja: requiere seguridad de red, autenticación, autorización y gestión de certificados TLS.
Punto único de fallo: si el servidor remoto se cae, afecta a todos los usuarios. Considere implementar una alta disponibilidad para los entornos críticos.
Seguridad del servidor MCP remoto
En todos los sistemas MCP, la autenticación en el servidor MCP se realiza por separado de la autenticación en el servicio al que proporciona acceso el servidor MCP. El servidor MongoDB MCP proporciona acceso configurado estáticamente a las instancias de MongoDB que el MCP Server protege.
El servidor MCP no ofrece funcionalidades de autenticación o autorización entrantes; debes configurar la autenticación y autorización. Esto es especialmente importante para una implementación remota del MCP Servidor porque el MCP Servidor está disponible en una red.
El siguiente diagrama muestra un flujo de trabajo de autenticación.

Proteger las conexiones al servidor MCP
Todas las conexiones entrantes al servidor MCP deben estar protegidas, de lo contrario, la base de datos queda expuesta.
Las conexiones deben estar protegidas incluso si la conexión entre el Servidor MCP y la base de datos está completamente segura como se describe en las siguientes secciones. Esto se debe a que el MCP Server proporciona un punto de conexión separado.
La protección de las conexiones entrantes al servidor MCP requiere un servicio externo que opere en paralelo con el servidor MCP. Esto suele requerir un proxy inverso para aplicar los controles de acceso para las conexiones entrantes. El proxy asigna los derechos de acceso de la solicitud entrante a una instancia específica del servidor MCP, que está configurada de forma estática para conectarse a una instancia de base de datos MongoDB, ya sea localmente en el servidor MCP o en un clúster de Atlas.
Existen otros métodos para proteger el Servidor MCP. Para simplificar, las siguientes secciones suponen el uso de un patrón proxy.
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:
El agente solicita acceso al servidor MCP. El Servidor MCP está protegido por un proxy.
El proxy envía el agente al AS, que inicia una solicitud de autorización
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.
Se le da al agente un token de acceso para acceder al RS.
El agente utiliza el token de acceso para llamar al servidor MCP a través del proxy.
El proxy valida el token de acceso y permite la llamada al servidor MCP.
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. JWTs 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.
Anti-patrones de seguridad MCP
Las siguientes secciones describen anti-patrones que no se deben utilizar.
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, el agente obtiene y transmite credenciales para acceder a la base de datos al proxy. El proxy valida las credenciales y las pasa al Servidor MCP. El servidor MCP utiliza las credenciales para conectar con la base de datos. La autenticación de paso tiene los siguientes problemas:
Solo pueden operar credenciales copiables y reproducibles, lo que limita las conexiones a opciones de baja seguridad.
La cadena de conexión está oculta en el sistema.
Cualquiera puede omitir potencialmente la siguiente parte de la cadena.
Seguridad de bases de datos y redes
El método que el Servidor MCP utiliza para acceder de forma segura a la base de datos es diferente del método que se usa para proteger el acceso al Servidor MCP. Las siguientes secciones describen la seguridad de base de datos y de la red.
Autenticación y Autorización de Base de Datos
El servidor MCP admite los siguientes métodos de autenticación de bases de datos:
Autenticación de empresa 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 personalizados de base de datos 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 la 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.
Seguridad del directorio de registro
La logPath opción de configuración indica el directorio en el que el servidor MCP guarda las entradas de registro. Los registros pueden contener información sensible, como cadenas de conexión, patrones de query y detalles sobre errores.
Para asegurar el directorio de registros:
Establezca el propietario del directorio en la cuenta de usuario que ejecuta el Servidor MCP.
Configura los permisos de lectura y guardado sólo para el propietario.
Negar el acceso a todos los demás usuarios y procesos.
Revisa y rota regularmente los archivos de registro para prevenir el acceso no autorizado a datos históricos.
Seguridad del directorio de exportaciones
La exportsPath opción de configuración especifica el directorio en el que el MCP servidor almacena los archivos de datos exportados. Protege los archivos exportados contra el acceso no autorizado porque pueden contener registros de base de datos sensibles.
Para asegurar el directorio de exportaciones:
Establezca el propietario del directorio en la cuenta de usuario que ejecuta el Servidor MCP.
Configura los permisos de lectura y guardado sólo para el propietario.
Negar el acceso a todos los demás usuarios y procesos.
Supervise el tamaño del directorio para evitar el agotamiento del espacio en disco debido a acumulaciones de exportaciones.
Importante
Aísle tanto los directorios logPath como los exportsPath de otros procesos del sistema. datos sensibles a usuarios o aplicaciones no autorizados en el mismo sistema.
Permisos de la API de Atlas
Asigna permisos mínimos de Atlas API al usuario de Atlas para la implementación. Normalmente, utiliza solo los roles de proyecto y asígnalos únicamente a los proyectos específicos que necesites gestionar o ver.
Nota
Evite el rol Organization Owner a menos que requiera control administrativo sobre todos los proyectos y configuraciones en la organización. El Organization Owner rol raramente es necesario y puede ser un riesgo de seguridad.
La siguiente tabla muestra los roles de Atlas con los mínimos privilegios para asignar a tareas comunes:
Tarea a realizar | Rol con mínimos privilegios para asignar | Nivel de Rol |
|---|---|---|
Listar organizaciones y proyectos |
| organización |
Crear nuevos proyectos |
| organización |
Ver clústeres y bases de datos en un proyecto |
| Proyecto |
Crea y gestiona clústeres en un proyecto |
| Proyecto |
Administrar listas de acceso al proyecto |
| Proyecto |
Gestionar usuarios de base de datos |
| Proyecto |
Para obtener información completa sobre los roles de Atlas, consulta Roles de usuario de Atlas.