開放網路軟體安全計畫(OWASP)日前發佈最新版十大網站資安風險,2017年上榜的10大網路安全大風險分別是注入攻擊、無效身份認證、敏感資料外洩、XML外部處理器漏洞、無效的存取控管、不安全的組態設定、網站攻擊、不安全反序列化漏洞、使用已有漏洞的元件、紀錄與監控不足風險。

事實上,不該停在前10大的迷思,有數百個問題可以影響Web應用程式的整體安全性。該如何有效地防制Web應用程式和API中的漏洞潛在攻擊呢?

WAF該部署在資料路徑的哪個地方?

App應用不安全變數正在破壞我們的金融、醫療、國防、能源和其他關鍵基礎設施。越來越複雜和相互聯繫的App讓實現應用安全的難度倍增。網頁應用防火牆(web application firewall;WAF)是應用防護的中心要素。除了能滿足PCI-DSS的遵循要求,WAF也具備優異能力以防禦前二十大網站安全風險(OWASP Top 20)。它也是解決零時差漏洞的常用解決方案,既可快速釋出新病毒特徵碼更新,有時在有長期部署的解決方案下,也能透過編程功能來修補應用漏洞。

Web應用程式的安全性是複雜、困難和負擔昂貴的,雖然這些問題是眾所周知的,但大多數開發團隊仍沒有足夠的資源來防範,來自四面八方媒介相關的各種攻擊,即使您的專案有時間和預算,所需的專業知識水平也很難達到。由於需要在每個應用程式中反覆處理這些漏洞,使得它成為您的生產路徑中的重要阻礙因素,這也讓企業面對WAF的佈局更複雜化。

問題在於你要把它架在哪裡?

當然有好幾個選項。資料路徑包含插入點,以便能部署WAF,但這不代表每個插入點都適用,因為其中有的效率較差,有些會形成單點錯誤(point of failure),而其他則可能引入架構性風險,長期下來可能導致重大損失。

理想上,你應該將WAF部署在負載平衡層後面,可兼顧使用量、效能及穩定性,同時為所有App提供防護—尤其是在網路上曝險的App。

使用量 負載平衡的決策中,資源要求(CPU等)佔有比例最小。這也說明何以負載平衡設備往往可支援上百萬用戶,而WAF使用量更大,因為它們需要檢查所有酬載,依據特徵碼和規則來判斷是否為安全及有效的呼叫。

現代資料中心的設計大量借用了雲端、以及以用量為基礎的成本架構的思維。使用量成為營運成本的重要因素。使用量更會導致更多的資源需求,這就會侵蝕到預算。因此使用量最佳化對資料中心或公有雲環境都是控制成本的良策。

穩定性 WAF水平擴充是很常見的作法,就是用負載平衡器來擴充WAF,這種架構決策直接關係到使用量。雖然許多WAF擴充方便,但仍可能因突增的流量或攻擊而過載。如果WAF位於負載平衡器前方,你要嘛需要另一負載平衡層分別擴充之,不然就得冒著效能和可用性降低的風險。

效能 效能是應用部署的關鍵考量。資料在傳輸路徑上傳送時,有太多變項及系統互動因素介入,光是要找出效能瓶頸就很難了,更不用說在不影響其他環節下個別調校。一如大家所知,系統負載愈增加,效能就愈衰減。這是不做使用量最佳化的結果之一,也是為什麼許多有經驗的網路架構師將網路裝置的使用量閾值訂在60%的主因。

將WAF部署在負載平衡層後方就不需要加上指定的WAF負載平衡層,等於省去了一整個網路層。雖然節省的處理時間看來不多,但花在管理連線和擴充WAF服務,然後重覆一次以選擇目標app instance或伺服器上的幾毫秒時間,集結起來可不得了。藉由負載平衡層後部署WAF省略掉這層,你所省下來的珍貴毫秒,今天的使用者不但能感覺到,還會很感激。

透通性 透通性是資料路徑安全解決方案的必要條件。要是無法監控整個資料流—包括酬載—WAF許多安全功能就無以施展。畢竟大部份惡意程式都是存在酬載,而非協定的標頭中。將WAF部署在負載平衡層後,可以在SSL/TLS流量流到WAF檢查前將之解密。這是比較理想的架構,因為負載平衡器需要看清楚流量,才能決定如何更適當傳送呼叫流量。

歸結上述所言,WAF應該能部署在資料路徑上任何你希望的位置上。它是L7代理伺服器為基礎的安全服務,是網路路徑上的中介角色,如果你堅持,它也可以架在網路邊緣。但如果你想同時最佳化網路架構的效能、穩定性及使用量,那麼最明智的選擇是將WAF部署在負載平衡層後,靠近它所保護的應用系統。

有了正確的工具,WAF將能完整涵蓋網路,大幅減低安全風險及營運成本。