php - seguridad - reporting services pide usuario contraseña

Dónde almacenar las credenciales de inicio de sesión de la base de datos para una aplicación PHP

Question

Tenemos un servidor de desarrollo y un servidor en vivo con diferentes detalles de conexión a la base de datos (nombre de usuario, contraseña, etc.).

Actualmente estamos almacenando AMBOS detalles de la conexión de la base de datos en un archivo initial.php y se selecciona uno si está presente una declaración DEFINE. Agregamos manualmente esa declaración DEFINE en nuestro servidor en vivo.

¿Es este un enfoque seguro? ¿Cuáles son los enfoques mejores / alternativos para administrar la seguridad de la conexión DB?

Una consecuencia de esto es que cada desarrollador puede ver los detalles de conexión de la base de datos y eso es un poco arriesgado ...

Answer 1

¿Es este un enfoque seguro?

Depende de tu definición de seguro.

cada desarrollador puede ver los detalles de conexión de la base de datos

AFAIK, aparte de usar el nombre de usuario / contraseña / base de datos por defecto en el archivo php.ini, ese problema es bastante inevitable (y usar los valores predeterminados significa que automáticamente tienen acceso a la base de datos).

Supongo que podría usar diferentes archivos de inclusión cifrados usando el codificador Zend con una función que devuelve identificadores de bases de datos, y configure el alcance y los permisos para diferentes archivos, pero es complicado aislar el código PHP de los datos subyacentes. Otro enfoque sería restringir todo a los servicios web e implementar un modelo de permisos extendido en el nivel de servicio web.

Answer 2

Es un poco difícil proteger su aplicación contra los desarrolladores que la están usando. Mis sugerencias serán cargar todas las contraseñas de un archivo de configuración y crear dos entornos separados: uno para el desarrollo y otro para el servidor de producción. Dé acceso total a los desarrolladores a la máquina en desarrollo y, cuando se traslade al servidor de producción, la aplicación se alimentará con la configuración de producción que se almacenará solo en esa máquina y, por lo tanto, será inaccesible para la mayoría de los desarrolladores. Este tipo de seguridad es más un proceso y debe definir varios pasos, como quién tiene acceso a las máquinas de producción y quién está haciendo la publicación ... etc.

Answer 3

Utilizo un archivo .ini, que luego se analiza a través de parse_ini_file(INI_FILENAME_HERE, true) . Este archivo no está bajo control de versión (como lo son los archivos php- / template- / whatever-files). Entonces en cada máquina creo ese archivo (.database.ini) para la respectiva conexión a la base de datos.

Ejemplo de archivo .ini para una conexión MySQL, usando PDO:

[db_general]
driver = "mysql"
user = "USERNAME"
password = "PASSWORD"

; DSN
; see http://www.php.net/manual/en/pdo.drivers.php
[db_data_source_name]
host = "localhost"
port = 3306
dbname = "DATABASE_NAME"

; specify PDO-options, provide keys without PDO::
; see http://www.php.net/manual/en/pdo.drivers.php
[db_pdo_options]
MYSQL_ATTR_INIT_COMMAND = "SET NAMES utf8"

; specify more PDO-attributes, provide keys without PDO::
; see http://php.net/manual/en/pdo.setattribute.php
[db_pdo_attributes]
ATTR_CASE = "PDO::CASE_LOWER"
ATTR_ERRMODE = "PDO::ERRMODE_EXCEPTION"
ATTR_EMULATE_PREPARES = false

Como no se puede usar :: dentro de .ini-file-keys, use la constant(''PDO::'' . $iniKey) en su código para obtener las constantes PDO deseadas.

Answer 4

Recientemente tuve que lidiar con este problema, y ​​lo que hice fue crear dos nuevos usuarios de bases de datos. El primero no tenía ningún privilegio, aparte de los privilegios de lectura en tablas en su propio esquema. El segundo tenía privilegios de inserción para una tabla de "carga" que estaría rellenando con mi código.

El usuario sin privilegios recibió una tabla de "credenciales" en su esquema, que contenía las credenciales y la contraseña del usuario de inserción (junto con algunos otros parámetros que necesitaba para mi aplicación). Por lo tanto, el código solo contenía las credenciales para el usuario sin privilegios, estaba codificado y se cambiaba periódicamente, y en tiempo de ejecución buscaba las credenciales necesarias para hacer las inserciones. La búsqueda se realizó detrás de nuestro firewall, entre servidores, por lo que no era algo que un extraño pudiera espiar.

No me preocupaban los desarrolladores, sino los intrusos y los usuarios avanzados, que teóricamente podían obtener acceso al servidor web y echar un vistazo a los archivos ini. De esta forma, solo los desarrolladores y los DBA pueden espiar (y todos nos conocemos). Cualquier otra persona tendría que averiguar cómo consultar la base de datos, descubrir qué SQL usar, descubrir cómo ejecutar el código ... No es imposible, pero ciertamente es un dolor gigantesco en varios pasos en el trasero y no lo vale.

Muy seguro, en teoría, de todos modos ...

Answer 5

Otro enfoque sería configurar variables de entorno en la máquina en vivo y desarrollo y acceder a ellas desde el código ... No sé mucho php, pero en python eso sería:

import os
password = os.environ(''DB_PASS'')

Esto le permite distribuir cuentas y contraseñas según sea necesario para los desarrolladores y servidores implementados. Dependiendo de sus permisos en esa máquina, se podría evitar que los desarrolladores tengan acceso a la contraseña en vivo.