Inquilinos, usuarios y roles en escenarios de Azure Lighthouse

  • Artículo

Antes de incorporar clientes para Azure Lighthouse, es importante comprender cómo funcionan los inquilinos, los usuarios y los roles de Microsoft Entra, así como la forma en que se pueden usar en escenarios de Azure Lighthouse.

Un inquilino es una instancia dedicada y de confianza del Microsoft Entra ID. Normalmente, cada inquilino representa una organización individual. Azure Lighthouse permite una proyección lógica de recursos de un inquilino en otro. Esto permite a los usuarios del inquilino de administración (por ejemplo, uno perteneciente a un proveedor de servicios) acceder a los recursos delegados en el inquilino de un cliente, o bien permite que las empresas con varios inquilinos centralicen sus operaciones de administración.

Para lograr esta proyección lógica, una suscripción (o uno o varios grupos de recursos dentro de una suscripción) en el inquilino del cliente tiene que estar incorporado a Azure Lighthouse. Este proceso de incorporación puede realizarse a través de plantillas de Azure Resource Manager o mediante la publicación de una oferta pública o privada en Azure Marketplace.

Sea cual sea el método de incorporación, deberá definir las autorizaciones. Cada autorización incluye un principalId (un usuario, grupo o entidad de servicio de Microsoft Entra en el inquilino de administración) combinado con un rol integrado que define los permisos específicos que se concederán para los recursos delegados.

Nota:

A menos que se especifique explícitamente, las referencias a un "usuario" en la documentación de Azure Lighthouse pueden referirse a un usuario, grupo o entidad de servicio de Microsoft Entra en una autorización.

Prácticas recomendadas para definir usuarios y roles

Para crear las autorizaciones, se recomiendan las siguientes prácticas recomendadas:

  • En la mayoría de los casos, querrá asignar permisos a una entidad de servicio o un grupo de usuarios de Microsoft Entra, en lugar de a una serie de cuentas de usuario individuales. Esto le permite agregar o quitar el acceso de usuarios individuales a través de la cuenta de Microsoft Entra del inquilino, en lugar de tener que actualizar la delegación cada vez que cambian los requisitos de acceso individuales.
  • Siga el principio de privilegios mínimos para que los usuarios solo tengan los permisos necesarios para completar su trabajo, lo que ayuda a reducir la posibilidad de errores involuntarios. Para más información, consulte Procedimientos de seguridad recomendados.
  • Incluya una autorización con el rol de eliminación de asignaciones de registro de los servicios administrados para que pueda quitar el acceso a la delegación posteriormente si es necesario. Si este rol no está asignado, solo un usuario puede quitar el acceso a los recursos delegados del inquilino del cliente.
  • Asegúrese de que todos los usuarios que necesiten ver la página Mis clientes en Azure Portal tengan el rol de Lector (u otro rol integrado que incluya acceso de lectura).

Importante

Para agregar permisos a un grupo de Microsoft Entra, la opción Tipo de grupo debe establecerse en Seguridad. Esta opción se selecciona cuando se crea el grupo. Para más información, consulte Creación de un grupo básico e incorporación de miembros con Microsoft Entra ID.

Compatibilidad de roles para Azure Lighthouse

Al definir una autorización, cada cuenta de usuario debe tener asignado uno de los roles integrados de Azure. No se admiten los roles personalizados ni los roles de administrador de suscripciones clásicas.

Todos los roles integrados son compatibles actualmente con Azure Lighthouse, con las siguientes excepciones:

  • No se admite el rol de Propietario.

  • Se admite el rol integrado administrador de acceso de usuario, pero solo con el objetivo limitado de asignar roles a una identidad administrada en el inquilino del cliente. No se aplicará ningún otro permiso que normalmente conceda este rol. Si define un usuario con este rol, también debe especificar los roles integrados que este usuario puede asignar a las identidades administradas.

  • No se admiten los roles con el permiso DataActions.

  • No se admiten roles que incluyan cualquiera de las siguientes acciones:

    • */write
    • */delete
    • Microsoft.Authorization/*
    • Microsoft.Authorization/*/write
    • Microsoft.Authorization/*/delete
    • Microsoft.Authorization/roleAssignments/write
    • Microsoft.Authorization/roleAssignments/delete
    • Microsoft.Authorization/roleDefinitions/write
    • Microsoft.Authorization/roleDefinitions/delete
    • Microsoft.Authorization/classicAdministrators/write
    • Microsoft.Authorization/classicAdministrators/delete
    • Microsoft.Authorization/locks/write
    • Microsoft.Authorization/locks/delete
    • Microsoft.Authorization/denyAssignments/write
    • Microsoft.Authorization/denyAssignments/delete

Importante

Al asignar roles, asegúrese de revisar las acciones especificadas para cada rol. En algunos casos, aunque no se admitan roles con el permisoDataActions, las acciones incluidas en un rol pueden permitir el acceso a los datos, donde los datos se exponen mediante claves de acceso y no se accede mediante la identidad del usuario. Por ejemplo, el rol Colaborador de la máquina virtual incluye la acción Microsoft.Storage/storageAccounts/listKeys/action, que devuelve las claves de acceso de la cuenta de almacenamiento que se podrían usar para recuperar determinados datos del cliente.

En algunos casos, un rol que se había admitido anteriormente con Azure Lighthouse puede dejar de estar disponible. Por ejemplo, si el permiso DataActions se agrega a un rol que anteriormente no tenía ese permiso, ese rol ya no se puede usar al incorporar nuevas delegaciones. Los usuarios a los que ya se les asignó el rol podrán seguir trabajando en recursos delegados previamente, pero no podrán realizar tareas que usen el permiso DataActions.

En cuanto se agrega un nuevo rol integrado aplicable a Azure, se puede asignar al incorporar clientes mediante las plantillas de Azure Resource Manager. Puede haber un retraso antes de que el rol recién agregado esté disponible en el Centro de partners cuando se publique una oferta de servicio administrado. Del mismo modo, si un rol deja de estar disponible, es posible que lo vea en el Centro de partners durante un período de tiempo; sin embargo, no podrá publicar nuevas ofertas con estos roles.

Transferencia de suscripciones delegadas entre inquilinos de Microsoft Entra

Si se transfiere una suscripción a la cuenta de otro inquilino de Microsoft Entra, los recursos de definición de registro y asignación de registro creados con el proceso de incorporación de Azure Lighthouse se mantienen. Esto significa que el acceso concedido a través de Azure Lighthouse a inquilinos de administración permanece en vigor para esa suscripción (o para los grupos de recursos delegados de esa suscripción).

La única excepción es si la suscripción se transfiere a un inquilino de Microsoft Entra al que se le había delegado anteriormente. En este caso, se quitan los recursos de delegación para ese inquilino y el acceso concedido a través de Azure Lighthouse ya no se aplica, porque la suscripción ahora pertenece directamente a ese inquilino (en lugar de delegársele a través de Azure Lighthouse). Sin embargo, si esa suscripción también se delegó a otros inquilinos de administración, esos otros inquilinos de administración conservarán el mismo acceso a la suscripción.

Pasos siguientes