騰訊雲帳號認證服務 騰訊雲 API 密鑰授權範圍過大？如何配置微粒度 CAM 策略

先說結論：API 密鑰不是不能用，而是不能直接給全能權限

很多團隊第一次接騰訊雲時，最常見的做法就是先申請一組 API 密鑰，然後把它塞進程式、腳本、CI/CD，最後為了省事直接配上很大的權限。短期看，開發確實快了；長期看，這其實是在拿整個雲環境賭運氣。只要密鑰被洩露，攻擊者不只可以讀資料，還可能刪資源、改配置、關服務，甚至把監控和日誌一起動掉，讓你連追查都變得困難。

所謂「授權範圍過大」，本質上不是一個管理員按鈕沒點對，而是權限設計沒有按業務切開。很多人以為只要能跑起來就好，等出事再收權限。問題是，真正出事的時候，往往不是「少了哪個權限」，而是「多給了太多本來不該有的權限」。所以談 CAM 策略，不是為了把流程搞複雜，而是把風險提前關進籠子裡。

先理解 CAM、密鑰和子帳號之間的關係

在騰訊雲裡，CAM 是權限控制的核心。你可以把它理解成一套規則系統：誰可以做什麼、對哪個資源做、在什麼條件下做。API 密鑰只是身份憑證，真正決定這把鑰匙能開哪些門的，是掛在它身上的 CAM 策略。

如果你直接用主帳號的密鑰，風險最大。主帳號通常擁有最高控制權，一旦外洩，等於把整個帳號交給別人。更合理的做法，是用子帳號或角色來承接業務，再把策略精準綁上去。這樣即使某個系統被入侵，攻擊面也只會停留在那個子任務上，不會一路穿透到整個雲環境。

CAM 策略通常可以拆成幾個關鍵元素：動作、資源、條件。動作是你允許它做什麼，例如讀物件、上傳檔案、查詢實例；資源是它只能碰哪些對象，例如某個 bucket、某台 CVM、某個資料庫；條件則是把權限再縮一步，例如只允許固定來源 IP、固定時間段、或者必須符合額外安全要求。這三層一旦搭好，權限就不再是「可不可以用」，而是「只在需要的地方用」。

微粒度授權的核心，不是把權限切到最細，而是切到剛剛好

很多人聽到「微粒度」就以為要把每個 API 都單獨開一條策略，結果把自己搞得很累。其實真正有效的做法，不是追求表面上的細，而是追求業務上的準。最好的權限設計，應該讓開發、運維、測試三種角色各做各的事，彼此看得見流程，但碰不到不該碰的資源。

你可以先記住四個原則：

• 先拆身份，再拆權限。不要讓一組密鑰同時服務多個系統。
• 先收動作，再收資源。能少給一個 action，就先少給一個。
• 能用條件限制，就不要只靠 allow。來源 IP、有效時間、MFA 都是很實用的保險。
• 權限要可回收。項目結束、環境下線、交接完成，策略就該跟著清掉。

真正成熟的團隊，通常不會問「這個帳號能不能做更多」，而是反過來問：「這個任務完成，最少需要哪些權限？」這個思路一變，策略設計就會乾淨很多，後面排錯、審計和責任劃分也都會清楚。

配置 CAM 策略前，先做一張權限清單

不要急著進控制台點新增策略。你先做一件更重要的事：把應用程式真正會用到的雲服務列出來。很多人權限會開大，就是因為根本不知道程式到底調了哪些 API，只好先丟一把超大鑰匙，怕少了哪個就跑不起來。其實只要先整理呼叫路徑，常常可以把 80% 的冗餘權限直接砍掉。

建議你照這個順序整理：

• 列出系統會接觸的雲服務，例如 COS、CVM、CDB、CLB、CLS。
• 找出每個服務實際使用的動作，例如查詢、上傳、下載、建立、刪除。
• 標出資源範圍，例如單一 bucket、單一實例、單一專案名稱。
• 區分讀寫需求，讀和寫最好分成兩組策略。
• 判斷哪些場景可以加條件，例如只允許內網、只允許辦公網段、只允許夜間批次任務。

這份清單一做好，你就會很明白：有些服務其實只需要查詢權限；有些任務只需要上傳，不需要刪除；有些管理操作只應該留給人工，不該放進自動化腳本。權限越貼近真實需求，後面出問題的機率就越低。

實際配置時，按這五步走最穩

第一步：不要從主帳號開始。先建立子帳號或角色，讓業務系統綁定這個身份。主帳號保留給真正的管理工作，不要拿去當日常接口憑證。

第二步：先用基礎策略跑通，再改成自訂策略。如果你一開始就手寫得太細，容易漏掉必要動作；但如果一直停留在預設的大權限，又容易留下安全洞。最好的方式是先驗證業務流程，再把多餘部分一條條收掉。

第三步：盡量把資源寫死。例如只允許某一個 bucket、某一台實例、某一個資料庫，不要為了方便把整個地域、整個產品類別全部放開。很多事故不是因為有人故意破壞，而是腳本本來只應該碰測試環境，結果拿到權限後順手把正式環境也改了。

第四步：把高風險動作單獨拆開。刪除、關閉、重啟、變更計費相關配置，這些動作最好不要跟一般讀寫混在同一條策略裡。即便同一個系統需要，也可以考慮把它們拆成另一個角色，平時不用，必要時再臨時切換。

第五步：上線後一定要測。很多策略不是寫錯，而是寫得太理想。你要實際跑一遍業務流程，看哪些 API 失敗、哪些多餘。調整策略的原則很簡單：缺什麼補什麼，多什麼刪什麼，不要因為怕報錯就一路加寬。

一個比較典型的策略範例

假設你的應用只需要對某個 COS bucket 做上傳、下載和列表查詢，那就不該給它整個 COS 的管理權限，也不該允許它碰其他 bucket。下面是一個思路示例，重點在於把動作和資源都收斂到具體對象，而不是給一個泛用的大範圍：

{"version":"2.0","statement":[{"effect":"allow","action":["cos:GetObject","cos:PutObject","cos:ListBucket"],"resource":["qcs::cos:ap-guangzhou:uid/1250000000:example-bucket-1250000000","qcs::cos:ap-guangzhou:uid/1250000000:example-bucket-1250000000/*"]}]}

如果這個應用只讀不寫，就把 PutObject 拿掉；如果它只需要上傳，不需要列舉檔案，ListBucket 也可以去掉。這就是微粒度的價值：不是把策略做得花，而是讓每一條權限都能對上業務邏輯。

如果換成 CVM 這類運算資源，思路也一樣。比如某個自動化腳本只需要查詢實例狀態、重啟某一台指定機器，那就不要把整個地域所有實例都放開，更不要讓它有創建、刪除、修改關鍵配置的能力。很多誤操作其實不是技術問題，而是權限本來就沒有邊界。

條件限制常被忽略，但它其實很有用

不少人做 CAM 時只記得寫 action 和 resource，卻把 condition 忽略掉。這很可惜，因為條件限制通常是最後一道保險。比如某個管理腳本只應該從內網機器執行，那就把來源 IP 限住；某個操作只該在工作時段執行，那就把時間窗收窄；某些高風險帳號，只要不是人工核准的流程，就不應該放行。

騰訊雲帳號認證服務 條件限制的好處，不只是增加安全性，也能幫助你在權限出問題時縮小排查範圍。當一筆請求被拒絕時，你可以很快判斷是動作不對、資源不對，還是來源條件不符合。這種可觀察性，對維運來說很重要，因為它會直接影響你排錯的時間成本。

常見錯誤：看起來在做權限，實際上只是把風險換個地方

第一個錯誤，是把一整套業務都塞進同一個密鑰。今天這個專案會用，明天那個腳本也會用，最後沒人說得清楚誰在調哪個資源。這種權限混用，一旦出事，連影響範圍都很難界定。

第二個錯誤，是只管能不能執行，不管執行後會碰到什麼資料。比如一個查詢接口，表面上只是讀，實際上卻可以看到所有環境的資訊；一個批次任務，表面上只是同步，實際上卻順手改了生產配置。這種情況，權限看似不大，風險卻不小。

騰訊雲帳號認證服務 第三個錯誤，是策略寫完就不再回頭看。業務會變，架構會變，服務會下線，權限也應該跟著變。很多歷史包袱之所以越積越多，就是因為大家默認權限是一次性的配置，卻忘了它本質上應該是持續維護的資產。

第四個錯誤，是把「臨時測試」變成長期方案。測試時先開大權限，等跑通再收，這沒問題；有問題的是跑通之後沒有真的收回來。久而久之，最初那個臨時開口就成了永久漏洞。

真正落地時，最有用的是一套可持續的習慣

CAM 策略不是寫一次就結束，而是要配合日常管理。你可以把幾個習慣固定下來：新項目先做權限設計、每次上線都做權限復核、每季清理一次閒置密鑰、每次人員離職或交接都檢查綁定的子帳號、每次事故都回頭看是否存在過度授權。

如果你願意再往前一步，可以把權限審核加入發布流程。也就是說，不只是程式碼要 review，策略也要 review。因為很多安全問題不是寫出來的，而是默默放進去的。當權限變成流程的一部分，團隊自然會更在意邊界，也更容易形成共識。

騰訊雲帳號認證服務 最後要記住一句話：權限不是越多越安心，剛剛好才是最安全。對雲端來說，真正成熟的管理，不是讓每把鑰匙都能打開所有門，而是讓它只在需要的門前有效。把 CAM 策略收細一點，系統可能不會立刻變得更快，但它一定會變得更穩、更好查、更不容易出大事。

結語：把權限收小，不是限制效率，而是保住底線

騰訊雲 API 密鑰授權範圍過大，表面看只是設定問題，實際上反映的是整個權限思維。你若把密鑰當成便利工具，它就會在某一天變成風險入口；你若把它當成需要精準管理的安全資產，它就能幫你把系統控制在可預期的範圍內。微粒度 CAM 策略的價值，不在於炫技，而在於把每一次呼叫都放回該去的位置。