Pour les DSI et architectes M365, les enjeux dépassent la simple migration technique. Les environnements SharePoint Online, Microsoft Teams, OneDrive et Power Platform embarquent des configurations d’accès et des données critiques qui doivent rester intègres dans le locataire cible. Une mauvaise gestion des identités via Microsoft Entra ID peut compromettre la continuité des services et exposer l’organisation à des incidents de sécurité majeurs. Pour approfondir le cadre global de sécurité et conformité lors d’une migration Microsoft 365 tenant to tenant, Eliadis propose une analyse détaillée des prérequis réglementaires et techniques. Les sections suivantes détaillent comment bâtir une checklist de sécurité migration Microsoft 365 rigoureuse, couvrant l’audit de sécurité des applications cloud et le contrôle de conformité à chaque étape du projet.
À retenir :
- Les migrations tenant to tenant dans Microsoft 365 comportent des risques de sécurité comme les fuites de données et la non-conformité RGPD
- Un plan de tests de sécurité structuré est essentiel pour évaluer les risques avant, pendant et après la migration
- Les DSI doivent cartographier les applications et vérifier les configurations pour assurer la sécurité des données critiques dans le nouveau locataire
- Tester dans un environnement de validation permet d’identifier les régressions sans compromettre les données de production
- Les contrôles post-migration, y compris les tests d’intrusion et la validation des accès, garantissent la conformité et la sécurité continue
- La gouvernance continue et les revues périodiques sont nécessaires pour maintenir une sécurité efficace suite à la migration
Préparation du plan de tests de sécurité avant la migration
La préparation d’un plan de tests de sécurité rigoureux conditionne directement la réussite d’une migration tenant to tenant. Avant toute bascule, cartographier les applications, identifier les dépendances critiques et délimiter précisément les périmètres d’audit constitue le socle indispensable de toute démarche de vérification sécurité des applications M365.
Sélection des applications à auditer et identification des risques spécifiques
La première étape de l’audit pré-migration tenant to tenant consiste à établir un inventaire exhaustif des applications concernées : SharePoint Online, Power Platform, flux Azure DevOps, connecteurs et services tiers intégrés à Microsoft 365. Chaque application est ensuite évaluée selon son niveau de criticité métier, ses volumes de données sensibles et la complexité de ses dépendances. Cette cartographie permet d’ordonner les priorités d’audit et d’anticiper les points de friction lors du passage au locataire cible.
La validation de la sécurité des environnements source et cible implique également d’identifier les comptes de service, les groupes Azure AD et les permissions applicatives susceptibles de ne pas se transposer automatiquement. Selon Microsoft, il est recommandé d’effectuer des validations complètes pour vérifier que chaque utilisateur du mappage est actif dans le locataire cible avant migration, afin de minimiser les failles d’accès (Source : Microsoft — 2026-04-06). Ce contrôle des droits d’accès avant la bascule doit figurer explicitement dans le plan de tests.
Mise en place d’un environnement de validation (proof of concept)
Avant d’engager la migration en production, la création d’un environnement de test isolé permet de simuler les configurations du locataire cible et de valider les règles de permissions. Cet environnement de preuve de concept reproduit les paramètres de gouvernance, les politiques de partage SharePoint Online et les flux Power Platform dans des conditions contrôlées. Les équipes peuvent ainsi détecter les régressions de droits, les ruptures de connecteurs ou les conflits de stratégies conditionnelles sans exposer les données de production.
Dans une approche DevSecOps migration cloud, cet environnement de test s’intègre au pipeline DevSecOps pour automatiser les contrôles de conformité à chaque itération. La préparation audit sécurité Microsoft 365 gagne ainsi en traçabilité et en reproductibilité, deux critères essentiels pour les revues post-migration.
| Application / Service | Risque identifié | Contrôle recommandé |
|---|---|---|
| SharePoint Online | Permissions de site non migrées | Audit des groupes et niveaux d’autorisation |
| Power Platform | Connecteurs orphelins | Inventaire et revalidation des connexions |
| Azure AD | Comptes non mappés | Validation croisée source / cible |
| Azure DevOps | Pipelines liés à l’ancien tenant | Mise à jour des identités de service |
Définition des responsabilités entre équipes
Un plan de tests efficace repose sur une gouvernance claire. Les rôles entre les équipes de sécurité, IT et gouvernance doivent être formalisés dès cette phase, en s’appuyant sur une matrice RACI adaptée à chaque périmètre applicatif. Chez Eliadis, l’accompagnement de cette étape s’articule autour d’ateliers de cadrage qui associent les référents métier aux experts techniques, garantissant que les exigences de conformité réglementaire Microsoft 365 sont intégrées dès la conception du plan. Cette organisation prépare directement la phase d’exécution des tests, abordée dans le chapitre suivant.
Exécution des tests de sécurité et validation des contrôles d’accès
Après une migration tenant to tenant, les tests de sécurité applicatifs permettent de détecter rapidement les écarts de configuration et de s’assurer que les politiques d’accès restent pleinement opérationnelles. Cette phase d’exécution couvre les pentests, la vérification des rôles et la validation des mécanismes d’authentification renforcée.
Réalisation de pentests et analyse des vulnérabilités
Les tests d’intrusion constituent la première ligne de vérification post-migration. Ils visent à simuler des attaques réelles sur le nouveau tenant afin d’identifier toute surface d’exposition non couverte par les politiques de sécurité définies en amont. L’analyse des vulnérabilités doit porter sur les points d’entrée critiques : accès aux portails d’administration, connecteurs applicatifs et API exposées. L’utilisation de Microsoft Defender for Cloud facilite la centralisation des alertes et l’évaluation continue de la posture de sécurité de l’environnement migré. Microsoft Defender for Identity complète ce dispositif en surveillant les comportements suspects liés aux comptes à privilèges. Les résultats des pentests doivent être documentés et traduits en actions correctives avant toute mise en production définitive. Pour approfondir les pratiques liées à la sécurité du cycle de développement, la ressource DevSecOps Microsoft offre un cadre de référence utile.
Vérification des rôles Azure AD et des autorisations RBAC
La validation des groupements RBAC est une étape incontournable des audits de configuration Entra ID. Lors d’une migration, les rôles attribués dans l’ancien tenant ne sont pas transférés automatiquement : il est donc impératif de reconstituer les assignations dans Microsoft Entra ID et de s’assurer que les Azure AD roles reflètent bien les principes du moindre privilège. Un tableau de correspondance entre les rôles sources et cibles facilite cette vérification :
| Rôle source (ancien tenant) | Rôle cible (nouveau tenant) | Statut de validation |
|---|---|---|
| Administrateur global | Administrateur global | À restreindre selon besoin réel |
| Administrateur Exchange | Administrateur Exchange | Vérifier les périmètres délégués |
| Lecteur de sécurité | Lecteur de sécurité | Confirmer les groupes associés |
| Propriétaire de groupe | Propriétaire de groupe | Revalider les adhésions dynamiques |
Les vérifications des accès utilisateurs doivent inclure les comptes de service et les identités non humaines, souvent oubliés lors des migrations, mais porteurs de risques élevés si leurs permissions restent mal configurées.
Validation du fonctionnement des mécanismes MFA et Conditional Access
Les tests d’authentification sécurisés doivent confirmer que le Conditional Access fonctionne selon les règles définies dans le nouveau tenant : localisation, conformité des appareils, niveau de risque identitaire. La validation MFA migration est désormais d’autant plus critique que, selon Microsoft, l’authentification multifacteur est obligatoire depuis janvier 2025 pour les connexions aux portails Azure et Microsoft, renforçant ainsi la sécurité post-migration (Source : Microsoft — 2025-01-30). Chaque scénario de connexion doit être testé : utilisateur interne, invité externe, accès conditionnel sur application sensible. Les résultats alimenteront directement le chapitre suivant, consacré à la gouvernance et à la remédiation des écarts identifiés.
Tests de configuration, de chiffrement et de résilience
Valider les paramètres de chiffrement et les configurations de sécurité post-migration permet de garantir que les données et les flux applicatifs restent protégés dans le nouveau locataire. Ces vérifications constituent une étape décisive avant toute mise en production définitive.
Tests de chiffrement des données au repos et en transit
La vérification des paramètres de chiffrement doit couvrir deux périmètres distincts : les données stockées dans Microsoft 365 (SharePoint Online, Exchange Online, OneDrive Entreprise) et les données en transit entre les services. Pour les données au repos, il convient de confirmer que le chiffrement natif géré par Microsoft est actif et, le cas échéant, que les clés gérées par le client (Customer Managed Keys) ont été correctement reprovisionnées dans le nouveau tenant. Pour le transit, les tests doivent vérifier que TLS 1.2 ou supérieur est imposé sur tous les points d’entrée applicatifs et que les certificats présentés sont valides, non expirés et rattachés à la bonne autorité de certification. Un tableau de suivi structuré facilite la traçabilité de ces contrôles.
| Périmètre | Protocole / Standard | Critère de validation | Statut |
|---|---|---|---|
| Données au repos (SharePoint, OneDrive) | AES-256 | Chiffrement activé, clés reprovisionnées | À vérifier |
| Données en transit | TLS 1.2 / TLS 1.3 | Version imposée sur tous les endpoints | À vérifier |
| Certificats applicatifs | X.509 | Validité, chaîne de confiance, expiration | À vérifier |
| Connexions API Graph | OAuth 2.0 / HTTPS | Token signé, scope minimal, HTTPS enforced | À vérifier |
Validation de la sécurité des API Microsoft Graph et du WAF Azure
La sécurité des API et connecteurs représente un vecteur d’attaque fréquemment sous-estimé lors des migrations. Les tests portant sur Microsoft Graph API doivent vérifier que les permissions accordées aux applications enregistrées respectent le principe de moindre privilège : aucun scope superflu, consentement administrateur explicite pour les permissions sensibles, et journalisation activée dans Microsoft Defender for Cloud Apps. En parallèle, la protection des API Microsoft Graph doit être complétée par une validation du Web Application Firewall (WAF) configuré sur Azure Application Gateway. Les règles OWASP Core Rule Set doivent être actives, les logs d’inspection accessibles et les politiques de blocage testées via des requêtes malformées contrôlées. Les équipes peuvent s’appuyer sur les référentiels DevSecOps publiés par Microsoft pour structurer ces vérifications de bout en bout.
Revue de configuration des restrictions locataires
La sécurisation des flux intertenant passe par une revue rigoureuse des politiques de contrôle d’accès externe. Selon Microsoft, la configuration de Tenant Restrictions V2 permet de réduire les risques d’accès non autorisé entre locataires en limitant l’accès des utilisateurs externes et en renforçant la sécurité des applications (Source : Microsoft — 2025-05-30). Le contrôle des restrictions locataires doit être réalisé en vérifiant que les politiques Tenant Restrictions V2 sont bien appliquées au niveau du proxy ou des en-têtes HTTP, que les tenants autorisés sont listés explicitement et que toute tentative d’accès vers un tenant non référencé est journalisée et bloquée. Ces tests complètent la revue des configurations de sécurité post-migration avant d’aborder les tests de résilience et de continuité de service.
Validation finale et suivi post-migration
La validation post-migration repose sur une campagne structurée de tests de non-régression et d’audit de conformité, destinée à confirmer que les applications et les politiques de sécurité fonctionnent correctement dans le nouveau tenant. Sans cette étape, des régressions silencieuses peuvent compromettre la stabilité ou la conformité RGPD post-migration.
Contrôle de la journalisation et de l’audit des événements de sécurité
La validation logs sécurité applicative constitue le premier réflexe à adopter après toute migration tenant to tenant. Il s’agit de vérifier que Microsoft Purview Audit collecte bien les événements attendus : accès aux fichiers sensibles, modifications de permissions, connexions suspectes. Un écart dans la remontée des journaux peut signaler une mauvaise configuration des connecteurs ou une rupture dans la chaîne de délégation d’administration.
Le suivi des journaux de sécurité doit également couvrir Microsoft 365 Defender, en s’assurant que les alertes générées dans l’environnement source continuent d’être correctement traitées dans le nouveau contexte. Il convient de paramétrer les rétentions de logs conformément aux exigences réglementaires applicables, notamment celles découlant du RGPD.
Tests de non-régression sur les applications principales
La campagne de tests post-migration doit couvrir en priorité Teams, SharePoint et OneDrive, qui concentrent l’essentiel des usages collaboratifs. Pour chaque application, il est recommandé de rejouer les scénarios métier critiques : partage de fichiers inter-équipes, accès conditionnel depuis un poste non géré, workflows déclenchés via Power Automate, ou encore formulaires déployés avec Power Apps.
La ressource Microsoft DevSecOps fournit un cadre de référence utile pour intégrer ces contrôles dans un processus de livraison continue. D’après ShareGate, il semble pertinent de s’appuyer sur une approche progressive : « Effectuer un test setup ou proof of concept avec petit environnement Microsoft 365 pour valider architecture et permissions avant migration complète », ce qui suggère que la logique de validation par paliers reste valable y compris en phase post-migration (Source : ShareGate — 2025-06-13).
| Application | Scénario à valider | Outil de contrôle |
|---|---|---|
| Microsoft Teams | Accès aux canaux, réunions, partages internes | Microsoft 365 Defender |
| SharePoint | Permissions de sites, héritage, recherche | Microsoft Purview Audit |
| OneDrive | Synchronisation, partage externe, DLP | Microsoft Purview Compliance Manager |
| Power Apps / Power Automate | Flux actifs, connecteurs, droits d’exécution | Centre d’administration Power Platform |
Vérification des scénarios de continuité de service (PRA/PCA)
Les tests de résilience applicative Microsoft 365 constituent le dernier volet de la validation finale. Il s’agit de simuler des incidents — indisponibilité d’un service, révocation d’accès accidentelle, perte de configuration conditionnelle — et de vérifier que les procédures de reprise d’activité (PRA) et de continuité d’activité (PCA) documentées restent opérationnelles dans le nouveau tenant. La validation de la continuité d’activité post-migration doit être formalisée dans un rapport signé avant toute décision de clôture du projet.
L’audit de conformité et sécurité mené via Microsoft Purview Compliance Manager permet de scorer l’environnement migré par rapport aux référentiels réglementaires retenus et d’identifier les actions correctives résiduelles. Ce bilan prépare directement la gouvernance continue abordée dans la prochaine étape.
Conclusion
Une migration tenant to tenant réussie repose avant tout sur un plan de tests de sécurité structuré, appliqué à chaque couche technologique avant toute mise en production. La maîtrise de ce processus constitue un avantage métier direct : elle réduit les risques d’incident, facilite l’audit de conformité et renforce la confiance des utilisateurs finaux.
Selon Microsoft, les Security Defaults de Microsoft Entra ID offrent une protection automatique dès la création d’un nouveau tenant, avec une prise d’effet dans les 24 heures (Source : Microsoft — 2024-09-27). Cette posture de sécurité initiale doit néanmoins être complétée par des contrôles approfondis couvrant Microsoft 365, Microsoft Defender Suite et l’ensemble des politiques d’accès conditionnels.
La gouvernance continue post-migration reste indispensable : les configurations évoluent, les menaces aussi. Un programme d’amélioration continue sécurité cloud, intégrant des revues périodiques et des tests de régression, garantit que la sécurisation post-migration tenant to tenant demeure effective dans la durée. Les équipes souhaitant approfondir les pratiques DevSecOps associées peuvent consulter les recommandations Microsoft DevSecOps.
