網路連線 (至雲端)— 一個架構設計師的觀點 (部分機器翻譯)
在本文中，Microsoft 安全性 & 合規性架構師 Ed Fisher 說明如何藉由避免最常見的陷阱，將您的網路優化以進行雲端連線。
關於作者
我目前是零售和消費者商品小組中的主要技術專家，專注於安全性 & 合規性。 過去十年來，我一直與移至 Office 365 的客戶合作。 我曾與小型商店合作過，其中有少數幾個位置可供政府機關和企業使用分散在世界各地的數百萬位使用者，以及介於其中的許多其他客戶，其中大部分都擁有數以萬計的使用者、世界各地多個位置、更高程度的安全性需求，以及許多合規性需求。 我已協助數百個企業和數百萬名使用者安全地移至雲端。
過去 25 年的背景包括安全性、基礎結構和網路工程，以及在加入 Microsoft 之前將前兩位僱主移至 Office 365，我已在數據表的您這邊停留許多次，而且請記住其外觀。 雖然沒有任何兩個客戶相同，但大部分客戶都有類似的需求，而在使用任何 SaaS 或 PaaS 平臺等標準化服務時，最佳方法通常相同。
這不是網路，這是您 (使用錯誤) 的方式！
不論發生多少次，都不會讓我覺得 有創意 的安全性小組和網路團隊如何嘗試取得他們認為應該連線到 Microsoft 雲端服務的方式，永遠不會失敗。 一律有一些安全策略、合規性標準，或是他們想要使用更好的方式，而不願意參與有關他們嘗試完成之目標的對話，或 如何 以更佳、更簡單、更符合成本效益的方式執行這項操作。
向我呈報這類事情時，我通常願意接受挑戰，並逐步引導他們瞭解作法和原因，並讓他們到達所需的位置。 但是，如果我完全坦白，我有時必須分享，我只想要讓他們執行他們將會執行的動作，然後回來說，我告訴您，當他們最後認為它無法運作時。 我有時可能會想要這麼做，但 卻不想這麼做。 我所做的是嘗試說明我將包含在這篇文章中的所有內容。 不論您的角色為何，如果您的組織想要使用 Microsoft 雲端服務，接下來的動作可能會有一些優點可協助您。
指導原則
讓我們從一些有關我們在這裡執行之動作的基礎規則開始。 我們正在討論如何安全地連線到雲端服務，以確保最小複雜度和最大效能，同時維持真正的安全性。 下列任何一項都無法與任何專案相反，即使您或您的客戶無法使用您最愛的 Proxy 伺服器來處理所有專案。
- 只是因為您可以，不表示您應該：或是將 Jurassic Park 影片中的 Dr. 因為是使用複雜密碼來將他複雜化“...是，是，但您的安全性小組非常專注於是否可以讓他們無法停止思考是否應這麼做。」
- 安全性並不表示複雜度：您不是更安全，只是因為您花費更多金錢、路由傳送更多裝置，或按下更多按鈕。
- Office 365 是透過因特網存取的：但與因特網 Office 365 不同。 這是由 Microsoft 管理並由您管理的 SaaS 服務。 不同於您在因特網上造訪的網站，您實際上可以窺視幕後，而且可以套用符合原則和合規性標準所需的控件，只要您了解雖然您可以達成目標，但您可能只需要以不同的方式執行這些動作。
- 擷取點不正確，本地化的分組是好的：每個人都一律想要將其所有使用者的所有因特網流量回溯到某個中心點，通常可以監視並強制執行原則，但通常是因為比在其所有位置布建因特網存取更便宜，或是他們的做法。 但那些死點就是這樣...流量阻塞的點。 防止您的使用者流覽至「郵件」或串流處理貓影片並沒有任何錯誤，但不會以相同方式處理您的任務關鍵性商務應用程式流量。
- 如果 DNS 不快樂，就不會有任何快樂：最佳設計的網路可能會因為不佳的 DNS 而無法運作，無論是將要求遞歸至世界其他區域的伺服器，或是使用 ISP 的 DNS 伺服器或其他快取 DNS 解析資訊的公用 DNS 伺服器。
- 因為這是您用來執行此動作的方式，並不表示您現在應該這麼做：技術會不斷變更，Office 365 也不例外。 套用針對內部部署服務開發和部署的安全性措施或控制網路流覽，並不會提供相同層級的安全性保證，而且可能會對效能造成顯著的負面影響。
- Office 365 建置成可透過因特網存取：簡而言之。 無論您想要在使用者與邊緣之間執行什麼動作，一旦流量離開您的網路並進入我們的網路之前，流量仍會通過因特網。 即使您使用 Azure ExpressRoute 將一些延遲敏感流量直接從網路路由傳送至我們的網路，還是絕對需要因特網路機能力。 接受它。 請勿過度思考。
通常會做出錯誤選擇的位置
雖然有許多地方在安全性名稱中做出錯誤決策，但這些是我最常與客戶一起遇到的決策。 許多客戶交談一次都牽涉到這一切。
邊緣的資源不足
極少數客戶會部署綠色區域環境，而且他們擁有其用戶運作方式及其因特網輸出外觀的多年經驗。 無論客戶是否擁有 Proxy 伺服器或允許直接存取，以及只允許 NAT 輸出流量，他們都已執行此作業數年，而且不考慮在傳統內部應用程式移出雲端時，他們要開始從邊緣抽取多少資源。
帶寬一律是一個問題，但 NAT 裝置可能沒有足夠的馬利來處理增加的負載，而且可能會提前開始關閉連線以釋出資源。 大部分連線到 Office 365 的用戶端軟體都需要持續連線，而完全利用 Office 365的使用者可能會有32個以上的並行連線。 如果 NAT 裝置提前卸除它們，這些應用程式可能會因為嘗試使用不再存在的連線而變得沒有回應。 當他們放棄並嘗試建立新的連線時，會在您的網路齒輪上載入更多負載。
本地化的分組
此清單中的其他一切都歸結為一件事：儘快離開您的網路並進入我們的網路。 將使用者流量回傳至中央輸出點，特別是當該輸出點位於使用者所在的另一個區域時，會造成不必要的延遲，並同時影響客戶端體驗和下載速度。 Microsoft 在全球各地都有一些存在點，其中包含我們所有服務的前端，以及幾乎與每個主要 ISP 一起建立的對等互連，因此將使用者的流量路由 傳送至 本機，可確保其能以最低延遲快速進入我們的網路。
DNS 解析流量應遵循因特網輸出路徑
當然，若要讓客戶端尋找任何端點，它必須使用 DNS。 Microsoft 的 DNS 伺服器會評估 DNS 要求的來源，以確保我們傳回最接近要求來源的因特網回應。 請確定您的 DNS 已設定，讓名稱解析要求移出與使用者流量相同的路徑，以免您提供他們本機輸出，但提供給另一個區域中的端點。 這表示讓本機 DNS 伺服器「移至根」，而不是轉送到遠端資料中心的 DNS 伺服器。 此外，watch 公開和私人 DNS 服務，這可能會快取來自世界某一部分的結果，並提供給來自世界其他區域的要求。
若要 Proxy 或不使用 Proxy，這就是問題所在
首先要考慮的事項之一是是否要將用戶的連線 proxy 至 Office 365。 這很容易;不要 Proxy。 Office 365 是透過因特網存取，但不是因特網。 這是您核心服務的延伸模組，因此應加以處理。 任何您可能想要 Proxy 執行的動作，例如 DLP 或反惡意代碼或內容檢查，都已可供您在服務中使用，而且可以大規模使用，而不需要破解 TLS 加密的連線。 但是，如果您真的想要 Proxy 無法控制的流量，請注意我們在 的指引 https://aka.ms/pnc ，以及 位於 https://aka.ms/ipaddrs的流量類別。 我們有三種類別的 Office 365 流量。 優化和允許真的應該直接移轉並略過您的 Proxy。 預設值可以是 Proxy。 這些檔案中有詳細資料...讀取它們。
大部分依賴使用 Proxy 的客戶，當他們實際查看自己正在執行的動作時，都會發現當用戶端對 Proxy 提出 HTTP CONNECT 要求時，Proxy 現在只是昂貴的額外路由器。 MAPI 和 RTC 等使用中的通訊協定甚至不是 Web Proxy 所瞭解的通訊協定，因此即使使用 TLS 破解，您也不會真正獲得任何額外的安全性。 您會收到額外的延遲。 如需詳細資訊，請參閱 https://aka.ms/pnc Microsoft 365 流量的優化、允許和默認類別。
最後，請考慮對 Proxy 的整體影響及其對應的回應，以處理該影響。 隨著透過 Proxy 建立的連線越來越多，它可能會減少 TCP 縮放因數，因此不需要緩衝處理太多流量。 我已看到客戶的 Proxy 超載，因此他們使用的縮放比例為 0。 由於 Scale Factor 是指數值，而且我們想要使用 8，因此 Scale Factor 值的每個縮減都會對輸送量造成極大的負面影響。
TLS 檢查表示安全性！ 但不是真的！ 許多具有 Proxy 的客戶都想要使用它們來檢查所有流量，這表示 TLS 會「中斷並檢查」。當您針對透過 HTTPS 存取的網站執行此動作時， (隱私權考慮，儘管) 您的 Proxy 可能必須在數百毫秒內針對 10 或甚至 20 個並行串流執行此動作。 如果涉及大量下載或影片，則其中一或多個連線可能會持續更長的時間，但整體而言，大部分的聯機會非常快速地建立、傳輸和關閉。 執行中斷和檢查表示 Proxy 必須執行雙倍的工作。 針對從用戶端到 Proxy 的每個連線，Proxy 也必須建立與端點的個別連線。 所以，1 變成 2,2 變成 4,32 變成 64...請參閱我要去哪裡？ 針對一般網路流覽，您可能可以調整 Proxy 解決方案的大小，但是當您嘗試對用戶端連線執行相同的動作以進行 Office 365 時，並行、長時間存留的連線數目可能會是大於您調整大小的順序。
串流並不重要， 只是它是
在使用 UDP 的 Office 365 中，唯一的服務是即將淘汰) 和 Microsoft Teams 的 Skype (。 Teams 會使用 UDP 來串流流量，包括音訊、視訊和簡報共用。 串流流量是即時的，例如當您有語音、視訊和簡報簡報或執行示範的在線會議時。 這些會使用 UDP，因為如果封包已卸除或依序送達，使用者實際上無法看見，而且數據流可以繼續進行。
當您不允許從客戶端到服務的輸出 UDP 流量時，它們可以切換回使用 TCP。 但如果卸除 TCP 封包， 一切都會停止 ，直到重新傳輸逾時 (RTO) 過期，而且可以重新傳輸遺漏的封包。 如果封包未按順序送達，所有項目都會停止，直到其他封包到達為止，而且可以依序重新組合。 兩者都會導致音訊中容易察覺的故障 (記住 Max Headroom？) 和視訊 (您是否按下某個專案...詛，有) ，導致效能不佳和用戶體驗不佳。 還記得上面關於 Proxy 的內容嗎？ 當您強制 Teams 用戶端使用 Proxy 時，您會強制它使用 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 中斷和檢查有任何相依性。
其他時候，組織開始移至雲端之前已重設大小併購購買的硬體，就無法相應增加以處理新的流量模式和負載。 如果您真的必須透過單一輸出點和/或 Proxy 路由傳送所有流量，請準備據以升級網路設備和頻寬。 仔細監視這兩者的使用率，因為體驗不會隨著更多用戶上線而緩慢降低。 在到達臨界點之前，一切都沒問題，然後每個人都會受到影響。
規則的例外狀況
如果您的組織需要 租使用者限制，您必須使用具有 TLS 中斷和檢查的 Proxy 來強制某些流量通過 Proxy，但您不需要強制所有流量通過它。 這不是全部或全無主張，因此請注意 Proxy 需要修改的內容。
如果您要允許分割通道，但也針對一般 Web 流量使用 Proxy，請確定您的 PAC 檔案會定義哪些項目必須直接進行，以及如何定義通過 VPN 信道的有趣流量。 我們提供 PAC 檔案 https://aka.ms/ipaddrs 範例，讓您更容易管理。
總結
數以萬計的組織，包括幾乎所有的 500 家，每天都會使用 Office 365 來執行其任務關鍵性功能。 他們會安全地執行此動作，並透過因特網執行此動作。
無論您有哪些安全性目標，有一些方法可以完成這些目標，而不需要 VPN 連線、Proxy 伺服器、TLS 中斷和檢查，或集中式因特網輸出，讓使用者的流量從您的網路中取出，並盡可能快速地進入我們的流量，無論您的網路是公司總部，都能提供最佳效能。 遠程辦公室，或在家工作的使用者。 我們的指引是根據如何建置 Office 365 服務，並確保安全且高效能的用戶體驗。