私下访问公共云applications（又称 SaaS）

随着企业寻求更加动态和灵活的方式来利用软件，同时确保运营稳定性、成本透明度、动态规模和敏捷性，软件即服务 (SaaS) 产品在所有行业中变得越来越普遍。

然而，在我们获得第三方提供的应用之前，我们需要准备好几个组件以使我们的用户能够访问，例如：网络连接、存储、计算（在基础层）、虚拟化、操作系统、中间件、运行时以及允许应用在服务层运行所需的一切。 只有这样，您才能进入 RBAC 配置、用户管理和向最终用户分发应用的领域。

还需要注意的是，虽然上述许多层在功能内的底层技术上正在整合和重叠，但组织通常拥有不同的团队，他们拥有自己特定层的独特流程。 通常情况下，每一层都有多个团队在运作。

本文概述了 Thad Széll（瑞银杰出工程师）和 Nuno Ferreira（Volterra 现场首席技术官）的想法和创新，使组织能够以实时、安全和私密的方式采用 SaaS应用，而不会损害和污染现有环境。 他们的重点始于 Microsoft Office 365。

众所周知，SaaS应用通常通过公共互联网访问，而第一组问题就出现在这里。 第一个基础设施问题源于这样的事实：以前的应用是在受控的、主要是静态的基础设施上，而现在它将通过互联网进行访问，而互联网是极具动态性的，不受某个特定实体的控制。

一些 SaaS 提供商能够提供专用电路（例如，Azure 提供 ExpressRoute）或 VPN，以便组织私下连接它们。 要采用这种机制，组织至少需要：

与 SaaS 提供商对等（在网络级别）并维护路由关系将 SaaS 提供商的公共 IP 地址注入/通告到企业网络中将服务视为外部网或 DMZ 并覆盖分段和安全级别如果 SaaS 提供商仅向客户提供 VPN 服务，则需要设备来构建和维护此 VPN。 请注意，这些技术并不能解决延迟问题。

拥有正向代理/NAT 设备可以解决一些安全问题，但它不能解决路由问题和将第三方公共 IP 地址注入公司网络的需要。

此外，SaaS 提供商通常极具动态性，其公布的地址、DNS 名称和发布的端点经常发生变化，因此需要建立运营机制来维护对等/注入/广告和安全控制。

因此，无需路由即可实现正向代理/NAT的解决方案更加优雅且必要。

我们以 Office 365 为例。 微软正在通过 Azure 扩大其云足迹，并且微软application服务也在日益扩展。 该平台允许大型企业拥有到 Azure 的私有、专用、高速物理链路，称为 ExpressRoute。

因此，微软可以通过允许企业员工通过此专用的私有 ExpressRoute 电路访问 Office 365 来解决上述问题（有关隐私和延迟）。

ExpressRoute for Office 365 为许多面向 Internet 的 Office 365 服务提供了备用路由路径。 ExpressRoute for Office 365 的体系结构基于将已经可通过 Internet 访问的 Office 365 服务的公共 IP 前缀公布到您配置的 ExpressRoute 线路中，以便随后将这些 IP 前缀重新分配到您的网络中。 使用 ExpressRoute，您可以有效地为 Office 365 服务启用多种不同的路由路径 - Internet 和 ExpressRoute。 网络上的这种路由状态可能代表内部网络拓扑设计和安全方式的重大变化。

好吧，也许不是那么私密。

下图描述了这种情况：

这种方法给网络和安全团队带来了三个不同的挑战：

网络路由和 NAT 企业网络基础设施团队将需要将可公共路由的 IP 空间注入其企业网络，以允许用户遵循首选路径（通过 ExpressRoute）。 此外，为了防止公司网络暴露给微软，网络团队还需要对该微软网络实施 NAT。 这不仅带来了维护与 Microsoft 的 BGP 对等（以及 NAT）的操作复杂性，而且还需要仔细规划以适应可通过将路由注入核心网络和 Internet 的专用电路提供路由的网络复杂性。 Office 365 的安全变更管理地址会不时发生变化，因此这些变化需要反映在企业的内部安全和代理基础设施中。 如果不这样做，在启用 ExpressRoute 线路时可能会导致与 Office 365 服务的连接间歇性或完全丢失。 微软提供了一份全面且定期更新的文档（和 REST API），其中列出了需要在企业安全和路由设备上配置并持续更新的域、IP 地址和 TCP/UDP 端口列表，以执行企业安全和治理政策。操作和安全可视性 NAT 设备在应用中的可视性很小甚至为零。 那么，当一切看起来都不够好时，我们该如何处理这种情况呢？

我们制定了一个优雅的解决方案，它消除了管理复杂网络基础设施和安全策略的需要，同时为员工提供了 ExpressRoute 连接的优势，以访问 Office 365 和相关应用服务。

Volterra 的集成网络和安全堆栈包括一个具有可编程代理和负载均衡功能的应用路由器，以满足这一需求。 除了这些功能之外，Volterra 还为企业发展到零信任安全提供了一条简单的途径。

从高层次上讲，企业将拥有一个 Volterraapplication网关集群，该集群与 ExpressRoute 路由器对等连接，Microsoft 在该路由器上提供 Office 365 路由/服务。 Volterraapplication网关通过此路由器自动发现 Office 365 端点，允许企业从那里访问 Office 365 服务。 这项创新使得运营商无需管理另一个流程来将动态配置转换为基础设施上的规则。 Volterra 网关自动发现创新允许客户端不断更改其请求的目的地，并且网关将对任何传入的请求触发自动发现和 TLS 完整性。

解决方案的第二部分是将这些服务公开给企业用户，而无需在企业网络内宣传微软公共路由。 可以通过两种方式实现：

第一种方法是通过 ExpressRoute 线路直接从 Azure 中的 Volterraapplication网关集群执行此操作。 请注意，注入企业网络的唯一 IP 将是 Azure 中 Volterraapplication网关集群的 IP 地址。 为了说明目的，我们假设网关位于 Azure 中，但只要满足以下 2 个条件，它就可以位于任何地方：a. 用户可以访问网关并向其发送流量（或者网关拦截它）b. 网关连接到 Office 365 端点所在/可发现的快速路由电路。 第二种方法是在公司场所（和私有 DC）内添加一个（或多个）Volterraapplication网关集群。 然后，我们将配置策略以在本地application网关群集上公开发现的 Office365 端点服务。 这些端点是通过位于 Azure 云中的 Volterraapplication网关发现的（如第一部分所述）。 此外，企业运营团队可以在加密所有流量的同时配置额外的安全和身份验证策略。 下图代表了这些场景：

Volterraapplication网关集群还实现了自动扩展功能，这意味着当一个网关超过特定阈值时，它将旋转另一个网关并将其添加到集群中。

Volterra 解决方案的其他功能也为企业网络、安全和运营团队带来了显著优势，包括：

通过集中策略和基于 SaaS 的管理实现操作简化 通过可编程数据平面实现集成/统一的代理、安全性和路由 细粒度且丰富的应用使用情况和访问的可视性、日志记录和指标 通过实现简单性和卓越运营，我们相信此解决方案是那些试图实现与 UBS 类似目标的组织的真正答案，我们可以确保使用对 SaaS 服务（例如 Office 365）的私人访问，而无需使您的公司网络“可用于公共网络，甚至是公共网络的一部分”。