Los beneficios de la arquitectura de microservicios –equipos de desarrollo más pequeños, ciclos de lanzamiento más rápidos, menos dependencias, menos riesgo– se están volviendo sumamente conocidos gracias a que compañías como Amazon, Google y Netflix están compartiendo sus experiencias.

Pero un tema menos conocido, y que no se entiende del todo, es el de los desafíos de seguridad introducidos por este nuevo paradigma. No obstante, los ingenieros que se encuentran en la vanguardia tienen mucha sabiduría y conocimientos que ofrecer en este frente también.

Usted necesita tener en mente más detalles antes de quitarle la envoltura al contenedor de aplicaciones.

En vez de asegurar una aplicación monolítica o dos, usted es ahora responsable de, quizás, docenas de servicios más pequeños, todos capaces de interactuar en uno con el otro de distintas maneras. Además, usted está tratando de asegurar y proteger esos servicios de ataques externos y malos usos internos, ya sean deliberados o no.

No es como en los viejos tiempos

Las aplicaciones monolíticas, el día de ayer, eran grandes e inflexibles, y las arquitecturas orientadas al servicio creadas para reemplazarlas tenían sus propias complejidades. Reemplazar estas pilas por aplicaciones débilmente acopladas, implementadas a través de contenedores inmutables, parece un paso hacia la dirección correcta, y lo es. Sin embargo, también significa varias rupturas con la tradición, muchas de las cuales afectan la seguridad.

Estos cambios significan que los desarrolladores terminarán asumiendo responsabilidades que una vez estuvieron a cargo del departamento de operaciones. La seguridad adentro, y entre los microservicios, pertenece a esa categoría. Un buen argumento puede ser el de quién tiene la mejor comprensión de la seguridad –desarrollo u operaciones– pero recuerde que los desarrolladores son dueños de las APIs que gobiernan cómo los servicios interactúan con otros servicios y con el mundo exterior. Es decir, gran parte de la carga de seguridad cae en ellos.

Para la gente de operaciones, asegurar los microservicios significa descartar suposiciones sobre, incluso, qué herramientas pueden ser utilizadas. Owen Garrett, director de productos en Nginx, señala en un correo electrónico que “muchas de la tecnología desarrollada para gestionar aplicaciones tradicionales basadas en la web, no puede ser aplicada directamente a las aplicaciones de microservicios”.

Esto incluye a la seguridad, no sólo las aplicaciones de firewalls, “sino los procesos internos de IDS, también”.

Tanto en el front-end como en el back-end

Otra razón por la que los microservicios hacen la seguridad más difícil: hay muchas más partes móviles que atacar.

Como Garrett explica, “la superficie de ataque de una aplicación de microservicios puede ser mucho mejor (que una aplicación monolítica tradicional])”. En las aplicaciones antiguas, “la superficie de ataque es muy lineal -el tráfico golpea el equilibrador de carga, luego la web (la capa de presentación), y después la aplicación y los niveles de datos”.

Pero con los microservicios, Garrett señala que el flujo es completamente diferente: “por lo general es necesario exponer un gran número de diferentes servicios para que las aplicaciones externas puedan dirigirse a ellos directamente, lo que lleva a una superficie de ataque mucho mayor”.

“Si divide su aplicación en servicios más pequeños”, anota Kesley Hightiwer, gerente de producto y principal abogado de CoreOS, “necesitará una solución de autenticación más robusta entre cada servicio. Esto puede ser un reto para muchas organizaciones, ya que solo necesita implementar este nivel de seguridad entre los usuarios y sus productos”.

Luego, se tiene que asegurar el acceso a los datos. Jonah Kowall, vicepresidente de desarrollo de mercado y perspectivas en AppDynamics, ha observado la manera en la que Netflix, un usuario de microservicios influyente, ha abordado el tema del almacenamiento de datos. “Netflix recomienda mantener el almacenamiento de datos para cada servicio autónomo”, señala en una conversación por teléfono. Esto reduce las interdependencias entre servicios, pero incrementa el número de almacenes de datos.

En vez de residir en un único repositorio central (como el RDBMS de una aplicación tradicional monolítica), los datos en una arquitectura de microservicios están altamente distribuidos. Por lo general, estarían divididos entre varios tipos de almacenes de datos (Cassandra y Riak, en el caso de Netflix).

“Eso se convierte en un problema importante de seguridad”, anota Kowall, “porque entonces usted no tendrá ni siquiera una manera centralizada de determinar si están pasando cosas malas. Se crean así una gran cantidad de cuestiones y problemas en torno a dónde iría para [encontrar] una única fuente de verdad, para validar el cumplimiento o cualquier tipo de regla que usted esté tratando de implementar para el control de la seguridad”.

Lo que está dentro también cuenta

Los retos creados por la panoplia de la tecnología en el nivel de datos se extiende a los propios microservicios. Dado que los microservicios son independientes el uno del otro, los desarrolladores, por lo general, tienen rienda suelta para implementar diferentes lenguajes, marcos de trabajo, middleware, y más. Por lo tanto, cada microservicios podría involucrar un conjunto completamente diferente de consideraciones de seguridad.

Así como Garrett señaló, “los problemas se agravan cuando cada microservicio es desarrollado independientemente de los demás, con su propia selección de idiomas y marco de desarrollo, y quizás sin normas de seguridad universales”.

Con los microservicios compuestos de contenedores, se vuelve incluso más difícil cuando se da cuenta que los contenedores tienen una mala reputación por ser opacos. Algunas soluciones están llegando al mercado: Twistlock, por ejemplo, comercializa un sistema de seguridad que pretende ayudar a los desarrolladores obtener un mayor control sobre lo que está pasando dentro de los contenedores. Sin embargo, no llegará ninguna solución coherente hasta que el estándar en el mundo de los contenedores se calme.

Existen mejores prácticas para los creadores de microservicios, incluyendo aquellos que tratan de abordar los problemas de seguridad. Entre lo mejor hasta ahora se encuentra la lista de preguntas Graham. Es un catálogo largo y potencialmente desalentador, pero pone de relieve la dificultad de obtener una garantía -no siempre por razones técnicas. Al final, si no está construyendo algo realmente nuevo con los microservicios, usted está solo -pero eso sucede también con cualquier otra tecnología de vanguardia.

-Serdar Yegulalp, JavaWorld