5.4. Implementaci´on del Control de Acceso
5.4.6. Protecci´on de las Tablas Involucradas seg´ un las Pol´ıticas de Acceso
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 tablaADMAPPL.
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.