那把金鑰從未過期

Truffle Security 本週發表了一份普查， BleepingComputer 在週四跟進報導。 自 2022 年 8 月起，該公司持續在 AWS 存取金鑰公開現身的地方收集它們：git 歷史、Hugging Face 資料集、Docker 映像、套件登錄庫、CI 日誌。接著再確認它們是否還能用。

這份報告 清點出 431,875 筆已驗證的 AWS 發現紀錄，去重後得到橫跨 50,654 個不同帳戶的 64,024 把唯一存取金鑰。 其中有 10,616 組帶有足夠材料可以重新測試。其中八十八個百分點至今仍可通過認證。那是 9,308 把今天還活著的金鑰，過去四年間任何人都可能從某個公開表面上把它們撿走。

他們把驗證範圍壓得很窄，只用唯讀的中繼資料呼叫：sts:GetCallerIdentity、iam:ListAccessKeys、 政策名稱列舉、一次預算讀取，以及每個帳戶一次 Cost Explorer 呼叫。他們沒有讀取任何資料，也沒有更動 任何東西，並在發表前通知了 10,616 位擁有者中的 10,260 位。

接著看看這些金鑰有多老。

五年，而且還在往上加

仍在運作的金鑰，年齡中位數是 1,831 天。最老的是 17.4 年。整組資料裡只有 25 把，也就是百分之一的 十分之九，來自最近三十天。

這樣的分布描述的是沉積物，而不是一條新鮮意外被抓到又被清乾淨的河流。金鑰外洩之後就一直外洩下去， 因為 AWS 的靜態存取金鑰沒有到期這回事：沒有時鐘，沒有更新，沒有十八個月後就變質的憑證。它會一直 有效，直到有人打開主控台把它刪掉。Truffle 量了那個「有人」出現的頻率。在研究人員能夠列舉金鑰的 使用者裡，2,903 人中有 398 人在外洩金鑰旁邊放了一把較新的金鑰，也就是 13.7%。其餘 2,505 人從未輪替過。

這也不能怪到偵測那一步，因為 Amazon 早就把發現的工作做完了。當 AWS 在公開場合看到自家的金鑰，它會 給那位使用者掛上一個叫 AWSCompromisedKeyQuarantine 的政策，收緊這把金鑰能做的事，並寄信給該帳戶。 沒有人需要開口要求。Truffle 發現有 929 位 IAM 使用者，佔 7,590 位活躍使用者的 12%，此刻正掛著那個 政策。其中一百一十二人掛的是最初版本，代表 AWS 至少在三年前就標記了他們，而他們的金鑰現在仍會 回應。

偵測有效，信也寄了，三年之後金鑰依然好用。

外洩表面搬到了沒有刪除鍵的地方

整份普查裡最大的單一來源是 Hugging Face：橫跨 3,394 個資料集的 8,482 把唯一有效金鑰，以及 17.9% 的 root 金鑰比例，遠高於其他族群。

這條管線的另一端，Truffle 早就量過了。六月時團隊 把 Hugging Face 上每個公開資料集都複製了一份： 1 億 8,690 萬個唯一檔案、7.6 PB、約 815,000 個資料集儲存庫。他們把 Parquet、Arrow、JSONL 與壓縮檔攤平成可掃描的文字，並驗證找到的每一項。結果是 6,003 個資料集裡有 221,303 組有效且唯一的憑證：11,496 把 AI 供應商金鑰、橫跨 3,811 個專案的 8,557 把 Google Cloud 服務帳戶金鑰、8,594 組可用的資料庫登入資訊、3,343 把能通過 STS 身分檢查的 AWS 金鑰，以及 349 個 GitHub 個人存取權杖，其中 223 個能推送程式碼，130 個能改寫 CI 工作流程。

他們的兩個例子顯示一次失誤能跑多遠。有人把一家巴西金融科技公司的 AWS 金鑰貼進聊天機器人，如今它在 不同語料庫裡被複製了大約十八次。以同樣方式被擷取的一把 Infura 金鑰，最後落在 1,131 個資料集與 10,162 個不同的檔案位置裡。Truffle 找到的唯一有效機密中，有四十四個百分點出現在一個以上的資料集。

然後人們拿這些資料集去訓練。StarCoder 有文件紀錄的訓練資料含有 25,217 把這類金鑰；Swallow 有 22,484 把；OLMo 3 有 21,278 把。大型專有模型的語料庫不對外公開，所以外界沒有人知道。

Truffle 給出了直白的結論：輪替仍是唯一的解法，因為沒有人能回頭去清訓練資料。任何曾經進到公開儲存庫、 網頁或聊天機器人的金鑰，都該當成已經燒掉。

那份清單上的每個來源，都是代理程式會寫出來的東西

再看一次 Truffle 去哪裡採買：git 歷史、Docker 映像、套件登錄庫、CI 日誌、資料集上傳。那些都是建置 產出，而且正是今天的編碼代理程式在無人看顧的深夜，以任何團隊都審不完的速度製造出來的東西。

一個在你睡覺時清理待辦的代理程式，會寫提交、改寫 lockfile、建映像、推分支、灌滿日誌。這其中每一件 都是發佈表面，而整段期間你的 ~/.aws/credentials 都在它伸手可及之處，因為 SDK 本來就是被設計成 去那裡找它。

編碼代理程式寫出這些產物的速度，比以往任何工具都快，而那 13.7% 沒有動過。

負責簽章的那一半留在你的 Mac 上

Bromure Agentic Coding 把代理程式跑在 Apple Virtualization 框架上的一次性 Ubuntu VM 裡，對外唯一 通道是主機端的代理伺服器。在這個設計裡，AWS 需要特別處理。SigV4 從不把祕密放上線路，因為 SDK 是在行程內拿它算出一個 HMAC，所以代理伺服器在傳輸途中沒有東西可以替換。於是 Bromure 改為搬動簽章 這件事本身。

在 VM 裡，~/.aws/config 指向一個 credential_process 輔助程式。當 SDK 索取憑證時，輔助程式會回 傳真正的存取金鑰 ID，搭配一組每次工作階段重新鑄造的四十字元假祕密。存取金鑰 ID 是識別碼而不是祕密， 它是用來表明哪個 IAM 使用者在呼叫的那一半。祕密存取金鑰才是負責簽章的那一半，而它從未進入 VM 的 位址空間。Bromure 甚至不把 AWS_ACCESS_KEY_ID 或 AWS_SECRET_ACCESS_KEY 匯入客體環境，理由是環境 變數會從 /proc、ps -E 與 shell 歷史裡漏出去。VM 拿到的只有一個區域字串，別無其他。

SDK 簽出的請求，其簽章不可能正確。在出去的路上，主機把那個簽章剝掉，用真材料重新計算 SigV4。aws、 boto3 與 terraform 都照常運作。任何繞過代理伺服器的東西，都會從 Amazon 收到 InvalidSignatureException，而那正是你想要的失敗方式。

現在把一個 Bromure 工作區丟進 Truffle 的方法論裡。他們把一把金鑰計入的門檻，是一次簽章過的 sts:GetCallerIdentity 回來是有效的。假設一個被入侵的相依套件從那個客體裡撈走憑證檔，或者代理程式 被說服去 cat 它，或者某次建置把它內嵌進公開的 bundle。跑出去的是一個識別碼，加上四十個從來就不是 祕密的字元。它在外洩的當天就失效，所以永遠不會加入那層沉積物，後面也不會拖著五年的長尾。

這同時拿掉了那個要等人類完成的輪替步驟。真正的祕密只住在一個地方，也就是你 Mac 上設定檔的「憑證」 面板。在那裡改掉，下一個工作階段就會取用。沒有人需要去查九十次深夜執行裡，是哪一次寫出了哪個產物。

一個比簽它的金鑰還要窄的簽章請求

普查的另一個重點是觸及範圍。在 817 把能連到某家企業的金鑰裡，有 768 把給出帳戶的完整控制權：526 把 root 金鑰，以及 242 個持有 AdministratorAccess 的 IAM 使用者。其中一百三十把 root 金鑰位於組織管理帳戶上，也就是統管組織內每個成員帳戶的那個帳戶。在研究人員能夠列舉的使用者裡，有 976 人持有 AdministratorAccess，比例是 84%。

那些是多年前為了方便而鑄出來的金鑰，用途是一件只需要三個權限的工作。

Bromure 的 Guardrails 設定會在使用的當下把憑證收窄，讓你完全不必記得要在源頭收窄它。它是代理伺服器 裡的一個主機端政策引擎。對 AWS 而言，它會從 DynamoDB、Lambda 這類 JSON 協定服務的 X-Amz-Target 標頭讀出動作名稱，從 EC2、IAM、SQS 這類查詢協定服務的 Action= 參數讀出動作名稱，而對 S3 則退回 使用 HTTP 方法判斷。Delete*、Terminate*、Remove*、Purge* 與 Destroy* 被歸為破壞性； Get*、List* 與 Describe* 被歸為讀取。把設定檔調成唯讀，變更操作就會以一個硬邦邦的 403 回來，代理程式會把它讀成一次普通的 API 失敗。調成封鎖破壞性操作，建立與更新會通過，刪除不會。

執行這件事的是你的 Mac，不是 VM，所以一個被說服去做什麼的代理程式，沒辦法用講道理的方式繞過去。你 主機拿去簽章的憑證，最後比憑證本身還要窄，而在一個 84% 可列舉使用者都握著管理員權限的族群裡，這件事 很值得。

紀錄比帳單先出現

再從報告裡挑一個數字。在研究人員能讀到預算的 2,754 個帳戶中，只有 262 個設定過任何預算警示，也就是 9.5%，其上限中位數是八美元。同一組帳戶在七月花了 420,631 美元，其中五十個超過 1,000 美元，九個超過 10,000 美元。這些擁有者多半會在帳單上跟入侵者初次見面。

Bromure 會在工作進行的同時寫下紀錄。主機簽出的每一個請求，都會在視窗 → 安全時間軸留下一列 credential.aws_sign，帶著服務、方法、主機、區域與遮罩後的存取金鑰 ID，和套件抓取、防火牆裁決與 憑證替換並列在一起。Bromure 把這份日誌留在 Mac 上，VM 裡的任何東西都改不了它。若要更嚴格的版本， AWS → 使用時需核准會把每次簽章呼叫變成一則同意提示，並給出有時限的授權，所以一整個下午的實際 工作只會問你一次。

Bromure 把同樣的想法用在更前面一步，也就是你第一次把設定檔叫起來的時候。它會讓你匯入的代理程式設定 先過一輪遮蔽：結構化的 JSON、TOML 與 YAML 依鍵名過濾，比對 token、secret、password、apikey、 credential、authorization、private_key 與 access_key；純文字則依權杖形狀過濾，比對 AKIA、 ASIA、sk-ant-、ghp_、glpat-、AIza 與 npm_。無論你 Mac 上的 dotfile 裡放著哪些真祕密， 它們都不會跟著其餘設定一起搭車進 VM。

這份普查證明了什麼

Truffle Security 這件事做得很正派：唯讀呼叫、不碰任何資料、在發表前通知了 10,616 位擁有者中的 10,260 位。AWS 的表現也比標題暗示的要好，因為那個隔離政策，正是 Amazon 在沒人要求的情況下自己找出 外洩金鑰並警告擁有者。偵測環節的兩半都盡到了本分。

結果仍然是 9,308 把有效金鑰、年齡中位數五年，以及 13.7% 的輪替率。

那個失靈的控制項，要求一個人在失誤發生的數個月甚至數年之後，去一台可能已經不歸他管的系統上，為一把 完全沒有任何異狀跡象的金鑰完成一件雜事。這種形狀的控制項在規模面前必然失靈，而且早在有什麼東西開始 在深夜寫提交之前，它就已經在失靈了。

所以別再指望那件雜事扛起全部重量。把一組從來就不是憑證的憑證放進工作區，普查就沒有東西可數，語料庫 就沒有東西可複製，而那條五年長尾就變成別人的事了。

---

資料來源：Truffle Security「Leaked Corporate AWS Keys Held Full Admin Rights」（2026 年 8 月 19 日） · Truffle Security「Scanning 7.6 Petabytes of HuggingFace Training Data for Secrets」（2026 年 6 月 1 日） · Truffle Security「Introducing TruffleHog AWS Analyze」（2026 年 8 月 20 日） · BleepingComputer「Hundreds of leaked AWS keys give full control over corporate accounts」（2026 年 8 月 21 日） · Cybernews「Massive exposure: researchers test leaked AWS keys, 9 out of 10 still authenticate」（2026 年 8 月 21 日）