Funcionar como un servicio (más seguro)

Existen varios enfoques modernos para la arquitectura y el desarrollo de aplicação que básicamente toman la forma de "hacerlo más pequeño y, por lo tanto, más eficiente".

Tanto los microservicios como la función como servicio (FaaS) se basan en el concepto de código muy específico. Ahora bien, si bien es cierto que la mayoría de las organizaciones no están descomponiendo las aplicações en cientos de microservicios o miles de funciones, están gravitando hacia este diseño. Esto se debe a menudo a que facilita el desarrollo ágil, ya que un equipo relativamente pequeño puede diseñar, desarrollar y luego perfeccionar un servicio mucho más rápidamente que una aplicação grande y monolítica. Después de todo, es mucho más fácil escribir y probar algo que tiene 1.000 líneas de código que una aplicação más grande que tiene 100.000 líneas de código.

Pero hay otro beneficio interesante de los microservicios y FaaS que no se promociona tanto como debería: la seguridad.

Hay muchas discusiones en Internet (y he leído una cantidad significativa de ellas) que intentan determinar la densidad de defectos y vulnerabilidades "promedio de la industria". Encontrará una amplia gama de estimaciones, algunas basadas en escaneos reales de código fuente abierto y otras basadas en números autoinformados. La NASA, por ejemplo, ha promocionado con orgullo su extremadamente baja densidad de defectos como una de las razones del éxito del programa del transbordador espacial. También hay informes basados ​​en datos recopilados objetivamente por empresas de seguridad como WhiteHat, pero sus números se centran en vulnerabilidades por aplicação y no necesariamente por líneas de código.

No existe un consenso real sobre la densidad de defectos y vulnerabilidades, excepto que sí existe uno.

Es lógico, sin embargo, que cuantas menos líneas de código escribas, menos defectos y vulnerabilidades es probable que se introduzcan. Igualmente importante es que cuantas menos líneas de código tengas que buscar para encontrar una vulnerabilidad o un defecto, más rápido lo encontrarás y, se supone, lo solucionarás.

Una de las razones por las que esto es cierto es el alcance. Si mi microservicio o función se centra en codificar un aspecto de la lógica empresarial, requiere menos lógica y menos bibliotecas para implementar. Ese alcance más pequeño significa menos posibilidades de introducir errores en la lógica o vulnerabilidades en las bibliotecas (de terceros o de otros) necesarias para implementar esa lógica adicional. Cada vez que tienes que incluir otro componente o llamar a otro servicio estás introduciendo oportunidades de defectos y vulnerabilidades.

Menos interfaces con la función o el microservicio también contribuyen a que el código sea más seguro. Cada interfaz (un punto de entrada como una llamada API) introduce la posibilidad de una vulnerabilidad porque está manejando la entrada del usuario. Y la entrada del usuario, como todos sabemos, siempre debe tratarse como sospechosa y potencialmente maliciosa .

Y si los microservicios reducen el potencial de vulnerabilidades y defectos, entonces reducir aún más el alcance de una función debería disminuir aún más la posibilidad.

Ahora bien, esto no quiere decir que los microservicios y FaaS sean inherentemente más seguros que sus contrapartes monolíticas y de tres niveles. El código descuidado es código descuidado, sin importar cuántas líneas ocupe. Pero es cierto que ambas arquitecturas se prestan a prácticas de desarrollo y entrega que pueden conducir a un código más seguro.

Tener en cuenta los beneficios de seguridad al evaluar o implementar microservicios y/o FaaS puede ayudar a evitar que el código crezca excesivamente, además de protegerse contra la introducción de vulnerabilidades.