Tener usuarios de bases de datos separados (con contraseñas separadas), además del usuario root, es una buena práctica. Esto le permite proteger los datos de cada base de datos, de modo que si la contraseña de una base de datos se pierde, no compromete los datos de la otra base de datos. Y no tiene que usar la contraseña de root en ningún lugar, excepto cuando realice el mantenimiento de la base de datos.
En otras palabras, la diferencia entre el inicio de sesión compartido para todos los usuarios de la base de datos y los inicios de sesión separados es que el atacante puede acceder a menos datos cuando usa inicios de sesión separados. Porque incluso si el atacante no puede acceder a la raíz, todavía puede leer los datos que pertenecen al usuario comprometido, y tal vez hacer algún daño. Pero el resto de su base de datos está protegida.
Esto se debe a que la forma más probable en que los atacantes obtendrán acceso a su base de datos es a través de algún tipo de vulnerabilidad de inyección SQL en la aplicación, o al acceder a su red de alguna manera y al descubrir las credenciales de la cuenta en los archivos de configuración.
En el primer caso, solo se pierden los datos en la base de datos con el exploit. En el segundo caso (con un atacante en su red), solo obtienen acceso a los datos en la base de datos con la configuración filtrada. En ninguno de los dos casos, el atacante podrá acceder a la cuenta raíz.
Todo se reduce al principio de privilegio mínimo .
Además, puede tener diferentes esquemas de rotación de claves para las dos cuentas, tanto en términos de la frecuencia con la que cambia las contraseñas como en la forma en que las distribuye. Y eso, sospecho, es el valor más práctico para tener contraseñas diferentes. Con el tiempo, las contraseñas probablemente divergirán de todos modos, o causarán muchos dolores de cabeza operativos.