Поставщики 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:)

Изменить: чтобы уточнить, это означает, что у меня есть 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

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