Ejemplo Simple

En esta secci´on se muestra c´omo act´ua el control de acceso, sobre un requerim- iento el cu´al consta de proteger a una tabla en la operaci´on SELECT. Para lograr este cometido, la implementaci´on del control de acceso estar´a basada en los cinco pasos que se mencionaron en la secci´on anterior. Es momento de iniciar con los pasos para la implementaci´on del control de acceso.

Identificaci´on del Atributo de Clasificaci´on. Como se puede observar, la com- pa˜n´ıa basa su operaci´on por departamentos, entonces, el atributo seleccionado es de- partamento (DEPTO).

Definici´on de las Pol´ıticas de Acceso. La compa˜n´ıa decide implementar una pol´ıtica de acceso, de acuerdo a sus necesidades; en este caso la compa˜n´ıa define el siguiente requerimiento como una pol´ıtica de acceso:

Pol´ıtica SELECT DIRECCIONES. Los usuarios del departamento de ventas, s´olo pueden consultar informaci´on concerniente a direcciones de los empleados de di- cho departamento.

Para empezar a visualizar mejor el panorama de lo que se va a proteger, v´ease la figura 4.4 que describe un sencillo modelo de datos conteniendo una de las tablas que entrar´a al control de acceso para satisfacer a la pol´ıticaSELECT DIRECCIONES.

En este peque˜no modelo, se puede verificar que la tabla DIRECCIONES tiene una relaci´on de integridad referencial con la tabla DEPARTAMENTO. Como se puede apreciar, cada tabla tiene una llave primaria y la tabla DIRECCIONES tiene tambi´en, una llave

Figura 4.4: Modelo de datos - Ejemplo Simple.

for´anea que es DIRECCION DEPTO. Esta llave es la que relaciona a ambas tablas, ya que los valores que pueda tomar DIRECCION DEPTO debe de corresponder a alguno de los que tenga la llave primaria de la tabla DEPARTAMENTO, es decir DEPARTAMENTO ID . Esta relaci´on es 1:N y la tabla DEPARTAMENTO es la tabla padre de DIRECCIONES.

Para este ejemplo, la tabla DEPARTAMENTO, contiene los siguientes valores: Departamento Depto Departamento Desc

A Ventas

B RH

C Sistemas

Tabla 4.3: Tabla DEPARTAMENTO

Como la tablaDEPARTAMENTOmuestra aquellos existentes en la organizaci´on, ser´a us- ada para clasificar la informaci´on, por el atributoDEPTO.

Creaci´on de la Tabla de Clasificaci´on. Es momento de crear la tabla de clasifi- caci´on, que identificar´a a los usuarios por departamento. Las siguientes l´ıneas de co- mando, crear´an la tabla en la base de datos; para esto se usar´a una sesi´on de base de datos con el usuario SYSTEM, que para este ejemplo, ser´a el encargado de implementar el control de acceso (el nombre de la tabla es CLASIFICA USUARIO).

CREATE TABLE CLASIFICA USUARIO( USERID VARCHAR2(30) NOT NULL, DEPTO VARCHAR2(4) NOT NULL, CONSTRAINT PK ACCESSUSR PRIMARY KEY(USERID,DEPTO) )

Una vez creada la tabla, se debe de llenar con la informaci´on de los usuarios y de los departamentos a los que pertenecen. La tabla 4.4 muestra c´omo queda la tabla de clasificaci´on con datos.

USERID DEPTO

U1 A

U2 C

U3 B

Tabla 4.4: Tabla de Clasificaci´on (CLASIFICA USUARIO)

En este momento, ya se pueden identificar qu´e usuarios pertenecen o est´an asig- nados a qu´e departamento; por ejemplo, el usuario U1 est´a asignado al departamento A (Ventas) y el usuario U2 est´a asignado al departamento B (Recursos Humanos o RH). Despu´es de conocer el atributo y la tabla de clasificaci´on, se define el template de especificaci´on de la pol´ıtica de acceso SELECT DIRECCIONES en la tabla :

Pol´ıtica: SELECT DIRECCIONES Tabla a proteger: DIRECCIONES

Due~no tabla a proteger: ESQUEMA1 Atributo de Clasificaci´on: DEPTO Operaciones en las que aplica: SELECT

Tabla de clasificaci´on: CLASIFICA USUARIO

Tabla 4.5: Template de Especificaci´on de la Pol´ıticaSELECT DIRECCIONES

Antes de continuar, se hace la aclaraci´on del due˜no de la tabla a proteger; para este ejemplo se tomar´a como nombre ESQUEMA1.

Funci´on de Acceso. Es hora de crear la funci´on de acceso; para su creaci´on, la funci´on estar´a encapsulada en un paquete llamado ACCESO DEPTO, y su c´odigo ser´a gen- erado e implementado autom´aticamente con la cuenta SYSTEM y usando el template de la pol´ıtica SELECT DIRECCIONES visto en la tabla 4.5. A continuaci´on se muestra el c´odigo que se gener´o para crear dicha funci´on de acceso.

1 CREATE OR REPLACE PACKAGE ACCESO_DEPTO IS

2 FUNCTION F_SELECT(SCHEMA IN VARCHAR2, OBJECT IN VARCHAR2) RETURN VARCHAR2; 3 END ACCESO_DEPTO;

4 /

5 CREATE OR REPLACE PACKAGE BODY ACCESO_DEPTO IS

6 FUNCTION F_SELECT(SCHEMA IN VARCHAR2, OBJECT IN VARCHAR2) RETURN VARCHAR2 IS 7 PREDICATE VARCHAR2(2000);

8 BEGIN

9 IF SYS_CONTEXT(’USERENV’,’SESSION_USER’) = ’ADMINISTRADOR’ OR 10 SCHEMA = SYS_CONTEXT(’USERENV’,’SESSION_USER’) THEN

11 PREDICATE := ’1 = 1’; 12 ELSE

13 IF OBJECT = ’DIRECCIONES’ 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 ACCESO_DEPTO;

Figura 4.5: Funci´on de Acceso - Ejemplo Simple. La explicaci´on del c´odigo es como sigue:

Entre las l´ıneas 1 y 3 de la figura 4.5 se tiene la creaci´on del encabezado del paquete, que a su vez en la l´ınea 2 est´a la declaraci´on de la funci´on de acceso F SELECT, con sus respectivos par´ametros SCHEMA y OBJECT. Esta funci´on retorna un valor tipoVARCHAR2, que a la postre, ser´a el predicado extra.

La siguiente parte del paquete consta de la creaci´on del cuerpo d el mismo. Aqu´ı se desarrolla de igual manera el cuerpo de la funci´onF SELECT. Aqu´ı se puede apreciar en la l´ınea 7 (figura 4.5) la declaraci´on de la variablePREDICATE que contendr´a el predicado extra.

Entre las l´ıneas 9 y 10 (figura 4.5), se verifica algo muy importante dentro de las funciones de acceso; aqu´ı se valida si el usuario que est´a intentando accesar a la tabla protegida (en este caso DIRECCIONES), es un usuario administrador o el due˜no del esquema al que pertenece la tabla.

• Un usuario administrador, es una especie de super usuario, el cu´al es capaz de tener acceso completo a las tablas de los modelos. La definici´on de qui´en es un usuario administrador es responsabilidad de la organizaci´on.

• El valor del par´ametro SCHEMA es el que describe al due˜no del esquema al que pertenece la tabla, por lo tanto, con este par´ametro se puede saber si el usuario que est´a intentando accesar a la tabla protegida, es el due˜no del esquema.

• Con la sentencia SYS CONTEXT(’USERENV’,’SESSION USER’) se puede saber qu´e usuario conectado, est´a tratando de accesar a la tabla protegida. Para simplificar el proceso, de ahora en adelante, esta sentencia ser´a sustituida por el USERIDdel usuario empleado en cada ejemplo.

La l´ınea 11 (figura 4.5), est´a dando el valor a la variablePREDICATEde 1 = 1. Esto significa, que si el usuario que est´a intentando accesar a la tabla DIRECCIONES es un usuario administrador o el due˜no del esquema al que pertenece esta tabla (par´ametroSCHEMA), el predicado extra contendr´a una condici´on v´alida y har´a que el query original se ejecute sin ning´un problema, pr´acticamente sin modificaci´on. Esto se decidi´o implementar as´ı por razones de operabilidad, ya que por lo menos el due˜no del esquema de la tabla debe tener acceso a ella sin restricci´on.

Suponiendo que el usuario que est´a accesando a la tabla DIRECCIONES no es un usuario administrador ni el due˜no del esquema, entonces se dispone a construir el predicado extra. En la l´ınea 13(figura 4.5) se hace la validaci´on si el objeto que se est´a siendo accesado es la tablaDIRECCIONES, si es as´ı entonces se inicia con la construcci´on del predicado extra.

Entre las l´ıneas 14 y 16 de la figura 4.5, se puede visualizar el predicado extra construido, mismo que en la l´ınea 19 ser´a retornado y autom´aticamente agregado al query original.

Entre estas l´ıneas (14 y 16 figura 4.5), se puede observar la sentencia OBJECT

||’ DEPTO...’ esta sentencia refiere a la caracter´ıstica de poder reusar el c´odigo de esta funci´on y aplicar a otras tablas se sean protegidas usando el atributo de clasifi- caci´on DEPTO, es decir, para este caso la tabla que se est´a protegiendo es la tabla DIRECCIONES y como OBJECT es el par´ametro usado en la funci´on de acceso paraidentificar la tabla a proteger, la sentencia OBJECT||’ DEPTO...’, se puede re- ducir a DIRECCIONES DEPTO, por lo tabto se est´a haciendo referencia al campo DIRECCIONES DEPTO (de la tabla DIRECCIONES) el cual cotiene el atributo de clasificaci´on DEPTO; de esta maner se est´a asegurando la utilizaci´on de dicho atribu- to. Pero entonces, ¿qu´e pasar´ıa si se tratara de usar la misma funci´on de acceso para proteger contra el DML SELECT (que es el descrito en este ejemplo) a otra tabla usando el mismo atributo de clasificaci´on? Sup´ongase que otra tabla a proteger es PUESTO y que dicha tabla contiene dentro de su estructura el atributo depto (cam- pos PUESTO DEPTO); entonces se puede usar la misma funci´on de acceso pero con la diferencia de que el par´ametro OBJECT tendr´a ahora el valor PUESTO (recuerde que al hacer la llamada autom´atica el RDBMS a la funci´on de acceso, pasa tambi´en el valor del del due˜no del esquema en el par´ametro SCHEMA y el nombre de la tabla en el par´ametro OBJECT). De esta manera la sentencia OBJECT||’ DEPTO’ puede ser reducida por PUESTO DEPTO, por lo tanto se asegura que se usa el atributo de clasificaci´on para proteger esta tabla. Despu´es de visualizar y explicar el c´odigo de la funci´on de acceso, se procede al siguiente paso (es importante recordar que los c´odigos de las funciones de acceso son generados).

Protecci´on de las Tablas Involucradas seg´un la Pol´ıtica. Hasta aqu´ı se ha con- struido las partes bases para el control de acceso; es el momento de implementarlo en la base de datos y proteger las tablas. Para este ejemplo, se proteger´a la tablaDIRECCIONES. Como se mostr´o en la secci´on anterior, en este paso se usa el paquete DBMS RLS, que es el encargado de especificarle a la base de datos que la tabla DIRECCIONES entra en el control de acceso, protegi´endola seg´un lo especificado en la pol´ıtica de acceso SELECT DIRECCIONES. Como parte del ejemplo, el due˜no de la tabla DIRECCIONES ser´a llamado comoESQUEMA1. La siguiente l´ınea de comando se debe de realizar en una sesi´on de base de datos conectado como el usuarioSYSTEM.

EXEC DBMS RLS.ADD POLICY(‘ESQUEMA1’, ‘DIRECCIONES’, ‘SELECT DIRECCIONES’,‘SYSTEM’,

‘ACCESO DEPTO.F SELECT’,‘SELECT’,TRUE);

Para quedar m´as claro, se describir´an los par´ametros usados enDBMS RLS.ADD POLICY, bas´andose en la explicaci´on de la secci´on anterior.

Par´ametro 1. Es el nombre del due˜no del esquema de la tabla, para este caso es ESQUEMA1.

Par´ametro 2. Es el nombre de la tabla que se va a proteger; es decirDIRECCIONES. Par´ametro 3. Es el nombre que se le da a la pol´ıtica de acceso para identificarla dentro de la base de datos; en este caso se llamaSELECT DIRECCIONES.

Par´ametro 4. Nombre del esquema due˜no de la funci´on de acceso; para este caso esSYSTEMya que con esta cuenta se cre´o el paquete que encapsula a la funci´on de acceso.

Par´ametro 5. Nombre de la funci´on de acceso. Como fue creada dentro de un paquete, entonces se especifica con el nombre del paquete, punto (.), el nombre de la funci´on:ACCESO DEPTO.F SELECT.

Par´ametro 6. Operaci´on DML para la cu´al va a aplicar se va a proteger a la tabla DIRECCIONES. Como la pol´ıtica de acceso SELECT DIRECCIONES se refiere a las consultas, la operaci´on DML esSELECT.

Par´ametro 7. Indicador que muestra si la pol´ıtica est´a activada; esto significa que la pol´ıtica de acceso est´a lista para iniciar la modificaci´on de queries en cuanto se detecte que alg´un usuario est´a accesando a la tabla DIRECCIONES. Para este caso debe de estar activada, entonces el valor es TRUE.

En estos momentos, el control de acceso queda implementado dentro de la base de datos para proteger a la tabla DIRECCIONES. Entonces, cuando se haga una operaci´on

SELECTsobre la tabla DIRECCIONES, la pol´ıtica de accesoSELECT DIRECCIONESentrar´a en acci´on y la funci´on de accesoACCESO DEPTO.F SELECTiniciar´a el proceso de modificaci´on de queries, protegiendo as´ı la tabla DIRECCIONES. Recuerde que puede revisar la vista DBA POLICIES para verificar que ya est´a la pol´ıtica implementada en la base de datos.