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.
Patrón recomendado: SSO (Identity Center) para humanos, role
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
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.
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.
