Comment auditer et securiser vos serveurs Exchange on-premises en 7 etapes

Cet article est ne d'un constat simple : sur les 30 derniers audits Exchange que j'ai realises pour des entreprises francaises (PME, ETI, associations du secteur sante), aucune n'avait une configuration Exchange conforme aux recommandations de securite de Microsoft. Pas une seule. Les memes erreurs reviennent : OWA expose sans restriction IP, certificats auto-signes en production, regles de transport absentes, logs d'audit desactives, et sauvegardes non testees. Ce guide reprend les 7 etapes de notre methodologie d'audit, avec les commandes PowerShell et les criteres de verification que nous utilisons sur le terrain.

— Etape 1 : Inventaire complet de votre parc Exchange

Un audit sans inventaire exhaustif est un audit incomplet. La premiere etape consiste a cartographier l'ensemble des serveurs Exchange de votre organisation, y compris ceux que vous avez oublies. Ouvrez l'Exchange Management Shell et executez :

Get-ExchangeServer | Select-Object Name, Edition, AdminDisplayVersion, ServerRole, Site | Format-Table -AutoSize

Cette commande vous donne la liste de tous les serveurs enregistres dans votre organisation Exchange, avec leur version exacte et leur role. Completez avec une verification reseau pour identifier les serveurs qui ne seraient pas dans l'inventaire Exchange (serveurs decommissionnes mais toujours en ligne, instances de test oubliees) :

# Scan reseau pour trouver les serveurs Exchange non documentes
nmap -sV -p 443,25,587,993,995 --script=banner 10.0.0.0/8 | grep -i "exchange\|owa\|autodiscover"

Pour chaque serveur identifie, documentez : nom, version exacte (CU et SU), roles installes, date du dernier CU applique, systeme d'exploitation, services exposes sur le reseau (OWA, ECP, ActiveSync, EWS, Autodiscover, SMTP), et usage metier (production, hybride, test, decommissionnement prevu). Cette cartographie est le socle de toutes les etapes suivantes. Sur nos 30 audits, nous trouvons en moyenne 1,4 serveur Exchange supplementaire par organisation par rapport a l'inventaire declare — souvent des serveurs de test devenus « critiques » sans que personne ne l'ait formalise.

Verifiez egalement la version du Cumulative Update et du Security Update. Exchange sans le dernier SU est une cible immediate pour les attaquants. La commande Get-ExchangeServer | Format-List Name, AdminDisplayVersion vous donne la version exacte. Comparez-la avec la matrice de versions Microsoft pour identifier les mises a jour manquantes.

— Etape 2 : Analyser OWA et les services exposes

OWA (Outlook Web Access) est le composant Exchange le plus frequemment cible par les attaquants. Les vulnerabilites ProxyLogon (2021), ProxyShell (2021), ProxyNotShell (2022) et plus recemment CVE-2026-42897 exploitent toutes des composants web d'Exchange. L'audit de cette couche est donc critique.

Commencez par lister les repertoires virtuels exposes :

# Lister les URLs OWA
Get-OwaVirtualDirectory | Select-Object Server, InternalUrl, ExternalUrl

# Lister les URLs ECP (Exchange Control Panel)
Get-EcpVirtualDirectory | Select-Object Server, InternalUrl, ExternalUrl

# Lister les URLs ActiveSync
Get-ActiveSyncVirtualDirectory | Select-Object Server, InternalUrl, ExternalUrl

# Lister les URLs EWS
Get-WebServicesVirtualDirectory | Select-Object Server, InternalUrl, ExternalUrl

# Lister Autodiscover
Get-AutodiscoverVirtualDirectory | Select-Object Server, InternalUrl, ExternalUrl

Pour chaque service, la question fondamentale est : ce service a-t-il besoin d'etre accessible depuis Internet ? Dans la majorite des cas, ECP (le panneau d'administration) ne devrait jamais etre accessible depuis Internet. ActiveSync peut etre necessaire pour les mobiles, mais devrait etre protege par un acces conditionnel ou un MDM. OWA doit etre evalue au cas par cas — si vos utilisateurs utilisent exclusivement le client lourd Outlook, desactivez OWA ou restreignez-le aux IP internes. Pour une methodologie complementaire sur la securisation des points d'entree web, consultez notre guide sur comment securiser ses API — les principes de reduction de surface d'attaque s'appliquent de maniere identique.

Testez l'accessibilite depuis l'exterieur en utilisant curl ou un scanner comme SSL Labs pour verifier la configuration TLS. Un serveur Exchange qui repond avec TLS 1.0 ou 1.1 depuis Internet est un signal d'alarme immediat.

— Etape 3 : Hardening IIS et regles de transport

Exchange repose sur IIS (Internet Information Services) pour tous ses composants web. Le hardening d'IIS est donc une etape incontournable. Voici les verifications prioritaires :

Headers de securite : verifiez la presence des headers suivants dans la configuration IIS du site Default Web Site et du site Exchange Back End. Les headers manquants sont la cause numero un des exploitations de type XSS sur Exchange.

# Verifier les headers de securite dans IIS
# A ajouter dans web.config ou via IIS Manager :
# X-Content-Type-Options: nosniff
# X-Frame-Options: SAMEORIGIN
# Content-Security-Policy: script-src 'self'
# Strict-Transport-Security: max-age=31536000; includeSubDomains

# Verification rapide :
curl -sI https://votre-exchange.local/owa | grep -iE "x-content|x-frame|content-security|strict-transport"

Regles de transport : les regles de transport Exchange permettent de filtrer et de modifier les e-mails en transit. Verifiez qu'aucune regle n'a ete ajoutee par un attaquant (transfert silencieux, modification de headers) et que les regles de securite de base sont en place :

# Lister toutes les regles de transport
Get-TransportRule | Select-Object Name, State, Priority, Comments | Format-Table -AutoSize

# Verifier les regles de transfert dans les boites aux lettres (IOC courant)
Get-InboxRule -Mailbox * | Where-Object {$_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo} `
  | Select-Object MailboxOwnerId, Name, ForwardTo, RedirectTo

Configuration TLS : desactivez TLS 1.0 et 1.1 si ce n'est pas deja fait. En 2026, seuls TLS 1.2 et 1.3 devraient etre actifs. Verifiez avec Get-TlsCipherSuite sur le serveur et avec un scan SSL Labs depuis l'exterieur. Attention : certaines applications metier anciennes peuvent dependre de TLS 1.0 — identifiez-les avant de desactiver. Pour une approche globale du hardening serveur, notre article sur le hardening Exchange Server couvre ces points en detail.

— Etape 4 : Gestion des certificats TLS

Les certificats TLS d'Exchange sont un angle mort frequemment negligé. Sur nos 30 audits, 8 organisations utilisaient encore des certificats auto-signes pour OWA en production, et 5 avaient des certificats expires depuis plus de 30 jours. Un certificat mal gere ne pose pas seulement un probleme de confiance navigateur — il peut aussi indiquer une infrastructure non maintenue, donc vulnérable.

# Lister tous les certificats Exchange
Get-ExchangeCertificate | Select-Object Thumbprint, Subject, NotAfter, Services, Status | Format-Table -AutoSize

# Verifier les certificats qui expirent dans les 90 prochains jours
Get-ExchangeCertificate | Where-Object {$_.NotAfter -lt (Get-Date).AddDays(90)} | Select-Object Subject, NotAfter

Les bonnes pratiques : utilisez des certificats emis par une autorite de certification reconnue (Let's Encrypt pour les environnements non critiques, DigiCert ou Sectigo pour les environnements de production). Automatisez le renouvellement. Assurez-vous que le certificat couvre tous les noms d'hote necessaires : mail.domaine.fr, autodiscover.domaine.fr, et le FQDN interne du serveur. Un certificat SAN (Subject Alternative Name) est generalement la meilleure option.

— Etape 5 : Monitoring et journalisation

Un serveur Exchange sans monitoring est un serveur que vous ne pourrez pas defendre en cas d'incident. La journalisation doit couvrir trois niveaux : les logs IIS (acces web), les logs d'audit Exchange (actions des utilisateurs et des administrateurs), et les logs systeme Windows (evenements de securite).

Audit Exchange : activez l'audit des boites aux lettres pour toutes les operations sensibles. Depuis Exchange 2019 CU12+, l'audit est active par defaut, mais verifiez que la configuration n'a pas ete modifiee :

# Verifier l'audit des boites aux lettres
Get-OrganizationConfig | Select-Object AuditDisabled

# Verifier l'audit admin
Get-AdminAuditLogConfig | Select-Object AdminAuditLogEnabled, LogLevel

# Rechercher des evenements suspects dans les 7 derniers jours
Search-AdminAuditLog -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date) `
  -Cmdlets "New-InboxRule","Set-InboxRule","New-TransportRule","Set-TransportRule" `
  | Select-Object RunDate, Caller, CmdletName, ObjectModified

Integration SIEM : envoyez les logs IIS, les logs d'audit Exchange et les evenements Windows (Event ID 4625 pour les echecs d'authentification, 4624 pour les connexions reussies, 1102 pour l'effacement de logs) vers votre SIEM. Si vous n'avez pas de SIEM, notre guide de choix SIEM vous aidera a identifier la solution adaptee a votre budget. Au minimum, centralisez les logs sur un serveur separe pour qu'un attaquant ne puisse pas les effacer en compromettant le serveur Exchange.

Alertes critiques a configurer : connexion OWA depuis un pays inhabituel, creation de regle de transfert, modification de la configuration Exchange (cmdlets Set-*), echecs d'authentification massifs sur OWA (brute force), et connexion admin Exchange en dehors des heures ouvrees.

— Etape 6 : Sauvegardes et plan de reprise

La sauvegarde d'Exchange est souvent le parent pauvre de l'infrastructure de messagerie. Pourtant, c'est la derniere ligne de defense en cas de ransomware ou de compromission majeure. Voici les points de controle essentiels :

Verification des sauvegardes : la question n'est pas « faites-vous des sauvegardes ? » (la reponse est presque toujours oui) mais « avez-vous teste la restauration ? » Sur nos 30 audits, 22 organisations n'avaient jamais teste la restauration d'une base de donnees Exchange. Une sauvegarde non testee n'est pas une sauvegarde — c'est un faux sentiment de securite.

# Verifier l'etat des sauvegardes des bases de donnees
Get-MailboxDatabase | Select-Object Name, LastFullBackup, LastIncrementalBackup, DatabaseSize | Format-Table -AutoSize

# Verifier les bases sans sauvegarde recente (> 7 jours)
Get-MailboxDatabase | Where-Object {$_.LastFullBackup -lt (Get-Date).AddDays(-7) -or $_.LastFullBackup -eq $null} `
  | Select-Object Name, LastFullBackup

Les bonnes pratiques de sauvegarde Exchange : sauvegarde complete quotidienne (minimum), retention de 30 jours minimum, stockage hors site (regle 3-2-1), test de restauration trimestriel documente, et sauvegarde des certificats TLS et de la configuration IIS (souvent oubliee). En complement, documentez un plan de reprise d'activite (PRA) specifique a la messagerie : quels sont les RTO et RPO acceptables pour votre direction ? Quelle est la procedure de bascule en cas de perte du serveur principal ?

— Etape 7 : Evaluer la migration vers Exchange Online

La derniere etape de l'audit n'est pas technique — elle est strategique. Chaque audit Exchange on-premises devrait se conclure par une evaluation honnete de la pertinence du maintien en on-premises versus la migration vers Exchange Online. Ce n'est pas une question de technologie, c'est une question de cout total de possession et de capacite a maintenir un niveau de securite acceptable.

Les criteres a evaluer :

• Cout d'infrastructure : serveurs physiques ou virtuels, licences Windows Server, licences Exchange, stockage, reseau, electricite, refroidissement.
• Cout de competences : administration Exchange, patching regulier, hardening, monitoring, gestion des incidents. Un administrateur Exchange competent coute entre 55 000 et 80 000 euros par an en France.
• Cout du risque : chaque zero-day Exchange genere un cout de reaction (audit, mitigation, investigation). ProxyLogon en 2021 a coute entre 15 000 et 150 000 euros par entreprise touchee, selon la taille de l'organisation et la gravite de la compromission.
• Contraintes reglementaires : HDS, souverainete des donnees, RGPD, exigences sectorielles. Certaines contraintes rendent la migration vers Exchange Online complexe mais pas impossible (SecNumCloud, hebergement en France).
• Cout de migration : projet de migration, formation des utilisateurs, reconfiguration des applications dependantes (CRM, ERP, applications metier). Comptez 3 a 12 mois selon la complexite.

Pour les organisations qui ne migrent pas, le rapport d'audit doit inclure un cout annuel estime du maintien en on-premises versus le cout de migration, avec une recommandation claire et des jalons. Ce document est indispensable pour que la direction prenne une decision eclairee — et pour que le RSSI ne porte pas seul la responsabilite d'un choix qui est, in fine, un choix de direction generale. Sur la securisation globale de votre environnement Microsoft, consultez egalement notre guide sur comment securiser Microsoft 365.

— Questions frequentes