問題：內部工具太快上線，安全跟不上
AI 讓每個部門的員工都能快速打造應用，但速度也帶來風險：任何人部署到公開網路時，可能不小心暴露內部資料。Cloudflare 在 2026 年 8 月 14 日發布新功能，讓託管在 Workers 上的應用更容易保持私密。現在可以直接對 Worker 或整個帳戶套用 Cloudflare Access，讓應用預設就在公司登入之後，不必依賴每位開發者自行設定。
從主機名稱層級改為 Worker 層級
過去要為每個可達的網域分別設定 Access 政策；新增自訂網域時，若沒先更新政策，該網域就會未經認證地公開。現在政策直接綁定 Worker，任何關聯的網域或 URL 都會自動受到保護。你可以選擇只保護預覽 URL，或保護所有主機名稱。若選預覽，每次部署新版本時，workers.dev 預覽網址或自訂預覽網域都會要求認證。若選全部，自訂網域、路由、workers.dev 子網域和預覽 URL 全部涵蓋。
帳戶層級預設私有，減少人為疏漏
如果組織內有許多開發者部署 Workers，不該依賴每個人記得啟用 Access。現在可以在帳戶層級設定一次 Access 政策，之後帳戶內現有與未來的每個 Worker，從建立那一刻起就是私密的。政策可以只涵蓋預覽流量、所有正式流量，或兩者。預覽限定適合正式 Worker 刻意公開、但不想讓進行中的部署暴露的情境。需要公開某個 Worker 時，可以在該 Worker 上繞過帳戶政策。
直接取得使用者身份，不用自己驗證 JWT
當 Access 保護 Worker 時，每個請求都會帶上已驗證使用者的 email、姓名和群組，方便個人化內容、強制權限或記錄活動。這透過 Worker 的 context 物件（ctx）運作。啟用 Access 後，系統會把身份附加為 ctx.access，呼叫 ctx.access.getIdentity() 就能取得使用者資訊。以前必須自行解析 JWT、驗證簽章並擷取 claims，現在這些都省了。在 Worker 中取得身份的完整寫法如下：
export default {
async fetch(request, env, ctx) {
if (!ctx.access) {
return new Response("Access required", { status: 403 });
}
const identity = await ctx.access.getIdentity();
const email = identity?.email ?? "unknown";
return new Response(`Hello, ${email}`);
}
};本地開發時，可以在 wrangler.jsonc 加入 access 區塊模擬已驗證使用者，ctx.access.getIdentity() 會回傳類似正式環境的身份物件。更換 email 就能測試不同使用者，不必每次部署後再透過 Access 登入。access 區塊的設定方式如下：
{
"access": {
"dev": {
"aud": "my-app",
"identity": { "email": "admin@company.com" }
}
}
}內部平台：每個部署預設私有
如果管理內部平台讓員工原型化並部署應用，需要每個應用都私有，但不想逐一設定。Workers for Platforms 可以大規模部署 Workers，所有流量都經過單一入口的 dispatch Worker。只要在 dispatch Worker 設定 Access 政策，透過它部署的每個 Worker 就預設私有。Cloudflare 也開源了一個範例，可以部署自己的內部拖放式平台，在 dispatcher worker 設定一次 access，之後每個站台都預設私有。
底層架構：FL2 讓路由與執行分離
這項功能由 FL2 支援，這是 Cloudflare 邊緣網路的新 Rust 模組化代理。Access 傳統上在請求管線中先於所有 Workers 邏輯執行。但要讓 Access 針對個別 Worker 而非主機名稱，必須知道請求要送達哪個 Worker。因此需要把 Workers 路由從執行中分離，並將路由邏輯移到 Access 之前。在舊的 FL1 系統（基於 NGINX 和 Lua 模組）中，這種改動複雜且有風險。FL2 的嚴格模組系統將邏輯分成定義良好、順序一致的階段，靜態宣告輸入與輸出，讓編譯器找出階段間的破壞性互動，並能逐步安全地推出重構。
實際使用方式
這項功能現在對所有人開放。可以在儀表板中試用，或參考 Cloudflare Access for Workers 文件。設定帳戶層級政策後，所有新的 Worker 自動受保護；需要公開時再針對單一 Worker 繞過。查看 Worker 的 Access 分頁，可以看到套用的政策，優先順序為主機名稱政策、Worker 政策、帳戶政策。
對產品建構者來說，這代表內部工具可以更快上線，同時把安全負擔從個別開發者轉移到平台層級。預設私有加上直接取得身份，減少了設定摩擦，也讓稽核與個人化更容易。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。