Restricciones de Autorización en Sistemas de Gestión de
Workflow.
Juan J. Moreno Quinteros1, Martín Sorondo Peyre2. Luis Joyanes Aguilar3,
1 Uruguayo. Universidad Pontificia de Salamanca, Campus de Madrid, Facultad de Informática, Paseo de Juan XXIII, 3 – 28040. Tel. 91 514 17 07. Madrid, España.
Universidad Católica del Uruguay, Facultad de Ingeniería y Tecnologías. Av. 8 de Octubre 2738 – 11600. Tel. (598 2) 487 2717. Montevideo, Uruguay, 11600.
2 Uruguayo. Universidad Católica del Uruguay, Facultad de Ingeniería y Tecnologías Av. 8 de Octubre 2738 – 11600. Tel. (598 2) 487 2717. Montevideo, Uruguay, 11600.
3 Español. Universidad Pontificia de Salamanca, Campus de Madrid, Facultad de Informática, Paseo de Juan XXIII, 3 – 28040. Tel. 91 514 17 07. Madrid, España.
RESUMEN
Este trabajo presenta los lineamientos generales para la construcción de una herramienta de software para la especificación de restricciones de separación de funciones. Ésta permitirá ser integrada con cualquier Sistema de Gestión de Workflow que utilice un modelo de seguridad basado en roles, aplicando así estas restricciones sobre los procesos automatizados en él. La separación de funciones, como principio de seguridad, tiene el objetivo de reducir el riesgo de fraudes evitando que un individuo tenga la autoridad suficiente en el sistema como para cometerlos por sus propios medios. Dos variedades se identifican y contemplan en este trabajo: requerimientos que pueden ser verificados en tiempo de diseño (separación de funciones estática), y requerimientos que solo pueden verificarse en tiempo de ejecución (separación de funciones dinámica). Se discuten los principales aspectos de la integración con el WMS, enfatizando aspectos de performance y disminución de la complejidad de la automatización de procesos. Palabras clave: Workflow, Authorization, Restrictions, RBAC
1 Introducción
Una carencia bastante común de los modelos de autorización basados en roles es que no son capaces de modelar restricciones de autorización (restricciones en adelante) sobre los roles. Una restricción típica, relevante y muy conocida en el área de la seguridad es la “Separación de Funciones” cuyo objetivo es reducir el riesgo de fraudes evitando que un individuo tenga la autoridad suficiente en el sistema como para cometer un fraude por sus propios medios. Un ejemplo de una regla de negocio que refleja una restricción de ese tipo sería: “Para tener validez, un cheque debe ser firmado por dos personas diferentes”. El punto fundamental es que las restricciones de autorización o la separación de funciones no están soportadas nativamente en los Workflow Management System (WMS). Esto casi siempre se puede lograr, dependiendo de el Sistema de Gestión de Workflow, mediante la codificación de las restricciones para cada tarea y en el lenguaje de programación soportado por la herramienta; sin embargo esta solución es bastante compleja, hace muy difícil la especificación de restricciones y tiene un problema fundamental y es que da por tierra el principio fundamental de que usuarios no técnicos puedan modelar sus flujos en el WMS.
El objetivo de este trabajo es proponer los principales aspectos del desarrollo de una herramienta con soporte para la especificación de restricciones de separación de funciones. La llamaremos “Constraint Management Tool” (en adelante CMT), y estará compuesta por una aplicación visual para la especificación de restricciones (“Constraint Builder”, en adelante CB) y por un componente que se encargará de la verificación de estas restricciones (“Constraint Engine”, en adelante CE). El CMT necesita para su funcionamiento estar integrado y sincronizado con un WMS y por lo tanto esta integración también formará parte de los lineamientos que veremos a continuación. En la Ilustración 1 podemos ver una primera aproximación a la arquitectura del sistema propuesto. Los componentes principales del esquema son el WMS y el CMT.
Por un lado disponemos de un Sistema de Gestión de Workflow, completo y funcionando, que tendrá su propia arquitectura interna y que será distinta en cada uno de ellos dependiendo de su fabricante A pesar de esto, podemos encontrar elementos en común en todos los WMSs como lo son el Motor de Workflow (WE), el Agente de Seguridad (SA) y el Diseñador de Procesos. Sobre la derecha de la Ilustración 1 se
encuentra el CMT, compuesto del CB y el CE, los que mantienen y comparten la información sobre las restricciones, almacenada en un repositorio de datos (Constraint Data). La integración del WMS con el CMT se realiza a través de los tres repositorios de datos (Execution Knowledge, RBAC Data y Process Definition) que podemos observar en el centro de la imagen y a través de un canal de comunicación entre el Workflow Engine y el Constraint Engine mediante el cual realizan un intercambio de mensajes que vamos a detallar más adelante y que permite la sincronización entre ambos componentes para asegurar
El Execution Knowledge engloba toda la información disponible acerca del estado de la ejecución de los procesos en el Motor de Workflow. En particular: cuales son los procesos que están ejecutando, en que estado están y quienes han actuado sobre cada proceso.
Esta información es necesaria para aquellas restricciones que deben ser evaluadas en tiempo de ejecución y que se basan en información histórica. La RBAC Data contiene toda la información relativa al modelo de roles y autorizaciones del WMS (Ilustración 2) y es administrada únicamente por este último
Ilustración 2 – Modelo de Roles
La definición del proceso (“Process Definition”) contiene la información completa de los procesos que se necesita para que WMS los ejecute. Esto incluye información sobre las condiciones de inicio y finalización, tareas, reglas para las transiciones, usuarios y permisos asociados, etc. Las restricciones especificadas en el CE por el Gerente de Seguridad (en adelante SOf – Security Officer) son almacenadas en un repositorio privado del CMT, el Constraint Data (CD). Esta CD contendrá otros datos requeridos para el funcionamiento del CMT y se implementará como una base de datos relacional, debido a que el tiempo de recuperación de la información influye directamente sobre la performance del CE en responder a las solicitudes del WMS.
2 Separación de Funciones – Implementación
Se utilizará un modelo de administración por entidades en conflicto. Un conflicto entre entidades implica que el riesgo de fraude se incremente si no se controlan cuidadosamente las asociaciones entre esas entidades. Las entidades que han sido identificadas para el dominio son: usuarios, permisos y roles. En la Tabla 1 podemos observar algunos ejemplos de estos conflictos.
Conflicto Posible Interpretación como una regla de negocio
Roles conflictivos Los roles “Encargado de Ventas” y “Cajero” son mutuamente excluyentes. Permisos conflictivos “Aprobar orden de compra” Un mismo usuario nunca puede recibir el permiso de “Crear orden de compra” y Usuarios conflictivos Los miembros de la misma familia pueden conspirar para cometer un fraude.
Tabla 1 - Entidades Conflictivas
Como se ha mencionado es posible identificar dos variantes de la separación de funciones, la Separación de Funciones estática (SSoD – Static Separation of Duties) y la Separación de Funciones Dinámica (DSoD – Dinamic Separation of Duties), según el momento en que estos conflictos pueden ser verificados. Para ambas se utilizará el método anterior de las entidades en conflicto. Pero si bien el concepto es similar, requieren un análisis e implementación completamente independientes que veremos en los siguientes apartados
3 Separación de Funciones Estática (SSoD)
La Separación de Funciones Estática debe su nombre a que sus requerimientos no dependen de la ejecución de ningún proceso y por lo tanto pueden ser evaluados en tiempo de diseño. El objetivo principal detrás de la Separación de Funciones Estática es prohibir la introducción en la base de
autorizaciones de relaciones definidas como incompatibles entre las entidades de interés (usuarios, permisos y roles). Estas relaciones incompatibles o conflictos son definidas por el SOf1 a través del Constraint Builder y son almacenadas como restricciones en la CD. Por ejemplo un conflicto definido entre los roles “Cajero” y “Vendedor” implica que ningún usuario podrá ser asignado a ambos roles en ningún momento. Un conflicto entre los permisos “Crear Orden de Compra” y “Aprobar Orden de Compra” implica que ningún usuario podrá en ningún momento obtener ambos permisos a través de los roles que le son asignados. Finalmente, un conflicto entre usuarios implica que los mismos sean considerados, a efecto de las autorizaciones, como un único usuario porque pueden conspirar para cometer un fraude, entonces, si existe una restricción entre los roles “Cajero” y “Vendedor” y existe también otra restricción entre los usuarios “Juan” y “Jorge”, si “Juan” está asignado al rol “Cajero” entonces “Jorge” no podrá ser asignado al rol “Vendedor” y viceversa. Se podría argumentar que la SSoD es muy restrictiva para las operaciones normales de una organización, sin embargo, es realmente útil para aplicar restricciones que alcancen a todos los procesos y se mantengan constantes a través del tiempo sobre todo en grandes organizaciones. El almacenamiento de las restricciones de SSoD se realizará en tres conjuntos o colecciones, una para cada una de las entidades en conflicto: usuarios, roles y permisos que tendrán el nombre de “Static Conflicting User Set” (SCUS), “Static Conflicting Role Set” (SCRS) y “Static Conflicting Permission Set” (SCPS) respectivamente. Según podemos apreciar en la Tabla 2, cada elemento de estas colecciones, que llamaremos conflicto, será a su vez un conjunto y estará compuesto por al menos dos Usuarios, Roles o Permisos distintos entre sí, respectivamente.
U = un conjunto de usuarios, {u1, … , un}. R = un conjunto de roles, {r1, … , rn}. P = un conjunto de permisos, {p1, … , pn}. j i i n
n
i
n
u
U
i
j
u
u
u
u
cu
=
{
1,...,
}
/
≥
2
∧
(
∀
≤
)
∈
∧
(
∀
≠
)
≠
j i i nn
i
n
r
R
i
j
r
r
r
r
cr
=
{
1,...,
}
/
≥
2
∧
(
∀
≤
)
∈
∧
(
∀
≠
)
≠
j i i nn
i
n
p
P
i
j
p
p
p
p
cp
=
{
1,...,
}
/
≥
2
∧
(
∀
≤
)
∈
∧
(
∀
≠
)
≠
SCUS = un conjunto de conflictos estáticos de usuarios, {cu1, … , cun}.
SCRS = un conjunto de conflictos estáticos de roles, {cr1, … , crn}.
SCPS= un conjunto de conflictos estáticos de permisos, {cp1, … , cpn}.
Tabla 2 - Definición formal de las restricciones de SSoD
3.1 Implementación de Restricciones de Separación de Funciones Estática
Desde el punto de vista de la implementación, una violación a este tipo de restricciones se puede producir con cualquier modificación de la RBAC Data, por ejemplo la asignación de un Rol a un Usuario o un Permiso a un Rol. De acuerdo a la Arquitectura del Sistema de la Ilustración 1, el responsable del mantenimiento y actualización de la RBAC Data es el propio WMS, en particular el Security Agent y por otro lado el encargado del mantenimiento y verificación de las restricciones es el CMT. Por lo tanto, deberá existir una comunicación entre estos dos de modo
que cada vez que el SA quiera realizar un cambio en la RBAC Data2 deberá notificar al CMT del mismo (en realidad al CE), el que se encargará de verificar si esta modificación viola o no las restricciones. Si el cambio no produce ninguna violación entonces se autoriza al Security Agent a realizarlo, pero en el caso contrario, se rechaza y se construye un mensaje indicando el motivo de la violación que será enviado al SOf. Luego, éste podrá desistir de realizar el cambio o utilizar el CMT para modificar las restricciones de modo que este sea aceptado.
Con el objetivo de expresar más claramente la idea, se omitió intencionalmente un detalle y es que no todas las modificaciones en la RBAC Data introducidas por el WMS pueden llegar a producir una violación en las restricciones. En realidad estas modificaciones las podemos agrupar en tres categorías distintas, modificaciones que pueden producir una violación a las restricciones y que llamaremos modificaciones activas, modificaciones que no pueden producir una violación a las
restricciones pero sin embargo requieren la realización de tareas de mantenimiento en la Constraint Data (Ejemplo eliminación de usuarios o roles) y que llamaremos modificaciones pasivas y
finalmente modificaciones que no tienen ningún efecto para el CMT y que llamaremos modificaciones neutras, como se resume en la Tabla 3.
Activas Pasivas Neutras
Agregar UA Eliminar Usuario Agregar Usuario
Agregar PA Eliminar Rol Agregar Rol
Agregar RH Eliminar Permiso Agregar Permiso
- Eliminar UA -
- Eliminar PA -
- Eliminar RH -
Tabla 3 - Posibles modificaciones realizadas por el WMS sobre la RBAC Data3. La “comunicación” que fue mencionada entre el WMS y el CMT se realiza a través del intercambio de mensajes entre ellos y únicamente para el caso de las modificaciones activas o pasivas ya que las modificaciones neutras no tienen efecto sobre el WMS. Estos mensajes a su vez podemos clasificarlos en dos tipos: mensajes de notificación y mensajes de autorización (Ilustración 3). Los mensajes de notificación son enviados por el WMS hacia el CMT
(unidireccionales) y se utilizan para notificar las modificaciones pasivas. Los mensajes de
autorización también son enviados por el WMS pero en este caso solicitan la autorización del
CMT para realizar una modificación activa a lo que el CMT debe responder (bidireccionales) habilitando o no la modificación según esta produzca una violación a las restricciones.
Ilustración 3 – Intercambio de Mensajes, SSoD.
3.2 Modificaciones activas
Una relación de UA (User Assignment) es una dupla (Usuario, Rol) que implica que se autoriza al Usuario a poder jugar el Rol especificado en la relación. Esta modificación, al igual que las demás modificaciones activas, requiere un análisis previo de la CD para verificar que la misma no viola las restricciones establecidas. El análisis consiste en verificar que el usuario no este autorizado a jugar ningún rol marcado como conflictivo con el rol que se quiere autorizar, verificar que ninguno
2 Esta situación se producirá cada vez que el Gerente realice algún cambio en la seguridad utilizando la
herramienta para la Administración de Seguridad provista por el WMS. Ejemplos: otorgar un permiso a un rol, asignar un rol a un usuario, etc .
de los permisos que serán otorgados al usuario a través del rol en cuestión están identificados como conflictivos con alguno de los permisos a los que el usuario ya está autorizado y verificar que las dos reglas anteriores también se cumplen para cada uno de los usuarios identificados como conflictivos con el usuario en cuestión. Si alguna de las verificaciones no se cumple entonces el CMT devuelve un mensaje negando la modificación y explicando el motivo.
Una relación de PA (Permission Assignment) es una dupla (Rol, Permiso) que implica la autorización de un Permiso a un Rol. Al igual que en el caso anterior, la inserción de una relación de este tipo en la CD requiere un análisis previo de la misma, consistente en verificar que el Rol no tenga asignado ningún permiso identificado como conflictivo con el permiso que se quiere agregar (en ese caso se transformaría en un rol inutilizable), para cada uno de los usuarios que están asignados al rol de la relación PA, es decir para aquellos usuarios que obtendrán este nuevo permiso, verificar que no existen conflictos entre el permiso en cuestión y los demás permisos que ya tiene asignados y verificar que esto también se cumple para cada uno de los usuarios identificados como conflictivos con cada uno de los usuarios que obtienen el nuevo permiso. La relación RH (Role Hierarchy) se realiza entre dos roles (Padre,Hijo) y significa que el rol Hijo depende del rol Padre en la jerarquía, implicando que el padre heredará todos los permisos asignados al Hijo. En este caso es preciso verificar que Padre e Hijo no estén identificados como conflictivos, verificar que no existan conflictos entre los permisos actuales del Padre y los permisos que pasará a tener a partir de la herencia de los permisos del Hijo, verificar que no exista ningún usuario asignado al rol Padre y que a su vez esté asignado a un rol en conflicto con el rol Hijo, para cada usuario asignado al rol Padre verificar que los permisos que obtendrá no generan conflictos con los que ya tiene asignados y finalmente verificar que las dos reglas anteriores también se cumplen para los usuarios en conflicto con cada uno de los usuarios que se verifica.
3.3 Optimización de las Modificaciones activas
Si bien el objetivo de la investigación en este momento no es la optimización de la solución vamos a realizar una pequeña modificación a los procedimientos mencionados recientemente con el objetivo de optimizar y simplificar el resultado. La optimización se realizará al momento de verificar los conflictos entre dos roles. Supongamos que tenemos los permisos P1, P2, P3 y p4, los roles R1 y R2 de acuerdo a la Ilustración 4.
El procedimiento de verificación de la existencia de un conflicto estático entre R1 y R2 consiste en verificar en primer lugar que no exista una restricción estática explícita especificada por el SOf que establezca que R1 y R2 son roles conflictivos. En segundo lugar consiste en verificar que para cada uno de los permisos asignados a R1 no exista ningún permiso
conflictivo con este asignado a R2. Ilustración 4 – Intercambio de Mensajes SSoD. Ahora bien, si existe una restricción estática entre dos permisos asignados a dos roles distintos, por ejemplo entre P1 y P4, esto implica que los roles, en este caso R1 y R2, se transformarán por transitividad en roles conflictivos y por lo tanto a los fines del sistema esto es idéntico a la existencia de una restricción explícita entre R1 y R2.
Entonces, para simplificar y optimizar el procedimiento de verificación de conflictos entre dos roles vamos a introducir un tipo de restricciones entre roles que llamaremos restricciones “inferidas”. Estas restricciones son idénticas a las restricciones entre roles pero no son realizadas por el SOf sino que son inferidas por el sistema cada vez que el mismo ingresa una restricción entre Permisos. Por ejemplo, si se agrega una restricción entre P1 y P4 el sistema inferirá que existe una restricción entre R1 y R2 y la agregará a la base con una bandera para distinguirlas de
las restricciones “explícitas”. Esta distinción es necesaria para el caso posterior de que se elimine la restricción entre los permisos P1 y P4, requiriendo así eliminar la restricción inferida.
Considerando esta pequeña modificación ahora el procedimiento de verificación de la existencia de un conflicto estático entre dos roles se limita únicamente a verificar que no exista una restricción entre estos dos roles ya que las restricciones entre sus permisos están contempladas por las restricciones inferidas entre roles. Sin embargo, la desventaja de esta aproximación surge al momento de eliminar una restricción entre Permisos porque implica reprocesar las restricciones inferidas relacionadas a la restricción eliminada para determinar si las mismas se mantienen o también deben ser removidas. En el ejemplo anterior, si se elimina la restricción entre P1 y P3 entonces debe eliminarse también la restricción inferida entre R1 y R2, pero esto no debe ser así si además existía otra restricción entre los permisos P2 y P4.
3.4 Modificaciones Pasivas
Como mencionamos, las modificaciones pasivas requieren la realización de tareas de mantenimiento en la CD. A grandes rasgos podemos decir que estas tareas consisten en eliminar las referencias en la CD a la entidad o relación que acaba de ser eliminada y no tiene mucho sentido entrar en detalle sobre las mismas ya que son relativamente triviales.
3.5 Especificación de Restricciones de Separación de Funciones Estática
La especificación de las restricciones de Separación de Funciones Estática se realiza a través del mencionado Constraint Builder. En este, el SOf debe poder acceder a la información sobre la definición del proceso (tareas que lo componen y flujos), roles, usuarios y autorizaciones como para lograr una buena comprensión del sistema y comprobar la efectividad de las restricciones especificadas o las restricciones que se van a especificar.
Cuando el SOf especifica una nueva restricción el sistema debe realizar algunas verificaciones para comprobar que la CD quedará en un estado “consistente” luego de la inserción de la misma en la base restricciones. Por ejemplo, si existe un usuario ‘Juan’ asignado a los roles ‘R1’ y ‘R2’, la inserción de una nueva restricción entre los roles ‘R1’ y ‘R2’ dejaría la base en un estado inconsistente porque se estaría violando la misma desde el momento de su creación. A continuación vamos a detallar los procedimientos de verificación de consistencia que van a depender del tipo de restricción que se este insertando pero a grandes rasgos podríamos decir que consisten en comprobar que no existan casos como el del ejemplo anterior y en su defecto prohibir la introducción de la restricción en la base y poner al tanto al SOf del conflicto en cuestión.
3.6 Nuevo conflicto entre permisos
En este caso la tarea consiste en analizar la RBAC Data en busca de roles que estén asignados a dos o más de los permisos en conflicto. Si se encuentra un rol de este estilo entonces se rechaza la restricción y se pone en conocimiento del SOf cual es rol que generó el problema. Finalmente, si se permite agregar la restricción a la CD, es necesario “calcular” las restricciones de roles estáticas inferidas de acuerdo a lo establecido en el apartado 0.
3.7 Nuevo conflicto entre roles
Antes de agregar un conflicto entre roles es necesario analizar las asignaciones entre usuarios y roles para detectar si existe algún usuario asignado a dos o más de los roles incluidos en la restricción en cuyo caso no se podría insertar la misma en la CD.
3.8 Nuevo conflicto entre usuarios
La inserción de una nueva restricción de esta clase en la CD requiere que previamente se hayan analizado los roles que están asignados a los usuarios de la misma para asegurar de que no existan conflictos entre ellos. En este caso no es necesario buscar conflictos entre los permisos de cada usuario ya que partimos de la base de que si existe alguno entonces también existirá una restricción estática de roles inferida que lo contemple si corresponde.
4 Separación de Funciones Dinámica (DSoD)
La separación de funciones dinámica provee mayor flexibilidad que la separación de funciones estática y permite aplicar restricciones que se ajustan más al funcionamiento de las organizaciones humanas controlando la activación y el uso de los roles en tiempo de ejecución en lugar de las relaciones entre Usuarios, Permisos y Roles en tiempo de diseño. Utilizando nuevamente el modelo de administración por entidades en conflicto vamos a presentar los roles dinámicamente conflictivos, los permisos dinámicamente conflictivos y los usuarios dinámicamente conflictivos. En la separación de funciones dinámica se permite que los roles conflictivos tengan usuarios en común siempre y cuando no asuman ambos roles en una misma instancia de un proceso. En el ejemplo anterior de los roles “Cajero” y “Vendedor”, se permite que un usuario tenga ambos roles, pero si en un proceso actuó como “Cajero” no podrá hacerlo como “Vendedor” y viceversa. En segundo lugar hemos de mencionar a los permisos dinámicamente conflictivos como podrían ser “Crear Orden de Compra” y “Aprobar Orden de Compra”. El mismo razonamiento anterior se aplica en este caso permitiendo que los Usuarios obtengan ambos permisos a través de las asignaciones a roles pero impidiendo que logren el ejercicio de ambos en una misma instancia de proceso. Esto no impide que si “Juan” ejerció el permiso de “Crear Orden de Compra” en una instancia pueda ejercer “Aprobar Orden de Compra” en otra.
Finalmente para los usuarios dinámicamente conflictivos se aplica el mismo criterio y por lo tanto si “Juan” y “Jorge” están identificados como conflictivos y “Jorge” actuó como “Cajero” en una instancia de un proceso se interpretará como que si “Jorge” también lo hubiera hecho.
En esta situación la comunicación entre el CMT y el WMS se incrementa ya que ahora el CMT deberá responder a las modificaciones introducidas en la RBAC Data al tiempo que participar en las decisiones de autorización para cada tarea, verificando las restricciones dinámicas.
4.1 Implementación de Restricciones de Separación de Funciones Dinámica
Cada vez que se quiere verificar la autorización de un usuario para realizar una tarea es necesario analizar las restricciones existentes que aplican al mismo y también la historia de sus ejecuciones, es decir, las tareas que ha realizado previamente. Si consideramos todos los procesos, tareas y usuarios de una organización entonces el volumen de la información a consultar es demasiado grande y sería inviable mantener al usuario en espera mientras se realizan las verificaciones. La solución que vamos a proponer se basa en que el CMT mantenga una parte de estos datos en la CD. Esta solución tiene las desventajas aparejadas con el mantenimiento de información redundante pero logra reducir notablemente el tiempo de verificación por dos motivos: el volumen de información es mucho menor porque solo almacena la información relevante y, el tiempo de respuesta es mínimo porque se estaría accediendo a un RDBMS. En realidad, por cuestiones de optimización vamos a estar almacenando información sobre lo que cada usuario no puede hacer en vez de almacenar lo que hizo y a partir de esto calcular lo que puede hacer. De esta forma trasladamos una parte del procesamiento (calcular lo que no puede hacer) a un momento en que
la latencia no es importante que es cuando el usuario finaliza una tarea, reducimos más aún el volumen de los datos que hay que analizar en cada verificación y ganamos velocidad porque corroborar la autorización de un usuario a realizar una tarea se limitará a chequear que no exista una entrada en la tabla donde se almacena lo que el usuario no puede hacer. Vale destacar que esto aplica a la verificación de autorizaciones en cuanto a las restricciones y es independiente de las verificaciones previas que realiza el Security Agent o Agente de Seguridad.
La información sobre lo que el usuario no pude hacer se almacena en dos conjuntos o colecciones llamados CantDoSet y CantPlaySet. En el primero se almacenan las tareas que los usuarios no pueden realizar de la forma (Usuario, Tarea, Instancia) que se interpreta cómo: “El usuario Usuario no puede realizar la tarea Tarea en la instancia Instancia”. En el segundo se almacenan los roles que los usuarios no pueden jugar de la forma (Usuario, Rol, Instancia) y se interpreta de la misma forma. En la Tabla 4 podemos observar la definición formal de estas estructuras.
U = un conjunto de usuarios, {u1, … , un}. R = un conjunto de roles, {r1, … , rn}. P = un conjunto de permisos, {p1, … , pn}. j i i n
n
i
n
u
U
i
j
u
u
u
u
cu
=
{
1,...,
}
/
≥
2
∧
(
∀
≤
)
∈
∧
(
∀
≠
)
≠
j i i nn
i
n
r
R
i
j
r
r
r
r
cr
=
{
1,...,
}
/
≥
2
∧
(
∀
≤
)
∈
∧
(
∀
≠
)
≠
j i i nn
i
n
p
P
i
j
p
p
p
p
cp
=
{
1,...,
}
/
≥
2
∧
(
∀
≤
)
∈
∧
(
∀
≠
)
≠
DCUS4 = un conjunto de conflictos dinámicos de usuarios, {cu1, … , cun}.
DCRS5 = un conjunto de conflictos dinámicos de roles, {cr1, … , crn}.
DCPS6= un conjunto de conflictos dinámicos de permisos, {cp1, … , cpn}.
T = un conjunto de tareas, {task1,…,taskn}
I = un conjunto de instancias de proceso, {ins1,…,insn}
I
ins
T
task
U
user
ins
task
user
dni
=
(
,
,
)
/
∈
∧
∈
∧
∈
I
ins
T
task
U
user
ins
task
user
cdi
=
(
,
,
)
/
∈
∧
∈
∧
∈
I
ins
R
role
U
user
ins
role
user
cpi
=
(
,
,
)
/
∈
∧
∈
∧
∈
DoneSet = un conjunto de DoneItems, { dni1, … , dnin }
CantDoSet = un conjunto de CantDoItems, { cdi1, … , cdin }
CantPlaySet = un conjunto de CantPlayItems, { cpi1, … , cpin }
Tabla 4- Definición formal de las restricciones de DSoD
4.2 Descripción de la comunicación
En la Ilustración 5 podemos observar el intercambio de mensajes que ocurre entre el CE y el WE para asegurar el cumplimiento de las restricciones de DSoD. A continuación vamos a comentar cual es la utilidad de estos mensajes y de que forma logran cumplir con su objetivo.
4 Dinamic Conflicting User Set 5 Dinamic Conflicting Role Ser 6 Dinamic Conflciting Permission Set
Ilustración 5 – Intercambio de Mensajes, SSoD.
Done.
La función Done es invocada por el WMS cada vez que una tarea acaba de ser realizada por un usuario en una instancia de proceso. Recibe como parámetros el usuario, la tarea realizada y la instancia de proceso. Es utilizada por el CE para actualizar la CD ya que el evento ocurrido puede haber producido una modificación en las autorizaciones. El procedimiento que realiza es:
• Agregar una entrada en la tabla DoneSet.
• Para cada permiso en conflicto con el permiso de la tarea realizada agregar una entrada en la tabla CantDoSet.
• Agregar una entrada en la tabla CantPlaySet para cada Rol en conflicto con los Roles asignados al permiso para realizar la tarea.
• Repetir los dos pasos anteriores para cada Usuario en conflicto con el Usuario en cuestión.
Finish
Una vez que finaliza una instancia de proceso es necesario eliminar toda la información referente a ella de la CD, eliminando todas sus entradas en las tablas DoneSet, CantDoSet y CantPlaySet. El objetivo de esta tarea es reducir la cantidad de datos en la CD y por lo tanto reducir el espacio de búsqueda, salvando una caída en la performance del CE al momento de verificar las restricciones. Este procedimiento se realiza a través de la función Finish que debe ser invocada por el WMS cada vez que finaliza una instancia de proceso y que recibe como parámetro el identificador de la instancia que acaba de finalizar. La labor de esta función es:
• Recorrer la tabla DoneSet eliminando las entradas con referencia a la instancia de proceso. • Idem para las tablas CantDoSet y CantPlaySet.
Vale destacar que se supone que una vez finalizada una instancia de proceso, ésta nunca resucita. Si así fuera, no se debería eliminar la información de la CD.
Who
Who es una de las funciones principales del CMT. Retorna una lista con los usuarios autorizados a realizar una tarea en una instancia de proceso que recibe como parámetro. Identifica los usuarios autorizados a realizar la tarea en su correspondiente proceso y luego chequea los mismos contra las restricciones dinámicas para ver si realmente están autorizados. El procedimiento consiste en:
• Identificar los Roles autorizados a realizar la tarea.
• Determinar los Usuarios autorizados a jugar los Roles identificados.
• Verificar para cada uno de los usuarios que no exista una entrada en la tabla CantDoSet que impida la realización de la tarea en la instancia de proceso.
• Para cada usuario, verificar que no exista una entrada en la tabla CantPlaySet que impida al usuario jugar alguno de los roles autorizados a realizar esa tarea en la instancia.
CanDo
La función CanDo es similar a la función Who pero en vez de determinar los usuarios autorizados a realizar una tarea en una instancia de proceso determina si un usuario, recibido cómo parámetro, esta autorizado a realizar una tarea en una instancia de proceso. Retorna ‘Verdadero’ o ‘Falso’. Conceptualmente el procedimiento es invocar la función Who y verificar si el usuario pertenece a la lista de usuarios generada. Por cuestiones de performance se realiza un proceso más eficiente:
• Identificar los Roles autorizados a realizar la tarea.
• Determinar si el Usuario está autorizado a jugar alguno de los Roles identificados.
• Verificar que no exista una entrada en la tabla CantDoSet para el usuario en cuestión que impida la realización de la tarea en esa instancia.
• Verificar que no exista una entrada en la tabla CantPlaySet que impida al usuario jugar alguno de los roles autorizados a realizar la tarea en esa instancia de proceso.
4.3 Especificación de Restricciones de Separación de Funciones Dinámica
Estas restricciones, al igual que las anteriores, son especificadas por el SOf a través del Constraint Builder. La diferencia radica en que al insertar una nueva restricción no es necesario realizar un chequeo de inconsistencias porque estas no ocurren con esta variedad de SoD. Sí hay que considerar que al agregar un nuevo conflicto, puede haber instancias de proceso en ejecución, lo que implica que la nueva restricción no va surtir efecto sobre ninguna de ellas.
Por ejemplo, una organización tiene un proceso automatizado con tareas T1 y T2 , permisos P1 Y P2 ambos asignados a un rol R y autorizados a realizar las mismas tareas, y finalmente una cantidad x de usuarios autorizados a jugar el rol. Un día esta organización aplica una política de separación de funciones sobre sus procesos automatizados: los usuarios que realizan las tareas T1 y T2 deben ser distintos. El SOf, utilizando el CB, especifica un nuevo conflicto dinámico entre los permisos P1 y P2. A partir de ese momento cada vez que un usuario realice la tarea T1 se agregará una entrada en la tabla CantPlaySet, impidiendo que realice la tarea T2. Pero, cualquier usuario podría realizar la tarea T2 en las instancias de proceso que hubiera iniciado antes de que se especificara la nueva restricción (no existe ninguna entrada que lo impida en la tabla CantPlaySet) Por este motivo, al agregar una restricción se deben realizar tareas para mantener actualizada la información de la Constraint Data evitando que ocurra un caso como el planteado. Otra solución podría ser manejar versiones de las definiciones de procesos omitiendo estos procedimientos. Las nuevas restricciones se aplicarían solo sobre las instancias de proceso creadas posteriormente a la definición de la nueva restricción y no sobre las instancias que ya estaban ejecutando. A pesar de su sencillez se optó por la primera alternativa, considerando que hay tres tipos de restricciones (permisos, roles y usuarios) y que cada nueva restricción generaría una nueva versión de la definición del proceso, produciendo un crecimiento incontrolable del número de versiones.
Nuevo conflicto entre permisos
Al agregar un nuevo conflicto entre permisos se debe chequear las tareas que han realizado los usuarios en los procesos activos para actualizar las entradas en la CantDoSet. Por ejemplo en un proceso con dos tareas T1 y T2 cuando se ingresa un nuevo conflicto entre T1 Y T2 es necesario actualizar la tabla CantDoSet para que todos los usuarios que realizaron la tarea T1 no puedan realizar la T2. Se recorre la tabla DoneSet e inserta una nueva entrada en la tabla CantDoSet de la forma (Usuario, T2, Instancia) para cada entrada en DoneSet donde la tarea sea igual a T1.
Al agregar un nuevo conflicto entre roles es preciso insertar, para cada usuario que halla jugado alguno de los roles del nuevo conflicto, una nueva entrada en la tabla CantPlaySet para cada uno de los roles restantes del conflicto. Es decir que si tenemos un nuevo conflicto entre los roles R1, R2 y R3 y existe un usuario U1 que en una instancia de proceso determinada I1 actuó como R1 entonces es necesario agregar en la tabla CantPlaySet las entradas (U1,R2,I1) y (U1,R3,I1). Esta tarea presenta una complejidad extra, dado que no se cuenta directamente con la información sobre los roles que ha jugado cada usuario en cada instancia, por lo que es necesario determinarlos a partir de las tareas. El criterio que vamos a utilizar para este fin es que si un usuario U1 realizó la tarea T1 en la instancia I1 se considerará que U1 jugó todos los roles autorizados a realizar T1.
Nuevo conflicto entre usuarios
Un conflicto entre usuarios implica que estos sean considerados como un único usuario desde el punto de vista del sistema y por lo tanto todo lo que hace un usuario debe considerarse que también fue realizado por los usuarios en conflicto. Se recorren las tablas DoneSet y CantPlaySet y para cada una de las entradas correspondientes a cada uno de los usuarios del conflicto agregamos una entrada similar pero para cada uno de los usuarios conflictivos restantes.
5 Validación y Verificación: Prototipo
Para validar y verificar la solución propuesta, se desarrolló un prototipo funcional. Este desarrollo en paralelo permitió la detección temprana de algunos errores de diseño y posterior corrección de los mismos en la solución propuesta. Consta de tres grandes módulos que son el Constraint Builder, el Constraint Engine y un simulador de un WMS (Mini WMS). El Constraint Builder es una aplicación visual engargada de la interacción con el SOf que permite realizar la especificación de las restricciones de autorización. El Constraint Engine es un componente COM engargado de la interacción con el WMS recibiendo y procesando los mensajes que fueron detallados en las secciones anteriores. Finalmente el Mini WMS es otra aplicación que permite realizar algunas tareas mínimas de un WMS (agregar usuarios, roles, permisos, autorizaciones) y se utiliza para simular los mensajes que el WMS enviaría al CE y de esta forma estudiar su comportamiento.
5.1 Constraint Builder
En versión de la herramienta se permite la especificación de restricciones de Separación de Funciones Estática y Dinámica.
En la Ilustración 6 se presenta un ejemplo de pantalla del prototipo de la herramienta. Cumpliendo con estas especificaciones el CB es capaz de interpretar la definición del modelo de roles a partir del archivo de intercambio en el formato definido para este fin y de ese modo permite al usuario la especificación de nuevas restricciones las cuales son almacenadas en la Constraint Data.
Ilustración 6 - Constraint Builder
En cuanto al Constraint Engine podemos agregar que también fue desarrollado en Visual Basic y que es capaz de recibir y procesar los mensajes del WMS pero no posee ninguna interfaz gráfica. Respecto a la Constraint
Data vale destacar que la misma se implementó como una base de datos de Microsoft Access en primer lugar porque es una aplicación accesible y en segundo lugar porque permite mover fácilmente los datos de una máquina a otra.
Ilustración 7 - Constraint Data
Este último aspecto es valorado en esta instancia que requiere demostraciones continuamente.
5.3 Mini WMS
El Mini WMS es una aplicación que intenta simular el comportamiento que tendría un WMS permitiendo de esta forma analizar la interacción con el Constraint Management Tool. En cuanto a su funcionalidad podemos destacar que permite realizar completamente el mantenimiento del modelo de roles, lo que sería la administración de Seguridad en un WMS: agregar y eliminar usuarios, roles y permisos así como también permite crear relaciones entre usuarios y roles y entre roles y permisos. Como hemos mencionado anteriormente, todo WMS que se precie de tal debería proveer una herramienta para la definición de los procesos que sería la encargada del mantenimiento de la información sobre la definición de los procesos.
Ilustración 8 - Menú de
En la Ilustración 8 se presenta el menú de administración de seguridad. Para realizar las pruebas se requiere que exista al menos un proceso almacenado, por lo que se definió uno de ejemplo llamado “Solicitud de Materiales” (Ilustración 9).
Finalmente en la pantalla principal del programa podemos ver que existes dos grandes marcos, uno llamado “Processes” y otro llamado “Functions”. El primero contiene una lista de selección con los procesos gerenciados por el WMS permitiendo agregar, eliminar y modificar los mismos.
El segundo agrupada las cuatro funciones que fueron definidas y que representan la comunicación entre el WMS y el Constraint Engine. El objetivo de las mismas en este entorno es permitir al usuario invocar manualmente las mismas especificando los parámetros deseados y de esta forma analizar el comportamiento del CE ante la simulación
del funcionamiento de un WMS real. Ilustración 10 Mini WMS - Menú Principal
6 Conclusiones
En este trabajo se trazó la necesidad de aplicar restricciones de autorización en modelos de control de acceso basados en roles (RBAC), primordialmente en los Sistemas de Gestión de Workflow, donde la seguridad es un aspecto substancial. Se focalizó en el tipo específico de restricciones de “Separación de Funciones”. A partir de ellas, se diseñó el Constraint Management Tool, aplicación que las contempla y permite aplicarlas sobre los procesos de un WMS.
Se demostró que el CMT es útil para la implementación de restricciones de autorización en modelos de roles. Simultáneamente, se probó que este tipo de restricciones pueden ser efectivamente aplicadas sobre Sistemas de Gestión de Workflow. Dado el enorme alcance de una solución completa de este tipo, algunos aspectos serán considerados en trabajos futuros.
La integración entre el CMT y un WMS se demostró posible, cumpliendo los principales objetivos: disminuir la complejidad de la automatización de procesos de negocios y aumentar la capacidad para solucionar requerimientos de seguridad complejos.
Restan aspectos para evaluar, algunos de los cuales se presentará a continuación, antes de que esta herramienta pueda ser considerada como madura. En el ínterin los Sistemas de Gestión de Workflow evolucionarán y la necesidad de contar con este tipo de funcionalidad podría aumentar hasta dejar de ser una característica opcional, para ser un requisito en todos ellos.
7 Trabajo Futuro
Se debería profundizar en el estudio de la interacción del CMT con un WMS de producción real para detectar posibles problemas de integración y performance identificando los principales puntos
débiles del sistema y proponer una solución para eliminarlos.
Algunas restricciones presentadas no fueron consideradas para la implementación por escapar al alcance definido. Estas y otras restricciones deberían ser identificadas y consideradas.
Los Sistemas de Gestión de Workflow evolucionan y progresivamente se adaptarán a las especificaciones de la Workflow Management Coalition. El Constraint Mangement Tool debería adaptarse paulatinamente para cumplir con estas especificaciones, principalmente a la Interfaz 5, eliminando el formato propietario definido en la arquitectura propuesta.
En la medida que la tecnología de Business Process Management evolucione, y en particular el estándar BPEL (Business Process Execution Language) soporte participantes humanos, será necesario extender la herramienta CMT para funcionar en una arquitectura orientada a servicios.
8 Bibliografía
[AH96a] Atluri V. and Huang W. An Authorization Model for Workflows. Proceedings of the
Fifth European Symposium on Research in Computer Security, Rome, Italy, and Lecture Notes in Computer Science, No.1146, Springer-Verlag, September, 1996.
[AS01] Gail-Joon Ahn & Michael E. Shin. “Role-Based Authorization Constraints
Specification Using Object Constraint Language”, 2001.
[BEa01] R. A. Botha & J. H. P. Eloff. “Separation of duties for access control enforcement in
workflow environments”, IBM SYSTEMS JOURNAL Vol. 40 No. 3, 2001.
[BFA99] Bertino E., Ferrari E, Atluri V. Specification and Enforcement of Authorization
Constraints in Workflow Management Systems”, 1999.
[CCF00] Casati F., Castano S., Fugini M : Managing Workflow Authorization Constraints
through Active Database Technology, 2000.
[FSG01] Ferraiolo D., Sandhu R., Gavrila S., Kuhn R., Chandramouli R. “Proposed NIST
Standard for Role-Based Access Control”, 2001.
[GGF98] Gligor V., Gavrila S., Ferraiolo D : On the Formal Definition of Separation-of-Duty
Policies and their Composition, 1998.
[GPS99] Grefen P., Pernici B., Sánchez G., Database Support for Workflow Management: The
WIDE Project; Kluwer Academic Publishers, February 1999; ISBN 0-7923-8414-8.
[MWA00] Miller J., Wu S., Arpinar I., Sheth A., Kochut J. Security for the METEOR
Workflow Management System, 2000.
[SA99] Sandhu R., Ahn G: The RSL99 language for Role-Based Separation of Duties
Constraints, 1999.
[SA00] Sandhu R., Ahn G: Role-based Authorization Constraints Specifications, 2000.
[SCFY96] Sandhu, Cohin, Feinstein, Youman: Role Based Access Control Models. IEEE
Computer 39, 2 (Febrero), 38 – 47, 1996.
[Stu00] Jake Sturm: Developing XML Solutions. Microsoft Press Book, 2000. ISBN
0-7356-0796-6.
[SZ97] Simon R., Zurko M: Separation of Duty in Role-Based Environments, 1997.
[WBK01] Wainer J., Barthelmess P., Kumar A.: W-RBAC - A workflow security model
incorporating controlled overriding of constraints, Octubre 2001.
[WfMC] Workflow Management Coalition. Workflow Reference Model 1.1, Jan. 1995,
Terminology and Glossary, Jun., 1996. Audit Data Specification, 1998. Workflow Security Considerations – White Paper, Feb., 1998.