安全性是采用云技術所必需的一個要素，缺乏安全性通常會阻礙云技術的采用。然而，隨著安全策略和合規復雜性、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 和軟件即服務，以及基礎架構即服務)。因此需要將法規遵從性(就像安全策略管理和事故監控)部分地內置于云平臺上。
用戶需要采用基于白名單的策略，因為黑名單不再夠好
在此提醒，黑名單是指您向任何不在黑名單上的人提供訪問。白名單是指您僅向白名單中的人提供訪問。
模型驅動的安全組件
要實現自動化，一些 “算法” 需要能夠理解安全策略要求和與策略相關的一切(用戶、應用程序、應用程序互聯和應用程序工作流)，并自動生成匹配的技術安全策略實現。模型驅動安全方法將模型驅動的軟件開發方法背后的推理應用于安全和合規性策略管理，從而推進了這一需要的安全策略自動化級別。
模型驅動安全方法
實際上，通過分析應用程序及其所有交互并應用通用安全要求，模型驅動安全方法可以自動生成技術授權(和其他)規則。模型驅動安全方法是一個工具支持的流程，涉及到較高抽象級別上的建模安全要求，以及使用系統可用的其他信息源，特別是應用程序的功能模型(由其他利益相關者建立)，自動生成細粒度、上下文相關的技術授權(和其他)規則。模型驅動安全流程中輸入的信息用領域特定語言 (DSL) 表達，使用通用建模語言(比如統一建模語言或 UML)或企業架構框架(EA 框架)(例如，美國國防部架構框架或 DODAF，英國國防部架構框架或 MODAF，以及 NATO 架構框架或 NAF)。
捕獲安全要求在不使用圖形編輯器的情況下完成;也可以使用文本模型編輯器完成此任務(例如，在 Eclipse 這樣的建模工具中)。然后通過分析有關這些應用程序及其所有交互的信息，這些要求會被自動轉換為可實施的安全規則(訪問控制和監控規則)。
模型驅動安全運行時支持跨所有受保護 IT 應用程序的安全策略運行時實施，自動策略更新，以及策略違規的綜合監控。在模型驅動安全方法的第一步中，需要在一個模型驅動安全工具中將法規和治理標準建模(或從預先構建的模板中選擇)為一個高級安全策略。然后將這一安全策略模型應用于各組成系統的功能模型，也就是說，將安全策略模型角色映射到系統角色，并根據安全策略模型限制這些系統角色的行為。
從技術角度來看，這些(安全性和功能)模型被自動轉換為低級、細粒度、上下文相關的安全策略，并在整個云業務流程、云 mashup 或 SOA 環境中得到實施(例如，通過集成到中間件或域邊界的本地實施點)。本地實施點也可以處理安全合規性相關事件的監控。每當 SOA 應用程序(或其交互配置)發生變化時，模型驅動安全方法可以自動更新安全性實施和監控。
總而言之，模型驅動安全流程可以分為以下幾個步驟：策略建模，自動策略生成，策略實施，策略審計，和自動更新。下面我們看看這些步驟在云應用程序上下文中是如何執行的。
模型驅動安全架構
圖 1 中的圖表展示了基本架構：左上角顯示基于云的開發和 mashup 環境(業務流程管理系統 (BPMS)，編排的 Web 服務)。其中還顯示，需要(由云提供商)將模型驅動的安全組件安裝到開發/mashup 工具鏈中，以自動化策略的生成。
右上角顯示云安全服務，該服務提供 PaaS，開發工具的模型驅動的安全附加組件，以及定期的通用形式的策略更新;另外，還顯示了云安全服務提供的運行時管理(監控/分析/報告)功能。
底部顯示了部署到應用程序服務器(和云運行時堆棧的其他部分)的一些云服務，以及需要在運行時堆棧上(由云提供商)安裝的策略實施 (PEP) 和監控點。
在開發并集成一個應用程序之后，模型驅動安全方法會自動分析應用程序和策略模型，并生成被自動推送到相關 PEP/監控點的技術規則。每當一條消息經過任何受保護資源之間時，模型驅動安全方法就會自動評估和實施技術策略，并且如有需要，將事故警報推送到云安全服務的運行時安全策略管理特性。
圖 1. 架構概覽：使用 PaaS 的模型驅動的云安全策略自動化
優勢
如得到有效利用(參見 案例研究)，模型驅動安全方法具有眾多優勢：
它可以通過自動化(策略生成，實施，監控，更新)降低人工管理開銷，節省成本/時間，對于敏捷軟件應用程序來說尤其如此。
它還可以通過最大限度減少人工錯誤降低安全風險，通過確保安全策略始終符合業務需求和系統的功能行為來增加保障，從而增強系統的安全性。
此外，它可以跨安全孤島(例如，不同的應用程序運行時平臺)統一策略。
最后，它形成一個更加自動化的模型驅動敏捷認證方法的一部分。
缺陷
模型驅動安全方法的采用出于幾個原因仍然受到挑戰：
依賴于應用程序規范和一個適當定義的軟件開發生命周期 (SDLC);然而，建模互聯系統(特別是云 mashup 交互)的各個方面是先進的云 PaaS 的一個重要部分，也是健全的系統設計的一部分。
建模系統和安全策略的工作。然而，在適當的粒度級別(例如，云 mashup 模型)建模系統實際上不會增加策略管理的總體成本。這是因為，如果安全管理員因其工具不支持模型驅動安全方法而必須手動指定詳細的技術安全規則，他們可以在其策略管理工具內有效地指定應用程序規范的安全相關方面。在實踐中，對于大型系統來說，這是不可能的，尤其是在整個系統生命周期中。模型驅動安全方法只是重用專家(和/或工具)指定的模型上的信息(通常占安全策略規則的很大一部分)，不管怎樣，這些專家更了解應用程序和工作流(應用程序開發人員/集成人員和流程建模人員)。
從實踐經驗來看，與傳統的人工策略定義和管理相比，即使應用很小一段時間，模型驅動安全方法也可以大大降低保護系統的成本，并提高安全性。
實現云應用程序安全策略自動化
隨著云 PaaS 的興起，將所述模型驅動安全架構的全部或部分遷移到云中，以最高的自動化水平保護和審計云應用程序和 mashup 是合乎邏輯的。特別是，安全策略模型被作為一個云服務提供給應用程序開發和部署工具(策略即服務)，而且策略自動化被嵌入到云應用程序部署和運行時平臺(自動化策略生成/更新、實施和監控)。
不同的云部署場景是可行的;例如，開發工具和應用程序平臺中的安全特性都作為 Paas 配置的一部分托管在同一云服務中，或一些安全特性是另行托管的(特別是策略配置和監控)。這不同于本地非云部署，其中模型驅動安全方法通常安裝在本地安裝的開發工具(比如 Eclipse)內，或與其并行安裝，以保護大量本地運行時應用程序平臺(例如，Web 應用程序服務器)上的應用程序，并支持本地監控和報告。
如前所述，一般的模型驅動安全流程分為以下步驟：策略建模、自動策略生成、策略實施、策略審計和自動更新。下面我們看看這些步驟在云應用程序上下文中是如何執行的。在云上下文中，模型驅動安全方法的 5 個步驟如下所述。
云中的策略配置(策略即服務)
在模型驅動安全方法的云版本中，可以將策略配置作為基于訂閱的云服務提供給應用程序開發工具。將策略模型的規范、維護和更新提供給應用程序開發人員和安全專家具有顯著的效益：最重要的是，應用程序開發人員和安全專家現在無需持續指定(或購買并安裝)和維護用于模型驅動安全方法的策略模型，而是可以訂閱他們需要的策略源，而無需知道模型的細節。
策略即服務提供商(通常與云提供商不同)負責策略建模、維護和更新。其他優勢包括，用戶組織無需是安全和合規性專家，因為最新策略模型將被作為源持續提供給他們，前期成本障礙因訂閱模型而得以最小化。而且最終用戶組織無需持續監控變革法規和最佳實踐。
對于更加復雜的策略，一些簡單的設置和安全相關信息的一些潛在標記可能是有必要的：例如，對于一個 PCI DSS 策略模型訂閱，支付信息相關的界面可能需要連同應用程序 mashup 模型一同加以標記。整合到云中的預包裝云模塊越多，最終用戶組織需要做的標記就越少，因為云模塊可能已經提前被云提供商所標記(例如，支付處理模塊的 PCI 相關標記)。
總而言之，所描述的外包模型并非新事物。它已經在其他安全方面成功應用了多年，比如反病毒和反間諜軟件。用戶從反病毒提供商那里訂閱策略源，并讓反病毒軟件客戶端自動實施該策略(但與反病毒相比之下，本文闡述應用于云應用程序安全的外包模型)。
盡管質疑一個基于云的授權策略管理服務的真實性和可靠性是很自然的事(特別對于任務關鍵型環境)，但需要將這樣一個部署場景的含義看作與受保護云應用程序的內在真實性和可靠性水平相關。如果受保護云服務本身可通過 Internet 進行訪問，那么對策略管理服務的許多攻擊(例如，拒絕服務)也可以被轉移至受保護服務本身。在這種情況下，基于云的策略管理器不會增加風險。如果需要更高的真實性和可靠性，比方說對于一個啟用了優質服務 (QoS) 的私有云，那么策略管理器和受保護云都需要加固的基礎架構。總之，基于云的安全策略管理將是為許多組織配置的許多服務的正確選擇，但并不面向所有服務。
云中的自動技術策略生成
模型驅動安全方法的自動策略生成特性被集成到了開發、部署和 mashup 工具中(以獲取對功能應用信息的訪問)。它使用上一節描述的策略源。PaaS 有時包含云托管的開發和 mashup 工具，以及一個云托管的運行時應用程序平臺。在這種情況下，使用模型驅動安全方法的自動技術策略生成也可被遷移到云中，這樣一來在云托管的開發、部署和/ 或 mashup 流程中就可以為應用程序自動生成技術安全策略。對于 mashup 工具來說尤其如此，因為這些工具更有可能是云托管的，通常是圖形和/或模型驅動的工具，且關注云服務之間的交互和信息流。如果開發工具不托管在 PaaS 云上，那么就需要將模型驅動的安全技術策略自動生成特性集成到本地開發工具中。
云中的自動安全策略實施
策略實施自然而然應當集成到 PaaS 應用程序平臺中，這樣一來，每當云服務得到訪問時就會自動實施生成的技術策略。如上一節所述，策略要么使用托管模型驅動安全和 PaaS 開發工具在云內生成，要么通過本地模型驅動安全和開發工具上傳進來。
在 PaaS 應用程序平臺內置策略實施點的方式取決于 PaaS 應用程序平臺是否允許安裝策略實施點(例如，各種開源 PaaS 平臺;參見 案例研究);支持一個基于標準的策略實施點(例如 OASIS XACML);或者支持一個專有策略實施點。
云中的自動策略監控
策略實施點通常引起安全相關的運行時警報，特別是與阻截的調用相關的事故。對這些警報的收集、分析和直觀表示也可被遷移到云中。這有諸多優勢：可以集中分析多個云服務的事故以及其他信息(比如網絡入侵檢測);而且可以跨多個云服務提供安全態勢的綜合直觀表示;可以存儲整合的事故信息供審計之用;而且可以將合規相關決策支持工具作為云服務加以提供。
自動更新
所述模型驅動方法支持在應用程序、特別是其交互變更時，自動更新技術安全策略實施和審計。當安全策略需求變化時可以實現同樣的自動化。
最終用戶組織和云提供商如何使用安全策略自動化
所述策略即服務方法消除了最終用戶以及云提供商的諸多負擔：
最終用戶組織中的安全專家只需訂閱其云訂閱中的策略即服務安全選項，可能會采用一些簡單的安全標記特性(或培訓期開發人員)，并定期檢查合規報告。不過在此之前，安全專家的一個重要任務是要求其云提供商實現策略自動化(特別是針對私有云)。
最終用戶組織中的應用程序開發人員/集成人員只需使用云提供商提供的、策略即服務增強的 mashup/開發工具，并且可能會采用一些簡單的安全標記特性。
PaaS 云提供商將為最終用戶組織實現所有這些簡單性，通過執行以下步驟來實現策略自動化：首先，他們將與策略即服務提供商建立一個訂閱和服務級別協議。接下來，他們將需要從策略即服務提供商那里獲取模型驅動的安全自動化軟件和實施/監控軟件，并將它們分別安裝到其 PaaS mashup/開發工具和運行時平臺中。他們還將需要為最終用戶組織提供相關的安全訂閱選項、手冊和對策略即服務提供商創建的合規報告的訪問權限。在短期內，與公有云提供商相比，私有云提供商將更有可能提供這種服務(參見下面的案例研究)，因為私有云用于更多任務關鍵型用戶。
新概念還是使用過的已有概念?
一些安全工具作為云服務(安全即服務)提供，例如，用于執行 Web 應用程序測試。然而，針對授權管理的模型驅動安全方法之前沒有作為云服務(策略即服務)實現(據據本文作者所知），主要是由于標準，特別是 PEP，采用起來比較緩慢。通過直接與云提供商協作，作者為 OpenPMF 參考實現避免了這一問題（參見 案例研究）。這樣一來，就可以將合適的集成點開發到其基礎架構中。
案例研究
下面我們來探討一些案例。
面向私有云的應用程序安全策略自動化
ObjectSecurity 的 OpenPMF 針對大量不同的技術實現了應用程序安全策略自動化。在傳統安裝中，OpenPMF 被用作一個本地開發、編排和合規監控/報告工具插件，位于一個本地安裝的開發工具(例如 Eclipse，Intalio BPMS)內或與之并排放置，以保護大量平臺(各種 Web 應用程序服務器、Java EE、數據分發服務或 DDS、CORBA/CORBA 組件模型或 CCM)上的應用程序。隨著 PaaS 的興起，將 OpenPMF 也作為云服務提供才合情合理。
例如，對于針對私有云的應用程序安全策略自動化，從本地策略自動化到基于云的策略自動化的所述轉變被集成到了 Intalio 云中。Intalio 云是一個全棧式開源云產品，包含實現策略自動化的必要先決條件，包括使用業務流程建模的應用程序開發和集成(參見下圖)，以及一個基于 Web 服務的運行時平臺。已經為 OpenPMF 完成了開發 (Intalio BPMS/Eclipse)、運行時 (Apache Axis2) 和身份驗證/加密(安全套接字層或 SSL/傳輸層安全或 TLS)的當前技術集成。圖 3 顯示嵌入到 BPM Web 服務編排工具中的策略自動化特性(菜單 OpenPMF >Generate Security Policy)。只需單擊一下，就可以自動生成特定應用程序的詳細技術安全規則(參見圖 4)。
圖 2. 安裝(面向云平臺提供商)
圖 3. 自動策略生成(面向 PaaS 用戶)
圖 4. 技術策略部署(面向 PaaS 用戶，或全部隱藏)
圖 5. 運行時監控(用戶和策略即服務提供商)
云和 SOA 的模型驅動安全部署
一家應用程序安全策略自動化供應商 ObjectSecurity 和主要承包商 Promia(政府和行業安全技術供應商)目前正在為美國海軍在實際作戰部署中實現模型驅動安全策略自動化。這一部署遠比本文所述部署全面，它處理云和 SOA 體系的所有層，特別是應用程序、中間件、虛擬機、操作系統和網絡。項目提供一種有效的方式，為動態變化的互聯 SOA 和云應用有效管理信息安全，特別是提供一個可促進敏捷變更、快速認證和靈活策略管理的設施。
所用的技術(參見圖 6)包括：ObjectSecurity OpenPMF 模型驅動安全，應用程序安全監控和策略管理;Promia Raven 入侵檢測，監控，審計和 XML 信息交換功能;實施一個安全開發生命周期的安全增強的云和 SOA 開發和部署工具;可擴展的基于授權的訪問控制 (ZBAC)，用于分配授權;一個加固、受信任的運行時平臺，提供全堆棧保護，可托管 SOA/云應用和保護;一個提供全局全堆棧策略管理和自動化、報告、認證自動化和決策支持、配置、版本控制、掃描和測試的管理系統。
圖 6. 模型驅動安全策略自動化的實現
結束語
綜上所述，本文指出，敏捷分布式應用程序格局(比如云 mashup)的安全和合規策略管理需要以模型驅動且自動化的方式進行，才能具有敏捷性、可管理性、可靠性和可擴展性。這涉及到兩個核心概念：首先，將策略配置作為基于訂閱的云服務提供給應用程序開發工具(策略即服務);其次，將技術策略生成、實施、審計和更新嵌入云應用程序開發和運行時平臺中。通過將云應用程序和 mashup 的安全和合規策略自動化遷移到云中，云應用程序和 mashup 在云采用背后的總體理論基礎內更加無縫地受到保護。這也改進和簡化了云應用程序的安全軟件開發生命周期。
下面是開始應用模型驅動安全自動化的后續步驟的幾個具體建議：
試用
云提供商應當嘗試將安全策略自動化嵌入其平臺(例如，為 Eclipse 獲取 ObjectSecurity 免費試用版)。對于云用戶來說，如果您在支持模型驅動 mashup 和策略自動化或至少授權管理的 IaaS 或 PaaS 云中構建云應用程序，可以試用模型驅動安全策略自動化(例如，為 Intalio 云獲取 ObjectSecurity 工具免費試用版)。
規劃架構并推廣愿景
如果您處于云采用的規劃階段，那么您應當規劃您的架構來支持策略自動化，即使您沒有從頭開始實現它。模型驅動的 mashup 工具在支持策略自動化方面尤其有效，而且在勸說您的管理層采用策略自動化和 mashup 工具時，您可以使用 “總和大于部分” 這一論據。
如有可能，可要求您的云提供商實現策略自動化
向您的云提供商表明，有技術和方法可供使用，以及它們如何幫助您更經濟高效地處理云安全性。默認情況下，云提供商似乎提供 “要么接受要么放棄” 的云產品，這些產品無法協助安全專家最好地完成其工作。遺憾的是，一些云提供商(特別是 PaaS)不對外開放其基礎架構，因此集成您自己的策略自動化產品可能是一個挑戰。安全專家需要提出正確的問題讓云提供商朝著正確的方向發展，或選擇一個更開放的云提供商。
適時集成第三方策略即服務
如果您要為大型組織部署私有云，可以考慮使用基于標準的第三方云應用程序安全策略自動化產品;這樣一來，您就可以從第三方安全專家那里訂閱策略即服務，同時應用程序層實施通過云提供商的基于標準的特性完成(例如，可擴展訪問控制標記語言 (XACML))。
適時集成第三方事故監控和分析服務
上述情況同樣適用于監控。如果您的云提供商不提供您需要的東西，確保以標準格式(例如 syslog)導出警報，以便由第三方產品做進一步處理。
京公網安備 11010502049343號