Arquitecturas basadas en microservicios: Seguridad I

Hoy en día, uno de los grandes retos a la hora de afrontar un nuevo desarrollo es la securización del mismo. La seguridad de una compañía siempre es algo que entraña muchos riesgos, pero antiguamente era más sencillo debido a dos premisas que se cumplían en la mayoría de los desarrollos:

El desarrollo a realizar era de consumo interno

A finales de los 90 y principios del 2000, antes del estallido de Internet, la mayoría de las compañías preferían abordar todos sus desarrollos de forma interna, sin el uso masivo de librerías de terceros ni software basado en Open Source.
Esto, que a día de hoy nos parecería una locura, provocaba muchos efectos negativos, pero a nivel de seguridad y sistemas tenía un efecto muy positivo: Tu software solo sería ejecutado dentro de una red propia.

seguridad en arquitecturas basadas en microservicios

Eso hacía perfectamente posible bloquear físicamente el acceso a tu software desde cualquier otra red, además ya debías estar autenticado para acceder a la misma. De esta forma, si, por ejemplo, usábamos un framework de seguridad como Spring Security, incluso la implementación de seguridad más sencilla (almacenamiento de usuarios y contraseña en base de datos) nos permitía tener un nivel de confianza suficiente.

Una sola aplicación contenía todos los servicios del desarrollo

Con el crecimiento exponencial de las aplicaciones basadas en interfaces web también vino de la mano la aceptación masiva de un patrón de desarrollo, el patrón MVC (Modelo Vista Controlador). Este patrón se basa en que una aplicación es capaz de exponer todos sus modelos (representaciones de los objetos alojados en una base de datos) al usuario mediante vistas (interfaces de interacción con el usuario) que serán gestionadas por una serie de objetos controladores (objetos que controlan los flujos de datos desde los modelos a las vistas, y viceversa).
Este patrón fomentaba que todas las interacciones del usuario estuviesen contenidas dentro de la misma aplicación, motivando también, en muchas ocasiones, que los servicios de negocio estuviesen incluidos dentro de la misma aplicación o formasen parte de la base de datos (sobretodo en sistemas basados en Oracle o SQL Server). Todo esto conllevaba que solo una aplicación era la que tenía que ser securizada. Evidentemente, la securización debía de ser de muy alto nivel cuando estas aplicaciones estaban disponibles online, pero siempre se sabía que solo podía existir un punto de acceso.

Factores

Actualmente estas dos premisas han dejado de cumplirse en la mayoría de desarrollos, principalmente debido a los siguientes factores:

Omnicanalidad Apificación Uso de librerías de terceros
Actualmente la mayoría de las aplicaciones no solo tienen que estar disponibles mediante su exposición a través de internet, también tienen que tener en cuenta que pueden ser consumidas por múltiples canales y tecnologías: Usuarios, aplicaciones móviles nativas, otras aplicaciones, etc. Esto hace que las aplicaciones deban de tener un interfaz que permita la comunicación con todos estos canales, así como las herramientas de seguridad para poder validar que estos canales están autorizados para poder comunicarse con ella. Asimismo, muchos de estos canales serán externos a nuestras redes y sistemas por lo que nuestras aplicaciones ya no podrán ser aplicaciones solo de uso interno Otra de las causas de la omnicanalidad es la que ha generado que nuestras aplicaciones deban de ser diseñadas como librerías de consumo al servicio de terceros. Durante los años 2000 y 2010 se dio una primera oleada de exposición de software al exterior mediante el uso de servicios web. La creación y uso de dichos servicios, tuvo bastantes dificultades para su interoperabilidad entre distintos lenguajes, lo que hizo que no tuviese la aceptación esperada. Posteriormente la popularidad obtenida por la notación JSON, bastante menos verbosa que los xml usados por los servicios web, así como una revisión de las posibilidades que no se estaban utilizando en el protocolo de comunicación HTTP dieron paso a la popularización de los servicios REST. El uso de estos servicios también volvió a popularizar la fragmentación de servicios (generación de microservicios) lo que generó que la seguridad de las aplicaciones ya no contase con un solo punto de entrada Otra de las evoluciones, quizás para mí la más grande de todas, fue la explosión en el desarrollo de software libre y la creación de infinidad de librerías puestas a disposición de terceros para fomentar su uso y continua mejora. Eso permite que, los desarrolladores no tengan que preocuparse por muchas partes de una solución, ya que ya han sido resueltas por la comunidad, gracias a ello podemos focalizar nuestro trabajo en el negocio concreto que estamos desarrollando. Por otra parte el uso de estas librerías también ha traído la necesidad de que tengamos que poder establecer una comunicación segura con muchas de ellas lo que, en la práctica, significa que no solo debemos garantizar el acceso a nuestros recursos sino a recursos utilizados por terceros

Debido a esto la securización del software ha debido de evolucionar y adaptarse para poder dar respuesta a los desafíos de hoy en día. En futuras entradas os hablaremos del que para nosotros es el estándar de seguridad más utilizado a día de hoy -OAuth2- y de su implementación en Spring Security.

¡Feliz Desarrollo!

Referencias

   ≡   Patron MVC   ≡   Servicios Web   ≡   Historia de API Rest   ≡   Definición de API Rest   ≡