Privilegios que cruzan del directorio local a la nube

Un rol del inquilino se puede recibir de dos maneras: puesto a mano sobre una cuenta, o heredado por pertenecer a un grupo. La diferencia importa poco mientras todo viva en la nube, y lo cambia todo cuando el grupo se administra en la sede: entonces la lista de quién es administrador en la nube la escribe quien pueda editar ese grupo en el directorio local.

De ahí sale la recomendación que repiten los marcos de arquitectura de identidad: las cuentas con roles de administración del inquilino se crean directamente en la nube y no se sincronizan, para que un problema en la sede no se convierta en un problema arriba. Un evaluador no la cita como opinión: la usa como regla con la que medir lo que encuentra.

Una asignación directa de rol sobre una cuenta sincronizada es el caso más limpio de privilegio que cruza la frontera: la cuenta nació en la sede, su contraseña se gestiona en la sede, y el rol que la hace administradora está puesto arriba. No hay grupo de por medio que lo disimule.

Abre el laboratorio y cruza las columnas de origen, rol y forma de recibirlo.

El segundo camino es el grupo. Un grupo de la sede con un nombre inocente puede estar enlazado a un rol del inquilino que permite registrar aplicaciones y conceder permisos a nombre de toda la organización. Quien administre las pertenencias de ese grupo —normalmente un equipo de operación de cuentas, no el de seguridad— tiene el camino abierto.

Vuelve al laboratorio y mira qué entrega cada grupo.

El hallazgo se abre con un número: cuántas de las cuentas que administran el inquilino tienen su origen en el directorio de la sede. Esa cifra, y no un adjetivo, es la que hace que alguien decida moverse.

Un hallazgo sin corrección aplicable es una queja. La corrección tiene que caber en el presupuesto y en el calendario de quien la recibe, y tiene que resolver la causa, no el síntoma.