安全測(cè)試結(jié)果的可視化過去一直是被低估的環(huán)節(jié)。掃描器出了報(bào)告、滲透測(cè)試寫了文檔、修復(fù)完再登記個(gè)Excel等月底復(fù)盤時(shí)才拉出來看一眼中間出了什么風(fēng)險(xiǎn)、修復(fù)進(jìn)展怎么樣、還有多少高危漏洞在裸奔全靠人工腦補(bǔ)。我也是被這個(gè)問題折磨了大半年才下決心把Grafana接入安全測(cè)試流程把漏洞數(shù)據(jù)、資產(chǎn)信息、修復(fù)進(jìn)度全部集中到一個(gè)看板上讓團(tuán)隊(duì)成員打開瀏覽器就能看到當(dāng)前的安全態(tài)勢(shì)而不是等每周的例會(huì)材料。這篇博文就圍繞這套可視化看板的集成實(shí)踐展開從方案選型、數(shù)據(jù)源接入、看板搭建到告警配置完整記錄我落地這套系統(tǒng)時(shí)踩過的坑和沉淀下來的做法。適合安全工程師、DevOps運(yùn)維人員和測(cè)試開發(fā)同學(xué)參考尤其是正在做安全測(cè)試結(jié)果聚合但不知道從哪下手的人。1. 項(xiàng)目背景與方案選型為什么安全測(cè)試結(jié)果需要可視化看板1.1 安全測(cè)試數(shù)據(jù)的現(xiàn)狀痛點(diǎn)先說一個(gè)很現(xiàn)實(shí)的問題安全測(cè)試的結(jié)果數(shù)據(jù)天生就是多源異構(gòu)的。漏洞掃描器比如Nessus、AWVS、Xray輸出自己的報(bào)告格式SAST工具報(bào)告一堆代碼缺陷DAST工具跑出一堆URL問題滲透測(cè)試的人工發(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í)間分布這些信息全部被打平了。可視化看板要解決的就是讓這些數(shù)據(jù)從報(bào)告里的靜態(tài)文字變成屏幕上的實(shí)時(shí)態(tài)勢(shì)。不是把報(bào)告變得更漂亮而是把分散的工具結(jié)果統(tǒng)一起來基于同一個(gè)時(shí)間軸、同一套資產(chǎn)維度讓趨勢(shì)、變化、分布變得可見且可追蹤。1.2 技術(shù)方案選型的心路歷程選型的核心問題只有一個(gè)數(shù)據(jù)往哪兒放。當(dāng)時(shí)我對(duì)比了三類方案。第一類是直接購(gòu)買商業(yè)的安全運(yùn)營(yíng)平臺(tái)功能全、開箱即用但價(jià)格高而且通常要綁定自家掃描器我們已有的工具鏈不好接入數(shù)據(jù)模型也被鎖死。第二類是自研一個(gè)小型管理系統(tǒng)后端API加上前端列表頁(yè)。這個(gè)方案靈活但開發(fā)成本不低而且做好了也就是個(gè)漏洞管理列表圖表只能自己畫趨勢(shì)分析、報(bào)表導(dǎo)出這些功能全要重復(fù)造輪子迭代周期太長(zhǎng)。第三類就是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)化漏洞庫(kù)走M(jìn)ySQL?？窗暹B接這三個(gè)數(shù)據(jù)源各取所長(zhǎng)。1.3 Grafana在安全測(cè)試場(chǎng)景中的定位很多人一提Grafana就想到機(jī)器監(jiān)控CPU、內(nèi)存、網(wǎng)絡(luò)流量覺得這是運(yùn)維的專屬工具。實(shí)際上Grafana的處理對(duì)象是時(shí)序指標(biāo)和結(jié)構(gòu)化數(shù)據(jù)安全測(cè)試結(jié)果天然符合這個(gè)模型——漏洞發(fā)現(xiàn)時(shí)間是時(shí)間軸風(fēng)險(xiǎn)等級(jí)是維度資產(chǎn)IP、團(tuán)隊(duì)歸屬這些是標(biāo)簽。所以Grafana完全可以承載安全測(cè)試看板且不需要引入一套全新的安全產(chǎn)品。我推薦的定位方式Grafana只做呈現(xiàn)和告警不承擔(dān)數(shù)據(jù)采集和業(yè)務(wù)邏輯。安全測(cè)試的數(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ù)源對(duì)接讓安全測(cè)試數(shù)據(jù)流進(jìn)來2.1 三種數(shù)據(jù)接入路徑的取舍先明確一個(gè)概念Grafana本身不存數(shù)據(jù)它只是問數(shù)據(jù)源要數(shù)據(jù)。所以接入的第一步是想清楚安全測(cè)試結(jié)果以什么形式、存在哪里。我實(shí)際落地時(shí)用了三條路徑適配不同類型的數(shù)據(jù)。路徑A結(jié)構(gòu)化漏洞庫(kù)入MySQL。這類數(shù)據(jù)格式最規(guī)整——漏洞編號(hào)、標(biāo)題、風(fēng)險(xiǎn)等級(jí)、受影響資產(chǎn)、發(fā)現(xiàn)時(shí)間、修復(fù)狀態(tài)。適合放在關(guān)系型數(shù)據(jù)庫(kù)里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ù)趨勢(shì)。路徑C半結(jié)構(gòu)化報(bào)告入Loki。掃描器導(dǎo)出的JSON報(bào)告、系統(tǒng)日志、CI階段輸出不適合拆成字段存數(shù)據(jù)庫(kù)直接以日志形式推給Loki。Grafana的LogQL可以解析JSON字段提取漏洞等級(jí)、掃描目標(biāo)等信息。適用于滲透測(cè)試過程日志、掃描器原始輸出檢索。這三條路徑可以并行。數(shù)據(jù)源頭不一樣進(jìn)存儲(chǔ)的通道不同但最終都匯入同一個(gè)Grafana組織可以在同一塊看板上關(guān)聯(lián)展示。2.2 結(jié)構(gòu)化數(shù)據(jù)表設(shè)計(jì)與入庫(kù)腳本我的實(shí)踐是建兩張核心表漏洞主表和資產(chǎn)表。字段設(shè)計(jì)上有幾個(gè)容易被忽視的點(diǎn)單獨(dú)說說。漏洞主表的字段字段名類型說明idbigint自增主鍵vuln_idvarchar(64)漏洞唯一編號(hào)通常是掃描器自帶IDtitlevarchar(255)漏洞標(biāo)題severityvarchar(16)嚴(yán)重級(jí)別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)常是一對(duì)一但資產(chǎn)改名或IP復(fù)用很常見拆開才能關(guān)聯(lián)資產(chǎn)歷史。raw_data字段很重要。掃描器報(bào)告經(jīng)常帶一些額外信息CVE編號(hào)、CVSS分值、漏洞描述當(dāng)前用不到但后續(xù)做關(guān)聯(lián)分析時(shí)就是寶不需要回頭改表結(jié)構(gòu)。入庫(kù)腳本我用Python寫了個(gè)定時(shí)任務(wù)每小時(shí)從掃描平臺(tái)拉一次新增漏洞做增量寫入。關(guān)鍵點(diǎn)是要維護(hù)一個(gè)游標(biāo)位置記錄上次拉取的偏移量避免重復(fù)入庫(kù)。首次全量導(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ù)庫(kù)連接拖崩了?，F(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ù)長(zhǎng)度這樣寫{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ù)源建議使用只讀賬號(hào)?？窗逯恍枰樵儾恍枰獙懭搿Ｓ米x寫賬號(hào)萬一某條查詢誤觸發(fā)了更新操作后果是很嚴(yán)重的。另外Grafana對(duì)MySQL查詢有個(gè)限制默認(rèn)不允許SELECT以外的語句這個(gè)可以保持開啟。連接超時(shí)參數(shù)要設(shè)置。數(shù)據(jù)量大的情況下一條慢查詢可能拖到30秒以上看板加載時(shí)會(huì)轉(zhuǎn)圈很久。我在MySQL數(shù)據(jù)源配置中將timeout設(shè)為10秒查詢超過10秒就直接失敗寧可看板局部加載失敗也不能卡死整個(gè)頁(yè)面。Loki查詢?nèi)绻婕案哳l解析建議開啟log volume的緩存。這個(gè)在Loki配置里可以調(diào)減少重復(fù)查詢的負(fù)載。3. 看板設(shè)計(jì)與可視化落地從一堆數(shù)字到一屏了然3.1 看板的分層設(shè)計(jì)思路看板不是把圖表堆在一起就完事了布局和層級(jí)直接決定了使用效率。我設(shè)計(jì)的看板分了四個(gè)區(qū)域按照總覽→趨勢(shì)→明細(xì)→追蹤的邏輯排布。第一行是核心指標(biāo)卡當(dāng)前未修復(fù)漏洞總數(shù)、高危及以上數(shù)量、本周新增漏洞數(shù)、本周修復(fù)數(shù)、平均修復(fù)時(shí)長(zhǎng)。這五個(gè)數(shù)字回答的是當(dāng)前狀態(tài)怎么樣。第二行是趨勢(shì)圖漏洞發(fā)現(xiàn)趨勢(shì)按天堆疊柱狀圖和修復(fù)趨勢(shì)按天折線圖?；卮鸬氖亲罱亲兒眠€是變壞。第三行是分布圖按資產(chǎn)維度的漏洞分布按團(tuán)隊(duì)維度的修復(fù)負(fù)載按來源工具的漏洞占比。回答的是問題集中在哪。第四行是明細(xì)列表未修復(fù)漏洞的表格支持按嚴(yán)重級(jí)別、資產(chǎn)、團(tuán)隊(duì)過濾點(diǎn)擊能跳到關(guān)聯(lián)的資產(chǎn)詳情?；卮鸬氖蔷唧w是哪些漏洞在拖后腿。這個(gè)分層邏輯不是拍腦袋定的。我見過很多看板把幾十個(gè)圖表不分主次全堆在上面結(jié)果打開后大腦一片空白根本不知道先看哪里。核心指標(biāo)卡給結(jié)論趨勢(shì)圖給方向分布圖給定位明細(xì)表給抓手一層往下鉆一層。3.2 核心指標(biāo)卡SQL與告警閾值設(shè)定指標(biāo)卡的SQL相對(duì)簡(jiǎn)單但要寫出正確結(jié)果有幾個(gè)細(xì)節(jié)。以未修復(fù)高危漏洞數(shù)為例這個(gè)查詢?cè)贛ySQL中的寫法是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ù)字和上周五對(duì)不上的坑之后寫了個(gè)統(tǒng)一的時(shí)間定義在變量里加了一個(gè)date_range下拉框默認(rèn)本周可切到近7天、近30天、本季度所有圖表共用同一個(gè)變量口徑才不會(huì)亂。告警閾值方面我給高危未修復(fù)數(shù)設(shè)了三級(jí)閾值5個(gè)以下綠色5到10個(gè)黃色超過10個(gè)紅色。這個(gè)閾值不是隨便定的是通過回看歷史三個(gè)月的數(shù)據(jù)算出來的——正常情況下高危未修復(fù)數(shù)在3到8之間波動(dòng)5作為黃色預(yù)警線能捕捉到上升趨勢(shì)10作為紅色告警線則意味著某個(gè)環(huán)節(jié)大概率出故障了。3.3 趨勢(shì)圖與分布圖的構(gòu)建方法趨勢(shì)圖使用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按天級(jí)別兩個(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)柱子的長(zhǎng)度是從高到低的漏洞總數(shù)柱子顏色按最高危級(jí)別映射這樣一眼能看出哪個(gè)資產(chǎn)是最需要優(yōu)先處理的。團(tuán)隊(duì)負(fù)載分布用Pie chart展示每個(gè)團(tuán)隊(duì)名下未修復(fù)漏洞的占比這個(gè)圖在周會(huì)上非常有用誰的工作量最重一目了然。3.4 變量模板化的高級(jí)應(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 安全測(cè)試看板與監(jiān)控告警看板的區(qū)別最后說一個(gè)容易混淆的點(diǎn)。Grafana的模板庫(kù)里有大量現(xiàn)成的服務(wù)器監(jiān)控看板網(wǎng)絡(luò)流量、CPU、磁盤全都有很多新手以為安全測(cè)試看板也能直接導(dǎo)入一個(gè)現(xiàn)成模板就行。實(shí)際上這兩類看板的側(cè)重點(diǎn)差別很大監(jiān)控看板關(guān)注系統(tǒng)當(dāng)前是否健康和穩(wěn)定展示的是吞吐量、延遲、錯(cuò)誤率安全測(cè)試看板關(guān)注風(fēng)險(xiǎn)暴露面是否在可控范圍展示的是漏洞數(shù)量、修復(fù)時(shí)效、資產(chǎn)暴露情況。所以安全測(cè)試看板在導(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條請(qǐng)及時(shí)跟進(jìn)處理。這個(gè)配置有幾個(gè)設(shè)計(jì)考量。for: 30m表示持續(xù)30分鐘才觸發(fā)避免掃描器剛?cè)霂?kù)一批數(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 通知渠道接入與分級(jí)策略告警要發(fā)到合適的人手里才有效。我配置了三個(gè)通知渠道企業(yè)微信群機(jī)器人、郵件、釘釘。分組策略按嚴(yán)重級(jí)別區(qū)分critical級(jí)告警直接推群并安全負(fù)責(zé)人high級(jí)告警推群不人medium及以下只寫進(jìn)每周匯總郵件。分級(jí)方案在告警疲勞和感知度之間取了個(gè)平衡。企業(yè)微信機(jī)器人接入方法很成熟建一個(gè)群添加自定義機(jī)器人拿到Webhook地址在Grafana的通知渠道里新建一個(gè)Webhook類型URL填機(jī)器人的地址消息模板可自定義。模板中可以用{{ commonAnnotations.summary }}和{{ commonLabels.severity }}來引用告警信息。我實(shí)際用下來的消息模板長(zhǎng)這樣{ 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é)把告警路由到對(duì)應(yīng)的聯(lián)系人需要單獨(dú)在Alerting→Contact points和Notification policies里各配一遍。4.3 告警靜默與防抖實(shí)戰(zhàn)告警靜默是最容易被忽略但最實(shí)打?qū)嵔鉀Q問題的一個(gè)功能。安全測(cè)試場(chǎng)景經(jīng)常出現(xiàn)的情況夜間批量掃描任務(wù)跑完一批低危漏洞入庫(kù)觸發(fā)了一堆不痛不癢的告警某資產(chǎn)臨時(shí)下線維護(hù)掃描器連續(xù)幾次連不上導(dǎo)致檢測(cè)結(jié)果異常某團(tuán)隊(duì)正在做集中修復(fù)高危數(shù)量在下降通道但還沒降到閾值以下每天固定觸發(fā)一次告警。我在實(shí)踐中為這三種場(chǎng)景分別配置了靜默規(guī)則夜間掃描時(shí)段凌晨0點(diǎn)到6點(diǎn)自動(dòng)靜默非critical告警對(duì)特定資產(chǎn)的告警設(shè)置48小時(shí)靜默維護(hù)窗口通過匹配labels里的asset_ip對(duì)正在修復(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í)間與看板趨勢(shì)對(duì)不上問題這是我最先遇到、也是咨詢最多的問題MySQL里明明有數(shù)據(jù)但看板上的趨勢(shì)圖出現(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頁(yè)面可以直接查看原始日志流。如果你發(fā)現(xiàn)某個(gè)日志流的content字段是一大段帶縮進(jìn)的JSON基本就能判定是格式問題。用{appsecurity-scanner} | vuln這樣的查詢手動(dòng)確認(rèn)解析效果是一條快捷的排查路徑。5.3 MySQL查詢性能問題隨著漏洞數(shù)據(jù)不斷累積vulns表到了百萬行級(jí)別后看板的加載速度肉眼可見地變慢。我遇到的性能優(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)級(jí)別時(shí)間范圍過濾的查詢從全表掃描變成索引range scan加載速度提升了大概10倍。第二個(gè)是聚合查詢的優(yōu)化。跟監(jiān)控系統(tǒng)一樣Grafana的趨勢(shì)圖是按小時(shí)甚至按分鐘拉數(shù)據(jù)的存儲(chǔ)層做了預(yù)聚合就快很多。我在MySQL里加了一張vulns_daily_summary表每天跑一個(gè)定時(shí)任務(wù)統(tǒng)計(jì)當(dāng)天的漏洞增量、修復(fù)量、各級(jí)別數(shù)量趨勢(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)營(yíng)組織Organization統(tǒng)一管理所有看板。按團(tuán)隊(duì)創(chuàng)建文件夾每個(gè)團(tuán)隊(duì)的看板放在對(duì)應(yīng)的文件夾下。在文件夾的Permissions中添加對(duì)應(yīng)團(tuán)隊(duì)并對(duì)齊角色為Viewer。核心敏感看板如全局總覽只對(duì)管理員開放普通用戶可以訪問但看不到。如果同一塊看板想讓不同用戶只看到自己團(tuán)隊(duì)的數(shù)據(jù)則要利用變量加數(shù)據(jù)權(quán)限控制。Grafana企業(yè)版有基于標(biāo)簽的權(quán)限控制但社區(qū)版沒有。我的替代方案是按團(tuán)隊(duì)拆分變量為每個(gè)用戶配置獨(dú)立的首頁(yè)看板URLURL中帶上團(tuán)隊(duì)參數(shù)例如/d/vuln-board?var-teamsecurity。用戶打開的就是過濾后的視圖不需要進(jìn)入編輯模式就能看到對(duì)應(yīng)數(shù)據(jù)。這個(gè)方案不完美但勝在簡(jiǎn)單可落地。5.5 常見問題速查表問題現(xiàn)象可能原因解決方案趨勢(shì)圖時(shí)間偏移數(shù)小時(shí)時(shí)區(qū)不匹配Grafana Preferences設(shè)置為Asia/Shanghai趨勢(shì)圖數(shù)據(jù)斷層時(shí)間字段為字符串格式統(tǒng)一改為datetime類型日志解析后無字段JSON多行格式預(yù)處理壓縮為單行JSON看板加載很慢缺少?gòu)?fù)合索引添加(status, severity, discovered_at)索引告警反復(fù)觸發(fā)for配置過短設(shè)置for為30m或更長(zhǎng)消息沒收到通知策略未關(guān)聯(lián)在Alerting中檢查聯(lián)系點(diǎn)和路由部分圖表顯示No data變量空值過濾查詢中使用($var all OR field $var)用戶可以看到其他團(tuán)隊(duì)數(shù)據(jù)權(quán)限配置不對(duì)按文件夾設(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í)候看板才算真正長(zhǎng)在了流程里而不只是一個(gè)偶爾打開的展示屏。先從一個(gè)核心指標(biāo)卡開始跑通數(shù)據(jù)鏈路再逐步增加圖表和告警規(guī)則是這套方案落地時(shí)最穩(wěn)妥的推進(jìn)節(jié)奏。