Un equipo de seguridad revisa sus alertas y encuentra actividad inusual en una cuenta de servicio. La cuenta tiene permisos de administrador porque "era más fácil" darle acceso amplio cuando se configuró hace dos años. Nadie la revisó desde entonces. El atacante que la comprometió tardó cuarenta minutos en moverse lateralmente a tres entornos adicionales usando los mismos permisos.
El acceso excesivo no es un descuido aislado. Es una práctica habitual en entornos cloud que crecen más rápido que los procesos que los gobiernan.
Por qué IAM en cloud es un problema diferente
En un entorno on-premise, los permisos se gestionan con cierta fricción natural: alguien tiene que abrir un ticket, alguien tiene que aprobar, alguien tiene que ejecutar el cambio en Active Directory. Esa fricción, aunque ineficiente, actúa como filtro. En cloud, cualquier desarrollador con los permisos correctos puede crear una cuenta de servicio, asignarle un rol y darle acceso a producción en minutos. Sin aprobación. Sin registro visible. Sin revisión posterior.
El resultado es que los entornos cloud acumulan identidades —humanas, de servicio y de aplicación— con permisos que nadie recuerda haber otorgado, para propósitos que ya no existen y sin fecha de expiración. Según datos de CrowdStrike, el 80% de las brechas en cloud involucran identidades comprometidas o mal configuradas. No vulnerabilidades de software. Identidades.
Los cuatro problemas de IAM cloud que más se repiten
El primero es el acceso excesivo por defecto. Cuando no hay una política explícita de mínimo privilegio, los equipos técnicos tienden a dar permisos amplios para evitar bloqueos operativos. Es una decisión racional en el corto plazo. En el largo plazo, es la razón por la que un atacante que compromete una sola cuenta puede moverse con libertad por el entorno.
El segundo es la proliferación de cuentas de servicio no gestionadas. Cada integración, cada automatización, cada pipeline de desarrollo crea cuentas de servicio con sus propias credenciales. Muchas de esas integraciones cambian o desaparecen, pero las cuentas permanecen activas. Son identidades huérfanas con acceso vigente que nadie monitorea.
El tercero es la ausencia de autenticación multifactor en cuentas privilegiadas. En 2026, que una cuenta de administrador de entorno cloud no tenga MFA habilitado debería ser inaceptable. Sin embargo, ocurre con frecuencia —especialmente en cuentas técnicas donde "el MFA interfiere con los procesos automatizados". Ese argumento no es técnico: es una racionalización de la comodidad operativa frente al riesgo.
El cuarto es la falta de revisión periódica de accesos. Los permisos en cloud se otorgan con facilidad y raramente se revocan. Sin un proceso formal de revisión —quién tiene acceso a qué, si sigue siendo necesario y si está siendo usado— el inventario de accesos activos crece de forma indefinida y el radio de exposición con él.
¿Qué hacer al respecto?
El primer paso es hacer un inventario real de identidades en el entorno cloud. No de usuarios del directorio corporativo: de todas las identidades con acceso activo, incluidas las cuentas de servicio, las claves de API, los roles asignados a funciones y los accesos que tienen los proveedores externos. Ese inventario, en la mayoría de los entornos, revela entre un 30 y un 50 por ciento más de identidades de las que el equipo de seguridad esperaba encontrar.
El segundo paso es implementar el principio de mínimo privilegio de forma progresiva. No como un proyecto de rediseño total —eso tarda meses y genera resistencia operativa— sino como un proceso de corrección incremental. Empezar por las cuentas con más privilegios, las que tienen acceso a producción y las que llevan más tiempo sin actividad registrada.
El tercer paso es establecer un proceso de revisión periódica de accesos con dientes. Revisión trimestral, responsable por área, lista de accesos a validar y proceso de revocación automática para lo que no se justifique. Sin ese proceso, el inventario de accesos solo crece.
En tu entorno cloud actual, ¿podrías listar en menos de una hora todas las identidades que tienen acceso de administrador y justificar por qué cada una lo necesita?
Acciones inmediatas
- Genera un reporte de todas las identidades con permisos de administrador en tu entorno cloud y valida cuáles tienen justificación activa. Incluye cuentas humanas, de servicio y de aplicación. Las que no tengan un caso de uso vigente son candidatas inmediatas a reducción de privilegios o desactivación. Es el ejercicio de mayor impacto por unidad de tiempo en IAM.
- Identifica todas las cuentas de servicio que no han registrado actividad en los últimos 90 días. Una cuenta inactiva con acceso activo es una identidad huérfana que representa superficie de ataque sin valor operativo. La regla es simple: si no se usa, se deshabilita. Si hace falta de nuevo, se recrea con los permisos mínimos necesarios.
- Verifica que todas las cuentas con acceso privilegiado tienen MFA habilitado sin excepción. Si existe alguna cuenta de administrador exenta de MFA por razones operativas, documenta explícitamente el riesgo que eso representa y el plan para resolverlo. La excepción no documentada es el mayor riesgo: alguien tomó la decisión pero nadie la asumió.
- Establece una fecha y un responsable para la primera revisión formal de accesos en entorno cloud. No hace falta un proceso perfecto desde el inicio: hace falta uno que ocurra. Una revisión trimestral básica con una hoja de cálculo y responsables definidos por área es mejor que un proceso sofisticado que nunca se ejecuta.
- Revisa si los proveedores externos con acceso a tu entorno cloud tienen permisos acotados y con fecha de expiración. El acceso de un consultor o proveedor que terminó su proyecto hace seis meses y sigue activo es una de las fuentes más comunes de acceso no autorizado. La regla: acceso de terceros siempre acotado en tiempo y en alcance, con proceso de revocación al cierre del proyecto.
Si quieres evaluar el estado de gestión de identidades y accesos en tu entorno cloud e implementar controles de mínimo privilegio, contáctanos en https://tbsek.mx/contacto/.
