Entra ID : Politique Acces Conditionnel Invites Parametres Collaboration Externe — les Six Réglages par Défaut qui Jouent Contre Vous

Votre politique d'accès conditionnel invités et vos paramètres de collaboration externe Entra ID sont en réalité deux surfaces de contrôle distinctes que la plupart des tenants configurent une seule fois, lors de la mise en place initiale, et ne revisitent jamais. L'accès conditionnel détermine si un invité déjà connecté doit passer par le MFA, un appareil conforme, ou une méthode d'authentification plus forte. Les paramètres de collaboration externe déterminent qui est autorisé à devenir invité en premier lieu, ce qu'un invité peut voir une fois entré, et combien de temps ce compte invité est autorisé à exister. Un tenant peut avoir une excellente couverture MFA pour ses employés tout en laissant chacun de ces réglages par défaut spécifiques aux invités exactement là où Microsoft les livre — ce qui, pour plusieurs d'entre eux, est l'option la plus permissive.

Cet article passe en revue six failles précises dans cette surface de contrôle des invités, chacune rattachée à un défaut ou un mécanisme documenté par Microsoft : aucune politique d'accès conditionnel n'évalue réellement les connexions des invités, les invités peuvent inviter d'autres invités, les invités peuvent parcourir l'annuaire, les comptes invités n'expirent jamais, personne ne remarque un invité qui ne s'est jamais connecté, et les invités peuvent atteindre des applications d'entreprise qui ne leur ont jamais été attribuées. Aucune de ces failles ne nécessite qu'un attaquant exploite une vulnérabilité — elles nécessitent seulement qu'un admin ait accepté la configuration prête à l'emploi du tenant. Pour la vue d'ensemble de l'audit complet d'un tenant, voir Comment auditer la sécurité Microsoft Entra ID (Azure AD) : guide pratique.

Politique d'Accès Conditionnel Invités et Paramètres de Collaboration Externe Entra ID, Définition

L'accès invité dans Entra ID commence par une invitation — la collaboration B2B crée un objet utilisateur avec UserType défini sur Guest dans votre annuaire, adossé aux identifiants du tenant d'origine de l'invité ou de son fournisseur d'identité. À partir de là, deux groupes de paramètres indépendants gouvernent ce que l'invité peut faire.

External Collaboration Settings, sous Entra ID > External Identities, contrôlent les autorisations d'invitation des invités, la visibilité de l'annuaire pour les invités, l'inscription en libre-service, et les listes d'autorisation/blocage de domaines. L'accès conditionnel (Conditional Access) est un moteur de politiques distinct qui évalue chaque connexion, y compris celles des invités, selon des règles d'attribution pouvant cibler des types spécifiques d'invités et d'utilisateurs externes — utilisateurs invités de collaboration B2B, utilisateurs membres de collaboration B2B, utilisateurs de connexion directe B2B, invités locaux, utilisateurs de fournisseurs de services, et autres utilisateurs externes — chacun pouvant être inclus ou exclu indépendamment, pour un seul tenant ou tous les tenants.

Ces deux systèmes ne communiquent pas entre eux. Un invité peut être invité sous les paramètres de collaboration les plus permissifs et se voir tout de même bloqué par une politique d'accès conditionnel stricte, ou être invité sous des paramètres de collaboration stricts et traverser sans encombre une politique d'accès conditionnel qui n'évalue jamais les invités. Examiner l'un sans l'autre ne donne que la moitié du tableau — voir Sécurité des comptes invités Azure : la surface d'attaque oubliée de votre tenant pour le modèle d'exposition des invités plus large dans lequel s'inscrivent les six failles de cet article.

Comment les Invités Échappent à la Couverture de l'Accès Conditionnel

GUEST_NO_CA_POLICY [HIGH] se déclenche lorsqu'aucune politique d'accès conditionnel activée n'inclut explicitement un type d'utilisateur invité ou externe. Le contrôle lit l'attribution « utilisateurs inclus » de chaque politique activée, donc une base « Tous les utilisateurs » ne compte pas comme couverture des invités — c'est exactement la distinction sur laquelle repose le reste de cette section.

La documentation Microsoft elle-même indique que l'option d'attribution Tous les utilisateurs (All users) dans l'accès conditionnel inclut « tous les utilisateurs de l'annuaire, y compris les invités B2B » — donc en théorie, une seule politique MFA de base ciblant Tous les utilisateurs couvre déjà tous les invités. En pratique, ce même corpus documentaire explique trois façons dont cette couverture disparaît silencieusement.

Les Exclusions l'Emportent sur les Inclusions, Sans Condition

Microsoft l'indique sans détour : « Lorsqu'une organisation inclut et exclut à la fois un utilisateur ou un groupe, cet utilisateur ou ce groupe est exclu de la politique. L'action d'exclusion l'emporte sur l'action d'inclusion dans une politique. » Si un groupe d'exclusion contenant des invités se retrouve attaché à une politique — pour n'importe quelle raison, à n'importe quel moment — cette politique cesse de les protéger, silencieusement, sans aucun avertissement dans l'admin center. Une politique qui affiche toujours « On » dans l'admin center tout en excluant discrètement votre population d'invités ressemble, à première vue, aux politiques en mode rapport seul traitées dans Accès conditionnel mode rapport seul, exclusions obsolètes : ce que « appliqué » veut vraiment dire — les deux cas laissent au tenant un faux sentiment de couverture appliquée.

Les Politiques de Risque Utilisateur ne Peuvent pas être Résolues pour les Utilisateurs Externes, donc Microsoft Recommande de Construire une Exclusion

Le risque utilisateur nécessite une réinitialisation de mot de passe que le tenant de ressources ne peut pas effectuer sur une identité externe, donc le correctif documenté par Microsoft est : « Vous pouvez empêcher les politiques basées sur le risque d'affecter les utilisateurs externes en créant un groupe dans Microsoft Entra ID qui contient tous les utilisateurs externes de votre organisation. Ajoutez ensuite ce groupe en exclusion de vos politiques d'accès conditionnel basées sur le risque utilisateur et le risque de connexion. » Notez jusqu'où va cette recommandation : seule la politique de risque utilisateur est irrésolvable pour une identité externe — Microsoft précise tout aussi explicitement que « La politique de risque de connexion s'applique si l'utilisateur invité externe satisfait le contrôle d'octroi. » Suivre cette consigne à la lettre fait donc disparaître une couverture de risque de connexion qui fonctionnait, en même temps que la couverture de risque utilisateur cassée. Ce groupe « tous les utilisateurs externes », une fois créé pour une raison légitime, devient le levier le plus facile à réutiliser la prochaine fois qu'une connexion invité casse quelque chose — et le réutiliser contre la base MFA ou de conformité des appareils (pas seulement la politique de risque pour laquelle il a été créé) est ainsi qu'un tenant se retrouve avec zéro politique évaluant réellement les connexions des invités, alors même que « Tous les utilisateurs » les inclut techniquement.

Cibler des Rôles ou des Groupes plutôt que Tous les Utilisateurs

Cibler une politique sur des rôles d'annuaire ou des groupes spécifiques plutôt que sur Tous les utilisateurs exclut structurellement les invités dès lors que ces rôles ou groupes sont peuplés à partir de données RH internes ou de données de rôle que les objets invités ne portent pas.

Pour d'autres modes de défaillance de couverture de base qui ne sont pas spécifiques aux invités, voir Lacunes de Couverture Politique de Base Accès Conditionnel Entra ID : Aucune Politique pour les Admins, Tous les Utilisateurs ou Toutes les Applications et la revue plus large des exclusions et du ciblage dans Failles acces conditionnel Entra ID : quelles mauvaises configurations laissent une vraie exposition.

Les Paramètres de Collaboration Externe Livrés Grands Ouverts

Deux des six failles se situent entièrement dans les paramètres de collaboration externe, et toutes deux ont par défaut l'option la plus permissive d'une échelle à quatre ou trois choix.

GUEST_TO_GUEST_INVITE — les Invités Peuvent Inviter des Invités par Défaut

Les paramètres d'invitation des invités comptent quatre options, de « Anyone in the organization can invite guest users including guests and non-admins (most inclusive) » jusqu'à « No one in the organization can invite guest users including admins (most restrictive) ». La documentation Microsoft précise clairement sur laquelle un tenant démarre : « Par défaut, tous les utilisateurs de votre organisation, y compris les utilisateurs invités de collaboration B2B, peuvent inviter des utilisateurs externes à la collaboration B2B. » C'est l'option la plus inclusive de la liste. À moins qu'un admin ne l'ait restreinte manuellement, chaque invité que vous avez jamais invité a toujours disposé d'une autorisation permanente pour inviter d'autres invités dans votre tenant — sans approbation, sans notification, sans aucune trace au-delà de l'entrée du journal d'audit pour l'invitation elle-même. Durcissement du Tenant Azure : Corriger les Configs à Risque traite ce point aux côtés des autres réglages de collaboration par défaut que les tenants laissent intacts.

GUEST_DIRECTORY_VISIBILITY — le Défaut n'est pas l'Option Restrictive

L'accès des utilisateurs invités compte trois niveaux : même accès que les membres, accès limité, ou restreint à leur seul profil. Microsoft indique l'option intermédiaire comme valeur par défaut : « Guest users have limited access to properties and memberships of directory objects: (Default) This setting blocks guests from certain directory tasks, like enumerating users, groups, or other directory resources. Guests can see membership of all non-hidden groups. » Le comportement prêt à l'emploi permet à n'importe quel invité d'énumérer l'appartenance de tous les groupes non masqués de votre annuaire — y compris, si vous ne l'avez pas verrouillé séparément, les groupes attribuables à un rôle ou à appartenance privilégiée ; voir Groupes Privilégiés Imbriqués Entra ID, Groupes Attribuables à un Rôle et Invités dans les Groupes de Sécurité pour ce qu'un invité peut apprendre de cette seule visibilité.

Les deux paramètres vivent sur la même page de l'admin center (External Identities > External collaboration settings). Microsoft documente un délai de propagation spécifique au niveau d'accès des invités : après l'enregistrement du paramètre restreint, « The changes can take up to 15 minutes to take effect for guest users. »

Les Invités que Personne ne Gouverne

GUEST_NO_EXPIRATION_POLICY — un Invité Directement Invité n'a Aucune Expiration Attachée

Un invité invité directement par e-mail, en dehors de la gestion des droits d'utilisation (entitlement management), est ce que la terminologie Microsoft elle-même appelle non gouverné (ungoverned). La documentation Microsoft sur la gestion des droits d'utilisation trace la ligne avec précision : les invités qui demandent l'accès via un package d'accès peuvent être convertis en gouvernés (governed), ce qui signifie que « leur compte sera supprimé ou désactivé un nombre de jours spécifié après l'expiration de leur dernière attribution de package d'accès. » Mais « les utilisateurs invités qui existaient déjà dans votre tenant du fait d'avoir été invités sont non gouvernés », et une fois qu'un invité non gouverné perd sa dernière attribution de package d'accès, « ils resteront dans le tenant indéfiniment. » Un invité directement invité qui n'a jamais été rattaché à un package d'accès n'a absolument aucun mécanisme d'expiration attaché — ni un long délai par défaut, ni un court, aucun. Il persiste jusqu'à ce qu'un humain le remarque et le supprime manuellement, ou jusqu'à ce qu'un admin construise rétroactivement un processus de cycle de vie pour l'attraper.

GUEST_NEVER_SIGNED_IN — Invisible à une Revue d'Accès Standard jusqu'à ce qu'il Franchisse la Fenêtre d'Inactivité

Le rapport des invités inactifs d'Entra ID (ID Governance > Dashboard > Guest access governance) est l'outil conçu pour attraper ce cas, et il traite les invités jamais connectés comme leur propre catégorie : le rapport sépare explicitement « les invités qui ne se sont jamais connectés ou se sont connectés au moins une fois » (guests who have never signed in or signed in at least once), et pour le groupe jamais connecté, « les jours d'inactivité sont calculés à partir de la date de création » plutôt que de la dernière connexion, puisqu'il n'y en a pas. Le seuil d'inactivité par défaut est de 90 jours. Deux pièges comptent en pratique : ce rapport nécessite une licence Entra ID Governance ou Entra Suite, donc les tenants sans cette licence ne peuvent pas l'ouvrir du tout, et les revues d'accès construites pour supprimer les invités inactifs ignorent délibérément tout invité créé plus récemment que la fenêtre d'inactivité configurée — « this ensures that guests can sign in once before being removed » — donc un invité récent, jamais connecté, est invisible au nettoyage pendant toute la durée de cette fenêtre.

L'Accès aux Applications que les Invités n'ont Jamais Obtenu par Attribution

GUEST_APP_ACCESS_UNRESTRICTED [MEDIUM] — Microsoft indique le défaut sans détour, dans ses recommandations sur la restriction d'une application à un ensemble d'utilisateurs : « Applications registered in a Microsoft Entra tenant are, by default, available to all users of the tenant who authenticate successfully. » Le contrôle qui change cela est Require user assignment (exiger l'attribution utilisateur), et il est opt-in par application, pas activé par défaut. Une fois qu'un invité a été invité — pour un projet, un document partagé, une réunion — il est « a user of the tenant » pour toute autre application n'ayant pas activé l'attribution, que cela ait été voulu ou non.

Pourquoi cette Faille Survit à une Revue du Portail

Cette faille est facile à manquer lors d'une revue du portail à cause de la façon dont elle échoue : « When user assignment isn't required, unassigned users don't see the app on their My Apps, but they can still sign in to the application itself (also known as SP-initiated sign-on) or they can use the User Access URL. » Une application qui semble verrouillée — parce qu'aucun invité n'apparaît dans sa liste d'utilisateurs attribués, et qu'aucun invité ne la voit sur sa page My Apps — peut rester atteignable par tout invité disposant du lien de connexion direct, qui est souvent simplement l'URL de connexion normale de l'application. Le statut d'attribution et la visibilité ne sont pas la même chose, et seule l'attribution contrôle réellement l'accès.

Les invités disposant de rôles d'annuaire élevés aggravent cette faille précise ; voir Rôle Admin Invité Entra Confiance B2B Inter-Tenant : Comment un Compte Externe Atteint Administrateur Général pour ce qui se passe quand un invité sous-attribué se révèle aussi détenir des autorisations administratives.

Détection

Aucune de ces six failles n'apparaît comme une signature d'attaque — ce sont des états de configuration que vous devez interroger directement.

Cibler une Revue sur votre Population d'Invités

Pour cibler une revue d'accès sur votre seule population externe, la règle de groupe dynamique donnée par Microsoft en exemple est :

(user.userType -eq "Guest") and (user.mail -contains "@contoso.com") and (user.accountEnabled -eq true)

Remplacez le filtre de domaine par le vôtre, ou supprimez-le pour capturer tous les types d'invités.

Remédiation

1. Restreindre les Invitations d'Invités

Dans External collaboration settings, sortez de l'option par défaut « Anyone... including guests ». Si une poignée de personnes a réellement besoin de droits d'invitation sans un rôle admin complet, attribuez-leur le rôle Guest Inviter plutôt que de laisser les invitations ouvertes à tout le monde :

Import-Module Microsoft.Graph.Identity.DirectoryManagement

$roleName = "Guest Inviter"
$role = Get-MgDirectoryRole | where {$_.DisplayName -eq $roleName}
$userId = "<user object ID or UPN>"

$DirObject = @{
  "@odata.id" = "https://graph.microsoft.com/v1.0/directoryObjects/$userId"
  }

New-MgDirectoryRoleMemberByRef -DirectoryRoleId $role.Id -BodyParameter $DirObject

Un piège avant de l'exécuter : Get-MgDirectoryRole « ne retourne que les rôles qui ont été activés » (only returns roles that have been activated), et « tous les rôles intégrés ne sont pas activés initialement » (not all built-in roles are initially activated). Dans un tenant où Guest Inviter n'a jamais été attribué via l'admin center, $role revient vide et la dernière ligne échoue. Attribuez le rôle une fois dans le portail — ce qui l'active implicitement — ou activez-le d'abord avec l'API Activate directoryRole.

2. Resserrer la Visibilité de l'Annuaire pour les Invités

Passez à « restricted to properties and memberships of their own directory objects » à moins qu'un scénario de collaboration précis n'exige réellement que les invités puissent parcourir l'appartenance aux groupes.

3. Donner aux Invités une Politique d'Accès Conditionnel Dédiée et Activée

Ciblez explicitement « Guest or external users » (tous les sous-types que vous utilisez), en exigeant au minimum le MFA — ne vous reposez pas uniquement sur une base « Tous les utilisateurs ». Auditez ensuite la liste d'exclusion de chaque politique activée existante à la recherche d'un groupe « Guest or external users » ou « tous les utilisateurs externes », et confirmez que chacun est intentionnel et toujours nécessaire, et non une exclusion de politique de risque qui a fui dans votre base MFA.

4. Convertir les Invités en Packages d'Accès Gouvernés

Faites-le partout où un invité correspond à un projet ou un engagement défini, afin que la politique de cycle de vie attache réellement une expiration. Pour les invités qui ne passeront jamais par la gestion des droits d'utilisation, construisez une revue d'accès récurrente sur le groupe dynamique d'invités ci-dessus avec un seuil d'inactivité et une décision auto-appliquée « bloquer, puis supprimer ».

5. Activer le Rapport des Invités Inactifs

Cela nécessite une licence Entra ID Governance / Entra Suite. Passez en revue la catégorie jamais connecté selon un calendrier régulier — ces comptes sont invisibles à une revue d'accès standard tant qu'ils n'ont pas franchi votre fenêtre d'inactivité.

6. Exiger l'Attribution sur les Applications d'Entreprise

Réglez « Assignment required » sur Yes pour chaque application d'entreprise qui ne devrait pas être ouverte à tout le tenant, puis attribuez explicitement les utilisateurs ou groupes — pas les invités par défaut — qui en ont besoin. Revérifiez les applications ajoutées en dehors de votre processus d'onboarding standard ; les applications SAML SSO, les applications Application Proxy utilisant la préauthentification Microsoft Entra, et les applications OAuth 2.0/OpenID Connect ayant reçu un consentement d'un utilisateur ou d'un admin supportent toutes ce contrôle.

Comment EtcSec Détecte Cela

EtcSec vérifie chaque audit Azure/Entra par rapport à ces six constats : GUEST_NO_CA_POLICY, GUEST_TO_GUEST_INVITE, GUEST_DIRECTORY_VISIBILITY, GUEST_NO_EXPIRATION_POLICY, GUEST_NEVER_SIGNED_IN, et GUEST_APP_ACCESS_UNRESTRICTED. Ils ne fonctionnent pas tous de la même façon, et cette différence compte au moment de décider ce que prouve un résultat propre.

Trois sont évalués par rapport à l'état réel de votre tenant, donc leur résultat change quand vous corrigez le paramètre sous-jacent. GUEST_NO_CA_POLICY lit l'attribution « utilisateurs inclus » de chaque politique d'accès conditionnel activée. GUEST_TO_GUEST_INVITE lit la politique d'invitation des invités du tenant. GUEST_NEVER_SIGNED_IN énumère les comptes invités sans aucune connexion interactive ni non interactive et en rapporte le nombre. Ce sont ces trois-là qui vous indiquent si le correctif du trimestre dernier est toujours en place après que le prochain admin a touché aux paramètres de collaboration externe ou à l'accès conditionnel.

Les trois autres — GUEST_DIRECTORY_VISIBILITY, GUEST_NO_EXPIRATION_POLICY, et GUEST_APP_ACCESS_UNRESTRICTED — sont soulevés comme avis au niveau du tenant sur chaque audit Azure plutôt que d'être activés/désactivés par un seul indicateur du tenant. Lisez-les comme une invitation permanente à revérifier ce contrôle dans le portail, pas comme la preuve qu'il est actuellement mal configuré.

Références Principales

• Configure external collaboration settings
• Conditional Access: Users, groups, agents, and workload identities
• Authentication and Conditional Access for B2B users
• Convert guest user lifecycle in entitlement management
• Monitor and clean up stale guest accounts
• Manage access to apps
• Restrict a Microsoft Entra app to a set of users
• Restrict guest user access permissions
• List directoryRoles (Microsoft Graph)
• Customize and filter activity logs in Microsoft Entra ID