Cloudflare 推出 Workers 資源級權限：代理營運稽核指南
Cloudflare 於 2026 年 9 月 15 日宣布為 Workers 提供資源級存取控制。這次更新新增 Metadata Read-Only、Content Read-Only、Editor 與 Admin 四類角色，並可套用於 Developer Platform、特定產品或單一 Worker。所有客戶都能透過控制台、API 與 Terraform 使用。
這項改變與代理營運密切相關：邊緣程式經常參與請求正規化、路由、可觀測性與憑證處理。只需查看指標的人不應同時取得原始碼；部署管線也不應能刪除其他 Worker。新模型更容易表達這些界線，但團隊仍須把角色對應到真實任務，並驗證「應該被拒絕」的路徑。
四類角色如何分工
| 角色 | 主要能力 | 代理營運情境 |
|---|---|---|
| Metadata Read-Only | 查看清單、設定與可觀測資料，但不讀取原始內容 | 值班人員檢查延遲、錯誤、日誌與追蹤 |
| Content Read-Only | 讀取內容或程式碼，但不能修改 | 審閱請求正規化 Worker 的稽核人員 |
| Editor | 讀取並更新內容與設定，但不能建立或刪除資源 | 僅向一個 Worker 部署核准版本的 CI |
| Admin | 包含建立、重新命名、刪除與授權在內的完整控制 | 受限的緊急管理帳號 |
這些角色可縮小到單一 Worker。Cloudflare 的範例指出，CI/CD 可僅取得某個 Worker 的 Editor 權限，因此能部署，但不能刪除該 Worker，也不能修改其他 Worker。
先盤點所有存取主體
列出能接觸邊緣平台的人員、服務帳號、智慧代理、CI 工作與 API Token。為每個主體記錄負責人、業務目的、目標 Worker、允許動作、到期或複核日期，以及撤權方法。
不要因身分名稱不清楚就授予寬泛角色。應先重新命名或替換含義模糊的憑證。部署、監控與緊急管理共用一個 Token，會破壞稽核歸因，也會讓撤權造成更大影響。
部署工具需要組合代理驗證值時，可參考代理憑證編碼驗證指南。儲存庫端的防洩漏措施可搭配GitHub 代理密鑰阻擋更新。
依動作選擇最窄角色
從實際動作出發，而不是從職稱出發：
- 只需指標與追蹤的值班觀察者，優先給予目標 Worker 的 Metadata Read-Only。
- 只有必須檢查原始碼時，才給程式碼審閱者 Content Read-Only。
- 部署工作只取得其負責 Worker 的 Editor。
- Admin 僅保留給極少數、受監控的緊急路徑。
- 臨時事件權限必須設定期限，並實際驗證到期後已失效。
不要為了「以後可能需要」疊加角色。工作流程確實需要兩項權限時，應記錄原因並分別測試。
將程式部署與路由變更分開
Cloudflare 指出，自訂網域與路由變更同時需要 Worker 的 Editor 權限，以及相關 Zone 的 Workers Routes 權限。這種拆分很重要：修改程式與決定流量去向是兩個不同的風險決策。
日常部署身分不應修改正式路由。路由或自訂網域變更應採獨立核准，並把 Zone 權限限制在最小範圍。變更後既要確認 Worker 版本，也要驗證公開路由。程式上傳成功不代表流量已進入預期版本。
可參考代理市場容錯移轉驗收測試，用小流量驗證避免把單一區域問題放大為全球切換。
把密鑰視為獨立控制面
資源級角色能減少不必要的存取，但不能讓已外洩的密鑰變安全。代理使用者名稱、密碼、Token 與端點憑證應存放在核准的密鑰機制中，禁止寫入 Worker 原始碼、建置產物、指令歷史、分析維度或日誌。
可觀測紀錄不應包含完整 Authorization 標頭、Cookie、代理 URL 或穩定工作階段識別碼。匯出前應雜湊或遮蔽，並依營運需求設定保留期限。
驗證拒絕路徑
權限策略不能只靠一次成功部署證明。應在非正式環境確認：
- Metadata Read-Only 能查看允許的遙測，但不能取得原始碼；
- Content Read-Only 能審閱程式，但不能發布版本；
- Editor 能更新指定 Worker，但不能刪除它；
- 僅作用於 Worker A 的身分無法查看或修改 Worker B；
- 沒有 Workers Routes 權限的部署身分無法變更路由；
- 已撤銷或過期的權限及時失敗，並產生可歸因的稽核事件。
Cloudflare 表示，API 授權錯誤現在會提供相關權限文件提示，而不只有通用 403。它適合診斷，不應觸發自動提權。缺少權限也可能表示工作流程正在執行不該執行的動作。
以小範圍驗證遷移舊權限
Cloudflare 尚未淘汰舊權限，但建議遷移到新角色。不要一次替換所有身分。先選一個低風險 Worker，建立窄範圍身分，執行讀取、部署與拒絕測試，再觀察完整營運週期。
記錄新舊策略、負責人、回復條件與移除日期。新角色證明足夠後，應撤銷舊授權，避免兩套權限長期並存。可先從唯讀監控開始，再逐步涵蓋部署與管理。
稽核檢查清單
- 每位人員、代理、CI 工作與 Token 都有明確負責人。
- 每個主體都限制到最小 Worker 或產品範圍。
- 監控、程式碼審閱、部署與管理使用獨立身分。
- 一般 CI 儘量使用 Editor，而不是 Admin。
- 路由變更需要獨立 Zone 權限與核准。
- 代理憑證不進入原始碼、建置產物或日誌。
- 成功與拒絕測試都有紀錄。
- 臨時權限的到期與撤權路徑經過驗證。
- 小範圍遷移成功後移除舊授權。
- 授權錯誤觸發複核，而不是自動擴權。
常見問題
Editor 能讓 CI 刪除 Worker 嗎？
不能。Cloudflare 將 Editor 定義為可更新內容與設定，但不能建立或刪除資源。仍應在非正式環境驗證實際行為。
Metadata Read-Only 是否足夠用於事件回應？
對只需設定、指標、日誌與追蹤的觀察者，它是適合的預設角色。只有任務確實需要查看或修改程式時才升級。
Worker 權限是否自動包含路由變更？
不包含。Cloudflare 指出，路由與自訂網域還需要對應 Zone 的 Workers Routes 權限。
自動化是否應依 403 提示申請更高權限？
不應。先比較嘗試動作與核准工作流程，再由負責人判斷是動作錯誤或策略需要調整。
合規說明
僅對組織擁有或獲授權管理的帳戶與邊緣資源實施存取控制。遵守內部核准、稽核、保留與區域資料要求。不得利用代理基礎設施或受限身分繞過服務控制、隱藏未授權存取或未經許可蒐集資料。
