Sécurité et autorisations d’Azure Lighthouse : gérer l’accès cloud multi-locataires en toute sécurité

By Mirko Peters · 2026-10-21

Découvrez le fonctionnement de la sécurité d’Azure Lighthouse, comment appliquer le moindre privilège à travers plusieurs locataires, et comment les clients conservent un contrôle total sur leur cloud.

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

La sécurité d’Azure Lighthouse repose sur les principes du moindre privilège, des projections logiques de ressources et des limites strictes contrôlées par le client. Elle permet aux fournisseurs de services gérés d’administrer des environnements cloud multi-locataires sans jamais détenir de mots de passe administrateur, en s’appuyant sur des rôles Azure intégrés et des pistes d’audit permanentes.

Points clés

• Les clients conservent une autorité absolue sur leurs locataires Azure en définissant des périmètres précis et des rôles intégrés.
• Les définitions et affectations d’inscription agissent comme une poignée de main permanente, vérifiée par Azure à chaque action.
• Le rôle Propriétaire complet et l’accès au plan de données ne sont absolument pas pris en charge dans les délégations Azure Lighthouse.
• Les fournisseurs opèrent via des projections logiques dans leur propre portail, sans partager les mots de passe ni les identifiants des utilisateurs.
• Les journaux d’activité enregistrent chaque modification apportée au locataire du client, offrant une piste d’audit transparente.

L’architecture de sécurité d’Azure Lighthouse

Gérer plusieurs environnements cloud exigeait traditionnellement de créer des comptes d’administrateur dédiés dans chaque locataire client. Cette méthode engendrait des risques de sécurité importants, des tableurs interminables de mots de passe temporaires et des identifiants oubliés persistant dans des systèmes externes. Azure Lighthouse change fondamentalement cette dynamique en introduisant une porte sécurisée, liée cryptographiquement, entre des environnements cloud distincts.

Plutôt que de fusionner des locataires ou de partager des identifiants, Lighthouse s’appuie sur une projection logique. Les ressources du client restent entièrement dans son propre environnement cloud : son locataire, son abonnement et ses groupes de ressources. Le fournisseur de services gérés consulte ces ressources par un accès sécurisé depuis son propre locataire de gestion. Chaque requête envoyée par le fournisseur passe par la couche de validation centrale d’Azure, qui vérifie en permanence les autorisations accordées avant d’autoriser l’exécution de toute commande.

La poignée de main en deux parties

La sécurité d’Azure Lighthouse ne repose pas sur une confiance aveugle : elle s’appuie sur deux fichiers de configuration JSON immuables, déployés directement par l’administrateur de premier niveau du client.

La première partie est la définition d’inscription. Ce document réside dans le compte du client et détaille explicitement l’organisation externe de confiance ainsi que les rôles intégrés précis qui lui sont accordés. La seconde partie est l’affectation d’inscription, qui joue le rôle d’adresse en pointant cette définition vers un abonnement ou un groupe de ressources spécifique.

Comme ces composants résident dans le locataire du client, celui-ci conserve un contrôle absolu. Si un contrat prend fin, le client peut supprimer l’affectation d’inscription, verrouillant instantanément la porte sans avoir besoin de la coopération du fournisseur de services.

Mettre en œuvre le principe du moindre privilège dans des environnements multi-locataires

Un principe fondamental de la sécurité cloud moderne est celui du moindre privilège, qui consiste à n'accorder aux utilisateurs et aux systèmes que le minimum d'autorisations nécessaires à leurs tâches. Azure Lighthouse facilite l'application de ce principe, car il associe les autorisations à des groupes de sécurité, à des principaux de service et à des comptes d'automatisation plutôt qu'à des utilisateurs individuels.

Par exemple, un fournisseur de services gérés peut structurer l'accès de son équipe en plusieurs niveaux distincts :

• Équipe support : se voit attribuer le rôle Lecteur pour inspecter l'état des machines virtuelles et les journaux de diagnostic, sans pouvoir effectuer de modifications.
• Ingénieurs de migration : se voient attribuer le rôle Contributeur sur des groupes de ressources spécifiques pour déployer des charges de travail et appliquer des mises à jour.
• Scripts d'automatisation : se voient attribuer des comptes de service personnalisés et limités à un périmètre précis pour exécuter les sauvegardes nocturnes et la collecte de télémétrie.

Cette approche granulaire garantit qu'une erreur humaine ou des identifiants compromis au niveau du fournisseur ne peuvent pas entraîner de dommages catastrophiques dans l'ensemble des environnements clients gérés.

Les limites des rôles intégrés comme garde-fous de sécurité

Pour protéger les organisations contre une attribution excessive d'autorisations, Azure Lighthouse applique des garde-fous stricts sur ce qui peut être délégué et sur ce qui ne le peut pas. Plus particulièrement, le rôle de niveau supérieur Propriétaire n'est absolument pas pris en charge dans une délégation Lighthouse. Un fournisseur ne peut jamais recevoir la capacité d'attribuer des autorisations à d'autres personnes ni de prendre la propriété complète de l'abonnement du client.

De plus, les rôles qui donnent accès aux plans de données, comme la lecture de fichiers dans des conteneurs Azure Blob Storage ou la consultation d'enregistrements de bases de données, ne peuvent pas être délégués via Lighthouse. Lighthouse gère les plans de contrôle de l'infrastructure, afin que la supervision administrative ne franchisse jamais la frontière des atteintes à la confidentialité des données.

Pistes d'audit et suivi de la conformité

Les responsables de la conformité s'inquiètent souvent à l'idée que des prestataires externes accèdent à l'infrastructure cloud essentielle de l'entreprise. Azure Lighthouse apaise cette inquiétude en tenant, du côté du client, une trace écrite minutieuse et infalsifiable.

Chaque action effectuée par un utilisateur du fournisseur, qu'il s'agisse de redémarrer une machine virtuelle, de modifier une règle de pare-feu ou de mettre à jour les paramètres réseau, est consignée directement dans le journal d'activité Azure du client. Comme ces journaux se trouvent dans le locataire du client, le fournisseur externe ne peut ni les modifier ni les supprimer. Les administrateurs informatiques peuvent effectuer des audits réguliers pour répondre à des questions essentielles en matière de sécurité : qui a accédé à cette ressource ? Quand a-t-elle été modifiée ? Quelle commande exacte a été exécutée ?

Par ailleurs, les entreprises peuvent associer Azure Lighthouse à Privileged Identity Management (PIM) pour exiger une élévation de privilèges juste à temps. Plutôt que de détenir en permanence des droits de contributeur, les ingénieurs du fournisseur peuvent demander un accès uniquement lorsqu'un incident survient, les approbations étant journalisées et les limites de durée appliquées automatiquement.

Conclusion

Azure Lighthouse résout la tension permanente entre une sécurité cloud robuste et une gestion multilocataire efficace. En remplaçant le partage de mots de passe par une gestion déléguée des ressources, vérifiée cryptographiquement et contrôlée par le client, les responsables informatiques peuvent faire évoluer leurs opérations sans compromettre leur posture de sécurité. Pour explorer les concepts fondamentaux de cette architecture, je vous invite à écouter l'épisode complet du M365 FM Podcast, qui présente de façon accessible la gestion cloud moderne.

Questions fréquentes

Un fournisseur Azure Lighthouse peut-il consulter les mots de passe de mon organisation ?

Non. Azure Lighthouse n'expose, ne transfère et ne partage jamais de mots de passe ni d'identifiants d'utilisateurs entre locataires. Les fournisseurs s'authentifient à l'aide de leurs propres systèmes d'identité d'entreprise tout en opérant sur vos ressources au travers de projections logiques.

Que se passe-t-il si un fournisseur subit une violation de sécurité ?

Comme l'accès est strictement limité aux rôles intégrés et aux ressources définis dans l'affectation d'inscription, et exclut le rôle Propriétaire, le rayon d'impact reste étroitement contenu. De plus, le client peut révoquer immédiatement l'accès en supprimant l'affectation d'inscription depuis son propre portail.

Azure Lighthouse prend-il en charge les rôles RBAC personnalisés ?

Non. Azure Lighthouse ne prend en charge que les rôles Azure intégrés fournis par Microsoft. Les rôles personnalisés créés dans le locataire du fournisseur ou du client ne peuvent pas être utilisés dans les définitions d'inscription.

Qui est habilité à configurer Azure Lighthouse dans le locataire d'un client ?

Seul un utilisateur disposant d’un accès à privilèges élevés peut déployer le modèle d’enregistrement et établir la connexion, en l’occurrence un compte doté d’autorisations lui permettant d’attribuer des rôles au niveau de l’abonnement ou du groupe de ressources, comme User Access Administrator ou Owner.