Présentation de la sécurité de domaine
S’applique à : Exchange Server 2010 SP2, Exchange Server 2010 SP3
Dernière rubrique modifiée : 2016-11-28
La sécurité de domaine fait référence à l'ensemble des fonctionnalités de Microsoft Exchange Server 2010 et de Microsoft Office Outlook 2007 qui fournissent une alternative relativement économique à S/MIME ou à d'autres solutions de sécurité au niveau message. Le rôle de la fonctionnalité de sécurité de domaine est de fournir aux administrateurs un moyen de gérer les chemins de messages sécurisés sur Internet avec les partenaires commerciaux. Une fois que ces chemins de messages sécurisés sont configurés, les messages ayant voyagé avec succès sur le chemin sécurisé d'un expéditeur authentifié sont affichés à l'attention de l'utilisateur comme en provenance d'un domaine sécurisé dans l'interface d'Outlook et de Microsoft Office Outlook Web App.
La sécurité de domaine utilise l'authentification TLS (Transport Layer Security) mutuelle pour fournir une authentification et un chiffrement basés sur la session. L'authentification TLS mutuelle diffère du protocole TLS tel qu'il est généralement implémenté. En règle générale, lorsque TLS est implémenté, le client vérifie que la connexion au serveur souhaité s'établit de manière sécurisée en validant le certificat du serveur. Celui-ci est reçu dans le cadre de la négociation TLS. Dans ce scénario, le client authentifie le serveur avant que le client ne transmette les données. Toutefois, le serveur n’authentifie pas la session auprès du client.
Avec l'authentification TLS manuelle, chaque serveur vérifie la connexion auprès de l'autre serveur en validant un certificat fourni par l'autre serveur. Dans ce scénario, lorsque des messages sont reçus de domaines externes sur des connexions vérifiées dans un environnement Exchange 2010, Outlook 2007 affiche une icône « Domaine sécurisé ».
.gif "Important") Important : |
|---|
| L'objet de cette rubrique n'est pas de donner un explication détaillée des technologies et concepts relatifs à la cryptographie et aux certificats. Avant de déployer une solution de sécurité qui utilise la cryptographie et les certificats numériques, il est conseillé de comprendre les concepts de base de l’approbation, de l’authentification, du chiffrement et de l’échange de clés publiques et privées. Pour plus d'informations, consultez les références répertoriées à la fin de cette rubrique. |
Souhaitez-vous rechercher les tâches de gestion relatives à la gestion des serveurs de transport ? Voir Gestion des serveurs de transport.
Validation de certificats TLS
Pour comprendre la sécurité globale et la fiabilité résultante d'une transmission TLS mutuelle, vous devez comprendre la manière dont le certificat TLS sous-jacent est validé.
Exchange 2010 comprend un ensemble de cmdlets permettant de créer, de demander et de gérer les certificats TLS. Par défaut, ces certificats ont été auto-signés. Un certificat auto-signé est un certificat signé par son propre créateur. Dans Exchange 2010, les certificats auto-signés sont créés par l'ordinateur qui exécute Microsoft Exchange à l'aide de l'API de cryptographie (CAPI) Microsoft Windows sous-jacente. Les certificats étant auto-signés, les certificats obtenus sont moins dignes de confiance que les certificats générés par l’infrastructure à clé publique (PKI) ou une autorité de certification tierce. Nous vous recommandons donc d’utiliser les certificats auto-signés pour le courrier interne uniquement. De la même façon, si les organisations de réception avec lesquelles vous échangez manuellement des messages électroniques de domaine sécurisé ajoutent votre certificat auto-signé au magasin de certificats racines approuvés de chacun de leurs serveurs de transport Edge entrants, les certificats auto-signés sont approuvés explicitement.
Pour les connexions qui traversent Internet, il est vivement conseiller de générer des certificats TLS avec une infrastructure à clé publique ou une autorité de certification tierce. La génération de clés TLS avec une infrastructure à clé publique ou une autorité de certification tierce réduit la gestion globale de la sécurité de domaine. Pour plus d’informations sur les options concernant les certificats approuvés et la sécurité de domaine, voir Utilisation d'une infrastructure à clé publique sur le serveur de transport Edge pour la sécurité d'un domaine.
Vous pouvez utiliser les cmdlets de certificat Exchange 2010 pour générer des demandes de certificat pour votre propre infrastructure à clé publique ou pour des autorités de certification tierces. Pour plus d'informations, voir Présentation des certificats TLS.
Pour plus d'informations sur la configuration de Domain Security, consultez les documents suivants :
Utilisation des services Exchange hébergés
La sécurité au niveau message est améliorée par les services hébergés Microsoft Exchange ou disponible auprès de ces sites.
Exchange Hosted Services comprend quatre services hébergés distincts :
Filtrage hébergé, qui aide les organisations à se protéger des logiciels malveillants circulant par courrier électronique
Archive hébergée, qui les aide à répondre aux exigences de rétention à des fins de conformité
Chiffrement hébergé, qui les aide à chiffrer des données afin de préserver la confidentialité
Continuité hébergée, qui les aide à conserver l’accès à la messagerie pendant et après des situations d’urgence
Ces services s’intègrent avec tout serveur Exchange sur site géré en interne ou tout service de messagerie Exchange hébergé offert via des fournisseurs de service. Pour plus d’informations sur Exchange Hosted Services, voir Services Microsoft Exchange Hosted Services.
Ressources
Housley, Russ et Tim Polk. Planification de l'infrastructure à clé publique (PKI) : Guide des meilleures pratiques pour le déploiement d’une infrastructure ç clé publique (Best Practices Guide for Deploying Public Key Infrastructure) New York : John Wiley & Son, Inc., 2001.
Adams, Carlisle et Steve Lloyd. Cryptographie Appliquée : Algorithmes, protocoles et codes source en langage C, 2e Edition. (Applied Cryptography : Protocols, Algorithms, and Source Code in C, 2nd Edition). New York : John Wiley & Son, Inc., 1996.
© 2010 Microsoft Corporation. Tous droits réservés.