Grafana 被偷 code 拒交贖金：香港 DevOps 更要查 token

圖：TechCrunch．原文連結

Grafana Labs 今次事件表面上係一宗「開源公司被偷 code、攻擊者勒索」新聞，但真正值得公司 IT team、DevOps、SRE 同 MSP 留意嘅位，唔係攻擊者有幾大口氣，而係一粒 token 點樣變成進入整個開發環境嘅門匙。Grafana 官方確認，有未獲授權一方取得可進入 Grafana Labs GitHub environment 嘅 token，並下載公司 codebase；公司同時表示，目前調查未見客戶資料、個人資料、客戶系統或營運受影響。呢個講法要小心讀：官方係話「目前調查未見證據」，唔等於調查已完結，亦唔等於每間用 Grafana 嘅公司可以當無事發生。

香港公司如果本身有用 Grafana 做 dashboard、監控、alert、log 或基建可視化，呢單事唔應該包裝成本地受害事件。現時未有公開資料顯示香港機構因 Grafana 呢次事件被入侵。但實務上，香港 SaaS、電商、金融科技、系統整合商同內部開發團隊常見一個共通風險：GitHub／GitLab、CI/CD、雲端帳戶、Grafana service account、Terraform、PagerDuty、Slack bot、Jira app 全部都有 token，權限可能多年無人清，離職同事、舊 runner、舊 workflow 仍然留住可用憑證。Grafana 事件嘅價值，就係提醒大家開源工具本身透明，唔代表圍住佢嘅私有 repo、build pipeline、部署憑證同第三方整合都安全。

發生咩事

Grafana Labs 喺官方 LinkedIn 同 X 發文指，攻擊者取得一個可進入 Grafana Labs GitHub environment 嘅 token，並用嚟下載 codebase。公司表示已即時展開 forensic analysis，認為已識別憑證外洩來源，並已停用受影響憑證、加入額外保安措施，減低再次未授權存取嘅機會。攻擊者之後嘗試以公開 codebase 作勒索，要求付款；Grafana Labs 表示根據自身營運經驗同 FBI 一向不建議支付贖金嘅取態，決定唔付款，並會喺 post-incident review 完成後再分享更多資料。

TechCrunch 報道亦提到一個重要修正：事件涉及 Grafana 嘅 GitHub environment。呢點值得特別寫清楚，因為早期或二手報道有機會將 GitHub、GitLab 或一般 source control 混用；對技術團隊嚟講，呢啲字眼唔係小事，因為 GitHub token、GitLab token、CI job token、runner token、deploy key、app installation token 嘅權限模型唔同，調查範圍亦唔同。現階段已知重點係 Grafana 官方確認有 token 被濫用、有 codebase 被下載、有勒索要求、調查仍然未完成；未確認嘅係攻擊者到底攞到邊啲私有 code、是否包含非開源商業元件、外洩來源嘅技術細節，以及攻擊者自稱身份是否可信。

開源唔等於無秘密

Grafana 本身係出名嘅開源可視化同 dashboard 平台，官方形容佢可以查詢、可視化、設定 alert，同理解存放喺唔同地方嘅資料。Grafana Labs 亦唔只得一個 dashboard 工具，佢圍繞 observability 建立咗 Loki、Tempo、Mimir、k6、Pyroscope、Alloy 等多個項目，亦同 Prometheus、OpenTelemetry 呢類雲端原生監控生態有密切關係。正因為 Grafana 係好多公司用嚟睇系統健康、API latency、error rate、infra usage 嘅地方，攻擊者即使未必直接攞到客戶資料，都會對佢嘅 code、build 流程同整合憑證有興趣。

「開源公司被偷 source code」聽落好似矛盾，因為開源 code 本來就公開。但公司實際運作入面，公開 repo 之外通常仲有私有 repo、內部工具、商業功能、部署腳本、測試資料、CI template、issue metadata、release automation、security tooling 同供應商整合設定。就算攻擊者只係下載到部分 codebase，都可能用嚟搵未公開漏洞、理解內部架構、製作更可信嘅 phishing、或者搜尋殘留 secret。換句話講，開源降低咗「code 被看見」本身嘅稀有性，但唔會自動處理身份、權限、token、runner 同第三方 app 呢條供應鏈。

今次最值得拆開睇嘅係 token。Grafana 官方無公開 token 類型，但一粒可以進入 GitHub environment 嘅 token，至少代表某個機器身份、第三方整合、automation 或人手流程曾經獲授權做某啲事。GitHub 官方文件提醒，hardcoded API key、password、token 呢類 secret 一旦入咗 repo，就會成為未授權存取目標；GitLab 文件亦清楚講，外部資源通常要靠 private key 或 token 認證，而 secret 應該放喺 repo 之外。呢啲原則唔新，但現實係好多團隊為咗交付速度，會將 secret 散落喺 workflow、環境變數、共享筆記、debug log、runner 機、container image layer，甚至舊 incident channel。

競爭同業脈絡：observability 已經係攻擊面

Grafana 所在嘅 observability 市場，本來就係 Datadog、New Relic、Dynatrace、Splunk、Elastic、Prometheus 生態同各大雲端原生監控服務互相重疊嘅位置。呢啲工具唔只負責畫圖，實際上會接觸大量系統 metadata：服務名、cluster、namespace、deployment、endpoint、錯誤訊息、query、alert rule、on-call flow、甚至某啲情況下嘅 sample log。攻擊者如果可以睇到監控或開發環境，未必即刻等於攞到客戶資料，但足以幫佢理解邊啲服務最重要、邊啲時間最忙、邊條 pipeline 最有價值。

呢單事亦同近年供應鏈攻擊趨勢接軌：攻擊者唔一定要先攻 production database，反而可以先搵 source control、package registry、CI runner、GitHub Actions、GitLab CI、第三方 action、SaaS app token。The Hacker News 同 The Register 都將 Grafana 事件同近期 Instructure／Canvas 被勒索事件放埋一齊比較，但兩者差異好大：Instructure 報道焦點係學生同教職員資料外洩及付款爭議；Grafana 目前官方講法係未見客戶資料或系統受影響，勒索籌碼主要係 codebase。對公司決策層嚟講，呢個差異會直接影響應變優先次序、法律通報、客戶溝通同是否停用整合。

勒索組織自稱身份亦要保留距離。The Hacker News 引述第三方追蹤指出，有名為 CoinbaseCartel 嘅資料勒索團伙聲稱涉及事件，但 Grafana 官方未有公開歸因，亦未確認攻擊者身份。資安新聞入面，勒索組織經常靠「自稱」製造壓力同名氣；未經官方、執法或可信技術證據確認之前，將佢寫成已證實兇手，反而會幫攻擊者放大宣傳。比較穩陣嘅寫法係：有第三方報道某團伙聲稱責任，但 Grafana 目前重點披露係 token 外洩、codebase 被下載、拒絕付款同調查未完。

香港 team 應該點查

香港公司最實際嘅第一步唔係等供應商出完整報告，而係盤點自己有冇相同模式。凡係有用 GitHub、GitLab、Grafana、Terraform、Docker registry、Kubernetes、雲端 IAM、Slack／Teams bot、Jira／Confluence app、監控平台同部署工具，都應該問一個簡單問題：如果其中一粒 token 今日外洩，攻擊者可以做到咩？只讀 repo？下載 artifact？改 workflow？開 release？讀 production secret？連入內部 Grafana？或者用 dashboard 搵到下一層目標？呢個問題比「我哋有無用 Grafana」更重要，因為 token 外洩唔會尊重工具邊界。

可以由以下 checklist 開始做一次短週期檢查：

• GitHub／GitLab token：列出 PAT、deploy key、GitHub App、GitLab project／group access token、runner token，移除無 owner、無到期日、無用途記錄嘅憑證。
• CI/CD secret：檢查 repo、org、environment、group、project 層級 secret；確認 production secret 只俾受保護 environment 或指定分支使用。
• 最小權限：GitHub Actions 嘅 GITHUB_TOKEN 預設應盡量只讀，必要 job 先提升；第三方 action 盡量 pin 到完整 commit SHA。
• Grafana 權限：檢查 service account 同 token 有無過大權限；Grafana 官方文件指 service account token 會繼承 service account 權限，亦建議唔肯定有效期時用短 expiry。
• secret scanning：開啟 GitHub secret scanning／push protection 或 GitLab secret detection，加入自家 token pattern，唔好只靠平台預設支援嘅供應商格式。
• runner 同 log：查 self-hosted runner 有無長期存放 SSH key、cloud credential、kubeconfig；清理曾經印出 secret 嘅 workflow log，並即時 rotate。
• 第三方整合：重查所有接入 GitHub/GitLab/Grafana 嘅 SaaS app，尤其係有 repo read、workflow write、admin 或 webhook 權限嘅工具。

唔好等到勒索先知 token 太大權

最難處理嘅唔係「有無 secret」，而係 secret 生命週期無人真正擁有。好多團隊會有 password manager，但 CI secret、service account、OIDC trust、webhook signing secret、Grafana token、cloud role mapping 係由唔同 team 分散管理；一出事，大家先發現無 inventory、無到期日、無 last-used review、無 emergency rotation playbook。GitHub 文件建議 secret scanning alert 出現時即時 rotate 受影響憑證；GitLab 文件亦提到一旦 secret 被 commit，應盡快 revoke 同 replace。呢啲唔應該係 incident 當日先臨場學嘅流程。

Grafana 事件暫時未變成「客戶資料被偷」嘅故事，亦唔應該被誇大成所有 Grafana 用家即時受害。但佢示範咗一個更普遍嘅現實：開源、雲端、DevOps、SaaS 整合令開發速度快咗，同時亦令機器身份多到好難靠人腦記住。香港 IT team 如果只係每年做一次人手帳戶 review，漏晒 service account、CI token 同第三方 app 權限，下一次出事時，最先要答嘅未必係「點解攻擊者咁勁」，而係「點解一粒舊 token 仲有咁大權限」。

參考來源

• TechCrunch — Open source tool maker Grafana Labs says hackers stole its code, refuses to pay ransom — original report
• Grafana Labs official LinkedIn post — 官方聲明，確認 token、GitHub environment、codebase、未見客戶資料受影響、拒絕付款同調查未完成。
• The Hacker News: Grafana GitHub Token Breach Led to Codebase Download and Extortion Attempt — 補充第三方報道、歸因未確認、資料勒索脈絡同同類事件比較。
• The Register: Grafana Labs admits attackers downloaded its codebase from GitHub — 補充事件不明位，包括到底下載到邊類 codebase、同 Instructure／Canvas 勒索事件差異。
• Grafana OSS official page — 核實 Grafana Labs 開源背景、成立脈絡同主要 observability 項目。
• Grafana documentation: Service accounts — 核實 Grafana service account token 權限、expiry、rotation 同自動化工作負載用法。
• GitHub Docs: About secret scanning — 核實 secret scanning、credential leak、rotate exposed credential 等建議。
• GitLab Docs: Secret detection — 核實 GitLab secret detection、push protection、pipeline scanning 同外洩後 revoke／replace 做法。

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。