在 AWS 中進行勝利的 WAR (Web Application Resource) 部署

對於企業在使用亞馬遜雲端服務(AWS)時,最重要的安全建議就是:「一定要去參加WAR」。WAR是Well-Architected Review的縮寫,是一種強而有力且積極主動的方式,可以透過AWS團隊和其合作夥伴來降低實際風險。如果你正在使用AWS(或正考慮使用),不妨將WAR納入你的安全武器庫。這是一個在雲端產業開始流行的祕密武器,閱讀完本文後你就會明白為什麼了。

AWS提倡共同責任模式

談到雲端環境時,常聽到並被所有雲端服務供應商使用的一個術語就是「共同責任模式」。這個模式通常會決定與任何潛在的雲端服務供應商簽訂的主服務協議條款,無論是軟體即服務(SaaS)、平台即服務(PaaS)或基礎架構即服務(IaaS)模式。目的是要明確界定並建立雲端服務供應商與雲端消費者之間應分擔的安全責任。

作為安全專家,Wallarm主張採用共同責任模式。雲端供應商無法為你提供100%的安全性,比如說保護你客戶的資料和存取權(你可以在下面看到AWS的共同安全模式)。對於應用程式和API的安全性而言,由雲端服務供應商和雲端消費者共同提高防禦能力也有莫大的好處。所有在AWS和其他雲端基礎架構上的客戶都應該積極主動地參與自身的雲端安全工作。(參見以Wallarm在AWS上保護應用程式的安全。)

這張圖像顯示了共同責任是如何分配的:

從良好架構的框架開始，針對 AWS 雲端架構師
AWS 開發了良好架構框架 (Well-Architected Framework)，以幫助雲端架構師建立安全、高效能、具有彈性和效率的應用程式基礎架構。基於五大支柱—操作卓越、安全、可靠性、性能效率和成本優化—此框架為客戶和合作夥伴提供了一種一致的方法，以評估架構並實施隨時間擴展的設計。

AWS 的良好架構框架方法建立在共享責任模型之上，該模型幫助消費者和提供者真正理解他們的責任分擔，如下圖所示。

這個架構框架不僅僅是AWS的架構工具,更是一種生活方式和看待架構的方式,以確保有彈性和一致的結果。

Well-Architected 框架是一套不斷更新的最佳實踐,AWS會持續更新。每次你想要開始新的事物或改變某些東西時,都要用這五大支柱來評估你的構想,這就是WAR(Well-Architected Review)的用途。

雲端安全的WAR之路
WAR是一種有系統的方法來審視你的架構,無論是已在AWS、內部部署或其他雲端服務商。目前WAR有46個問題,但由於這是一種活的方法論,問題數量可能會改變。它與以下五大支柱相呼應:

• 安全性
• 可靠性
• 效能效率
• 成本優化
• 營運卓越

回答WAR問題有助於找出哪些領域屬於以下三種類別:

• 架構良好
• 需要改進
• 重大問題

重大問題應立即加以改善,例如未對帳戶使用多重驗證或公開敏感資料。需要改進的項目應在三到六個月內檢視。

AWS建議你定期(至少每六到十二個月)對每個關鍵工作負載執行這些審查。即使今天被視為架構良好的項目,未來也可能因為環境變化或新選項取代現有做法而改變。

按呢做伊雲端戰爭(WAR for AWS)

有兩個重點因素,做伊雲戰爭之前,愛先考慮真

1. 架構的複雜程度
2. 技術水準

咱來看伊幾個例子,什麼樣的組合因素會鼓勵你發動戰爭,什麼樣的組合因素就算了啦。

架構的複雜程度高,技術水準也強,這種情況就適合發動戰爭。反過來,架構簡單,技術又不濟,就免開打啦。

若是架構雖然複雜,但是技術水準不錯,或是架構簡單,技術又很強,就要看具體情況決定要不要開戰。

總之,做伊雲戰爭的決定,愛先好好評估自家的實力,同時也要看敵情,才決定發動與否啦。一不小心就會陷入泥淖,那可就慘了!

• 情況一:高度複雜的架構及專家級技能
• 若你的架構高度複雜,且具備專家級技能,建議採用混合式的方法。
• 至少與AWS代表會面一次,對於發現那些輕易被忽視的小細節十分有幫助。舉例來說,過於專注於基礎建設上的商業邏輯,可能會遮蔽了你對關鍵問題的視野。
• 在初次進行Well-Architected Review(WAR)並將結果匯入AWS主控台後,你可以再次內部重複相同的流程,由你高度熟練的員工來執行。WAR的頻率取決於你發現的問題以及內部可運用的資源。
• 情況二:高度複雜的架構及新手級技能
• 當你面臨高度複雜的架構,但又缺乏足夠的人手來理解Well-Architected Framework的各個支柱時,尋求外部協助是最佳之選。與AWS合作夥伴協商良好的價格,是最合理的做法。
• 別讓成本顧慮阻礙了你進行WAR,因為Well-Architected Review所帶來的節省,足以抵銷與AWS合作顧問的額外成本。
• 情況三:不太複雜的架構及新手級技能
• 如果你對AWS還算陌生,而且架構的複雜度不算太高,那麼直接與AWS團隊合作是最佳選擇。WAR將有助於你了解如何處理災難復原、備援、故障切換等,這些通常都是新團隊容易忽略的部分。
• 情況四:不太複雜的架構及專家級技能

唯一可行(但非必要)採用自行執行(DIY)方式的情況,是當你的架構複雜度不高,且具備專家級技能時。

若要自行執行WAR,你可以使用2018年11月推出的AWS Well-Architected Tool,搭配使用手冊。請先審視Well Architected Framework白皮書,並參考其中的問題和最佳實踐方式來自行執行審查。

Well-Architected Tool已內建於你的AWS主控台中,使用起來非常簡單。每個問題都有詳盡的說明和影片教學。

我們強烈建議你透過瀏覽AWS資源,來熟悉所有支柱的內容。

WAR的流程

WAR的流程很簡單,並沒有你擔心的那麼繁瑣。它從以問卷形式進行審查開始。審查通常只需幾個小時,相當輕鬆。無論你是自行執行、指派AWS合作夥伴或直接與AWS專家團隊合作,你都會使用Well-Architected Tool來回答46個問題。在初步階段結束時,你應該已對目前的架構有相當程度的了解,並獲得一份詳細報告,其中將關鍵問題和需要改進的地方細分為可執行的改善步驟。除了自行執行外,你很可能會收到一份詳細報告,指出WAR五大支柱中的差距所在。

Amazon以”給顧客最大的喜悅”為基本原則,這項理念在WAR中可見一斑。AWS代表會與客戶合作,協助減輕WAR發現的問題。很多時候,公司甚至可以獲得AWS的額度,用來修正WAR期間發現的關鍵問題。WAR可分多次進行,特別是當有數個關鍵工作負載被納入WAR範疇時。

什麼是關鍵工作負載?

每個客戶都最清楚自己業務的重點所在,哪些是對營運至關重要的部分。它可能是處理所有訂單的顧客入口網站、驅動製造流程的供應鏈系統,或是用來確保案件如期完成的案件管理系統。關鍵工作負載就是你認為對於運作、變更或發展業務而言最為重要的部分。

各種鏡頭為WAR視野增添力量

AWS強調”戴上各種鏡頭”並不是無的放矢。WAR過程是一個不斷演進的過程。AWS為某些特定使用案例擴展了WAR,他們稱之為”鏡頭(lenses)”:

• 無伺服器應用程式
• 高效能運算(HPC)
• 物聯網(IoT)

每個鏡頭領域的變化都很快速,各自也有不同的架構最佳實踐。這正是為何單純依賴雲端安全供應商永遠不是一個好主意的原因之一。威脅環境的快速演變,讓我們了解到共同責任的必要性,以及風險所在。

為了理解起見,讓我們聚焦在其中一個鏡頭:無伺服器。

無伺服器運算假設供應商會執行客戶提供的程式碼,同時完全負責基礎建設和環境本身。無伺服器供應商提供所謂的”函數即服務”(FaaS)平台。FaaS平台會執行應用程式邏輯的程式碼,但本身保持完全無狀態,也就是不儲存任何資料。AWS Lambda是最古老也是最受歡迎的公有雲無伺服器運算服務。

無伺服器鏡頭可以減少攻擊面。由於AWS完全自行負責基礎架構的部分,因此不需要強化EC2作業系統或設定容器。此外,由於沒有資料或狀態暴露,因此風險也相對有限。

仍需要確保安全的是與函數運算的API介面,以及存取控制(包括驗證)。為了加強WAR流程的應用程式安全性和細緻的驗證實踐,我們建議:

• 應用自動設定的執行階段API安全性,實現防禦在深度。
• 將自動化安全測試整合到你的建置或持續整合流程中。

• DAST咧是動態應用程式安全測試,DEV就是開發人員啦。
• WAF就是Web應用程式防火牆,SEC就是安全囉。
• FAST是應用程式安全測試框架,OPS就是營運團隊啦。
• CI/CD就是持續整合/持續測試啦。

結論

AWS Well-Architected Framework會提供策略,幫你比對工作負載是否符合本文建議的最佳實踐。它也可以提供指引,協助你建構穩定高效的系統,讓你專注在功能需求和整體營運上。

趕緊下載AWS Well-Architected Framework白皮書,開始學習吧!要最好地理解並落實與雲端服務供應商的共同責任,就非做一次WAR不可啦。