¿Son seguras las aplicaciones sin servidor?

  • Gestión de apps

Estamos entrando en la próxima etapa de virtualización. Pasamos de servidores físicos a máquinas virtuales y, ahora, a aplicaciones sin servidor, también conocidas como funciones como servicio. En cada etapa, la esperanza de vida se acorta y se requieren nuevos enfoques para el monitoreo y la seguridad.

Las aplicaciones sin servidor toman datos de una entrada, los pasan a través de una o más cargas de trabajo apropiadas y luego dirigen la salida a un destino. En sí mismas, las aplicaciones sin servidor generalmente no procesan datos. Simplemente actúan como una cinta transportadora programable, transportando los datos de un lugar a otro. Esto significa que la vida útil ya no se mide en minutos u horas, sino en fracciones de segundo. El resultado es que las herramientas de seguridad utilizadas para monitorear las generaciones anteriores de tecnología de virtualización ya no lo hacen.

Impulsados ​​por el aumento en la adopción de microservicios, las aplicaciones sin servidor ofrecen un gran grado de flexibilidad. Desafortunadamente, una mayor flexibilidad significa más oportunidades para que los atacantes y posibles perpetradores entren.

La creciente superficie de ataque

Si bien las aplicaciones sin servidor permiten una mayor granularidad, como una facturación más rápida para los servicios, son vulnerables a los ataques que explotan la escalada de privilegios y las dependencias de las aplicaciones. Y dado que las aplicaciones sin servidor suelen ser funciones pequeñas y discretas, también se transfieren más datos a través de las redes, otro vector de ataque potencial. La amenaza de los ataques de denegación de servicio de fuerza bruta, en los que la arquitectura sin servidor no escala y genera costosas interrupciones en el servicio, sigue prevaleciendo.

Un estudio reciente descubrió que más del 20% de las aplicaciones sin servidor de código abierto contienen vulnerabilidades de seguridad críticas. Su informe encontró que el 21% (de 1.000) de los proyectos sin servidor de código abierto contenían una o más vulnerabilidades críticas o configuraciones incorrectas, lo que podría permitir a los atacantes manipular la aplicación y realizar varias acciones maliciosas. Alrededor del 6% de los proyectos incluso tenían secretos de aplicaciones, como claves o credenciales de la interfaz de programación de aplicaciones (API), publicados en sus repositorios de código de acceso público.

La crisis de identidad

Las aplicaciones sin servidor son particularmente susceptibles a los compromisos de identidad. Están estrechamente relacionados con los permisos de identidad y acceso en el lado del proveedor de la nube. Las empresas que utilizan aplicaciones sin servidor se centran en el modelo de menor privilegio para ayudar a protegerlas. Todos los principales proveedores de la nube tienen una oferta sin servidor. En muchos casos, no se conoce la implementación exacta: puede ser que se forme un contenedor propietario en, pero se están ocupando de la configuración.

Y eso es bueno, porque la responsabilidad de la seguridad de la infraestructura sin servidor, como la seguridad física, la seguridad de la red o los parches del sistema operativo, recae en estas grandes y confiables marcas. Si bien el parcheo es una de sus competencias principales, el servidor no hace nada para mantener a los atacantes alejados de los datos. Si un atacante obtiene acceso a los datos de una empresa a través de una vulnerabilidad (credenciales filtradas, información privilegiada comprometida o por cualquier otro medio), entonces el servidor no ayuda.

Sin embargo, el propietario de la aplicación sigue siendo completamente responsable de la lógica de la aplicación, el código, los datos y las configuraciones de la capa de aplicación, garantizando que sean seguros, resistentes y capaces de resistir los ataques. Los desarrolladores aún deben tener cuidado con la forma en que escriben su código. Si escribe código inseguro y lo pone en funciones, todavía existen muchos problemas de seguridad: inyecciones de SQL y ataques similares.

Confianza en la nube

Lo que todo esto significa es que los clientes tienen que confiar mucho más en sus proveedores en la nube. Tener preguntas como, '¿cómo se supervisa la entrada y la salida en una función', a través de algo como la comprensión fundamental de cómo el proveedor está monitoreando las actividades maliciosas es completamente comprensible. Especialmente debido a que muchas de las herramientas que se implementarían en un entorno local o una máquina virtual no están ubicadas. En última instancia, confía en el proveedor para mantener el sistema subyacente seguro.

Las aplicaciones sin servidor no son para todos. Hacen que el monitoreo sea más difícil, mientras que el escalado y el ahorro de costos pueden valer la pena para algunos desarrolladores, las aplicaciones sin servidor vienen con mayores requisitos de prueba y diferentes estrategias de monitoreo que las aplicaciones tradicionales. Dicho esto, abren muchos beneficios para muchos entornos DevOps. La escalabilidad, la rentabilidad y la compatibilidad con las aplicaciones en la nube existentes son inigualables. A pesar de esos beneficios, todavía hay preocupaciones y prácticas de seguridad muy serias para estar despiertos.