安全新基建:阿里資料資產藍圖

2020年年中，一名白帽子在GitHub上發現了某新能源車企的一個後台系統所使用的憑證，該憑證簡單使用了Base64加密。雖然該憑證並不能直接登入對應的後台系統，但是白帽子透過掌握到的API列表，成功找到幾個沒有鑑權的接口，透過這些接口，可以批量獲取後台資料。

這次潛在危機本來應該敲響警鐘，但2020年8月，該車企又遇到了類似安全事件。車主爆料，自己的車輛管控APP上竟然出現了幾輛別人的車。雖然車主回饋給車企之後，車企默默修復了這個問題。白帽們透過分析，一致認為這個問題又是一起典型的介面缺少鑑權的漏洞。

隨著雲端服務的興起，傳統的企業架構形成了目前較常見的雲端+本地的混合部署形態，網路架構也朝向混合部署轉變，傳統的安全防禦已不足以應對混合部署下的威脅。

攻防的本質是資訊不對稱，而漏洞的本質是資料出入口缺乏有效控制。在目前的混合部署情勢下，「我知道我的企業資產有哪些出入口有問題」就顯得極為重要。

產業痛點：盤點自家到底有“多少錢”
這個問題該如何解決，各企業都有自己的探索與實踐。不過在阿里安全看來，問題的根本是企業無法即時掌握自己的資產，尤其是混部結構下的資產。就是我「不知道」我有這些接口，或者我「不知道」這些接口有安全問題。

當然，知道了我有哪些出入口，還遠遠不夠，當評估業務風險時，又會發現一堆問題都沒有得到答案：

l 風險有多大？影響面是多少？

l 現在的防護策略涵蓋了多少？

l 如何判斷策略是否有效？

l 是否還有遺漏在外的資產？

l 還有多少可提升的空間？

這一系列問題需要用具體的安全數據來回答，但是現實情況一點都不樂觀。

不同類型的資產資料散落在各條業務線，一是很難蒐集整合，一是很難理解消化，同時很難進行整體沉澱經驗，不同業務線之間很難復用彼此的業務結果。

我們在期待這樣的“天使同事”，她手裡有我需要的所有“資產數據”，已經幫我把數據都關聯解析完畢，還能根據自己支撐的業務場景，對數據進行了沉澱與打標，你可以完全復用她的方法論，不但可以直接用，還可以根據需要自由組合。

「資產藍圖」就致力於成為這樣的「天使同事」。

資產藍圖的解法
2020年3月，阿里巴巴發表了數位基建新一代安全架構。在新的安全架構下，我們重新思考安全防禦該如何走的時候，急需一個能用數據說明的可量化驅動系統提供資料輸入。這個系統最大的目標就是用數據驅動安全防禦走向，也就是藍圖誕生的背景。

藍圖是一個資產採集系統，專注於梳理、盤點、管理大型企業內網資產，可用於發現企業內網的各類基礎資產資訊、資產指紋、資產間的資料流血緣；並提供了多維度標籤的資產清單，發布成為標籤資產目錄，以滿足業務提出的各類分析應用需求的快速搭建，讓資產流動起來，利用起來，讓數據從業務中而來，最終為業務所用。

「藍圖」的建造目前經歷了四個階段：

第一階段，基礎資產盤點，需要盤點清楚資產範圍、狀態、安全防控狀況，並了解企業內部的主機、應用程式、儲存、中介軟體、供應鏈、原始碼、權限等等相關資源。

第二階段，關聯資產盤點，需要盤點不同類別節點資產之間的存取關係、關聯關係。

第三階段，血緣資產盤點，需要分析資料在南北向（網絡邊界從外到內）、東西向（跨應用資源、跨節點訪問）的流動路徑，畫出資產間的邊界範圍和鏈路血緣流動關係。

第四階段，標籤資產盤點，在資產資料支撐業務需求後，沉澱有針對性的資料標籤，最大化價值。

藍圖選擇這種階梯型的發展計劃，原因之一是每個階段互相支持，但每個階段的成果都是相對獨立可交付使用的。優點是，隨著每個階段的建設完成，可以快速交付每個階段的成果，讓業務快速使用，例如在「基礎資產」盤點階段，主機與應用程式都可以快速交付給業務進行資產盤點。完成基礎資產盤點後，建立主機與應用程式、網域名稱、負責人的關聯關係，可快速進行安全緊急應變、溯源定位。而整個資產大盤可以讓業務方清楚地看到現在的資產全貌，甚至透過大盤看到現在安全水位、資產管理水位以及對應的風險。

血緣資產盤點則是整個系統價值的擴大機。如果說前面兩個節點都是後勤支援，那麼第三個階段之後，藍圖同前線安全團隊，站到了一個戰壕里，可以直接輸出數位化「彈藥」。一旦發現攻擊行為，根據被攻擊的IP位址，安全人員可以快速定位可能受到該伺服器影響的一級、二級影響範圍，並根據一、二級影響機器對應的應用等級，快速評估攻擊風險。

挑戰與風險
藍圖的內部發展雖然可謂是一帆風順，佔據了“天時、地利、人和”，但是在實際發展中仍然面臨了巨大的挑戰。

挑戰一：“能用”
沒有人事先能知道業務都需要哪些資產資料。

業務方需要盤點資產時，大多數情況下所需的資產資料多且雜，不僅包括了已經明確的資產範圍，甚至還要有供應鏈關係、特殊的中間件、小眾的程式碼架構等。沒有數據就意味著，無法對業務方進行有效的支撐。藍圖除了需要有一個標準化的資產資料輸出流程（資料自助申請、介面或視圖輸出資產資料），來滿足大多數業務的需求之外，還需要一個客製化需求的入口，對於業務方自己都沒有明確的資產資料需求的情況，需要跟業務方做詳細的溝通，與業務一起理解所需的資產資料。

最後，藍圖再尋找並引進或生產出業務方所需的資產數據，在這個過程中，一方面滿足了業務的需求，一方面也補全了藍圖自身的資產數據缺口。

挑戰二：“敢用”
沒有準召的數據就沒有價值。

其實，很多公司都做過資產盤點，但大多沒有「做起來」。究其根源，是資產資料沒有「準召」（準確和召回），或上游資產沒有準召，導致下游業務無法穩定使用。

藍圖提供的解法是，投入適當的資源到準召建設中去。依賴自身資產資料檢查經驗，沉澱出具備藍圖特色的可配置化的自動化準召檢查系統，利用該系統，完成如下的檢查與準召：

l 品質基礎監控，主要包括完整性、準確性、一致性、及時性的規則配置沉澱及監控警告處置，其中規則分為通用性規則及自訂規則。

l 多源交叉驗證，實現多個來源與資產資料&連結資料的比較校驗、準召值計算、異常資料監控警告處置，支援自訂SQL以滿足營運多樣化的交叉驗證需求。

l benchmark樣本庫，支援資產&連結的樣本沉澱及使用，支援基於樣本庫的交叉驗證、掃描驗證。

l 人工驗證流程。在無法進行自動化驗證的事物上，投入外包資源，抽取一定數量的樣本，進行人工準召驗證。

挑戰三：“好用”
資產資料的價值不是羅列而是加工。

即便有了全面的資產數據，每一份資產數據都能有準召，如果只是簡單的羅列，那麼這種盤點結果也沒有太高的價值。資產盤點的價值一定是在關聯、加工的結果中反映出來的。

藍圖顯然不會為自己定位成簡單的資產資料堆砌平台，但要怎麼實現1+1>2的放大效果，一直是資產盤點領域的難題。藍圖的入口是血緣資料。

透過自建血緣鏈路的程式碼分析能力，完成應用程式碼的自動化分析，擷取應用程式中的介面呼叫、中間件使用、DB使用等等信息，再結合流量、應用等信息，產生呼叫鏈路與資料鏈路數據，不但解決南北向的邊界資訊流向路徑描畫，也完善了東西向應用間資訊走向路徑。

再結合線上資訊、離線資訊、以及離線資訊之間的血緣分析，產生血緣數據，掌握DB內數據的流動路徑。

最後，應用資料鏈路/呼叫鏈路，加上資料血緣數據，真正實現了從介面到資料庫的全向資料流動路徑分析。

數據的價值體現大部分都在於第二個使用者。

藍圖在服務業務方的同時，積極沉澱業務實際使用需求與經驗，在標準化基礎資料的基礎上，建立具有業務屬性的資產標籤，複用多方業務效果，最大化業務治理的價值。

如在服務於內容安全風險業務場景時，藍圖從技術層面打標具有內容增改邏輯的接口，再結合業務具體使用情況，對接口進行標記。藍圖再結合改進後的邏輯，給其他的介面進行打標。在另外一個專案中，這批具備標籤的內容增改接口，可以直接作為既定接口範圍，根據業務需要，重點做二次篩選即可，不但做到業務價值最大化復用，也真正做到取自業務用於業務。

驅動安全營運
藍圖透過四個階段的發展，依託海量資產數據，建立混合雲架構下的資產盤點系統，協助業務方利用資產數據完成資產盤點、風險識別等等各種業務需求，然後提供標準化的資產使用方案，提供業務方可靠、便捷的高效使用通道。

最終，阿里安全希望，透過客觀資產盤點，驅動阿里安全的建設，就如同人體靜脈圖一樣，藍圖透過清晰地資產盤點，能夠主動發現風險問題，並成為幫助各安全單位進行有效安全運作的手段。