¿Qué es la seguridad sin servidor?

¿Qué es la computación sin servidor?

La computación sin servidor se refiere a un modelo de computación en la nube en el que el proveedor de la nube ejecuta el servidor y gestiona dinámicamente la asignación de recursos de la máquina. AWS Lambda Functions, Google nube Functions y Azure Functions son marcos populares sin servidor que crean aplicaciones.

Una arquitectura sin servidor proporciona el beneficio de un escalado automatizado, casi infinito. Muy poca diferencia entre los desarrolladores y el código implementado, lo que acelera el tiempo de comercialización y facilita el mantenimiento y la prueba de funciones individuales. Finalmente, la cantidad real de recursos de la aplicación consumidos afecta el precio, lo que significa que usted paga solo por lo que usa, lo que resulta en costos más bajos.

Serverless representa un cambio adicional de responsabilidades del cliente al proveedor de la nube. Sin infraestructura involucrada, hay una disminución significativa en los gastos generales de operaciones.

Transferir la gestión de la infraestructura a su proveedor de nube le permite centrarse en el desarrollo de soluciones para servir a su organización y a sus clientes. Le ayuda a mantener el enfoque en sus ventajas competitivas únicas y, con frecuencia, resulta en ahorros de costos no solo en computación, sino también en el cambio de personas al desarrollo.

¿Cómo mejora la seguridad sin servidor?

Aquí hay algunos puntos clave:

1. Los proveedores de la nube se encargan del sistema operativo, la seguridad en tiempo de ejecución y la aplicación de parches. Al implementar una aplicación sin servidor, usted cede el control sobre la mayor parte de la pila a su proveedor de nube, quien brinda servicios como administración de claves. Ya no posee SO, derechos de administrador, SSH ni segmentación. AWS, Microsoft y Google son confiables a la hora de mantener sus partes de la pila parcheadas y seguras, por lo que darles una porción más grande de la pila ciertamente mejora las cosas en ese sentido.
2. Apátrida/Efímero. Además, la naturaleza efímera y apátrida de la computación sin servidor hace que la vida de los atacantes sea más difícil. Las funciones sin servidor como AWS Lambda se ejecutan durante unos segundos y luego mueren. Los contenedores se reciclan. El hecho de que las funciones sin servidor vayan y vengan, al no tener memoria, reduce el riesgo de ataques a largo plazo.
3. Visibilidad de la aplicación sin servidor: el beneficio. El hecho de que las aplicaciones sin servidor estén estructuradas como una gran cantidad de pequeñas funciones en la nube ofrece una oportunidad fantástica para la seguridad. Las herramientas de seguridad de aplicaciones a menudo hacen todo lo posible para analizar e instrumentar su aplicación empaquetada solo para poder observar o filtrar el flujo interno de su aplicación.
4. Microservicio más pequeño = La capacidad de construir roles mínimos y adecuados para cada función. Pasar a un microservicio más pequeño le permite realizar una IAM más detallada. Tiene la oportunidad de aplicar políticas de seguridad a cada una de esas pequeñas cosas, lo que puede reducir significativamente su superficie de ataque.

Mientras cualquier función dentro de un contenedor necesite acceso para leer desde S3, todas las funciones dentro de ese contenedor también tendrían ese privilegio. Con AWS Lambda, tiene la oportunidad de aplicar privilegios a funciones individuales y garantizar que dichos privilegios estén restringidos solo al alcance más pequeño necesario. Si hay una vulnerabilidad en una de sus funciones, un atacante solo obtendrá acceso a las capacidades limitadas de esa función, no al gran conjunto de permisos para otorgar a un contenedor.

¿Cuáles son los desafíos de seguridad sin servidor?

Con la estructura cambiante de las aplicaciones sin servidor, surgen algunos nuevos desafíos.

1. La visibilidad de seguridad se vuelve más difícil. La cantidad total de información y el número de recursos aumenta con la falta de servidor. Esto dificulta su capacidad para dar sentido a todos los datos. Con mil millones de eventos en su registro todos los días, es un desafío obtener inteligencia de las montañas de datos para una verdadera observabilidad.
2. Los protocolos, vectores y puntos de ataque se han multiplicado por cada función, y Protocolo = un punto potencial de ataque. Esto requiere enfoques únicos para la seguridad de Google Functions, Azure Functions y AWS Lambda.
3. Más recursos = Más permisos para administrar. Más recursos equivale a más permisos para administrar, lo que crea desafíos en la determinación de permisos para todas estas interacciones. La tecnología automatizada puede detectar riesgos de configuración y generar automáticamente permisos de función de mínimo privilegio.
4. Observabilidad en aplicaciones sin servidor: el desafío. Las aplicaciones sin servidor utilizan diferentes servicios de varios proveedores de nube, en múltiples versiones y regiones. Para comprender su superficie de ataque y los riesgos potenciales, necesita una visión completa de todo su ecosistema sin servidor. A medida que su aplicación se propaga, esta visión centrada en la seguridad puede ser cada vez más difícil de construir y mantener.

¿Dónde implementar la seguridad sin servidor?

Con una aplicación sin servidor, no hay ningún lugar donde colocar la seguridad clásica como WAF, firewall e IDS. Construir muros entre atacantes y recursos no es simple por varias razones.

1. Si bien una implementación más rápida y frecuente puede ser muy positiva, la velocidad de la tecnología sin servidor puede plantear nuevos desafíos en la configuración de la seguridad.
2. Las herramientas de seguridad podrían agregar tiempo al procesamiento, que debe multiplicar por todas las solicitudes. Afortunadamente, la mayoría de las mejores prácticas de seguridad sin servidor no requieren ningún tiempo de procesamiento adicional.
3. Erosión del perímetro. La aplicación tradicional tenía un límite claro. El exterior y el interior eran distintos, y podríamos hacer seguridad en el perímetro. Si bien no es ideal que la seguridad permanezca exclusivamente en el perímetro, aún era posible construir un muro.

Las aplicaciones sin servidor son más porosas y detalladas. Las aplicaciones sin servidor, que constan de docenas o cientos de funciones, son un pequeño microservicio con sus propias políticas, función, API, seguimiento de auditoría, etc. Esto cambia la superficie de ataque, en lugar de un pequeño número de puntos de entrada con mucha funcionalidad oculta detrás de cada uno, ahora hay más puntos de entrada, cada uno con una pequeña parte de la aplicación detrás. Defender su aplicación ahora requiere pensar en cada punto de entrada.

Varios eventos pueden desencadenar funciones, tales como:

• Eventos de almacenamiento en la nube (p. ej. AWS S3, almacenamiento Azure Blob, almacenamiento en la nube de Google)
• Procesamiento de datos de transmisión (p. ej. AWS Kinesis)
• Cambios en las bases de datos (p. ej. AWS DynamoDB, Azure CosmosDB)
• Modificaciones de código (p. ej. Compromiso de código de AWS)
• Notificaciones (por ejemplo, SMS, correos electrónicos, IoT)

¿Qué son las amenazas a la seguridad sin servidor?

Si bien las motivaciones de los atacantes siguen siendo las mismas, las tácticas que utilizarán con la aplicación sin servidor deben cambiar. A continuación se presentan algunas de las amenazas a la seguridad sin servidor exclusivas de esta nueva arquitectura de aplicaciones.

1. La amenaza de las funciones con privilegios excesivas

Con la aplicación sin servidor, tiene la oportunidad de aplicar privilegios a funciones individuales y asegurarse de que dichos privilegios estén restringidos al alcance más pequeño necesario. Esto puede permitirle minimizar significativamente su superficie de ataque, así como mitigar el impacto de cualquier ataque.

Desafortunadamente, una investigación reciente de Check Point encontró que la gran mayoría de los desarrolladores no aprovechan esta oportunidad. Nuestra investigación descubrió que el 98 por ciento de las funciones en aplicaciones sin servidor están en riesgo, y el 16 por ciento se considera "grave". Además, la mayoría de estas funciones cuentan con más permisos de los que requieren, los cuales podrían eliminarse para mejorar la seguridad de la función y la aplicación.

Al analizar funciones, Check Point asigna una puntuación de riesgo a cada función. Esto se basa en las debilidades de postura descubiertas y factores no solo en la naturaleza de la debilidad, sino también en el contexto en el que ocurre. Después de analizar decenas de miles de funciones en aplicaciones en vivo, descubrimos que la mayoría de las aplicaciones sin servidor simplemente no se implementan con la seguridad necesaria para minimizar los riesgos. Los mayores problemas de postura de seguridad que Check Point descubrió son los permisos innecesarios, mientras que el resto tiene que ver con códigos y configuraciones vulnerables.

2. El ataque del Día de la Marmota

El hecho de que las funciones sin servidor sean efímeras y de corta duración hace que sea más difícil para los atacantes persistir en su aplicación a largo plazo. Además, esta es una de las muchas ventajas de seguridad de Serverless. Sin embargo, el simple hecho de que esto haga la vida más difícil para los atacantes no significa que detendrán los ataques; simplemente cambiarán la estrategia.

La corta duración de las funciones sin servidor significa que las amenazas a la seguridad sin servidor pueden cambiar de forma. Los atacantes pueden construir un ataque mucho más corto que solo robe, por ejemplo, algunos números de tarjetas de crédito. Esta única ronda del ataque se repite continuamente en lo que denominamos el ataque del “Día de la Marmota”.

3. Envenenamiento del pozo

A pesar de la corta vida útil de los recursos nativos de la nube, los atacantes aún pueden encontrar formas de lograr persistencia a largo plazo en su aplicación. Una forma en que los atacantes pueden eludir la naturaleza efímera de las aplicaciones sin servidor es mediante un ataque ascendente o "envenenamiento del pozo".

Las aplicaciones nativas de la nube tienden a comprender muchos módulos y bibliotecas con código de una variedad de fuentes de terceros. Los atacantes trabajan para incluir código malicioso en proyectos comunes. Luego, después de envenenar el pozo, el código malicioso en sus aplicaciones en la nube puede llamar a casa, obtener instrucciones y causar estragos.

4. Mayor tiempo para la configuración de seguridad sin servidor

Si bien esto no es precisamente una “amenaza” de seguridad, es más un desafío y un posible obstáculo para sus esfuerzos por proteger su arquitectura sin servidor.

Serverless transmite el beneficio de una mayor velocidad de desarrollo de aplicaciones. Desafortunadamente, el enfoque tradicional de seguridad, donde los desarrolladores escriben código y empaquetan cargas de trabajo, y las operaciones de seguridad luego ponen controles de seguridad alrededor de esas cargas de trabajo, simplemente no funcionará para servidores sin servidor.

Si los desarrolladores deben esperar la seguridad para abrir puertos, roles de IAM o grupos de seguridad para ellos, el beneficio de una mayor velocidad se erosiona rápidamente. Con demasiada frecuencia, la solución es eliminar SecOps de la ecuación, lo que de hecho podría ser un riesgo.

Por otro lado, configurar permisos para la miríada de recursos sin servidor e interacciones entre ellos es una tarea que consume mucho tiempo. Además, “gastar” el tiempo de los desarrolladores en esa configuración de seguridad puede resultar costoso rápidamente, además de no ser el uso ideal de su tiempo. Aprovechar la automatización, como CloudGuard Platform, puede aumentar la seguridad sin servidor sin dedicar excesiva cantidad de tiempo al desarrollador.

5. Mayor tiempo para el procesamiento de seguridad

Otro beneficio de Serverless es que solo paga por lo que realmente consume, lo que puede resultar en costos reducidos. Sin embargo, pagar exactamente por lo que usa significa que cualquier aumento en el tiempo de procesamiento aumentará los costos.

Colocar un exceso de configuración de app sec en su aplicación podría potencialmente agregar trabajo adicional a sus funciones, lo que puede aumentar los costos. Si bien agregar tiempo de procesamiento por el bien de la seguridad es una inversión sabia, requiere una implementación adecuada para evitar aumentos de costos excesivos e innecesarios.

De manera similar al aumento de tiempo para la configuración de seguridad sin servidor mencionado anteriormente, no es exactamente una amenaza, sino más bien un desafío que tendrá que afrontar mientras protege su arquitectura sin servidor.