Ámbitos y herencia de asignaciones

Los ámbitos de Azure RBAC forman una jerarquía: grupo de administración, suscripción, grupo de recursos y recurso. Un grupo de administración puede contener suscripciones y otros grupos de administración. Una asignación se hereda hacia abajo: lo que se concede en un nivel vale en todo lo que cuelga de él. Nunca se hereda hacia arriba ni hacia los lados.

La regla práctica es asignar en el ámbito más estrecho que cubra la necesidad. Cada nivel que se sube multiplica los recursos que el permiso alcanza, incluidos los que se creen en el futuro.

Una asignación heredada no se ve en el recurso como asignación propia; se ve en la pestaña de asignaciones con la marca del ámbito de origen. Por eso no se corrige desde abajo: crear otra asignación más estrecha no quita la de arriba, porque los permisos se suman. Para que la herencia deje de llegar hay que retirarla o estrecharla en el ámbito donde se hizo, y comprobar después qué otras identidades dependían de ella.

Los permisos de Azure RBAC se suman: la herencia no se corta añadiendo una asignación menor debajo, solo moviendo la de arriba.

Abre jerarquia.txt y asignaciones.txt. Para saber quién tiene un rol efectivo sobre un grupo de recursos hay que mirar tres sitios: las asignaciones hechas en el propio grupo, las de la suscripción que lo contiene y las de los grupos de administración por encima. Las asignaciones de otras ramas, aunque digan Owner, no cuentan.

El riesgo mayor de una asignación no es lo que su titular puede hacer con los recursos, sino si puede asignar roles a otros: eso es lo que le permite ampliarse a sí mismo o a un cómplice. roles-integrados.txt dice qué roles pueden asignar roles. Cuenta solo las asignaciones que aplican a rg-datos, de arriba abajo, y cuenta a cada principal una vez.