Desarrollo de Aplicaciones
Joe Pecarr
09 de Abril del 2005
Estamos desarrollando un proyecto inform谩tico en el entorno Oracle y deseamos intercambiar criterios acerca de:
Primero, acceso de la aplicaci贸n a la BD a trav茅s de un solo usuario y N sessiones por los usuarios de la aplicaci贸n, segundo, N usuarios de BD uno por cada usuario de la aplicaci贸n, Tercero, esquema h铆brido. Agradeceremos cualquier sugerencia, gracias de antemano.
Primero, acceso de la aplicaci贸n a la BD a trav茅s de un solo usuario y N sessiones por los usuarios de la aplicaci贸n, segundo, N usuarios de BD uno por cada usuario de la aplicaci贸n, Tercero, esquema h铆brido. Agradeceremos cualquier sugerencia, gracias de antemano.
jc3000
09 de Abril del 2005
Bueno, referente a tu pregunta te cuento. Yo recomiendo 1 usuario de BBDD y N de aplicaci贸n
Yo he dise帽ado todo el tema de usuarios / seguridad de una aplicaci贸n que est谩 hecha en Developer 6i y lo que tenemos es un usuario de BBDD y N usuarios de aplicaci贸n. Al abrir la pantalla de entrada, automaticamente se conecta por debajo a la BBDD y tienes que introducir tu cuenta de usuario / contrase帽a. En base a eso, se activan una serie de restricciones. Estas cuentas de usuario / contrase帽as est谩n en la correspondiente tabla y est谩n encriptadas para que nadie pueda ver el contenido real. Estos datos que est谩n encriptados no pueden ser desencriptados
Tenemos 1 perfil x usuario y las restricciones las hacemos por perfiles o por usuarios.
Lo tenemos desde el nivel mas bajo ( un bot贸n por ejemplo ) hasta el nivel mas alto ( que se pueda o no entrar a una pantalla ).
Es complicado de dise帽ar y de mantener, ya que en cada modificaci贸n, cambio 贸 implementaci贸n nueva hay que tener en consideraci贸n todo esto para que por ejemplo, un usuario que solo tiene derechos a consultar alg煤n tipo de datos no pueda actualizarlos.
Pero si se monta bien tienes control total sobre todos los usuarios, las veces que entran en la aplicaci贸n, que han hecho, si han actualizado datos, si los han borrado , desde que ordenador lo han hecho , el tiempo que han tenido abierta la aplicaci贸n , etc,etc etc etc. Todo esto se lleva a las correspondientes tablas de auditoria a la que solo tienen acceso unas pocas personas y esos accesos a su vez est谩n auditados y solo pueden ser revisados por el admin de la aplicaci贸n.
Estamos estudiando ahora tambi茅n la viabilidad de llevar el control hasta para una simple consulta. Todo esto por las leyes de protecci贸n de datos.
Yo he dise帽ado todo el tema de usuarios / seguridad de una aplicaci贸n que est谩 hecha en Developer 6i y lo que tenemos es un usuario de BBDD y N usuarios de aplicaci贸n. Al abrir la pantalla de entrada, automaticamente se conecta por debajo a la BBDD y tienes que introducir tu cuenta de usuario / contrase帽a. En base a eso, se activan una serie de restricciones. Estas cuentas de usuario / contrase帽as est谩n en la correspondiente tabla y est谩n encriptadas para que nadie pueda ver el contenido real. Estos datos que est谩n encriptados no pueden ser desencriptados
Tenemos 1 perfil x usuario y las restricciones las hacemos por perfiles o por usuarios.
Lo tenemos desde el nivel mas bajo ( un bot贸n por ejemplo ) hasta el nivel mas alto ( que se pueda o no entrar a una pantalla ).
Es complicado de dise帽ar y de mantener, ya que en cada modificaci贸n, cambio 贸 implementaci贸n nueva hay que tener en consideraci贸n todo esto para que por ejemplo, un usuario que solo tiene derechos a consultar alg煤n tipo de datos no pueda actualizarlos.
Pero si se monta bien tienes control total sobre todos los usuarios, las veces que entran en la aplicaci贸n, que han hecho, si han actualizado datos, si los han borrado , desde que ordenador lo han hecho , el tiempo que han tenido abierta la aplicaci贸n , etc,etc etc etc. Todo esto se lleva a las correspondientes tablas de auditoria a la que solo tienen acceso unas pocas personas y esos accesos a su vez est谩n auditados y solo pueden ser revisados por el admin de la aplicaci贸n.
Estamos estudiando ahora tambi茅n la viabilidad de llevar el control hasta para una simple consulta. Todo esto por las leyes de protecci贸n de datos.