
Si es como la mayoría de los profesionales de la seguridad, es probable que esté empezando a sentirse un poco frustrado con los microservicios, o tal vez mucho. Las arquitecturas de microservicios, es decir, las arquitecturas que aprovechan REST para construir muchos componentes modulares pequeños y distribuidos, son poderosas desde la perspectiva de un arquitecto de software.
¿Quiere cambiar componentes rápidamente sin cerrar toda la aplicación o quiere agregar nuevas funciones sobre la marcha? Los microservicios facilitan estos objetivos. En lugar de reconstruir una gran aplicación monolítica, puede modificar (o agregar) de forma independiente los servicios específicos que le interesen.
La desventaja de esto, por supuesto, es que puede ser una pesadilla desde la perspectiva de la gestión de la seguridad. Esto es así por varias razones. Para los arquitectos de seguridad, esto es un desafío porque una de nuestras herramientas más efectivas, el modelado de amenazas de aplicaciones, se basa en el análisis de las interacciones entre los componentes desde la perspectiva de un atacante.
Esto se hace bajo la premisa de que los canales de comunicación se mantienen más o menos iguales a lo largo del tiempo. Si un desarrollador envía una actualización cada cinco minutos, y si cambia la ruta entre los servicios, el modelo de amenaza solo es válido en ese momento. Si alguna vez trató de modelar amenazas (y mantenerse actualizadas) en una aplicación de rápido crecimiento que usa microservicios en gran medida, sabe exactamente lo frustrante que puede ser.
ir a dar un paseo
También es un desafío desde un punto de vista operativo. Detrás de escena, las implementaciones más populares de microservicios son la orquestación de Docker y Kubernetes. Esto significa que los contenedores que realmente ejecutan el servicio están diseñados para ser efímeros: se agregan nuevos contenedores para adaptarse a una mayor carga y los contenedores se vuelven a implementar para adaptarse a cambios de aplicaciones o configuraciones actualizadas.
Para ilustrar por qué esto es un desafío, imagine que tiene alertas del sistema de detección de intrusos, entradas de registro o actividad sospechosa de hace unos días. ¿Qué hosts/nodos están específicamente involucrados y en qué estado se encuentran?
Tratar de solucionar esto es como tratar de atrapar el viento: para cuando llegue allí, es posible que esos contenedores se hayan sobrescrito y reubicado varias veces. A menos que quede claro a partir de la alerta lo que sucedió (¿cuándo sucedió?), la resolución de su incidente ahora se basa en la ingeniería inversa del estado de un sistema altamente complejo en algún momento del pasado.
Afortunadamente, la arquitectura de malla de servicio es una tecnología relativamente reciente que puede ayudar mucho con esto. Una red de servicios como patrón de diseño puede ser de gran ayuda para los profesionales de la seguridad de varias maneras. Es poderoso para los desarrolladores, pero igualmente poderoso, si no más poderoso, para aquellos de nosotros en el espacio de la seguridad.
Cómo puede ayudar una red de servicios
¿Qué es una red de servicios? Una forma de verlo es como un «despachador de tráfico» para su servicio. Cuando un servicio quiere comunicarse con otro servicio, hay dos opciones. Opción uno: conoce todos los demás servicios que existen e implementa la lógica para hablar con ellos. Opción dos: requiere que otra persona haga el trabajo.
Piense en ello como enviar una carta. Si quiero enviarle una carta a mi primo en Kentucky, una opción es escribir la carta, subirme a mi automóvil, conducir hasta su casa y entregarle la carta. Depende de muchas cosas: sé su dirección, tengo un automóvil disponible y listo para funcionar, descubro cómo llegar a su casa, sé si se mudará, etc. Esto no es muy eficiente.
Una mejor opción sería que yo escribiera la carta, la dirigiera yo mismo y dejara que la oficina de correos lo hiciera por mí. Hacer que mantengan el equipo de mensajería y entrega necesario para que pueda concentrarme en lo que realmente me importa: hacer llegar mis cartas.
En términos de implementación, hay varias formas de hacerlo, pero la forma más común es a través de un contenedor «sidecar». ¿Qué es un contenedor sidecar? Es solo otro contenedor, uno que ejecuta un proxy que está configurado específicamente para dirigir el tráfico de aplicaciones entre servicios. Esto significa que puede configurarse e implementarse de tal manera que la «entrega» de mensajes esté desvinculada de la lógica de la aplicación.
Desde la perspectiva del desarrollo de aplicaciones, los beneficios deberían ser bastante obvios: los desarrolladores pueden centrarse en la lógica comercial, en lugar de la mecánica de la comunicación de «cosas» (es decir, la comunicación entre servicios). Pero desde el punto de vista de la seguridad, también hay ventajas.
En particular, proporciona un gancho para el monitoreo y otros servicios de seguridad. Esto se puede agregar sin necesidad de modificar (o, de hecho, incluso conocer) la lógica de la aplicación de los servicios individuales. Entonces, por ejemplo, si quiero permitir que el Servicio A se comunique solo con el Servicio B usando TLS y autenticación sólida, puedo hacerlo. Del mismo modo, si quiero registrar qué versión de un contenedor está hablando con otro contenedor en un momento dado, puedo configurarlo para que me lo diga.
Consideraciones de integración
Si esto suena atractivo para usted, debería hacerlo. De hecho, representa algo que rara vez sucede en el mundo de la seguridad: lo convierte en el camino de menor resistencia para que los desarrolladores hagan las cosas de una manera más segura en lugar de una forma menos segura.
Los desarrolladores lo encuentran atractivo porque no tienen que preocuparse por los detalles de comunicación y logística de entrega para poder comunicarse con otros servicios. Además, también agrega opciones de seguridad que, de otro modo, tendríamos que aplicar en la capa de aplicación.
Por lo tanto, si su organización está considerando microservicios, una arquitectura de malla de servicios puede ayudarlo a proteger ese entorno. Si ya está usando uno, comprender qué es puede ayudarlo a encajar en la conversación y brindarle las herramientas para aliviar algunos de los «puntos débiles» de los microservicios.
La única advertencia es que requiere algo de preparación para aprender el nuevo conjunto de herramientas y adaptar las herramientas arquitectónicas al nuevo modelo.Ya sea que esté usando istio+Mensajero, Linkerd, o algo más, primero debe leer la documentación para comprender qué está disponible, cómo funciona el conjunto de herramientas y qué opciones de política/configuración están disponibles para usted. Es una buena idea de todos modos, ya que es solo cuestión de tiempo antes de que necesite verificar esa configuración.
Además, si aún tiene la intención de crear un modelo de amenaza para su aplicación, es posible que desee considerar nuevos paradigmas, lo que siempre es una buena idea.
Específicamente, es útil tener una visión más lógica en su análisis de flujo de datos, tal vez analizando la entrada y la salida de cada servicio individualmente, en lugar de asumir que el «servicio A» solo se comunicará con el «servicio B» (O, peor aún, suponga que estático tráfico entre servicios basado en lo que está haciendo la aplicación en un momento dado).
El punto es que los profesionales de la seguridad no solo no deben tener miedo de una red de servicios, sino que deben considerar los argumentos sólidos para adoptarla activamente.
Las opiniones expresadas en este artículo pertenecen al autor y no reflejan necesariamente las de ECT News Network.