La seguridad de los datos es crucial en tiempos de GDPR, PCI DSS o HIPPA. Para cumplir con las regulaciones, se debe extremar la precaución con respecto a cómo se deben almacenar y proteger los datos. Los datos, por lo general, pueden estar en reposo o en tránsito. Los datos en tránsito son los datos transferidos desde o hacia la base de datos. Los resultados de las consultas enviadas al cliente o la aplicación o los datos replicados entre los nodos del clúster son ejemplos de casos en los que los datos están en tránsito. Tendemos a proteger los datos en ese estado mediante SSL o TLS:conexiones cifradas entre los nodos de la base de datos o la base de datos y el cliente.
En el otro lado del espectro, tenemos datos en reposo; diríamos que la mayoría de los datos están, en un momento dado, en reposo. Estamos hablando de datos almacenados en el disco en espacios de tablas, diferentes estructuras de datos (búfer de gcache, registros de rehacer) y registros (registros binarios y de retransmisión). Echemos un vistazo a las consideraciones sobre este tema en MariaDB.
¿Qué cifrar en MariaDB?
Lo ideal es cifrar todo. Las bases de datos almacenan datos en diferentes lugares y de diferentes maneras, como se mencionó anteriormente. El conjunto más grande de datos se almacena en espacios de tabla:esta es la ubicación "final" donde se almacenan los datos. Obviamente, es posible encriptar espacios de tabla; de lo contrario, toda la función no tendría sentido. MariaDB puede almacenar los datos en un espacio de tabla compartido, varios de ellos o cada tabla puede almacenarse en un espacio de tabla separado; todos esos escenarios son compatibles. Los usuarios tienen cierto nivel de flexibilidad al elegir qué cifrar. Puede cifrar todo, tablas individuales o todo excepto algunas tablas individuales.
Registro de rehacer de MariaDB InnoDB
Otra estructura que almacena los datos es el registro de rehacer de InnoDB. El registro de rehacer de InnoDB es un lugar donde los datos se escriben después de que se haya actualizado una fila determinada. Los datos del registro de rehacer eventualmente se transferirán al espacio de tabla, pero por un tiempo, el registro de redo de InnoDB contiene todas las modificaciones que ocurrieron recientemente. Como puede imaginar, estos datos también son críticos y deben protegerse:MariaDB le permite cifrar el registro de rehacer de InnoDB.
Registros binarios de MariaDB
Los registros binarios (así como los registros de retransmisión) almacenan información sobre las consultas ejecutadas que modifican los datos. Dado que la información incluida nos permite reconstruir el estado actual de una fila que ha sufrido modificaciones, esta es otra forma de datos que deben protegerse y cifrarse. Tanto los registros binarios como los de retransmisión se pueden cifrar en MariaDB.
caché de Galera
Galera cache (gcache) es un búfer en disco en Galera Cluster que almacena la información sobre las modificaciones ejecutadas. Se utiliza en caso de falla del nodo o problemas temporales de la red para permitir que los nodos que se unen al clúster se pongan al día usando solo los datos que faltan, evitando la transferencia de todo el conjunto de datos. Al igual que los registros binarios o los registros de rehacer, gcache contiene la lista de modificaciones y, como tal, se puede usar para recuperar y reunir datos. En la versión comunitaria de MariaDB Galera Cluster gcache no se puede cifrar. Dicha opción está disponible en la versión Enterprise de MariaDB Galera Cluster.
¿Qué no se puede cifrar en MariaDB?
Todavía hay algunos lugares donde pueden aparecer datos que no se pueden cifrar, al menos a partir de ahora, en MariaDB. En primer lugar, los registros de errores pueden contener muestras de consultas que potencialmente pueden exponer algunos datos. Es imposible cifrar los registros de errores, pero es posible redirigir el registro de errores al syslog e implementar algún mecanismo de protección fuera de MariaDB.
Registros del complemento de auditoría
El complemento de auditoría también genera un registro; este registro puede contener información confidencial, incluidas las consultas exactas que se han ejecutado en la base de datos. No es posible cifrar este registro, pero se puede redirigir al syslog y cifrarlo allí.
Registros de consultas
Registros de consultas generales y lentas:esos registros contendrán consultas (o al menos muestras de ellas) que fueron ejecutadas por MariaDB. A partir de ahora, no es posible cifrar esos registros.
Grupo de búfer de InnoDB
Memoria:MariaDB realiza el cifrado solo para las páginas que están almacenadas en el disco. Todos los datos almacenados en el grupo de búfer de InnoDB no estarán cifrados. El grupo de búfer de InnoDB está destinado a mantener las filas modificadas recientemente o a las que se accedió mediante la consulta SELECT; esas filas obviamente contendrán muestras de datos. A partir de ahora, no hay opción para cifrar el grupo de búfer de InnoDB en MariaDB. Tenga en cuenta que se necesitaría acceso al sistema para leer la memoria en vivo. No es una tarea trivial, aunque tampoco es imposible de lograr.
Por favor, tenga en cuenta que cubrimos las opciones de encriptación incluidas en MariaDB. Siempre existe la posibilidad de utilizar otra capa de cifrado. Por ejemplo, cifrar todo el almacenamiento hará que los registros no sean legibles para nadie que tenga acceso físico al disco. Por otro lado, no protegerá los datos de alguien que pueda iniciar sesión en el sistema.
Compatibilidad con herramientas externas
Otra cosa a considerar es la compatibilidad. Si decide cifrar su MariaDB, debe tener en cuenta que esto puede afectar la forma en que opera. No es posible utilizar herramientas externas como XtraBackup o mysqlbinlog para procesar los datos y crear una copia de seguridad o gestionar registros binarios. Deberá ceñirse a las herramientas creadas por MariaDB (como Mariabackup), que están escritas teniendo en cuenta el mecanismo de encriptación. Pueden manejar los datos en reposo. El cifrado se implementa en MariaDB.
Planificación del proceso de cifrado
Esta sección no analizará el proceso en detalle, pero analiza lo que debe tener en cuenta al planificar el cifrado, como los recursos y el tiempo. La utilización de la CPU aumentará, así como la actividad de E/S durante la duración del proceso. Desde el punto de vista del usuario, todo se reduce a los ajustes de configuración y luego a la ejecución de los comandos ALTER para reconstruir y cifrar las tablas existentes. Para bases de datos grandes, esto por sí solo puede ser un desafío importante que requeriría planificación. Los cambios de esquema pueden ser una carga importante y se recomienda utilizar herramientas como pt-online-schema-change para reducir su impacto en los sistemas de producción y obtener un mejor control sobre el proceso.
Reflexiones finales
Como mencionamos, los datos son críticos para todas las organizaciones, y es crucial garantizar que los datos estén seguros y protegidos. El cifrado de los datos en reposo es uno de los elementos importantes de todo el panorama. Nos encantaría saber de usted acerca de su experiencia con el cifrado de datos en reposo en MariaDB. Si desea compartir sus pensamientos, puede dejar un comentario a continuación.
