On Feb 11, 2016 7:38 AM, "Rafael Cantos Villanueva" <raf...@rafaelcantos.es> wrote: > > Saludos > > Rafa > > > > El 11/02/2016 a las 12:28, alparkom . escribió: >> >> El día 11 de febrero de 2016, 8:01, Luis Felipe Tabera Alonso >> <taber...@unican.es> escribió: >>> >>> On Thursday 11 February 2016 07:33:51 alparkom . wrote: >>>> >>>> Explicado de forma simple; si hago una conexión en Java, el archivo >>>> .java tendrá los datos de conexión (en caso de usar MariaDB, se >>>> debería escribir en el .java la dirección del servidor, el usuario de >>>> MariaDB, la contraseña del mismo y el puerto usado)... entonces, que >>>> pasa si descompila dicho el .class que genera Java? >>> >>> >>> Lo estás haciendo mal, si el programa tiene todos esos datos 'tal cual', te va >>> a dar igual el lenguaje de programación, compilado o no. Un usuario malicioso >>> podrá obtenerlos. ¿Quién se supone que tiene acceso a la BD? ¿Solo usuarios? >>> ¿Solo el programa? El usuario/programa que acceda a la BD ¿Puede hacer con >>> ella lo que quiera? ¿debería poder? >>> >> >> Se supone que C++ es compilado a código máquina, y es imposible >> obtener el código de este lenguaje una vez compilado por lo que no >> podrían obtener los datos. > > > Te equivocas, yo te lo vuelvo a repetir. Da igual que el programa sea compilado o no, se puede descompilar igualmente y acceder a los datos. >
+1 >> >> Se supone que el software debería tener acceso a la base de datos. Si >> puede hacer lo que quiera es un sí, aunque dudo importe demasiado la >> respuesta a esta pregunta. >> >> Entonces como lo hacen softwares como algunos Adobe, donde debes >> iniciar sesión para ocupar varios de sus productos? Con HTTP? > > > Como te indicaba en otra respuesta, centra la seguridad en la base de datos y el servidor. Una opción es esta, enviar por htp, o mejor aún por https, emplear sockets, etc, una solicitud de acceso al servidor, con un usuario y contraseña. Desde el servidor, se realiza una conexión a la base de datos, con los datos almacenados de dicha conexión en el servidor, y autenticar al usuario. Una vez que lo has autenticado, puedes devolver un tokken de conexión que valide las comunicaciones realizadas entre ese usuario y el servidor a través de la aplicación. Esto, si te fijas, es igual que cuando accedes a un servicio web introduciendo tu usuario y contraseña desde un navegador web. > Si lo que quieres es una aplicación cliente-servidor, donde el cliente se ejecute desde la estación como una aplicación instalable, y además requieres (tus argumentos tendrás para ello) que se use conexiones a la Base de Datos mediante un único usuario, mi recomendación es mediar con una capa entre el cliente y la BD que exponga la interfaz que deseas que conozca el cliente. Dicha capa se encargará de la funcionalidad, la autenticación y la seguridad entre otros, y allí implementar el protocolo que más convenga. La comunicación con la base de datos quedará bajo este "Middleware", y podrás protegerle mediante firewall u otras medidas, dependiendo de tus recursos y arquitectura. Varios lenguajes tienen facilidades para crear estos componentes, exponiendo mediante "buses de servicio" u otros elementos, un API. Puedes desarrollar además uno propio, pero todo dependerá del alcance propuesto para la aplicación, como por ejemplo, hacer uso de estándares como SOA. Estas tecnologías no son exclusivas de los servicios WEB, aunque su uso este más extendido en ese campo. Con este componente mediando entre tus clientes y el modelo de datos, puedes desacoplar el desarrollo de este, haciendo uso incluso de un lenguaje de programación distinto al usado en el servidor, y disponer de clientes para diferentes sistemas operativos, dispositivos o situaciones como requerimientos de accesibilidad. Siempre encontrarás problemas de seguridad a resolver, pero todo dependerá de los requerimientos exigidos y hasta donde estés dispuesto a ceder y tolerar.
