Control de acceso a programas. Adaptación a la LOPD.

Saludos a todos.

Hace poco me tuve que enfrentar al desafío de adaptar una aplicación mía hecha con Velneo a la normativa de la LOPD ( Ley Orgánica de Protección de Datos, en España ). Esta ley, exige entre otras muchas cosas un control de acceso a las aplicaciones, los válidos y los no válidos, guardando en un fichero Log tanto los intentos de acceso exitosos como los fallidos, con una serie de datos como la IP desde donde se realizó el acceso, el nombre de usuario y contraseña, la fecha y la hora.

También es obligado el cambio de contraseñas de acceso cada X tiempo, poder hacer listados de accesos, llevar un control de quién accede a la información catalogada como de nivel máximo, cambiante según el objetivo de cada empresa…..

El vServer nos ofrece la aplicación del Historial del Servidor, pero no se adapta por completo  a las exigencias de la Ley. Por ello, tras varias reuniones con el asesor, me dí cuenta de que el control de acceso lo tenía que hacer yo mismo desde el mismo mapa de la aplicación.

Después de meditarlo un tiempo, me puse manos a la obra para resolver todos los requerimientos y me dispongo a compartir mi experiencia con vosotros.

El esquema de tablas que planteo es el siguiente:

Esquema de tablas para control de accesos a aplicación

1. Tabla USUARIOS: maestra. En ella se guarda el nombre del usuario, su contraseña y el nivel de acceso a la aplicación
2. Tabla PERMISOS.: maestra. En ella se guarda a qué tiene permiso el usuario. Partí del ejemplo de acceso a menús que pueden tener los distintos usuarios de la aplicación.
3. Tabla FLAGS: histórica de las dos anteriores. Siguiendo la forma de llamar a los permisos en Velneo, le puse el mismo nombre que la función  fUserFlag. Tiene además un campo booleano para indicar si el usuario tiene permiso o no.
4. Tabla HCONT: histórica de USUARIOS. Permite llevar un histórico de los cambios de contraseña. Se guarda en ella la fecha de entrada en vigor de la contraseña. Se pueden ampliar el número de campos para indicar la fecha de caducidad, avisos…..
5. Tabla BOARDS: maestra. En ella se registran las tablas de la aplicación. Hay que introducir los datos a mano, lo siento. Es una lástima que el API de Velneo no sea del todo satisfactorio como para evitar estas cosas y hacerlas de una manera más elegante.
6. Tabla BOARD USERS: histórica de USUARIOS  y de BOARDS.  Con campos booleanos para poder establecer unas operaciones mínimas como lectura, escritura, modificación y borrado. En este ejemplo no he puesto nada de esta tabla, pues excedería el objetivo de la entrada.
7. Tabla ACCESOS: maestra. Usada para llevar un registro de los intentos de acceso a la aplicación y si estos han sido correctos o fallidos.
8. Tabla LOG: histórica. El log propiamente dicho y que servirá de cajón de sastre donde registrar todo lo que queramos , desde un alta hasta una modificación pasando por la ejecución de un proceso.
9. Tabla MEM: maestra en memoria. Me sirve de base para pedir usuario y contraseña con un formulario.

Tabla histórica del LOG

Para llevar a cabo el control de acceso a la aplicación, en el menú AUTOEXEC he puesto el proceso siguiente como proceso On-init, con el que se controla el usuario, la contraseña, se hacen las comprobaciones, se registra el acceso o intento de acceso y se da el privilegio establecido al usuario.

Proceso control de usuario 2

Con ello guardamos en variables globales en memoria los datos de código de usuario $USER-CODE$ e  ip de acceso $USER IP$ que nos dan toda la información necesaria para dar de alta registros tanto en la tabla ACCESOS  como en la tabla LOG, usando la función siguiente, desde donde se estime oportuno.

A modo de ejemplo, he llamado a esta función desde dos procesos anteriores al botón Aceptar de dos formularios, el de alta de Usuarios y desde el alta de Permisos, pero se puede usar desde un trigger o proceso de tabla o desde cualquier otro proceso ( pérdida de foco, anterior o posterior a botón con acción aceptar o eliminar o….)

En el menú PRINCIPAL  he puesto dos opciones que no disparan ninguna acción, aunque podrían, pero que tienen condición de visibilidad utilizando una función a la que pasándole los parámetros de _usuario y _menu , busca en la tabla FLAGS si el usuario tiene o no autorización a ver ese menú u opción de menú.

¿Está el usuario autorizado a ver esta opción?

Con ella controlamos  la condición de visibilidad de una opción del menú ya que nos retorna el campo AUTORIZADO (booleano) para ese usuario y esa opción.

No he puesto en el ejemplo que os podéis descargar, las opciones y objetos que se utilizan para el control de acceso a tablas con la tabla BOARD-USERS. Si un hombre tiene hambre, no le des sólo un pez, enséñale a pescar.

Un saludo y espero que os guste.

P.D: el usuario por defecto que he puesto tiene los datos

• Nombre de usuario: superusuario
• Contraseña: hola