如何交接瀏覽器工作，而不分享原始憑證

團隊常說需要「分享登入」，真正需求卻更窄：審查草稿、更新獲授權商店、重現地區問題，或接續客服工作。從任務而不是密碼出發，會有更多選擇。

哪些算原始憑證

明顯例子包括密碼、復原碼、一次性密碼種子、私密金鑰與代理伺服器密碼。瀏覽器工作也包含不那麼顯眼的憑證：

• 驗證 Cookie 與工作階段識別碼；
• OAuth 存取與更新權杖；
• 密碼管理員紀錄與自動填入資料；
• 通行密鑰私密金鑰，或存取持有它的驗證器；
• 受信任裝置與復原狀態；
• 包含上述資料的設定檔封存檔。

NIST 工作階段指引將瀏覽器工作階段描述為以持有工作階段機密維持連續性。OWASP 工作階段管理指南說明實際後果：權杖有效時，可能等同建立它的最強驗證。

用戶端加密的設定檔封裝，只有在儲存服務不持有解密金鑰時，才能向該服務隱藏憑證值，也能降低旁觀者直接讀取的風險。獲授權接收者的裝置解密並啟動後，瀏覽器仍能行使工作階段權力。即使接收者從未讀取 Cookie，交接仍已轉移權限。

將任務與權力分開

選擇共用方式前，先寫一段簡短存取聲明：

具名操作人員 A 可從核准裝置 D，對資源 C 執行操作 B，直到時間 E，並遵守核准與稽核規則 F。

這句話會顯示不必要權限。如果任務只是「核准草稿」，完整管理員工作階段就過多。目標服務已有審核者角色時，共用瀏覽器狀態只增加風險，沒有增加能力。

NIST 的零信任架構建議按工作階段授予個別資源存取，只給任務所需最小權限。不必購買標示「零信任」的產品，也能用此原則檢查任何瀏覽器交接設計。

優先順序如下

1. 目標服務的具名存取

網站或 App 有自己的團隊、組織、角色、委派或核准功能時，優先使用。每個人以個別帳號與驗證器登入，讓服務套用權限、將行動歸屬到本人、執行風險控制，並撤銷單一人員而不必更換所有人的憑證。

通常這是最強模式，因為授權由理解操作的服務執行。瀏覽器管理工具無法可靠地把某站的共用管理員工作階段，轉成網站層級審核者角色。

共用與群組帳號降低可追責性。NIST SP 800-53 第 5 修訂版建議限制使用，並在允許前定義明確條件。

2. 目標服務提供的限定委派

服務提供 OAuth 或其他委派協定時，只授予用戶端或行為者必要資源、操作與有效期。RFC 9700建議將權杖權限限制為最低所需，並限定接收對象為預定資源伺服器。

優先使用短期、可撤銷且限定接收對象的授權。綁定傳送者的權杖可降低外洩後的重放風險，但攻擊者同時取得權杖與綁定金鑰時，仍無幫助。用戶端裝置與軟體依然在威脅邊界內。

委派尤其適合自動化：腳本可取得明確操作許可，而不取得個人密碼或一般瀏覽器工作階段。稽核事件應識別發起人、受委派行為者、資源、範圍與結果。

3. 經中介使用已儲存機密

部分舊服務只提供共用憑證。受控憑證中介或密碼管理員，可讓核准瀏覽器流程使用機密，不必在聊天、工單、文件或一般輸出中顯示，以減少複製。

這改善保管、輪替與存取審查，卻不會修復目標服務的帳號模型。登入後每位操作人員仍可能使用同一網站身分。產生的工作階段依然敏感，需要自己的逾時、撤銷與裝置控制。

OWASP 機密管理指南建議細分權限、減少人員直接接觸值、控制生命週期，並稽核誰請求與使用機密。瀏覽器產品應盡可能透過不透明參照整合，而非變成另一個通用機密庫。

4. 受保護的瀏覽器工作階段交接

只有目標服務缺乏足夠委派，而且獲授權流程確實需要延續工作階段時，才使用共用已登入設定檔。這是一般交接中風險最高的一種，因為接收者取得透過有效帳號行動的能力。

最低控制包括：

• 明確擁有者與核准接收者；
• 說明任務、資源與到期時間；
• 單一使用中寫入者，或經測試的衝突模型；
• 任何雲端上傳前先在用戶端加密；
• 接收裝置授權與本機保護；
• 避免同時工作歸屬不明的鎖定；
• 授予、下載、開啟、敏感操作、關閉、撤銷與復原的稽核事件；
• 一般介面回傳遮蔽狀態，而非 Cookie 或權杖；
• 目標服務的工作階段撤銷計畫。

這種模式可降低憑證值被隨意複製或由雲端儲存讀取的風險，但不能讓目標服務區分使用同一已登入帳號的兩個人，也無法保護工作階段免於惡意軟體、惡意擴充功能，或濫用獲授權權力的接收者。

5. 傳送原始憑證

將密碼、Cookie、復原碼、通行密鑰或設定檔封存檔複製到訊息、試算表、工單、腳本或未保護匯出，會形成持久機密副本，數量不明、撤銷薄弱。應避免。

例外的舊流程確實需要時，依組織核准憑證程序處理，最小化接收者與有效期，之後輪替或撤銷。訊息加密不能取代個人責任或每份複本的紀錄。

比較權力，不只比較方便

模式	目標服務能辨識人員	範圍能符合任務	撤銷邊界	主要剩餘風險
目標服務具名成員	通常可以	通常最強	移除單一成員或角色	服務權限過大
限定委派權杖	可呈現行為者與用戶端	範圍與接收對象夠窄時很強	撤銷授權或權杖	權杖、用戶端或金鑰遭入侵
中介式共用登入	登入後常不能	受共用帳號限制	輪替機密並終止工作階段	共用網站身分與有效工作階段
加密瀏覽器工作階段	目標服務通常不能	設定檔層級，常較廣	撤銷共用及目標工作階段	接收裝置可行使完整工作階段權力
原始憑證副本	沒有可靠個人身分	通常廣泛	找出副本、輪替並終止工作階段	未知副本與薄弱責任追蹤

這說明「沒人看得到密碼」不是完整成功標準。重要的是接收者能行使多少權力、持續多久，以及哪個系統能撤銷。

通行密鑰改善驗證，但共用仍需注意

WebAuthn 建立限定於信賴方的公開金鑰憑證。WebAuthn Level 3 規格說明私密金鑰由驗證器持有，網站腳本取得簽署結果，不取得私密憑證本身。正確部署時可提供抗網路釣魚驗證。

通行密鑰不會自動建立團隊角色。目標服務可為每位具名成員註冊獨立憑證，維持個別存取；提供者也可能支援同步或共用驗證金鑰。NIST SP 800-63B-4承認這種模型，也列出未授權使用、跨裝置擴散、同步系統入侵與撤銷困難等風險。

獲授權團隊應優先讓每人使用自己的具名服務帳號與驗證器。如果共用通行密鑰是唯一支援模式，就當作共用驗證器，記錄誰可接收、可在哪些受管理裝置使用，並驗證提供者如何顯示、撤銷與復原。目標服務仍可能把所有操作記在同一帳號下。

將瀏覽器交接定義為契約

移動設定檔狀態前，受控交接應回答：

1. 誰在行動？ 使用具名組織身分，不用泛稱操作人員。
2. 誰授權？ 記錄擁有者或政策決策，不儲存核准機密。
3. 共用什麼？ 指明設定檔與任務，不列原始 Cookie 或憑證值。
4. 接收者能做什麼？ 區分啟動、編輯、匯出、自動化、共用與管理權。
5. 可在哪裡執行？ 限於已註冊且適合資料敏感度的受信任裝置。
6. 持續多久？ 設到期時間並關閉閒置工作階段。
7. 能有兩個寫入者嗎？ 除非刻意設計並測試衝突行為，否則只允許一個。
8. 記錄什麼？ 行為者、裝置、設定檔參照、操作、結果與時間；預設排除機密與頁面內容。
9. 如何撤銷？ 同時涵蓋瀏覽器共用授權與目標服務工作階段。
10. 如何復原？ 保留最近正常版本，不意外恢復已撤銷權限。

加密是契約的一部分，保護儲存或傳輸中的資料；授權決定誰可取得解密途徑；裝置信任與本機隔離保護使用；稽核支援責任追蹤與調查。這些控制不能互相取代。

自動化應留在機密邊界外

API、SDK、命令列工具與代理常需要啟動設定檔或執行核准生命週期操作，但很少需要 Cookie 值、密碼、通行密鑰、代理憑證或原始設定檔封存。

狹窄介面可接受不透明的設定檔或機密參照，並回傳：

• 操作是否獲授權；
• 就緒、鎖定、到期或已撤銷等遮蔽狀態；
• 有期限的程序或工作階段參照；
• 結構化錯誤與復原步驟；
• 稽核事件參照。

不能只因呼叫者能啟動設定檔，就回傳憑證。匯出、大量共用或其他涉及機密的操作，需要獨立政策，適用時也要明確核准。

網站內容與自動化輸入仍不受信任。頁面指示不應能說服代理透過紀錄、工具輸出、截圖或支援管道揭露工作階段資料。

撤銷有兩層

從瀏覽器工作區移除協作者，會停止未來透過該工作區取得授權，但不證明目標服務工作階段已失效。裝置可能已持有解密狀態，複製或仍在執行的工作階段可能繼續。

正常結束存取時：

1. 撤銷團隊授權並關閉設定檔租約；
2. 依保留政策移除加密本機資料；
3. 目標服務支援時，終止相關工作階段；
4. 移除該人的目標服務成員資格或委派授權；
5. 在核准期間保留遮蔽後稽核證據。

懷疑入侵時，也要隔離受影響設定檔版本、撤銷有效工作階段與權杖、移除未授權驗證器、輪替暴露的共用機密，並檢查稽核事件。還原舊快照可能恢復舊工作階段機密，因此復原必須尊重撤銷狀態。

謹慎交接後仍有的限制

• 用戶端加密保護儲存與傳輸資料，但獲授權端點仍須解密瀏覽器所需內容。
• 瀏覽器鎖定控制產品層級並行，不控制目標服務中的每個操作。
• 共用工作階段通常只向目標服務呈現一個帳號身分，即使瀏覽器產品有更詳細稽核。
• 遭入侵裝置或擴充功能不必擷取可讀密碼，也能透過有效工作階段操作。
• 撤銷工作區授權與撤銷網站工作階段是兩項操作。
• 目標服務條款、客戶合約與適用法律，仍決定流程是否可委派。
• 某些服務沒有安全替代個別存取的方式；這時縮小範圍或不進行交接，可能才是負責任結果。

RFC 6265將 Cookie 描述為隱含權力：即使促成要求的一方不知道 Cookie 值，瀏覽器仍可將它附上。這是工作階段共用的核心限制。隱藏憑證降低揭露，卻不會降低瀏覽器能行使的權力。