5 errores de IAM en AWS que ponen en riesgo a una pyme
AWS Identity and Access Management (IAM) define quién puede entrar a tu cuenta, qué puede hacer y sobre qué recursos. Cuando crece sin una revisión periódica, aparecen accesos que nadie recuerda, permisos más amplios de lo necesario y credenciales que sobreviven a las personas o proyectos que las crearon. Esta guía explica los cinco errores más comunes y cómo empezar a corregirlos sin detener la operación.
Seguridad AWSMapa de riesgo IAM
Cinco accesos que conviene revisar antes de que se conviertan en un incidente.
Cuenta AWS
Identidades y permisos
Personas · roles · aplicaciones · terceros
Cuenta raíz
Uso cotidiano del acceso con privilegio total.
Permisos amplios
AdministratorAccess sin dueño ni fecha de revisión.
Llaves antiguas
Credenciales permanentes en código o servidores.
Sin propietario
Usuarios y roles que ya nadie puede justificar.
Acceso externo
Recursos públicos o compartidos entre cuentas.
IAM no es una lista de usuarios
Una decisión de acceso combina una identidad, una acción, un recurso y unas condiciones. Por eso borrar usuarios antiguos no basta: un rol puede confiar en otra cuenta, un bucket puede tener una política pública y una aplicación puede seguir usando una llave guardada hace años.
El objetivo tampoco es quitar permisos hasta romper el trabajo. El principio de mínimo privilegio consiste en conceder lo necesario durante el tiempo necesario, observar el uso real y ajustar con evidencia. En una pyme, eso se puede hacer por etapas y con controles que AWS ya ofrece.
Los cinco errores y cómo corregirlos
Usar la cuenta raíz para el trabajo diario
El riesgo: El usuario raíz tiene acceso completo a la cuenta y puede ejecutar tareas que ninguna otra identidad puede realizar. Si sus credenciales se filtran, no existe una política de IAM que limite el daño.
Qué hacer: Activa MFA resistente al phishing cuando sea posible, elimina cualquier llave de acceso del usuario raíz y reserva ese acceso para las pocas tareas que realmente lo requieren. Para la administración diaria, usa acceso federado o un rol administrativo con credenciales temporales.
Dar AdministratorAccess para resolver todo rápido
El riesgo: Un permiso temporal suele quedarse durante años. El problema no es solo una cuenta comprometida: una persona o automatización con permisos globales también puede borrar recursos, cambiar redes o desactivar controles por error.
Qué hacer: Empieza con políticas administradas cuando el equipo todavía está entendiendo la carga, pero registra un responsable y una fecha de revisión. Después reduce los permisos a las acciones y recursos que realmente se usan.
Guardar llaves de acceso de larga duración en código o servidores
El riesgo: Las llaves permanentes terminan en archivos de configuración, repositorios, computadores y respaldos. Aunque el código actual sea privado, una copia antigua puede seguir conteniendo una credencial válida.
Qué hacer: Usa roles de IAM y credenciales temporales para EC2, Lambda, contenedores y pipelines compatibles. Si un caso exige una llave de larga duración, identifica a su dueño, revisa el último uso y reemplázala sin interrumpir la aplicación antes de eliminar la anterior.
Conservar usuarios, roles y permisos sin dueño
El riesgo: Cuando una persona cambia de función, un proveedor termina su contrato o un proyecto se cierra, el acceso suele sobrevivir. Esas identidades huérfanas aumentan la superficie de ataque y dificultan saber quién puede hacer qué.
Qué hacer: Cruza el informe de credenciales con la lista real del equipo y asigna un dueño a cada usuario, rol y llave. Desactiva primero lo dudoso, monitorea el impacto y elimina después de confirmar que no existe una dependencia.
No revisar acceso externo ni permisos sin uso
El riesgo: Una política puede compartir un bucket, una clave KMS o un rol con otra cuenta sin que sea evidente en la operación diaria. También puede conceder cientos de acciones que la carga nunca utiliza.
Qué hacer: Usa IAM Access Analyzer para revisar acceso público o entre cuentas y para validar políticas antes de publicarlas. El análisis de acceso sin uso ayuda a encontrar roles, llaves, contraseñas y permisos inactivos; revisa su costo y alcance antes de activarlo.
Una auditoría inicial de IAM en 60 minutos
Esta revisión no reemplaza una evaluación completa, pero permite detectar los riesgos evidentes y salir con una lista priorizada. Hazla con acceso de solo lectura siempre que sea posible.
Asegura el usuario raíz
Confirma MFA, ausencia de llaves activas y un mecanismo de recuperación controlado por más de una persona.
Descarga el informe de credenciales
Revisa usuarios, contraseñas, MFA, llaves activas, fecha de creación y último uso. Marca todo lo que no tenga dueño claro.
Busca permisos amplios
Identifica AdministratorAccess, acciones con comodín y políticas adjuntas directamente a usuarios. Prioriza producción y datos sensibles.
Revisa acceso externo
Consulta los hallazgos de IAM Access Analyzer para recursos públicos o compartidos con cuentas externas y valida si cada acceso es intencional.
Convierte hallazgos en acciones
Asigna responsable, riesgo, cambio propuesto y fecha. Primero desactiva o reduce; elimina solo cuando hayas comprobado que la operación no depende del acceso.
Qué no conviene hacer durante la limpieza
- No elimines todo lo que parece viejo de una vez. Desactiva, monitorea y elimina después. Una llave sin uso reciente puede pertenecer a un proceso mensual.
- No cambies permisos en producción sin una ruta de reversión.Guarda la política anterior, prueba con el equipo afectado y haz cambios pequeños.
- No confundas MFA con mínimo privilegio. MFA protege el inicio de sesión; no limita lo que una identidad puede hacer después de autenticarse.
- No crees una llave nueva antes de confirmar que hace falta.Roles, federación e IAM Identity Center reducen la cantidad de secretos permanentes que debes custodiar.
Cuándo repetir la revisión
Revisa IAM de forma periódica y también cuando alguien sale de la empresa, cambia de función, termina un contrato con un proveedor, se retira una aplicación o existe sospecha de acceso no autorizado. La frecuencia depende del ritmo de cambio, pero el proceso debe tener responsable y evidencia de cierre.
Para equipos pequeños, una revisión mensual de credenciales y hallazgos, más una auditoría trimestral de roles y políticas, suele ser un punto de partida razonable. Lo importante es que el calendario exista y que cada excepción tenga dueño y fecha de vencimiento.
Fuentes oficiales de AWS
¿No sabes por cuál acceso empezar?
En CloudTing revisamos IAM con acceso de solo lectura, clasificamos los hallazgos por impacto y te entregamos un plan de corrección que protege la cuenta sin bloquear al equipo.
Solicitar una revisión de seguridad AWS →