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.
