Skip to content

Access control and audit model for the multidimensional modeling of data warehouses

febrero 24, 2011

Para la asignatura Pruebas y Seguridad me tocó como trabajo analizar un artículo que trataba sobre modelado de seguridad para DataWareHouses, extendiendo los modelos multidimensionales. El trabajo consistió en lo que resumo a continuación.

 

Los DW generalmente son utilizados para sistemas de toma de decisiones (DSS), y en ellos se accede a datos que suelen ser muy delicados y esenciales. Si estos son implementados sólo para el gerente general, tal vez no hay problemas ni necesidades de implementar muchas cosas relacionadas a control de acceso, pero si es necesario tener distintos roles que acceden a unas cosas sí y a otras no, ahí es donde es necesario diseñar el sistema de seguridad. Ahora, esto no lo podemos dejar para el final como ya es sabido, por lo que es ideal considerarlo desde el diseño.

El problema es que los DW se diseñan con modelos MD (multidimensionales), y no hay forma de especificar diseño de seguridad para un modelo multidimensional. En el artículo se presenta un modelo que permite especificar el control de acceso y auditoría desde el diseño de los DW.

Sin entrar mucho en detalle, los DW son usados para DSS cruzando distintas fuentes de información, como ser bases de datos de distintos sistemas, archivos, etc. Esta información es transformada y procesada, y permite luego que se consulten con ciertas facilidades. De ahí que es interesante ver dos conceptos fundamentales para el diseño de DW:

    • Facts: datos numéricos
    • Dimensiones: datos que le dan contexto a los facts

Esto nos da un Modelo Multidimensional. Esto por ejemplo le permitiría a alguien consultar el mismo dato con distintas perspectivas, desde distintas dimensiones, por ejemplo comparando como ha variado a lo largo del tiempo, o similar. Como se trata de distintas dimensiones para un mismo dato a esto se le llama cubo, o hipercubo ya que puede tener más de 3 dimensiones. Pensar en que esta información en los sistemas fuente está sumamente plana, pero en el DW puede estar redundante como para poder mejorar los tiempos de este tipo de consultas.

 

Hay tres aspectos para manejar la seguridad, los cuales van en conjunto

    • Authentication – identificar ambas partes (saber quién es quién)
    • Access control – se determina quién puede hacer qué sobre qué cosas
    • Audit – se guarda información sobre quién hace qué sobre qué cosas, como para descubrir violaciones de seguridad, o diagnosticar causas de probelas

Hay formas de agregar seguridad a estos sistemas, pero por lo general en las últimas etapas de su implementación. Pero como ya se vio en clase es mucho mejor incluirla desde el inicio, en su diseño.

  • Tanto el control de acceso como la auditoría deberían tenerse en cuenta el modelado de diseño del sistema para facilitar su implementación, y no resolverlo con parches luego que está todo implementado.
  • En el artículo se asegura que en ninguno de los modelos MD analizados se incluyen aspectos de seguridad, por lo que no permiten desarrollar un sistema de DW estos aspectos en la etapa de diseño. En algunos trabajos se proponen cosas para access control, pero no para auditoría. Entonces esta propuesta es la primera que incluye a ambas, con un modelo MD.

Modelo propuesto

Se basa en el Modelo de Control de Acceso Obligatorio (top secret, secret, confidential, unclassified), que como se vio tiene sus defectos (poli-instanciación) pero por lo general están asociados a lectura/escritura, y acá  sólo se considera la lectura, pues es la que se utiliza para este tipo de sistemas, así que no es problema.

Cada usuario tiene un rol con cierto nivel de acceso.

  • Authorization Subjects
    • User profile: se definen los atributos del usuario, y en este también queda definido el nivel de acceso. Luego con OCL se puede definir reglas accediendo a las propiedades, como definir que si el userprofile.securityLevel > confidential  entonces ….
    • Queda definido entonces security level, user role, o user compartments para cada usuario.
  • Authorization Objects
    • Se especifican reglas en OCL sobre los atributos, dimensiones, facts, etc.
  • Authorization Actions
    • Sólo se considera la lectura. Queda fuera del alcance la parte de ETL donde se hacen escrituras y transformaciones.
  • SIARs – sensitivity information assignments
    • Se definen reglas en OCL que indican según Facts, dimensions y base classes, indicando a qué clase de acceso corresponde, pudiendo ser security level, user role, o user compartments.
    • Algo interesante definido acá es la propagación de las reglas. Si se define una regla para una relación entre un fact y una base, entonces esa regla se propaga para las relaciones de niveles superiores, pues mientras más cercana la relación en realidad son más específicos los datos.
    • Para cada clase también se definen SL, SR y SC directamente en la parte donde se muestran los estereotipos, indicando el nivel de acceso de la clase. (ver SIAR 6)
  • Authorization Rules  (AUR)
    • Es un sistema cerrado. Se debe definir la regla de acceso, si no se define entonces no se da acceso.
    • De todos modos se pueden dar reglas positivas (dando acceso) o negativas (restringiendo) usando el signo de + o –
    • Acá las restricciones se propagan hacia arriba, y las positivas hacia abajo
  • Audit Rules (AR)
    • Indican qué cosas se van a auditar. Se indica sobre qué objeto se aplica, qué tipo de accesos (ninguno, todos, frustrados, satisfactorios).
    • Se pueden indicar condiciones, y la información que se quiere guardar para esto.
  • Conflict Resolution
    • Existen muchas posibilidades de conflictos entre AURs y SIARs, por lo que se definieron un conjunto de reglas para su resolución.

Conclusión

Hay puntos planteados como trabajo futuro, como pensar también en el proceso ETL (carga del datawarehouse) y no sólo la consulta del almacén de datos. Además de resumir la propuesta, el trabajo contaba con un aporte, que es la idea (planteada a grandes rasgos) de generar pruebas de seguridad automáticamente a partir del modelo MD extendido con las reglas para auditoría y control de acceso, como para plantearle a un tester qué requisitos sería interesante probar y cómo. Esto sería aplicar Model Driven Testing a este esquema.

Anuncios
Dejar un comentario

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: