Contraseñas de DB: ¿Más seguras en los archivos de configuración .ini de una aplicación PHP o las variables de entorno apache2?

Estoy completamente de acuerdo con tu opinión de que no es una buena idea que phpinfo () descargue tus contraseñas de DB. Un archivo ini parece estar un poco mejor, su aplicación puede recuperar las contraseñas cuando sea necesario. Con los frameworks actuales como Symfony, este es el camino a seguir. Si restringe el acceso a las máquinas de producción a los administradores a cargo, tiene un círculo limitado de personas que podrían acceder a los archivos de configuración. Por supuesto, los archivos ini no deben almacenarse en un repositorio público. El inconveniente es que la aplicación en sí misma, el usuario del servidor web debe tener acceso al archivo y, por lo tanto, cualquier script PHP podría leerlo y volcarlo.

Esto plantea la cuestión de si está dispuesto a hacer grandes esfuerzos para mejorar la seguridad.

En el mundo Java EE puedes aplicar el siguiente concepto. Implementa una aplicación empresarial en un servidor de aplicaciones como GlassFish o JBoss. En la configuración JDBC concreta, se establece un marcador de posición para la contraseña. La contraseña real se puede almacenar dentro de un archivo de contraseña encriptado para el cual el administrador debe ingresar una contraseña al iniciar el servidor. Naturalmente, esto evita un inicio de servidor completamente automatizado. Personalmente, no puedo asegurarte que esto es 100% a prueba de balas, pero hace que sea más difícil para un atacante.

Otra posibilidad es "externalizar" sus contraseñas. Podría usar un servicio de contraseñas (google para "Cyber-Ark", creo que tienen una API / SDK para conectar sus propias aplicaciones a su bóveda de contraseñas) herramienta que almacena las contraseñas y controla el acceso. Cada vez que su aplicación necesite una contraseña, debe ser recuperada del servicio. Por supuesto, alguien que obtenga acceso a la API y los datos de inicio de sesión al servicio de contraseñas también podría solicitar contraseñas. Pero con un servicio separado, tiene al menos la opción de acceso de registro para tener un registro de auditoría disponible. Separación de tareas: si el servicio de contraseñas tiene otro administrador, a una persona le resulta difícil hacer cosas que no están permitidas, o al menos existe la posibilidad de hacer un seguimiento de estas cosas.

Si usa php-fpm , puede establecer variables de entorno para cada grupo en el archivo de configuración del grupo . Esto es genial por algunas razones.

1. Los archivos de configuración del grupo php-fpm deben ser rw-r----- y ser propiedad de root:root . Por lo tanto, el usuario de php-fpm no debería poder leerlos (tenga en cuenta que el demonio padre php-fpm puede porque se genera como root y luego se bifurca a los niños) .

2. Estos archivos de configuración de la agrupación php-fpm no pueden comprometerse accidentalmente con el código fuente de la aplicación a GitHub o similares.

Aquí hay un ejemplo:

# in the php-fpm pool configuration file
env[MYSQL_PASSWORD] = somecrazylongpasswordhere

Al tratar con archivos de contraseñas, debemos ver que solo aquellos usuarios pueden acceder a los detalles de las contraseñas que "necesitan saber" eso. En su caso, las personas que tienen acceso al árbol de código, es decir, el archivo .ini, deben conocer los detalles de la base de datos y las contraseñas, ya que es posible que no tengan acceso a la sección de entorno. Si tienen acceso al árbol de códigos y al entorno, creo que tiene razón y puede dejar esos detalles en el archivo .ini, pero asegúrese de que esté fuera del directorio de contenido web.

Ahora mismo puedo pensar en esto.

Todo: siéntase libre de corregirme o agregar cualquier cosa que haya omitido.