6 configuraciones erróneas comunes en AWS

Luego de pasar una intensa semana en Nerdearla Argentina, presentando charlas en el Auditorio y haciendo Q&A en vivo, volver a laburar a veces cuesta un poco!

Para darle una mano a esta semana, vamos a charlar un poco de 6 configuraciones que pueden traer problemas en AWS, y cómo evitarlas.

Si están manejando infraestructura en AWS (o si recién estás aprendiendo), capaz te cruzaste con algunos ajustes que parecen raros o arriesgados. E incluso las configuraciones más pequeñas y erróneas pueden llevar a grandes quilombos.

Así que sin más, vamos a pasar a 6 configuraciones erróneas comunes en AWS que muchas veces se pasan por alto, y sobre todo, vamos a aprender a solucionarlas para evitar problemas a futuro.

Políticas IAM Demasiado Permisivas

Esta es un clásico. Querés poner las cosas en marcha, así que terminás dando demasiado acceso—tal vez algo como AdministratorAccess completo. Te entiendo, es tentador, pero es abrir las puertas al desastre.

Por qué tenés que preocuparte:

Si alguien obtiene esas claves IAM demasiado permisivas, básicamente tiene las llaves del reino. Es uno de los ataques más comunes: los atacantes logran escalar privilegios y obtener acceso que definitivamente no deberían haber tenido.

Solución Rápida:

• Aplicá el principio de privilegio mínimo. No des más permisos de los necesarios.
• Usá AWS IAM Access Analyzer para identificar políticas arriesgadas.
• Revisá regularmente tus roles y políticas IAM. Hay que mantenerlas ágiles y eficientes.

Buckets S3 Públicos: El Centro de las Brechas de Datos

Si hay algo que vemos una y otra vez, es que los buckets S3 mal configurados llevan a brechas de datos. Uno pensaría que a estas alturas la gente dejaría de hacer públicos sus buckets por accidente, pero aún pasa. Muchas organizaciones fueron víctimas de esto.

Por qué deberías preocuparte:

Cuando tus buckets S3 están abiertos al público, estás invitando a problemas. Todo lo que se necesita es un desliz, y pum! Tus datos sensibles están expuestos. Y eso no es algo que queres contarle a tu jefe (o peor, a tus clientes).

Solución Rápida:

• Siempre configurá tus buckets S3 como privados a menos que necesites sí o sí que sean públicos.
• Habilitá S3 Block Public Access para prevenir exposiciones accidentales.
• Revisá las políticas de tus buckets usando AWS Trusted Advisor o Amazon Macie para evitar sorpresas.

Variables de Entorno Expuestas: Peligro Oculto

Acá hay algo que no es tan obvio pero igual de peligroso: exponer tus archivos .env. Estos archivos suelen tener claves de API, credenciales de bases de datos e incluso claves de acceso de AWS. Si están expuestos (ponele, en GitHub o a través de un servidor mal configurado), los atacantes pueden agarrarlos y acceder a tus recursos de AWS.

Por qué deberías preocuparte:

Los atacantes escanean activamente la web buscando variables de entorno expuestas. Si entran, pueden causar quilombos serios, desde filtrar datos hasta lanzar ataques de ransomware a gran escala. Un desastre.

Solución Rápida:

• No pongas datos sensibles en archivos .env. En su lugar, usá AWS Secrets Manager o Systems Manager Parameter Store para manejar secretos de manera segura.
• Revisá los permisos de los archivos y asegurate de que nunca se expongan públicamente.

Datos Sin Cifrar en Rest: Ya no es opcional

El cifrado ya no es simplemente algo "que deberíamos tener"; es una necesidad. Sin embargo, muchas personas todavía se olvidan de habilitarlo cuando configuran sus buckets S3, volúmenes EBS o bases de datos RDS. AWS hace fácil el cifrado, pero no está habilitado por defecto, así que tenés que prestarle atención a esto.

Por qué deberías preocuparte

Si tus datos no están cifrados y alguien logra acceder, pueden leer todo. Cifrarlos significa que, incluso si alguien obtiene acceso, no podrá hacer mucho con ellos.

Solución Rápida:

• Activá el cifrado por defecto para todo el almacenamiento en AWS: S3, EBS y RDS.
• Verificá tus recursos actuales y habilitá el cifrado si aún no está activado. ¡Son 3 clics en la consola de AWS!

Grupos de Seguridad Abiertos

Los grupos de seguridad son como firewall para tus recursos de AWS. Pero si los configurás demasiado amplios, como permitir acceso 0.0.0.0/0 en puertos clave, estás abriendo la puerta de par en par para que cualquiera en Internet entre. Esto fue un factor importante en varias brechas de seguridad, donde grupos mal configurados permitieron a atacantes acceder a instancias EC2, llevando a la filtración de datos de clientes.

Por qué deberías preocuparte

Dejar tus grupos de seguridad abiertos al mundo es como invitar a los hackers a tomar mate. En serio, es una de las formas más fáciles de ser comprometido.

Solución Rápida:

• Limitá el acceso en los grupos de seguridad especificando los rangos de IP mínimos necesarios.
• Revisá regularmente tus grupos de seguridad y cerrá cualquier acceso innecesario.
• Usá AWS Config para alertarte sobre configuraciones de grupos de seguridad riesgosas.

Configuraciones VPC Inseguras: La Aislación Importa

Cuando configurás AWS por primera vez, los ajustes por defecto de VPC (Virtual Private Cloud) están bien para tareas básicas, pero no son seguros para laburar en producción. Si dejás cosas como subredes demasiado abiertas o no aislás tus recursos correctamente, facilitás que los atacantes se muevan una vez que están adentro.

Por qué deberías preocuparte

Un atacante que obtiene acceso a una parte de tu infraestructura podría lograr acceso a otras si tu VPC no está bien protegida. No queremos que salten de un servicio a otro.

Solución Rápida:

• Usá subredes privadas para recursos sensibles y evitá poner todo en subredes públicas.
• Implementá VPC Flow Logs para monitorear el tráfico de red.
• Segmentá los recursos tanto como sea posible para reducir la superficie de ataque.

---

Fuente: 6 common misconfigurations in your AWS environment