當談及安全性和云計算模型時，平臺即服務(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的問題，那么這將會是一場噩夢了，因為在基礎設施級你無法實施多少措施以緩解已識別的風險。如果你一直以來都是依賴于基礎設施級的控制以滿足在應用程序級的安全挑戰，現在是時候重新考慮