一鍵保護所有內部應用程式——無論是否「氛圍編碼」
AI 讓各部門員工都能以前所未有的速度建構應用程式。
然而，正是這種速度讓每位 CISO 夜不能寐：任何員工都可以建構應用程式、將其部署至公共網際網路，並意外暴露內部工作或公司資料。
今天，我們推出全新工具，讓您輕鬆將部署在 Workers 上的應用程式設為私有。您現在可以將 Cloudflare Access 直接套用至單一 Worker 或帳戶下的所有 Worker，讓您的應用程式預設受到公司登入機制的保護，無需仰賴每位開發人員自行設定。
您現在可以：
- 在帳戶層級設定原則，確保所有預覽及正式部署預設受到公司登入機制的保護。
- 在單一應用程式上設定原則，確保無論以何種方式部署，與其相關聯的每個網域都強制執行驗證。
- 確切掌握誰造訪了您的應用程式。直接在程式碼中取得每位已驗證使用者的電子郵件、姓名及群組——無需 JWT（JSON Web Token）驗證。
- 部署一個每次部署都預設私有的內部平台。我們已對一個範例：一個內部的靜態網站平台，其中部署的每個 Worker 皆為私有。
Workers 上的 Access：運作方式
當您在 Worker 上啟用 Access 後，Cloudflare 會在任何請求抵達您的應用程式碼之前強制執行驗證。無論請求是透過自訂網域、路由、workers.dev 子網域或預覽 URL 到達 Worker，只要啟用了 Access，使用者就必須先完成驗證。
過去，您必須在主機名稱層級進行設定，這意味著需要在 Worker 可達的每個網域上分別設定 Access 原則。若您想為 Worker 新增自訂網域，必須先更新 Access 原則，否則該主機名稱將可在未經驗證的情況下被存取。
現在，原則直接附加至 Worker 本身，因此與該 Worker 相關聯的任何網域或 URL 都會自動受到保護。您可以選擇保護範圍：僅限預覽 URL，或所有主機名稱。
若設定為僅限預覽，每次部署新版本時，為該應用程式建立的所有預覽 URL（無論是 workers.dev 預覽 URL 或您用於預覽的自訂網域）都將要求驗證。若設定為所有主機名稱，則與該 Worker 相關聯的每個網域均受到保護——包括自訂網域、路由、workers.dev 子網域及預覽 URL。
Access 讓您掌控使用者的驗證方式。您可以連接現有的身分識別提供者，讓員工使用現有憑證登入；或限制特定電子郵件地址、電子郵件網域或群組的存取。對於智慧體，您可以透過服務權杖授予存取權限。
請參閱 Cloudflare Access for Workers 文件以瞭解詳情。
預設將帳戶中的所有 Worker 設為私有
若您的組織內有多位開發人員部署 Workers，您不會希望仰賴每個人記得啟用 Access。您希望預設就是私有。
您只需在帳戶層級設定一次 Access 原則，帳戶中現有及未來的所有 Worker 從建立之時起便設為私有。
您可以選擇原則涵蓋的範圍：僅限預覽 URL 流量、所有正式流量，或兩者皆涵蓋。若您的正式 Worker 是刻意公開的，但永遠不希望進行中的部署被外部看見，僅限預覽的設定便十分實用。
某個 Worker 需要公開？只需針對該 Worker 略過帳戶層級原則即可。
保護特定 Worker
如果您不需要帳戶層級的預設設定，只想鎖定某個特定的 Worker，可以直接將 Access 套用至該 Worker。
Worker 視圖中全新的 Access 索引標籤清楚顯示哪些原則套用至該應用程式。若有多個原則，優先順序由最具體者決定：主機名稱原則優先，其次是 Worker 原則，再次是帳戶原則。
掌握誰在存取您的應用程式
當 Access 保護您的 Worker 時，您可以取得每個請求的發出者資訊——包括電子郵件、姓名及群組——以便個人化使用者所見的內容、強制執行權限，或依使用者記錄活動。
這透過 Worker 的 context 物件（ctx）實現。每個傳送至 Worker 的請求都會攜帶一個包含該請求中繼資料的 ctx。啟用 Access 後，我們會將已驗證使用者的身分附加至其中，以 ctx.access 的形式呈現。接著，呼叫 ctx.access.getIdentity() 即可取得使用者的電子郵件、姓名及更多資訊。
過去，這意味著您需要自行驗證 JWT——解析權杖、驗證簽章，並擷取宣告。現在，只要在 Worker 上啟用 Access，每個已驗證的請求都會包含 ctx.access。
以下是取得使用者身分所需的全部程式碼：
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}`);
}
};部署前先在本機測試
我們示範了如何使用 ctx.access.getIdentity() 讓 Worker 取得請求發出者的資訊——包括電子郵件、姓名及群組。
您可以在使用 wrangler dev 於本機開發時使用此功能。在 wrangler.jsonc 中新增 access 區塊，即可模擬已驗證的使用者：
{
"access": {
"dev": {
"aud": "my-app",
"identity": { "email": "admin@company.com" }
}
}
}您的 Worker 會透過 ctx.access.getIdentity() 接收該設定——回傳一個與正式環境中相同格式的身分物件。修改設定中的電子郵件即可以不同使用者身分進行測試。
這意味著您可以驗證正確的內容是否顯示給正確的使用者，而無需每次修改後都重新部署並透過 Access 登入。
部署每個應用程式預設私有的內部平台
若您管理一個內部平台，讓員工可以在其中建構原型及部署應用程式，那麼您需要確保所有應用程式預設均為私有，而無需針對每個應用程式設定存取控制。
Workers for Platforms 讓您能夠大規模部署 Workers。每個 Worker 都存在於一個命名空間中，所有流向該命名空間的流量都通過單一入口：調度 Worker。
在您的調度 Worker 上設定 Access 原則，透過它部署的每個 Worker 預設即為私有。
我們也提供一個開放原始碼範例，讓您可以部署自己的內部拖放式部署平台——在調度 Worker 上設定一次 Access，透過它部署的每個網站預設即為私有。
點擊下方按鈕即可自行部署！
如需完整架構，請參閱 Workers for Platforms 參考架構。
建立在穩固的基礎之上
這項功能得以實現，要歸功於 FL2——一個以 Rust 為基礎的模組化代理系統，作為 Cloudflare 邊緣網路的核心驅動力。Access 是您應用程式的前端閘道，因此傳統上它在請求管線中先於所有 Workers 邏輯執行。但為了讓 Access 應用程式能夠針對個別 Workers 本身而非其主機名稱，Access 需要知道特定請求將到達哪個 Worker。因此，我們需要將 Workers 的路由與 Workers 的執行分離，並移動路由邏輯，使其能在 Access 之前執行。
在我們舊有的 FL1 系統中（基於 NGINX 和以 Lua 撰寫的模組），這項變更將既複雜又充滿風險。產品之間的交互作用可能十分微妙，而將邏輯移至請求管線較早的階段，若依賴其他產品修改的共用狀態，可能會帶來安全風險。
FL2 讓這一切變得簡單。其嚴格的模組系統將邏輯分離至定義明確、順序一致的階段，並靜態宣告各自的輸入與輸出。我們得以借助編譯器找出階段之間的任何問題互動，並有信心地逐步推出此次重構。
立即試用
此功能現已向所有人開放。請前往儀表板試用，或閱讀 Cloudflare Access for Workers 文件以開始使用。
致謝
感謝 Jesse Li、Brandon Strittmatter、Kyle Hiller、Kenny Johnson、Matt "TK" Taylor、Brendan Irvine-Broque、Yomna Shousha 及 Mike Aizatsky，感謝他們在工程與設計方面的貢獻，使這一切成為可能！
