Azure Cross-Tenant Access : reprendre le contrôle des identités entre organisations
Je suis un solution architecte dans le cloud Azure, avec des multiples expériences dans le monde du consulting. Je parcours l'univers informatique depuis déjà plus de 15 ans, m'amuse à jouer les magiciens du code et les alchimistes du cloud. J'ai été apprenti sorcier en conception des applications, et je fais partie des super-héros de développement backend, web et mobile, toujours prêt à sauver le monde du chaos informatique !
Mon pouvoir spécial réside dans l'art de construire des architectures gigantesques et de rendre les sites invincibles. Imaginez-moi, tel un maître des nuages, déployant des serveurs en un claquement de doigts et écrivant des sorts magiques pour des logiciels d'application éblouissants.
N'hésitez pas à me contacter si vous avez besoin d'aide ! Je suis toujours prêt à défendre l'Internet des méchants bugs et des pannes maléfiques ! :)
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/b2b-collaboration-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-appshttps://learn.microsoft.com/en-us/entra/external-id/cross-tenant-access-settingshttps://learn.microsoft.com/en-us/defender-cloud-apps/activity-logs
