¿Qué es la seguridad sin servidor?

Las aplicaciones sin servidor requieren seguridad sin servidor

Con cada gran avance en el desarrollo de software y en las operaciones de TI se produce un cambio en los vectores de ataque y en los riesgos de seguridad. En los primeros tiempos de la virtualización a contenedores, los profesionales de la seguridad tuvieron que adaptarse y encontrar nuevas formas de endurecer, defender y gobernar su infraestructura. El concepto de una aplicación sin servidor presenta uno de los mayores cambios de paradigma jamás vistos en lo que respecta a la seguridad de las aplicaciones.

Tradicionalmente, las organizaciones protegían sus aplicaciones recurriendo a herramientas basadas en infraestructuras y redes. Inspeccionarían el tráfico con un cortafuegos, intentarían detectar actividades maliciosas con un sistema de detección de intrusos o protegerían las aplicaciones con tecnología de autoprotección de aplicaciones en tiempo de ejecución, o RASP. Incluso con los contenedores, las organizaciones podrían seguir confiando en la seguridad de la infraestructura subyacente hasta cierto punto.

Una aplicación sin servidor consiste en servicios distribuidos en la nube que trabajan juntos, como un bucket de S3 que activa una función Lambda, que a su vez activa DynamoDB^®. En esta arquitectura, no hay lugar para cortafuegos, herramientas IDS/IPS ni ningún tipo de agentes de instrumentación o métodos de protección basados en servidores. En lugar de centrarse en la inspección de la red y las listas de control de acceso, el modelo sin servidor desplaza el foco de la seguridad hacia los permisos IAM, la protección del comportamiento y el código fuerte.

Vectores de ataque sin servidor

La adopción de la seguridad sin servidor proporciona a las aplicaciones una gran ventaja desde el punto de vista de la seguridad, puesto que las organizaciones ya no tienen que preocuparse por la seguridad de la infraestructura, la red o el host. Sin embargo, han surgido nuevos vectores de ataque y se han reimaginado ataques conocidos para entornos sin servidor. Veamos un ejemplo (para ver la lista completa, consulte el Top 12 Risks for Serverless Applicationsde la Cloud Security Alliance):

Inyección de datos de eventos

Los fallos de inyección en las aplicaciones, uno de los riesgos más comunes hasta la fecha, se han tratado a fondo en muchas guías de buenas prácticas de codificación segura. A alto nivel, los fallos de inyección se producen cuando una entrada no fiable se pasa directamente a un intérprete antes de ser ejecutada o evaluada. En el contexto de la arquitectura sin servidor, sin embargo, las inyecciones de datos de eventos de función no se limitan estrictamente a la entrada directa del usuario (como la entrada de una llamada a la API web). La mayoría de las arquitecturas sin servidor proporcionan una multitud de fuentes de eventos que pueden desencadenar la ejecución de una función sin servidor.

Los ejemplos de fuentes de inyección de datos de sucesos incluyen:

• Eventos de almacenamiento en la nube (por ejemplo, AWS S3^®, Azure Blob Storage, Google Cloud Storage)
• Eventos de bases de datos NoSQL (por ejemplo, AWS DynamoDB, Azure Cosmos DB^®)
• Eventos de la base de datos SQL
• Eventos de procesamiento de flujos (por ejemplo, Amazon Kinesis^®)
• Cambios en el código y nuevas confirmaciones de código en los repositorios
• Llamadas a la API HTTP

Cada entrada de evento puede incluir diferentes formatos de mensaje, y varias partes de estos mensajes de evento pueden contener entradas controladas por atacantes o peligrosas por otros motivos. El rico conjunto de fuentes de eventos aumenta la superficie de ataque potencial e introduce complejidades cuando se intenta proteger las funciones sin servidor contra las inyecciones de datos de eventos. Esto es especialmente cierto porque las arquitecturas sin servidor no se entienden tan bien como los entornos web, donde los desarrolladores saben en qué partes del mensaje no se debe confiar (por ejemplo, parámetros GET/POST, cabeceras HTTP, etc.).

Protección de las aplicaciones sin servidor

La seguridad eficaz sin servidor se centra en garantizar la integridad del código, permisos estrictos y análisis de comportamiento.

• Acceso y permisos: Mantenga el acceso con privilegios mínimos para las funciones sin servidor y otros servicios. Por ejemplo, si una función de AWS Lambda necesita acceder a una tabla de DynamoDB, asegúrese de que solo puede realizar la acción específica que requiere la lógica empresarial.
• Exploración de vulnerabilidades: Garantice la integridad del código y de la plantilla infraestructura como código analizando periódicamente las dependencias vulnerables de terceros, los errores de configuración y los roles demasiado permisivos.
• Protección de tiempo de ejecución: Utilice la protección de tiempo de ejecución para detectar entradas de eventos maliciosos y comportamientos anómalos de las funciones, y limite según sea necesario la capacidad de cada función para acceder a archivos, hosts, Internet y engendrar procesos hijos.

Preguntas frecuentes sin servidor