La sécurisation d’un tenant Microsoft 365 ne peut plus se limiter à l’activation de l’authentification multifacteur. Les environnements modernes reposent sur un ensemble de services interconnectés : Microsoft Entra ID, Exchange Online, Microsoft Teams, SharePoint Online, OneDrive, Microsoft Purview et Microsoft Defender.
Une compromission de l’identité d’un utilisateur ou d’un administrateur peut ainsi donner accès à sa messagerie, ses fichiers, ses conversations Teams, ses applications et ses données professionnelles.
Ce guide présente les principaux contrôles à mettre en œuvre pour protéger un tenant Microsoft 365, réduire sa surface d’attaque et améliorer sa capacité de détection et de réponse aux incidents.
Les objectifs de la sécurisation
La stratégie de sécurisation d’un tenant Microsoft 365 doit poursuivre plusieurs objectifs complémentaires :
- protéger les identités et les comptes à privilèges ;
- généraliser l’utilisation de l’authentification multifacteur ;
- contrôler les conditions d’accès aux services ;
- limiter le nombre de privilèges permanents ;
- sécuriser Exchange Online et la messagerie ;
- maîtriser le partage dans SharePoint Online, OneDrive et Teams ;
- contrôler les applications tierces et les consentements OAuth ;
- protéger les données sensibles ;
- journaliser les activités administratives ;
- détecter les comportements inhabituels ;
- préparer la réponse aux incidents de sécurité.
L’identité constitue désormais le premier périmètre de sécurité. Elle doit donc être placée au centre de l’architecture de protection du tenant.
1. Protéger les identités avec Microsoft Entra ID
Microsoft Entra ID fournit le socle d’identité et d’authentification de Microsoft 365.
Une compromission d’Entra ID peut permettre à un attaquant d’accéder simultanément à plusieurs services : Exchange Online, Teams, SharePoint Online, OneDrive et aux applications utilisant Entra ID comme fournisseur d’identité.
La sécurisation des identités doit donc être considérée comme une priorité critique.
Généraliser l’authentification multifacteur
L’authentification multifacteur, ou MFA, doit être imposée aux utilisateurs et tout particulièrement aux comptes disposant de privilèges administratifs.
Lorsque Conditional Access est disponible, il est préférable de centraliser les exigences d’authentification dans les stratégies d’accès conditionnel plutôt que de gérer la MFA séparément pour chaque utilisateur.
Une attention particulière doit être portée aux situations suivantes :
- accès aux portails d’administration ;
- accès depuis un équipement non maîtrisé ;
- accès depuis une localisation inhabituelle ;
- accès à une application sensible ;
- accès extérieur à l’organisation ;
- accès des comptes invités ;
- connexion présentant un niveau de risque élevé ;
- modification d’une méthode d’authentification.
Privilégier l’authentification résistante au phishing
Toutes les méthodes d’authentification multifacteur n’offrent pas le même niveau de protection.
Pour les comptes sensibles, il est recommandé d’étudier progressivement l’utilisation de mécanismes résistants au phishing, notamment :
- Windows Hello for Business ;
- les clés de sécurité FIDO2 ;
- les passkeys ;
- l’authentification par certificat lorsque le contexte le justifie.
Ces méthodes renforcent la protection contre les campagnes de phishing et les attaques visant à intercepter une session d’authentification.
2. Séparer les comptes d’administration
Un compte utilisé quotidiennement pour la messagerie, la navigation Internet et les tâches bureautiques ne devrait pas être utilisé pour administrer Microsoft 365.
Chaque administrateur devrait disposer d’au moins deux identités distinctes :
- un compte bureautique standard ;
- un compte administratif dédié.
Exemple de convention de nommage :
Compte bureautique : prenom.nom@organisation.mc
Compte administratif : prenom.nom.adm@organisation.mc
Le compte administratif doit respecter plusieurs règles :
- ne pas être utilisé pour la navigation Internet quotidienne ;
- ne pas être utilisé comme boîte aux lettres personnelle ;
- ne disposer que des rôles nécessaires ;
- bénéficier d’une authentification forte ;
- être soumis à des stratégies Conditional Access renforcées ;
- faire l’objet d’une surveillance spécifique ;
- ne pas être utilisé depuis un poste non maîtrisé.
3. Appliquer le principe du moindre privilège
Le rôle Global Administrator ne doit pas être attribué par défaut aux membres de l’équipe d’administration.
Il doit être réservé aux opérations qui nécessitent réellement ce niveau de privilège.
Pour les autres activités, il convient de privilégier des rôles spécialisés, par exemple :
- Exchange Administrator ;
- SharePoint Administrator ;
- Teams Administrator ;
- Security Administrator ;
- Compliance Administrator ;
- Conditional Access Administrator ;
- Authentication Administrator ;
- User Administrator.
Le principe directeur doit être le suivant :
Pas de privilège permanent lorsqu’un privilège temporaire peut suffire.
Une revue régulière des rôles doit permettre d’identifier :
- les comptes inutilement privilégiés ;
- les rôles devenus obsolètes ;
- les comptes inactifs ;
- les attributions permanentes qui pourraient devenir temporaires ;
- les comptes de service disposant de permissions excessives.
4. Déployer Privileged Identity Management
Lorsque les licences disponibles le permettent, Microsoft Entra Privileged Identity Management, ou PIM, permet de réduire l’exposition des comptes à privilèges.
L’utilisateur ne dispose alors pas obligatoirement d’un rôle administratif actif en permanence. Il doit activer temporairement son rôle lorsqu’il en a besoin.
L’activation peut être soumise à différentes conditions :
- authentification multifacteur ;
- justification ;
- durée limitée ;
- approbation ;
- notification ;
- vérification périodique de l’attribution.
Le fonctionnement cible peut être résumé ainsi :
Administrateur → demande d’activation → contrôle MFA → justification ou approbation → activation temporaire du rôle → expiration automatique.
Les rôles les plus sensibles doivent être traités en priorité :
- Global Administrator ;
- Privileged Role Administrator ;
- Security Administrator ;
- Conditional Access Administrator ;
- Exchange Administrator ;
- SharePoint Administrator.
5. Conserver des comptes d’accès d’urgence
L’organisation doit maintenir des comptes d’accès d’urgence, souvent appelés comptes Break Glass.
Ils permettent de reprendre le contrôle du tenant lorsqu’une défaillance du système d’authentification ou une mauvaise configuration de sécurité empêche les administrateurs habituels de se connecter.
Ces comptes doivent faire l’objet de mesures particulières :
- procédure d’utilisation documentée ;
- identifiants protégés ;
- surveillance systématique ;
- génération d’une alerte en cas de connexion ;
- tests réguliers ;
- contrôle des modifications ;
- limitation stricte de leur utilisation.
Les comptes d’urgence ne doivent jamais devenir des comptes d’administration ordinaires.
Toute utilisation de l’un de ces comptes doit provoquer une analyse afin d’en déterminer la cause et d’identifier les éventuelles actions correctives.
6. Structurer les stratégies Conditional Access
Conditional Access constitue l’un des principaux mécanismes de contrôle des accès à Microsoft 365.
Il permet d’appliquer des décisions de sécurité selon différents critères, comme l’identité de l’utilisateur, son rôle, la ressource demandée, le niveau de risque ou l’état de l’appareil.
CA01 : protection des administrateurs
Une stratégie spécifique doit protéger les comptes administratifs.
Elle peut notamment imposer :
- une authentification forte ;
- une fréquence d’authentification adaptée ;
- l’utilisation d’un appareil maîtrisé ;
- des méthodes d’authentification renforcées ;
- des restrictions d’accès selon le niveau de sensibilité.
Niveau de priorité : critique.
CA02 : protection générale des utilisateurs
Une stratégie doit imposer l’authentification multifacteur aux utilisateurs selon le niveau de risque et la politique de sécurité de l’organisation.
Niveau de priorité : critique.
CA03 : blocage de l’authentification héritée
Les anciens protocoles d’authentification peuvent contourner certaines protections modernes.
Ils doivent être recensés, surveillés, puis bloqués dès que les dépendances techniques ont été traitées.
Niveau de priorité : critique.
CA04 : traitement des utilisateurs à risque
Lorsque les fonctionnalités nécessaires sont disponibles, les utilisateurs présentant un niveau de risque doivent être soumis à des contrôles adaptés.
Ces contrôles peuvent comprendre une authentification renforcée, une réinitialisation sécurisée du mot de passe ou un blocage temporaire.
CA05 : traitement des connexions à risque
Une connexion détectée comme risquée doit déclencher une réponse proportionnée au niveau de risque.
La stratégie peut imposer une authentification supplémentaire ou bloquer l’accès lorsque le risque est jugé trop important.
CA06 : contrôle des équipements
Pour les ressources les plus sensibles, l’organisation peut conditionner l’accès à l’utilisation :
- d’un appareil conforme ;
- d’un appareil géré ;
- d’un poste institutionnel ;
- d’un système d’exploitation autorisé.
CA07 : gestion des localisations
Les Named Locations peuvent contribuer à l’évaluation du contexte de connexion.
Cependant, une adresse IP ou une localisation géographique ne doit pas être considérée comme une preuve suffisante de confiance. Elle doit constituer un signal parmi plusieurs autres.
Déployer progressivement les politiques
Toute nouvelle stratégie Conditional Access devrait d’abord être évaluée sur une population limitée.
Une démarche progressive permet de réduire le risque de blocage général :
- concevoir la stratégie ;
- identifier les exclusions strictement nécessaires ;
- utiliser le mode Report-only ;
- analyser les résultats ;
- tester sur une population pilote ;
- corriger les effets indésirables ;
- activer progressivement la stratégie ;
- documenter la configuration finale.
7. Protéger les jetons d’accès
L’utilisation de la MFA ne protège pas automatiquement contre tous les scénarios de compromission.
Un attaquant peut chercher à récupérer un jeton de session déjà délivré après une authentification légitime. Il peut ensuite tenter de réutiliser ce jeton depuis un autre appareil.
La stratégie de sécurisation doit donc intégrer :
- la protection des jetons lorsque le scénario est compatible ;
- la vérification de l’état des équipements ;
- la détection des connexions inhabituelles ;
- la révocation des sessions lors d’un incident ;
- la surveillance des changements de méthodes d’authentification ;
- la limitation de la durée des privilèges ;
- l’analyse des authentifications suspectes.
La Token Protection complète la MFA et Conditional Access. Elle ne les remplace pas.
8. Contrôler les applications et les consentements OAuth
Les applications intégrées à Microsoft Entra ID peuvent disposer de permissions importantes sur le tenant.
L’organisation doit régulièrement examiner :
- les Enterprise Applications ;
- les App registrations ;
- les permissions Microsoft Graph ;
- les permissions déléguées ;
- les permissions applicatives ;
- les consentements accordés par les utilisateurs ;
- les consentements accordés par un administrateur ;
- les secrets et certificats associés aux applications ;
- les applications inutilisées ;
- les propriétaires des applications.
Une application disposant de permissions applicatives sensibles peut fonctionner sans intervention directe d’un utilisateur. Une attention particulière doit donc être portée à ce type de permission.
Un processus formel devrait être mis en place :
Demande d’application → analyse de l’éditeur → analyse des permissions → validation de sécurité → consentement → mise en production → revue périodique.
Chaque application devrait disposer :
- d’un propriétaire identifié ;
- d’une justification métier ;
- d’une liste de permissions validées ;
- d’une date de révision ;
- d’une procédure de suppression ;
- d’une gestion maîtrisée des secrets et certificats.
9. Sécuriser Exchange Online
La messagerie demeure l’une des principales cibles des attaquants.
Elle constitue à la fois un vecteur d’entrée et une source importante d’informations sensibles.
Les contrôles doivent notamment porter sur :
- les protocoles de connexion ;
- les règles de transport ;
- les transferts automatiques ;
- les règles de boîte de réception ;
- les délégations ;
- les permissions Full Access ;
- les permissions Send As ;
- les permissions Send on Behalf ;
- les connecteurs ;
- les comptes techniques ;
- les applications ayant accès aux boîtes aux lettres ;
- les journaux d’audit ;
- les activités de connexion inhabituelles.
Les règles de transfert externe doivent être particulièrement surveillées. Elles peuvent être utilisées pour exfiltrer discrètement des messages.
10. Déployer SPF, DKIM et DMARC
Tous les domaines utilisés pour l’envoi de courriers doivent être recensés.
La protection des domaines de messagerie doit comprendre :
- SPF ;
- DKIM ;
- DMARC.
SPF permet de déclarer les infrastructures autorisées à envoyer des messages pour un domaine.
DKIM ajoute une signature cryptographique aux messages.
DMARC définit le traitement attendu lorsque les contrôles d’authentification ne sont pas satisfaisants et fournit des rapports permettant d’analyser les sources d’envoi.
Le passage vers une politique DMARC restrictive doit être progressif. Les sources légitimes doivent être identifiées avant d’appliquer une politique susceptible de rejeter des messages.
11. Renforcer la protection contre le phishing
Lorsque Microsoft Defender for Office 365 est disponible, ses fonctions doivent être configurées en cohérence avec le niveau de risque de l’organisation.
La protection doit couvrir :
- les tentatives de phishing ;
- l’usurpation de domaine ;
- l’usurpation d’utilisateurs ;
- les liens malveillants ;
- les pièces jointes malveillantes ;
- les campagnes d’attaque ;
- les messages provenant d’expéditeurs inhabituels.
Une protection renforcée doit être envisagée pour les populations particulièrement exposées :
- administrateurs ;
- dirigeants ;
- fonctions financières ;
- ressources humaines ;
- équipes de sécurité ;
- utilisateurs manipulant des données sensibles.
12. Sécuriser SharePoint Online et OneDrive
SharePoint Online et OneDrive concentrent une part importante des documents d’une organisation.
La gouvernance du partage est donc essentielle.
Les contrôles doivent porter sur :
- le partage externe ;
- les liens anonymes ;
- la durée de validité des liens ;
- les invités ;
- les permissions héritées ;
- les propriétaires de sites ;
- les sites sans propriétaire actif ;
- les applications ayant accès aux contenus ;
- le partage de documents sensibles ;
- la classification des informations.
Le niveau de partage autorisé doit être cohérent avec la sensibilité des données.
Les sites contenant des informations sensibles doivent faire l’objet de contrôles renforcés et de revues régulières.
13. Sécuriser Microsoft Teams
Microsoft Teams regroupe des conversations, des réunions, des fichiers et des accès externes.
Sa sécurisation doit couvrir plusieurs dimensions :
- création des équipes ;
- accès des invités ;
- accès externe ;
- fédération ;
- applications Teams ;
- stratégies de réunion ;
- enregistrement des réunions ;
- transcription ;
- partage d’écran ;
- gestion des participants anonymes ;
- permissions des organisateurs et présentateurs ;
- cycle de vie des équipes.
Les fichiers partagés dans Teams utilisent SharePoint Online et OneDrive. La gouvernance de Teams doit donc être cohérente avec les règles appliquées au partage documentaire.
14. Classifier les données avec Microsoft Purview
Microsoft Purview Information Protection permet d’organiser la classification et la protection des informations.
Une classification simple peut reposer sur trois niveaux :
Information Publique
Information dont la diffusion est autorisée et ne présente pas de risque particulier pour l’organisation.
Information Interne
Information destinée à un usage institutionnel ou professionnel interne.
Diffusion Restreinte
Information sensible nécessitant une protection renforcée et un contrôle strict de sa diffusion.
Selon la classification, les étiquettes peuvent être associées à différentes mesures :
- marquage visuel ;
- en-tête ou pied de page ;
- filigrane ;
- chiffrement ;
- restriction d’accès ;
- restriction du partage ;
- limitation de l’impression ;
- expiration de l’accès ;
- application automatique ou recommandée.
La politique de classification doit rester suffisamment simple pour être comprise par les utilisateurs.
15. Mettre en œuvre la prévention contre la fuite de données
Les mécanismes de Data Loss Prevention, ou DLP, permettent d’identifier certaines catégories d’informations et d’encadrer leur circulation.
Une politique DLP peut intervenir dans plusieurs services :
- Exchange Online ;
- SharePoint Online ;
- OneDrive ;
- Microsoft Teams ;
- applications de productivité compatibles.
Le déploiement doit être progressif.
Il est conseillé de commencer par un mode d’évaluation ou de simulation afin d’identifier les impacts avant de mettre en place des blocages.
Une politique trop restrictive peut perturber fortement les activités métier. À l’inverse, une politique trop permissive ne réduit pas suffisamment le risque de fuite d’informations.
16. Activer la journalisation et l’audit
Un tenant sécurisé doit également être observable.
L’organisation doit être en mesure de retrouver les événements importants concernant :
- les authentifications ;
- les changements de méthodes MFA ;
- les modifications administratives ;
- les changements de rôles ;
- les modifications Conditional Access ;
- les opérations Exchange Online ;
- les activités SharePoint Online ;
- les consentements applicatifs ;
- les modifications d’applications ;
- les opérations sur les données sensibles ;
- les événements de sécurité.
Les journaux doivent être accessibles aux équipes chargées de la sécurité.
Lorsque l’architecture le prévoit, les événements peuvent être centralisés dans un SIEM tel que Microsoft Sentinel afin de faciliter leur corrélation et leur exploitation.
17. Configurer les alertes de sécurité
Des alertes doivent être prévues pour les scénarios les plus sensibles.
Les principaux cas d’usage comprennent :
- connexion administrative inhabituelle ;
- utilisation d’un compte d’urgence ;
- attribution d’un rôle privilégié ;
- modification d’une stratégie Conditional Access ;
- ajout d’une méthode d’authentification ;
- consentement accordé à une application sensible ;
- création d’une application disposant de permissions importantes ;
- activité de messagerie suspecte ;
- création d’une règle de transfert ;
- téléchargement massif de fichiers ;
- activité inhabituelle sur un compte utilisateur.
Une alerte doit être associée à une procédure de traitement. Sans processus de qualification et de réponse, l’accumulation d’alertes risque de produire une fatigue opérationnelle.
18. Préparer la réponse aux incidents
La sécurité ne doit pas uniquement chercher à empêcher les attaques. Elle doit également prévoir les actions à mener lorsqu’un incident survient.
Pour les scénarios principaux, l’organisation doit formaliser des procédures comprenant les étapes suivantes :
Détection → qualification → confinement → révocation des accès → investigation → correction → rétablissement → retour d’expérience.
Un playbook consacré à la compromission d’un compte Microsoft 365 devrait au minimum traiter les opérations suivantes :
- vérifier l’identité et l’activité du compte ;
- bloquer temporairement la connexion si nécessaire ;
- révoquer les sessions actives ;
- réinitialiser les secrets concernés ;
- contrôler les méthodes d’authentification ;
- vérifier les règles de boîte de réception ;
- vérifier les délégations ;
- contrôler les consentements applicatifs ;
- analyser les authentifications ;
- rechercher des activités similaires sur d’autres comptes ;
- documenter l’incident ;
- corriger la cause initiale.
19. Gouverner les changements
Les modifications affectant les composants critiques du tenant doivent être documentées et validées.
Cela concerne notamment :
- les stratégies Conditional Access ;
- les méthodes d’authentification ;
- les rôles Entra ID ;
- les configurations Exchange Online ;
- les politiques Microsoft Purview ;
- les applications OAuth ;
- les paramètres de partage ;
- les connecteurs ;
- les stratégies Teams ;
- les paramètres de sécurité.
Pour les changements sensibles, le cycle recommandé est le suivant :
Préparation → préproduction ou pilote → validation → changement → contrôle → documentation.
Chaque changement doit prévoir une procédure de retour arrière lorsque celle-ci est techniquement possible.
20. Utiliser Microsoft Secure Score avec discernement
Microsoft Secure Score peut être utilisé comme indicateur pour identifier des améliorations possibles.
Il ne doit cependant pas devenir l’unique objectif de la stratégie de sécurité.
Avant d’appliquer une recommandation, il convient d’évaluer :
- le risque réellement réduit ;
- les licences nécessaires ;
- l’impact sur les utilisateurs ;
- la compatibilité avec l’architecture ;
- la population concernée ;
- les contraintes métier ;
- les éventuelles dépendances techniques.
L’objectif n’est pas d’obtenir le score maximal, mais d’atteindre un niveau de sécurité cohérent avec les risques et les usages de l’organisation.
21. Prioriser les actions de sécurisation
La sécurisation doit être progressive et pilotée selon le niveau de risque.
Priorité 1 : mesures critiques
- sécuriser les comptes administrateurs ;
- séparer les comptes bureautiques et administratifs ;
- généraliser l’authentification multifacteur ;
- mettre en place les stratégies Conditional Access essentielles ;
- sécuriser les comptes d’urgence ;
- bloquer les mécanismes d’authentification obsolètes ;
- réduire les privilèges permanents ;
- contrôler les applications OAuth ;
- vérifier les protections de la messagerie.
Priorité 2 : mesures importantes
- déployer PIM lorsque les licences le permettent ;
- renforcer les méthodes d’authentification ;
- sécuriser Teams ;
- maîtriser le partage SharePoint Online et OneDrive ;
- structurer Microsoft Purview Information Protection ;
- mettre en place les alertes ;
- formaliser les procédures de réponse aux incidents ;
- organiser les revues périodiques des accès.
Priorité 3 : amélioration de la maturité
- généraliser les mécanismes résistants au phishing ;
- renforcer la protection des jetons et des sessions ;
- développer les politiques DLP ;
- automatiser les contrôles de conformité ;
- centraliser les événements dans un SIEM ;
- tester régulièrement les procédures de sécurité ;
- intégrer la sécurité dans la gouvernance des changements.
22. Checklist d’audit du tenant
La matrice suivante peut être utilisée comme point de départ pour un audit.
Identités et administration
- La MFA est activée pour les administrateurs.
- La MFA est généralisée aux utilisateurs.
- Les comptes administratifs sont séparés des comptes bureautiques.
- Le nombre de Global Administrators est maîtrisé.
- Les rôles spécialisés sont utilisés.
- Les attributions de rôles sont régulièrement révisées.
- PIM est utilisé lorsque les licences le permettent.
- Les comptes d’urgence sont documentés.
- Les comptes d’urgence sont testés.
- Une alerte est générée lors de leur utilisation.
Conditional Access
- Une stratégie protège les administrateurs.
- Une stratégie impose la MFA.
- L’authentification héritée est bloquée.
- Les comptes de service sont recensés.
- Les exclusions sont documentées.
- Les politiques sont testées en Report-only.
- Les connexions à risque sont traitées.
- Les utilisateurs à risque sont traités.
- Les appareils non maîtrisés font l’objet de restrictions adaptées.
Applications
- Les Enterprise Applications sont recensées.
- Les App registrations sont recensées.
- Les permissions Microsoft Graph sont contrôlées.
- Les consentements administrateurs sont révisés.
- Les applications inutilisées sont supprimées.
- Les secrets expirés ou anciens sont identifiés.
- Chaque application possède un propriétaire.
Exchange Online
- Les règles de transfert externe sont maîtrisées.
- Les permissions de boîte aux lettres sont contrôlées.
- Les connecteurs sont documentés.
- Les protocoles obsolètes sont bloqués.
- SPF est configuré.
- DKIM est configuré.
- DMARC est configuré.
- Les protections contre le phishing sont vérifiées.
- Les règles de boîte de réception suspectes peuvent être recherchées.
Teams, SharePoint Online et OneDrive
- Le partage externe est maîtrisé.
- Les liens anonymes sont contrôlés.
- Les invités sont régulièrement révisés.
- Les sites sensibles sont identifiés.
- Les propriétaires de sites sont connus.
- La création des équipes est gouvernée.
- Les applications Teams sont contrôlées.
- Les stratégies de réunion sont adaptées.
Purview et protection des données
- Une classification des informations est définie.
- Les étiquettes de sensibilité sont documentées.
- Les politiques de publication sont maîtrisées.
- Les effets du chiffrement sont testés.
- Les scénarios de changement d’étiquette sont testés.
- Les politiques DLP sont évaluées.
- Les utilisateurs disposent d’une documentation adaptée.
Surveillance et incidents
- L’audit est activé et exploitable.
- Les changements administratifs sont surveillés.
- Les rôles privilégiés font l’objet d’alertes.
- Les comptes d’urgence font l’objet d’alertes.
- Les consentements sensibles sont surveillés.
- Une procédure de compromission de compte existe.
- Les procédures de sécurité sont régulièrement testées.
- Les incidents sont documentés.
Conclusion
La sécurisation d’un tenant Microsoft 365 repose sur une approche globale combinant identité, contrôle des accès, protection des données, surveillance et gouvernance.
Les premières actions doivent porter sur les comptes administratifs, l’authentification multifacteur, Conditional Access, les comptes d’urgence et la maîtrise des privilèges.
La protection doit ensuite être étendue aux applications OAuth, à Exchange Online, à Teams, à SharePoint Online, à OneDrive et aux informations sensibles avec Microsoft Purview.
Enfin, la journalisation, les alertes et les procédures de réponse aux incidents permettent de transformer un ensemble de configurations techniques en un dispositif de sécurité réellement opérationnel.
La sécurité d’un tenant Microsoft 365 n’est pas un projet ponctuel. Elle nécessite des contrôles réguliers, des revues de configuration, des tests et une adaptation continue aux nouveaux usages et aux nouvelles menaces.
