Comptes Invités Azure : Risques Clés

Que sont les comptes invités Azure ?

Les comptes invités Azure Entra ID correspondent aux identités externes utilisées en collaboration B2B. Ils permettent à des partenaires, prestataires ou fournisseurs d'accéder à des ressources de votre tenant sans compte membre interne.

Le mécanisme est légitime. Le risque vient de la gouvernance : droits d'invitation trop larges, MFA non imposé aux externes, comptes invités jamais revus et accès qui survivent bien après la fin du besoin métier.

Pour un lecteur technique, le sujet n'est pas « les invités existent ». Le sujet est :

qui peut créer un invité
quelles politiques d'accès lui sont appliquées
comment son accès est revu et révoqué
quels groupes, applications ou sites il peut atteindre une fois admis

Le mécanisme qui compte vraiment

Un compte invité Entra ID n'est pas un simple doublon d'utilisateur interne. L'authentification se fait souvent contre l'identité d'origine de l'utilisateur externe, puis le tenant ressource applique ses propres règles d'autorisation.

Cela crée trois angles de risque :

invitation trop facile : trop de personnes dans le tenant peuvent inviter des externes
contrôles d'accès insuffisants : les invités ne sont pas soumis à un MFA ou à des politiques d'accès conditionnel suffisamment strictes
absence de cycle de vie : personne ne valide périodiquement que l'accès est encore justifié

Une gouvernance faible des invités est donc un problème d'IAM, pas un simple problème de collaboration.

Ce qu'il faut vérifier en priorité

1. Qui peut inviter des invités ?

Microsoft documente plusieurs modèles possibles pour les invitations externes. Si le tenant autorise largement les utilisateurs membres à inviter des externes, la création d'identités externes devient difficile à gouverner.

Le bon niveau de restriction dépend du contexte, mais le point défensif reste le même : l'invitation d'invités doit être pensée comme une capacité sensible, pas comme une action banale ouverte à tout le monde.

2. Les invités sont-ils réellement soumis à MFA ?

Le fait qu'un utilisateur soit externe ne doit pas l'exempter de contrôles forts. Entra permet de cibler les guests and external users dans Conditional Access. Si cette population n'est pas couverte par une politique MFA, un compte invité compromis peut garder un accès direct à vos ressources partagées.

3. Les invités sont-ils revus et supprimés ?

Microsoft Entra ID Governance documente explicitement l'usage des Access Reviews pour les invités. Le problème classique n'est pas l'invitation initiale, mais l'accumulation : comptes jamais revus, groupes jamais nettoyés, projets terminés depuis des mois mais encore ouverts.

Chaînes d'attaque réalistes

Cas 1 - Invitation trop large

Si trop d'utilisateurs peuvent inviter des externes, un attaquant qui compromet un compte interne peut créer une identité externe qu'il contrôle et la faire entrer dans le tenant comme point d'ancrage plus durable.

Cas 2 - Invité compromis sans MFA fort

Un compte invité déjà présent, mais peu surveillé, donne à l'attaquant un accès immédiat aux ressources où il est déjà autorisé : SharePoint, Teams, groupes M365, applications ou données métier.

Cas 3 - Compte invité obsolète mais encore membre

C'est l'un des scénarios les plus fréquents. L'utilisateur externe ne collabore plus depuis longtemps, mais son compte est encore membre de groupes ou d'applications, sans revue récente. La surface d'attaque n'est pas “nouvelle”, elle est simplement oubliée.

Détection

Journaux à surveiller

Les signaux les plus utiles se trouvent dans les journaux d'audit Entra et de connexion :

création ou invitation d'utilisateurs externes
ajouts d'invités à des groupes ou à des applications
connexions d'invités depuis des emplacements inhabituels
invités dormant depuis longtemps mais toujours membres de ressources sensibles

Lecture défensive correcte

Il ne suffit pas de compter les invités. Il faut corréler :

qui les a invités
quand
où ils ont accès
s'ils se connectent encore
si leur accès a été revu récemment

Exemple d'inventaire utile

Connect-MgGraph -Scopes "Directory.Read.All"
Get-MgUser -Filter "userType eq 'Guest'" -Select "displayName,userPrincipalName,signInActivity" |
    Select-Object DisplayName, UserPrincipalName, @{N="DerniereConnexion";E={$_.SignInActivity.LastSignInDateTime}} |
    Sort-Object DerniereConnexion

Ce type d'inventaire sert à identifier les comptes invités sans activité récente ou jamais utilisés.

Remédiation

1. Restreindre les droits d'invitation

Le premier contrôle consiste à réduire qui peut inviter des externes. Il faut choisir une politique adaptée au tenant, mais l'objectif est le même : faire de l'invitation B2B une action gouvernée.

2. Exiger MFA pour les invités et externes

Une politique Conditional Access ciblant Guests or external users doit imposer une authentification forte sur les applications cloud concernées.

Exemple de principe de configuration :

Conditional Access
Utilisateurs : Guests or external users
Applications : All cloud apps ou périmètre sensible
Grant controls : Require multifactor authentication

3. Mettre en place des Access Reviews récurrentes

Microsoft documente l'usage de recurring access reviews pour les invités dans les groupes et les applications. C'est le mécanisme qui transforme la gouvernance des invités en processus continu au lieu d'un nettoyage ponctuel.

4. Supprimer les invités obsolètes

$cutoff = (Get-Date).AddDays(-90)
Get-MgUser -Filter "userType eq 'Guest'" -Select "id,displayName,userPrincipalName,signInActivity" |
    Where-Object {$_.SignInActivity.LastSignInDateTime -lt $cutoff -or $null -eq $_.SignInActivity.LastSignInDateTime} |
    Select-Object DisplayName, UserPrincipalName

Avant suppression en masse, il faut bien sûr confirmer l'absence de besoin métier. Le principe reste néanmoins simple : un invité sans usage ni owner identifiable n'a pas vocation à rester.

5. Revoir les groupes et applications exposés

Les invités les plus risqués ne sont pas ceux qui existent, mais ceux qui ont accès à :

groupes M365 ou Teams sensibles
SharePoint métier contenant des données critiques
applications internes exposées via Entra ID
rôles ou groupes qui élargissent fortement la portée d'accès

6. Vérifier les paramètres de collaboration externe et la confiance inter-tenant

Un tenant peut imposer du MFA aux invités tout en gardant des paramètres externes trop permissifs. Il faut vérifier ensemble :

External collaboration settings : qui peut inviter, quelles restrictions de lecture annuaire s'appliquent aux invités, et si les users members gardent des capacités d'invitation trop larges
Cross-tenant access settings : si le tenant accepte la MFA, la conformité device ou d'autres claims du tenant source sans décision explicite par partenaire

Le point défensif important est que la gouvernance des invités ne s'arrête pas au compte. Elle inclut aussi le niveau de confiance accordé au tenant externe et le périmètre exact des ressources visées.

7. Définir un processus de sortie réellement technique

Supprimer quelques comptes invités “anciens” ne suffit pas. Il faut un processus de sortie qui vérifie, pour chaque invité ou sponsor externe :

l'appartenance aux groupes M365, Teams et SharePoint sensibles
l'affectation d'applications Enterprise Applications ou d'apps métier
l'existence d'un sponsor interne encore responsable de cet accès
l'absence de connexions récentes qui contrediraient la suppression prévue

Sans cette séquence, le tenant supprime parfois le compte visible mais oublie le groupe, l'application ou le besoin métier qui recréera le même accès quelques semaines plus tard.

Validation après correction

Une clôture sérieuse d'un sujet de gouvernance des invités doit permettre de démontrer :

Qui peut inviter des externes aujourd'hui.
Si les invités sont soumis à MFA par politique.
Quels comptes invités sont encore actifs, inactifs ou sans propriétaire.
Quelles revues périodiques d'accès sont réellement en place.

Si ces quatre points ne sont pas visibles dans le tenant, le sujet n'est pas sous contrôle.

Ce qu'il faut valider après une campagne de nettoyage

Après remédiation, il faut aussi pouvoir montrer que :

les paramètres de collaboration externe correspondent bien à la politique attendue
les principaux groupes et applications exposés aux invités ont été revus, pas seulement les comptes eux-mêmes
les invités supprimés ou bloqués ne réapparaissent pas via un circuit d'invitation encore trop ouvert
les sponsors internes savent qui doit approuver, renouveler ou fermer les accès externes

Cette validation est ce qui distingue un nettoyage ponctuel d'un vrai contrôle de sécurité reproductible.

Contrôle final à ne pas oublier

Avant de clore le sujet, il est utile de prendre un petit échantillon d'invités encore actifs et de vérifier manuellement trois choses : le sponsor interne est identifiable, l'accès observé correspond bien au besoin métier déclaré, et une revue future est déjà planifiée. Cette vérification évite de transformer l'Access Review en simple rituel administratif sans impact réel sur l'exposition du tenant.

Erreurs fréquentes côté défense

Les erreurs les plus courantes sont :

considérer les invités comme des comptes “moins importants” que les membres internes
ouvrir largement les invitations par commodité projet
se reposer sur le tenant source de l'invité sans imposer ses propres contrôles d'accès
ne jamais faire d'Access Review sur les groupes et applications exposés aux invités
supprimer quelques comptes obsolètes sans corriger la gouvernance qui les recrée

Un lecteur technique ne veut pas un discours vague sur la collaboration. Il veut savoir qui peut créer une identité externe, comment elle est authentifiée, quels contrôles s'appliquent et comment elle disparaît quand le besoin métier s'arrête.

Références primaires

Comment EtcSec détecte cela

EtcSec suit notamment trois axes dans ce sujet :

GUEST_INVITATION_UNRESTRICTED
GUEST_NO_MFA_REQUIRED
GUEST_STALE_90_DAYS

Pris ensemble, ces constats répondent à la vraie question : est-ce que les identités externes de votre tenant sont gouvernées comme des accès sensibles, ou seulement tolérées parce qu'elles sont utiles au quotidien ?

Comptes Invités Azure : Risques du Tenant