En el mundo de los microservicios, el objetivo es tener una pequeña pieza de software que realice un conjunto de tareas bien definida. Los microservicios son aplicaciones de software que son autónomas. Son pequeños servicios modulares de despliegue independiente que ejecutan un proceso único y se comunican a través de un mecanismo ligero y bien definido para cumplir un objetivo específico.
Normalmente, se establecen límites claros con respecto a lo que su microservicio puede o no puede hacer. El paso a los microservicios requiere no solo un cambio en la arquitectura, sino también una base sólida de confianza entre los diferentes equipos que trabajan juntos para desarrollar estos microservicios. La construcción de esta confianza les da la confianza que necesitan para confiar en la disponibilidad de los servicios y el cumplimiento del contrato de servicio acordado para las API estándar.
Sin un alto nivel de confianza entre los equipos de desarrolladores , el caos se producirá rápidamente en la organización de desarrollo. Cada equipo creará lo que quiera y/o cambiará las API sin notificar al resto de la organización. En este estado de confusión, la funcionalidad se romperá y el desarrollo de software se detendrá.
Si bien la confianza es extremadamente importante en el desarrollo de microservicios, la planificación anticipada ante posibles problemas de seguridad es aún más crítica. Desafortunadamente, las consideraciones de seguridad a menudo se pasan por alto en el proceso de transición a microservicios sin tener en cuenta que las consecuencias de los fallos de seguridad pueden ser devastadores para la empresa.
Por ejemplo, supongamos que se está implementando un microservicio que acepta la entrada de un usuario y pasa esa entrada a una base de datos back-end. Si su servicio no es seguro y la entrada no está validada, los piratas informáticos podrán inyectar código malicioso en el sistema y reducir parte del servicio, o tal vez incluso peor, comprometer todo el sistema.
Una plétora de microservicios
A medida que el repertorio de servicios y aplicaciones crece, probablemente sea más seguro suponer que la cantidad de microservicios disponibles también crecerá. A medida que aumente la cantidad de opciones, seguramente surgirán más y más problemas de seguridad. Hoy, veremos algunos de los problemas y posibles soluciones que debemos tener en cuenta antes de empezar a utilizar microservicios.
Reutilización del código
El uso de códigos compartidos y bibliotecas puede ayudar a impulsar el movimiento a microservicios, pero también puede ser una espada de doble filo. Si eliges usar una solución de código abierto, siempre estarás atado a ese código y a todas sus deficiencias.
Por un lado, la reutilización de la tecnología estándar de la industria puede ser algo bueno ya que ya se ha probado y utilizado en todo el mundo. Por otro lado, el uso generalizado de la tecnología estándar puede ser problemática. Si surge una vulnerabilidad del componente , nuestra compañía y otras compañías que están usando la tecnología necesitarán aplicar parches de emergencia para mitigar fallas críticas en todas las aplicaciones. Imagine lo que sería tener que implementar nuevamente todos sus servicios debido a un nuevo paquete de seguridad, o parchear los servidores con un binario completamente nuevo. Este escenario suena como una pesadilla, ¿no?
Si tomamos el fallo de Heartbleed, por ejemplo. Cuando se descubrió el error en abril de 2014, aproximadamente el 66% de los servidores web de Internet necesitaban un parche porque el software que incluía las bibliotecas vulnerables se usaba en casi todos los servidores web del mundo. Esta catástrofe requirió el parchado y el reinicio de cientos de miles de servidores en un período de tiempo muy corto.
Si tiene una cantidad menor de servidores, las soluciones de implementar todo de nuevo o aplicar parches con un nuevo binario son factibles, ya sea manualmente o con una cantidad básica de scripts. Pero cuando se escala, ya no son opciones viables para resolver este problema. En estos casos se debe tener un método probado y verificado de orquestación para poder realizar operaciones masivas rápidamente para aliviar este tipo de problemas.
Negación de servicio
Asegurarse de que las aplicaciones son seguras no es una hazaña fácil, y administrar una serie de servicios que tienen múltiples puntos de entrada desde el exterior puede ser difícil. A medida que crece la cantidad de servicios, la magnitud de este problema se amplifica. Una gestión adecuada de los grupos de seguridad ayudará a garantizar que solo se expongan los puertos correctos. Si esto se hace, puede ayudar a que nuestras aplicaciones no sufran una gran cantidad de dolores de cabeza y angustias si una parte maliciosa ataca nuestro producto en un ataque.
Configurar una aplicación de firewall o una solución alternativa en frente de los sistema puede corregir un problema como este, asegurando que solo el tráfico apropiado llegue a la puerta de entrada de nuestra aplicación y verificando que no contiene códigos maliciosos ni amenazas.
Tráfico entre microservicios
Cada microservicio se pasa información de uno a otro. Cuando el tráfico se encuentra en una parte segregada de nuestra propia red, es seguro asumir que el riesgo de tener un espía se reduce ya que generalmente se encuentra detrás de un cortafuegos corporativo, lo que lo hace menos susceptible a los ataques man-in-the-middle.
Cuando te mueves a la cloud, esta suposición ya no es válida. El tráfico entre los microservicios debe estar encriptado en cloud. Esto significa que, además de los microservicios que manejan el tráfico cifrado, también nos deberán asegurarse que el rendimiento de las aplicaciones subyacentes no sufra como resultado del trabajo adicional que se debe realizar con el cifrado y descifrado de la información.
Hay una serie de métodos que se pueden usar para mitigar este problema. Una de esas soluciones es la creación de una nube privada virtual (VPC), que nos permitirá segregar las cargas de trabajo en la nube sin permitir que un intruso malintencionado ingrese al sistema y pueda espiar el tráfico. Sin embargo, esta no es una solución infalible, y todavía tiene una serie de vectores de ataque que deberemos abordar. Otra opción es descargar el cifrado a un servicio externo (por ejemplo, un servicio de equilibrio de carga) que habilitará la protección del tráfico con una interrupción mínima o cambios en el sistema actual.
Seguridad en los secretos compartidos
Para asegurarnos que los microservicios no estén abiertos al mundo, te sugiero agregar autenticación entre los servicios de los sistemas. Hacer esto asegurará que solo las piezas correctas puedan hablar entre ellas y que tengan las credenciales adecuadas para hacerlo.
Incrustar estos secretos en sus aplicaciones es una muy mala idea. Las mejores prácticas para la arquitectura moderna recomiendan no almacenar ninguna credencial en los servidores. Por supuesto, esto plantea la cuestión de cómo permitirá que las aplicaciones se autentiquen entre sí y con servicios de terceros si las credenciales no se pueden almacenar localmente.
Hay algunas formas de abordar este problema. Una estrategia es usar herramientas de terceros o las herramientas y servicios que ya están disponibles en la mayoría de los proveedores cloud. El concepto es muy simple. Cuando inicia una solicitud de autenticación, le solicita a otro servicio que solicite un conjunto temporal de credenciales en su nombre, lo que le permite acceder durante un período de tiempo determinado. Esto resuelve el problema de la longevidad de las credenciales porque expiran después de un cierto período de tiempo, y porque no hay credenciales que estén incrustadas en el microservicio en sí.
Seguridad en todos los ámbitos
Es muy poco probable que aquellos que están produciendo el microservicio en realidad pertenezcan a un solo equipo. Tiene sentido que cada equipo desarrolle, pruebe y despliegue su propio microservicio (o conjunto de ellos). Por lo tanto, la responsabilidad de proteger el servicio no puede recaer únicamente en un único equipo y organización de seguridad operacional tradicional: debe recaer en todos los equipos que producen el software.
Para garantizar que una empresa esté protegida y protegida de atacantes externos, es recomendable que considere algún tipo de asociación entre el equipo tradicional de OPSEC y los desarrolladores ( Ya he hablado de los DevSecOps). Establecer dicha asociación ayudará a los participantes a trabajar juntos para que el software que están produciendo sea seguro por defecto, reforzado y probado continuamente para verificar el cumplimiento de una línea base de requisitos de seguridad antes de su paso a producción. Cuando la responsabilidad también recae en los equipos que están creando el servicio, su nivel de compromiso y conciencia aumentará considerablemente.
Cambios en el código
El último problema que abordaremos es el ciclo de vida de la aplicación. Nadie escribe software que sea 100 por ciento perfecto la primera vez, siempre habrá algunos errores que arreglar antes de que el software funcione tan eficientemente como se supone que debe hacerlo. Por ejemplo, la base de la metodología ágil se reitera todo el tiempo, proporcionando solo el producto mínimo viable y mejorando a medida que avanza en el proyecto.
Cuando se trata de microservicios, puede haber varios cambios cada día. Cuando actualicemos nuestra aplicación cambiando o agregando funcionalidades, deberemos asegurarnos de que el código sea (como mínimo) el mismo que antes, o incluso mejor. Esto requiere escanear el código agregado para detectar vulnerabilidades y debilidades antes de implementar el código. Debiendo vincular esto a los procesos de integración continua para que se realice como parte del proceso de lanzamiento.
Seguridad en los microservicios
El mantenimiento de un sistema seguro suele ser una tarea desalentadora, y con el cambio a microservicios, hay un vector adicional que se debe abordarse. Cada microservicio tiene sus puntos débiles respectivos que deben protegerse, reforzarse y controlarse continuamente en busca de vulnerabilidades.
El alcance de esta tarea no debe subestimarse: a medida que crece el uso de la arquitectura de microservicio, los problemas de seguridad se vuelven más importantes y urgentes. Para protegerse y proteger nuestra empresa, se deben abordar estos problemas de seguridad de manera temprana y de una forma continua.
La seguridad de los microservicios acaba de empezar
