Realmente depende de cuál sea tu modelo de amenaza.
Si eliminamos todo lo demás y solo pensamos en la aplicación, básicamente no hay nada más que puedas hacer para mejorar realmente la seguridad de la aplicación. Manténgase alejado de las soluciones esotéricas y concéntrese en lo que es más fácil de mantener y limpiar. Quiero hacer hincapié en la limpieza, ya que normalmente el desastre de seguridad surge de situaciones complicadas.
De todos modos: si el atacante obtiene una ejecución remota de código bajo el usuario de la aplicación, no puede restringir el acceso a la configuración de ninguna manera; la aplicación debe acceder a ella, al igual que el atacante. Si obtiene capacidades de lectura de archivos, entonces el almacenamiento en una base de datos lo protegerá de la divulgación, incluso si tiene que almacenar las credenciales de la base de datos en un archivo, es probable que el atacante no pueda aprovecharlas. Si recibe una inyección de SQL, el acceso a la base de datos (en el caso poco probable de que esto no se traduzca en un código exec remoto), es más seguro tenerlos en un archivo. Realmente, depende de cómo se diseñe tu aplicación.
Ejecutar Apache como root es realmente una mala idea (bueno, deshabilitar la eliminación de privilegios, quiero decir). En lugar de implementar soluciones únicas, enfóquese en cosas que se mantendrán en su lugar sin más trucos y obtenga los beneficios de Pentest. pasar cosas a través del stdin, por ejemplo, hará que sea muy difícil para los evaluadores recuperar las credenciales, pero a la larga es probable que termines con un script de bash haciendo el trabajo ... que es mucho peor que las otras soluciones .