Nota
Esta página se aplica tanto a Atlas Infinite como a Atlas Core.
Puede añadir una capa adicional de seguridad a sus datos habilitando el cifrado en reposo a nivel de base de datos con claves gestionadas por el cliente. Usted es el propietario y controla las claves de cifrado, que se almacenan en el sistema de gestión de claves (KMS) de su proveedor de nube. Para obtener más información sobre cómo Atlas cifra sus datos en reposo y en qué se diferencian los tipos de clave disponibles, consulte la descripción general del cifrado en reposo de Atlas.
La configuración del cifrado en reposo utilizando la gestión de claves de cifrado en reposo implica gastos extra para el proyecto de Atlas. Para obtener más información, consulte Seguridad avanzada.
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 el Modelo de Responsabilidad Compartida.
Para aplicar que las claves gestionadas por el cliente para el cifrado en reposo estén habilitadas en todos los clústeres y las implementaciones de búsqueda dedicadas de un proyecto, utilice las políticas de recursos de Atlas. Puede utilizar las políticas de recursos para requerir llave maestra de cliente antes de crear o cambiar clústeres o implementaciones de búsqueda.
Importante
Característica no disponible en los clústeres Flex
Los clústeres Flex no admiten esta característica en este momento. Para obtener más información, se debe consultar Limitaciones de Atlas Flex.
Puede utilizar uno o más de los siguientes proveedores de gestión de claves de clientes al configurar el cifrado en reposo para el proyecto Atlas:
Nota
Se aplican algunas limitaciones a la gestión de claves de cliente en la versión preliminar pública de Atlas Infinite. Para consultar la lista completa, vea las limitaciones de la versión preliminar pública.
En la versión preliminar pública, Atlas solo admite claves administradas por el cliente en Atlas Infinite a través de AWS KMS. No se admiten Azure Key Vault ni Google Cloud KMS. Cuando un clúster de Atlas Infinite utiliza claves administradas por el cliente, se restaura una instantánea dentro del proyecto que la creó; no se admiten restauraciones entre proyectos ni entre organizaciones.
Tras configurar al menos un proveedor de gestión de claves para el proyecto Atlas, puede habilitar la gestión de claves de cliente para cada clúster de Atlas que requiera cifrado. El proveedor de gestión de claves no tiene por qué coincidir con el proveedor de servicios en la nube del clúster.
En un clúster de Atlas Infinite, puede migrar entre el cifrado predeterminado y una clave administrada por el cliente en cualquier dirección. Atlas Infinite trata la migración como una rotación de claves: su clúster permanece disponible y la clave anterior sigue siendo válida hasta que finalice la migración. Para obtener más información, consulte Atlas Infinite Encryption.
Nota
Cuando se activa o desactiva la gestión de claves de cliente, Atlas realiza una sincronización inicial para volver a cifrar los datos del clúster. También vuelve a crear los índices de MongoDB Search y MongoDB Vector Search en el clúster.
Como alternativa, para proyectos con M10 o clústeres de Atlas más grandes implementados solo en regiones de Azure, puede usar la API de administración de Atlas para crear automáticamente un enlace privado de Azure en su AKV que permita a Atlas comunicarse de forma segura con su AKV a través de las interfaces de red privada de Azure. Para obtener más información, consulte Administrar claves de cliente con Azure Key Vault.
Si su proveedor de KMS deja de estar disponible, esto no desactiva el clúster mientras siga en funcionamiento. Si decide reiniciar dicho clúster, Atlas lo desactiva si su clave es revocada.
Para aprender sobre las recomendaciones para el cifrado, incluidos los niveles de clasificación de datos y los tipos de cifrado a utilizar, consulta Recomendaciones para el cifrado de datos de Atlas en el Atlas Architecture Center.
Nota
Para clústeres con cifrado en reposo mediante claves gestionadas por el cliente, la validación de datos de Atlas requiere acceso adicional a su KMS para descifrar los datos. Para obtener más información, consulte Uso de KMS para la validación de datos.
Acceso requerido
Para configurar la gestión de claves de cliente, debes tener acceso de Project Owner al proyecto.
Los usuarios con acceso Organization Owner deben añadirse al proyecto como Project Owner.
Configurar Atlas con la gestión de claves del cliente
El cifrado en reposo mediante la gestión de llaves requiere credenciales válidas del proveedor de gestión de llaves y una llave de cifrado. Para proporcionar estos detalles y activar la gestión de llaves de cliente:
En Atlas, ve a la página Advanced de tu proyecto.
Si aún no aparece, se debe seleccionar la organización que contiene el proyecto en el menú Organizations de la barra de navegación.
Si aún no se muestra, seleccione su proyecto en el menú Projects de la barra de navegación.
En la barra lateral, haz clic en Database & Network Access en la sección Security.
En la barra lateral, haga clic en Advanced.
La página Avanzada se muestra.
(Opcional) Cambia el botón junto a Search Node Data Encryption a On.
Opcionalmente, puede habilitar el cifrado para todos los datos en los nodos de búsqueda. También puedes activar esta funcionalidad más adelante.
Para obtener más información, consulta Permitir la gestión de claves de cliente para los nodos de búsqueda.
(Opcional) Permite el acceso hacia o desde el panel de control de Atlas.
Para aprender más, consulta Permitir el acceso desde el plano de control de Atlas.
Permite el acceso desde el plano de control de Atlas
Dependiendo de la configuración de su KMS, es posible que deba agregar las siguientes direcciones IP a su lista de acceso KMS para que Atlas pueda comunicarse con su KMS:
Direcciones IP de salida del plano de control de Atlas
direcciones IP públicas de los nodos del clúster Atlas (plano de datos)
Para permitir la comunicación entre Atlas y KMS:
Envía una solicitud GET al punto de conexión returnAllControlPlaneIpAddresses.
El endpoint de la API devuelve una lista de direcciones IP del plano de control de Atlas entrantes y salientes en CIDR, categorizadas por proveedor de nube y región. Para aprender más, consulta los requisitos previos para gestionar claves de clientes con AWS, Azure y GCP.
Activar la gestión de claves de cliente para un clúster de Atlas
Después de configurar Atlas con la gestión de claves de cliente, debes permitir la gestión de claves de cliente para cada clúster de Atlas que tenga datos que desees cifrar.
Nota
Debes tener el rol de Project Owner para permitir la gestión de claves de cliente para el clúster en ese proyecto.
Para nuevos clústeres:
Opcional: añade direcciones IP de los nuevos nodos del clúster.
En función de la configuración de la gestión de claves, es posible que haya que añadir las direcciones IP de nodo del clúster de Atlas a la lista de acceso del KMS del proveedor de nube, para que el clúster pueda comunicarse con el KMS. Para permitir la comunicación entre el clúster y KMS:
Envía una solicitud GET al punto de conexión
ipAddresses. El punto de conexión de la API returnAllIpAddresses devuelve una lista de direcciones IP de los nuevos nodos del clúster, similar a la siguiente:{ "groupId": "xxx", // ObjectId "services": { "clusters": [ { "clusterName": "Cluster0", "inbound": [ "3.92.113.229", "3.208.110.31", "107.22.44.69" ], "outbound": [ "3.92.113.229", "3.208.110.31", "107.22.44.69" ] } ] } } Se deben añadir las direcciones IP devueltas a la lista de acceso IP del proveedor de nube. Se debe modificar la lista de acceso IP antes de que el plan de provisionamineto se revierta. El clúster intenta realizar el provisionamineto durante un máximo de tres días antes de que el plan de provisionamineto se revierta debido a las restricciones de acceso IP.
Consulta los requisitos previos para gestionar las claves de cliente con AWS, Azure y GCP para obtener más información.
Nota
Si necesita más tiempo para actualizar la lista de acceso IP, puede:
Aprovisiona el clúster sin cifrado en reposo y luego actívalo después de actualizar la lista de acceso IP.
Se debe configurar una lista de acceso IP más inclusiva en el Key Management Service del proveedor de nube, abrir el clúster con cifrado en reposo y luego modificar la lista de acceso IP.
Para los clústeres existentes:
En Atlas, ve a la página Clusters de tu proyecto.
Si aún no se muestra, seleccione la organización que contiene su proyecto deseado en el menú Organizations de la barra de navegación.
Si aún no aparece, selecciona el proyecto deseado en el menú Projects de la barra de navegación.
En la barra lateral, haz clic en Clusters en la sección Database.
La página de clústeres se muestra.
Active el cifrado del clúster.
Expande el panel Additional Settings.
Se debe cambiar el ajuste de Manage your own encryption keys a Yes.
Se debe verificar el estado de la configuración de Require Private Networking para el clúster.
Si configuró el cifrado en reposo mediante CMK (a través de redes privadas) para Atlas a nivel de proyecto, el estado es Active. Si no ha configurado ninguna conexión de punto final privado para su proyecto, el estado es Inactive.
Activar la gestión de claves de cliente para los nodos de búsqueda
Al configurar la gestión de claves del cliente para el proyecto, también se puede activar el cifrado con la gestión de claves del cliente para los nodos de búsqueda. Esto garantiza que las cargas de trabajo de MongoDB Search y MongoDB Búsqueda Vectorial, incluyendo índices, estén completamente cifrados con las claves gestionadas por el cliente.
Esta función está disponible en todos los proveedores de servicios de gestión del conocimiento (KMS).
Para activar el cifrado de datos de nodos de búsqueda con claves gestionadas por el cliente:
En Atlas, ve a la página Advanced de tu proyecto.
Si aún no aparece, se debe seleccionar la organización que contiene el proyecto en el menú Organizations de la barra de navegación.
Si aún no se muestra, seleccione su proyecto en el menú Projects de la barra de navegación.
En la barra lateral, haz clic en Database & Network Access en la sección Security.
En la barra lateral, haga clic en Advanced.
La página Avanzada se muestra.
Se debe activar el cifrado en reposo con la gestión de claves de cliente o editar la configuración.
Si aún no ha configurado la Gestión de Claves del Cliente, siga los pasos en Configurar Atlas con Gestión de Claves del Cliente.
De lo contrario, haz clic en el botón Edit junto a Encryption at Rest using your Key Management.
Haga clic en Save.
Después de activar el cifrado de datos de nodos de búsqueda a nivel de proyecto, Atlas lo activa a nivel de clúster cuando configuras el cifrado de clúster para cualquier clúster nuevo o existente con nodos de búsqueda. Atlas cifra los nodos de búsqueda utilizando la clave gestionada por el cliente y reconstruye todos los índices de búsqueda. La duración de este proceso depende del tamaño y número de tus índices.
Nota
Si se desactiva la gestión de claves de cliente a nivel de proyecto o si la clave gestionada por el cliente queda no válida, Atlas se debe pausar el clúster y eliminar los nodos de búsqueda, haciendo que los queries de la base de datos no estén disponibles.
Cuando vuelve a habilitar la gestión de claves de clientes o soluciona la configuración de su clave, Atlas reanuda su clúster, proporciona nuevos nodos de búsqueda y realiza una sincronización inicial. La funcionalidad de búsqueda se reanuda cuando se completa la sincronización inicial.
Añade nodos a un clúster de Atlas cifrado
Se deben agregar nodos o particiones al set de réplicas o clúster particionado.
Puedes agregar nodos elegibles a clústeres M10+ o aumentar el número de particiones en el clúster particionado.
Opcional: añade direcciones IP de los nuevos nodos del clúster o particiones.
En función de la configuración de la gestión de claves, es posible que haya que añadir las direcciones IP de nodo del clúster de Atlas a la lista de acceso del KMS del proveedor de nube, para que el clúster pueda comunicarse con el KMS. Para permitir la comunicación entre el clúster y KMS:
Envíe una solicitud GET al punto de conexión
ipAddresses. El endpoint de la API returnAllIpAddresses devuelve una lista de direcciones IP de los nuevos nodos o fragmentos del clúster, similar a la siguiente:{ "groupId": "xxx", // ObjectId "services": { "clusters": [ { "clusterName": "Cluster0", "inbound": [ "3.92.113.229", "3.208.110.31", "107.22.44.69" ], // List<String> "outbound": [ "3.92.113.229", "3.208.110.31", "107.22.44.69" ] } ] } } Se deben añadir las direcciones IP devueltas a la lista de acceso IP del proveedor de nube. Se debe modificar la lista de acceso IP antes de que el plan de provisionamineto se revierta. El clúster intenta realizar el provisionamineto durante un máximo de tres días antes de que el plan de provisionamineto se revierta debido a las restricciones de acceso IP.
Consulta los requisitos previos para gestionar las claves de cliente con AWS, Azure y GCP para obtener más información.
Valide la configuración de su KMS
Atlas valida la configuración de KMS:
Cuando añades o actualizas credenciales.
Cada 15 minutos.
On-demand con el endpoint de la API de cifrado en reposo.
Atlas cierra todos los procesos de mongod y mongos en la siguiente comprobación de validez programada si se da una de las siguientes condiciones:
las credenciales del proveedor de gestión de claves pierden validez
alguien borra o desactiva la llave de cifrado
Si Atlas no puede conectarse con su proveedor de gestión de claves, o si Atlas detecta una posible falsa alarma, Atlas no detendrá sus procesos. La Encryption at Rest KMS network access denied alerta está habilitada por defecto para todos los proyectos nuevos para comunicar cualquier fallo de acceso a la red KMS. Puedes configurar tus ajustes de alerta.
Si Atlas cierra tus clústeres, ocurren los siguientes eventos:
Atlas envía un correo electrónico al
Project Ownercon una lista de los clústeres afectados.La página Clusters refleja que Atlas deshabilitó sus clústeres debido a una configuración de cifrado en reposo no válida.
No se puede leer ni guardar datos en el clúster desactivado. Se pueden enviar actualizaciones a clústeres desactivados, como cambios en el tamaño del disco e instancia. Atlas procesa estos cambios cuando alguien restaura la llave de cifrado. Atlas continúa realizando mantenimiento y aplicando parches de seguridad. Los clústeres desactivados retienen todos los datos, por lo que la facturación continúa.
Nota
Potencia de la máquina virtual
Mientras un clúster está deshabilitado, Atlas no detiene la máquina virtual (VM) en la que se está ejecutando el clúster. Atlas puede realizar parches que reinician el servidor, pero la energía de la VM no se reinicia.
Para recuperar el acceso a sus datos:
Actualiza tus credenciales si han cambiado desde que configuraste Atlas con la gestión de claves de cliente.
Se debe restaurar la clave si ha sido deshabilitada o borrada.
Después de actualizar la configuración, se debe hacer clic en Try Again para validarla. Si no se haces, Atlas valida en su siguiente verificación programada. Todos los procesos mongod y mongos se reinician después de que Atlas determina que la configuración es válida.
Advertencia
Si se borró la clave, restaure esa clave para recuperar el acceso a los clústeres. No se puede cambiar una clave ni desactivar el cifrado en reposo mediante la gestión de claves del cliente sin una clave válida.
Restaurar una clave eliminada
Para restaurar una clave borrada, se debe consultar la documentación del proveedor de gestión de claves:
Azure Key Vault: Recuperar la clave borrada
GCP KMS: Destruir y restaurar versiones clave
Uso de KMS para la validación de datos
En el caso de clústeres con cifrado en reposo mediante claves gestionadas por el cliente, la validación de datos de Atlas requiere acceso adicional a KMS para descifrar los datos durante las comprobaciones de validación.
La validación de datos está habilitada por defecto para todos los proyectos. Puede optar por no participar si los costos, las solicitudes o las consideraciones de seguridad extra de KMS no se ajustan a sus requisitos.
Uso de KMS
Cuando la validación de datos está habilitada, las instancias de validación realizan más solicitudes a su KMS para descifrar los datos de los clústeres cifrados.
Volumen de solicitudes:
Atlas realiza aproximadamente una solicitud de descifrado por nodo de set de réplicas por hora durante la validación. Un set de réplicas estándar de tres nodos con una ventana de validación de siete días genera aproximadamente 500 solicitudes KMS más.
Costos estimados:
Para la mayoría de los clústeres, los costos de KMS relacionados con la validación son mínimos. Para conocer los precios actuales, consulte la documentación de su proveedor de nube.
Consideraciones de seguridad:
Las instancias de validación aparecen como principales extra en los registros de auditoría de KMS.
Si utiliza listas de direcciones IP permitidas para su KMS, es posible que deba agregar rangos de direcciones IP de instancias de validación a su lista de direcciones permitidas.
Las instancias de validación utilizan las mismas claves gestionadas por el cliente que los nodos del clúster.
Para obtener la lista actual de rangos de IP de instancias de validación, póngase en contacto con el Soporte de MongoDB.
Configuración de la lista de permitidos de IP para clústeres cifrados
La mayoría de las configuraciones de KMS no requieren cambios adicionales en la lista de direcciones IP permitidas para la validación de datos. Sin embargo, si su KMS utiliza controles de acceso basados en IP (por ejemplo, Azure Key Vault con restricciones de firewall), debe agregar los rangos de IP de las instancias de validación a su lista de direcciones permitidas. De lo contrario, la validación fallará.
Para configurar las listas de direcciones IP permitidas para su KMS:
AWS KMS normalmente permite el acceso mediante el rol de IAM. No se requiere ninguna configuración adicional de la lista de direcciones IP permitidas para las instancias de validación si su política de IAM permite el rol de Atlas.
Azure Key Vault suele utilizar listas de permitidos de IP estrictas. Si la validación falla con errores de acceso a KMS, agregue los rangos de IP de validación de Atlas a las reglas de red de Azure Key Vault.
En el portal de Azure, navegue hasta su Key Vault.
Seleccione Networking en el menú de la izquierda.
En Firewalls and virtual networks, agregue los rangos de IP de validación de Atlas.
Haga clic en Save.
Google Cloud KMS generalmente permite el acceso mediante cuenta de servicio. No se requiere ninguna configuración adicional de lista de direcciones IP permitidas para las instancias de validación si su política de IAM permite la cuenta de servicio de Atlas.
Para obtener más información sobre la validación de datos, consulta Validación de datos para la coherencia del clúster.