Data Analysis Process

Ambos diseños son bastante similares en cuanto a sus componentes e interacciones entre ellos, sin embargo existen entre ellos muchas diferencias que se detallarán a continuación.

El diseño generado en el proyecto @lis (que en lo sucesivo será denominado diseño

original) consta de 7 agentes que interactúan entre si y una base de datos, el diseño propuesto consta de 4 agentes que interactúan y una base de datos. En cuanto al número de componentes, el diseño original es más complejo que el diseño propuesto por lo que la gestión del sistema podría ser más complicada en el diseño original.

En la figura 6.6 se presenta la arquitectura definida en ambos diseños haciendo énfasis en el flujo de información. Como se puede apreciar en dicha figura, el flujo de información en el diseño original es lineal, mientras que en el diseño propuesto es distribuida.

En el diseño original, cualquier falla en alguno de los agentes PA, GPA, LPA, SBA,

Finder o Provider deshabilitaría por completo el funcionamiento del sistema pues el flujo

de información estaría truncado. En el diseño propuesto solo una falla en el agente GestorDeRegistros deshabilitaría al sistema.

PA GPA LPA SBA Finder Provider BD XIA AgenteDeUsuario Proveedor GestorDeRegistros AgenteDeConsulta BD

Figura 6.6. Flujo de información en el diseño original (izquierda) y el propuesto (derecha).

Otro elemento que queda en evidencia al ver el flujo de información es que en el diseño original solo el agente Provider puede almacenar nueva información en la base de

datos, la información que el agente almacena es la referente a las reservaciones hechas o canceladas por el usuario, es decir que como parte del diseño original del sistema no se tomó en cuenta la posibilidad de actualizar el registro de ofertas turísticas. En el diseño propuesto hay también una sola entidad capaz de escribir en la base de datos, sin embargo la actualización del registro de ofertas turísticas si se tomó en cuenta en el diseño propuesto.

El sistema propuesto en ambos diseños es distribuido, en el diseño original, se prevé una distribución geográfica de las diferentes instancias de cada componente. Siendo más explícitos, se prevé la existencia de un único GPA, diversos PA creados dinámicamente bajo demanda de los usuarios, un LPA por cada país que participe en el proyecto, un SBA por cada LPA y un conjunto de Finder y Provider (1 de cada tipo) por cada SBA, así

mismo se prevé la existencia de una base de datos por cada país que participe en el proyecto. Esta estructura se muestra en la figura 6.7.

Como se puede apreciar en la figura 6.7, el GPA es un cuello de botella para el sistema ya que todas las peticiones que el usuario realiza y todas las respuestas que se le envían tienen que pasar a través del GPA, el cual no solo tiene que retransmitir sino que tiene que realizar tareas de planeación. Esto hace que el GPA sea un punto altamente falible del sistema.

En cuanto al diseño propuesto, no se establece una distribución geográfica para sus componentes, sino que se establece una cardinalidad múltiple para todos ellos. El diseño y la arquitectura propuesta están preparados para la multiplicidad de los componentes y al no establecer una política geográfica para la distribución de componentes, se tiene un grado de flexibilidad que permitirá que durante la implementación o inclusive una vez desplegado el sistema se modifique la distribución de los componentes según sea necesario.

PA 2 GPA LPA SBA Finder Provider BD XIA LPA SBA Finder Provider BD XIA LPA SBA Finder Provider BD XIA

País A País B País C

PA n PA 1

Figura 6.7. Multiplicidad y distribución de componentes en el diseño original.

En cuanto a las interacciones entre agentes (figura 6.8), el diseño original presenta un número reducido de ellas, básicamente el PA tiene tres posibles interacciones con el GPA, solicitar un itinerario, reservar un itinerario o cancelar una reservación y el GPA tiene las mismas interacciones con el LPA. El LPA tiene tres posibles interacciones con el SBA, solicitar una oferta, reservar una oferta o cancelar una reservación. El SBA tiene una sola interacción con el Finder, solicitar una oferta, y dos con el Provider, reservar una oferta o

cancelar una reservación. El XIA tiene las mismas interacciones que el SBA con el Finder

y Provider y el PA tiene tres interacciones posibles con el XIA, solicitar ofertas, reservar

una oferta y cancelar una reservación.

PA GPA LPA SBA

Finder Provider XIA Reservar itinerario Solicitar itinerario Cancelar itinerario Reservar sub-itinerario Solicitar sub-itinerario Cancelar sub-itinerario Reservar oferta Solicitar oferta Cancelar oferta Reservar oferta Solicitar oferta Cancelar oferta C an ce la r of er ta R es er va r of er ta S ol ic ita r of er ta C an ce la r of er ta R es er va r of er ta S ol ic ita r of er ta

Figura 6.8. Posibles interacciones entre agentes del diseño original.

Las interacciones en el diseño original son repetitivas, es decir que para cada entidad realiza las mismas interacciones que el resto pero a un nivel de abstracción diferente. Esto se debe a que el diseño está basado en el precepto de la descomposición. En el diseño propuesto las interacciones no se repiten, es decir que cada entidad activa interactúa de manera diferente con el resto del sistema. Esto implica que cada entidad está bien diferenciada del resto en cuanto a las tareas que realiza, en el diseño original no está bien clara la diferenciación en las tareas que cada entidad realiza. Ya que las tareas en el diseño original son las mismas y cambia solo el nivel de abstracción (en realidad, cambia el tipo de estructura de datos sobre la que se trabaja), cada interacción es similar pero crece en cuanto a complejidad de la estructura de datos intercambiada. Esto, además de incrementar

el tamaño y complejidad de los mensajes intercambiados, aumenta el número de mensajes intercambiados y la latencia del sistema. En otras palabras, en el diseño original se necesita un mayor número de interacciones y mensajes para realizar cada tarea.

La seguridad no es un factor que se haya tomado en cuenta en el diseño original mientras que el diseño propuesto se realizó tomando como base una política que busca resguardar la integridad y privacidad de la información en el sistema.

La disponibilidad del sistema es vulnerable en el diseño original, como se mostró en la figura 5, el GPA es la parte medular de la interacción entre el usuario y el sistema por lo que un ataque que reluciera o eliminara la capacidad de respuesta de este elemento estaría terminando casi por completo con la disponibilidad del sistema. Así mismo, la base de datos y lo agentes Finder son otro factor de vulnerabilidad de el diseño original. Ataques

que comprometieran la capacidad de respuesta de cualquiera de estos dos elementos restarían funcionalidad al sistema, sin embargo para afectar de manera total a la disponibilidad del sistema sería necesario atacar todas las instancias de estos elementos.

La política de seguridad en la que se baso el diseño propuesto no toma la disponibilidad como un factor fundamental del sistema. Dependiendo de la configuración final de los elementos del sistema, de su número y distribución, la disponibilidad del sistema puede ser más o menos vulnerable. Si por ejemplo, el sistema no se distribuye sino que se establece de manera centralizada, como se muestra en la figura 6, cualquier ataque que reluciera o eliminara la capacidad de respuesta de la base de datos o el AgenteDeConsulta o el GestorDeRegistros redundaría en una pérdida total de la disponibilidad del sistema. Por el contrario, si el sistema se establece de manera distribuida, la distribución afectaría el nivel de vulnerabilidad en cuanto a disponibilidad. Un esquema distribuido como el mostrado en la figura 6.9 reduciría la vulnerabilidad del sistema ya que sería necesario eliminar todas y cada una de las instancias del GestorDeRegistros o de la base de datos para la pérdida total de la disponibilidad.

AgenteDeUsuario Proveedor GestorDeRegistros AgenteDeConsulta BD GestorDeRegistros BD GestorDeRegistros BD AgenteDeUsuario AgenteDeConsulta AgenteDeUsuario Proveedor GestorDeRegistros AgenteDeConsulta BD

Figura 6.9. Diseño propuesto, configuración distribuida (izquierda) y configuración centralizada (derecha).

La distribución en el diseño original es rígida, pues se establece que la multiplicidad de los componentes es por país. Por lo tanto si solo hay un país, y su LPA, SBA, base de datos o agentes Finder son atacados, la disponibilidad del sistema sería eliminada.

original no existe ningún elemento o restricción que indique o permita que los elementos del sistema sean identificables, esto quiere decir que cualquier entidad puede formar parte del sistema en cualquier nivel.

Un atacante podría entrar al sistema e interactuar con cualquiera de sus elementos haciéndose pasar por cualquier otro de los elementos. De este modo, un atacante puede inventar reservaciones, eliminar reservaciones válidas, promover ofertas turísticas fraudulentas, etc. La privacidad de la información presente en el sistema, incluyendo información valiosa como números de tarjetas de crédito, es nula, cualquier entidad auténtica o maligna puede acceder a la información sin ninguna restricción.

La privacidad es uno de los factores tomados en cuenta en la política de seguridad en la que se basa el diseño propuesto, por lo tanto el sistema estará protegido en los términos que la política así lo indique. La política establece que existe un mecanismo a través del cual se pueda identificar y autenticar unívocamente a cada elemento del sistema. Con base en dicha identificación y autenticación, las interacciones y acciones están restringidas de modo que cada elemento del sistema solo pueda acceder a la información que le corresponde, de esta manera la privacidad de la información se mantiene. Por ejemplo, para que una entidad pueda acceder al perfil de un usuario (donde presumiblemente se almacenaría su número de tarjeta de crédito) deberá ser una entidad de tipo AgenteDeUsuario y tener la identidad del usuario al que le pertenece el perfil. Un atacante debería burlar el mecanismo de autenticación para poder acceder a esta información.

En cuanto a la integridad de la información, el diseño original es completamente vulnerable. No indica el uso de ningún mecanismo a través del cual se pueda verificar la integridad de la información y sin un mecanismo cualquier entidad tiene la posibilidad de modificar cualquier información en cualquier momento sin que esto pudiera ser detectado.

El diseño propuesto toma en cuenta la integridad del sistema e indica que en el sistema existirá un mecanismo a través del cual se puede verificar la integridad de la información en cualquier momento. Además de esto, el diseño indica que cada operación de lectura de información deberá de ser acompañado de una revisión de la integridad que si falla detiene la operación que se está realizando y genera una alerta, lo mismo sucede en el caso de cualquier operación de escritura añadiendo como paso final la actualización de la información de integridad.

Mediante el mecanismo de autenticación, el de verificación de integridad y el de no repudio, demás del uso adecuado de la distribución de los componentes del sistema, el diseño propuesto asegura la privacidad e integridad de la información y la disponibilidad del sistema, dentro de los límites descritos en la política de seguridad.