TÉCNICO-GERENCIAL · IDENTIDAD CLOUD · IAM
Hace dos semanas analicé la gestión de identidad y acceso en entornos on-premise: las cuentas huérfanas, el privilege creep, los accesos de terceros sin vencimiento, y el proceso de revisión con sus cinco pasos y sus fricciones reales. Hoy quiero ver qué ocurre con esos mismos problemas cuando la organización tiene un entorno cloud activo, ya sea como destino de una migración planificada o como resultado de una migración de urgencia.
La respuesta corta es que los problemas de identidad no desaparecen al migrar a la nube. Se suman a los que ya existían on-premise. Y en cloud tienen características propias que los hacen más difíciles de detectar y más fáciles de que se acumulen sin que nadie los encuentre.
EL PROBLEMA DE LAS CREDENCIALES DE LARGA DURACIÓN
En entornos on-premise, las contraseñas de usuario tienen un ciclo de vida definido por la política del directorio: vencen cada cierto tiempo y el usuario tiene que renovarlas. En cloud, hay una categoría de credenciales que no tiene ese ciclo de vida por defecto: las access keys o claves de acceso programático.
Las access keys son pares de identificador y secreto que se usan para autenticar llamadas a la API del proveedor cloud desde aplicaciones, scripts y herramientas automatizadas. Se crean una vez, y salvo que alguien las rote explícitamente, permanecen válidas indefinidamente. En entornos cloud creados bajo urgencia, es frecuente encontrar access keys creadas durante la migración inicial que llevan meses o años activas, usadas por múltiples aplicaciones, conocidas por personas que ya no están en la organización.
La diferencia con una contraseña de usuario es que una access key comprometida puede usarse silenciosamente desde cualquier punto de internet sin que el acceso parezca anómalo. No requiere pasar por el perímetro de la red corporativa. No requiere VPN. Requiere solo la clave y el secreto, que pueden haber sido expuestos en un repositorio de código, en un archivo de configuración, o en la memoria de un sistema comprometido.
LAS IDENTIDADES DE SERVICIO SIN CICLO DE VIDA
En entornos on-premise, las cuentas de usuario tienen un ciclo de vida más o menos visible vinculado a la relación laboral de la persona. Cuando alguien sale, RRHH lo notifica (o debería notificarlo) y TI desactiva la cuenta. Ese ciclo de vida existe, aunque con las fricciones que describí hace dos semanas.
Las identidades de servicio en cloud, los service principals en Azure o los IAM roles y users en AWS, no tienen ese ciclo de vida vinculado a ninguna persona. Se crean para un proyecto, para una aplicación, para una fase de implementación. Y cuando el proyecto termina, la aplicación cambia, o la fase concluye, nadie tiene la obligación formal de revisar si esas identidades siguen siendo necesarias.
El resultado previsible es una acumulación de identidades de servicio activas en el entorno cloud que ya no tienen una función activa pero que mantienen sus permisos originales. En entornos con años de historia cloud o con múltiples proyectos de implementación, ese inventario puede ser extenso y difícil de auditar porque no hay un directorio centralizado equivalente al Active Directory que consolide todas las identidades y sus estados.
ERROR COMÚN
Asumir que las identidades de servicio cloud son menos riesgosas que las cuentas de usuario porque "no las usa ninguna persona." Una identity de servicio con permisos de administrador sobre recursos críticos es exactamente tan riesgosa como una cuenta de usuario con los mismos permisos, y frecuentemente más difícil de monitorear porque su actividad es automatizada y genera volúmenes de logs más difíciles de revisar manualmente.
EL ACCESO FEDERADO Y SUS FRICCIONES ESPECÍFICAS
Una de las ventajas que suele argumentarse para la adopción de cloud es la posibilidad de federar la identidad corporativa con el entorno cloud: los usuarios se autentican con sus credenciales del directorio on-premise, como Active Directory, y ese acceso se extiende al entorno cloud sin necesidad de gestionar identidades separadas. Azure Active Directory, hoy renombrado como Entra ID, está diseñado exactamente para ese escenario.
El problema aparece cuando la federación se configura de forma incompleta o incorrecta. Si las políticas de acceso condicional no están bien definidas, un usuario puede autenticarse en el entorno cloud desde cualquier dispositivo y ubicación sin los controles que aplican en el entorno corporativo. Si la sincronización entre el directorio on-premise y el directorio cloud no está correctamente configurada, las bajas de usuarios pueden no propagarse al entorno cloud, recreando el problema de cuentas huérfanas pero en un entorno que es más difícil de auditar.
En entornos híbridos donde coexisten infraestructura on-premise y cloud, como el que quedó en TechCorp Latam después de migrar solo los sistemas críticos a Azure y mantener el resto on-premise, la gestión de identidad tiene que cubrir dos entornos con herramientas parcialmente distintas y con visibilidad que no siempre es centralizada. Esa complejidad es exactamente donde las brechas tienden a acumularse.
MFA INCONSISTENTE ENTRE ENTORNOS
La autenticación multifactor en entornos on-premise y cloud no siempre se implementa con la misma consistencia. En muchas organizaciones, el MFA se habilitó para el acceso a aplicaciones corporativas específicas pero no se extendió al entorno cloud de forma sistemática. El resultado es que las cuentas administrativas del directorio corporativo pueden tener MFA, pero las cuentas de acceso directo a la consola cloud o a las APIs del proveedor no lo tienen.
Esa inconsistencia crea una asimetría de protección que los atacantes conocen y aprovechan: si el acceso al entorno on-premise requiere MFA pero el acceso directo a la consola Azure o AWS no lo requiere, el entorno cloud se convierte en el punto de menor resistencia para un ataque de credenciales comprometidas.
¿QUÉ SIGNIFICA ESTO EN PRODUCCIÓN?
La gestión de identidad en entornos cloud no es un problema distinto al de la gestión de identidad on-premise. Es el mismo problema con una superficie más amplia, herramientas más diversas, y menos visibilidad centralizada. Las fricciones que describí hace dos semanas, la transversalidad del proceso, la resistencia de las jefaturas a certificar accesos, la ausencia de un dueño claro del proceso, todas existen también en cloud, con la complejidad adicional de que el inventario de identidades cloud es más difícil de obtener y más difícil de mantener actualizado.
El punto de partida práctico es el mismo que para el entorno on-premise: el inventario. En cloud, eso significa listar todas las identidades activas en el tenant o la cuenta cloud, incluyendo usuarios, grupos, cuentas de servicio, roles y cualquier identidad federada, con los permisos asignados a cada una. Ese inventario, la primera vez que se construye en un entorno con historia, produce casi siempre más identidades de las esperadas y más permisos de los que se recuerdan haber asignado.
DECISIÓN QUE DEBE TOMAR EL CIO
¿Tiene la organización un inventario actualizado de todas las identidades activas en su entorno cloud, con los permisos de cada una y la última vez que fueron usadas? Si ese inventario no existe, la gestión de identidad cloud está operando a ciegas. Las herramientas nativas del proveedor, Azure Entra ID Access Reviews, AWS IAM Access Analyzer, permiten construir ese inventario sin herramientas adicionales. La decisión es asignar a alguien el tiempo para hacerlo.
En cloud, las identidades se crean más rápido, se multiplican más, y tienen menos visibilidad centralizada que en un directorio on-premise. Eso no significa que el problema sea distinto. Significa que requiere más disciplina para no dejar que crezca sin control.
Artículo núcleo de la semana: Seguridad en la nube: las decisiones que se toman mal cuando la infraestructura deja de ser tuya. Mañana: el caso TechCorp Latam.
#SeguridadCloud #CloudSecurity #Azure #IAM #IdentidadCloud #Ciberseguridad #CIO #ITManager #GestiónDeRiesgos #TechCorpLatam #CyberLeadership #Liderazgo #Chile #ZeroTrust #NISTCSF #ISO27001 #EntraID
Comentarios
Publicar un comentario