Cuestiones de seguridad en SOA

diciembre 20, 2012

URL copied!

Categories: AutomotiveCommunicationsConsumer and RetailFinancial ServicesHealthcareManufacturing and IndustrialMediaTechnology

Un producto de software no es una aplicación aislada, sino que convive en un universo altamente conectado: se comunica, se integra, se relaciona y expande en busca de cumplir sus propósitos. Este hecho recrudece en ambientes distribuidos con alto grado de conexión y exposición como lo es de la las arquitecturas SOA, donde múltiples servicios son combinados, uniendo diferentes tecnologías y plataformas.

En estos contextos, las cuestiones de seguridad se vuelven decisivas. Dejan de ser un simple requerimiento no funcional para convertirse en una de las prioridades para el éxito del producto. La seguridad debe atacarse desde el inicio mismo del proyecto, y mantenerse activamente presente en todo el resto de las etapas.

En primera instancia, cada servicio debe cumplir con exigencias mínimas de seguridad. Entre ellas podemos nombrar integridad y confidencialidad de los datos, responder con precisión ante accesos no autorizados y considerar ataques clásicos como denial of service o non-repudation. Pero por encima de estas cuestiones, cualquier plan de seguridad en SOA debe analizar desde el momento cero la seguridad en los canales de comunicación. De nada sirve tener dos componentes invulnerables si el canal que los comunica es inseguro.

Se puede considerar la seguridad desde dos perspectivas: seguridad a nivel de la capa de transporte, y seguridad a nivel de mensajes. A nivel transporte tiene menores costos, y se basa en conceptos de seguridad ya desarrollados ya sea sobre TSL, SSL, O VPN. La segunda tiene la ventaja de poder adaptarse más a las necesidades particulares de un sistema. Las estrategias están enfocadas en la encriptación o firmado de mensajes, ya sea de manera total o parcial. Por ejemplo, los mensajes Request y Response del protocolo SOAP Envelope utiliza como algoritmos de encriptación y firma a: 3DES y Sha1WithRSA.

Entre los ataques más comunes a SOA se puede nombrar a SQL Injection. En este caso se inyecta código SQL en datos XML para obtener respuestas fraudulentas, o causar errores que revelen información sensible sobre la base de datos. Para que este ataque tenga efecto se requiere que los datos recibidos por un servicio SOA se inserten directamente en una sentencia SQL, y que la misma corra con los permisos suficientes.

Para combatir este ejemplo es importante evitar que datos de origen desconocido se anexen a sentencias SQL. Esto se logra con validación de contenidos y reglas de detección de amenazas. También el ataque “replay” es conocido, donde se busca ganar acceso respondiendo mensajes firmados y válidos. Para evitar esta modalidad es común la utilización de timestamps. Finalmente, otro punto a controlar adjuntos dañinos dentro de los mensajes SOAP. Los mismos pueden directamente bloquearse, o servirse de los servicios de un antivirus.

Un error común al intentar abordar cuestiones de seguridad es incluirla solamente al finalizar el proyecto siguiendo un esquema que prioriza la velocidad antes que la seguridad. Esto es grave porque recién con el proyecto terminado se pueden detectar amenazas serias que impiden culminarlo con éxito. Alcanza con imaginar una arquitectura compleja ya finalizada donde llevar a cabo las tareas de seguridad implica realizar cambios drásticos de funcionamiento.

Si en cambio el concepto de seguridad es tratado desde etapas tempranas, esto permitirá tener en cuenta posibles restricciones y limitaciones entre los componentes. Para tener esto en cuenta es fundamental que se incluyan el diseño de casos y pruebas de penetración al diseñar todo el esquema general de testing de la aplicación o producto.

Top Insights