Revisión de accesos, o quitar lo que ya no se usa

Una revisión de acceso reúne a un revisor (el propietario del recurso, un gerente, la propia persona o personas elegidas) y le presenta cada acceso con su última actividad para que apruebe o deniegue. Puede cubrir miembros de un grupo, acceso a aplicaciones y asignaciones de roles de Entra o de Azure. Su valor no es la lista que produce, sino el acceso que se retira. Se hace con recurrencia, porque el privilegio vuelve a acumularse.

Dos ajustes deciden qué pasa cuando los revisores no responden dentro de la duración de la revisión: uno elige qué hacer con el acceso de quien nadie revisó (dejarlo como está, retirarlo, aprobarlo o seguir la recomendación del sistema) y otro decide si los resultados se aplican solos al terminar. Si el acceso se deja como está, el de quien nadie revisó se queda. Sin la aplicación automática, ni siquiera las denegaciones se ejecutan hasta que alguien las aplique a mano. Una revisión así produce un informe y no cambia nada.

Abre revision-owner-prod.txt y lee los ajustes antes de mirar los resultados.

Los invitados externos son el caso típico: un proveedor recibe un rol alto para un proyecto y nadie lo retira. La ayuda de decisión «No sign-in within 30 days» recomienda denegar a quien no inició sesión en 30 días. Cuando la recomendación es denegar y el revisor no respondió, el ajuste de no respuesta decide el destino del acceso.

Para argumentar un hallazgo hace falta el número. La fecha de la revisión y el último inicio de sesión dan los días de inactividad. Un invitado con un rol de Owner que lleva cuatro meses sin entrar no tiene una necesidad operativa que defender.

Un hallazgo bien redactado dice qué se encontró, por qué importa y qué se recomienda, de forma que quien lo lea pueda actuar sin hablar contigo. Para esta revisión, lo encontrado es que los ajustes dejan sin retirar el acceso de dos principales que el sistema recomendaba denegar y que no respondieron.