稽核日誌（其一）：Web 服務中稽核日誌的基本概念 ― 需求整理基礎篇

招標時常見的「審計日誌」應該記錄哪些內容？

大家好，我是 Liberogic 的 CTO 大塚。

參與網站或 Web 服務的招標時，需求中經常會出現「必須能取得審計日誌」、「日誌需保存一定期間」等描述。

為了符合這些需求，我們需要選擇服務、變更方案，或新增日誌保存選項。然而，「審計日誌」究竟指的是什麼呢？

本文將針對這些問題稍作整理。

日誌的種類繁多

簡單來說，日誌其實可分為幾種不同類型。

這些都屬於日誌，但記錄的內容與用途各不相同。
例如，記錄管理員變更使用者權限、或工作人員發布內容等操作的日誌，一般較接近所謂的稽核日誌。

故障調查與證據保全應分開考量

日誌的用途大致可分為兩類。

其一是在發生故障或問題時，用來查明原因的日誌。

用於調查「昨天送出的表單沒有收到」、「特定時段曾發生錯誤」等詢問時使用。

另一項是記錄，用於事後確認操作的實際執行情況。

這些記錄包括「是誰變更了設定」、「內容於何時發布」以及「在管理畫面中執行了哪些操作」等資訊。

這兩者的保存期間與使用方式各不相同。

若要將所有日誌長期保存在可搜尋的狀態，成本也會隨之增加。反之，若只保留最近的日誌，稽核或事故調查時所需的證跡就可能遺失。

若從一開始就將兩者分開考量，設計會更合理、更不吃力。

將「需要稽核日誌」轉化為需求

光是「稽核日誌」這個詞，無法決定具體的架構。

我們會先確認目的，再逐步整理需要保留的紀錄與保存方式。

只說「可以取得日誌」還不夠完整

若雲端服務的管理介面上已顯示日誌，很容易就會認為「已經可以取得日誌」。

不過，各服務保存的內容與保存期間都不盡相同。

• 錯誤會被留存，但管理者的操作不會被留存
• 可在管理介面確認，但會在一定期間後刪除
• 若要轉送至外部，需要更高階的方案
• 應用程式自身的操作，需要由我們自行記錄

「誰變更了商品資訊」、「處理了哪一筆申請資料」之類的營運紀錄，單靠雲端服務有時無法完整掌握。

若招標需求中寫有「稽核日誌」，至少建議先確認以下幾點。

需求整理檢查清單

✅️ 要記錄哪些操作
✅️ 是使用者的操作還是管理者的操作
✅️ 目的是障礙調查還是稽核
✅️ 需要保存多久
✅️ 平時是否需要搜尋
✅️ 誰可以查看日誌
✅️ 是否可能包含個人資料

若在未釐清這些問題的情況下決定服務或方案，可能會建置出超出所需的大型架構，或反而漏留必要的日誌。

現代 Web 服務的日誌也會分散

若是傳統的 Web 伺服器，只要保存伺服器內的日誌檔案，就能維持相對容易理解的做法。

如今越來越常見的做法，是組合 CDN、主機代管、資料庫、Headless CMS、郵件發送等多種雲端服務來建置 Web 服務。

Liberogic 除了 AWS 之外，也會依案件需求使用 Cloudflare、Vercel、Supabase、microCMS、Kuroco 等服務。

日誌也會分別保存在各個服務中，因此需要從整個系統的角度，審視「整體究竟會留下哪些紀錄」。

首先確認目的

一聽到「需要稽核日誌」，就會覺得必須導入特殊的服務。

當然，視需求而定，可能需要外部的日誌管理服務或長期保存機制。不過，並不是一開始就要準備龐大的架構。

首先要釐清的是：要記錄什麼、為了什麼而記錄，以及要保存多久。

在整理好這些之後，務實的做法是將可以用標準功能應對的部分，與需要另外建構機制的部分區分開來。

下一次，我們將簡單比較 AWS、Cloudflare、Vercel、Supabase、無頭 CMS 等我們經常處理的服務，各自會留下哪些日誌。

那麼就先這樣。