Как ограничить доступ к веб-ресурсам из Интернета, но выставить их во внутренней сети

"Когда я запрашиваю страницу на веб-сайте через программу Fiddler, я вижу запрос веб-сайта, но не вижу запроса веб-сервисов с веб-сайта"

Это утверждение верно в очень ограниченном контексте, но реальность гораздо шире.

Запросы с веб-сайта к его собственному API можно легко увидеть, например, с помощью инструментов браузера ... нажмите F12 в любом браузере и посмотрите на вкладку «Сеть», это то, что любой может сделать, чтобы увидеть, что такое веб-сайт (любой веб-сайт). делает.

Вам нужно как-то защитить свой API. Вы можете использовать что-то вроде OAuth2 или сделать это на уровне сервера. Например, вы можете заблокировать сервер, чтобы принимать подключения только с IP-адреса вашего сайта. Вы также можете сделать так, чтобы сервер, на котором находится API, был полностью заблокирован. Вы можете заблокировать API.

Вам просто нужно понять, что у вас есть проблема с безопасностью, если вы ничего не делаете. Стек технологий, который вы используете, не имеет значения для этого.

Currently, the client accesses the web services directly, but it’s necessary to make the client access the web server and the web server access the web services

Даже если вы создадите другое приложение ASP.NET (своего рода «фасад»), которое обрабатывает запросы от клиента и вызывает внутренние веб-службы, это само по себе не решит проблему:

• Если фасад принимает запросы от любого клиента и просто отправляет их в веб-службы, это ничем не отличается от предоставления веб-служб непосредственно в Интернет.

Как отметил @Andrei Dragotoniu, вы должны защищать свои услуги, принимая запросы только от авторизованных клиентов.

Как разрешить доступ к веб-сервисам

Распространенным способом защиты доступа к веб-сервисам является Веб-токен JSON (JWT). Маркер содержит зашифрованные утверждения, объясняющие личность (и, возможно, другие аспекты) клиента. Обычно это работает следующим образом:

• Новый токен генерируется на сервере после успешной аутентификации клиента. Аутентификация может быть как ручной (форма входа), так и автоматической (например, с OAuth).
• Как только токен сгенерирован, он возвращается клиенту. Затем клиент начинает присоединять токен в качестве заголовка HTTP к каждому запросу, который он отправляет веб-службам. При каждом запросе веб-сервисы подтверждать прикрепленного токена.

Этот блогпост содержит дополнительные сведения и примеры использования JWT в C#.

Шлюзы API

Требование ограничить доступ к веб-сервисам внутренней сетью не редкость. Типичное решение здесь — Шлюз API.

(from Wikipedia)Gateway: a server that acts as an API front-end, receives API requests, enforces throttling and security policies, passes requests to the back-end service and then passes the response back to the requester. A gateway often includes a transformation engine to orchestrate and modify the requests and responses on the fly. A gateway can also provide functionality such as collecting analytics data and providing caching. The gateway can provide functionality to support authentication, authorization, security, audit and regulatory compliance.

Подробнее о шлюзах API в этой статье. Один из самых популярных шлюзов API — Конг.

Даже если вы развернете веб-службу в интрасети, вы не сможете использовать веб-службу из клиентского браузера (Angular или JS-приложения).

Одним из возможных решений может быть,

1. Разверните веб-службу на веб-сервере интрасети.
2. Создайте прокси-веб-службу на пограничном сервере (они как интранет, так и интернет). Прокси-веб-служба должна просто раскрывать необходимые методы, скрывая исходные веб-методы.
3. Использование прокси-веб-службы из клиентских приложений.

В противном случае клиентские приложения никогда не смогут использовать веб-службы интрасети.

При необходимости, если вы создаете веб-приложения на основе NodeJS, ASP.Net, их можно развернуть на пограничных веб-серверах, которые могут взаимодействовать с веб-службами интрасети, а пользователи (живущий в интернете) не могут напрямую обращаться к веб-службам.

Обновлено: Более того, судя по приведенному выше коду, похоже, что вы пытаетесь использовать веб-службу из управляемого кода .Net Runtime (ASP.Net MVC). Что ж, в этом случае AngularJS будет использовать ajax для вашего действия контроллера. Затем контроллер на пограничном сервере может общаться с любой веб-службой интрасети. AngularJS не нужно общаться с веб-службой. Теперь это прямолинейно.