Exporter (0) Imprimer
Développer tout

Guide sur la sécurité dans Exchange 2010

Exchange 2010
 

S’applique à : Exchange Server 2010 SP3, Exchange Server 2010 SP2

Dernière rubrique modifiée : 2012-03-08

Ce guide est destiné à l’administrateur du service informatique chargé de sécuriser le déploiement de Microsoft Exchange Server 2010. Il est conçu pour aider l’administrateur à comprendre et à gérer l’environnement de sécurité global dans lequel Exchange est installé.

Auparavant, pour chaque version de Microsoft Exchange, l’équipe Exchange publiait des guides sur le renforcement de la sécurité autonomes avec des informations sur les autorisations et la sécurité. Cette approche était utile pour le verrouillage des services et des répertoires après l’exécution de l’installation d’Exchange 2010. Toutefois, avec Microsoft Exchange Server 2007, l’installation d’Exchange n’active que les services requis par le rôle serveur en cours d’installation. Microsoft Exchange n’est plus installé, par conséquent sa sécurité n’est plus renforcée. Il est conçu pour renforcer votre sécurité par défaut.

Donc, contrairement aux versions précédentes de Microsoft Exchange dans lesquelles les administrateurs du service informatique devaient appliquer plusieurs procédures pour verrouiller les serveurs exécutant Microsoft Exchange, Exchange 2010 ne nécessite ni verrouillage ni renforcement.

Exchange 2010 a été développé dans le respect des principes du cycle de développement de la sécurité de Microsoft (SDL, Security Development Lifecycle). La sécurité de chaque fonctionnalité et composant a été vérifiée. Des paramètres par défaut choisis avec soin sont les garants d’un déploiement sécurisé. Ce guide vise à informer les administrateurs des fonctionnalités relatives à la sécurité et des fonctionnalités qui peuvent avoir un impact sur les considérations de sécurité. Il fait référence aux rubriques concernant la sécurité de la documentation Exchange 2010. Ces rubriques sont répertoriées dans l’Annexe 1 : Documentation supplémentaire concernant la sécurité. Ce guide n’explique pas comment renforcer le système d’exploitation Windows Server.

Contenu de cette rubrique

Nouveautés

Cycle de développement de la sécurité d’Exchange 2010

Meilleures pratiques pour l’obtention de la sécurité

Meilleures pratiques pour le maintien de la sécurité

Utilisation des ports réseau et renforcement du pare-feu

Paramètres de limitation et stratégies de limitation du client

Contrôle d’accès basé sur les rôles

Active Directory

Comptes Exchange Server

Système de fichiers

Services

Certificats

Considérations relatives à NTLM

Authentification à deux facteurs

Fédération

Secure/Multipurpose Internet Mail Extensions (S/MIME)

Considérations relatives au rôle serveur

Annexe 1 : Documentation supplémentaire concernant la sécurité

Exchange 2010 inclut les nouvelles fonctionnalités de sécurité suivantes :

  • Contrôle d’accès basé sur un rôle   Exchange 2010 inclut un nouveau modèle de contrôle d’accès basé sur un rôle qui permet à votre organisation de gérer précisément les autorisations attribuées à différents intervenants, tels que les administrateurs de destinataires, les administrateurs de serveurs, les gestionnaires de découverte, les responsables d’enregistrements et les administrateurs de l’organisation.

  • Stratégies de limitation   Exchange 2010 introduit des mécanismes de limitation dans les serveurs de boîtes aux lettres, d’accès au client et de transport afin de protéger votre organisation des attaques par déni de service et réduire l’impact de telles attaques.

  • Délégation fédérée   Exchange 2010 introduit de nouvelles fonctionnalités de délégation fédérée grâce auxquelles vous pouvez autoriser vos utilisateurs à collaborer en toute sécurité avec des utilisateurs qui se trouvent dans des organisations externes. La délégation fédérée permet aux utilisateurs de partager leur calendrier et leurs contacts avec des utilisateurs situés dans des organisations fédérées externes. La collaboration entre forêts est également possible, sans avoir besoin de configurer ni de gérer des relations d’approbation Active Directory.

  • Gestion des droits relatifs à l’information   Exchange 2010 inclut de nouvelles fonctionnalités de protection et de contrôle de l’information qui vous permettent de protéger le contenu des messages confidentiels à plusieurs niveaux, tout en conservant les fonctions de votre organisation concernant le déchiffrement, la recherche et l’application de stratégies de messagerie visant à protéger le contenu.

  • Pas d’Assistant Configuration de la sécurité   Dans Exchange 2010, l’installation impose de modifier la configuration pour installer et activer uniquement les services requis pour un rôle serveur Exchange particulier et pour limiter les communications aux seuls ports requis pour les services et processus exécutés sur chaque rôle serveur. Ceci rend les outils, tels que l’Assistant Configuration de la sécurité, inutiles pour la configuration de ces paramètres.

Début 2002, Microsoft a introduit l’initiative informatique de confiance. Depuis l’introduction de l’informatique de confiance, le processus de développement de Microsoft et l’équipe Microsoft Exchange se sont concentrés sur le développement d’un logiciel qui renforce votre sécurité. Pour plus d’informations, voir Informatique de confiance.

Dans Exchange 2010, l’informatique de confiance a été mise en place dans les quatre domaines centraux suivants :

  • Sécurisé à la conception   Exchange 2010 a été conçu et développé conformément au cycle de développement sécurisé de l’informatique de confiance : Cycle de développement d’une sécurité informatique fiable. Lors du processus de création d’un système de messagerie plus sécurisé, la première étape a été la conception de modèles de menace et chaque fonction a été testée dès sa conception. Plusieurs améliorations liées à la sécurité ont été intégrées au processus et aux pratiques de codage. Des outils de modélisation détectent les dépassements de mémoire tampon et autres menaces potentielles de sécurité. Aucun système ne peut garantir une sécurité totale. Toutefois, grâce à l’inclusion de principes de conception sécurisée dans tout le processus de conception, Exchange 2010 est plus sécurisé que ses versions précédentes.

  • Sécurisé par défaut   Un objectif d’Exchange 2010 de développer un système dans lequel la plupart des communications réseau seraient chiffrées par défaut. À part pour les communications SMB (Server Message Block) du cluster et certaines communications de messagerie unifiée, l’objectif a été atteint. Grâce à l’utilisation de certificats auto-signés, des protocoles Kerberos, SSL (Secure Sockets Layer) et autres techniques de chiffrement standard de l’industrie, pratiquement toutes les données Exchange 2010 sont protégées sur le réseau. De plus, avec l’installation basée sur le rôle, il est possible d’installer Exchange 2010 de façon à ce que seuls les services et les autorisations liées à ces services soient installés avec un rôle serveur spécifique et approprié. Dans les versions précédentes de Microsoft Exchange, tous les services de toutes les fonctionnalités devaient être installés. 

  • Blocage du courrier indésirable et fonctionnalité antivirus   Exchange 2010 intègre une suite d’agents de blocage du courrier indésirable exécutée sur le réseau du périmètre sur le rôle de serveur de transport Edge, et peut également être installée sur le rôle de serveur de transport Hub qui se trouve sur le réseau interne. La fonctionnalité antivirus a été améliorée grâce à l’ajout de Microsoft Forefront Protection 2010 for Exchange Server comme solution Microsoft.

  • Sécurisé dans le déploiement   Lors du développement de Exchange 2010, la version préliminaire a été déployée dans l’environnement de production du service informatique Microsoft. À partir des données obtenues lors de ce déploiement, Microsoft Exchange Server Best Practice Analyzer a été mis à jour pour détecter des configurations de sécurité basées sur la réalité, et les meilleures pratiques préalables et postérieures au déploiement ont été répertoriées dans l’Aide d’Exchange 2010. 

    Auparavant, la gestion des autorisations était documentée et remise une fois que la documentation principale était achevée. Toutefois, nous savons que la gestion des autorisations n’est pas un processus complémentaire. Elle devrait être intégrée à l’ensemble de la planification et du déploiement d’Exchange 2010. C’est pourquoi nous avons rationalisé notre documentation sur les autorisations et l’avons intégrée à la documentation principale afin de fournir un contexte sans faille aux administrateurs lorsqu’ils planifient ou déploient leur modèle administratif. Exchange 2010 inclut un nouveau modèle d’autorisations basé sur les rôles qui vous permet d’accorder des autorisations précises aux administrateurs et utilisateurs afin qu’ils puissent effectuer des tâches avec les autorisations minimales requises.

  • Communications   Maintenant que Exchange 2010 a été publié, l’équipe Exchange s’engage à actualiser le logiciel et à vous tenir informé. En maintenant à jour votre système avec Microsoft Update, vous êtes assuré que les dernières mises à jour de sécurité sont installées dans votre organisation. Exchange 2010 intègre également des mises à jour pour le blocage du courrier indésirable. De plus, en vous abonnant aux Microsoft Technical Security Notifications (en anglais), vous pouvez vous tenir au courant des derniers problèmes de sécurité dans Exchange 2010.

Certaines meilleures pratiques de base vous aideront à créer et à maintenir un environnement plus sécurisé. En général, pour optimiser votre environnement Exchange 2010 le plus efficacement en termes de sécurité, il suffit d’exécuter des analyseurs régulièrement et de maintenir à jour le logiciel et les fichiers de signature antivirus.

Ces meilleures pratiques vous aideront à créer un environnement Exchange 2010 plus sécurisé :

  • Installation déléguée   Lorsque vous installez le premier serveur Exchange 2010 dans votre organisation, le compte que vous utilisez pour exécuter le programme d’installation doit être membre du groupe Administrateurs d’entreprise. Le compte utilisé est ajouté au groupe de rôles Gestion de l’organisation créé par le programme d’installation d’Exchange 2010. Vous pouvez utiliser l’installation déléguée pour autoriser les administrateurs qui ne sont pas membres du groupe de rôles Gestion de l’organisation à configurer d’autres serveurs. Pour plus d’informations, voir Configurer un serveur Exchange 2010 et déléguer l'installation.

  • Autorisations du système de fichiers   Le programme d’installation d’Exchange 2010 attribue les autorisations minimales requises dans le système de fichiers dans lequel les fichiers binaires et les données d’Exchange sont stockés. Vous ne devez pas modifier les listes de contrôle d’accès dans les dossiers racine et le dossier Program Files du système de fichiers.

  • Chemins d’installation   Nous vous conseillons d’installer les fichiers binaires d’Exchange 2010 sur un lecteur non-système (volume autre que celui sur lequel le système d’exploitation est installé). Les bases de données et les journaux de transaction d’Exchange peuvent croître rapidement et doivent se trouver sur des volumes non-systèmes adaptés à la capacité et aux performances. De nombreux autres journaux générés par différents composants Exchange, tels que les journaux de transport, sont également stockés dans le même chemin d’installation que les fichiers binaires d’Exchange et peuvent s’étendre de façon conséquente, selon la configuration et votre environnement de messagerie. Dans Exchange 2010, la taille maximale de nombreux fichiers journaux et l’espace de stockage maximal qu’un dossier de fichiers journaux peut occuper sont configurables. La valeur définie par défaut est 250 mégaoctets. Pour empêcher toute défaillance système potentielle liée à un espace disque insuffisant, nous vous recommandons d’évaluer les exigences d’enregistrement de chaque rôle serveur et de configurer les options d’enregistrement et l’emplacement de stockage des fichiers journaux en fonction de ces exigences.

  • Blocage des clients Outlook hérités   En fonction de vos besoins, vous pouvez configurer le blocage des clients Outlook pour bloquer les versions des clients Outlook hérités. Certaines fonctionnalités d’Exchange 2010, telles que les règles de protection Outlook et les archives personnelles, ne prennent pas en charge les clients Outlook hérités. Pour plus d’informations sur le blocage des clients Outlook, voir Configurer le blocage de clients Outlook pour la gestion des enregistrements de messagerie.

  • Découplement des adresses SMTP par rapport aux noms d’utilisateur   Par défaut, Exchange génère des adresses de messagerie et des alias en fonction du nom d’utilisateur de la personne utilisant la boîte aux lettres. Dans le but de renforcer la sécurité, de nombreuses organisations mettent en place une stratégie d’adresse de messagerie supplémentaire qui consiste à découpler les adresses de messagerie de l’utilisateur des noms d’utilisateur. Par exemple, si le nom d’utilisateur de Ben Smith est bsmith et le domaine est contoso.com, l’adresse de messagerie principale générée par la stratégie d’adresse de messagerie par défaut est bsmith@contoso.com. Vous pouvez créer une stratégie d’adresse de messagerie supplémentaire afin de générer des adresses dans lesquelles le nom d’utilisateur ou l’alias de l’utilisateur n’apparaît pas. Ainsi, vous pouvez créer une stratégie d’adresse de messagerie utilisant le modèle %g.%s@domain pour générer des adresses au format Prénom.Nom@domaine. Pour l’utilisateur Ben Smith, la stratégie donnera l’adresse Ben.Smith@contoso.com. Vous pouvez également découpler les adresses de messagerie des noms d’utilisateur en spécifiant un alias différent du nom d’utilisateur lorsque vous créez ou activez une boîte aux lettres.

    RemarqueRemarque :
    Si l’adresse SMTP principale d’un utilisateur ne correspond pas au nom d’utilisateur principal du compte, l’utilisateur ne peut pas utiliser son adresse de messagerie pour se connecter à Microsoft Office Outlook Web App et doit fournir un nom d’utilisateur au format DOMAINE\nom_utilisateur. Lorsqu’il utilise Microsoft Outlook, l’utilisateur doit fournir le nom d’utilisateur au format DOMAINE\nom_utilisateur si le système lui demande ses informations d’identification lorsqu’Outlook se connecte au service de découverte automatique.

Microsoft Update est un nouveau service offrant les mêmes téléchargements que Microsoft Windows Update, ainsi que les dernières mises à jour d’autres programmes Microsoft. Il peut permettre à votre serveur d’optimiser sa sécurité et ses performances.

Une des fonctionnalités clés de Microsoft Update est la mise à jour automatique Windows. Cette fonctionnalité installe automatiquement les mises à jour à priorité élevée essentielles à la sécurité et à la fiabilité de votre ordinateur. Sans ces mises à jour de sécurité, votre ordinateur est plus vulnérable aux attaques de cyber-criminels et programmes malveillants.

La façon la plus fiable d’utiliser Microsoft Update est de recevoir les mises à jour automatiquement sur votre ordinateur à l’aide des mises à jour automatiques Windows. Vous pouvez activer les mises à jour automatiques lorsque vous vous inscrivez à Microsoft Update.

Windows analyse alors le logiciel Microsoft installé sur votre ordinateur pour rechercher toute mise à jour à priorité élevée actuelle et passée requise, puis il les télécharge et les installe automatiquement. Par la suite, dès que vous vous connectez à Internet, Windows répète ce processus de mise à jour pour toute nouvelle mise à jour à priorité élevée.

Pour activer Microsoft Update, consultez la page Microsoft Update

Le mode par défaut de Microsoft Update exige que chaque serveur Exchange soit connecté à Internet afin de recevoir les mises à jour automatiques. Si vous exécutez des serveurs qui ne sont pas connectés à Internet, vous pouvez installer Windows Server Update Services (WSUS) pour gérer la distribution des mises à jour aux ordinateurs de votre organisation. Vous pouvez ensuite configurer Microsoft Update sur les ordinateurs Microsoft Exchange internes de façon à contacter votre serveur WSUS interne pour les mises à jour. Pour plus d’informations, voir Microsoft Windows Server Update Services 3.0

WSUS n’est pas la seule solution Microsoft de gestion de mises à jour disponible. Pour plus d’informations sur les mises à jour de sécurité, les processus, les communications et les outils de Microsoft, voir le guide Microsoft Security Update Guide (en anglais).

Il n’est plus nécessaire d’installer ou d’exécuter les outils suivants :

  • L’outil de sécurité URLScan n’est pas nécessaire pour IIS 7. Dans les versions antérieures de Microsoft Exchange, il était fréquent d’installer les outils IIS, tels qu’URLScan, pour sécuriser une installation IIS. Exchange 2010 requiert Windows Server 2008, qui inclut IIS 7. Un grand nombre des fonctionnalités de sécurité qui étaient à l’origine comprises dans UrlScan sont maintenant disponibles dans les fonctionnalités Filtrage des demandes d’IIS 7.

  • Vous n’avez plus besoin d’installer Exchange Best Practices Analyzer. Dans les versions antérieures de Microsoft Exchange, il était habituel d’installer et d’exécuter l’outil Exchange Best Practices Analyzer avant l’installation, puis après de façon régulière. Le programme d’installation d’Exchange 2010 inclut les composants Exchange Best Practices Analyzer et les exécute au cours de l’installation. Il n’est pas nécessaire d’exécuter Exchange Best Practices Analyzer avant l’installation.

  • Vous n’avez plus besoin d’utiliser l’Assistant Configuration de la sécurité ou les modèles Exchange de l’Assistant. Le programme d’installation d’Exchange 2010 installe uniquement les services requis pour un rôle serveur Exchange donné et crée un pare-feu Windows avec règles de sécurité avancées pour ouvrir uniquement les ports nécessaires aux services et processus de ce rôle serveur. Il n’est plus nécessaire d’exécuter l’Assistant Configuration de la sécurité pour ce faire. Contrairement à Exchange Server 2007, Exchange 2010 ne comprend pas les modèles de l’Assistant Configuration de la sécurité.

Ces recommandations vous aideront à maintenir la sécurité de votre environnement Exchange 2010.

Comme indiqué ci-avant, l’exécution de Microsoft Update est recommandée. En plus d’exécuter Microsoft Update sur tous les serveurs, il est également très important de maintenir les ordinateurs clients à jour et de conserver les mises à jour de l’antivirus sur tous les ordinateurs de votre organisation.

En plus du logiciel Microsoft, assurez-vous que vous exécutez les dernières mises à jour de tous les logiciels exécutés dans votre organisation.

Exchange 2010 utilise également l’infrastructure de Microsoft Update pour maintenir à jour les filtres de blocage du courrier indésirable. Par défaut, avec les mises à jour manuelles, l’administrateur doit visiter Microsoft Update pour télécharger et installer les mises à jour du filtrage du contenu. Les données de mise à jour du filtrage du contenu sont actualisées et mises à disposition toutes les deux semaines.

Les mises à jour manuelles de Microsoft Update n’incluent pas les données du service de réputation d’IP de Microsoft ou de signature de courrier indésirable. Les données du service de réputation d’IP de Microsoft et de signature de courrier indésirable sont uniquement disponibles avec Forefront Security pour les mises à jour automatiques de blocage du courrier indésirable d’Exchange Server.

Pour plus d’informations sur l’activation des mises à jour automatiques du blocage du courrier indésirable de Forefront, voir Présentation des mises à jour du blocage du courrier indésirable.

Les virus, les vers et autres contenus nuisibles transmis par les systèmes de messagerie électronique sont une réalité destructrice à laquelle de nombreux administrateurs de Microsoft Exchange sont confrontés. Par conséquent, vous devez développer un déploiement antivirus de défense pour tous les systèmes de messagerie. Cette section fournit des recommandations pour le déploiement d’un logiciel antivirus pour Exchange 2010.

Vous devez notamment être vigilant concernant deux modifications importantes dans Exchange 2010 au moment de choisir un fournisseur de solutions antivirus :

  • À partir d’Exchange Server 2007, Microsoft Exchange est basé sur une architecture 64 bits.

  • Exchange 2010 comprend la fonctionnalité d’agent de transport.

Ces deux modifications impliquent que les fournisseurs de solutions antivirus doivent proposer des logiciels spécifiques à Exchange 2010. Un antivirus conçu pour les versions précédentes d’Exchange ne fonctionnera pas correctement avec Exchange 2010.

Pour utiliser une approche de défense approfondie, il est recommandé de déployer le logiciel antivirus conçu pour des systèmes de messagerie sur la passerelle SMTP ou sur les serveurs Exchange qui hébergent des boîtes aux lettres, en plus du logiciel antivirus installé sur le bureau de l’utilisateur.

Vous décidez des types de logiciels antivirus à utiliser et de l’emplacement de déploiement des logiciels en définissant l’équilibre approprié entre le coût et le risque que vous êtes prêt à assumer. Par exemple, certaines organisations exécutent des logiciels antivirus de messagerie sur la passerelle SMTP, des analyses antivirus au niveau des fichiers sur le serveur Exchange et des logiciels antivirus clients sur le bureau de l’utilisateur. Cette approche fournit une protection spécifique à la messagerie sur le client. D’autres organisations peuvent tolérer des coûts plus élevés et donc améliorer la sécurité en exécutant un logiciel de messagerie antivirus sur la passerelle SMTP, une analyse antivirus au niveau fichier sur le serveur Exchange et un logiciel client antivirus sur le bureau de l’utilisateur, en plus d’un logiciel antivirus compatible avec Exchange VSAPI (Virus Scanning Application Programming Interface) 2.5 sur le serveur de boîtes aux lettres Exchange.

Un antivirus de transport est implémenté en tant qu’agents de transport, ou en intègre. Les agents agissent sur les événements de transport, un peu comme les récepteurs d’événements dans les versions précédentes de Microsoft Exchange. Pour plus d’informations, voir Présentation des agents de transport.

RemarqueRemarque :
Les messages qui ne sont pas routés via le transport, tels que les éléments de dossiers publics, les éléments envoyés et les éléments de calendrier, qui ne peuvent être analysés que sur un serveur de boîtes aux lettres, ne sont pas protégés par une analyse antivirus uniquement du transport.

Des développeurs tiers peuvent écrire des agents de transport personnalisés pour exploiter le moteur d’analyse MIME sous-jacent afin d’effectuer une analyse antivirus fiable au niveau du transport. Pour obtenir la liste des partenaires antivirus et Exchange antispam, voir Fournisseurs de logiciels indépendants.

En outre, Forefront Protection for Exchange Server est une solution logicielle antivirus étroitement intégrée dans Exchange 2010, qui offre une protection antivirus supplémentaire pour l’environnement Exchange. Pour plus d’informations, voir Microsoft Forefront Protection 2010 for Exchange Server.

La première ligne de défense de votre organisation est l’endroit où votre antivirus de messagerie doit être exécuté en priorité. Il s’agit de la passerelle SMTP à travers laquelle les messages externes pénètrent dans votre environnement de messagerie. Dans Exchange 2010, la première ligne de défense est le serveur de transport Edge.

Si vous utilisez un serveur ou une passerelle SMTP autre qu’Exchange pour recevoir du courrier électronique entrant avant Exchange, il est recommandé de mettre en place des fonctions de blocage du courrier indésirable et antivirus suffisantes sur les hôtes SMTP autres qu’Exchange.

Dans Exchange 2010, tous les messages sont routés à travers un serveur de transport Hub. Cela inclut les messages envoyés ou reçus à l’extérieur de l’organisation Exchange et les messages envoyés à l’intérieur de l’organisation Exchange. Les messages sont envoyés à une boîte aux lettres située sur le même serveur de boîte aux lettres que l’expéditeur. Pour se protéger efficacement des propagations de virus dans votre organisation et pour fournir une deuxième ligne de défense, il est recommandé d’exécuter un antivirus de transport sur les serveurs de transport Hub.

Outre l’analyse antivirus sur les serveurs transport, une solution d’analyse Microsoft Exchange VSAPI (Virus Scanning API) exécutée sur les serveurs de boîtes aux lettres peut constituer un rampart de défense important dans de nombreuses organisations. Envisagez d’exécuter une solution antivirus VSAPI si l’une des conditions suivantes est vraie :

  • Les produits d’analyse antivirus de bureau déployés dans votre organisation ne sont pas complets et fiables.

  • Votre organisation veut disposer d’une protection supplémentaire que l’analyse des bases de données des boîtes aux lettres peut fournir.

  • Votre organisation a développé des applications personnalisées qui ont un accès par programme à une base de données Exchange.

  • Votre communauté d’utilisateurs publie régulièrement des messages dans des dossiers publics.

Les solutions antivirus qui utilisent Exchange VSAPI s’exécutent directement dans le traitement de banque d’informations Exchange. Les solutions VSAPI sont probablement les seules solutions pouvant protéger contre des vecteurs d’attaque qui placent du contenu infecté dans la banque d’informations Exchange en ignorant l’analyse de client et de transport standard. Par exemple, la solution VSAPI est la seule qui analyse les données qui sont soumises à une base de données par CDO (Collaboration Data Objects), WebDAV et les services Web Exchange. En outre, quand une propagation de virus se produit, souvent, une solution VSAPI offre la manière la plus rapide de supprimer et éliminer des virus d’une base de données de messagerie infectée.

Si vous déployez un logiciel antivirus du système de fichiers pour protéger vos serveurs Exchange, tenez compte des points suivants :

  • Vous devez exclure les répertoires de serveurs Exchange dans lesquels les bases de données de boîtes aux lettres et de dossiers publics Exchange sont stockées, des analyseurs antivirus du système de fichiers. Pour plus d’informations, voir Analyse antivirus au niveau fichier sur Exchange 2010.

  • Les analyseurs antivirus du système de fichiers ne protègent que les fichiers. Pour protéger les messages électroniques, vous devez mettre en place des produits antivirus et de sécurité de la messagerie compatibles avec Exchange, tels que notamment Microsoft Forefront, ou des produits tiers ou de partenaires appropriés. Pour en savoir plus sur la protection contre le courrier indésirable et les virus, voir Présentation de la fonction de blocage du courrier indésirable et des virus. Pour plus d’informations, voir Forefront Protection 2010 for Exchange Server : Vue d’ensemble.

  • Vous devez maintenir les signatures antivirus et de blocage du courrier indésirable à jour pour assurer une protection efficace.

  • Les rapports générés par les logiciels ou services antivirus et de blocage du courrier indésirable doivent être régulièrement examinés pour vérifier que la protection est active et efficace, détecter rapidement les problèmes et prendre les mesures appropriées.

Le filtrage du courrier indésirable et des virus est amélioré par les services hébergés Microsoft Exchange ou disponible auprès de ces sites. Les services Exchange hébergés comprennent 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 aide les organisations à répondre aux exigences de rétention et de conformité

  • Chiffrement hébergé, qui aide les organisations à chiffrer des données afin de préserver la confidentialité

  • Continuité hébergée, qui aide les organisations à conserver l’accès à la messagerie pendant et après des défaillances

Ces services s’intègrent aux serveurs Exchange locaux qui sont gérés en interne. Pour plus d’informations, voir Forefront Online Protection for Exchange.

Dans Exchange 2010, le filtrage des pièces jointes permet d’appliquer des filtres sur les serveurs de transport Edge pour contrôler les pièces jointes que reçoivent les utilisateurs. Le filtrage des pièces jointes prend de l’ampleur dans le contexte actuel où de nombreux types de pièces jointes contiennent des virus dangereux ou des matériaux inappropriés pouvant porter préjudice à l’ordinateur de l’utilisateur ou à l’organisation en endommageant des documents importants ou en rendant publiques des informations confidentielles.

Vous pouvez utiliser les types de filtrage des pièces jointes suivants pour contrôler les pièces jointes entrant ou sortant de votre organisation via un serveur de transport Edge :

Filtrage basé sur le nom de fichier ou l’extension de nom de fichier   Vous pouvez filtrer les pièces jointes en spécifiant le nom de fichier exact ou l’extension de nom de fichier à filtrer. NomFichierMauvais.exe est un exemple de filtre de nom de fichier exact. *.exe est un exemple de filtre d’extension de nom de fichier.

Filtrage basé sur le type de contenu MIME du fichier   Vous pouvez aussi filtrer les pièces jointes en spécifiant le type de contenu MIME à filtrer. Les types de contenu MIME indiquent la nature de la pièce jointe, s’il s’agit d’une image JPEG, d’un fichier exécutable, d’un fichier Microsoft Office Excel 2010 ou d’un autre type de fichier. Les types de contenu sont exprimés en type/sous-type. Par exemple, le type de contenu image JPEG est exprimé en image/jpeg.

Si une pièce jointe correspond à l’un de ces critères de filtrage, vous pouvez configurer les actions suivantes à appliquer à la pièce jointe.

  • Bloquer le message et la pièce jointe

  • Supprimer la pièce jointe mais transmettre le message

  • Supprimer silencieusement le message et la pièce jointe

Pour plus d’informations, voir Présentation du filtrage des pièces jointes.

RemarqueRemarque :
Vous ne pouvez pas utiliser l’agent de filtrage des pièces jointes pour filtrer les pièces jointes en fonction de leur contenu. Vous pouvez utiliser les règles de transport pour inspecter le contenu du message et de la pièce jointe, puis prendre des mesures telles que la suppression ou le rejet du message, ou la protection IRM du message et des pièces jointes. Pour plus d’informations, voir Présentation des règles de transport.

La fonctionnalité de filtrage des fichiers qui est fournie par Forefront Protection for Exchange Server inclut des fonctions avancées qui ne sont pas disponibles dans l’agent de filtrage des pièces compris avec Exchange 2010.

Par exemple, les fichiers conteneurs, qui sont des fichiers qui contiennent d’autres fichiers, peuvent être analysés à la recherche de types de fichier incriminés. Le filtrage de Forefront Protection for Exchange Server peut analyser les fichiers conteneurs suivants et agir sur les fichiers incorporés :

  • PKZip (.zip)

  • GNU Zip (.gzip)

  • Fichier compressé à extraction automatique d’archives (.zip)

  • Fichiers compressés (.zip)

  • Archive Java (.jar)

  • TNEF (winmail.dat)

  • Stockage structuré (.doc, .xls, .ppt, etc.)

  • MIME (.eml)

  • SMIME (.eml)

  • UUEncode (.uue)

  • Unix tape archive (.tar)

  • Archive RAR (.rar)

  • MACBinary (.bin)

RemarqueRemarque :
L’agent de filtrage des pièces jointes inclus avec Exchange 2010 détecte les types de fichier même s’ils ont été renommés. Le filtrage des pièces jointes s’assure également que les fichiers Zip et LZH compressés ne contiennent pas de pièces jointes bloquées en exécutant une recherche de correspondance entre l’extension du nom de fichier et les fichiers contenus dans le fichier Zip ou LZH compressé. Le filtrage de fichiers Forefront Protection for Exchange Server peut également déterminer si une pièce jointe bloquée a été renommée dans un fichier conteneur.

Vous pouvez également filtrer les fichiers par taille de fichier. De plus, vous pouvez configurer Forefront Protection for Exchange Server de manière à ce qu’il mette en quarantaine les fichiers filtrés ou qu’il envoie des notifications de message électronique Exchange basées sur les comparaisons de filtres de fichiers.

Pour plus d’informations, consultez la page sur la protection d’une organisation Microsoft Exchange avec Microsoft Forefront Security pour Exchange Server.

Exchange Best Practices Analyzer est l’un des outils les plus efficaces que vous pouvez exécuter régulièrement pour vérifier que votre environnement Exchange est sûr. L’outil Exchange Best Practices Analyzer examine automatiquement le déploiement d’Microsoft Exchange et détermine s’il est configuré conformément aux meilleures pratiques Microsoft. Dans Exchange 2010, l’outil Exchange Best Practices Analyzer est installé dans le cadre du programme d’installation d’Exchange et peut être lancé dans la section Outils de la console de gestion Exchange (EMC). Un accès réseau approprié permet à Exchange Best Practices Analyzer d’examiner tous vos serveurs AD DS (Active Directory Domain Services) et Exchange. L’outil Exchange Best Practices Analyzer comprend les vérifications de l’héritage des autorisations. Il teste également la validation des autorisations RBAC. Cette procédure inclut des tests visant à s’assurer que tous les utilisateurs peuvent accéder au Panneau de configuration Exchange (ECP), que tous les rôles RBAC par défaut créés par le programme d’installation d’Exchange sont configurés correctement et qu’au moins un compte d’administration est présent au sein de l’organisation Exchange.

Windows Server 2008 inclut le pare-feu Windows avec fonctions avancées de sécurité, un pare-feu d’inspection dynamique qui est activé par défaut. Le pare-feu Windows avec fonctions avancées de sécurité fournit les fonctionnalités suivantes :

  • Filtrage de tout le trafic IPv4 (IP version 4) et IPv6 (IP version 6) entrant ou sortant de l’ordinateur. Par défaut, tout le trafic entrant est bloqué sauf s’il s’agit d’une réponse à une requête sortante précédente provenant de l’ordinateur (trafic sollicité), ou s’il est spécifiquement autorisé par une règle créée pour autoriser ce trafic. Par défaut, tout le trafic sortant est autorisé, à l’exception des règles de sécurisation renforcée des services qui empêchent les services standard de communiquer de façon inattendue. Vous pouvez autoriser le trafic en fonction des numéros de port, des adresses IPv4 ou IPv6, du chemin d’accès et du nom d’une application, du nom d’un service en cours d’exécution sur l’ordinateur, ou de tout autre critère.

  • Protection du trafic réseau entrant ou sortant de l’ordinateur à l’aide du protocole IPsec pour vérifier l’intégrité du trafic réseau, pour authentifier l’identité des ordinateurs ou des utilisateurs d’envoi ou de réception et pour chiffrer le trafic à des fins de confidentialité.

Exchange 2010 est conçu pour s’exécuter avec le pare-feu Windows Server avec fonctions avancées de sécurité activé. Le programme d’installation d’Exchange crée les règles de pare-feu requises pour autoriser les services et processus Exchange à communiquer. Il crée uniquement les règles nécessaires aux services et processus installés sur un rôle serveur donné. Pour en savoir plus sur l’utilisation des ports réseau et les règles de pare-feu créées pour chaque rôle de serveur Exchange 2010, voir Référence de port de réseau Exchange.

Dans Windows Server 2008 et Windows Server 2008 R2, le pare-feu Windows avec fonctions avancées de sécurité vous permet de spécifier le processus ou le service pour lequel un port est ouvert. Cette méthode est plus sécurisée car elle limite l’utilisation du port au processus ou au service spécifié dans la règle. Le programme d’installation d’Exchange 2010 crée des règles de pare-feu avec le nom de processus spécifié. Dans certains cas, une règle supplémentaire qui n’est pas limitée au processus est également créée à des fins de compatibilité. Vous pouvez désactiver ou supprimer les règles qui ne sont pas limitées aux processus et conserver les règles correspondantes qui sont également créées par le programme d’installation d’Exchange 2010 et qui sont limitées aux processus, si votre déploiement les prend en charge. Le nom des règles non limitées aux processus contient (GFW). Nous vous recommandons de tester suffisamment les règles dans votre environnement avant de désactiver les règles qui ne sont pas limitées à un processus.

Le tableau suivant dresse la liste des règles de pare-feu Windows créées par le programme d’installation d’Exchange, y compris les ports ouverts sur chaque rôle serveur.

Règles de pare-feu Windows

Nom de la règle Rôles serveur Port

MSExchangeRPCEPMap (GFW) (TCP-Entrée)

Tous les rôles

RPC-EPMap

MSExchangeRPC (GFW) (TCP-Entrée)

Accès client, transport Hub, boîte aux lettres, messagerie unifiée

RPC dynamique

MSExchange - IMAP4 (GFW) (TCP-Entrée)

Accès au client

143, 993 (TCP)

MSExchange - POP3 (GFW) (TCP-Entrée)

Accès au client

110, 995 (TCP)

MSExchange - OWA (GFW) (TCP-Entrée)

Accès au client

5075, 5076, 5077 (TCP)

MSExchangeMailboxReplication (GFW) (TCP-Entrée)

Accès au client

808 (TCP)

MSExchangeIS (GFW) (TCP-Entrée)

Boîte aux lettres

6001, 6002, 6003, 6004 (TCP)

MSExchangeTransportWorker (GFW) (TCP-Entrée)

Transport Hub

25, 587 (TCP)

SESWorker (GFW) (TCP-Entrée)

Messagerie unifiée

N’importe lequel

UMService (GFW) (TCP-Entrée)

Messagerie unifiée

5060, 5061 (TCP)

UMWorkerProcess (GFW) (TCP-Entrée)

Messagerie unifiée

5065, 5066, 5067, 5068

ImportantImportant :
Lorsque vous modifiez le port par défaut utilisé par un service Exchange 2010, vous devez également modifier la règle de pare-feu Windows avec fonctions avancées de sécurité correspondante pour autoriser la communication sur le port que vous décidez d’utiliser (et qui n’est pas le port par défaut). Exchange 2010 ne modifie pas les règles de pare-feu lorsque vous changez les ports par défaut utilisés pour un service.

Exchange 2010 inclut des paramètres de limitation sur les rôles serveur de transport, d’accès au client et de boîte aux lettres pour contrôler différents paramètres de connexion inhérents à chaque protocole. Exchange 2010 comprend également des stratégies de limitation du client pour contrôler la charge des serveurs d’accès au client. Ces paramètres et stratégies de limitation vous aident à contrôler la charge et à protéger les serveurs Exchange 2010 des attaques par déni de service ciblées sur différents protocoles.

Sur les serveurs de transport Exchange 2010, des paramètres de limitation des messages sont implémentés sur le serveur et sur les connecteurs d’envoi et de réception pour contrôler la vitesse de traitement des messages, la vitesse de connexion SMTP et les délais d’expiration des sessions SMTP. Ensemble, ces paramètres de limitation empêchent les serveurs de transport d’être surchargés en acceptant et en remettant un grand nombre de messages, en offrant une protection contre les clients SMTP non autorisés et les attaques par déni de service.

Vous pouvez configurer les stratégies de limitation suivantes sur les serveurs de transport Exchange 2010 à l’aide de la cmdlet Set-TransportServer.

Paramètres de limitation des serveurs de transport

Paramètre Description

MaxConcurrentMailboxDeliveries

Le paramètre MaxConcurrentMailboxDeliveries spécifie le nombre maximal de threads de remise que le serveur de transport Hub peut ouvrir simultanément pour remettre des messages à des boîtes aux lettres. Le pilote de banque d’informations du serveur de transport Hub est responsable de la remise des messages entre les serveurs de boîtes aux lettres. Ces limites s’appliquent à la remise des messages dans les boîtes aux lettres de l’organisation Exchange.

Valeur par défaut   20 remises

MaxConcurrentMailboxSubmissions

Le paramètre MaxConcurrentMailboxSubmissions spécifie le nombre maximal de threads de remise que le serveur de transport Hub peut ouvrir simultanément pour accepter des messages provenant de boîtes aux lettres. Le pilote de banque d’informations du serveur de transport Hub est responsable de la remise des messages entre les serveurs de boîtes aux lettres. Ces limites s’appliquent à l’acceptation de nouveaux messages provenant de boîtes aux lettres de l’organisation Exchange.

Valeur par défaut   20 soumissions

MaxConnectionRatePerMinute

Le paramètre MaxConnectionRatePerMinute spécifie la vitesse maximale à laquelle de nouvelles connexions entrantes peuvent être ouvertes sur les serveurs de transport Hub ou de transport Edge. Ces connexions sont ouvertes sur les connecteurs de réception existant sur le serveur.

Valeur par défaut   1 200 connexions par minute.

MaxOutboundConnections

Le paramètre MaxOutboundConnections spécifie le nombre maximal de connexions sortantes simultanées que les serveurs de transport Hub ou de transport Edge peuvent ouvrir simultanément. Les connexions sortantes se produisent en utilisant les connecteurs d’envoi existant sur le serveur. La valeur spécifiée par le paramètre MaxOutboundConnections s’applique à tous les connecteurs d’envoi existant sur le serveur de transport.

Valeur par défaut   1 000 connexions.

Si vous entrez la valeur illimitée, aucune limite n’est imposée quant au nombre de connexions sortantes.

Cette valeur peut également être configurée au moyen de la console de gestion Exchange.

MaxPerDomainOutboundConnections

Le paramètre MaxPerDomainOutboundConnections spécifie le nombre maximal de connexions qu’un serveur de transport Hub ou Edge côté Internet peut ouvrir sur un domaine distant. Les connexions sortantes aux domaines distants se produisent en utilisant les connecteurs d’envoi existant sur le serveur.

Valeur par défaut   20 connexions par domaine.

Si vous entrez la valeur illimitée, aucune limite n’est imposée quant au nombre de connexions sortantes par domaine.

Cette valeur peut également être configurée au moyen de la console de gestion Exchange.

PickupDirectoryMaxMessagesPerMinute

Le paramètre MaxPerDomainOutboundConnections spécifie la vitesse de traitement des messages pour les répertoires de collecte et de relecture. Chaque répertoire peut traiter de façon indépendante des fichiers de messages à la vitesse spécifiée par le paramètre PickupDirectoryMaxMessagesPerMinute. Valeurs par défaut   Par défaut, le répertoire de collecte peut traiter 100 messages par minute et le répertoire de relecture 100 messages par minute au même moment.

Les répertoires de collecte et de relecture recherchent de nouveaux fichiers de messages toutes les 5 secondes, soit 12 fois par minute. Cet intervalle de 5 secondes entre deux interrogations n’est pas configurable. Cela signifie que le nombre maximal de messages qui peuvent être traités durant cet intervalle correspond à la valeur que vous attribuez au paramètre PickupDirectoryMaxMessagesPerMinute, divisée par 12 (PickupDirectoryMaxMessagesPerMinute/12). Par défaut, un peu plus de 8 messages au maximum peuvent être traités pendant chaque intervalle de 5 secondes entre deux interrogations.

Les paramètres de limitation suivants sont disponibles sur les connecteurs d’envoi. Utilisez la cmdlet Send-Connector pour configurer ces paramètres.

Paramètres de limitation des connecteurs d’envoi

Paramètre Description

ConnectionInactivityTimeOut

Le paramètre ConnectionInactivityTimeOut spécifie la durée maximale pendant laquelle une connexion SMTP ouverte avec un serveur de messagerie de destination peut rester inactive avant d’être interrompue.

Valeur par défaut   10 minutes.

SmtpMaxMessagesPerConnection

Le paramètre SmtpMaxMessagesPerConnection spécifie le nombre maximal de messages que ce serveur d’envoi peut envoyer par connexion.

Valeur par défaut   20 messages

Vous pouvez configurer les paramètres de limitation suivants sur les connecteurs de réception des serveurs de transport Exchange 2010 pour contrôler des paramètres de connexion, tels que les délais d’inactivité, le nombre maximal de connexions et le nombre d’erreurs de protocole SMTP autorisées au cours d’une connexion. Utilisez la cmdlet Set-ReceiveConnector pour configurer ces paramètres.

Paramètres de limitation des connecteurs de réception

Paramètre Description

ConnectionInactivityTimeOut

Le paramètre ConnectionInactivityTimeOut spécifie la durée maximale pendant laquelle une connexion SMTP ouverte avec un serveur de messagerie source peut rester inactive avant d’être interrompue.

Valeur par défaut sur les serveurs de transport Hub   5 minutes.

Valeur par défaut sur les serveurs de transport Edge   1 minute.

ConnectionTimeOut

Le paramètre ConnectionTimeOut spécifie la durée maximale pendant laquelle une connexion SMTP avec un serveur de messagerie source peut rester ouverte, même si le serveur de messagerie source transmet des données.

Valeur par défaut sur les serveurs de transport Hub   10 minutes.

Valeur par défaut sur les serveurs de transport Edge   5 minutes.

La valeur spécifiée par le paramètre ConnectionTimeout doit être supérieure à la valeur spécifiée par le paramètre ConnectionInactivityTimeout.

MaxInboundConnection

Le paramètre MaxInboundConnection spécifie le nombre maximal de connexions SMTP entrantes que ce connecteur de réception autorise simultanément.

Valeur par défaut   5 000

MaxInboundConnectionPercentagePerSource

Le paramètre MaxInboundConnectionPercentagePerSource spécifie le nombre maximal de connexions SMTP qu’un connecteur de réception autorise simultanément depuis un serveur de messagerie source. La valeur est exprimée comme pourcentage de connexions restantes disponibles sur un connecteur de réception. Le nombre maximal de connexions autorisées par le connecteur de réception est défini par le paramètre MaxInboundConnection. Valeur par défaut   2 pour cent

MaxInboundConnectionPerSource

Le paramètre MaxInboundConnectionPerSource spécifie le nombre maximal de connexions SMTP qu’un connecteur de réception autorise simultanément depuis un serveur de messagerie source.

Valeur par défaut   100 connexions.

MaxProtocolErrors

Le paramètre MaxProtocolErrors spécifie le nombre maximal d’erreurs de protocole SMTP qu’un connecteur de réception autorise avant que le connecteur de réception ne ferme la connexion au serveur de messagerie source.

Valeur par défaut   5 erreurs

Les paramètres de limitation suivants sont disponibles pour le service POP3 de Microsoft Exchange sur les serveurs d’accès au client. Utilisez la cmdlet Set-POPSettings pour configurer ces paramètres. Pour plus d’informations, voir Définir les limites de connexion pour POP3.

Paramètres de limitation du service POP3

Paramètre Description

MaxCommandSize

Le paramètre MaxCommandSize spécifie la taille maximale d’une commande. Les valeurs possibles sont comprises entre 40 et 1 024 octets.

Valeur par défaut   40 octets.

MaxConnectonFromSingleIP

Le paramètre MaxConnectionFromSingleIP spécifie le nombre de connexions que le serveur spécifié accepte d’une adresse IP particulière. Les valeurs possibles vont de 1 à 25 000 octets.

Valeur par défaut   2 000 connexions.

MaxConnections

Le paramètre MaxConnections spécifie le nombre total de connexions que le serveur spécifié accepte. Celles-ci incluent les connexions authentifiées et non authentifiées. Les valeurs possibles vont de 1 à 25 000 octets.

Valeur par défaut   2 000 connexions.

MaxConnectionsPerUser

Le paramètre MaxConnectionsPerUser spécifie le nombre maximal de connexions que le serveur d’accès au client accepte d’un utilisateur particulier. Les valeurs possibles vont de 1 à 25 000 octets.

Valeur par défaut   16 connexions.

PreAuthenticationConnectionTimeOut

Le paramètre PreAuthenticatedConnectionTimeout spécifie le temps à attendre avant de fermer une connexion inactive non authentifiée. Les valeurs possibles sont comprises entre 10 et 3 600 secondes.

Valeur par défaut   60 secondes.

Les paramètres de limitation suivants sont disponibles pour le service IMAP4 de Microsoft Exchange sur les serveurs d’accès au client. Utilisez la cmdlet Set-IMAPSettings pour configurer ces paramètres. Pour plus d’informations, voir Définir les limites de connexion pour IMAP4.

Paramètres de limitation du service IMAP4

 

Paramètre Description

AuthenticationConnectionTimeOut

Le paramètre AuthenticatedConnectionTimeout spécifie le délai d’attente avant la fermeture d’une connexion authentifiée inactive. Les valeurs possibles sont comprises entre 30 et 86 400 secondes.

Valeur par défaut   1 800 secondes.

MaxCommandSize

Le paramètre MaxCommandSize spécifie la taille maximale d’une commande. La taille par défaut est 40 octets. Les valeurs possibles sont comprises entre 40 et 1 024 octets.

Valeur par défaut   40 octets.

MaxConnectionFromSingleIP

Le paramètre MaxConnectionFromSingleIP spécifie le nombre de connexions que le serveur spécifié accepte d’une adresse IP particulière. Les valeurs possibles vont de 1 à 25 000 octets.

Valeur par défaut   2 000 connexions.

MaxConnections

Le paramètre MaxConnections spécifie le nombre total de connexions que le serveur spécifié accepte. Celles-ci incluent les connexions authentifiées et non authentifiées. Les valeurs possibles vont de 1 à 25 000 octets.

Valeur par défaut   2 000 connexions.

MaxConnectionsPerUser

Le paramètre MaxConnectionsPerUser spécifie le nombre maximal de connexions que le serveur d’accès au client accepte d’un utilisateur particulier. Les valeurs possibles vont de 1 à 25 000 octets.

Valeur par défaut   16 connexions.

PreAuthenticatedConnectionTimeOut

Le paramètre PreAuthenticatedConnectionTimeout spécifie le temps à attendre avant de fermer une connexion inactive non authentifiée. Les valeurs possibles sont comprises entre 10 et 3600 secondes.

Valeur par défaut   60 secondes.

Dans Exchange 2010, vous pouvez utiliser les stratégies de limitation de client pour gérer les performances du serveur d’accès au client en contrôlant des paramètres, tels que le nombre de connexions simultanées pour chaque protocole d’accès au client, le pourcentage de temps qu’une session cliente peut consacrer à l’exécution d’opérations LDAP, d’opérations RPC et d’opérations d’accès au client. Il existe une stratégie de limitation de client par défaut qui est généralement suffisante pour gérer la charge placée sur les serveurs d’accès au client. Vous pouvez modifier les paramètres de la stratégie par défaut ou créer des stratégies personnalisées qui répondent aux besoins de votre déploiement.

Les stratégies de limitation sont disponibles pour les groupes d’utilisateurs et les méthodes d’accès suivants :

  • Accès anonyme

  • Accès intersite (CPA)

  • Exchange ActiveSync (EAS)

  • Services Web Exchange (EWS)

  • IMAP

  • POP

  • Outlook Web App (OWA)

  • Accès au client RPC (RCA)

Les paramètres de limitation suivants sont disponibles dans les stratégies de limitation de client pour chacun de ces groupes d’utilisateurs (Accès anonyme et CPA) et chacune de ces méthodes d’accès (EAS, EWS, IMAP, OWA, POP et RCA).

Paramètres de stratégie de limitation de client

Paramètre de limitation Accès anonyme CPA EAS EWS IMAP OWA POP RCA

Nombre max. d’accès simultanés

Oui

Oui

Oui

Oui

Oui

Oui

Oui

Oui

Pourcentage de temps dans AD

Oui

N/A

Oui

Oui

Oui

Oui

Oui

Oui

Pourcentage de temps dans CAS

Oui

Oui

Oui

Oui

Oui

Oui

Oui

Oui

Pourcentage de temps dans l’appel de procédure distante (RPC) des boîtes aux lettres

Oui

Oui

Oui

Oui

Oui

Oui

Oui

Oui

CPA   Accès intersite

EAS   Exchange ActiveSync

EWS   Services Web Exchange

OWA   Outlook Web App

En plus de ces paramètres de limitation basés sur les groupes d’utilisateurs et les méthodes d’accès, les paramètres de limitation suivants sont disponibles dans une stratégie de limitation de client.

Paramètres de stratégie de limitation de client

Paramètre Description

CPUStartPercent

Le paramètre CPUStartPercent spécifie le pourcentage processeur par processus à partir duquel commence l’interruption des utilisateurs soumis à cette stratégie. Les valeurs valides sont comprises entre 0 et 100. Utilisez $null pour désactiver la limitation en bande passante, basée sur le pourcentage processeur, qui est définie pour cette stratégie.

EASMaxDeviceDeletesPerMonth

Le paramètre EASMaxDeviceDeletesPerMonth impose une limite au nombre de partenariats Exchange ActiveSync qu’un utilisateur peut supprimer par mois. Par défaut, chaque utilisateur peut supprimer jusqu’à 20 partenariats par mois calendaire. Une fois la limite atteinte, la tentative de suppression du partenariat échoue et un message d’erreur est adressé à l’utilisateur.

EASMaxDevices

Le paramètre EASMaxDevices impose une limite au nombre de partenariats Exchange ActiveSync dont un utilisateur peut disposer en même temps. Par défaut, chaque utilisateur peut créer 10 partenariats Exchange ActiveSync par le biais de son compte Exchange. Une fois la limite dépassée, les utilisateurs doivent supprimer un de leurs partenariats existants avant de pouvoir créer d’autres partenariats. Un message d’erreur par courrier électronique détaillant la limite est transmis à l’utilisateur une fois la limite dépassée. De plus, un événement est consigné dans le journal des applications dès qu’un utilisateur dépasse la limite définie.

EWSFastSearchTimeOutInSeconds

Le paramètre EWSFastSearchTimeoutInSeconds spécifie l’intervalle de temps pendant lequel se poursuivent des recherches avec les Services Web Exchange avant que ce délai n’arrive à expiration. Si la recherche dure plus longtemps que le temps indiqué par la valeur de la stratégie, la recherche s’arrête et un message d’erreur est émis. La valeur par défaut de ce paramètre est de 60 secondes.

EWSFindCountLimit

Le paramètre EWSFindCountLimit définit la taille maximale du résultat des demandes FindItem ou FindFolder qui peuvent être simultanément mémorisées dans le serveur d’accès au client pour cet utilisateur pendant ce processus. Si vous essayez de rechercher plus d’éléments ou de dossiers que ne le permet la limite de votre stratégie, un message d’erreur est émis. Cependant, la limite n’est pas appliquée strictement si la demande est faite dans le cadre de l’affichage d’une page indexée. Dans ce scénario spécifique, les résultats de la recherche sont tronqués pour inclure le nombre d’éléments et de dossiers correspondant à la limite définie par la stratégie. Vous pouvez alors continuer à paginer vos résultats par d’autres demandes FindItem ou FindFolder.

EWSMaxSubscriptions

Le paramètre EWSMaxSubscriptions spécifie le nombre maximal d’abonnements actifs d’émission et de réception qu’un utilisateur peut avoir simultanément sur un serveur d’accès au client spécifique. Si l’utilisateur essaie de créer plus d’abonnements que le nombre maximal configuré, l’abonnement échoue et un événement est journalisé dans l’Observateur d’événements.

ExchangeMaxCmdlets

Le paramètre ExchangeMaxCmdlets spécifie le nombre de cmdlets qu’il est possible d’exécuter pendant un laps de temps donné avant que leur exécution ne ralentisse. La valeur spécifiée par ce paramètre doit être inférieure à la valeur spécifiée par le PowerShellMaxCmdlets parameter.

La période utilisée pour cette limite est spécifiée par le paramètre PowerShellMaxCmdletsTimePeriod. Nous vous recommandons de définir des valeurs pour les deux paramètres à la fois.

ForwardeeLimit

Le paramètre ForwardeeLimit spécifie les limites pour le nombre de destinataires qu’il est possible de configurer dans les règles de boîte de réception par le biais d’une action de transfert ou de redirection. Ce paramètre ne limite pas le nombre de messages qu’il est possible de transférer ou de rediriger vers les destinataires configurés.

MessageRateLimit

Le paramètre MessageRateLimit spécifie le nombre de messages par minute qu’il est possible de soumettre à des fins de transport. Pour les messages envoyés via le rôle serveur de boîtes aux lettres (Outlook Web App, Exchange ActiveSync ou les services Web Exchange), ceci entraîne une remise différée des messages jusqu’à ce que le quota de l’utilisateur soit disponible. De manière plus spécifique, les messages apparaissent dans le dossier Boîte d’envoi ou le dossier Brouillons pendant de plus longues périodes lorsque les utilisateurs envoient des messages à un débit supérieur à celui du paramètre MessageRateLimit.

Pour les clients POP ou IMAP qui envoient directement les messages à transporter via SMTP, une erreur temporaire survient s’ils envoient à un débit supérieur au paramètre MessageRateLimit . Exchange tente alors d’établir une connexion et d’envoyer les messages ultérieurement.

PowerShellMaxCmdletQueueDepth

Le paramètre PowerShellMaxCmdletQueueDepth spécifie le nombre d’opérations que l’utilisateur est autorisé à exécuter. Cette valeur affecte directement le comportement des paramètres PowerShellMaxCmdlets et PowerShellMaxConcurrency. Par exemple, le paramètre PowerShellMaxConcurrency consomme au moins deux opérations définies par le paramètre PowerShellMaxCmdletQueueDepth, mais des opérations supplémentaires sont également consommées lors de l’exécution des cmdlets. Le nombre d’opérations dépend des cmdlets exécutées. Il est recommandé que la valeur du paramètre PowerShellMaxCmdletQueueDepth soit au moins trois fois supérieure à celle du paramètre PowerShellMaxConcurrency parameter. Ce paramètre n’affectera pas les opérations du Panneau de configuration Exchange ou celles des services Web Exchange.

PowerShellMaxCmdlets

Le paramètre PowerShellMaxCmdlets spécifie le nombre de cmdlets qu’il est possible d’exécuter pendant un laps de temps donné avant que leur exécution ne s’arrête. La valeur spécifiée par ce paramètre doit être supérieure à la valeur spécifiée par le paramètre ExchangeMaxCmdlets. La période utilisée pour cette limite est spécifiée par le paramètre PowerShellMaxCmdletsTimePeriod. Ces deux valeurs doivent être définies en même temps.

PowerShellMaxCmdletsTimePeriod

Le paramètre PowerShellMaxCmdletsTimePeriod spécifie la période, en secondes, que la stratégie de limitation utilise pour déterminer si le nombre de cmdlets exécutées va au-delà des limites spécifiées par les paramètres PowerShellMaxCmdlets et ExchangeMaxCmdlets.

PowerShellMaxConcurrency

Le paramètre PowerShellMaxConcurrency spécifie des informations différentes selon le contexte :

Dans le contexte de la gestion à distance PowerShell, le paramètre PowerShellMaxConcurrency spécifie le nombre maximal de sessions Gestion à distance PowerShell qu’un utilisateur Gestion à distance PowerShell peut ouvrir simultanément.

Dans le contexte des Services Web Exchange, le paramètre PowerShellMaxConcurrency spécifie le nombre d’exécutions simultanées de cmdlets que peut avoir un utilisateur.

La valeur de ce paramètre n’est pas nécessairement liée au nombre de navigateurs ouverts par l’utilisateur.

RecipientRateLimit

Le paramètre RecipientRateLimit spécifie les limites du nombre de destinataires qu’un utilisateur peut traiter en l’espace de 24 heures.

Pour plus d’informations sur les stratégies de limitation Exchange 2010, voir Présentation des stratégies de limitation du client.

Le contrôle d’accès basé sur les rôles (RBAC) est le modèle d’autorisations d’Exchange 2010 qui vous permet de contrôler ce que les administrateurs et les utilisateurs peuvent réaliser, tant à des niveaux élargis que détaillés. Avec RBAC, il n’est plus nécessaire de modifier les listes de contrôle d’accès sur des objets Active Directory, tels que les unités d’organisation et les conteneurs par défaut, pour accorder la délégation précise d’autorisations à des groupes comme les opérateurs du support technique ou pour des fonctions comme la gestion des destinataires. Active Directory

Pour plus d’informations, voir Présentation du contrôle d'accès basé sur un rôle. Pour obtenir une liste des rôles de gestion RBAC inclus dans Exchange 2010, voir Rôles de gestion intégrés. Pour obtenir une liste des groupes de rôles par défaut, voir Groupes de rôles intégrés.

Les groupes de rôles créés par le programme d’installation d’Exchange 2010 ou par vous sont créés dans Active Directory en tant que groupes de sécurité universels dans l’unité d’organisation de groupes de sécurité Microsoft Exchange. Vous pouvez ajouter des membres à un groupe de rôles à l’aide de la cmdlet New-RoleGroupMember ou du Panneau de configuration Exchange (ECP). Lorsque vous ajoutez un membre à un groupe de rôles, l’utilisateur ou le groupe est ajouté au groupe de sécurité Active Directory correspondant. Vous pouvez utiliser une stratégie de groupe restreint pour limiter l’appartenance aux groupes de rôles RBAC importants, tels que Gestion de la découverte. Lorsque vous implémentez une stratégie de groupe restreint, l’appartenance au groupe est gérée par les contrôleurs de domaine Active Directory et tous les utilisateurs qui ne font pas partie de la stratégie sont automatiquement supprimés.

ImportantImportant :
Si vous utilisez les groupes restreints pour limiter l’appartenance aux groupes de rôles RBAC, les modifications que vous apportez au groupe de rôles à l’aide des outils Exchange 2010 doivent également être répercutées dans la stratégie du groupe restreint dans Active Directory. Pour plus d’informations, voir Group Policy Security Settings.

Exchange Server stocke les données de configuration dans la partition de configuration et les données des destinataires dans la partition de domaine AD DS (Active Directory Domain Services). Pour en savoir plus sur les autorisations requises pour configurer une organisation Exchange 2010, voir Référence d'autorisations de déploiement d'Exchange 2010. La communication avec les contrôleurs de domaine Active Directory est sécurisée à l’aide de l’authentification et du chiffrement Kerberos.

Exchange 2010 fournit un niveau d’autorisation supplémentaire à l’intérieur d’Exchange, connu sous le nom de contrôle d’accès basé sur les rôles (RBAC), au lieu de s’appuyer sur l’application des entrées de contrôle d’accès (ACE) pour chaque compte nécessitant les autorisations appropriées. Dans les versions antérieures de Microsoft Exchange, le programme d’installation d’Exchange s’appuyait sur ACE au sein d’Active Directory pour que les administrateurs Exchange puissent gérer les objets dans la partition de domaine. Les administrateurs Exchange sont autorisés à effectuer certaines opérations dans un cadre donné via le contrôle d’accès basé sur les rôles (RBAC). Le serveur Exchange exécute les actions autorisées au nom de l’administrateur ou des utilisateurs à l’aide des autorisations accordées dans Active Directory via les groupes de sécurité d’autorisations Exchange Windows et de sous-système approuvé Exchange. Pour plus d’informations sur le contrôle d’accès basé sur un rôle, voir Présentation du contrôle d'accès basé sur un rôle.

Dans Exchange 2010, /PrepapareDomain n’applique aucune entrée de contrôle d’accès pour le groupe de sécurité universel d’autorisations Exchange Windows au conteneur AdminSDHolder dans Active Directory. Si /PrepareDomain détecte que des entrées de contrôle d’accès ont été accordées au groupe de sécurité universel d’autorisations Exchange Windows, les entrées de contrôle d’accès sont supprimées. Cela comporte les implications ci-après :

  • Les membres du groupe de sécurité universel d’autorisations Exchange Windows ne peuvent pas modifier l’appartenance des groupes de sécurité protégés, tels que Administrateurs d’entreprise et Administrateurs de domaine. Cela comporte les implications ci-après.

  • Les membres du groupe de sécurité universel d’autorisations Exchange Windows ne peuvent pas forcer la redéfinition du mot de passe d’un compte protégé par l’objet AdminSDHolder.

  • Les membres du groupe de sécurité universel d’autorisations Exchange Windows ne peuvent pas modifier les autorisations d’un groupe ou compte protégé par l’objet AdminSDHolder.

Nous vous recommandons de ne pas activer les boîtes aux lettres pour les comptes protégés par l’objet AdminSDHolder et de conserver des comptes séparés pour les administrateurs Active Directory : un compte pour l’administration d’Active Directory et un compte pour l’utilisation habituelle quotidienne, dont la messagerie électronique. Pour plus de détails, consultez les rubriques suivantes :

Le programme d’installation d’Exchange 2010 crée une nouvelle unité d’organisation dans le domaine racine, appelée des groupes de sécurité Microsoft Exchange. Le tableau suivant présente les nouveaux groupes de sécurité universels.

Groupes de sécurité Microsoft Exchange

Groupe de sécurité Description

Exchange All Hosted Organizations

Ce groupe contient tous les groupes des boîtes aux lettres de l’organisation hébergées par Exchange. Il permet d’appliquer des objets de définition du mot de passe à toutes les boîtes aux lettres hébergées. Ce groupe ne doit pas être supprimé.

Exchange Servers

Ce groupe contient tous les serveurs Exchange. Il ne doit pas être supprimé. Nous déconseillons fortement toute modification d’appartenance à ce groupe.

Exchange Trusted Subsystem

Ce groupe contient des serveurs Exchange qui exécutent des cmdlets Exchange pour le compte d’utilisateurs via le service de gestion. Ses membres sont autorisés à lire et modifier toute la configuration Exchange, ainsi que les comptes d’utilisateur et les groupes. Ce groupe ne doit pas être supprimé.

Exchange Windows Permissions

Ce groupe contient des serveurs Exchange qui exécutent des cmdlets Exchange pour le compte d’utilisateurs via le service de gestion. Ses membres sont autorisés à lire et modifier tous les comptes et groupes Windows. Ce groupe ne doit pas être supprimé. Nous déconseillons fortement toute modification d’appartenance à ce groupe et suggérons de surveiller l’appartenance du groupe.

ExchangeLegacyInterop

Ce groupe est dédié à l’interopérabilité avec les serveurs Exchange 2003 au sein de la même forêt. Ce groupe ne doit pas être supprimé.

En plus de ces groupes de sécurité, le programme d’installation crée les groupes de sécurité suivants qui correspondent aux groupes de rôles RBAC de même nom.

Groupes de sécurité correspondant aux groupes de rôles RBAC

Groupe de sécurité Groupe de rôles RBAC

Installation déléguée

Installation déléguée

Gestion de la découverte

Gestion de la détection

Support technique

Support technique

Gestion de l’hygiène

Gestion de l’hygiène

Gestion de l’organisation

Gestion de l’organisation

Gestion des dossiers publics

Gestion des dossiers publics

Gestion des destinataires

Gestion des destinataires

Gestion des enregistrements

Gestion des enregistrements

Gestion du serveur

Gestion du serveur

Gestion de la messagerie unifiée

Gestion de messagerie unifiée

Afficher uniquement la gestion de l’organisation

Gestion de l’organisation en affichage seul

De même, lorsque vous créez un groupe de rôles, Exchange 2010 génère un groupe de sécurité du même nom en tant que groupe de rôles. Pour plus de détails, consultez les rubriques suivantes :

Les utilisateurs sont ajoutés ou supprimés de ces groupes de sécurité lorsque vous ajoutez ou supprimez des utilisateurs des groupes de rôles à l’aide de la cmdlet Add-RoleGroupMember ou Remove-RoleGroupMember, ou à l’aide de l’Éditeur des utilisateurs RBAC (contrôle d’accès basé sur un rôle) dans le Panneau de configuration Exchange (ECP).

Le programme d’installation d’Exchange 2010 crée des répertoires avec des autorisations minimales pour qu’Exchange 2010 puisse fonctionner. Nous conseillons de ne pas renforcer la sécurité des autorisations dans les listes de contrôle d’accès par défaut sur les répertoires créés par le programme d’installation.

Le programme d’installation d’Exchange 2010 ne désactive aucun service Windows par défaut. Le tableau suivant répertorie les services activés par défaut sur chaque rôle serveur. Seuls les services nécessaires au fonctionnement d’un rôle serveur Exchange 2010 en particulier sont activés par défaut.

Services installés par le programme d’installation d’Exchange

Nom du service Nom court du service Contexte de sécurité Description et dépendances Type de démarrage par défaut Rôles serveur Obligatoire (O) ou facultatif (F)

Microsoft Exchange Topologie Active Directory

MSExchangeADTopology

Système local

Fournit des informations de topologie Active Directory à plusieurs services Exchange. Si ce service est arrêté, la plupart des services Exchange ne peuvent pas démarrer. Ce service n’a pas de dépendance.

Automatique

Boîte aux lettres, transport Hub, accès au client, messagerie unifiée

O

Microsoft Exchange ADAM

ADAM_MSExchange

Service réseau

Stocke les données de configuration et les données des destinataires sur le serveur de transport Edge. Ce service représente l’instance nommée des services AD LDS (Active Directory Lightweight Directory Service), qui est automatiquement créée par le programme d’installation pendant l’installation du serveur de transport Edge. Ce service dépend du service Système d’événement COM+.

Automatique

Transport Edge

O

Carnet d’adresses Microsoft Exchange

MSExchangeAB

Système local

Gère les connexions du carnet d’adresses client. Ce service dépend du service de topologie Microsoft Exchange Active Directory.

Automatique

Accès au client

O

Mise à jour de la fonction antispam d’Microsoft Exchange

MSExchangeAntispamUpdate

Système local

Fournit le service de mise à jour de la fonction antispam de Microsoft Forefront Protection 2010 for Exchange. Sur les serveurs de transport Hub, ce service dépend du service de topologie Microsoft Exchange Active Directory. Sur les serveurs de transport Edge, ce service dépend du service ADAM Microsoft Exchange.

Automatique

Transport Hub, transport Edge

F

Service d’identification Microsoft Exchange

MSExchangeEdgeCredential

Système local

Contrôle les changements d’informations d’identification dans AD LDS et installe les changements sur le serveur de transport Edge. Ce service dépend du service ADAM Microsoft Exchange.

Automatique

Transport Edge

O

Microsoft Exchange EdgeSync

MSExchangeEdgeSync

Système local

Se connecte à l’instance AD LDS sur les serveurs de transport Edge abonnés via un canal sécurisé du protocole LDAP (Lightweight Directory Access Protocol) pour synchroniser les données entre un serveur de transport Hub et un serveur de transport Edge. Ce service dépend du service de topologie Microsoft Exchange Active Directory. Si l’abonnement Edge n’est pas configuré, ce service peut être désactivé.

Automatique

Transport Hub

F

Distribution de fichiers Microsoft Exchange

MSExchangeFDS

Système local

Distribue le carnet d’adresses en mode hors connexion (OAB) et les messages personnalisés de messagerie unifiée. Ce service dépend des services de topologie et de station de travail Microsoft Exchange Active Directory.

Automatique

Accès au client, messagerie unifiée

O

Authentification basée sur les formulaires Microsoft Exchange

MSExchangeFBA

Système local

Fournit une authentification basée sur les formulaires à Outlook Web App et au Panneau de configuration Exchange. Si ce service est arrêté, Outlook Web App et le Panneau de configuration Exchange ne pourront pas authentifier les utilisateurs. Ce service n’a pas de dépendance.

Automatique

Accès au client

O

Microsoft Exchange IMAP4

MSExchangeIMAP4

Service réseau

Fournit le service IMAP4 aux clients. Si ce service est arrêté, les clients ne peuvent pas se connecter à cet ordinateur en utilisant le protocole IMAP4. Ce service dépend du service de topologie Microsoft Exchange Active Directory.

Manuel

Accès au client

F

Banque d’informations Microsoft Exchange

MSExchangeIS

Système local

Gère la banque d’informations Exchange. Cela inclut les bases de données de boîtes aux lettres et de dossiers publics. S’il est arrêté, les bases de données de boîtes aux lettres et de dossiers publics se trouvant sur cet ordinateur ne sont pas disponibles. S’il est désactivé, tout service en dépendance directe ne pourra pas démarrer. Ce service dépend des services RPC, Serveur, Journal des événements Windows et Station de travail.

Automatique

Boîte aux lettres

O

Service de dépôt du courrier Microsoft Exchange

MSExchangeMailSubmission

Système local

Envoie des messages du serveur de boîtes aux lettres à des serveurs de transport Hub Exchange 2010. Ce service dépend du service de topologie Microsoft Exchange Active Directory.

Automatique

Boîte aux lettres

O

Assistants de boîte aux lettres Microsoft Exchange

MSExchangeMailboxAssistants

Système local

Effectue le traitement en arrière-plan de boîtes aux lettres dans la banque d’informations Exchange. Ce service dépend du service de topologie Microsoft Exchange Active Directory.

Automatique

Boîte aux lettres

O

Service de réplication de boîte aux lettres Microsoft Exchange

MSExchangeMailboxReplication

Système local

Traite les déplacements de boîtes aux lettres et les demandes de déplacement. Ce service dépend du service de topologie Microsoft Exchange Active Directory et du service Partage de port Net.Tcp.

Automatique

Accès au client

F

Surveillance Microsoft Exchange

MSExchangeMonitoring

Système local

Permet aux applications d’appeler les cmdlets de diagnostic d’Exchange. Ce service n’a pas de dépendance.

Manuel

Tous

F

Microsoft Exchange POP3

MSExchangePOP3

Service réseau

Fournit le service POP3 aux clients. Si ce service est arrêté, les clients ne peuvent pas se connecter à cet ordinateur en utilisant le protocole POP3. Ce service dépend du service de topologie Microsoft Exchange Active Directory.

Manuel

Accès au client

F

Hôte de service protégé Microsoft Exchange

MSExchangeProtectedServiceHost

Système local

Fournit un hôte à plusieurs services Exchange qui doivent être protégés d’autres services. Ce service dépend du service de topologie Microsoft Exchange Active Directory.

Automatique

Transport Hub, accès client

O

Service de réplication Microsoft Exchange

MSExchangeRepl

Système local

Fournit la fonctionnalité de réplication aux bases de données de boîtes aux lettres sur les serveurs de boîtes aux lettres dans un groupe de disponibilité de base de données (DAG). Ce service dépend du service de topologie Microsoft Exchange Active Directory.

Automatique

Boîte aux lettres

F

Accès au client RPC Microsoft Exchange

MSExchangeRPC

Service réseau

Gère les connexions du client RPC pour Exchange. Ce service dépend du service de topologie Microsoft Exchange Active Directory.

Automatique

Boîte aux lettres, accès au client

F (boîte aux lettres), O (accès client)

Microsoft Exchange Search Indexer

MSExchangeSearch

Système local

Pilote l’indexation du contenu des boîtes aux lettres, ce qui améliore les performances de recherche de contenu. Ce service dépend des services de topologie Microsoft Exchange Active Directory et de recherche Microsoft (Exchange Server).

Automatique

Boîte aux lettres

F

Extension Microsoft Exchange Server pour Sauvegarde Windows Server

WSBExchange

Système local

Permet aux utilisateurs de Sauvegarde Windows de sauvegarder et récupérer les données d’applications pour Microsoft Exchange. Ce service n’a pas de dépendance.

Manuel

Boîte aux lettres

F

Hôte de service Microsoft Exchange

MSExchangeServiceHost

Système local

Fournit un hôte à plusieurs services Exchange. Sur les rôles serveur interne, ce service dépend du service de topologie Microsoft Exchange Active Directory. Sur les serveurs de transport Edge, ce service dépend du service ADAM Microsoft Exchange.

Automatique

Tous

O

Moteur de reconnaissance vocale Microsoft Exchange

MSSpeechService

Service réseau

Fournit des services de traitement de la parole pour la messagerie unifiée. Ce service dépend du service Windows Management Instrumentation (WMI).

Automatique

Messagerie unifiée

O

Surveillance du système Microsoft Exchange

MSExchangeSA

Système local

Transfère les recherches d’annuaire à un serveur de catalogue global pour les clients hérités Outlook, génère des adresses de messagerie électronique et des carnets d’adresses en mode hors connexion, met à jour les informations de disponibilité pour les clients hérités et gère les autorisations et les appartenances aux groupes pour le serveur. S’il est désactivé, tout service en dépendance directe ne pourra pas démarrer. Ce service dépend des services RPC, Serveur, Journal des événements Windows et Station de travail.

Automatique

Boîte aux lettres

O

Limitation de bande passante Microsoft Exchange

MSExchangeThrottling

Service réseau

Limite la vitesse des opérations des utilisateurs. Ce service dépend du service de topologie Microsoft Exchange Active Directory.

Automatique

Boîte aux lettres

O

Transport Microsoft Exchange

MSExchangeTransport

Service réseau

Fournit le serveur SMTP et la pile de transport. Sur les serveurs de transport Hub, ce service dépend du service de topologie Microsoft Exchange Active Directory. Sur les serveurs de transport Edge, ce service dépend du service ADAM Microsoft Exchange.

Automatique

Transport Hub, transport Edge

O

Recherche de journal de transport Microsoft Exchange

MSExchangeTransportLogSearch

Système local

Offre des fonctionnalités de recherche à distance dans les fichiers journaux de transport Microsoft Exchange. Sur les serveurs de transport Hub, ce service dépend du service de topologie Microsoft Exchange Active Directory. Sur les serveurs de transport Edge, ce service dépend du service ADAM Microsoft Exchange.

Automatique

Transport Hub, boîte aux lettres, transport Edge

F

Messagerie unifiée Microsoft Exchange

MSExchangeUM

Système local

Active les fonctionnalités de messagerie unifiée d’Microsoft Exchange. Il permet le stockage des messages vocaux et de télécopie dans Exchange et donne la possibilité aux utilisateurs d’accéder par téléphone à la messagerie électronique, à la messagerie vocale, au calendrier, aux contacts ou à un standard automatique. Si ce service est arrêté, la messagerie unifiée n’est pas disponible. Ce service dépend du service de topologie Microsoft Exchange Active Directory et du service de moteur vocal Microsoft Exchange.

Automatique

Messagerie unifiée

O

Recherche Microsoft (Exchange Server)

msftesql-Exchange

Système local

Il s’agit d’une version personnalisée pour Microsoft Exchange d’Microsoft Search. Ce service dépend du service RPC.

Manuel

Transport Hub, boîte aux lettres

F

Le programme d’installation d’Exchange 2010 crée des certificats auto-signés pour sécuriser la communication sur différents protocoles, tels que HTTP, SMTP, POP3 et IMAP4. Les certificats auto-signés créés par le programme d’installation sont valides pendant cinq ans. Grâce à cette période de validité, les certificats auto-signés n’ont pas besoin d’être renouvelés pendant une partie importante du déploiement Exchange 2010 et les services de messagerie ne sont pas affectés par l’expiration de ces certificats.

Pour les mécanismes et protocoles d’accès au client externes, tels qu’Outlook Web App, POP3, IMAP4, Outlook Anywhere et le service de découverte automatique, tenez compte des recommandations suivantes :

  • Utilisez des certificats signés par une autorité de certification commerciale qui est approuvée par les clients accédant à ces services.

  • Utilisez l’Assistant Nouveau certificat Exchange ou la cmdlet New-ExchangeCertificate pour adresser aux autorités de certification commerciales des demandes de signature de certificats. Les demandes de certificats générées à l’aide de ces outils permettent de s’assurer que toutes les exigences en matière de certificats Exchange sont remplies.

  • Prenez en compte les exigences en matière de certificats pour chaque protocole ou service pour lequel vous souhaitez autoriser un accès au client externe.

    • Sur les serveurs d’accès au client, les certificats permettent de protéger le trafic HTTP (Outlook Anywhere, Outlook Web App, le service de découverte automatique, Exchange ActiveSync et les services Web Exchange) à l’aide du protocole SSL (Secure Sockets Layer) et le trafic POP3 et IMAP4 à l’aide du protocole SSL ou TLS (Transport Layer Security). Pour plus d’informations, voir Gestion du protocole SSL pour un serveur d’accès au client.

    • Sur les serveurs de transport, les certificats permettent de protéger le trafic SMTP à l’aide du protocole TLS. Pour plus d’informations, voir Présentation des certificats TLS.

    • Sur les serveurs de messagerie unifiée, les certificats permettent de protéger le trafic VoIP (Voice over Internet Protocol). Pour plus d’informations, voir Présentation de la sécurité VoIP de messagerie unifiée.

    • Pour la fédération, les certificats permettent de chiffrer les jetons SAML échangés avec Microsoft Federation Gateway (MFG) et les organisations des partenaires fédérés. Pour plus d’informations, voir Présentation de la fédération.

  • Surveillez les dates de validité des certificats et renouvelez-les à temps auprès des autorités de certification pour éviter toute interruption du service.

  • Lorsque vous stockez des certificats exportés avec la clé privée associée, protégez le fichier exporté à l’aide des contrôles d’accès appropriés sur le dossier/fichier où il réside. En fonction des exigences en matière de sécurité de votre organisation, vous pouvez activer l’audit d’accès au fichier pour les dossiers dans lesquels se trouvent les fichiers de certificats avec clés privées.

Le protocole NTLM est considérablement moins sécurisé que le protocole Kerberos. Dans Exchange 2010, les protocoles POP3 et IMAP4 ne prennent pas en charge l’authentification NTLM lorsque SecureLogin est défini sur LoginType. Pour plus d’informations, voir Configuration de l’authentification pour POP3 et IMAP4. Les services Exchange 2010 qui utilisent l’authentification intégrée de Windows peuvent utiliser les protocoles NTLM ou Kerberos. Kerberos est utilisé pour la communication du serveur d’accès au client vers un serveur de boîte aux lettres Exchange 2010 et entre les serveurs d’accès au client Outlook Web App, Exchange ActiveSync et les services Web Exchange. Pour plus d’informations sur les services qui utilisent NTLM pour l’authentification, voir Référence de port de réseau Exchange.

Les mécanismes d’authentification à deux facteurs utilisent un authentificateur supplémentaire en plus des informations d’identification de l’utilisateur (nom d’utilisateur et mot de passe). Il peut par exemple s’agir de jetons générés de façon aléatoire ou d’un certificat numérique sur une carte à puce avec un code confidentiel. De nombreuses organisations déploient l’authentification à deux facteurs pour sécuriser l’accès à leur réseau.

Exchange 2010 n’inclut pas la prise en charge native de l’authentification à deux facteurs. Exchange 2010 utilise le serveur IIS (Internet Information Server 7) pour l’accès au client via HTTP (découverte automatique, Outlook Web App, Outlook Anywhere, Exchange ActiveSync et services Web Exchange). De nombreux produits d’authentification à deux facteurs s’intégrant à IIS sont proposés par des partenaires et tiers. Ils fonctionnent avec les services d’accès au client Exchange, tels qu’Outlook Web App. Avant de déployer les produits d’authentification à deux facteurs pour les services Exchange, il est conseillé de les tester convenablement pour s’assurer qu’ils répondent aux exigences de sécurité de l’organisation et fournissent les fonctionnalités dont vous avez besoin.

Exchange 2010 introduit de nouvelles fonctionnalités de fédération pour sécuriser la collaboration entre les organisations Exchange fédérées. Les organisations Exchange 2010 peuvent créer une approbation de fédération avec Microsoft Federation Gateway (MFG), puis établir des relations avec d’autres organisations fédérées dans le but de partager des informations de disponibilité et des calendriers. Les organisations peuvent également autoriser les utilisateurs à partager leurs informations de disponibilité, calendrier et contacts avec des utilisateurs qui se trouvent dans des organisations fédérées, à l’aide des stratégies de partage. Pour plus d’informations sur les approbations de fédération et le partage fédéré, voir Présentation de la fédération et Présentation de la délégation fédérée.

Une fois que vous avez établi une approbation de fédération avec MFG, aucun partage ne s’effectue entre deux organisations fédérées, sauf si vous créez une relation organisationnelle. Toutefois, le partage entre vos utilisateurs et les utilisateurs situés dans des organisations fédérées externes est activé par défaut par le biais de la stratégie de partage par défaut qui est attribuée aux utilisateurs. La stratégie autorise uniquement le partage du calendrier avec les informations de disponibilité pour les utilisateurs appartenant à toutes les organisations fédérées externes. Si vous ne souhaitez pas autoriser les utilisateurs à partager leur calendrier et leurs informations de disponibilité avec les utilisateurs de tous les domaines fédérés externes, vous devez désactiver la stratégie de partage par défaut ou modifier le nom de domaine spécifié dans la stratégie afin de n’indiquer que les domaines avec lesquels vous souhaitez autoriser le partage. Vous devez effectuer cette modification avant de créer une approbation de fédération avec MFG. Pour plus d’informations, voir Désactiver une stratégie de partage et Configurer les propriétés des stratégies de partage.

Vous pouvez désactiver toutes les fonctionnalités de fédération d’une organisation, notamment la délégation fédérée, en supprimant l’approbation de fédération avec MFG de l’organisation. Pour plus d’informations, voir Supprimer une approbation de fédération.

S/MIME est une norme destinée au chiffrement à clé publique et à la signature de données MIME, qui assure l’authentification, l’intégrité des messages, la non-répudiation et la confidentialité des données de messagerie. Les utilisateurs peuvent signer ou chiffrer les messages, ou les deux, par l’intermédiaire des certificats S/MIME. Pour plus d’informations sur S/MIME, voir Understanding S/MIME (en anglais).

S/MIME est une technologie côté client qui n’impose aucune interopérabilité concernant les serveurs de messagerie. En ce qui concerne le transfert des messages, les messages signés et chiffrés par le protocole S/MIME sont transférés de la même manière que les messages en texte clair (non chiffrés). Le message s’affiche réellement après le contrôle du certificat et la validation du message. Pour Outlook Web App, le protocole S/MIME est pris en charge à l’aide d’un contrôle ActiveX. Bien qu’Outlook Web App prenne en charge la plupart des navigateurs connus, tels que Microsoft Internet Explorer, Mozilla FireFox et Safari, les contrôles ActiveX sont une fonctionnalité d’Internet Explorer. Les utilisateurs d’Outlook Web App qui utilisent d’autres navigateurs ne peuvent pas accéder aux fonctionnalités S/MIME et devront sans doute faire appel à un autre client de messagerie qui prend en charge le protocole S/MIME. Pour plus d’informations sur S/MIME dans Outlook Web App, voir Outlook Web App et S/MIME.

Pour plus de détails sur la prise en charge de S/MIME dansOutlook, voirVue d'ensemble des certificats et de la messagerie chiffrée dans Outlook (en anglais).

Même si le protocole S/MIME offre des avantages en termes de sécurité à une organisation, prenez en compte les points suivants au moment d’évaluer la technologie :

  • Les messages chiffrés par le protocole S/MIME sont opaques pour votre organisation. Les logiciels de sécurité de messagerie, tels que les antivirus et les programmes de blocage du courrier indésirable, ne peuvent pas inspecter le contenu des messages, notamment le corps des messages et les pièces jointes.

  • Comme le contenu des messages et les pièces jointes sont chiffrés, les stratégies de messagerie de votre organisation, y compris les règles de transport, ne peuvent pas s’appliquer aux messages chiffrés par le protocole S/MIME.

  • La modification des messages signés par le protocole S/MIME pour les rendre conformes aux stratégies de messagerie de votre organisation (par exemple pour appliquer une clause d’exclusion de responsabilité ou une signature personnalisée), a pour effet d’invalider le message.

  • Il n’est pas possible de rechercher des violations de contenu dans les messages chiffrés et votre organisation ne peut pas empêcher les informations confidentielles (notamment les informations d’identification personnelle) de quitter l’organisation.

  • Les messages chiffrés par le protocole S/MIME ne peuvent pas être indexés par le service de recherche Exchange et le service de découverte ne peut donc pas les parcourir.

  • Pour répondre aux réglementations locales ou aux exigences de découverte en cas de litige, votre organisation peut être amenée à produire des copies non chiffrées de tous les messages chiffrés.

Exchange 2010 propose des fonctionnalités de gestion des droits relatifs à l’information (IRM) qui permettent à votre organisation d’appliquer une protection permanente au contenu des messages confidentiels, afin que seuls les destinataires spécifiés soient en mesure d’accéder aux messages protégés par IRM. Votre organisation peut également contrôler la façon dont ce contenu est utilisé après sa remise aux destinataires. Par exemple, vous pouvez empêcher les utilisateurs d’imprimer les messages, d’y répondre ou de les transférer à l’intérieur ou à l’extérieur de l’organisation. De même, votre organisation a toujours la possibilité de déchiffrer le contenu protégé par IRM pour l’analyser avec un antivirus et un programme de blocage du courrier indésirable et d’autres agents de transport, et pour appliquer des stratégies de messagerie à l’aide de règles de transport. Elle peut également activer l’archivage et la découverte des messages protégés par IRM. Les fonctionnalités IRM sont également disponibles dans tous les navigateurs Web pris en charge par Outlook Web App et dans les appareils Windows Mobile. Pour plus d’informations sur IRM, voir Présentation de la gestion des droits relatifs à l'information.

Cette section répertorie les points de sécurité à prendre en compte pour le rôle serveur Exchange 2010.

Dans Exchange 2010, des changements d’architecture ont été apportés à la banque d’informations Exchange et à la connexion des clients MAPI, tels qu’Outlook. Les clients MAPI se connectent au serveur d’accès au client, isolant ainsi le serveur de boîte aux lettres du trafic client. Les serveurs de boîtes aux lettres communiquent uniquement avec les serveurs d’accès au client qui utilisent RPCSec, et avec les serveurs AD DS (Active Directory Domain Services) de votre organisation. Les serveurs d’accès au client ne requièrent pas de connexion Internet.

Le stockage est un composant essentiel des serveurs de boîtes aux lettres. Vous devez planifier le sous-système de stockage du serveur de boîte aux lettres afin de garantir des performances satisfaisantes et un espace de stockage approprié à votre déploiement. Pour plus d’informations sur la planification du stockage d’un serveur de boîte aux lettres, voir Conception du stockage de serveur de boîtes aux lettres.

Une fois le déploiement du serveur de boîte aux lettres effectué, vous devez surveiller les points suivants :

  • Disponibilité du sous-système de stockage.

  • Disponibilité d’un espace disque suffisant sur les volumes contenant la base de données de boîte aux lettres et les journaux de transaction. Une base de données de boîte aux lettres ou de dossier public est démontée lorsque l’espace disque disponible du volume sur lequel se trouvent la base de données ou les journaux de transaction correspondants devient insuffisant.

Vous pouvez utiliser Microsoft Federation Gateway Systems Center Operations Manager pour contrôler la disponibilité de l’espace de stockage et l’espace disque disponible. Pour plus de détails, voir Systems Center Operations Manager 2007.

Au moment de la planification et de la surveillance de l’espace de stockage, si vous prévoyez d’utiliser les fonctionnalités suivantes, vous devez prendre en compte les conditions de stockage ci-dessous :

  • Journalisation   Lorsque vous utilisez la journalisation pour archiver les messages à long terme, selon que vous utilisez la journalisation standard (base de données par boîte aux lettres) ou la journalisation étendue (règles de journal), les messages échangés par tous les destinataires d’une base de données de boîte aux lettres ou les destinataires désignés dans une règle de journal sont remis dans un état de journal à la boîte aux lettres de journalisation ou au destinataire spécifié. Il peut en résulter un nombre important d’états de journal remis à une boîte aux lettres de journalisation. Lorsque vous planifiez le stockage des serveurs de boîtes aux lettres, vous devez prendre en compte les tailles des boîtes aux lettres de journalisation. Vous pouvez contrôler les tailles des boîtes aux lettres de journalisation en allouant des quotas suffisants à une boîte aux lettres de journalisation. Pour plus d’informations sur la journalisation et les quotas des boîtes aux lettres, consultez les rubriques suivantes :

  • Blocage de litiges   Lorsque vous placez une boîte aux lettres en blocage de litiges, les éléments supprimés par l’utilisateur à l’aide de la fonctionnalité Récupérer les éléments supprimés d’Outlook et d’Outlook Web App et les messages supprimés par des processus automatiques, tels que la gestion des enregistrements de messagerie, sont conservés jusqu’à la suppression du blocage pour litiges. Dans Exchange 2010, le quota d’avertissement d’éléments récupérables et le quota d’éléments récupérables sont définies sur 20 Go et 30 Go. Pour plus d’informations, consultez les rubriques suivantes :

La disponibilité élevée des serveurs de boîtes aux lettres est essentielle pour garantir la disponibilité du service de messagerie. Exchange 2010 inclut les groupes de disponibilité de la base de données (DAG) pour maintenir une disponibilité élevée des serveurs de boîtes aux lettres. Les groupes de disponibilité de la base de données peuvent offrir une disponibilité lorsque votre déploiement Exchange connaît une défaillance du sous-système de stockage, du serveur, de la connexion réseau ou une panne de l’ensemble du centre de données. Pour plus d’informations sur la planification et la mise en œuvre d’un déploiement Exchange 2010 à disponibilité élevée, voir Haute disponibilité et résilience de site.

Par défaut, dans Exchange 2010, le trafic de réplication (envoi de journaux) entre les membres DAG situés sur différents sites Active Directory est chiffré. Vous pouvez chiffrer le trafic de réplication entre les serveurs du même site Active Directory en activant la propriété NetworkEncryption du DAG (définissez la propriété sur Enabled). Utilisez la cmdlet Set-DatabaseAvailabilityGroup pour modifier cette propriété pour un DAG.

La réplication se produit sur un seul port TCP, par défaut le port TCP 64327. Vous pouvez modifier le port utilisé pour la réplication. Pour plus d’informations, voir Configurer les propriétés du groupe de disponibilité de la base de données.

Paramètres de disponibilité élevée

Paramètre Description

NetworkEncryption

Le paramètre NetworkEncryption spécifie si le chiffrement réseau est activé. Les valeurs valides sont les suivantes :

  • Disabled   désactivé sur tous les réseaux

  • Enabled   activé sur tous les réseaux

  • InterSubnetOnly   activé pour la communication inter-sous-réseau uniquement

  • SeedOnly   activé uniquement pour l’amorçage

Valeur par défaut   InterSubnetOnly

ReplicationPort

Le paramètre ReplicationPort spécifie un port TCP (Transmission Control Protocol) pour l’activité de réplication (envoi de journaux et amorçage).

Valeur par défaut   Si ce paramètre n’est pas spécifié, le port par défaut pour la réplication sera le port TCP 64327.

Par défaut, Exchange 2010 n’autorise pas les administrateurs à accéder aux boîtes aux lettres. Si votre organisation utilise des applications ou des services qui doivent accéder à une boîte aux lettres, vous devez attribuer les autorisations appropriées aux comptes utilisés par ces applications ou services. Il est recommandé de ne pas configurer ces applications ou services pour utiliser des informations d’identification de l’administrateur.

Bien que toutes les boîtes aux lettres soient susceptibles de contenir des informations confidentielles cruciales aux yeux d’une organisation, les boîtes aux lettres suivantes méritent une attention toute particulière du point de vue de la sécurité, et les autorisations d’accès à ces boîtes aux lettres doivent être contrôlées et surveillées pour répondre aux exigences en matière de sécurité de votre organisation.

  • Boîtes aux lettres de découverte   Les boîtes aux lettres de découverte sont utilisées par la fonctionnalité de recherche dans plusieurs boîtes aux lettres d’Exchange 2010. Cela permet aux gestionnaires de découverte qui font partie du groupe de rôles Gestion de la découverte de rechercher des messages dans toutes les boîtes aux lettres d’une organisation Exchange 2010. Les messages renvoyés par une détection sont copiés dans la boîte aux lettres de découverte spécifiée. Le programme d’installation d’Exchange 2010 crée une boîte aux lettres de détection par défaut. Pour plus d’informations, voir Présentation de la recherche dans plusieurs boîtes aux lettres.

  • Boîtes aux lettres de journalisation   Lorsque vous configurez la journalisation d’une base de données de boîte aux lettres ou créez des règles de journal pour journaliser les messages en provenance et à destination de destinataires désignés, les états de journal sont remis à la boîte aux lettres de journalisation spécifiée. Pour plus d’informations, consultez les rubriques suivantes :

Outre la protection de ces boîtes aux lettres, notez qu’un administrateur peut utiliser les règles de transport pour inspecter le contenu d’un message et en remettre une copie à un autre destinataire, même en tant que destinataire Cci. Les autorisations requises pour gérer les règles de transport sont répertoriées dans l’entrée Règles de transport de la rubrique Stratégie de messagerie et autorisations de conformité. Nous vous conseillons d’utiliser des contrôles appropriés pour contrôler et surveiller la création et la modification des règles de transport, et de procéder à des audits réguliers sur les actions de règle de transport pour toutes les règles.

Dans Exchange 2010, les clients suivants se connectent aux serveurs d’accès au client pour accéder aux boîtes aux lettres :

  • Clients Outlook utilisant MAPI

  • Clients Outlook utilisant Outlook Anywhere

  • Navigateurs Web utilisant Outlook Web App

  • Appareils mobiles utilisant Exchange ActiveSync

  • Clients POP3 et IMAP4

  • Applications utilisant les services Web Exchange (EWS)

Par défaut, ces méthodes d’accès au client sont sécurisées à l’aide de chemins de données chiffrés. De même, par défaut, les clients Outlook qui se connectent à un serveur d’accès au client avec MAPI utilisent le chiffrement RPC. L’accès Outlook Web App, Outlook Anywhere et Exchange ActiveSync est sécurisé à l’aide du protocole SSL (Secure Sockets Layer).

Pour l’accès au client externe, vous devez obtenir et installer des certificats signés par une autorité de certification approuvée par le client. Pour plus d’informations, voir Gestion du protocole SSL pour un serveur d’accès au client.

Par défaut, les services POP3 et IMAP4 sont désactivés sur les serveurs d’accès au client Exchange 2010. Si vous les activez, nous recommandons d’utiliser les protocoles TLS (Transport Layer Security) ou SSL (Secure Sockets Layer) pour sécuriser la communication. Pour plus d’informations, consultez les rubriques suivantes :

Nous vous conseillons d’utiliser les pare-feu et méthodes d’accès appropriés lorsque vous publiez les serveurs d’accès au client pour un accès externe. Microsoft Forefront Threat Management Gateway (TMG) 2010 inclut des assistants de publication qui facilitent et sécurisent la publication des serveurs d’accès au client Exchange 2010 pour un accès externe. Pour plus d’informations, voir Forefront Threat Management Gateway (TMG) 2010.

ImportantImportant :
La recherche des serveurs d’accès au client sur les réseaux de périmètre n’est pas prise en charge.

Sur les serveurs d’accès au client, IIS est utilisé pour fournir un accès par protocole HTTP aux services, tels qu’Outlook Web App, Exchange ActiveSync, Outlook Anywhere, la découverte automatique, le Panneau de contrôle Exchange (ECP), les services Web Exchange et le carnet d’adresses en mode hors connexion. Remote PowerShell utilise également IIS, et toutes les demandes RPS, y compris les demandes émises par la console de gestion Exchange (EMC), sont enregistrées dans des journaux IIS. Les journaux IIS peuvent croître et utiliser une quantité importante de l’espace disque. IIS, composant Windows Server, ne comprend aucun système de suppression des journaux anciens en fonction de la taille du répertoire dans lequel les fichiers journaux se trouvent. Il est recommandé de transférer les journaux IIS sur un volume non-système, afin que l’augmentation des fichiers journaux ne provoque pas l’insuffisance de l’espace disque du volume système, ce qui pourrait entraîner une interruption du service. Vous devez contrôler la croissance des fichiers journaux et mettre en place un mécanisme manuel d’archivage ou de suppression des journaux, en fonction des besoins. Pour plus de détails, voir Configuring Logging in IIS 7 (en anglais).

Exchange 2010 présente deux rôles serveur de transport conçus pour différents objectifs.

  • Transport Edge   Le rôle serveur de transport Edge est un serveur de transport qui n’appartient pas à un domaine, généralement situé dans des réseaux de périmètre, et qui transfère les messages entre votre organisation Exchange et des hôtes SMTP externes. Bien que conçu pour les réseaux de périmètre, vous pouvez également placer les serveurs de transport Edge sur le réseau interne et associer le serveur à un domaine Active Directory en tant que serveur membre.

  • Transport Hub   Le rôle serveur de transport Hub transfère les messages au sein de l’organisation, y compris les messages entre les serveurs Exchange, les messages issus de clients SMTP tels que les utilisateurs faisant appel à POP3 et IMAP4, ainsi que les serveurs d’application et les appareils.

Par défaut, dans Exchange 2010, la communication SMTP est sécurisée avec TLS.

Communication SMTP entre les serveurs de transport Hub   Les serveurs de transport Hub dans une organisation Exchange utilisent TLS pour renforcer la sécurité de la communication SMTP au sein de l’organisation. Il est conseillé de laisser TLS activé sur les serveurs de transport Hub. Dans Exchange 2010, les organisations qui utilisent des appareils ou des systèmes non-Exchange pour réaliser le chiffrement TLS peuvent décharger TLS des serveurs de transport Hub sur ces appareils. Pour plus d’informations, voir Désactivation du protocole TLS entre des sites Active Directory pour la prise en charge de l'optimisation de réseau étendu.

Communication SMTP entre les serveurs de transport Hub et Edge   L’ensemble du trafic entre les serveurs de transport Hub et Edge est authentifié et chiffré. Le mécanisme sous-jacent pour l’authentification et le chiffrement est Mutual TLS. Au lieu d’utiliser la validation X.509 pour valider les certificats, Exchange 2010 utilise la confiance directe pour authentifier les certificats. La confiance directe signifie que la présence du certificat dans Active Directory ou AD LDS (Active Directory Lightweight Directory Services) valide le certificat. Active Directory est considéré comme un mécanisme de stockage approuvé. Lorsque la confiance directe est utilisée, il importe peu que le certificat soit auto-signé ou signé par une autorité de certification. Lorsque vous abonnez un serveur de transport Edge à un site Active Directory, l’abonnement Edge publie le certificat du serveur de transport Edge dans Active Directory. Les serveurs de transport Hub traitent le certificat publié comme étant valide. Le service Microsoft EdgeSync met à jour AD LDS sur les serveurs de transport Edge dotés de certificats de serveur de transport Hub, qui sont considérés comme valides par le serveur de transport Edge.

Communication SMTP entre les serveurs de transport Edge et les hôtes externes   Dans Exchange 2010, la communication SMTP entre les serveurs de transport Edge et les hôtes externes anonymes est sécurisée par défaut à l’aide du protocole TLS opportuniste. Vous n’avez pas besoin d’un certificat émis par une autorité de certification approuvée et aucune procédure de configuration n’est nécessaire. Les connecteurs de réception proposent une négociation TLS pour les connexions SMTP entrantes. Les connecteurs d’envoi tentent également une négociation TLS pour toutes les connexions SMTP sortantes. Le protocole TLS opportuniste n’effectue pas de validation des certificats, ce qui permet d’utiliser des certificats auto-signés. Pour plus d’informations, voir Fonction TLS et terminologie associée dans Exchange 2010.

RemarqueRemarque :
Par défaut, les serveurs de transport Hub ne peuvent pas communiquer avec les hôtes SMTP externes, car aucun connecteur de réception n’est présent sur les serveurs de transport Hub pour autoriser les hôtes anonymes à communiquer. Il est possible de configurer les serveurs de transport Hub pour qu’ils communiquent avec des hôtes anonymes. Pour plus d’informations, voir Configurer le flux de messagerie sur Internet directement à l’aide d’un serveur de transport Hub. Nous ne recommandons pas cette topologie car elle augmente les risques liés à la sécurité en exposant à Internet le serveur Exchange 2010 et tous les rôles installés sur ce serveur. Il est recommandé d’implémenter une passerelle SMTP basée sur un réseau de périmètre, comme le serveur de transport Edge.

Communication SMTP entre les serveurs de transport Hub ou Edge et les hôtes actifs   Dans Exchange 2010, vous pouvez configurer un connecteur d’envoi pour qu’il route le courrier des domaines distants, y compris le courrier Internet, vers une passerelle SMTP qui se trouve en général sur le réseau de périmètre. Bien qu’il soit possible de créer un connecteur d’envoi pour router le courrier électronique vers un hôte actif sans utiliser d’authentification, il est conseillé d’utiliser une authentification appropriée pour ces connecteurs. Si vous utilisez l’authentification de base, nous recommandons l’utilisation de l’authentification de base sur TLS. Si vous choisissez l’option Sécurisé de l’extérieur, on suppose que l’authentification s’effectue avec un mécanisme autre qu’Exchange, tel qu’IPsec. Lorsque vous configurez le connecteur avec l’adresse d’un hôte actif, vous pouvez utiliser soit l’adresse IP de l’hôte actif, soit son nom de domaine complet. Nous recommandons d’utiliser l’adresse IP de l’hôte actif, car elle protège des incohérences DNS, même si utiliser le nom de domaine complet est plus simple.

Utilisation de la sécurité du domaine pour la communication SMTP avec les partenaires    Dans Exchange 2010, vous pouvez utiliser la sécurité du domaine pour sécuriser les chemins de communication des messages avec les domaines des partenaires. La sécurité du domaine utilise le protocole Mutual TLS pour fournir un chiffrement et une authentification basés sur la session. Pour l’authentification Mutual TLS, les hôtes source et de destination vérifient la connexion en effectuant la validation du certificat X.509. Les serveurs de transport qui communiquent avec les domaines des partenaires configurés pour la sécurité du domaine requièrent un certificat signé par un tiers approuvé ou une autorité de certification interne. Si vous utilisez une autorité de certification interne, la liste de révocation de certificats doit être publiée et accessible à l’hôte partenaire. Pour plus de détails, consultez les rubriques suivantes :

Exchange 2010 utilise le port SMTP par défaut (Port TCP 25) pour la communication SMTP. Le programme d’installation d’Exchange crée les règles requises dans le pare-feu Windows avec fonctions avancées pour autoriser la communication sur les ports par défaut. Si vous attribuez un port différent à un connecteur, Exchange ne modifie pas les règles de pare-feu ou crée automatiquement une nouvelle règle pour autoriser la communication sur ce port. Vous devez modifier manuellement la configuration du pare-feu pour autoriser la communication sur les ports autres que ceux par défaut. Lorsque vous configurez un connecteur de réception pour un port autre que celui par défaut, les clients SMTP qui envoient des messages au connecteur doivent également être configurés pour utiliser ce port.

Dans Exchange 2010, vous pouvez placer le rôle serveur de transport Hub sur un serveur de boîte aux lettres Exchange 2010. Cela inclut un serveur de boîte aux lettres membre d’un groupe de disponibilité de la base de données. Il est recommandé de ne pas placer le rôle serveur de transport Hub sur un serveur de boîte aux lettres, en particulier dans les topologies sur lesquelles aucun serveur de transport Edge n’est déployé, afin d’isoler les serveurs de boîtes aux lettres d’Internet. Vous pouvez localiser un rôle serveur de transport Hub sur les serveurs d’accès au client. Vous devez suivre les instructions de dimensionnement de chaque rôle serveur lorsque vous placez plusieurs rôles serveur sur le même serveur.

Lorsque vous désignez un hôte actif pour un connecteur d’envoi sur un serveur de transport Hub ou Edge, il est recommandé d’utiliser les adresses IP au lieu du nom de domaine complet d’un hôte actif, dans le but de prévenir les incohérences DNS et l’usurpation d’adresse. Cela réduit également l’impact des défaillances DNS sur l’infrastructure de transport. Les serveurs DNS utilisés dans les réseaux de périmètre doivent uniquement être utilisés pour la résolution sortante. Les serveurs DNS de périmètre peuvent contenir des enregistrements pour les serveurs de transport Hub. Vous pouvez également utiliser des fichiers d’hôte sur les serveurs de transport Edge pour éviter de créer des enregistrements pour les serveurs de transport Hub sur les serveurs DNS situés dans des réseaux de périmètre.

Outre les étapes abordées dans cette section, il est conseillé d’utiliser des limites de taille des messages suffisantes sur les connecteurs et des paramètres de limitation des messages sur les serveurs de transport. Pour plus d’informations, consultez les rubriques suivantes :

Lorsque vous prévoyez de déployer un rôle serveur de messagerie unifiée, vous devez prendre en compte les différents canaux de communication utilisés par la messagerie unifiée pour communiquer avec les passerelles IP ou PBX IP.

Par défaut, lorsque vous créez un plan de numérotation de messagerie unifiée, il communique en mode Non sécurisé. De même, les serveurs de messagerie unifiée associés au plan de numérotation de messagerie unifiée envoient et reçoivent des données des passerelles IP, des PBX IP et d’autres ordinateurs Exchange 2010 sans utiliser de chiffrement. En mode non sécurisé, le canal de support RTP (Real-Time Transport Protocol) et les informations de signalisation SIP ne sont pas chiffrés.

Vous pouvez configurer un serveur de messagerie unifiée afin qu’il utilise Mutual TLS pour chiffrer le trafic SIP et RTP vers et provenant d’autres appareils et serveurs. Lorsque vous ajoutez un serveur de messagerie unifiée à un plan de numérotation de messagerie unifiée et que vous configurez le plan de numérotation afin qu’il utilise le mode SIP sécurisé, seul le trafic de signalisation SIP sera chiffré et les canaux de support RTP continueront à utiliser le protocole TCP. Le protocole TCP n’est pas chiffré. Toutefois, si vous ajoutez un serveur de messagerie unifiée à un plan de numérotation de messagerie unifiée et si vous configurez le plan de numérotation afin qu’il utilise le mode sécurisé, le trafic de signalisation SIP et les canaux de support RTP sont chiffrés. Un canal de signalisation sécurisé utilisant SRTP (Secure Real-Time Transport Protocol) utilise également Mutual TLS pour chiffrer les données VoIP.

Si la passerelle IP ou PBX IP que vous utilisez prend en charge le protocole IPsec, vous pouvez également utiliser IPsec pour sécuriser la communication entre un serveur de messagerie unifiée et la passerelle IP ou PBX IP.

Pour plus d’informations, voir Présentation de la sécurité VoIP de messagerie unifiée.

La messagerie unifiée envoie également des messages, tels que les notifications d’appels manqués et les messages vocaux, aux serveurs de transport Hub. Par défaut, cette communication a lieu sur SMTP avec le chiffrement TLS.

Vous pouvez configurer une stratégie de boîte aux lettres de messagerie unifiée pour un accès sans code confidentiel. Ceci permet à un appelant d’accéder à la messagerie vocale sans entrer de code confidentiel, en fonction de son code d’appelant. L’usurpation du code de l’appelant a peu d’importance. Il est recommandé de ne pas activer l’accès sans code confidentiel à la messagerie vocale. En outre, il est conseillé de passer en revue les paramètres par défaut des codes confidentiels, et de les configurer pour qu’ils répondent aux exigences en matière de sécurité de votre organisation. Les paramètres suivants peuvent être configurés pour une stratégie de boîte aux lettres de messagerie unifiée avec la cmdlet Set-UMMailboxPolicy.

Paramètres permettant de contrôler le code confidentiel de l’utilisateur pour accéder à la messagerie vocale

Paramètre Description

AllowCommonPatterns

Le paramètre AllowCommonPatterns spécifie l’autorisation des codes confidentiels faciles à deviner. Les exemples de code confidentiel incluent des sous-ensembles du numéro de téléphone, des chiffres séquentiels ou des chiffres répétés. Si cette option est définie sur $false, les chiffres séquentiels et répétés et le suffixe de l’extension de boîte aux lettres sont rejetés. Si cette option est définie sur $true, seul le suffixe de l’extension de boîte aux lettres est rejeté.

AllowPinlessVoiceMailAccess

Le paramètre AllowPinlessVoiceMailAccess spécifie si les utilisateurs associés à la stratégie de boîte aux lettres de messagerie unifiée doivent utiliser un code confidentiel, afin d’accéder à leur messagerie vocale. Un code confidentiel est toujours obligatoire pour accéder à leur messagerie électronique et à leur calendrier.

Valeur par défaut   désactivé ($false).

LogonFailusresBeforePINReset

Le paramètre LogonFailuresBeforePINReset spécifie le nombre de tentatives d’ouverture de session infructueuses successives avant la réinitialisation automatique du code confidentiel de la boîte aux lettres. Pour désactiver cette fonctionnalité, définissez ce paramètre sur Illimité. Si ce paramètre n’est pas défini sur Illimité, il doit être défini avec une valeur inférieure à celle du paramètre MaxLogonAttempts. Les valeurs sont comprises entre 0 et 999.

Valeur par défaut   5 échecs

MaxLogonAttempts

Le paramètre MaxLogonAttempts spécifie le nombre de tentatives successives d’ouverture de session dont bénéficient les utilisateurs, avant le verrouillage des boîtes aux lettres à messagerie unifiée. Les valeurs sont comprises entre 1 et 999.

Valeur par défaut   15 tentatives.

MinPINLength

Le paramètre MinPINLength spécifie le nombre minimal de chiffres requis dans un code confidentiel pour des utilisateurs à messagerie unifiée. Les valeurs sont comprises entre 4 et 24.

Valeur par défaut   6 chiffres

PINHistoryCount

Le paramètre PINHistoryCount spécifie le nombre de codes confidentiels précédents qui sont mémorisés et ne sont pas autorisés durant une réinitialisation de code confidentiel. Ce nombre inclut la première définition du code confidentiel. Les valeurs sont comprises entre 1 et 20.

Valeur par défaut   5 codes confidentiels

PINLifetime

Le paramètre PINLifetime spécifie le nombre de jours qui s’écoulent avant qu’un nouveau mot de passe ne soit requis. Les valeurs sont comprises entre 1 et 999. Si vous spécifiez Illimité, le code confidentiel de l’utilisateur n’expirera pas.

Valeur par défaut   60 jours

Dans Exchange 2010, les messages vocaux peuvent être marqués comme protégés. Ils sont protégés à l’aide de la gestion des droits relatifs à l’information (IRM). Vous pouvez configurer les paramètres de protection des messages vocaux en configurant les paramètres suivants dans une stratégie de boîte aux lettres de messagerie unifiée. Pour plus d’informations, consultez les rubriques suivantes :

Paramètres de protection des messages vocaux

Paramètre Description

ProtectAuthenticatedVoicemail

Le paramètre ProtectAuthenticatedVoiceMail indique si les serveurs de messagerie unifiée qui répondent aux appels Outlook Voice Access pour les utilisateurs à messagerie unifiée associés à la stratégie de boîte aux lettres de messagerie unifiée créent des messages vocaux protégés. Si la valeur est définie sur Privé, seuls les messages marqués comme privés seront protégés. Si la valeur est définie sur Tous, chaque message vocal est protégé.

Valeur par défaut   Aucun (Aucune protection n’est appliquée aux messages vocaux)

ProtectUnauthenticatedVoiceMail

Le paramètre ProtectUnauthenticatedVoiceMail spécifie si les serveurs de messagerie unifiée qui répondent aux appels pour utilisateurs à messagerie unifiée associés à la stratégie de boîte aux lettres de messagerie unifiée créent des messages vocaux protégés. Cela s’applique également lorsqu’un message est envoyé à partir d’un standard automatique de messagerie unifiée à un utilisateur à messagerie unifiée, via la stratégie de boîte aux lettres de messagerie unifiée. Si la valeur est définie sur Privé, seuls les messages marqués comme privés seront protégés. Si la valeur est définie sur Tous, chaque message vocal est protégé.

Valeur par défaut   Aucun (Aucune protection n’est appliquée aux messages vocaus)

RequireProtectedPlayOnPhone

Le paramètre RequireProtectedPlayOnPhone spécifie si des utilisateurs associés à la stratégie de boîte aux lettres de messagerie unifiée peuvent utiliser Émettre au téléphone pour des messages vocaux protégés, ou si des utilisateurs peuvent utiliser un logiciel multimédia pour lire le message protégé.

Valeur par défaut   $false Les utilisateurs peuvent utiliser les deux méthodes pour écouter les messages vocaux protégés.

ImportantImportant :
Pour que les serveurs de messagerie unifiée puissent continuer à répondre aux appels, il est primordial qu’ils aient accès à Active Directory. Il est conseillé de surveiller la disponibilité d’Active Directory.

Cette section contient des liens vers de la documentation Exchange supplémentaire concernant la sécurité.

 © 2010 Microsoft Corporation. Tous droits réservés.
Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Afficher:
© 2014 Microsoft