Restricciones de Autorización en Sistemas de Gestión de Workflow.

Transcripción

1 Restrccones de Autorzacón en Sstemas de Gestón de Workflow. Juan J. Moreno Qunteros 1, Martín Sorondo Peyre 2. Lus Joyanes Agular 3, 1 Uruguayo. Unversdad Pontfca de Salamanca, Campus de Madrd, Facultad de Informátca, Paseo de Juan XXIII, Tel Madrd, España. Unversdad Católca del Uruguay, Facultad de Ingenería y Tecnologías. Av. 8 de Octubre Tel. (598 2) Montevdeo, Uruguay, jmoreno@ucu.edu.uy 2 Uruguayo. Unversdad Católca del Uruguay, Facultad de Ingenería y Tecnologías Av. 8 de Octubre Tel. (598 2) Montevdeo, Uruguay, msorondo@adnet.com.uy 3 Español. Unversdad Pontfca de Salamanca, Campus de Madrd, Facultad de Informátca, Paseo de Juan XXIII, Tel Madrd, España. ljoyanes@fpablov.org RESUMEN Este trabajo presenta los lneamentos generales para la construccón de una herramenta de software para la especfcacón de restrccones de separacón de funcones. Ésta permtrá ser ntegrada con cualquer Sstema de Gestón de Workflow que utlce un modelo de segurdad basado en roles, aplcando así estas restrccones sobre los procesos automatzados en él. La separacón de funcones, como prncpo de segurdad, tene el objetvo de reducr el resgo de fraudes evtando que un ndvduo tenga la autordad sufcente en el sstema como para cometerlos por sus propos medos. Dos varedades se dentfcan y contemplan en este trabajo: requermentos que pueden ser verfcados en tempo de dseño (separacón de funcones estátca), y requermentos que solo pueden verfcarse en tempo de ejecucón (separacón de funcones dnámca). Se dscuten los prncpales aspectos de la ntegracón con el WMS, enfatzando aspectos de performance y dsmnucón de la complejdad de la automatzacón de procesos. Palabras clave: Workflow, Authorzaton, Restrctons, RBAC

2 1 Introduccón Una carenca bastante común de los modelos de autorzacón basados en roles es que no son capaces de modelar restrccones de autorzacón (restrccones en adelante) sobre los roles. Una restrccón típca, relevante y muy conocda en el área de la segurdad es la Separacón de Funcones cuyo objetvo es reducr el resgo de fraudes evtando que un ndvduo tenga la autordad sufcente en el sstema como para cometer un fraude por sus propos medos. Un ejemplo de una regla de negoco que refleja una restrccón de ese tpo sería: Para tener valdez, un cheque debe ser frmado por dos personas dferentes. El punto fundamental es que las restrccones de autorzacón o la separacón de funcones no están soportadas natvamente en los Workflow Management System (WMS). Esto cas sempre se puede lograr, dependendo de el Sstema de Gestón de Workflow, medante la codfcacón de las restrccones para cada tarea y en el lenguaje de programacón soportado por la herramenta; sn embargo esta solucón es bastante compleja, hace muy dfícl la especfcacón de restrccones y tene un problema fundamental y es que da por terra el prncpo fundamental de que usuaros no técncos puedan modelar sus flujos en el WMS. El objetvo de este trabajo es proponer los prncpales aspectos del desarrollo de una herramenta con soporte para la especfcacón de restrccones de separacón de funcones. La llamaremos Constrant Management Tool (en adelante CMT), y estará compuesta por una aplcacón vsual para la especfcacón de restrccones ( Constrant Bulder, en adelante CB) y por un componente que se encargará de la verfcacón de estas restrccones ( Constrant Engne, en adelante CE). El CMT necesta para su funconamento estar ntegrado y sncronzado con un WMS y por lo tanto esta ntegracón tambén formará parte de los lneamentos que veremos a contnuacón. En la Ilustracón 1 podemos ver una prmera aproxmacón a la arqutectura del sstema propuesto. Los componentes prncpales del esquema son el WMS y el CMT. Por un lado dsponemos de un Sstema de Gestón de Workflow, completo y funconando, que tendrá su propa arqutectura nterna y que será dstnta en cada uno de ellos dependendo de su fabrcante 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 Segurdad (SA) y el Dseñador de Procesos. Sobre la derecha de la Ilustracón 1 se encuentra el CMT, compuesto del CB y el CE, los que mantenen y comparten la nformacón sobre las restrccones, almacenada en un repostoro de datos (Constrant Data). La ntegracón del WMS con el CMT se realza a través de los tres repostoros de datos (Executon Knowledge, RBAC Data y Process Defnton) que podemos observar en el centro de la magen y a través de un canal de comuncacón entre el Workflow Engne y el Constrant Engne medante el cual realzan un ntercambo de mensajes que vamos a detallar más adelante y que permte la sncronzacón entre ambos componentes para asegurar el cumplmento de las restrccones. Ilustracón 1 Arqutectura del sstema

3 El Executon Knowledge engloba toda la nformacón dsponble acerca del estado de la ejecucón de los procesos en el Motor de Workflow. En partcular: cuales son los procesos que están ejecutando, en que estado están y quenes han actuado sobre cada proceso. Esta nformacón es necesara para aquellas restrccones que deben ser evaluadas en tempo de ejecucón y que se basan en nformacón hstórca. La RBAC Data contene toda la nformacón relatva al modelo de roles y autorzacones del WMS (Ilustracón 2) y es admnstrada úncamente por este últmo Ilustracón 2 Modelo de Roles La defncón del proceso ( Process Defnton ) contene la nformacón completa de los procesos que se necesta para que WMS los ejecute. Esto ncluye nformacón sobre las condcones de nco y fnalzacón, tareas, reglas para las transcones, usuaros y permsos asocados, etc. Las restrccones especfcadas en el CE por el Gerente de Segurdad (en adelante SOf Securty Offcer) son almacenadas en un repostoro prvado del CMT, el Constrant Data (CD). Esta CD contendrá otros datos requerdos para el funconamento del CMT y se mplementará como una base de datos relaconal, debdo a que el tempo de recuperacón de la nformacón nfluye drectamente sobre la performance del CE en responder a las solctudes del WMS. 2 Separacón de Funcones Implementacón Se utlzará un modelo de admnstracón por entdades en conflcto. Un conflcto entre entdades mplca que el resgo de fraude se ncremente s no se controlan cudadosamente las asocacones entre esas entdades. Las entdades que han sdo dentfcadas para el domno son: usuaros, permsos y roles. En la Tabla 1 podemos observar algunos ejemplos de estos conflctos. Conflcto Posble Roles conflctvos Permsos conflctvos Interpretacón como una regla de negoco Los roles Encargado de Ventas y Cajero son mutuamente excluyentes. Un msmo usuaro nunca puede recbr el permso de Crear orden de compra y Aprobar orden de compra Usuaros conflctvos Los membros de la msma famla pueden consprar para cometer un fraude. Tabla 1 - Entdades Conflctvas Como se ha menconado es posble dentfcar dos varantes de la separacón de funcones, la Separacón de Funcones estátca (SSoD Statc Separaton of Dutes) y la Separacón de Funcones Dnámca (DSoD Dnamc Separaton of Dutes), según el momento en que estos conflctos pueden ser verfcados. Para ambas se utlzará el método anteror de las entdades en conflcto. Pero s ben el concepto es smlar, requeren un análss e mplementacón completamente ndependentes que veremos en los sguentes apartados 3 Separacón de Funcones Estátca (SSoD) La Separacón de Funcones Estátca debe su nombre a que sus requermentos no dependen de la ejecucón de nngún proceso y por lo tanto pueden ser evaluados en tempo de dseño. El objetvo prncpal detrás de la Separacón de Funcones Estátca es prohbr la ntroduccón en la base de

4 autorzacones de relacones defndas como ncompatbles entre las entdades de nterés (usuaros, permsos y roles). Estas relacones ncompatbles o conflctos son defndas por el SOf 1 a través del Constrant Bulder y son almacenadas como restrccones en la CD. Por ejemplo un conflcto defndo entre los roles Cajero y Vendedor mplca que nngún usuaro podrá ser asgnado a ambos roles en nngún momento. Un conflcto entre los permsos Crear Orden de Compra y Aprobar Orden de Compra mplca que nngún usuaro podrá en nngún momento obtener ambos permsos a través de los roles que le son asgnados. Fnalmente, un conflcto entre usuaros mplca que los msmos sean consderados, a efecto de las autorzacones, como un únco usuaro porque pueden consprar para cometer un fraude, entonces, s exste una restrccón entre los roles Cajero y Vendedor y exste tambén otra restrccón entre los usuaros Juan y Jorge, s Juan está asgnado al rol Cajero entonces Jorge no podrá ser asgnado al rol Vendedor y vceversa. Se podría argumentar que la SSoD es muy restrctva para las operacones normales de una organzacón, sn embargo, es realmente útl para aplcar restrccones que alcancen a todos los procesos y se mantengan constantes a través del tempo sobre todo en grandes organzacones. El almacenamento de las restrccones de SSoD se realzará en tres conjuntos o coleccones, una para cada una de las entdades en conflcto: usuaros, roles y permsos que tendrán el nombre de Statc Conflctng User Set (SCUS), Statc Conflctng Role Set (SCRS) y Statc Conflctng Permsson Set (SCPS) respectvamente. Según podemos aprecar en la Tabla 2, cada elemento de estas coleccones, que llamaremos conflcto, será a su vez un conjunto y estará compuesto por al menos dos Usuaros, Roles o Permsos dstntos entre sí, respectvamente. U = un conjunto de usuaros, {u 1,, u n }. R = un conjunto de roles, {r 1,, r n }. P = un conjunto de permsos, {p 1,, p n }. cu = u,..., u }/ n 2 ( n) u U ( j) u { 1 n n cr = r,..., r }/ n 2 ( n) r R ( j) r r { 1 cp = p,..., p }/ n 2 ( n) p P ( j) p { 1 n SCUS = un conjunto de conflctos estátcos de usuaros, {cu 1,, cu n }. SCRS = un conjunto de conflctos estátcos de roles, {cr 1,, cr n }. SCPS = un conjunto de conflctos estátcos de permsos, {cp 1,, cp n }. u Tabla 2 - Defncón formal de las restrccones de SSoD 3.1 Implementacón de Restrccones de Separacón de Funcones Estátca Desde el punto de vsta de la mplementacón, una volacón a este tpo de restrccones se puede producr con cualquer modfcacón de la RBAC Data, por ejemplo la asgnacón de un Rol a un Usuaro o un Permso a un Rol. De acuerdo a la Arqutectura del Sstema de la Ilustracón 1, el responsable del mantenmento y actualzacón de la RBAC Data es el propo WMS, en partcular el Securty Agent y por otro lado el encargado del mantenmento y verfcacón de las restrccones es el CMT. Por lo tanto, deberá exstr una comuncacón entre estos dos de modo j j p j 1 Gerente de Segurdad o Securty Offcer (SOf)

5 que cada vez que el SA quera realzar un cambo en la RBAC Data 2 deberá notfcar al CMT del msmo (en realdad al CE), el que se encargará de verfcar s esta modfcacón vola o no las restrccones. S el cambo no produce nnguna volacón entonces se autorza al Securty Agent a realzarlo, pero en el caso contraro, se rechaza y se construye un mensaje ndcando el motvo de la volacón que será envado al SOf. Luego, éste podrá desstr de realzar el cambo o utlzar el CMT para modfcar las restrccones de modo que este sea aceptado. Con el objetvo de expresar más claramente la dea, se omtó ntenconalmente un detalle y es que no todas las modfcacones en la RBAC Data ntroducdas por el WMS pueden llegar a producr una volacón en las restrccones. En realdad estas modfcacones las podemos agrupar en tres categorías dstntas, modfcacones que pueden producr una volacón a las restrccones y que llamaremos modfcacones actvas, modfcacones que no pueden producr una volacón a las restrccones pero sn embargo requeren la realzacón de tareas de mantenmento en la Constrant Data (Ejemplo elmnacón de usuaros o roles) y que llamaremos modfcacones pasvas y fnalmente modfcacones que no tenen nngún efecto para el CMT y que llamaremos modfcacones neutras, como se resume en la Tabla 3. Actvas Pasvas Neutras Agregar UA Elmnar Usuaro Agregar Usuaro Agregar PA Elmnar Rol Agregar Rol Agregar RH Elmnar Permso Agregar Permso - Elmnar UA - - Elmnar PA - - Elmnar RH - Tabla 3 - Posbles modfcacones realzadas por el WMS sobre la RBAC Data 3. La comuncacón que fue menconada entre el WMS y el CMT se realza a través del ntercambo de mensajes entre ellos y úncamente para el caso de las modfcacones actvas o pasvas ya que las modfcacones neutras no tenen efecto sobre el WMS. Estos mensajes a su vez podemos clasfcarlos en dos tpos: mensajes de notfcacón y mensajes de autorzacón (Ilustracón 3). Los mensajes de notfcacón son envados por el WMS haca el CMT (undrecconales) y se utlzan para notfcar las modfcacones pasvas. Los mensajes de autorzacón tambén son envados por el WMS pero en este caso solctan la autorzacón del CMT para realzar una modfcacón actva a lo que el CMT debe responder (bdrecconales) habltando o no la modfcacón según esta produzca una volacón a las restrccones. 3.2 Modfcacones actvas Ilustracón 3 Intercambo de Mensajes, SSoD. Una relacón de UA (User Assgnment) es una dupla (Usuaro, Rol) que mplca que se autorza al Usuaro a poder jugar el Rol especfcado en la relacón. Esta modfcacón, al gual que las demás modfcacones actvas, requere un análss prevo de la CD para verfcar que la msma no vola las restrccones establecdas. El análss consste en verfcar que el usuaro no este autorzado a jugar nngún rol marcado como conflctvo con el rol que se quere autorzar, verfcar que nnguno 2 Esta stuacón se producrá cada vez que el Gerente realce algún cambo en la segurdad utlzando la herramenta para la Admnstracón de Segurdad provsta por el WMS. Ejemplos: otorgar un permso a un rol, asgnar un rol a un usuaro, etc. 3 De acuerdo al modelo de la Ilustracón 2 Modelo de Roles

6 de los permsos que serán otorgados al usuaro a través del rol en cuestón están dentfcados como conflctvos con alguno de los permsos a los que el usuaro ya está autorzado y verfcar que las dos reglas anterores tambén se cumplen para cada uno de los usuaros dentfcados como conflctvos con el usuaro en cuestón. S alguna de las verfcacones no se cumple entonces el CMT devuelve un mensaje negando la modfcacón y explcando el motvo. Una relacón de PA (Permsson Assgnment) es una dupla (Rol, Permso) que mplca la autorzacón de un Permso a un Rol. Al gual que en el caso anteror, la nsercón de una relacón de este tpo en la CD requere un análss prevo de la msma, consstente en verfcar que el Rol no tenga asgnado nngún permso dentfcado como conflctvo con el permso que se quere agregar (en ese caso se transformaría en un rol nutlzable), para cada uno de los usuaros que están asgnados al rol de la relacón PA, es decr para aquellos usuaros que obtendrán este nuevo permso, verfcar que no exsten conflctos entre el permso en cuestón y los demás permsos que ya tene asgnados y verfcar que esto tambén se cumple para cada uno de los usuaros dentfcados como conflctvos con cada uno de los usuaros que obtenen el nuevo permso. La relacón RH (Role Herarchy) se realza entre dos roles (Padre,Hjo) y sgnfca que el rol Hjo depende del rol Padre en la jerarquía, mplcando que el padre heredará todos los permsos asgnados al Hjo. En este caso es precso verfcar que Padre e Hjo no estén dentfcados como conflctvos, verfcar que no exstan conflctos entre los permsos actuales del Padre y los permsos que pasará a tener a partr de la herenca de los permsos del Hjo, verfcar que no exsta nngún usuaro asgnado al rol Padre y que a su vez esté asgnado a un rol en conflcto con el rol Hjo, para cada usuaro asgnado al rol Padre verfcar que los permsos que obtendrá no generan conflctos con los que ya tene asgnados y fnalmente verfcar que las dos reglas anterores tambén se cumplen para los usuaros en conflcto con cada uno de los usuaros que se verfca. 3.3 Optmzacón de las Modfcacones actvas S ben el objetvo de la nvestgacón en este momento no es la optmzacón de la solucón vamos a realzar una pequeña modfcacón a los procedmentos menconados recentemente con el objetvo de optmzar y smplfcar el resultado. La optmzacón se realzará al momento de verfcar los conflctos entre dos roles. Supongamos que tenemos los permsos P1, P2, P3 y p4, los roles R1 y R2 de acuerdo a la Ilustracón 4. El procedmento de verfcacón de la exstenca de un conflcto estátco entre R1 y R2 consste en verfcar en prmer lugar que no exsta una restrccón estátca explícta especfcada por el SOf que establezca que R1 y R2 son roles conflctvos. En segundo lugar consste en verfcar que para cada uno de los permsos asgnados a R1 no exsta nngún permso conflctvo con este asgnado a R2. Ilustracón 4 Intercambo de Mensajes SSoD. Ahora ben, s exste una restrccón estátca entre dos permsos asgnados a dos roles dstntos, por ejemplo entre P1 y P4, esto mplca que los roles, en este caso R1 y R2, se transformarán por transtvdad en roles conflctvos y por lo tanto a los fnes del sstema esto es déntco a la exstenca de una restrccón explícta entre R1 y R2. Entonces, para smplfcar y optmzar el procedmento de verfcacón de conflctos entre dos roles vamos a ntroducr un tpo de restrccones entre roles que llamaremos restrccones nferdas. Estas restrccones son déntcas a las restrccones entre roles pero no son realzadas por el SOf sno que son nferdas por el sstema cada vez que el msmo ngresa una restrccón entre Permsos. Por ejemplo, s se agrega una restrccón entre P1 y P4 el sstema nferrá que exste una restrccón entre R1 y R2 y la agregará a la base con una bandera para dstngurlas de

7 las restrccones explíctas. Esta dstncón es necesara para el caso posteror de que se elmne la restrccón entre los permsos P1 y P4, requrendo así elmnar la restrccón nferda. Consderando esta pequeña modfcacón ahora el procedmento de verfcacón de la exstenca de un conflcto estátco entre dos roles se lmta úncamente a verfcar que no exsta una restrccón entre estos dos roles ya que las restrccones entre sus permsos están contempladas por las restrccones nferdas entre roles. Sn embargo, la desventaja de esta aproxmacón surge al momento de elmnar una restrccón entre Permsos porque mplca reprocesar las restrccones nferdas relaconadas a la restrccón elmnada para determnar s las msmas se mantenen o tambén deben ser removdas. En el ejemplo anteror, s se elmna la restrccón entre P1 y P3 entonces debe elmnarse tambén la restrccón nferda entre R1 y R2, pero esto no debe ser así s además exstía otra restrccón entre los permsos P2 y P Modfcacones Pasvas Como menconamos, las modfcacones pasvas requeren la realzacón de tareas de mantenmento en la CD. A grandes rasgos podemos decr que estas tareas conssten en elmnar las referencas en la CD a la entdad o relacón que acaba de ser elmnada y no tene mucho sentdo entrar en detalle sobre las msmas ya que son relatvamente trvales. 3.5 Especfcacón de Restrccones de Separacón de Funcones Estátca La especfcacón de las restrccones de Separacón de Funcones Estátca se realza a través del menconado Constrant Bulder. En este, el SOf debe poder acceder a la nformacón sobre la defncón del proceso (tareas que lo componen y flujos), roles, usuaros y autorzacones como para lograr una buena comprensón del sstema y comprobar la efectvdad de las restrccones especfcadas o las restrccones que se van a especfcar. Cuando el SOf especfca una nueva restrccón el sstema debe realzar algunas verfcacones para comprobar que la CD quedará en un estado consstente luego de la nsercón de la msma en la base restrccones. Por ejemplo, s exste un usuaro Juan asgnado a los roles R1 y R2, la nsercón de una nueva restrccón entre los roles R1 y R2 dejaría la base en un estado nconsstente porque se estaría volando la msma desde el momento de su creacón. A contnuacón vamos a detallar los procedmentos de verfcacón de consstenca que van a depender del tpo de restrccón que se este nsertando pero a grandes rasgos podríamos decr que conssten en comprobar que no exstan casos como el del ejemplo anteror y en su defecto prohbr la ntroduccón de la restrccón en la base y poner al tanto al SOf del conflcto en cuestón. 3.6 Nuevo conflcto entre permsos En este caso la tarea consste en analzar la RBAC Data en busca de roles que estén asgnados a dos o más de los permsos en conflcto. S se encuentra un rol de este estlo entonces se rechaza la restrccón y se pone en conocmento del SOf cual es rol que generó el problema. Fnalmente, s se permte agregar la restrccón a la CD, es necesaro calcular las restrccones de roles estátcas nferdas de acuerdo a lo establecdo en el apartado Nuevo conflcto entre roles Antes de agregar un conflcto entre roles es necesaro analzar las asgnacones entre usuaros y roles para detectar s exste algún usuaro asgnado a dos o más de los roles ncludos en la restrccón en cuyo caso no se podría nsertar la msma en la CD.

8 3.8 Nuevo conflcto entre usuaros La nsercón de una nueva restrccón de esta clase en la CD requere que prevamente se hayan analzado los roles que están asgnados a los usuaros de la msma para asegurar de que no exstan conflctos entre ellos. En este caso no es necesaro buscar conflctos entre los permsos de cada usuaro ya que partmos de la base de que s exste alguno entonces tambén exstrá una restrccón estátca de roles nferda que lo contemple s corresponde. 4 Separacón de Funcones Dnámca (DSoD) La separacón de funcones dnámca provee mayor flexbldad que la separacón de funcones estátca y permte aplcar restrccones que se ajustan más al funconamento de las organzacones humanas controlando la actvacón y el uso de los roles en tempo de ejecucón en lugar de las relacones entre Usuaros, Permsos y Roles en tempo de dseño. Utlzando nuevamente el modelo de admnstracón por entdades en conflcto vamos a presentar los roles dnámcamente conflctvos, los permsos dnámcamente conflctvos y los usuaros dnámcamente conflctvos. En la separacón de funcones dnámca se permte que los roles conflctvos tengan usuaros en común sempre y cuando no asuman ambos roles en una msma nstanca de un proceso. En el ejemplo anteror de los roles Cajero y Vendedor, se permte que un usuaro tenga ambos roles, pero s en un proceso actuó como Cajero no podrá hacerlo como Vendedor y vceversa. En segundo lugar hemos de menconar a los permsos dnámcamente conflctvos como podrían ser Crear Orden de Compra y Aprobar Orden de Compra. El msmo razonamento anteror se aplca en este caso permtendo que los Usuaros obtengan ambos permsos a través de las asgnacones a roles pero mpdendo que logren el ejercco de ambos en una msma nstanca de proceso. Esto no mpde que s Juan ejercó el permso de Crear Orden de Compra en una nstanca pueda ejercer Aprobar Orden de Compra en otra. Fnalmente para los usuaros dnámcamente conflctvos se aplca el msmo crtero y por lo tanto s Juan y Jorge están dentfcados como conflctvos y Jorge actuó como Cajero en una nstanca de un proceso se nterpretará como que s Jorge tambén lo hubera hecho. En esta stuacón la comuncacón entre el CMT y el WMS se ncrementa ya que ahora el CMT deberá responder a las modfcacones ntroducdas en la RBAC Data al tempo que partcpar en las decsones de autorzacón para cada tarea, verfcando las restrccones dnámcas. 4.1 Implementacón de Restrccones de Separacón de Funcones Dnámca Cada vez que se quere verfcar la autorzacón de un usuaro para realzar una tarea es necesaro analzar las restrccones exstentes que aplcan al msmo y tambén la hstora de sus ejecucones, es decr, las tareas que ha realzado prevamente. S consderamos todos los procesos, tareas y usuaros de una organzacón entonces el volumen de la nformacón a consultar es demasado grande y sería nvable mantener al usuaro en espera mentras se realzan las verfcacones. La solucón que vamos a proponer se basa en que el CMT mantenga una parte de estos datos en la CD. Esta solucón tene las desventajas aparejadas con el mantenmento de nformacón redundante pero logra reducr notablemente el tempo de verfcacón por dos motvos: el volumen de nformacón es mucho menor porque solo almacena la nformacón relevante y, el tempo de respuesta es mínmo porque se estaría accedendo a un RDBMS. En realdad, por cuestones de optmzacón vamos a estar almacenando nformacón sobre lo que cada usuaro no puede hacer en vez de almacenar lo que hzo y a partr de esto calcular lo que puede hacer. De esta forma trasladamos una parte del procesamento (calcular lo que no puede hacer) a un momento en que

9 la latenca no es mportante que es cuando el usuaro fnalza una tarea, reducmos más aún el volumen de los datos que hay que analzar en cada verfcacón y ganamos velocdad porque corroborar la autorzacón de un usuaro a realzar una tarea se lmtará a chequear que no exsta una entrada en la tabla donde se almacena lo que el usuaro no puede hacer. Vale destacar que esto aplca a la verfcacón de autorzacones en cuanto a las restrccones y es ndependente de las verfcacones prevas que realza el Securty Agent o Agente de Segurdad. La nformacón sobre lo que el usuaro no pude hacer se almacena en dos conjuntos o coleccones llamados CantDoSet y CantPlaySet. En el prmero se almacenan las tareas que los usuaros no pueden realzar de la forma (Usuaro, Tarea, Instanca) que se nterpreta cómo: El usuaro Usuaro no puede realzar la tarea Tarea en la nstanca Instanca. En el segundo se almacenan los roles que los usuaros no pueden jugar de la forma (Usuaro, Rol, Instanca) y se nterpreta de la msma forma. En la Tabla 4 podemos observar la defncón formal de estas estructuras. U = un conjunto de usuaros, {u 1,, u n }. R = un conjunto de roles, {r 1,, r n }. P = un conjunto de permsos, {p 1,, p n }. cu = u,..., u }/ n 2 ( n) u U ( j) u { 1 n n cr = r,..., r }/ n 2 ( n) r R ( j) r r { 1 cp = p,..., p }/ n 2 ( n) p P ( j) p { 1 n u DCUS 4 = un conjunto de conflctos dnámcos de usuaros, {cu 1,, cu n }. DCRS 5 = un conjunto de conflctos dnámcos de roles, {cr 1,, cr n }. DCPS 6 = un conjunto de conflctos dnámcos de permsos, {cp 1,, cp n }. T = un conjunto de tareas, {task 1,,task n } I = un conjunto de nstancas de proceso, {ns 1,,ns n } dn = ( user, task, ns) / user U task T ns I cd = ( user, task, ns) / user U task T ns I cp = ( user, role, ns) / user U role R ns I DoneSet = un conjunto de DoneItems, { dn 1,, dn n } CantDoSet = un conjunto de CantDoItems, { cd 1,, cd n } CantPlaySet = un conjunto de CantPlayItems, { cp 1,, cp n } 4.2 Descrpcón de la comuncacón Tabla 4- Defncón formal de las restrccones de DSoD En la Ilustracón 5 podemos observar el ntercambo de mensajes que ocurre entre el CE y el WE para asegurar el cumplmento de las restrccones de DSoD. A contnuacón vamos a comentar cual es la utldad de estos mensajes y de que forma logran cumplr con su objetvo. j j p j 4 Dnamc Conflctng User Set 5 Dnamc Conflctng Role Ser 6 Dnamc Conflctng Permsson Set

10 Ilustracón 5 Intercambo de Mensajes, SSoD. Done. La funcón Done es nvocada por el WMS cada vez que una tarea acaba de ser realzada por un usuaro en una nstanca de proceso. Recbe como parámetros el usuaro, la tarea realzada y la nstanca de proceso. Es utlzada por el CE para actualzar la CD ya que el evento ocurrdo puede haber producdo una modfcacón en las autorzacones. El procedmento que realza es: Agregar una entrada en la tabla DoneSet. Para cada permso en conflcto con el permso de la tarea realzada agregar una entrada en la tabla CantDoSet. Agregar una entrada en la tabla CantPlaySet para cada Rol en conflcto con los Roles asgnados al permso para realzar la tarea. Repetr los dos pasos anterores para cada Usuaro en conflcto con el Usuaro en cuestón. Fnsh Una vez que fnalza una nstanca de proceso es necesaro elmnar toda la nformacón referente a ella de la CD, elmnando todas sus entradas en las tablas DoneSet, CantDoSet y CantPlaySet. El objetvo de esta tarea es reducr la cantdad de datos en la CD y por lo tanto reducr el espaco de búsqueda, salvando una caída en la performance del CE al momento de verfcar las restrccones. Este procedmento se realza a través de la funcón Fnsh que debe ser nvocada por el WMS cada vez que fnalza una nstanca de proceso y que recbe como parámetro el dentfcador de la nstanca que acaba de fnalzar. La labor de esta funcón es: Recorrer la tabla DoneSet elmnando las entradas con referenca a la nstanca de proceso. Idem para las tablas CantDoSet y CantPlaySet. Vale destacar que se supone que una vez fnalzada una nstanca de proceso, ésta nunca resucta. S así fuera, no se debería elmnar la nformacón de la CD. Who Who es una de las funcones prncpales del CMT. Retorna una lsta con los usuaros autorzados a realzar una tarea en una nstanca de proceso que recbe como parámetro. Identfca los usuaros autorzados a realzar la tarea en su correspondente proceso y luego chequea los msmos contra las restrccones dnámcas para ver s realmente están autorzados. El procedmento consste en: Identfcar los Roles autorzados a realzar la tarea. Determnar los Usuaros autorzados a jugar los Roles dentfcados. Verfcar para cada uno de los usuaros que no exsta una entrada en la tabla CantDoSet que mpda la realzacón de la tarea en la nstanca de proceso. Para cada usuaro, verfcar que no exsta una entrada en la tabla CantPlaySet que mpda al usuaro jugar alguno de los roles autorzados a realzar esa tarea en la nstanca.

11 CanDo La funcón CanDo es smlar a la funcón Who pero en vez de determnar los usuaros autorzados a realzar una tarea en una nstanca de proceso determna s un usuaro, recbdo cómo parámetro, esta autorzado a realzar una tarea en una nstanca de proceso. Retorna Verdadero o Falso. Conceptualmente el procedmento es nvocar la funcón Who y verfcar s el usuaro pertenece a la lsta de usuaros generada. Por cuestones de performance se realza un proceso más efcente: Identfcar los Roles autorzados a realzar la tarea. Determnar s el Usuaro está autorzado a jugar alguno de los Roles dentfcados. Verfcar que no exsta una entrada en la tabla CantDoSet para el usuaro en cuestón que mpda la realzacón de la tarea en esa nstanca. Verfcar que no exsta una entrada en la tabla CantPlaySet que mpda al usuaro jugar alguno de los roles autorzados a realzar la tarea en esa nstanca de proceso. 4.3 Especfcacón de Restrccones de Separacón de Funcones Dnámca Estas restrccones, al gual que las anterores, son especfcadas por el SOf a través del Constrant Bulder. La dferenca radca en que al nsertar una nueva restrccón no es necesaro realzar un chequeo de nconsstencas porque estas no ocurren con esta varedad de SoD. Sí hay que consderar que al agregar un nuevo conflcto, puede haber nstancas de proceso en ejecucón, lo que mplca que la nueva restrccón no va surtr efecto sobre nnguna de ellas. Por ejemplo, una organzacón tene un proceso automatzado con tareas T1 y T2, permsos P1 Y P2 ambos asgnados a un rol R y autorzados a realzar las msmas tareas, y fnalmente una cantdad x de usuaros autorzados a jugar el rol. Un día esta organzacón aplca una polítca de separacón de funcones sobre sus procesos automatzados: los usuaros que realzan las tareas T1 y T2 deben ser dstntos. El SOf, utlzando el CB, especfca un nuevo conflcto dnámco entre los permsos P1 y P2. A partr de ese momento cada vez que un usuaro realce la tarea T1 se agregará una entrada en la tabla CantPlaySet, mpdendo que realce la tarea T2. Pero, cualquer usuaro podría realzar la tarea T2 en las nstancas de proceso que hubera ncado antes de que se especfcara la nueva restrccón (no exste nnguna entrada que lo mpda en la tabla CantPlaySet) Por este motvo, al agregar una restrccón se deben realzar tareas para mantener actualzada la nformacón de la Constrant Data evtando que ocurra un caso como el planteado. Otra solucón podría ser manejar versones de las defncones de procesos omtendo estos procedmentos. Las nuevas restrccones se aplcarían solo sobre las nstancas de proceso creadas posterormente a la defncón de la nueva restrccón y no sobre las nstancas que ya estaban ejecutando. A pesar de su sencllez se optó por la prmera alternatva, consderando que hay tres tpos de restrccones (permsos, roles y usuaros) y que cada nueva restrccón generaría una nueva versón de la defncón del proceso, producendo un crecmento ncontrolable del número de versones. Nuevo conflcto entre permsos Al agregar un nuevo conflcto entre permsos se debe chequear las tareas que han realzado los usuaros en los procesos actvos para actualzar las entradas en la CantDoSet. Por ejemplo en un proceso con dos tareas T1 y T2 cuando se ngresa un nuevo conflcto entre T1 Y T2 es necesaro actualzar la tabla CantDoSet para que todos los usuaros que realzaron la tarea T1 no puedan realzar la T2. Se recorre la tabla DoneSet e nserta una nueva entrada en la tabla CantDoSet de la forma (Usuaro, T2, Instanca) para cada entrada en DoneSet donde la tarea sea gual a T1. Nuevo conflcto entre roles

12 Al agregar un nuevo conflcto entre roles es precso nsertar, para cada usuaro que halla jugado alguno de los roles del nuevo conflcto, una nueva entrada en la tabla CantPlaySet para cada uno de los roles restantes del conflcto. Es decr que s tenemos un nuevo conflcto entre los roles R1, R2 y R3 y exste un usuaro U1 que en una nstanca de proceso determnada I1 actuó como R1 entonces es necesaro agregar en la tabla CantPlaySet las entradas (U1,R2,I1) y (U1,R3,I1). Esta tarea presenta una complejdad extra, dado que no se cuenta drectamente con la nformacón sobre los roles que ha jugado cada usuaro en cada nstanca, por lo que es necesaro determnarlos a partr de las tareas. El crtero que vamos a utlzar para este fn es que s un usuaro U1 realzó la tarea T1 en la nstanca I1 se consderará que U1 jugó todos los roles autorzados a realzar T1. Nuevo conflcto entre usuaros Un conflcto entre usuaros mplca que estos sean consderados como un únco usuaro desde el punto de vsta del sstema y por lo tanto todo lo que hace un usuaro debe consderarse que tambén fue realzado por los usuaros en conflcto. Se recorren las tablas DoneSet y CantPlaySet y para cada una de las entradas correspondentes a cada uno de los usuaros del conflcto agregamos una entrada smlar pero para cada uno de los usuaros conflctvos restantes. 5 Valdacón y Verfcacón: Prototpo Para valdar y verfcar la solucón propuesta, se desarrolló un prototpo funconal. Este desarrollo en paralelo permtó la deteccón temprana de algunos errores de dseño y posteror correccón de los msmos en la solucón propuesta. Consta de tres grandes módulos que son el Constrant Bulder, el Constrant Engne y un smulador de un WMS (Mn WMS). El Constrant Bulder es una aplcacón vsual engargada de la nteraccón con el SOf que permte realzar la especfcacón de las restrccones de autorzacón. El Constrant Engne es un componente COM engargado de la nteraccón con el WMS recbendo y procesando los mensajes que fueron detallados en las seccones anterores. Fnalmente el Mn WMS es otra aplcacón que permte realzar algunas tareas mínmas de un WMS (agregar usuaros, roles, permsos, autorzacones) y se utlza para smular los mensajes que el WMS envaría al CE y de esta forma estudar su comportamento. 5.1 Constrant Bulder En versón de la herramenta se permte la especfcacón de restrccones de Separacón de Funcones Estátca y Dnámca. En la Ilustracón 6 se presenta un ejemplo de pantalla del prototpo de la herramenta. Cumplendo con estas especfcacones el CB es capaz de nterpretar la defncón del modelo de roles a partr del archvo de ntercambo en el formato defndo para este fn y de ese modo permte al usuaro la especfcacón de nuevas restrccones las cuales son almacenadas en la Constrant Data. Ilustracón 6 - Constrant Bulder 5.2 Constrant Engne

13 En cuanto al Constrant Engne podemos agregar que tambén fue desarrollado en Vsual Basc y que es capaz de recbr y procesar los mensajes del WMS pero no posee nnguna nterfaz gráfca. Respecto a la Constrant Data vale destacar que la msma se mplementó como una base de datos de Mcrosoft Access en prmer lugar porque es una aplcacón accesble y en segundo lugar porque permte mover fáclmente los datos de una máquna Ilustracón 7 - Constrant Data a otra. Este últmo aspecto es valorado en esta nstanca que requere demostracones contnuamente. 5.3 Mn WMS El Mn WMS es una aplcacón que ntenta smular el comportamento que tendría un WMS permtendo de esta forma analzar la nteraccón con el Constrant Management Tool. En cuanto a su funconaldad podemos destacar que permte realzar completamente el mantenmento del modelo de roles, lo que sería la admnstracón de Segurdad en un WMS: agregar y elmnar usuaros, roles y permsos así como tambén permte crear relacones entre usuaros y roles y entre roles y permsos. Como hemos menconado anterormente, todo WMS que se prece de tal debería proveer una herramenta para la defncón de los procesos que sería la encargada del mantenmento de la nformacón sobre la defncón de los procesos. Ilustracón 8 - Menú de admnstracón de segurdad Ilustracón 9 Proceso de ejemplo, Solctud de Materales

14 En la Ilustracón 8 se presenta el menú de admnstracón de segurdad. Para realzar las pruebas se requere que exsta al menos un proceso almacenado, por lo que se defnó uno de ejemplo llamado Solctud de Materales (Ilustracón 9). Fnalmente en la pantalla prncpal del programa podemos ver que exstes dos grandes marcos, uno llamado Processes y otro llamado Functons. El prmero contene una lsta de seleccón con los procesos gerencados por el WMS permtendo agregar, elmnar y modfcar los msmos. El segundo agrupada las cuatro funcones que fueron defndas y que representan la comuncacón entre el WMS y el Constrant Engne. El objetvo de las msmas en este entorno es permtr al usuaro nvocar manualmente las msmas especfcando los parámetros deseados y de esta forma analzar el comportamento del CE ante la smulacón del funconamento de un WMS real. Ilustracón 10 Mn WMS - Menú Prncpal 6 Conclusones En este trabajo se trazó la necesdad de aplcar restrccones de autorzacón en modelos de control de acceso basados en roles (RBAC), prmordalmente en los Sstemas de Gestón de Workflow, donde la segurdad es un aspecto substancal. Se focalzó en el tpo específco de restrccones de Separacón de Funcones. A partr de ellas, se dseñó el Constrant Management Tool, aplcacón que las contempla y permte aplcarlas sobre los procesos de un WMS. Se demostró que el CMT es útl para la mplementacón de restrccones de autorzacón en modelos de roles. Smultáneamente, se probó que este tpo de restrccones pueden ser efectvamente aplcadas sobre Sstemas de Gestón de Workflow. Dado el enorme alcance de una solucón completa de este tpo, algunos aspectos serán consderados en trabajos futuros. La ntegracón entre el CMT y un WMS se demostró posble, cumplendo los prncpales objetvos: dsmnur la complejdad de la automatzacón de procesos de negocos y aumentar la capacdad para soluconar requermentos de segurdad complejos. Restan aspectos para evaluar, algunos de los cuales se presentará a contnuacón, antes de que esta herramenta pueda ser consderada como madura. En el íntern los Sstemas de Gestón de Workflow evoluconarán y la necesdad de contar con este tpo de funconaldad podría aumentar hasta dejar de ser una característca opconal, para ser un requsto en todos ellos. 7 Trabajo Futuro Se debería profundzar en el estudo de la nteraccón del CMT con un WMS de produccón real para detectar posbles problemas de ntegracón y performance dentfcando los prncpales puntos

15 débles del sstema y proponer una solucón para elmnarlos. Algunas restrccones presentadas no fueron consderadas para la mplementacón por escapar al alcance defndo. Estas y otras restrccones deberían ser dentfcadas y consderadas. Los Sstemas de Gestón de Workflow evoluconan y progresvamente se adaptarán a las especfcacones de la Workflow Management Coalton. El Constrant Mangement Tool debería adaptarse paulatnamente para cumplr con estas especfcacones, prncpalmente a la Interfaz 5, elmnando el formato propetaro defndo en la arqutectura propuesta. En la medda que la tecnología de Busness Process Management evolucone, y en partcular el estándar BPEL (Busness Process Executon Language) soporte partcpantes humanos, será necesaro extender la herramenta CMT para funconar en una arqutectura orentada a servcos. 8 Bblografía [AH96a] Atlur V. and Huang W. An Authorzaton Model for Workflows. Proceedngs of the Ffth European Symposum on Research n Computer Securty, Rome, Italy, and Lecture Notes n Computer Scence, No.1146, Sprnger-Verlag, September, [AS01] Gal-Joon Ahn & Mchael E. Shn. Role-Based Authorzaton Constrants Specfcaton Usng Object Constrant Language, [BEa01] R. A. Botha & J. H. P. Eloff. Separaton of dutes for access control enforcement n workflow envronments, IBM SYSTEMS JOURNAL Vol. 40 No. 3, [BFA99] Bertno E., Ferrar E, Atlur V. Specfcaton and Enforcement of Authorzaton Constrants n Workflow Management Systems, [CCF00] Casat F., Castano S., Fugn M : Managng Workflow Authorzaton Constrants through Actve Database Technology, [FSG01] Ferraolo D., Sandhu R., Gavrla S., Kuhn R., Chandramoul R. Proposed NIST Standard for Role-Based Access Control, [GGF98] Glgor V., Gavrla S., Ferraolo D : On the Formal Defnton of Separaton-of-Duty Polces and ther Composton, [GPS99] Grefen P., Pernc B., Sánchez G., Database Support for Workflow Management: The WIDE Project; Kluwer Academc Publshers, February 1999; ISBN [MWA00] Mller J., Wu S., Arpnar I., Sheth A., Kochut J. Securty for the METEOR Workflow Management System, [SA99] Sandhu R., Ahn G: The RSL99 language for Role-Based Separaton of Dutes Constrants, [SA00] Sandhu R., Ahn G: Role-based Authorzaton Constrants Specfcatons, [SCFY96] Sandhu, Cohn, Fensten, Youman: Role Based Access Control Models. IEEE Computer 39, 2 (Febrero), 38 47, [Stu00] Jake Sturm: Developng XML Solutons. Mcrosoft Press Book, ISBN [SZ97] Smon R., Zurko M: Separaton of Duty n Role-Based Envronments, [WBK01] Waner J., Barthelmess P., Kumar A.: W-RBAC - A workflow securty model ncorporatng controlled overrdng of constrants, Octubre [WfMC] Workflow Management Coalton. Workflow Reference Model 1.1, Jan. 1995, Termnology and Glossary, Jun., Audt Data Specfcaton, Workflow Securty Consderatons Whte Paper, Feb., 1998.