Поставщики ASP.Net с веб-сервера в DMZ

Question

У нас есть веб-приложение asp.net для интрасети, в котором используются поставщики членства и роли OOTB ASP.net.

Теперь мы планируем выставить заявку в Интернете, путем перемещения веб-сервера в DMZ, как показано в следующем (дерьмовый) текста диаграммы

 

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

          DMZ        Intranet 

Теперь проблема заключается в том, что членство asp.net и поставщики ролей на веб-сервере не могут подключаться к серверу sql из-за внутреннего брандмауэра.

Вы когда-нибудь сталкивались с таким сценарием раньше? Порекомендуете ли вы открыть порты во внутреннем брандмауэре, чтобы веб-сервер мог напрямую подключиться к SQL-серверу? Какие у меня есть другие альтернативы (другой, кто сам забирает пользовательский поставщик)?

Answer 1

Изменение политики DMZ и открытие портов обычно ДЕЙСТВИТЕЛЬНО трудны. У вас может быть лучший успех в том, что я сделал: выставлять службу WCF внутри сети и связываться с ней по HTTP на порту 80.

Нулевое трение с людьми локальной сети, и я просто имитирую тот же точный (хотя и дерьмовый) API что .NET дает нам :)

Edit: выяснить, это означает, что у меня есть RemoteRoleProvider, который настроен так:

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

Answer 2

У нас есть пара веб-серверов, ориентированных на Интернет в DMZ, и нам пришлось открывать туннели в нашем брандмауэре обратно на SQL-сервер в нашей частной сети, с которой им нужно взаимодействовать. Я думаю, мы использовали что-то другое, чем порт 1433 для SQL-соединений. До сих пор он работал очень хорошо, то есть никаких нарушений безопасности.