iT邦幫忙

2023 iThome 鐵人賽

DAY 19
0
Security

Google BeyondCorp 零信任模型:從概念到實踐系列 第 19

Day 19 用戶體驗——讓用戶能夠自行修復故障

  • 分享至 

  • xImage
  •  

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

當故障發生時

當出現故障或用戶遇到複雜情況時該怎麽辦?承認用戶會遇到問題,我們就能識別最常見的情況,並制定盡可能順利解決問題的計劃。讓用戶了解問題,並在可能的情況下自行修復問題,是我們始終不變的大目標。

可以讓用戶自行修復的故障

Captive portals 強制門戶

由於 Google 是一家國際公司,有許多出差在外的員工,因此用戶在機場、酒店和咖啡廳工作時通常會遇到 captive portol 強制門戶。這些 captive portal 通常部署在私有網絡的 default gateway 上。當用戶試圖連接到該網絡時,BeyondCorp 的 Chrome 插件會嘗試下載 Proxy Auto-Config (PAC) 文件,但 captive portol 會阻止插件成功下載。

為了解決這個問題,每當 Chrome 插件偵測到網路狀態發生變化時,我們會判斷設備是否處於 captive portal 背後:方法很簡單,我們透過嘗試訪問 http://clients3.google.com/generate_204 (一個始終返回 HTTP 204 的空白頁面)來判斷設備是否面臨 captive portal。如果我們接收到的返回信息不是 HTTP 204(最常見的是 HTTP 302),我們就假設該設備連接到了一個 captive portal。然後,我們會 fall back 到 Chrome 插件內部存儲的預設 PAC 檔案,並通知使用者。

HTTP 302 Found: This response code means that URI of requested resource has been changed temporarily. New changes in the URI might be made in the future. Therefore, this same URI should be used by the client in future requests.

遇到 captive portal 的用戶可以點擊 Chrome 瀏覽器插件圖標,我們會告訴他們在機場或酒店嘗試驗證網絡時經常會遇到這個問題。BeyondCorp 已按計劃運行,用戶只需將 BeyondCorp 插件設置更改為 "Off : Direct" 即可。然後,用戶就可以通過 captive portal 完成身份驗證,此時插件就能成功下載最新的 PAC 文件。

這個簡單的流程允許用戶完全自行修復問題,停機時間最短,也不會給我們的技術人員帶來任何支援負擔。

本地網路設備

用戶還經常嘗試訪問私有網路上的設備,例如印表機或其他網路設備。然而,由於我們要求所有用戶訪問都必須通過 Access Proxy ,當啟用 BeyondCorp 插件時,訪問將失敗。與 captive portal 的解決方法類似——將 BeyondCorp 插件設置更改為 "Off : Direct"。然而與 captive portal 的情況不同,我們無法輕易檢測到此故障狀態。通常情況下,處於這種情況的用戶網路連接是正常的。從插件的角度來看,一切運行正常,用戶可以訪問所有公司資源,因此沒有理由對此提出警報。

為了弄清在這種情況下如何有效地與用戶進行交互,我們通過一個有代表性的用戶旅程進行了研究:一位工程師將公司的筆記本電腦帶回家,想用它來更改家用印表機的設置,而他們是通過印表機的 IP 地址連接到該設備的。用戶連接到家庭網絡,BeyondCorp 插件成功連接,下載了最新的 PAC 文件,並配置了 Proxy。當用戶在新的瀏覽器頁面中訪問印表機的 IP 地址時,該請求將與所有其他 private ip 流量一起發送到我們的 Access Proxy。路由請求失敗,用戶會收到一個錯誤信息。

我們透過專注於最終結果——Access Proxy 回覆的錯誤頁面,找到了解決這個用戶旅程的方法。當滿足特定條件時,我們會在錯誤頁面中插入自定義的 HTTP 502 錯誤信息。具體來說,當我們返回 HTTP 502 且用戶嘗試訪問RFC1918 或 RFC6598 地址時,錯誤消息會向用戶解釋,如果他們試圖訪問本地網絡設備,如家庭路由器或印表機(我們發現的兩種最常見情況),他們需要將 BeyondCorp 插件切換到 "Off : Direct" 模式。通過這種方式,我們能夠利用已經存在的基礎設施和流程,讓用戶自行解決問題。

自定義 Proxy 設置

我們的員工有時需要設置自定義 proxy (custom proxy) 來測試在國外的廣告。如果用戶安裝了多個每個都嘗試設置 proxy 的插件,這些插件可能會互相沖突,讓用戶感到困惑的同時阻擋他們對企業資源的訪問。

我們針對這個用例提供了兩種解決方案。首先,我們將外國 proxy 設置直接整合到 BeyondCorp 插件中。當用戶流量需要從特定位置出去時 (egress from a specific location),他們可以在插件中的支持國家下拉菜單中選擇該位置。用微小手段解決巨大問題,這個功能為我們的用戶提供了一個單一的插件,便滿足他們最常見的商務 proxy 需求。

此外,當用戶需要運行第二個 proxy 管控插件時,他們的 BeyondCorp 插件圖標會從綠色變為紅色。然後我們會給用戶一個選項,可以將 BeyondCorp 插件切換到 "Off : System Alternative" 模式,並解釋他們何時需要使用此設置。再次強調,這個過程允許用戶自行修復故障,提高他們的生產力,並減少我們支持團隊的負荷。


活過來了。。。
最近真的有點忙啊~小犬颱風沒能讓臺北人放假,明天還是要義不容辭風雨無阻的上班去。
我可以的!我行!不能不行。上班而已,不怕。
小犬颱風什麼的,大陸在十一長假什麼的,沒事。

週四加油 ><!希望明天能順利 debug


上一篇
Day 18 用戶體驗——減少使用 VPN
下一篇
Day 20 用戶體驗——爲了解釋複雜錯誤而生的入口網站(上)
系列文
Google BeyondCorp 零信任模型:從概念到實踐30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言