Infrastructure de messagerie hybride à sécurité renforcée - Accès web

Microsoft Entra ID

Microsoft 365

Office 365

La solution décrite dans cet article vous aidera à protéger votre service de messagerie (Outlook sur le web ou Panneau de configuration Exchange) lorsque des boîtes aux lettres sont hébergées dans Exchange Online ou Exchange local.

Architecture

Dans cette architecture, nous décomposons la solution en deux domaines afin de décrire la sécurité pour :

Exchange Online, sur le côté droit du diagramme.
Exchange en local dans un scénario hybride ou non hybride, sur le côté gauche du diagramme.

Téléchargez un fichier Visio de cette architecture.

Remarques générales

Cette architecture utilise le modèle d'identité fédéré Microsoft Entra. Pour les modèles de synchronisation de hachage de mot de passe et les modèles d’authentification directe, la logique et le flux sont identiques. La seule différence est liée au fait que Microsoft Entra ID ne redirigera pas la demande d'authentification vers les services de fédération Active Directory (AD FS) sur site.
Le diagramme montre l’accès au service Outlook sur le web qui correspond à un chemin d’accès .../owa. Le centre d’administration Exchange de l’utilisateur (ou Panneau de configuration Exchange) qui correspond à un chemin d’accès .../ecp suit le même flux.
Dans le diagramme, les lignes pointillées montrent les interactions de base entre les composants Active Directory locaux, Microsoft Entra Connect, Microsoft Entra ID, AD FS et Web Application Proxy. Vous pouvez en savoir plus sur ces interactions dans Ports et protocoles nécessaires à l’identité hybride.
Par Exchange local, nous entendons Exchange 2019 avec les dernières mises à jour et le rôle serveur de boîtes aux lettres. Par Exchange Edge local, nous entendons Exchange 2019 avec les dernières mises à jour et le rôle de transport Edge. Nous incluons le serveur Edge dans le diagramme pour mettre en évidence le fait que vous pouvez l’utiliser dans ces scénarios. Il n’est pas impliquée dans le travail avec les protocoles clients décrits ici.
Dans un environnement réel, vous n’aurez pas qu’un seul serveur. Vous aurez un groupe de serveurs Exchange à charge équilibrée pour la haute disponibilité. Les scénarios décrits ici sont adaptés à cette configuration.

Flux de l’utilisateur d’Exchange Online

Un utilisateur tente d’accéder au service Outlook sur le web via https://outlook.office.com/owa.
Exchange Online redirige l'utilisateur vers Microsoft Entra ID pour l'authentification.

Si le domaine est fédéré, Microsoft Entra ID redirige l'utilisateur vers l'instance AD FS locale pour l'authentification. Si l'authentification réussit, l'utilisateur est redirigé vers Microsoft Entra ID. (Pour simplifier le diagramme, nous avons omis ce scénario fédéré.)
Pour appliquer l'authentification multifacteur, Microsoft Entra ID applique une stratégie d'accès conditionnel Azure avec une exigence d'authentification multifacteur pour l'application client du navigateur. Pour plus d’informations sur la configuration de cette stratégie, consultez la section relative au déploiement de cet article.
La stratégie d’accès conditionnel appelle l’authentification multifacteur Microsoft Entra. L'utilisateur reçoit une demande pour terminer l'authentification multifacteur.
L'utilisateur effectue une authentification multifacteur.
Microsoft Entra ID redirige la session Web authentifiée vers Exchange Online et l'utilisateur peut accéder à Outlook.

Flux de l’utilisateur d’Exchange local

Un utilisateur tente d’accéder au service Outlook sur le web via une URL https://mail.contoso.com/owa qui pointe vers un serveur Exchange pour l’accès interne ou vers un serveur Proxy d’application web pour l’accès externe.
Exchange local (pour l’accès interne) ou le Proxy d’application web (pour l’accès externe) redirige l’utilisateur vers AD FS pour l’authentification.
AD FS utilise l’authentification Windows intégrée pour l’accès interne ou fournit un formulaire web dans lequel l’utilisateur peut entrer des informations d’identification pour l’accès externe.
En réponse à une stratégie de contrôle d'accès AF DS, AD FS appelle l'authentification multifacteur Microsoft Entra pour terminer l'authentification. Voici un exemple de ce type de stratégie de contrôle d’accès AD FS :

L'utilisateur reçoit une demande pour terminer l'authentification multifacteur.
L'utilisateur effectue une authentification multifacteur. AD FS redirige la session web authentifiée vers Exchange local.
L’utilisateur peut accéder à Outlook.

Si vous voulez implémenter ce scénario pour un utilisateur local, vous devez configurer Exchange et AD FS afin qu’AD FS pré-authentifie les demandes d’accès web. Pour plus d’informations, consultez Utiliser l’authentification basée sur les revendications AD FS avec Outlook sur le web.

Vous devez également activer l’intégration de l’authentification multifacteur AD FS et Microsoft Entra. Pour plus d’informations, consultez Configurer Azure MFA comme fournisseur d’authentification avec AD FS. (Cette intégration requiert AD FS 2016 ou 2019.) Enfin, vous devez synchroniser les utilisateurs avec Microsoft Entra ID et leur attribuer des licences pour l'authentification multifacteur Microsoft Entra.

Composants

Microsoft Entra ID. Microsoft Entra ID est un service de gestion des identités et des accès basé sur le cloud Microsoft. Il fournit une authentification moderne basée sur EvoSTS (un service de jeton de sécurité utilisé par Microsoft Entra ID). Il est utilisé comme serveur d’authentification pour Exchange Server en local.
Authentification multifacteur Microsoft Entra. L'authentification multifacteur est un processus dans lequel les utilisateurs sont invités, lors du processus de connexion, à fournir une autre forme d'identification, comme un code sur leur téléphone portable ou une analyse d'empreintes digitales.
Accès conditionnel Microsoft Entra. L'accès conditionnel est la fonctionnalité que Microsoft Entra ID utilise pour appliquer des politiques organisationnelles telles que l'authentification multifacteur.
AD FS. AD FS permet la gestion fédérée des identités et des accès en partageant l’identité numérique et les droits d’accès au-delà des limites de la sécurité et de l’entreprise avec une sécurité renforcée. Dans cette architecture, il est utilisé pour faciliter la connexion des utilisateurs avec une identité fédérée.
Proxy d’application web. Proxy d’application web pré-authentifie l’accès aux applications web à l’aide d’AD FS. Il fonctionne également comme un proxy AD FS.
Exchange Server. Exchange Server héberge les boîtes aux lettres des utilisateurs localement. Dans cette architecture, il utilise des jetons délivrés à l'utilisateur par Microsoft Entra ID pour autoriser l'accès aux boîtes aux lettres.
Services Active Directory. Les services Active Directory stockent des informations sur les membres d’un domaine, notamment les appareils et utilisateurs. Dans cette architecture, les comptes d'utilisateurs appartiennent aux services Active Directory et sont synchronisés avec Microsoft Entra ID.

Détails du scénario

L’infrastructure de messagerie d’entreprise est un service clé pour les organisations. La transition de méthodes plus anciennes et moins sécurisées d’authentification et d’autorisation vers l’authentification moderne constitue un enjeu crucial dans un monde où le recours au télétravail a pris de l’ampleur. La mise en œuvre d’exigences d’authentification multifacteur pour l’accès aux services de messagerie est l’un des moyens les plus efficaces de relever ce défi.

Cet article décrit une architecture pour améliorer votre sécurité dans un scénario d'accès Web à l'aide de l'authentification multifacteur Microsoft Entra.

L’architecture présentée ici décrit des scénarios qui vous aident à protéger votre service de messagerie (Outlook sur le web ou Panneau de configuration Exchange) lorsque des boîtes aux lettres sont hébergées dans Exchange Online ou localement dans Exchange.

Pour plus d’informations sur l’application de l’authentification multifacteur dans d’autres scénarios de messagerie hybride, consultez ces articles :

Cet article ne traite pas d’autres protocoles, tels qu’IMAP ou POP. Nous ne vous recommandons pas de les utiliser pour établir l’accès des utilisateurs.

Cas d’usage potentiels

Cette architecture s’applique aux scénarios suivants :

Renforcement de la sécurité de l’infrastructure de messagerie d’entreprise.
Adoption d’une stratégie de sécurité Confiance Zéro.
Application de votre niveau de protection élevé standard à votre service de messagerie locale lors de la transition vers/dans le cadre de la coexistence avec Exchange Online.
Appliquer des exigences strictes en matière de sécurité ou de conformité dans des organisations fermées ou hautement sécurisées, comme celles du secteur financier.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d'informations, consultez Microsoft Azure Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.

Disponibilité

La disponibilité globale dépend de la disponibilité des composants concernés. Pour plus d’informations sur la disponibilité, consultez les ressources suivantes :

La disponibilité des composants de la solution locale dépend de la conception implémentée, de la disponibilité du matériel et de vos opérations internes et routines de maintenance. Pour obtenir des informations sur la disponibilité de certains de ces composants, consultez les ressources suivantes :

Résilience

Pour plus d’informations sur la résilience des composants de cette architecture, consultez les ressources suivantes.

Pour Microsoft Entra ID : amélioration de la disponibilité de Microsoft Entra
Pour consulter des scénarios qui utilisent AD FS : Déploiement des services AD FS haute disponibilité par-delà les frontières dans Azure avec Azure Traffic Manager
Pour la solution locale Exchange : Haute disponibilité d’Exchange

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.

Pour plus d’informations sur la sécurité des composants de cette architecture, consultez les ressources suivantes :

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.

Le coût de votre mise en œuvre dépend de votre identifiant Microsoft Entra et des coûts de votre licence Microsoft 365. Le coût total comprend également le coût des logiciels et du matériel pour les composants locaux, les opérations informatiques, la formation, et l’implémentation des projets.

La solution nécessite au moins Microsoft Entra ID P1. Pour plus de détails sur les tarifs, consultez Tarification Microsoft Entra.

Pour plus d’informations sur Exchange, consultez la tarification d’Exchange Server.

Pour plus d’informations sur AD FS et le Proxy d’application web, consultez Tarification et licences pour Windows Server 2022.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à s’adapter efficacement pour répondre aux besoins des utilisateurs. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.

Les performances dépendent des performances des composants impliqués et des performances réseau de votre entreprise. Pour plus d’informations, consultez Optimisation des performances d’Office 365 à l’aide de lignes de référence et de l’historique des performances.

Pour plus d’informations sur les facteurs locaux qui influencent les performances dans le cadre des scénarios incluant les services AD FS, consultez les ressources suivantes :

Extensibilité

Pour plus d’informations sur la scalabilité d’AD FS, consultez Planification de la capacité des serveurs AD FS.

Pour plus d’informations sur la scalabilité d’Exchange Server en local, consultez Architecture recommandée pour Exchange 2019.

Déployer ce scénario

Pour déployer ce scénario, effectuez les étapes générales suivantes :

Commencez par le service d’accès web. Renforcez sa sécurité à l’aide d’une stratégie d’accès conditionnel Azure pour Exchange Online.
Renforcez la sécurité de l’accès web pour l’infrastructure de messagerie d’entreprise locale en utilisant l’authentification basée sur les revendications AD FS.

Configurer une stratégie d’accès conditionnel

Pour configurer une stratégie d'accès conditionnel Microsoft Entra qui applique l'authentification multifacteur, comme décrit à l'étape 3 du flux de l'utilisateur en ligne plus haut dans cet article :

Configurez Office 365 Exchange Online ou Office 365 en tant qu’application cloud :
Configurez le navigateur en tant qu’application cliente :
Appliquez l'exigence d'authentification multifacteur dans la fenêtre Accorder :

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

Pavel Kondrashov | Architecte de solution cloud
Ella Parkum | Architecte principale de solutions client - Ingénierie

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Infrastructure de messagerie hybride à sécurité renforcée - Accès web