POR EDUARDO ABURTO / DEVOPS
Durante los últimos meses he estado apoyando a varios equipos de backend en la implementación de APIs usando arquitectura serverless (sin servidor) en AWS. La tendencia es clara: cada vez más proyectos optan por API Gateway y Lambda como su stack principal, y con razón, pues su facilidad de despliegue y la escalabilidad son innegables.

Sin embargo, mientras configuraba en GitLab pipelines de integración continua / despliegue continuo (CI/CD, por sus siglas en inglés) noté patrones preocupantes en la forma en que manejamos la seguridad. Por ejemplo, es fácil caer en la trampa de priorizar la velocidad sobre la seguridad, especialmente cuando los deadlines aprietan.

Riesgos de seguridad en arquitecturas serverless

La seguridad en entornos sin servidor es diferente. Ya no estamos asegurando servidores tradicionales, estamos protegiendo funciones distribuidas, así como sus puntos de acceso. En mi experiencia, al trabajar con diferentes equipos he podido ubicar los problemas que más frecuentemente necesitan atención:

Exposición de funciones Lambda

Durante las pruebas de integración es común encontrar funciones Lambda con configuraciones demasiado permisivas. Los desarrolladores, concentrados en hacer funcionar la integración, a veces dejan los triggers completamente abiertos. Como DevOps, parte de mi trabajo es asegurarme de que esto no llegue a producción.

Gestión de Permisos IAM

Al trabajar es normal ver estos patrones: roles de gestión de identidad y acceso (IAM, en inglés) que van acumulando permisos innecesarios. Lo entiendo perfectamente, debido a que el desarrollador está en medio de un sprint, algo no funciona y la solución rápida es añadir ese permiso extra. El problema es que esos "permisos temporales" tienden a convertirse en permanentes.

Control de dependencias

En los últimos deploys que he supervisado el manejo de dependencias ha sido crítico. Los equipos necesitan moverse rápido, pero una dependencia comprometida puede exponer toda la infraestructura.

Prácticas que funcionan en el mundo real

Basado en mi experiencia implementando CI/CD para estos servicios, algo fundamental es contar con ambientes de prueba bien definidos. En un proyecto de arquitectura serverless, antes de llegar a producción cada función debe pasar por ambientes previos como QA y Staging. Esto nos permite detectar problemas de seguridad de manera temprana y validar que los permisos y configuraciones sean los correctos en cada etapa. No es lo mismo probar una Lambda con acceso a una base de datos de prueba que hacerlo con datos reales de clientes.

Basándome en esta estrategia de ambientes les presento las prácticas que realmente han funcionado:

El diagrama resume las áreas clave que siempre revisamos para garantizar una implementación de arquitectura serverless segura en AWS.

Asegurar funciones Lambda y API Gateway en proyectos de arquitectura serverless

Para asegurar las funciones Lambda y API Gateway recomiendo lo siguiente:

  • Implementar templates de IAM estandarizados para diferentes tipos de funciones.
  • Configurar Cognito para autenticación por defecto en todas las APIs nuevas.
  • Para APIs con menores requerimientos de seguridad hay que considerar API Keys como método de autenticación alternativo, asegurándonos de que se gestionen de forma segura con rotación periódica y restricciones de uso.
  • El API Gateway, siendo el punto de entrada principal, debe estar protegido por WAF, con reglas específicas definidas por el equipo de seguridad.
  • Usar variables de stage en API Gateway para manejar diferentes entornos de forma segura.

Automatización de seguridad

En la arquitectura serverless también es indispensable que el equipo de DevOps verifique lo siguiente:

  • Permisos IAM excesivos en el pipeline de CI/CD.
  • Exposición innecesaria de endpoints.
  • Configuraciones de seguridad en API Gateway.
  • Uso de autenticación basada en OpenID Connect (OIDC) en los pipelines en lugar de credenciales IAM estáticas. Esto permite una integración segura y sin necesidad de almacenar claves de acceso.

Monitoreo efectivo

El monitoreo va más allá de simplemente habilitar CloudTrail y GuardDuty. Por eso es importante implementar un sistema de notificaciones adaptado a las necesidades de cada proyecto usando CloudWatch para las métricas, el cual se conecta a Simple Notification Service (SNS), que es un servicio de mensajería de AWS que envía alertas a múltiples destinos, incluyendo Slack, donde una Lambda las procesa y distribuye a los canales adecuados de Slack.

Manejo de datos sensibles

Esta parte es crucial, sobre todo en el sector fintech, por lo que es importante establecer estándares claros como los siguientes:

  • Secrets Manager para credenciales de producción.
  • Parameter Store para configuraciones de ambiente.
  • KMS para todo lo relacionado con datos de clientes.

Un patrón que ha funcionado bien es centralizar la gestión de secrets en el pipeline de CI/CD. Esta acción evita que los desarrolladores tengan que manejar credenciales directamente.

Como conclusión, el rol de un DevOps en una fintech no sólo es facilitar el despliegue de servicios sin servidor, sino asegurarse de que cada paso del proceso siga las mejores prácticas de seguridad. La arquitectura serverless nos da agilidad, pero requiere un enfoque diferente en seguridad.

Si estás implementando arquitecturas similares, mi consejo es: automatiza las verificaciones de seguridad desde el principio. Es más fácil mantener buenos hábitos que corregir problemas en producción.

Para más información pueden consultar: