Case studies in the field

Como se puede ver para ambos casos tambi´en se generaron las instrucciones de l´ınea de comando para implementar la pol´ıtica en la base de datos, es decir, la llamada al paquete DBMS RLS. A continuaci´on se explica para cada pol´ıtica.

Pol´ıtica ACCESS ADM POLICY protegiendo a la tabla ADMAPPL:

EXEC DBMS RLS.ADD POLICY(‘STUDENTSCH’, ‘ADMAPPL’, ‘ACCESS ADM POLICY’,‘SYSTEM’,

‘ADMISSION ACCESS PKG.UPDATE DELETE ADM’, ‘UPDATE,DELETE’,TRUE);

Esto significa cada par´ametro del paquete DBMS RLS.ADD POLICY: Par´ametro 1. Nombre del due˜no del esquema de la tabla: STUDENTSCH. Par´ametro 2. Nombre de la tabla a proteger: ADMAPPL.

Par´ametro 3. Nombre de la pol´ıtica de acceso con el que se puede identificar dentro de la base de datos: ACCESS ADM POLICY.

Par´ametro 4. Nombre del esquema due˜no de la funci´on de acceso:SYSTEM ya que el paquete que encapsula a la funci´on de acceso se cre´o con esta cuenta.

Par´ametro 5. Nombre de la funci´on de acceso: ADMISSION ACCESS PKG.UPDATE DELETE ADM. Esta funci´on ser´a la que el DBMS usar´a para iniciar el proceso de modificaci´on de queries y a su vez la protecci´on a la tabla ADMAPPL.

Par´ametro 6. Operaci´on DML contra la que se proteger´a la tablaADMAPPL:UPDATE, DELETE.

Par´ametro 7. Indicador que determina si la pol´ıtica est´a activa:TRUE. Pol´ıtica ACCESS DCS POLICY protegiendo a la tabla ADMDCSN:

EXEC DBMS RLS.ADD POLICY(‘STUDENTSCH’, ‘ADMDCSN’, ‘ACCESS DCS POLICY’,‘SYSTEM’,

‘DECISION ACCESS PKG.ACCESS DCS’, ‘INSERT,UPDATE,DELETE’,TRUE);

A continuaci´on este es el significado de cada par´ametro empleado en la imple- mentaci´on de esta pol´ıtica:

Par´ametro 1. Nombre del due˜no del esquema de la tabla: STUDENTSCH. Par´ametro 2. Nombre de la tabla a proteger: ADMDCSN.

Par´ametro 3. Nombre de la pol´ıtica de acceso con el que se puede identificar dentro de la base de datos: ACCESS DCS POLICY.

Par´ametro 4. Nombre del esquema due˜no de la funci´on de acceso:SYSTEM ya que el paquete que encapsula a la funci´on de acceso se cre´o con esta cuenta.

Par´ametro 5. Nombre de la funci´on de acceso: DECISION ACCESS PKG.ACCESS DCS. Esta funci´on ser´a la que el DBMS usar´a para iniciar el proceso de modificaci´on de queries y a su vez la protecci´on a la tablaADMDCSN.

Par´ametro 6. Operaci´on DML contra la que se proteger´a la tablaADMDCSN: INSERT, UPDATE, DELETE.

Par´ametro 7. Indicador que determina si la pol´ıtica est´a activa:TRUE.

Una vez implementadas en la base de datos, las pol´ıticas pueden ser consultadas en la vista DBA POLICIES, que existente en la base de datos; con esta vista se pueden con- sultar todas las pol´ıticas de acceso que se han dado de alta con el paquete DBMS RLS. En este punto, el control de acceso ya est´a listo en la base de datos para proteger estas tablas.

5.4.7.

Resultados del Control de Acceso Implementado en el

M´odulo de Admisiones.

En esta secci´on se apreciar´a c´omo el control de acceso protege a las tablas del m´odulo de admisiones, es decir ADMAPPL y ADMDCSN. Los resultados est´an organi- zados de manera que primero se muestra c´omo la pol´ıtica de acceso ACCESS ADM POLICY funciona para proteger a la tabla ADMAPPL y despu´es la pol´ıtica ACCESS DCS POLICY protegiendo a la tabla ADMDCSN.

Pol´ıtica de Acceso ACCESS ADM POLICY. Antes de iniciar, se citar´a de nuevo esta pol´ıtica, para efectos de recordatorio:

Los usuarios s´olo podr´an modificar la informaci´on de admisiones (tabla ADMAP- PL), si el campus para el cu´al trabajan es el mismo para el cu´al el candidato de admisi´on (futuro alumno) desea aplicar.

V´ease la siguiente situaci´on. Sup´ongase que para el candidato de admisi´on con ID 5, se captura su solicitud; esto lo lleva a cabo el usuario U10 que labora en el campus A. La solicitud tambi´en es dirigida al campus A. Dentro de la misma base de datos existe el usuario U20, que labora en el campus B, por lo tanto la informaci´on del campus A y B coexisten dentro de la misma base de datos.

Ahora, el usuario U20 desea actualizar el registro del candidato ID 5 modificando la carrera para la cu´al el candidato desea aplicar. A continuaci´on se efect´ua el c´alculo del predicado extra:

Despu´es que el usuario U20 cambia los datos y ejecuta la opci´on de guardar desde su aplicaci´on, se activa la pol´ıtica (ACCESS ADM POLICY) para el DML de UPDATE

en la tabla ADMAPPL.

La funci´on (UPDATE DELETE ADM) usada por la pol´ıtica verifica que el usuario no es administrador ni el due˜no del esquema (l´ınea 9 y 10 figura 5.8). Se inicia la construcci´on del predicado. Se sabe que elUSERID que en ese momento est´a efec- tuando la actualizaci´on es U20.

El predicado entonces, se construye as´ı:

ADMAPPL CAMPUS IN

(SELECT ACCESSUSR CAMPUS FROM ACCESSUSR

WHERE ACCESSUSR USERID = ‘U20’)

Tabla 5.5: Predicado Extra 1.1

Otro predicado es el que se genera en la base de datos por medio de la aplicaci´on, el cu´al puede tener la siguiente forma:

UPDATE ADMAPPL

SET ADMAPPL PROGRAM = :CARRERA APP WHERE ADMAPPL ID = :ID APP

AND ADMAPPL PERIOD = :PERIOD APP;

Tabla 5.6: Query Original(UPDATE)

Despu´es de que que el predicado extra (tabla 5.5) es construido, el DBMS agrega ´este como una condici´on m´as (AND) al query original (tabla 5.6). De la siguiente forma, es como se estar´a ejecutando en su totalidad la operaci´on DMLUPDATE.

UPDATE ADMAPPL

SET ADMAPPL PROGRAM = :CARRERA APP WHERE ADMAPPL ID = :ID APP

AND ADMAPPL PERIOD = :PERIOD APP (AND

ADMAPPL CAMPUS IN

(SELECT ACCESSUSR CAMPUS

FROM ACCESSUSR

WHERE ACCESSUSR USERID = ‘U20’))

Tabla 5.7: Query Original 1.1(Modificado)

Simplificando el predicado extra (tabla 5.5)

• La instrucci´onSELECTdel predicado extra trae como resultado queACCESSUSR CAMPUS

tenga el valor B, ya que en la tabla de clasificaci´on ACCESSUSR(tabla 5.2) el usuario U20 tiene asignado el campus B.

El resultado de simplificar el predicado extra (tabla 5.5) es: ADMAPPL CAMPUS IN (‘B’)

Tabla 5.8: Predicado Extra 1.2

Finalmente el query modificado (tabla 5.7) es:

UPDATE ADMAPPL

SET ADMAPPL PROGRAM = :CARRERA APP WHERE ADMAPPL ID = :ID APP

AND ADMAPPL PERIOD = :PERIOD APP (AND

ADMAPPL CAMPUS IN (‘B’))

Tabla 5.9: Query Original 1.2 (Modificado)

Con el query resultante de la tabla 5.9, la operaci´on de actualizaci´on no se lle- var´a a cabo, ya que no encontrar´a un registro en la tabla ADMAPPL con el campus B. Recordar que para este registro el campus (ADMAPPL CAMPUS) tiene el valor A, ya que el candidato de admisi´on, desea aplicar para ese campus.

Pol´ıtica de AccesoACCESS DCS POLICY. Despu´es de explicar el comportamiento de la pol´ıtica de acceso ACCESS ADM POLICY, es el turno de la pol´ıtica ACCESS DCS POLICY. Esta pol´ıtica protege a la tabla ADMDCSN contra las operaciones DML INSERT,

Solo los usuarios que pertenezcan o laboren en el campus donde el alumno solic- it´o admisi´on podr´an insertar, modificar y borrar informaci´on referente a la tabla ADMDCSN.

En esta ocasi´on se plantear´a tambi´en una situaci´on de operaci´on, para hacer m´as f´acil en entendimiento del comportamiento de la pol´ıtica ACCESS DCS POLICY. Sup´ongase que un prospecto o candidato ha aplicado para ser admitido en el campus A, y despu´es de realizar su examen de admisi´on y de ser revisada su papeler´ıa y alg´un otro requisito administrativo, llega el momento de asignarle el c´odigo de la decisi´on de admisi´on; entonces el usuario U20 intenta asignar la decisi´on de admisi´on al candidato ID 5. Seg´un la tabla de clasificaci´on (tabla 5.2) el usuario U20 pertenece al campus B, y tomando el ejemplo de la pol´ıtica anterior, la informaci´on del candidato de admisi´on con ID 5, es del campus A.

Despu´es de capturar el c´odigo de la decisi´on de admisi´on, el usuario U20 procede guargar los cambios (COMMIT) y en este momento se activa la pol´ıtica de acceso

ACCESS DCS POLICY

La pol´ıtica hace uso de la funci´on asignada a ella (ACCESS DCS) para construir el predicado. Dicha funci´on verifica (l´ınea 9 y 10 de la figura 5.9)que el usuario no sea el due˜no del esquema ni la cuenta administradora ADMINISTRATOR. Es sabido que el usuario que est´a efectuando la inserci´on es U20. Tambi´en se valida que la tabla que se est´a accesando sea ADMLDCSN (l´ınea 13 figura 5.9).

Dicho esto, el predicado construido por la funci´on es

EXISTS( SELECT 1 FROM ADMAPPL

WHERE ADMAPPL ID = ADMDCSN ID AND ADMAPPL PERIOD = ADMDCSN PERIOD AND ADMAPPL CAMPUS IN

(

SELECT ACCESSUSR CAMPUS FROM ACCESSUSR

WHERE ACCESSUSR USERID = ’U20’))

Tabla 5.10: Predicado Extra 2.1

En primera instancia, la aplicaci´on genera un predicado de este tipo:

INSERT INTO ADMDCSN

VALUES (:ID, :PERIOD, :DECISION);

Despu´es de que el predicado extra 5.10 es construido, el DBMS une ´este con el query original (5.11)construido por la aplicaci´on. La forma en que sint´acticamente el DBMS une al query original y al predicado extra cuando el DML es un INSERT, no es del todo claro, pero se propone de la siguiente manera

INSERT INTO ADMDCSN

VALUES (:ID, :PERIOD, :DECISION) ( AND

EXISTS( SELECT 1 FROM ADMAPPL

WHERE ADMAPPL ID = ADMDCSN ID AND ADMAPPL PERIOD = ADMDCSN PERIOD AND ADMAPPL CAMPUS IN

(

SELECT ACCESSUSR CAMPUS FROM ACCESSUSR

WHERE ACCESSUSR USERID = ’U20’)))

Tabla 5.12: Query Original 2.2(Modificado)

Simplificando el predicado extra 5.10.

• Primero se obtiene obtiene el atributo de clasificaci´on del usuario U20. Esta b´usqueda se hace en el ´ultimo subquery, obteniedo como resultado que U20 tiene como atributo de clasificaci´on al campus B:

SELECT ACCESSUSR CAMPUS FROM ACCESSUSR

WHERE ACCESSUSR USERID = ’U20’

• Teniedo este valor se busca dentro de la tabla ADMAPPL que exista el registro para el cu´al el ID del Alumno y el periodo para el cu´al se est´a in- tentando asignar la decisi´on de admisi´on, corresponda al campus B, que fue obtenido con anterioridad.

• Esta b´usqueda no devuelve resultado alguno, ya que el registro que corre- sponde al candidato de admisi´on con ID 5 es del campus A.

Aplicando lo anterior, el predicado extra de la tabla 5.10, quedar´ıa:

EXISTS (NULL)

Tabla 5.13: Predicado Extra 2.2

Finalmente la operaci´on DMLINSERTdel query original (modificado) de la tabla 5.12 es simplificada, dando como resultado

INSERT INTO ADMDCSN

VALUES (:ID, :PERIOD, :DECISION) ( AND

EXISTS (NULL)

)

Tabla 5.14: Query Original 2.3 (Modificado)

Como se puede apreciar, la sentencia EXISTS valida que exista alg´un dato sin importar su naturaleza, s´olo que exista; pero NULL no es un dato; NULL es la forma de representar “la nada”; por lo tanto, no se puede insertar el registro. Adem´as, este procedimiento se aplica de igual manera para las operaciones de UPDATE y DELETE

utilizando la misma pol´ıtica y el mismo c´odigo.