Exchange Online : architecture, flux de messagerie et exploitation

Exchange Online est le service Exchange exploité par Microsoft dans Microsoft 365. Il fournit des boîtes aux lettres, calendriers, contacts, groupes, le transport SMTP et des fonctions d’administration. L’administrateur du tenant décide des destinataires, domaines, connecteurs, règles, autorisations et de la conservation. Microsoft exploite en revanche les serveurs de boîtes aux lettres, les copies de bases de données, les files d’attente internes, les correctifs et les opérations de basculement (Exchange Online service description, Exchange Online data resiliency).

Ainsi, Exchange Online ressemble fonctionnellement à son propre système Exchange, mais pas sur le plan de l’exploitation. Un administrateur local peut examiner un fichier de file d’attente ou activer une copie de base de données. Dans Exchange Online, il voit à la place les événements, états et objets de configuration fournis par le service. La capacité la plus importante consiste donc à associer une plainte d’utilisateur à un chemin clair : identité, accès client, objet destinataire, transport, filtrage, remise ou conservation.

Du tenant à la boîte aux lettres

Le tenant constitue le cadre organisationnel. Exchange Online y gère des destinataires à capacité de messagerie : boîtes aux lettres utilisateur et partagées, boîtes aux lettres de salle et d’équipement, listes de distribution, groupes Microsoft 365, contacts et utilisateurs de messagerie. Le type de destinataire détermine si des données sont stockées, comment la remise s’effectue et quelles autorisations sont disponibles (Recipients in Exchange Online).

Un compte utilisateur dans Microsoft Entra ID et une boîte aux lettres Exchange sont liés, mais ne constituent pas le même objet. L’attribution de licences peut déclencher le provisionnement d’une boîte aux lettres. Exchange ajoute alors des attributs et services liés à la messagerie. Lorsqu’un administrateur retire une licence ou supprime un compte, différents délais de conservation et de suppression s’appliquent. Pour l’exploitation et le départ des collaborateurs, le cycle de vie de l’identité, celui de la boîte aux lettres et la conservation de conformité doivent donc être planifiés conjointement (Delete or restore user mailboxes, Retention policies for Exchange).

Pour les experts, l’origine des attributs devient importante. Dans un tenant entièrement cloud, les propriétés Exchange sont gérées en ligne. Avec des identités synchronisées, l’environnement local peut rester la source faisant autorité pour certains attributs de destinataires. Une valeur apparaît alors dans Exchange Online, mais doit être modifiée localement puis synchronisée à nouveau. Ce modèle appartient à l’article Exchange Hybrid, car il n’existe pas sans synchronisation d’annuaire.

Comment un message entrant atteint la boîte aux lettres

Une fois le destinataire compris, le chemin du courrier peut être suivi. Le MX public d’un domaine pointe normalement vers Exchange Online Protection, EOP. EOP accepte la connexion SMTP, évalue l’expéditeur et le message, applique des règles de protection et de transport, puis transmet un message autorisé à Exchange Online. Pour les destinataires locaux, la remise dans la boîte aux lettres suit ensuite (Exchange Online Protection overview, Mail flow in EOP).

Le domaine accepté (Accepted Domain) définit la façon dont Exchange Online traite le domaine destinataire. Avec Authoritative, le service attend tous les destinataires valides dans sa propre organisation et rejette les adresses inconnues. Internal Relay permet de transférer des destinataires inconnus vers un autre système. Ce paramètre n’est pertinent que si le prochain saut et la résolution des destinataires sont planifiés de manière fiable ; sinon, des non-remises ou des boucles surviennent (Manage accepted domains in Exchange Online).

Un message interne ne reste pas automatiquement « sur le même serveur ». Exchange Online résout l’expéditeur et le destinataire, vérifie les règles et stratégies de protection, puis enregistre des événements de transport. Cette chaîne d’événements est déterminante pour l’administrateur : Delivered signifie que le service a remis le message à sa destination ; Filtered, Failed, Pending ou Expanded décrivent d’autres étapes. Message Trace rend ces étapes visibles, mais ne remplace pas la vérification de la boîte aux lettres de destination ou d’une règle en aval (Trace an email message, Message Trace FAQ).

Messages sortants et connecteurs

Pour les messages sortants, il faut d’abord déterminer si Exchange Online envoie directement au système de destination ou utilise un connecteur sortant configuré. Un connecteur peut diriger les messages vers sa propre infrastructure, vers un partenaire ou vers une passerelle de messagerie. La sélection repose notamment sur le domaine destinataire, les conditions du connecteur et les règles de transport (Set up connectors to route mail).

Les connecteurs entrants décrivent inversement les conditions dans lesquelles Exchange Online fait confiance à un système expéditeur. Les critères typiques sont l’adresse IP source ou un certificat TLS. Ces informations sont pertinentes pour la sécurité : une plage IP trop large ou un certificat vérifié de façon imprécise peut faire paraître du trafic tiers comme du trafic interne ou partenaire.

Lorsqu’une passerelle de messagerie externe est placée devant EOP, Microsoft voit d’abord l’adresse IP de la passerelle. Enhanced Filtering for Connectors peut intégrer les informations sur le saut d’origine dans l’évaluation du filtrage. Cette fonction n’est pas un « commutateur de filtre antispam » général, mais doit correspondre au chemin réel, aux connecteurs et aux adresses IP ignorées (Enhanced Filtering for Connectors).

La question des experts est ici la suivante : quelle contrepartie a réellement accepté un message, quelle identité a été vérifiée pour le connecteur et à quel saut a eu lieu le dernier filtrage de contenu ? Ces trois réponses doivent figurer dans chaque diagramme de flux de messagerie.

Structure technique du point de vue de l’administrateur

Exchange Online ne publie pas de liste de serveurs qu’un administrateur de tenant gère comme une batterie locale. Le service possède néanmoins des composants techniques clairement identifiables. Ils sont visibles via des protocoles et des interfaces d’administration.

La pile technologique périphérique se compose donc principalement de SMTP et TLS pour le transport de messagerie, ainsi que de HTTPS, OAuth, PowerShell et REST pour l’accès client et administratif. Les détails internes d’implémentation ne sont pertinents pour le client que dans la mesure où Microsoft les documente comme comportement de service, limite ou interface de diagnostic (About the Exchange Online PowerShell module, Microsoft Graph mail API).

Accès client et authentification moderne

Le transport de messagerie se termine dans la boîte aux lettres ; les utilisateurs y accèdent ensuite via des protocoles client. Outlook, Outlook sur le web, les clients mobiles et les applications utilisent des points de terminaison basés sur HTTPS. Autodiscover aide les clients à trouver le service approprié. L’authentification s’effectue via Microsoft Entra ID, tandis qu’Exchange vérifie l’autorisation au niveau de la boîte aux lettres (Clients and mobile in Exchange Online, Modern authentication in Exchange Online).

Cela distingue deux erreurs souvent confondues. Si l’authentification échoue dans Entra, le client n’atteint souvent pas Exchange du tout. Si le jeton est valide, Exchange peut néanmoins refuser l’accès en raison d’un rôle manquant, d’une autorisation de boîte aux lettres, d’une stratégie client ou d’une boîte aux lettres cible incorrecte. Les journaux de connexion et le diagnostic Exchange doivent donc être considérés ensemble dans le temps.

Les applications accèdent de préférence via Microsoft Graph ou des interfaces Exchange prises en charge. Une autorisation d’application Graph peut être étendue ; Exchange RBAC for Applications peut restreindre davantage l’étendue des boîtes aux lettres accessibles. Un jeton OAuth valide n’est donc que la première étape. Le service de ressources vérifie ensuite quelle action est autorisée sur quelle boîte aux lettres (Role Based Access Control for Applications).

Suivre les autorisations et les modifications

Exchange Online possède ses propres rôles d’administration. Les rôles Entra peuvent permettre l’accès à l’administration Exchange, mais les cmdlets Exchange effectives et leur étendue sont déterminées par Exchange-RBAC (Permissions in Exchange Online).

Il existe également des autorisations de boîte aux lettres telles que Full Access, Send As et Send on Behalf. Elles contrôlent des actions différentes et ne doivent pas être inventoriées comme un droit de délégation commun. Pour les applications, s’ajoutent les rôles OAuth et les rôles d’application Exchange (Manage permissions for recipients).

Pour les experts, l’origine d’une modification est aussi importante que l’état final. Les journaux d’audit, les journaux de connexion Entra et les exportations de configuration indiquent qui a modifié une règle, un connecteur ou une autorisation. Une exportation nocturne des objets centraux du flux de messagerie facilite les comparaisons, mais ne remplace pas une source d’audit protégée.

Diagnostic : d’abord DNS, puis événements de transport

Une analyse du flux de messagerie commence en dehors du tenant. Le MX indique quel système accepte le courrier Internet. Ensuite, Message Trace permet de vérifier si Exchange Online a vu le message précis et comment il l’a traité.

Resolve-DnsName -Type MX example.com
Resolve-DnsName autodiscover.example.com

dig MX example.com
dig autodiscover.example.com

Resolve-DnsName et dig montrent la publication et la résolution. Ils n’indiquent pas encore si EOP a accepté le message ou si une boîte aux lettres l’a reçu.

Pour l’étape suivante, une période restreinte est choisie avec l’expéditeur et le destinataire. Le même Exchange Online PowerShell fonctionne sous Windows et avec pwsh sur les systèmes Unix pris en charge.

Connect-ExchangeOnline
Get-MessageTraceV2 -SenderAddress sender@example.net `
  -StartDate (Get-Date).AddHours(-2) -EndDate (Get-Date)

pwsh
Connect-ExchangeOnline
Get-MessageTraceV2 -SenderAddress sender@example.net `
  -StartDate (Get-Date).AddHours(-2) -EndDate (Get-Date)

Connect-ExchangeOnline établit la session d’administration authentifiée. Get-MessageTraceV2 recherche les événements de transport ; Get-Date limite la fenêtre temporelle. Pour les tendances, des rapports sont disponibles, et pour les incidents Microsoft, Service Health. Un seul indicateur vert ne répond pas aux trois questions (Exchange Online monitoring).

Conservation, suppression et restauration

Microsoft protège le service en fonctionnement avec plusieurs copies de bases de données, Shadow Redundancy et Safety Net. Ces mécanismes servent à la disponibilité et à l’intégrité des données du service. Ils ne constituent pas l’interface utilisateur permettant de restaurer un message supprimé accidentellement (Exchange Online data resiliency).

Pour les cas utilisateur et de conformité, d’autres fonctions s’appliquent : Deleted Item Retention, Recoverable Items, Single Item Recovery, Retention Policies et Holds. Leurs effets se chevauchent, mais leurs objectifs diffèrent. Une règle de conservation peut protéger des contenus contre une suppression définitive ; elle ne fournit pas automatiquement une sauvegarde séparée, indépendante du tenant, avec un moment de restauration librement sélectionnable (Recoverable Items folder, Retention policies for Exchange).

Un concept de récupération fiable précise donc quels événements sont couverts par la résilience du service Microsoft, quels contenus peuvent être récupérés via la conservation Exchange ou Purview et pour quelles exigences une copie indépendante est nécessaire. Les tests de restauration doivent utiliser des cas concrets : message individuel, dossier, boîte aux lettres après suppression d’utilisateur, élément conservé pour des raisons légales et incident à l’échelle du tenant.

Sécurité et limites typiques

Exchange Online relie plusieurs domaines de sécurité : courrier Internet, EOP, configuration du tenant, connexion Entra, droits de boîte aux lettres et applications. L’efficacité de la protection dépend de la correspondance entre le chemin réel des messages et des connexions, et la configuration.

Pour le flux de messagerie, cela signifie que MX, identité du connecteur, Enhanced Filtering, SPF/DKIM/DMARC et règles de transport doivent être vérifiés comme une chaîne. Pour l’accès client, l’authentification moderne, Conditional Access, Exchange-RBAC et les autorisations de boîte aux lettres sont des contrôles distincts. Pour les applications, s’ajoutent le consentement OAuth et l’étendue autorisée des boîtes aux lettres.

La question administrative plus approfondie reste la même dans chaque cas : quel système a pris la décision, quelles données d’entrée a-t-il vues et où le résultat est-il journalisé ? Sans ces trois informations, même une stratégie formellement correcte reste difficile à vérifier.

Évolution technique et compromis délibérés

Exchange Online est issu des offres Exchange hébergées de Microsoft et a repris de nombreux concepts du produit serveur : destinataires, bases de données de boîtes aux lettres, transport, DAG, Shadow Redundancy et Safety Net. Le service automatise l’exploitation de cette infrastructure et fournit aux administrateurs de tenant un niveau d’administration plus élevé (Exchange Team: 20 years ago, Exchange Online data resiliency).

Le gain réside dans l’exploitation externalisée de la plateforme, l’intégration mondiale des services et des interfaces d’administration standardisées. Le prix est un accès moindre aux serveurs individuels, aux files d’attente et aux copies de bases de données, ainsi qu’une dépendance accrue aux fonctions de diagnostic, d’exportation et de récupération publiées. La tâche des experts n’est donc pas de deviner la topologie interne invisible, mais d’utiliser pleinement les contrôles du tenant et les signaux du service documentés.