Quand « Tous les utilisateurs » inclut aussi tous les invités

Aperçu

Microsoft Entra ID facilite la collaboration avec des tiers. Fournisseurs, sous-traitants, partenaires, auditeurs et clients peuvent être invités dans un locataire en tant qu'utilisateurs invités, sans avoir besoin de comptes internes complets.

Lors de nos tests, nous avons découvert un chemin d'attaque par lequel un utilisateur disposant d'un compte invité pouvait voir le groupe hérité All Users d'un locataire et énumérer les autres utilisateurs de ce locataire, y compris les invités et les membres.

Les référentiels CIS Microsoft 365 Foundations actuels comprennent le contrôle 5.1.6.2, « Ensure that guest user access is restricted », mais les scénarios combinés décrits dans cet article méritent tout de même un examen et des correctifs explicites, surtout pour les entreprises dont les locataires plus anciens ont pu être créés à l'époque où le paramètre du groupe All Users existait.

Qu'est-ce qu'un compte invité?

Un compte invité externe est une identité extérieure à une organisation qui est invitée dans un locataire Microsoft Entra à des fins de collaboration.

Par exemple, un sous-traitant qui utilise nom@fournisseur.com peut être ajouté comme utilisateur invité au locataire d'un client. Il conserve son identité d'origine, mais reçoit un accès limité à des ressources précises comme Teams, SharePoint, des applications ou des groupes.

Dans Entra ID, ces comptes apparaissent souvent avec #EXT# dans le nom d'utilisateur et userType = Guest.

Selon la configuration du locataire, les comptes invités peuvent être en mesure de voir des groupes comprenant :

• des sous-traitants
• des comptes de fournisseurs
• des identités de partenaires
• des utilisateurs en contact avec la clientèle
• des comptes qui semblent privilégiés
• des comptes de service ou partagés
• des adresses courriel et des noms d'utilisateur principaux (UPN)
• parfois des titres, des services ou des noms d'entreprise

Qu'est-ce que le groupe All Users?

Le groupe All Users semble être un groupe fourre-tout hérité, créé par Microsoft pour simplifier l'intégration des premiers locataires. Il servait de vaste groupe d'annuaire regroupant tout le monde dans le locataire, ce qui facilitait l'attribution de ressources par défaut, d'espaces de collaboration ou d'accès lors de la configuration initiale de Microsoft 365.

Dans les locataires plus anciens, ce type de groupe peut subsister longtemps après que le processus de configuration d'origine ou le comportement du produit a changé.

Dans un locataire moderne, l'utilisation de groupes larges devrait être explicite. Les groupes devraient exister parce qu'ils servent un objectif actuel, et non parce qu'ils ont été hérités d'une ancienne configuration par défaut. L'ancien modèle All Users est particulièrement risqué, parce que le ciblage large de « tous les utilisateurs » relève aujourd'hui généralement de contrôles propres à chaque produit, comme l'accès conditionnel, Intune ou Purview, plutôt que d'un seul groupe d'annuaire hérité susceptible d'inclure des invités.

Dans le groupe All Users, l'utilisateur invité externe peut voir les comptes membres M365, les comptes invités externes et les propriétaires de groupes.

Quelles sont les conséquences?

Un compte invité compromis, ou même un compte de sous-traitant peu fiable, peut se servir de cette visibilité pour cartographier la surface de collaboration externe du locataire. Dans certains environnements, le graphe de collaboration devient lui-même un renseignement d'affaires sensible.

Si All Users est associé à SharePoint, à Teams, à des applications d'entreprise, à des licences ou à des packages d'accès, le problème passe d'une fuite d'information à un accès non voulu.

Un site SharePoint public par défaut attribué de façon large peut devenir un point de collecte pour des fichiers auxquels chaque identité incluse peut accéder. Ce type de surface de collaboration large peut aussi être utilisé de façon malveillante pour distribuer des logiciels malveillants.

Comment en est-on arrivé là?

Habituellement, il ne s'agit pas d'un seul mauvais paramètre. C'est un ensemble de paramètres qui ont mal tourné.

• Le locataire permet la collaboration avec des invités.
• Des utilisateurs invités sont invités ou autorisés à s'inscrire en libre-service au moyen d'une application ou d'un flux d'utilisateurs.
• Un groupe dynamique large existe, nommé All Users.
• La règle du groupe inclut les invités, volontairement ou par accident.
• L'accès des invités n'est pas réglé au niveau le plus restrictif.
• L'appartenance aux groupes n'est pas masquée.
• Les invités peuvent voir le groupe et énumérer ses membres et ses propriétaires.

Le niveau d'accès invité par défaut de Microsoft est « accès limité ». Malgré ce nom, Microsoft indique que ce réglage par défaut permet encore aux invités de voir l'appartenance à tous les groupes non masqués. L'option plus stricte empêche les invités de voir les autres utilisateurs et l'appartenance aux groupes.

Le problème se résume souvent à ceci : le locataire est configuré pour la collaboration, mais le modèle d'annuaire présume encore qu'une large visibilité des groupes est acceptable.

Que devrions-nous faire?

Les groupes dynamiques larges qui incluent des invités ne devraient pas exister, à moins d'une raison d'affaires claire et de contrôles compensatoires. La posture la plus solide consiste à masquer la visibilité des groupes partout où c'est possible et à régler l'accès des invités à l'option la plus restrictive.

Considérez l'accès invité restreint comme la deuxième couche de protection. Si vous ne pouvez pas masquer la visibilité des groupes en raison d'un processus d'affaires, l'accès invité restreint devient obligatoire.

D'abord, vérifiez ce qui est possible à partir d'un compte invité :

• Un invité peut-il voir Mes groupes?
• Un invité peut-il voir le groupe All Users?
• Un invité peut-il afficher la liste des membres de ce groupe?

Ensuite, déterminez ce qui devrait être permis :

Masquez la visibilité des groupes partout où c'est possible

Commencez par réduire la visibilité des groupes. Si les invités ne peuvent pas voir les groupes larges ni l'appartenance aux groupes, le graphe de collaboration devient beaucoup plus difficile à énumérer.

Réglez l'accès des invités à l'option la plus restrictive

L'accès des utilisateurs invités devrait être limité aux propriétés et aux appartenances de leurs propres objets d'annuaire. C'est la deuxième couche de protection, et elle devient obligatoire lorsque la visibilité des groupes ne peut pas être masquée.

Vérifiez les groupes de votre locataire

Tout groupe dynamique destiné uniquement aux employés devrait exclure les invités :

(user.objectId -ne null) -and (user.userType -eq "Member")

Examinez les groupes larges ou ambigus comme :

• All Users
• Everyone
• All Employees
• All Staff
• All Contractors
• Guests
• External Users

Pour chaque groupe, vérifiez si les utilisateurs, y compris les invités, peuvent voir les attributions du groupe. Chaque groupe large devrait avoir un responsable clairement désigné, un objectif actuel documenté et une raison explicite pour chaque attribution de ressource.

• Si un groupe All Users est présent et inutilisé, supprimez-le.

  Remarque : Ce groupe All Users n'est pas la même chose que le ciblage « All Users » dans l'accès conditionnel, Intune ou Purview. Ces produits utilisent des portées propres à chaque service pour les types d'objets; ce groupe hérité est un objet d'annuaire large.

• Si un groupe All Users est présent et utilisé, transférez les utilisateurs vers d'autres regroupements, puis supprimez le groupe All Users.

Examinez l'inscription libre-service des invités

Si des utilisateurs externes peuvent s'intégrer au moyen d'une application, assurez-vous que les comptes invités ainsi créés ne sont pas automatiquement placés dans des groupes larges ayant une visibilité sur le locataire.

Conclusion

La collaboration avec des invités n'est pas le problème. Le problème, c'est une visibilité des invités sans limites.

Un sous-traitant devrait pouvoir accéder au projet, à l'application ou à l'espace de travail auquel il a été invité. Il ne devrait pas hériter automatiquement d'une carte de l'annuaire du locataire recensant tous les autres sous-traitants et fournisseurs.

La solution n'a rien de compliqué :

• restreignez la visibilité des invités,
• retirez les invités des groupes internes larges,
• et supprimez les anciennes surfaces de collaboration qui n'ont plus de raison d'être.

Références

• MicrosoftRestrict guest user access permissions in Microsoft Entra ID
• MicrosoftDefault user permissions in Microsoft Entra ID
• MicrosoftManage rules for dynamic membership groups in Microsoft Entra ID
• MicrosoftAdd B2B guest sign-in with self-service sign-up user flows
• TenableCIS Microsoft 365 Foundations v6.0.1, Ensure that guest user access is restricted
• Trend MicroEnable All Users Group
• MicrosoftCreate a rule for all users
• Merill FernandoAzureAD Restricted Access - Guest Permission Level