如果沒有深入風險和花費，以及高官們實際關心的其他信息安全度量的儀表盤，那么怎么才能正確度量云上的安全運維呢？

緩慢但堅定地，IT部門正在調整安全控制（文檔化的流程）和架構模型來適應公有和私有云環境里的信息系統。隨著預防性的，檢測性的和響應式的控制正在進入混合云模型，CISO們現在必須思考云里的管控以及新的信息安全度量標準，為了內部跟蹤以及服務級別協議（SLA）。

有一些監控活動，信息安全度量基本上都在內部數據中心和云里。機會在于引入云環境的安全工具能夠大量抓取相同的數據，并且提供目前收集的任何信息安全度量。比如，虛擬防火墻設備日志丟棄或者堵塞的連接；基于云的漏洞掃描能夠報告基礎架構即服務或者平臺即服務系統的系統以及補丁和暴露的狀態；基于主機的安全監控工具記錄文件的訪問和配置的變化。

新的InfoSec云度量

但，CISO必須更多地關注于云里的性能指標以及SLA相關的度量。這意味著安全團隊需要研究能夠收集到的和云安全（云運維）相關的新度量。如果自動化的預配和Chef，Puppet這樣的編排工具一起工作，就能夠收集到實例生成和態勢評估的日志。事件則適用于管理活動，密碼工具和秘鑰使用及訪問，以及被批準的配置的變形也能夠被監控，從而確定云供應商的安全態勢。重要的信息安全度量包括如下幾種：

管理登入云供應商控制臺的次數

云環境里超過特定時間一直不活躍的“孤兒”賬號數量

啟動系統數量vs運行超過定義時間的系統數量（也就是說，在一段時間之后仍然在運行的系統）

使用批準的配置的系統數量vs沒有使用批準配置的系統數量

技術控制不足

安全資深管理還需要監控云供應商的合同義務，法律和供應鏈方面的都需要監控。在每份供應商的合同里，通常會定義一系列的SLA，從標準運維能力（在線時間和性能）到安全相關的需求（事件響應時間和法律或者鑒證請求）。一些云供應商可能有義務滿足數據生命周期的需求，比如數據滯留，郵件消息的合法持有以及對設備和證據的產銷監管鏈鑒證需求的響應。

必須密切跟蹤這些合同義務并且向運維和執行管理層匯報。還必須仔細監控并且匯報云供應商審計的任何變化和鑒證報告。如果供應商的SOC 2報告里的控制聲明的重大變更是相關的，那么就必須由安全和法務團隊公告并且評估。

雖然云服務花費更多地和運維以及開發團隊相關，大多數成熟的部署現在也包括很多安全相關的費用。花費包括由安全技術導致的額外消耗到和“云上”工具和產品相關的許可證，到新的類似云訪問安全代理的服務。花費還可能包括認證和加密服務，以及為這些環境提供控制的其他云服務。安全團隊不能忽略云使用的財務和預算方面，因為信息安全控制和服務現在已經是部署和運維的不可缺少的一部分。云度量可能包括隨時間產生的費用和預算，不可預見的變更（可能是積極也可能是消極的）以及花費在云上vs本地的整體安全預算的百分比。

模型還未成熟

另一個需要跟蹤的重要領域是云安全項目的整體成熟度。所有企業都想要知道和業界其他公司相比，他們的表現如何。并且該領域還缺少這一類別的比較基準，我們需要從哪里先開始。

大多數安全團隊使用類似的控制框架，比如國家標準技術局 800-53（National Institute of Standards and Technology (NIST) 800-53），NIST網絡安全框架，以及云安全聯盟云控制度量，和傳統的成熟模型，比如通用成熟度模型相結合。從任何角度看這都不是什么完美的方案，但是至少企業能夠將本地控制的成熟度和云上的相對比，并且研究能夠改進的領域。目前，一些控制方法在云上還不太成熟。需要時間等待云供應商改進他們的能力，并且等待云環境里的原生集成更加穩定。

無論你選擇哪種云度量，都需要確保收集反饋，并且確認這些是否真的對利益相關者有用。安全資深管理趨向報告超級復雜的信息安全度量，或者僅僅是未整理的數據，這些對于業務高管來講并沒什么用處。這是我們在云上推進時可以有意識阻止的不好趨勢。

關注于真正重要的事情：改進安全控制的狀態，發現流程或者策略弱點并且修復它們，報告花銷并且滿足合規需求和成熟度目標。關注于這些領域，那么一定能收獲很多。

本文來源：TechTarget中國