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

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

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


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

                             DMZ                              Intranet

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

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


deployment architecture asp.net dmz asp.net-membership
person Nimesh Madhavan    schedule 22.10.2008    source источник

Ответы (2)


arrow_upward
2
arrow_downward

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

Никаких трений с людьми из LAN, и я просто имитирую тот же самый точный (хотя и дрянной) 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>
person Ben Scheirman    schedule 22.10.2008

arrow_upward
1
arrow_downward

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

person Chris Tybur    schedule 22.10.2008