上一篇整理了 91APP 與 Zeabur 兩起資安事件。其中有一個細節值得單獨拿出來談：Zeabur 第一次事件後的賠償範圍，特別點名了 OpenAI、Anthropic、Gemini、OpenRouter 等 AI API 金鑰遭盜用所產生的費用。依下游業者引述的官方公告，那次事件還與一個 AI 閘道元件的可疑活動有關。
這兩個細節放在一起，說明的是一個很多企業還沒意識到的變化：導入 AI 之後，貴司環境變數裡多了一批「拿到就能花錢」的東西。這篇文章談的是 AI 金鑰為什麼跟傳統的密碼不一樣，以及中小企業可以照著做的金鑰治理方法。
為什麼 AI 金鑰等於現金
傳統的資料外洩，攻擊者拿到的是客戶名單、訂單紀錄這類資料，要變現還得轉手、勒索或拿去詐騙，中間有時間差。AI API 金鑰不一樣：
- 拿到就能用。不需要破解、不需要轉手。把金鑰放進自己的程式，就能用貴司的帳戶呼叫模型。
- 費用記在貴司身上。每一次呼叫都是真實的帳單。被拿去跑大量生成、轉售額度或訓練資料，帳單可以在幾天內累積到驚人的數字。
- 權限通常很大。很多企業為了方便，整個組織共用一把金鑰，沒有限額、沒有到期日。一旦外洩，影響的是所有用到它的系統。
- 不容易發現。攻擊者的呼叫和貴司自己的呼叫，在帳單上看起來是一樣的。沒有用量告警，往往是月底對帳才發現。
換句話說，AI 金鑰的性質更接近一張沒有額度上限的公司信用卡，而不是一組帳號密碼。管理它的方式也應該比照信用卡。
AI 金鑰通常散落在哪裡
企業導入 AI 的速度很快，金鑰往往跟著散落在各處。常見的位置有：
- 雲端平台的環境變數。部署在 PaaS 上的服務，金鑰多半放在平台的環境變數設定裡。平台出事，金鑰就跟著出事，Zeabur 的兩次事件都是這個形狀。
- 自動化工具的憑證。n8n、Make 這類流程工具裡存著各種 AI 服務與內部系統的憑證，一台工具主機往往握有最多把鑰匙。
- 程式碼與設定檔。開發者為了測試方便寫死在程式裡，或是把 .env 檔一起推上程式碼庫。
- 前端程式。用 AI 快速做出來的網頁小工具，有時直接在瀏覽器端呼叫 AI 服務，金鑰就寫在任何人都看得到的網頁原始碼裡。
- 員工個人電腦與聊天紀錄。為了讓同事幫忙測試，金鑰被貼在通訊軟體裡，然後就再也沒人記得它在那裡。
金鑰治理的七個做法
以下七件事不需要買新系統，大多數是規則與習慣。依投入由小到大排列：
1. 每把金鑰都要有主人
建一張清單：金鑰屬於哪個服務、用在哪個系統、誰負責、放在哪裡、上次輪替是什麼時候。這張表是後面所有動作的基礎。出事的時候，沒有這張表的企業只能全部換掉，再一個一個找出哪裡壞了。
2. 一個系統一把，不共用
客服機器人、內部知識庫、行銷文案工具，各自用自己的金鑰。正式環境與測試環境也分開。這樣一把外洩，只需要換一把、只影響一個系統，帳單上也看得出是哪個系統的用量異常。主要的 AI 供應商多半提供專案或工作區層級的金鑰，可以直接用來切分。
3. 權限範圍與有效期限
能限制權限就限制，能設到期日就設。Zeabur 官方在第二次事件的說明中提到，不支援權限範圍與有效期限的舊版 API Key 是影響擴大的主因之一。這個教訓適用於所有系統：一把永不過期、什麼都能做的金鑰，是攻擊者最想要的東西。
4. 設定花費上限與用量告警
這是投入最小、效果最直接的一件事。在 AI 服務後台為每個專案設定每月花費上限，並設定用量異常時通知負責人。就算金鑰外洩，損失也被限制在上限之內，而且會在當天而不是月底被發現。
5. 不進程式碼、不進前端
金鑰只能存在於伺服器端的密鑰管理機制裡，不寫進程式碼、不進程式碼庫、不出現在瀏覽器端。程式碼託管平台多半提供推送前的密鑰掃描，開起來就能擋下大部分的意外。外包廠商交付的系統，驗收時也要檢查這一項。
6. 定期輪替，並演練過一次
訂一個輪替週期，例如每季一次，並且真的執行一次。第一次輪替通常會發現某個沒人記得的排程還在用舊金鑰。在平常發現這件事，比在事故當晚發現好太多。
7. 用閘道集中管理，並把閘道當成重點防護對象
用量變大之後，建議讓所有 AI 呼叫經過一個統一的閘道：供應商的金鑰只存在閘道裡，各系統拿到的是內部的權杖，可以個別限額、個別撤銷。我們在先前的系列談過閘道在成本與可用性上的好處。
但 Zeabur 的事件也提醒了另一面：閘道把鑰匙集中起來，它本身就成了最值錢的目標。閘道要放在與其他服務隔離的網路裡、管理介面不對外開放、元件持續更新、存取有完整紀錄。集中管理的前提，是這個集中點被當成金庫來保護。
AI 金鑰治理檢查表
| 項目 | 做到的樣子 |
|---|---|
| 清單 | 每把金鑰有對應的系統、負責人、存放位置、上次輪替日 |
| 切分 | 一個系統一把，正式與測試分開 |
| 權限 | 限制可用的模型與功能，能設到期日就設 |
| 上限 | 每個專案有每月花費上限與用量告警 |
| 存放 | 只在伺服器端的密鑰管理機制，不進程式碼與前端 |
| 輪替 | 有固定週期，且至少實際演練過一次 |
| 集中 | 用量大時經由閘道，閘道本身隔離、更新、留紀錄 |
下一篇要談的是另一種風險：不是金鑰被偷，而是整個平台不在了。當雲端供應商宣布停止營運，貴司有幾天可以搬家？
常見問題
懷疑 AI 金鑰外洩，第一步該做什麼？
先撤銷，再調查。到 AI 服務後台停用或刪除該金鑰並產生新的，再更新到使用它的系統。接著檢查用量紀錄，確認異常呼叫的時間範圍，並向供應商詢問是否能協助處理被盜用的費用。不要為了先釐清原因而讓舊金鑰繼續有效。
中小企業需要買密鑰管理系統嗎？
多數情況不需要一開始就買。雲端平台與主機商本身就有存放密鑰的機制，先把清單、切分、上限、輪替這四件事做好，就能擋下大部分風險。當系統數量多到清單難以維護，再考慮專門的密鑰管理工具或閘道。
外包廠商開發的系統，金鑰該由誰管？
建議 AI 服務的帳戶與金鑰由貴司自己申請、自己持有，再提供給廠商使用，而不是用廠商的帳戶。這樣帳單、用量與撤銷權都在貴司手上，合作結束時也能直接收回。
如果貴司想盤點目前有哪些 AI 金鑰散落在哪些系統、哪些需要立刻設定上限或輪替，歡迎聯絡品得網絡。
