Cómo detectar y prevenir la pérdida de propiedad de recursos en la nube
Estrategias con consultas SQL y políticas Rego para evitar que los entornos queden huérfanos tras rotaciones de personal.
Los cambios de equipo o las promociones suelen desatender la actualización de la propiedad de los recursos de infraestructura. Mientras la RR. HH. actualiza los títulos y el equipo de IT revoca los accesos físicos, las etiquetas de propietario en la nube suelen quedarse con el correo del empleado anterior. El resultado: aprobaciones de cambios que llegan a bandejas de entrada de personas que no tocan el proyecto desde hace meses, o entornos huérfanos que nadie monitoriza correctamente.
Detectar propietarios inactivos
La primera línea de defensa es una consulta que cruce las etiquetas de recursos con los registros de acceso de la identidad. En AWS, puedes unir los tags de propietario de las instancias EC2 con la tabla aws_iam_user_last_accessed_details para encontrar credenciales que no han autenticado en los últimos 90 días. En Azure, el proceso es más directo gracias a Entra ID: el userPrincipalName coincide directamente con la identidad que inicia sesión, eliminando la necesidad de parsear correos. En Google Cloud, la capa de IAM no guarda un historial equivalente, por lo que la señal más cercana es el último inicio de sesión registrado en Google Workspace para la cuenta asociada al recurso.
Un silencio de 90 días no es prueba definitiva de que el empleado haya cambiado de puesto, pero es una señal operativa que vale la pena revisar en quince minutos antes de convertirlo en un problema de seguridad a largo plazo.
Políticas para evitar recursos huérfanos
Las consultas únicamente detectan el problema después de que ocurre. Para prevenirlo, la propiedad debe dejar de ser una etiqueta de texto y convertirse en una asignación de rol real que el motor de políticas pueda evaluar. Esto implica usar bindings de IAM en la nube, RoleBindings en Kubernetes o roles personalizados en plataformas de orquestación de IaC.
Una política en Rego puede denegar la configuración de un recurso si el número de roles asignados como "owner" es cero. Esto fuerza la designación de un sustituto antes de permitir la operación. La implementación varía según la stack: un pipeline de Terraform casero requeriría integrar un servidor OPA en el CI/CD, mientras que plataformas de gestión de entornos pueden ejecutar estas políticas sobre las asignaciones de roles que ya están rastreando para detectar desviaciones (drift).
El paso faltante en la baja de empleados
La mayoría de las organizaciones tienen un checklist para la baja de empleados o los traslados internos, pero raramente preguntan "¿qué recursos posee esta persona?". Antes de revocar los accesos, el proceso debe incluir la revisión y reasignación explícita de los recursos etiquetados con el propietario saliente. Sin este paso, la infraestructura queda a merced de la inercia, dependiendo de que alguien descubra el problema durante la próxima auditoría de seguridad.
