网络上传（到云）- 一位架构师的观点
在本文中，Microsoft 安全 & 合规性架构师 Ed Fisher 介绍如何通过避免最常见的陷阱来优化云连接网络。
作者简介
我目前是零售和消费品团队的主要技术专家，专注于安全 & 合规性。 在过去的十年里，我一直与迁移到Office 365的客户合作。 我曾与小型商店合作，这些商店的地点为政府机构和企业，其用户数百万分布在世界各地，其中许多其他客户分布在其中，其中大多数有数以万计的用户，在世界各地有多个位置，需要更高级别的安全性，以及大量的合规性要求。 我帮助数百家企业和数百万用户安全可靠地迁移到云。
过去 25 年的背景包括安全、基础结构和网络工程，在加入 Microsoft 之前，我曾将两位以前的雇主转移到Office 365，我多次站在你的席上，并记住这是什么样子的。 虽然没有两个客户是相同的，但大多数客户都有类似的需求，并且当使用标准化服务（如任何 SaaS 或 PaaS 平台）时，最佳方法往往是相同的。
它不是网络 ， 这是你 (错误) 使用它的方式！
无论发生多少次，我都会惊讶于 创造性 的安全团队和网络团队如何尝试了解他们认为应该如何连接到 Microsoft 云服务。 始终有一些安全策略、合规性标准或更好的方法，他们坚持使用，而不愿意参与讨论他们试图完成的任务，或者 如何 有更好、更轻松、更经济高效、更高性能的方法。
当这种事情被升级给我时，我通常愿意接受挑战，引导他们完成如何和为什么，并让他们到达他们需要的地方。 但是，如果我完全坦率地说，我必须分享，有时我想让他们做他们会做的事，然后回来说我告诉你，所以当他们最终承认它不起作用。 我有时可能想这样做，但我 不想。 我所做的是尝试解释我将在这篇文章中包含的所有内容。 无论你的角色如何，如果你的组织想要使用 Microsoft 云服务，那么在以下方面可能有一些智慧可以帮助你。
指导原则
让我们从我们在此处执行的操作的一些基本规则开始。 我们将讨论如何安全地连接到云服务，以确保最低的复杂性和最佳性能，同时保持真正的安全性。 以下任何内容都不会与上述任何内容相反，即使你或你的客户也无法使用你喜欢的代理服务器处理所有内容。
- 仅仅因为你可以， 并不意味着你应该： 或者用伊恩·马尔科姆博士从侏罗纪公园电影“...是的，是的，但是你的安全团队非常专注于他们能否做到，他们并没有停下来考虑他们是否应该这样做。
- 安全性并不意味着复杂性：仅仅因为花费更多资金、通过更多设备路由或单击更多按钮，你就不会更安全。
- Office 365是通过 Internet 访问的：但这与Office 365 Internet 不同。 它是由 Microsoft 托管并由你管理的 SaaS 服务。 与你在 Internet 上访问的网站不同，你实际上确实可以在幕后偷看，并且可以应用满足策略和合规性标准所需的控制措施，只要你明白，虽然你可以达到目标，但你可能只需要以不同的方式执行它们。
- 扼流点是坏的，本地化的突破是好的：每个人都总是希望将所有用户的所有 Internet 流量回传到某个中心点，通常这样他们就可以监视它并强制执行策略，但通常是因为它要么比在其所有位置预配 Internet 访问更便宜，要么只是他们这样做的方式。 但这些扼流点正是...交通阻塞的点。 阻止用户浏览到 Instagram 或流式传输猫视频没有任何问题，但不要以同样的方式处理任务关键型业务应用程序流量。
- 如果 DNS 不满意，则不会一无所获：设计最好的网络可能会受到不良 DNS 的束手可及，无论是通过向世界其他地区的服务器递归请求，还是使用 ISP 的 DNS 服务器或其他缓存 DNS 解析信息的公共 DNS 服务器。
- 仅仅因为这是你过去的方式，并不意味着你现在应该这样做：技术不断变化，Office 365也不例外。 应用为本地服务或控制 Web 冲浪而开发和部署的安全措施不会提供相同级别的安全保障，并且可能会对性能产生重大负面影响。
- Office 365是为了通过 Internet 访问而构建的：简而言之就是这样。 无论你想在用户和边缘之间执行什么操作，流量在离开网络后，在进入我们的网络之前，仍会通过 Internet 传输。 即使使用 Azure ExpressRoute 将一些延迟敏感流量从网络直接路由到我们的网络，也绝对需要 Internet 连接。 接受它。 不要过度想。
经常做出错误选择的地方
虽然很多地方都以安全为名做出错误决策，但这是我与客户最常遇到的错误决策。 许多客户对话同时涉及所有这些内容。
边缘资源不足
很少有客户在部署绿地环境，并且他们拥有多年的用户工作方式和 Internet 出口情况的经验。 无论客户是拥有代理服务器还是允许直接访问，以及仅仅是 NAT 出站流量，他们多年来一直在这样做，并且不会考虑在将传统内部应用程序迁移到云时，他们将开始通过边缘抽水多少。
带宽始终是个问题，但 NAT 设备可能没有足够的马力来处理增加的负载，并且可能会过早地开始关闭连接以释放资源。 连接到Office 365的大多数客户端软件都要求持久连接，并且充分利用Office 365的用户可能有 32 个或更多个并发连接。 如果 NAT 设备过早地删除它们，这些应用可能会在尝试使用不再存在的连接时变得无响应。 当他们放弃并尝试建立新连接时，会给网络设备带来更大的负载。
本地化的分组讨论
此列表中的所有其他内容都归结为一件事，即尽快离开你的网络并进入我们的网络。 将用户流量回程到中心出口点（尤其是当出口点位于用户所在的另一个区域时），会引入不必要的延迟，并影响客户端体验和下载速度。 Microsoft 在世界各地都有接入点，前端适用于我们所有的服务和几乎每个主要 ISP 建立的对等互连，因此 在本地 路由用户的流量可确保它以最小的延迟快速进入我们的网络。
DNS 解析流量应遵循 Internet 出口路径
当然，客户端需要使用 DNS 才能找到任何终结点。 Microsoft 的 DNS 服务器会评估 DNS 请求的源，以确保我们返回响应（以 Internet 术语表示）最接近请求的源。 确保 DNS 已配置，以便名称解析请求与用户的流量发出相同的路径，以免向其提供本地出口，但发送到另一个区域中的终结点。 这意味着让本地 DNS 服务器“转到根目录”，而不是转发到远程数据中心的 DNS 服务器。 watch公共和专用 DNS 服务，这些服务可能会缓存来自世界某个地区的结果，并将它们处理给来自世界其他地区的请求。
要代理还是不代理，这就是问题
首先要考虑的事项之一是是否代理用户与Office 365的连接。 那很容易：不要代理。 Office 365是通过 Internet 访问的，但不是 Internet。 它是核心服务的扩展，应被视为此类扩展。 你可能希望代理执行的任何操作（例如 DLP、反恶意软件或内容检查）已在服务中可供你使用，并且可以大规模使用，而无需破解 TLS 加密连接。 但是，如果确实想要代理其他无法控制的流量，请关注我们的指南 https://aka.ms/pnc 和 在 https://aka.ms/ipaddrs的流量类别。 Office 365有三类流量。 “优化”和“允许”应直接执行并绕过代理。 默认值可以代理。 详细信息位于这些文档中...阅读它们。
大多数坚持使用代理的客户，当他们实际查看他们在做什么时，会意识到，当客户端向代理发出 HTTP CONNECT 请求时，代理现在只是一个昂贵的额外路由器。 使用中的协议（如 MAPI 和 RTC）甚至不是 Web 代理所理解的协议，因此即使使用 TLS 破解，你也没有真正获得任何额外的安全性。 你* 出现额外的延迟。 有关详细信息，请参阅 https://aka.ms/pnc ，包括 Microsoft 365 流量的“优化”、“允许”和“默认”类别。
最后，考虑对代理的总体影响及其相应的响应来处理该影响。 随着越来越多的连接通过代理建立，它可能会降低 TCP 规模因子，因此它不必缓冲这么多的流量。 我见过客户，他们的代理超载，以至于他们使用比例系数为 0。 由于缩放因子是一个指数值，并且我们希望使用 8，因此每次减少缩放因子值都会对吞吐量产生巨大的负面影响。
TLS 检查意味着安全性！ 但不是真的！ 许多具有代理的客户希望使用它们来检查所有流量，这意味着 TLS“中断并检查”。为通过 HTTPS 访问的网站执行此操作时， (隐私问题，尽管) 代理可能需要在几百毫秒内对 10 个甚至 20 个并发流执行此操作。 如果有大量下载或涉及视频，则其中一个或多个连接可能会持续更长的时间，但总的来说，大多数连接会非常快地建立、传输和关闭。 执行中断和检查意味着代理必须执行双重工作。 对于从客户端到代理的每个连接，代理还必须建立与终结点的单独连接。 那么， 1 变成 2， 2 变成 4， 32 变成 64...看看我要去哪里？ 对于典型的 Web 冲浪，你可能会调整代理解决方案的大小，但是当你尝试对客户端连接执行相同的操作以Office 365时，并发、长期连接的数量可能比调整大小要大几个数量级。
流式处理并不重要，只不过 是
Office 365中唯一使用 UDP 的服务是 Skype (即将) 和 Microsoft Teams 停用。 Teams 使用 UDP 进行流式处理流量，包括音频、视频和演示文稿共享。 流式处理流量是实时的，例如，使用语音、视频和演示或演示进行联机会议时。 它们使用 UDP，因为如果数据包被丢弃或无序到达，用户几乎无法察觉，流可以继续运行。
如果不允许从客户端到服务的出站 UDP 流量，则它们可能会回退到使用 TCP。 但是，如果丢弃 TCP 数据包， 则一切将停止 ，直到重新传输超时 (RTO) 过期，并且可以重新传输丢失的数据包。 如果数据包无序到达，则一切将停止，直到其他数据包到达并可以按顺序重新组合。 这两者都会导致音频中可察觉的故障 (记住 Max Headroom？) 和视频 (你单击了某些内容...哦，它) ，并导致性能不佳和用户体验不佳。 还记得我上面关于代理的内容吗？ 强制 Teams 客户端使用代理时，会强制它使用 TCP。 因此，你现在两次对性能造成负面影响。
拆分隧道可能看起来很可怕
但不是。 与Office 365的所有连接都通过 TLS 进行。 我们已经提供 TLS 1.2 相当长一段时间了，并且很快就会禁用旧版本，因为旧版客户端仍在使用它们，这是一个风险。
强制 TLS 连接（或其中 32 个）在访问服务之前通过 VPN 不会增加安全性。 它确实会增加延迟并降低总体吞吐量。 在某些 VPN 解决方案中，它甚至会强制 UDP 通过 TCP 通过隧道，这将再次对流式处理流量产生非常负面影响。 而且，除非你正在执行 TLS 检查，否则没有缺点。 客户中一个非常常见的主题是，由于大多数员工都是远程的，他们看到所有用户使用 VPN 进行连接，而不是配置拆分隧道以访问优化类别Office 365终结点，从而对带宽和性能产生重大影响。
这是一个简单的修复，可以进行拆分隧道，这是你应该做的。 有关详细信息，请确保查看使用 VPN 拆分隧道优化远程用户的Office 365连接。
过去的罪过
很多时候，做出错误选择的原因来自 (1 个) 不知道服务如何工作的组合， (2 个) 试图遵守采用云之前编写的公司策略， (3 个) 安全团队，他们可能不容易确信有多种方法可以实现其目标。 希望上面的内容和下面的链接对第一个操作有所帮助。 可能需要执行赞助才能超过第二个。 实现安全策略的目标（而不是其方法）有助于实现第三个目标。 从条件访问到内容审查、DLP 到信息保护、终结点验证到零时差威胁， 合理的安全策略可能具有的任何最终目标都可以使用 Office 365 中提供的内容来实现，并且无需依赖于本地网络设备、强制 VPN 隧道和 TLS 中断和检查。
其他时候，在组织开始迁移到云之前调整大小和购买的硬件根本无法纵向扩展以处理新的流量模式和负载。 如果确实必须通过单个出口点路由所有流量并/或代理流量，请准备好相应地升级网络设备和带宽。 仔细监视两者的利用率，因为体验不会随着更多用户加入而缓慢减少。 一切正常，直到达到临界点，然后每个人都受苦。
规则的例外
如果组织需要 租户限制，则需要使用具有 TLS 中断的代理并检查以强制某些流量通过代理，但不必强制所有流量通过代理。 这不是一个全部或全无的命题，因此请注意代理需要修改的内容。
如果要允许拆分隧道，但还要对常规 Web 流量使用代理，请确保 PAC 文件定义了必须定向的内容，以及如何为通过 VPN 隧道的内容定义有趣的流量。 我们在 中提供了示例 PAC 文件 https://aka.ms/ipaddrs ，使其更易于管理。
总结
数以万计的组织（包括几乎所有财富 500 强企业）每天使用Office 365执行其任务关键型职能。 他们这样做是安全的，他们通过互联网这样做。
无论你在发挥什么安全目标，都有一些方法可以实现这些目标，这些目标不需要 VPN 连接、代理服务器、TLS 中断和检查，或者集中的 Internet 出口，以便尽快将用户的流量从你的网络传出并传送到我们的网络，无论你的网络是否是公司总部，都能提供最佳性能， 远程办公室或该用户在家工作。 我们的指南基于如何构建Office 365服务，并确保安全且高性能的用户体验。