Pilot interview

Estas pol´ıticas son restricciones o condiciones que se definen en base a las necesi- dades de qu´e datos o informaci´on se desea proteger; a su vez las pol´ıticas son definidas por los usuarios administradores o responsables de la operaci´on de los procesos de la organizaci´on y tambi´en por los administradores de la base de datos. Un ejemplo de c´omo se define una pol´ıtica es el siguiente:

Pol´ıtica de Zona. Los usuarios de la zona occidente de la organizaci´on, s´olo pueden consultar los datos de las ventas diarias (tabla VENTAS DIARIAS) hechas en su zona.

Esto significa que se est´a protegiendo a la tablas donde se encuentra la informaci´on de las ventas diarias, o sea la tabla VENTAS DIARIAS, contra los accesos efectuados por usuarios de la zona occidente. Puede existir m´as de una pol´ıtica de acceso, depen- diendo de las necesidades de protecci´on; de hecho en este trabajo de tesis se propone hacer una pol´ıtica de acceso por tabla que se desee proteger.

Funci´on de Acceso. Una vez definida la pol´ıtica, es implementada en la base de datos. La implementaci´on consta del desarrollo de una funci´on (c´odigo) la cu´al se en- cargar´a de validar el condicionamiento propuesto en el enunciado de la pol´ıtica de acceso y determinar´a si un usuario puede consultar los datos del modelo de ventas.

La funci´on de acceso ser´a generada por el usuario SYSTEM. En la secci´on 4.6 correspondiente a la generaci´on de c´odigo, se apreciar´a c´omo los c´odigos de las fun- ciones de acceso son generados. As´ı mismo es importante recalcar que los c´odigos de las funciones de acceso vistas en este cap´ıtulo, tambi´en ser´an generados.

Esta funci´on, llamada funci´on de acceso, es asignada a cada tabla que se desea proteger y a su vez se especifica contra qu´e operaci´on DML se proteger´a. Por ejemplo para la pol´ıtica de zona, se crea una funci´on de acceso que es asignada a la operaci´on deSELECTde la tabla VENTAS DIARIAS del modelo de ventas, as´ı cuando un usuario consulte esta tabla, la funci´on de acceso tomar´a el query que se hace a dicha tabla y

verificar´a si es un usuario de la zona occidente. Al validar esto, la funci´on de acceso inicia el proceso de modificaci´on del query, agregando un predicado extra al query original. Por ejemplo, el usuario de base de datosFRODRIGUEZque es de la zona occidente, desea consultar la tablaVENTAS DIARIAS(que est´a protegida por la pol´ıtica de zona) y ejecuta el siguiente query:

SELECT * FROM VENTAS DIARIAS

Entonces lo que sucede inmediatamente de que inicia la ejecuci´on del query es lo muestra la figura 4.2:

Figura 4.2: Validaciones Ejecutadas por la Funci´on de Acceso.

Siguiendo el proceso descrito en la figura 4.2, despu´es de que el usuarioFRODRIGUEZ escribe su query, al ejecutarlo inician las validaciones:

1. El DBMS detecta que la tabla est´a siendo accesada es VENTAS DIARIAS y que est´a protegida por el control de acceso. Al determinar esto, el DBMS hace el llamado de forma autom´atica a la funci´on de acceso para iniciar el proceso de modificaci´on de queries.

2. La funci´on de acceso verifica y valida las condiciones descritas por la pol´ıtica de acceso.

a) La pol´ıtica de acceso (pol´ıtica de zona) condiciona a que la tabla VEN- TAS DIARIAS del modelo de datos de ventas, que sea consultada por usuar- ios de la zona occidente, s´olo obtengan informaci´on de su zona.

3. Despu´es de validar las condiciones de la pol´ıtica, la funci´on de acceso determina dos posibilidades:

a) Si el usuario no es de zona occidente, el query es ejecutado de manera normal. b) En caso contrario, la funci´on de acceso lleva a cabo lo siguiente:

i. Guarda y bloquea moment´aneamente el query a ejecutar por el usuario FRODRIGUEZ.

ii. Crea el predicado extra ZONA=‘Occidente’.

iii. Este predicado es retornado por la funci´on de acceso y autom´atica- mente se agrega al query original; entonces el query resultante a ejecu- tar es: SELECT * FROM VENTAS DIARIAS (WHERE ZONA=‘Occidente’). Co- mo se puede observar el predicado extra ZONA=‘Occidente’est´a comple- tado con la palabra reservada WHERE; esto se ha hecho para un mejor entendimiento de c´omo se puede visualizar la modificaci´on del query, adem´as de que el predicado extra funciona como las condiciones escritas en esta secci´on (WHERE) y esta representaci´on es m´as sencilla. De hecho, si en el query ya existiera una o m´as condiciones en elWHERE, el predicado extra se representar´ıa antecedido por la palabra reservada AND.

iv. Debido a que la condici´on ZONA=‘Occidente’ es agregada, el query so- lo devolver´a registros que corresponden a la zona del usuario FRO- DRIGUEZ, es decir, la zona occidente.

Como se puede apreciar la pol´ıtica de acceso y la modificaci´on de queries est´an muy relacionadas con la funci´on de acceso que es la que lleva a cabo el trabajo de de validaciones y construcci´on del predicado extra. Esta funci´on est´a compuesta y construida por sentencias PLSQL est´andar o sea estructuras de control de flujo (IF, WHILE, LOOP, FOR) de asignaci´on, declaraci´on de variables y de tipos b´asicos (VARCHAR2, NUMBER). Pueden existir m´as de una funci´on de acceso, ya que una puede ser creada para satisfacer ciertas validaciones de un grupo de pol´ıticas de acceso, mismas que pueden referirse s´olo a tablas de un modelo y otra funci´on de acceso para satisfacer las condiciones de pol´ıticas que refieran a tablas de otros modelos; de hecho es recomend- able que la funci´on de acceso sea creada dentro de un paquete (package) para fines de administraci´on de objetos, es decir para agruparlas e identificarlas sin ning´un problema.

Para la generaci´on de la funci´on de acceso se usar´a un esqueleto con sentencias pre- definidas. Esto se visualizar´a de mejor manera en la secci´on 4.6 que es la de generaci´on de c´odigo, pero se aclara que no existe restricci´on en cuanto al nombre de la funci´on (y del paquete), ni en cuanto al n´umero de funciones de acceso que se puedan desarrollar para satisfacer las necesidades de protecci´on de datos de la o las organizaciones. Como restricci´on, la funci´on de acceso se genera as´ı:

Debe de recibir dos par´ametros de entrada:

• Schema. Este par´ametro recibir´a como entrada el nombre del due˜no del esquema al que pertenece la tabla que se va a proteger. El due˜no del esquema es un usuario de la base de datos.

• Object. Este par´ametro recibe el nombre de la tabla que se est´a accesando. La funci´on es creada con el usuario SYSTEMde la base de datos (ver secci´on 4.6). Estos dos par´ametros deben de llamarse as´ı. Con ellos se identificar´a qui´en es el due˜no y qu´e tabla est´a siendo accesada por medio de un query y a su vez se puede, codi- ficadamente en la funci´on, saber qu´e validaciones de la pol´ıtica aplicar a qu´e tabla (esto se podr´a apreciar m´as claramente en las secciones en que se desarrollan los ejemplos).

Implementaci´on de la Pol´ıtica de Acceso. Ya se mencionaron ciertas caracter´ısti- cas y la forma de operar de la funci´on de acceso, a continuaci´on se mostrar´a c´omo se relaciona con las tablas del modelo de datos para que las mismas queden protegidas contra los accesos. Para este fin, se usa el paquete DBMS RLS que est´a embebido en el manejador de la base de datos (DBMS Oracle 9i R2); con este paquete se le especifica al DBMS qu´e tabla va a ser protegida, qu´e funci´on de acceso se usar´a y contra qu´e tipo de operaciones DML (es decir SELECT, INSERT, DELETE, UPDATE) que sean efectuadas por el usuario.

Este paquete es parte del RDBMS (para este caso Oracle 9i R2 Enterprise Edition) y se usa para poder crear la pol´ıtica de acceso en la base de datos. La tarea b´asica de este paquete es informar al RDBMS que una tabla ser´a protegida contra alg´un DML que se efect´ue sobre ella; a su vez tambi´en se le informa que para protegerla se usar´a cierta funci´on (funci´on de acceso) que se encargar´a de efectuar la modificaci´on de queries.

Figura 4.3: Funci´on del Paquete DBMS RLS.

En la figura 4.3, est´a resumida la tarea del paquete DBMS RLS. Tiene como en- tradas la tabla a proteger, los DML’s para los cuales la pol´ıtica actuar´a y la funci´on de acceso que ser´a la encargada de la modificaci´on de queries y el nombre con el que se identificar´a la pol´ıtica dentro de la base de datos. Estas entradas son tomadas por el paquete, asoci´andolas e indicando al RDBMS que se crear´a una pol´ıtica de acceso (llamada como lo indique la entrada) almacen´andola en la base de datos y que a su vez esta pol´ıtica se activar´a cuando se ejecute alg´un DML sobre la tabla a proteger, ejecutando autom´aticamente la funci´on de acceso pas´andole como par´ametros el due˜no del esquema al que pertenece la tabla y el nombre de la tabla a proteger. Por lo tanto en este punto ( con la ejecuci´on de la funci´on de acceso), se inicia la modificaci´on de queries, es decir, la protecci´on de la tabla.

Regresando a la implementaci´on de la pol´ıtica, la l´ınea de comando se tiene que ejecutar dentro de una sesi´on de base de datos con la cuenta system o la cuen- ta administradora que se designe para el manejo del control de acceso. Este paquete (DBMS RLS), se encarga de especificarle al DBMS, que se ha creado una pol´ıtica de acceso dentro de la base de datos. A su vez especifica qu´e funci´on de acceso va a usar para proteger a la tabla que se est´a especificando. Usando como ejemplo la pol´ıtica de zona, la tablaVENTAS DIARIASyFUNC ACCESS como nombre de la funci´on de acceso, esta es la forma en c´omo se implementa la pol´ıtica de acceso en la base de datos:

EXEC DBMS RLS.ADD POLICY(‘VENTAS’, ‘VENTAS DIARIAS’, ‘ZONA’,‘SYSTEM’,

‘FUNC ACCESS’,‘SELECT’,TRUE);

V´ease a continuaci´on los par´ametros que recibe para poder un mejor entendimien- to:

Par´ametro 1. Este par´ametro recibe el nombre del due˜no del esquema de la tabla que se va a proteger, para este caso es VENTAS.

Par´ametro 2. Este recibe el nombre de la tabla que se va a proteger:VENTAS DIARIAS. Par´ametro 3. Es el nombre con el cu´al se identifica la pol´ıtica de acceso a im- plementar. En este caso se asign´o el nombre de ZONA para hacer referencia a la pol´ıtica de zona mencionada con anterioridad.

Par´ametro 4. Es el due˜no de la funci´on de acceso. En este caso es la cuentaSYSTEM. Par´ametro 5. El nombre de la funci´on de acceso, que para ilustrar este ejemplo se usa el nombre FUNC ACCESS.

Par´ametro 6. Aqu´ı se especifican las operaciones DML para las cu´ales va a aplicar la pol´ıtica. Recuerde que las operaciones DML son SELECT, INSERT, UPDATE y DELETE. La pol´ıtica de zona especifica que se proteja en la operaci´on de consul- ta, por lo tanto, el valor que recibir´a este par´ametro es SELECT. Si la pol´ıtica aplicara para m´as de una operaci´on DML, el valor del par´ametro ser´ıa las opera- ciones DML separadas por comas, por ejemplo: ’SELECT,UPDATE’.

Par´ametro 7. Este par´ametro determina si la pol´ıtica de acceso estar´a activa.TRUE significa que est´a activa, FALSE lo contrario. Para este caso, la pol´ıtica debe de estar activa.

Despu´es de ejecutar esta l´ınea de comando, la pol´ıtica de acceso es creada y la fun- ci´on de acceso ahora est´a asignada a la tabla para protegerla cada vez que un usuario haga una operaci´on de SELECT sobre ella. Internamente, en la base de datos, lo que sucede es que la pol´ıtica de acceso se queda residente en el ´area del sistema o dic- cionario de datos, en espera, para detectar el momento en que se efect´ue un SELECT sobre la tabla protegida; en ese momento la pol´ıtica de acceso avisa al DBMS para que efect´ue la ejecuci´on de la funci´on de acceso, pas´andole autom´aticamente como par´amet- ros, el nombre del due˜no de la tabla y el nombre de la tabla que se est´a protegiendo (recuerde que estos dos par´ametros son los que la funci´on de acceso necesita para su funcionamiento). De esta manera la funci´on inicia las validaciones correspondientes y el proceso de modificaci´on de queries antes mencionado.

As´ı es como se protegen las tablas, y esta l´ınea de comando se tiene que correr para cada tabla que se desee proteger, adecuando los par´ametros.

Hasta el momento se han visto dos de los tres componentes esenciales del control de acceso, as´ı como sus caracter´ısticas y formas de operar. Estos componentes son:

Modificaci´on de queries. Pol´ıticas de acceso.

Tambi´en se ha podido observar que van de la mano, ya que las condiciones que la pol´ıtica de acceso defina, ser´an la base para que el proceso de modificaci´on de queries construya el predicado extra. En adici´on, se ha podido apreciar que el elemento fun- damental de estos dos componentes es la funci´on de acceso; ´esta es la encargada de llevar a cabo las validaciones y construcci´on del predicado extra que intervienen en la operaci´on de las pol´ıticas de acceso y de la modificaci´on de queries respectivamente.

Ahora se describir´a el ´ultimo componente del control de acceso: El atributo de clasificaci´on de informaci´on y usuarios.