操作紀錄與稽核:出事時的唯一證據

「這筆訂單的價格怎麼變成一折?」「這批商品是誰刪掉的?」當老闆問出這種問題,而系統只能兩手一攤的時候,接下來就是全公司互相猜疑的羅生門。稽核日誌(audit log,系統對每個重要操作留下的紀錄:誰、在什麼時候、做了什麼、把什麼改成了什麼)就是為了這一刻存在的。平常沒人看它,出事時它是唯一的證據。

該記什麼:不是全部,是「有後果的操作」

常見的兩個極端:什麼都不記,或什麼都記。前者出事沒得查,後者日誌爆量、要查的時候反而大海撈針。我們的原則是記「有後果的操作」——那些改變金錢、庫存、權限與資料存在性的動作:

• 錢相關:改價格、退款、折扣調整、手動改訂單金額。
• 貨相關:庫存調整、盤點修正、進出貨單的修改與作廢。
• 資料存在性:刪除訂單、刪除會員、批次匯入匯出(匯出全部客戶名單這種動作,尤其要記——個資外洩調查時第一個查的就是它)。
• 權限相關:開帳號、改角色、重設密碼。改權限的紀錄本身,是稽核鏈的起點。
• 登入行為:成功與失敗的登入、來源裝置。連續失敗是攻擊訊號,異常時段登入是內鬼訊號。

每一筆紀錄至少要有四個要素:誰(帳號)、何時(精確時間)、做了什麼(動作)、改動前後的值。最後一項最常被偷懶省略,但「價格從 1,200 改成 120」和「價格被改過」是兩種完全不同等級的證據力。

日誌本身要防篡改,否則只是日記

這是稽核日誌和一般系統紀錄的本質差異:稽核日誌必須連管理員都不能改。如果有權限的人可以事後刪掉自己的操作紀錄,這份日誌的證據力等於零。實務做法包括:日誌只能新增、不能修改與刪除(工程上稱 append-only);日誌與主系統分開存放,主系統被入侵也動不到它;真正敏感的環境還會把日誌即時複寫到另一個獨立服務。我們自己營運的進銷存 SaaS 支撐加盟門市的金流與庫存,總部與加盟主之間的信任,有一部分就是建立在「每一筆調整都有不可否認的紀錄」上——對帳有爭議時,翻紀錄,不用翻臉。

稽核日誌買的不是監控,是信任:因為每個人都知道有紀錄,大多數不該發生的事根本不會發生。

保存政策:留多久、誰能看

留多久?看資料性質。與交易和稅務相關的紀錄,建議對齊帳務憑證的保存年限(台灣稅法對帳簿憑證的要求是五年起);涉及個資存取的紀錄,個資法的舉證需求也支持多留。純操作行為的日誌,常見做法是線上留一年供快速查詢,更舊的壓縮歸檔到便宜的儲存空間。重點是先訂政策再實作,而不是等硬碟滿了才隨手刪。

誰能看也要設計:日誌本身就包含敏感資訊(誰的薪資被查過、哪個客戶的資料被開過),查閱日誌這個動作,本身也該留下紀錄。聽起來像套娃,但真的發生內部調查時,「誰去翻過紀錄」往往跟紀錄本身一樣重要。

什麼時候該做?越早越好,補做很貴

稽核日誌是典型的「事前便宜、事後昂貴」:系統設計時內建,成本是零頭;上線多年後補裝,每個功能都要回頭改,而且出事前的空白期永遠補不回來。它和權限設計是一對的——權限決定誰能開門,日誌記下誰開過門,兩者合起來才是完整的內控。如果你的系統目前連「誰改了價格」都答不出來,建議把這件事排進下一次改版,別等到需要證據的那天才發現一片空白。這類內控機制怎麼補、怎麼排優先序,可以參考我們的客製化系統與 SaaS 服務。