Tiene sentido proteger con contraseña la base de datos si protege el acceso al archivo de configuración de la aplicación que contiene las credenciales de texto sin formato. Cuando restringe el acceso de lectura a la cuenta de la aplicación solamente, el atacante requiere acceso de root para ver la contraseña. En caso de que haya violado alguna otra cuenta (menos privilegiada), no podrá acceder a la base de datos.

Eso es una especie de protección onion (también conocida como " Layered Security " o " Defense in Depth " como se ve, por ejemplo) , en SANS '" Layered Security: Por qué funciona" whitepaper ). Si un atacante puede llegar a la (s) máquina (es), no puede obtener acceso completo a la base de datos. La aplicación debe tener un acceso restringido limitado solo a las tablas requeridas, y todo lo que no necesita escribirse debe ser de solo lectura. Cualquier acceso superior debe requerir una contraseña diferente nunca utilizada en la aplicación.

El beneficio es que un atacante que tiene acceso de red a la base de datos pero no el acceso del sistema de archivos al servidor no podrá iniciar sesión en la base de datos.

Si esto proporciona seguridad adicional dependerá de su escenario de amenaza y de sus objetivos de seguridad. Sé de al menos dos situaciones en las que se agrega seguridad:

• Le permite controlar de manera más precisa el acceso legítimo a la base de datos: puede haber personas que legítimamente necesiten acceder a la base de datos, pero no a los datos que contiene, como los administradores de DB que realizan el mantenimiento. Una base de datos encriptada puede (según la configuración) permitir el acceso a la base de datos mientras se mantienen los datos en secreto.
  De manera similar, el cifrado de una parte de la base de datos (por ejemplo, solo columnas con contraseñas) permite un acceso limitado (por ejemplo, para problemas de depuración, para informes o para un almacén de datos ) a la vez que protege la información crítica.
• Puede proteger las copias de seguridad de la base de datos. Si se realiza una copia de seguridad de la base de datos a nivel de archivo, o con una herramienta de copia de seguridad que admita bases de datos cifradas, la copia de seguridad se cifrará. Esto es útil porque las copias de seguridad pueden ser una fuente de violaciones de datos, ya que a menudo no están protegidas, así como los servidores de los que se tomaron (consulte, por ejemplo, La seguridad de backup pobre conduce a la pérdida de datos del cliente Ameriprise ).

Beneficios de proteger con contraseña la base de datos

• Si no es posible usarlo de manera insegura, se reduce el riesgo de que si la base de datos y el servidor deban dividirse en una etapa posterior, se dejarán de manera insegura, lo que dará lugar a futuras vulnerabilidades.

• Si un atacante puede violar la máquina con una cuenta limitada, es posible que pueda conectarse a los servicios locales, pero no restablecer la contraseña de la base de datos; exigir que el atacante se autentique limita el daño que pueden hacer.

• Si se puede usar un ataque para reflejar / retransmitir el tráfico, entonces puede aparecer un adversario remoto en la máquina local (un ejemplo sería un proxy al que se puede convencer para que cargue una API de DB, o un servicio que muestra los datos recibidos cuando una conexión falla a una URL determinada)

• Si se usan contraseñas, se puede evitar que diferentes sistemas y usuarios utilicen las cuentas de los demás, de lo contrario, un atacante de cualquier sistema puede pretender ser cualquier otro sistema.

¿Sabes todas esas violaciones de datos que ocurrieron recientemente? ¿Aquellos en los que las personas encontraron copias de seguridad de bases de datos protegidas sin contraseña en depósitos no protegidos de Amazon S3? Sí .

Nunca asuma que su base de datos solo vivirá en su servidor seguro detrás de veinte mil millones de firewalls. La menor molestia de una contraseña en su base de datos es un pequeño precio a pagar por la seguridad esencialmente gratuita que ofrece.

Si no tiene mayores problemas de escala en su futuro, puede no agregar ninguna seguridad para tener una contraseña , aunque tenga en cuenta que "no tener una contraseña " no es lo mismo " confiar en cualquier persona que afirme ser su aplicación ".

Si su aplicación se ejecuta como su propio usuario en el servidor *, algunas bases de datos pueden permitirle usar la autenticación de terceros (por ejemplo, lo que Postgres llama peer de autenticación) que le permite al servidor usar mecanismos de red o de sistema operativo para Determinando qué usuarios son quienes dicen ser. Por ejemplo, bajo la configuración correcta, el usuario de shell "bob" podría acceder a la base de datos "bob" sin dar una contraseña. Hacer que las cosas sean simples puede facilitar la protección de su base de datos y su aplicación.

Dicho esto, como jrtapsell 's respuestas , puede que tenga que mover su aplicación a otro servidor por razones de costo o rendimiento. En ese caso, es probable que necesite una contraseña almacenada u otro secreto como una clave privada, aunque existen algunos métodos principalmente dentro de las redes privadas que podrían usarse para evitar esto.

Si cree que hay una posibilidad decente de que necesitará una contraseña (u otro secreto almacenado) en el futuro, debe hacer los arreglos ahora para que no sean inseguros más tarde por alguien con menos tiempo o experiencia.

_{* Idealmente, esa cuenta debería tener una contraseña segura, o solo estar disponible para iniciar sesión a través de sudo o un mecanismo equivalente}

Como complemento a la respuesta de Serge Ballesta.

Esto se vuelve especialmente complicado si estás usando una base de datos NoSQL, por ejemplo. MongoDB, como predeterminado, cualquier usuario de base de datos tendrá privilegios de solo lectura para todas las bases de datos, y ni siquiera se configura para tener un db-user fuera de la caja . Existen bastantes puntos débiles como estado en Blog de Spider Labs hace algún tiempo (alrededor de 2013), pero las recomendaciones generalmente no se siguen, incluso para las grandes empresas, por ejemplo Incidente MacKeeper (finales de 2015).

En ambas referencias, encontrará una lista de las vulnerabilidades más comunes. Si prefiere leer las pautas 'oficiales', puede encontrarlas en aquí , serán análogos a las bases de datos SQL. Sin embargo, me gusta pensar que no hay excesos cuando el tema es la seguridad.