逾9,300條公開AWS金鑰仍然有效，企業雲端帳戶多年暴露風險

Truffle Security於2026年8月發表的研究，揭示一個規模大、而且拖延多年的雲端憑證安全問題。研究團隊在公開程式碼庫、Git歷史、資料集、Docker映像檔、容器登錄庫及持續整合（CI）紀錄等來源，於2022年8月至2026年8月期間記錄到431,875項AWS秘密。去重及驗證後，合共得到64,024條獨立AWS金鑰。145

最令人關注的，並不只是有幾多金鑰曾經曝光，而是曝光後仍然「用得着」的數量：研究人員在2026年8月10日測試10,616組擁有完整資料的憑證配對，當中9,308組、約88%仍然可以成功通過AWS驗證。145

高權限憑證令企業帳戶面臨全面接管風險

經確認的金鑰包括10,625條Root憑證、48,744條IAM使用者金鑰，以及4,655條未能分類的金鑰。Root憑證佔獨立金鑰總數16.6%，屬AWS帳戶內權限最高的一類身份。1

Truffle Security在當中識別出817條與企業有關、而且仍然活躍的金鑰，包括：

• 526條Root金鑰，擁有AWS帳戶內最高級別的權限。
• 242條屬於擁有AdministratorAccess政策的IAM使用者金鑰，有機會提供整個帳戶的管理權限。
• 合共768條憑證，足以讓攻擊者全面控制企業AWS帳戶。
• 130條屬於AWS Organizations管理帳戶的活躍Root金鑰；一旦被入侵，風險可能波及同一組織旗下的成員帳戶。13

在另一個可以列出IAM政策的較小樣本中，1,157名可讀取資料的IAM使用者，有976名（84%）擁有AdministratorAccess；另有144名擁有IAMFullAccess。Truffle提醒，這個比例只能作為方向性參考，因為容許研究人員列出政策的使用者，未必代表所有外洩IAM使用者。1

受影響AWS帳戶數量存在兩個口徑

現有報道提供了兩個看似不同的帳戶總數，可能是採用不同統計範圍：其中一個摘要稱，64,024條金鑰涉及9,945個不同AWS帳戶；原始報告的摘要則列出50,654個不同AWS帳戶。目前提供的資料沒有解釋兩個數字為何有差異，因此不應將它們當成可以互換的總數。1

不過，帳戶層面的風險仍然清楚：研究發現數百條活躍憑證與企業有關，當中768條更可能讓攻擊者完全控制企業AWS帳戶。13

Hugging Face成為最大單一來源

Hugging Face是研究追蹤到的最大單一來源。研究人員在3,394個公開資料集內找到8,482條獨立、仍然有效的AWS金鑰；其中17.9%是Root憑證，亦是各個被追蹤來源之中Root金鑰比例最高的一個。125

問題在於，公開程式碼很容易被重複使用。含有秘密的程式碼快照，可能被納入AI訓練資料集，再被分發到多個下游資料集。換句話說，即使原本的程式碼庫已經刪走或修改一條金鑰，也不代表所有副本都已經消失。1

這項以AWS為主的結果，亦屬於Truffle Security對Hugging Face進行的更大規模掃描的一部分。公司表示，團隊掃描了7.6PB資料及1.87億個檔案，在6,003個資料集內找到221,303條仍然有效、而且獨立的憑證。這些數字涵蓋所有類型的憑證，並不只限於AWS金鑰。6

不少金鑰已經存在多年，卻一直沒有輪換

在2,903條能讀取建立日期的活躍金鑰中，中位數年齡為1,831日，即大約5年。當中一半超過5年，最舊的一條已有17.4年；只有25條、即0.9%，是在測試前30日內建立。1

這2,903條金鑰之中，只有398條（13.7%）擁有較新的替代金鑰。結果顯示，大部分金鑰在曝光後可能一直沒有輪換、取代或清理。1

實際上，只要秘密曾經出現在公開材料，企業就應該當它已永久外洩處理，即使原始檔案或程式碼庫內的內容已被修改。Git歷史、容器映像檔、套件產物及公開資料集，都可能保留舊版本。1

缺乏預算警報，增加被用來挖礦的風險

雲端開支控制同樣並不普遍。在2,754個可以讀取設定的AWS帳戶中，只有262個（9.5%）設有任何形式的預算警報；警報門檻的中位數為8美元。12

換句話說，90.5%的可讀取帳戶都沒有偵測到預算警報。攻擊者若取得仍然有效的憑證，便可能利用雲端運算資源挖掘加密貨幣，或執行其他高耗用工作，直至企業發現異常開支為止。12

研究人員能讀取支出資料的帳戶，在2026年7月合共花費420,631美元；其中50個帳戶當月支出超過1,000美元，9個更超過10,000美元。不過，這些數字只反映被觀察帳戶的開支，並不能證明相關支出是由憑證濫用造成。1

AWS的隔離政策不代表金鑰即時失效

Truffle表示，研究期間觀察到AWS會為被偵測為外洩的IAM金鑰套用AWSCompromisedKeyQuarantine政策。這項政策會限制金鑰可以進行的操作，但不一定會即時禁止該金鑰進行身份驗證。1

在檢查到的活躍IAM金鑰中，有929條（7,590條中的12%）帶有這項政策；另有112條使用AWS在2023年停止套用的舊版本政策。研究結果顯示，即使憑證已經收到長時間的外洩通知，部分金鑰仍可能保持可用。1

因此，企業應將隔離政策視為「可能已曝光」的警號，而不是代表原有秘密已安全退役。企業仍需查明金鑰持有人及其權限，並將金鑰撤銷或輪換。1

研究人員如何測試憑證

Truffle表示，團隊只會重新驗證資料完整的憑證配對。進行帳戶及權限分析時，研究人員每次只使用一條金鑰作唯讀IAM呼叫；團隊沒有公開金鑰內容，並會通知所有能夠識別的擁有人。15

這個測試方法對理解「88%」這個數字十分重要：它只適用於擁有完整憑證、並被重新測試的樣本，而不是所有公開發現項目，亦不是掃描期間找到的每一段不完整秘密。14

企業現在應該採取的措施

研究結果支持以下一套簡單的事故應變清單：

1. 刪除Root存取金鑰。 Truffle認為Root金鑰沒有正當的日常操作用途。1
2. 盤點所有IAM存取金鑰，包括程式碼庫、Git歷史、CI紀錄、映像檔、容器登錄庫及已發布資料集內的金鑰。1
3. 即時撤銷或輪換已曝光憑證。 只刪除看得見的副本並不足夠，因為秘密可能仍然存在於歷史紀錄或下游產物。1
4. 設定金鑰最長使用年期並強制輪換。 長期未使用的舊憑證，應該移除，而不是無限期保留。1
5. 設定雲端預算警報。 即使是10美元等較低門檻，也可以較早發現未經授權的異常開支。1
6. 監察AWSCompromisedKeyQuarantine。 一旦發現相關政策，應視為憑證可能外洩的證據並展開調查。1
7. 持續進行秘密掃描，覆蓋原始碼、提交歷史、建置系統、容器產物、登錄庫及公開資料集。1

這項研究最核心的警告是：公開曝光不是一次性的資料外洩事件。只要沒有撤銷、輪換及持續監察，一條AWS憑證就可能在多年後仍然成為通往雲端基礎設施的有效入口。