Atlas ofrece varias funciones de cifrado para proteger los datos mientras están en tránsito, en reposo y en uso para salvaguardar los datos durante todo su ciclo de vida.
Características del cifrado de datos de Atlas
Cifrado en tránsito
El cifrado en tránsito protege los datos durante la transmisión entre clientes y servidores, garantizando que no se puedan inspeccionar mientras están en movimiento. En Atlas, todo el tráfico de red hacia los clústeres está protegido por Seguridad de la Capa de Transporte (TLS), que está habilitada por defecto y no se puede deshabilitar. Los datos transmitidos hacia y entre nodos se cifran 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. Módulo de objetos FIPS.
Cifrado en reposo
El cifrado en reposo garantiza que todos los datos del 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.
De forma predeterminada, el cifrado en reposo es un 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 obtener más información, consulte Cifrado en reposo mediante gestión de claves del cliente.
Cifrado en uso
El cifrado en uso protege los datos durante su procesamiento. MongoDB cuenta con dos funciones de cifrado en uso para satisfacer sus necesidades de protección de datos: cifrado a nivel de campo del lado del cliente y cifrado consultable.
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, puede seleccionar un cifrado aleatorio, que no se puede consultar, pero podría ser necesario para ciertos requisitos 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 obtener más información sobre los algoritmos utilizados en el cifrado consultable, consulte el documento técnico sobre cifrado consultable.
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 funciones multirregionales. Por ejemplo:
GCP KMS admite la implementación en múltiples regiones y la replicación automática de claves.
En AWS KMS, debe configurar explícitamente las claves para que sean multirregionales y replicarlas en cada región en la que esté implementado Atlas. Para obtener más información, consulte Crear claves de réplica multirregionales 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 procesa la próxima verificació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 utiliza puntos de conexión privados para conectarse al KMS, debe establecer un punto de conexión privado desde cada región donde se implementan los nodos de Atlas hasta el KMS principal. Esto garantiza que la configuración siga siendo válida durante las comprobaciones periódicas y durante las configuraciones iniciales o rotaciones de claves que cada nodo necesita para acceder a la clave maestra del cliente almacenada en el KMS principal.
En resumen, la integración de Atlas con los proveedores BYOK para cifrado en reposo no admite la conmutación por error entre regiones de manera automática y es necesario cambiar la configuración manualmente.
Todas las recomendaciones del paradigma de implementación
Las siguientes recomendaciones se aplican a todos paradigmas de implementación.
Cifrado con gestión de claves del cliente
Habilite el cifrado con la administración de claves de cliente a nivel de proyecto. Tras habilitarlo, la configuración se aplica automáticamente a todos los clústeres creados en el proyecto, lo que garantiza una protección de datos uniforme en todo el entorno. Le recomendamos usar un servicio de administración de claves (KMS) como AWS KMS, Google Cloud KMS o Azure Key Vault.
Para entornos de prueba y producción, recomendamos que habilite el cifrado con administración de claves del cliente cuando aprovisione sus clústeres para evitar depender de los equipos de desarrollo de aplicaciones para configurarlo más adelante.
Para entornos de desarrollo y pruebas, considere omitir el cifrado con la gestión de claves de cliente para ahorrar costos. Sin embargo, si almacena datos confidenciales en Atlas, como en el sector sanitario o de servicios financieros, considere habilitar también el cifrado con la gestión de claves de cliente 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 administración de claves de 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 aprovisionamiento, también recomendamos evaluar la confidencialidad de ciertos campos de sus datos y clasificarlos para determinar qué datos requieren cifrado y qué restricciones globales aplicar a estos grupos. Como regla general, recomendamos aplicar el cifrado consultable a todos los campos confidenciales, además de seguir las prácticas recomendadas de modelado de datos.
Considere 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 formación
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 se divulgan, alteran o destruyen sin autorización. Aplique los controles de seguridad más exigentes a los datos restringidos, incluyendo CSFLE o cifrado consultable en todos los campos y cifrado con gestión de claves del cliente para mayor seguridad.
Ejemplos: Información de ingresos, nóminas, riesgos de seguridad
Ejemplos de automatización: Cifrado de datos Atlas
Tip
Para ver ejemplos de Terraform que aplican nuestras recomendaciones en todos los pilares, consulte uno de los siguientes ejemplos en GitHub:
Los siguientes ejemplos configuran el cifrado con la administración de claves de cliente utilizando herramientas Atlas para la automatización.
Antes de configurar el cifrado con la administración de claves de cliente, debe crear sus organizaciones, proyectos y clústeres. Para obtener más información, consulte Ejemplos de automatización: Organizaciones, proyectos y clústeres de Atlas.
Configurar el cifrado con la gestión de claves del cliente
Para sus entornos de desarrollo y pruebas, considere omitir el cifrado con la gestión de claves de cliente para ahorrar costos, a menos que trabaje en un sector altamente regulado o almacene datos confidenciales. Para obtener más información, consulte Recomendaciones para organizaciones, proyectos y clústeres de Atlas.
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 obtener un ejemplo de configuración completo, consulte Ejemplo de proveedor Atlas Terraform.
Alternativamente, para simplificar el proceso de configuración, puede utilizar el módulo de cifrado en reposo de Terraform.
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 obtener un ejemplo de configuración completo, consulte Ejemplo de proveedor 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 prueba y producción, le recomendamos habilitar el cifrado con administración de claves de cliente al aprovisionar sus clústeres. Para obtener más información, consulte Recomendaciones para organizaciones, proyectos y clústeres de Atlas.
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 obtener un ejemplo de configuración completo, consulte Ejemplo de proveedor Atlas Terraform.
Alternativamente, para simplificar el proceso de configuración, puede utilizar el módulo de cifrado en reposo de Terraform.
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 obtener un ejemplo de configuración completo, consulte Ejemplo de proveedor 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.