Fournisseurs ASP.Net du serveur Web dans la zone démilitarisée

Question

Nous avons une application Web asp.net intranet qui utilise l’adhésion OOTB ASP.net et les fournisseurs de rôles.

Nous prévoyons maintenant d'exposer l'application à Internet en déplaçant le serveur Web vers la zone démilitarisée, comme indiqué dans le diagramme de texte suivant (merdique)

             External                    Internal     
internet --- Firewall --- Web server --- Firewall --- App Server --- Database

                             DMZ                              Intranet

Le problème vient maintenant du fait que les fournisseurs d'appartenance asp.net et de rôle sur le serveur Web ne peuvent pas se connecter au serveur SQL à cause du pare-feu interne.

Avez-vous déjà fait face à un tel scénario auparavant? Recommanderez-vous d'ouvrir des ports dans le pare-feu interne afin que le serveur Web puisse se connecter directement au serveur SQL? Quelles autres solutions ai-je (autres qu'essayer moi-même un fournisseur personnalisé)?

Answer 1

La modification de votre stratégie DMZ et l’ouverture de ports sont généralement très difficiles. Vous feriez mieux de réussir ce que j’ai fait: exposer un service WCF au sein du réseau et communiquer avec lui via HTTP sur le port 80.

Zéro frottement avec les gens du réseau local, et je ne fais que simuler la même API exacte (bien que nulle) que .NET nous donne:)

Modifier: pour clarifier, cela signifie que j’ai un RemoteRoleProvider configuré comme suit:

<roleManager enabled="true" defaultProvider="RemoteRoleProvider">
   <providers>
      <add name="RemoteRoleProvider" type="MyCorp.RemoteRoleProvider, MyCorp" serviceUrl="http://some_internal_url/RoleProviderService.svc" />
   </providers>
</roleManager>

Answer 2

Nous avons plusieurs serveurs Web faisant face à Internet dans une zone démilitarisée et nous avons dû ouvrir des tunnels de notre pare-feu au serveur SQL de notre réseau privé avec lequel ils doivent interagir. Je pense que nous avons utilisé autre chose que le port 1433 pour les connexions SQL. Jusqu’à présent, cela a très bien fonctionné, c’est-à-dire qu’il n’ya pas eu de violation de la sécurité.