4.5. Ejemplos
4.5.3. Ejemplo Complejo
En el ejemplo de la secci´on anterior se mostr´o b´asicamente c´omo se protegi´o la tablaDIRECCIONEScontra operaciones de consulta, requerimiento definido en la pol´ıtica SELECT DIRECCIONES. En esta secci´on se mostrar´a c´omo se protege a las tablas contra las otras operaciones DML, o sea,INSERT, DELETE yUPDATE, usando el mismo ambiente definido en la secci´on pasada y expandiendo el modelo de datos para que pueda aprecia- rse de mejor manera. Para este ejemplo tambi´en se seguir´an los pasos para implementar el control de acceso.
Identificaci´on del Atributo de Clasificaci´on. Debido a que se estar´a trabajando con el mismo ambiente y el modelo de datos, el atributo seleccionado es de igual manera el departamento (DEPTO).
Definici´on de las Pol´ıticas de Acceso. En este caso se agregar´an dos pol´ıticas m´as, que a su vez, son requerimientos que la compa˜n´ıa identific´o para cubrir sus necesidades de protecci´on de informaci´on; las pol´ıticas son:
Pol´ıticaACCESO PROYECTOS. Los usuarios del departamento de ventas s´olo pueden consultar y modificar informaci´on de la tablaPROYECTOS, ´unicamente cuando dicha informaci´on se refiera al departamento de ventas.
Pol´ıtica ACCESO PROYECTO EMPLEADO. Los usuarios del departamento de ventas s´olo pueden consultar y modificar informaci´on de la tabla PROYECTO EMPLEADO, ´
unicamente cuando dicha informaci´on se refiera al departamento de ventas. Estas pol´ıticas ser´an analizadas m´as adelante, ya que con el entendimiento del modelo de datos y de los requerimientos a los que se refieren las pol´ıticas de acceso, ser´an divididas al momento de su implementaci´on en la base de datos, para un mejor entendimiento.
Modelo de Datos Antes de iniciar con la implementaci´on del control de acceso, v´ease la figura 4.7 que describe un modelo de datos m´as complejo que es mostrado en la secci´on del ejemplo simple.
Figura 4.7: Modelo de Datos - Ejemplo Complejo.
En este modelo se pueden apreciar siete tablas, de las cu´ales seis est´an relacionadas con la tablaDEPARTAMENTO:
TablaDIRECCIONES. La relaci´on de esta tabla fue mostrada en el ejemplo anterior. Tabla EMPLEADO. Esta tabla contiene la informaci´on concerniente a los emplead- os que de la empresa. La relaci´on existente entre esta tabla y la tablaDEPARTAMETO est´a construida por la llave for´anea de la tabla EMPLEADO en el campoEMPLEADO DEPTO. La relaci´on es de 1:N, de la tabla DEPARTAMENTO aEMPLEADO, respectivamente. Lo
que significa que para los valores que pueda tomar el campoEMPLEADO DEPTOdebe corresponder a alguno de los que tenga la llave primeria de la tablaDEPARTAMENTO, es decirDEPARTAMENTO ID.
Tabla DEPENDIENTES. Esta tabla describe a los dependientes econ´omicos del em- pleado y no tiene una relaci´on de llave for´anea con la tabla DEPARTAMENTO, pero se puede obtener a qu´e departamento corresponde usando la relaci´on que ex- iste con la tablaEMPLEADO construida con el campo DEPENDIENTES SSN como llave for´anea hacia la tabla EMPLEADO haciendo referencia al campoEMPLEADO SSN. Esta relaci´on tambi´en es de 1:N siendo la tabla padre, EMPLEADO.
Tabla DEPTO LOC. En esta tabla se encuentra la informaci´on del lugar en donde se localizan los departamentos. La tabla est´a relacionada tambi´en directamente con la tabla DEPARTAMENTO por medio de una llave for´anea creada a partir del campo DEPTO LOC DEPTO que hace referencia al campo DEPARTAMENTO DEPTO. De nueva cuanta la tablaDEPARTAMENTOes la tabla padre en esta relaci´on, que es 1:N.
Tabla PROYECTOS. En esta tabla se guarda la informaci´on de proyectos de la compa˜n´ıa. La relaci´on que guarda con la tabla DEPARTAMENTO, es tambi´en por medio de una llave for´anea definida en PROYECTOS DEPTO que se refiere al campo DEPARTAMENTO DEPTO, en la tablaDEPARTAMENTO. La tabla padre contin´ua siendo la tabla DEPARTAMENTO, dentro de la relaci´on 1:N.
TablaPROYECTO EMPLEADO. En esta tabla se guardan los empleados que est´an asig- nados a un proyecto. Esta tabla no guarda una relaci´on directa con la tabla DEPARTAMENTO, pero se puede determinar el departamento, usando la relaci´on que existe con la tablaPROYECTOS, ya que la llave for´anea existente enPROYECTO EMPLEADO (campo PROYECTO EMPLEADO NUM) hace referencia a la tabla PROYECTOS (campo PROYECTOS NUM). En esta ocasi´on la tabla padre esPROYECTOS, teniendo una relaci´on 1:N.
Se debe aclarar que el nombre del due˜no del esquema al que pertenecen las tablas PROYECTOS y PROYECTO EMPLEADO esESQUEMA2.
Creaci´on de la Tabla de Clasificaci´on. Una vez que se explic´o el modelo de datos, se procede a crear la tabla de clasificaci´on. En este caso la tabla de clasificaci´on ser´a la misma que se us´o en el ejemplo anterior, es decir CLASIFICA USUARIO.
Templates de Especificaci´on de las Pol´ıticas de Acceso. Antes de entrar a la descripci´on de las funciones de acceso, se muestran los templates de especificaci´on de las pol´ıticas de accesoACCESO PROYECTOS y ACCESO PROYECTO EMPLEADO:
Pol´ıtica: ACCESO PROYECTOS
Tabla a proteger: PROYECTOS Due~no tabla a proteger: ESQUEMA2 Atributo de Clasificaci´on: DEPTO
Operaciones en las que aplica: SELECT, INSERT, UPDATE, DELETE Tabla de clasificaci´on: TABLA CLASIFICACION
Tabla 4.6: Template de Especificaci´on de la Pol´ıticaACCESO PROYECTOS
Pol´ıtica: ACCESO PROYECTO EMPLEADO Tabla a proteger: PROYECTO EMPLEADO
Due~no tabla a proteger: ESQUEMA2 Atributo de Clasificaci´on: DEPTO
Operaciones en las que aplica: SELECT, INSERT, UPDATE, DELETE Tabla de clasificaci´on: TABLA CLASIFICACION
Funci´on de Acceso. A continuaci´on se mostrar´an los c´odigos generados las dos pol´ıticas de acceso. Para cada una se gener´o su respectiva funci´on de acceso; en primer lugar se analizar´a el c´odigo generado para la pol´ıtica de acceso ACCESO PROYECTOS. En la figura 4.8 se encuentra el c´odigo generado.
1 CREATE OR REPLACE PACKAGE PROTECCION_PROYECTOS IS
2 FUNCTION PROYECTOS_DMLS(SCHEMA IN VARCHAR2, OBJECT IN VARCHAR2) RETURN VARCHAR2; 3 END PROTECCION_PROYECTOS;
4 /
5 CREATE OR REPLACE PACKAGE BODY PROTECCION_PROYECTOS IS
6 FUNCTION PROYECTOS_DMLS(SCHEMA IN VARCHAR2, OBJECT IN VARCHAR2) RETURN VARCHAR2 IS 7 PREDICATE VARCHAR2(2000);
8 BEGIN
9 IF SCHEMA = SYS_CONTEXT(’USERENV’,’SESSION_USER’)
10 OR SYS_CONTEXT(’USERENV’,’SESSION_USER’) = ’ADMINISTRATOR’ THEN 11 PREDICATE := ’1 = 1’;
12 ELSE
13 IF OBJECT = ’PROYECTOS’ THEN
14 PREDICATE := OBJECT||’_DEPTO IN (SELECT DEPTO
15 FROM CLASIFICA_USUARIO
16 WHERE USERID = SYS_CONTEXT(’’USERENV’’,’’SESSION_USER’’)))’; 17 END IF;
18 END IF;
19 RETURN PREDICATE; 20 END;
21 END PROTECCION_PROYECTOS;
Figura 4.8: Funci´on de Acceso PROYECTOS DMLS
En el c´odigo de la figura 4.8, se gener´o usando el template de especificaci´on de la tabla 4.6 y tambi´en decidi´o generarlo con el nombre del paquete PROTEC- CION PROYECTOS y con el nombre de la funci´on de acceso PROYECTOS DMLS. A continuaci´on se explica el c´odigo generado. En el c´odigo de la figura 4.8, se deci- di´o generarlo con el nombre del paquete PROTECCION PROYECTOS y con el nom- bre de la funci´on de acceso PROYECTOS DMLS. A continuaci´on se explica el c´odigo generado.
De las l´ıneas 1 a 3 (figura 4.8), se puede apreciar la creaci´on de la cabecera del paquete y en la l´ınea 2 est´a la declaraci´on de la funci´on de acceso PROYEC- TOS DML.
Las siguientes l´ıneas consta de la declaraci´on del cuerpo del paquete. En la l´ınea 6 se puede apreciar la declaraci´on de la funci´on de acceso nuevamente, pero ahora servir´a para la construcci´on del cuerpo de la funci´on. En la l´ınea 7, figura 4.8, se hace la declaraci´on de la variable PREDICATE que alojar´a al predicado extra. Entre las l´ıneas 9 y 10 de la misma figura, se verifica que si el usuario que est´a in- tentando acceder a la tabla a proteger (PROYECTOS), es un usuario admin- istrador o el due˜no del esquema al que pertenece la tabla.
• Como ya se mencion´o anteriormente, un usuario administrador es aquel al que se le permite tener acceso completo a las tablas de los modelos.
• El valor del par´ametro SCHEMA es el que describe al due˜no del esquema al que pertenece la tabla, para este caso PROYECTOS, por lo tanto, con este par´ametro se puede saber si el usuario que est´a accediendo a la tabla prote- gida es el due˜no del esquema.
• Recordar que con la sentencia SYS CONTEXT(’USERENV’,’SESSION USER’) se puede saber el usuario que est´a conectado y tratando de acceder a la tabla a proteger; es decir, es el USERID de la sesi´on del usuario.
En la l´ınea 11 (figura 4.8) se est´a dando el valor a la variablePREDICATE de 1=1. Esto significa que si el usuario que est´a intentando acceder ala tabla PROYECTOS es un usuario administrador o el due˜no del esquema al que pertenece esta tabla, el predicado extra contendr´a una condici´on v´alida y har´a que el query original se ejecute sin ning´un problema.
Si el usuario no es ni el due˜no del esquema de la tabla ni un usuario administrador, entonces se dispone a construir el predicado extra. En la l´ınea 13 se hace la validaci´on de que si el objeto que se est´a accediendo es la tabla PROYECTOS y si es as´ı, se construye el predicado extra.
Entre las l´ıneas 14 y 16 de la figura 4.8, se observa que la variablePREDICATEtoma como valor el predicado extra construido, mismo que en la l´ınea 19 ser´a retornado y autom´aticamente agregado al query original.
Ahora se procede a listar el c´odigo que se gener´o para la pol´ıtica de acceso AC- CESO PROYECTO EMPLEADO. Este c´odigo puede ser visto en la figura 4.9:
1 CREATE OR REPLACE PACKAGE PROTECCION_PROYECTO_EMPLEADO IS 2 FUNCTION PROYECTO_EMPLEADO_DMLS(SCHEMA IN VARCHAR2,
OBJECT IN VARCHAR2) RETURN VARCHAR2; 3 END PROTECCION_PROYECTO_EMPLEADO;
4 /
5 CREATE OR REPLACE PACKAGE BODY PROTECCION_PROYECTO_EMPLEADO IS 6 FUNCTION PROYECTO_EMPLEADO_DMLS(SCHEMA IN VARCHAR2,
OBJECT IN VARCHAR2) RETURN VARCHAR2 IS 7 PREDICATE VARCHAR2(2000);
8 BEGIN
9 IF SCHEMA = SYS_CONTEXT(’USERENV’,’SESSION_USER’)
10 OR SCHEMA = SYS_CONTEXT(’USERENV’,’SESSION_USER’) = ’ADMINISTRATOR’ THEN 11 PREDICATE := ’1 = 1’;
12 ELSE
13 IF OBJECT = ’PROYECTO_EMPLEADO’ THEN 14 PREDICATE := ’EXISTS(
15 SELECT 1
16 FROM PROYECTOS
17 WHERE PROYECTOS_NUM = PROYECTO_EMPLEADO_NUM
18 AND {PROYECTOS_DEPTO IN
19 (
20 SELECT DEPTO
21 FROM CLASIFICA_USUARIO
22 WHERE USERID = SYS_CONTEXT(’’USERENV’’,’’SESSION_USER’’)))’; 23 END IF;
24 END IF;
25 RETURN PREDICATE; 26 END;
27 END PROTECCION_PROYECTO_EMPLEADO;
Figura 4.9: Funci´on de Acceso PROYECTO EMPLEADO DMLS
En el c´odigo de la figura 4.9, se decidi´o generarlo con el nombre del paquete PROTECCION PROYECTO EMPLEADO, con el nombre de la funci´on de acceso PROYECTO EMPLEADO DMLS y usando el template de especificaci´on visto en la tabla 4.7. A continuaci´on se explica el c´odigo de la funci´on PROYECTO EMPLEADO DMLS.
Como se puede apreciar, las primeras 6 l´ıneas de la figura 4.9, se est´a especificando la cabecera del paquete y la construcci´on del mismo, y en ambos se incluye a la funci´on de acceso PROYECTO EMPLEADO DMLS.
En la l´ınea 7, se aprecia la declaraci´on de la variblePREDICATE, que contendr´a al predicado extra.
En las l´ıneas 9 y 10 (figura 4.9), se valida el caso de que si el usuario que est´a inten- tando acceder a la tabla a proteger (PROYECTO EMPLEADO), es un usuario administrador o el due˜no del esquema al que pertenece la tabla.
• Recuerde que un usuario administrador es aquel al que se le permite tener acceso completo a las tablas de los modelos.
• El valor del par´ametroSCHEMAes el que describe al due˜no del esquema al que pertenece la tabla, para este caso PROYECTO EMPLEADO, por lo tanto, con este par´ametro se puede saber si el usuario que est´a accediendo a la tabla protegida es el due˜no del esquema.
• Recordar que con la sentencia SYS CONTEXT(’USERENV’,’SESSION USER’) se puede saber el usuario que est´a conectado y tratando de acceder a la tabla a proteger; es decir, es el USERID de la sesi´on del usuario.
En la l´ınea 11 (figura 4.9) se est´a dando el valor a la variablePREDICATEde 1=1. Es- to significa que si el usuario que est´a intentando acceder ala tablaPROYECTO EMPLEADO es un usuario administrador o el due˜no del esquema al que pertenece esta tabla, el predicado extra contendr´a una condici´on v´alida y har´a que el query original se ejecute sin ning´un problema.
Si el usuario no es ni el due˜no del esquema de la tabla ni un usuario admin- istrador, entonces se dispone a construir el predicado extra. En la l´ınea 13 se hace la validaci´on de que si el objeto que se est´a accediendo es la tabla PROYEC- TO EMPLEADO y si es as´ı, se construye el predicado extra.
Entre las l´ıneas 14 y 22 de la figura 4.9, se observa la construcci´on del predicado extra. Aqu´ı como se puede notar, el predicado extra es un poco m´as complejo que los vistos hasta ahora. Esto se debe a que la tabla PROYECTO EMPLEADO, no contiene dentro de su estructura al atributo de clasificaci´on DEPTO, pero el proceso de generaci´on de c´odigo es lo suficientemente inteligente para determinar que mediante la tabla PROYECTOS existe una relaci´on de integridad referencial con PROYECTO EMPLEADO, y debido a que la tabla PROYECTOS si con tiene el atributo de clasificaci´on en su estructura, es usada para poder construir el predicado extra y proteger a la tabla PROYECTO EMPLEADO.
Finalmente, en la l´ınea 25, el predicado extra es retornado y autom´aticamente agregado al query original.
Esta explicaci´on se aprecia muy vaga, pero m´as adelante en la secci´on de resul- tados, se podr´a notar c´omo es que funciona y aplica el control de acceso en estas dos tablas.
Protecci´on de las Tablas Involucradas seg´un la Pol´ıtica. Ahora es el mo- mento para implementar la protecci´on de las tablas PROYECTOS y PROYECTO EMPLEADO. De la misma manera en como se hizo en el ejemplo anterior, se usar´a el paquete DBMS RLS para implementar el control de acceso en la base de datos, especificando que las tablas PROYECTOS y PROYECTO EMPLEADO estar´an protegidas por las pol´ıticas de
accesoACCESO PROYECTOSyACCESO PROYECTO EMPLEADO, respectivamente. As´ı que se im- plementar´a en primer lugar la pol´ıtica ACCESO PROYECTOS. Como parte del ejemplo, el due˜no de las tablas de la informaci´on sobre proyectos ser´a llamadoESQUEMA2; entonces, las l´ıneas de comando mostradas en esta secci´on ser´an ejecutadas dentro de una sesi´on de base de datos con el usuario SYSTEM.
Pol´ıtica ACCESO PROYECTOS protegiendo a la tabla PROYECTOS:
EXEC DBMS RLS.ADD POLICY(‘ESQUEMA2’, ‘PROYECTOS’, ‘ACCESO PROYECTOS’,‘SYSTEM’,
‘PROTECCION PROYECTOS.PROYECTOS DMLS’, ‘SELECT,INSERT,UPDATE,DELETE’,TRUE);
Estos son los valores de los par´ametros empleados en el paqueteDBMS RLS.ADD POLICY Par´ametro 1. Nombre del due˜no del esquema de la tabla: ESQUEMA2.
Par´ametro 2. Nombre de la tabla a proteger: PROYECTOS.
Par´ametro 3. Nombre de la pol´ıtica de acceso con el que se puede identificar dentro de la base de datos:ACCESO PROYECTOS.
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:PROTECCION PROYECTOS. PROYECTOS DMLS. 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 tablaPROYECTOS.
Par´ametro 6. Operaci´on DML contra la que se proteger´a la tabla PROYECTOS: SELECT,INSERT,UPDATE,DELETE.
Par´ametro 7. Indicador que determina si la pol´ıtica est´a activa:TRUE.
Pol´ıticaACCESO PROYECTO EMPLEADO protegiendo a la tabla PROYECTO EMPLEADO:
Ahora toca el turno a la pol´ıtica ACCESO PROYECTO EMPLEADO para ser implementada.
EXEC DBMS RLS.ADD POLICY(‘ESQUEMA2’, ‘PROYECTO EMPLEADO’, ‘ACCESO PROYECTO EMPLEADO’,‘SYSTEM’,
‘PROTECCION PROYECTO EMPLEADO.PROYECTO EMPLEADO DMLS’, ‘SELECT,INSERT,UPDATE,DELETE’,TRUE);
Par´ametro 1. Nombre del due˜no del esquema de la tabla: ESQUEMA2. Par´ametro 2. Nombre de la tabla a proteger: PROYECTO EMPLEADO.
Par´ametro 3. Nombre de la pol´ıtica de acceso con el que se puede identificar dentro de la base de datos:ACCESO PROYECTO EMPLEADO.
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: PROTECCION PROYECTO EMPLEADO. PROYECTO EMPLEADO DMLS. 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 tablaPROYECTO EMPLEADO. Par´ametro 6. Operaci´on DML contra la que se proteger´a la tablaPROYECTOS EMPLEADO: SELECT,INSERT,UPDATE,DELETE.
Par´ametro 7. Indicador que determina si la pol´ıtica est´a activa:TRUE.
Hasta este punto, el control de acceso para proteger a las tablas PROYECTOS y PROYECTO EMPLEADO est´a implementado y listo para actuar en la base de datos. A con- tinuaci´on, la secci´on de resultados mostrar´a c´omo se comporta el control de acceso al proteger estas tablas.