Cómo usar el cifrado para proteger sus datos de MongoDB

La seguridad de la base de datos es un factor clave a considerar para cualquier aplicación que involucre datos altamente confidenciales, como informes financieros y de salud. La protección de datos se puede lograr mediante el cifrado en diferentes niveles, desde la propia aplicación hasta los archivos que contienen los datos.

Dado que MongoDB es una base de datos no relacional, no es necesario definir columnas antes de insertar datos; y, por lo tanto, los documentos de la misma colección pueden tener campos diferentes entre sí.

Por otro lado, para SQL DBMS, uno tiene que definir columnas para los datos, por lo que todas las filas tienen las mismas columnas. Uno puede decidir cifrar columnas individuales, todo el archivo de la base de datos o datos de la aplicación antes de involucrarse en el proceso de la base de datos.

Se prefiere el cifrado de columnas individuales, ya que es más económico y se cifran menos datos, lo que mejora la latencia. En general, el rendimiento general impacta como resultado del cifrado.

Sin embargo, para NoSQL DBMS, este enfoque no será el mejor. Teniendo en cuenta que no todos los documentos pueden tener todos los campos que desea usar en su cifrado, no se puede realizar el cifrado a nivel de columna.

El cifrado de datos a nivel de aplicación es bastante costoso y difícil de implementar. Por lo tanto, seguimos con la opción de cifrar datos a nivel de base de datos.

MongoDB proporciona cifrado nativo que no requiere que uno pague un costo adicional para proteger sus datos confidenciales.

Cifrado de datos en MongoDB

Cualquier operación de base de datos involucra cualquiera de estas dos formas de datos, datos en reposo o datos en movimiento.

Los datos en movimiento son un flujo de datos que se mueven a través de cualquier tipo de red, mientras que los datos en reposo son estáticos, por lo tanto, no se mueven a ninguna parte.

Ambos tipos de datos son propensos a la interferencia externa por parte de usuarios anónimos, a menos que se trate de un cifrado. El proceso de cifrado implica:

Generar una clave maestra para toda la base de datos
Generar claves únicas para cada base de datos
Cifrar sus datos con las claves de la base de datos que generó
Cifrar toda la base de datos con la clave maestra

Cifrado de datos en tránsito

Los datos se transfieren entre MongoDB y la aplicación del servidor de dos maneras, a través de Transport Layer Security (TLS) y Secure Socket Layer (SSL).

Estos dos son los protocolos de cifrado más utilizados para proteger los datos enviados y recibidos entre dos sistemas. Básicamente, el concepto es cifrar las conexiones a las instancias de mongod y mongos de modo que el tráfico de la red solo pueda ser leído por el cliente previsto.

TLS/SSL se utilizan en MongoDB con algunos certificados como archivos PEM que emite la autoridad de certificación o puede ser un certificado autofirmado. Este último tiene la limitación de que, sin embargo, el canal de comunicación está encriptado, siempre no hay validación contra la identidad del servidor, por lo que es vulnerable a ataques externos a mitad de camino. Por lo tanto, es recomendable utilizar certificados de autoridad de confianza que permitan a los controladores MongoDB verificar también la identidad del servidor.

Además del cifrado, TLS/SSL se puede usar en la autenticación del cliente y las autenticaciones internas de los miembros de conjuntos de réplicas y clústeres fragmentados a través de los certificados.

Configuración de TLS/SSL para clientes

Hay varias configuraciones de opciones TLS/SSL que se pueden usar en la configuración de estos protocolos.

Por ejemplo, si desea conectarse a una instancia de Mongod mediante encriptación, iniciaría su instancia como,

mongo --ssl --host example.com --sslCAFile /etc/ssl/ca.pem

--ssl habilita la conexión TLS/SSL.

--sslCAFile especifica el archivo pem de la autoridad certificadora (CA) para la verificación del certificado presentado por el mongod o los mongos. Por lo tanto, el shell de Mongo verificará el certificado emitido por la instancia de mongod contra el archivo CA especificado y el nombre de host.

También es posible que desee conectar una instancia de MongoDB que requiera un certificado de cliente. Usamos el ejemplo de código a continuación

mongo --ssl --host hostname.example.com --sslPEMKeyFile /etc/ssl/client.pem --sslCAFile /etc/ssl/ca.pem

La opción --sslPEMKeyFile especifica el archivo .pem que contiene el certificado de shell mongo y una clave para presentar a la instancia mongod o mongos. Durante el proceso de conexión:

El shell mongo verificará si el certificado es de la autoridad de certificación especificada que es (--sslCAFile) y, de lo contrario, el shell no podrá conectarse.

En segundo lugar, el shell también verificará si el nombre de host especificado en la opción --host coincide con el SAN/CN en el certificado presentado por mongod o mongos. Si este nombre de host no coincide con ninguno de los dos, la conexión fallará.

Si no desea utilizar certificados autofirmados, debe asegurarse de que la red de conexión sea de confianza.

Además, debe reducir la exposición de la clave privada, especialmente cuando se trata de conjuntos de réplicas/clúster fragmentado. Esto se puede lograr mediante el uso de diferentes certificados en diferentes servidores.

Las opciones adicionales que se pueden utilizar en las conexiones son:

requireSSL:esto restringirá cada servidor para usar solo conexiones encriptadas TLS/SSL.

--sslAllowConnectionsWithoutCertificates:Esto permite la validación si solo el cliente presenta un certificado; de lo contrario, si no hay certificado, el cliente seguirá conectado en modo cifrado. Por ejemplo:

mongod --sslMode requireSSL --sslAllowConnectionsWithoutCertificates --sslPEMKeyFile /etc/ssl/mongodb.pem --sslCAFile /etc/ssl/ca.pem

sslDisabledProtocols:esta opción evita que los servidores acepten conexiones entrantes que utilizan protocolos específicos. Esto se puede hacer con:

mongod --sslMode requireSSL --sslDisabledProtocols TLS1_0,TLS1_1 --sslPEMKeyFile /etc/ssl/mongodb.pem --sslCAFile /etc/ssl/ca.pem

Cifrado de datos en reposo

A partir de la versión 3.2, MongoDB introdujo una opción de cifrado nativo para el motor de almacenamiento WiredTiger. El acceso a los datos en este almacenamiento por parte de un tercero solo se puede lograr a través de una clave de descifrado para decodificar los datos en un formato legible.

El algoritmo de cifrado de cifrado comúnmente utilizado en MongoDB es el AES256-GCM. Utiliza la misma clave secreta para cifrar y descifrar datos. El cifrado se puede activar mediante el modo FIPS, lo que garantiza que el cifrado cumpla con los más altos estándares y cumplimiento.

Todos los archivos de la base de datos se cifran mediante el cifrado de datos transparente (TDE) en el nivel de almacenamiento.

Cada vez que se cifra un archivo, se genera una clave de cifrado privada única y es bueno comprender cómo se administran y almacenan estas claves. Todas las claves de la base de datos generadas se cifran posteriormente con una clave maestra.

La diferencia entre las claves de la base de datos y la clave maestra es que las claves de la base de datos se pueden almacenar junto con los datos cifrados, pero para la clave maestra, MongoDB recomienda que se almacene en un servidor diferente al de los datos cifrados, como una clave empresarial de terceros. soluciones de gestión.

Con los datos replicados, los criterios de cifrado no se comparten con los otros nodos, ya que los datos no se cifran de forma nativa a través del cable. Se puede reutilizar la misma clave para los nodos, pero la mejor práctica es usar claves individuales únicas para cada nodo.

Claves de cifrado rotativas

La clave administrada utilizada para descifrar datos confidenciales debe rotarse o reemplazarse al menos una vez al año. Hay dos opciones en MongoDB para lograr la rotación.

Rotación maestra de KMIP

En este caso, solo se cambia la clave maestra ya que se gestiona externamente. El proceso para rotar la llave se describe a continuación.

La clave maestra para los miembros secundarios del conjunto de réplicas se rota de uno en uno. Es decir

mongod --enableEncryption --kmipRotateMasterKey \ --kmipServerName <KMIP Server HostName> \--kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

Una vez que se complete el proceso, mongod saldrá y deberá reiniciar el secundario sin el parámetro kmipRotateMasterKey

mongod --enableEncryption --kmipServerName <KMIP Server HostName> \
  --kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem

El primario del conjunto de réplicas se reduce:
Con el método rs.stepDown(), el primario se desactiva y, por lo tanto, se fuerza la elección de un nuevo primario.
Verifique el estado de los nodos utilizando el método rs.status() y, si el principal indica que se ha reducido, rote su clave maestra. Reinicie el miembro reducido, incluida la opción kmipRotateMasterKey.
```
mongod --enableEncryption --kmipRotateMasterKey \
  --kmipServerName <KMIP Server HostName> \
  --kmipServerCAFile ca.pem --kmipClientCertificateFile client.pem
```

Registro

MongoDB siempre funciona con un archivo de registro para registrar algún estado o información específica en diferentes intervalos.

Sin embargo, el archivo de registro no está cifrado como parte del motor de almacenamiento. Esto presenta un riesgo en el sentido de que una instancia de mongod que se ejecuta con el registro puede generar datos potencialmente confidenciales en los archivos de registro como parte del registro normal.

Desde la versión 3.4 de MongoDB, existe la configuración security.redactClientLogData que evita que se registren datos potencialmente confidenciales en el registro del proceso mongod. Sin embargo, esta opción puede complicar el diagnóstico del registro.

Varios nueves Conviértase en un administrador de bases de datos de MongoDB - Llevando MongoDB a la producción Obtenga información sobre lo que necesita saber para implementar, monitorear, administrar y escalar MongoDBDescargar gratis

Rendimiento de cifrado en MongoDB

El cifrado en algún momento da como resultado un aumento de la latencia, lo que degrada el rendimiento de una base de datos. Este suele ser el caso cuando se trata de un gran volumen de documentos.

El cifrado y el descifrado requieren más recursos, por lo que es importante comprender esta relación para ajustar la planificación de la capacidad en consecuencia.

Con respecto a las pruebas de MongoDB, un motor de almacenamiento encriptado experimentará una latencia de entre 10 % y 20 % en la carga más alta. Este suele ser el caso cuando un usuario escribe una gran cantidad de datos en la base de datos, lo que resulta en un rendimiento reducido. Para las operaciones de lectura, la degradación del rendimiento es insignificante, entre un 5 y un 10 %.

Para una mejor práctica de cifrado en MongoDB, el motor de almacenamiento WiredTiger es el más preferido debido a su alto rendimiento, seguridad y escalabilidad. Además, optimiza el cifrado de los archivos de la base de datos a nivel de página, lo que tiene un gran mérito porque, si un usuario lee o escribe datos en la base de datos cifrada, la operación de rendimiento solo se aplicará a la página en la que se almacenan los datos en lugar de a todo el contenido. base de datos.

Esto reducirá la cantidad de datos que será necesario cifrar y descifrar para procesar un único dato.

Resumen

La seguridad de los datos para la información confidencial es imprescindible y es necesario protegerla sin degradar el rendimiento del sistema de la base de datos.

MongoDB proporciona procedimientos de cifrado nativos sólidos que pueden ayudarnos a proteger nuestros datos tanto en reposo como en movimiento. Además, los procedimientos de cifrado deben cumplir con los estándares establecidos por diferentes organizaciones.

El motor de almacenamiento avanzado WiredTiger ofrece una mejor opción debido a sus méritos asociados, como alto rendimiento, escalabilidad y seguridad. Al cifrar datos en conjuntos de réplicas, es una buena práctica usar diferentes claves maestras para cada uno, además de cambiarlas al menos una vez al año.

Independientemente de la disponibilidad de opciones de cifrado de terceros, no hay garantía de que su implementación coincida con ellas en términos de escalabilidad. Por lo tanto, es bastante considerado emplear el cifrado a nivel de base de datos.