這份文件，是給「真的需要落地做個資保護的人」。
不是法條整理，也不是資安口號，而是站在產品經理與系統設計者的角度，說明在實務中，如何把『避免傷害』這件事，設計進系統裡。
一、最小必要權限（Least Privilege）
核心概念： 不是「你能不能看到」，而是「你為什麼一定要看到」。
實務怎麼做？
- 權限設計從「任務」出發，而不是「職稱」
- 將權限拆成可組合模組（查詢 / 編輯 / 匯出 / 聯絡）
- 高風險操作（如下載、聯絡）需額外授權
PM 該問的問題
- 這個角色如果看不到，會無法完成工作嗎？
- 有沒有替代資訊可以支援決策？
二、角色分級與敏感資料隔離
核心概念： 不是所有資料，都應該出現在同一個畫面。
實務怎麼做？
- 將資料分為：一般 / 敏感 / 高敏感
- 高敏感資料需「二次動作」才可展開（點擊、理由、驗證）
- 聯絡方式、身份資訊獨立成模組，不預設顯示
PM 該注意
- 「方便」本身就是風險來源
- 一頁看完所有資料，通常是設計偷懶
三、完整日誌與可回溯紀錄
核心概念： 不是出事才查，而是隨時都查得到。
日誌至少要記錄
- 使用者帳號
- 存取時間
- 查詢對象（去識別化 ID）
- 操作類型（查看 / 編輯 / 匯出）
實務補充
- 日誌不可讓一般使用者刪除或修改
- PM 要確保「誰能看日誌」也有清楚規範
四、異常行為即時警示
核心概念： 系統要能懷疑『不尋常的好人』。
常見警示條件
- 非上班時段存取敏感資料
- 短時間內大量查詢個案
- 查詢與職責無直接關聯的對象
實務設計
- 先警示主管或系統管理者，不直接阻斷
- 保留人工判斷空間，避免影響正常業務
五、定期清查與資料生命週期管理
核心概念： 資料不該永遠存在，權限也不該。
實務怎麼做？
- 定期（每季 / 半年）權限盤點
- 專案結束即回收權限
- 資料設定到期日與自動遮蔽規則
PM 常犯的錯
- 只設計新增流程，沒設計「結束」流程
最後想說的
好的個資設計，不是因為你不信任人， 而是因為你知道：
人會犯錯，而系統不能假裝沒這件事。
如果你是 PM、系統設計者、或正在碰觸高敏感資料的產品， 這五個原則，應該是設計起點，而不是事後補救。
Yuyu小日子 