Seguridad sin servidor: mejores prácticas para proteger su infraestructura sin servidor

Seguridad sin servidor: mejores prácticas para proteger su infraestructura sin servidor 1

Según un estudio de LogicMonitor , el número de aplicaciones alojadas localmente disminuirá entre un 10% y un 27% en. En comparación, el número de aplicaciones alojadas nativas de la nube, más específicamente sin servidor, como AWS Lambda, Google Cloud y Microsoft Azure, aumentará hasta el 41%.

La tendencia hacia la nube, específicamente sin servidor, y lejos de lo local, no es nueva ni sorprende, ya que las aplicaciones alojadas sin servidor brindan a los desarrolladores una velocidad de comercialización más rápida y les permite lanzar nuevas funciones con mayor frecuencia. Además, puede ahorrarle a las organizaciones enormes costos de infraestructura. Sin embargo, ha dejado a DevSecOps y a los equipos de seguridad en un dilema. Si bien no quieren impedir los esfuerzos de desarrollo, no les queda más remedio que poner la seguridad de las aplicaciones sin servidor en manos de otra persona.

Para aliviar este problema, existen varias prácticas recomendadas de seguridad sin servidor que se deben implementar para proteger adecuadamente las aplicaciones sin servidor lanzadas por el desarrollador.

Mejores prácticas de seguridad sin servidor

No confíe únicamente en la protección WAF: los firewalls de la capa de aplicación solo son capaces de inspeccionar el tráfico HTTP. Esto significa que un WAF solo protegerá funciones que sean funciones activadas por API Gateway. No brindará protección contra ningún otro tipo de desencadenante de eventos. Un WAF no ayudará si sus funciones se activan desde diferentes fuentes de eventos, como por ejemplo:

Tener un WAF sigue siendo importante, pero no es ni debería ser la única línea de defensa para proteger las aplicaciones sin servidor. Depender únicamente de un WAF deja muchos agujeros de seguridad abiertos.

Personalizar permisos de funciones:Se encuentra que el 90% de los permisos en aplicaciones sin servidor tienen permisos excesivos. Si bien configurar permisos parece una tarea desalentadora cuando se piensa en los niveles de función sin servidor, un enfoque único para todos no es una solución. Establecer políticas que sean más amplias y más permisivas en la función es un error común de seguridad sin servidor, y no minimizar los roles y permisos de las funciones individuales hace que la superficie de ataque sea mayor de lo necesario. La creación de permisos de nivel de función adecuados requiere que los equipos de DevSecOps se reúnan con los desarrolladores que escribieron las funciones y revisen qué hace cada función. Sólo después de determinar qué debe hacer realmente cada función, se puede crear un rol único para cada función y una política de permisos adecuada.

Realice una auditoría de código: Black Duck Software realizó una auditoría de 1000 aplicaciones de uso común en empresas y descubrió que el 96 % utilizaba software de código abierto. Además, sus investigadores descubrieron que el 60% de ese software contenía vulnerabilidades de seguridad y algunos de los errores tenían más de cuatro años. Esto hace que la propiedad y la autenticidad del código sean un riesgo de seguridad crítico, ya que ¿realmente puedes confiar en lo que no es tuyo?

Conocido como “Envenenamiento del pozo”, los atacantes pretenden obtener una mayor persistencia a largo plazo en su aplicación mediante un ataque ascendente. Las aplicaciones nativas de la nube tienden a constar de muchos módulos y bibliotecas. Los módulos a menudo incluyen muchos otros módulos, por lo que no es raro que una sola función sin servidor incluya decenas de miles de líneas de código de varias fuentes externas, incluso con menos de 100 líneas de código que escribieron sus desarrolladores. Los atacantes buscan incluir su código malicioso en proyectos comunes. Después de envenenar el pozo, esperan pacientemente mientras la nueva versión llega a sus aplicaciones en la nube. Para mejorar la seguridad sin servidor de AWS, así como Microsoft Azure, Google Cloud Functions, etc., es importante realizar una auditoría de seguridad del código o buscar herramientas que puedan automatizar el proceso.

Mantenga el control sobre sus funciones: esto puede parecer un sueño utópico, pero la vulnerabilidad del código se puede mitigar mediante CI/CD cuidadoso. Las funciones maliciosas pueden infiltrarse a través de diversos medios, como ser implementadas por un empleado deshonesto. Además, las estaciones de trabajo desarrolladas podrían ser un objetivo para los atacantes, en lugar de las aplicaciones implementadas en sí, y permitirían a los atacantes implementar funciones maliciosas a través de canales legítimos. Estas funciones podrían infiltrarse y causar estragos sin ser detectadas. Para compensar esta posibilidad, cree una política y una estrategia para realizar un análisis de código durante la compilación antes de que entre en tiempo de ejecución y asegúrese de que todas las funciones pasen por CI/CD.

Mire todos los indicadores de ataque: la visibilidad se vuelve más difícil sin servidor. El cambio a la tecnología sin servidor aumenta significativamente la cantidad total de información y la cantidad de recursos, lo que dificulta la capacidad del equipo de seguridad y DevSecOps para darle sentido a todos los datos. A medida que aumenta la cantidad de funciones, se vuelve aún más difícil determinar si todo se comporta como se supone que debe hacerlo. Por ejemplo, sólo unos pocos cientos de funciones pueden generar miles de millones de eventos en su registro todos los días y resulta difícil saber cuáles son importantes. Incluso si está familiarizado con los patrones de ataque que son exclusivos de las aplicaciones sin servidor, simplemente no se pueden escanear todas visualmente, así que aproveche las herramientas de inteligencia artificial para obtener mayor visibilidad y eficiencia de la seguridad sin servidor .

Limite el tiempo de sus funciones: las funciones deben tener un perfil de tiempo de ejecución ajustado. Es cierto que elaborar tiempos de espera adecuados para las funciones sin servidor a menudo no es intuitivo. La duración máxima de una función puede ser bastante específica de esa función. Los equipos de DevSecOps deben considerar el tiempo de espera configurado versus el tiempo de espera real. Muchos desarrolladores establecen el tiempo de espera en el máximo permitido, ya que el tiempo no utilizado no genera un gasto adicional. Sin embargo, este enfoque crea un enorme riesgo de seguridad porque si un atacante puede tener éxito con una inyección de código, tendrá más tiempo disponible para causar más daño. Los tiempos de espera más cortos les obligan a atacar con más frecuencia, a lo que nos referimos como el “ Día de la Marmota”.”ataque, pero hace que el ataque sea más visible. Como práctica recomendada de seguridad sin servidor, reduzca no solo lo que puede hacer una función, sino también cuánto tiempo puede ejecutarse.

En conclusión, a pesar de que surgen nuevos desafíos de seguridad, las implementaciones sin servidor son excelentes para organizaciones de todos los tamaños: brindan a los desarrolladores velocidad de lanzamiento y mejoran los costos operativos y la eficiencia. La tecnología sin servidor también crea una oportunidad para adoptar una postura de seguridad aún mayor, ya que todo está al nivel de función, lo que hace que sea aún más difícil para los atacantes. Para aprovechar esta nueva oportunidad, es importante que los equipos cambien su enfoque de la seguridad de las aplicaciones en implementaciones sin servidor. Proteger las aplicaciones sin servidor requiere una variedad de herramientas y tácticas, incluida la colaboración entre las personas involucradas en la aplicación y la seguridad.