本文中，Microsoft 的安全 & 合規架構師 Ed Fisher 說明如何透過避免最常見的陷阱，優化您的網路以實現雲端連接。
關於作者
我目前是我們零售與消費品團隊的首席技術專家，專注於安全 & 合規。 過去十年我一直與客戶轉用 Office 365 合作。 我曾與擁有少數據點的小型商店合作，也曾與擁有數百萬全球用戶的政府機關及企業合作，還有許多其他客戶，其中大多數擁有數萬用戶，分布於世界多個地點，對更高安全性的需求，以及繁多的合規要求。 我已協助數百家企業及數百萬用戶安全且穩妥地遷移至雲端。
過去25年來，我有資安、基礎架構和網路工程的背景，並且在加入Microsoft前曾將兩位前任轉用Office 365，我曾多次站在你們這邊，也記得那是什麼感覺。 雖然沒有兩個客戶是完全相同的，但大多數客戶的需求相似，當使用標準化服務（如任何 SaaS 或 PaaS 平台）時，最佳方法往往相同。
問題不在於網路本身——而是你 () 使用它的方式！
無論發生多少次，我總是驚訝於那些 創意 資安團隊和網路團隊如何嘗試如何連接 Microsoft 雲端服務。 他們總是堅持使用某種安全政策、合規標準或更好的方式，卻不願意與他們討論他們想達成什麼，或 如何 找到更好、更簡單、更具成本效益且更效能的方法。
當這類事情被升級到我面前時，我通常願意接受挑戰，帶他們了解怎麼做、為什麼，並引導他們達到該達到的狀態。 但如果我要完全坦白，我必須分享，有時候我真的想讓他們隨心所欲，等他們終於承認沒用時，我就回來說我早就說過了。 我有時會想這麼做，但我 不會。 我會嘗試解釋這篇文章中所有的內容。 無論你的職務為何，如果你的組織想使用 Microsoft 雲端服務，接下來的內容中或許有一些智慧可以幫助你。
指導原則
讓我們先從一些關於我們現在要做的規則開始。 我們正在討論如何安全地連接雲端服務，以確保最低的複雜度與最大效能，同時維持真正的安全性。 以下內容並不違背這些，即使你或你的客戶無法使用你喜愛的代理伺服器來處理所有事情。
- 只是因為你能，並不代表你應該：或者套用《侏羅紀公園》電影中伊恩·馬爾科姆博士的話：「...是的，是的，但你們的保全團隊太專注於是否能做到，根本沒停下來想過是否該這麼做。」
- 安全性並不代表複雜性：你不會因為花更多錢、經過更多裝置或點擊更多按鈕而更安全。
- Office 365 是透過網際網路存取的：但這並不代表 Office 365 是網際網路。 這是由 Microsoft 管理、由你管理的 SaaS 服務。 與你在網路上瀏覽的網站不同，你確實能窺見幕後，並能套用所需的控制措施來達成你的政策與合規標準，只要你明白雖然能達成目標，但可能必須用不同的方式來實現。
- 瓶頸是壞事，局部突破則是好事：大家總是想把所有網路流量回傳到某個中央點，通常是為了監控和執行政策，但更多時候是因為這比在所有地點設置網際網路便宜，或者這就是他們的做法。 但那些瓶頸正是......交通堵塞的地點。 阻止用戶瀏覽 Instagram 或串流貓咪影片沒問題，但不要用同樣的方式對待你那些關鍵的商業應用程式流量。
- 如果 DNS 不滿意，那就什麼都不滿意：即使是設計最好的網路，也可能因為 DNS 不佳而受限，無論是透過向世界其他地區的伺服器遞迴請求，還是使用你 ISP 的 DNS 伺服器，或其他用來快取 DNS 解析資訊的公共 DNS 伺服器。
- 只是因為你以前是這樣做的，不代表你現在也該這麼做：科技不斷變化，Office 365 也不例外。 套用為本地服務或控制網路瀏覽而開發並部署的安全措施，無法提供同等程度的安全保障，且可能對效能產生重大負面影響。
- Office 365 是為了透過網際網路存取而設計：簡單來說就是這樣。 無論你想在用戶和你的邊緣之間做什麼，流量一旦離開你的網路，進入我們的網路前，還是會先通過網際網路。 即使你用 Azure ExpressRoute 將一些延遲敏感的流量直接從你的網路路由到我們的網路，網路連線也是絕對必要的。 接受它。 別想太多。
那裡經常做出錯誤的選擇
雖然有很多地方會以安全名義做出錯誤決策，但這些是我最常遇到的客戶。 許多客戶對話同時涉及這些因素。
邊緣資源不足
很少有客戶會部署新環境，他們對用戶的工作方式和網路出口有多年經驗。 無論客戶是否有代理伺服器，還是允許直接存取並直接NAT出站流量，他們多年來都這麼做，卻沒考慮到隨著傳統內部應用搬到雲端，將來會開始大量流量透過邊緣處理。
頻寬始終是個問題，但 NAT 裝置可能無法承受增加的負載，可能會提前關閉連線以釋放資源。 大多數連接 Office 365 的用戶端軟體預期有持續連線，而完全使用 Office 365 的使用者可能擁有 32 個或以上的同時連線。 如果 NAT 裝置提前斷線，這些應用程式可能會因為嘗試使用已不存在的連線而失去回應。 當他們放棄嘗試建立新連線時，會讓你的網路設備負擔更重。
局部突破
這份清單上的其他所有事情歸結為一件事——盡快離開你的網路，進入我們的網路。 將用戶流量回傳到中央出口點，尤其是當該出口點位於用戶所在區域以外的區域時，會帶來不必要的延遲，並影響客戶體驗和下載速度。 Microsoft 在全球設有接入點，為我們所有服務設置前端，並與幾乎所有主要 ISP 建立對等連接，因此將用戶流量 路由本地， 確保流量能以最低延遲快速進入我們的網路。
DNS 解析流量應遵循網際網路出口路徑
當然，客戶端要找到任何端點，必須使用 DNS。 Microsoft 的 DNS 伺服器會評估 DNS 請求的來源，以確保我們回傳的回應在網路上最接近請求來源。 請確保你的 DNS 設定為名稱解析請求會沿著與使用者流量相同的路徑發送，否則你會給他們本地出口，但卻是到另一個區域的端點。 這表示讓本地 DNS 伺服器「直接進入根源」，而不是轉發到遠端資料中心的 DNS 伺服器。 同時也要注意公共和私人DNS服務，這些服務可能會將某一地區的結果快取，並提供給來自其他地區的請求。
要不要代理，這就是問題所在
首先要考慮的是是否要代理使用者與 Office 365 的連線。 這個很簡單;不要代理。 Office 365 是透過網際網路存取，但它不是唯一的網際網路。 它是你核心服務的延伸，應該被當作如此對待。 你想讓代理執行的任何功能，例如DLP、反惡意軟體或內容檢查，服務中已經提供，且可以大規模使用，且無需破解TLS加密連線。 但如果你真的想代理那些你無法控制的流量，請參考我們在 的指引https://aka.ms/pnc以及流量分類。https://aka.ms/ipaddrs 我們對 Office 365 有三種流量類別。 Optimize and Allow 其實應該直接繞過你的代理伺服器。 預設可以代理。 細節都在那些文件裡......讀讀它們。
大多數堅持使用代理的客戶，當他們實際查看自己在做什麼時，會發現當客戶端向代理發送 HTTP CONNECT 請求時，代理就變成了昂貴的額外路由器。 像 MAPI 和 RTC 這類協定甚至不是網路代理能理解的協定，所以即使有 TLS 破解，也沒有額外安全性。 你*會遇到額外的延遲。 更多相關資訊請參考 https://aka.ms/pnc ，包括 Microsoft 365 流量的優化、允許與預設類別。
最後，考慮代理權的整體影響及其相應反應以應對該影響。 隨著越來越多透過代理連線，可能會降低 TCP 的擴展因子，讓它不必緩衝太多流量。 我看過有些客戶的代理伺服器過載到用 Scale 係數 0。 由於規模因子是指數級數值，而我們偏好使用8，每減少一次規模因子的減少，都會對吞吐量產生巨大負面影響。
TLS 檢查代表安全！ 但其實也不完全是！ 許多擁有代理的客戶希望用它們來檢查所有流量，這也意味著 TLS「中斷並檢查」。當你對透過 HTTPS (隱私問題存取的網站這樣做時) 代理可能需要同時進行 10 甚至 20 個並行串流，持續數百毫秒。 如果涉及大量下載或影片，這些連線中有一個或多個可能會持續更久，但整體來說，大多數連線都能很快建立、轉移並關閉。 做 break and inspect 意味著代理伺服器必須做雙倍的工作量。 對於用戶端與代理的每次連線，代理也必須獨立連接回端點。 所以，1變成2,2變成4,32變成64......你懂我的意思吧？ 你可能已經把代理解決方案的規模設定在一般網路瀏覽時沒問題，但當你嘗試對客戶端連接到 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 連線，而不是設定分割隧道來存取 Optimize 類別的 Office 365 端點。
分割隧道是個簡單的解決方法，你應該這麼做。 欲了解更多，請務必檢視使用 VPN 分割隧道優化 Office 365 連線功能。
過去的罪孽
很多時候，做出錯誤決策的原因，是因為 (1) 不了解服務運作方式， (2) 試圖遵守採用雲端前制定的公司政策， () 資安團隊不容易相信有多種達成目標的方法。 希望以上內容和下面的連結能幫助你解決第一個問題。 通過第二個階段可能需要執行擔保。 針對安全政策的目標而非其方法，有助於解決第三個問題。 從條件存取到內容審核、資料防護（DLP）、資訊保護、端點驗證到零時差威脅——任何合理的安全政策最終目標，都能透過 Office 365 提供的資源達成，且不依賴本地網路設備、強制 VPN 隧道及 TLS 中斷檢查。
有時候，在組織開始搬遷到雲端之前就已經設計和購買的硬體，根本無法擴展以應付新的流量模式和負載。 如果你真的必須將所有流量都經過單一出口點，或是代理，請準備好相應升級網路設備和頻寬。 同時要密切監控兩者的使用率，因為隨著用戶增加，體驗不會慢慢下降。 一切都還好，直到達到臨界點，大家都會受苦。
規則的例外
如果你的組織需要 租戶限制，你需要使用帶有 TLS break and inspect 的代理，強制部分流量通過代理，但不必強制所有流量通過。 這不是全有或全無的選擇，所以要注意代理人需要修改的部分。
如果你允許分割隧道，但同時使用代理處理一般網路流量，請確保你的 PAC 檔案定義哪些流量必須直接傳送，以及如何定義通過 VPN 隧道的有趣流量。 我們提供範例PAC檔案 https://aka.ms/ipaddrs ，讓管理更方便。
總結
數以萬計的組織，包括幾乎所有財富500強企業，每天都在使用 Office 365 執行其關鍵任務。 他們是透過網路安全進行的。
無論你有什麼安全目標，都有方法可以達成，不需要 VPN 連線、代理伺服器、TLS 破壞與檢查，或集中式網路出口，讓你的用戶流量盡快從你的網路轉移到我們的網路，這樣能提供最佳效能，無論你的網路是公司總部， 遠端辦公室，或是那位在家工作的使用者。 我們的指導基於 Office 365 服務的建置方式，確保使用者體驗安全且具效能。