審計日誌其一：Web 服務中的審計日誌思維 ― 需求整理基礎篇

競標中常見的「稽核日誌」究竟要記錄什麼？

大家好，我是在 Liberogic 擔任 CTO 的大塚。

參與 Web 網站或 Web 服務的競標時，需求中經常會寫著「能夠取得稽核日誌」「日誌要保存一定期間」等要求。

根據這些需求來選擇服務、變更方案或添加日誌保存的選項，但說起來「稽核日誌」究竟是指什麼呢？

這次我想試著把這些部分整理一下。

日誌也有各種類型

雖然籠統地說是日誌，但實際上有幾種類型。

這些都是日誌，但記錄的內容和使用目的各不相同。
例如，管理員變更了使用者的權限、負責人發佈了內容等操作的記錄，通常被稱為審計日誌。

故障調查與證跡保全應該分開考慮

日誌的目的大致可分為兩類。

其中一種是用於調查發生故障或問題時原因的日誌。

在調查「昨天提交的表單沒有收到」、「特定時間段發生錯誤」等客戶諮詢時會用到。

另一個是事後確認操作事實的日誌。

「誰變更了設定」「何時發佈了內容」「管理畫面上進行了什麼操作」之類的記錄。

這兩種的保存期間和使用方式都不同。

若試圖長期保留所有日誌且保持可搜尋的狀態，成本會大幅增加。反之，若只保留最近的日誌，審計或事件調查所需的證跡就會消失。

從一開始就分開考量，才能設計出合理的方案。

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

僅用「稽核日誌」這個詞無法決定具體的配置。

首先確認目的，然後將其轉化為必要的記錄和保存方法。

「可以取得日誌」還不夠

如果雲端服務的管理畫面上顯示了日誌，我們往往會認為「日誌已經取得了」。

但是，服務保存的內容和期間因服務而異。

• 會記錄錯誤，但不記錄管理員的操作
• 可以在管理畫面上確認，但在一定時期後會刪除
• 若要轉發到外部，需要升級為更高階的方案
• 應用程式自身的操作需要由我們自己記錄。

「誰が商品資訊進行了變更」「處理了哪筆申請資料」這類業務記錄，有時僅靠雲端服務是無法掌握的。

如果競標需求中寫著「稽核日誌」，至少應該確認以下幾點。

需求整理檢查清單

✅️ 記錄哪些操作
✅️ 使用者和管理員，是哪一方的操作
✅️ 故障調查和稽核，目的是哪一個
✅️ 保存多長時間
✅️ 是否需要平時就經常搜尋
✅️ 誰可以查閱日誌
✅️ 是否可能包含個人資訊

在不明確這些問題的情況下決定服務或方案，會導致配置變得不必要地龐大，或者相反地缺少必要的日誌記錄。

現代 Web 服務中的日誌也是分散的

在傳統 Web 伺服器時代，人們可以採用相對簡單明瞭的做法：將伺服器內的日誌檔案保存下來。

現在越來越多是將 CDN、主機代管、資料庫、headless CMS、郵件配信等多個雲端服務組合在一起來建構 Web 服務。

Liberogic 也根據案件需求，不只使用 AWS，還會搭配 Cloudflare、Vercel、Supabase、microCMS、Kuroco 等服務。

日誌也分別保存在各個服務中，因此需要著眼於全局，思考「作為整個系統會留下什麼」。

首先從確認目的開始

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

當然，根據需求可能確實需要外部日誌管理服務或長期保存機制。但這並不意味著從一開始就要準備大規模的架構。

首先要釐清：記錄什麼、為了什麼目的、要保存多久。

在整理這些問題之後，再將標準功能能夠應對的部分與需要額外建置的部分區分開來，這樣才是實務做法。

下次我們將大致比較一下 AWS、Cloudflare、Vercel、Supabase、headless CMS 等我們經常使用的服務會產生什麼樣的日誌。

好的，那就這樣吧。