五步實現雲計算PaaS 安全性

當談及安全性和雲計算模型時，平臺即服務(PaaS)有著它自己特殊的挑戰。 與其他的雲計算模型不同，PaaS安全性所要求的應用程式安全性專業知識往往是大多數公司無法投入鉅資就能夠擁有的。 這個問題很複雜，因為眾多公司都使用「進駐式」基礎設施級安全控制戰略作為應用程式級安全性風險的應對措施(例如，一旦應用程式代碼發佈生產，使用WAF以緩解所發現的跨網站腳本程式或其他前端問題)。 由於缺乏對PaaS中底層基礎設施的控制，這一戰略在PaaS部署應用中變得不具實際操作性。

考慮到PaaS與控制相關的靈活性，你必須對底層計算環境具有一定的控制能力。 如同IaaS一樣，PaaS提供了近乎無限的設計靈活性：你可以基於社交網站構建任何應用，以實現內聯網網站或CRM應用程式。 但是，與IaaS不同的是，應用程式下的「堆疊」是不透明的，這就意味著支援應用程式的元件和基礎設施都是(根據設計)一個「黑盒」。 也就是說，與SaaS類似，安全性控制必須內置於應用程式本身中;但與SaaS中服務供應商通常實施應用於所有客戶的應用程式級安全控制不同的是，在IaaS中安全控制措施是針對你的應用程式的。 這就意味著必須由你自己承擔責任以確定那些控制措施是合適的並執行具體的實施。

這裡的一個簡單圖示，表明了模型與客戶之間的差異：

應用程式設計靈活性

功能控制比

底層透明度

對於那些在應用程式安全方面已投入鉅資的組織來說，他們擁有固定滿編訓練有素的開發人員，獨立的開發、測試以及生產流程，所以應對PaaS安全性問題應該是駕輕就熟的。 而那些還未作出這些投資的機構可以遵循如下步驟，從而在一定程度上有助於應對PaaS安全性的挑戰。

步驟一：建立安全措施

應用程式安全性的根本挑戰遠在PaaS實施前就已經存在。 因此，對於如何完善生產安全、魯棒的應用程式的部署措施已有相當的研究。 有一個可提供直接支援的技術被稱為應用程式威脅建模。 一些很好的著力點是OWASP威脅建模頁以及微軟公司的安全性開發生命週期資源頁。 從工具的角度來看，是免費跨網站腳本(XSS)和SQL注入。 擁有內部工具的企業可以將其應用於PaaS的安全性措施，或者眾多PaaS供應商為客戶以免費或打折的價格提供了具有類似功能的工具。 而當企業希望使用一個更為廣泛的掃描策略時，他們還可以使用諸如Google公司的skipfish這樣的免費工具。

步驟二：掃描網路應用程式

眾多公司已經接受了應用程式掃描，這是一個用於解決通用安全問題(例如跨平臺腳本(XSS)和SQL導入)的網路應用程式掃描工具。 擁有內部工具的企業可以將其應用於PaaS安全性措施，或者眾多PaaS供應商為客戶以免費或打折的價格提供了類似功能的工具。 而當企業希望使用一個更為廣泛的掃描策略時，他們還可以使用諸如Google公司的skipfish這樣的免費工具。

步驟三：培訓開發人員

應用程式開發人員完全通盤精通應用程式安全性原則是非常關鍵的。 這可以包括語言級培訓(即他們目前用於構建應用程式所使用語言中的安全編碼原則)以及更廣泛的議題，如安全性設計原則等。 由於開發人員的減員和流動性等原因，這往往要求培訓必須定期重複並作為常態保持下去，所以開發人員應用程式的安全性培訓成本可能是較為昂貴的。 幸運的是，還有一些免費的資源，例如Texas A&M/FEMA國內防備校園計畫提供了一些安全性軟體發展的免費電子學習資料。 微軟公司也通過其Clinic 2806提供了免費培訓：微軟開發人員安全性知道培訓，這是一個開始你自己定制程式有用的入門級培訓材料。

步驟四：擁有專用的測試資料

這樣的情況總是在不斷發生中的：開發人員使用生產資料進行測試。 這是一個需要正確認識的問題，因為機密資料(例如客戶私人可辨識的資料)可能在測試過程中洩漏，特別是在開發或試運行環境中並沒有執行與生產環境相同的安全措施時。 PaaS的環境敏感性更甚，而眾多PaaS服務更易於實現部署、試運行以及生產之間的資料庫共用以簡化部署。 如開源Databene Benerator之類的工具可以產生符合你資料庫特定結構的高容量資料，而資料格式調整有助於擁有專用的生產資料。 通常，這些處理是屬於特定框架的，因此你需要留意找出一個能夠在你的特定環境中正常工作的。

步驟五：重新調整優先順序

這最後一個步驟是你可以實施的最重要的一個步驟。 既然PaaS可能意味著一種文化和優先順序的調整，那麼相應地接受這一調整並將其真正納入自己的思想行為體系中。 使用PaaS，所有都是與應用程式相關;這意味著組織的安全性將高度依賴于組織中的開發團隊。 如果這不是PaaS的問題，那麼這將會是一場噩夢了，因為在基礎設施級你無法實施多少措施以緩解已識別的風險。 如果你一直以來都是依賴于基礎設施級的控制以滿足在應用程式級的安全挑戰，現在是時候重新考慮。