利用雲應用程式安全性原則自動化提高雲安全性

本文詳述了有效應用程式安全性原則自動化的挑戰，闡述了模型驅動安全方法給安全性原則自動化帶來的好處，然後展示了如何實現雲應用程式安全性原則自動化。 安全性是採用雲技術所必需的一個要素，缺乏安全性通常會阻礙雲技術的採用。 然而，隨著安全性原則和合規複雜性、IT 複雜性和 IT 敏捷性的增加，將安全性原則轉化為安全實現的任務變得更加耗時、重複、昂貴且容易出錯，並且很容易增加最終使用者組織的安全工作量。 自動化可説明最終使用者組織（和雲供應商）減少該工作量，並提高策略實施準確度。 本文將重點介紹一個特別有趣的、富有挑戰且經常被遺忘的話題：應用程式層的安全性原則自動化。

雲應用程式安全性自動化

應用程式安全性原則自動化主要是一個自動化流程，將人類可理解的安全需求（比如企業安全性原則、遵從性法規和最佳實踐）轉化為在應用程式層實現的對應的技術安全性原則規則和配置。 在整個迴圈最後，它還包含審計自動化；例如，收集應用程式層警報並將它們映射為人類可理解的安全性和合規需求，以便持續評估安全態勢。

雲應用程式安全性原則剖析

應用程式安全性原則通常對於互聯、動態變化的應用程式格局來說尤其複雜，比如面向服務架構 (SOA)、雲應用程式 mashup、其他 「隨插即用」 的應用程式環境。 出於各種業務原因，以及以最少的總體維護工作量支援這些原因的安全要求，客戶採用了這樣的應用程式環境。 因此自動化非常關鍵。

安全自動化對於雲計算尤其重要，因為雲使用者要求雲供應商支援法規遵從策略管理，同時按照與雲計算大致相同的度量方式（根據它削減其前期資本支出和其內部手工維護工作的程度）衡量優勢。

總體而言，「應用程式層安全性」 遠比本文介紹的策略自動化方面寬泛，還包括漏洞掃描、應用程式層防火牆、建構管理、警報監控和分析以及原始程式碼分析等任務。 與應用程式層安全性原則密切相關的一個任務是身份識別和訪問管理。 儘管身份識別和訪問管理常常被視為與使用者身份管理（而非應用程式安全性）有更大的關係，但它們實際上與應用程式層安全性高度相關。 這是因為，當使用者訪問應用程式並進行身份驗證時，需要實施一個授權策略，這在很大程度上往往依賴于受訪問的特定應用程式。

此時，難題出現了：這個授權策略來自何處？ 誰編寫和維護該策略？ 如何實施該策略？ 如何審計該策略？ 這些問題在以下情況下也適用：使用應用程式安全性原則自動化以及身份識別和訪問管理，讓策略管理更省時、不重複、不再昂貴且不易出錯。

如今的雲應用程式安全性原則自動化部署

總體而言，安全性原則自動化，特別是對於雲技術來說，仍然處於相對較早的階段。 它主要側重于將身份識別/身份驗證作為一種服務（例如，Facebook 連接）提供。 還有一些基於雲的安全服務（反病毒、電子郵件掃描、入侵偵測系統 (IDS)，日誌管理），其中一些服務與應用程式間接相關。

本文專注于將應用程式安全性原則自動化作為一種服務提供。 目前只有幾個適用于早期採用者的部署：首先，ObjectSecurity 將其 OpenPMF 模型驅動的安全性原則自動化產品與一個私有平臺即服務 (PaaS) 雲（帶 Intalio BPMS 的 Intalio 雲）相集成，為雲 mashup 提供無縫的策略自動化。 涉及 OpenPMF 的另一個早期部署適用于美國海軍，在介於私有雲和 SOA 之間的灰色區域中。 它涉及到策略即服務，面向高保障環境中的虛擬化 IT 服務。 兩個案例都將在後面的 案例研究 一節加以討論。

還有大量其他模型驅動的安全性原則自動化部署，但不是針對雲，且大部分沒有涉及到策略即服務。

應用程式安全性原則自動化的挑戰

遺憾的是，在大多數情況下，安全性原則自動化說起來容易，做起來難。 本節概述應用程式安全性原則自動化實現起來較難的原因。

策略變得更難以實現和自動化，因為它們對人們和組織來說更加有意義

如今的許多安全工具提供了一定程度的自動化（無需維護），但無法實現相關性、正確性和自動化之間的折衷：在某些情況下，自動化工具的構建以供應商知道最終使用者組織想實現什麼預設安全性原則為前提。 在其他情況下，構建產品的宗旨在於隨時間啟發式地學習策略。 兩種方法的缺點在於，它們可能會實施非計畫中的、不相關或不完整的策略，即使安全機制自身能夠發揮其作用。

這樣的傳統安全自動化往往更適用于更加通用的安全工具，這些工具不需要特定于組織的策略，且面向技術體系的底層級（例如，網路或作業系統層），比如反病毒、反惡意軟體、預配置的網路入侵偵測系統，以及通用的應用程式漏洞掃描。

當必須將組織、使用者和應用程式行為考慮在內來實施和審計安全性原則時，安全自動化變得更難以實現。 例如，處理信用卡支付的一家組織會希望實施這樣的策略，比如 「未解密的信用卡資訊不得帶離組織之外」，「必須刪除不再使用的信用卡資訊」。 另一個示例是，一家醫療組織希望實施的策略包括，「醫生和護士僅在有法用途需要時，才能訪問其當前 患者的健康檔案，而不創建報警審計日誌」。 這樣複雜的、與上下文相關的策略取決於特定組織的安全性原則、業務流程、應用程式和應用程式交互。 通常實施這種複雜的、與上下文相關的策略的原因在於，最終使用者組織必須滿足行業特定規范（PCI 資料安全標準或 PCI DSS 和健康保險便攜性與責任法案或 HIPAA）。

策略變得更難以實現和自動化，因為它們變得更多、更複雜、功能多樣、細微性更細且與上下文相關

傳統的 「授權管理」 如今被歸類為身份識別和訪問管理一部分，它說明了這些挑戰：當系統和參與者越來越多，當互聯應用程式動態演化（「敏捷性」），當策略變得豐富多樣、細細微性和與上下文相關時，策略變得不可管理。 有太多、太複雜的技術安全規則需要管理，因此授權策略可能變得不明確或不可管理，並且對所實施策略的信心可能被削弱。 如前所述，需要回答的問題是：這個授權策略來自何處？ 誰編寫和維護該策略？ 如何實施該策略？ 如何審計該策略？

策略自動化變得更難以實現，因為 IT 格局變得越來越敏捷和互聯（特別對於雲 mashup）

要支援敏捷應用程式環境（比如雲和 SOA）背後的採用原理，授權管理本身至少需要是同等敏捷的，而且是自動化的、可管理的、細細微性的、與上下文相關的。 遺憾的是，面對頻繁而動態的系統變更，創建和維護一致且正確的技術安全性原則是一大挑戰。 這是因為，動態變更（例如，雲 mashup 的動態變更）會使實施的技術策略無效，而且安全性原則對於互聯、動態變化的應用程式格局來說尤為複雜，比如 SOA、雲應用程式 mashup，以及其他 「隨插即用」 應用程式環境。 如果不考慮這些缺點，授權管理形成一個關鍵的技術構建塊，可為所有受保護資源實施和審計應用程式授權策略。 它是雲應用程式安全性的一個重要部分，對於雲 mashup 來說更是如此，因為不同的角色（使用者或雲應用程式）應當在特定情況下獲得授權後，才能夠根據安全性原則調用彼此的服務。 一個重要的授權管理標準是 OASIS 可擴展存取控制標記語言 (XACML)。

法規遵從性是與策略相關的一個要求，因此也需要得到盡可能多的自動化支援

企業雲使用者不可避免地會要求為其雲託管應用程式和服務提供簡單、低維護量（自動化）的合規支援。 這是因為，許多雲應用程式要處理監管資訊（隱私、健康資訊、支付資訊），這些資訊通常是跨組織邊界且需要審計的。 合規審計不能成為雲使用者的獨有責任，因為使用者對雲體系的可見度有限（特別對於 PaaS 和軟體即服務，以及基礎架構即服務）。 因此需要將法規遵從性（就像安全性原則管理和事故監控）部分地內置於雲平臺上。

使用者需要採用基於白名單的策略，因為黑名單不再夠好

在此提醒，黑名單是指您向任何不在黑名單上的人提供訪問。 白名單是指您僅向白名單中的人提供訪問。

模型驅動的安全性群組件

要實現自動化，一些 「演算法」 需要能夠理解安全性原則要求和與策略相關的一切（使用者、應用程式、應用程式互聯和應用程式工作流），並自動生成匹配的技術安全性原則實現。 模型驅動安全方法將模型驅動的軟體發展方法背後的推理應用於安全和合規性策略管理，從而推進了這一需要的安全性原則自動化級別。