刪庫背後，是許可權管控的缺失

2020 年 3 月 10 日
筆記

「刪庫」事件過去了，微盟數據已經全面找回，並公布了相應的賠付方案。這事兒就算漸漸淡出了人們的視野，觀眾吃瓜一時爽，企業也紛紛順著熱點蹭上來，踩著別人的錯誤往上爬，還能花樣踢腿加劈叉。整個安全圈一片喜氣洋洋。

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

一、原因分析篇

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

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

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

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

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

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

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

二、整體方案篇

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

1.授權-修橋鋪路

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

工單授權

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

優點：按需供給，通過流程嚴格控制訪問許可權。

缺點：需要緊急處理事務時，流程審批耗時會耽誤處理時機。

靜態授權

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

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

優點：許可權管控粒度細

缺點：配置過程相對複雜且難調整

動態授權

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

優點：配置靈活，組合條件多

缺點：許可權查看和搜索比較麻煩

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擁有難以取代的優勢。

*本文作者：船長Plus，轉載請註明來自FreeBuf.COM