Azure Lighthouse (2025): qué es, cómo usarlo y por qué acelera la gestión multicliente y multitenant

Qué es Azure Lighthouse y beneficios clave

Azure Lighthouse habilita la administración entre inquilinos con escalabilidad, automatización y gobierno. El cliente (el tenant que posee las suscripciones) decide qué delega (una o varias suscripciones, o grupos de recursos concretos), a quién lo delega (usuarios, grupos o aplicaciones de servicio que viven en el tenant del proveedor) y con qué permisos (roles RBAC). Todo esto queda guardado como un recurso de Azure, visible y revocable en cualquier momento.

La principal ventaja es que el equipo del proveedor o del área de plataforma puede trabajar “como si” los recursos remotos fueran suyos: ve las suscripciones en el portal dentro de “My customers”, puede lanzar Azure Policy, configurar Azure Monitor o revisar Defender for Cloud, pero el cliente sigue teniendo el control y la auditoría en su tenant. No hace falta crear cuentas de invitado para cada técnico, lo que reduce mucho la gestión de identidades externas.

• Gestión a escala: una sola vista para muchas suscripciones/clientes, ideal para SOCs, NOC, equipos de plataforma y MSP.
• Sin invitados: no es necesario poblar el Azure AD/Entra ID del cliente con usuarios B2B; la delegación se hace por recurso.
• Integración nativa: funciona con la mayor parte del plano de gestión de Azure: Policy, Monitor, Defender, Sentinel, Resource Graph, Arc.
• Transparencia: el cliente siempre ve qué proveedor tiene acceso y qué roles tiene, y puede retirarlo sin depender del proveedor.

Arquitectura y conceptos: delegación, roles y ámbitos

Internamente, Azure Lighthouse se apoya en el modelo de Azure Delegated Resource Management. La delegación se representa como un recurso del tipo Microsoft.ManagedServices/registrationDefinitions que el cliente despliega en su suscripción. Ese recurso dice: “este tenant (managedByTenantId) puede administrar este ámbito (suscripción o RG) con estas identidades y estos roles”.

Esto permite dos estrategias:

• Delegación amplia (suscripción completa): más sencilla, recomendada cuando se va a gestionar postura (Defender, Policy, Monitor) o cuando el proveedor ofrece servicios 24×7. Se ve todo y se gestionan mejor las alertas.
• Delegación granular (grupo de recursos): útil cuando el cliente solo quiere que se administre una carga concreta (por ejemplo, un SAP en IaaS, un entorno de IoT o un RG con una app crítica).

Las identidades que reciben permisos pueden ser:

• Usuarios del tenant del proveedor.
• Grupos del tenant del proveedor (la opción preferida, porque permite añadir/quitar técnicos sin tocar la delegación en cada cliente).
• Aplicaciones de servicio (service principal) para automatizaciones, pipelines de IaC o integraciones con ITSM.

Onboarding por plantilla ARM (paso a paso)

El alta por plantilla ARM es la forma más rápida de empezar. No requiere publicar nada en Marketplace y es perfecta para pilotos o para clientes que ya tienen relación con el proveedor y solo necesitan autorizarle el acceso.

Pasos detallados:

1. Definir el modelo: el proveedor indica al cliente qué tenant debe aparecer como managedByTenantId (el del proveedor) y qué identidades (usuarios, grupos, apps) va a usar. También indica el rol RBAC apropiado: Reader, Contributor, Security Admin, etc.
2. Generar la plantilla desde el portal: en el portal de Azure del proveedor hay una zona de Lighthouse (“My customers”). Desde ahí se puede crear una definición de delegación y el portal genera automáticamente el JSON ARM con todos los campos. Ese JSON se descarga.
3. Entregar la plantilla al cliente: el cliente, en su suscripción, despliega la plantilla ARM. Puede hacerlo desde el portal (Importar plantilla → Revisar + crear) o por CLI/PowerShell. Es importante que el proveedor de recursos Microsoft.ManagedServices esté registrado en la suscripción.
4. Validar en ambos lados: en el tenant del proveedor debe aparecer el nuevo cliente en “My customers”; en el tenant del cliente debe aparecer el proveedor en “Service providers”. Si esto no aparece, algo se ha desplegado mal.
5. Documentar la delegación: conviene guardar el JSON exacto que se usó para que, si hay que añadir un rol o un nuevo grupo, se haga sobre la misma base y no se cree un modelo diferente.

{ "$schema": "https://schema.management.azure.com/schemas/2019-08-01/managedservicesDefinition.json#", "contentVersion": "1.0.0.0", "parameters": { "mspOfferName": { "type": "string" }, "mspOfferDescription": { "type": "string" }, "managedByTenantId": { "type": "string" }, "authorizations": { "type": "array" } }, "resources": [ { "type": "Microsoft.ManagedServices/registrationDefinitions", "apiVersion": "2020-02-01", "name": "[guid(parameters('mspOfferName'))]", "properties": { "registrationDefinitionName": "[parameters('mspOfferName')]", "description": "[parameters('mspOfferDescription')]", "managedByTenantId": "[parameters('managedByTenantId')]", "authorizations": "[parameters('authorizations')]" } } ] }

Si después hay que añadir otro grupo o una aplicación nueva, se vuelve a desplegar la misma plantilla (actualizada) o se crea una nueva delegación. Lo importante es no perder la relación entre “cliente” y “qué permisos le dimos”.

Onboarding por Managed Service en Azure Marketplace

Cuando se quiere que el alta del cliente sea autoservicio o cuando se comercializan paquetes de servicios gestionados, la vía más limpia es crear una Managed Service offer en Azure Marketplace. Esto hace que el cliente vea su oferta de servicio, la adquiera y, en ese mismo proceso, se haga la delegación Lighthouse.

Esta vía tiene ventajas comerciales (visibilidad, autoprovisión, control de planes) y de gobierno (se puede tener un plan “básico” para todos y uno “ampliado” solo para clientes con contrato especial).

Pasos generales:

1. Crear la oferta en Partner Center, de tipo Managed Service.
2. Definir los planes (públicos y/o privados) y en cada plan especificar qué identidades del proveedor tendrán cuál rol.
3. Publicar y probar con un tenant de prueba para comprobar que, al adquirirlo, aparece la delegación en “Service providers”.
4. Comunicar al cliente cómo adquirir esa oferta y qué permisos va a conceder.

Operación diaria: portal, CLI/API, Policy, Monitor, Defender y Sentinel

Una vez delegado, el día a día se parece a administrar cualquier suscripción propia, pero con un filtro por cliente. Desde “My customers” en el portal se puede seleccionar un cliente y, al hacerlo, el portal cambia el contexto y todo lo que se haga a partir de ahí (crear alertas, ver máquinas, asignar una Policy) se hace sobre la suscripción delegada.

Esto es especialmente potente para estas tareas:

• Azure Policy: asignar desde el tenant del proveedor una iniciativa (p. ej. ISO 27001 o Azure Security Benchmark) al tenant del cliente y ver en un mismo panel el cumplimiento de varios clientes.
• Azure Monitor y diagnósticos: enviar logs de Activity, de recursos PaaS y de infraestructura a un Log Analytics workspace del proveedor. Después, construir paneles agrupados por cliente.
• Defender for Cloud: revisar recomendaciones y secure score sin entrar al tenant del cliente. Si el cliente delegó la suscripción completa, la visibilidad es casi total.
• Microsoft Sentinel: recoger la telemetría de varios clientes en uno o varios workspaces y aplicar reglas y playbooks comunes.

También se puede trabajar por CLI o PowerShell: basta con hacer az account get-access-token --tenant <tenant-proveedor> (o el login estándar) y después seleccionar la suscripción delegada. Las operaciones ARM funcionarán contra esa suscripción como si fuera propia.

Seguridad y gobierno: MFA, mínimo privilegio, autorizaciones “eligible” y auditoría

Un punto clave que a veces se olvida: las políticas de acceso condicional del cliente no siempre protegen a las identidades del proveedor, porque esas identidades viven en otro tenant. Por eso la seguridad hay que reforzarla en el tenant del proveedor:

• MFA obligatorio para todos los técnicos y apps que operan con Lighthouse.
• Acceso condicional (ubicación, dispositivo, riesgos) en el tenant del proveedor.
• Asignación por grupos y revisiones de acceso periódicas.
• Elevación temporal (permisos “eligible”) para operaciones de más riesgo.
• Auditoría y exportación de logs del lado del cliente para comprobar quién hizo qué.

Así se consigue el equilibrio: el cliente se siente seguro porque puede revocar y auditar; el proveedor trabaja rápido porque ya no tiene que entrar con 15 usuarios invitados distintos.

Costes y disponibilidad

Azure Lighthouse no tiene coste extra. Se paga lo mismo que si el cliente no lo usara. El coste real viene de lo que se haga después (logs, Sentinel, Defender, monitorización, automatizaciones). Por eso conviene activar también presupuestos y alertas de coste por suscripción delegada, incluso si la factura la paga el cliente directo: así el proveedor puede avisar a tiempo.

Está disponible en Azure público. Para nubes soberanas (gobierno, China, etc.) hay que comprobar compatibilidad porque no siempre hay delegación cruzada.

Limitaciones y consideraciones técnicas

Aunque es muy flexible, hay que tener presentes algunas limitaciones para no diseñar procesos que luego no se pueden ejecutar:

• Solo plano de gestión: si su caso necesita leer contenido de un almacenamiento o un secreto de Key Vault, habrá que dar permisos de datos o montar una función/Logic App en el tenant del cliente.
• Roles integrados mejor que personalizados: los roles integrados están soportados y probados; los personalizados a veces no aplican bien en escenarios delegados.
• Delegue al nivel correcto: si va a medir postura de seguridad completa, delegue la suscripción entera; si delega solo un RG, algunas vistas de seguridad no estarán completas.
• Sin mezcla de nubes: no diseñar pensando en controlar un Azure público desde una nube soberana con Lighthouse.

Casos de uso: MSP/CSP y empresa multitenant

MSP/CSP

El patrón típico es: el MSP tiene su tenant de operación, da de alta a cada cliente con ARM o con Marketplace, y después aplica las mismas plantillas de Policy, los mismos conectores de diagnóstico y las mismas reglas de Sentinel a todos. Las incidencias llegan a un mismo NOC/SOC y se ve el contexto del cliente con un clic.

Empresa multitenant

Muchas organizaciones tienen un tenant corporativo y luego tenants “satélite” de filiales, de proyectos, de adquisiciones o de zonas geográficas. Con Lighthouse pueden administrar todos desde el tenant corporativo, sin forzar a las filiales a invitar usuarios ni a ceder el control total.

Preguntas frecuentes sobre Azure Lighthouse

Respuestas claras a las dudas que suelen aparecer cuando se propone Lighthouse en proyectos de operación gestionada, MSP o multitenant.

Enlaces oficiales

• Azure Lighthouse — visión general
• Incorporación de clientes con plantilla ARM
• Publicar Managed Service offer en Marketplace
• Buenas prácticas de seguridad
• Arquitectura de Azure Lighthouse
• Ver y administrar clientes
• Ejemplos y plantillas
• Requisitos de Managed Service offers (Partner Center)

Conclusión y siguientes pasos

Azure Lighthouse es la pieza que faltaba para que una operación en Azure pueda ser realmente multicliente sin dolores: el cliente conserva el control y puede revocar, el proveedor trabaja desde su propio tenant con sus políticas de seguridad y el equipo de plataforma puede estandarizar herramientas, paneles y runbooks.

El camino práctico suele ser: 1) definir roles y ámbitos, 2) probar una delegación ARM con un cliente piloto, 3) estandarizar las plantillas y 4) si hay una oferta comercial más amplia, publicarla en Marketplace. A partir de ahí, añadir Policy, Monitor, Defender y Sentinel es solo cuestión de madurez operativa.