Retos de la seguridad de microservicios y cómo manejarlos

A medida que más organizaciones se alejan del monolito hacia arquitecturas más distribuidas, basadas en microservicios: ¿La seguridad se está manteniendo? Aunque algunas cosas han mejorado, los microservicios todavía presentan algunos desafíos de seguridad importantes con los que tanto los desarrolladores como los arquitectos se verán obligados a lidiar.

En esta entrevista, Daniel Bryant, CTO de SpectoLabs y consultor técnico independiente, habla sobre algunos de los desafíos que se presentan al abordar la seguridad de los microservicios, y algunas de las herramientas y técnicas que puede utilizar.

En comparación con las arquitecturas más tradicionales, ¿qué nuevos retos han introducido los microservicios en términos de seguridad?

Daniel Bryant: En el enfoque tradicional, tenías una cosa. Así que, si estaba comprometida, estabas en problemas. Es como poner todos los huevos en una canasta. El otro lado de eso es que, cuando rompes las cosas, de repente tienes que asegurar muchas más cosas. La superficie de ataque es mucho más grande. Ya no estás haciendo cosas como endurecer los bordes, y luego no mirarás detrás de eso.

El mayor desafío ahora es que cada desarrollador tiene que ser mucho más consciente de la seguridad. Hay muchas más cosas, hay mucha más superficie de ataque, y hay mucha comunicación entre todas esas cosas que están expuestas.

¿Qué tipo de herramientas y técnicas son importantes para la seguridad de los microservicios?

Bryant: Hay cosas como firewalls de aplicación web, [que son] muy populares. Muchas compañías con las que he trabajado usan cosas como F5, y en realidad son firewalls de F5. Cada vez más, estamos viendo más firewalls de software, incluso con Amazon.

Esa es claramente prevención, pero también hay que pensar en la detección. De modo que, cosas básicas: registro de bandas bajas en el tráfico, registro del tráfico web, registro de acceso SSH [Secure Socket Shell]. [En] cualquier servidor web de cara al público, si se mira a través de los registros, la gente está constantemente probando los bordes. [Por lo tanto], usted desea ver [si es] solo de esta dirección IP o solo de este país... quiere estar haciendo una especie de tipo de análisis continuo de dónde vienen las cosas.

[Además,] ¿qué ataques hay? ¿Qué vectores están tratando de sondear? Si usted no está parchando sus sistemas, pueden quizás tener suerte un día. Por lo tanto, definitivamente necesita detección y necesita asegurarse de que todo está parchado. [La gente dirá:] 'Sí, gastamos todo este dinero en redes y en cómputo'. Eso es todo bueno, pero no se olvide de la aplicación. Si la aplicación tiene una vulnerabilidad masiva, todo lo demás es para nada. Solo se necesita un punto de entrada para que alguien entre y empiece a hacer daño.

Definitivamente creo que las cosas como el modelado de amenazas [también son] muy útiles. Entienda cómo funcionan las amenazas, qué amenazas existen y modele cómo pueden atacar su sistema. Y, a menudo, me parece, un efecto secundario de modelar las cosas correctamente abre mis ojos a diferentes maneras en que suceden las cosas. Por lo tanto, si empieza a hacer vectores de ataque, de repente piensa: ‘Bueno, estoy realmente endureciendo esto en la aplicación’, y puede darse cuenta de que hay una falla masiva en su sistema de correo electrónico o algo así.

[Y] OWASP [Open Web Application Security Project], son una organización impresionante. Tienen un montón de herramientas de diagnóstico o de lenguaje para escanear vulnerabilidades críticas en dependencias. Por lo tanto, si estoy usando Java o Maven, puedo ponerlo en mi Maven Palm. Si estoy usando Ruby, puedo ponerlo en mis gemas.

¿Cuál es la pregunta que todo el mundo debería estar preguntando cuando se trata de seguridad de microservicios?

Bryant: ¿Cómo puedo contribuir? Pregunte a su equipo, pregunte a su dirección, a sus líderes: ¿Qué puedo hacer? ¿Cuál es mi trabajo en relación con nuestra seguridad? ¿Debo seguir ciertos estándares? ¿Debo revisar dos veces mi trabajo? Este tipo de cosas son las más críticas.

Realmente creo que la seguridad de los microservicios no es masivamente diferente a la seguridad tradicional. Como desarrolladores, estamos tomando más y más... Tengo que ser una persona de operaciones, así como el desarrollador. Ya sabes, front end, back end, todas estas cosas. Si no se tiene cuidado, uno se vuelve como de una milla de ancho y una pulgada de profundidad.

Pero, al mismo tiempo, si usted como desarrollador está realmente bien educado a través de la pila, pero no sabe demasiado acerca de seguridad, es muy fácil dejar agujeros masivos. Si deja algunos agujeros de seguridad masivos, eso es potencialmente muy malo. Así que, desarrollar conciencia, modelar, documentar, compartir, venir a conferencias, charlar con la gente, aprender todo lo que se pueda... todo eso es importante.

¿Sobre qué están los expertos están aún rascándose la cabeza respecto a la seguridad de los microservicios? ¿Esa cosa que la gente parece todavía no conseguir realmente bien?

Bryant: No está pegado [específicamente] a microservicios; es más un caso de cómo el mundo está volviéndose cada vez más conectado. Hay cosas como bitcoin [que son] cada vez más atractivas para que los atacantes arremetan ahora.

Creo que, como industria, no somos tan responsables como deberíamos ser. Por lo tanto, es más un caso de que es solo el factor humano de nuevo. ¿Le estamos prestando suficiente atención como desarrolladores o como arquitectos? ¿Estamos haciendo cosas como defensa en profundidad? ¿Estamos haciendo cosas como auditoría y registro, y luego revisando de nuevo esas cosas? Hay algunas cosas básicas como términos de codificación que, de nuevo, no hacemos.

Cuando se trata de seguridad, ¿qué es mejor en una arquitectura tradicional como la arquitectura orientada a servicios (SOA) frente a una arquitectura distribuida de microservicios?

Bryant: No mucho ha cambiado en el punto de vista del principio. Lo único que diría [es que], con SOA, teníamos mucho más gobierno. SOA estaba impulsada por la ley de los proveedores... [Ellos] estaban diciendo: 'Usted debe usar mi ESB [bus de servicio empresarial] o mi  tecnología [particular]’. Había muchas desventajas en eso, pero una de las ventajas era que alguien lo poseía. Así, usted tiene esta ESB, esta cosa [gestionando] todas las conexiones dentro de sus servicios [y estaba] su trasero en la línea, básicamente. Así que, ellos realmente invertían en política y gobernanza y todo este tipo de cosas. Si algo salía mal, sabías a quién llamar.

Mientras que, en estos días, vamos hacia tecnologías más ligeras, pero usted tiene que asumir más responsabilidad como desarrollador y como arquitecto. El gobierno y la política y lo demás, por malo que a veces era, había una ventaja en ello. Es lo mismo con la política: cuanto más control tienes, obviamente menos libertad tienes, pero es un equilibrio que está allí en alguna parte.

¿Cómo pueden los equipos de DevOps trabajar mejor con los equipos de seguridad para asegurar que los servicios estén seguros?

Bryant: Toda la filosofía de DevOps se trata de unir a todos. Por lo tanto, muchas de las consultorías en las que trabajé realmente trataban e incorporaban a infosec [seguridad de la información]; en una organización clásica, a menudo se les llama infosec. Llévelos al proyecto temprano, porque en general son gente buena, pero no se les consulta hasta que las cosas van a salir en vivo. Así que tiene que involucrarlos antes. Su conocimiento es muy valioso, por lo que involucrarlos antes es grandioso.