SAP Web Dispatcher 架构布局_webdispatcher-CSDN博客

由 SAP 维护和支持；
支持多个操作系统；
遵循与 SAP NetWeaver AS ABAP/Java 的 Internet 通信管理器（ICM）相同的配置原则；
可以轻松地通过 SAP Solution Manager 或 SAP Focused Run 进行监控；
无需额外的许可费用。

总之，它能够很好地融入现有的 SAP 架构中——无论是本地部署还是在超大规模云服务提供商环境中。

更新：

2021年11月8日：添加了关于 SAP Web Dispatcher 嵌入式部署的 SAP 技术说明 3115889 的链接。
2021年10月15日：增加了一节描述如何使用 SAP Web Dispatcher 安全地集成不支持最新协议或强密钥套件的遗留设备。

SAP Web Dispatcher 的功能

有多种原因可能使我们希望或需要在 SAP 架构中部署 SAP Web Dispatcher 作为反向代理。

其中一些原因包括：

实现（有状态的）负载均衡（这是消息服务器无法做到的）
创建单一入口点（因为客户端书签可能会导致使用消息服务器进行负载均衡时出现问题）
在后端不可用时显示维护页面
修改报头
实现跨源资源共享（CORS）设置
网页缓存
向客户端启用 HTTP/2（如果旧的后端不支持它）

一些更专注于安全性的原因包括：

防止直接访问 SAP NetWeaver 的 ICM 或 SAP HANA 的平台路由器
终止 TLS 连接（取决于您的安全团队的理念）
执行 URL 过滤
执行 URL 重写（隐藏来源）
修改特定的安全相关报头
过滤某些 HTTP 方法/动词
防止分布式拒绝服务（DDoS）攻击
防止慢速拒绝服务（Slowloris）攻击
执行网络边缘认证（NEA）
为遗留设备提供通信中间件，以尽可能缩短弱加密（甚至未加密）流量的距离

在明确了引入 SAP Web Dispatcher 所需达到的目标之后，我们需要考虑目标架构布局。换句话说，我们需要考虑在架构中何处部署 SAP Web Dispatcher。

我快速浏览了一些关于 SAP Web Dispatcher 的博客文章。虽然找到了许多有价值的博客深入讨论了某些配置细节，但我没有发现任何文章涉及这个重要的总体话题。在下面，我列出了一些选项，并对每个选项指出了我认为存在的问题。

请注意，这里我只是举了一些例子，实际上可能存在许多种组合或变化形式。

截至撰写之时，还没有官方支持将 SAP Web Dispatcher 部署在容器中（参见 SAP 技术说明 1122387），所以我没有考虑这样的设置。

SAP Web Dispatcher 的部署选项

现在让我们仔细看看我们可以将 SAP Web Dispatcher 作为反向代理放置在哪里，以便服务于我们的 SAP 后端系统之一。请注意：图中使用 SAP NetWeaver（AS ABAP 和 AS Java）作为后端，但几乎所有内容也适用于 SAP HANA XSA（以及大多数情况下已弃用的 SAP HANA XS Classic）作为后端。

（一）SAP Web Dispatcher 在 SCS 实例中的嵌入式部署

这一部署选项是指在 (A)SCS 实例中的嵌入式/集成 SAP Web Dispatcher。这意味着 SAP Web Dispatcher 作为 SCS 实例的一部分运行在同一进程或紧密相关的进程中。具体操作方法可以在 SAP 技术说明 2771578 中找到。

SAP 技术说明 3115889 提供了选择独立部署还是嵌入式部署的指导

在这个场景中我们可以识别出的问题包括：

SAP Web Dispatcher 进程以<sapsid>adm身份运行。我们不应该将 SAP NetWeaver 系统的这个高权限账户暴露于额外的风险之中。
它与 ASCS 共享资源，在许多场景下还与（主要）应用服务器共享资源。我们不应将 SAP NetWeaver 的单点故障暴露于额外风险中（例如，来自 DDoS 攻击的风险）。
在许多场景下，它还与（主要）应用服务器共享资源。
它没有位于单独的网络或防火墙区域（Demilitarized Zone, DMZ）。我们不应引入横向移动的可能性。
它与 SAP NetWeaver 及其底层操作系统共享维护窗口。

SAP 只推荐在特殊场景下采用此选项（但并未详细说明“特殊场景”具体指什么）。

（二）带有独立 SAP Web Dispatcher 的 SCS 实例

接下来合乎逻辑的另一个部署选项是在 (A)SCS 实例的主机上设置一个独立的 SAP Web Dispatcher。

在这个场景中我们仍然可以识别出的问题包括：

SAP Web Dispatcher 与 ASCS 共享资源，在许多场景下还与（主要）应用服务器共享资源。
它没有位于单独的网络或 DMZ区中。
它与 SAP NetWeaver 的操作系统共享维护窗口。

（三）单独的独立SAP Web Dispatcher

最后的考虑可能是在一个单独的主机上设置一个独立的 SAP Web Dispatcher。

从安全角度来看，这是首选的架构。

SAP Web Dispatcher 进程以其自己的 <sid>adm 身份运行。
它不与后端系统共享资源。
它——或者至少应该——位于一个单独的网络或 DMZ 中。
它有自己的维护窗口。

为了进一步提高安全级别，

SAP Web Dispatcher 可以作为一个高可用集群来部署（见下文）。
可以配置反向调用以避免在后端系统上打开防火墙以允许传入连接。

将 SAP Web Dispatcher 集成到一个系统架构中

由于 SAP 系统架构通常由两个或更多系统组成（如开发、沙箱、质量保证、集成测试和生产系统），下一步我们必须考虑如何将所有这些系统纳入我们的规划中。

（一）单一独立的独立 SAP Web Dispatcher 安装

那么，让我们从最简单的架构开始。

我们可以识别出的问题包括：

对 SAP Web Dispatcher 的攻击可能影响整个 SAP 系统架构。当 SAP Web Dispatcher 暴露在互联网上时，这种情况更加糟糕。
生产系统与非生产系统的流量之间没有分离。
生产系统和非生产系统的证书存储可被同一个操作系统用户访问。
SAP Web Dispatcher 的维护窗口会影响所有后端系统的可用性（至少在 SAP Web Dispatcher 不是高可用的情况下）。
配置的复杂度随着所连接后端数量的增加而增加

（二）多个独立的独立 SAP Web Dispatcher 安装

在下一个部署选项中，我们将生产环境与非生产环境分开。

通过这样做，我们实现了以下几点：

将生产系统与非生产系统的流量分离开来。
将生产系统与非生产系统的证书管理分离开来。
非生产 SAP Web Dispatcher 的维护窗口不会影响生产后端的可用性，反之亦然。
配置的复杂度降低。

为了进一步提高安全级别：

我们可以将至少生产环境的 SAP Web Dispatcher 设置为高可用集群。
我们可以设置两个或更多的 SAP Web Dispatcher 安装作为由额外负载均衡器前端的主动/主动集群。这样我们还可以防止使用 extbind（以提升的权限运行）绑定端口<1024，同时在端口443上为客户端提供服务。
反向调用可以被配置以避免在后端系统上为传入连接打开防火墙。

非生产环境的 SAP Web Dispatcher 可以为每个后端（如 INT/QAS 和 DEV 等）进一步拆分，

可以测试网络应用，例如它们在负载均衡、URL 重写方面的表现，
可以在实施到生产环境之前验证安全措施。

将 SAP Web Dispatcher 集成到多个（独立的）系统架构中

当我们环境中存在多个（独立的）SAP 系统架构时，我们可能会考虑到成本节约的问题。因此，我们可能会考虑优化并设计出一种架构，让多个架构共享一个 SAP Web Dispatcher。

（一）一个 SAP Web Dispatcher 服务于多个后端

如果我们仍然希望将生产系统与非生产系统的流量分开，我们可以考虑将同一分类的多个后端连接到一个 SAP Web Dispatcher 上。

我们可以识别出的问题包括：

对 SAP Web Dispatcher 的攻击可能影响整个 SAP 系统架构。当 SAP Web Dispatcher 暴露在互联网上时，这种情况更为严重。
生产系统与非生产系统的流量之间没有分离。
生产系统与非生产系统的证书存储可被同一个操作系统用户访问。
SAP Web Dispatcher 的维护窗口会影响所有后端系统的可用性（至少在 SAP Web Dispatcher 不是高可用的情况下）。
随着连接的后端数量增加，配置的复杂度也会增加。

（二）多个独立的独立 SAP Web Dispatcher 安装

在下一个部署选项中，我们将生产环境与非生产环境分开

通过这样做，我们实现了以下几点：

分离了生产系统与非生产系统的流量。
分离了生产系统与非生产系统的证书管理。
非生产环境的 SAP Web Dispatcher 的维护窗口不会影响生产后端的可用性，反之亦然。
配置变得更加简单。

为了进一步提高安全级别：

我们可以将至少生产环境的 SAP Web Dispatcher 设置为高可用集群。
我们可以设置两个或更多的 SAP Web Dispatcher 安装作为由额外负载均衡器前端的主动/主动集群。这样我们还可以防止使用 extbind（以提升的权限运行）来绑定端口<1024，同时在端口 443 上为客户端提供服务。
反向调用可以被配置以避免在后端系统上为传入连接打开防火墙。
非生产环境的 SAP Web Dispatcher 可以为每个后端（如 INT/QAS 和 DEV 等）进一步拆分。
可以测试网络应用，例如它们在负载均衡、URL 重写方面的表现。
可以在实施到生产环境之前验证安全措施。

将 SAP Web Dispatcher 集成到多个（独立的）系统架构中

（一）一个 SAP Web Dispatcher 服务于多个后端

如果我们仍然希望分离生产系统与非生产系统的流量，我们可以考虑将同一类别的多个后端连接到一个 SAP Web Dispatcher 上。

我们可以识别出的问题包括：

对 SAP Web Dispatcher 的攻击可能影响多个系统架构。当 SAP Web Dispatcher 暴露在互联网上时，这种情况尤为严重。
多个证书存储可被同一个操作系统用户访问（尤其是在 TLS 再加密或多个域通过 SNI 地址访问时）。
SAP Web Dispatcher 的维护窗口会影响所有生产或非生产后端的可用性（除非 SAP Web Dispatcher 被设置为高可用集群）。
配置的复杂度随着连接的后端数量增加而增加。

请注意：在某些场景中，这种架构是不可避免的。例如，如果后端是 SAP Fiori 门户（ABAP 前端）和 SAP Fiori 搜索（ABAP 后端），或者是 SAP NetWeaver ABAP 和 SAP HANA XS，或者是 SAP NetWeaver AS ABAP 和 SAP Analytics Cloud - 实时数据连接。