Sécurisation de votre serveur d'applications

Sur cette page

Dans ce module
Objectifs
S'applique à
Présentation
Menaces et contre-mesures
Méthodologie
Problèmes liés aux canaux de communication
Pare-feu
Problèmes de sécurité de .NET Remoting
Problèmes de sécurité liés aux services d'entreprise (COM+)
Résumé
Informations complémentaires

Dans ce module

Les serveurs d'application de niveau intermédiaire servent généralement à héberger la logique métier et les services d'accès aux données. Cette fonctionnalité est d'ordinaire intégrée aux applications de services d'entreprise, ou exposée aux serveurs Web frontaux à l'aide des services Web de niveau intermédiaire ou de la technologique Microsoft® .NET Framework Remoting.

Ce module traite séparément chaque technologie et vous montre comment sécuriser votre serveur d'application dans chaque cas. Il met l'accent sur les canaux de communication associés qui connectent le serveur Web au serveur d'application et ceux qui relient ce dernier au serveur de base de données.

Avant d'examiner en détail la configuration propre à une technologie, le module identifie les principaux dangers qui menacent un serveur d'application. Ces dangers sont légèrement différents de ceux qui concernent les serveurs Web directement confrontés à Internet, du fait que les serveurs d'application du niveau intermédiaire sont (ou doivent être) isolés de tout accès direct à Internet.

Haut de page

Objectifs

Ce module vous permettra :

• de sécuriser les canaux de communication vers votre serveur d'application ;

• de sécuriser votre service Web, vos services d'entreprise et vos solutions d'applications à distance sur les serveurs d'application du niveau intermédiaire ;

• de configurer un pare-feu interne qui sépare votre serveur Web de votre serveur d'application ;

• de gérer l'allocation dynamique de ports RPC ;

• d'utiliser .Net Remoting en toute sécurité ;

• de verrouiller une application de services d'entreprise ;

• de connaître les contre-mesures à appliquer pour faire face aux menaces auxquelles sont couramment confrontés les serveurs d'application, et notamment les écoutes clandestines, les accès non autorisés, les virus, les chevaux de Troie et les vers.

Haut de page

S'applique à

Ce module s'applique aux produits et technologies suivants :

• Microsoft Windows Server 2000 et 2003

• Microsoft .NET Framework 1.1 et ASP.NET 1.1

• Microsoft SQL Server

Haut de page

Présentation

Pour sécuriser le serveur d'application, vous devez appliquer une configuration de sécurité incrémentale après le verrouillage du système d'exploitation sous-jacent et du serveur Web IIS (Internet Information Services), s'il est installé.

La figure 17.1 montre l'axe de ce module, qui comprend la configuration des pare-feu internes qui font partie de nombreux modèles de déploiement multiniveaux.

Figure 17.1
Modèle de déploiement avec serveur d'application distant

Haut de page

Menaces et contre-mesures

Du fait que les serveurs d'application sont censés être isolés de tout accès via Internet, nombre des dangers qui les menacent proviennent de l'intérieur de l'entreprise. Les principales menaces pour le serveur d'application sont les suivantes :

• Écoute clandestine du réseau

• Accès non autorisé

• Virus, chevaux de Troie et vers

La figure 17.2 illustre les principaux dangers pour un serveur d'application.

Figure 17.2
Principales menaces et vulnérabilités d'un serveur d'application.

Écoute clandestine du réseau

Les pirates équipés de logiciels de surveillance du réseau peuvent intercepter les données circulant entre le serveur Web et le serveur d'applications, ainsi que celles qui transitent entre le serveur d'application et les systèmes en aval ou les serveurs de base de données. Le pirate peut visualiser ces données et être en mesure de les modifier.

Vulnérabilités

Les faiblesses suivantes peuvent rendre votre serveur d'application vulnérable aux écoutes clandestines du réseau :

• Données sensibles transmises sous forme de texte clair par l'application

• Utilisation de l'authentification Microsoft SQL Server pour l'accès à la base de données, entraînant la transmission d'informations d'authentification en texte clair

• Absence de cryptage sur la couche transport ou application

• Interfaces d'administration du matériel réseau non sécurisées

• Utilisation du canal TCP .NET Remoting pour l'accès aux composants distants

Attaques

Le pirate place des outils d'interception de paquets sur le réseau afin de capturer le trafic.

Contre-mesures

Les contre-mesures visant à empêcher l'interception des paquets sont les suivantes :

• Utiliser une authentification sécurisée, comme par exemple l'authentification Windows, qui n'envoie pas de mots de passe sur le réseau.

• Crypter les informations d'authentification de SQL Server. Si vous utilisez l'authentification SQL Server, vous pouvez crypter automatiquement les informations d'authentification en installant un certificat de serveur sur le serveur de base de données.

• Sécuriser les canaux de communication. Vous pouvez notamment opter pour l'utilisation de SSL (Secure Sockets Layer) ou d'IPSec (Internet Protocol Security).

• Utiliser le cryptage RPC (Remote Procedure Call) avec les applications de services d'entreprises.

• Utiliser un réseau segmenté, qui permet d'isoler les segments susceptibles de subir des écoutes.

• Utiliser HttpChannel et SSL avec .NET Remoting.

Accès non autorisé

Si vous ne parvenez pas à bloquer les ports utilisés par les applications qui s'exécutent sur le serveur d'application au niveau du pare-feu du périmètre, un pirate externe peut communiquer directement avec le serveur d'application. Si vous autorisez des ordinateurs autres que les serveurs Web frontaux à se connecter au serveur d'application, le profil d'attaque du serveur d'application augmente.

Vulnérabilités

Les vulnérabilités pouvant entraîner un accès non autorisé sont notamment :

• Faiblesses dans la configuration du réseau de périmètre et du pare-feu

• Port superflus ouverts sur le pare-feu interne

• Absence de stratégies IPSec pour limiter la connectivité aux hôtes

• Services actifs inutiles

• Protocoles inutiles

• Faiblesse des stratégies de comptes et de mots de passe.

Attaques

Les attaques courantes visant à obtenir un accès non autorisé sont les suivantes :

• L'analyse de ports pour détecter les services à l'écoute

• L'accrochage de bannière, qui diffuse les services disponibles et éventuellement les versions de logiciel

• L'introduction d'applications malveillantes

• Les attaques par mot de passe contre les comptes par défaut dotés de mots de passe trop simples

Contre-mesures

Pour éviter les accès non autorisés, vous pouvez mettre en œuvre les contre-mesures suivantes :

• Application sur les pare-feu de stratégies visant à bloquer tout le trafic, sauf sur les ports de communication attendus

• Stratégies de filtrage TCP/IP ou IPSec pour empêcher les hôtes non autorisés d'établir des connexions

• Désactivation des services inutilisés

• Mappage de points finaux statiques DCOM permettant exclusivement d'accéder aux hôtes autorisés

Virus, vers et chevaux de Troie

Ces attaques ne sont généralement remarquées que lorsqu'elles commencent à consommer les ressources système, ce qui ralentit ou arrête l'exécution d'autres applications. Les serveurs d'application qui hébergent IIS sont susceptibles de subir des attaques IIS.

Vulnérabilités

• Serveurs sans correctifs

• Exécutant des services inutiles

• Filtres et extensions ISAPI inutiles

Contre-mesures

Les contre-mesures suivantes permettent de limiter les risques liés aux virus, aux chevaux de Troie et aux vers :

• Application rapide des derniers correctifs logiciels

• Désactivation des fonctionnalités inutilisées, telles que les filtres et extensions ISAPI inemployés

• Exécution des processus avec des comptes moins privilégiés pour limiter l'ampleur des dommages si le système est compromis

Haut de page

Méthodologie

Si vous sécurisez les canaux de communication avec le serveur d'application et empêchez tout hôte, à l'exception des serveurs Web autorisés, d'accéder au serveur d'application, vous ne laissez aux pirates que la possibilité de lancer des attaques sur la couche application, exploitant les faiblesses de conception et de développement des applications Web.

Pour limiter ce risque, les développeurs doivent appliquer les règles de conception et de développement sécurisé décrites dans les parties II et III de ce guide.

Les solutions de configuration de ce module sont propres au serveur d'application et ne doivent pas être appliquées indépendamment les unes des autres. Appliquez-les parallèlement aux solutions présentées dans le Module 15, « Sécurisation de votre réseau », le Module 16, « Sécurisation de votre serveur Web » et le Module 18, « Sécurisation de votre serveur de base de données ».

Haut de page

Problèmes liés aux canaux de communication

Les données d'application sensibles et les informations d'authentification transmises au serveur d'application et reçues de lui doivent être cryptées afin d'assurer leur confidentialité et leur intégrité. Cela permet de limiter les risques liés à l'écoute clandestine et à la fraude.

Le cryptage du trafic réseau résout la question de l'écoute clandestine et de la falsification des données. Si vous considérez cette menace comme négligeable dans votre environnement, par exemple parce que votre application est située dans un réseau fermé et sécurisé physiquement, vous n'avez pas besoin de crypter le trafic. Si les risques d'écoute clandestine du réseau posent problème, vous pouvez faire appel à SSL, qui fournit un canal de communication sécurisé au niveau de la couche application, ou IPSec, qui fournit une solution au niveau de la couche transport. IPSec crypte tout le trafic IP qui circule entre deux serveurs, tandis que SSL permet à chaque application de choisir de fournir ou non un canal de communication crypté.

Services d'entreprise

Les applications de services d'entreprises (ou COM+) communiquent sur le réseau à l'aide de DCOM sur RPC. RPC utilise le port 135, qui fournit des services de mappage de point final pour permettre aux clients de négocier les paramètres, y compris le port de communication, qui est affecté dynamiquement par défaut.

Le canal des services d'entreprise peut être sécurisé de deux façons :

• Chiffrement RPC
  Vous pouvez configurer une application de services d'entreprise pour l'authentification RPC Packet Privacy. Outre l'authentification, elle permet le cryptage de tout paquet de données envoyé ou reçu par l'application de services d'entreprises.

• IPSec
  Vous pouvez mettre en œuvre une stratégie IPSec entre le serveur Web et le serveur d'application pour crypter le canal de communication.

.NET Remoting

Il existe deux modèles d'implémentation possibles pour les applications qui utilisent .NET Remoting :

• Canal http sur le port 80
  Ce modèle utilise ASP.NET comme service d'hébergement.

• Canal TCP sur un port quelconque
  Dans ce modèle, l'application est hébergée dans un exécutable personnalisé, qui est généralement un service Windows.

Selon les impératifs de l'application en termes de performances et de sécurité, vous pouvez employer l'une des deux méthodes suivantes pour sécuriser le canal de Remoting.

• Utiliser SSL avec HTTPChannel
  Si l'application est hébergée dans ASP.NET, vous pouvez tirer profit de la fonctionnalité HTTPS intégrée de Microsoft IIS. HTTPS assure l'authentification et la transmission sécurisée de données.

• Utiliser IPSec avec le canal TCPChannel.
  Avec le canal TCP, vous pouvez utiliser une stratégie IPSec pour fournir un chiffrement de toutes les données IP au niveau de la couche transport. Notez que si vous utilisez le canal TCP, vous devez fournir votre propre mécanisme d'authentification. Pour plus d'informations, consultez le module 13, « Création de composants distants sécurisés ».

Services Web

Les services Web sont hébergés par ASP.NET et IIS ; ils utilisent le protocole HTTP pour communiquer sur le réseau.

SSL ou IPSec peut servir à sécuriser le canal de communication. Ou alors, le cryptage peut être géré au niveau de la couche application ; il s'agit alors de crypter la charge utile du message ou les parties sensibles de cette charge utile. Pour effectuer cette opération en respectant les standards ouverts, téléchargez le produit WSE (Web Services Enhancements), disponible pour les services Web. Pour plus d'informations, reportez-vous au module 12 , Création de services Web sécurisés.

SQL Server

Le serveur d'application communique avec SQL Server en utilisant le port TCP 1433 par défaut. Sauf si une autre configuration a été définie, le port UDP 1434 est également utilisé pour la négociation.

Pour sécuriser le canal entre le serveur d'application et SQL Server, utilisez IPSec ou SSL. SSL impose l'installation d'un certificat de serveur sur le serveur de base de données.

Pour plus d'informations sur l'utilisation de SSL avec SQL Server, reportez-vous à l'article 276553 de la Base de connaissances Microsoft « How To: Enable SSL Encryption for SQL Server 2000 with Certificate Server ».

Haut de page

Pare-feu

Votre infrastructure de sécurité peut comprendre des pare-feu internes de chaque côté du serveur d'application. Cette section traite des ports que vous devez ouvrir sur ces pare-feu pour prendre en charge les fonctionnalités de votre application.

Services d'entreprise

Si vous utilisez des services d'entreprise de niveau intermédiaire, configurez le pare-feu interne qui sépare le serveur Web du serveur d'application de manière à permettre le trafic DCOM et RPC. De plus, si vous utilisez les services d'entreprise, vos applications emploient généralement des transactions distribuées et les services du DTC (Distributed Transaction Coordinator). Dans ce cas, ouvrez des ports DTC sur n'importe quel pare-feu qui sépare le serveur d'application des gestionnaires de ressources distants, tels que le serveur de base de données. La figure 17.3 montre une configuration type de port pour les services d'entreprise.

Figure 17.3
Configuration type de port pour les services d'entreprise

Remarque : la figure 17.3 ne montre pas les autres ports nécessaires au mécanisme d'authentification entre le client et l'application de services d'entreprise, ni ceux utilisés entre cette application et le serveur de base de données. Généralement, pour les réseaux qui n'utilisent pas Active Directory, le port TCP 139 est nécessaire pour l'authentification Windows. Pour plus d'informations sur les ports requis, consultez les articles TechNet "TCP and UDP Port Assignments," à l'adresse http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/windows/2000/server/reskit/en-us/cnet/cnfc_por_gdqc.asp et "Security Considerations for Administrative Authority," à l'adresse http://www.microsoft.com/technet/security/bestprac/bpent/sec2/seconaa.mspx.

Par défaut, DCOM utilise l'allocation dynamique de ports RPC, qui sélectionne de manière aléatoire les numéros de port au-delà de 1024. De plus, le port 135 est utilisé par le service de mappage de point final RPC.

Limitez les ports nécessaires pour prendre en charge DCOM sur le pare-feu interne de deux façons :

• En définissant les plages de ports.
  Vous pouvez ainsi contrôler les ports affectés dynamiquement par RPC. Pour plus d'informations sur la façon de restreindre les ports affectés de manière dynamique, reportez-vous à l'article 300083 de la Base de connaissances Microsoft « How To: Restrict TCP/IP Ports on Windows 2000 and Windows XP ».

• En utilisant le mappage de points finaux statiques.
  Microsoft Windows 2000 SP3 (ou QFE 18.1 et versions suivantes) ou Windows Server 2003 vous permet de configurer les applications Enterprise Services pour qu'elles utilisent un point final statique. Avec le mappage de points finaux statiques, vous n'avez qu'à ouvrir deux ports sur le pare-feu : le port 135 pour RPC et un port sélectionné pour votre application de services d'entreprise.

  Pour plus d'informations sur le mappage de points finaux statiques, reportez-vous à l'article 312960 de la Base de connaissances Microsoft « Cannot Set a Fixed Endpoint for a COM+ Application ».

Services Web

Si vous ne parvenez pas à ouvrir des ports sur le pare-feu interne, vous pouvez introduire une couche de façade de services Web devant les composants de service du serveur d'application. Cela signifie que vous n'avez qu'à ouvrir le port 80 pour que le trafic http (notamment les messages SOAP) puisse circuler dans les deux sens.

Cette approche ne vous autorise pas à faire circuler le contexte de transaction du client au serveur, bien que dans de nombreux cas où votre architecture de déploiement inclut un serveur d'application de niveau intermédiaire, il est préférable d'initier les transactions dans le composant de service distant, sur le serveur d'application.

Pour plus d'informations sur les besoins en matière de déploiement physique pour les agents de service et les interfaces de service, tels que la couche de façade de services Web, consultez le chapitre « Déploiement physique et exigences opérationnelles » dans la section de référence de l'article MSDN intitulé « Architecture d'applications pour .NET : conception d'applications et de services », à l'adresse /france/msdn/netframework/1X/20030225_apparch_0.mspx.

Impératifs concernant DTC

Si votre application emploie les transactions distribuées COM+ et si celles-ci sont utilisées sur différents serveurs distants séparés par un pare-feu interne, ce dernier doit ouvrir les ports requis pour prendre en charge le trafic DTC. DTC utilise une allocation dynamique des ports RPC. Outre le port 135 pour RPC, DTC a besoin d'au moins un port supplémentaire pour communiquer.

Si votre architecture de déploiement comprend un niveau d'application distant, les transactions y sont normalement lancées au sein de l'application de services d'entreprise, et sont propagées au serveur de base de données. En l'absence de serveur d'application, l'application de services d'entreprise sur le serveur Web lance la transaction et la propage vers le gestionnaire de ressources SQL Server.

Pour plus d'informations sur la configuration des pare-feu en vue de prendre en charge le trafic DTC, consultez :

• "DTC Security Considerations" dans le SDK de la plate-forme COM+ à l'adresse http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cossdk/htm/pgdtc_admin_9dkj.asp

• Article 250367 de la Base de connaissances Microsoft, « INFO: Configuring Microsoft Distributed Transaction Coordinator (DTC) to Work Through a Firewall ».

• Article 306843 de la Base de connaissances Microsoft, « How To: Troubleshoot MS DTC Firewall Issues ».

.NET Remoting

Si vous utilisez le canal http et hébergez vos composants distants dans ASP.NET, n'ouvrez que le port 80 sur le pare-feu interne pour autoriser le trafic HTTP. Si votre application utilise également SSL, ouvrez le port 443.

Si vous utilisez le canal TCP et hébergez un service Windows, ouvrez le ou les ports configurés pour votre application Remoting. L'application peut avoir besoin d'un port supplémentaire pour prendre en charge les rappels.

La figure 17.4 montre une configuration type de ports de pare-feu pour .NET Remoting. Notez que les numéros de port présentés pour le scénario du canal TCP (5555 et 5557) sont des illustrations. Les numéros de port réels sont indiqués dans les fichiers de configuration web.config, sur les machines client et serveur. Pour plus d'informations, consultez le module 13, « Création de composants distants sécurisés ».

Figure 17.4
Configuration type de ports de pare-feu Remoting pour les scénarios faisant appel à des canaux HTTP et TCP.

Services Web

Les services Web communiquent via SOAP sur HTTP ; par conséquent n'ouvrez que le port 80 sur le pare-feu interne.

SQL Server

Si un pare-feu sépare le serveur d'application du serveur de base de données, la connexion à SQL Server via un pare-feu impose que vous configuriez le client avec SQL Server Client Network Utility et le serveur de base de données avec Server Network Utility. Par défaut, SQL Server écoute sur le port TCP 1433, bien qu'il soit possible de modifier cette configuration. Le port choisi doit être ouvert sur le pare-feu.

Suivant le mode d'authentification SQL choisi et la façon dont votre application utilise des transactions distribuées, il est possible que vous deviez ouvrir plusieurs ports supplémentaires au niveau du pare-feu :

• Si votre application utilise l'authentification Windows pour se connecter à SQL Server, les ports permettant de prendre en charge le protocole Kerberos ou l'authentification NTLM doivent être ouverts.

• Si votre application utilise les transactions distribuées, comme les transactions automatisées COM+, configurez votre pare-feu pour autoriser le trafic DTC entre les instances DTC distinctes d'une part et entre le DTC et les gestionnaires de ressources tels que SQL Server d'autre part.

Pour plus d'informations sur les ports nécessaires à SQL Server, reportez-vous au module 18, « Sécurisation de votre serveur de base de données ».

Haut de page

Problèmes de sécurité de .NET Remoting

L'infrastructure .NET Remoting permet aux applications de communiquer les unes avec les autres, sur la même machine ou sur différentes machines d'un réseau. L'infrastructure Remoting peut utiliser la couche transport HTTP ou TCP pour la communication et envoyer des messages en différents formats, dont les plus courants sont le format SOAP ou binaire.

Hébergement dans un service Windows (canal TCP)

Du fait que l'infrastructure Remoting ne fournit pas de mécanismes d'authentification et d'autorisation par défaut, son utilisation pour les applications exposées à Internet n'est pas recommandée. Elle est conçue pour les applications s'exécutant dans un environnement fiable, et convient bien à la communication entre un serveur Web et des serveurs d'application distants, comme le montre la Figure 17.5.

Figure 17.5
Remoting avec un canal TCP et un hôte de service Windows

Dans ce scénario, un service Windows héberge les objets Remoting et la communication s'effectue par un canal TCP. Cette approche offre de bonnes performances, sans toutefois nécessairement traiter les aspects liés à la sécurité. Pour renforcer la sécurité, utilisez IPSec entre le serveur Web et le serveur d'applications et autorisez le serveur Web à établir des connexions avec le serveur d'applications uniquement.

Hébergement dans IIS (canal HTTP)

Pour profiter des fonctions de sécurité fournies par ASP.NET et IIS, hébergez vos composants distants dans ASP.NET et utilisez le canal HTTP pour communiquer, comme le montre la figure 17.6.

Figure 17.6
Remoting avec un canal HTTP et un hôte ASP.NET

Dans ce scénario, vous pouvez faire appel à l'authentification Windows intégrée pour authentifier l'identité de processus de l'application Web ASP.NET. Vous pouvez également employer SSL pour sécuriser la communication et les gardes-barrières fournis par IIS et ASP.NET pour l'autorisation.

Haut de page

Problèmes de sécurité liés aux services d'entreprise (COM+)

COM+ fournit l'architecture sous-jacente pour les services d'entreprise ; vous devez donc le sécuriser si vous l'utilisez sur le serveur d'applications du niveau intermédiaire. Pour sécuriser un serveur employant les services d'entreprise, vous devez suivre deux grandes étapes :

• Sécuriser l'infrastructure de services des composants.
  Vous devez sécuriser le système d'exploitation sous-jacent et l'infrastructure de services d'entreprise. Cette phase implique des mesures de sécurité élémentaires, telles que l'application des correctifs et des mises à jour, la désactivation des services et le blocage des ports inutilisés, etc.

• Configurer la sécurité de l'application de services d'entreprise.
  Vous devez sécuriser l'application de services d'entreprise déployée sur le serveur, en tenant compte des besoins de sécurité propres à l'application.

Le développeur peut spécifier bon nombre des paramètres de sécurité qui agissent au niveau de l'application ou des composants à partir des métadonnées intégrées aux assemblys déployées. Celles-ci régissent les paramètres de sécurité de catalogue affectés initialement à l'application lors de son enregistrement auprès des services d'entreprise. L'administrateur peut ensuite visualiser et modifier si nécessaire ces paramètres à l'aide de l'outil Services de composants.

Sécuriser l'infrastructure de services des composants

Les services d'entreprise ne sont pas un composant facultatif ; ils font partie intégrante de Windows 2000 et installés à ce titre avec lui. Vu sous l'angle de la sécurité, le fait de savoir quels composants du système d'exploitation sont installés pour prendre en charge les services d'entreprise vous permet de prendre les mesures de sécurité appropriées.

Quels sont les éléments installés par le système d'exploitation ?

Le tableau suivant présente les éléments de base des services de composants qui sont installés dans le cadre d'une installation standard du système d'exploitation.

Table 17.1 Composants des services d'entreprise

Quels éléments .NET Framework installe-t-il ?

Lorsque vous installez .NET Framework, les composants suivants liés aux services d'entreprise sont installés.

Tableau 17.2 Outils des services d'entreprise .NET Framework et paramètres de configuration

Pour sécuriser l'infrastructure de services de composants, examinez les éléments suivants :

• Correctifs et mises à jour

• Services

• Ports

• Catalogue COM+

Correctifs et mises à jour

Mettez à jour le serveur d'applications avec les derniers Service Packs et correctifs pour limiter les risques associés aux virus, vers et chevaux de Troie. Parmi les logiciels devant être mis à jour régulièrement figure le système d'exploitation, qui comprend IIS et .NET Framework.

Les mises à jour du runtime COM+ sont parfois publiées sous forme de versions QFE. Utilisez les ressources suivantes pour faciliter la gestion des correctifs et des mises à jour :

• Mises à jour et correctifs de Windows
  Utilisez MBSA (Microsoft Baseline Security Analyzer) pour détecter les mises à jour de sécurité manquantes sur les serveurs d'application. Pour plus d'informations sur la façon d'utiliser MSBA sur un ordinateur unique et pour maintenir un groupe de serveurs à jour, reportez-vous à « Procédure : utilisation de MBSA » dans la section « Procédures » de ce guide.

  Pour plus d'informations sur les environnements dans lesquels de nombreux serveurs doivent être mis à jour à partir d'un point d'administration centralisé, consultez « Procédure : implémentation de la gestion des correctifs logiciels » dans la section « Procédures » de ce guide.

• Mises à jour et correctifs de .NET Framework
  À l'heure où nous rédigeons ces lignes (mai 2003) MBSA n'a pas la capacité de détecter .NET Framework. Vous devez donc mettre à jour manuellement .NET Framework.

• Pour mettre à jour manuellement .NET Framework

  1. Déterminez le Service Pack .NET Framework qui est installé sur votre serveur Web.
     Pour cela, consultez l'Article 318785 de la Base de connaissances Microsoft, « COMMENT FAIRE : Procédures pour déterminer si des Service Packs sont installés sur .NET Framework."

  2. Comparez la version installée de .NET Framework au Service Pack actif.
     Pour cela, consultez l'Article 318836 de la Base de connaissances Microsoft, « INFO : Comment obtenir le dernier Service Pack pour .NET Framework ».

     • Mises à jour et correctifs de COM+
       Les derniers Service Packs de Windows intègrent les derniers correctifs en date de COM+. Toutefois, les mises à jour du runtime COM+ sont parfois publiées sous forme de versions QFE. Il n'existe pas actuellement de service de notification automatique pour les mises à jour de COM+ : vous devez donc surveiller la base de connaissances Microsoft à l'adresse http://support.microsoft.com. Utilisez "kbQFE" comme mot clé de recherche pour affiner les résultats de la recherche.

Services

Pour réduire la surface exposée aux attaques, désactivez tous les services qui ne sont pas indispensables. Parmi les services requis figurent Microsoft DTC et le service COM+ Event System, nécessaire pour prendre en charge la fonction LCE COM+.

Pour sécuriser les services sur votre serveur d'application, désactivez MS DTC s'il n'est pas nécessaire.

Désactiver le service Microsoft DTC (s'il est inutile)

Le service DTC est étroitement intégré avec COM+. Il coordonne les transactions qui sont réparties sur plusieurs bases de données, files d'attente de messages, système de fichiers ou autres gestionnaires de ressources. Si vos applications n'utilisent pas les services de transaction automatisés COM+, le service DTC doit être désactivé avec le composant logiciel enfichable MMC des Services.

Ports

Les composants de service communiquent à l'aide de DCOM, qui communique à son tour à l'aide du transport RPC.

Par défaut, DCOM alloue dynamiquement les ports, ce qui n'est pas souhaitable du point de vue de la sécurité et de la configuration des pare-feu. Les ports DCOM doivent être restreints afin de réduire la surface exposée aux attaques et d'éviter d'ouvrir des ports inutiles sur le pare-feu interne. Vous avez deux options pour restreindre les ports utilisés par DCOM :

• Utiliser des plages de ports.

• Utiliser le mappage statique des points finaux.

Plages de ports

Pour les communications entrantes, vous pouvez configurer l'allocation dynamique de ports RPC de façon à sélectionner certains ports appartenant à une plage limitée au-delà de 1024. Ensuite, configurez votre pare-feu de manière à limiter les communications externes entrantes à ces seuls ports et au port 135, réservé au mappeur de point final RPC.

• Pour gérer l'allocation dynamique de ports RPC

  1. Lancez l'outil Services de composants.

  2. Cliquez pour développer les nœuds Services de composants et Ordinateurs, cliquez avec le bouton droit sur Poste de travail, puis cliquez sur Propriétés.

  3. Cliquez sur l'onglet Protocoles par défaut, puis sélectionnez TCP/IP orienté connexion dans la zone de liste Protocoles DCOM.

  4. Cliquez sur Propriétés.

  5. Dans la boîte de dialogue Propriétés pour les services Internet COM, cliquez sur Ajouter.

  6. Dans la zone de texte Plage de ports, ajoutez une plage de ports, par exemple 5000–5020 puis cliquez sur OK.

  7. Laissez les options Attribution de plages de ports et Affectation du port dynamique par défaut définies sur Étendue : Internet.

  8. Cliquez deux fois sur OK pour fermer la boîte de dialogue.

  9. Redémarrez l'ordinateur pour que les modifications prennent effet.

Mappage statique des points finaux

Windows 2000 (SP3 ou QFE 18.1) ou Windows Server 2003 vous permet de configurer les applications de services d'entreprise pour qu'elles utilisent un point final statique. Si un pare-feu sépare le client du serveur, vous n'avez besoin d'ouvrir que deux ports sur le pare-feu. Ce sont le port 135 pour RPC et un port destiné à votre application de services d'entreprise.

• Pour configurer un point final statique pour DCOM

  1. Obtenez l'ID d'application de votre application de services d'entreprises dans le catalogue COM+. Pour effectuer cette opération, suivez la procédure ci-après :

     • Lancez l'outil Services de composants.

     • Affichez la boîte de dialogue Propriétés de l'application et récupérez l'ID d'application dans la page Général.

  2. Lancez L'Éditeur du Registre (Regedt32.exe).

  3. Sélectionnez la clé de registre suivante :

     HKEY_CLASSES_ROOT\AppID
     

  4. Dans le menu Edition, cliquez sur Ajouter une valeur, puis ajoutez la valeur de registre suivante, où {Votre AppID} est l'ID de l'application COM+ que vous avez obtenu à l'étape 1 :

     Nom de la clé : {Votre AppID} 
     Nom de la valeur : Endpoints
     Type de données : REG_MULTI_SZ
     Données de la valeur : ncacn_ip_tcp,0,<numéro de port>
     

     Le numéro de port que vous indiquez dans la zone de texte Données de la valeur doit être supérieur à 1024 et de doit pas entrer en conflit avec les ports connus que d'autres applications de l'ordinateur utilisent. Vous ne pouvez pas modifier la partie ncacn_ip_tcp,0 de cette clé.

  5. Fermez l'Éditeur du Registre.

Catalogue COM+

Les paramètres de configuration de l'application de services d'entreprise sont conservés dans le catalogue COM+. La majeure partie des options de configuration est stockée dans la base de données d'enregistrement (RegDB), composée des fichiers situés dans le répertoire suivant :

%windir%\registration

Par défaut, le groupe Tout le monde a le droit de lire la base de données. Modifiez l'ACL de ce répertoire pour limiter l'accès en lecture/écriture aux administrateurs et au compte système local. Accordez également un accès en lecture aux comptes utilisés pour exécuter les applications de services d'entreprise. Voici l'ACL requise :

Administrateurs : Lecture/écriture
Système :  Lecture/écriture
Comptes " Exécuter en tant que " des services d'entreprise : Lecture

Applications de services d'entreprise sécurisées

Les paramètres individuels de configuration d'application sont stockés dans le catalogue COM+ et peuvent être configurés à l'aide de l'outil Services de composants ou par le biais de scripts. Bon nombre des paramètres traités ci-dessous peuvent également être définis par les développeurs d'applications : il leur suffit pour cela d'utiliser les métadonnées de niveau assembly appropriées dans l'assembly du composant de service. Lorsque vous enregistrez le composant de service, par exemple au moyen de Regsvcs.exe, le catalogue COM+ est automatiquement configuré au moyen de ces métadonnées, bien que l'identité « Exécuter en tant que » de l'application doive être configurée par un administrateur.

Pour sécuriser une application de services d'entreprise, vous devez configurer les éléments suivants :

• Identité (Exécuter en tant que)

• Niveau d'authentification

• Sécurité COM+ basée sur les rôles

• Emprunt d'identité

• Fichiers journaux CRM

• Assemblys de l'application

Identité (Exécuter en tant que)

Configurez les applications du serveur de services d'entreprise pour qu'elles s'exécutent avec les comptes les moins privilégiés. Ceci limite les dommages que pourrait causer un pirate qui parviendrait à intervenir sur le processus serveur et à exécuter du code en utilisant son contexte de sécurité.

Si les composants de service au sein de l'application de services d'entreprise n'empruntent pas le contexte de sécurité de l'appelant, l'identité de niveau processus indiquée via le compte « Exécuter en tant que » est utilisée pour l'accès aux ressources locales et distantes situées en aval. Pour prendre en charge l'authentification réseau sur un serveur de base de données distant, vous pouvez créer un compte local « miroir », c'est-à-dire un compte local sur le serveur distant pour lequel le nom d'utilisateur et le mot de passe correspondent.

Remarque : lorsque vous définissez l'identité « Exécuter en tant que » avec les services d'entreprise, le privilège « Ouvrir une session en tant que tâche » est automatiquement accordé au compte.

Niveau d'authentification

Pour authentifier les appelants, les applications de services d'entreprise font appel à RPC, qui utilise à son tour les services sous-jacents d'authentification du système d'exploitation fournis via la couche SSPI (Security Service Provider Interface). Cela signifie que les applications authentifient les appelants avec l'authentification Windows, qui peut utiliser Kerberos ou NTLM.

RPC définit les niveaux d'authentification qui déterminent quand a lieu l'authentification et si des communications authentifiées doivent faire l'objet de vérifications d'intégrité ou être cryptées. Au minimum, vous devriez utiliser une authentification au niveau appel pour vous assurer que chaque appel à une méthode de composant de service est authentifié.

Remarque : l'authentification au niveau appel n'entraîne pas le cryptage des données de message. De ce fait, si l'écoute clandestine du réseau constitue un véritable problème, utilisez le niveau d'authentification avec confidentialité du paquet ou faites appel à une authentification au niveau appel sur un canal sécurisé avec IPSec.

Le tableau 17.3 présente les différents niveaux d'authentification :

Tableau 17.3 : Niveaux d'authentification de l'application de services d'entreprise

• Pour définir l'authentification au niveau appel

  1. Démarrez les Services de composants et affichez la boîte de dialogue Propriétés de l'application.

  2. Cliquez sur l'onglet Sécurité.

  3. Sélectionnez Appeler dans la liste déroulante Niveau d'authentification pour les appels.

Sécurité COM+ basée sur les rôles

Les autorisations dans les applications de services d'entreprise sont fournies par les rôles des services d'entreprise (COM+). Les rôles COM+ contiennent des comptes d'utilisateurs et de groupes Windows, et servent à restreindre l'accès aux applications, composants, interfaces et méthodes. Dans l'idéal, vos applications de services d'entreprise doivent être configurées pour une autorisation au niveau composant, qui vous permet d'autoriser les appelants à utiliser des méthodes de composant de service individuelles.

Pour configurer la sécurité basée sur les rôles :

• Activez la sécurité basée sur les rôles.

• Activez les contrôles d'accès au niveau composant.

• Appliquez les contrôles d'accès au niveau composant.

Activer la sécurité basée sur les rôles

Par défaut, la sécurité basée sur les rôles est désactivée dans Windows 2000. En revanche, elle est activée dans Windows Server 2003.

• Pour activer la sécurité basée sur les rôles

  1. Démarrez l'outil Services de composants et affichez la boîte de dialogue Propriétés de l'application.

  2. Cliquez sur l'onglet Sécurité.

  3. Sélectionnez Appliquer les vérifications d'accès pour cette application.

     

Figure 17.7
Activation de la sécurité basée sur les rôles

Activer les contrôles d'accès au niveau composant

Sans contrôle d'accès au niveau composant, tout compte utilisé pour se connecter à un composant quelconque de l'application se voit accorder un accès s'il est membre d'un rôle de l'application, quel qu'il soit. Avec les contrôles d'accès au niveau composant, les autorisations sont définies par les composants individuels. C'est le niveau de précision recommandé.

• Pour activer les contrôles d'accès au niveau composant

  1. Démarrez l'outil Services de composants et affichez la boîte de dialogue Propriétés de l'application.

  2. Cliquez sur l'onglet Sécurité.

  3. Cliquez sur Effectuer les vérifications d'accès au niveau du processus et des composants.

     

Figure 17.8
Activation des contrôles d'accès au niveau composant

Appliquer les contrôles d'accès au niveau composant

Pour permettre à des composants individuels appartenant à l'application de services d'entreprise d'effectuer des contrôles d'accès et d'autoriser les appelants, vous devez activer les contrôles d'accès au niveau composant.

• Pour appliquer les contrôles d'accès au niveau composant

  1. Démarrez l'outil Services de composants et développez votre application dans l'arborescence.

  2. Sélectionnez le dossier Composants, cliquez dessus avec le bouton droit, puis cliquez sur Propriétés.

  3. Cliquez sur l'onglet Sécurité.

  4. Cliquez sur Appliquer les vérifications d'accès au niveau du composant.

Remarque : ce paramètre n'a d'effet que si vous avez activé le contrôle d'accès au niveau application et avez configuré le contrôle d'accès au niveau processus et composant, comme indiqué précédemment.

Emprunt d'identité

Les clients DCOM définissent le niveau d'emprunt d'identité pour déterminer les capacités du serveur avec lequel ils communiquent en matière d'emprunt d'identité. Lors de la configuration d'une application de services d'entreprise s'exécutant sur un serveur d'application de niveau intermédiaire, le niveau d'emprunt d'identité défini affecte tous les appels à distance s'adressant à des composants en aval, y compris le serveur de base de données. Le niveau d'emprunt d'identité est défini dans la page Sécurité de la boîte de dialogue Propriétés de l'application, dans Services de composants, comme le montre la figure 17.9.

Figure 17.9
Niveaux d'emprunt d'identité DCOM

Le niveau approprié dépend des fonctionnalités voulues au niveau application, mais vous devez le déterminer en respectant les consignes suivantes :

• Evitez l'emprunt d'identité Anonyme. Le composant aval ne pourra pas identifier votre application à des fins d'authentification ou d'autorisation.

• Utilisez Identifier pour permettre au composant aval d'authentifier et d'autoriser votre application. Il ne sera cependant pas en mesure d'accéder aux ressources locales ou distantes en utilisant le contexte de sécurité emprunté de votre application.

• Utilisez Emprunter l'identité si vous voulez autoriser le composant aval à emprunter l'identité de votre application afin d'accéder aux ressources locales du serveur en aval.

• Utilisez Délégué si vous voulez autoriser le composant aval à emprunter l'identité de votre application afin d'accéder aux ressources locales ou distantes. Dans ce cas, des comptes doivent être configurés pour la délégation dans Active Directory.

Tout accès aux ressources en aval effectué par des composants de service de votre serveur d'application de niveau intermédiaire s'effectue normalement avec l'identité du serveur d'application. Toutefois, si les composants de service effectuent un emprunt d'identité par programmation et si l'application cliente (qui est généralement une application ASP.NET ou un service Web sur le serveur Web) a été configurée pour prendre en charge la délégation Kerberos, c'est l'identité du client qui est utilisée.

Pour obtenir davantage d'informations, consultez la section « How To : Enable Kerberos Delegation in Windows 2000 » dans la section « How To » de « Microsoft patterns & practices Volume I, Building Secure ASP.NET Web Applications: Authentication, Authorization, and Secure Communication » à l'adresse http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/secnetlpMSDN.asp.

Fichiers journaux CRM

Si votre application de services d'entreprise utilise le CRM, vous devez vous assurer que les fichiers journaux CRM sont sécurisés pour éviter tout risque de divulgation d'informations. Selon la nature de l'application, les fichiers peuvent contenir des données d'application sensibles. Les fichiers journaux CRM sont créés dans le répertoire suivant :

%windir%\system32\dtclog

Les noms des fichiers journaux CRM sont dérivés de l'ID de l'application de services d'entreprise et portent l'extension .crmlog. Les fichiers journaux CRM sont sécurisés au moment de leur création par les services d'entreprise et sont configurés avec un ACL qui accorde un contrôle total au compte « Exécuter en tant que » de l'application. Aucun autre compte ne peut y accéder.

Si vous modifiez l'identité de l'application après la création du fichier journal, vous devez modifier manuellement l'ACL du fichier. Assurez-vous que la nouvelle identité « Exécuter en tant que » de l'application dispose de l'autorisation « Contrôle total ».

Assemblys de l'application

Pour protéger les assemblys de l'application déployée qui contiennent des composants de service, vous devez renforcer les ACL associés aux fichiers .dll des assemblys, afin d'empêcher leur remplacement ou leur suppression par des utilisateurs non autorisés.

Appliquez l'ACL suivante au dossier DLL de votre application :

Utilisateurs : Exécuter
Compte Exécuter en tant que de l'application : Exécuter
Administrateurs : Lecture, écriture et exécution

L'emplacement des DLL d'assembly d'une application est défini au moment du déploiement ; il peut donc différer d'une installation à l'autre. La boîte de dialogue Propriétés de l'outil Services de composants n'indique pas l'emplacement des DLL d'assembly. Il pointe vers %windir%\System32\mscoree.dll, qui fournit les services d'interception du composant.

• Pour connaître l'emplacement des DLL de l'application

  1. Démarrez l'outil Services de composants et développez votre application dans l'arborescence.

  2. Sélectionnez le dossier Composants, sélectionnez un composant, cliquez dessus avec le bouton droit, puis cliquez sur Propriétés.

  3. Dans la boîte de dialogue Propriétés extrayez l'ID de classe (CLSID) du composant.

  4. Lancez Regedt32.exe et localisez le CLSID extrait sous HKEY_CLASSES_ROOT\CLSID.

  5. Cliquez sur la clé InprocServer32.

     L'emplacement de la DLL est indiqué par la valeur nommée CodeBase.

Haut de page

Résumé

Lorsque les défenses en place pour un réseau de périmètre sont suffisantes, les menaces susceptibles d'affecter les serveurs d'application de niveau intermédiaire proviennent pour la plupart de l'intérieur même de l'organisation. Disposer d'une infrastructure sécurisée composée de stratégies IPSec qui autorisent uniquement l'accès au serveur d'application à partir de certains serveurs Web tout en fournissant des canaux de communication sécurisés est une stratégie efficace pour limiter les risques.

Dans ce module, vous avez pu aborder des mesures de sécurité supplémentaires. Elles varient en fonction de la technologie utilisée sur le serveur d'applications.

Les pare-feu internes de chaque côté du serveur d'application posent d'autres problèmes. Les ports qui doivent être ouverts dépendent des choix faits en matière de mise en œuvre de l'application, tels que les protocoles de transport et l'utilisation des transactions distribuées.

Haut de page

Informations complémentaires

Pour plus d'informations sur les questions traitées dans ce module, consultez les articles suivants dans la Base de connaissance Microsoft, à l'adresse http://support.microsoft.com :

• Article 233256, How To: Enable IPSec Traffic Through a Firewall »

• Article 312960, Cannot Set a Fixed Endpoint for a COM+ Application »

• Article 259011 SAMPLE: A Simple DCOM Client Server Test Application »

• Article 248809 SAMPLE: DCOM Does Not Work over Network Addressed Translation – Based Firewall »

• Article 250367 INFO: Configuring Microsoft Distributed Transaction Coordinator (DTC) to Work Through a Firewall »

• Article 154596, PROCÉDURE : Configurer l'allocation de port dynamique RPC avec un pare-feu »

Haut de page