v7. Control del acceso a la base de datos

Precedentes

Debido a la ley de protección de datos, a la implantación de controles de calidad y seguridad, cada vez es mayor la necesidad de delimitar dentro de la empresa, quien accede a cada información, y quien puede modificar ciertos datos.

Sobre todo cuando el perfil de la empresa es medio / alto, estos requerimientos de seguridad se tornan exigencias.

Por lo tanto las aplicaciones deben facilitar el establecer múltiples niveles de acceso a la información. Y las bases de datos no pueden permitir que cualquier usuario pueda hacer consultas indiscriminadas de los datos.

Ejemplo

Una ficha de clientes contendrá información con distinto nivel de relevancia:

1. Datos personales. Que podrán ver cualquier persona de la empresa, pero modificar solo, por ejemplo el departamento comercial.
2. Condiciones de venta. Estos datos es muy posible que solo lo puedan ver el departamento comercial, pero solo modificarlo el director comercial.
3. Datos de riesgo. Estos podrían ser vistos por departamento comercial y administrativo, pero solo modificados por este último.

Al igual que este ejemplo se podrían exponer de cualquier información que se maneje (documentos de compra, venta, etc...)

Estos controles se pueden realizar dentro de la aplicación, pero si no se pueden implementar dentro de la propia base de datos, nos encontramos con que toda la seguridad analizada es saltada en el momento que se accede desde fuentes externas, mediante ODBC u otros medios (vDataClient en v7).

Hay que tener en cuenta, que cada vez es mas frecuente el acceder desde estos medios, y además por personal variado, para, por ejemplo, hacer mailings.

Necesidades

Por lo tanto se hace necesario, poder crear perfiles de acceso, tanto a nivel de tablas como de campos, de forma que un usuario a la hora de hacer un "SELECT" de una tabla solo vea los campos a los que tiene acceso, independientemente del medio por el que realiza la consulta.

Y sería bueno que estos controles se puediesen definir desde la propia solución (aplicación), por el usuario, sin tener que hacerlo desde el vServer.

Es decir, que se puedan crear dentro del programa tablas de perfiles de acceso y el usuario asignado como administrador pueda decidir las tablas/campos que puede ver cada usuario.

Funciones APIVEL para v7

Explicación de las mejoras que creo deberían tener las APIVEL de Velneo en la v7.

Estas nos permitirían crear exportaciones / importaciones a XML, así como tener mas flexibilidad para hacer generadores de listados o de exportaciones definidas por el cliente.

Los cambios serían:

Nueva función: Get identificador de campo por número

Sería como la función de la imagen, pero que devuelva el identificador.

Además en esta función, ¿en que idioma devolverá el nombre?.

Esto nos permitiría, por ejemplo, crear una exportación de la tabla a XML del tipo:

De forma que la etiqueta sea el Identificador, y no el nombre que cambiará según el idioma.

<registro><id>1 </id><name>NOMBRE</name></registro>

Modificar: Get numero de campo por identificador

Poder introducir el identificador, no como un desplegable, si no con una variable.

De esta forma podremos incorporar el fichero XML anterior, obteniendo el identificador del tag.

Condición activo/visible en v7

En algunos objetos (formulario, rejilla) tenemos las siguientes propiedades, que considero deberían extenderse a muchos otros:

Objetos visuales, donde deberían estar: Acciones, Imprescindible poder activar o desactivar acciones según el usuario, menús
Y sobre todo en:
Tablas y campos de tabla
¿Que nos permitiría tener estar propiedades en estos objetos?
Sobretodo nos daría un control en el acceso a los datos desde cualquier medio (vDataclient, ODBC,...), pudiendo el programador establecer los controles que considere oportunos de acceso dependiente del usuario que se identifique, esto no nos es posible hacerlo utilizando el estilo “privado”, puesto que nos condiciona el hacerlo a través del servidor, no de la aplicación, y nos limitan las condiciones, al no poder utilizar información del proyecto.
Al poder controlar estas condiciones mediante variables – fórmulas del programa, tenemos toda la flexibilidad para establecer los perfiles de acceso a la información.
Ejemplos:
Tabla, condición visible: Tabla de estadísticas de venta, nadie podría acceder a esta tabla (es como si no existiera para él) si su usuario, no cumple la condición de visibilidad, con lo que a través de ODBC no podría obtener esta información.
Campo, condición visible: impedir ver campos como riesgo, a ciertos usuarios.
Campo, condición activo: Poder configurar a nivel de datos que usuarios modifican que datos. A ciertos niveles de empresa, es muy común que datos de una misma tabla sean mantenidos por unos usuarios, y otros solo los puedan ver, pero nunca modificar (ejemplo condiciones de venta).

Con las propiedades a nivel de formulario, rejilla, podemos controlarlo, pero, tenemos un gran agujero de seguridad en el momento que acceden a los datos por otros medios, y es algo que será muy común. Por lo tanto estableciendo estas reglas a nivel de datos (parte izquierda de v6), la aplicación quedará robusta.
Por otra parte, con definirlos aquí, ya sería suficiente, sin tener que hacerlo es cada objeto visual.