Sécurité des comptes invités Azure : la surface d'attaque oubliée de votre tenant

Que sont les comptes invités Azure ?

Les comptes invités (guest accounts) Azure Entra ID (collaboration B2B) permettent à des utilisateurs externes - partenaires, prestataires, fournisseurs, auditeurs - d'accéder à vos ressources Microsoft 365 sans disposer d'un compte dans votre tenant. Les comptes invités s'authentifient via leur tenant d'origine, mais l'accès à vos ressources leur est accordé selon les autorisations que vous leur attribuez.

Les comptes invités sont une fonctionnalité légitime et largement utilisée. Le problème, c'est la gouvernance. Les organisations invitent des utilisateurs externes pour des projets de courte durée et ne les suppriment jamais. Les paramètres d'invitation restent à leur valeur par défaut, ce qui permet à tout utilisateur du tenant - y compris les invités déjà présents - d'inviter n'importe qui. Le MFA n'est pas exigé pour les invités. Il en résulte une population croissante d'identités externes avec des niveaux d'accès variables - beaucoup oubliées, certaines appartenant à des personnes ayant quitté leur organisation depuis des années.

Comment ça fonctionne

Les comptes invités diffèrent des comptes membres sur deux points essentiels :

1. L'authentification a lieu dans le tenant d'origine de l'invité - vous ne contrôlez ni ses stratégies MFA, ni ses exigences de mot de passe, ni sa posture de sécurité. Vous pouvez néanmoins lui imposer votre propre MFA : par défaut, les paramètres d'accès inter-tenants ne font pas confiance aux revendications MFA ou d'appareil provenant d'autres organisations Microsoft Entra, donc votre stratégie d'accès conditionnel continue de s'appliquer. Ce que vous ne pouvez pas faire, c'est hériter d'une quelconque garantie sur la façon dont son tenant d'origine l'a authentifié.
2. La gouvernance du cycle de vie est optionnelle (opt-in) - Entra ID dispose bien d'un mécanisme natif qui supprime automatiquement les invités (les révisions d'accès avec Appliquer automatiquement les résultats à la ressource, et Bloquer la connexion pendant 30 jours puis supprimer l'utilisateur du tenant comme action sur les invités refusés), mais il est désactivé par défaut et nécessite un abonnement Microsoft Entra ID Governance ou Entra ID P2. Un tenant qui ne l'active jamais n'a aucun offboarding automatique.

Les droits d'invitation sont ouverts par défaut. Le comportement documenté par Microsoft est que « tous les utilisateurs de votre organisation, y compris les utilisateurs invités en collaboration B2B, peuvent inviter des utilisateurs externes à la collaboration B2B » - ce n'est donc pas réservé à vos membres : un invité déjà présent peut en inviter un autre, sans aucun contrôle ni approbation de l'IT. Dans les organisations pratiquant activement la collaboration B2B, il est courant de trouver des centaines de comptes invités, dont une part significative n'a montré aucune activité depuis un an.

La chaîne d'attaque

Étape 1 - Énumérer les comptes invités

# signInActivity nécessite AuditLog.Read.All ET une licence Entra ID P1/P2.
# Directory.Read.All seul renvoie les invités mais pas leurs données de connexion.
Connect-MgGraph -Scopes "User.Read.All","AuditLog.Read.All"

# Lister tous les comptes invités avec leur date de dernière connexion.
# -All est obligatoire : sans lui, seule la première page est renvoyée (500 max
# lorsque signInActivity est sélectionné) et le reste des invités est omis silencieusement.
Get-MgUser -All -Filter "userType eq 'Guest'" `
  -Property "displayName,userPrincipalName,signInActivity,createdDateTime" |
  Select-Object DisplayName, UserPrincipalName, CreatedDateTime,
    @{N="LastSignIn";E={$_.SignInActivity.LastSignInDateTime}} |
  Sort-Object LastSignIn

# Trouver les invités inactifs depuis 180 jours ou plus.
# signInActivity n'est PAS renvoyé par défaut : si vous omettez -Property, chaque
# invité semble ne jamais s'être connecté, et ce filtre les sélectionne tous.
$cutoff = (Get-Date).AddDays(-180)
Get-MgUser -All -Filter "userType eq 'Guest'" `
  -Property "displayName,userPrincipalName,signInActivity" |
  Where-Object { $null -eq $_.SignInActivity.LastSignInDateTime -or
    $_.SignInActivity.LastSignInDateTime -lt $cutoff }

Étape 2 - Exploiter des paramètres d'invitation non restreints

Si les droits d'invitation des invités ne sont pas restreints, tout compte membre compromis peut inviter des identités externes contrôlées par l'attaquant pour obtenir un accès persistant :

# Utilisation d'un compte membre compromis pour inviter une identité externe contrôlée par l'attaquant
# Permission déléguée à moindre privilège : User.Invite.All
New-MgInvitation `
  -InvitedUserEmailAddress "[email protected]" `
  -InviteRedirectUrl "https://myapps.microsoft.com" `
  -SendInvitationMessage $false

Étape 3 - Accéder aux ressources sans MFA

Si les invités ne sont pas soumis à une stratégie d'accès conditionnel exigeant le MFA, un compte invité compromis donne un accès direct à toutes les ressources partagées sans vérification supplémentaire - fichiers SharePoint, canaux Teams, contenu OneDrive. Le pire scénario est celui d'un invité qui détient également un rôle d'annuaire Entra, où une confiance B2B inter-tenants grande ouverte devient un chemin vers le rôle d'administrateur général - voir Rôle d'administrateur invité Entra et confiance B2B inter-tenants : comment les utilisateurs externes atteignent le rôle d'administrateur général.

Étape 4 - Mouvement latéral via les ressources partagées

Les comptes invités ont souvent accès à des contenus partagés sensibles, directement exfiltrables. Documents de projet, contrats, données clients - tout est visible pour les invités disposant des autorisations adéquates. L'appartenance à un groupe est la voie la plus tranchante : un invité ajouté à un groupe privilégié imbriqué ou attribuable à un rôle hérite de bien plus qu'un simple accès aux fichiers, comme détaillé dans Groupes privilégiés imbriqués Entra ID, groupes attribuables à un rôle et invités dans les groupes de sécurité.

Étape 5 - Persister via des comptes oubliés

Les comptes invités inactifs persistent indéfiniment. Un attaquant qui compromet un compte invité oublié dispose d'un accès persistant et peu visible, rarement révisé ou révoqué.

Détection

Événements du journal d'audit Entra ID

Voici les noms d'activité tels qu'ils apparaissent dans le journal d'audit Microsoft Entra. Les connexions des invités ne sont pas des événements d'audit - elles se trouvent dans les journaux de connexion, une source distincte.

Requêtes de détection SIEM (Elastic)

Les noms de champs ci-dessous suivent l'intégration Elastic Azure Logs.

Invitations d'invités (KQL) :

azure.auditlogs.operation_name: "Invite external user"

L'événement d'audit enregistre qui a invité (initiated_by), pas les rôles d'annuaire de cette personne - l'intégration expose initiated_by.user.id, .displayName, .ipAddress et .userPrincipalName, rien d'autre. « Invitations provenant de comptes non-administrateurs » doit donc être résolu en comparant l'UPN de l'initiateur avec vos détenteurs actuels de rôles d'administration, et non par un simple filtre sur un champ roles.

Comptes invités accédant aux portails d'administration (KQL) :

azure.signinlogs.properties.user_type: "Guest" AND
azure.signinlogs.properties.app_display_name: ("Azure Portal" OR "Microsoft Azure Management")

Invitations d'invités en masse (>5 en 1 heure) - ES|QL : KQL ne fait que filtrer ; il ne joue aucun rôle dans l'agrégation, la transformation ou le tri des données, une règle de rafale ne peut donc pas du tout être écrite en KQL. Utilisez ES|QL :

FROM logs-azure.auditlogs-*
| WHERE azure.auditlogs.operation_name == "Invite external user"
| STATS invites = COUNT(*)
    BY inviter = azure.auditlogs.properties.initiated_by.user.userPrincipalName,
       window = DATE_TRUNC(1 hour, @timestamp)
| WHERE invites > 5

Remédiation

1. Restreindre les droits d'invitation

Entra ID > External Identities > External collaboration settings:
Guest invite settings: "Only users assigned to specific admin roles can invite"

Avec ce paramètre, seuls les détenteurs du rôle User Administrator ou Guest Inviter peuvent envoyer des invitations, ce qui crée une piste d'audit et empêche les abus d'invitation. Notez ce que ce paramètre n'est pas : il restreint qui peut inviter, il n'ajoute pas de flux d'approbation. Si vous avez besoin d'approbations, placez l'accès invité derrière des packages d'accès de gestion des droits d'utilisation (entitlement management) avec des approbateurs nommés.

2. Exiger le MFA pour les utilisateurs invités

Conditional Access Policy:
Name: Require MFA - Guest Users
Users > Include > Select users and groups > Guest or external users:
  select every applicable type (B2B collaboration guest users,
  B2B collaboration member users, B2B direct connect users,
  Local guest users, Service provider users, Other external users)
Target resources > Include: All resources (formerly 'All cloud apps')
Access controls > Grant: Require multifactor authentication
Enable policy: On

Il n'existe pas de case à cocher unique « All guests and external users » (tous les invités et utilisateurs externes) - vous choisissez les types d'utilisateurs externes que vous souhaitez couvrir. Comme les paramètres de confiance inter-tenants ne font pas confiance au MFA du tenant d'origine par défaut, les invités satisfont cette stratégie en effectuant le MFA face à votre propre tenant.

3. Supprimer les comptes invités inactifs

# La suppression d'un utilisateur nécessite un scope en écriture - User.DeleteRestore.All est
# le moins privilégié. AuditLog.Read.All est ce qui rend signInActivity lisible.
Connect-MgGraph -Scopes "User.Read.All","AuditLog.Read.All","User.DeleteRestore.All"

$cutoff = (Get-Date).AddDays(-90)

# -All et -Property ne sont pas optionnels ici. Sans -Property, les données de
# connexion sont absentes, chaque invité correspond au test $null, et ce script
# supprime l'intégralité de la population d'invités.
$staleGuests = Get-MgUser -All -Filter "userType eq 'Guest'" `
  -Property "id,displayName,userPrincipalName,signInActivity" |
  Where-Object {
    $null -eq $_.SignInActivity.LastSignInDateTime -or
    $_.SignInActivity.LastSignInDateTime -lt $cutoff
  }

Write-Host "Found $($staleGuests.Count) stale guest accounts"

# Exportez et vérifiez la liste avant de supprimer quoi que ce soit, puis retirez -WhatIf.
$staleGuests | Select-Object DisplayName, UserPrincipalName,
  @{N="LastSignIn";E={$_.SignInActivity.LastSignInDateTime}} |
  Export-Csv .\stale-guests.csv -NoTypeInformation

$staleGuests | ForEach-Object {
  Remove-MgUser -UserId $_.Id -WhatIf
}

Un invité supprimé de cette façon reste récupérable pendant 30 jours avant que Microsoft Entra ID ne le supprime définitivement.

4. Configurer des révisions d'accès trimestrielles

Entra ID > ID Governance > Access reviews:
Create recurring quarterly reviews for all guest accounts
Reviewers: Resource owners or group owners
Auto apply results to resource: Enable
If reviewers don't respond: Remove access
Action to apply on denied guest users:
  Block from signing in for 30 days then remove user from the tenant

Ce sont les deux dernières lignes qui transforment une révision en véritable offboarding : retirer uniquement l'accès laisse l'objet invité dans le tenant. L'action de suppression du compte B2B est disponible lorsque la révision cible des équipes et groupes sélectionnés - elle n'est pas proposée sur la révision « All Microsoft 365 groups with guest users » (tous les groupes Microsoft 365 avec des invités). Licences : les révisions d'accès nécessitent un abonnement Microsoft Entra ID Governance ou Microsoft Entra Suite ; certaines fonctionnalités opèrent avec Entra ID P2.

5. Mettre en place des niveaux d'accès invité

Utilisez la gestion des droits d'utilisation (entitlement management) Entra ID pour automatiser le cycle de vie des invités avec des dates d'expiration automatiques. Comme les révisions d'accès, il s'agit d'une fonctionnalité Microsoft Entra ID Governance, sous licence distincte d'Entra ID P1.

Comment EtcSec détecte cela

EtcSec audite la gouvernance des comptes invités à chaque scan Azure, en identifiant les risques de prolifération et les accès non contrôlés.

GUEST_INVITATION_UNRESTRICTED signale les tenants dont la stratégie d'invitation des invités reste ouverte à tout le monde - le paramètre par défaut - au lieu d'être restreinte à un ensemble contrôlé d'inviteurs. C'est la cause racine de la prolifération incontrôlée d'invités.

GUEST_NO_MFA_REQUIRED signale les tenants où les utilisateurs invités ne sont soumis à aucune stratégie d'accès conditionnel exigeant le MFA, laissant les identités externes avec une authentification plus faible que celle des utilisateurs internes.

GUEST_STALE_90_DAYS liste les comptes invités activés dont la dernière connexion enregistrée date de plus de 90 jours, fournissant une liste priorisée pour la révision d'accès et le nettoyage. Les invités qui ne se sont jamais connectés constituent un cas différent, signalé séparément par GUEST_NEVER_SIGNED_IN.

Questions fréquentes

Les comptes invités Azure présentent-ils un risque de sécurité par défaut ? Les comptes invités eux-mêmes ne sont pas intrinsèquement risqués, mais une gouvernance déficiente crée un risque important. Les principaux problèmes sont : l'absence d'exigence de MFA pour les invités, des droits d'invitation illimités, et des comptes inactifs jamais supprimés. Un programme d'invités bien gouverné présente un faible risque ; un programme non géré devient une surface d'attaque majeure.

À quelle fréquence dois-je réviser les comptes invités ? Microsoft ne publie pas de fréquence unique imposée : les révisions d'accès Entra ID peuvent être planifiées de façon hebdomadaire, mensuelle, trimestrielle ou annuelle, et l'intervalle approprié dépend de la sensibilité des ressources partagées. La fréquence trimestrielle est la référence EtcSec. Les révisions d'accès peuvent automatiser le résultat avec suppression automatique en cas d'absence de réponse, ce qui rend le processus gérable même pour de grands tenants ; cela nécessite un abonnement Entra ID Governance ou Entra ID P2.

Un compte invité peut-il servir de pivot au sein de l'organisation ? Oui. Un invité disposant d'un accès Teams peut voir tous les messages et fichiers de ces canaux. Si l'invité dispose également d'un accès SharePoint, il peut lire et potentiellement exfiltrer des documents. Les dégâts sont limités par les autorisations de l'invité, mais les invités inactifs sur-privilégiés sont extrêmement courants en pratique.

Priorités de révision

Les comptes invités Azure - la surface d'attaque oubliée de votre tenant doivent être traités comme une exposition réelle au sein de votre tenant Entra ID et Azure, et non comme un simple paramètre isolé. Commencez par définir le périmètre de la révision : quels administrateurs, invités, principaux de service, inscriptions d'applications, exclusions de stratégie et comptes de secours (break-glass) sont concernés, quels workflows métier en dépendent, quels privilèges ils exposent, et quelles exceptions d'urgence ont été ajoutées au fil du temps. Cette étape de cadrage évite une remédiation superficielle, car le symptôme technique est souvent plus restreint que le rayon d'impact opérationnel réel. En documentant l'intégralité du chemin allant de la configuration au privilège, l'équipe peut prioriser les changements qui réduisent rapidement le risque sans casser les accès en production. Cela crée également une base défendable pour les validations ultérieures et donne à la direction une explication claire de l'importance actuelle du sujet.

Contrôles adjacents à examiner

Lorsque des attaquants atteignent votre tenant Entra ID et Azure, ils s'arrêtent rarement au premier point faible. Autour du sujet des comptes invités Azure - la surface d'attaque oubliée de votre tenant, ils testent généralement si le chemin exposé peut être enchaîné avec une authentification héritée, une gouvernance des invités défaillante, un consentement d'application trop large, des comptes de secours inactifs, et des rôles jamais révisés. Cela signifie que les défenseurs doivent examiner non seulement la faiblesse principale, mais aussi chaque dépendance voisine qui transforme un accès en persistance ou en élévation de privilèges. Confirmez quelles identités, rôles, autorisations et hypothèses de confiance peuvent être réutilisés par un opérateur motivé. Si un correctif ne referme qu'un seul objet en laissant intacts les chemins de privilèges adjacents, le risque effectif change à peine. Une revue disciplinée des possibilités d'enchaînement est ce qui transforme ce sujet en un exercice de durcissement concret plutôt qu'en une simple case à cocher ponctuelle.

Preuves et télémétrie à collecter

Une réponse solide au sujet des comptes invités Azure - la surface d'attaque oubliée de votre tenant nécessite des preuves que les équipes d'ingénierie et de détection peuvent toutes deux examiner. Collectez les journaux de connexion, les journaux d'audit, les changements d'attribution de rôles, les événements de consentement, les changements d'identifiants d'application et les signaux de connexion à risque, comparez les changements récents avec les fenêtres de maintenance connues, et isolez les comptes ou systèmes dont le comportement a changé sans raison métier claire. Utilisez ces preuves pour répondre à trois questions : quand le chemin à risque est-il apparu, qui peut encore l'utiliser, et une exposition similaire existe-t-elle ailleurs dans votre tenant Entra ID et Azure. Une bonne revue de télémétrie aide aussi à distinguer la dette technique héritée d'une exploitation active. Cette distinction compte, car le plan de remédiation pour une mauvaise configuration ancienne diffère du plan pour un chemin qui montre déjà une activité de type attaquant ou des exceptions de stratégie répétées.

Comptes invités Azure : validation avant clôture

Une revue solide des comptes invités Azure doit se conclure par des preuves issues de la production, et non par une simple supposition que le chemin à risque a disparu. Avant de clôturer le constat, revérifiez les attributions de rôles, la portée des stratégies, les autorisations d'application ou les paramètres invités, les preuves de connexion, d'audit ou de risque issues du tenant réel, ainsi que le chemin d'exception qui pourrait silencieusement recréer l'exposition. Confirmez que l'état plus sûr s'applique à la portée qui compte réellement : l'OU de production, l'attribution de rôle effective, le chemin applicatif, ou le chemin de confiance et de délégation qu'un attaquant exploiterait réellement. Consignez le responsable technique, la dépendance métier et la condition de retour arrière afin que la prochaine revue puisse déterminer si l'état plus sûr a été maintenu.

Utilisez une courte checklist de clôture :

• vérifiez que l'état à risque a bien disparu du point de vue de l'attaquant, pas seulement sur une capture d'écran d'administration
• conservez un export ou un échantillon de journal avant/après prouvant que la portée concernée a changé
• documentez le responsable et la décision d'exception si le contrôle n'a pas pu être pleinement appliqué

Pour les expositions adjacentes, recoupez le résultat avec Applications Azure sur-privilégiées du tenant, Durcissement du tenant Azure : corriger les paramètres par défaut non sécurisés, Comment auditer la sécurité de Microsoft Entra ID (Azure AD) : guide pratique de révision, et Conformité AD et Azure : NIS2, ISO 27001, contrôles CIS. Le même écart de contrôle réapparaît souvent dans des chemins d'identité voisins, des lacunes de journalisation ou des autorisations déléguées, ce qui explique pourquoi l'étape de validation finale compte autant que le constat initial.

Comptes invités Azure : preuves à conserver pour le prochain cycle de révision

Le prochain réviseur ne devrait pas avoir à reconstituer le dossier de mémoire. Conservez les preuves qui ont initialement justifié le constat, la preuve que le changement a été appliqué, et la note expliquant pourquoi l'état final est acceptable. Pour ce sujet, les preuves les plus utiles combinent généralement l'export du tenant ou la capture d'écran montrant la portée concernée, les preuves de connexion, d'audit ou de stratégie démontrant que le contrôle s'applique désormais, ainsi que la note sur le responsable, l'approbation et l'exception pour l'état final. Ce dossier compact rend les revues trimestrielles ou post-changement beaucoup plus rapides et aide à expliquer si le problème a été supprimé, réduit ou formellement accepté.

Si un changement ultérieur d'administration, de stratégie ou d'application rouvre le chemin, ces preuves historiques permettent aussi de démontrer plus facilement ce qui a dérivé. C'est ce qui transforme les comptes invités Azure d'une vérification ponctuelle en un processus d'assurance reproductible.

Sources

• Microsoft Learn - Configure external collaboration settings (portée d'invitation par défaut, options d'invitation des invités, rôle Guest Inviter)
• Microsoft Learn - List users (Microsoft Graph) (signInActivity nécessite Entra ID P1/P2 et AuditLog.Read.All)
• Microsoft Learn - Get-MgUser et Remove-MgUser
• Microsoft Learn - Manage guest access with access reviews et What are access reviews? (application automatique, licences)
• Microsoft Learn - Cross-tenant access overview (les revendications MFA du tenant d'origine ne sont pas fiables par défaut)
• Microsoft Learn - Conditional Access: target resources et users and groups
• Microsoft Learn - Entra audit log activity reference (noms des activités liées aux utilisateurs invités)
• Elastic - Azure exported fields et KQL

Lectures complémentaires

Examinez ce sujet conjointement avec Failles d'accès conditionnel Entra ID : quelles mauvaises configurations laissent une exposition réelle, Durcissement du tenant Azure : corriger les paramètres par défaut non sécurisés, Accès privilégié Azure : trop d'administrateurs généraux, Applications Azure sur-privilégiées du tenant, et Azure Identity Protection : bloquer les identifiants divulgués. Ces articles connexes montrent comment les mêmes faiblesses d'identité s'enchaînent généralement lors d'une évaluation réelle, au lieu d'apparaître comme des constats isolés.

• Failles d'accès conditionnel Entra ID : quelles mauvaises configurations laissent une exposition réelle
• Durcissement du tenant Azure : corriger les paramètres par défaut non sécurisés
• Accès privilégié Azure : trop d'administrateurs généraux
• Applications Azure sur-privilégiées du tenant
• Azure Identity Protection : bloquer les identifiants divulgués

L'utilisation de ces références permet de garder la discussion sur la remédiation centrée sur l'ensemble du chemin d'attaque plutôt que sur un seul écart de contrôle.

Checklist de validation

Avant de clôturer la revue, relancez les mêmes vérifications que celles ayant révélé le problème et confirmez que le chemin à risque n'existe plus du point de vue de l'attaquant. Vérifiez les identités, privilèges, chemins d'héritage et contrôles compensatoires pertinents en production, et pas seulement en environnement de test ou dans la documentation. Consignez le responsable technique, la dépendance métier attendue, et les preuves montrant que la nouvelle configuration est à la fois plus sûre et opérationnellement viable. Cette dernière étape de validation est ce qui ancre l'article dans la manière dont les équipes réduisent réellement le risque identitaire.

Confirmer les contrôles du cycle de vie des invités en pratique

La remédiation des comptes invités doit inclure une revue de qui parraine les utilisateurs externes, de la façon dont l'accès est recertifié, et des chemins de collaboration qui créent encore des identités invitées durables avec de larges autorisations. Les programmes les plus résilients combinent des restrictions d'invitation, des révisions d'accès périodiques et des vérifications de responsabilité, afin que l'accès invité reste lié à un besoin métier réel au lieu de perdurer indéfiniment après la fin du projet.