Règles de flux de messagerie Exchange Online : un angle mort à auditer
Les règles de flux de messagerie, aussi appelées règles de transport, s'appliquent à tous les messages de l'organisation, sans que les utilisateurs n'en voient jamais la trace. Dans nos audits, elles s'accumulent au fil des années, des migrations et des prestataires. Certaines affaiblissent discrètement la sécurité, d'autres pourraient servir à exfiltrer du courrier.
Pourquoi les règles de transport méritent l'attention
Une règle de boîte aux lettres ne concerne qu'un utilisateur, et celui-ci peut la voir dans Outlook. Une règle de transport, elle, est définie au niveau de l'organisation dans le centre d'administration Exchange et s'exécute sur le service de transport, pour tous les messages qui correspondent à ses conditions. Personne, en dehors des administrateurs Exchange, n'a de raison d'aller la consulter.
C'est précisément ce qui en fait un outil intéressant pour un attaquant qui a obtenu un rôle d'administration Exchange : une seule règle suffit à recevoir une copie de tout le courrier d'un dirigeant, durablement, sans compromettre sa boîte aux lettres. C'est aussi ce qui explique leur accumulation : on crée une règle pour un besoin ponctuel, puis on l'oublie.
Les règles qui détournent le courrier
Plusieurs actions permettent de faire sortir des messages de leur circuit normal :
- Ajouter un destinataire en copie cachée : le destinataire initial reçoit son message normalement, rien ne signale la copie ;
- Rediriger le message vers une autre adresse, interne ou externe ;
- Transférer pour approbation à un modérateur, qui voit donc le contenu avant le destinataire ;
- Router via un connecteur sortant particulier, ce qui peut faire transiter le courrier par un service tiers.
Ces actions ont des usages légitimes : archivage réglementaire, supervision de certains flux, outil de signature hébergé chez un prestataire. Mais chacune doit être documentée, justifiée et rattachée à un responsable. Une copie cachée vers une adresse externe, sans explication écrite, doit être traitée comme un incident jusqu'à preuve du contraire.
Les règles qui affaiblissent le filtrage
La deuxième famille de règles à risque concerne le filtrage. L'action « définir le niveau de confiance du courrier indésirable (SCL) » avec la valeur de contournement (-1) fait passer les messages à côté du filtrage antispam. On la retrouve souvent conditionnée par le domaine de l'expéditeur : « tout ce qui vient de partenaire.fr est sûr ».
Le problème est que l'adresse d'expéditeur se falsifie facilement. Une règle fondée uniquement sur le domaine expéditeur offre un passe-droit à quiconque usurpe ce domaine. Même logique pour les règles fondées sur des mots dans l'objet ou sur une adresse IP trop large. Microsoft applique certaines protections « sécurisées par défaut », notamment pour les programmes malveillants et l'hameçonnage à haut niveau de confiance, mais il ne faut pas compter sur elles pour compenser une règle trop permissive ; vérifiez le comportement actuel dans votre locataire.
Les bons outils pour les bons besoins. Pour les simulations d'hameçonnage d'un prestataire ou les boîtes d'analyse de l'équipe sécurité, la stratégie de remise avancée est prévue à cet effet. Pour un partenaire légitime, on privilégie la liste d'autorisation et de blocage du locataire, avec des entrées limitées dans le temps, plutôt qu'une règle de contournement permanente.
Les autres réglages qui passent inaperçus
Au-delà des actions elles-mêmes, plusieurs détails changent le comportement réel des règles :
- la priorité et l'option « ne plus traiter de règles », qui peuvent empêcher une règle de sécurité placée plus bas de s'appliquer ;
- les exceptions, parfois plus larges que la condition elle-même ;
- le mode : une règle en mode test ne fait rien, ce qui peut donner une fausse impression de protection ;
- les règles qui suppriment ou modifient des en-têtes, susceptibles de perturber les vérifications en aval ou d'insérer des en-têtes de contournement ;
- les règles désactivées mais conservées, qu'un administrateur peut réactiver d'un clic.
Passer les règles en revue
La revue se fait plus facilement en PowerShell que dans le portail. La commande Get-TransportRule liste les règles avec leur état, leur priorité, leur mode et la date de dernière modification. Nous recommandons de les exporter avec l'ensemble de leurs conditions, exceptions et actions, puis de les classer en trois catégories : à conserver et documenter, à corriger, à supprimer.
Pour chaque règle conservée, on consigne son objectif, son demandeur, son responsable technique et sa date de révision. Côté détection, la création et la modification de règles de transport apparaissent dans le journal d'audit sous les opérations New-TransportRule, Set-TransportRule et Enable-TransportRule. Une alerte sur ces opérations, ou au moins un contrôle régulier, permet de repérer une règle ajoutée hors processus.
Enfin, limitez le nombre de personnes qui peuvent créer ces règles. Le rôle « Transport Rules » est inclus dans des groupes de rôles Exchange larges ; une revue des membres de ces groupes fait partie du même exercice.
Ce qu'un audit vérifie
- L'inventaire complet des règles de transport, actives, désactivées et en mode test.
- Les règles qui ajoutent une copie cachée, redirigent, soumettent à approbation ou routent vers un connecteur.
- Les règles qui positionnent un SCL de contournement ou des en-têtes de contournement, et leurs conditions.
- L'usage de la remise avancée et de la liste d'autorisation du locataire à la place des contournements.
- La documentation et le responsable de chaque règle conservée.
- La surveillance des créations et modifications de règles dans le journal d'audit.
- Les membres des groupes de rôles qui disposent du rôle Transport Rules.