Make the MongoDB docs better! We value your opinion. Share your feedback for a chance to win $100.
Click here >
Docs Menu
Docs Home
/ /

Configura el cifrado

En esta página se analiza la configuración del servidor para soportar el cifrado en reposo. Si utiliza MongoDB Atlas, tus datos ya están cifrados. MongoDB gestiona el cifrado de Atlas a nivel del proveedor de nube, pero también puede utilizar su propia solución de gestión de claves. Consulta la documentación de gestión de claves de Atlas para más detalles.

MongoDB Enterprise 3.2 introduce una opción de cifrado nativa 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 de almacenamiento. MongoDB utiliza una clave maestra que no se almacena junto con la instalación de MongoDB. Solo la clave maestra se gestiona externamente, las demás claves pueden almacenarse en su instancia de MongoDB.

El motor de almacenamiento cifrado de MongoDB proporciona dos opciones de gestió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 local de llaves a través de un archivo llave.

Importante

MongoDB no puede encriptar los datos existentes. Cuando activas el cifrado con una clave nueva, la instancia de MongoDB no puede contener ningún dato preexistente. Si tu instalación de MongoDB ya tiene datos existentes, consulta Cifrar datos en reposo para pasos adicionales.

MongoDB Enterprise admite la transferencia segura de claves con dispositivos de gestión de claves compatibles. Utilizar un administrador de llaves permite que las llaves se almacenen en el administrador de llaves.

MongoDB Enterprise admite la transferencia segura de claves con dispositivos de gestión de claves que cumplen con el protocolo de Interoperabilidad de Gestió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.

  • El gestor de claves debe ser compatible con el protocolo de comunicación KMIP.

    La versión por defecto del protocolo KMIP es 1.2. Puede configurar MongoDB para usar la versión KMIP 1.0 o 1.1 en el servidor MongoDB archivo de configuración.

  • Para una integración con un sistema externo de gestión de claves usando el KMIP, deberías permitir las siguientes operaciones KMIP:

    • Crear (operation_create)

    • Obtener (operation_get)

    • Activar (operation_activate)

    • GetAttributes (operation_get_attributes)

    • Cifrar (operation_encrypt)

    • Descifrar (operation_decrypt)

    MongoDB requiere las operaciones de cifrado y descifrado con la configuración por defecto de KMIP. Si configuras security.kmip.useLegacyProtocol en true en el archivo de configuración del servidor MongoDB, MongoDB utiliza el protocolo KMIP 1.0/1.1, que no requiere estas operaciones.

  • Para autenticar MongoDB ante un servidor KMIP, debes tener un certificado válido expedido por el dispositivo de gestión de llaves.

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.

Para crear una nueva clave cuando te conectes al administrador de claves, agrega una entrada similar a la siguiente en tu archivo de configuración. Reemplace las cadenas y el número de puerto por sus valores.

security:
enableEncryption: true
kmip:
serverName: "mdbhost.somecompany.com"
port: 5696
serverCAFile: "security/libs/trusted-ca.pem"
clientCertificateFile: "security/libs/trusted-client.pem"

Para obtener más información sobre estas opciones, consulta Opciones de Configuración de la Gestión de Claves.

Para conectarse a la versión 1.0 o 1.1 En el servidor KMIP, establecer la opción de configuración security.kmip.useLegacyProtocol.

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.

Importante

La activación del cifrado mediante un servidor KMIP en Windows falla cuando se utiliza security.kmip.clientCertificateFile y el servidor KMIP aplica TLS 1.2.

Para activar el cifrado en reposo con KMIP en Windows, debes:

mongod verifica la conexión al servidor KMIP al inicio.

El nombre del servidor especificado en security.kmip.serverName debe coincidir con el Nombre Alternativo del Sujeto SAN o con 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 uso de la clave fue exitosa, revisa la entrada de registro. Si es exitoso, el proceso registrará los siguientes mensajes:

[initandlisten] Created KMIP key with id: <UID>
[initandlisten] Encryption key manager initialized using master key with id: <UID>

Puedes utilizar una clave maestra existente que ya administre tu servidor KMIP. Para usar una clave existente, añade una entrada similar a la siguiente en tu archivo de configuración antes de iniciar mongod. Reemplace las cadenas y el número de puerto con sus valores.

security:
enableEncryption: true
kmip:
keyIdentifier: "a29fba3-fd8327a2-74ba-43aa-bd3b-78a549a5295f"
serverName: "mdbhost.somecompany.com"
port: 5696
serverCAFile: "security/libs/trusted-ca.pem"
clientCertificateFile: "security/libs/trusted-client.pem"

Para obtener más información sobre estas opciones, consulta Opciones de Configuración de la Gestión de Claves.

Para conectarse a la versión 1.0 o 1.1 En el servidor KMIP, establecer la opción de configuración security.kmip.useLegacyProtocol.

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 verifica la conexión al servidor KMIP al inicio.

El nombre del servidor especificado en security.kmip.serverName debe coincidir con el Nombre Alternativo del Sujeto SAN o con 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á.

El uso del método keyfile no cumple con la mayoría de las directrices regulatorias de gestión de claves y requiere que los usuarios gestionen de manera segura sus propias claves.

La gestión segura del archivo de claves es fundamental.

Importante

La rotación de claves no está disponible para la gestión de claves local. Si tu caso de uso requiere rotación de claves, utiliza un gestor de claves.

Para cifrar utilizando un archivo clave, debes contar con un archivo clave codificado en base64 que contenga una única string de 16 o 32 caracteres. El archivo clave debe ser accesible solo por el propietario del proceso mongod.

  1. Cree el archivo de claves codificado en base64 con la string de 16 o 32 caracteres. Se puede generar el archivo clave codificado utilizando cualquier método que se prefiera. Por ejemplo,

    openssl rand -base64 32 > mongodb-keyfile
  2. Actualiza los permisos del archivo.

    chmod 600 mongodb-keyfile
  3. Para utilizar el archivo de claves, inicia mongod con las siguientes opciones:

    • --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.

  4. Verifica si el administrador de claves de cifrado se inicializó correctamente con el archivo de claves. Si la operación fue exitosa, el proceso registrará el siguiente mensaje:

    [initandlisten] Encryption key manager initialized with key file: <path to keyfile>

MongoDB no puede encriptar los datos existentes. Cuando habilitas el cifrado con una nueva clave, la instancia de MongoDB no puede tener ningún dato preexistente.

Si estás utilizando un set de réplicas que sí tiene datos existentes, utiliza una sincronización inicial en escala para cifrar los datos.

Por ejemplo, considere un set de réplicas con tres nodos. El set de réplicas está en uso y contiene datos que deseas cifrar. Estos son los pasos que deberías seguir para cifrar los datos en reposo:

1

Siga estos pasos para preparar el servidor:

  • Elija uno de los servidores secundarios.

  • Deten mongod en el servidor secundario.

  • Opcional: Realizar una copia de seguridad de los datos en dbPath. Si no se requiere una copia de seguridad completa, considera hacer una copia de seguridad solo del directorio diagnostic.data para preservar datos de solución de problemas potencialmente útiles en caso de inconvenientes. Consulta Captura de Datos Diagnósticos a Tiempo Completo para más información.

  • Remover los archivos y directorios en la dbPath.

2

Inicie el servidor secundario con el cifrado activado. La mongod instancia crea un nuevo almacén de claves.

3

Importar los datos del sistema principal. Inicia el proceso mongod, especificando las opciones de replicación según corresponda.

mongod realiza una sincronización inicial y cifra los datos durante el proceso de sincronización.

4

Cuando el primer secundario haya terminado de importar y cifrar los datos, repite el proceso en las demás instancias de secundario mongod.

5

Cuando todos los secundarios hayan sido cifrados, step down el principal. Los secundarios elegibles elegirán un nuevo primario.

La antigua principal ahora es una secundaria. Repetir los pasos para remover los datos no cifrados y luego ejecutar una sincronización inicial.

Volver

Cifrado en reposo

Obtén una insignia de habilidad

¡Domina "Operaciones de cifrado en reposo" de forma gratuita!

Más información

En esta página