Caso 5 Control de Acceso en Empresa Regiomontana

La informaci´on de este caso ha sido obtenida por medio de un encuentro con el DBA de una empresa regiomontana, la cu´al tiene implementado el sistema Oracle eBusiness Suite 11i. Esta persona comenta que el dise˜no de la aplicaci´on est´a de tal for- ma que un usuario tiene el privilegio SELECT ANY TABLE y ´este es el administrador principal de la aplicaci´on. No es necesario utilizar roles y los permisos (privilegios) a usuarios que necesitan acceso directo a la base de datos, lo cual no es com´un, se realizan v´ıa GRANT directamente al objeto requerido. Tambi´en comenta que no hay usuarios que tengan privilegios mas all´a de los que necesitan al accesar la base de datos, puesto que todas las modificaciones deben realizarse a trav´es de la aplicaci´on. Respecto a una t´ecnica de control de acceso usada, indica que no se usan triggers ni otro tipo de stored procedures para ello, pero que usan una estructura de tablas para indicar qu´e usuarios y qu´e privilegios dentro de la aplicaci´on tiene cada usuario, asi como a cu´ales m´odulos de la misma tiene acceso; por lo tanto la aplicaci´on es quien lleva el control de acceso.

3.3.

Resumen

Los DBMS descritos, tienen en escencia las mismas capacidades en lo que a roles y a privilegios se refieren; instrucciones como GRANT y SET ROLE son usadas muy

parecido; si hablamos de ventajas y desventajas, tendr´ıan pr´acticamente las mismas, ya que el basar un control de acceso s´olo en estas facilidades (GRANT, SET ROLE), se caer´ıa en administraci´on dif´ıcil por el n´umero de objetos y usuarios(si es que ambos son muchos). S´olo aquellos con caracter´ısticas especiales resaltan y proporcionan her- ramientas extendibles para dise˜nar e implementar un control de acceso m´as confiable y f´acil de manejar. En los casos presentados se puede apreciar que el control de acceso no es un factor est´atico, siempre se est´a buscando proteger la informaci´on mejorando algunas facilidades o t´ecnicas de acceso dependiendo al esquema y ambiente en el que se desarrolla una situaci´on real.

De los casos anteriores se pueden destacar las caracter´ısticas de cada uno:

Caso 1: FUB.

El acceso se otorga bajo la combinaci´on de funci´on laboral y posici´on jer´arquica. Se basa en roles.

El control de acceso est´a desarrollado en una aplicaci´on.

Este caso muestra que se trata de un control de acceso tradicional, ya que se basa en roles, pero con la innovaci´on de que el rol se otorga dependiendo de la funci´on labo- ral y la posici´on jer´arquica del usuario; tambi´en se observa que el control de acceso es pr´acticamente una aplicaci´on externa y la desventaja es que si la aplicaci´on falla, todo el control se viene abajo.

Caso 2: Ingrian.

Usan pol´ıticas de cambio frecuente de passwords.

Encripta la informaci´on. Se usan SecureID, llaves p´ublicas y certificados de aut- enticidad.

Ofrece una aplicaci´on llamada DataSecure para controlar el acceso.

Para este caso, se aprecian controles de acceso previos a la conexi´on, pero estando una vez dentro de sus sistemas de informaci´on ofrecen la ayuda de la aplicaci´on para controlar el acceso a los datos. De igual manera se est´a haciendo uso de una aplicaci´on para controlar el acceso y si falla, tambi´en deja de ofrecer la protecci´on a los datos.

Caso 3. Sistema de Informaci´on de Salud.

Se usan roles.

De nuevo el control de acceso depende de una aplicaci´on, y el control se hace en base a roles, o sea, de manera tradicional.

Caso 4. DAFMAT.

Se usan roles asignados a las tareas o actividades. La aplicaci´on administra el control de acceso.

Se emplean matrices de acceso por actividad laboral.

Este caso al igual que los otros vuelve a depender de la aplicaci´on, s´olo que aqu´ı se usan matrices de acceso para asignar un rol a determinado procedimiento, mismo que llevar´a acabo una tarea espec´ıfica. De nuevo, si la aplicaci´on tiene problemas, el control de acceso dejar´a de funcionar.

Caso 5. Empresa Regiomontana.

Se usan permisos directos, es decir, se le otorgan permisos al usuario para que pueda usar un objeto.

No usan roles.

Se puede consultar todo (SELECT ANY TABLE). La aplicaci´on tambi´en determina el acceso.

Para este caso, se puede ver que es mucho m´as sencillo que los anteriores, pero de la misma forma dependen de una aplicaci´on.

Con estos casos se puede concluir que los controles de acceso son dependientes de las aplicaciones que se usan para explotar la informaci´on, esto lleva a confirmar que la ventaja significativa del control de acceso presentado en la tesis es que no es una aplicaci´on, puesto que se implementa dentro de la base de datos y adem´as los tiempos de desarrollo son casi despreciables, porque se cuenta con la generaci´on autom´atica de c´odigo. A continuaci´on, el siguiente cap´ıtulo muestra el control de acceso hecho en esta tesis, as´ı como su funcionamiento, ejemplos y la generaci´on de c´odigo para su implementaci´on.

Cap´ıtulo 4

Desarrollo del Control de Acceso

Este cap´ıtulo presenta el mecanismo desarrollado para la creaci´on del control de acceso a datos para organizaciones con informaci´on centralizada. Es necesario recordar que para estas organizaciones los accesos pueden ser tanto locales como remotos.

Dicho control de acceso ha sido desarrollado para ser implementado directamente en la base de datos, es decir, se aplica directamente en las tablas del modelo que se desea proteger. Una de las partes fundamentales de este proyecto es que el control de acceso est´a situado fuera de cualquier aplicaci´on, es independiente del tipo o giro de aplicaci´on que se desarrolle y de igual manera para el objetivo que ´esta haya sido de- sarrollada.

Para la implementaci´on de este control de acceso se hizo uso de objetos y carac- ter´ısticas prove´ıdas por el propio manejador de la base de datos; con esto se asegura de que el impacto para el propio manejador sea m´ınimo. Tambi´en para dicha imple- mentaci´on se hace uso de la generaci´on de c´odigo de manera autom´atica; dicha gen- eraci´on se provee por medio de una consola a la cu´al basta con definirle ciertas entradas y como salidas generar´a el c´odigo, una conexi´on a la base de datos y la implementaci´on del c´odigo generado, asegurando que el control de acceso quede implementado en la base de datos. Es necesario asentar que este control de acceso no aplica para ambientes distribu´ıdos, es decir, bases de datos distribu´ıdas.

En las secciones siguientes se presenta la problem´atica a atacar y la soluci´on de la misma, que dicho en otras palabras es el control de acceso. A su vez se mostrar´an los componenetes de este control de acceso y se ilustrar´a su aplicaci´on con ejemplos: uno con operaciones b´asicas y otro en el que intervienen operaciones m´as complejas. Tambi´en se muestra la generaci´on de c´odigo, c´omo se hace, c´omo se implementa en la base de datos. El RDMBS usado en los ejemplos y generaci´on del c´odigo es Oracle Database Server 9i R2 Enterprise Edition.

4.1.

Problema

Esta secci´on presenta el problema que se detect´o y se atac´o en este trabajo de tesis. El problema consta en que los datos de una organizaci´on con informaci´on central- izada, tienen el riesgo de que sean accesados por usuarios que no deban manipularlos, ya sea por error o como acto malicioso. De ello se deslinda que la informaci´on pierda la capacidad de ser confiable y consistente, y que a su vez el funcionamiento de toda la organizaci´on se vea afectado, de manera negativa e imposibilita para toma de decisiones y operaci´on diaria. La forma en como los usuarios pueden tener acceso es atrav´es de una aplicaci´on o directamente en la base de datos (telnet, secure shell).

Como parte de las definiciones de las diferentes entidades que coexisten dentro de una organizaci´on, ll´amense usuarios a aquellos que pertenecen al ambiente de trabajo y que tienen la posibilidad de conectarse y manipular la informaci´on.