Zero Trust 的基礎是為每個應用程式、使用者和裝置定義精細的控制和授權原則。擁有足夠精細的系統來做到這一點對於同時滿足監管和安全要求至關重要。但如此多的控制有一個潛在的缺點：為了解決使用者問題，管理員必須考慮應用程式、使用者身分和裝置資訊等變數的複雜組合，這可能需要費力地篩選記錄。
我們認為有一種更好的方法，正因如此，從今天開始，管理員可以輕鬆稽核其 Cloudflare One 原則使用的所有作用中使用者工作階段和相關資料。這可以實現兩全其美的效果：極其精細的控制，同時在單個簡單的主控台中保持更高的疑難排解和診斷 Zero Trust 部署的能力。管理員現在可以使用以前存在於使用者瀏覽器中或動態變更的資訊，而無需打擾終端使用者或深入挖掘記錄。
應用程式驗證和授權快速入門
_驗證_和_授權_是 Zero Trust 原則在允許使用者存取資源之前評估的兩個元件。
驗證是驗證使用者、裝置或系統身分的過程。常見的驗證方法包括輸入使用者名稱和密碼、出示數位憑證，以及指紋或面部掃描等生物特徵辨識技術。多重要素驗證 (MFA) 需要兩種或更多獨立的驗證方法來增強安全性，例如硬體金鑰與密碼相結合。
授權是在實體成功通過驗證後授予或拒絕對特定資源或權限的存取的過程。它定義了經過驗證的實體在系統中可以做什麼和不能做什麼。
應用程式驗證/授權機制
我們將重點介紹 Web 應用程式，此類應用程式通常使用 HTTP Cookie 來處理驗證和授權。
驗證：
登入：當使用者透過輸入使用者名稱和密碼登入 Web 應用程式時，應用程式會根據其資料庫或身分識別提供者 (IdP) 驗證這些憑證。還可以套用其他形式的驗證來實現多重要素驗證。如果它們匹配，伺服器或外部安全服務（例如 Cloudflare Access）就會認為使用者已通過驗證。
Cookie/權杖建立：然後，伺服器以 Cookie 或 JSON Web 權杖的形式為使用者建立工作階段。Cookie 在一段時間內有效，之後使用者必須重新進行驗證。
傳送和儲存 Cookie：伺服器向使用者的瀏覽器傳送回應，其中包括工作階段 ID 和 Cookie 中有關使用者的其他識別資訊。然後，瀏覽器會儲存這個 Cookie。此 Cookie 用於在使用者的後續請求中識別該使用者。
授權：
後續請求：對於對 Web 應用程式的所有後續請求，使用者的瀏覽器會自動在請求中包含 Cookie（帶有工作階段 ID 和其他識別資訊）。
伺服器端驗證：伺服器從 Cookie 中獲取使用者資料並檢查工作階段是否有效。如果有效，伺服器還會擷取使用者的詳細資訊及其與該工作階段 ID 相關的存取權限。
授權決定：根據使用者的存取權限，伺服器決定使用者是否有權執行請求的操作或存取請求的資源。
這樣，使用者在登入後，其所有後續請求都保持經過驗證的狀態（並且可以檢查其授權），直到工作階段到期或他們登出帳戶。
在現代 Web 應用程式中，此工作階段狀態通常以 JSON Web 權杖 (JWT) 的形式儲存。
偵錯基於 JWT 的驗證
許多現代 Web 應用程式和 Cloudflare Access 等 Zero Trust 網路存取 (ZTNA) 解決方案都使用 JWT 來進行驗證和授權。JWT 包含一個負載，該負載對有關使用者的資訊和可能的其他資料進行編碼，並且由伺服器對其進行簽名以防止篡改。JWT 通常以無狀態方式使用，這意味著伺服器不會保留每個 JWT 的復本，它只是在其隨著請求傳入時對其進行驗證和解碼。JWT 的無狀態性質意味著您不必依賴中央系統來處理使用者工作階段管理，這可以避免隨著存取系統的使用者數量增加而產生可擴展性問題。
但是，由於 JWT 的這種無狀態性質，如果不從使用者處獲得特定的 JWT，則很難對基於 JWT 的驗證進行偵錯。原因如下：
**1. 權杖特定性：**每個 JWT 都特定於一個使用者和一個工作階段。它包含有關使用者、頒發機構、權杖的頒發時間、到期時間以及可能的其他資料的資訊（聲明）。因此，要偵錯問題，您通常需要獲得導致問題的確切 JWT。
**2. 無伺服器端記錄：**由於 JWT 是無狀態的，因此伺服器預設不儲存工作階段。它無法查找過去的權杖或其關聯狀態，除非它是專門設計用來記錄它們的，但出於隱私和資料縮製考慮，通常情況並非如此。
**3. 暫時性問題：**JWT 的問題可能是暫時性的，它們可能與使用權杖的具體時刻有關。例如，如果使用者嘗試使用權杖時，該權杖已過期，則需要該特定權杖來偵錯問題。
**4. 隱私和安全：**JWT 可能包含敏感資訊，因此應謹慎處理。從使用者那裡獲取 JWT 可能會將他們的個人資訊或安全憑證暴露給偵錯問題的人員。此外，如果使用者透過不安全的通道將 JWT 傳送給開發人員或 IT 服務台，則可能會被攔截（Cloudflare 最近發佈了免費的 HAR Sanitizer 來幫助緩解這一問題）。
這些因素使得在沒有相關特定權杖的情況下，很難對基於 JWT 的驗證問題進行疑難排解。
偵錯身分問題的更好方法
我們著手建置一種更好的方法來偵錯與 Cloudflare Zero Trust 中使用者身分相關的問題，而無需來回分享 JWT 或 HAR 檔案。管理員現在可以檢視使用者的登錄身分（用於 Gateway 原則）和所有作用中 Access 工作階段。
此工作階段資訊包括 Zero Trust 評估的完整身分，包括 IdP 聲明、裝置狀態資訊、網路背景資訊等。透過利用 Cloudflare Workers KV，我們能夠在不對 Access 的驗證邏輯進行任何額外負載的情況下建置此功能。當使用者使用 Access 進行驗證時，其關聯的身分會立即儲存到 Workers KV 中的鍵/值組中。這一切都發生在使用者驗證事件的上下文中，這意味著延遲影響或對外部服務的依賴極小。
所有 Zero Trust 方案的所有客戶都可以使用此功能。如果您想開始使用 Cloudflare Zero Trust，請立即註冊一個最多可容納 50 位使用者的免費帳戶！或者，與 Cloudflare 專家合作，討論適合貴組織的 SSE 或 SASE，一步一步地解決您的 Zero Trust 用例。