Recommandations de déploiement RPC sur HTTP

Cette section décrit les meilleures pratiques et les configurations de déploiement recommandées pour obtenir une sécurité et des performances maximales lors de l’utilisation de RPC sur HTTP. Les différentes configurations trouvées ici s’appliquent à différentes organisations en fonction de différentes exigences en matière de taille, de budget et de sécurité. Chaque configuration fournit également des considérations de déploiement utiles pour déterminer ce qui convient le mieux à un scénario donné.

Pour plus d’informations sur les scénarios RPC à volume élevé sur HTTP, consultez Microsoft RPC Load Balancing.

Les recommandations suivantes s’appliquent à toutes les configurations :

• Utilisez des versions de Windows qui prennent en charge RPC sur HTTP v2.
• Placez IIS sur l’ordinateur qui exécute le proxy RPC en mode IIS 6.0.
• Interdire l’accès anonyme au répertoire virtuel du proxy RPC.
• N’activez jamais la clé de Registre AllowAnonymous.
• Faites en sorte que vos clients RPC sur HTTP utilisent le certificateSubjectField (voir RpcBindingSetAuthInfoEx pour plus d’informations) pour vérifier que le proxy RPC auquel vous vous êtes connecté est le proxy RPC attendu.
• Configurez les ValidPorts clé de Registre pour contenir uniquement les ordinateurs auxquels le RPC sur les clients HTTP se connectera.
• N’utilisez pas de caractères génériques dans la clé ValidPorts ; cela peut gagner du temps, mais une machine complètement inattendue peut également s’adapter au caractère générique.
• Utilisez SSL sur RPC sur les clients HTTP. Si les instructions définies dans ces sections sont suivies, le client RPC sur HTTP ne pourra pas se connecter sans utiliser SSL.
• Configurez RPC sur les clients HTTP pour utiliser le chiffrement RPC en plus d’utiliser SSL. Si le client RPC sur HTTP ne peut pas atteindre le KDC, il peut utiliser uniquement Negotiate et NTLM.
• Configurez les machines clientes pour utiliser NTLMv2. Définissez la clé de Registre LMCompatibilityLevel sur 2 ou version ultérieure. Consultez msdn.microsoft.com pour plus d’informations sur la clé LMCompatibilityLevel.
• Exécutez une batterie de serveurs web de machines proxy RPC avec la configuration décrite ci-dessus.
• Déployez un pare-feu entre Internet et le proxy RPC.
• Pour optimiser les performances, configurez IIS pour envoyer une réponse courte pour les codes d’erreur non réussis. Étant donné que le consommateur de la réponse IIS est un processus automatisé, il n’est pas nécessaire d’envoyer des explications conviviales au client ; ils seront simplement ignorés par le RPC via le client HTTP.

Les objectifs de base du proxy RPC du point de vue de la sécurité, des performances et de la facilité de gestion sont les suivants :

• Fournissez un point d’entrée unique pour RPC via le trafic HTTP vers le réseau de serveur. Le fait d’avoir un point d’entrée unique pour RPC sur le trafic HTTP vers un réseau de serveur présente deux principaux avantages. Tout d’abord, étant donné que le proxy RPC est confronté à Internet, la plupart des organisations isolent ces machines dans un réseau spécial appelé réseau de périmètre non approuvé qui est distinct du réseau organisationnel normal. Les serveurs d’un réseau de périmètre non approuvé sont très soigneusement gérés, configurés et surveillés pour pouvoir résister aux attaques provenant d’Internet. Le moins de machines d’un réseau de périmètre non approuvé, plus il est facile de configurer, de gérer, de surveiller et de sécuriser ces machines. Deuxièmement, étant donné qu’une seule batterie de serveurs web avec des proxys RPC installés peut traiter n’importe quel nombre de serveurs RPC sur des serveurs HTTP résidant sur le réseau d’entreprise, il est beaucoup judicieux de séparer le proxy RPC du serveur RPC sur le serveur HTTP et de placer le proxy RPC dans un réseau de périmètre non approuvé. Si le proxy RPC se trouvait sur la même machine que le serveur RPC sur http, les organisations seraient forcées de placer tous leurs serveurs principaux dans un réseau de périmètre non approuvé, ce qui rendait beaucoup plus difficile la sécurité du réseau de périmètre non approuvé. La séparation du rôle du proxy RPC et du serveur RPC sur HTTP permet aux organisations de conserver le nombre d’ordinateurs dans un réseau de périmètre non approuvé gérable et, par conséquent, plus sécurisé.
• Servir de fusible de sécurité pour le réseau serveur. Le proxy RPC est conçu comme un fusible utilisable pour le réseau du serveur : si quelque chose se produit mal sur le proxy RPC, il sort simplement et protège ainsi le RPC réel sur le serveur HTTP. Si les meilleures pratiques décrites dans cette section ont été suivies jusqu’à présent, le RPC sur le trafic HTTP est chiffré avec le chiffrement RPC en plus du protocole SSL. Le chiffrement RPC lui-même est entre le client et le serveur, et non entre le client et le proxy. Cela signifie que le proxy ne comprend pas et ne peut pas déchiffrer le trafic RPC qu’il reçoit. Il comprend uniquement certaines séquences de contrôle envoyées par le client traitant de l’établissement de la connexion, du contrôle de flux et d’autres détails de tunneling. Il n’a pas accès aux données envoyées par le client RPC via HTTP au serveur. En outre, le client RPC sur HTTP doit s’authentifier indépendamment auprès du proxy RPC et du serveur RPC sur le serveur HTTP. Cela fournit une défense en profondeur. Si l’ordinateur proxy RPC devient compromis, en raison d’une erreur de configuration ou d’une violation de sécurité d’une certaine sorte, les données qui le passent sont toujours sécurisées contre la falsification. Un attaquant qui aurait le contrôle du proxy RPC peut interrompre le trafic, mais pas le lire ou le falsifier. C’est là que le rôle de fusion du proxy RPC entre en jeu : il est utilisable sans que la sécurité du rpc sur le trafic HTTP soit compromise.
• Distribuez certaines des vérifications d’accès et déchiffrement entre plusieurs machines exécutant le proxy RPC dans une batterie de serveurs web. En fonctionnant correctement dans une batterie de serveurs web, le proxy RPC permet aux organisations de décharger le déchiffrement SSL et certaines des vérifications d’accès, ce qui libère davantage de capacité sur le serveur principal pour le traitement. L’utilisation d’une batterie web de machines proxy RPC permet également à une organisation d’augmenter sa capacité à résister aux attaques par déni de service (DoS) en augmentant la capacité sur ses serveurs frontaux.

Dans les lignes directrices définies jusqu’à présent, les organisations ont toujours des choix. Chaque organisation a des choix et des compromis entre les inconvénients des utilisateurs, la sécurité et le coût :

• Utilisez l’authentification de base ou l’authentification intégrée Windows pour vous authentifier auprès du proxy RPC ? RPC sur HTTP prend actuellement en charge uniquement NTLM . Il ne prend pas en charge Kerberos. En outre, s’il existe un proxy HTTP ou un pare-feu entre le client RPC via le client HTTP et le proxy RPC qui insère le via pragma dans l’en-tête HTTP, l’authentification NTLM ne fonctionnera pas. Si ce n’est pas le cas, les organisations peuvent choisir entre l’authentification de base et NTLM. L’avantage de l’authentification de base est qu’il est plus rapide et plus simple, et offre donc moins d’opportunités pour les attaques par déni de service. Mais NTLM est plus sécurisé. Selon les priorités d’une organisation, il peut choisir Basic, NTLM ou autoriser ses utilisateurs à choisir entre les deux. Si un seul est choisi, il est préférable de désactiver l’autre à partir du répertoire virtuel proxy RPC pour réduire le risque d’attaque.
• Utilisez le même ensemble d’informations d’identification pour le proxy RPC et le RPC sur le serveur HTTP, ou utilisez des informations d’identification différentes pour chacun d’eux ? Le compromis pour cette décision est entre la commodité et la sécurité de l’utilisateur. Peu d’utilisateurs aiment entrer plusieurs informations d’identification. Toutefois, si une violation de sécurité se produit dans un réseau de périmètre non approuvé, avoir des ensembles distincts d’informations d’identification pour le proxy RPC et le serveur RPC sur HTTP server fournit une protection supplémentaire. Notez que si des informations d’identification distinctes sont utilisées et qu’un ensemble d’informations d’identification est les informations d’identification de domaine de l’utilisateur, il est recommandé d’utiliser les informations d’identification de domaine de l’utilisateur pour le serveur RPC sur le serveur HTTP et non pour le proxy RPC.