Les migrations inter‑locataires Microsoft 365 soulèvent des défis complexes qui vont bien au-delà du simple déplacement de données. La protection de la Digital Workplace, la continuité des politiques de gouvernance des données dans le cloud et le respect des obligations réglementaires doivent être assurés à chaque étape. Des outils comme Microsoft Purview, le Microsoft Compliance Center et Azure AD / Entra ID jouent un rôle central dans cet encadrement. Pour les organisations qui souhaitent aborder ce chantier avec méthode, la migration tenant to tenant M365 proposée par Eliadis offre un cadre structuré, piloté par des experts Microsoft qui accompagnent leurs clients depuis 2001 sur l’ensemble de leurs enjeux de sécurité Microsoft 365 et de conformité réglementaire cloud.
À retenir :
- Les migrations Tenant to Tenant Microsoft 365 exposent les données sensibles à des risques tels que fuites d’informations et ruptures de conformité
- La sécurité doit être intégrée dès la conception du projet de migration, avec des configurations telles que segmentation et contrôles de gouvernance
- La stratégie Zero Trust est essentielle, requérant une cartographie des ressources et des politiques d’accès conditionnel
- Microsoft Purview est clé pour la classification et la protection des données durant la migration, évitant des pertes de contexte
- Après la migration, l’audit et la journalisation avancée assurent la conformité et la traçabilité des opérations
- Les tests de sécurité post-migration doivent inclure des scans de vulnérabilités et un plan de réponse aux incidents adapté à la nouvelle structure des identités
Mettre en place les fondations de la sécurité Microsoft 365 avant la migration
Sécuriser un environnement Microsoft 365 avant une migration tenant to tenant commence par des configurations précises : segmentation des accès, durcissement des identités et contrôles de gouvernance appliqués dès la phase de préparation. Ces actions constituent le socle sur lequel repose l’ensemble du processus de migration.
Définir une stratégie Zero Trust pour les environnements source et cible
L’approche zéro trust Microsoft 365 impose de ne jamais accorder une confiance implicite à un compte ou à un appareil, y compris ceux appartenant au tenant source. Avant d’initier le moindre flux de données, il convient de cartographier les périmètres de chaque locataire, de segmenter les ressources selon leur niveau de sensibilité et d’établir des politiques d’accès conditionnel Azure AD adaptées à chaque environnement. Cette segmentation source/cible réduit considérablement la surface d’attaque exposée pendant la fenêtre de coexistence des deux tenants. Pour approfondir ce sujet, consultez les recommandations sur l’isolation tenant Microsoft 365, qui détaillent les meilleures pratiques de cloisonnement applicables dès cette étape.
Les CIS Benchmarks Microsoft 365 constituent une référence utile pour évaluer le niveau de durcissement initial de chaque tenant. Ils couvrent notamment la désactivation des protocoles d’authentification hérités, la configuration des politiques de mots de passe et l’activation de l’authentification multifacteur pour l’ensemble des comptes.
Configurer les restrictions de locataire v2 (Tenant Restrictions v2)
Les restrictions de locataire v2 représentent un mécanisme central de la sécurité avant migration M365. Selon la documentation officielle de Microsoft, cette fonctionnalité permet de contrôler les accès cross-tenant de façon granulaire. La configuration des restrictions Microsoft Entra s’opère directement au niveau du tenant, sans dépendance à un proxy réseau intermédiaire : les restrictions de locataire v2 utilisent une liste autorisée de locataires partenaires configurée côté serveur sans en-tête proxy (Source : Microsoft — 2025-05-30). Ce modèle simplifie le déploiement tout en offrant un contrôle précis sur les identités externes autorisées à accéder aux ressources du tenant cible. La mise en place de ces restrictions doit intervenir avant toute ouverture de flux entre les deux environnements.
Pour compléter ce dispositif, Microsoft Defender for Cloud Apps permet de surveiller les activités suspectes entre tenants et d’appliquer des politiques de session en temps réel, renforçant ainsi la visibilité sur les comportements anormaux durant la phase de coexistence. Retrouvez une analyse détaillée du contrôle d’accès Microsoft 365 multi-tenant pour structurer ces configurations.
Préparer Azure AD / Microsoft Entra ID et les rôles administratifs
La sécurisation des comptes administrateurs constitue un prérequis non négociable. Il s’agit d’appliquer le principe du moindre privilège en limitant les rôles d’administration globale, d’activer Privileged Identity Management (PIM) pour un accès juste-à-temps, et de créer des comptes dédiés à la migration afin d’éviter tout débordement de privilèges vers les environnements de production.
| Contrôle | Périmètre | Outil associé | Priorité |
|---|---|---|---|
| Accès conditionnel | Tenant source et cible | Microsoft Entra ID | Critique |
| Restrictions de locataire v2 | Flux cross-tenant | Entra External ID | Critique |
| PIM (moindre privilège) | Comptes administrateurs | Azure AD / Entra ID | Haute |
| Surveillance des sessions | Applications cloud | Defender for Cloud Apps | Haute |
| Durcissement CIS Benchmarks | Les deux tenants | Microsoft Secure Score | Moyenne |
La préparation sécurité tenant source se prolonge naturellement vers la maîtrise du cloisonnement réseau, sujet abordé dans les meilleures pratiques de cloisonnement réseau tenant to tenant sur Azure, qui constituent l’étape suivante de ce cadre de sécurité.
Protéger et classifier la donnée avec Microsoft Purview
Microsoft Purview constitue le socle de gouvernance à activer avant toute migration tenant to tenant : il permet de classifier, protéger et tracer chaque fichier tout au long du transfert. Sans cette couche de contrôle, des données sensibles peuvent traverser les frontières organisationnelles sans aucune étiquette ni règle DLP applicable dans le tenant cible.
Appliquer les étiquettes de confidentialité et les stratégies DLP aux contenus migrés
La classification et l’étiquetage Microsoft Purview doivent être définis dans les deux tenants avant le démarrage de la migration. Dans le tenant source, chaque site SharePoint Online et chaque bibliothèque de fichiers doit être inventorié selon sa sensibilité : confidentiel, usage interne, public. Cette politique de classification des données Microsoft 365 établit la correspondance entre les étiquettes source et celles configurées dans le tenant cible, évitant toute perte de contexte lors du transfert.
Les stratégies DLP Microsoft 365 doivent elles aussi être synchronisées. Il est recommandé d’exporter la configuration DLP du Centre de conformité Microsoft 365 source, de l’analyser et de la recréer dans le tenant cible avant la première vague de migration. Cette approche garantit que les règles de prévention des fuites de données s’appliquent dès la réception des contenus, sans fenêtre de vulnérabilité.
Gérer le chiffrement au repos et en transit
La sécurisation des fichiers migrés repose sur deux niveaux de chiffrement distincts. Au repos, Azure Information Protection assure le chiffrement des fichiers portant une étiquette de confidentialité via des clés gérées par le locataire (CMK) ou par Microsoft. En transit, le protocole TLS est activé par défaut entre les tenants Microsoft 365, mais il est essentiel de vérifier que les connecteurs de migration ne contournent pas ce chiffrement natif, notamment lorsqu’un outil tiers est utilisé.
| Phase | Type de chiffrement | Outil concerné | Action recommandée |
|---|---|---|---|
| Avant migration | Chiffrement au repos | Azure Information Protection | Auditer les étiquettes actives et les clés associées |
| Pendant transfert | Chiffrement en transit | SharePoint Online / TLS | Vérifier la conformité du connecteur de migration |
| Après migration | Chiffrement au repos | Microsoft Purview | Réappliquer les étiquettes et contrôler les droits |
Coordonner la suppression temporaire des étiquettes avant transfert
Certaines étiquettes de confidentialité intègrent un chiffrement qui bloque le déplacement des fichiers entre tenants. Selon Microsoft, pour migrer des sites comportant des étiquettes de type User-Defined, il est nécessaire de supprimer ces étiquettes en utilisant la commande Unlock-SPOSensitivityLabelEncryptedFile (Source : Microsoft — 2025-11-05). Cette opération doit être planifiée avec soin : la suppression temporaire d’étiquettes crée une fenêtre pendant laquelle les fichiers ne sont plus protégés par chiffrement. Il convient donc de la restreindre à des plages horaires de faible activité et de réappliquer immédiatement les étiquettes correspondantes dans le tenant cible dès réception des données.
Pour approfondir les exigences réglementaires liées à cette étape, la conformité réglementaire Microsoft 365 en contexte de migration fournit un cadre d’analyse complémentaire. Le chapitre suivant examinera comment sécuriser les identités et les accès tout au long du processus de migration.
Garantir la conformité et la traçabilité post‑migration
Après une migration tenant to tenant, superviser la conformité et la traçabilité des opérations est indispensable pour maintenir la sécurité des données et répondre aux exigences réglementaires. Les outils natifs de Microsoft 365 permettent d’instaurer une gouvernance structurée dès les premières heures suivant la bascule.
Activer les journaux d’audit et la journalisation avancée
Les journaux d’audit Microsoft 365 constituent le socle de toute stratégie de traçabilité des opérations migration. Accessibles depuis le Centre d’administration Microsoft 365, ils enregistrent l’ensemble des activités utilisateurs et administrateurs : connexions, modifications de permissions, exports de fichiers ou changements de configuration. Pour aller plus loin, l’activation de l’audit avancé (Audit Premium) prolonge la durée de rétention des logs et permet d’interroger des événements à haute valeur probante, notamment lors d’un incident de sécurité post-migration.
L’intégration de ces journaux dans Azure Monitor et Log Analytics offre une centralisation des données télémétriques. Il devient ainsi possible de corréler des événements issus de plusieurs workloads (Exchange Online, SharePoint, Teams) et d’identifier des comportements anormaux dans les flux de données inter-tenants. Pour approfondir la mise en place de ces mécanismes, consultez notre guide dédié à la journalisation d’audit lors d’une migration tenant to tenant.
Mesurer la posture de conformité via Microsoft Purview Compliance Manager
Le Microsoft Purview Compliance Manager fournit un score de conformité dynamique, calculé sur la base des contrôles actifs dans l’environnement Microsoft 365. Après une migration, ce score peut temporairement baisser si certaines politiques n’ont pas été réappliquées dans le tenant cible. Il convient donc de réaliser une revue systématique des actions correctives proposées par l’outil.
| Domaine | Contrôle à vérifier | Priorité |
|---|---|---|
| Protection des données | Étiquettes de sensibilité réappliquées | Haute |
| Gestion des accès | Politiques d’accès conditionnel actives | Haute |
| Rétention | Stratégies de rétention héritées du tenant source | Moyenne |
| Journalisation | Audit avancé activé sur le tenant cible | Haute |
| Partage externe | Paramètres de partage SharePoint conformes | Moyenne |
Selon la documentation Microsoft, « PartnerRole définit les rôles du locataire partenaire comme source ou cible pour les migrations SharePoint », ce qui suggère que la bonne configuration de ces rôles conditionne directement la traçabilité des transferts inter-tenants. (Source : Microsoft — 2025-10-02)
Suivre les accès, les transferts de données et les alertes de sécurité
La traçabilité des opérations migration tenant to tenant repose sur la mise en place de tableaux de bord sécurité M365, construits avec Power BI connecté à Log Analytics. Ces tableaux de bord offrent une vision consolidée des accès inhabituels, des volumes de données transférées et des alertes déclenchées par Microsoft Defender for Cloud Apps.
Il est recommandé de configurer des règles d’alerte automatisées pour toute tentative d’accès depuis un tenant non autorisé ou tout export massif de contenu. La gouvernance des données post-migration implique également une revue périodique des groupes de sécurité et des droits délégués, afin d’éviter les dérives d’accès héritées du tenant source. Ces mécanismes de monitoring conformité cloud Microsoft 365 préparent le terrain pour une gestion long terme de la sécurité, thème que nous développons dans le chapitre suivant.
Tests, contrôles et réponse aux incidents de sécurité
Après une migration tenant to tenant Microsoft 365, les contrôles post‑migration constituent la dernière ligne de défense avant la remise en production complète. Un plan de tests de sécurité post‑migration structuré permet de détecter les vulnérabilités résiduelles avant qu’elles ne soient exploitées.
Intégrer les tests de vulnérabilité et de pénétration dans le plan post-migration
Les tests de sécurité Microsoft 365 tenant doivent démarrer dès la fin du basculement, en ciblant en priorité les surfaces d’attaque élargies par la migration : règles de transport héritées, permissions délégées non révoquées et configurations de connecteurs SMTP. Un scan de vulnérabilités Microsoft 365 tenant to tenant systématique permet d’inventorier ces failles avant qu’elles ne soient exploitables. Microsoft Defender for Office 365 joue ici un rôle central : ses rapports d’attaques simulées (Attack Simulator) reproduisent des scénarios de phishing et de compromission de comptes pour évaluer la résistance réelle du nouvel environnement. Parallèlement, une analyse des risques liés à la migration doit couvrir les secrets applicatifs stockés dans Azure Key Vault afin de vérifier que les politiques d’accès ont été correctement transférées. Selon Microsoft, la propagation DNS pour vérification de domaine peut prendre jusqu’à 72 heures lors de migration de boîtes aux lettres — un délai pendant lequel les flux de messagerie restent exposés à des erreurs de routage (Source : Microsoft — 2024-05-20). Il est donc recommandé d’effectuer un test de pénétration Microsoft 365 tenant to tenant ciblé sur les enregistrements MX et SPF/DKIM/DMARC pendant cette fenêtre critique.
Mettre à jour le plan de réponse aux incidents et la gestion des identités compromises
Les réponses aux incidents Microsoft 365 doivent s’appuyer sur un plan révisé après la migration, car les identités, les groupes et les rôles ont évolué. La gestion des identités compromises (IAM) doit intégrer des playbooks mis à jour précisant les procédures de révocation de token, de réinitialisation des authentificateurs MFA et de quarantaine des comptes suspects. Microsoft Secure Score constitue un indicateur de pilotage fiable : chaque action corrective recommandée par la plateforme doit être priorisée selon son impact sur le score global et sa complexité d’implémentation.
| Contrôle | Outil associé | Fréquence recommandée | Seuil d’alerte |
|---|---|---|---|
| Score de sécurité global | Microsoft Secure Score | Hebdomadaire | Baisse > 5 points |
| Scan de vulnérabilités | Microsoft Defender for Office 365 | Mensuelle | Toute criticité haute |
| Tests de pénétration | Attack Simulator / tiers | Trimestrielle | Taux de compromission > 10 % |
| Audit des accès Azure Key Vault | Azure Key Vault / Logs | Continue | Accès non autorisé détecté |
Mettre en place un plan de tests continu et des tableaux de suivi sécurité
Un plan de tests de sécurité post‑migration pérenne repose sur une cadence formalisée : scans hebdomadaires automatisés, revues mensuelles des scans de vulnérabilités Microsoft 365, et exercices trimestriels de simulation d’incidents. Power BI peut être connecté aux logs Microsoft 365 pour générer des tableaux de bord dynamiques centralisant le Microsoft Secure Score, les alertes Defender et les résultats des audits IAM. Ce dispositif de surveillance continue transforme chaque résultat de test en action corrective traçable, garantissant que la posture de sécurité s’améliore durablement après la migration. La gouvernance de ces contrôles doit être intégrée dans le cycle de vie global de la Digital Workplace afin d’assurer une conformité continue avec les exigences réglementaires et les politiques internes de l’organisation.
Conclusion
Sécuriser une migration Microsoft 365 tenant to tenant repose sur trois impératifs concrets : anticiper les risques en amont, maintenir la conformité après le basculement et s’appuyer sur des expertises éprouvées. Négliger l’un de ces axes compromet l’intégrité du cadre de gouvernance M365 dans sa globalité.
La planification de sécurité doit précéder chaque phase opérationnelle. La configuration de Microsoft Entra ID, la classification des données via Microsoft Purview et la validation des mappages utilisateurs constituent des prérequis non négociables. À ce titre, selon Microsoft, la commande TenantToTenant‑PrepareMigration permet de valider le fichier de mappage d’utilisateurs avant tout déplacement d’environnements Power Platform (Source : Microsoft — 2026-04-06).
L’audit post-migration M365 garantit quant à lui que les politiques de gouvernance cloud restent opérationnelles dans le nouveau tenant. Enfin, faire appel à un partenaire spécialisé en sécurité et conformité Microsoft 365 — tel qu’Eliadis — permet d’optimiser durablement la posture de sécurité et d’accélérer l’adoption des nouveaux environnements collaboratifs.
