Seguridad y permisos de Azure Lighthouse: cómo gestionar el acceso a la nube multiinquilino de forma segura

By Mirko Peters · 2026-10-21

Descubre cómo funciona la seguridad de Azure Lighthouse, cómo aplicar el mínimo privilegio entre inquilinos y cómo los clientes mantienen el control total de su nube.

Automatically translated with AI from the original post. Read the English original

La seguridad de Azure Lighthouse se basa en los principios de mínimo privilegio, las proyecciones lógicas de recursos y los límites estrictos controlados por el cliente, que permiten a los proveedores de servicios gestionados administrar entornos de nube multiinquilino sin llegar nunca a tener contraseñas de administrador. Para ello utiliza roles integrados de Azure y registros de auditoría permanentes.

Puntos clave

• Los clientes conservan la autoridad absoluta sobre sus inquilinos de Azure al definir ámbitos precisos y roles integrados.
• Las definiciones y asignaciones de registro actúan como un acuerdo permanente que Azure verifica en cada acción.
• Los roles de Propietario completo y el acceso al plano de datos no son compatibles en absoluto con las delegaciones de Azure Lighthouse.
• Los proveedores operan mediante proyecciones lógicas en su propio portal, sin compartir contraseñas ni credenciales de usuario.
• Los registros de actividad documentan cada cambio en el inquilino del cliente, lo que proporciona un registro de auditoría transparente.

La arquitectura de seguridad de Azure Lighthouse

Tradicionalmente, gestionar varios entornos de nube requería crear cuentas de administrador dedicadas dentro de cada inquilino de cliente. Este método antiguo generaba enormes riesgos de seguridad, hojas de cálculo llenas de contraseñas temporales y credenciales olvidadas que seguían activas en sistemas externos. Azure Lighthouse cambia esta dinámica de raíz al introducir una puerta segura y criptográficamente vinculada entre mundos de nube independientes.

En lugar de fusionar inquilinos o compartir credenciales, Lighthouse utiliza una proyección lógica. Los recursos del cliente permanecen íntegramente en su propio entorno de nube: su inquilino, sus suscripciones y sus grupos de recursos. El proveedor de servicios gestionados ve estos recursos a través de una puerta segura desde su propio inquilino de administración. Cada solicitud que envía el proveedor pasa por la capa de validación central de Azure, que comprueba continuamente la documentación de autorización antes de permitir que se ejecute cualquier comando.

El acuerdo en dos piezas

La seguridad de Azure Lighthouse no se basa en una confianza ciega; se apoya en dos archivos de configuración inmutables en formato JSON que despliega directamente el administrador principal del cliente.

La primera pieza es la definición de registro. Este documento reside en la cuenta del cliente y detalla explícitamente qué organización externa es de confianza y qué roles integrados se le conceden. La segunda pieza es la asignación de registro, que actúa como la dirección y apunta esa definición a una suscripción o grupo de recursos concreto.

Como estos componentes residen en el inquilino del cliente, este mantiene el control absoluto. Si un contrato termina, el cliente puede eliminar la asignación de registro, cerrando la puerta al instante sin necesitar la cooperación del proveedor de servicios.

Aplicar el mínimo privilegio en entornos multiinquilino

Un principio básico de la seguridad moderna en la nube es el de mínimo privilegio: dar a usuarios y sistemas solo los permisos mínimos necesarios para realizar sus tareas. Azure Lighthouse facilita aplicar este principio al asignar los permisos a grupos de seguridad, entidades de servicio y cuentas de automatización, en lugar de a usuarios individuales.

Por ejemplo, un proveedor de servicios gestionados podría estructurar el acceso de su equipo en niveles diferenciados:

• Equipo de soporte: se le asigna el rol Lector para revisar el estado de las máquinas virtuales y los registros de diagnóstico sin realizar cambios.
• Ingenieros de migración: se les asigna el rol Colaborador en grupos de recursos específicos para implementar cargas de trabajo y aplicar actualizaciones.
• Scripts de automatización: se les asignan cuentas de servicio personalizadas y con alcance limitado para ejecutar copias de seguridad nocturnas y recopilar telemetría.

Este enfoque granular garantiza que un error humano o unas credenciales comprometidas en el lado del proveedor no puedan extenderse y causar daños catastróficos en todos los entornos de clientes gestionados.

Limitaciones de los roles integrados como barreras de seguridad

Para proteger a las organizaciones de la sobreasignación de permisos, Azure Lighthouse aplica barreras estrictas sobre lo que se puede delegar y lo que no. Lo más destacable es que el rol Propietario de nivel superior no es compatible con ninguna delegación de Lighthouse. Un proveedor de servicios nunca puede recibir la capacidad de asignar permisos a otros ni de asumir la propiedad total de la suscripción del cliente.

Además, los roles que conceden acceso a planos de datos, como leer archivos dentro de contenedores de Azure Blob Storage o consultar registros de bases de datos, no se pueden delegar a través de Lighthouse. Lighthouse gestiona los planos de control de la infraestructura, de modo que la supervisión administrativa nunca cruza la frontera hacia infracciones de privacidad de datos.

Registros de auditoría y seguimiento de cumplimiento

Los responsables de cumplimiento normativo suelen ponerse nerviosos ante la idea de que proveedores externos accedan a la infraestructura crítica de la nube empresarial. Azure Lighthouse reduce esta preocupación al mantener, del lado del cliente, un registro meticuloso e imposible de alterar.

Cada acción realizada por un usuario del proveedor, ya sea reiniciar una máquina virtual, modificar una regla de firewall o actualizar la configuración de red, se escribe directamente en el Azure Activity Log del cliente. Como estos registros residen en el inquilino del cliente, el proveedor externo no puede modificarlos ni eliminarlos. Los administradores de TI pueden realizar auditorías periódicas para responder a preguntas críticas de seguridad: ¿quién accedió a este recurso?, ¿cuándo se modificó?, ¿qué comando exacto se ejecutó?

Además, las empresas pueden combinar Azure Lighthouse con Privileged Identity Management (PIM) para exigir una elevación just-in-time. En lugar de mantener permisos de colaborador permanentes, los ingenieros del proveedor pueden solicitar acceso solo cuando ocurre un incidente, con las aprobaciones registradas y los límites de tiempo aplicados automáticamente.

Conclusión

Azure Lighthouse resuelve la tensión permanente entre una seguridad robusta en la nube y una gestión multiinquilino eficiente. Al sustituir el intercambio de contraseñas por una gestión de recursos delegada, verificada criptográficamente y controlada por el cliente, los responsables de TI pueden escalar sus operaciones sin comprometer su postura de seguridad. Para conocer los conceptos fundamentales detrás de esta arquitectura, escucha el episodio completo del podcast M365 FM, con una explicación sin jerga de la gestión moderna en la nube.

Preguntas frecuentes

¿Puede un proveedor de Azure Lighthouse ver las contraseñas de mi organización?

No. Azure Lighthouse nunca expone, transfiere ni comparte contraseñas ni credenciales de usuario entre inquilinos. Los proveedores se autentican con sus propios sistemas de identidad empresarial mientras operan sobre tus recursos a través de proyecciones lógicas.

¿Qué ocurre con el acceso de Azure Lighthouse si un proveedor sufre una brecha de seguridad?

Como el acceso está estrictamente limitado a los roles integrados y a los recursos específicos definidos en la asignación de registro, y excluye el rol Propietario, el radio de impacto queda muy contenido. Además, el cliente puede revocar el acceso al instante eliminando la asignación de registro desde su propio portal.

¿Admite Azure Lighthouse roles RBAC personalizados?

No. Azure Lighthouse solo admite los roles integrados de Azure proporcionados por Microsoft. Los roles personalizados creados en el inquilino del proveedor o del cliente no se pueden usar en las definiciones de registro.

¿Quién tiene la autoridad para configurar Azure Lighthouse en el inquilino de un cliente?

Solo un usuario con acceso de alto privilegio, concretamente una cuenta con permisos para asignar roles a nivel de suscripción o de grupo de recursos, como User Access Administrator u Owner, puede implementar la plantilla de registro y establecer la conexión.