Inquilinos, usuarios y roles en escenarios de Azure Lighthouse
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. Si lo hace, puede agregar o quitar el acceso para usuarios individuales a través del identificador de Microsoft Entra del inquilino, sin tener que actualizar la delegación cada vez que cambien los requisitos de acceso individuales.
- Siga el principio de usar privilegios mínimos. Para reducir la posibilidad de errores accidentales, los usuarios solo deben tener los permisos necesarios para realizar su trabajo específico. Para más información, consulte Procedimientos de seguridad recomendados.
- Incluya una autorización con el Rol de eliminación de asignación de registro de servicios administrados para que pueda eliminar el acceso a la delegación 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 roles personalizados ni roles de administrador de suscripciones clásicos.
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 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. Aunque no se admiten roles con el permiso DataActions, hay casos en los que las acciones incluidas en un rol admitido pueden permitir el acceso a los datos. Esto suele ocurrir cuando los datos se exponen a través de claves de acceso, a los que no se accede a través de 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 ha asignado ese rol podrán seguir trabajando en recursos delegados previamente, pero no podrán realizar ninguna tarea que use 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. De forma similar, si un rol deja de estar disponible, es posible que todavía lo vea en el Centro de partners durante un tiempo, pero no podrá publicar nuevas ofertas con dichos 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
- Obtenga información sobre las Prácticas de seguridad recomendadas para Azure Lighthouse.
- Incorpore los clientes a Azure Lighthouse, ya sea mediante plantillas de Azure Resource Manager o publicando una oferta de servicios administrados privada o pública en Azure Marketplace.