Cloudflare Access Service Token 輪替怎麼做？Grace Period 與停用流程

先把輪替、停用、刪除分成三種動作#

Cloudflare 在 2026 年 8 月 25 日加入輪替 Grace Period 與 token 狀態控制。Dashboard 可選擇 1 小時至 30 天的寬限期；API 則用 RFC 3339 時間指定舊 Secret 的到期時間。這個時間是遷移截止點，不是「舊值永遠有效」的備援機制。

日常輪替：先建立切換計畫，再產生新 Secret#

建議把輪替拆成以下順序，並在密碼管理工具或部署紀錄中留下 token ID、使用服務與預定失效時間：

1. 列出所有會使用這組 token 的 workflow、服務、Secret name 和環境，先確認沒有遺漏的非正式腳本。
2. 在 Access 的 Service Tokens 頁面選取 token，執行 rotate，設定足夠讓所有使用端完成部署的 Grace Period。
3. 只在產生當下保存新的 Client Secret；Cloudflare 不會把完整 Secret 當成可隨時重看的欄位。
4. 先更新 staging，再更新 production 與排程工作。Client ID 維持不變，應替換的是 Secret 和安全儲存位置。
5. 用實際請求驗證新值可以通過 Access，再觀察舊值是否仍被使用。不要只測 Dashboard 的登入畫面。
6. Grace Period 到期後，再檢查失敗請求、部署紀錄和密碼管理工具，確認沒有服務還依賴舊 Secret。

如果要以 API 自動化，輪替 endpoint 的 body 可以指定舊 Secret 的到期時間：

1
curl --request POST \
2
  --url "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/access/service_tokens/$SERVICE_TOKEN_ID/rotate" \
3
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
4
  --header "Content-Type: application/json" \
5
  --data '{"previous_client_secret_expires_at":"2026-08-30T02:00:00Z"}'

上面的時間只是示例，實際截止點應依部署窗口設定。若省略 previous_client_secret_expires_at，前一個 Secret 會立即失效；自動化腳本不要把這個欄位誤刪，除非你已經確定所有使用端同步完成。

疑似外洩：先停用，再判斷是否要重建#

當 Secret 出現在公開 log、錯誤回報或不明主機上，先到 Service Tokens 將 token 設為 disabled，讓它停止驗證。停用會保留設定，之後可以再啟用，但不要把「可以重新啟用」當成已完成修復。

接著確認存取紀錄、撤換可能暴露的 CI Secret，並檢查這組 token 是否有超出必要範圍的 Access policy。若仍要保留同一個 service identity，可在控制風險後重新產生 Secret；若使用端已分散到不同系統，則更適合拆成多組 token，降低下一次輪替的爆炸半徑。

Access 只負責在入口驗證這組 service identity，後端仍應限制 API 權限和可讀取的資料。若你是把 Worker 當成內部 API，還可以搭配 Cloudflare Workers 套用 Access 的 Worker scope 設定檢查不同環境的保護範圍。

新的 cfast_ Secret 需要立刻輪替嗎？#

不一定。Cloudflare 文件指出，2026 年 8 月 26 日起新建立或輪替的 Client Secret 會使用 cfast_ 開頭、後接 40 個英數字元與 8 個字元 checksum 的格式；既有 64 字元十六進位 Secret 仍可使用，也沒有因為格式變更而被要求立即輪替。Client ID 和 HTTP header 的使用方式不變。

因此排查時應分開看兩件事：格式是否符合目前文件，以及 Secret 是否需要依組織政策、時間表或事件處理而輪替。看到舊格式不代表它已失效；看到新格式也不代表它可以跳過權限盤點。

輪替完成前的驗證清單#

• 新 Client Secret 已寫入正確的 Secret store，沒有出現在 workflow log 或部署輸出。
• staging、production、排程任務與本機管理腳本都完成一次真實驗證。
• 舊 Secret 的 Grace Period、token disabled 狀態和實際時間點已被記錄。
• 失敗請求能對應到服務與版本，而不是只看到一筆模糊的 401。
• Access policy、service token 的用途和擁有者仍符合最小權限原則。

結論是：一般輪替用 Grace Period 讓使用端分批切換；疑似外洩則先 disable，不能等待寬限期自然結束。把 token ID、用途、失效窗口和驗證結果寫進可追蹤的變更紀錄，之後的輪替才不會依賴某位維運者的記憶。

常見問題#