9,300 條外洩 AWS 金鑰多年後仍可用：768 條足以全面接管企業雲端帳戶

一條 AWS 金鑰出現在公開儲存庫，未必代表它仍然有效；但如果金鑰一直未被撤銷、仍可通過驗證，而且權限很高，就等於雲端帳戶長期留着一扇未有上鎖的門。

Truffle Security 追蹤 2022 年 8 月至 2026 年 8 月期間公開出現的 AWS 憑證，結果顯示，問題不只是「曾經外洩」，而是大量金鑰在多年後仍然可用，當中更有數百條足以全面控制企業 AWS 帳戶。

逾 9,300 條外洩金鑰重測後仍可用

研究團隊在公開程式碼儲存庫、Git 歷史、已發布資料集、Docker 映像檔、容器登錄庫及持續整合（CI）紀錄等來源，收集到 431,875 次 AWS 機密出現紀錄。去除重複項目後，資料涉及 64,024 條獨立 AWS 存取金鑰，以及 50,654 個 AWS 帳戶。

在其中 10,616 組完整金鑰組合中，研究人員於 8 月 10 日重新測試，發現 88% 仍能成功驗證身分，換算即超過 9,300 條公開外洩金鑰仍然可用。

這個數字的重點，不只是有人曾經把金鑰放上網，而是外洩、有效及保留實際權限這幾個風險條件經常同時存在。即使開發者事後把金鑰從檔案刪除，任何人只要早已複製該憑證，仍可能繼續使用；刪檔或改寫 Git 歷史，並不等於金鑰已失效。

768 條企業金鑰擁有完整管理員控制權

在仍然有效、並被歸屬於企業帳戶的金鑰中，有 817 條與公司有關，當中包括：

• 526 條 AWS root 帳戶金鑰
• 242 條屬於套用 AWS AdministratorAccess 政策的 IAM 使用者
• 合共 768 條金鑰可全面管理企業 AWS 帳戶

Root 憑證是 AWS 客戶可擁有的最高級別存取權；而具備 AdministratorAccess 的 IAM 身分，亦可在廣泛範圍內操作 AWS 服務。有效的高權限金鑰可能讓未獲授權人士接管帳戶、讀取資料、建立雲端資源，甚至濫用雲端計費，例如開設挖礦資源。

因此，事件反映的不只是程式碼清理做得不足，更是憑證權限及生命週期管理出現問題。真正有效的處理方法，是立即撤銷或輪換金鑰，而非只把秘密從可見檔案中移除。

Hugging Face 成為最大單一來源

Hugging Face 錄得 8,482 宗 AWS 憑證外洩，是調查識別出的最大單一來源；Truffle Security 指出，當中 17.9% 是 root 憑證。

這個結果亦與團隊對 Hugging Face 公開資料的更廣泛掃描有關。Truffle Security 表示，研究涵蓋 7.6 PB 公開資料集，並在數千個資料集內發現仍然有效的憑證，顯示秘密資料不只會留在一般程式碼儲存庫，也可能隨公開發布的訓練資料及其他資料集長期流傳。

對保安團隊而言，單單掃描目前的原始碼已經不夠。Git 歷史、建置產物、容器映像檔、資料登錄庫、公開資料集及 CI 輸出，都可能保留開發者以為已經刪除的憑證。

中位數年齡約五年，絕大部分似乎沒有輪換

報告所載的憑證中位數年齡約為 1,831 日，即大約五年；最舊的一條金鑰已有 17.4 年。只有 13.7% 的紀錄找到同一使用者較新的相關金鑰，顯示大部分憑證很可能沒有按照正常流程輪換。

長期有效的存取金鑰，會拉長未獲授權使用的時間，也令企業更難追查金鑰由誰擁有、用於哪個系統。即使經歷員工轉職、應用程式搬遷、儲存庫清理或團隊交接，舊金鑰仍可能繼續有效。

所以，金鑰「很舊」不代表「一定無效」。只要曾經公開外洩，企業就應核實其狀態，並在無法證明已失效時立即撤銷、輪換及調查。

只有少數帳戶設定預算警報

Truffle Security 能讀取 2,754 個帳戶的相關資料，但當中只有 262 個啟用了 AWS 預算警報。

預算警報不能取代金鑰撤銷、日誌分析或威脅偵測，但可以在有人利用外洩憑證建立高昂資源時發出早期提示，例如進行加密貨幣挖礦或其他雲端濫用。如果通知沒有送到能夠即時處理的人手上，帳戶被入侵後的異常開支可能持續增加。

AWS 通知機制不是處理外洩的終點

報道指 AWS 的公開金鑰保護機制能夠識別已披露的存取金鑰、通知受影響客戶，並施加限制或隔離措施。 不過，今次測試仍有大量金鑰保持有效，反映偵測或通知未必每次都能促成客戶及時撤銷及輪換憑證。

偵測只是憑證事故處理的第一步。完整流程還應包括確認負責人、了解金鑰可以存取哪些資源、檢查有沒有被濫用，以及令金鑰失效。

Truffle Security 表示，其驗證工作屬於只讀測試，主要檢查憑證能否通過身分驗證，以及帳戶和權限資料，而不是修改客戶資源。不過，以上測試方法是 Truffle Security 的說法，所提供的其他來源未有逐項獨立證實所有操作細節。

AWS 金鑰外洩後，企業應該點做？

1. 立即撤銷或輪換金鑰

停用或刪除所有曾經公開的憑證；如果業務仍然需要存取權，才發出新的金鑰。從儲存庫刪除秘密、刪除檔案或改寫 Git 歷史，都不能令已被複製的金鑰失效。

2. 移除 root 存取金鑰

AWS root 使用者不應用作日常程式化存取。企業應刪除 root 金鑰，改用受控、權限範圍更窄的身分和角色。

3. 核實權限及擁有人

查清楚金鑰屬於哪個帳戶、使用者或服務，以及可以存取哪些資源。應優先處理 root 權限、AdministratorAccess、廣泛資料存取權，或可以建立基礎設施的金鑰。

4. 撤銷前後都要調查

檢查身分驗證活動、CloudTrail 紀錄、IAM 設定變更、新建資源及帳單，尋找可疑行為。撤銷金鑰只能阻止日後繼續使用，不能證明它之前從未被人使用過。

5. 以短期身分取代長期金鑰

可行的話，使用短期 IAM 角色及工作負載身分，取代永久有效的存取金鑰。配合最小權限原則，即使憑證外洩，也可以減少可造成的損害。

6. 設定預算警報及應變流程

啟用 AWS Budgets 警報及成本異常監察，並把通知交到能夠迅速採取行動的團隊或負責人手上。財務監察只能作為最後一道防線，不能取代秘密掃描、金鑰輪換及權限檢視。

真正危險的是幾個問題疊加

今次調查最值得注意的，未必只是外洩秘密的總數，而是 公開曝光、持續有效、高權限、使用年期極長，以及監察不足 同時出現。

公開資料儲存空間可以在企業忘記憑證用途多年後，仍然保留相關內容；而一條已被複製的金鑰，除非有人明確撤銷，否則未必會自行消失。

對雲端團隊來說，最安全的做法很簡單：把每一條外洩 AWS 憑證都當作已被攻陷，立即確認它可以接觸甚麼、撤銷或輪換，並逐步以短期、最小權限的身分取代長期存取金鑰。