如果要在 DMZ 中托管且不能直接访问数据库（防火墙阻止 tcp 端口 1433），如何设计 ASP.NET MVC Web 应用程序的层？

Posted 2023-05-07

【中文标题】如果要在 DMZ 中托管且不能直接访问数据库（防火墙阻止 tcp 端口 1433），如何设计 ASP.NET MVC Web 应用程序的层？

【英文标题】：How to design tiers of ASP.NET MVC web application if it is to be hosted in DMZ with no direct access to database (tcp port 1433 blocked by firewall)?

【发布时间】：2018-07-05 13:59:17

【问题描述】：

考虑以下网络安全设置：

       Users         Internet
         |        
  ====Firewall==== Port 80, 443 only
         |              
     Web Server      DMZ - ASP.NET MVC + Web API
         |          
  ====Firewall==== Port 80, 443 only
         |         
     "App" Server   WCF or ASP.NET Web API ??
         |           
      Database      Internal network

我在许多客户端都看到了上述网络设置。 IT 基础架构团队不允许 DMZ 中的 Web 服务器通过端口 1433 与托管在内部网络中的 SQL Server 建立直接连接。具有讽刺意味的是，我看到 web.config 位于 Web 服务器上，并带有纯文本 DB 密码，它们是好的。

通常我已经看到并研究过 WCF 托管在“应用”服务器上的解决方案（因为它可以在 HTTP 端口上使用），如图所示。 WCF 成为 Web 前端与 DB 交互的唯一方式。使用 WCF 的一个“好处”是它返回易于从 ASP.NET MVC 前端使用的强类型对象。

问题：

使用 WCF 是因为它允许在 80 或 443 上传输数据并返回强类型对象。这是一个不错的选择吗？ 应该改用 ASP.NET Web API 吗？如果是这样，如何使用复杂的对象图实现强类型化？ JSON.net 和内置序列化程序是否足以胜任这项工作？ 有更好的解决方案吗？

请注意，我们目前无法使用 ASP.NET Core。

由于这是一个反复出现的问题，如果有比使用 WCF 更好的解决方案，我真的很想听听社区的意见。

【问题讨论】：

如问题中所述，ASP.NET Core NOT 是一个选项。 WCF 不能与二进制协议一起使用，因为它需要端口除了 80，这正是我问这个问题的原因。我们只能将 SOAP 与 WCF 一起使用，它还是 HTTP，正如您所说的“更慢”，与 Web API 非常相似。

当我说您没有提供任何可以帮助您选择其中一个的要求时，这正是我的意思。可以使用 SOAP 或 REST 构建多层应用程序。一样容易。如果你需要 SOAP（为什么？）你不能使用 Web API。如果没有，则没有足够的信息可供选择。

当然跟负载均衡和高可用性有关。你问的与端口限制无关。你在问错误的问题。多层应用程序每层可以有 多个 机器。可以有多个前端网络服务器。可以有多个个后端应用服务器。通常，您需要两者中的两个来确保高可用性。

我不是在谈论您发布的内容 - 没有足够的信息。您甚至没有说为什么您考虑使用 WCF。我说的是你需要考虑什么才能做出决定。安全性、API 版本控制、可靠性、标准、易于部署、易于维护。缓存 - SOAP 只使用 POST，所以缓存是hard。 REST (Web API) 仅使用 POST 来修改数据，使用 GET 来检索数据，这使得缓存变得轻松。

您可以将 ASP.NET MVC 应用程序托管在 APP 服务器层。然后在WEB服务器层，使用IIS设置反向代理。

【参考方案1】：

我刚刚做了一个同样问题的系统，数据库访问仅限于应用服务器。

我们选择采用的方法是一个 Mvc 前端和一个托管在 App Server 上的 Web Api 后端。

为了获得您通常可以通过 WCF 获得的强类型，我们选择了一个名为 Refit 的工具：https://github.com/paulcbetts/refit。它允许您将带有预配置 url 模板的接口转换为可以通过普通 DI 容器注入的对象，使其非常可测试并删除大量样板 HttpClient 代码。这与 WebApi 后端配合得非常好。

【讨论】：

Web API 也提供强类型。动作参数可以是字符串或 compelx 对象。 Refit 为 WSDL 和代理生成器提供了替代方案。

感谢您的回答，我将探索这个选项。

【参考方案2】：

将IIS Reverse Proxy 构建到您的 DMZ 区域，您不需要两台单独的服务器（网络+应用程序）。当反向代理将所有相关流量路由到您的 Web 服务器时，您可以在内部网络中运行它。

    Users           Internet
     |        
====Firewall====  Port 80, 443 only
     |              
IIS Reverse Proxy     DMZ 
     |          
====Firewall====  Port 80, 443 only
     |         
  Web Server        ASP.NET MVC
     |           
  Database       Internal network

【讨论】：

谢谢，我在问这个问题之前探索了这个选项。我已要求我的基础架构团队考虑此选项。但是，根据我过去与他们的经验，他们不太可能做出任何更改，因此我正在为当前的网络设置寻找最佳解决方案。

如您所见，无需更改网络设置。防火墙和网段保持不变，因为反向代理在与专用网络中的实际 Web 服务器通信时可以使用这些公共端口 (80,443)，但当然，如果出于某种原因需要，您也可以更改端口。使用反向代理，实现起来要容易得多，因为您不需要实现自己的软件代理层。当然，反向代理配置可能有它自己的挑战（使用 gzip 编码等），但网络中有大量的指导和支持。

我同意，但 Infosec 团队也必须同意。

好的，我们希望有一天您的信息安全团队会发现这个答案被接受，然后他们会说服自己:) 但是，是的，如果有一些确切的功能或安全性，我可以尝试找到更多的论据-反向代理配置指出的相关问题。

【参考方案3】：

我会做以下设置：

          Users         Internet
                   |        
            ====Firewall==== Port 80, 443 only
                   |              
         Proxy/load balancer with URL pattern rules 
            |                    |
http://foo.com/api/...        http://foo.com/ui/...
            |                    | 
            |          static content server 
            |
            |          
     ====Firewall==== Port 80, 443 only
            |         
        "App" Server   ASP.NET Web API 
            |           
         Database      Internal network

静态内容服务器可能是 MVC 应用程序，无需访问 DB URL 模式规则可能会被替换为不同的域（例如 foo.com 和 api.foo.com）