Ocultar Passwords a produccion.

[Aldrin Gonzalo Martoq Ahumada]

On Dec 5, 2007 1:54 PM, Asdtaker <asdtaker en gmail.com> wrote:
> Estimados, mi ultima consulta aqui fue respecto de un cliente para jabber (y
> ya vieron lo que ocurrio (y esta ocurriendo)). Finalmente, se opto por
> openfire y spark como cliente, lejos las discusiones respecto a la
> performance del modelo, ya esta implementado y camina /de pelos/. Gracias a
> todos lo que dieron sus opiniones.
>
> Esta vez, los molesto con otra cosa que me aflije. Tengo algunos servicios
> con db (mysql, db2, sql server) y existe un gran cuestionamiento: ¿como
> escondo las password (y usuarios) de las db a los programas y usuarios?. Es
> decir, pe. al configurar el acceso a mysql para un servicio web (LAMP),
> necesariamente debo configurar en un file la passwordm user y database que
> utilizare. Otro problema, y mas grande aun, en cuando tenemos aplicaciones
> cliente-servidor, con archivos de configuracion en cada cliente, o bien (en
> el caso sql server) odbc, en ese caso no existe manera de encriptar las
> password, y al menos debe conocerla el desarrollador/analista de la
> aplicacion y configurarla (digitarla) bien en el codigo (ejecutable) o en un
> archivo de configuracion. Mi problema es que necesito que estas password no
> sean conocidas por nadie, ni siquiera el admin del sistema (password
> bipartida) y el dia de mañana poder cambiarlas de manera transparente para
> los usuarios.
>
> He hecho monos, tirado lineas y buscado en san google, pero ando medio
> perdido. Espero me puedan orientar.
>
> Mis ideas me llevan a pensar que debe haber /algo/ en medio que permita la
> autenticacion, es decir:
>
> SERVER(user, pass)<:::::::::>**ALGO**<:::::::::>CLIENTE(user, _clave_)
>
> donde clave, es una llave, un id de instalacion, la ip de mi LAN, el usuario
> de dominio, etc.

Tienes un problema de arquitectura o disen~o, algunos tips te dio
Franco. Esto se resuelve implementando servicios y creando una capa de
acceso a el (bus de servicios). El bus se encarga de la seguridad,
acceso, enrutamiento, excepciones, auditoria, etc.

Puedes implementarlo con muchas tecnologias y maneras, varias ya estan
hechas. Luego, lo que le das a tu desarrollador es una API o framework
que encapsula el acceso al bus y lo mas importante, a los servicios
que tiene acceso (esto independiza la tecnologia usada). Los accesos
(permisos) los defines en el servidor o en el bus.

Cualquier otro chamullo no te asegura nada. Si creas una DLL que
"encripta" la password por otra, es lo mismo, igual estas dando full
acceso a la base de datos (basta descompilar la dll o revisar el
stream a la conexion para saber que user/pass estas usando). Si creas
una DLL que realiza el servicio, estas duplicando codigo y eso lo hace
inmantenible, la logica del servicio tiene que estar donde se provee
(en el servidor) y el cliente solo debe tener una API para accesar a
el, que depende de la tecnologia usada.


Hay muchas otras razones para implementar esta arquitectura (un unico
punto con la logica, tienes un mecanismo de auditoria, generalmente el
bus te garantiza que no se pierden los datos, permite especializar los
sistemas, integrar sistemas antiguos y mejorar la performance ya que
los servidores trabajan en base a eventos en vez de a full conexiones,
...); pero en particular resuelve tu problema de acceso a los datos,
ya que no abres de patas la base de datos, sino que solo a servicios
bien conocidos y definidos. Puedes encontrar un monton de buzzwords al
respecto, estoy buscando alguna literatura que te pueda ayudar a
entender un poco el asunto.... Creo que este link te servira:

http://www-306.ibm.com/software/info1/websphere/index.jsp?tab=landings/esbbenefits


Saludos,
-- 
Aldrin Martoq