App 安全與個資
App 登入、權限與個資如何設計
從身分驗證、角色授權與個資生命週期，規劃兼顧操作便利、營運需求與資料保護的 App。
登入、權限與個資經常被合併成一個「會員功能」，實際上是三個不同問題：登入確認使用者是誰，權限決定他能做什麼，個資治理則管理資料為何被收集、保存多久以及如何被使用。若只完成登入畫面，卻沒有處理伺服器端授權與資料生命週期，產品仍可能讓錯誤的人看到或修改不該接觸的資料。
登入方式要符合風險與使用頻率
Email 密碼、手機驗證碼、Apple 或 Google 登入、企業單一登入，各有帳號找回、身分合併與客服成本。低頻消費服務若要求複雜密碼，可能增加放棄與忘記密碼；涉及付款、健康、員工或管理權限的產品，則需要更嚴謹的重新驗證、多因素驗證、裝置或工作階段管理。
規格不能只描述成功登入，也要涵蓋驗證碼逾時、Email 已被使用、第三方登入中斷、手機遺失、帳號停用、異常嘗試與更換聯絡方式。錯誤訊息應協助合法使用者復原，但不要洩漏某個帳號是否存在。Token、工作階段與敏感憑證應使用作業系統建議的安全儲存方式，並由伺服器驗證有效性。
- 依資料敏感度與交易風險決定驗證強度
- 設計註冊、登入、找回、換機、登出與停用的完整流程
- 明確處理第三方登入與既有帳號的合併規則
權限必須在伺服器端逐項檢查
把管理按鈕藏起來只是介面控制，不等於安全。每一次讀取、修改、匯出或刪除資料的 API 請求，都應確認使用者身分、角色、資料歸屬與允許的動作。例如分店人員只能看所屬分店、講師只能看自己的課程、會員只能讀取自己的訂單，不能只用一個「已登入」條件涵蓋所有情境。
權限模型可從角色開始，但還要處理紀錄層級與狀態限制。客服或許能查看聯絡資料，卻不能匯出全部會員；營運人員能改期，但已退款訂單不得任意恢復。高風險操作可要求再次驗證、主管核准或留下原因。權限異動、資料匯出及重要交易應有可稽核紀錄，並定期檢視不再需要的權限。
- 分開定義查看、新增、修改、刪除、匯出與核准能力
- 同時檢查角色、資料所有權、組織範圍與目前狀態
- 對敏感操作加入重新驗證、確認或稽核紀錄
用資料生命週期管理個資
個資設計應從目的開始：每個欄位為何需要、在哪個步驟收集、誰能使用、會提供給哪些第三方，以及何時刪除或去識別。不要因為「未來可能用到」就一次收集身分證明、生日、位置或通訊錄。定位、相機、照片與通知等系統權限，應在使用者準備啟用相應功能時說明價值並提出請求。
使用者還需要能查看與更新必要資料、調整同意與行銷偏好、申請刪除帳號，並理解哪些交易或法定紀錄可能依政策保留。企業端要定義保存期限、備份中的刪除方式、第三方資料流、事件應變與客服處理程序。實際法律義務會依市場與資料類型不同，產品團隊應把法務或隱私審查納入正式上線流程。
- 資料最小化：只收集完成明確目的所需的欄位
- 透明控制：說明用途、第三方、偏好與刪除方式
- 營運治理：保存期限、備份、事件處理與供應商責任
AgentTech 如何把安全要求落實到產品流程
客戶的難點通常是既要讓會員快速完成登入，又無法接受跨分店看到錯誤名單、離職人員保留權限或敏感資料遭大量匯出的風險。AgentTech 會先建立資料盤點、角色權限矩陣與高風險操作清單，再把註冊、登入、找回、停用、刪除及內部管理流程做成可驗收規格。工程範圍包含伺服器端授權、工作階段管理、安全儲存、稽核紀錄與必要監控；法規判斷則應由企業依服務市場配合法務或隱私專業審查。
以多分店課程 App 為例：學員可以查看自己的出席與付款紀錄，櫃檯只能管理所屬分店，區域主管可看彙整報表，但不應下載完整身分資料。AgentTech 可把「角色、分店、資料所有權、紀錄狀態」四層條件放進 API 授權，對匯出和權限異動加入重新驗證及稽核；帳號停用後同步撤銷工作階段。測試時以不同角色實際嘗試越權讀取與修改，確保安全要求不是只寫在文件裡。
- 盤點個資目的、資料流、保存期限及第三方服務
- 定義登入復原、角色／紀錄授權及敏感操作防護
- 執行權限測試、事件紀錄、帳號停用與上線前安全檢查
這篇文章適用的服務
iOS、Android 與跨平台 App
APP Agent
產品需求、原生與跨平台選型、商業 App、API 與後台、登入權限、測試上架及版本維護。