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

多雲環境的資安

資訊安全不應該是事後的想法或建立多雲環境的附加因素。 相反，資安應該融入到開發和部署工作流程中。 與其將資安視為由資安團隊處理的事情，不如將資安置於每個人思考過程的最前期。

在之前的文章中，我們討論了將資安納入開發週期的重要性以及建構安全的容器化系統的優勢。 在本文中，我們將仔細研究如何保護我們的整個多雲基礎架構。 擁有安全的開發和部署流程是不夠的。 還需要持續監控多雲部署並充分了解我們的企業所面臨的威脅。

即使是最安全的 Web application也可能因以前未知的威脅或部署過程中導入的弱點而導致安全漏洞。 這就是為什麼建立一個讓每個人都了解不斷變化的威脅態勢的資安策略很重要的原因。 我們還需要持續監控惡意活動。

這可能要求企業重新檢視如何看待資安。 它還可能要求企業部署新技術，以解決在多雲環境中部署應用程式的現實和危險。

邊緣管理原則(Edge Management Principles)

資安從來就不簡單。 但過去更簡單的一件事是網路“邊緣(edge)”的公認定義。 網路邊緣一詞用於防火牆，或者可能是gateway routers。 易於定義的分界線讓資安團隊與非資安團隊有清楚的責任界線。 這導致了今天仍然存在的關於組織邊界的“城堡和護城河”的比喻。 但近年來，這些界線已被侵蝕。隨著越來越多作業轉移到雲端，邊緣的定義發生了變化。 然而，無論我們的組織對邊緣的定義如何，邊緣管理的原則都沒有改變。

哪甚麼是"邊緣(edge)"?

在我們繼續之前，讓我們定義“邊緣”一詞的含義，因為這將為我們的資安這一部分的討論提供一些資訊。 邊緣的大多數定義會將其與IoT混為一談，IoT由網路與連上的網路上的終端設備組成。 這些“things”當然是邊緣的重要組成部分，因為這些設備通常用是進出資料進入網路的Gateway。

但邊緣的意義遠多於這些，尤其是在多雲環境中。 多雲策略意味著我們的組織有效使用的每個CSP並成為為組織“邊緣”的一部分。

通過將多雲環境視為邊緣的一部分，我們的組織可以使用 CSP的工具來限制和重新導向網路流量，最大限度地減少雲端基礎設施的攻擊面，同時盡可能廣泛地提供應用程式服務。

因此，我們對邊緣的新定義不僅包括傳統的IoT設備，還包括部署在多雲環境中的基礎設施，用於過濾和重新導向對多雲應用程式的流量，例如 DNS 或 WAF。

邊緣網路中的數位資產管理

在資安團隊能夠正確管理和保護組織的邊緣之前，他們需要知道有哪些系統。 良好的資產管理是良好邊緣安全的基礎。 資安團隊需要知道在多雲環境的每個instance中部署了什麼，以及每個系統運行在什麼CSP的服務上。 資產管理不應該是一個靜態的過程。 正如開發週期不再是一個以六個月或一年為間隔測量的靜態週期一樣，資產管理應該是動態的，並持續監控部署到雲端中的數位資產。

所有部署到邊緣網路的系統都有一個共同點，那就是它們是對外性的存取。 與未部署到邊緣網路的系統相比，這需要不同類型的資安策略。 管理和保護邊緣網路設備需要資安團隊區分合法網路流量和潛在的惡意網路流量。 它還要求團隊能夠即時阻止惡意網路流量。 隔離的方式遠不可行。 邊緣網路基礎設施是可對外性的存取，這讓它成為目標。 它可能是一個容易攻擊的目標，或者它可能是一個駭客想要竊取組織的資料。 無論是哪種，我們都需要密切監視到達邊緣系統的網路流量以發現潛在的攻擊。 僅僅尋找已知的漏洞是不夠的。 尋找可能不包含已知攻擊指標的惡意網路流量也很重要(尋找我們還不知道的 — unknow unknows)。

最後，我們的資安團隊需要能夠關聯所有邊緣網路設備和內部系統的惡意活動。 特別是有針對性的網路攻擊，不再會發生在單一個點上。 駭客將盡可能多點探測他們能找到的攻擊向量。 如果邊緣網路設備的“資安功能”沒有跟其他安全基礎設施有一個統一控制的系統與介面，則很難建立這種關聯。 資安團隊應該能夠從邊緣網路設備中擷取日誌和網路流量資訊，並快速將其與網路上發生的其他安全事件關聯起來。 理想情況下，這應該發生在我們組織主要使用的資安方案中，無論是 SIEM 系統、MSSP(Managed security service provider) 還是其他一些資安工具。

基於在企業的效益與挑戰：多雲端平台的使用part2中討論的安全開發原則，保護邊緣網路的第一步包括對雲端基礎設施進行良好的資產管理、能夠在邊緣網路設備有效的監控其網路流量，以及發生在我們的網路中將影響邊緣設備的事件與其他資安活動相關聯起來。

為何在邊緣網路中保護我們的資產使如此重要

正如本系列的前兩篇文章中所討論的，多雲環境很複雜，需要仔細規劃，而這種規劃延伸到實施適當的資安控制。 錯誤配置的防火牆規則、部署不當的 VPN 或隨便設定的 API 存取控制都可能導致數上千萬客戶的資料洩漏。 這些漏洞還可以為駭客提供更多存取網路的方法。

強大的邊緣網路安全性還可以幫助保護我們免受潛在的軟體開發的安全漏洞的影響。 例如，在邊緣防止XSS(Cross-site scripting) 攻擊意味著敏感的客戶資料不太可能洩漏。

保護邊緣網路資產不僅僅是確保雲端基礎設施的其餘部分是安全的。這也意味著保護邊緣網路設備本身。保護雲端中的邊緣首先要保護保護該雲端基礎設施的邊緣設備。我們需要密切監控並能快速修補部署在雲端環境的邊緣系統。能夠利用並獲得對其中一個系統的訪問權限的駭客可能不僅可以訪問多雲端基礎架構，還可以訪問整個網路。我們需要將雲端中的邊緣設備視為關鍵資產，就像他們將網路中的邊緣設備一樣。

採取必要的措施來保護和監控新定義的邊緣網路，對於在開發團隊在其流程中構建安全性時所做的工作大有幫助。這會建立一個多層次的資安策略，意味著一個錯誤不一定會導致有資安事件發生，因為其他資安措施將會啟動並彌補這些錯誤。

API Gateway作為集中式的資安策略機制

更好的管理邊緣網路的安全性的一種方法是使用 API gateway。 API gateway是一個系統，放置於在多雲環境中的服務之前，並充當aggregator。 它們不是讓每個服務直接互相通訊，而是使用處理authentication和access policies的 API gateway進行通訊。

一開始的第一印象，API gateway似乎增加了已經很複雜的多雲部署的複雜性，但如果實施得當，API gateway可以降低複雜性。 儘管它確實為我們的雲端環境加上了另一個layer，但 API gateway集中了跨不同服務和跨多個雲端環境的資安策略。 這有助於確保access control得到普遍部署和實施。 APIgateway簡化了安全性也提高了 API 部署的安全性。

在其最基本的部署中，API gateway管理跨多個服務的 API authentication，如下圖所示，確保只有授權用戶或系統才能訪問API gateway之後的服務，並限制可以訪問的 API requests的數量。 這也允許 API gateway管理 API key authentication。

不過 API gateway其實可以做更多的事情來增強 API的 安全性。 API gateway還可以充當所有 API 基礎設施的log aggregate，在單一個儀表板中顯示 API log messages，可以導入到 SIEM 系統或發送到 MSSP。 當然，API gateway作為log aggregate的有效性取決於 API 本身回報的錯誤訊息的質量。 如果 API 只報告簡單的 200 “OK”、404 “資源未找到”或 500 條“內部錯誤”資訊，則gateway本身的是低效能的。

API gateway還可用於在 API 基礎架構中實施白黑名單。 這讓資安團隊在他們的API 運作中進行更加精確的安全性。 例如，如果某些 API 只能從內部網路訪問，資安團隊可以使用 API gateway阻擋對所有外部網路的訪問。 然後，白名單可以啟用對內部網路的訪問。 白名單與authentication security control相結合，可實現更強大的 API 安全性。

相反，如果擔心來自特定網路的針對Open API 的攻擊，資安團隊可以阻止這些網路，同時仍允許大多數Internet繼續訪問。 我們應該謹慎使用這樣的黑名單，因為 用IP的方式的效用是短暫的，今天被用於惡意目的的網路可能會在明天被合法流量使用 — — 甚至是從現在開始的一個小時。

我們還可以使用 API gateway來監控 API 基礎設施受到攻擊的流量，包括 SQL injection、oversized JSON 或要讓目標系統崩潰或充當DoS 的 XML requests攻擊。 跨所有 API 基礎架構集中日誌資料，讓我們的資安團隊能夠監控協調的 API 攻擊。

需要注意的是，保護 API gateway本身與保護 API 基礎設施同樣重要。 許多團隊選擇將其 API gateway服務外包給第三方，這是完全合理的，只要組織能夠查詢 API gateway本身以尋找潛在的資安事件。 在選擇外包 API gateway廠商之前，我們需要了解我們的團隊需要多少訪問權限才能監控資安事件，以及如何檢索這些資料。

如果我們決定建立自己的API gateway，請確保我們實施了適當的資安控制，包括以下：

• 限制誰可以access gateway
• 對gateway本身啟用日誌服務
• 定期的上patches

正如破壞邊緣基礎設施的其他方面可以使駭客access敏感資料一樣，access API gateway可以使駭客能夠直接通過我們的 API 擷取敏感資料。

WAF(Web Application Firewalls)

在邊緣保護多雲環境的另一種方法是使用 WAF。 自 1990 年代後期以來，WAF 一直不固定的形式出現，但直到 2000 年代初才被廣泛採用。

WAF 是一種偵測性和預防性的安全控制，位於網路邊緣(通常是組織的內部網路)和 Web application之間，保護應用程式免受惡意攻擊。 儘管大多數資安設備都專注於保護資安設備背後的人員/服務/系統，但 WAF 是專門為保護軟體而設計的。 大多數 WAF 結合使用signature-based的detection和heuristics方法來監控一個或多個 Web application的惡意流量。 WAF 阻止惡意流量，防止駭客訪問敏感資訊或目標系統本身。 WAF 是多層資安策略中的另一個工具，有時也稱為縱深防禦(defense in depth)。

在過去的幾年裡，WAF 作為一種資安工具越來越受到重視，因為針對 Web Application的攻擊不斷增加。 根據 Imperva 的一份報告，2018 年 Web application漏洞比 2017 年增加了 23%。 2018 年報告的超過一半的 Web application漏洞都是使用已知的漏洞，38% 的報告的 Web application漏洞沒有解決方案，例如第三方廠商發布的patches。

這些數字很驚人，證明了多層資安策略的重要性。 WAF 可以通過攔截最常見的攻擊類型來幫助我們彌補易受攻擊的 Web application。 WAF 可以防止 XSS 攻擊、SQL injection和暴露潛在敏感資料的攻擊。 WAF 可以完全阻止攻擊，也可以警告我們可能的惡意活動。

WAF 是高度客製化的，使其成為還沒有有application防禦措施的漏洞的理想工具。 例如，如果發現 Web application的漏洞允許駭客以不安全的方式訪問一個後端系統，資安團隊可以建利一個signature來阻擋對該後端系統的訪問，並在所有雲端中快速部署它。 WAF 暫時保護 Web application，同時允許合法流量繼續自由流動，直到我們可以部署更好的解決方案。

即使是最先進的企業，跟上針對 Web application的最新威脅也是一項挑戰。 這就是為什麼大多數 WAF 都有一個威脅情資的後端系統，該後端會在發現新威脅時自動更新，並確保自動部署保護措施。 “企業獲得兩全其美：針對最新威脅的自動部署保護，以及專門為其環境設計的客製解決方案。“

儘管 WAF 可以提高多雲架構的安全性，但它們也增加了另一層複雜性。 很多時候，企業以錯誤的使用 WAF來防護到不對的web application，或者最終根本沒有提供額外的保護。 我們需要在架構設計的早期仔細規劃和考慮 WAF 部署，而不是事後才考慮。 後期添加 WAF 和糟糕的 WAF 管理可能會導致花費大量費用購買一個基本上什麼都不做的解決方案。

網路監控

到目前為止，我們已經討論了建立具有多層安全保護的複雜多雲環境。但是我們還需要確保一切都保持正常運行，即使多雲部署的複雜性使得監控基礎設施變得困難。

術語“網路監控(network monitoring)”實際上有點用詞不當。當然，監控網路上的流量很重要，也是網路監控的關鍵部分。但真正的網路監控還包括監控應用程式的運作狀況及其運行的硬體。

傳統的網路監控依賴於 Netflow、Syslog 收集和SNMP等工具來衡量被監控系統的運行狀況。多雲解決方案使用許多相同的工具。監控 Netflow 有助於確保網路流量在系統之間正常流動，而 Syslog 有助於衡量應用程式本身的健康狀況。我們使用 SNMP 檢查底層硬體的運行狀況。借助這三個組件，我們可以有效地衡量系統的運行狀況並確保我們的基礎架構高效運作。

多雲架構還需要一個網路監控維度：效能監控。要全面了解我們的 Web application的健康狀況，我們需要了解它如何回應來自世界各地和跨 CSP的real query。效能監控允許我們測試 Web application並從特定位置測量效能。這種類型的監控還可以提醒我們其他類型的網路監控無法做到的網路活動，例如潛在的DDoS攻擊或可能的 BGP hijacking事件。

將效能監控與 Netflow、Syslog 和 SNMP 監控相結合，可以讓團隊全面了解 Web application的效能，並使企業對 Web application功能更有信心。

不過，網路監控只是整體IT監控服務的一部分。資安監控對於確保多雲環境的健康也是必要的。

資安的Monitoring, Logging 與 Notification

只有在告警得到正確及時處理以及所有security layer都到位情況下才能提高多雲基礎架構的安全性。眾所周知，塔吉特百貨(Target)忽視了系統一直發出的早期告警最終導致了 2013 年資料洩露事件，最終導致公司損失數億美元。塔吉特百貨(Target)不是唯一會發生這樣事情的企業。企業通常會錯過告警或非及時回應告警，從而導致代價高昂的資料遺失或暴露。

資安監控又增加了一層複雜性。但好消息是資安監控非常易於管理。雖然作起來並不容易，但還是可以做到的。如今，許多企業都在成功監控其應用程式的攻擊和其他資安事件。

首先要了解多雲環境中使用的基礎架構的事件日誌記錄功能。如果我們從頭開始，這很容易，因為我們可以確保部署的所有系統或廠商都滿足我們設置的嚴格的日誌記錄要求。這些要求應包括以下：

• 一致的event logging和清晰的事件解釋
• 一種通過 Syslog、API 或其他標準日誌接口遠端訪問log的方法
• 定義明確的日誌結構，以便於開發新的日誌收集器

與企業使用的Log Aggregate Tools的相容性

如果廠商無法滿足這些要求以及我們及其他要求，請盡可能選擇其他的廠商。

當然，即使是新的多雲部署也可能涉及使用古老系統。 這些系統可能無法滿足我們明定的需求。 在這些情況下，我們需要確保來自其他資安系統的補償控制可以為我們的團隊提供相同類型的資訊。

對我們的log aggregate tool有一個標準化很重要。 這將幫助我們避免在多雲架構中一次一個控制台管理數十或數百個系統的安全性。 相反的，我們希望確保將這些日誌集中到同一個地方，以便可以aggregate和correlate它們。

當然，我們可能已經有一個log aggregate tool。我們可以使用 SIEM 系統或 MSSP 來處理我們的監控和告警。將來自多雲環境的日誌導入現有的日誌收集系統是最有意義的，因為我們的團隊已經習慣了該工具。

Log aggregate tool讓我們的維運作業更輕鬆，並使我們的資安團隊更加有效，因為它收集不同的日誌源，對其進行正規化，並以所有系統和廠商的標準方式將它們呈現給資安團隊。這種正規化和標準化使資安團隊能夠更好地監控告警並確定告警的優先等級。團隊可以首先關注優先等級的最高級，然後沿著清單檢視，而不是四處尋找解決每個告警的方法。

要真正提高我們的資安監控解決方案的有效性，將資產和漏洞掃描結果傳送到我們的log aggregate system。這將的資料關聯會有效。例如，如果我們的 SIEM 提醒您我們的Web application可能受到 XSS 攻擊，我們可以快速轉向資產資訊，以查看目標系統是否正在運行任何易受該類型攻擊的應用程式。這些問題的答案使團隊能夠為告警分配最準確的優先級等並做出相應的回應。

我們選擇的日誌平台應該使用資料分析技術來處理導入的日誌並根據事件的優先等級解析這些日誌，如果它可以跨多個系統和跨多個CSP關聯，則為事件增加額外的權重。 使用這些相同的分析，log aggregate平台可以幫助將高優先級告警的數量從每天數百個減少到數十個。

正如容器幫助企業在多個CSP之間無縫部署複雜系統一樣，有效的log aggregate工具可以在所有系統和CSP之間提供相同的security picture。 讓我們的IR(incident response) 團隊以更有效的方式處理事件，希望在攻擊造成任何損害之前阻止它。

結論

多雲環境伴隨著資安挑戰。 這就是為什麼從一開始就應該將安全性考慮到架構過程中的原因。 將多雲基礎設施視為新的邊緣需要團隊實施layered security方法，包括漏洞掃描、API gateway部署和 WAF，作為對 Web application exploitation的最終檢查。

當然，如果沒有從網路和資安的角度進行適當的監控，所有這些資安基礎設施都是毫無意義的。 使用正確的工具將來自所有系統和廠商的監控匯總到一個位置，將有助於確保多雲環境的安全管理過程盡可能無縫。