安全測試結(jié)果的可視化過去一直是被低估的環(huán)節(jié)。掃描器出了報(bào)告、滲透測試寫了文檔、修復(fù)完再登記個(gè)Excel等月底復(fù)盤時(shí)才拉出來看一眼中間出了什么風(fēng)險(xiǎn)、修復(fù)進(jìn)展怎么樣、還有多少高危漏洞在裸奔全靠人工腦補(bǔ)。我也是被這個(gè)問題折磨了大半年才下決心把Grafana接入安全測試流程把漏洞數(shù)據(jù)、資產(chǎn)信息、修復(fù)進(jìn)度全部集中到一個(gè)看板上讓團(tuán)隊(duì)成員打開瀏覽器就能看到當(dāng)前的安全態(tài)勢而不是等每周的例會(huì)材料。這篇博文就圍繞這套可視化看板的集成實(shí)踐展開從方案選型、數(shù)據(jù)源接入、看板搭建到告警配置完整記錄我落地這套系統(tǒng)時(shí)踩過的坑和沉淀下來的做法。適合安全工程師、DevOps運(yùn)維人員和測試開發(fā)同學(xué)參考尤其是正在做安全測試結(jié)果聚合但不知道從哪下手的人。1. 項(xiàng)目背景與方案選型為什么安全測試結(jié)果需要可視化看板1.1 安全測試數(shù)據(jù)的現(xiàn)狀痛點(diǎn)先說一個(gè)很現(xiàn)實(shí)的問題安全測試的結(jié)果數(shù)據(jù)天生就是多源異構(gòu)的。漏洞掃描器比如Nessus、AWVS、Xray輸出自己的報(bào)告格式SAST工具報(bào)告一堆代碼缺陷DAST工具跑出一堆URL問題滲透測試的人工發(fā)現(xiàn)還散落在Word和Excel里中間件漏洞、供應(yīng)鏈組件風(fēng)險(xiǎn)又來自另一個(gè)平臺(tái)。想把這些數(shù)據(jù)匯總起來回答幾個(gè)最基礎(chǔ)的問題——當(dāng)前有多少高危漏洞、哪些資產(chǎn)受影響、修復(fù)率是多少——都能讓人焦頭爛額。我見過不少團(tuán)隊(duì)的做法是每周讓安全工程師手動(dòng)導(dǎo)出幾份報(bào)告拼到PPT里。這種做法有兩個(gè)致命問題。一是損耗實(shí)時(shí)性漏洞從發(fā)現(xiàn)到被人看見中間隔了好幾天攻擊者比你還早知道二是損耗細(xì)節(jié)匯總報(bào)告通常只會(huì)保留高危有幾個(gè)、中危有幾個(gè)這類匯總數(shù)字真正排查需要知道的具體漏洞、受影響資產(chǎn)、時(shí)間分布這些信息全部被打平了?？梢暬窗逡鉀Q的就是讓這些數(shù)據(jù)從報(bào)告里的靜態(tài)文字變成屏幕上的實(shí)時(shí)態(tài)勢。不是把報(bào)告變得更漂亮而是把分散的工具結(jié)果統(tǒng)一起來基于同一個(gè)時(shí)間軸、同一套資產(chǎn)維度讓趨勢、變化、分布變得可見且可追蹤。1.2 技術(shù)方案選型的心路歷程選型的核心問題只有一個(gè)數(shù)據(jù)往哪兒放。當(dāng)時(shí)我對比了三類方案。第一類是直接購買商業(yè)的安全運(yùn)營平臺(tái)功能全、開箱即用但價(jià)格高而且通常要綁定自家掃描器我們已有的工具鏈不好接入數(shù)據(jù)模型也被鎖死。第二類是自研一個(gè)小型管理系統(tǒng)后端API加上前端列表頁。這個(gè)方案靈活但開發(fā)成本不低而且做好了也就是個(gè)漏洞管理列表圖表只能自己畫趨勢分析、報(bào)表導(dǎo)出這些功能全要重復(fù)造輪子迭代周期太長。第三類就是Grafana加Prometheus/Loki/MySQL這條路。Grafana本身是可視化平臺(tái)不需要做報(bào)表模塊它的數(shù)據(jù)源插件體系相當(dāng)成熟Prometheus、MySQL、Elasticsearch、Loki都原生支持意味著數(shù)據(jù)只要有地方存就能快速出圖告警功能內(nèi)置配置好通知渠道就能聯(lián)動(dòng)釘釘、郵件和企業(yè)微信。而且社區(qū)插件多后續(xù)想擴(kuò)展也方便。最終我選擇Grafana作為展示層底數(shù)數(shù)據(jù)的存儲(chǔ)根據(jù)不同來源分了三條鏈路實(shí)時(shí)監(jiān)控指標(biāo)走Prometheus日志和掃描結(jié)果詳情走Loki結(jié)構(gòu)化漏洞庫走M(jìn)ySQL。看板連接這三個(gè)數(shù)據(jù)源各取所長。1.3 Grafana在安全測試場景中的定位很多人一提Grafana就想到機(jī)器監(jiān)控CPU、內(nèi)存、網(wǎng)絡(luò)流量覺得這是運(yùn)維的專屬工具。實(shí)際上Grafana的處理對象是時(shí)序指標(biāo)和結(jié)構(gòu)化數(shù)據(jù)安全測試結(jié)果天然符合這個(gè)模型——漏洞發(fā)現(xiàn)時(shí)間是時(shí)間軸風(fēng)險(xiǎn)等級是維度資產(chǎn)IP、團(tuán)隊(duì)歸屬這些是標(biāo)簽。所以Grafana完全可以承載安全測試看板且不需要引入一套全新的安全產(chǎn)品。我推薦的定位方式Grafana只做呈現(xiàn)和告警不承擔(dān)數(shù)據(jù)采集和業(yè)務(wù)邏輯。安全測試的數(shù)據(jù)采集仍然由各掃描器、爬蟲和CI/CD流水線完成通過寫腳本或者接口上報(bào)到存儲(chǔ)層Grafana負(fù)責(zé)把存儲(chǔ)層的數(shù)據(jù)組織成有價(jià)值的視圖。這個(gè)分工讓系統(tǒng)邊界清晰掃描器要換、數(shù)據(jù)格式要改都動(dòng)不到看板本身。2. 數(shù)據(jù)管道與Grafana數(shù)據(jù)源對接讓安全測試數(shù)據(jù)流進(jìn)來2.1 三種數(shù)據(jù)接入路徑的取舍先明確一個(gè)概念Grafana本身不存數(shù)據(jù)它只是問數(shù)據(jù)源要數(shù)據(jù)。所以接入的第一步是想清楚安全測試結(jié)果以什么形式、存在哪里。我實(shí)際落地時(shí)用了三條路徑適配不同類型的數(shù)據(jù)。路徑A結(jié)構(gòu)化漏洞庫入MySQL。這類數(shù)據(jù)格式最規(guī)整——漏洞編號、標(biāo)題、風(fēng)險(xiǎn)等級、受影響資產(chǎn)、發(fā)現(xiàn)時(shí)間、修復(fù)狀態(tài)。適合放在關(guān)系型數(shù)據(jù)庫里Grafana通過MySQL數(shù)據(jù)源查詢做分組統(tǒng)計(jì)和多維篩選。適用于漏洞管理、修復(fù)進(jìn)度追蹤。路徑B采集器指標(biāo)入Prometheus。掃描任務(wù)的執(zhí)行狀態(tài)、掃描耗時(shí)、掃描器自身健康度這類運(yùn)行時(shí)指標(biāo)以指標(biāo)的形式暴露。Prometheus按固定間隔抓取Grafana展示成時(shí)序圖。適用于流水線監(jiān)控、掃描任務(wù)趨勢。路徑C半結(jié)構(gòu)化報(bào)告入Loki。掃描器導(dǎo)出的JSON報(bào)告、系統(tǒng)日志、CI階段輸出不適合拆成字段存數(shù)據(jù)庫直接以日志形式推給Loki。Grafana的LogQL可以解析JSON字段提取漏洞等級、掃描目標(biāo)等信息。適用于滲透測試過程日志、掃描器原始輸出檢索。這三條路徑可以并行。數(shù)據(jù)源頭不一樣進(jìn)存儲(chǔ)的通道不同但最終都匯入同一個(gè)Grafana組織可以在同一塊看板上關(guān)聯(lián)展示。2.2 結(jié)構(gòu)化數(shù)據(jù)表設(shè)計(jì)與入庫腳本我的實(shí)踐是建兩張核心表漏洞主表和資產(chǎn)表。字段設(shè)計(jì)上有幾個(gè)容易被忽視的點(diǎn)單獨(dú)說說。漏洞主表的字段字段名類型說明idbigint自增主鍵vuln_idvarchar(64)漏洞唯一編號通常是掃描器自帶IDtitlevarchar(255)漏洞標(biāo)題severityvarchar(16)嚴(yán)重級別critical/high/medium/lowasset_ipvarchar(64)受影響資產(chǎn)IPasset_namevarchar(128)資產(chǎn)名稱teamvarchar(128)負(fù)責(zé)團(tuán)隊(duì)statusvarchar(16)狀態(tài)open/fixing/fixed/ignoreddiscovered_atdatetime發(fā)現(xiàn)時(shí)間fixed_atdatetime修復(fù)時(shí)間可為空sourcevarchar(64)來源nessus/xray/sast/dast/manualraw_datajson掃描器原始字段留著備用幾個(gè)容易踩坑的設(shè)計(jì)點(diǎn)severity不要用中文用枚舉字符串。中文在分組統(tǒng)計(jì)和過濾時(shí)容易出編碼問題而且告警規(guī)則判斷時(shí)大小寫不敏感容易誤判。asset_ip和asset_name分開存別看它們經(jīng)常是一對一但資產(chǎn)改名或IP復(fù)用很常見拆開才能關(guān)聯(lián)資產(chǎn)歷史。raw_data字段很重要。掃描器報(bào)告經(jīng)常帶一些額外信息CVE編號、CVSS分值、漏洞描述當(dāng)前用不到但后續(xù)做關(guān)聯(lián)分析時(shí)就是寶不需要回頭改表結(jié)構(gòu)。入庫腳本我用Python寫了個(gè)定時(shí)任務(wù)每小時(shí)從掃描平臺(tái)拉一次新增漏洞做增量寫入。關(guān)鍵點(diǎn)是要維護(hù)一個(gè)游標(biāo)位置記錄上次拉取的偏移量避免重復(fù)入庫。首次全量導(dǎo)入沒關(guān)系但增量階段如果每輪都全量拉數(shù)據(jù)量上來后壓力會(huì)很大。import mysql.connector import requests import json def fetch_vulns(last_id): payload {since_id: last_id, limit: 100} resp requests.post(https://scanner.internal/api/v1/vulns, jsonpayload, timeout30) resp.raise_for_status() return resp.json()[data] def sync_vulns(): last_id load_cursor() cnx mysql.connector.connect(usergrafana_ro, password..., host10.0.1.10, databasesecurity_center) cursor cnx.cursor() for vuln in fetch_vulns(last_id): sql INSERT INTO vulns (vuln_id, title, severity, asset_ip, asset_name, team, status, discovered_at, source, raw_data) VALUES (%s, %s, %s, %s, %s, %s, %s, %s, %s, %s) ON DUPLICATE KEY UPDATE titleVALUES(title), severityVALUES(severity) cursor.execute(sql, (vuln[vuln_id], vuln[title], vuln[severity], vuln[asset_ip], vuln[asset_name], vuln[team], vuln[status], vuln[discovered_at], vuln[source], json.dumps(vuln, ensure_asciiFalse))) last_id max(last_id, vuln[id]) cnx.commit() cursor.close() cnx.close() save_cursor(last_id)增量同步的游標(biāo)一定要持久化。我就吃過虧腳本重啟后游標(biāo)丟失結(jié)果從0開始全量同步把數(shù)據(jù)庫連接拖崩了。現(xiàn)在游標(biāo)存在本地文件里腳本每次啟動(dòng)先讀文件再?zèng)Q定從哪里開始拉。2.3 Loki接入掃描報(bào)告日志Loki和Prometheus是同一家公司的產(chǎn)品接入方式很像是老朋友了。在Grafana中添加Loki數(shù)據(jù)源只需要填一個(gè)URL。掃描器報(bào)告的推送我用的Promtail文件監(jiān)聽模式把掃描結(jié)果JSON文件的目錄掛給Promtail新文件出現(xiàn)時(shí)自動(dòng)推送?？窗逯胁樵僉oki數(shù)據(jù)長度這樣寫{appsecurity-scanner} | json | severityhigh | unwrap duration這條查詢的意思選擇app等于security-scanner的日志流解析JSON字段篩出高危漏洞然后把duration字段作為數(shù)值用于圖表繪制。需要注意LogQL的json解析要求日志內(nèi)容是標(biāo)準(zhǔn)JSON單行格式如果是pretty打印的多行JSONPromtail推過來會(huì)解析失敗。這個(gè)坑我踩了不止一次現(xiàn)在掃描器輸出日志前統(tǒng)一先做一次單行化處理。2.4 數(shù)據(jù)源配置的坑與注意事項(xiàng)Grafana數(shù)據(jù)源配置本身不難但有幾個(gè)細(xì)節(jié)值得記住。MySQL數(shù)據(jù)源建議使用只讀賬號?？窗逯恍枰樵儾恍枰獙懭?。用讀寫賬號萬一某條查詢誤觸發(fā)了更新操作后果是很嚴(yán)重的。另外Grafana對MySQL查詢有個(gè)限制默認(rèn)不允許SELECT以外的語句這個(gè)可以保持開啟。連接超時(shí)參數(shù)要設(shè)置。數(shù)據(jù)量大的情況下一條慢查詢可能拖到30秒以上看板加載時(shí)會(huì)轉(zhuǎn)圈很久。我在MySQL數(shù)據(jù)源配置中將timeout設(shè)為10秒查詢超過10秒就直接失敗寧可看板局部加載失敗也不能卡死整個(gè)頁面。Loki查詢?nèi)绻婕案哳l解析建議開啟log volume的緩存。這個(gè)在Loki配置里可以調(diào)減少重復(fù)查詢的負(fù)載。3. 看板設(shè)計(jì)與可視化落地從一堆數(shù)字到一屏了然3.1 看板的分層設(shè)計(jì)思路看板不是把圖表堆在一起就完事了布局和層級直接決定了使用效率。我設(shè)計(jì)的看板分了四個(gè)區(qū)域按照總覽→趨勢→明細(xì)→追蹤的邏輯排布。第一行是核心指標(biāo)卡當(dāng)前未修復(fù)漏洞總數(shù)、高危及以上數(shù)量、本周新增漏洞數(shù)、本周修復(fù)數(shù)、平均修復(fù)時(shí)長。這五個(gè)數(shù)字回答的是當(dāng)前狀態(tài)怎么樣。第二行是趨勢圖漏洞發(fā)現(xiàn)趨勢按天堆疊柱狀圖和修復(fù)趨勢按天折線圖?；卮鸬氖亲罱亲兒眠€是變壞。第三行是分布圖按資產(chǎn)維度的漏洞分布按團(tuán)隊(duì)維度的修復(fù)負(fù)載按來源工具的漏洞占比?；卮鸬氖菃栴}集中在哪。第四行是明細(xì)列表未修復(fù)漏洞的表格支持按嚴(yán)重級別、資產(chǎn)、團(tuán)隊(duì)過濾點(diǎn)擊能跳到關(guān)聯(lián)的資產(chǎn)詳情?；卮鸬氖蔷唧w是哪些漏洞在拖后腿。這個(gè)分層邏輯不是拍腦袋定的。我見過很多看板把幾十個(gè)圖表不分主次全堆在上面結(jié)果打開后大腦一片空白根本不知道先看哪里。核心指標(biāo)卡給結(jié)論趨勢圖給方向分布圖給定位明細(xì)表給抓手一層往下鉆一層。3.2 核心指標(biāo)卡SQL與告警閾值設(shè)定指標(biāo)卡的SQL相對簡單但要寫出正確結(jié)果有幾個(gè)細(xì)節(jié)。以未修復(fù)高危漏洞數(shù)為例這個(gè)查詢在MySQL中的寫法是SELECT COUNT(*) FROM vulns WHERE status IN (open, fixing) AND severity high這里要注意status的取值。漏洞狀態(tài)流轉(zhuǎn)一般是open→fixing→fixed→ignored未修復(fù)應(yīng)該包含open和fixing兩個(gè)狀態(tài)。很多看板只統(tǒng)計(jì)statusopen會(huì)導(dǎo)致同一漏洞進(jìn)入修復(fù)流程后從看板上消失數(shù)字看起來很好看但實(shí)際風(fēng)險(xiǎn)還在那里。本周新增漏洞數(shù)的SQL要小心時(shí)間跨度的邊界SELECT COUNT(*) FROM vulns WHERE discovered_at DATE_SUB(NOW(), INTERVAL 7 DAY)這個(gè)寫法是可以的但如果你希望本周是從周一開始算而不是過去7天就要用YEARWEEK函數(shù)。我在踩了一次周一例會(huì)看板數(shù)字和上周五對不上的坑之后寫了個(gè)統(tǒng)一的時(shí)間定義在變量里加了一個(gè)date_range下拉框默認(rèn)本周可切到近7天、近30天、本季度所有圖表共用同一個(gè)變量口徑才不會(huì)亂。告警閾值方面我給高危未修復(fù)數(shù)設(shè)了三級閾值5個(gè)以下綠色5到10個(gè)黃色超過10個(gè)紅色。這個(gè)閾值不是隨便定的是通過回看歷史三個(gè)月的數(shù)據(jù)算出來的——正常情況下高危未修復(fù)數(shù)在3到8之間波動(dòng)5作為黃色預(yù)警線能捕捉到上升趨勢10作為紅色告警線則意味著某個(gè)環(huán)節(jié)大概率出故障了。3.3 趨勢圖與分布圖的構(gòu)建方法趨勢圖使用Grafana的Time series面板。MySQL數(shù)據(jù)源的表查詢要按時(shí)間維度做分組聚合SELECT DATE_FORMAT(discovered_at, %Y-%m-%d) as day, severity, COUNT(*) as cnt FROM vulns WHERE discovered_at NOW() - INTERVAL 30 DAY GROUP BY day, severity ORDER BY dayGrafana的MySQL查詢支持返回多個(gè)series這套SQL按天級別兩個(gè)維度分組后Time series會(huì)自動(dòng)把不同severity渲染成不同的柱子或線。圖表上的圖例名稱如果顯示的是highcritical之類的枚舉值最好在SQL中用CASE WHEN轉(zhuǎn)一下成中文標(biāo)簽否則領(lǐng)導(dǎo)看的時(shí)候會(huì)問critical是啥意思。SELECT DATE_FORMAT(discovered_at, %Y-%m-%d) as day, CASE severity WHEN critical THEN 嚴(yán)重 WHEN high THEN 高危 WHEN medium THEN 中危 ELSE 低危 END as severity, COUNT(*) as cnt FROM vulns WHERE discovered_at NOW() - INTERVAL 30 DAY GROUP BY day, severity ORDER BY day分布圖我推薦用Bar gauge和Pie chart兩個(gè)面板。資產(chǎn)管理分布用Bar gauge每條柱子代表一個(gè)資產(chǎn)柱子的長度是從高到低的漏洞總數(shù)柱子顏色按最高危級別映射這樣一眼能看出哪個(gè)資產(chǎn)是最需要優(yōu)先處理的。團(tuán)隊(duì)負(fù)載分布用Pie chart展示每個(gè)團(tuán)隊(duì)名下未修復(fù)漏洞的占比這個(gè)圖在周會(huì)上非常有用誰的工作量最重一目了然。3.4 變量模板化的高級應(yīng)用Grafana的變量功能是看板靈活性的關(guān)鍵。我在看板里定義了三個(gè)變量資產(chǎn)分組、團(tuán)隊(duì)、來源工具都是基于MySQL數(shù)據(jù)源做Query變量SELECT DISTINCT team FROM vulns WHERE team ! ORDER BY team變量定義之后所有面板的查詢中都可以引用。以資產(chǎn)分布圖為例子查詢里加上AND team ${team}當(dāng)下拉框選擇安全組時(shí)資產(chǎn)分布圖就只會(huì)展示安全組名下的資產(chǎn)漏洞情況。這個(gè)聯(lián)動(dòng)的價(jià)值在于同一個(gè)看板既可以用作全局總覽也可以選中某個(gè)團(tuán)隊(duì)下鉆查看不需要為每個(gè)團(tuán)隊(duì)單獨(dú)建一塊看板。變量也會(huì)有個(gè)小坑如果某個(gè)下拉框選了空值查詢會(huì)變成AND team 導(dǎo)致部分?jǐn)?shù)據(jù)被過濾掉。解決辦法是在變量的Include All option中設(shè)置一個(gè)All值查詢模板寫成AND ($team all OR team $team)這樣All的時(shí)候不做過濾選中特定團(tuán)隊(duì)時(shí)才過濾。3.5 安全測試看板與監(jiān)控告警看板的區(qū)別最后說一個(gè)容易混淆的點(diǎn)。Grafana的模板庫里有大量現(xiàn)成的服務(wù)器監(jiān)控看板網(wǎng)絡(luò)流量、CPU、磁盤全都有很多新手以為安全測試看板也能直接導(dǎo)入一個(gè)現(xiàn)成模板就行。實(shí)際上這兩類看板的側(cè)重點(diǎn)差別很大監(jiān)控看板關(guān)注系統(tǒng)當(dāng)前是否健康和穩(wěn)定展示的是吞吐量、延遲、錯(cuò)誤率安全測試看板關(guān)注風(fēng)險(xiǎn)暴露面是否在可控范圍展示的是漏洞數(shù)量、修復(fù)時(shí)效、資產(chǎn)暴露情況。所以安全測試看板在導(dǎo)入模板時(shí)不能指望開箱即用數(shù)據(jù)模型就是你要自己先搭好的。我這套看板里的所有面板都是從頭配的沒有用任何現(xiàn)成模板。模板的參考價(jià)值在于學(xué)習(xí)布局和圖表類型的搭配不在于直接套用。4. 告警與通知讓安全風(fēng)險(xiǎn)主動(dòng)找到人4.1 告警規(guī)則與閾值設(shè)計(jì)可視化看板解決的是被動(dòng)查看的問題但真正讓看板產(chǎn)生價(jià)值的是告警——風(fēng)險(xiǎn)出現(xiàn)時(shí)不用等人主動(dòng)打開看板系統(tǒng)直接推消息到相關(guān)人。Grafana的告警規(guī)則支持基于面板查詢配置。我在一個(gè)關(guān)鍵指標(biāo)上配置了告警高危以上未修復(fù)漏洞數(shù)超過10條時(shí)觸發(fā)。詳細(xì)配置如下groups: - name: security_vulns rules: - alert: HighVulnCountTooHigh expr: mysql_vuln_high_count 10 for: 30m labels: severity: page team: security annotations: summary: 高危漏洞數(shù)超過10條當(dāng)前值 {{ $value }} description: 當(dāng)前未修復(fù)高危以上漏洞數(shù)量為 {{ $value }}已超過閾值10條請及時(shí)跟進(jìn)處理。這個(gè)配置有幾個(gè)設(shè)計(jì)考量。for: 30m表示持續(xù)30分鐘才觸發(fā)避免掃描器剛?cè)霂煲慌鷶?shù)據(jù)、團(tuán)隊(duì)還沒來得及處理時(shí)告警反復(fù)橫跳。曾經(jīng)我設(shè)置的for: 5m結(jié)果每次掃描任務(wù)跑完都會(huì)產(chǎn)生一批告警早上一來看到幾十條未讀到最后大家連看都不看了。告警疲勞比沒有告警更可怕。我這里用的是傳統(tǒng)告警引擎的配置方式。如果你使用的是Grafana 9以上的版本建議使用統(tǒng)一告警引擎Unified Alerting直接在界面里配置規(guī)則可以按查詢做區(qū)間判斷也能用表達(dá)式組合多個(gè)條件靈活度更高。4.2 通知渠道接入與分級策略告警要發(fā)到合適的人手里才有效。我配置了三個(gè)通知渠道企業(yè)微信群機(jī)器人、郵件、釘釘。分組策略按嚴(yán)重級別區(qū)分critical級告警直接推群并安全負(fù)責(zé)人high級告警推群不人medium及以下只寫進(jìn)每周匯總郵件。分級方案在告警疲勞和感知度之間取了個(gè)平衡。企業(yè)微信機(jī)器人接入方法很成熟建一個(gè)群添加自定義機(jī)器人拿到Webhook地址在Grafana的通知渠道里新建一個(gè)Webhook類型URL填機(jī)器人的地址消息模板可自定義。模板中可以用{{ commonAnnotations.summary }}和{{ commonLabels.severity }}來引用告警信息。我實(shí)際用下來的消息模板長這樣{ msgtype: text, text: { content: 【安全告警】{{ .CommonAnnotations.summary }}\n詳情{{ .CommonAnnotations.description }}\n時(shí)間{{ .StartsAt }} } }有一點(diǎn)要提前注意Grafana的通知渠道和告警規(guī)則是在不同地方配置的很多新手把Webhook地址填完就以為完事了結(jié)果告警觸發(fā)半天沒人收到消息一查發(fā)現(xiàn)告警規(guī)則里沒有關(guān)聯(lián)這個(gè)通知渠道。在Grafana 9中通知策略Notification policies負(fù)責(zé)把告警路由到對應(yīng)的聯(lián)系人需要單獨(dú)在Alerting→Contact points和Notification policies里各配一遍。4.3 告警靜默與防抖實(shí)戰(zhàn)告警靜默是最容易被忽略但最實(shí)打?qū)嵔鉀Q問題的一個(gè)功能。安全測試場景經(jīng)常出現(xiàn)的情況夜間批量掃描任務(wù)跑完一批低危漏洞入庫觸發(fā)了一堆不痛不癢的告警某資產(chǎn)臨時(shí)下線維護(hù)掃描器連續(xù)幾次連不上導(dǎo)致檢測結(jié)果異常某團(tuán)隊(duì)正在做集中修復(fù)高危數(shù)量在下降通道但還沒降到閾值以下每天固定觸發(fā)一次告警。我在實(shí)踐中為這三種場景分別配置了靜默規(guī)則夜間掃描時(shí)段凌晨0點(diǎn)到6點(diǎn)自動(dòng)靜默非critical告警對特定資產(chǎn)的告警設(shè)置48小時(shí)靜默維護(hù)窗口通過匹配labels里的asset_ip對正在修復(fù)的團(tuán)隊(duì)設(shè)置了serialized告警即同一規(guī)則在6小時(shí)內(nèi)只通知一次。Grafana的靜默配置在Alerting→Silences中可以創(chuàng)建支持基于label匹配器精確匹配。創(chuàng)建時(shí)最關(guān)鍵的是設(shè)定合理的持續(xù)時(shí)間時(shí)間到了自動(dòng)過期不用手動(dòng)清理。我建議規(guī)則中務(wù)必帶上team或asset_ip標(biāo)簽否則靜默只能按整條規(guī)則全局匹配粒度太粗。5. 常見問題與排查技巧實(shí)錄踩過的坑都在這5.1 數(shù)據(jù)時(shí)間與看板趨勢對不上問題這是我最先遇到、也是咨詢最多的問題MySQL里明明有數(shù)據(jù)但看板上的趨勢圖出現(xiàn)斷層或數(shù)據(jù)點(diǎn)完全不顯示。排查思路一Grafana默認(rèn)使用瀏覽器的時(shí)區(qū)。如果瀏覽器時(shí)區(qū)是UTC而MySQL中存儲(chǔ)的是北京時(shí)間那么discovered_at字段在查詢時(shí)會(huì)被Grafana按UTC時(shí)間處理導(dǎo)致數(shù)據(jù)偏移8小時(shí)。體現(xiàn)在圖表上就是當(dāng)天數(shù)據(jù)少了幾小時(shí)。解決辦法是在Grafana的Preferences中把時(shí)區(qū)設(shè)置為Asia/Shanghai或者在數(shù)據(jù)源配置中指定time_zone參數(shù)。排查思路二時(shí)間字段格式不標(biāo)準(zhǔn)。MySQL的datetime類型沒問題但如果你把時(shí)間存成字符串Grafana的MySQL插件能識(shí)別標(biāo)準(zhǔn)的YYYY-MM-DD HH:MM:SS格式識(shí)別不了2024-01-01T00:00:00Z這種ISO帶時(shí)區(qū)的格式。我遇到過一次是因?yàn)槟炒螌?dǎo)入腳本用了Python的isoformat()導(dǎo)致了這個(gè)問題。排查思路三查詢條件中的時(shí)間范圍寫錯(cuò)。Grafana在面板中通過$__timeFrom和$__timeTo宏來限定時(shí)間范圍如果SQL中忘了寫WHERE discovered_at $__timeFrom就會(huì)出現(xiàn)在面板設(shè)定時(shí)間范圍外查全部數(shù)據(jù)的風(fēng)險(xiǎn)數(shù)據(jù)量大時(shí)查詢會(huì)很慢。-- 正確寫法使用Grafana宏限定時(shí)間范圍 SELECT DATE_FORMAT(discovered_at, %Y-%m-%d) as day, COUNT(*) as cnt FROM vulns WHERE discovered_at $__timeFrom AND discovered_at $__timeTo GROUP BY day5.2 JSON日志解析失敗問題用Loki做半結(jié)構(gòu)化數(shù)據(jù)解析時(shí)最常見的問題是日志推上去了但查不出來字段。這個(gè)情況十有八九是日志格式不是標(biāo)準(zhǔn)單行JSON。Promtail默認(rèn)按行讀取文件如果你的JSON報(bào)告是格式化過的、有換行縮進(jìn)Promtail會(huì)把整個(gè)JSON按單行推上來嗎不會(huì)它會(huì)按換行切成多行每一行都不完整LogQL的| json解析自然失敗。解決方案有幾個(gè)我最終用的是在采集端做預(yù)處理寫了個(gè)小腳本把掃描器的結(jié)果先通過json.dumps壓縮成單行再丟棄到一個(gè)output.json文件里Promtail只監(jiān)聽這個(gè)文件。這樣改動(dòng)只影響采集側(cè)不影響原始報(bào)告存檔。還有一個(gè)排查技巧Loki的Explore頁面可以直接查看原始日志流。如果你發(fā)現(xiàn)某個(gè)日志流的content字段是一大段帶縮進(jìn)的JSON基本就能判定是格式問題。用{appsecurity-scanner} | vuln這樣的查詢手動(dòng)確認(rèn)解析效果是一條快捷的排查路徑。5.3 MySQL查詢性能問題隨著漏洞數(shù)據(jù)不斷累積vulns表到了百萬行級別后看板的加載速度肉眼可見地變慢。我遇到的性能優(yōu)化有幾個(gè)關(guān)鍵動(dòng)作第一個(gè)是索引。critical查詢中經(jīng)常使用到status、severity、discovered_at這三個(gè)字段的組合。我給vulns表創(chuàng)建了復(fù)合索引ALTER TABLE vulns ADD INDEX idx_status_severity_time (status, severity, discovered_at);這個(gè)索引直接讓按狀態(tài)級別時(shí)間范圍過濾的查詢從全表掃描變成索引range scan加載速度提升了大概10倍。第二個(gè)是聚合查詢的優(yōu)化。跟監(jiān)控系統(tǒng)一樣Grafana的趨勢圖是按小時(shí)甚至按分鐘拉數(shù)據(jù)的存儲(chǔ)層做了預(yù)聚合就快很多。我在MySQL里加了一張vulns_daily_summary表每天跑一個(gè)定時(shí)任務(wù)統(tǒng)計(jì)當(dāng)天的漏洞增量、修復(fù)量、各級別數(shù)量趨勢圖直接查這張匯總表明細(xì)列表才去查大表。這樣看板響應(yīng)速度和底表數(shù)據(jù)量基本解耦了。第三個(gè)是做數(shù)據(jù)歸檔。超過一年的已修復(fù)漏洞定期移到vulns_archive表主表只保留活躍和近一年的數(shù)據(jù)查詢性能才有保障。5.4 看板顯示權(quán)限與多團(tuán)隊(duì)隔離當(dāng)看板要開放給多個(gè)團(tuán)隊(duì)查看時(shí)權(quán)限隔離就成了繞不開的問題。安全團(tuán)隊(duì)希望所有團(tuán)隊(duì)都能看到自己名下的漏洞但又不希望A團(tuán)隊(duì)看到B團(tuán)隊(duì)的數(shù)據(jù)。Grafana的實(shí)現(xiàn)方式是通過組織和文件夾來配置權(quán)限。方案是創(chuàng)建安全運(yùn)營組織Organization統(tǒng)一管理所有看板。按團(tuán)隊(duì)創(chuàng)建文件夾每個(gè)團(tuán)隊(duì)的看板放在對應(yīng)的文件夾下。在文件夾的Permissions中添加對應(yīng)團(tuán)隊(duì)并對齊角色為Viewer。核心敏感看板如全局總覽只對管理員開放普通用戶可以訪問但看不到。如果同一塊看板想讓不同用戶只看到自己團(tuán)隊(duì)的數(shù)據(jù)則要利用變量加數(shù)據(jù)權(quán)限控制。Grafana企業(yè)版有基于標(biāo)簽的權(quán)限控制但社區(qū)版沒有。我的替代方案是按團(tuán)隊(duì)拆分變量為每個(gè)用戶配置獨(dú)立的首頁看板URLURL中帶上團(tuán)隊(duì)參數(shù)例如/d/vuln-board?var-teamsecurity。用戶打開的就是過濾后的視圖不需要進(jìn)入編輯模式就能看到對應(yīng)數(shù)據(jù)。這個(gè)方案不完美但勝在簡單可落地。5.5 常見問題速查表問題現(xiàn)象可能原因解決方案趨勢圖時(shí)間偏移數(shù)小時(shí)時(shí)區(qū)不匹配Grafana Preferences設(shè)置為Asia/Shanghai趨勢圖數(shù)據(jù)斷層時(shí)間字段為字符串格式統(tǒng)一改為datetime類型日志解析后無字段JSON多行格式預(yù)處理壓縮為單行JSON看板加載很慢缺少復(fù)合索引添加(status, severity, discovered_at)索引告警反復(fù)觸發(fā)for配置過短設(shè)置for為30m或更長消息沒收到通知策略未關(guān)聯(lián)在Alerting中檢查聯(lián)系點(diǎn)和路由部分圖表顯示No data變量空值過濾查詢中使用($var all OR field $var)用戶可以看到其他團(tuán)隊(duì)數(shù)據(jù)權(quán)限配置不對按文件夾設(shè)置團(tuán)隊(duì)權(quán)限最后分享一個(gè)個(gè)人體會(huì)看板的價(jià)值不取決于圖表的數(shù)量取決于團(tuán)隊(duì)是否真正依賴它做日常決策。這套系統(tǒng)上線頭一個(gè)月大家還是會(huì)習(xí)慣性地問最近漏洞情況怎么樣到第二個(gè)月、第三個(gè)月他們已經(jīng)開始主動(dòng)盯著高危數(shù)量那個(gè)指標(biāo)卡一旦變黃變紅就來找安全團(tuán)隊(duì)問情況——這時(shí)候看板才算真正長在了流程里而不只是一個(gè)偶爾打開的展示屏。先從一個(gè)核心指標(biāo)卡開始跑通數(shù)據(jù)鏈路再逐步增加圖表和告警規(guī)則是這套方案落地時(shí)最穩(wěn)妥的推進(jìn)節(jié)奏。