Seguridad sin servidor y de funciones

La informática sin servidor (Functions as a Service, FaaS) permite a los desarrolladores implementar funciones individuales que se invocan mediante eventos —solicitudes HTTP, mensajes de cola, activadores de bases de datos o temporizadores programados— sin administrar los servidores subyacentes. Entre las principales plataformas se incluyen AWS Lambda, Google Cloud Functions y Azure Functions. El proveedor de la nube se encarga de la aplicación de parches, el escalado y la infraestructura. Aunque esto reduce la carga operativa, modifica el modelo de responsabilidad de seguridad: el proveedor protege el entorno de ejecución, pero el desarrollador es el único responsable del código de la función, los permisos y la configuración.

Las funciones sin servidor presentan una superficie de ataque distinta de la de las aplicaciones tradicionales: normalmente son de corta duración (de segundos a minutos), lo que hace menos eficaces las soluciones EDR y la supervisión de red tradicionales; están orientadas a eventos, lo que significa que muchas fuentes de entrada diferentes (eventos de S3, API Gateway, SNS) pueden activar su ejecución; a menudo se ejecutan con permisos de IAM que permiten acceder a otros recursos de la nube; y consumen dependencias de terceros (paquetes de npm y pip) que pueden contener código malicioso. La superficie de ataque está definida por las entradas de eventos, los permisos de IAM y las cadenas de confianza de las dependencias.

La vulnerabilidad de seguridad más común en la informática sin servidor son los roles de IAM con privilegios excesivos. Cuando los desarrolladores necesitan que una función acceda a un bucket de S3, resulta tentador asignarle s3:* (acceso completo a S3) para evitar errores de permisos. Una función comprometida o vulnerable con este rol podría leer, escribir o eliminar cualquier bucket de la cuenta. La defensa consiste en aplicar estrictamente roles de IAM con mínimo privilegio: cada función debe tener un rol dedicado que conceda únicamente los permisos mínimos necesarios para las tareas específicas de esa función. Herramientas como AWS IAM Access Analyzer y Cloudsplaining identifican automáticamente los roles de Lambda con privilegios excesivos.

La inyección de eventos se produce cuando los datos controlados por un atacante incluidos en la carga útil de un evento son procesados de forma insegura por el código de la función. Dado que las funciones sin servidor pueden activarse desde muchas fuentes de eventos —encabezados HTTP, parámetros de consulta, registros de cambios de bases de datos, cuerpos de mensajes de cola y contenido de correos electrónicos—, cualquiera de ellas puede transportar cargas útiles maliciosas. Entre los tipos comunes de inyección se incluyen: inyección SQL si la función consulta una base de datos utilizando datos del evento, inyección NoSQL (operadores de MongoDB en cargas útiles JSON), inyección de comandos si los datos del evento se utilizan en comandos del sistema operativo, y SSRF (falsificación de solicitudes del servidor) si se obtienen las URL incluidas en los datos del evento. La validación de entradas y las consultas parametrizadas son defensas esenciales.

Las funciones sin servidor suelen depender de docenas de paquetes de terceros. Estas dependencias introducen riesgos en la cadena de suministro: un paquete malicioso o comprometido puede ejecutar código arbitrario en el entorno de ejecución de la función, acceder a variables de entorno (que a menudo contienen secretos), establecer conexiones de red salientes y utilizar el rol de IAM de la función para acceder a recursos de la nube. Ataques de gran repercusión, como el compromiso del paquete npm event-stream (2018), y numerosos paquetes de typosquatting demuestran este riesgo. Entre las defensas se incluyen la fijación de dependencias, el análisis SCA en CI/CD y mantener una huella mínima de dependencias.

Las funciones sin servidor suelen recibir secretos mediante variables de entorno configuradas en la consola de la nube. Estas variables de entorno son visibles para cualquiera que tenga acceso de IAM a la configuración de Lambda y cualquier código que se ejecute dentro de la función puede acceder a ellas. Prácticas recomendadas: evite almacenar secretos directamente como variables de entorno en texto plano; en su lugar, almacene ARN o nombres de secretos y recupere los secretos en tiempo de ejecución desde AWS Secrets Manager o Parameter Store; habilite el cifrado de KMS para las variables de entorno de Lambda en reposo; y no registre nunca las variables de entorno (muchos registradores de depuración vuelcan todas las variables de entorno cuando se produce un error).

La denegación de servicio contra funciones sin servidor puede adoptar la forma de una inundación de invocaciones: un atacante que pueda activar repetidamente una función podría agotar el límite de concurrencia de la cuenta (el valor predeterminado de Lambda es de 1.000 ejecuciones simultáneas por región), impidiendo que se ejecuten otras funciones de la cuenta. Las funciones que procesen entradas controladas por el usuario deben implementar limitación de tasa en el nivel de API Gateway, validar los límites de tamaño de las cargas útiles y establecer valores de tiempo de espera adecuados para evitar ejecuciones descontroladas. Las funciones también pueden ser objeto de ataques de expansión al estilo Billion Laughs al analizar XML o YAML si no se limita el tamaño de la entrada.

De forma predeterminada, las funciones de AWS Lambda se ejecutan en una VPC administrada por AWS con acceso a Internet, pero sin acceso a los recursos de su VPC privada (bases de datos RDS, ElastiCache y API privadas). Para acceder a recursos privados, Lambda debe configurarse para ejecutarse dentro de su VPC, con subredes y grupos de seguridad específicos. Sin embargo, las funciones de Lambda asociadas a una VPC no tienen acceso a Internet de forma predeterminada; necesitan una NAT Gateway para el acceso saliente a Internet. Los grupos de seguridad asociados a las funciones de Lambda deben seguir reglas de mínimo privilegio: permita únicamente los puertos y destinos específicos necesarios. Evite utilizar reglas salientes 0.0.0.0/0 en los grupos de seguridad de funciones de producción.

La supervisión de la seguridad sin servidor requiere enfoques diferentes de los de la supervisión tradicional de hosts. Dado que las funciones son efímeras, los agentes basados en hosts no resultan prácticos. La supervisión eficaz utiliza: AWS CloudTrail para registrar todas las llamadas a la API de Lambda (invocaciones, cambios de configuración y asunción de roles); CloudWatch Logs Insights para consultar los registros de ejecución de las funciones en busca de patrones anómalos; Amazon GuardDuty para detectar amenazas, incluida la actividad de red inusual de Lambda; y herramientas comerciales de seguridad nativas para entornos sin servidor, como Protego (ahora parte de Check Point) o la supervisión sin servidor de Datadog, que instrumentan las funciones mediante capas para proporcionar visibilidad en tiempo de ejecución.

Las pruebas de seguridad sin servidor requieren herramientas específicas: PureSec CLI (ahora de Check Point) y Prowler analizan las configuraciones de la nube en busca de configuraciones incorrectas en entornos sin servidor; las herramientas DAST pueden probar funciones activadas mediante HTTP para detectar vulnerabilidades de inyección; el análisis estático del código de las funciones con herramientas como Bandit (Python) o complementos de seguridad de ESLint permite detectar patrones de programación inseguros; y las pruebas manuales deben enumerar todas las fuentes de eventos que pueden activar cada función y probar cada una con cargas útiles malformadas y maliciosas. OWASP Serverless Top 10 proporciona una lista de comprobación completa de vulnerabilidades específica para arquitecturas sin servidor.

La informática sin servidor extiende aún más el modelo de responsabilidad compartida hacia el proveedor. El proveedor de la nube es responsable de: el entorno de ejecución de la función, los parches del sistema operativo, la seguridad de la infraestructura subyacente y las instalaciones físicas. El cliente sigue siendo responsable de: la seguridad del código de la función, el diseño de los permisos de IAM, la gestión de secretos, la validación de entradas, la gestión de dependencias, la configuración del registro y las políticas de red. La menor responsabilidad sobre la infraestructura no significa una menor responsabilidad sobre la seguridad; simplemente desplaza el foco de la inversión en seguridad, principalmente hacia la seguridad a nivel de aplicación y de IAM.

Compruebe su comprensión de los conceptos de CompTIA Security+ (SY0-701) tratados en esta lección.

En esta lección ha aprendido lo siguiente: los roles de IAM con privilegios excesivos son el principal riesgo en entornos sin servidor; cada función necesita un rol dedicado con mínimo privilegio; los ataques de inyección de eventos explotan cualquier fuente de eventos que entregue datos controlados por un atacante a funciones sin validación de entradas; y el riesgo de la cadena de suministro de dependencias derivado de paquetes de terceros puede comprometer la ejecución de una función y permitir el acceso a credenciales de IAM y secretos. A continuación, exploraremos el análisis de seguridad de Infrastructure as Code para detectar configuraciones incorrectas antes de la implementación.