本篇內容來自於文獻：The human element: "The User Experience"

爲了解釋複雜的訪問錯誤而生的入口網站

前篇提到的都是簡單的報錯，用戶可以自行修復。但是一些複雜的報錯會需要 Google 內部的工程師介入協助，比如 Google 的後端基礎設施中複雜多層次的 ACL 邏輯，可能會讓使用者和支援團隊都難以理解。即使是一位經驗豐富的 SRE 可能也需要查詢多個內部服務數分鐘才能識別出單個 403 錯誤頁面的原因。考慮到我們的 Access Proxy 每天提供的 403 錯誤頁面數量（僅 HTTP/S 就有約 1200 萬個），人工參與故障排除是不可擴展和不實際的。

為了協助診斷和排除更複雜的 BeyondCorp 訪問問題，我們設計了一個統一的入口，旨在協助使用者和支援團隊。該入口的做法不是僅僅告知使用者他們被拒絕訪問某資源並提供通用 error code ，而是會解釋具體為什麼用戶會被拒絕以及該如何解決問題。

該入口是獨立的，而不是直接集成在 Access Proxy 中，因為它使用了更細粒度的 ACL，依賴於終端使用者的當前信任等級。由於 Access Proxy 被公開設計，我們希望限制攻擊者可以從 403 錯誤頁面中獲取的信息量。

入口的架構

該入口大致分為前端和後端兩部分，之間通過一個 API 進行通信。

• 前端是一個互動式網頁，根據使用者的輸入向後端API發送請求。
• 後端可以查詢多個參與訪問決策的基礎設施服務。它有意地省略了各種緩存層，以便使用者獲得新鮮信息。
• 前端和後端之間的 API 也可以用於其他用途，如批次處理和分析，或將輸出嵌入到其他工具中。

解釋引擎

除了查詢和呈現 ACL 外，該入口還需要以有用的方式將這些信息呈現給使用者。因此，我們建立了一個解釋引擎，從訪問遭拒後回傳的錯誤參數中生成故障排除的詳細信息。它通過遞歸遍歷提供授權決策的子系統樹來運作。

例如，Access Proxy 的 ACL 可能要求設備必須被完全信任才能訪問特定的 URL。當獲取這個ACL 時，解釋引擎會與我們的設備推斷流程 (device inference pipeline) 聯系，以獲取訪問公司資源所需的條件。然後，我們將這些信息傳遞給我們的前端，並將其翻譯成通俗易懂的語言，使用戶能夠訪問門戶網站，了解他們目前的狀態以及如何解決問題。

ACLing the ACLs

雖然解釋引擎為用戶提供了有用的信息，但它暴露的數據可能是敏感的。它揭示了受保護系統中存在問題的 ACL，並披露了有關用戶賬戶和設備狀態的信息--所有這些對潛在攻擊者來說都是有用的信息。為這些數據定義 ACL 是一個棘手的過程，因為我們需要平衡工具的可用性和保護敏感信息的需要。

根據請求故障排除信息的用戶和設備，我們可以將輸出中的敏感節點替換為較常見的變數。在極端情況下，我們會將節點替換為 “請聯繫技術支援” 的指示。在這種情況下，我們的技術支援團隊和 SRE 可以通過驗證用戶身份並代表他們查看相關信息，在不泄露敏感信息的情況下為用戶提供幫助。

活過來了。。。嗎。。。
最近快爆炸了哈哈哈哈哈嗚嗚嗚
Q4 終於向我重拳出擊了，我毫無招架之力。
除了對美好生活的嚮往和對用戶的愛（？）支撐著我風雨無阻義不容辭，我找不到其他理由。
噢，可能是成爲更好的自己吧。真希望有一天我可以在自我介紹的時候說，我是專爲解決複雜問題而生的。哈哈。單純的小小架構師的夢想。

BTW 最近開始爲了 101 垂直馬拉松鍛鍊身體，爬樓梯使人專注腳下。真好。也是真累。

明天見~星期五加油！