近日，微盟“刪庫”事件引起廣泛關注，再次給廣大企業敲響 運維安全及數據 安全 警鐘。面對日漸複雜的企業IT系統，完善企業運維安全體系，讓運維自動化、規範化，消除潛在風險，是企業當前急需解決的問題。
構建企業運維安全體系
隨着數字化的高速發展，企業業務系統承載 巨大 價值的業務數據，運維安全不言而喻，而 惡意破壞或誤操作而導致的運維安全事件卻屢見不鮮。 此類事件一旦發生，將給企業運作帶來巨大影響及重大的經濟損失。 面對運維安全的潛在威脅，企業如何做到防患於未然？ 如何降低運維和數據安全風險，避免“刪庫跑路”或誤操作等“人禍”再次發生？
作爲曾經的信息安全專業學生，目前負責運維繫統建設和交付的工程師，雖然不能深入給大家介紹怎麼弄個蠕蟲、木馬、病毒等，但是可以先跟大家介紹下信息安全的體系結構。
面向目標的安全體系結構
信息安全的三個最基本目標（CIA 三元組）：機密性(Confidentiality)、完整性(Integrity)、可用性(Availability)。
面向應用層次的安全體系結構
面向過程的信息安全保障體系
OSI（開放系統互聯）安全體系結構
當然，整個信息安全體系是個非常龐大的課題，在每個主題下，都有很細很深的知識點，比如密碼、網絡、認證體系、訪問控制、入侵檢測、數字水印等，但是各位只要粗略的瞭解上面的幾個安全維度，就可以很直觀地把這次事件出現問題的大致定位，方便下文針對此次事件的回顧反思。
從安全目標三要素上來看， 這次事件破壞了系統的可用性 ，造成300萬用戶中的核心7萬多用戶的服務不可用，微盟市值蒸發10多億，由於服務中斷對用戶間接損失暫不可估。
從安全基本要素來看， 基本上系統、信息和人員三要素都有不同程度的缺失 ，比如運行安全和數據安全以及人員管理不到位等，這個後文細說。
從安全過程上來看，系統能夠在故障後幾分鐘內識別告警處理，整體響應和恢復過程也還算迅速，因此 主要的問題還是發生在事前的保護環節 。
企業運維安全核心要點
不要把雞蛋放在一個籃子裏——備份的重要性
在服務器業務系統的日常運行過程中，可能會存在人爲誤操作或者一些無法預見性的事件發生，最終導致數據丟失。爲了減輕對業務系統影響，需要最大程度的減小數據丟失，在最短的時間內恢復數據，通過定期執行合理、完善的備份策略，可以在必要時最大限度的減少業務停機時間以及數據丟失所帶來的影響。
無論是磁盤RAID陣列、磁帶冷備份數據，還是兩地三中心的實時備份業務架構，只要能夠定期執行、並保證介質安全（注意，很多企業恢復的時候才發現備份的數據有問題），相信對業務的影響應該有限。
很不幸，這次事件之所以損失如此之大，原因就是生產的備份數據也被刪除了！
顯然，這個核心人員權限足夠大。
權限控制的重要性
針對訪問權限過大的問題，業內使用訪問控制（Access control）來管理用戶對資源的訪問權限，其核心要素是 訪問控制策略的制定 。
訪問控制的策略模型通常有DAC（自主訪問控制）、MAC（強制訪問控制）、RBAC（基於角色的訪問控制模型）三種。
自主訪問控制模型 ：特權用戶爲普通用戶分配訪問權限，可以授予或收回普通用戶的權限，靈活性較高，但是特權用戶的用戶權限太高。
此次事件，這位核心運維人員顯然擁有過高的操作權限了。
強制訪問控制模型 ：相較於DAC，增加了多級訪問控制，每次訪問的主體（提出資源訪問的實體）和客體（被訪問資源實體）都有對應的等級，通過主客體之間的登記比較，決定主體對客體的訪問形式。
基於角色的訪問控制模型 ：引入了組合角色的概念，將主客體進行進一步抽象，是目前大部分系統中常用的解決方案；RBAC模型遵照三個基本模型：
-
最小特權原則
-
最小泄露原則
-
多級安全策略
如果基於角色訪問控制，備份數據和生產數據的訪問權限分開，狀況就會好很多。
操作審計
除了事前控制，在運維過程中，也需要進行審計，最好能實時審計，這樣才能防止有人不遵守規範，從而帶來損失。例如：
- 通過遠程運維審計系統，增加堡壘機進行服務器管理；
- 採用動態令牌等身份ID認證，實現抗抵賴性；
- 運維審計系統可以設計高危指令禁止或提醒確認機制；
人員管理
任你技術通天、嚴防死守，抵不住內部人員一頓操作猛如虎！ 所以，最大的風險永遠不是規章制度、技術手段，而是——人。
所有的流程規則、技術控制，也都是爲了防止人的風險：
- 加強人員的技術培訓和管理培訓，增強安全意識、培養職業道德；
- 對員工以應有的尊重，大多數技術崗位人員，沒有什麼深仇大恨不會做這麼絕；
- 適當分工，小公司爲了節約成本，一個人幹兩個人甚至多個人的活兒，連自己的分內事兒都容易忙中出錯，更別提有人員分擔工作或者A/B互補了；
所有以上建議，無非就是滿足信息安全裏的：可追溯性(Accountability)、抗抵賴性(Non-repudiation)、真實性(Authenticity)、可控性(Controllable)這些原則而已。
上面的這些建議可不是信口開河，都是從血與淚的經驗中總結出來的。
在設計上，自動化運維繫統有以下幾個考慮：
基於BRAC模型的權限控制和認證管理
針對不同角色分配系統、菜單、按鈕權限； 人員和角色可以靈活配置：
所有按鈕操作的權限都可進行細化，防止不具有權限的人進行操作：
所有腳本執行，均納入審批流程，防止單個人員完成整個運維操作：
靈活的認證方式
系統腳本執行引擎與各維護資源均採用互信方式，防止密碼泄露。
提供針對特定場景的獨立主機認證方式管理（只有創建人有權限，密碼採用不可逆加密存儲）。
相對隔離的上下游數據
系統的用戶數據均對接企業內部sso、ldap，防止後門賬戶。
所有操作的資源對象，都是由上游資產管理等類CMDB系統提供，保證了數據的準確性和一致性；同時阻止了未納入系統的資源控制。
人機隔離和安全審計
系統底層通過自動化執行引擎worker訪問機器，隔離了人直接操作機器；
圖形化編排引擎
所有腳本執行均儘量通過圖形化選擇、編排等形式完成，最大可能避免引入人爲錯誤；
同時所有操作（無論系統內部操作還是運維執行）均有審計日誌；
實時查看腳本執行結果：
對於腳本中含有的高危命令，具有 事前識別 的機制 ：
支持定時任務：
內置備份恢復等常用場景：
後記
有了自動化運維繫統的幫助，相信很多企業的員工可以從多個方面減少出錯的機會和概率，降低了被刪庫跑路的風險。
以BeyondBSM自動化運維產品爲核心的運維繫統已經交付多個金融行業客戶使用，其中包括中國某知名卡機構，該套系統在生產環境平穩運行三年多，極大地提高了運維人員的工作效率和便利性 ，支撐企業業務快速穩定發展。