企業的效益與挑戰 — 多雲端平台Part4

多雲架構的高可用度與資訊安全服務

在本系列文章的part 2 and part3 文章中，我們介紹了核心和邊緣的多雲安全，但還有其他多雲安全案例需要我們更深入地探討。 本文會描述的一些案例並且是不適用於每個種的多雲設置。 但重要的是要意識到它們的存在，以防它們變得有相關。

本文描述的每個案例是在針對提高雲端的可用性(availability)、減少我們的Application或減輕 DDoS 攻擊的威脅。

DNS的服務韌性與流量引導

當我們談論保護多雲架構的邊緣網路時，需要從 DNS 開始。 令人驚訝的是，很多人使用 DNS 來加強多雲環境的安全性通常是事後才想到的，或者根本沒有想到。 但是高品質的 DNS 基礎設施可以提供許多安全增強功能。

選擇 DNS服務商很重要，因為如果沒有可靠的 DNS，我們的應用程式將無法被access。 合適的 DNS 服務商可以通過提高韌性和優化流量管理來增強 Web application的安全性。

DNS的服務韌性

正確的 DNS 架構可以通過多種方式提高多雲架構的韌性。第一種是在不同的網路和不同的服務商平台上託管Primary DNS NS(name server)和secondary DNS NS。註冊新域名時，網域註冊商會要求提供NS list。大多數人使用預NS。也可能使用其他DNS 服務商的NS。

但是 DNS 協定允許有Primary和secondary NS。Primary NS是託管Zone file的Authoritative NS，該檔案包含domain或subdomain的相關資訊。Secondary NS會從Primary NS自動接收update，並且不需要放在同一網路上(就是可以不用是同一個服務商)。事實上，強烈建議在不同的網路上託管Secondary NS。這增加了 DNS 設置的韌性，意味著即使主要服務商服務掛掉，Secondary NS服務仍能繼續提供服務。

DNS 服務商提高韌性的第二種方式是在其Authoritative NS上實施anycast protocol。 Anycast 是一種路由協議，通常由 DNS 服務商實施（不過沒有每一家都這樣），這樣做可以提高服務的“可用性並加快對 DNS 查詢的回應”。 Anycast protocol允許多個地理上不同的服務器共享同一個的 IP addrerss。 例如，每個recursive server上的“hints”檔案指向 13 台root server，但這 13 台服務器實際上掩蓋了分散在世界各地的 600 多台服務器。 每個root server的 IP 地址是多個服務器的anycast address。

在選擇或變更 DNS 服務商時，重要的是要確定用在我們域名的Authoriative DNS 服務器是否位於Anycast IP addrrss後面。 Anycast 不只是作為一個force multiplier，它實際上通過使用現有的路由協議來幫助加快回應速度，以確保對 IP address的request由最近的網路服務器完成。 使用anycast的 DNS 服務商不僅僅通過在一個anycats address後面擁有多個 DNS 服務器來增加韌性。 它們還通過確保離客戶端最近的DNS服務器滿足每個request來提高效能。

DNS流量轉向

前面討論的 DNS 韌性特質是要內建於 DNS服務 中，可幫助 DNS 在大規模部署中有效工作。 但是有些 DNS 服務為附加組件加上了一些功能，但這些功能沒有內建到 DNS protocol中。 這並不意味著這些功能對安全的價值或重要性降低。 這只是意味著只有少數的DNS服務商有這些功能。

這些加強功能中的大多數都圍繞著流量轉向，即基於先前定義的一組規則在多雲架構中的不同站台之間重定向DNS request的過程。 DNS 具有獨特的地位，因為它是從 Web Application request 網頁內容的過程中的第一步。 因此，在DNS layer是實施流量導向規則的是明智的做法。

例如，已經使用多雲解決方案的企業會將添加一個新站台後希望將其整個web service簡化為rotation的方式，以確保新站與其他站台加入整體服務的韌性。 在這種情況下，企業可能會進行具有流量導向功能的 DNS 服務將 30% 的流量發送到新站台。

一種更常見的方法是使用 DNS 服務商對我們的web服務執行運作狀況檢查，然後回應 從客戶端來的DNS request該到哪一個站台去。 在這種類型的流量轉向設定中，DNS 服務商會持續監控所有 Web site的健康狀況，無論它們託管在哪裡。 如果CSP中的站台停止回應health check，DNS 服務將不再將 DNS request導向到該CSP，直到它再次有回應。

以這種方式使用 DNS 不如使用負載均衡器可靠，但它的成本效益要高得多。網站用戶將能夠不間斷地訪問 Web application，即使在CSP的資料中心發生重大中斷時也是如此。

最後，一些 DNS 服務商能夠使用流量轉向來最大化 Web application的效能。效能優化可以採取多種形式。一種常見的效能優化類型是基於地理位置資訊的流量來導向。在多雲環境中，企業可能在數十個甚至數百個區域運作相同的 Web application。 DNS 服務商可以優化導入的 DNS request並將用戶轉送到最近的CSP。例如，假設多雲架構設置在新加坡、孟買、倫敦和東京的資料中心，並且 DNS request來自台灣的某個位置。具有流量導向功能的 DNS 服務商可以將該request 導向到東京的資料中心。

我們可以使用這些相同的技術來確定擴展雲端架構的潛在新位置。例如，如果 DNS 服務商開始記錄來自香港的越來越多的 DNS requests，並且這被證實是一種成長趨勢，那麼可能是時候考慮擴展到在香港有資料中心的CSP了(雖然CDN可以解決這一個問題)。

同樣，這些功能本質上不是 DNS 服務的一部分，並且並非所有 DNS 服務商都支援它們。 如果我們的 DNS 服務商確實支援這些額外功能，這些功能可以幫助加強我們的多雲架構的安全性和可用性。

與我們的DNS服務商合作強化安全性

DNS 服務商可以為 Web application提供額外的security layer。 但是我們需要注意 DNS hijacking的威脅。 這是一個如此大的問題，以至於 ICANN 發布了有關威脅的警告。 使用 DNS 為雲端基礎設施加上一層安全性非常重要。 但企業也應該確保與 DNS 服務商的通訊安全。 需要對我們自己企業當前註冊的每個域名立即採取以下預防措施：

• 對企業已註冊的所有域名進行分配編排。
• 在域名註冊商的服務上啟用MFA。
• 鎖定域名，使其無法轉移或更新。
• 為所有域名啟用DNSSEC。
• 定期測試以確保資安政策有被遵守。

域名註冊商應被視為潛在攻擊面的一部分，因此務必採取措施確保域名安全。

機器人管理(Bot Management)

運作互聯網 Web application無疑會遇到機器人問題。 機器人是在互聯網上自動化活動的程序。 有些機器人是有正面功用的，例如 Google 的搜索爬蟲，而其他機器人則從事惡意活動。 而惡意機器人佔接近多數的所有網站流量。

惡意機器人活動範圍廣泛，從資料竊取和自動化的網站劫持到 DDoS 攻擊。 我們將在後面的部分討論 DDoS 預防。 現在，讓我們專注於防止機器人竊取資訊或劫持服務。

企業經常使用機器人來瞄準競爭對手的網站並收集定價訊息以確保他們的價格更低。 儘管這些簡單的機器人大多很煩，但更高階的機器人可用於造成嚴重損害。

例如，機器人通常以航空公司和飯店預訂網站為目標。 這些機器人會去預訂航班或飯店，使一般客戶無法進行預訂，並迫使這些客戶去找競爭對手。 然後，機器人會取消預訂，或者只是讓他們的購物車過期，從而使航空公司或飯店網站損失數百萬美元的收入。

其他機器人參與了更多的惡意活動。 這些機器人掃描數以億計的網站，尋找要利用的特定缺陷。 這可能是 XSS 攻擊，或者他們可能正在掃描具有常見應用程式（如 WordPress ）的的站台，而這些站台都還是舊版本容易受攻擊。 在找到易受攻擊的站台後，他們將利用它並竊取敏感資訊或安裝惡意軟體或form-jacking script來攔截信用卡資料。

不幸的是，無論我們的網站多麼安全，仍然有可能受到這些機器人的攻擊。 隨著成千上萬的機器人全天候掃描互聯網，我們的安全性需要完美無缺。 但壞人只需要幸運的成功一次。

任何規模的多雲架構都需要cloud-based bot mitigation solution。 在惡意機器人有機會與 Web application交互之前阻止它們，可以使 Web 服務對客戶端還是正常的。 與自己刻的方法相比，外包的機器人保護服務還具有幾個優勢。

對於菜鳥來說，因為這些外包服務商已經看到了數千個機器人，所以外包服務商能夠比我們自己嘗試更早的偵測到機器人流量。 外包服務商有效地識別模式，因為他們正在監視所有客戶的機器人流量跡象，而不是只有我們。 外包服務商甚至可以偵測以“low and slow”模式運行的機器人流量，通過不經常訪問目標 Web application以及從設計為看起來無害的 IP 地址範圍來規避偵測。

這些服務還可以尋找潛在的可疑流量，同時在合法流量還是運作正常的情況下不會中斷服務。 網站管理此類行為的一種方法是使用驗證碼(CHPTCHAs)，這是主要在區分人類和機器人的小問題。 類似這樣一個問題，“這些照片中有多少張有紅綠燈？” 或“有多少圖片包含腳踏車？” 。

不幸的是，機器人在解決驗證碼方面做得非常好 — — 有些機器人比很多人類更擅長。 Bot Management Service會嘗試使用 JavaScript challenges和其他查詢瀏覽器的方法來區分人類和機器人，而不是依靠錯誤的驗證碼來區分人類和機器人。 因為機器人背後沒有完整的瀏覽器，它們幾乎總是在這些類型的驗證方式中失敗。

Bot Management Service可以顯著減少會連接到我們 Web application的惡意爬蟲程式流量。 Cloud-based Bot Management Service可以在多雲架構中快速部署，我們可以在多雲環境中擴展或縮減服務時很容易的添加或刪除它們。

API的保護

在本系列文章的part 3文章中，我們討論了 API 在多雲架構中的重要性。 API 用於連接在多雲環境中運行的所有不同服務，對於從一個來源獲取資訊到另一個來源並以統一的方式將其呈現給客戶端至關重要。

這就是 API 保護如此重要的原因。 駭客已經意識到 API 可以是他們可以拿到敏感資料的寶庫。 因此，這些惡意行為者一直在尋找探索 API弱點 的方法，包括使用機器人。

API保護技術涵蓋了多個領域：

• 限制誰或什麼可以access APIs.
• 限制某一段時間或某一時間區間的資料取出量
• 確保通過 API 傳輸的所有資料都經過適當加密

可以使用 API gateway和 WAF 的組合來進行保護。 這意味著 API 不一定需要對新技術進行投資。 企業只需要正確的使用 API gateway和 WAF 功能。 讓我們仔細看看確保 API 保護的過程。

在大多數情況下，人類永遠不應該直接asccess API。 API 主要用編碼方式將資訊從一個系統帶到另一個系統。 第二個系統將呈現資訊並以人類可以理解和使用的方式表現出來。 應該客戶端應該被自動的阻絕在直接進行API 呼叫，並且這些API呼叫應該只來自作為多雲架構一部分的授權系統或來自可能也在查詢您的後端系統的受信任的合作夥伴。

客戶端被限制直接進行 API 呼叫，但他們仍然可以找到操作有被授權系統進行惡意 API 呼叫的方法。 這就是為什麼僅限制哪些系統可以呼叫API是不夠的。 API呼叫本身也應該受到返回資料的數量和類型的限制。

例如，來自面向互聯網 API call絕不應該洩露多個用戶名和密碼。 此外，不應該有辦法從面對互聯網的系統中get到所有客戶姓名和電子郵件地址。 使用 API gateway來做access control並在 WAF 上建立特徵集以阻擋這些類型的查詢可以防止發生資料洩漏，即使 API 無意中曝露到互聯網。

我們還可以使用 API gateway和 WAF 在 API 通訊中強制實施加密。 大多數 API 通訊應使用TLS加密進行。 如果由於某種原因，API 本身未加密，則可以強制這些未加密的流量走VPN，以提供具有某種加密級別的通訊。

API 是多雲架構的關鍵組件。 安全地部署 API 並確保通過 API 呼叫在不同系統之間共享的資料受到保護需要大量計劃。

Application-Layer DDoS Protection

DDoS 攻擊是任何面向互聯網的 Web Application的企業都必須面對的現實。 DDoS 攻擊可以不管有沒有理由隨時對任何企業發起攻擊。 防範這些攻擊應該是我們計劃中的一部分。

本文重點關注兩種 DDoS 攻擊：Application-layer DDoS 攻擊和Network-layer DDoS 攻擊。

顧名思義，Application-layer DDoS 攻擊針對特定的 Web Application或 API，耗盡L7資源，這樣一來也讓一般用戶無法訪問服務。 Network-layer DDoS 攻擊使整個網路充滿流量，使我們的CSP的所有資源耗盡，而不僅僅是特定的 Web Application或服務。

Application-layer DDoS 攻擊通常更難偵測和阻擋，因為攻擊者正在發出合法的 HTTP request。因此，對流量進行分類並將攻擊者的request與正常的request分開可能是一個挑戰。

有多種方法可以實現有效的Application-layer DDoS 保護。最常見的方法是使用 WAF 在惡意request到達 Web application之前阻止它們。這需要實施一個可以處理大量流量而不減慢正常request的 WAF。

它還經常涉及理解每次攻擊的性質。 DDoS 攻擊的本質意味著攻擊是分佈式的 (distributed)— — 源自數千或數十萬個 IP address。至少一開始看，這些攻擊還可以與合法流量混在一起。幸運的是，Application-layer DDoS 攻擊通常具有不同的特徵。這些功能允許資安團隊建立可以部署到 WAF 的特徵集，並在不阻礙合法流量的情況下阻止惡意流量。

Cloud-based的 WAF 使企業能夠在整個多雲基礎架構中快速部署這些保護措施。 如果我們的企業不具備識別這些模式和實施保護所需的技能，那麼使用託管 WAF 服務可能是有利的，這些服務可以從可以讓服務商幫我們監控和部署保護我們的web 服務。

阻擋某些類型的Application-layer DDoS 攻擊的另一種方法是使用不同類型的驗證。 我們之前在提到防止機器人時討論了這種類型的保護。 某些類型的Application-layer DDoS 攻擊的行為類似於機器人。 事實上，它們經常使用相同的底層技術。 這意味著可以通過使用許多相同的技術來阻擋它們。

在可疑流量進入目標 Web Application之前使用 CAPTCHA 或 JavaScript challenge，可以讓我們快速區分惡意流量和合法流量。 這些類型的辨識動作不需要被普遍使用。 相反，我們可以建立規則來檢查正常模式之外的網路流量模式，並只在識別出這些可疑模式時部署檢查。 這種方法的優點是我們“不需要識別可疑流量”，只需要識別“正常行為之外”的流量。 這種方法的一個缺點是我們冒著減慢合法網路流量的風險，這可能導致客戶從我們的網站流失掉。

Network-Layer DDoS Protection

第二種 DDoS 攻擊是發生在網路層的攻擊。這些攻擊使用network protocol（例如 DNS、NTP) 或 Memcached）來使整個網路充滿大量流量，以至於所有系統都不堪負荷。有史以來最大的network-layer DDoS 攻擊產生了每秒 1.35 TB 的持續流量。

Network-layer DDoS 保護涉及應在network-layer實施的不同類型的安全措施。大多數CSP將無法在我們的邊緣阻擋這些攻擊。

訣竅是設置 DDoS 保護措施，攔截惡意網絡流量，並在它有機會到達CSP之前將其阻擋。 DDoS 保護服務會監控惡意流量，甚至在它到達我們的雲端架構邊緣之前就將其阻擋。與Application-layer DDoS 攻擊不同，Network-layer攻擊不會“混入”我們網路中的現有流量，因此在阻止 DDoS 攻擊的同時破壞 Web Application的合法流量的可能性很小。

這是運行多雲架構的另一個優勢。通過構建跨多個網路託管的地理多樣化環境，我們可以建立redundancy，使 Web application不易受到network-layer DDoS 攻擊。即使一個站台暫時離線，其他站台也可以承接負載。

與其他類型的安全措施一樣，重要的是計劃我們的 DDoS mitigation strategy並重複測試該計劃，以驗證站台在不同類型的 DDoS 攻擊期間是按我們預先的計劃運作。

深度互聯網監控: 資料智能(Data Intelligence)

我們在這一系列的文章中多次提到了監控，這值得深入研究。 多雲基礎架構的定義很複雜，需要複雜的監控方案。 這不僅僅是監控網路基礎設施以確保其正常運行並監控應用程式效能的問題。 企業還需要了解 Web Application在世界各地的服務的情況。

深度互聯網監控不僅是監控我們的架構以及不同站台如何相互連接。 它是關於監控互聯網本身的效能。 互聯網是有韌性的，完全中斷的可能性很小。 但是，小規模的區域性中斷一直在發生。 2018 年，全球發生了 12,600 起網路路由事件。 這些類型的中斷可能持續幾分鐘、幾小時或幾天，並且只影響互聯網的一部分。

當這些攻擊發生時，企業可能完全沒有注意到它們。 但無論有多少redundancy，它們都會影響嘗試訪問我們 Web Application的人。 我們的客戶不會關心為什麼會服務中斷； 他們只會關心他們無法訪問我們的網站這一件事。 這就是為什麼從盡可能多的位置了解我們的 Web Application是如何運作的如此重要的原因。

從大量來源收集監控和效能資料並隨著時間的推移追踪效能，使組織能夠更好地了解問題並對中斷做出快速反應。 這些監控趨勢線可以幫助企業在需要建立額外的基礎架構時選擇最好的CSP。 它們還幫助企業確定哪些CSP表現不佳，最終在企業在改善客戶體驗的同時節省費用。

結合政策，管理，與可見性

只有當我們的企業結合了策略、管理和可見性時並能夠將這些進行跨雲的實施本文中的所有提到的內容才有效。這是絕對必要的，即使多雲架構中的每個CSP都有不同的功能和不同的管理平台。

高效能和有效率管理多雲解決方案的唯一方法是有一個統一平台查看所有內容。使用一個能夠支援多雲端的“管理平台”來進行部署、執行策略以及管理和監控所有的CSP。

這也使企業能夠利用達到一種規模效率(efficiencies of scale)。企業可以快速部署服務到新的資料中心，同時修補所有CSP的系統，並實施新的安全策略，例如新的 DDoS 保護規則。集中式管理和監控框架提供端到端(end-to-end)的可見性，並在系統開始出現故障時為企業提供早期預警。

複雜性需要政策的細緻度

儘管我們可以在構建多雲基礎架構後建立管理和監控工具，但應在部署之前確定系統政策。 從一開始就部署合規的基礎設施很重要，無論這些策略與資安、資訊保留或 PCI DSS 或 HIPAA 等法規有關。嘗試在部署後追溯並修補使用不符合政策的服務或系統是痛苦的，並且可能導致違反我們政策的漏洞。

政策還需要細緻化以正確涵蓋多雲部署，尤其是當多雲部署分佈在多個國家/地區時。 不同的國家有不同的監管框架，可能需要不同的政策來保持合規。 例如，在歐盟使用CSP的企業需要滿足GDPR法規要求。 了解我們部署的每個位置的政策，然後執行這些政策是規劃的關鍵部分。

除了監管政策之外，企業還需要確保在所有雲端中以相同的方式實施安全性。 在VM上使用容器更容易做到這一點。 但是我們確實需要擔心容器運行的硬體。 了解每個CSP的patch和強制執行政策，並在必要時補償其過程中的任何缺陷，應該是我們計劃的一部分。

任何多雲解決方案固有的複雜性都可以通過在所有CSP之間標準化管理解決方案來緩解，該解決方案可執行政策並提供全面的可見性。

邊緣讓我們有更簡單託管服務的產品

最後，將資安方案集中在邊緣而不是核心，可以容易的將託管的雲端服務整合為多雲架構的一部分。企業將受益於能夠在所有CSP之間快速部署這些解決方案，並且通過只使用它需要的服務來幫助降低成本。

託管服務的邊緣部署還可以根據需要部署新的託管服務。剛開始遷移到雲端過程的組織可能希望最初專注於部署 WAF，但推遲使用其他形式的資安保護。當我們準備好加上其他資安服務時，將更容易在整個多雲架構解決方案中正確的找到和部署服務。

隨著 Web Application的不斷成長，託管的服務也會隨之成長。企業可以加上新的CSP並在現有的CSP中啟用新的服務。當CSP表現不佳或企業的業務成長超出CSP的能力時，這種deployment-on-demand還可以更容易地切換到別家的產品。

結論

多雲架構需要重新考量如何在所有CSP之間部署安全性。 通過保護邊緣網路，企業可以靈活地在整個架構中提供安全性，同時提高可見性並提高 Web Application的效能。

通過與資安合作夥伴密切合作，企業可以找到適合其特定需求的解決方案。 這些解決方案可以與 Web application和企業本身一起成長。

要充分利用這些解決方案，企業必須首先了解需求並提出正確的問題。 如果不這樣做，可能會導致我們使用不合適的解決方案，進而產生沈沒成本。 通過適當的訓練和研究，我們的企業可以有效地保護網路邊緣的多雲架構。