candado

Como muchos de los aspectos que intervienen en el diseño de un sistema SOA, es posible que con la seguridad caigamos en uno de los errores más frecuentes en el diseño de software empresarial: hacer las cosas más complicadas de lo necesario.

No necesitamos una solución bonita, académica o una en la que nos sintamos realizados como ingenieros de software, tenemos que hacer exactamente lo necesario, ni más ni menos. Por supuesto, tenemos que dejar el diseño abierto para que se pueda extender y no sea una solución que no pueda evolucionar, pero tampoco podemos caer en lo que se llama sobreingeniería.

¿Cual sería este enfoque práctico sobre la seguridad en un sistema SOA de una empresa? En mi opinión, el siguiente:

Si los servicios web manejan información sensible o si implementan una funcionalidad a la que es necesario restringir el acceso, es necesario securizar los servicios. Aunque tampoco poco podemos caer en el absurdo de pensar que todos los servicios hay que securizarlos. Hay servicios que se pueden considerar “públicos” o sin seguridad.

Esta securización implica, como en todos los sistemas informáticos (sean SOA o no), la autenticación del usuario o cliente del servicio y la autorización

Autenticación

La autenticación consiste básicamente en demostrar que eres quien dices ser. La forma más común de hacer esto es mediante la combinación de un código de usuario y una contraseña (username/password). En escenarios más complejos también se pueden usar certificados digitales para autenticar al servidor, o a las dos partes implicadas (cliente y servidor).

De esta manera es necesario, que el cliente proporcione al servidor o proveedor del servicio, unas credenciales de acceso. Como particularidad, en la arquitectura SOA no se tiene sesión. Por lo tanto, es necesario enviar las credenciales en cada invocación que se realiza a los servicios o bien, generar un token de seguridad  (una ristra de ceros y unos) y sea ese token el que se envía en cada invocación.

Autorización

Una vez que el usuario está autenticado, lo normal es que no pueda ejecutar todas las funcionalidades del sistema. Es decir, es necesario que de alguna manera se indique, qué funcionalidades puede ejecutar un usuario y cuáles no. Normalmente, dado el gran número de usuarios que puede tener un sistema, estos se agrupan en roles, y las funcionalidades se restringen basándonos en estos roles.

A continuación, y teniendo en cuenta el escenario específico de la empresa, y sobre todo, buscando la simplicidad de la implementación y el mantenimiento manteniendo los requisitos de seguridad necesarios, debemos indicar como securizar los servicios.

Seguridad en los servicios web

Para la securización de los servicios web tenemos dos opciones:

  1. Usar seguridad de mensaje
  2. Usar seguridad en la capa de transporte

En la primera modalidad, lo que se hace es poner en el mensaje SOAP (el XML que viaja por la red) una cabecera de seguridad. Es decir las credenciales viajan en el mensaje al igual que la información de negocio. Para implementar esto, el estándar WS-Security nos proporciona muchas alternativas que pueden llegar a ser muy complicadas.

La más sencilla de esta modalidad sería el uso de la etiqueta UserNameToken, en el que se codifican el usuario y la password del cliente. También se pueden usar credenciales de tipo certificado digital, Kerberos, SAML, etc. etc.

La segunda modalidad, sería securizar el transporte, es decir el canal por donde viaja el mensaje (este mensaje no tiene ninguna información en su interior relativa a la seguridad).

Por poner un símil, si nos imaginamos que el tráfico de datos es como enviar dinero de una empresa al banco:

  • Si lo enviamos por una carretera normal, sin escolta, en un vehículo blindado, sería similar a la seguridad en el mensaje. Por cualquier carretera que pase el vehículo, estará protegido.
  • Si por el contrario, enviamos el dinero en un vehículo normal y corriente, pero por una carretera vigilada por la policía, entonces estaríamos hablando de seguridad en el transporte. Si nos salimos de esa carretera, la mercancía estará desprotegida.

Por supuesto, también se pueden usar las dos opciones a la vez, es decir con seguridad en el mensaje y en el transporte, pero esto sólo sería necesario  en condiciones muy especiales.

Ventajas y desventajas de la seguridad en el mensaje

Ventajas

  • La seguridad va integrada en el mensaje. Por lo tanto, no importa por donde pase este mensaje, siempre estará securizado
  • Es un estándar de WS-*
  • Se puede usar en combinación con el cifrado y la firma de mensajes

Desventajas

  • Es más complicado de implementar
  • Se necesitan más conocimientos por parte de los desarrolladores
  • En el caso de UserNameToken, el usuario y password no van cifrados

Ventajas y desventajas de la seguridad en el transporte

Ventajas

  • Si se usa el tipo de seguridad BASIC es un estándar en HTTP, implementado desde siempre por browsers, lenguajes de programación, etc.
  • Es más fácil de implementar
  • Se puede usar también para los servicios de tipo REST

Desventajas

  • Sólo se securiza el tramo por el que viaja el mensaje. Es decir, si al llegar al servidor se “reenvía” a otro, puede que no esté securizado
  • El usuario y la password no van cifrados

Conclusión

Teniendo en cuenta todo lo anterior, y como siempre, teniendo en cuanta las condiciones particulares de cada empresa, mi consejo sería elegir la opción más sencilla posible siempre que cumpla con las necesidades. Por ello, una opción a tener en cuenta, y válida en la mayoría de las ocasiones, es la seguridad básica en el transporte.

Las razones para ello son las siguientes:

  • Las comunicaciones internas dentro de los sistemas de la empresa no necesitan un elevado nivel de seguridad ya que es una red interna.
  • En el caso de servicios expuestos en internet para clientes finales o para partners, dependiendo del caso, habrá que implementar una seguridad más alta.
  • La implementación es más sencilla, y por tanto la productividad en el desarrollo de servicio más alta
  • En el caso de que puntualmente, debido al tratamiento de información sensible en los servicios u otro motivo, se puede usar HTTPS en lugar de HTTP. De este modo, la comunicación va cifrada de extremo a extremo, logrando confidencialidad en la comunicación y que la contraseña no se pueda leer.
  • El estándar WS-Security nos da un sin fin de posibilidades: cifrado fuerte, firma (no repudio), hash para garantizar la integridad del mensaje, etc. etc. Sin embargo, por mi experiencia, dentro de la red interna de la empresa, normalmente no necesitamos tanto. Si lo usamos, estamos pagando un precio en cuanto a coste de implementación y mantenimiento que tal vez no esté justificado.

¿Cuál es vuestra opinión?

Anuncios