Cloudflare Access 可作為 WordPress 登入頁前的身份代理，只有符合政策的使用者才能到達來源。它不會取代 WordPress 密碼、雙重驗證和角色權限。設定過廣可能阻擋 AJAX、REST API、付款回傳或排程，因此要從測試站開始。
先列出需要保護的入口
一般包括 `wp-login.php`、後台路徑和管理子網域，但前台及外掛也可能呼叫後台端點。整理登入、密碼重設、媒體、AJAX、REST API 和 Webhook，再決定保護路徑或獨立主機名稱。
理解 Access 是網站前的第二道門
訪客先通過 Access 身份政策，才會看到 WordPress 登入畫面。即使 Access 已核准，WordPress 仍要驗證自己的帳戶。兩層使用不同工作階段，登出 WordPress 不一定同時結束 Access，反之亦然。
建立 Self-hosted 應用
在 Zero Trust 的 Applications 建立自託管 Web 應用，選擇受 Cloudflare 代理的網域或公開主機名稱。應用路徑越精確，誤傷前台的風險越低。建立前確認 DNS、HTTPS 和 WordPress 登入本身正常。
使用公司身份供應商
團隊可連接身份供應商，讓 Access 依電郵、群組和其他屬性判斷使用者。不要把「任何有效電郵」誤當成只限自己，並測試未授權帳戶確實被拒絕。
Access 拒絕未匹配使用者
應用是 deny by default，使用者必須符合 Allow 政策才可進入。建立 Include 規則定義候選人，再用 Require 加上額外條件，以 Exclude 移除特定帳戶。Include 多項通常類似 OR，而多個 Require 可能同時必須成立。
避免 Include Everyone
若 Allow 政策包含 Everyone，等於任何人都可能通過該層。使用一次性電郵驗證時，「所有有效電郵」亦不代表公司員工。至少限制明確電郵、公司網域或身份群組，並定期核對離職人員。
Bypass 規則要保持精確
前台 AJAX、付款 Webhook 或監察服務可能需要不經互動登入，但 Bypass 會停用 Access 控制及相關記錄。若機器流量需要驗證，優先考慮 Service Auth。任何例外都限制在必要主機、路徑和方法，不能全站繞過。
留意政策評估順序
Service Auth 和 Bypass 等動作有其評估優先次序，Allow 與 Block 亦按規則順序處理。較精確例外與一般員工政策要有清楚名稱和理由。修改順序後重新測試，不能假設下方規則總能覆蓋上方結果。
為管理員要求額外條件
除身份群組外，可按需要要求裝置狀態、地區、網絡或其他選擇器。條件過嚴會令員工出差或更換裝置時失去存取。先為主要管理員和後備管理員準備可審核的復原程序。
測試 WordPress 重要流程
用授權和未授權帳戶測試登入、登出、密碼重設、文章編輯、媒體上載、外掛更新、AJAX、REST API 和排程。WooCommerce 網站還要測試付款回傳、結帳和訂單狀態。錯誤只在某路徑出現時，先檢查應用範圍。
保護來源避免直接繞過
若來源 IP 仍接受直接請求，攻擊者可能繞過 Access。可配合 Tunnel 或防火牆限制入口，同時保留安全管理與回復通道。
設定合理工作階段時間
過長工作階段令遺失裝置持續有效，過短則頻繁打斷編輯。按管理風險設定 Access session duration，並理解身份供應商和 WordPress 自己也有工作階段。人員離職時撤銷身份、Access 及 WordPress 帳戶。
監察拒絕與異常登入
查看 Access 日誌、WordPress 登入紀錄和來源安全事件，分辨政策拒絕、WordPress 密碼錯誤及應用程式故障。大量拒絕可能是攻擊，也可能是錯誤範圍阻擋正常 API。修改政策前先找到對應路徑和身份。
準備緊急復原
記錄如何暫停應用、修改政策和透過受保護管理通道進入來源。至少兩位可信管理員應能執行復原。不要以永久 Bypass 作後門；緊急例外要有到期時間，事件後立即移除並檢查日誌。
結語
Cloudflare Access 保護 WordPress 後台的可靠方式是：先盤點路徑、建立精確自託管應用、以明確身份 Allow，再為必要機器流量使用受控驗證。測試 AJAX、API 和付款流程，並限制來源直接入口，才能增加防護而不破壞網站。
