Implicaciones de seguridad de serverless: de la infraestructura a OWASP

Por su propia naturaleza, serverless (FaaS) aborda algunos de los principales problemas de seguridad actuales. Al eliminar la gestión de la infraestructura, traslada sus problemas de seguridad al proveedor de la plataforma. Lamentablemente, los atacantes no se rendirán sin más, sino que se adaptarán a este nuevo mundo. Más específicamente, FaaS hará que los atacantes pasen de enfocarse en los servidores a enfocarse en los problemas de las aplicaciones que destaca OWASP, y los defensores deberían adaptar sus prioridades en consecuencia.

En esta publicación veremos qué problemas de seguridad resuelve serverless y cuáles no. Probablemente, cada uno de estos puntos merecería una publicación completa (¡quizás escriba algunas más adelante!), pero aquí no profundizaré demasiado en la mitigación ni en la gestión de riesgos, para enfocarme en el panorama general.

Aquí tienes una vista rápida de las áreas que deben preocuparnos.

¡Ahora, veamos los detalles!

¿Cómo ayuda serverless a la seguridad?

Serverless traslada la responsabilidad de administrar los servidores del propietario de la aplicación al proveedor de la plataforma. Estos molestos servidores son notoriamente difíciles de proteger, pero los expertos que administran las plataformas se encargan de ello bastante bien. Por eso, aquí tienes las tres principales amenazas de seguridad que serverless mitiga de forma significativa.

1. Sin servidores sin parches ni binarios vulnerables

Ante todo, serverless prácticamente elimina la principal fuente de exploits exitosos en la actualidad: los servidores sin parches. Estos servidores usan binarios con vulnerabilidades conocidas porque no aplicaron las últimas actualizaciones de seguridad de esas dependencias. Según la mayoría de los recuentos, las dependencias con vulnerabilidades conocidas representan la gran mayoría de los exploits exitosos actuales.

Aunque serverless no elimina la necesidad de mantener los servidores actualizados, traslada esta responsabilidad al proveedor de la plataforma. La administración de servidores es una de sus competencias principales, por lo que es muy poco probable que las máquinas no estén actualizadas.

2. La denegación de servicio se convierte en un problema de facturación

Los ataques de denegación de servicio impiden que un servidor atienda solicitudes legítimas y se repiten hasta que todos los servidores capaces de atender una solicitud dejan de estar disponibles. Al usar FaaS, los servidores se aprovisionan a pedido y se descartan (estoy pasando por alto las optimizaciones de rendimiento específicas de cada plataforma), por lo que la idea de «derribar un servidor» pierde sentido. Cada vez que llega una solicitud, legítima o no, la plataforma aprovisiona un servidor y ejecuta la función solicitada.

Cabe señalar que, aunque serverless elimina conceptualmente los ataques DoS como amenaza para la disponibilidad, las plataformas sí establecen límites de concurrencia que debes tener en cuenta. AWS Lambda tiene actualmente un límite predeterminado de 600 ejecuciones simultáneas de funciones. Además, un ataque DoS puede generar una enorme factura por uso, algo casi tan desagradable como el propio ataque. Así que no te confíes demasiado con el tiempo de ejecución ni con las vulnerabilidades ReDoS.

3. La inmutabilidad elimina los servidores comprometidos

En muchos ataques, explotar una vulnerabilidad es apenas el primer paso. En lugar de repetir los ataques, los atacantes buscan comprometer el servidor e instalar un agente malicioso para lanzar ataques posteriores y más profundos. Los ataques más dañinos, como las brechas de Sony y Target, involucran servidores comprometidos de este tipo.

En FaaS, los servidores son inmutables y de corta duración, lo que elimina de manera implícita la posibilidad de que un servidor comprometido permanezca activo durante mucho tiempo. Esta protección contribuye poco a reducir la probabilidad de que un ataque tenga éxito, pero ayuda mucho a limitar lo que puede ocurrir después del exploit y, con ello, los daños que puede causar.

¿Qué problemas de seguridad siguen igual?

Como vimos, serverless nos quita de encima, como propietarios de aplicaciones, algunas amenazas importantes. ¿Significa eso que los atacantes simplemente dejarán de atacar las aplicaciones serverless? Por supuesto que no.

Estos son los tres principales problemas de seguridad que serverless no resuelve. Aunque FaaS no los empeora, eliminar las amenazas mencionadas anteriormente hace que estos problemas suban naturalmente en la lista de prioridades de los atacantes. Por eso, es más importante que nunca tener en cuenta estos riesgos y abordarlos.

4. Las vulnerabilidades en tu código siguen ahí

Serverless te quita de encima la mayor parte de la «carga adicional», pero lo que queda es tu propio código, incluidas sus vulnerabilidades. Las vulnerabilidades a nivel de aplicación (por ejemplo, cross-site scripting y inyección SQL) siguen siendo graves si se explotan, y las técnicas de mitigación (por ejemplo, la validación de entradas y el acceso programático a bases de datos) siguen siendo tan esenciales como siempre.

Las prácticas recomendadas siguen siendo las mismas. Usa herramientas de pruebas de seguridad estáticas (SAST) y dinámicas (DAST), facilita la validación de entradas y, siempre que sea posible, prioriza las listas de permitidos, entre otras medidas. La guía OWASP Top Ten ofrece muchos consejos útiles sobre este tema, al igual que su guía de referencia.

5. Se incluyen dependencias vulnerables de la aplicación

A primera vista, las funciones FaaS parecen estar compuestas únicamente por tu código, pero eso no es del todo cierto. Las funciones también incluyen dependencias de la aplicación que se obtienen de npm (Node.js), PyPI (Python), Maven (Java) u otras plataformas pertinentes. Estos paquetes de código son como pequeños fragmentos de infraestructura integrados en tu aplicación.

Las dependencias de las aplicaciones son similares a las dependencias de los servidores, que suelen ser objeto de exploits. Son comunes y se descargan miles de millones de veces al mes; es difícil llevar un registro de los paquetes que usas; y con frecuencia son vulnerables, pues se divulgan nuevas vulnerabilidades con regularidad. Los atacantes ya están explotando dependencias vulnerables de aplicaciones, pero, al perder el camino fácil de las dependencias vulnerables de servidores, atacarán con toda su fuerza estas entidades similares.

Las vulnerabilidades conocidas son tan fáciles de detectar para ti como para los atacantes. Para proteger las dependencias de las aplicaciones, necesitas acceso a una buena base de datos y herramientas automatizadas que prevengan continuamente la incorporación de nuevos paquetes vulnerables y te alerten sobre los problemas recién divulgados. Snyk hace que todo este proceso sea muy fácil, ¡y te recomiendo que lo pruebes! De lo contrario, elige la herramienta que mejor se adapte a ti y a tu plataforma, pero no descuides este problema.

6. Los datos «en reposo» son igual de accesibles

Por último, serverless no hace nada para impedir que los atacantes accedan a tu base de datos. Si un atacante obtiene acceso a tus datos mediante alguna de las vulnerabilidades mencionadas anteriormente, credenciales filtradas, una persona interna comprometida o cualquier otro medio, FaaS no cambiará nada.

Si almacenas información confidencial, asegúrate de cifrarla correctamente. Los algoritmos criptográficos de código abierto están ampliamente disponibles y no hay una buena razón para no usarlos. Además, evita la tentación de darles acceso a todos a tu base de datos (¡incluso solo de lectura!) y, en su lugar, permite el acceso únicamente a las personas y los sistemas que más lo necesitan. FaaS permite una granularidad mayor en este aspecto: limita el acceso a las funciones que usan directamente la base de datos. Por último, no expongas tus almacenes de datos directamente a internet: como vimos con el reciente ataque a MongoDB y las declaraciones explícitas de Redis, estos sistemas se diseñaron para uso interno.

Marqué este problema como «neutral», ya que serverless no perjudica la seguridad de los datos en reposo. Sin embargo, como las funciones siempre son sin estado, en algunos casos el estado —incluidos los datos confidenciales que contiene— pasará de un almacenamiento local (por ejemplo, un sistema de archivos o la memoria) a uno en red (por ejemplo, Redis o colas). Asegúrate de aplicar las mismas prácticas de seguridad de datos a ese almacenamiento transitorio que al almacenamiento persistente, como una base de datos.

¿Qué problemas de seguridad empeora serverless?

Serverless no crea nuevos problemas de seguridad, pero sí amplifica algunos. La arquitectura que impulsa implica que aplicamos más ciertas prácticas y, al hacerlo, elevamos los problemas de seguridad que conllevan. Veamos las tres principales áreas en las que serverless dificulta la seguridad.

7. Servicios de terceros y datos «en tránsito»

Usar FaaS no hace que almacenes más datos, pero definitivamente hace que muevas más datos de un lado a otro. Los datos que tradicionalmente permanecían en la máquina ahora se transfieren entre funciones muchas veces y suelen modificarse ligeramente entre una llamada y otra. Además, su granularidad y naturaleza sin estado fomentan un mayor uso de servicios de terceros, lo que exige enviar y recibir datos a través de la red.

Cada vez que transmitimos datos, existe la posibilidad de que se filtren o manipulen. Además, cada comunicación implica confiar nuestros datos a la otra parte, tanto los que le enviamos como los que recibimos, lo que abre la posibilidad de que se abuse de esa confianza. Como en FaaS nos comunicamos más, debemos prestar más atención a este problema y protegernos mejor.

La seguridad de los datos es un campo amplio, pero te sugiero enfocarte en dos áreas: el cifrado y la confianza. Primero, asegúrate de cifrar todos los datos mediante HTTPS o claves y un KMS. Ambas técnicas también permiten validar la identidad del interlocutor. Segundo, desconfía de todas las entradas que provengan de una función o un servicio con el que te comuniques, incluso si se trata de otra función. Si una función confía implícitamente en otra, y ni hablar de un servicio de terceros, pronto crearás una cadena frágil que se romperá en cuanto uno de sus componentes se vuelva malicioso o se vea comprometido.

8. Más flexibilidad implica una mayor superficie de ataque

Una de las principales ventajas de serverless es su flexibilidad, que nos permite trasladar el flujo de control al cliente y admitir más casos de uso sin modificar el código del lado del servidor. Lamentablemente, una mayor flexibilidad también ofrece más oportunidades para que los atacantes hagan que tu sistema realice acciones imprevistas. Como dijo Mark Nunnikhoven: «Los desarrolladores se enfocan en resolver un problema; la seguridad analiza para qué más se pueden usar esas soluciones».

La única manera de abordar este problema es tratar cada función como su propio perímetro de seguridad. Esto significa que cada función debe depurar las entradas y salidas, proteger sus datos y encargarse de proteger su código y sus dependencias. Hoy en día, la mayoría de los sistemas tienen un perímetro sólido, pero un interior poco protegido. FaaS amplía enormemente este perímetro y exige un conjunto más amplio de defensas.

Por suerte, FaaS ofrece dos grandes oportunidades para aplicar una protección tan amplia. Primero, las funciones suelen ser más pequeñas, lo que facilita (aunque no es trivial) definir mejor lo que pueden y no pueden hacer en comparación con una aplicación completa, y hacer cumplir esos límites en el código y las pruebas unitarias. Segundo, las personas externas suelen invocar las funciones mediante la API Gateway, que permite definir un modelo o esquema para las llamadas y establecer restricciones más estrictas para las entradas y salidas permitidas. Asegúrate de aprovechar estas oportunidades y proteger cada función por separado.

9. La supervisión de seguridad se vuelve extremadamente difícil

Serverless hace que implementar código sea increíblemente fácil. Implementar una función en producción es prácticamente gratis, y los costos de ejecución son tan bajos y granulares que una función con poco volumen apenas se reflejará en tu factura. Esto significa que no tenemos ningún incentivo financiero para no implementar una función ni para eliminarla una vez implementada. Para empeorar las cosas, no hay una manera fácil de saber quién usa una función, por lo que eliminarla después de implementarla resulta muy arriesgado. Así se abre el camino para tener miles de funciones implementadas que casi nunca se usan.

Reducir las barreras para implementar código es excelente para la productividad, pero crea una pesadilla de seguridad. Cada función implementada es un posible objetivo de ataque y puede tener vulnerabilidades que se aprovechen para penetrar en tus redes privadas, manipular tu base de datos o lanzar ataques en tu nombre. Las dependencias de las aplicaciones integradas en estas funciones quedarán desactualizadas y se descubrirán nuevas vulnerabilidades en ellas, lo que facilitará la automatización de estos exploits. La complejidad de los sistemas de monitoreo hace que sea tan fácil explotar las dependencias vulnerables y tan difícil prevenirlo.

Además, las soluciones actuales de monitoreo de seguridad no funcionan en un entorno sin servidor. La mayoría requiere un agente en el servidor de larga duración (que ahora ya no existe), tiene una sobrecarga durante el inicio y la ejecución demasiado alta para ser razonable en FaaS y no puede escalar a pedido como lo hacen las plataformas sin servidor. Además, estas soluciones están diseñadas en torno a una aplicación de extremo a extremo, y su lógica e interfaz no están preparadas para la granularidad extrema de la arquitectura sin servidor.

Este es un desafío de todo el ecosistema y requiere nuevos enfoques. Asegúrate de llevar un seguimiento minucioso de las funciones que se implementan, quién las usa y qué dependencias utilizan. Aunque el costo operativo de ejecutar una función es bajo, ten en cuenta el costo total de propiedad, incluido el mayor riesgo de tener código sin usar, vulnerable o desactualizado en producción.

Con el tiempo, necesitamos que las soluciones de monitoreo de seguridad en tiempo de ejecución evolucionen y se adapten para funcionar sin agentes, con una sobrecarga baja y a gran escala. También necesitamos alternativas a las soluciones de monitoreo de infraestructura que te permitan llevar un seguimiento de las dependencias vulnerables de las aplicaciones en todas las funciones y te ayuden a actualizar o eliminar las funciones problemáticas. En Snyk, haremos nuestra parte y estamos trabajando para ampliar nuestra solución de CI/CD para dependencias vulnerables de aplicaciones, de modo que monitoree directamente las funciones implementadas: avísanos si quieres participar en la beta.

Resumen

La arquitectura sin servidor es increíble y está revolucionando la forma en que operamos las aplicaciones. También trae consigo un cambio sísmico de magnitud similar en el mundo de la seguridad: resuelve ciertos problemas, agrava otros y cambia las prioridades del resto. En esta publicación, intenté resumir las tres áreas principales en las que FaaS es mejor, igual o peor para la seguridad web, en comparación con otras técnicas de computación en la nube. Aquí tienes una tabla breve que las resume:

Como la arquitectura sin servidor es nueva, tenemos la oportunidad de integrar de forma natural las prácticas y herramientas de seguridad en la creación de aplicaciones sin servidor. Me entusiasma ver cómo crece y alcanza su enorme potencial, tanto para operaciones como para seguridad.