Microsoft Exchange Online est au cœur de la communication d’une organisation. Une boîte aux lettres contient bien plus que des messages : informations métier, pièces jointes, calendriers, contacts, historiques de conversation et parfois des données sensibles.
La messagerie constitue également une cible privilégiée pour les cyberattaquants :
- phishing ;
- usurpation d’identité ;
- compromission de comptes ;
- attaque BEC, ou Business Email Compromise ;
- fraude au président ;
- distribution de logiciels malveillants ;
- vol de jetons de session ;
- exfiltration d’informations ;
- détournement des flux de messagerie.
La sécurisation d’Exchange Online doit donc s’inscrire dans une stratégie globale intégrant Microsoft Entra ID, Microsoft Defender for Office 365, Microsoft Purview, Microsoft Intune et les mécanismes de supervision de Microsoft 365.
1. Les objectifs de la sécurisation d’Exchange Online
Une stratégie de sécurisation d’Exchange Online doit permettre de :
- protéger les identités et les comptes à privilèges ;
- empêcher l’usurpation des domaines de messagerie ;
- réduire les risques de phishing et de fraude ;
- bloquer les pièces jointes et les liens malveillants ;
- maîtriser les protocoles et les méthodes d’accès ;
- encadrer les transferts automatiques ;
- contrôler les permissions sur les boîtes aux lettres ;
- sécuriser les applications accédant aux messages ;
- protéger les informations sensibles ;
- journaliser les opérations importantes ;
- détecter les comportements anormaux ;
- préparer la réponse aux incidents.
La sécurisation ne doit pas reposer sur un paramètre isolé. Elle doit former un ensemble cohérent de contrôles administratifs, techniques et organisationnels.
2. Protéger les identités avec Microsoft Entra ID
La première protection d’Exchange Online se situe dans Microsoft Entra ID.
Un attaquant qui compromet l’identité d’un utilisateur peut accéder à sa boîte aux lettres sans avoir besoin d’attaquer directement l’infrastructure Exchange Online.
Les mesures prioritaires comprennent :
- la généralisation de l’authentification multifacteur ;
- la protection renforcée des administrateurs ;
- l’utilisation de Conditional Access ;
- le contrôle des terminaux ;
- la surveillance des connexions à risque ;
- la révocation rapide des sessions en cas d’incident ;
- la maîtrise des méthodes d’authentification.
Généraliser l’authentification multifacteur
La MFA doit être imposée aux utilisateurs autorisés à accéder à Exchange Online.
Une politique renforcée doit être appliquée aux comptes sensibles :
- Global Administrator ;
- Exchange Administrator ;
- Security Administrator ;
- Authentication Administrator ;
- Conditional Access Administrator ;
- comptes de support ;
- comptes techniques disposant de privilèges.
Pour les populations sensibles, privilégier progressivement les méthodes résistantes au phishing :
- Windows Hello for Business ;
- clés de sécurité FIDO2 ;
- passkeys ;
- authentification par certificat lorsque l’architecture le justifie.
Séparer les comptes d’administration
Un administrateur ne devrait pas utiliser son compte bureautique quotidien pour administrer Exchange Online.
Exemple de séparation :
Plain Text
Compte bureautique
prenom.nom@organisation.mc
Compte administratif
prenom.nom.adm@organisation.mc
Le compte administratif ne doit normalement pas être utilisé pour :
- consulter la messagerie quotidienne ;
- naviguer sur Internet ;
- utiliser les applications bureautiques ;
- participer aux réunions ;
- accéder à des services externes ;
- effectuer des opérations sans rapport avec l’administration.
Cette séparation réduit l’exposition des identités privilégiées.
3. Appliquer le principe du moindre privilège
Le rôle Global Administrator ne doit pas être attribué systématiquement aux personnes chargées d’Exchange Online.
Pour les opérations de messagerie, privilégier les rôles spécialisés lorsque cela est possible :
- Exchange Administrator ;
- Exchange Recipient Administrator ;
- Security Administrator ;
- Compliance Administrator ;
- Global Reader pour les activités de consultation ;
- rôles Exchange personnalisés lorsque la séparation fonctionnelle l’exige.
Le principe directeur doit rester simple :
Aucun privilège permanent lorsqu’un privilège limité ou temporaire peut répondre au besoin.
Les rôles doivent être régulièrement révisés afin de détecter :
- les comptes disposant de droits excessifs ;
- les attributions devenues inutiles ;
- les comptes inactifs ;
- les privilèges permanents à remplacer par une activation temporaire ;
- les comptes de service disposant de permissions trop importantes.
Lorsque les licences le permettent, Microsoft Entra Privileged Identity Management peut servir à encadrer l’activation temporaire des rôles.
4. Protéger Exchange Online avec Conditional Access
Conditional Access permet d’appliquer des décisions de sécurité selon le contexte de connexion.
Les stratégies peuvent notamment tenir compte :
- de l’identité ;
- du rôle administratif ;
- de l’application utilisée ;
- de l’état du terminal ;
- du niveau de risque ;
- de la localisation ;
- du type de client ;
- de la ressource demandée.
Une baseline peut comprendre les politiques suivantes :
CA01 : protection des administrateurs
Imposer une authentification résistante au phishing et, lorsque l’architecture le permet, l’utilisation d’un appareil maîtrisé.
CA02 : protection des utilisateurs
Exiger une authentification multifacteur pour l’accès à Exchange Online.
CA03 : blocage des mécanismes hérités
Bloquer les méthodes d’authentification anciennes qui ne prennent pas correctement en charge les contrôles modernes.
CA04 : utilisateurs à risque
Appliquer une réponse adaptée aux comptes présentant un risque identifié.
CA05 : connexions à risque
Renforcer l’authentification ou bloquer une tentative selon le niveau de risque.
CA06 : terminaux non maîtrisés
Limiter le téléchargement ou l’accès aux données depuis les appareils non gérés.
CA07 : comptes administratifs
Appliquer des conditions plus strictes aux comptes disposant de rôles privilégiés.
Toute nouvelle stratégie doit être déployée progressivement :
- définir l’objectif de sécurité ;
- identifier les populations concernées ;
- documenter les exclusions ;
- utiliser le mode Report-only ;
- analyser les résultats ;
- tester sur une population pilote ;
- corriger les impacts indésirables ;
- activer progressivement la politique.
5. Bloquer l’authentification héritée
Les protocoles et clients anciens peuvent réduire l’efficacité des mécanismes modernes de protection.
L’objectif doit être de bloquer les mécanismes hérités lorsque les dépendances techniques ont été traitées.
Avant toute désactivation, il convient d’identifier :
- les applications anciennes ;
- les équipements multifonctions ;
- les scripts ;
- les applications métier ;
- les systèmes de supervision ;
- les systèmes utilisant encore une authentification non moderne.
La désactivation doit être accompagnée d’une phase d’observation afin d’éviter l’interruption d’un service métier légitime.
6. Désactiver SMTP AUTH lorsqu’il n’est pas nécessaire
SMTP AUTH peut rester utilisé par certains équipements, scripts ou applications.
Cependant, Microsoft recommande de désactiver SMTP AUTH lorsque son utilisation n’est pas nécessaire. [learn.microsoft.com]
Le modèle de gouvernance recommandé est le suivant :
Plain Text
SMTP AUTH désactivé par défaut
↓
Besoin métier identifié
↓
Analyse de sécurité
↓
Exception limitée
↓
Compte dédié
↓
Surveillance
↓
Révision périodique
Évitez d’activer SMTP AUTH globalement pour répondre au besoin d’un seul périphérique.
Pour chaque exception, documenter :
- l’application ou le périphérique ;
- le compte utilisé ;
- le propriétaire du service ;
- la justification ;
- le volume d’envoi attendu ;
- les adresses sources ;
- les destinataires autorisés ;
- les mesures de surveillance ;
- la date de révision.
7. Inventorier les sources d’envoi
Avant de sécuriser les domaines de messagerie, il faut recenser tous les systèmes capables d’envoyer des courriers au nom de l’organisation.
L’inventaire doit couvrir :
- Exchange Online ;
- Exchange Server en environnement hybride ;
- applications métier ;
- imprimantes et scanners ;
- systèmes de supervision ;
- plateformes de newsletters ;
- services d’envoi transactionnel ;
- portails institutionnels ;
- outils de réservation ;
- services d’alerte ;
- prestataires externes.
Pour chaque source, documenter :
- le domaine utilisé dans le champ From ;
- le domaine utilisé pour l’enveloppe SMTP ;
- les adresses IP ;
- le fournisseur ;
- la méthode d’authentification ;
- le support de SPF ;
- le support de DKIM ;
- le volume attendu ;
- le propriétaire métier et technique.
Cet inventaire est indispensable avant le déploiement d’une politique DMARC restrictive.
8. Configurer SPF
SPF, ou Sender Policy Framework, permet d’identifier les sources autorisées à envoyer du courrier pour un domaine.
SPF utilise un enregistrement TXT publié dans le DNS. Le système destinataire vérifie si la source du message fait partie des sources déclarées pour le domaine utilisé lors de la transmission SMTP. [learn.microsoft.com]
Dans une configuration simple utilisant uniquement Exchange Online, un enregistrement peut ressembler à ceci :
Plain Text
v=spf1 include:spf.protection.outlook.com -all
Cet exemple ne doit pas être repris sans analyse si d’autres services envoient du courrier pour le domaine.
Points de vigilance
- conserver un seul enregistrement SPF par domaine ;
- inventorier toutes les sources légitimes ;
- éviter d’ajouter des fournisseurs inutilisés ;
- supprimer les anciennes sources ;
- contrôler les mécanismes
include; - surveiller les erreurs DNS ;
- utiliser une terminaison cohérente avec la politique retenue.
SPF ne protège pas seul le domaine visible par l’utilisateur dans le champ From. Il doit être complété par DKIM et DMARC.
9. Activer DKIM
DKIM, ou DomainKeys Identified Mail, ajoute une signature numérique aux messages.
Dans Exchange Online, les clés publiques nécessaires à la validation sont publiées dans le DNS au moyen d’enregistrements CNAME. Le système destinataire utilise la clé publique correspondante afin de vérifier la signature du message. [learn.microsoft.com]
DKIM doit être activé sur chaque domaine personnalisé utilisé pour envoyer du courrier.
Contrôles recommandés
- activer DKIM sur tous les domaines d’envoi ;
- vérifier la présence des enregistrements DNS ;
- tester la signature des messages ;
- contrôler le domaine indiqué dans la signature ;
- documenter les sélecteurs utilisés ;
- planifier la rotation des clés ;
- vérifier les plateformes tierces ;
- supprimer les anciennes configurations inutiles.
Les plateformes de mailing et les services SaaS doivent signer les messages avec un domaine cohérent avec l’identité de l’organisation.
10. Déployer DMARC
DMARC complète SPF et DKIM.
DMARC vérifie notamment l’alignement entre le domaine visible dans le champ From et les domaines validés par SPF ou DKIM. Une politique DMARC indique également le traitement demandé lorsqu’un message échoue aux contrôles. [learn.microsoft.com]
Les politiques possibles sont :
Plain Text
p=none
Observation des résultats sans demande de mise en quarantaine ou de rejet.
Plain Text
p=quarantine
Demande de traitement renforcé des messages en échec.
Plain Text
p=reject
Demande de rejet des messages échouant à DMARC.
Trajectoire recommandée
Plain Text
Inventaire des sources
↓
SPF correctement configuré
↓
DKIM activé
↓
DMARC p=none
↓
Analyse des rapports
↓
Correction des sources
↓
Déploiement progressif de p=quarantine
↓
Validation
↓
Passage maîtrisé vers p=reject
Microsoft recommande l’utilisation combinée de SPF, DKIM et DMARC pour obtenir la meilleure protection contre l’usurpation et le phishing. [learn.microsoft.com]
Sous-domaines et domaines inactifs
Les domaines secondaires, domaines défensifs et domaines inactifs doivent également être examinés.
Un domaine qui n’envoie normalement aucun courrier doit bénéficier d’une politique empêchant son utilisation abusive.
11. Exploiter les rapports DMARC
Le déploiement de DMARC doit être accompagné d’une surveillance des rapports.
Ces rapports permettent d’identifier :
- les sources légitimes ;
- les systèmes oubliés ;
- les erreurs SPF ;
- les signatures DKIM absentes ou incorrectes ;
- les défauts d’alignement ;
- les services tiers non documentés ;
- les tentatives d’usurpation.
L’organisation doit désigner un responsable de leur analyse et définir une fréquence de revue.
Chaque nouvelle source d’envoi doit passer par un processus de validation avant d’être ajoutée à la configuration SPF ou DMARC.
12. Utiliser ARC avec discernement
Authenticated Received Chain, ou ARC, permet de préserver des informations d’authentification lorsque des services intermédiaires modifient les messages pendant leur transport.
Microsoft inclut ARC dans les mécanismes complémentaires d’authentification des messages et explique qu’il peut conserver les résultats d’authentification originaux lorsqu’un service intermédiaire modifie un message. [learn.microsoft.com]
Les éventuels ARC sealers approuvés doivent être limités à des services identifiés et de confiance.
13. Renforcer la protection anti-phishing
Le phishing vise à convaincre l’utilisateur :
- de communiquer ses identifiants ;
- d’ouvrir un fichier ;
- de suivre un lien ;
- d’autoriser une application ;
- d’effectuer un paiement ;
- de modifier des coordonnées bancaires ;
- de transmettre une information sensible.
Lorsque Microsoft Defender for Office 365 est disponible, les stratégies doivent être adaptées au niveau de risque de l’organisation.
Une attention particulière doit être portée aux populations exposées :
- direction ;
- fonctions financières ;
- ressources humaines ;
- administrateurs ;
- équipes de sécurité ;
- assistantes et secrétariats ;
- personnes autorisées à valider des paiements ;
- collaborateurs accessibles depuis l’extérieur.
Utilisateurs protégés
Les identités susceptibles d’être usurpées doivent être explicitement recensées.
L’objectif est de mieux détecter les messages imitant :
- un dirigeant ;
- un responsable financier ;
- un compte administratif ;
- un service institutionnel ;
- un domaine partenaire ;
- une adresse interne.
14. Protéger contre l’usurpation
L’usurpation peut prendre différentes formes :
- imitation d’un domaine ;
- imitation d’un utilisateur ;
- modification du nom d’affichage ;
- utilisation d’un domaine très proche ;
- utilisation d’un sous-domaine trompeur ;
- message provenant d’un domaine compromis.
La protection ne doit donc pas reposer uniquement sur le domaine de l’expéditeur.
Les contrôles doivent inclure :
- SPF ;
- DKIM ;
- DMARC ;
- politiques anti-phishing ;
- protection contre l’usurpation ;
- sensibilisation des utilisateurs ;
- signalement des messages suspects ;
- procédures de validation hors messagerie pour les opérations sensibles.
Pour une demande financière ou un changement de coordonnées bancaires, prévoir systématiquement une validation via un canal indépendant.
15. Identifier les expéditeurs externes
L’identification des messages externes permet aux utilisateurs de mieux distinguer les correspondants internes et externes.
Microsoft recommande que les messages entrants externes soient facilement identifiables, par exemple au moyen d’une indication dans l’objet ou dans le contenu du message. [learn.microsoft.com]
Dans une organisation moderne, il est préférable d’évaluer les mécanismes natifs d’identification des expéditeurs externes avant de modifier massivement l’objet ou le corps des messages.
Une bannière ou un indicateur ne constitue toutefois pas une protection suffisante. Les utilisateurs peuvent progressivement ne plus y prêter attention.
16. Protéger les liens
Les liens constituent l’un des principaux vecteurs de phishing.
La stratégie doit prendre en compte :
- les liens présents dans les messages ;
- les redirections ;
- les URL raccourcies ;
- les liens vers des services de partage ;
- les liens modifiés après la livraison ;
- les liens utilisés dans les pièces jointes.
Lorsque les licences le permettent, Microsoft Defender for Office 365 peut renforcer le contrôle des liens.
Les utilisateurs doivent pouvoir signaler rapidement un lien suspect et recevoir une procédure simple :
- ne pas ouvrir le lien ;
- ne pas transférer le message à plusieurs personnes ;
- utiliser le mécanisme de signalement prévu ;
- avertir l’équipe de sécurité si une action a déjà été réalisée.
17. Protéger les pièces jointes
Les pièces jointes peuvent contenir :
- logiciels malveillants ;
- macros ;
- scripts ;
- archives protégées ;
- fichiers exécutables ;
- documents exploitant une vulnérabilité ;
- liens indirects vers une charge malveillante.
Les protections doivent couvrir :
- l’analyse anti-malware ;
- le traitement des pièces jointes inconnues ;
- le blocage de certains types de fichiers ;
- la quarantaine ;
- les alertes ;
- l’investigation des campagnes ;
- la protection de SharePoint Online, OneDrive et Teams lorsque nécessaire.
Les extensions à risque doivent faire l’objet d’une politique documentée, adaptée aux besoins métier.
18. Maîtriser les listes d’autorisation
Les listes d’autorisation peuvent créer des contournements importants.
Évitez les autorisations trop larges basées uniquement sur :
- une adresse IP ;
- un domaine complet ;
- une adresse d’expéditeur ;
- une règle de transport qui fixe artificiellement le niveau de confiance.
Toute exception doit être :
- justifiée ;
- limitée ;
- documentée ;
- surveillée ;
- datée ;
- révisée ;
- supprimée dès qu’elle n’est plus nécessaire.
Une autorisation permanente ne doit pas être utilisée pour masquer un défaut SPF, DKIM ou DMARC.
19. Sécuriser les connecteurs Exchange Online
Les connecteurs contrôlent certains flux entre Exchange Online et des systèmes externes.
Ils peuvent être utilisés pour :
- un environnement hybride ;
- une passerelle de messagerie ;
- un relais applicatif ;
- un prestataire ;
- un service de signature ;
- une plateforme d’archivage ;
- un système métier.
Chaque connecteur doit disposer :
- d’un propriétaire ;
- d’une justification ;
- d’une direction de flux ;
- de conditions d’utilisation précises ;
- d’un mécanisme d’authentification ;
- d’une surveillance ;
- d’une date de revue ;
- d’une procédure de retrait.
Les connecteurs obsolètes ou associés à des infrastructures retirées doivent être supprimés.
20. Auditer les règles de transport
Les règles de flux de messagerie peuvent :
- rediriger un message ;
- ajouter ou supprimer un en-tête ;
- modifier l’objet ;
- appliquer un avertissement ;
- bloquer une pièce jointe ;
- contourner un contrôle ;
- transférer un message vers un destinataire externe.
Une revue régulière doit permettre d’identifier :
- les règles sans propriétaire ;
- les anciennes règles ;
- les exceptions trop larges ;
- les règles désactivées ;
- les règles contournant le filtrage ;
- les redirections externes ;
- les priorités incohérentes ;
- les règles créées pour un test puis oubliées.
Pour chaque règle sensible, documenter l’objectif, le propriétaire, la date de création et les conditions de suppression.
21. Bloquer ou limiter les transferts automatiques externes
Une règle de transfert externe peut être utilisée pour exfiltrer discrètement des messages.
Le risque concerne :
- les règles Inbox ;
- les paramètres de transfert de boîte aux lettres ;
- les règles de transport ;
- certaines configurations applicatives ;
- les délégations.
La politique recommandée consiste à bloquer le transfert automatique externe par défaut, puis à gérer les besoins légitimes comme des exceptions formelles.
Une exception doit préciser :
- la boîte concernée ;
- le destinataire externe ;
- la justification ;
- le propriétaire métier ;
- la durée ;
- les informations susceptibles d’être transférées ;
- le niveau de validation requis.
22. Surveiller les règles Inbox suspectes
Après une compromission, un attaquant peut créer une règle de boîte de réception pour :
- transférer les messages ;
- masquer les réponses ;
- supprimer les alertes ;
- déplacer certains messages ;
- surveiller une conversation financière ;
- intercepter les échanges avec un partenaire.
Les règles Inbox doivent être examinées lors de toute suspicion de compromission.
Les signes d’alerte peuvent comprendre :
- une règle récemment créée ;
- un nom inhabituel ;
- un transfert externe ;
- une suppression automatique ;
- un déplacement vers un dossier peu visible ;
- une règle ciblant des termes financiers ;
- une règle désactivée mais toujours présente.
23. Contrôler les permissions des boîtes aux lettres
Les permissions Exchange Online doivent faire l’objet de revues périodiques.
Les principales délégations sont :
- Full Access ;
- Send As ;
- Send on Behalf.
Pour chaque délégation, il faut vérifier :
- la justification ;
- le bénéficiaire ;
- la date d’attribution ;
- la durée nécessaire ;
- le propriétaire de la boîte ;
- la sensibilité des messages ;
- la traçabilité de l’utilisation.
Les délégations accordées à des groupes sont parfois plus difficiles à analyser. Il faut également connaître les membres réels de ces groupes.
24. Sécuriser les boîtes aux lettres partagées
Les boîtes partagées nécessitent une gouvernance spécifique.
Chaque boîte doit disposer :
- d’un propriétaire métier ;
- d’un usage documenté ;
- d’une liste maîtrisée de délégués ;
- d’une politique de conservation ;
- d’un niveau de sensibilité ;
- d’une date de révision ;
- d’une procédure de suppression.
Évitez l’usage direct d’un mot de passe partagé.
L’accès doit être accordé aux identités nominatives au moyen des permissions appropriées.
Les boîtes inutilisées ou sans propriétaire doivent être identifiées et traitées.
25. Maîtriser les applications OAuth et Microsoft Graph
Une application peut accéder aux messages sans utiliser les protocoles habituels d’un client de messagerie.
Les permissions Microsoft Graph doivent donc être examinées avec attention.
Il faut inventorier :
- les Enterprise Applications ;
- les App registrations ;
- les permissions déléguées ;
- les permissions applicatives ;
- les consentements administrateurs ;
- les secrets ;
- les certificats ;
- les propriétaires des applications ;
- les applications inutilisées.
Une application disposant d’une permission applicative étendue peut représenter un périmètre d’accès considérable.
Le processus recommandé est le suivant :
Plain Text
Demande d’application
↓
Analyse de l’éditeur
↓
Analyse des permissions
↓
Validation sécurité
↓
Consentement administrateur
↓
Surveillance
↓
Revue périodique
26. Protéger les appareils mobiles
L’accès à Exchange Online depuis un appareil mobile doit être intégré à la stratégie de sécurité.
Les points à examiner comprennent :
- appareils gérés ou non gérés ;
- applications de messagerie autorisées ;
- conformité du terminal ;
- chiffrement de l’appareil ;
- code de déverrouillage ;
- version du système ;
- effacement sélectif ;
- protection des données de l’application ;
- copier-coller vers des applications personnelles ;
- téléchargement des pièces jointes.
Lorsque Microsoft Intune est disponible, les politiques de protection des applications peuvent compléter Conditional Access.
27. Protéger les données avec Microsoft Purview
Microsoft Purview permet de renforcer la protection des informations présentes dans les messages et les pièces jointes.
Une classification peut par exemple s’appuyer sur les niveaux suivants :
Information Publique
Information pouvant être diffusée sans restriction particulière.
Information Interne
Information réservée à un usage institutionnel ou professionnel interne.
Diffusion Restreinte
Information sensible nécessitant des restrictions d’accès et de diffusion.
Selon la classification, les contrôles peuvent comprendre :
- marquage ;
- chiffrement ;
- restrictions d’accès ;
- contrôle du transfert ;
- contrôle de l’impression ;
- expiration ;
- limitation à certaines identités ;
- application d’une politique DLP.
28. Déployer des politiques DLP
Les politiques Data Loss Prevention permettent de détecter et de contrôler la circulation d’informations sensibles.
Elles peuvent notamment intervenir lors de l’envoi :
- de données personnelles ;
- d’informations financières ;
- de documents sensibles ;
- de données réglementées ;
- de volumes inhabituels d’informations ;
- d’informations vers un destinataire externe.
Le déploiement doit être progressif :
- identifier les données sensibles ;
- définir les scénarios à risque ;
- créer une politique pilote ;
- utiliser le mode de simulation ou d’audit ;
- analyser les résultats ;
- réduire les faux positifs ;
- sensibiliser les utilisateurs ;
- activer les restrictions nécessaires.
Un blocage général sans phase d’analyse peut perturber les activités métier.
29. Définir les politiques de conservation
La conservation des messages doit répondre aux exigences métier, juridiques, réglementaires et institutionnelles.
Les décisions doivent porter sur :
- la durée de conservation ;
- les populations concernées ;
- les types de boîtes aux lettres ;
- les messages à conserver ;
- les conditions de suppression ;
- les besoins d’investigation ;
- les obligations de preuve ;
- la gestion des départs ;
- la conservation en cas de contentieux.
Il faut éviter de confondre sauvegarde, rétention, archivage et conservation réglementaire. Ces mécanismes répondent à des objectifs distincts.
30. Activer et exploiter l’audit
Un environnement sécurisé doit être observable.
La journalisation doit permettre d’investiguer :
- les connexions ;
- les opérations administratives ;
- les modifications de règles ;
- les changements de permissions ;
- les activités sur les boîtes ;
- les consentements applicatifs ;
- les mouvements de messages ;
- les actions de suppression ;
- les modifications de connecteurs ;
- les changements de configuration.
Les journaux doivent être accessibles aux personnes chargées de la sécurité et intégrés, lorsque l’architecture le prévoit, dans Microsoft Sentinel ou un autre SIEM.
31. Configurer les alertes
Les principaux scénarios d’alerte comprennent :
- connexion inhabituelle ;
- activité administrative anormale ;
- création d’une règle de transfert ;
- ajout d’une permission sur une boîte ;
- modification d’un connecteur ;
- changement d’une règle de transport ;
- augmentation inhabituelle du volume d’envoi ;
- consentement applicatif sensible ;
- campagne de phishing ;
- téléchargement ou extraction inhabituelle ;
- utilisation d’un compte d’urgence.
Chaque alerte doit être associée à :
- un niveau de sévérité ;
- un propriétaire ;
- une procédure de qualification ;
- un délai de traitement ;
- une méthode d’escalade ;
- des critères de clôture.
32. Préparer la réponse à une compromission
Une procédure opérationnelle doit être disponible pour traiter rapidement la compromission d’une boîte aux lettres.
Étapes recommandées
- confirmer l’identité de l’utilisateur ;
- 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 ;
- examiner les connexions récentes ;
- rechercher les règles Inbox suspectes ;
- vérifier le transfert de la boîte ;
- examiner les permissions ;
- contrôler les applications autorisées ;
- analyser les messages envoyés ;
- rechercher les messages de phishing similaires ;
- déterminer les informations exposées ;
- informer les parties concernées ;
- corriger la cause initiale ;
- documenter l’incident.
La procédure doit également définir qui peut décider du blocage d’un compte, de la suppression d’un message ou de l’extension de l’investigation.
33. Protéger les comptes d’urgence
Des comptes d’accès d’urgence permettent de reprendre le contrôle du tenant en cas de défaillance majeure.
Ils doivent faire l’objet :
- d’une procédure documentée ;
- d’un stockage sécurisé des identifiants ;
- d’une surveillance stricte ;
- d’une alerte immédiate en cas d’utilisation ;
- de tests réguliers ;
- d’un contrôle des modifications ;
- d’une utilisation exclusivement exceptionnelle.
Toute connexion à un compte d’urgence doit déclencher une investigation.
34. Réaliser des contrôles réguliers
La sécurité d’Exchange Online évolue avec :
- les nouveaux services ;
- les applications ;
- les domaines ;
- les partenaires ;
- les changements d’organisation ;
- les nouvelles menaces ;
- les modifications de licence ;
- les évolutions de Microsoft 365.
Une revue périodique doit porter sur :
- comptes administratifs ;
- rôles ;
- protocoles ;
- SMTP AUTH ;
- domaines ;
- SPF ;
- DKIM ;
- DMARC ;
- connecteurs ;
- règles de transport ;
- transferts externes ;
- permissions ;
- applications OAuth ;
- politiques Defender ;
- politiques DLP ;
- alertes ;
- procédures d’incident.
35. Prioriser les actions
Priorité 1 : mesures critiques
- généraliser la MFA ;
- protéger les administrateurs ;
- déployer Conditional Access ;
- bloquer les mécanismes hérités ;
- désactiver SMTP AUTH lorsqu’il est inutile ;
- bloquer les transferts automatiques externes non autorisés ;
- vérifier les délégations ;
- configurer SPF, DKIM et DMARC ;
- activer les protections anti-phishing ;
- formaliser la procédure de compromission.
Priorité 2 : mesures importantes
- auditer les connecteurs ;
- revoir les règles de transport ;
- contrôler les applications OAuth ;
- sécuriser les appareils mobiles ;
- identifier les comptes sensibles ;
- protéger les liens et les pièces jointes ;
- mettre en place les alertes ;
- surveiller les règles Inbox ;
- gouverner les boîtes partagées.
Priorité 3 : amélioration de la maturité
- déployer les politiques DLP ;
- structurer Microsoft Purview ;
- centraliser les journaux dans un SIEM ;
- automatiser les revues de configuration ;
- mettre en œuvre un contrôle continu des domaines ;
- tester les procédures d’incident ;
- réaliser des exercices de simulation ;
- produire une baseline Exchange Online périodique.
36. Checklist de sécurisation Exchange Online
Identités
- La MFA est généralisée.
- Les administrateurs utilisent des comptes séparés.
- Conditional Access protège Exchange Online.
- Les méthodes résistantes au phishing sont étudiées.
- Les rôles privilégiés sont régulièrement révisés.
- Les comptes d’urgence sont documentés et testés.
Protocoles
- Les mécanismes hérités sont bloqués.
- Les usages SMTP AUTH sont inventoriés.
- SMTP AUTH est désactivé lorsqu’il n’est pas nécessaire.
- Les exceptions sont documentées.
- Les applications anciennes font l’objet d’un plan de migration.
Domaines
- Tous les domaines de messagerie sont inventoriés.
- Les sources d’envoi sont documentées.
- SPF est configuré pour chaque domaine.
- DKIM est activé.
- DMARC est publié.
- Les rapports DMARC sont analysés.
- Les domaines inactifs sont protégés.
- Les plateformes tierces sont contrôlées.
Protection contre les menaces
- Les stratégies anti-spam sont vérifiées.
- Les stratégies anti-phishing sont configurées.
- Les utilisateurs sensibles sont protégés.
- La protection contre l’usurpation est activée.
- Les liens sont contrôlés.
- Les pièces jointes sont analysées.
- Les utilisateurs peuvent signaler les messages suspects.
- Les listes d’autorisation sont limitées.
Flux de messagerie
- Les connecteurs sont inventoriés.
- Chaque connecteur possède un propriétaire.
- Les règles de transport sont documentées.
- Les anciennes règles sont supprimées.
- Les contournements de filtrage sont contrôlés.
- Les relais SMTP sont maîtrisés.
- Les volumes d’envoi inhabituels sont détectés.
Boîtes aux lettres
- Les transferts externes sont bloqués par défaut.
- Les exceptions sont validées.
- Les règles Inbox suspectes peuvent être recherchées.
- Les permissions Full Access sont révisées.
- Les permissions Send As sont révisées.
- Les permissions Send on Behalf sont révisées.
- Les boîtes partagées disposent d’un propriétaire.
- Les boîtes inutilisées sont identifiées.
Applications
- Les applications OAuth sont inventoriées.
- Les permissions Microsoft Graph sont analysées.
- Les consentements administrateurs sont révisés.
- Les applications inutilisées sont supprimées.
- Les secrets et certificats sont maîtrisés.
- Chaque application possède un propriétaire.
Protection des données
- Une classification des informations existe.
- Les étiquettes Purview sont documentées.
- Les effets du chiffrement sont testés.
- Les politiques DLP sont évaluées.
- Les politiques de conservation sont définies.
- Les exigences juridiques et réglementaires sont documentées.
Audit et réponse aux incidents
- L’audit est exploitable.
- Les opérations administratives sont surveillées.
- Les modifications sensibles génèrent des alertes.
- Une procédure de compromission existe.
- Les sessions peuvent être révoquées rapidement.
- Les équipes savent rechercher une campagne de phishing.
- Les procédures sont testées.
- Les incidents donnent lieu à un retour d’expérience.
Conclusion
La sécurisation de Microsoft Exchange Online ne peut pas être réduite à l’activation d’un filtre anti-spam.
Elle nécessite une approche complète associant :
Microsoft Entra ID → Conditional Access → Exchange Online → Microsoft Defender → Microsoft Purview → Microsoft Intune → Audit et supervision
Les premières mesures doivent porter sur les identités, la MFA, les comptes administratifs, l’authentification héritée, SMTP AUTH, les transferts externes et l’authentification des domaines.
La protection doit ensuite être étendue aux liens, aux pièces jointes, aux connecteurs, aux délégations, aux applications OAuth et aux données sensibles.
Enfin, la journalisation, les alertes et les procédures de réponse aux incidents transforment les configurations techniques en un dispositif de sécurité opérationnel.
La sécurité d’Exchange Online doit être régulièrement réévaluée. Chaque nouveau domaine, connecteur, prestataire, application ou usage de messagerie modifie potentiellement la surface d’exposition de l’organisation.
