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內資料的流動路徑。

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

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

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

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

驅動安全運營

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

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

本文作者：阿里安全 安全專家 鄭虔