外洩後仍持續有效，才是最棘手的地方

Truffle Security 從公開程式碼儲存庫、Git 歷史、資料集、Docker 映像檔、容器註冊庫與持續整合（CI）記錄中，蒐集到 431,875 次 AWS 秘密出現紀錄。去除重複後，資料集包含 64,024 組獨立 AWS 存取金鑰，分屬 50,654 個 AWS 帳戶。

研究人員成功取得並驗證 10,616 組完整金鑰組合。到了 8 月 10 日重新測試時，其中 88% 仍能通過身分驗證，也就是超過 9,300 組曾公開外洩的金鑰依然可用。

金鑰出現在公開儲存庫，並不一定代表它今天仍具危險性；真正嚴重的情況是金鑰尚未撤銷、仍能登入，而且保有重要權限。這次調查顯示，這三項條件經常同時存在。

768 組企業金鑰可完全控制 AWS 帳戶

在仍有效、且可歸屬於企業帳戶的金鑰中，共有 817 組與公司有關，當中包括：

• 526 組 AWS 根使用者（root）金鑰
• 242 組屬於套用 AWS AdministratorAccess 政策之 IAM 使用者的金鑰
• 總計 768 組金鑰具備公司 AWS 帳戶的完整管理權限

根使用者憑證是 AWS 客戶可擁有的最高權限之一；擁有 AdministratorAccess 的 IAM 身分，則能以廣泛權限操作多項 AWS 服務。只要金鑰仍有效，攻擊者便可能取得帳戶控制權、存取資料、建立未授權資源，甚至濫用雲端帳單進行挖礦等活動。

因此，問題不只是「原始碼清理得不夠乾淨」，更涉及權限設計與憑證生命週期管理。即使把金鑰從公開檔案中刪除，已被複製的憑證仍可能有效；真正的防護措施是撤銷或輪替金鑰。

Hugging Face 成為最大單一來源

Hugging Face 共出現 8,482 次 AWS 憑證外洩，是調查中規模最大的單一來源。Truffle Security 表示，其中 17.9% 是根使用者憑證。

這項結果也反映出更廣泛的公開資料風險。Truffle Security 曾掃描 Hugging Face 上 7.6 PB 的公開資料集，在數千個資料集內找到仍可使用的憑證，顯示秘密資訊不只會留在傳統軟體儲存庫，也可能隨公開分發的資料長期流通。

對資安團隊而言，僅掃描目前的原始碼儲存庫並不足夠。Git 歷史、建置產物、容器映像檔、註冊庫、公開資料集及 CI 輸出，都可能在開發者以為已經移除秘密後，繼續保存憑證。

中位數已存在約 5 年，卻很少被輪替

報告顯示，這些憑證的中位數年齡約為 1,831 天，大約 5 年；最老的金鑰則已有 17.4 年。只有 13.7% 的項目能找到同一使用者較新的關聯金鑰，意味著大多數憑證可能從未依照正常流程輪替。

長期有效的存取金鑰，會拉長未授權使用的時間，也讓組織更難確認憑證歸屬。它們可能跨越員工異動、應用程式搬遷、儲存庫清理與營運責任移交，持續成為雲端環境中的「遺留入口」。

因此，憑證年齡本身就應視為風險訊號。數年前外洩的金鑰不應被預設為已失效；除非擁有者能證明它已無法使用，否則應立即驗證、撤銷並展開調查。

啟用預算警示的帳戶少之又少

Truffle Security 能讀取 2,754 個帳戶的部分帳戶資訊，但只有 262 個帳戶啟用了 AWS 預算警示。

預算警示不能取代金鑰撤銷或威脅偵測，卻能在外洩憑證被用來建立高成本資源時，提供較早的提醒，例如雲端挖礦或其他濫用行為。若通知沒有送達能夠處置事件的人員，帳戶遭入侵後，異常支出可能持續累積。

AWS 的通知機制能做什麼，又不能解決什麼？

報告描述，AWS 可偵測已公開的存取金鑰、通知受影響客戶，並採取限制或隔離措施。 不過，這次測試仍發現大量金鑰持續有效，顯示偵測或通知並不一定能促使客戶及時撤銷和輪替憑證。

偵測只是憑證事件處理的第一步。完整流程還應包括確認負責人、判斷憑證可存取的資源與權限、檢查是否遭到濫用，最後使金鑰失效。

Truffle Security 將自身驗證描述為「唯讀」測試：研究人員檢查憑證是否能通過驗證，以及帳戶或權限中繼資料，並未修改客戶資源。不過，這項測試方法是 Truffle Security 的說法，提供的資料並未由所有來源獨立證實，因此應以此脈絡理解相關描述。

AWS 金鑰外洩後，組織應立即採取的措施

1. 立即撤銷或輪替金鑰

停用或刪除所有公開外洩的憑證；若業務仍需要存取權，再核發新的金鑰。單純從儲存庫刪除秘密、移除檔案或重寫 Git 歷史，都不能讓已被複製的憑證失效。

2. 移除根使用者存取金鑰

AWS 根使用者存取金鑰不應用於日常程式化操作。應刪除根金鑰，改用受控且權限範圍明確的身分執行工作負載。

3. 釐清權限與憑證歸屬

確認金鑰所屬的帳戶、使用者、服務與可存取資源，並優先處理具備根權限、AdministratorAccess、廣泛資料存取權，或能建立基礎設施之權限的金鑰。

4. 撤銷前後都要調查

檢查身分驗證活動、CloudTrail 紀錄、IAM 變更、新建立的資源與帳單，尋找可疑行為。撤銷只能阻止外洩金鑰繼續使用，無法證明它在此之前沒有被濫用。

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

在可行的情況下，使用短期 IAM 角色與工作負載身分，取代永久有效的存取金鑰。遵循最小權限原則，也能降低憑證外洩後的潛在損害。

6. 設定預算警示並建立通報流程

啟用 AWS Budgets 預算警示與成本異常監控，並將通知送達能迅速採取行動的聯絡人。財務監控是最後一道防線，不能取代秘密掃描、憑證輪替與權限檢視。

更廣泛的雲端資安警示

這項調查最值得注意的，不只是外洩秘密的總數，而是 公開暴露、持續有效、高度權限、長期未更新與監控不足 同時出現。公開資料儲存空間可能在組織忘記憑證用途與位置多年後，仍保留相關資訊；而被複製的金鑰，也可能一直有效到有人明確撤銷為止。

對雲端團隊而言，較安全的作法是把每一組外洩 AWS 憑證都視為已遭入侵：立即確認它能接觸哪些資源，撤銷或輪替金鑰，並以短效、最小權限的身分取代長期存取憑證。

外洩後仍持續有效，才是最棘手的地方

Truffle Security 從公開程式碼儲存庫、Git 歷史、資料集、Docker 映像檔、容器註冊庫與持續整合（CI）記錄中，蒐集到 431,875 次 AWS 秘密出現紀錄。去除重複後，資料集包含 64,024 組獨立 AWS 存取金鑰，分屬 50,654 個 AWS 帳戶。

研究人員成功取得並驗證 10,616 組完整金鑰組合。到了 8 月 10 日重新測試時，其中 88% 仍能通過身分驗證，也就是超過 9,300 組曾公開外洩的金鑰依然可用。

金鑰出現在公開儲存庫，並不一定代表它今天仍具危險性；真正嚴重的情況是金鑰尚未撤銷、仍能登入，而且保有重要權限。這次調查顯示，這三項條件經常同時存在。

768 組企業金鑰可完全控制 AWS 帳戶

在仍有效、且可歸屬於企業帳戶的金鑰中，共有 817 組與公司有關，當中包括：

• 526 組 AWS 根使用者（root）金鑰
• 242 組屬於套用 AWS AdministratorAccess 政策之 IAM 使用者的金鑰
• 總計 768 組金鑰具備公司 AWS 帳戶的完整管理權限

根使用者憑證是 AWS 客戶可擁有的最高權限之一；擁有 AdministratorAccess 的 IAM 身分，則能以廣泛權限操作多項 AWS 服務。只要金鑰仍有效，攻擊者便可能取得帳戶控制權、存取資料、建立未授權資源，甚至濫用雲端帳單進行挖礦等活動。

因此，問題不只是「原始碼清理得不夠乾淨」，更涉及權限設計與憑證生命週期管理。即使把金鑰從公開檔案中刪除，已被複製的憑證仍可能有效；真正的防護措施是撤銷或輪替金鑰。

Hugging Face 成為最大單一來源

Hugging Face 共出現 8,482 次 AWS 憑證外洩，是調查中規模最大的單一來源。Truffle Security 表示，其中 17.9% 是根使用者憑證。

這項結果也反映出更廣泛的公開資料風險。Truffle Security 曾掃描 Hugging Face 上 7.6 PB 的公開資料集，在數千個資料集內找到仍可使用的憑證，顯示秘密資訊不只會留在傳統軟體儲存庫，也可能隨公開分發的資料長期流通。

對資安團隊而言，僅掃描目前的原始碼儲存庫並不足夠。Git 歷史、建置產物、容器映像檔、註冊庫、公開資料集及 CI 輸出，都可能在開發者以為已經移除秘密後，繼續保存憑證。

中位數已存在約 5 年，卻很少被輪替

報告顯示，這些憑證的中位數年齡約為 1,831 天，大約 5 年；最老的金鑰則已有 17.4 年。只有 13.7% 的項目能找到同一使用者較新的關聯金鑰，意味著大多數憑證可能從未依照正常流程輪替。

長期有效的存取金鑰，會拉長未授權使用的時間，也讓組織更難確認憑證歸屬。它們可能跨越員工異動、應用程式搬遷、儲存庫清理與營運責任移交，持續成為雲端環境中的「遺留入口」。

因此，憑證年齡本身就應視為風險訊號。數年前外洩的金鑰不應被預設為已失效；除非擁有者能證明它已無法使用，否則應立即驗證、撤銷並展開調查。

啟用預算警示的帳戶少之又少

Truffle Security 能讀取 2,754 個帳戶的部分帳戶資訊，但只有 262 個帳戶啟用了 AWS 預算警示。

預算警示不能取代金鑰撤銷或威脅偵測，卻能在外洩憑證被用來建立高成本資源時，提供較早的提醒，例如雲端挖礦或其他濫用行為。若通知沒有送達能夠處置事件的人員，帳戶遭入侵後，異常支出可能持續累積。

AWS 的通知機制能做什麼，又不能解決什麼？

報告描述，AWS 可偵測已公開的存取金鑰、通知受影響客戶，並採取限制或隔離措施。 不過，這次測試仍發現大量金鑰持續有效，顯示偵測或通知並不一定能促使客戶及時撤銷和輪替憑證。

偵測只是憑證事件處理的第一步。完整流程還應包括確認負責人、判斷憑證可存取的資源與權限、檢查是否遭到濫用，最後使金鑰失效。

Truffle Security 將自身驗證描述為「唯讀」測試：研究人員檢查憑證是否能通過驗證，以及帳戶或權限中繼資料，並未修改客戶資源。不過，這項測試方法是 Truffle Security 的說法，提供的資料並未由所有來源獨立證實，因此應以此脈絡理解相關描述。

AWS 金鑰外洩後，組織應立即採取的措施

1. 立即撤銷或輪替金鑰

停用或刪除所有公開外洩的憑證；若業務仍需要存取權，再核發新的金鑰。單純從儲存庫刪除秘密、移除檔案或重寫 Git 歷史，都不能讓已被複製的憑證失效。

2. 移除根使用者存取金鑰

AWS 根使用者存取金鑰不應用於日常程式化操作。應刪除根金鑰，改用受控且權限範圍明確的身分執行工作負載。

3. 釐清權限與憑證歸屬

確認金鑰所屬的帳戶、使用者、服務與可存取資源，並優先處理具備根權限、AdministratorAccess、廣泛資料存取權，或能建立基礎設施之權限的金鑰。

4. 撤銷前後都要調查

檢查身分驗證活動、CloudTrail 紀錄、IAM 變更、新建立的資源與帳單，尋找可疑行為。撤銷只能阻止外洩金鑰繼續使用，無法證明它在此之前沒有被濫用。

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

在可行的情況下，使用短期 IAM 角色與工作負載身分，取代永久有效的存取金鑰。遵循最小權限原則，也能降低憑證外洩後的潛在損害。

6. 設定預算警示並建立通報流程

啟用 AWS Budgets 預算警示與成本異常監控，並將通知送達能迅速採取行動的聯絡人。財務監控是最後一道防線，不能取代秘密掃描、憑證輪替與權限檢視。

更廣泛的雲端資安警示

這項調查最值得注意的，不只是外洩秘密的總數，而是 公開暴露、持續有效、高度權限、長期未更新與監控不足 同時出現。公開資料儲存空間可能在組織忘記憑證用途與位置多年後，仍保留相關資訊；而被複製的金鑰，也可能一直有效到有人明確撤銷為止。

對雲端團隊而言，較安全的作法是把每一組外洩 AWS 憑證都視為已遭入侵：立即確認它能接觸哪些資源，撤銷或輪替金鑰，並以短效、最小權限的身分取代長期存取憑證。