“刪庫”事件過去了，微盟原計劃28號恢復商家服務，這事兒就算漸漸淡出了人們的視野，如今又好巧不巧被創始人的魔幻輿論推得一浪更比一浪高。

觀眾吃瓜一時爽，企業也紛紛順著熱點蹭上來，踩著別人的錯誤往上爬，還能花樣踢腿加劈叉。整個安全圈一片喜氣洋洋。

實際上大家彼此心知肚明，這次事件只需要最簡單的雙人復核就能避免，多一次打擾，少虧12億。那么為什么最初級的操作也做不到呢?

一、原因分析篇

有人指出這次“刪庫”原因是微盟沒有使用堡壘機，僅僅如此嗎?

愛因斯坦說，問題往往不會在它發生的那個層面得到解決。

現在很多互聯網公司對自己的技術非常有信心，為了節省成本，會選擇基于開源軟件自主研發安全產品。但在設計產品和管理產品的過程中，難免缺乏專業經驗。

專業的人做專業的事。脫離錢去談安全，就有可能丟了**還套不著狼。

“刪庫”這么狗血的事情已經在歷史上重演很多次了，有蓄意破壞的，也有失手誤刪的，歸根結底，都是人的因素。當你大門敞開，這庫就遲早要刪，即便現在沒有動機，也不能保證沒有手誤的可能。

人永遠存在犯錯的可能性，而安全又是一個神奇的四兩撥千斤的問題，任何一點小錯誤都有發展成大規模破壞的潛力。因此運維安全的第一步，就是對“人”的權限管控。

構建成熟的權限管控體系，才能最小化排除人的不穩定因素。

二、整體方案篇

數據中心內的運維安全體系分為身份驗證，授權，訪問控制，審計和主機防護5個方面，而其中的授權+訪問控制實現權限管控。從字面意義上理解：授權就是授予相應的人相應的權限(人+賬號+資產)，訪問控制就是在人在獲得權限之后允許做哪些事情不允許做哪些事情(時間+地點+操作)。二者本質上是一個授予和執行的關系。

1. 授權-修橋鋪路

在數據中心內，根據業務場景的不同有三種授權通道：工單申請、動態授權、靜態授權。

(1) 工單授權

操作人員根據每天需要處理的事務向部門領導提交工單申請，包括：服務器IP、賬號、運維事項、時間范圍等，領導審批后操作人員才可在堡壘機中查看到申請的訪問權限。

• 優點：按需供給，通過流程嚴格控制訪問權限。
• 缺點：需要緊急處理事務時，流程審批耗時會耽誤處理時機。

(2) 靜態授權

對于人員固定，訪問目標固定且低風險的訪問權限可以使用靜態授權，如：張三每周一至周五早上9點到10點之間都需要對備份機做巡檢，巡檢用到的賬號是一個只讀的低權賬號。

在執行授權的過程中，通常會伴隨常規策略設置，定義基礎權限，主要包括人、賬號、資產，偶爾也會涉及到事件、地點、操作等策略配置。

• 優點：權限管控粒度細
• 缺點：配置過程相對復雜且難調整

(3) 動態授權

相對于靜態授權的條目多，配置復雜，動態授權提供了一種按屬性，按標簽的更便捷的配置方式。例如：按用戶部門(系統，數據庫，網絡)，角色(管理員，值班員)，設備類型(主機，數據庫，中間件)，業務系統(網銀，手機銀行)等，根據標記自動生成訪問權限，實現動態授權。

• 優點：配置靈活，組合條件多
• 缺點：權限查看和搜索比較麻煩

2. 訪問控制-分道限速

授權階段足以滿足登陸訪問的基礎需求了，然而不足以將“人”的風險降至最低。訪問控制則是對“人的行為”進行風險控制的強力補充。

通過時間策略、源地址策略、操作規則的進一步設置，連同人、賬號、資產的基礎權限，形成六維細粒度權限管控體系，實現權限最小化管理。

• 時間條件：按時間維度縮小權限范圍，比如：2020年1月1日9:00 -10：00，每周一至周五00:00-02:00
• 源地址條件：按IP地址為度縮小權限范圍，比如：只允許在192.168.1.10-20地址范圍訪問
• 操作條件：按指令，剪貼板上下行，磁盤映射，文件傳輸上下行等縮小權限范圍，比如：不允許支持rm -rf *，只允許文件上傳不允許下載
• 控制動作：當觸發以上規則時系統執行相應的動作，比如：不阻斷但發郵件報警，阻斷并發syslog，等待管理員審批等。

目前常見的幾種權限管控包括：ACL(基于黑白名單)【1】、RBAC(基于角色)【2】、ABAC(基于屬性)【3】，在不同的業務場景下，適配不同的技術手段。

三、結語

不得不承認，權限管控是一件干起來十分吃力又不討好的事情，安全本身看不見效果。即便是比較好的自動化平臺，至少也需要人來審批。從前期準備到后期運用，很容易形成成本升高、效率卻降低的局面。

的確，樹上的果子摘下來就能吃，何必要洗一遍呢?

但最近這個世界在告誡我們，你不知道那個果子有沒有被果蝠碰過。

愿大家身體健康，也愿行業更健康。

Reference：

• 【1】ACL(Access Control List)訪問控制表，基于白名單和黑名單提供決策依據，其中，白名單用于允許，黑名單用于拒絕。通過訪問控制模塊，對數據進行匹配，命中則執行設定的動作。比較常見的場景：傳統防火墻策略。
• 【2】RBAC(Role-BasedAccess Control)基于角色的訪問控制，常見于軟件管理系統的用戶分權。與ACL中一一對應的授權執行關系不同，RBAC引入了角色(role)，與操作權限和資源權限相關聯，適合在操作權限和資源權限控制簡單，且相對固化，但人員變更頻繁的場景下使用。比較常見的場景：數據庫的用戶角色(role)管理。
• 【3】ABAC(Attribute-BasedAccess Control)基于屬性的訪問控制，常見于分布式業務場景的用戶分權。ABAC是一種貼近自然語言的權限控制模型，抽取異構場景的共性屬性，用屬性的自然組合來解決權限控制問題。針對復雜、分布式、動態、細粒度的權限管控要求，ABAC擁有難以取代的優勢。