1. 題幹與適用情境
一個服務接收讀取或寫入資源的請求。服務本身擁有較寬權限，但呼叫方只能獲得有限能力。如果服務接收呼叫方控制的路徑或資源 ID，再用自身權限執行操作，攻擊者可能誘使它完成呼叫方本不能直接完成的動作。AWS 將這類問題稱為 confused deputy。
能力式安全把權限放進明確的參照或權杖：它同時指向資源並攜帶使用權限。這個 capability 應不可偽造、範圍受限，並只傳給確實需要的程式碼。題目考察安全模型，不限定雲端廠商或程式語言。
2. 面試官考察點
- 權限推理： 能否區分認證、授權與持有被委託權限。
- 威脅建模： 能否指出代理、混淆輸入、高權限動作和攻擊者控制邊界。
- 最小權限： 是否把 capability 收縮到單一操作、物件、租戶或時間窗口。
- 生命週期判斷： 能否解釋撤銷、過期、稽核和洩漏，而不聲稱 capability 能解決一切。
- 取捨表達： 能否在真實營運約束下比較 capability 與環境身分和策略檢查。
弱回答只會說「使用 token」。強回答會說明 token 授權什麼、如何約束，以及洩漏或必須撤銷時會發生什麼。
3. 回答前需要澄清的問題
代理是本地程式碼、服務還是雲端角色？
模式相同，但邊界不同。函式庫可能無意繼承檔案控制代碼；服務可能使用工作負載身分；雲端角色可能被誘騙去存取跨帳戶資源。先說清楚誰擁有寬權限。
委託的是哪個資源和操作？
明確是讀、寫、追加、刪除、呼叫還是組合操作。針對單一物件和方法的 capability 比萬用資源名稱更容易稽核和撤銷。
撤銷和洩漏要求是什麼？
詢問是否需要立即撤銷、離線使用、多租戶隔離或不可否認稽核。這些約束決定使用記憶體參照、簽名權杖、租約、代理或中心策略檢查。
4. 30 秒回答框架
「混淆代理發生在低權限呼叫方提供資源名稱，而高權限服務使用自身權限執行操作，卻沒有把請求綁定到呼叫方明確獲授的範圍。能力式安全讓權限顯式化：傳遞不可偽造的參照或權杖，限定一個資源和操作，並要求代理只能使用該參照。我會在委託時收縮 capability，把它綁定到租戶和受眾，按風險設定過期或撤銷，並記錄簽發和使用。Capability 能減少環境權限和混淆代理風險，但洩漏、重放、復原和稽核仍需單獨設計。」
5. 分步驟深入解答
步驟一：區分身分與權限
認證回答誰在呼叫，授權回答該身分按策略能做什麼。Capability 是具體的帶權限參照：持有它並通過不可偽造性檢查，就獲得特定動作。它可以和身分並存，但不依賴每次內部呼叫都重新讀取全域環境身分。
步驟二：畫出混淆代理流程
假設報表服務能以工作負載身分讀取任意檔案。使用者傳送 file=/reports/other-tenant.csv。如果服務只驗證請求已認證，它就成了代理：使用者提供名稱，服務花費更大的權限。缺少的綁定是「該呼叫方確實被授予這個物件的權限」。
步驟三：用有範圍的權限取代名稱
改由有權所有者建立某個報表和操作的 capability，例如租戶 A 的唯讀權限，直到指定時間。呼叫方把 capability 交給服務。服務解引用它或交給代理，不把任意路徑轉換成權限。object-capability 研究將這種模式描述為把存取權編碼到物件中，限制物件之間的互動。
步驟四：委託時收縮權限
元件繼續委託時，應產生更弱的 capability：減少方法、限制子物件、縮短壽命、綁定租戶或增加速率限制。不能因為下游方便就擴大 capability。只暴露 readMetadata() 的包裝器比傳遞可寫可刪的檔案控制代碼更安全。
步驟五：處理權杖和重放
跨程序傳遞時，使用簽名、綁定受眾的保護參照，或由代理簽發控制代碼。包含資源、動作、租戶、簽發者、受眾、過期時間和需要防重放時的唯一 ID。使用前驗證完整性與上下文。加密只能隱藏內容，不能單獨保證範圍或阻止重放。
步驟六：規劃撤銷和復原
純記憶體 capability 易傳遞，卻難以全域撤銷。租約、短過期、透過撤銷儲存間接參照或輪換金鑰，分別在即時控制、可用性和延遲之間取捨。權杖洩漏後，應撤銷控制代碼或綁定，必要時輪換相關金鑰並檢查紀錄；刪除使用者記錄不一定會讓已簽發 capability 失效。
步驟七：保留稽核和策略邊界
記錄誰簽發 capability、範圍是什麼、哪個代理使用以及結果。即使 capability 是授權原語，也要保留身分上下文以便追責。高風險動作可疊加租戶狀態、法律保留或 step-up authentication 等策略檢查。
6. 高品質示範回答
「混淆代理是權限錯配：呼叫方提供資源名稱，但服務擁有更大權限並執行操作。服務把名稱當成授權，因此被混淆。AWS 在跨帳戶和跨服務場景中記錄了這個模式。
我會傳遞明確的 capability：不可偽造的參照或受保護權杖，限定租戶、物件、操作、受眾和過期時間。代理只能使用這個 capability；繼續委託時建立更弱的子 capability。遠端權杖要檢查完整性、上下文與重放約束，並記錄簽發和使用。
撤銷是關鍵取捨。敏感動作可以用短租約或可撤銷控制代碼，但要接受查詢成本。Capability 能減少環境權限並讓權限流更可見，卻不能消除洩漏、復原、稽核和策略要求。我會測試跨租戶存取、權杖重放、混淆名稱與撤銷競態。」
7. 常見錯誤
- 「認證通過就夠了」 → 讓寬權限服務自行決定範圍 → 把操作綁定到明確且受限的權限。
- 「簽名 token 自動就是 capability」 → 忽略受眾、操作、過期與重放 → 把完整性和範圍分開驗證。
- 「登入檢查後繼續使用呼叫方路徑」 → 重現混淆代理流程 → 傳遞 capability 或代理控制代碼，而不是任意名稱。
- 「Capability 消除了授權策略」 → 漏掉租戶狀態和上下文規則 → 對高風險動作疊加策略檢查。
- 「撤銷沒有成本」 → 忽略分散式副本和離線使用 → 按需求選擇租約、間接參照或過期。
- 「隱藏所有身分上下文」 → 讓事故調查無法進行 → 稽核簽發者、主體、範圍和使用事件。
8. 追問及應對
Capability 和 ACL 查詢有什麼差別？
ACL 查詢從身分和資源名稱出發，在使用時查策略。Capability 則沿資料流攜帶被委託權限。ACL 集中策略和撤銷；capability 讓權限顯式並減少環境權限，但仍需處理生命週期和洩漏。
Capability 可以被複製嗎？
程序內參照通常能被持有它的程式碼複製，邊界在於誰能收到以及是否收縮。遠端權杖若不綁定通道、隨機數、受眾或短租約，也可能被重放。可複製性是要建模的風險，不代表權杖無害。
如何保護 capability URL？
把它當作 bearer 憑證：使用 HTTPS、窄範圍、短過期、不可猜熵、受眾綁定、速率限制，並從紀錄和 referrer 中脫敏。敏感或可重複動作應先一次性兌換可撤銷控制代碼。
雲端系統哪裡仍會出現混淆代理？
服務角色、建置執行器或儲存代理接收使用者控制的資源 ID，再使用寬角色就是典型場景。把請求綁定到資源策略、租戶和目標動作；AWS 的跨帳戶指引就是具體邊界例子。