Как развернуть приложение на основе веб-API и браузера ASP.NET в производственной среде

(Пожалуйста, простите, если это опубликовано на неправильном форуме. Мы не знали, где именно это опубликовать.)

У нас есть одностраничное приложение ASP.NET Web API - приложение на основе браузера, работающее в IIS для обслуживания HTML5 / CSS3 / JavaScript, которое взаимодействует с конечной точкой веб-API ASP.NET только для доступа к базе данных и передачи данных JSON. В нашей среде разработки все отлично работает - то есть у нас есть одно решение Visual Studio с проектом веб-API ASP.NET и два проекта библиотеки классов для доступа к данным. При разработке и тестировании модулей разработки с использованием IIS Express на порт localhost: для запуска сайта и доступа к веб-API все в порядке.

Теперь нам нужно перенести его в производственную среду (а у нас проблемы - или мы просто не понимаем, что нужно делать).

Производственная среда полностью внутренняя (в общедоступном Интернете ничего не публикуется). Есть два домена. В один домен, корпоративный, все пользователи обычно входят в систему. Другой домен, домен процесса, содержит экземпляр SQL Server, к которому нашему приложению и веб-API потребуется доступ.

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

домен корпорации (конечные пользователи) <–> брандмауэр (открытый порт 80) <–> DMZ (веб-сервер, на котором запущен IIS) <–> брандмауэр (открытый порт 80 или 1433 ????) <–> домен процесса (IIS для веб-API и SQL Server)

Мы разработчики и не совсем понимаем все сетевые аспекты, поэтому нам интересно, как развернуть наше приложение браузера / веб-API в этом сценарии.

Нужно ли нам разбивать наше приложение так, чтобы весь клиентский код (HTML5 / CSS3 / JavaScript / images / и т. Д.) Находился на сервере IIS в DMZ, а веб-API устанавливался на сервере в домене процесса?
Или все приложение (клиентский код и веб-API) остается вместе на сервере IIS в DMZ, который затем каким-то образом обращается к экземпляру SQL Server для получения данных?
Не могли бы вы просто получить доступ к веб-API на сервере в домене процесса с сервера и приложения IIS в DMZ, выбрав "http: // сервер / имя приложения / api / getitmes"?
Во втором брандмауэре между DMZ и доменом процесса нужно ли открывать порт 1433 или просто порт 80, поскольку веб-API является конечной точкой HTTP?
Или есть какой-нибудь лучший способ развертывания (то есть, как одностраничные приложения ASP.NET Web API, написанные полностью на HTML5 и JavaScript, должны быть развернуты в производственной среде?)?

Я уверен, что есть и другие вопросы, но мы начнем с них. Спасибо!!!

(Примечание: это серверы Win2k8 R2, SQL Server 2k8 R2 и IIS 7.5.)

Я понимаю, что ваша ИТ-группа хочет разобраться в этом, но, похоже, они тоже не до конца понимают, как работает эта установка. Я не буду вдаваться в подробности, но, по сути, это единственный трафик, которым вы будете обмениваться с серверами до process домен - это стандартный HTTP-трафик (при условии, что вы используете веб-API для вызовов REST)

По сути, вы получите следующее:

           Initial Request
SPA Web Server ---> Client (Running SPA)
                      |
                      | - REST Call
          Firewall -> | - Port 80 Only
                Web API Server
                      |
                      | - SQL (1433) .NET Connection/Data Source
          Firewall -> | - Port 1433 / 1434
             Backend SQL Servers

Помните, что при использовании SPA единственное взаимодействие клиента с веб-сервером SPA - это первоначальный запрос на получение HTML, JS и CSS. После этого (в зависимости от того, как вы это написали) он должен напрямую отправлять вызовы REST на сервер веб-API.

Сервер веб-API отправляет SQL-запросы прямо оттуда в базу данных.

Итак, коротко и коротко:

TL; DR: У вас должен быть брандмауэр между вашими клиентами и двумя экземплярами IIS (кстати, они могут быть одним и тем же сервером), чтобы разрешать трафик HTTP и HTTPS. Затем на другом интерфейсе этого веб-сервера (-ов) у вас есть подключение к домену процесса, и разрешен вход только для трафика SQL (1433 и 1434).

Надеюсь, это поможет.