14 respuestas en este tema

[TiammatMX]

Jóvenes, buena tarde...

Comenzando un nuevo proyecto, y ésta vez quiero implementarle un control de usuarios algo más seguro que el que siempre he usado. El típico, entra el usuario, y de acuerdo a una serie de permisos guardados en una tabla, se le permite o no acceder a la opción.

OK, a veces es lo más óptimo, pero quiero "simplificarme" un poco más la vida ésta vez. Requiero me comuniquen sus ideas de cómo implementan ustedes el control y acceso de usuarios, si quieren darme sus algoritmos o recomendaciones de componentes que implementen ésto. Trabajaré con Delphi 7 y Firebird.

Agradeciendo de antemano.

[Caral]

Hola
Yo tengo un sistema sencillo de uso.
Como mi form principal lo que tiene son botones y popupmenus, es sencillo por medio de la BD asignar que boton estara enable a que usuario.
Saludos

[Marc]

Hola.

Jóvenes, buena tarde...

Comenzando un nuevo proyecto, y ésta vez quiero implementarle un control de usuarios algo más seguro que el que siempre he usado. El típico, entra el usuario, y de acuerdo a una serie de permisos guardados en una tabla, se le permite o no acceder a la opción.

OK, a veces es lo más óptimo, pero quiero "simplificarme" un poco más la vida ésta vez. Requiero me comuniquen sus ideas de cómo implementan ustedes el control y acceso de usuarios, si quieren darme sus algoritmos o recomendaciones de componentes que implementen ésto. Trabajaré con Delphi 7 y Firebird.

Agradeciendo de antemano.

Yo no sé si me molestaría. Piensa que en Firebird no hay seguridad que  valga cuando el usuario tiene acceso físico al archivo de la base de  datos.

Por más seguridad que le pongas a una base de datos,  siempre que pueda copiar el archivo en otro servidor entonces volverá a  tener acceso total a toda la base de datos con el usuario SYSDBA -  masterkey (vía ODBC, por ejemplo).

Es por eso que yo normalmente solo pongo seguridad a nivel de la aplicación, y lo hago de la forma que comentas, con una tabla de permisos.

Saludos.

[Sergio]

Nosotros no tenemos seguridad a nivel de base de datos, como dice Marc, si tienes acceso fisico al servidor o puedes hacerte una copia de seguridad, la recuperas en un firebird recien instalado y entras con masterkey.

Asi que usamos una tabla de permisos con esta estructura: Primero dividimos el programa en zona, por ejemplo "CONTABILIDAD". En cada zona, definimos 5 tipos de posibles acciones (ver listado, ver ficha, modificar ficha, borrar ficha y crear ficha), y estos son los puntos a los que cada usuario puede o no acceder.

Pero de nuevo, al darle acceso a un usuario a una zona+ accion, damos 4 posibilidades: Permitido, denegado, chivato y explicando. Los dos primeras estan claras, las otras dos dejan registrado en una tabla especial que tal usuario a tal hora y fecha entro "sospechosamente" a la zona "editar contabilidad", e incluso incluimos en ese registro de "incidencias de permisos" a que ficha entro y que cosas modifico. Si le pusiste chivato, el usuario ni se entera, pero si pusiste explicando, se le avisa y tiene que escribir el porque lo hace.

Esto es muy flexible porque permite darle opcion a añadir clientes a alguien que no suele hacerlo, pero que si un dia no tiene a quien pedirselo, que pueda seguir trabajando dejando constancia de porque se medio salto las reglas.

Evidentmeente, todo esto se almacena en un blob de la tabla de usuarios, con los permisos de cada zona + accion codificados como comento del 1 al 4, eso si, el blob está encriptado, por si acaso.

Las claves de usuario tambien las encriptamos, si no un simple select name, password from usuarios te lo da todo en bandeja.

Luego, cada pantalla lleva pegado un componente -por herencia visual, claro- que contiene el permiso necesario para entrar, por ejemplo "CONTABILIDAD", y si el form es de una ficha, mirara los permisos de cada una de las acciones posibles y activa solo los botones que toquen: si no puedes borrar esa ficha, el boton se desactiva, por ejemplo, o si no puedes editar, los edit salen en readonly. Ah, claro, y si no puedes ver ficha, esta se niega a abrirse, eso te da una seguridad maxima, aunque no te acuerdes de desactivarle las opciones al usuario.

Todo esto lo hace el propio formcreate, ya que todos derivan de uno generico que lleva el componente con el texto "contabilidad" pegado y el codigo para recorrer los componenetes y ponerlos en readonly y esa cosas, asi que tu solo creas un form y le asignas una zona de programa y listo.

Evidentemente, solo el usuario "super" puede revisar ese log de accesos o cambiar los permisos y esas cosas "delicadas".

[look]

hola, con respecto al tema de seguridad de la base de datos, yo he empezado a implementar una idea;
esta idea consiste en crear los perfiles en tablas planas estas encriptadas con una clave, por ejemplo una tabla paradox, menciono el caso de tablas paradox solo como ejemplo sinembargo hay otras de las cuales se les puede poner una clave a la tabla para accesar a estas.
al guardar los datos del perfil de usuario en una tabla con clave se podria aunmentar la seguridad de esta sin preocuparnos por que el usuario pueda abrir la base de datos con algun administrador.

saludos amigos!

[Marc]

Hola.

hola, con respecto al tema de seguridad de la base de datos, yo he empezado a implementar una idea;
esta idea consiste en crear los perfiles en tablas planas estas encriptadas con una clave, por ejemplo una tabla paradox, menciono en caso de tablas paradox solo como ejemplo sinembargo hay otras de las cuales se les puede poner una clave a la tabla para accesar a estas.
al guardar los datos de pel perfil de usuario en una tabla con clave se podria aunmentar la seguridad de esta sin preocuparnos por que el usuario pueda abrir la base de datos con algun administrador.

saludos amigos!

El problema es que no basta con encriptar las tablas de perfiles (permisos), también tienes que encriptar todas las tablas de tu aplicación. Ya que en caso contrario, simplemente pueden ignorar las tablas de perfiles, y con un Administrador, irse directamente a ver los datos en sus respectivas tablas.

Como Firebird no lleva encriptación integrada, la tendrías que programar tu mismo, y eso me parece mucho trabajo para hacerlo para todas tus tablas.

[TiammatMX]

Marc, Sergio..., hablo de CONTROL DE ACCESO DE USUARIOS A MI APLICACIÓN. El tema de la base de datos ya está más que controlado. Gracias por su atención.

hola, con respecto al tema de seguridad de la base de datos, yo he empezado a implementar una idea;
esta idea consiste en crear los perfiles en tablas planas estas encriptadas con una clave, por ejemplo una tabla paradox, menciono en caso de tablas paradox solo como ejemplo sinembargo hay otras de las cuales se les puede poner una clave a la tabla para accesar a estas.
al guardar los datos de pel perfil de usuario en una tabla con clave se podria aunmentar la seguridad de esta sin preocuparnos por que el usuario pueda abrir la base de datos con algun administrador.

saludos amigos!

La idea es buena, parece fácil y manejable..., veremos qué más hay... 

[Delphius]

Hola,
Pues a como yo lo veo. No hay algo más simple que asociar un nro de nivel de acceso a un perfil determinado. Luego consultado este Nro se explora los menus, controles, etc que tengan en su propiedad TAG dicho valor o que esté en su rango permitido de acceso y habilitarlo.

¿Me explico? Existe una tabla Perfiles con un campo NivelAcceso, al loguearse el usuario se lee éste campo y luego se compara con los TAG de los controles. Por ejemplo:

Nivel1: Invitado
Nivel2: Usuario Limitado
Nivel3: Usuario Normal
Nivel4: Administrador
Nivel5: Super Administrador

Supongamos que accede un Usuario Normal (3), entonces todos aquellos controles con TAG menor o igual a 3 se habilitan.

Si esto no cumple con el criterio de simpleza entonces no se como se llama.
Creo que lo más adecuado sería que TU definas a que llamas "simplificarme". Porque la idea de simplicarse la vida y la de tener un control más que seguro no van en la misma línea... a mi humilde entender. Si en verdad quieres un control seguro no esperes soluciones bien simples.

Saludos,

[Rolphy Reyes]

Saludos.

@TiammatMX: Visita esta página.

[Sergio]

TiammatMX, lo que te comentaba en mi post es justame eso, el control de acceso de los usuarios a la aplicación, a que pantallas puede o no puede entrar, lo de la base de daots solo es el primer parrafo.

Delphius, el sistema que propones es demasiado simple en general, si tu aplicación permite generar facturas y consultar saldos contables, necesitas dos permisos distitnso, porque un usuario podria hacer A y no B o al reves, por eso mi sistema es tan "complicado".

[Desart]

Si me permitís entrar en el tema, yo uso un sistema parecido al de Delphius, lo he ido mejorando con el tiempo, ahora uso el tag de AcctionList, uso hasta 9 niveles y luego uso, ademas el tag 0 para usar la misma clave que en el login, para comprobar que es el usuario activo, o un número x de x caracteres, y nos solicita una clave, con este número, pido un clave y  puedo usarlo de dos maneras, 1ª), uso el mimo numero como clave solicitada, o tengo unas variables asignadas y segun el numero ha de ser la variable.


espero esto les ayude, un saludo desde Canarias.

[Delphius]

Delphius, el sistema que propones es demasiado simple en general, si tu aplicación permite generar facturas y consultar saldos contables, necesitas dos permisos distitnso, porque un usuario podria hacer A y no B o al reves, por eso mi sistema es tan "complicado".

Eso ya lo se amigo,

Por algo al final he dicho:

(...)Porque la idea de simplicarse la vida y la de tener un control más que seguro no van en la misma línea... a mi humilde entender. Si en verdad quieres un control seguro no esperes soluciones bien simples.

Saludos,

Hay controles y controles. La intención de mi post era mostrar el esquema más elemental de seguridad que se ocurrió (Si se lee supuestamente se está pidiendo algo simple). Evidentemente que esto no es viable cuando se requiere de un mejor control, y ni que decir si además debe contar con una auditoría o incluso si debe apegarse a una norma ISO.... Recuerdo de cátedra de Auditoría ¿O era en la de Seguridad? en la que el profe nos contó sobre el control de acceso de usuario... Piuff... cuando se requiere de ver la 5ta pata al gato ¡es de no terminar! Al menos se hablaba de 5 o 6 tablas para controlar entre perfiles, roles, asignación de funciones, permisos y niveles...
No tengo el borrador de la ISO con la que estudié (creería que ya se ha aprobado... si recordara el número podría darles alguna referencia). Se que lo tengo guardado... me fijo por la tarde.

Saludos,

[Marc]

Lo que comentas se parece mucho al sistema que montamos nosotros. Añado algunas anotaciones.

Asi que usamos una tabla de permisos con esta estructura: Primero dividimos el programa en zona, por ejemplo "CONTABILIDAD". En cada zona, definimos 5 tipos de posibles acciones (ver listado, ver ficha, modificar ficha, borrar ficha y crear ficha), y estos son los puntos a los que cada usuario puede o no acceder.

Pero de nuevo, al darle acceso a un usuario a una zona+ accion, damos 4 posibilidades: Permitido, denegado, chivato y explicando. Los dos primeras estan claras, las otras dos dejan registrado en una tabla especial que tal usuario a tal hora y fecha entro "sospechosamente" a la zona "editar contabilidad", e incluso incluimos en ese registro de "incidencias de permisos" a que ficha entro y que cosas modifico. Si le pusiste chivato, el usuario ni se entera, pero si pusiste explicando, se le avisa y tiene que escribir el porque lo hace.

El tema de seguridad lo hago parecido, pero en cambio los registros de actividad no los programo en la aplicación, sino que los programo en la base de datos, mediante triggers. Así cada vez que se inserta/modifica un registro, guardo la fecha/hora, persona y equipo desde el que se ha hecho el cambio (y estoy pensando en actualizar los triggers para que también se guarden los valores de los campos modificados).

La ventaja de tu sistema es que tienes más control, está muy bien esto de poder pedir explicaciones al usuario. Pero implementarlo en la base de datos tiene la ventaja de que es mucho más exhaustivo (por ejemplo, con tu sistema puedes registrar que se ha modificado un albarán, pero imagino que no guardas las líneas de albarán afectados).

Esto es muy flexible porque permite darle opcion a añadir clientes a alguien que no suele hacerlo, pero que si un dia no tiene a quien pedirselo, que pueda seguir trabajando dejando constancia de porque se medio salto las reglas.

Muy interesante .

  Luego, cada pantalla lleva pegado un componente -por herencia visual, claro- que contiene el permiso necesario para entrar, por ejemplo "CONTABILIDAD", y si el form es de una ficha, mirara los permisos de cada una de las acciones posibles y activa solo los botones que toquen: si no puedes borrar esa ficha, el boton se desactiva, por ejemplo, o si no puedes editar, los edit salen en readonly. Ah, claro, y si no puedes ver ficha, esta se niega a abrirse, eso te da una seguridad maxima, aunque no te acuerdes de desactivarle las opciones al usuario.

Aquí se nota el que soy un programador perezoso . En lugar de poner un componente visual, yo simplemente utilizo una variable definida en el formulario padre. Todos mis formularios le dan el valor correspondiente en su FormCreate (junto a otras variables que afectan al funcionamiento estándar de las fichas de datos, como el nombre de la clave primaria, etc. ...).

Saludos.

[Sergio]

Hola Marc, de nuevo hacemos las cosas de forma parecidas!

En realidad, no comente que tenemos un nivel anterior de "zona de programa", y luego la parte espcificia del programa, y finalmente las 5 acciones, asi, agrupando por zona, montamos la pantalla de definicion de permisos con una le ngueta por zona, dentro una linea por pantalla, y en 5 columnas las 5 acciones con un combo para eelgir en cada una uno de los 4 posibles niveles de acceso.

Aparte de eso, hacerlo trigger tiene el problema de que es demasiado indiscrimiinado, si una persona con plenos poderes para altas de clientes da 20 al dia, no queremos generar 20 incidencias, solo si el usuario tiene permiso "parcial" para hacerlo.

Claro que eso lo puedes hacer por firebird, pero entonces has de usar alguna tabla de sesion para saber el usuario -nuestro programa es de antes de firebird, asi que no teniamos esa opcion- y los permisos han de estar sin cifrar, en una tabla plana, lo cual no es admisible para nuestra aplicacion, por eso optamos por ujna solucion por programa, que ademas te permite darle a elegir despues de avisarle de que su accion será grabada a que cancele y no la complete, o a que escriba algo como explicación y continuar.

Tambien nos permite dejar ver la lista de clientes y que eso implique antes dar una explicacion... eso no lo puedes hacer por triggers ni dejar registrado que se entro a ver solamente.

Ademas, por programa tienes herencia, y eso te facilita muchisimo las cosas, sobre todo si solo tienes 2 tipos de pantalla: Listas y fichas. Y si ademas las dos derivan de un form generico tuyo, puedes poner alli todo el control de acceso UNA sola vez, incluido la generacion de la incidencia recogiendo datos cambiados y esas cosas... repito, en un solo punto de todas tus aplicaciones presentes y futuras.

Otra cosa que si puedes hacer por programa es usar el sistema para evitar que se pida un informe contable, que se active una opcion especifica que no va a base de datos, o incluso que el acceso al programa de un cierto usuario implique que antes tiene que explicar porque entra y que quede registrado... no tienes limitaciones.

Mas cosas que permite es, por ejemplo, que para hacer algo necesites dos o mas permisos a la vez, como editar una cosa que se ha producido y que ya esta facturada, por lo que cambiarla ahora implica tener que poder la ficha en si, y tambien tener que poder editar una factura, porque "implicitamente2 editar la una implica que se  modifique la otra.

Por ciertto, Marc, yo tambien hubiese puesto una variable, pero mi hermano trabaja conmigo y el es mas metodico que yo, que soy mas caotico y menos "object oriented" que el. El creo el sistema de herencia visual, los forms genericos de fichas y listas con todo "de fabrica" (todos los de listas llevan por defecto su propio generador de informes configurable sin que tengas que hacer nada, lo dificil es eliminar esa posibilidad en una lista concreta, de hecho nuestra aplicacion se vende SIN ningun informe, cada usuario se configura los suyos, todo un sueño) y mucas mas cosas... asl final, una nueva pantalla del estilo con su filtro, su lista con listados, su edicion de ficha mas todos los extras posibles, lleva poquisimo codigo, pero poco poco.

[Marc]

Hola Sergio.

Aparte de eso, hacerlo trigger tiene el problema de que es demasiado indiscrimiinado, si una persona con plenos poderes para altas de clientes da 20 al dia, no queremos generar 20 incidencias, solo si el usuario tiene permiso "parcial" para hacerlo.

A mi me gusta registrarlo todo. Ya no solo para que el cliente pueda consultar lo que hacen sus empleados, sino también para que no me vuelvan a salir con cosas como que los productos desaparecen solos. Ahora les puedo decir quien y cuando ha borrado ese producto.

Claro que eso lo puedes hacer por firebird, pero entonces has de usar alguna tabla de sesion para saber el usuario -nuestro programa es de antes de firebird, asi que no teniamos esa opcion- y los permisos han de estar sin cifrar, en una tabla plana, lo cual no es admisible para nuestra aplicacion, por eso optamos por ujna solucion por programa, que ademas te permite darle a elegir despues de avisarle de que su accion será grabada a que cancele y no la complete, o a que escriba algo como explicación y continuar.

Sí, tengo definida una tabla de sesiones para eso.

Nosotros ya empezamos desde el principio con Firebird (después de perder un año con Visual Basic y SQL Server, que en la época de SQL Server 7 cuando lo ponías en el ordenador de la tienda de un cliente, se comía todos los recursos y se caía el sistema). La verdad es que es una suerte no depender de código heredado y poder enfocarte en una sola plataforma.

  Tambien nos permite dejar ver la lista de clientes y que eso implique antes dar una explicacion... eso no lo puedes hacer por triggers ni dejar registrado que se entro a ver solamente.

Sí, eso me ha gustado mucho .

  Ademas, por programa tienes herencia, y eso te facilita muchisimo las cosas, sobre todo si solo tienes 2 tipos de pantalla: Listas y fichas. Y si ademas las dos derivan de un form generico tuyo, puedes poner alli todo el control de acceso UNA sola vez, incluido la generacion de la incidencia recogiendo datos cambiados y esas cosas... repito, en un solo punto de todas tus aplicaciones presentes y futuras.

Sí, lo sé. No lo decía porqué piense que vuestro sistema sea malo, yo también estuve a punto de programarlo así. Pero al final me convenció más ponerlo por triggers, por ser un poco más robusto y eficiente, y sobretodo más exhaustivo con los datos que va a grabar (cuando el formulario tiene relaciones maestro-detalle). Ambos sistemas son muy válidos, y puse la anotación solo para que vean alternativas.

    Otra cosa que si puedes hacer por programa es usar el sistema para evitar que se pida un informe contable, que se active una opcion especifica que no va a base de datos, o incluso que el acceso al programa de un cierto usuario implique que antes tiene que explicar porque entra y que quede registrado... no tienes limitaciones.

Mas cosas que permite es, por ejemplo, que para hacer algo necesites dos o mas permisos a la vez, como editar una cosa que se ha producido y que ya esta facturada, por lo que cambiarla ahora implica tener que poder la ficha en si, y tambien tener que poder editar una factura, porque "implicitamente2 editar la una implica que se  modifique la otra.

Está claro que vuestro sistema de seguridad es mejor que el mío. El mío solo permite definir a que pantallas pueden entrar, y si pueden entrar solo en modo consulta, o también para añadir/modificar. Cualquier otra opción de seguridad (quienes pueden ver precios de coste, modificar el stock, pasar presupuestos a ventas, etc. ...) la defino en una pantalla de configuración aparte, y la tengo que programar específicamente para cada formulario que tenga opciones especiales de seguridad.

NOTA: No lo he mejorado porqué en realidad no hay demasiadas opciones especiales de seguridad, y tampoco dan mucho trabajo. No cuesta nada en el FormCreate de esos formularios, consultar el nivel de Seguridad del usuario activo y habilitar/deshabilitar algunas opciones en consecuencia. Pero un día de estos lo tendría que unificar todo, como hacéis vosotros.

      Por ciertto, Marc, yo tambien hubiese puesto una variable, pero mi hermano trabaja conmigo y el es mas metodico que yo, que soy mas caotico y menos "object oriented" que el. El creo el sistema de herencia visual, los forms genericos de fichas y listas con todo "de fabrica" (todos los de listas llevan por defecto su propio generador de informes configurable sin que tengas que hacer nada, lo dificil es eliminar esa posibilidad en una lista concreta, de hecho nuestra aplicacion se vende SIN ningun informe, cada usuario se configura los suyos, todo un sueño) y mucas mas cosas... asl final, una nueva pantalla del estilo con su filtro, su lista con listados, su edicion de ficha mas todos los extras posibles, lleva poquisimo codigo, pero poco poco.

Sí, nosotros también trabajamos así y es una maravilla (si tuviera que volver a la época de Visual Basic, donde había que programarlo todo y me quedaban toneladas de bugs, entonces prefiero dejar la programación).

La programación orientada a objetos es un punto que también tengo pendiente. Utilizo muchísimo la herencia visual, pero en cambio muy pocas veces me genero nuevas clases (nunca veo la necesidad de crear una clase, soy de la generación de programación procedural y es difícil cambiar hábitos tan arraigados).