En el post anterior (LINK) me propuse explicar, alto nivel, las diferencias existentes entre una arquitectura monolítica y una de microservicios y, en base a esta explicación, compararlas como método para comentar los beneficios que pueden tener las de microservicios por sobre las monolíticas, por supuesto, si se tiene en cuenta la gestión centralizada y estandarizada mediante gestores de plataforma (PaaS) y de redes de microservicios (Service Mesh).

En línea con esto continúo el desarrollo abordando la problemática de la resiliencia en términos de ciberseguridad.

Para hablar de resiliencia, no esta de mas comenzar con una definición, obviamente hay muchas, la que más me gustó es:

“Resiliencia es la capacidad de entregar continuamente el resultado esperado a pesar de la existencia de eventos adversos”

Reaccionar frente a un incidente con arquitecturas monolíticas o altamente acopladas puede requerir un gran esfuerzo y tiempo de resolución mientras que, en el caso de las de microservicios, el desacoplamiento, la estandarización y centralización de la gestión la hace menos compleja y propone un esquema de diagnóstico y solución de problemas menos escabroso.

Para explicar mejor esto, propongo utilizar un motor como analogía. Podemos considerar un motor ensamblado y en funcionamiento como una aplicación monolítica y, desarmado, pero en funcionamiento también (acompáñenme con la imaginación) como una solución basada en microservicios. En esta última, debemos considerar que cada pieza es un microservicio que entrega su propio valor agregado e interactúa con el resto para entregar aun mayor valor, es decir, para que el motor funcione.

Si consideramos que el motor monolítico falla o no entrega el resultado esperado, deberíamos realizar el siguiente proceso:

1. Diagnóstico del problema (si es que tengo información de sensores)
2. Desarme
3. Inspección
4. Reparación
5. Armado
6. Prueba en ambientes controlados
7. Puesta en producción

Detallo estos pasos justamente para que se vea de forma tangible el esfuerzo y tiempo que puede requerir esta solución y, sobre todo, si volvemos a la definición de resiliencia, se observe que la pérdida de disponibilidad puede ser total o que el servicio, como un todo, se vea considerablemente impactado.

Por el otro lado, si analizamos el motor basado en microservicios, podríamos simplificar este proceso considerando los siguientes pasos:

1. Diagnóstico: Si implementamos PaaS y Service Mesh obtenemos grandes beneficios en términos de logging y tracing y, por ende, en la posibilidad de hacer diagnósticos en caliente
2. Reparación: Solo del microservicio que falló
3. Prueba
4. Puesta en producción: Solo del microservicio que falló y en general con despliegues automatizados

Nuevamente detallo un posible proceso en función de dar claridad a la explicación y, si lo logré, me acompañarán si concluyo que este accionar requerirá menor esfuerzo y tiempo de recuperación y, por lo tanto, se puede entender que si lo que falló es una pieza del motor, es probable que la falla tenga menor impacto en la solución como un todo y que el motor pueda seguir entregando valor.

Ahora, para ser resiliente en términos de ciberseguridad, no alcanza solo con implementar arquitecturas de microservicios, debido a que una “falla” o ataque, no necesariamente implica que notemos una indisponibilidad o un comportamiento anómalo.

En términos de prevención y resiliencia, no podemos escapar a las medidas básicas y conocidas de seguridad, entre otras:

• Gestionar los parches
• Gestionar identidades de usuarios y privilegiadas (IAM y PAM)
• Protegernos ante malware
• Cifrar las comunicaciones y la información
• Aplicar seguridad en Sistemas Operativos y plataformas (Hardening)
• Segmentar la red incluyendo el centro de cómputos (norte a sur y este a oeste)

Adicionalmente agrego a esta lista la implementación y evangelización de una no tan nueva, forma de pensar, Zero Trust.

Considerando la complejidad que hoy tienen los ciber ataques, confianza cero propone un cambio de mindset por el cual debemos considerar que:

• La red siempre es hostil
• No existe zona de red de confianza: Dejar de considerar perímetros que separan zonas de confianza de las no confiables
• Las amenazas siempre están presentes: Es decir, consideramos al atacante dentro de la red, solo debemos encontrarlo
• Todo dispositivo, usuario, aplicación, componente de infraestructura o tráfico, debe autenticarse y autorizarse: En función con dejar de pensar en zonas de confianza, no debemos seguir considerando que como la aplicación o el tráfico se encuentra dentro de una red privada y confiable, podemos carecer de autenticación, autorización y cifrado.
• Loguear e inspeccionar todo

Nuevamente es que, implementando soluciones tipo PaaS y Service Mesh, esta gestión de lo básico y de lo necesario para aplicar confianza cero, se torna menos complejo. Por ejemplo, mediante distintos sidecars podemos nutrir a cada microservicio de capacidades como proxy reverso, firewall de aplicación web (WAF), cifrado, logging y tracing, etc. Y considerando la capa de gestión de la plataforma (PaaS) podemos estandarizar las configuraciones de los contenedores, asegurarnos que no se implementen versiones de componentes no homologadas o vulnerables, mantener un nivel de patching específico, etc.

Por supuesto, es muy probable que si han seguido noticias sobre como evolucionaron los ataques de ciberseguridad en los últimos años, estarán pensando que, a pesar de hacer todo esto, es todavía muy complejo detectar un ataque del tipo ATP (Advanced persistet threath) y por lo tanto, ponemos en juego la resiliencia del negocio.

Así como antes introduje el cambio de mindset que debemos abordar en línea con la práctica de Zero Trust, para el caso de la detección de amenazas avanzadas es que debemos dejar de pensar en función de monitorear, para considerar actuar en términos de vigilancia. Esto quiere decir que debemos considerar que estamos bajo ataque continuamente, en otras palabras, buscar constantemente al atacante, aunque los sensores nos digan que todo funciona normalmente.

A partir de esto es que dejaré para el próximo post analizar ¿cómo, mediante la vigilancia y la seguridad ofensiva, podemos estar mejor preparados frente a un ataque en función de gestionar un negocio resiliente?.