1. 題目與使用情境
你負責一個面向企業客戶的 B2B SaaS。銷售回饋多個客戶要求「只允許公司網路存取」，否則採購會卡住。工程團隊擔心行動辦公、雲端代理、IPv6、第三方整合與錯誤設定會造成大範圍鎖定。請判斷是否提供 IP Allowlist，說明保護什麼、誰來管理、如何上線，以及不滿足條件時的替代方案。
假設產品已有身分驗證、稽核紀錄與管理員角色；IP Allowlist 只限制來源，不取代使用者身分、裝置狀態或細緻授權。
2. 面試官考察重點
- 能否把「客戶想要安全」拆成合規證明、網路邊界與真實威脅，而不是直接承諾一個開關。
- 能否區分企業級存取控制的涵蓋面：網頁、API、Git 或自動化權杖可能需要不同策略。
- 能否辨識 IP 作為訊號的脆弱處，包括代理出口變動、IPv6 漏配、共享出口與繞過路徑。
- 能否用分階段發布、緊急解鎖與可觀測性降低誤傷，再用證據決定是否擴大範圍。
3. 回答前需要釐清的問題
- 採購阻塞來自哪類要求：稽核證明、法規條款、內部網路政策，還是希望阻斷遭竊權杖？不同動機決定 IP 控制是否足夠。
- 必須保護哪些資源與入口？若只保護管理後台，和同時保護 API、命令列、Webhook、CI 機器人的實作邊界不同。
- 客戶的出口 IP 是否穩定，是否有多區域、IPv6、零信任代理或遠端員工？這決定清單更新與回退成本。
- 誰能新增、啟用、停用與審核項目？需要多管理員核准、命中預覽或短時間旁路嗎？
4. 30 秒回答框架
「我先確認客戶要解決的風險與必須保護的入口。若採購與合規價值足夠，我會做分層 IP Allowlist：先保護管理面與明確的企業資源，支援 CIDR、IPv4/IPv6、變更預覽、稽核與緊急恢復；API、自動化應用與使用者佈建另外定義涵蓋矩陣。上線前提供觀察模式與自鎖保護，預設保留一條已驗證的恢復通道。若客戶需要的是遭竊權杖防護，我會把強式驗證、裝置策略與風險偵測作為配套，而不是把 IP 當成唯一安全邊界。用誤拒率、啟用率、恢復事件與銷售轉化驗證價值。」
5. 分步驟深入解答
第一步：驗證問題是否值得做
把需求按「收入、合規、風險、替代方案」量化。統計提出需求的目標帳戶金額、採購階段、受監管產業與現有流失原因；訪談安全負責人確認他們需要的是網路位置證明還是更強的工作階段控制。若只有少量客戶想要固定辦公網，先提供設定服務或 IdP 條件存取，而不是立即承諾全平台能力。
第二步：定義最小可行邊界
第一版只保護高價值、可明確列出的資源，例如管理後台與企業私有專案。每條規則包含 CIDR、描述、負責人、核准紀錄與生效時間；支援 IPv4 與 IPv6。GitHub 的企業文件顯示，IP 清單可能涵蓋網頁、API 與 Git 等入口，但應用程式安裝權杖、使用者佈建等路徑可能有例外，因此產品必須公開逐入口涵蓋矩陣，不能只寫「全站生效」。
第三步：把自鎖與變更風險當成核心體驗
管理員啟用前先要求目前來源通過檢查，展示即將被拒絕的活躍來源，並允許設定短時間恢復碼或第二位管理員核准。更新採用草稿、預覽、排程生效與自動回滾；快取或邊緣傳播存在延遲時，介面應顯示未完成狀態。緊急旁路必須有原因、到期時間與稽核紀錄，不能變成永久後門。
第四步：組合替代控制
IP 只能表達「請求從哪裡來」，不能證明操作者是誰、裝置是否可信或請求是否被轉送。對遭竊權杖、行動辦公與第三方自動化，組合抗釣魚多因素驗證、裝置或 IdP 條件存取、短期權杖與最小權限。客戶若只需要稽核證據，可先提供登入事件中的來源 IP、匯出報表與 SIEM 整合，避免為低頻強控制承擔完整維運成本。
第五步：分階段驗證價值
先對少量設計客戶開放觀察模式，記錄命中、未命中、IPv6 漏配、恢復與旁路原因；再讓管理員主動啟用，最後擴大到 API 與自動化入口。成功指標包括目標帳戶啟用率、採購週期變化、誤拒率、平均恢復時間、因設定造成的支援工單，以及沒有 IP 控制時客戶採用替代方案的比例。若啟用率低且誤拒率高，應縮小承諾或改做 IdP 整合。
6. 高品質示範回答
「我不會把 IP Allowlist 當成簡單的安全開關。先確認客戶是為了合規證明、限制辦公網，還是擔心權杖遭竊；如果是後者，IP 單獨解決不了問題。
如果需求足以影響企業採購，我會先做可稽核的最小版本：管理員為企業資源維護 IPv4 與 IPv6 的 CIDR 項目，先涵蓋管理後台與私有資源，提供草稿、命中預覽、第二位管理員核准、緊急恢復與完整稽核。API、Git、CI 機器人與使用者佈建逐項說明是否受保護，因為不同驗證路徑可能有例外。
上線時先觀察再強制，啟用前檢查目前來源，傳播期間顯示狀態，誤配時提供有期限的恢復通道。對行動辦公與代理出口，我會推薦 IdP 條件存取、強式多因素與裝置策略作為組合控制。觀察週期結束後，用啟用率、誤拒率、恢復時間、支援工單與採購轉化決定是否擴展入口；如果客戶只要合規證據，就優先交付來源 IP 稽核與報表，而不是維護容易鎖死使用者的全域開關。」
7. 常見錯誤
- 錯誤表現： 說「企業都需要 IP 白名單」。→ 失敗原因： 把單一客戶偏好當成普遍需求，忽略身分、裝置與代理情境。→ 修正方法： 先拆解威脅、合規與採購證據，再比較替代控制。
- 錯誤表現： 預設 IP 規則涵蓋網頁、API 與所有機器人。→ 失敗原因： 不同驗證路徑與應用程式權杖可能有例外。→ 修正方法： 建立逐入口涵蓋矩陣並公開未涵蓋路徑。
- 錯誤表現： 只支援 IPv4 與固定辦公室位址。→ 失敗原因： 漏掉 IPv6、雲端出口與遠端辦公，容易自鎖。→ 修正方法： 支援 CIDR 與預覽，先觀察再強制並保留恢復流程。
- 錯誤表現： 用「開啟後更安全」作為唯一成功指標。→ 失敗原因： 安全收益與誤拒、維運及銷售成本沒有可比較證據。→ 修正方法： 同時追蹤啟用率、誤拒率、恢復事件、工單與採購結果。
8. 追問及應對
追問一：客戶要求一上線就保護 API，你會怎麼做？
先確認 API 呼叫方是否使用固定出口與可輪替權杖。若不穩定，先交付 IdP 或工作負載身分策略，並以觀察模式記錄 IP 命中；只有涵蓋與恢復演練通過後，才把 API 納入強制範圍。
追問二：管理員把自己鎖在門外，產品應如何恢復？
啟用前驗證目前來源，要求第二位管理員核准，並提供一次性、短時間、可稽核的恢復流程。恢復動作必須自動到期、通知安全負責人，且不能繞過身分與權限檢查。
追問三：IP Allowlist 與零信任策略衝突嗎？
不必然衝突。IP 可以作為網路位置訊號，但零信任仍需持續驗證身分、裝置、工作階段與資源權限。產品應允許客戶把 Allowlist 當成一層條件，而不是宣稱它能取代 IdP 條件存取。