Compartir vía

¿Qué son los grupos de administración de Azure?

  • Artículo

Si su organización tiene varias suscripciones de Azure, puede que necesite una manera de administrar el acceso, las directivas y el cumplimiento de esas suscripciones de forma eficaz. Los grupos de administración de Azure proporcionan un ámbito de gobernanza por encima de las suscripciones. Si se organizan las suscripciones en grupos de administración, las condiciones de gobernanza que se apliquen se propagarán por herencia a todas las suscripciones asociadas.

Los grupos de administración proporcionan capacidad de administración de nivel empresarial a gran escala con independencia del tipo de suscripciones que tenga. Sin embargo, todas las suscripciones de un único grupo de administración deben confiar en el mismo inquilino de Microsoft Entra ID.

A modo de ejemplo, puede aplicar directivas a un grupo de administración que limite las regiones disponibles para la creación de máquinas virtuales (VM). Esta directiva se aplicaría a todos los grupos de administración, suscripciones y recursos anidados, y permitiría la creación de máquinas virtuales solo en regiones autorizadas.

Jerarquía de los grupos de administración y las suscripciones

Puede compilar una estructura flexible de grupos de administración y suscripciones para organizar los recursos en una jerarquía para una administración unificada de las directivas y el acceso. El diagrama siguiente muestra un ejemplo de creación de una jerarquía para la gobernanza mediante grupos de administración.

Diagrama de una jerarquía de grupos de administración de ejemplo.

Puede crear una jerarquía que aplique una directiva, por ejemplo, que limite las ubicaciones de las máquinas virtuales a la región Oeste de EE. UU. en el grupo de administración llamado Corp. Esta directiva hereda todas las suscripciones de Contrato Enterprise (EA) descendientes de ese grupo de administración y se aplica a todas las máquinas virtuales de esas suscripciones. El propietario del recurso o la suscripción no puede modificar esta directiva de seguridad para permitir una gobernanza mejorada.

Nota:

Los grupos de administración no se admiten actualmente en las características de Cost Management en suscripciones de Contrato de cliente de Microsoft (MCA).

Otro escenario en el que usaría grupos de administración es para proporcionar acceso de usuario a varias suscripciones. Al mover varias suscripciones de un grupo de administración, puede crear una asignación de roles de Azure en el grupo de administración. El rol hereda ese acceso a todas las suscripciones. Una asignación en el grupo de administración puede permitir a los usuarios tener acceso a todo lo que necesitan, en lugar de crear scripts de control de acceso basado en rol (RBAC) de Azure sobre las distintas suscripciones.

Hechos importantes acerca de los grupos de administración

  • Un único directorio puede admitir 10 000 grupos de administración.

  • Un árbol de grupo de administración puede admitir hasta seis niveles de profundidad.

    Este límite no incluye el nivel raíz ni el nivel de suscripción.

  • Cada grupo de administración y suscripción solo puede admitir un elemento primario.

  • Cada grupo de administración puede tener muchos elementos secundarios.

  • Todas las suscripciones y grupos de administración están dentro de una única jerarquía en cada directorio. Para más información, consulte Hechos importantes sobre el grupo de administración raíz más adelante en este artículo.

Un grupo de administración raíz para cada directorio

Cada directorio tiene un grupo de administración de nivel superior denominado grupo de administración raíz. Este grupo de administración raíz está integrado en la jerarquía para contener todos los grupos de administración y suscripciones.

Este grupo de administración raíz permite la aplicación de directivas globales y de asignaciones de roles de Azure a nivel de directorio. Inicialmente, el acceso elevado permite administrar todas las suscripciones y grupos de administración de Azure al rol de administrador de acceso de usuario de este grupo raíz. Una vez que el administrador de inquilinos eleva el acceso, puede asignar cualquier rol de Azure a otros usuarios o grupos del directorio para administrar la jerarquía. Como administrador, puede asignar su cuenta como propietario del grupo de administración raíz.

Hechos importantes acerca de los grupos de administración raíz

  • De manera predeterminada, el nombre para mostrar del grupo de administración raíz es Grupo raíz del inquilino y funciona como un grupo de administración. El id. es el mismo valor que el id. de inquilino de Microsoft Entra.
  • Para cambiar el nombre para mostrar, su cuenta debe tener el rol Propietario o Colaborador en el grupo de administración raíz. Para más información, consulte Cambiar el nombre de un grupo de administración.
  • El grupo de administración raíz no se puede mover ni eliminar, a diferencia de los demás.
  • Todas las suscripciones y los grupos de administración se incluyen en un grupo de administración raíz único del directorio.
    • Todos los recursos del directorio pertenecen al grupo de administración raíz para la administración global.
    • Las suscripciones nuevas pertenecen de manera predeterminada y automática al grupo de administración raíz cuando se crean.
  • Todos los clientes de Azure pueden ver el grupo de administración raíz, pero no todos los clientes tienen acceso para administrar ese grupo de administración raíz.
    • Todos los usuarios con acceso a una suscripción pueden ver el contexto de dónde está esa suscripción en la jerarquía.
    • Ninguna tiene acceso predeterminado al grupo de administración raíz. Los administradores globales de Microsoft Entra son los únicos usuarios que pueden elevar sus propios privilegios para obtener acceso. Una vez que tienen acceso al grupo de administración raíz, pueden asignar cualquier rol de Azure a otros usuarios para administrar el grupo.

Importante

Todas las asignaciones de acceso de usuario o de directivas del grupo de administración raíz se aplican a todos los recursos del directorio. Debido a este nivel de acceso, todos los clientes deben evaluar la necesidad de tener los elementos definidos en este ámbito. Las asignaciones de directivas y de acceso de usuario deberían ser obligatorias solo en este ámbito.

Instalación inicial de los grupos de administración

Cuando algún usuario comienza usando grupos de administración, se produce un proceso de configuración inicial. El primer paso es la creación del grupo de administración raíz en el directorio. Todas las suscripciones existentes que hay en el directorio se convierten en elementos secundarios del grupo de administración raíz.

El motivo de este proceso es asegurarse de que hay solo una jerarquía de grupos de administración en un directorio. La jerarquía única dentro del directorio permite a los clientes administrativos aplicar directivas y un acceso global que otros clientes dentro del directorio no puedan omitir.

Todo lo asignado en la raíz se aplica a toda la jerarquía. Es decir, se aplica a todos los grupos de administración, suscripciones, grupos de recursos y recursos dentro de ese inquilino de Microsoft Entra.

Acceso al grupo de administración

Los grupos de administración de Azure admiten Azure RBAC en todas las definiciones de roles y acceso a los recursos. Los recursos secundarios que existen en la jerarquía heredan estos permisos. Cualquier rol de Azure puede asignarse a un grupo de administración que hereda la jerarquía para los recursos.

Por ejemplo, puede asignar el rol Colaborador de máquina virtual de Azure a un grupo de administración. Este rol no tiene ninguna acción en el grupo de administración, pero se hereda en todas las máquinas virtuales de ese grupo de administración.

El gráfico siguiente muestra la lista de roles y las acciones admitidas en los grupos de administración.

Nombre de rol de Azure Crear Cambiar nombre Move** Eliminar Asignación de acceso Asignar directiva Lectura
Propietario X X X X X X X
Colaborador X X X X X
Colaborador de grupo de administración* X X Mover detalles X X
Lector X
Lector de grupo de administración* X
Colaborador de directivas de recursos X
Administrador de acceso de usuario X X

*: estos roles permiten a los usuarios realizar las acciones especificadas solo en el ámbito del grupo de administración.

**: no se necesitan asignaciones de roles en el grupo de administración raíz para mover una suscripción o un grupo de administración hacia y desde este grupo.

Trasladar suscripciones y grupos de administración

Mover suscripciones y grupos de administración requiere que se apliquen diferentes asignaciones de roles. Para mover una suscripción secundaria o un grupo de administración, se necesitan los siguientes permisos:

  • La suscripción secundaria o el grupo de administración que se va a mover
    • Microsoft.management/managementgroups/write
    • Microsoft.management/managementgroups/subscriptions/write (solo para suscripciones)
    • Microsoft.Authorization/roleAssignments/write
    • Microsoft.Authorization/roleAssignments/delete
    • Microsoft.Management/register/action
  • Grupo de administración primario de destino
    • Microsoft.management/managementgroups/write
  • Grupo de administración primario actual
    • Microsoft.management/managementgroups/write

Para obtener más información sobre cómo mover elementos dentro de la jerarquía, consulte Administrar los recursos con grupos de administración.

Asignación y definición de roles personalizados de Azure

Puede definir un grupo de administración como un ámbito asignable en una definición de rol personalizado de Azure. El rol personalizado de Azure está disponible para su asignación no solo en ese grupo de administración, sino también en todos los grupos de administración, suscripciones, grupos de recursos o recursos que haya debajo de él. El rol personalizado hereda la jerarquía, como cualquier rol integrado.

Para obtener información sobre las limitaciones con roles personalizados y grupos de administración, consulte Limitaciones más adelante en este artículo.

Definición de ejemplo

La definición y creación de un rol personalizado no cambia con la inclusión de los grupos de administración. Use la ruta de acceso completa para definir el grupo de administración /providers/Microsoft.Management/managementgroups/{_groupId_}.

Use el identificador del grupo de administración, no su nombre para mostrar. Este error común se produce porque ambos son campos definidos por el usuario al crear un grupo de administración.

...
{
  "Name": "MG Test Custom Role",
  "Id": "id",
  "IsCustom": true,
  "Description": "This role provides members understand custom roles.",
  "Actions": [
    "Microsoft.Management/managementGroups/delete",
    "Microsoft.Management/managementGroups/read",
    "Microsoft.Management/managementGroups/write",
    "Microsoft.Management/managementGroups/subscriptions/delete",
    "Microsoft.Management/managementGroups/subscriptions/write",
    "Microsoft.resources/subscriptions/read",
    "Microsoft.Authorization/policyAssignments/*",
    "Microsoft.Authorization/policyDefinitions/*",
    "Microsoft.Authorization/policySetDefinitions/*",
    "Microsoft.PolicyInsights/*",
    "Microsoft.Authorization/roleAssignments/*",
    "Microsoft.Authorization/roledefinitions/*"
  ],
  "NotActions": [],
  "DataActions": [],
  "NotDataActions": [],
  "AssignableScopes": [
        "/providers/microsoft.management/managementGroups/ContosoCorporate"
  ]
}
...

Problemas al desasociar la definición del rol y la ruta de la jerarquía de asignación

Las definiciones de roles son un ámbito asignable en cualquier parte de la jerarquía del grupo de administración. Una definición de roles puede estar en un grupo de administración primario mientras la asignación de roles real exista en la suscripción secundaria. Dado que hay una relación entre ambos elementos, se muestra un error si intenta separar la asignación de su definición.

Por ejemplo, considere el siguiente ejemplo de una pequeña sección de una jerarquía.

Diagrama de un subconjunto de la jerarquía de grupos de administración de ejemplo.

Supongamos que se define un rol personalizado en el grupo de administración de espacio aislado. Dicho rol personalizado se asigna luego en las dos suscripciones de espacio aislado.

Si intenta mover una de esas suscripciones para que sea un elemento secundario del grupo de administración Corp, esto interrumpe la ruta de acceso de la asignación de roles de suscripción a la definición de roles para el grupo de administración del espacio aislado. En este escenario, se recibe un error que indica que no se permite el traslado porque interrumpe esta relación.

Para solucionar este escenario, tiene estas opciones:

  • Quitar la asignación de roles de la suscripción antes de mover la suscripción a un nuevo grupo de administración primario.
  • Agregar la suscripción al ámbito asignable de la definición de roles.
  • Cambiar el ámbito asignable en la definición de roles. En este ejemplo, puede actualizar los ámbitos asignables desde el grupo de administración de espacio aislado al grupo de administración raíz para que ambas ramas de la jerarquía puedan llegar a la definición.
  • Crear otro rol personalizado se define en la otra rama. Este nuevo rol también requiere que cambie el rol en la suscripción.

Limitaciones

Hay limitaciones en el uso de roles personalizados en los grupos de administración:

  • En los ámbitos asignables de un nuevo rol no se puede definir más de un grupo de administración. Esta limitación se ha establecido para reducir el número de situaciones en las que las definiciones de roles y las asignaciones de roles están desconectadas. Esta situación se produce cuando una suscripción o un grupo de administración con una asignación de roles se mueve a un elemento primario diferente que no tiene la definición de roles.
  • No se pueden asignar roles personalizados con DataActions en el ámbito del grupo de administración. Para más información, consulte Límites de roles personalizados.
  • Azure Resource Manager no valida la existencia del grupo de administración en el ámbito asignable de la definición de roles. La definición de roles se crea aunque haya algún error de escritura o un identificador de grupo de administración incorrecto.

Movimiento de grupos de administración y suscripciones

Para mover un grupo de administración o una suscripción a un elemento secundario de otro grupo de administración, necesita:

  • Permisos de escritura del grupo de administración y de escritura de la asignación de roles en la suscripción o en el grupo de administración secundarios.
    • Ejemplo de rol integrado: Propietario
  • Acceso de escritura de grupos de administración en el grupo de administración primario de destino.
    • Ejemplo de rol integrado: Propietario, Colaborador, Colaborador de grupo de administración
  • Acceso de escritura de grupos de administración en el grupo de administración primario existente.
    • Ejemplo de rol integrado: Propietario, Colaborador, Colaborador de grupo de administración

Hay una excepción: si el grupo de administración primario existente o de destino es el grupo de administración raíz, no se aplican los requisitos de permisos. Puesto que el grupo de administración raíz es la zona de aterrizaje predeterminada de todos los nuevos grupos de administración y suscripciones, no necesita permisos sobre él para mover un elemento.

Si el rol Propietario de la suscripción se hereda del grupo de administración actual, los destinos de movimiento están limitados. Solo puede mover la suscripción a otro grupo de administración en el que tenga el rol Propietario. No puede moverla a un grupo de administración en el que solo sea Colaborador porque perdería la propiedad de la suscripción. Si se le asigna directamente el rol Propietario de la suscripción, puede moverla a cualquier grupo de administración donde tenga el rol Colaborador.

Importante

Azure Resource Manager almacena en caché los detalles de la jerarquía del grupo de administración durante un máximo de 30 minutos. Como resultado, es posible que Azure Portal no muestre inmediatamente que se ha movido un grupo de administración.

Auditoría de grupos de administración mediante registros de actividad

Se admiten grupos de administración en registros de actividad de Azure Monitor. Puede consultar todos los eventos que se producen en un grupo de administración en la misma ubicación central que otros recursos de Azure. Por ejemplo, puede ver todos los cambios de asignaciones de roles o de asignación de directiva efectuados en un grupo de administración determinado.

Captura de pantalla de los registros de actividad y las operaciones relacionadas con un grupo de administración seleccionado.

Cuando quiera realizar consultas en grupos de administración fuera de Azure Portal, el ámbito de destino de los grupos de administración será similar a "/providers/Microsoft.Management/managementGroups/{management-group-id}".

Nota:

Con la API de REST de Azure Resource Manager, puede habilitar la configuración de diagnóstico en un grupo de administración para enviar entradas relacionadas del registro de actividad de Azure Monitor a un área de trabajo de Log Analytics, Azure Storage o Azure Event Hubs. Para más información, consulte Creación o actualización de la configuración de diagnóstico del grupo de administración.

Contenido relacionado

Para más información sobre los grupos de administración, consulte: