Les projets de migration Microsoft 365 génèrent des configurations temporaires, des résidus de permissions et des partages externes qui élargissent la surface d’attaque. Sans un audit de sécurité lors d’une migration tenant to tenant structuré, ces accès croisés persistent bien au-delà de la bascule et exposent l’organisation à des risques réels. Un pentest tenant to tenant ciblant Microsoft Entra ID, Microsoft Defender et Microsoft Purview permet de simuler des scénarios d’attaque réalistes sur M365, de valider les contrôles Zero Trust en place et de renforcer la posture de sécurité globale. Ce guide détaille la méthodologie à suivre pour conduire ce test d’intrusion tenant Microsoft 365 de manière rigoureuse, en conformité avec les règles d’engagement définies par Microsoft pour les environnements de production.
À retenir :
- Un test de pénétration tenant to tenant identifie les vulnérabilités lors des migrations Microsoft 365 et limite la surface d’attaque.
- Trois approches de pentest existent : boîte noire, boîte grise et boîte blanche, le choix dépend du contexte.
- Les risques dans Exchange, SharePoint, Teams et OneDrive doivent être audités, chacun ayant des priorités spécifiques.
- La coordination entre les équipes administratives des tenants source et cible est cruciale pour le succès du pentest.
- La méthodologie de test suit trois phases : planification, exécution isolée et reporting conforme aux standards.
- Les résultats des tests nourrissent la gouvernance et garantissent la conformité avec le RGPD.
Comprendre les fondements du test de pénétration Microsoft 365 tenant to tenant
Un pentest tenant to tenant consiste à simuler des attaques ciblant les deux environnements Microsoft 365 impliqués dans une migration, afin d’identifier les failles exploitables avant, pendant ou après le transfert de données. Définir précisément le périmètre de cet audit technique Microsoft 365 est la première condition d’un résultat exploitable.
Choisir le bon type de test selon le niveau d’accès disponible
Trois approches structurent le pentest tenant to tenant selon le degré de connaissance accordé aux testeurs. En boîte noire, l’équipe offensive ne dispose d’aucun accès préalable : elle reconstitue la surface d’attaque comme le ferait un tiers malveillant. En boîte grise, des identifiants utilisateurs standards sont fournis, ce qui reflète le scénario d’un compte compromis ou d’un collaborateur malveillant. En boîte blanche, les administrateurs du tenant source et du tenant cible partagent l’intégralité de la configuration : cette approche maximise la couverture de l’analyse de sécurité post-migration. Le choix dépend de la maturité sécurité du client, du calendrier du projet et du niveau de risque acceptable. Eliadis recommande généralement la boîte grise pour les migrations inter-tenants, car elle équilibre réalisme et profondeur d’analyse.
Cartographier la surface d’attaque typique d’un environnement inter-tenant
Les services Microsoft 365 exposés lors d’une migration forment une surface d’attaque étendue qui doit être documentée avant toute simulation d’attaque collaborative. Selon Microsoft Learn, les tests de pénétration permettent d’évaluer la sécurité des applications hébergées dans Azure avant et après migration (Source : Microsoft Learn — 2026-01-07). Cette logique s’applique directement aux workloads Microsoft 365 : Exchange Online concentre les risques liés à la messagerie et aux règles de transport malveillantes, SharePoint Online expose les bibliothèques de documents et les permissions héritées, Microsoft Teams peut devenir un vecteur de propagation latérale via les canaux partagés inter-tenants, et OneDrive Entreprise présente des risques de fuite lors de la coexistence des deux tenants. Un inventaire structuré de ces composants est indispensable.
| Service | Risques principaux | Priorité d’audit |
|---|---|---|
| Exchange Online | Règles de transfert cachées, usurpation d’identité | Haute |
| SharePoint Online | Permissions excessives, liens de partage anonymes | Haute |
| Microsoft Teams | Canaux externes, partage inter-tenant non contrôlé | Moyenne |
| OneDrive Entreprise | Synchronisation résiduelle, accès post-migration non révoqués | Moyenne |
Coordonner les parties prenantes pour un test efficace
Un pentest inter-tenant implique nécessairement deux équipes d’administration distinctes. La coordination entre les administrateurs du tenant source et ceux du tenant cible doit être formalisée dès le lancement du projet : définition des plages horaires autorisées, périmètre des comptes de test, canaux d’escalade en cas d’incident. Un scan de vulnérabilités Microsoft 365 tenant to tenant réalisé en amont permet d’alimenter cette coordination avec des données concrètes sur l’état de chaque environnement. Cette gouvernance préalable conditionne directement la valeur de l’évaluation offensive post-migration qui sera conduite dans les phases suivantes.
Organiser la méthodologie et l’exécution des tests
Une méthodologie de pentest Microsoft 365 structurée repose sur trois phases distinctes : planification, exécution en environnement isolé et reporting. Respecter les frameworks OWASP, PTES et NIST garantit une couverture exhaustive des vecteurs d’attaque propres aux environnements cloud.
Planification et cadrage des tests
La phase de planification définit le périmètre exact des tests, les objectifs de sécurité et les contraintes réglementaires. Il convient de documenter les scénarios d’attaque potentiels en s’appuyant sur le guide PTES Microsoft 365 et les contrôles recommandés par le NIST SP 800-115. Un plan de test de sécurité formalisé précise les plages horaires d’exécution, les systèmes concernés et les règles d’engagement, notamment pour éviter toute interruption de service en production.
Selon CodeTwo, les opérations de migration cross-tenant nécessitent la coordination entre administrateurs source et cible pour configurer les identifiants de tenant, en mobilisant spécifiquement le rôle d’Administrateur global (Source : CodeTwo — 2024-07-18). Cette coordination préalable est également indispensable dans le cadre d’un test de pénétration tenant to tenant, où la délimitation des droits entre les deux environnements conditionne directement la validité des résultats obtenus.
Définir les rôles et comptes nécessaires
L’exécution des tests requiert une organisation précise des accès. Les rôles suivants sont généralement impliqués :
- Administrateurs globaux des tenants source et cible, pour autoriser les scénarios d’attaque et accéder aux journaux d’audit.
- Comptes de test dédiés, sans privilèges de production, permettant de simuler des comportements d’utilisateurs compromis sans risque pour les données réelles.
- Équipe de sécurité chargée de superviser les alertes remontées par Microsoft Defender for Office 365 et l’Azure Security Center pendant l’exécution.
| Rôle | Périmètre d’action | Outils associés |
|---|---|---|
| Administrateur global | Configuration tenant, attribution des permissions de test | Centre d’administration Microsoft 365, PowerShell |
| Compte de test utilisateur | Simulation d’attaques par hameçonnage, MFA bypass | Attack Simulator, scripts PowerShell |
| Analyste sécurité | Surveillance des alertes et corrélation des événements | Microsoft Defender for Office 365, Azure Security Center |
Exécution en préproduction et outils utilisés
L’exécution doit impérativement se dérouler dans un environnement de préproduction ou un tenant dédié aux tests, afin d’éviter tout impact sur les utilisateurs finaux. Les outils mobilisés comprennent PowerShell pour l’automatisation des scénarios d’audit des accès et identités, des scanners de vulnérabilités compatibles avec les normes de sécurité cloud Microsoft, ainsi que les capacités d’audit natives de Microsoft Defender for Office 365. La documentation officielle de Microsoft précise les conditions d’autorisation à respecter pour tout test de pénétration sur Microsoft 365.
Le reporting final consolide les vulnérabilités identifiées, leur criticité selon le framework OWASP et les recommandations de remédiation priorisées. La phase suivante abordera l’analyse approfondie des résultats et la mise en œuvre du plan de remédiation post-migration.
Identifier, tester et corriger les vulnérabilités propres à la migration tenant to tenant
Lors d’une migration tenant to tenant, les vecteurs d’attaque les plus critiques concernent les droits résiduels, les comptes orphelins et les politiques d’accès inter-tenant mal configurées. Un contrôle de sécurité tenant to tenant structuré permet de réduire significativement la surface exposée avant la bascule définitive.
Analyser la surface d’attaque liée aux droits résiduels et comptes orphelins
Au cours d’une migration, des comptes utilisateurs désactivés ou non transférés peuvent conserver des droits d’accès actifs sur des ressources du tenant source ou cible. Cette situation crée des comptes orphelins qui constituent une cible privilégiée pour un attaquant cherchant à se déplacer latéralement entre environnements. La revue de droits d’accès doit être réalisée de manière systématique en interrogeant Microsoft Entra ID pour lister l’ensemble des attributions de rôles, des licences actives et des appartenances à des groupes de sécurité. Les comptes sans activité récente ou sans correspondance dans l’annuaire cible doivent être suspendus avant le début des tests d’intrusion.
La sécurité Entra ID impose également de vérifier les identités de service (service principals) et les applications enregistrées dans le tenant source. Ces entités bénéficient fréquemment de permissions élevées qui ne sont pas révoquées automatiquement lors de la migration. Un inventaire complet, exporté via Microsoft Graph API, constitue la base documentaire indispensable à cette phase d’analyse.
Vérifier la configuration des politiques d’accès externe et des tenant restrictions
Les Cross-tenant access policies et les tenant restrictions déterminent quels utilisateurs externes peuvent accéder aux ressources du tenant cible, et inversement. Une mauvaise configuration de ces politiques peut permettre à un utilisateur du tenant source de maintenir un accès non autorisé après la migration. Le test de résilience Microsoft 365 doit inclure des scénarios de simulation d’accès inter-tenant en utilisant des comptes de test représentatifs des deux environnements.
D’après Microsoft Learn, pour migrer les restrictions de tenant v1 vers v2, il convient d’évaluer la politique existante, de constituer une liste des identifiants de tenants externes autorisés, puis de configurer les paramètres d’accès inter-tenant en conséquence (Source : Microsoft Learn — 2025-05-30). Cette démarche structurée garantit que les politiques d’accès inter-tenant ne laissent aucune autorisation résiduelle non contrôlée. Le Conditional Access doit être testé en conditions réelles pour valider que les règles s’appliquent correctement aux identités invitées et aux connexions transfrontalières.
| Contrôle | Outil recommandé | Risque si absent |
|---|---|---|
| Inventaire des service principals | Microsoft Graph API | Permissions orphelines persistantes |
| Revue des Cross-tenant access policies | Microsoft Entra ID | Accès non autorisé post-migration |
| Test des règles Conditional Access | Portail Entra / Logs de connexion | Contournement des politiques sur comptes invités |
| Détection d’activités anormales | Microsoft Defender for Cloud Apps | Exfiltration de données non détectée |
Mettre en œuvre un plan de correction et de revue après tests
Une fois les vulnérabilités identifiées, chaque finding doit être documenté avec son niveau de criticité, les preuves collectées et les recommandations de remédiation associées. Microsoft Defender for Cloud Apps facilite la surveillance continue des comportements suspects entre tenants et peut être utilisé pour valider l’efficacité des corrections appliquées. La politique d’accès inter-tenant doit faire l’objet d’une revue formelle après chaque cycle de correction, impliquant les équipes sécurité et les administrateurs du tenant cible. Ce processus itératif garantit que le périmètre sécurisé reste cohérent jusqu’à la clôture du projet de migration.
La phase suivante abordera la formalisation du rapport de test de pénétration et les modalités de communication des résultats aux parties prenantes du projet.
Rapports, gouvernance et alignement avec la conformité réglementaire
Intégrer les résultats d’un test de pénétration dans un cadre de gouvernance structuré est une étape décisive pour transformer les constats techniques en décisions stratégiques. Sans cette formalisation, les vulnérabilités identifiées risquent de rester sans traitement durable.
Documenter les rapports exécutifs et techniques
Un test de pénétration tenant to tenant génère deux niveaux de documentation distincts. Le rapport technique recense l’ensemble des vecteurs d’attaque testés, les failles exploitées, leur niveau de criticité (CVSS) et les recommandations correctives précises. Le rapport exécutif, destiné à la direction IT et à la DSI, synthétise l’exposition globale du tenant M365, les risques métier associés et les priorités d’action. Ce reporting exécutif sécurité Microsoft 365 doit être intelligible sans prérequis techniques et formulé en termes d’impact opérationnel et financier.
Pour les migrations inter-tenant, il est recommandé d’intégrer dans ces rapports les journaux d’activité issus du Microsoft Purview Compliance Portal. D’après Microsoft Learn, les administrateurs peuvent surveiller les journaux de connexion via le workbook d’activité inter-tenant après déploiement des restrictions v2 (Source : Microsoft Learn — 2025-05-30). Ces données constituent une base d’audit sécurité M365 fiable pour objectiver les constats du pentest.
| Type de rapport | Audience cible | Contenu clé |
|---|---|---|
| Rapport technique | Équipes sécurité, SOC | Vulnérabilités, scores CVSS, PoC, remédiation |
| Rapport exécutif | DSI, DSSI, Direction générale | Synthèse des risques, impact métier, feuille de route |
Confronter les résultats avec les exigences RGPD et politiques internes
La validation conformité post-migration implique de croiser les résultats du pentest avec les obligations issues du RGPD et des politiques de sécurité internes. Les accès non autorisés à des données à caractère personnel entre tenants constituent des manquements potentiels à l’article 32 du RGPD, relatif à la sécurité du traitement. Chaque vulnérabilité critique doit donc être qualifiée selon son impact sur la protection des données personnelles et documentée dans le registre des traitements si nécessaire. Cette démarche renforce la conformité RGPD et prépare l’organisation à d’éventuels audits réglementaires.
Assurer la validation conjointe avec les équipes de sécurité et la direction IT/DSI
La gouvernance sécurité Microsoft 365 ne peut reposer sur les seules équipes techniques. La Direction de la Sécurité des Systèmes d’Information (DSSI) doit valider formellement les conclusions du pentest et approuver le plan de remédiation. Cette validation conjointe ancre la posture Zero Trust dans une démarche managériale cohérente : chaque accès inter-tenant restreint ou supprimé à la suite du test doit faire l’objet d’une décision tracée et d’une mise à jour de la politique d’accès conditionnels dans le Zero Trust Framework de l’organisation. Pour approfondir les modalités d’autorisation des tests au sein de votre environnement M365, la documentation officielle penetration testing Microsoft 365 précise les règles d’engagement à respecter.
Une fois ce cadre de gouvernance établi, il devient possible d’aborder sereinement la phase de remédiation priorisée et le suivi continu de la posture de sécurité post-migration.
Conclusion
Un test de pénétration tenant to tenant est une étape structurante pour garantir la sécurité d’une migration Microsoft 365 réussie. Il ne s’agit pas d’une formalité : c’est un contrôle de robustesse Microsoft 365 qui révèle les failles invisibles aux outils natifs.
Intégrer un pentest M365 dans le plan de migration, c’est s’assurer que les configurations entre tenants source et cible respectent les meilleures pratiques d’évaluation Microsoft 365. Microsoft Learn indique d’ailleurs que la migration des politiques de restrictions tenant vers la version 2 s’effectue en une seule opération, sans modification côté client (Source : Microsoft Learn — 2025-05-30), ce qui simplifie la mise en conformité post-migration.
Le reporting issu de l’audit global tenant to tenant alimente directement la gouvernance cloud : il documente les risques résiduels, oriente les équipes sécurité et facilite la collaboration inter-tenant. Microsoft Defender et Microsoft Purview complètent cette démarche en assurant la supervision continue. Chez Eliadis, cette approche structurée de la sécurité cloud Microsoft 365 est au cœur de chaque accompagnement en migration et gouvernance M365.
