Atlas ofrece varias funcionalidades de cifrado para proteger los datos durante su transmisión, en reposo y en uso, salvaguardando los datos a lo largo de su ciclo de vida completo.
Nota
El Modelo de Responsabilidad Compartida de MongoDB Atlas define los deberes complementarios de MongoDB y sus clientes en el mantenimiento de un entorno de datos seguro y resiliente. Bajo este marco, MongoDB gestiona la seguridad y la integridad operativa de la plataforma subyacente, mientras que los clientes son responsables de la configuración, gestión y políticas de datos de sus implementaciones específicas. Para obtener un desglose detallado de la propiedad en materia de seguridad y excelencia operativa, consulta Modelo de responsabilidad compartida.
Funcionalidades para el cifrado de datos Atlas
Cifrado en tránsito
El cifrado en tránsito protege los datos durante la transmisión entre clientes y servidores, garantizando que sus datos no puedan ser inspeccionados mientras estén en movimiento. En Atlas, todo el tráfico de red a los clústeres está protegido por Transport Layer Security (TLS), que está habilitado por defecto y no se puede deshabilitar. Los datos transmitidos a y entre nodos se encriptan en tránsito mediante TLS, lo que garantiza una comunicación segura en todo momento.
Puedes seleccionar qué versión de TLS utilizar en Atlas. TLS 1.2 y una longitud de clave mínima de 128 bits son los ajustes por defecto recomendados. Todo el cifrado en tránsito está respaldado por OpenSSL FIPS Módulo de objetos.
Cifrado en reposo
El cifrado en reposo garantiza que todos los datos en disco estén cifrados y solo sean visibles una vez descifrados por un proceso o aplicación autorizados.
En Atlas, los datos del cliente se cifran automáticamente en reposo mediante AES-256. Este proceso utiliza el cifrado de disco del proveedor de nube, y el proveedor gestiona las llaves de cifrado. Este proceso no se puede desactivar.
Por defecto, el cifrado en reposo es cifrado a nivel de volumen.
Además, se puede habilitar el cifrado a nivel de base de datos trayendo la propia llave (BYOK). Esta es la clave administrada por el cliente (llave maestra de cliente (CMK)) que añades con un Key Management Service (KMS), como AWS KMS, Google Cloud KMS o Azure Key Vault. La funcionalidad BYOK proporciona cifrado a nivel de archivo y es equivalente al cifrado transparente de datos (TDE), que cumple con los requisitos empresariales de TDE. El cifrado con gestión de claves por parte del cliente añade otra capa de seguridad para una confidencialidad adicional y segmentación de datos.
Para obtener más información, consulta Cifrado en reposo con gestión de claves por parte del cliente.
Cifrado en uso
El cifrado en uso protege los datos mientras se procesan. MongoDB tiene dos características para el cifrado en uso para satisfacer sus necesidades de protección de datos: Cifrado de nivel de campo del lado del cliente y Queryable Encryption.
Client-side field-level encryption
Cifrado a nivel de campo del lado del cliente (CSFLE) es una capacidad de cifrado en uso que permite a una aplicación cliente cifrar datos sensibles antes de almacenarlos en la base de datos MongoDB. Los datos sensibles se cifran de forma transparente, permanecen cifrados a lo largo de todo su ciclo de vida y solo se descifran en el lado del cliente.
Puedes cifrar de forma selectiva campos individuales dentro de un documento, varios campos dentro del documento o el documento completo. Opcionalmente, puedes asegurar cada campo con su propia clave y descifrarlos de manera fluida en el cliente utilizando un driver de MongoDB. CSFLE utiliza AES-256 en modo CBC autenticado para cifrar datos.
Además, puedes seleccionar cifrado aleatorizado, que no se puede consultar, pero podría ser necesario para ciertos requerimientos de seguridad.
El siguiente diagrama demuestra un flujo de trabajo CSFLE donde los registros de los usuarios se almacenan en una base de datos MongoDB y son consultados por el cliente. El número de seguridad social (SSN) del usuario se cifrado antes de ser almacenado en la base de datos. Cuando la aplicación envía una basic equality query en el campo, el driver de MongoDB utiliza la clave para cifrar la query en el lado del cliente y envía la query cifrado al servidor. El servidor devuelve los resultados cifrados al cliente, quien posteriormente descifra los resultados antes de devolverlos al cliente autenticado en texto plano legible.
CSFLE es compatible con los principales servicios de gestión de claves on-premises y en la nube.
Queryable Encryption
Queryable Encryption ayuda a las organizaciones a proteger datos sensibles cuando se consultan. Al igual que CSFLE, permite que las aplicaciones cifren sus datos del lado del cliente antes de almacenarlos en la base de datos MongoDB. También permite que las aplicaciones realicen consultas expresivas, como consultas de igualdad, directamente sobre los datos cifrados mediante el uso de un algoritmo de búsqueda cifrado. Queryable Encryption garantiza protección para la información confidencial sin sacrificar la capacidad de realizar consultas sobre ella. Queryable Encryption siempre utiliza cifrado no determinista.
Para aprender sobre los algoritmos utilizados en Queryable Encryption, consulte informe técnico de Queryable Encryption.
El siguiente diagrama demuestra un flujo de trabajo de Queryable Encryption donde los registros de usuario se almacenan en una base de datos MongoDB y el cliente los consulta. La fecha de nacimiento (DOB) del usuario se cifra antes de almacenarla en la base de datos. Cuando la aplicación envía una query de rango expresivo en el campo, el driver de MongoDB utiliza la clave para cifrar la query y pasa un token criptográfico junto con ella al servidor de MongoDB. El server utiliza el algoritmo de búsqueda cifrado para procesar la query sin conocer los datos reales. Por último, el driver utiliza la clave para descifrar los resultados de la query y los devuelve al cliente autenticado como texto plano legible.
Recomendaciones para el cifrado de datos de Atlas
Las implementaciones de una sola región no tienen ningún aspecto único con respecto al cifrado de datos. Consulta la siguiente sección para ver "Todas las recomendaciones de paradigmas de implementación".
En implementaciones de multiregión y multi-nube, se puede activar el cifrado a nivel de base de datos utilizando una clave propia gestionada por el cliente (BYOK).
Algunos proveedores de KMS admiten capacidades de multiregión. Por ejemplo:
GCP KMS admite la implementación multiregión y la replicación automática de claves.
En AWS KMS, se necesita configurar explícitamente las claves para que sean de multiregión y replicarlas en cada región donde se implemente Atlas. Para obtener más información, consulta Crea claves de réplica multiregión en AWS.
No obstante, en el evento de una Interrupción del servicio regional que afecte al punto final KMS configurado, la integración de Atlas con un proveedor de KMS no proporciona una transferencia automática por error del mecanismo de conexión o acceso al KMS entre regiones.
If the configured KMS proveedor becomes unavailable, Atlas performs periodic validación of your KMS configuration. Si las credenciales de tu proveedor de KMS se vuelven inválidas o si la llave de cifrado se borra o deshabilita, Atlas apaga el mongod y mongos procesos en la siguiente comprobación de validación programada y le notifica por correo electrónico, reflejando el estado en la interfaz de usuario de Atlas.
Cuando Atlas no puede conectarse a tu proveedor de gestión de claves, no detiene tus procesos. Por lo tanto, si el acceso al KMS se ve interrumpido debido a un problema regional, el clúster podría continuar en funcionamiento hasta que lo reinicie manualmente o hasta que la validación falle de manera más crítica.
Por eso, si el KMS deja de funcionar, puedes cambiar la configuración. Para recuperar el acceso a la llave de cifrado en un escenario de interrupción del servicio de multiregión, debes cambiar manualmente la configuración en Atlas para que apunte a una instancia o configuración de KMS diferente y accesible.
Si utilizas nodos privados para conectarte a KMS, debes establecer un nodo privado desde cada región donde se implementen nodos de Atlas de regreso al KMS primario. Esto es para garantizar que la configuración siga siendo válida durante los controles periódicos, así como durante las configuraciones iniciales o rotaciones de llaves, para lo cual cada nodo necesita acceder a la llave maestra de cliente almacenada en el KMS principal.
En resumen, la integración de Atlas con los proveedores BYOK para el cifrado en reposo no proporciona soporte para la conmutación por error multiregión de forma automática, por lo que deberás cambiar la configuración manualmente.
Todas las recomendaciones paradigmáticas de implementación
Las siguientes recomendaciones aplican a todos paradigmas de implementación.
Cifrado con gestión de claves de cliente
Puedes habilitar cifrado con gestión de claves del cliente a nivel de proyecto. Una vez habilitada, la configuración se aplica automáticamente a todos los clústeres creados dentro del proyecto, garantizando una protección de datos coherente en todo tu entorno. Recomendamos que utilice un servicio de gestión de claves (KMS) como AWS KMS, Google Cloud KMS o Azure Key Vault.
Para entornos de staging y producción, recomendamos habilitar el cifrado con la administración de claves del cliente cuando aprovisiones los clusters para evitar depender de los equipos de desarrollo de aplicaciones para configurarlo más adelante.
Para entornos de desarrollo y pruebas, considera omitir el cifrado con la gestión de claves de cliente para ahorrar costos. Sin embargo, si almacena datos sensibles en Atlas, como en los sectores de salud o servicios financieros, considere habilitar el cifrado con gestión de llaves de cliente también en entornos de desarrollo y pruebas.
Utiliza los siguientes métodos para habilitar el cifrado con gestión de claves por parte del cliente:
Para aprender a configurar el cifrado con la administración de claves del cliente al aprovisionar una nueva organización, Proyecto y clúster de Atlas, consulte Ejemplos de automatización: organizaciones, Proyectos y clústeres de Atlas.
Clasificación de datos
Durante el proceso de provisionamineto, también recomendamos evaluar la sensibilidad de ciertos campos en sus datos y clasificarlos para determinar qué datos requieren cifrado y qué restricciones globales aplicar a estos grupos. Como pauta general, recomendamos aplicar la Queryable Encryption a todos los campos confidenciales, además de seguir las mejores prácticas de modelado de datos.
Considera los siguientes niveles de clasificación de datos como punto de partida:
Datos públicos: Datos que, en caso de divulgación, alteración o destrucción no autorizada, representan poco o ningún riesgo para la empresa. Aunque la confidencialidad sea menos preocupante, aún así debes aplicar controles de autorización para evitar la modificación o destrucción no autorizada de datos públicos.
Ejemplos: productos, folletos, información de entrenamiento
Datos privados: Datos que representan un riesgo moderado para la empresa en caso de divulgación no autorizada, alteración o destrucción de los datos. Por defecto, todos los datos institucionales que no estén explícitamente clasificados como datos restringidos o públicos deben considerarse datos privados. Aplica CSFLE o Queryable Encryption en cualquier campo que contenga datos privados, como PII.
Ejemplos: información del cliente, contratos, costos de productos
Datos Restringidos: Datos que representan un riesgo significativo para la empresa si ocurre una divulgación, alteración o destrucción no autorizada de los datos. Aplica el nivel más alto de controles de seguridad a los datos restringidos, incluidos CSFLE o Queryable Encryption en todos los campos y cifrado con gestión de claves por parte del cliente para seguridad adicional.
Ejemplos: Información sobre ganancias, Nómina, Riesgos de seguridad
Ejemplos de automatización: cifrado de datos de Atlas
Tip
Para ejemplos de Terraform que aplican nuestras recomendaciones en todos los pilares, consulta uno de los siguientes ejemplos en GitHub:
Los siguientes ejemplos configuran el cifrado con la gestión de claves del cliente utilizando las herramientas de automatizaciónde Atlas.
Antes de configurar el cifrado con la gestión de claves del cliente, debes crear tus organizaciones, proyectos y clústeres. Para obtener más información, consulta Ejemplos de Automatización: Atlas Orgs, Proyectos y Clústeres.
Configurar el cifrado con gestión de claves del cliente
Para tus entornos de desarrollo y pruebas, considera omitir el cifrado con la gestión de claves del cliente para ahorrar costos, a menos que te encuentres en una industria altamente regulada o almacenes información sensible. Para obtener más información, consulte Recomendaciones para Atlas Orgs, Proyectos y clústeres.
Para habilitar el cifrado con gestión de claves de cliente mediante Terraform, utilice el siguiente módulo. Modifique los ID y nombres para usar sus propios valores:
Tip
Para obtener ejemplos adicionales y opciones de configuración, consulte la documentación del módulo atlas-aws.
module "atlas_aws" { source = "terraform-mongodbatlas-modules/atlas-aws/mongodbatlas" version = "~> 0.3" project_id = var.atlas_project_id encryption = { enabled = true create_kms_key = { enabled = true alias = "alias/atlas-encryption" enable_key_rotation = true } } }
Tip
Para obtener ejemplos adicionales y opciones de configuración, consulte la documentación del módulo atlas-azure.
module "atlas_azure" { source = "terraform-mongodbatlas-modules/atlas-azure/mongodbatlas" version = "~> 0.3" project_id = var.atlas_project_id atlas_azure_app_id = var.atlas_azure_app_id service_principal_id = var.service_principal_id create_service_principal = false encryption = { enabled = true key_vault_id = var.azure_key_vault_id key_identifier = var.azure_key_identifier } }
resource "mongodbatlas_encryption_at_rest" "test" { project_id = var.atlas_project_id google_cloud_kms_config { enabled = true service_account_key = "{\"type\": \"service_account\",\"project_id\": \"my-project-common-0\",\"private_key_id\": \"e120598ea4f88249469fcdd75a9a785c1bb3\",\"private_key\": \"-----BEGIN PRIVATE KEY-----\\nMIIEuwIBA(truncated)SfecnS0mT94D9\\n-----END PRIVATE KEY-----\\n\",\"client_email\": \"my-email-kms-0@my-project-common-0.iam.gserviceaccount.com\",\"client_id\": \"10180967717292066\",\"auth_uri\": \"https://accounts.google.com/o/oauth2/auth\",\"token_uri\": \"https://accounts.google.com/o/oauth2/token\",\"auth_provider_x509_cert_url\": \"https://www.googleapis.com/oauth2/v1/certs\",\"client_x509_cert_url\": \"https://www.googleapis.com/robot/v1/metadata/x509/my-email-kms-0%40my-project-common-0.iam.gserviceaccount.com\"}" key_version_resource_id = "projects/my-project-common-0/locations/us-east4/keyRings/my-key-ring-0/cryptoKeys/my-key-0/cryptoKeyVersions/1" } }
Para más opciones de configuración e información sobre este ejemplo, consulta la documentación de Terraform.
Para sus entornos de pruebas y producción, recomendamos habilitar el cifrado con la gestión de claves del cliente al aprovisionar sus clústeres. Para obtener más información, consulte Recomendaciones para Atlas Orgs, Proyectos y clústeres.
Para habilitar el cifrado con gestión de claves de cliente mediante Terraform, utilice el siguiente módulo. Modifique los ID y nombres para usar sus propios valores:
Tip
Para obtener ejemplos adicionales y opciones de configuración, consulte la documentación del módulo atlas-aws.
module "atlas_aws" { source = "terraform-mongodbatlas-modules/atlas-aws/mongodbatlas" version = "~> 0.3" project_id = var.atlas_project_id encryption = { enabled = true create_kms_key = { enabled = true alias = "alias/atlas-encryption" enable_key_rotation = true } } }
Tip
Para obtener ejemplos adicionales y opciones de configuración, consulte la documentación del módulo atlas-azure.
module "atlas_azure" { source = "terraform-mongodbatlas-modules/atlas-azure/mongodbatlas" version = "~> 0.3" project_id = var.atlas_project_id atlas_azure_app_id = var.atlas_azure_app_id service_principal_id = var.service_principal_id create_service_principal = false encryption = { enabled = true key_vault_id = var.azure_key_vault_id key_identifier = var.azure_key_identifier } }
resource "mongodbatlas_encryption_at_rest" "test" { project_id = var.atlas_project_id google_cloud_kms_config { enabled = true service_account_key = "{\"type\": \"service_account\",\"project_id\": \"my-project-common-0\",\"private_key_id\": \"e120598ea4f88249469fcdd75a9a785c1bb3\",\"private_key\": \"-----BEGIN PRIVATE KEY-----\\nMIIEuwIBA(truncated)SfecnS0mT94D9\\n-----END PRIVATE KEY-----\\n\",\"client_email\": \"my-email-kms-0@my-project-common-0.iam.gserviceaccount.com\",\"client_id\": \"10180967717292066\",\"auth_uri\": \"https://accounts.google.com/o/oauth2/auth\",\"token_uri\": \"https://accounts.google.com/o/oauth2/token\",\"auth_provider_x509_cert_url\": \"https://www.googleapis.com/oauth2/v1/certs\",\"client_x509_cert_url\": \"https://www.googleapis.com/robot/v1/metadata/x509/my-email-kms-0%40my-project-common-0.iam.gserviceaccount.com\"}" key_version_resource_id = "projects/my-project-common-0/locations/us-east4/keyRings/my-key-ring-0/cryptoKeys/my-key-0/cryptoKeyVersions/1" } }
Para más opciones de configuración e información sobre este ejemplo, consulta la documentación de Terraform.