La industria está entusiasmada por el gran potencial que aporta la arquitectura SOA, los Web Services y el procesamiento XML. Con el nivel de seguridad apropiado, las tecnologías XML pueden facilitar la interoperabilidad entre aplicaciones y por tanto, ofrecer funciones de negocio como nunca antes.

Sin embargo, los departamentos de Seguridad están preocupados, razón no les falta, ante los problemas potenciales de seguridad. Los flujos de datos XML están atravesando, de forma inadvertida, las rutas y protocolos existentes. Los Firewalls se muestran desarmados frente a posibles ataques sobre XML, que llegarían directamente a las aplicaciones, representando así nuevos ataques a la seguridad, disponibilidad y rendimiento de los sistemas.

Para poder sacar provecho a las indudables ventajas que ofrecen los Web Services y evitar sus amenazas, es necesario un nuevo tipo de servicio, los gateways o Firewalls de XML, que permitan los nuevos procesos de negocio sin cambiar o re-inventar las infraestructuras disponibles de seguridad.

Situación de partida

El secreto del rápido crecimiento de los Servicios Web está en el uso de estándares abiertos, libres y muy probados (HTTP, XML, SOAP). Estos estándares suponen independencia de plataforma en las comunicaciones, ya que se pueden montar en cualquier máquina, sistema operativo, servidor web y lenguaje de programación. Lo único que tiene que saber hacer un servicio web es entender XML (porque el HTTP ya lo gestiona el servidor web).

También debe su crecimiento a la existencia de herramientas (librerías y programas) que convierten otras librerías ya existentes en un servicio web.

Con la madurez del lenguaje ECMAScript (o JavaScript) y la aparición de formas de realizar peticiones XML al servidor web sin abandonar la página HTML actual, ha surgido una nueva forma de dinamizar el contenido de las páginas web, el llamado Web 2.0.

Tanto los Servicios Web como los Web 2.0 envían peticiones XML al servidor web, peticiones que resultan opacas a los sistemas tradicionales de seguridad, por ejemplo el cortafuegos IP está configurado para dejarlas pasar. En el caso de no existir algún filtro en el trayecto de las peticiones al servidor web, y se produce alguna vulnerabilidad en el trayecto, se podría dejar escapar información sin control o incluso, incorporarse información no controlada. Además se requieren más funciones de seguridad, derivadas del hecho de que la gran mayoría de esas peticiones incluyen transacciones (de negocio) que tiene que estar autenticadas, o que conforma parte de procesos más complejos que hay que desglosar y enrutar de diversas formas.

Seguridad, ¿falta algo?

Controlar la seguridad de los Servicios Web publicados en Internet no es tarea sencilla. Los cortafuegos IP más avanzados que filtran la capa de aplicación no son de gran ayuda, las peticiones HTTP correctas las tiene que dejar pasar.

Con otros protocolos TCP/IP es más fácil, ya que o utiliza el protocolo adecuado o se frenan, pero en caso de SOAP sobre HTTP, aunque se utilice el protocolo adecuado, la validez de los datos XML no la filtra el cortafuegos.

Siempre hay que tener en cuenta todas las facetas de la seguridad a la hora de publicar un Servicio Web en Internet, ya que los atacantes utilizarán el punto más débil de todo el proceso e infraestructura para colarse y dañar.

Se puede conseguir la confidencialidad en las comunicaciones utilizando la variante cifrada del HTTP, el HTTPS, pero ésto incluye una sobrecarga a los servidores web. También es factible la alternativa XML del cifrado XML.

Igualmente, se puede lograr la acreditación de los participantes utilizando los métodos de acreditación de HTTP (cabeceras Basic o Digest authentication) o HTTPS (requerir certificado de cliente) o emplear la alternativa XML, token SAML (Security Assertion Markup Language) dentro de sistemas de Federación.

El control de acceso a los recursos se puede realizar de la forma tradicional con los medios para controlar permisos del servidor web o mediante la alternativa XML, conocida como XACML (eXtensible Access Control Markup Language), controlando el acceso mediante políticas definidas
Todavía faltan diversos aspectos de la seguridad como la aplicación de políticas, virtualización, enrutamiento, aplicación de firma digital y verificación/ validación por campos, sin olvidar, por otra parte, las vulnerabilidades relativas a la disponibilidad y contenidos.

¿Cómo podemos evitar los siguientes aspectos?

Alternativas y Arquitecturas

De la misma manera que sucedió en los inicios de Internet, cuando las funciones de seguridad se delegaban primero en la aplicación y luego en el servidor ahora se ha impuesto la solución madura de los dispositivos de red dedicados. Con los Servicios Web sucede algo similar. La opción de implementar las capas de seguridad en las aplicaciones está prácticamente descartada, debido a la complejidad, al conocimiento específico del que no disponen la mayoría de los programadores y por la dificultad en su mantenimiento. En cambio, se ha popularizado el uso de librerías que se instalan en servidores y que aportan las funciones de seguridad, motivado por el sentimiento de comodidad por parte de los programadores ante este tipo de alternativa.

Todas las mejoras en seguridad son posibles utilizando estas librerías, pero con grandes inconvenientes: la seguridad está distribuida en múltiples componentes, cada parte se administra de un modo diferente, incluye sobrecarga en el desarrollo y en los servidores web, además resulta más difícil consolidar las trazas de funcionamiento o perseguir los errores, también es más costoso en caso de cambio en los estándares, políticas o simplemente versiones de software (tanto aplicativo como librerías de seguridad).

Todos estos inconvenientes unido a la fuerte necesidad de proceso de XML, han favorecido las soluciones basadas en dispositivos de red (donde se pueden utilizar procesadores especializados ASIC) con la función de Pasarelas (especializados) Web Services. Es una solución que entienden bien los responsables de Comunicaciones, acostumbrados a trabajar con Proxy y Firewalls, para los responsables de Arquitectura y Tecnología es la alternativa más lógica, dado que los Web Services permiten una separación clara de comunicaciones y lógica de aplicación, con lo que resulta muy sencillo establecer arquitecturas con capas de servicios, consolidando los servicios de seguridad. Para los responsables de Operación, la ventaja fundamental es que una arquitectura más simple facilita todos los trabajos de mantenimiento. Y por último, para los responsables de Seguridad la ventaja principal está en la posibilidad de controlar tanto las políticas que se tienen que aplicar como la obtención de las trazas para auditoria o análisis forenses en caso de problemas en un único punto.

Con arquitecturas SOA, Web Services y Web 2.0 estamos ante un nuevo ciclo en la evolución de las tecnologías de Información. Las posibilidades son enormes y las ventajas muy atractivas: interoperabilidad y flexibilidad para desplegar nuevas relaciones y servicios. Pero, por lo mismo, los retos de seguridad son importantes.

Afortunadamente la industria mediante el desarrollo de estándares, guías de buenas prácticas y tecnologías, ya en plena madurez, está aportando soluciones que permiten andar con confianza este nuevo camino de progreso tecnológico. Dentro de estás Tecnologías y buenas prácticas, las pasarelas de seguridad Web Services como dispositivos de red se están convirtiendo en una pieza clave para arquitectos, responsables de sistemas y de seguridad. Pronto sus ventajas también convencerán a los desarrolladores.