Reconozco que a los “técnicos” nos cuesta la comunicación, pero, dado el amor que tengo por la profesión que práctico, he decidido llevar mi esfuerzo por cambiar la imagen de stopper que tenemos quienes practicamos seguridad, a otro nivel. Esfuerzo que me va a exigir salir de las trincheras y tomar un rol de comunicador.

Desde que se comenzó a hablar de la famosa transformación digital me dediqué a leer y leer los “distintos” puntos de vista de los autores respecto a cómo impacta esta transformación a la ciberseguridad, en la gran mayoría de los casos, me encontré con una línea muy similar en la que se atribuyen gran cantidad de riesgos y prácticamente ningún beneficio.

Desde la bibliografía, no parece existir una solución clara a estos riesgos y mucho menos, entender si este cambio de paradigma propone beneficios.

Intentando pararme en otro lugar y, considerando distintos puntos de vista, intentaré plantear cómo abordar los riesgos y hasta plantear beneficios asociados a los cambios tecnológicos necesarios para la transformación.

Arquitectura de Microservicios y sus beneficios para la ciberseguridad

Lo primero que se observa cuando uno comienza a investigar sobre Microservicios es que la flexibilidad de esta tecnología configura un gran riesgo de ciberseguridad debido a que repercute en la cantidad de activos a administrar y en la velocidad de cambio.

A lo largo de este texto me voy a encargar de intentar romper esta hipótesis y voy a apelar a los lectores para que comenten.

Para comenzar me voy a dedicar a comparar dos extremos desde el punto de vista de arquitectura (Monolíticas y Microservicios) para luego detallar los beneficios que veo en las de microservicios. No voy a realizar un estudio profundo, simplemente voy a tomar ciertas características de estas en función de lo que quiero estudiar.

Incluso, en ciertas oportunidades, tomaré algunas licencias para intentar ser lo más gráfico posible, sobre todo, para los lectores menos técnicos.

Arquitecturas monolíticas vs microservicios:

Las arquitecturas monolíticas se caracterizan por cumplir una gran cantidad de funciones o propósitos dentro de lo que podemos considerar una solución que abarca a todas estas o un gran activo tecnológico. Estas funciones se encuentran interconectadas entre sí dentro de “una caja” o sistema operativo que la contiene.

Este tipo de arquitecturas las podemos encontrar, por ejemplo, en la industria bancaria con los llamados core bancario, los cuales, poseen sus módulos de caja de ahorro, cuenta corriente, tarjetas, etc. A su vez, todos estos módulos pueden llegar a estar compuestos de una gran cantidad de funciones fuertemente relacionadas entre sí.

Les presento un esquema sencillo de lo que intento explicar.

El problema principal por el que este tipo de arquitecturas dejan de utilizarse, es el alto grado de acoplamiento, el cual, entre tantas cosas, incrementa los costos (plata y esfuerzo) de mantenimiento, cambio y resiliencia.

Analizando las arquitecturas de microservicios, las funciones se encuentran totalmente desacopladas unas de otras, a tal punto que, las comunicaciones entre estos servicios ocurren a nivel de red, también con APIs pero en general sobre protocolo HTTP (RESTFul).

De esta manera, imaginemos que se decide exponer una API de transferencias mediante el API Gateway (API GW) a los front end.

Cuando este API sea consumida, podemos pensar que aguas abajo, este servicio de negocio va a ser soportado por una composición de microservicios, por ej: Consulta de saldo –> Débito en cuenta –> Crédito en cuenta, en donde cada uno de estos es un servicio autónomo, desplegado y mantenido individualmente.

Si logré explicarme bien, supongo se estarán imaginando que a partir de estos cambios de paradigma nace una gran complejidad asociada a la cantidad de componentes a gobernar y, no les voy a mentir, están en lo correcto.

Si con las arquitecturas monolíticas estaban acostumbrados a administrar activos del orden de las decenas o algunos cientos, con los Microservicios vamos a tener que pensar en los varios cientos o miles.

¡Pero ojo! Hay una problema oculto detrás de los “pocos” activos que administramos y radica en que en la mayoría de los casos, los monolíticos, aunque pocos, son muy distintos entre sí. Esta diferencia en términos de esquemas de autenticación y autorización, trazabilidad, cifrado, hardening, etc, implica que cada proyecto y configuración es en general un volver a empezar y, por supuesto, una gestión de seguridad específica para cada solución.

Bien, entonces, ¡si las monolíticas son malas podemos decir que los microservicios son los buenos!… NO necesariamente.

Como veníamos detallando antes, si incrementamos drásticamente esta complejidad estamos destinados al fracaso, pero, si nos paramos en la otra vereda y profundizamos sobre como implementar esta gran cantidad de componentes de manera de poder centralizar la administración y estandarizar las configuraciones, la cantidad pasa a ser anecdótica.

Para lograr esta centralización y estandarización vamos a introducir dos conceptos:

• PaaS (Plataforma como servicio)
• Service Mesh

Al igual que los anteriores esquemas, me voy a permitir representar estas dos capas con el objetivo de ser lo más descriptivo posible y tomándome algunas licencias. Por favor, que no se enojen los puristas.

En general y simplificando, cuando hablamos de microservicios nos referimos a una funcionalidad (un desarrollo) que corre en un contenedor sin la necesidad de que exista un Sistema Operativo tradicional. Es aquí donde entra en juego la solución PaaS encargándose, entre otros temas, de gestionar los contenedores y, en un plano más cercano al software de base, nos permitirá contar con las primeras capacidades de estandarización y centralización de la administración.

Subiendo de capa, las funcionalidades de negocio son implementadas en contenedores y, para lograr la preciada centralización y estandarización, es que aparece la solución Service Mesh con su Control Plane.

A su vez, los SideCars gestionarán distintas problemáticas propias del desarrollo, muchas de ellas, asociadas a la seguridad.

Con los sidecars podremos estandarizar lógica de autenticación, autorización, logging, balanceo, firewall, WAF (Web Application Firewall), etc. Esto es posible debido a que estas funciones dejan de ser construidas por cada desarrollador, los sidecars proponen un esquema en el que el equipo de desarrollo instancia al sidecar para resolver el tema en cuestión, sin tener que diseñar lógica ad-hoc.

Sin ánimos de ser repetitivo, y comparando nuevamente con las arquitecturas del estilo monolíticas, por cada nuevo proyecto o desarrollo de un módulo de negocio, el equipo de desarrollo tenía que sentarse con el equipo de seguridad y definir / negociar que debía considerar el sub-módulo de seguridad, que modelo de autenticación implementar (integrada a un idp o local, ej: directorio activo), si el esquema de autorización (roles y perfiles) será local o integrado, si se debe pensar en un backoffice de parametría, segregación de funciones administrativas, etc, etc, etc.

Es decir, si el desarrollo de la funcionalidad de negocio llevaba 6 meses, es muy probable que, con estas lógicas propias de seguridad, el proyecto finalice en 8.

Adicionalmente, ese sub-módulo de seguridad va a requerir ser administrado (otra consola para el equipo de Seguridad) y controlado (más controles específicos) y va a tener que ser mantenido como pieza de software.

Por el contrario, mediante los sidecars, el desarrollador “llama” a librerías que, en general, se encuentran dentro de los frameworks, para implementar (desacoplar) lógica de “soporte” a la solución y, como comentábamos antes, los sidecars gestionados por la service mesh, van a ser quienes se apoyen en otros componentes centrales, por ejemplo en un proveedor de identidades que gestione la autenticación y la autorización.

Si fui lo suficientemente claro, me permito retomar la hipótesis y dejarlos pensando en que, si observamos e implementamos correctamente estas arquitecturas, existen grandes beneficios para la gestión, la vigilancia y la resiliencia de ciberseguridad, temas que intentaré abordar en próximos posts.