題幹與適用場景
公司把業務資料放在物件儲存、湖倉表和資料倉庫，分析師透過 SQL、Spark 與 BI 工具存取。權限靠人工工單和各引擎本地帳號維護，離職撤權滯後，稽核時無法還原跨帳戶查詢。目標是自助申請、最小權限、欄/列保護、緊急存取和統一稽核。
請設計資料存取治理層：如何分類與標記資料、誰能批准、策略在哪裡執行、怎樣覆蓋多個引擎、如何處理 break-glass、撤權、快取與匯出，以及怎樣證明允許和實際讀取都可稽核。核心考察資料平台治理與可營運性，因此歸入 data。
面試官考察點
面試官看你是否把治理拆成目錄、策略、執行、證據和營運閉環，而非只說「加 RBAC」。高品質回答會區分身份、用途、資源標籤、欄列過濾與脫敏，並說明策略決策點與執行點的邊界。
還要考慮跨服務一致性：同一使用者從 Athena、Spark、BI 或匯出任務存取時，授權和稽核欄位不能遺失。稽核日誌要防竄改、可查詢、有保留策略，且涵蓋拒絕、管理員變更和緊急存取。
回答前需要釐清的問題
- 資料源、引擎、身份提供者和跨帳戶邊界有哪些？
- 哪些欄位是 PII、財務或受合約限制資料，分類由誰維護？
- 存取按角色、屬性、用途、租戶還是欄列過濾組合決定？
- 審批是一次性、定期續期還是每次查詢都需要？
- 緊急存取最大時長、審批人和事後複核是什麼？
- 能否記錄實際掃描範圍、返回列數、匯出目標和服務身份？
30 秒回答框架
「我會先建立帶 owner 的資料目錄與敏感標籤，再把使用者身份、團隊、用途、地區和資源標籤輸入統一策略決策點。執行點在各引擎或資料代理落實欄列過濾與脫敏，審批產生有期限授權。所有允許、拒絕、策略版本、查詢資源、服務身份和匯出動作寫入集中且防竄改的稽核流；緊急權限自動過期並觸發複核。最後用撤權、跨帳戶、快取和策略漂移演練證明實際存取與日誌一致。」
分步驟深入解答
先做資料資產清單：表、欄、檔案路徑、主題、租戶和派生資料都要有 owner、分類、來源、保留期限與允許用途。標籤不能只靠一次掃描；schema 變更、欄位新增和業務規則變化要觸發複核。無法確定的敏感欄位採保守標籤。
把授權拆成決策與執行。策略決策輸入主體身份、群組、屬性、用途、裝置/網路條件、資源標籤和環境；輸出允許、拒絕、過濾條件、脫敏規則、策略版本與過期時間。執行點可以是資料代理、引擎外掛或表格過濾器，但繞過入口不能讀到原始物件檔案。
自助申請流程展示資料用途、欄位範圍、期限和責任人。低風險、預批准用途可自動授予短期角色；敏感資料需要 owner 或合規審批。授權採最短期限，離職、團隊變更和專案結束觸發撤權。審批記錄要關聯實際策略版本，避免工單批准而線上策略沒變。
欄列保護要說明語意：分析師可看到脫敏郵箱和聚合結果，但不能透過 JOIN、匯出或錯誤訊息重建原值。租戶過濾條件由可信身份注入，不能由使用者提交 tenant_id 就取得存取。匯出、臨時表、快取和物化視圖也套用同一策略。
稽核事件至少包含主體、身份鏈、用途、資源、欄列過濾結果、策略版本、引擎、查詢或作業 ID、時間、來源帳戶、返回/掃描規模、匯出目標和允許/拒絕結果。寫入低權限、受控讀取的不可變儲存，用校驗和或版本鏈檢測刪除與竄改。拒絕與管理員變更同樣重要。
跨引擎和跨帳戶要傳遞原始使用者與服務身份，不能只記錄共享 ETL 角色。服務代使用者存取時保留 delegation chain；跨帳戶事件同步到資源擁有方。無法傳遞上下文的舊引擎先隔離或限制資料範圍，不宣稱已統一稽核。
設計 break-glass：只給強認證的少數角色，必須填原因、自動過期、即時告警和事後複核；緊急權限不能繞過稽核。策略發布採版本、灰度和回滾，監控拒絕率、越權嘗試、撤權延遲、無 owner 資產、稽核缺口和高風險匯出。用合成身份和蜜罐欄位驗證能讀到與有記錄。
高品質示範回答
「我會先建立資料目錄、敏感標籤與 owner，覆蓋原表、派生表、物件路徑和匯出副本。策略決策點接收主體身份、團隊、用途、地區和資源標籤，返回允許、拒絕、欄列過濾、脫敏規則、策略版本與過期時間；執行點放在資料代理或引擎外掛，並封鎖繞過路徑。
申請流程要求用途、範圍、期限與責任人，敏感存取需要 owner 審批，授權短期化並在離職或專案結束撤銷。欄列策略也套用於臨時表、快取與匯出，避免透過 JOIN 或錯誤訊息重建原值。
稽核事件保留使用者與服務身份鏈、資源、策略版本、引擎、查詢 ID、過濾結果、規模、匯出目標和允許/拒絕結果，寫入不可變儲存。Break-glass 自動過期、告警並複核。上線前測試跨帳戶、撤權、舊引擎、快取與蜜罐，證明實際讀到的資料與稽核記錄一致。」
常見錯誤
- 只設計 RBAC → 無法表達用途、地區與欄級限制 → 組合身份、屬性、資源標籤和過濾規則。
- 只保護查詢引擎 → 可繞過引擎讀物件儲存 → 統一入口並封鎖原始路徑。
- 共享 ETL 帳號代替使用者 → 稽核無法追責 → 保留 delegation chain。
- 只記錄成功查詢 → 越權嘗試和策略漂移消失 → 記錄拒絕、變更和緊急存取。
- 授權永久有效 → 專案結束仍可存取 → 最短期限、續期和自動撤權。
- 只保護原表 → 快取、匯出和物化副本洩漏 → 所有派生路徑套用同一策略。
- Break-glass 繞過稽核 → 緊急通道成為後門 → 強認證、原因、過期、告警和複核。
- 只測策略結果 → 實際資料可能被繞過 → 用合成身份、蜜罐欄位和匯出演練驗證。
追問及應對
追問一：RBAC 和 ABAC 怎麼選？
穩定團隊邊界可用角色，動態用途、地區、資料標籤和時間條件需要屬性。通常組合兩者，並限制策略複雜度。
追問二：如何防止透過聚合重建敏感值？
限制小樣本聚合、JOIN、差分查詢和匯出頻率，必要時設閾值或加噪；按敏感度和準確性要求驗證。
追問三：快取資料怎麼稽核？
快取鍵綁定主體和策略版本，記錄填充與讀取身份鏈，撤權或版本變更時失效。無法帶使用者上下文的共享快取禁止存敏感結果。
追問四：日誌本身含敏感查詢怎麼辦？
記錄結構化資源標識和摘要，避免保存完整 SQL、參數和原始資料；稽核欄位分級保護、加密、限權與設定保留期限。
追問五：舊引擎不支援欄列權限怎麼辦？
隔離舊引擎、只提供預過濾視圖或遷移到代理路徑，標記稽核覆蓋缺口。不能用團隊約定代替執行控制。
追問六：如何衡量治理沒有拖慢分析？
同時監控授權決策延遲、查詢 p95、拒絕誤報率、快取命中和審批時延；身份或策略版本變更要立即使快取失效。
追問七：為什麼要記錄策略版本？
策略更新前後同一查詢可能得到不同結果。版本讓稽核能解釋當時為何允許、拒絕或過濾，也支援回滾與復盤。