Hay aspectos incomprensibles en el mundo de la informática en general. El uso de base de datos es básico para que los servicios funcionen. Realizar una replicación para crear un servidor de respaldo no es algo raro. Lo que sí que resulta extraño es que los datos de conexión a la base de datos a replicar aparezcan en archivos de texto plano, como es el caso de MySQL y sus derivados.

O al menos eso es lo que pensamos nosotros y una inmensa mayoría de usuarios. Para todos aquellos usuarios que no conozcan en qué consiste la replicación de base de datos, lo vamos a explicar de forma breve: Se parten de dos equipos con dos bases de datos en el mismo estado (mismas bases de datos, tablas, filas, …), es decir, dos copias idénticas. Una asumirá el rol de maestro y otra de esclavo. Esto quiere decir que las consultas se dirigirán sobre el primero mientras que el esclavo quedará a la espera. Si se configura una replicación, el maestro ejecutará las órdenes y las copiará a un registro que será leído por el esclavo, permitiendo que este pueda replicar todas las operaciones realizadas.

Después de esta breve explicación, volvemos al tema que nos ocupa. En primer lugar, vamos a ver qué es lo que existe en el manual de la base de datos. En la página de ayuda de la base de datos podemos leer lo siguiente:

Although you do not have to create an account specifically for replication, you should be aware that the replication user name and password are stored in plain text in the master info repository file or table

Es decir, que los usuarios deben ser conscientes de que las credenciales de acceso del usuario de replicación utilizado para acceder al maestro se almacenan en una tabla o fichero en texto plano. Para ser más exactos, el archivo en cuestión si hablamos de sistemas Linux se puede encontrar en la dirección:

/bin/lib/mysql/

O lo que es lo mismo, junto aquellos que conforman el entramado lógico de las bases de datos y sus tablas.

Con esto lo que se puede apreciar es que de entrada no es un fallo de seguridad como tal, aunque muchos usuarios seguro que discrepan con la seguridad de esta función. Muchos usuarios se han quejado al respecto, pero desde MySQL manifiestan que no hay de qué preocuparse si la base de datos está configurada de forma correcta y el usuario de replicación se ha creado de forma correcta.

Las explicaciones de MySQL

Ya hemos dicho que esto es algo que a corto plazo no va a cambiar. Los responsables de la base de datos están convencidos de que esto no es un problema de seguridad y a continuación os vamos a explicar el motivo. Antes de nada, os queremos dar una pequeña pista: el asunto va de permisos.

A la hora de crear un usuario de replicación no es el “mismo proceso” que uno de escritura o lectura de una base de datos parcial o completa. Lo que se quiere decir es que en este caso los permisos que se deben dar con Replication Slave y Replication Client (así es como se llaman en MySQL o a través de phpMyAdmin). La configuración de estos roles permite que el esclavo lea el log de actividad de la base de datos primaria y pueda extrapolar los comandos a la suya, añadiendo, eliminando o editando las filas de la tabla que sea necesaria. Por lo tanto, en caso de un problema de seguridad en el servidor esclavo y obtener las contraseñas de login en la base de datos del servidor primario, el impacto sería nulo.

Por este motivo, desde MySQL creen que no hay nada que solucionar y que no se trata de un aspecto prioritario.