Overview
Esta página describe la configuración del servidor para admitir el cifrado en reposo. Si usa MongoDB Atlas, sus datos ya están cifrados. MongoDB gestiona el cifrado de Atlas a nivel de proveedor de la nube, pero también puede usar su propia solución de gestión de claves. Consulte la documentación de gestión de claves de Atlas para obtener más información.
MongoDB Enterprise 3.2 introduce una opción de cifrado nativo para el motor de almacenamiento WiredTiger. Fuera de Atlas, el cifrado solo está disponible para instalaciones empresariales que utilizan el motor de almacenamiento WiredTiger.
La gestión segura de las claves de cifrado es un requisito fundamental para el cifrado del almacenamiento. MongoDB utiliza una clave maestra que no se almacena con la instalación. Solo la clave maestra se gestiona externamente; otras claves se pueden almacenar con la instancia de MongoDB.
El motor de almacenamiento cifrado de MongoDB admite dos opciones de administración de claves para la clave maestra:
Integración con un dispositivo de gestión de claves de terceros a través del Protocolo de Interoperabilidad de Gestión de Claves (KMIP). Recomendado
Uso de la gestión de claves local a través de un archivo de claves.
Importante
MongoDB no puede cifrar datos existentes. Al habilitar el cifrado con una nueva clave, la instancia de MongoDB no puede tener datos preexistentes. Si su instalación de MongoDB ya tiene datos, consulte Cifrar datos existentes en reposo para obtener más información.
Administrador de claves
MongoDB Enterprise admite la transferencia segura de claves con dispositivos de gestión de claves compatibles. El uso de un administrador de claves permite almacenar las claves en él.
MongoDB Enterprise admite la transferencia segura de claves con dispositivos de administración de claves compatibles con el Protocolo de interoperabilidad de administración de claves (KMIP).
Para obtener una lista de los socios certificados de MongoDB, consulta la Lista de socios.
Tip
Recomendado
Utilizar un administrador de claves cumple con las directrices regulatorias de gestión de claves, como HIPAA, PCI-DSS y FERPA, y es recomendable en comparación con la gestión local de claves.
Requisitos previos
Su administrador de claves debe admitir el protocolo de comunicación KMIP.
La versión predeterminada del protocolo KMIP es 1.2. Puede configurar MongoDB para usar la versión 1.0 o 1.1 de KMIP en el servidor MongoDB. archivo de configuración.
Para una integración con un dispositivo de administración de claves de terceros mediante el KMIP, debe permitir las siguientes operaciones KMIP:
Crear (
operation_create)Obtener (
operation_get)Activar (
operation_activate)
Para autenticar MongoDB en un servidor KMIP, debe tener un certificado válido emitido por el dispositivo de administración de claves.
Nota
MongoDB Enterprise en Windows ya no admite AES256-GCM como un cifrado de bloques para el cifrado en reposo. Este uso solo es compatible con Linux.
Cifrar usando una nueva clave
Para crear una nueva clave cuando se conecta al administrador de claves, utilice las siguientes opciones para iniciar mongod:
Para conectarse a un 1.0 1.1 servidor KMIP versión o, utilice la --kmipUseLegacyProtocol opción.
Incluir opciones adicionales según sea necesario para la configuración. Por ejemplo, si se desea que los clientes remotos se conecten a su implementación o si los miembros de su implementación se ejecutan en hosts diferentes, especificar el --bind_ip.
La siguiente operación crea una nueva clave principal en su administrador de claves. mongod usa la clave maestra para cifrar las claves que mongod genera para cada base de datos.
mongod --enableEncryption \ --kmipServerName <KMIP Server HostName> \ --kmipPort <KMIP server port> \ --kmipServerCAFile ca.pem \ --kmipClientCertificateFile client.pem
mongod verifica la conexión al servidor KMIP al inicio.
El nombre del servidor especificado en --kmipServerName debe coincidir con el nombre alternativo SAN del sujeto o el nombre común CN en el certificado presentado por el servidor KMIP. SAN puede ser un nombre de sistema o una dirección IP.
Si SAN está presente, mongod no intenta coincidir con CN.
Si el nombre de host o la dirección IP del servidor KMIP no coincide con SAN ni con CN, mongod no se iniciará.
Para verificar que la creación y el uso de la clave se realizaron correctamente, revise el archivo de registro. Si se realizó correctamente, el proceso registrará los siguientes mensajes:
[initandlisten] Created KMIP key with id: <UID> [initandlisten] Encryption key manager initialized using master key with id: <UID>
Cifrar usando una clave existente
Puede usar una clave maestra existente que su servidor KMIP ya administre. Para usar una clave existente, utilice estas opciones al iniciar mongod para conectarse mongod al administrador de claves:
Para conectarse a un 1.0 1.1 servidor KMIP versión o, utilice la --kmipUseLegacyProtocol opción.
Incluir opciones adicionales según sea necesario para la configuración. Por ejemplo, si se desea que los clientes remotos se conecten a su implementación o si los miembros de su implementación se ejecutan en hosts diferentes, especificar el --bind_ip.
mongod --enableEncryption \ --kmipServerName <KMIP Server HostName> \ --kmipPort <KMIP server port> \ --kmipServerCAFile ca.pem \ --kmipClientCertificateFile client.pem \ --kmipKeyIdentifier <UID>
mongod verifica la conexión al servidor KMIP al inicio.
El nombre del servidor especificado en --kmipServerName debe coincidir con el nombre alternativo SAN del sujeto o el nombre común CN en el certificado presentado por el servidor KMIP. SAN puede ser un nombre de sistema o una dirección IP.
Si SAN está presente, mongod no intenta coincidir con CN.
Si el nombre de host o la dirección IP del servidor KMIP no coincide con SAN ni con CN, mongod no se iniciará.
Administración de claves locales
Importante
El uso del método de archivo de claves no cumple con la mayoría de las pautas regulatorias de administración de claves y requiere que los usuarios administren de forma segura sus propias claves.
La gestión segura del archivo de claves es fundamental.
Para cifrar con un archivo de claves, debe tener un64 archivo de claves codificado en base que contenga una sola 16 32 cadena de caracteres o. Solo el propietario del proceso debe poder acceder a este archivo de claves.mongod
Cree el archivo de clave codificado base64 con la cadena de caracteres 16 o 32. Puede generar el archivo de clave codificado con el método que prefiera. Por ejemplo,
openssl rand -base64 32 > mongodb-keyfile Actualiza los permisos del archivo.
chmod 600 mongodb-keyfile Para utilizar el archivo de clave, inicie con las siguientes
mongodopciones:--enableEncryption,--encryptionKeyFile <path to keyfile>,
mongod --enableEncryption --encryptionKeyFile mongodb-keyfile Incluir opciones adicionales según sea necesario para la configuración. Por ejemplo, si se desea que los clientes remotos se conecten a su implementación o si los miembros de su implementación se ejecutan en hosts diferentes, especificar el
--bind_ip.Verifique si el administrador de claves de cifrado se inicializó correctamente con el archivo de claves. Si la operación se realizó correctamente, el proceso registrará el siguiente mensaje:
[initandlisten] Encryption key manager initialized with key file: <path to keyfile>
Cifrar datos existentes en reposo
MongoDB no puede cifrar datos existentes. Al habilitar el cifrado con una nueva clave, la instancia de MongoDB no puede tener datos preexistentes.
Si está utilizando un conjunto de réplicas que tiene datos existentes, utilice una sincronización inicial continua para cifrar los datos.
Por ejemplo, considere un conjunto de réplicas con tres miembros. El conjunto de réplicas está en uso y contiene datos que desea cifrar. Estos son los pasos que seguiría para cifrar los datos en reposo:
Preparar un servidor.
Siga estos pasos para preparar el servidor:
Elija uno de los servidores secundarios.
Detener en el servidor
mongodsecundario.Opcional: Realice una copia de seguridad de los datos
dbPathen. Si no necesita una copia de seguridad completa, considere hacer una copia de seguridad solo deldiagnostic.datadirectorio para conservar datos útiles para la resolución de problemas en caso de que surja algún problema. Consulte Captura de datos de diagnóstico a tiempo completo para obtener más información.Elimine los archivos y directorios
dbPathen.
Sincronizar los datos.
Importe los datos del servidor principal. Inicie el proceso mongod y especifique las opciones de replicación según corresponda.
mongod Realiza una sincronización inicial y encripta los datos durante el proceso de sincronización.
Repita el proceso en los secundarios.
Cuando la primera instancia secundaria haya terminado de importar y cifrar los datos, repita el proceso en las otras instancias mongod secundarias.
Cifrar el primario.
Una vez cifrados todos los secundarios, el principal. Los secundarios elegibles elegirán un nuevostep down principal.
El servidor principal antiguo ahora es secundario. Repita los pasos para eliminar los datos sin cifrar y luego ejecute una sincronización inicial.