IAM en AWS: permisos excesivos es deuda que se cobra con intereses
DeveloperFullAccess no es más rápido — es más peligroso. Patrones IAM que usamos en cuentas de clientes PYMES sin paralizar entregas.
AWS Security Blog repite: long-lived access keys y políticas AdministratorAccess son vectores #1 post-filtración. En cuentas de PYMES en LatAm heredamos usuarios IAM personales con keys en laptops, sin rotación desde 2020. El CIS AWS Benchmark penaliza exactamente esto.
SSO y roles en lugar de llaves estáticas
Patrón recomendado: SSO (Identity Center) para humanos, roles por ambiente (dev/staging/prod), service roles para apps con policies scoped a recursos específicos por ARN. Elimine keys estáticas donde IAM roles for tasks/instance profiles basten.
Permission boundaries en cuentas de desarrollo evitan que un script erróneo cree admin accidental. Access Analyzer encuentra recursos compartidos externamente — ejecútelo mensual; cuesta minutos, ahorra vergüenza pública.
Un proceso de revisión trimestral de accesos
Proceso: cada nuevo servicio AWS pide policy mínima documentada en PR. Revisión trimestral de usuarios inactivos y policies con Action "*" sin condición. NIST recomienda recertificación de acceso; para 20 usuarios es reunión de una hora, no proyecto enterprise.
IAM aburrido es IAM seguro. Su developer en Carolina puede seguir desplegando rápido con rol de deploy scoped a un bucket y una función Lambda — no necesita god mode porque "así siempre fue".
Escribe sobre ciberseguridad práctica para pymes en Puerto Rico y el Caribe — sin relleno, con lo que realmente hay que hacer.
