El árbol de Azure: inquilino, grupos, suscripciones y grupos de recursos

En la cima de todo está el inquilino: el directorio de Microsoft Entra de la empresa, donde viven sus usuarios, grupos y aplicaciones. Lo identifica un dominio (aquí, orinoquia.example) y un identificador propio. Una suscripción no tiene usuarios propios: confía en un directorio, el de su inquilino, para saber quién es quién. Cada suscripción confía en un único directorio, y un mismo directorio puede ser de confianza para muchas suscripciones.

Esto fija una regla de revisión: la frontera de identidad de una empresa en Azure es el inquilino, no la suscripción. Quien administra el directorio puede, en principio, llegar a todo lo que cuelga de él, y por eso la primera pregunta de una revisión es cuántos inquilinos tiene la empresa y cuántas suscripciones confían en cada uno. Abre la tabla inquilino y la de suscripciones para ver ambas cifras en Orinoquia.

Debajo del inquilino hay un grupo raíz de administración, que se llama por defecto «Tenant root group». Debajo, grupos de administración dentro de grupos, hasta seis niveles de profundidad sin contar la raíz ni el nivel de las suscripciones. Cada grupo de administración y cada suscripción tiene un único padre, de modo que el árbol no tiene ciclos ni atajos.

Una revisión empieza dibujando ese árbol. Lee la tabla grupos_de_administracion y sigue los padres desde la raíz hasta el grupo más hondo.

El grupo de recursos es el nivel más pequeño que reúne cosas. Su criterio no es la organización de la empresa sino el ciclo de vida: lo que se crea, se cambia y se borra junto. Un recurso pertenece a un solo grupo, y borrar el grupo borra todo lo que contiene. Las etiquetas que lleve el grupo no pasan a sus recursos.

Eso hace peligroso un grupo que mezcla ciclos de vida: quien lo borra al cerrar un proyecto temporal arrastra, sin querer, lo que debía quedarse. Cada recurso de Orinoquia declara su ciclo en la tabla recursos. Busca el grupo donde convive lo temporal con algo permanente.

Un auditor propone una solución elegante: poner sub-arroz-prod a la vez bajo mg-arroz-prod y bajo mg-plataforma, para que herede las reglas de los dos. Azure no lo permite. Cada suscripción admite un solo padre, y cada grupo de administración también. Lo que sí se puede es mover la suscripción de padre; los efectos de la herencia cambian en cuanto se mueve, y por eso una suscripción movida a otro grupo pierde lo que heredaba del anterior.