存取控制與稽核日誌

3 個觀點

1. 誰能存取（人類、服務帳戶）
2. 什麼能存取（資料、功能、環境）
3. 記錄誰在何時做了什麼（稽核日誌）

最小權限的原則

所有權限都從必要最小限開始，依需要擴張。「以防萬一而放寬」是事故的根源。

RBAC（角色型存取控制）

將權限賦予角色而非個人，再將角色分配給個人的方式較易管理。

角色範例：
・Admin       … 全權限（極少數）
・Operator    … 經由正式工具的讀寫
・Support     … 顧客資料僅讀取
・Developer   … 僅開發、測試
・Auditor     … 僅稽核日誌讀取

密鑰、權杖的存取

• ReceiptRoller 的用戶端密鑰 → 僅正式服務帳戶
• 顧客的存取權杖 → 僅應用程式執行使用者，對人類隱藏
• Webhook 密鑰 → 僅接收伺服器

稽核日誌

記錄誰做了什麼，對不正偵測、事故調查、合規因應是必須的。

應記錄的事件

• 對正式環境的登入、登出
• 密鑰、權杖的取得
• 顧客資料的閱覽（尤其是大量取得）
• 資料刪除、匯出
• 應用程式設定的變更
• 權限的賦予、剝奪

各記錄應包含的項目

• 時間戳（UTC）
• 執行者（user_id / service_account_id）
• 動作（read, write, delete 等）
• 對象（resource_type ＋ resource_id）
• 結果（success / failure）
• 用戶端IP、User-Agent
• 相關請求ID

保管

• 稽核日誌專用的儲存（僅寫入、不可竄改）
• 最少 1 年（依業界而定為 3～7 年）
• 與應用程式日誌分開保管

定期審查

• 季度：已賦予權限的盤點，剝奪不需要的權限
• 月度：稽核日誌的異常模式確認
• 離職時：即時停用帳戶、相關密鑰輪替
• 年度：存取控制政策整體的檢視

多因素驗證（MFA）

能存取正式環境的所有使用者請設為 MFA 必須。相較於 SMS，建議 TOTP（Google Authenticator 等）或 FIDO2。

相關指南

• 資料保護的思維
• 正式運用的最佳實務
• 密鑰的輪替
• 返回開發者幫助中心