Partager via

Locataires, utilisateurs et rôles dans les scénarios Azure Lighthouse

  • Article

Avant d’intégrer des clients pour Azure Lighthouse, il est important de comprendre comment les locataires, les utilisateurs et les rôles fonctionnent dans Microsoft Entra, ainsi que la façon dont ils peuvent être utilisés dans les scénarios Azure Lighthouse.

Un locataire est une instance dédiée et approuvée de Microsoft Entra ID. En général, chaque locataire représente une seule organisation. Azure Lighthouse permet d’opérer une projection logique des ressources d’un locataire sur un autre. Cela permet aux utilisateurs du locataire de gestion (appartenant par exemple à un fournisseur de services) d’accéder à des ressources déléguées dans le locataire d’un client, ou permet aux entreprises avec plusieurs locataires de centraliser leurs opérations de gestion.

Pour atteindre cette projection logique, un abonnement (ou un ou plusieurs groupes de ressources au sein d’un abonnement) dans le locataire client doit être intégré à Azure Lighthouse. Ce processus d’intégration peut être effectué par le biais de modèles Azure Resource Manager ou par la publication d’une offre publique ou privée sur la Place de marché Azure.

Avec chaque méthode d’intégration, vous devez définir des autorisations. Chaque autorisation comprend un principalId (un utilisateur, un groupe ou un principal du service Microsoft Entra dans le locataire de gestion) associé à un rôle intégré qui définit les autorisations spécifiques qui seront accordées pour les ressources déléguées.

Remarque

Sauf spécification explicite, les références à un « utilisateur » dans la documentation Azure Lighthouse peuvent s’appliquer à un utilisateur, à un groupe ou à un principal de service Microsoft Entra dans une autorisation.

Meilleures pratiques pour la définition des utilisateurs et des rôles

Lorsque vous créez vos autorisations, nous vous recommandons de suivre ces meilleures pratiques :

  • Dans la plupart des cas, vous affectez des autorisations à un groupe d’utilisateurs ou à un principal de service Microsoft Entra, plutôt qu’à une série de comptes d’utilisateur individuels. Cela vous permet d’ajouter ou de supprimer l’accès pour des utilisateurs individuels via votre locataire Microsoft Entra ID, sans devoir mettre à jour la délégation chaque fois que vos exigences d’accès individuel changent.
  • Suivez le principe des privilèges minimum. Pour réduire les risques d’erreurs accidentelles, les utilisateurs doivent disposer uniquement des autorisations nécessaires pour effectuer leur travail spécifique. Pour plus d’informations, consultez les Pratiques de sécurité recommandées.
  • Incluez une autorisation avec le rôle Supprimer l’attribution de l’inscription des services gérés afin de pouvoir supprimer l’accès à la délégation si nécessaire. Si ce rôle n’est pas attribué, l’accès aux ressources déléguées ne peut être supprimé que par un utilisateur dans le locataire du client.
  • Assurez-vous que tous les utilisateurs qui ont besoin d’afficher la page Mes clients dans le portail Azure possèdent le rôle de Lecteur (ou un autre rôle intégré qui inclut l’accès Lecteur).

Important

Pour que vous puissiez ajouter des autorisations pour un groupe Microsoft Entra, le Type de groupe doit être défini sur Sécurité. Cette option est sélectionnée lors de la création du groupe. Pour plus d’informations, consultez Créer un groupe de base et ajouter des membres avec Microsoft Entra ID.

Prise en charge des rôles pour Azure Lighthouse

Lorsque vous définissez une autorisation, chaque compte utilisateur doit recevoir un des rôles intégrés Azure. Les rôles personnalisés et les Rôles Administrateur classique de l’abonnement ne sont pas pris en charge.

Tous les rôles intégrés sont actuellement pris en charge par Azure Lighthouse, avec les exceptions suivantes :

  • Le rôle de propriétaire n’est pas pris en charge.

  • Le rôle Administrateur de l’accès utilisateur est pris en charge, mais uniquement pour les besoins limités d’affectation de rôles à une identité gérée dans le locataire client. Aucune autre autorisation généralement accordée par ce rôle ne s’applique. Si vous définissez un utilisateur avec ce rôle, vous devez également spécifier le ou les rôles que cet utilisateur peut affecter aux identités gérées.

  • Les rôles disposant d’une autorisation DataActions ne sont pas pris en charge.

  • Les rôles qui incluent l’une des actions suivantes ne sont pas pris en charge :

    • */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

Important

Quand vous attribuez des rôles, veillez à passer en revue les actions spécifiées pour chaque rôle. Même si les rôles avec DataActions autorisation ne sont pas pris en charge, il existe des cas où des actions incluses dans un rôle pris en charge peuvent autoriser l’accès aux données. Cela se produit généralement lorsque les données sont exposées à travers des clés d’accès, non accessibles via l’identité de l’utilisateur(-trice). Par exemple, le rôle Contributeur de machines virtuelles inclut l’action Microsoft.Storage/storageAccounts/listKeys/action. Celle-ci retourne des clés d’accès au compte de stockage qui peuvent être utilisées pour récupérer certaines données client.

Dans certains cas, un rôle précédemment pris en charge avec Azure Lighthouse peut devenir indisponible. Par exemple, si l’autorisation DataActions est ajoutée à un rôle qui ne disposait de cette autorisation précédemment, ce rôle ne peut plus être utilisé lors de l’intégration de nouvelles délégations. Les utilisateurs qui se sont déjà vus attribuer ce rôle pourront toujours utiliser des ressources déléguées précédemment, mais ils ne seront pas en mesure d’effectuer toute tâche nécessitant l’autorisation DataActions.

Dès qu'un nouveau rôle intégré applicable a été ajouté à Azure, il peut être attribué lors de l'intégration d'un client à l'aide des modèles Azure Resource Manager. Un certain temps peut s’écouler avant que le nouveau rôle ne soit disponible dans l’Espace partenaires lors de la publication d’une offre de services gérés. De même, si un rôle devient indisponible, vous pouvez toujours le voir dans l’Espace partenaires pendant un certain temps, mais vous ne pourrez pas publier de nouvelles offres à l’aide de tels rôles.

Transfert d’abonnements délégués entre locataires Microsoft Entra

Si un abonnement est transféré à un autre compte de locataire Microsoft Entra, la définition de l’inscription et les ressources d’attribution de l’inscription créées par le processus d’intégration d’Azure Lighthouse sont conservées. Cela signifie que l’accès accordé par Azure Lighthouse aux locataires gestionnaires reste en vigueur pour cet abonnement (ou pour les groupes de ressources délégués au sein de cet abonnement).

La seule exception est le transfert de l’abonnement à un locataire Microsoft Entra auquel il avait été délégué. Dans ce cas, les ressources de délégation pour ce locataire sont supprimées et l’accès accordé par l’intermédiaire d’Azure Lighthouse ne s’applique plus, puisque l’abonnement appartient désormais directement à ce locataire (au lieu d’être délégué par le biais d’Azure Lighthouse). Toutefois, si cet abonnement a également été délégué à d’autres locataires gestionnaires, ces derniers conserveront le même accès à l’abonnement.

Étapes suivantes