Cifrado en reposo y TLS en tránsito

Proteger los datos de MongoDB requiere protección en dos puntos distintos: cifrado en tránsito (datos que se desplazan entre los clientes y MongoDB, o entre los miembros de un conjunto de réplicas) y cifrado en reposo (datos almacenados en disco). La autenticación controla quién puede conectarse, pero incluso un usuario autenticado que opere mediante una conexión sin cifrar expone sus credenciales y consultas a la interceptación de red. Juntos, TLS y el cifrado en reposo proporcionan una defensa en profundidad.

TLS (Transport Layer Security) cifra el canal de red entre los clientes de MongoDB, los controladores y las instancias mongod/mongos. Habilitar TLS evita las escuchas y los ataques de intermediario en la red. MongoDB 4.2 y versiones posteriores solo admiten TLS 1.1 y superiores, y TLS 1.3 está disponible en plataformas modernas. Use siempre TLS en cualquier entorno donde el tráfico de red pueda ser interceptado, incluidos los VPC en la nube a pesar del aislamiento a nivel de VPC.

TLS se configura en la sección net.tls de mongod.conf. Establezca mode: requireTLS para rechazar todas las conexiones sin cifrar. Debe proporcionar un archivo PEM que contenga el certificado y la clave privada del servidor. Opcionalmente, proporcione un CAFile para exigir que los clientes presenten certificados firmados por su CA (TLS mutuo).

El controlador oficial de MongoDB para Node.js habilita TLS cuando la URI de conexión utiliza mongodb+srv:// (Atlas siempre utiliza TLS) o cuando se establece la opción tls: true. En implementaciones autogestionadas, puede ser necesario proporcionar la ruta al archivo de la CA para que el controlador pueda verificar el certificado del servidor. Use variables de entorno para las rutas de los certificados, de modo que no queden codificadas directamente en el código fuente.

MongoDB ofrece cuatro modos TLS durante las fases de migración. disabled solo acepta conexiones sin cifrar (únicamente para desarrollo). allowTLS acepta conexiones TLS y sin cifrar (por compatibilidad con versiones anteriores). preferTLS utiliza TLS de forma predeterminada, pero acepta conexiones sin cifrar. requireTLS rechaza todas las conexiones que no usan TLS y es el único modo aceptable para implementaciones en producción.

El motor de almacenamiento predeterminado de MongoDB, WiredTiger, admite Encrypted Storage Engine (disponible en MongoDB Enterprise). Cifra los archivos de datos del disco mediante AES-256-CBC o AES-256-GCM. Aunque un atacante obtenga acceso al disco físico o a una instantánea del disco, no podrá leer los datos sin la clave de cifrado. Esto satisface requisitos de cumplimiento como GDPR, HIPAA y PCI-DSS, que exigen proteger los datos en reposo.

MongoDB Atlas proporciona cifrado en reposo mediante la gestión de claves del proveedor de nube: AWS KMS, Azure Key Vault o Google Cloud KMS. Los clientes pueden aportar su propia Customer Master Key (CMK), lo que les da control total; si elimina su CMK, Atlas no podrá descifrar sus datos. El cifrado en reposo de Atlas se habilita por proyecto en la configuración de seguridad y se aplica a todos los clústeres de ese proyecto.

El cifrado solo es tan sólido como la seguridad de sus claves. Siga estas prácticas recomendadas para la gestión de claves: almacene las claves de cifrado en un servicio de gestión de claves (KMS) dedicado, en lugar de hacerlo en el mismo servidor que la base de datos; rote las claves de cifrado con regularidad (MongoDB admite la rotación de claves sin volver a cifrar todos los datos); use claves independientes para desarrollo, staging y producción; y habilite los registros de auditoría de KMS para realizar un seguimiento de todos los eventos de acceso a las claves.

Los certificados TLS caducan, normalmente después de 1–2 años. MongoDB admite la rotación de certificados en línea: puede implementar un nuevo archivo PEM y enviar el comando rotateCertificates a mongod, que utilizará el nuevo certificado para todas las conexiones nuevas sin reiniciar el proceso. Planifique la renovación del certificado al menos 30 días antes de su caducidad para evitar imprevistos de última hora y caídas en producción.

TLS y el cifrado en reposo protegen los datos en tránsito y en disco, pero los controles a nivel de red añaden otra capa. En MongoDB Atlas, use entradas de IP Access List para incluir en la lista de permitidos únicamente los servidores de su aplicación y las IP de los desarrolladores. En producción, use VPC Peering o AWS PrivateLink para que el tráfico entre su aplicación y Atlas nunca atraviese la Internet pública, eliminando una gran clase de ataques basados en la red incluso antes de tener en cuenta TLS.

Una vez habilitado TLS, verifique que todas las conexiones estén cifradas comprobando connPoolStats o el registro de conexiones de MongoDB. MongoDB registra los fallos del handshake de TLS, lo que le permite identificar cualquier cliente antiguo que aún intente establecer conexiones sin cifrar. En Atlas, la pestaña Monitoring muestra las conexiones activas y su estado de TLS, por lo que resulta sencillo confirmar la aplicación completa antes de eliminar el modo allowTLS.

En esta lección ha aprendido lo siguiente: requireTLS en mongod.conf impone conexiones de clientes cifradas y debe ser el único modo utilizado en producción; WiredTiger Encrypted Storage Engine protege los archivos de datos en disco (Enterprise), mientras que Atlas proporciona cifrado en la nube basado en CMK; y los controles a nivel de red, como las listas de IP permitidas y el emparejamiento de VPC, añaden capas de protección más allá de TLS. A continuación veremos Client-Side Field Level Encryption.