DESARROLLO DE SERVICIOS WEB SEGUROS EN MULEESB DEVELOPMENT OF SECURE WEB SERVICES ON MULEESB Ing. Claudia I. Castro Zamora1, Ing. Ernesto Gil Aranguren2 1 ISPJAE, CUBA, [email protected] 2 ISPJAE, CUBA, [email protected]

RESUMEN: En la actualidad el tema de integración de aplicaciones ha cobrado importancia teniendo en cuenta que las empresas contienen una gran cantidad de soluciones heterogéneas que necesitan intercambiar información entre sí. Con el objetivo de dar respuesta a esta problemática han surgido un conjunto de soluciones entre las que se encuentran los modelos de arquitecturas ESB. Este modelo de arquitectura permite la comunicación fácil entre diferentes tecnologías, a través de servicios web. Sin embargo la mayoría de los intercambios de información se realizan sobre canales no seguros, aun cuando se manipule información sensible de las entidades. En el caso de los ESB, la probabilidad de ataque se incrementa pues al ser considerado un punto se acceso único al cual todos los demás se conectan, la protección de los mensajes intercambios, así como la autenticación y autorización de cada cliente, es vital para evitar riesgos que dañen a la empresa que despliegue un ESB. El objetivo de este trabajo es evaluar algunos escenarios de ataques y a través de las propias herramientas del ESB, protegerse contra algunas de las vulnerabilidades aparecidas en la bibliografía consultada. MuleESB mediante un conjunto de conectores propios de su tecnología permite implementar los estándares de seguridad HTTPS y WS-Security los cuales constituyen una de las estrategias más usadas para garantizar la seguridad en entornos de servicios web. Palabras Clave: EIA, ESB, WS-Security, HTTPS, MuleESB

ABSTRACT: At present the issue of application integration has become more important given that the companies contain a large amount of heterogeneous solutions that need to exchange information with each other. In order to respond to this problem they have emerged a set of solutions among which are models of ESB architectures. This architecture model allows easy communication between different technologies, through web services. However most of the information exchanges are performed on insecure channels, even if sensitive information is handled entities. In the case of the ESB, the likelihood of attack increases to be considered as a point only is access to which all others are connected, the protection of message exchanges, as well as authentication and authorization for each client, it is vital to avoid risks damaging the company to deploy an ESB. The aim of this study was to evaluate some attack scenarios and through the tools of ESB, protect against some of the vulnerabilities that appeared in the literature. MuleESB through a set of connectors on its own technology allows the implementation of safety standards and WS-Security HTTPS which is one of the most used strategies to ensure security in Web services environments. KeyWords: EIA, ESB, WS-Security, HTTPS, MuleESB

“XII Seminario Iberoamericano de Seguridad en las Tecnologías de la Información”

Castro, C.; Gil, E. | “DESARROLLO DE SERVICIOS W EB SEGURO EN MULEESB”

1. INTRODUCCIÓN En la actualidad, la problemática de integración de aplicaciones es un tema común, debido a que las empresas requieren desarrollar e integrar nuevas aplicaciones en sus entornos. Sin embargo muchas de estas aplicaciones están desarrolladas en épocas diferentes, por disimiles personas, tecnologías, plataformas y lenguajes. Además de haberse concebido para ser utilizadas por usuarios y no para comunicarse entre sí. A esta situación es lo que comúnmente se conoce como problema de integración. Con el objetivo de dar respuesta a esta problemática han surgido un conjunto de soluciones como: Integración de Aplicaciones Empresariales (EAI, por sus siglas en inglés), Servicios Web y Arquitectura Orientada a Servicios (SOA, por sus siglas en inglés). Las soluciones EAI permiten las aplicaciones y fuentes de datos existentes en la empresa compartan e intercambien datos y procesos de negocio. SOA constituye un estilo de arquitectura que permite construir soluciones empresariales basadas en la creación de servicios. SOA propone el desarrollo y la reutilización de servicios sencillos para el desarrollo de aplicaciones . Los servicios web permiten establecer enlaces punto a punto para que las aplicaciones compartan información independientemente de la plataforma, ubicación y lenguaje de programación . Sin embargo esta tecnología de interoperabilidad tiene los siguientes problemas:  En la medida que crece el número de conexiones ente las aplicaciones, aumenta considerablemente la cantidad de interfaces de conexión a programar.  Las incompatibilidades de formato en la información que se intercambia deben ser resueltas por cada aplicación que participa en la integración.  No cuenta con mecanismos de monitoreo acerca de la información que se intercambia entre las aplicaciones, elemento necesario en la calidad de la integración.  Cada aplicación cliente es responsable de actualizarse cuando existan cambios en las interfaces de las aplicaciones proveedoras.  Cada aplicación cliente es responsable de implementar su orquestación.  Los sistemas legados que no son compatibles con los servicios web no pueden ofrecer su información. Con el objetivo de ofrecer una solución a estos problemas han surgido tecnologías como Bus de Servicio Empresarial (ESB, por sus siglas en ingles). Los ESB no están basados solamente en servicios web sino

también en el patrón EAI , ya que ofrecen una plataforma de integración basada en estándares que combinan mensajería, servicios web, transformación de datos y enrutamiento inteligente. Es conocido que en entornos de transferencia de datos donde los canales de comunicación pueden ser accedidos por muchos usuarios, los riesgos de ataques hacia los servicios publicados o los posibles consumidores de los mismos se incrementan, y considerando además la creciente demanda de soluciones cada más orientadas a los servicios de internet los riesgos toman especial significancia. Una de las formas más utilizadas por los ESB para publicar sus servicios es a través del protocolo SOAP. Este protocolo básicamente constituye un intercambio de mensajes SOAP entre el cliente y el servidor, en este caso el ESB. Los posibles ataques para este protocolo son recogidos en . Los servicios web además pudieran considerarse un subtipo de aplicaciones, con sus características, en se realiza una reseña de los ataques más frecuentes al intercambio de datos entre los servidores web y los clientes. ESB no están exentos de tales ataques, más bien se podría decir que por sus características, es una de las soluciones cuyo impacto es mayor, pues de producirse uno de ellos se compromete la confidencialidad o la integridad de la información manipulada, o peor aún puede hacer colapsar todo el ESB ocasionando un DoS1 generalizado, trayendo consigo perdidas sustanciales para la empresa atacada. El objetivo de este trabajo es desarrollar servicios web con seguridad a través del ESB MuleESB pues es uno de los más utilizados en la actualidad, teniendo en cuenta las amenazas de seguridad que implican la comunicación insegura entre el cliente, ESB y el proveedor del servicio web.

2. CONTENIDO En este punto se analizara las generalidades del ESB MuleSoft y sus capacidades para la integración de aplicación. Luego se analizaran los escenarios donde un ESB es más vulnerable y al final se llegara a la solución a través de los propios elementos del ESB seleccionado para mitigar las amenazas de los ataques. 2.1 MuleESB Mule ESB es un proyecto de software libre desarrollado por Ross Mason perteneciente a la compañía MuleSoft, actualmente se encuentra en su versión 3.4. Mule ESB es un framework de mensajería ligera basada en Java que permite la rápida conexión e inter1

Denegacion de servicios (DoS, por sus siglas en ingles)

“XII Seminario Iberoamericano de Seguridad en las Tecnologías de la Información”

Castro, C.; Gil, E. | “DESARROLLO DE SERVICIOS W EB SEGURO EN MULEESB”

cambio de datos entre aplicaciones . Mule permite a los desarrolladores integrar sus aplicaciones e intercambiar datos sin tener en cuenta las tecnologías y maneja todas las interacciones entre aplicaciones y componentes de manera transparente sin importar los protocolos de transporte utilizados (JMS, Web Services, JDBC, HTTP, FTP, SMTP). Permite la publicación y la invocación de servicios web de tipos REST y SOAP, haciendo uso del framework CXF . Adicionalmente posibilita hacer transformaciones de mensajes incluyendo XSLT. Se integra con proyectos como Maven y Spring que garantizan una correcta estructuración de los proyectos y configuración de objetos en los flujos ESB respectivamente. Mule provee herramientas de apoyo a los desarrolladores para la creación y configuración del fichero XML que contien la definición de los flujos Mule. Este es el caso de la herramienta Eclipse, que a través de plugins se pueden desarrollar proyectos de tipo ESB y de la herramienta MuleStudio que está basada también en Eclipse y brinda un conjunto de componentes gráficos que hace más fácil el diseño de los flujos. Mule ESB en su versión Enterprise cuenta con una consola de administración (MMC) que actúa como servidor ESB, que brinda la posibilidad de monitorear y gestionar los distintos flujos de las aplicaciones que son desplegados en el ESB. Este producto permite visualizar los recursos de las aplicaciones implementadas, dígase flujos, componentes y mensajes que se intercambian entre componentes, además del estado del servidor en cuanto a consumo de recursos físicos de donde ha sido desplegado. 2.2 Prototipo de ataques a los servicios web Los servicios web, son un tipo de aplicaciones web, cuyas vulnerabilidades son en parte parecidas a las de las aplicaciones web tradicionales. En el caso del protocolo SOAP, el cual incluye intercambio de mensajes XML, existen amenazas específicas de acuerdo a este tipo de implementación.

vicio web, denegación de servicio por alteración de los parámetros SOAP, denegación de servicio por complejidad en la cabecera o cuerpo del mensaje del mensaje SOAP. El atributo integridad se afectado según por los siguientes ataques: ataque hombre-en-el-medio activo de servicio web, suplantación de identidad en el WSDL, inyección de XML en algunas partes especificas del mensaje SOAP. Para el caso de la confidencialidad se tiene: hombre-en-el-medio pasivo. Por ultimo para el caso del control de acceso: suplantación de identidad de la etiqueta SOAPAction. En sentido general muchos de los ataques explotan las vulnerabilidades del intercambio de mensajes sin protección entre el cliente y el servidor y además explotan la complejidad de los XML para su procesamiento para generar denegación de servicios. La taxonomía mencionada posee similitud con las amenazas descritas en y ambas fuentes tienen correspondencia en sus ideas centrales.

2.3 Algunos posibles escenarios de ataques 2.3.1

Escenario #1

Puesto que los ESB tienen la capacidad para enrutar y transformar datos de servicios externos a la entidad donde se encuentran, y estas conexiones no siempre están protegidas se pudiera dar con el escenario que se muestra en la Figura 1. Para todos los escenarios planteados a continuación, una entidad se define como una ubicación física específica, la cual no coincide con la ubicación de otra entidad y que posee mecanismos de seguridad física. Como se aprecia el atacante de manera general pudiera alterar o conocer en amabas conexiones los datos que se pasan de manera entre el cliente y el ESB y entre el ESB y el servicio web que le brinda esa funcionalidad.

Según existe una taxonomía en la que se agrupan los ataques reportados a los servicios web. Estos ataques se clasifican de acuerdo a los objetivos de la seguridad, al número de partes que intervienen, al componente del servicio web atacado y a la propagación del ataque. Para el caso de este artículo escogemos de acuerdo a los atributos de la seguridad que afectan pues de esta manera se tiene una idea más clara de que atributo se desea proteger primero. Para el atributo de la disponibilidad, se encuentran entre otros los siguientes ataques: denegación de servicio por sobretamaño de XML, suplantación de la dirección del ser“XII Seminario Iberoamericano de Seguridad en las Tecnologías de la Información”

Castro, C.; Gil, E. | “DESARROLLO DE SERVICIOS W EB SEGURO EN MULEESB”

Figura 1. Escenario de ataque #1

De esta manera el ESB puede creer que se comunica con la entidad Y, cuando en verdad puede estarlo haciendo con otro que se haga pasar por ella. Además el cliente puede creer también estar comunicando con el ESB de la entidad X cuando pudiera ser atacado por un atacante que se haga pasar por el ESB. Los datos intercambiados en cada parte de la comunicación pudieran tener una nivel de sensibilidad alto, lo cual la confidencialidad estaría comprometida.

2.3.2

Escenario #2

En este escenario la vulnerabilidad consiste en ofrecer servicios de la propia entidad de manera desprotegida a los clientes sin que se sepa a ciencia cierta quienes son en realidad. En la Figura 2 se muestra un diagrama de cuál es la vulnerabilidad de esta variante de conexión. La diferencia de este escenario con el anterior es que aunque la comunicación entre el ESB y el servicio web que le ofrece el servicio es insegura al encontrarse dentro de la entidad, significara un reto mayor para el atacante forzar los mecanismos de seguridad de red de dicha entidad, por lo tanto escogerá introducirse por el elemento más vulnerable. En este caso las conexiones entre el cliente y el ESB están desprotegidas, por lo tanto si un atacante podría modificar ciertos parámetros de los mensajes SOAP y para extraer más información de la entidad de la que se tiene por parte de cliente, incluso hacerle creer al ESB que es un usuario de mayor privilegio. Esto traería como resultado que se afectara la autenticación y los privilegios de cada cliente del ESB, además que se podría afectar la integridad de los mensajes SOAP con fines propios para el atacante.

2.3.3

Escenario #3

En muchas ocasiones la seguridad se ve afectada por el eslabón más débil, el factor humano. Supóngase que el ESB enrute o transforme servicios de una entidad Y con seguridad y exponga de manera no intencional algunos de estos servicios a otros cliente sin protegerlos. En esta situación se estaría debilitando la seguridad de los servicios de la entidad Y. Un atacante con los conocimientos suficientes del ESB, podría alterar un mensaje de entrada del mismo para que este realizara una consulta específica a los servicios protegidos de la entidad Y, de esta manera indirectamente cruza la barrera impuesta por la seguridad entre el ESB y la entidad Y. Este ejemplo se muestra en detalle en la Figura 3. En este escenario el atacado podría ser el ESB, el cual ha publicado un servicio sin protección cuyo consumo es protegido. Esta situacion puede afectar la integridad de los mensajes enviado por el cliente para hacer que la solicitud de mensajes se otra, el ESB recibe este mensaje, y de alguna manera puede entender que es válido para ese cliente, transforma el mensaje recibido por uno nuevo con seguridad para el proveedor que está en la entidad Y. El proveedor que confía en el ESB, resuelve esta solicitud y la entrega al ESB y este la remite al cliente y es interceptado por el atacante.

Figura 3. Escenario de ataque #3

2.4 HTTPS y WS-Security

Figura 2. Escenario de ataque #2

Ahora que ya se han analizado una parte de los posibles escenarios de ataques de manera general, es necesario ver cómo serán mitigados, utilizado básicamente los medios o métodos que ofrecen los ESB.

“XII Seminario Iberoamericano de Seguridad en las Tecnologías de la Información”

Castro, C.; Gil, E. | “DESARROLLO DE SERVICIOS W EB SEGURO EN MULEESB”

MuleESB posee soporte para HTTPS y WS-Security. En este apartado veremos como HTTPS y WSSecurity resuelve la problemáticas de los escenarios descritos previamente. El protocolo de transporte de híper-texto seguro (HTTPS, por sus siglas en ingles), es básicamente el mismo protocolo HTTP, que se despliega sobre la capa de transporte seguro (TLS, por sus siglas en inglés). TLS es un protocolo de comunicación segura para transmisión de datos por internet, y permite a los usuarios acceder e intercambiar datos con sus cuentas en la web. TLS implementa una comunicación segura mediante criptografía simétrica entre el servidor y el cliente. Sin embargo para poder utilizar la criptografía simétrica es necesario garantizar un intercambio de claves seguro. Para resolver esta nueva dificultad, el servidor envía un certificado digital al cliente, anunciando quien es. Este certificado se encuentra muchas veces definido por el estándar X509. TLS también permite la autenticación mutua, el cual lleva un mecanismo más complejo. Una vez que el cliente recibe el certificado cifra la clave secreta que utilizaran a partir de ese momento con la clave pública del servidor haciendo que sólo este pueda descifrar esa clave. A partir de este momento la comunicación será privada entre el servidor y el cliente, de esta manera el atacante no podrá saber que datos se están intercambiando. Para el caso de la suplantación de identidad es probable aun con el uso del certificado, pues su validación depende de una tercera parte confiable, aunque en los navegadores web poseen mecanismo para revocar ciertos certificados si se identifica que no son válidos. Puesto que HTTPS utiliza TLS, el cual se encuentra más abajo en el modelo OSI de las capas de red, los datos que se protegen con TLS, solo dejan libre el IP y el puerto con el cual se están comunicando. Por tanto todo el empaquetado de HTTP se trasmite seguro por la red, incluso los URL. Con el uso HTTPS se garantiza autenticación y confidencialidad durante la transmisión de los datos.

vidor y el cliente, modificando algunos de los valores definidos en esos mensajes. WS-Security es independiente del transporte de los mensajes SOAP, por lo tanto podemos utilizar HTTPS junto a WS-Security. Dado que HTTPS garantizar la seguridad punto a punto entre el cliente y el servidor WS-Security intenta a través de señales (tokens) criptográficas garantizar los atributos de seguridad modificando los mensajes SOAP tradicionales. De esta manera la seguridad se procesa entre los orígenes y destinos reales de la comunicación SOAP y no tanto por los intermediarios como el ESB. El uso de WS-Security y sus señales permite autenticación, integridad, confidencialidad de los mensajes SOAP. El artículo se habla sobre la poca eficiencia de esta propuesta. Y esta dado esta falta de eficiencia en el conjunto de validaciones que hay que realizar una vez obtenido el mensaje SOAP. Dicho mensaje presenta una estructura XML y que además para el caso de WS-Security, puede contener muchas más señales que se utilizan para la seguridad. La mejor estrategia sin duda seria evaluar el escenario de desarrollo del servicio web y ver cuando utilizar una solución u otra. Para soluciones de enrutamiento, es recomendable utilizar WS-Security aunque el cliente debe estar preparado para este método de comunicación ya que este garantiza la seguridad extremo a extremo, sin importar las pasarelas. Donde tengamos comunicaciones directas entre el servidor y el cliente, es posible tener HTTP, y para mejor garantía que no existan servidores intermediarios, y los servicios web se publiquen preferentemente por método REST.

2.5 HTTPS y WS-Security en MuleESB MuleESB posee en sus componentes implementaciones de WS-Security y HTTPS. En esta sección se observa cuales pasos se ejecutaria en Mule para las configuraciones correspondientes que permitan utilizar cada implementación de seguridad. Los componentes en MuleESB, se llaman conectores. En un flujo normal de MuleESB como aparece en la Figura 4, es posible proteger las conexiones a HTTP ya que al ESB se le especifica que cada conexión HTTP de manera global los parámetros a utilizar para usar el protocolo HTTPS.

Dado que el ESB tiene la propiedad de enruta, transformar u orquestar servicios, no es del todo recomendable utilizar HTTPS para estas operaciones pues con esta solo garantizaríamos la seguridad de las conexiones punto a punto entre dos de los nodos participantes. WS-Security es una propuesta hecha por y que ha tenido algunas mejoras, en la cual se intenta proteger los mensajes SOAP que se intercambian entre el ser“XII Seminario Iberoamericano de Seguridad en las Tecnologías de la Información”

Castro, C.; Gil, E. | “DESARROLLO DE SERVICIOS W EB SEGURO EN MULEESB”

Figura 4. Flujo proxy sin seguridad.

En el apartado de Configuración Global del Editor de Flujo, se observan las conexiones HTTP (Figura 5), y cada una de estas se pueden configurar para que utilicen HTTPS como aparece en la

Figura 5. Configuración global.

En el editor de propiedades del conector HTTP, se observan varias secciones, en la señalada en el recuadro, se especifica la ubicación del almacén de claves (KeyStore), así como la contraseña para acceder al mismo. Al realizar esta modificación estaremos proporcionando el certificado necesario para realizar la conexión HTTPS con el cliente. Figura 7. Editor de propiedades del conector HTTP

Figura 6. Editor de propiedades del conector HTTP

En el caso del apartado del cliente en este mismo editor de propiedades se utiliza para la conexión segura cuando el ESB orquesta o enruta una o varias solicitudes hacia un servicio con seguridad HTTPS.

Luego de analizar al apartado de HTTPS, corresponde ver las configuraciones necesarias para el soporte a la implementación de WS-Secuity. Como se planteo previamente el mismo exige que tanto el cliente como el servidor a través de las bibliotecas de servicios web alteren el mensaje SOAP, enviando las señales de seguridad de acuerdo a los objetivos que se desea proteger. En el sitio oficial de MuleSoft se expone un ejemplo bastante completo de cómo utilizar los componentes para implementar esta variante. Para este trabajo se escogen 3 ejemplos de los descritos en . Para el primer ejemplo se escoge la autenticación del cliente mediante la señal de UsernameToken definida en y se agrega el valor del timestamp para garantizar no procesar mensajes obsoletos. En la Figura 8 se observa parte del flujo del primer ejemplo, en el solo se reflejan los componentes principales del flujo para mostrar el mecanismo de WS-Security. Cuando por el ENDPOINT HTTP recibe el mensaje SOAP, este es procesado por el componente SOAP llamado UsernameToken service. En dicho componente se han especificado como procesar las señales de seguridad descritas previamente.

“XII Seminario Iberoamericano de Seguridad en las Tecnologías de la Información”

Castro, C.; Gil, E. | “DESARROLLO DE SERVICIOS W EB SEGURO EN MULEESB”

implementa cómo obtener claves para un usuario determinado, ósea podremos especificar que contraseña debería un usuario determinado. Ahora bien el mensaje SOAP procesado por el conector UsernameToken service, valida que el nombre de usuario y la contraseña sean válidas y chequea que el timestamp no estuviese vencido. Para el ejemplo 2 (ver Figura 10) se agrega en la propiedad action el valor signature, o sea la firma del mensaje.

Figura 8. Flujo del ejemplo 1.

La especificación de los elementos previamente mencionados se realiza en el panel de propiedades del elemento, en el apartado de seguridad. Una vez llegado a esta sección, se debe insertar un nuevo elemento de configuración, estos elementos de seguridad se corresponden con las especificaciones para WSS4J. Dado que Mule está implementado sobre Java, la implementación del procesamiento de los mensajes con WSS4J, posee una serie de manipuladores para poder permitir al programador realizar sus propias validaciones.

Figura 10. Flujo del ejemplo 2.

El proceso de chequeo de la firma digital depende certificados digitales por tanto se debe introducir los mecanismos suficientes para que extraigan los certificados digitales de un almacén y se validen con el mecanismo correcto la firma del mensaje.

Figura 11. Panel de configuración para el ejemplo 2

Para lograr esto en el panel de configuración que se muestre en la Figura 11, se agrega la propiedad signaturePropFile, el cual también está definido en el estándar de WSS4J. Para esta manipulador se define el fichero de configuración dentro del flujo de Mule con el nombre ¨wssecurity.properties¨. Figura 9. Panel para la inserción de nuevos elementos de seguridad

Para este ejemplo, los manipuladores escogidos a través de la propiedad KEY fueron ACTION con valor UsernameToken Timestamp y PASSWORDCALLBACKCLASS con valor com.mulesoft.mule.example.security.PasswordCallBack. En la Figura 9 se observa cómo queda en el panel ambas configuraciones. Para entender lo que se realizó en el ejemplo debemos comprender el valor de parámetro KEY. Este parámetro especifica el valor del manipulador, para el caso del ACTION, el manipulador determina que procesar de la envoltura del mensaje SOAP. Para el caso del PASSWORDCALLBACK, este manipulador

Figura 12. Datos del fichero de configuración de

“XII Seminario Iberoamericano de Seguridad en las Tecnologías de la Información”

Castro, C.; Gil, E. | “DESARROLLO DE SERVICIOS W EB SEGURO EN MULEESB”

“signaturePropFile”

Los valores de este fichero se encuentran visualizados en Figura 12, el cual debe definir el proveedor criptográfico a utilizar, el tipo del fichero almacén de certificados así como la contraseña para acceder al mismo, además del alias y el nombre del fichero. Para validar la firma Mule utiliza los comandos del keytool de Java y certifica la firma del documento. Para el ejemplo 3 se utiliza la variante de cifrar el mensaje además de agregar la información relacionada con la autenticación. El flujo se observa en la Figura 13.

Figura 13. Flujo del ejemplo 3

Para esta variante se debe agregar a la propiedad action el valor de “Encrypt”. Además se agrega la propiedad decryptionPropFile, igualmente definida en el estándar de WSS4J. Ahora la propiedad decryptionPropFile es utilizado por Mule para llevar a cabo el descrifrado del mensaje SOAP. Las configuraciones para esta variante se encuentran en la Figura 14.

Figura 14. Panel de configuración para el ejemplo 3

En la propiedad “decryptionPropFile” se especifica el almacén de claves que se utilizara por Mule para descifrar los mensajes SOAP. En resumen se puede observar que tanto la protección punto a punto de las conexiones entre un cliente y el ESB así como el ESB y el proveedor del servicio se pueden proteger por el protocolo HTTPS, sin embargo esta estrategia no puede garantizar la seguridad extremo a extremo. Para esto se utiliza la estrategia de WS-Security que se implementa en Mule a través del estándar de programación WSS4J. Para el uso de WS-Security el cliente debe importar y manipular también las clases contenidas en WSS4J de lo contrario la comunicación entre los extremos no será posible.

3. CONCLUSIONES MuleESB es un ESB de código abierto capaz de desplegar servicios con HTTPS y WS-Security, lo cual mejora la seguridad de los servicios publicados. El uso del ESB para incorporar la seguridad a los servicios de la misma entidad, cuando estos son publicados a través del ESB a otras entidades permite a los desarrolladores enfocarse en el desarrollo funcional de sus servicios y delegar la seguridad en el ESB. Si se consume un servicio en un entidad externa, que contenga seguridad, por el ESB, este puede crear una capa intermedia con su propia seguridad y de esta manera no afectar la seguridad del servicio consumido. Aunque es posible asegurar las conexiones entre cada par de la comunicación para enrutar un servicio por el ESB con HTTPS, no es posible garantizar la seguridad extremo a extremo. Por lo que se hace necesario para la mayoría de los escenarios de publicación de servicios web por el ESB, la estrategia de WS-Security, El uso de HTTPS o WS-Security en el ESB es válido, aunque dependerá de que los clientes tengan el soporte necesario para el caso de WS-Security. Además la eficiencia de WS-Security puede verse afectada si el volumen de los mensajes es grande y si cada mensaje contiene muchos elementos de seguridad.

4. REFERENCIAS BIBLIOGRÁFICAS 1. Rosen, M., Applied SOA: Service-Oriented Architecture and Design Strategies, I.W.P. Inc, Editor. 2008. 2. Cámara, J., Recomendaciones para la adopción de SOA. Jornadas de Servicios Web y SOA, 2008. 3. S. P. Ahuja, A.P., Enterprise Service Bus: A Performance Evaluation Communications and Network. 2011. 3(133-140). 4. NSA, S.a.N.A.C.I.A.D. (2009) Service Oriented Architecture Security Vulnerabilities Web Services. 5. Gangan, S., A Review of Man-in-the-Middle Attacks. 2015. 6. Mulesoft, Introducing Mule Concepts. 2012. 7. David Dossot, J.D.E.V.R., Mule in action, Second Edition. 2014, New York: Manning Publications Co. 8. WS-Attacks.org. WS-Attacks.org. WSAttacks.org 2011 9. A. Ozment, S.E.S., Bootstrapping the Adoption of Internet Security Protocols. MIT Lincoln Laboratory and University of Cambridge, 2006. 10. R. M. Mohammad, F.T., L. McCluskey, An

“XII Seminario Iberoamericano de Seguridad en las Tecnologías de la Información”

Castro, C.; Gil, E. | “DESARROLLO DE SERVICIOS W EB SEGURO EN MULEESB”

Assessment of Features Related to Phishing Websites using an Automated Technique. 2012. 11. H. Dinesha, V.K.A., Framework Design of Secure Cloud Transmission Protocol. IJCSI International Journal of Computer Science, 2013. 10(1). 12. Rescorla, E. (2000) HTTP Over TLS. Volume, 13. C. Adams, S.F., T. Kause, T. Mononen (2005) Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP). Volume, 14. B. Atkinson, S.H., Web Services Security (WS-Security). developerWorks. IBM, 2002. 15. S. Kumar, A.K.G., A Conceptual Technique for Modelling Security as a Service in Service Oriented Distributed Systems. JOURNAL OF COMPUTER SCIENCE AND SOFTWARE APPLICATION, 2014. 1. 16. M. B. Juric, I.R., B. Brumen, M. Colnaric, M. Hericko, Comparison of performance of Web services, WS-Security, RMI, and RMI–SSL. The Journal of Systems and Software, 2006. 79: p. 689-700. 17. Sosnoski, D., Servicios web Java: El alto costo de (WS-)Security. DeveloperWorks, 2011. 18. MuleSoft. WS-Security Example. 2015 [cited 2015 03-11-15]. 19. Foundation, T.A.S. Apache WSS4J - Web Services Security for Java. 2015 [cited 2015 03-11].

5. SÍNTESIS CURRICULARES DE LOS AUTORES Ing. Claudia Ivette Castro Zamora (22/12/89, La Habana. Cuba). Graduada de Ingeniería Informática en 2012. Especialista en Integración de Aplicaciones Empresariales, actualmente se concentra en el estudio de Enterprise Service Bus (ESB) en el entorno de integración de aplicaciones heterogéneas. Ha trabajado el desarrollo de sistemas de conformación de equipos de proyectos, específicamente desarrollando una capa de servicios web para este sistema. Ha investigado sobre calidad de software, enfocándose en lo referente a la calidad de los servicios web desde la etapa de diseño y además en las políticas para el cumplimiento de la interoperabilidad entre las diferentes tecnologías que implementan servicios web. Profesor Instructor de la Facultad de Ingeniería Informática. CUJAE. Ing. Ernesto Gil Aranguren (29/12/1988, La Habana. Cuba). Graduado de Ingeniería Informática en 2012. Especialista en Seguridad informática, actualmente trabaja en ataques de canal colateral sobre algoritmos criptográficos, enfocándose en los ataques de fallos. Presento en informática 2013 el trabajo “Desarrollo de componente de cifrado simétricos AES y GOST sobre Microblaze”. Ha trabajado en el desarrollo de sistemas embebidos, componentes de cifrado simétricos con bajas prestaciones, sistemas de arranque para PC (BIOS), borrado seguro de la información en nivel de discos duros (HDD). Profesor Instructor de la Facultad de Ingeniería informática. CUJAE .

“XII Seminario Iberoamericano de Seguridad en las Tecnologías de la Información”