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.
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.
Puede seleccionar la versión de TLS que desea usar en Atlas. La configuración predeterminada recomendada es TLS 1.2 y una longitud de clave mínima de 128 bits. OpenSSL admite todo el cifrado en tránsito. 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 de los clientes se cifran automáticamente en reposo mediante AES-256. Este proceso utiliza el cifrado de disco de su proveedor de nube, quien administra las claves de cifrado. Este proceso no se puede deshabilitar.
Por defecto, el cifrado en reposo es cifrado a nivel de volumen.
Además, puede habilitar el cifrado a nivel de base de datos trayendo su propia clave (BYOK). Esta es la clave administrada por el cliente (CMK) que se agrega con un servicio de administración de claves (KMS), como AWS KMS, Google Cloud KMS o Azure Key Vault. La función BYOK proporciona cifrado a nivel de archivo y es equivalente al Cifrado de Datos Transparente (TDE), cumpliendo con los requisitos empresariales de TDE. El cifrado con la administración de claves del cliente añade una capa adicional de seguridad para mayor confidencialidad y segmentación de datos.
Para aprender más, Cifrado en reposo mediante la gestión de claves 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.
Cifrado a nivel de campo del lado del cliente
El cifrado a nivel de campo del lado del cliente (CSFLE) es una función de cifrado en uso que permite a una aplicación cliente cifrar datos confidenciales antes de almacenarlos en la base de datos MongoDB. Los datos confidenciales se cifran de forma transparente, permanecen cifrados durante todo su ciclo de vida y solo se descifran en el lado del cliente.
Puede cifrar selectivamente campos individuales dentro de un documento, varios campos dentro del documento o el documento completo. Opcionalmente, puede proteger cada campo con su propia clave y descifrarlos sin problemas en el cliente mediante un controlador MongoDB. CSFLE utiliza AES-256 en modo CBC autenticado para cifrar los 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 admite todos los principales servicios de gestión de claves locales y en la nube.
Queryable Encryption
El cifrado consultable ayuda a las organizaciones a proteger los datos confidenciales cuando se consultan. Al igual que CSFLE, permite que las aplicaciones cifren los datos en el 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 un algoritmo de búsqueda cifrado. El cifrado consultable garantiza la protección de la información confidencial sin sacrificar la capacidad de realizar consultas. El cifrado consultable siempre utiliza cifrado no determinista.
Para aprender sobre los algoritmos utilizados en Queryable Encryption, consulte informe técnico de Queryable Encryption.
El siguiente diagrama muestra un flujo de trabajo de cifrado consultable 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 almacenarse en la base de datos. Cuando la aplicación envía una consulta de rango expresivo en el campo, el controlador de MongoDB utiliza la clave para cifrar la consulta y envía un token criptográfico al servidor MongoDB. El servidor utiliza el algoritmo de búsqueda cifrada para procesar la consulta sin conocer los datos reales. Finalmente, el controlador utiliza la clave para descifrar los resultados de la consulta y los devuelve al cliente autenticado como texto sin formato legible.
Recomendaciones para el cifrado de datos de Atlas
Las implementaciones de una sola región no tienen consideraciones específicas para el cifrado de datos. Consulte la siguiente sección para ver "Recomendaciones sobre todos los paradigmas de implementación".
En implementaciones multi-nube y multi-región, puede habilitar el cifrado a nivel de base de datos incorporando su propia clave administrada por el cliente (BYOK).
Algunos proveedores de KMS admiten capacidades de multiregión. Por ejemplo:
GCP KMS admite la implementación en múltiples regiones 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.
Si el proveedor de KMS configurado deja de estar disponible, Atlas realiza una validación periódica de su configuración de KMS. Si las credenciales de su proveedor de KMS dejan de ser válidas o si la clave de cifrado se elimina o se deshabilita, Atlas cierra 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 su proveedor de administración de claves, no detiene sus procesos. Por lo tanto, si el acceso al KMS se interrumpe debido a un problema regional, el clúster podría seguir ejecutándose hasta que lo reinicie manualmente o hasta que la validación presente un error más grave.
Por ello, si el KMS falla, puede cambiar la configuración. Para recuperar el acceso a la clave de cifrado en una interrupción multirregional, debe 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 del 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.
Utilice los siguientes métodos para habilitar el cifrado con la administración de claves 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, alteración o destrucción no autorizada. Por defecto, todos los datos institucionales que no estén clasificados explícitamente como restringidos o públicos deben tratarse como datos privados. Aplique CSFLE o cifrado consultable en cualquier campo que contenga datos privados, como información de identificación personal (PII).
Ejemplos: Información del cliente, contratos, costos del producto
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 la gestión de claves de cliente con Terraform, cree los siguientes recursos. Cambie los ID y los nombres para usar sus valores:
Tip
Para un ejemplo completo de configuración, consulte Ejemplo de proveedor de Atlas Terraform.
Alternativamente, para simplificar el proceso de configuración, puedes usar el módulo de Terraform para cifrado en reposo.
resource "mongodbatlas_cloud_provider_access_setup" "setup_only" { project_id = var.atlas_project_id provider_name = "AWS" } resource "mongodbatlas_cloud_provider_access_authorization" "auth_role" { project_id = var.atlas_project_id role_id = mongodbatlas_cloud_provider_access_setup.setup_only.role_id aws { iam_assumed_role_arn = aws_iam_role.test_role.arn } } resource "mongodbatlas_encryption_at_rest" "test" { project_id = var.atlas_project_id aws_kms_config { enabled = true customer_master_key_id = aws_kms_key.kms_key.id region = var.atlas_region role_id = mongodbatlas_cloud_provider_access_authorization.auth_role.role_id } } data "mongodbatlas_encryption_at_rest" "test" { project_id = mongodbatlas_encryption_at_rest.test.project_id } output "is_aws_kms_encryption_at_rest_valid" { value = data.mongodbatlas_encryption_at_rest.test.aws_kms_config.valid }
Tip
Para un ejemplo completo de configuración, consulte Ejemplo de proveedor de Atlas Terraform.
resource "mongodbatlas_encryption_at_rest" "test" { project_id = var.atlas_project_id azure_key_vault_config { enabled = true azure_environment = "AZURE" tenant_id = var.azure_tenant_id subscription_id = var.azure_subscription_id client_id = var.azure_client_id secret = var.azure_client_secret resource_group_name = var.azure_resource_group_name key_vault_name = var.azure_key_vault_name key_identifier = var.azure_key_identifier } } data "mongodbatlas_encryption_at_rest" "test" { project_id = mongodbatlas_encryption_at_rest.test.project_id } output "is_azure_encryption_at_rest_valid" { value = data.mongodbatlas_encryption_at_rest.test.azure_key_vault_config.valid }
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 obtener más opciones de configuración e información sobre este ejemplo, consulte 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 la gestión de claves de cliente con Terraform, cree los siguientes recursos. Cambie los ID y los nombres para usar sus valores:
Tip
Para un ejemplo completo de configuración, consulte Ejemplo de proveedor de Atlas Terraform.
Alternativamente, para simplificar el proceso de configuración, puedes usar el módulo de Terraform para cifrado en reposo.
resource "mongodbatlas_cloud_provider_access_setup" "setup_only" { project_id = var.atlas_project_id provider_name = "AWS" } resource "mongodbatlas_cloud_provider_access_authorization" "auth_role" { project_id = var.atlas_project_id role_id = mongodbatlas_cloud_provider_access_setup.setup_only.role_id aws { iam_assumed_role_arn = aws_iam_role.test_role.arn } } resource "mongodbatlas_encryption_at_rest" "test" { project_id = var.atlas_project_id aws_kms_config { enabled = true customer_master_key_id = aws_kms_key.kms_key.id region = var.atlas_region role_id = mongodbatlas_cloud_provider_access_authorization.auth_role.role_id } } data "mongodbatlas_encryption_at_rest" "test" { project_id = mongodbatlas_encryption_at_rest.test.project_id } output "is_aws_kms_encryption_at_rest_valid" { value = data.mongodbatlas_encryption_at_rest.test.aws_kms_config.valid }
Tip
Para un ejemplo completo de configuración, consulte Ejemplo de proveedor de Atlas Terraform.
resource "mongodbatlas_encryption_at_rest" "test" { project_id = var.atlas_project_id azure_key_vault_config { enabled = true azure_environment = "AZURE" tenant_id = var.azure_tenant_id subscription_id = var.azure_subscription_id client_id = var.azure_client_id secret = var.azure_client_secret resource_group_name = var.azure_resource_group_name key_vault_name = var.azure_key_vault_name key_identifier = var.azure_key_identifier } } data "mongodbatlas_encryption_at_rest" "test" { project_id = mongodbatlas_encryption_at_rest.test.project_id } output "is_azure_encryption_at_rest_valid" { value = data.mongodbatlas_encryption_at_rest.test.azure_key_vault_config.valid }
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 obtener más opciones de configuración e información sobre este ejemplo, consulte la documentación de Terraform.