# Azure Cross-Tenant Access : reprendre le contrôle des identités entre organisations

# Pourquoi a-t-on besoin de gérer le cross-tenant aujourd’hui ?

Si, comme moi, vous gérez ou travaillez avec plusieurs tenants Azure, vous avez forcément déjà été confronté à cette situation : des utilisateurs provenant d’un autre tenant (partenaires, filiales, prestataires) qui souhaitent accéder à vos applications, vos environnements ou vos services.

Dans ces contextes multi-organisations, la question n’est plus simplement *« comment authentifier un utilisateur »*, mais plutôt :

> **« Qui a le droit de parler à mon tenant, depuis quel tenant, et pour quelles applications ? »**

Le modèle historique \*\*“\*\*un tenant = une organisation” n’est plus adapté aux environnements modernes.

Aujourd’hui, les entreprises fonctionnent avec :

* des filiales dans des tenants Azure différents
    
* des partenaires externes
    
* des prestataires avec leur propre Entra ID
    
* des applications SaaS multi-tenants
    

des contextes réglementaires stricts (NIST, ISO, etc.)

Le besoin n’est plus seulement d’authentifier des utilisateurs, mais de contrôler les flux d’identité entre organisations distinctes.

Avant l’introduction du Cross-Tenant Access, Microsoft proposait principalement 3 approches.

### Guest users

* L’utilisateur externe est invité
    
* Il devient un **Guest** dans le tenant cible
    

Avantages

* Simple à mettre en place
    
* Compatible avec Conditional Access
    
* Bien intégré aux apps Microsoft 365
    

Limites

* Une fois invité, le guest peut **tenter d’accéder à toutes les applications**
    
* Le contrôle se fait **après le début de l’authentification**
    
* Surface d’attaque plus large
    
* Mauvais cloisonnement entre tenants
    

### Conditional Access uniquement

Principe

* On laisse l’authentification se produire
    
* On bloque ensuite via Conditional Access (MFA, device, location, etc.)
    

Avantages

* Très puissant et granulaire
    
* Logs détaillés dans les Sign-in logs
    

Limites

* Le tenant externe peut **toujours initier une authentification**
    
* Les CA s’exécutent **trop tard** dans la chaîne
    
* plus de logs, plus de surface d’exposition
    

### Defender for Cloud Apps

Principe

* Contrôle des accès et des actions **au niveau applicatif**
    
* Détection et blocage basés sur des politiques
    

Avantages

* Excellente visibilité
    
* Très utile pour l’audit et la gouvernance SaaS
    

Limites

* Ne bloque pas toujours **avant l’authentification**
    
* Ne remplace pas un contrôle d’identité à la frontière du tenant
    

# Pourquoi passer au Cross-Tenant Access ?

Le **Cross-Tenant Access** répond à une question que les autres mécanismes ne couvrent pas :

> Quels tenants ont le droit de parler avec le mien, et pour quelles applications, avant même toute authentification ?”

Ce que le Cross-Tenant Access apporte en plus

* Contrôle à la frontière du tenant
    
* Blocage avant authentification (pre-auth)
    
* Réduction drastique de la surface d’attaque
    
* Séparation claire entre organisations
    
* Zéro Trust réel entre tenants
    

# Où se place le Cross-Tenant Access dans la chaîne de sécurité ?

Le Cross-Tenant Access est le premier niveau de contrôle dans la chaîne de sécurité Azure.  
Il agit avant toute authentification, en filtrant les tentatives d’accès à la frontière du tenant.  
Si l’accès est bloqué à ce stade, aucune authentification n’a lieu, aucun Sign-in log n’est généré et les Conditional Access ne s’exécutent pas.  
Les contrôles contextuels (CA) et la visibilité SOC (Defender for Cloud Apps) n’interviennent que si le Cross-Tenant Access autorise explicitement l’accès.

## Exemple : le “blocage invisible” dans les Sign-in logs

Situation

* Utilisateur d’un **tenant externe**
    
* Tentative d’accès à une **application X**
    
* Application **non autorisée** dans la Cross-Tenant policy
    

Résultat

* Accès bloqué **correctement**
    
* Aucun log dans les Sign-in logs Entra ID
    

C’est normal car le blocage se fait **avant l’authentification**.

Où peut on voir la trace ?

Dans *Microsoft Defender for Cloud Apps —>* Activity log

# Conclusion

Le Cross-Tenant Access répond à un besoin des environnements cloud modernes : contrôler les flux d’identité entre organisations distinctes, dès la frontière du tenant.

En agissant avant toute authentification, le Cross-Tenant Access permet de : réduire significativement la surface d’attaque et appliquer un Zero Trust réel entre tenants.

Il ne remplace ni les Conditional Access, ni Defender for Cloud Apps, mais s’intègre dans une stratégie de défense en profondeur, où chaque couche joue un rôle précis : le Cross-Tenant Access filtre, Conditional Access contrôle, Defender for Cloud Apps observe et gouverne.

# Sources

[https://learn.microsoft.com/en-us/entra/external-id/cross-tenant-access-overview](https://learn.microsoft.com/en-us/entra/external-id/cross-tenant-access-overview)  
https://learn.microsoft.com/en-us/entra/external-id/b2b-collaboration-overview  
[https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview](https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview)  
[https://learn.microsoft.com/en-us/defender-cloud-apps/what-is-defender-for-cloud-apps](https://learn.microsoft.com/en-us/defender-cloud-apps/what-is-defender-for-cloud-apps)https://learn.microsoft.com/en-us/entra/external-id/cross-tenant-access-settingshttps://learn.microsoft.com/en-us/defender-cloud-apps/activity-logs