API 金鑰妥協調查

中級2 分鐘閱讀更新於 2026-03-21

調查 AI API 金鑰妥協事件,涵蓋偵測、範圍評估、使用鑑識與修補程序。

ai-forensics-ir api-key credential-compromise incident-response

概觀

AI API 金鑰是攻擊者的高價值目標。被妥協的 OpenAI、Anthropic、Google AI 或 Azure OpenAI API 金鑰讓攻擊者以受害者的代價存取強大語言模型。後果從財務(攻擊者以被盜 GPT-4 金鑰在單個週末燒掉超過 10 萬美元)到營運層面(攻擊者可用金鑰處理敏感資料,潛在地從 RAG 連接系統外洩資訊)。最壞情況下,具備微調權限的被妥協金鑰讓攻擊者能投毒與帳號相關的模型。

API 金鑰妥協調查在數個重要面向上與傳統憑證妥協不同。首先,「影響範圍」高度取決於金鑰連接到什麼。僅用於簡單完成的金鑰與接入具工具存取的代理系統的金鑰風險剖面不同。其次,鑑識成品主要是 API 使用日誌與帳單紀錄,而非系統日誌與網路擷取。再者,憑證竊取的攻擊面廣泛:金鑰可能出現在 git 倉儲、用戶端程式碼、CI/CD 日誌、環境變數傾印與共用設定檔中。

本文完整走過 AI API 金鑰妥協的調查生命週期:初始偵測、範圍評估、攻擊者活動的鑑識重建,以及修補。

API 金鑰妥協的偵測

使用異常偵測

API 金鑰妥協最可靠的訊號是異常使用。表現為:請求量尖峰、意外模型使用(攻擊者使用 GPT-4-turbo 而應用程式只用 GPT-3.5)、來自陌生 IP 位址的請求,或於正常營業時間外的使用。

UsageRecord 資料類別含 timestamp、api_key_prefix(最後 4 字元或遮罩金鑰)、model、input_tokens、output_tokens、endpoint、source_ip、user_agent、status_code、cost_usd。

AnomalyAlert 含 alert_type、severity(low/medium/high/critical)、description、evidence 字典、timestamp、api_key_prefix。

APIKeyUsageAnalyzer 偵測異常 API 金鑰使用模式。類別屬性 MODEL_COSTS 記錄每 1K 符元的粗略成本(美元):gpt-4 (in 0.03/out 0.06)、gpt-4-turbo (0.01/0.03)、gpt-4o (0.005/0.015)、gpt-3.5-turbo (0.0005/0.0015)、claude-3-opus (0.015/0.075)、claude-3.5-sonnet (0.003/0.015) 等。

核心方法:

_check_volume_anomaly(key_prefix, day, records, baseline):請求量超過基準 5 倍或 > 1000 時告警 high。
_check_cost_anomaly:每日成本超過基準平均 5 倍或 > 10 美元時告警 critical。
_check_model_anomaly:使用基準中未知的模型時告警 high(每個未知模型一次)。
_check_ip_anomaly:來自未知 IP 的請求告警 high,證據含未知 IP 清單。
_check_time_anomaly:營業時間外請求超過 30% 時告警 medium。
_std(values) 計算樣本標準差。

監控帳單儀表板

除 API 層級監控外,帳單儀表板提供次要偵測訊號。大多 AI 供應商提供帳單告警,但預設閾值通常設定過高,無法捕捉早期妥協。配置對實際使用有意義的告警:若通常每天花 50 美元,設定 75/150/500 美元三個告警。第一個捕捉緩慢漏洞,第二個捕捉主動濫用,第三個捕捉大規模濫用。

範圍評估

判定被曝露了什麼

一旦識別被妥協金鑰,立即的問題是:攻擊者可用它做什麼?答案取決於金鑰的權限與它所連接的東西。

KeyScopeAssessment 含 key_prefix、provider、permissions、connected_services、data_exposure_risk(low/medium/high/critical)、financial_exposure、findings。

assess_openai_key_scope(key_prefix, org_settings, usage_history) 評估被妥協 OpenAI API 金鑰的範圍:

從使用歷史擷取使用過的模型;加入 permissions
檢查微調存取(endpoint 含 fine_tun),若存在則標記為 CRITICAL,因攻擊者可在你的組織中建立被投毒的模型,data_risk 設為 critical
檢查檔案上傳存取、助理 API 存取(可含自訂工具、RAG 連結)
從 org_settings 推論速率限制與月費上限,以 financial_exposure 表示最壞情況每月可花費金額
回傳完整範圍分析

跨雲端評估

類似邏輯套用到 Anthropic、Google AI、Azure OpenAI。每個供應商各有 IAM 模型:Azure OpenAI 與服務主體綁定並繼承 Azure RBAC;Google AI 金鑰則通常與服務帳號相關;Anthropic 金鑰可作組織/工作區範圍化。

重建攻擊者活動

從帳單與使用 API 取得資料

OpenAI 與 Anthropic 提供使用 API。將多方資料源(供應商日誌、應用層日誌、網路層 WAF/CDN 日誌、身分提供者日誌)依時間對齊後,重建攻擊者活動。

關鍵鑑識問題

首次未授權使用的時間? 這定義了妥協的起始。
金鑰從何被取得? 檢視 git 提交、容器映像、CI 日誌以尋找金鑰曝露。
呼叫的特定端點? 哪些模型?fine-tune?embeddings?assistants API?有哪些檔案上傳?
可疑資料模式? 是否有攻擊者透過 RAG 或 assistants API 從你的系統洩漏資料的跡象?

修補與強化

立即行動

撤銷被妥協金鑰:在供應商控制台中撤銷。
撤銷所有下游衍生金鑰:若有從主金鑰衍生的服務特定金鑰,一併撤銷。
輪替相關憑證:資料庫密碼、服務帳號金鑰等,若可能曝露則一併輪替。
檢查供應商帳號的其他妥協:攻擊者可能改變帳號設定(webhook、IP 白名單)。

後續強化

將金鑰限制為特定 IP 範圍(若供應商支援)
啟用 API 使用硬上限(每日、每月最大花費)
實作金鑰使用監控:異常偵測告警直達 SOC
將金鑰存放於秘密管理器(AWS Secrets Manager、Azure Key Vault、HashiCorp Vault)
自動化金鑰輪替:依時程或事件觸發
在 CI 上執行 git-secrets / detect-secrets 以防止金鑰曝露
採用短生命週期、範圍化的權杖,而非長效 API 金鑰
對團隊進行訓練,強調金鑰處理的禁忌(切勿貼到 Slack、Trello 等)

參考資料

OWASP. (2025). OWASP Top 10 for Large Language Model Applications. LLM08: Vector and Embedding Weaknesses. https://owasp.org/www-project-top-10-for-large-language-model-applications/
OpenAI. (2024). Best Practices for API Key Safety. https://help.openai.com/en/articles/5112595-best-practices-for-api-key-safety
Azure. (2024). Azure Key Vault documentation. https://learn.microsoft.com/en-us/azure/key-vault/
MITRE ATLAS. (2024). AML.T0012 — Valid Accounts. https://atlas.mitre.org/

API 金鑰妥協調查

中級2 分鐘閱讀更新於 2026-03-21

調查 AI API 金鑰妥協事件,涵蓋偵測、範圍評估、使用鑑識與修補程序。

ai-forensics-ir api-key credential-compromise incident-response

核心方法:

_check_volume_anomaly(key_prefix, day, records, baseline):請求量超過基準 5 倍或 > 1000 時告警 high。
_check_cost_anomaly:每日成本超過基準平均 5 倍或 > 10 美元時告警 critical。
_check_model_anomaly:使用基準中未知的模型時告警 high(每個未知模型一次)。
_check_ip_anomaly:來自未知 IP 的請求告警 high,證據含未知 IP 清單。
_check_time_anomaly:營業時間外請求超過 30% 時告警 medium。
_std(values) 計算樣本標準差。

assess_openai_key_scope(key_prefix, org_settings, usage_history) 評估被妥協 OpenAI API 金鑰的範圍:

從使用歷史擷取使用過的模型;加入 permissions
檢查微調存取(endpoint 含 fine_tun),若存在則標記為 CRITICAL,因攻擊者可在你的組織中建立被投毒的模型,data_risk 設為 critical
檢查檔案上傳存取、助理 API 存取(可含自訂工具、RAG 連結)
從 org_settings 推論速率限制與月費上限,以 financial_exposure 表示最壞情況每月可花費金額
回傳完整範圍分析

首次未授權使用的時間? 這定義了妥協的起始。
金鑰從何被取得? 檢視 git 提交、容器映像、CI 日誌以尋找金鑰曝露。
呼叫的特定端點? 哪些模型?fine-tune?embeddings?assistants API?有哪些檔案上傳?
可疑資料模式? 是否有攻擊者透過 RAG 或 assistants API 從你的系統洩漏資料的跡象?

修補與強化

立即行動

撤銷被妥協金鑰:在供應商控制台中撤銷。
撤銷所有下游衍生金鑰:若有從主金鑰衍生的服務特定金鑰,一併撤銷。
輪替相關憑證:資料庫密碼、服務帳號金鑰等,若可能曝露則一併輪替。
檢查供應商帳號的其他妥協:攻擊者可能改變帳號設定(webhook、IP 白名單)。

後續強化

將金鑰限制為特定 IP 範圍(若供應商支援)
啟用 API 使用硬上限(每日、每月最大花費)
實作金鑰使用監控:異常偵測告警直達 SOC
將金鑰存放於秘密管理器(AWS Secrets Manager、Azure Key Vault、HashiCorp Vault)
自動化金鑰輪替:依時程或事件觸發
在 CI 上執行 git-secrets / detect-secrets 以防止金鑰曝露
採用短生命週期、範圍化的權杖,而非長效 API 金鑰
對團隊進行訓練,強調金鑰處理的禁忌(切勿貼到 Slack、Trello 等)

參考資料

OWASP. (2025). OWASP Top 10 for Large Language Model Applications. LLM08: Vector and Embedding Weaknesses. https://owasp.org/www-project-top-10-for-large-language-model-applications/
OpenAI. (2024). Best Practices for API Key Safety. https://help.openai.com/en/articles/5112595-best-practices-for-api-key-safety
Azure. (2024). Azure Key Vault documentation. https://learn.microsoft.com/en-us/azure/key-vault/
MITRE ATLAS. (2024). AML.T0012 — Valid Accounts. https://atlas.mitre.org/

API 金鑰妥協調查

相關文章

API 金鑰妥協調查

相關文章