Header Ads Widget

Ticker

6/recent/ticker-posts

¿Qué es más seguro: monolito o microservicios?

 


Hay muchas cosas que me gustan de los microservicios: facilitan el escalado, ayudan a aislar fallas y hacen posible alimentar a todo un equipo de desarrollo con solo dos pizzas . Dicho esto, una mayor preocupación para algunos es la seguridad ...

¿Son los microservicios más o menos seguros que los monolitos? ¿Qué debe tener en cuenta al cambiar de una arquitectura a otra? Responderemos esas preguntas, y otras, en esta comparación de cinco partes de seguridad de monolitos y microservicios.

Superficies de ataque

Una consideración de seguridad importante al elegir entre un monolito y microservicios es la cantidad y el tamaño de las superficies de ataque. Una superficie de ataque es la suma de las vulnerabilidades de una aplicación: cuanto más pequeña, mejor. En un monolito, solo hay una superficie de ataque, aunque considerable. Sin embargo, con los microservicios, cada servicio tiene su propia superficie de ataque, pero de menor tamaño.

Aquí, la arquitectura ganadora a menudo depende del tamaño y la complejidad de su aplicación. Una aplicación pequeña y sencilla tiene menos vulnerabilidades, por lo que la superficie de ataque singular de un monolito aún puede ser manejable. Por otro lado, las debilidades de una aplicación única y multifacética pueden volverse abrumadoras a menos que se dividan, como en un enfoque de microservicios.

“El efecto neto de esto es que cada [micro] servicio tiene una superficie de ataque más pequeña: la suma de los puntos en los que una pieza de software puede ser atacada. La superficie de ataque más pequeña también facilita que el personal de seguridad sepa dónde distribuir los parches de seguridad. Un ejecutable de aplicación monolítica puede terminar con muchas funciones y componentes de software diferentes en su interior, lo que dificulta que los profesionales de la seguridad sepan exactamente dónde se está ejecutando el software que necesita parchearse ". Bernard Golden, 4 formas de explotar la arquitectura de microservicios para mejorar la seguridad de las aplicaciones

Acoplamiento

Otro factor a considerar al comparar la seguridad monolítica con la seguridad de microservicios es el nivel de acoplamiento. Las partes individuales de un monolito están intrínsecamente más conectadas que los servicios en una arquitectura de microservicios. Esto significa que si un aspecto de un monolito es explotado o falla, otros pueden seguirlo.

Por otro lado, los microservicios están desacoplados por diseño. Si bien esto significa que hay más superficies de ataque para proteger (como se discutió anteriormente), la probabilidad de una vulnerabilidad en cascada en múltiples aspectos de la aplicación es mucho menor. Sin mencionar que el desacoplamiento también hace que sea más fácil abordar problemas individuales y realizar actualizaciones sin cerrar toda la aplicación.

“En una arquitectura monolítica, todo el código es parte de un solo producto. Si surge un problema de seguridad, todo el sistema puede estar expuesto a ataques y, como resultado, puede verse afectado. Esto hace que sea muy difícil aislar las posibles amenazas a la seguridad, ya que ahora todo el sistema puede verse comprometido y el software malicioso podría propagarse por todas partes. Bloquear partes del sistema donde ocurrió una infracción puede ser bastante difícil con esta arquitectura, ya que no desea apagar todo el sistema para solucionar un problema ... La separación crea dispositivos de seguridad que detienen preventivamente los problemas de seguridad dentro de servicios específicos antes de que se propaguen a otras áreas del sistema ". Bob Brodie, Aumente la seguridad mediante la transición de la arquitectura monolítica a la arquitectura de microservicios

Autenticación

La autenticación es definitivamente un tema pertinente cuando se trata de seguridad, especialmente en el caso de los microservicios. Mientras que los monolitos tienen todos los recursos necesarios a mano, los microservicios deben comunicarse entre sí para acceder a los recursos; un esquema de autenticación efectivo asegura que solo los servicios y usuarios apropiados puedan obtener acceso.

“La autenticación entre microservicios no es algo en lo que los equipos piensen cuando provienen de un monolito. No es necesario que se autentique cuando llame a una función en código entre bibliotecas en un servidor. Los microservicios son una situación totalmente diferente. Es fundamental asegurarse de que cada servicio pueda autenticar no solo el servidor que solicita datos, sino también el contexto del usuario que ha iniciado sesión. En un monolito, esta es información que simplemente se almacena en la memoria. En un microservicio, esa es la información que debe pasarse con cada solicitud ". Eric Boersma, las 10 principales trampas de seguridad que se deben evitar al migrar de un monolito a microservicios

Cuando se implementa correctamente , la autenticación (y la autorización) son activos invaluables en una arquitectura de microservicios, que actúan como un control de seguridad adicional con cada recurso al que se accede. Si se implementa de manera deficiente, lo cual es cierto en muchos sistemas de autenticación internos, puede introducir nuevas vulnerabilidades de seguridad y mucha redundancia. Para citar al experto en seguridad de API Keith Casey , "si desea atraer piratas informáticos, cree su propio sistema de autenticación".

Vigilancia

En un mundo perfecto, la seguridad no tiene ninguna vulnerabilidad de producto. Sin embargo, en realidad, la seguridad es saber que algunas amenazas pueden estar ocultas a la vista. Cuando los piratas informáticos aprovechan las vulnerabilidades, los profesionales de la seguridad deben tener los medios adecuados para diagnosticar y responder. Como tal, monitorear el comportamiento anormal es un proceso invaluable en cualquier programa de seguridad.

“Lo más importante de todo es que [los piratas informáticos] quieren actuar sin ser detectados ni monitoreados. Si pueden actuar con lentitud, con el tiempo, tienen la oportunidad de hacer mucho más ". Keith Casey, Cómo construir una estrategia de seguridad API efectiva

El monitoreo del uso es definitivamente más fácil con un monolito que con microservicios, más aún si desea fusionar los datos de uso de diferentes partes de una aplicación. Por supuesto, el monitoreo todavía es muy factible para los microservicios, pero requiere una mayor inversión.

“En mi experiencia, la supervisión de servicios en microservicios se omite por dos razones. La primera es que es tediosa. Necesita agregar ese monitoreo a cada servicio, y eso lleva tiempo. En segundo lugar, no parece que se necesite supervisión; los servicios tienen una estructura tan simple que un ingeniero "solo sabrá" si algo va mal ". Eric Boersma, las 10 principales trampas de seguridad que se deben evitar al migrar de un monolito a microservicios

Contenerización

Una consideración de seguridad final (indirecta) a tener en cuenta es la de contenerización. A menudo, los microservicios se alojan en entornos en contenedores, que pueden tener varios beneficios de seguridad. Por ejemplo, existen numerosas soluciones de monitorización de contenedores, que pueden facilitar el tedioso proceso de monitorización descrito anteriormente.

"La capacidad de medir y comparar el comportamiento de la red observado con un modelo predictivo para un microservicio es una ventaja clave que brindan las arquitecturas en contenedores". John Morello, citado en Microservices Security: probablemente no es lo que crees

Conclusión

Habiendo revisado cinco consideraciones de seguridad primordiales en el debate de monolitos versus microservicios (superficies de ataque, acoplamiento, autenticación, monitoreo y contenedorización), una cosa está clara: ninguna arquitectura se destaca sobre la otra. Tanto los microservicios como los monolitos tienen ventajas y desventajas en términos de seguridad. Sin embargo, lo que está claro es que el enfoque monolítico puede facilitar la seguridad para aplicaciones más pequeñas y viceversa.

Publicar un comentario

0 Comentarios