核心命題： 在傳統機房裡，攻擊者要拿到的是「帳號密碼」。在雲端，他要拿到的是一個能被信任的身分——而這種身分可能不是人，是程式。 本文角度： 概念拆解與收緊建議。不含任何操作細節。
憑據的形態變了，但風險沒變
回想一下傳統環境：登入系統要靠帳號密碼；伺服器之間要互相呼叫，往往就用一組寫在設定檔裡的帳密。
雲端改變了這件事。現在：
- 應用程式呼叫資料庫，用的是服務主體（一個程式身分）；
- 程式需要存取儲存桶，會取得一個臨時憑證（有到期時間）；
- 部署流程要用到密鑰，可能放在 CI/CD 的環境變數裡。
形態變了，但攻擊者的目標沒變：取得一個被信任的身分。
四個必須分清的概念
概念一：服務主體（Service Principal / Service Account）
白話： 一個「不是人」的身分。它代表一個應用程式或一項自動化任務。
為什麼重要： 人會離職、會改密碼、會被稽核盯上；服務主體往往長期存在、長期有效、甚少被檢視。憑據一旦洩漏，可能多年不被發現。
概念二：角色（Role）與權限綁定
白話： 雲端不直接把權限給某個身分，而是先定義「角色」（能做什麼），再把角色綁定到身分上。
為什麼重要： 這種設計本意是為了靈活與可管理，但實務上常見的問題是——綁定過寬（給了比需要更多的權限），而且很少收窄。
概念三：臨時憑證（Temporary Credentials）
白話： 一種有到期時間的憑據。時間到了自動失效。
為什麼重要： 這是雲端相對傳統環境最大的安全紅利。長期有效的密鑰一旦洩漏就是永久缺口；臨時憑證把「洩漏的影響時間」壓縮到幾小時。
一個有用的判斷標準： 如果你們的環境裡存在大量「長期密鑰」，那答案很簡單——能改成臨時憑證的都應該改。
概念四：CI/CD 密鑰
白話： 自動化部署流程需要用到的憑據。
為什麼重要： 這些密鑰通常權限很大（能部署、能改配置、能讀取其他密鑰），而且存在於程式碼倉庫或建置系統中——一旦洩漏，影響範圍極廣。
五個最常見的盲點
盲點一：長期密鑰散落各處
最常見的情況：多個系統各自持有一組長期有效的密鑰，沒有人知道總共有幾組、什麼時候建立的、誰在用。
收緊： 先做一次盤點——「我們有多少組長期憑據？分別在哪些地方？」很多企業第一次盤點就會嚇一跳。
盲點二：權限過寬（「反正都是內部系統」）
綁定角色時，為了不要出錯，往往直接給一個較大的權限範圍。
收緊： 從最小權限開始，遇到權限不足再逐步加——而不是反過來。
盲點三：儲存桶與服務的意外公開
雲端環境最經典的事故類型：儲存桶沒有正確設定，任何人都能讀取。
收緊： 自動化檢查公開存取設定，而不是靠人工記得。
盲點四：日誌開了但沒人看
啟用審計日誌是好事，但如果沒有人定期查看、沒有異常告警，日誌只是佔空間。
收緊： 明確指定「誰負責看、多久看一次、什麼情況要告警」。
盲點五：離職與委外流程未覆蓋雲端
人事變動會撤銷內部系統的權限，但雲端上的服務主體、外包專案的角色綁定常常被遺漏。
收緊： 把雲端權限納入同一份「人員／廠商變動檢查清單」。
一份可落地的收緊順序
按性價比排序，建議依序進行：
- 盤點：列出所有長期憑據、所有服務主體、所有對外公開的資源；
- 改臨時：把能用臨時憑證取代的長期密鑰全部換掉；
- 收權限：把權限綁定逐項收窄到實際需要；
- 看日誌：指定負責人、設定告警條件；
- 進流程：把雲端權限寫進人事與委外變動的清單；
- 定期覆核：每季檢查一次「誰有什麼權限、還需不需要」。
為什麼這件事和 AI 代理有關
把前面幾篇連起來看：攻擊方（無論是人或代理）在攻擊鏈上最執著的資源是憑據。而在雲端環境裡，憑據的數量比傳統環境多得多——每個服務主體、每個 CI/CD 流程、每個自動化任務，都是一組潛在的憑據。
這意味著：雲端環境的「憑據隔離」難度更高，但回報也更大。
三個一句話
- 雲端的身分不只是人，還包括程式。 服務主體往往比人類帳號更危險，因為它更少被檢視。
- 臨時憑證是最大的紅利。 能改的都應該改——它把「永久缺口」變成「幾小時缺口」。
- 權限收窄要一次一次做。 沒有人能一次做對，但每次都往正確方向走。
下一步
- 想了解供應鏈風險（雲端依賴是其中一環），可閱讀供應鏈與第三方風險
- 想了解憑據在傳統環境中的形態，可閱讀憑據與 AD 概念層
- 想從整體防禦視角檢視，可閱讀從紅隊復盤看防禦