審計日誌其2：Web服務的日誌功能橫向比較 | 主題

AWS、Cloudflare、Vercel、Supabase、headless CMS中還剩下什麼？

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

上次我們整理了存取日誌、應用程式日誌和審計日誌之間的差異。

這次我們將更具體地了解在我們日常使用的AWS、Cloudflare、Vercel、Supabase、headless CMS中，可以取得什麼樣的日誌。

話雖如此，我們並不是在細緻比較各服務的價格或功能。

因為各服務在「標準保留什麼內容」和「事後可以確認到什麼程度」這些特性上有很大差異，所以我們將大致整理一下這方面的內容。

服務	主要可確認的日誌	長期保存的思考方式	注意事項
AWS	執行、存取、管理操作	結合 CloudWatch 和 S3	每個服務都需要進行設定
Cloudflare	Workers 的執行、例外等	轉送至 R2 或外部服務	靜態配信與執行日誌分開記錄
Vercel	Functions、部署、執行日誌	透過 Log Drains 等轉送至外部	保存範圍取決於方案
Supabase	資料庫、API、身份驗證、管理操作	透過 Log Drains 等轉送至外部	應用程式特有的操作需另外實作
Headless CMS	內容更新、管理操作	使用服務的歷史紀錄・稽核功能	目標操作和方案不同
Datadog／Sentry	彙總的日誌、錯誤資訊	根據用途和儲存量進行設計	僅導入並不能成為稽核日誌

即使是相同的「日誌功能」，目標操作和保存期間也會有所不同。

另外，管理畫面上顯示的內容和為稽核目的長期保存的內容是兩回事。

AWS 雖然功能齊全，但需要進行設定

AWS 的日誌相關服務相當充實。

例如，Lambda 或 API Gateway 等的執行狀況會收集到 CloudWatch Logs。在 AWS 管理畫面或 API 上進行的操作，可以用 CloudTrail 記錄。

簡而言之，

CloudWatch Logs：檢視應用程式或 AWS 服務的運作
CloudTrail：檢視誰在 AWS 環境中執行了什麼操作
S3：長期保存日誌

各司其職的角色分工。

從搜尋、監控、通知到長期保存，都可以在 AWS 中組建完成，因此這種架構對稽核要求嚴格的系統也容易對應。

不過，「使用 AWS 就會自動保存所有內容」並非如此。

需要針對各個使用的服務設定日誌輸出，並決定保存期間和保存目的地。由於自由度很高，前提是要進行適當的設計。

Cloudflare 將短期調查與外部保存分開考慮

在 Cloudflare Workers 中，可以透過 Workers Logs 確認用 console.log() 輸出的內容和錯誤。

這對開發中的確認或近期的障礙調查非常方便，但如果需要保留長期的稽核軌跡，最好不要只依賴標準的日誌畫面。

需要長期保存的日誌應該考慮使用 Logpush 等工具，將其發送到 R2 或外部日誌管理服務。

此外，如果使用 Cloudflare Pages 或 Workers 來提供靜態網站服務，並非所有存取都會記錄在 Worker 執行日誌中。

網站看起來可以正常顯示，容易誤以為「當然會有存取日誌」，但靜態檔案的提供和 Worker 的執行是兩回事。

Cloudflare 相對容易建立精簡的設定，但需要理解各個流程的執行路徑，才能正確設計日誌。

Vercel 易於確認 Next.js 日誌

在 Vercel 中，可以從管理介面確認 Next.js Functions 和 Server Actions 等輸出的日誌。

由於部署和執行日誌位置相近，開發者容易理解，也便於日常的錯誤調查。

另一方面，日誌可查閱的期間和外部傳輸的範圍會因方案而異。

如果需要保留較長時間的日誌，需要使用 Drains 等工具將其發送到外部儲存位置。

不限於 Vercel，管理畫面中顯示日誌和為審計目的長期保存日誌是兩回事。

這兩點需要分開確認。

Supabase 產生的日誌不只是資料庫日誌

Supabase 是以 PostgreSQL 為中心的服務，但實際上並非只有資料庫功能，而是由身份驗證、API、儲存空間、Edge Functions 等多個功能組成。

由於各項日誌都能從管理畫面確認，因此可以輕鬆追蹤應用程式整體的運作狀況。

此外，還有身份驗證相關的日誌，以及用於確認在 Supabase 管理畫面上執行之操作的審計日誌。

不過這裡也要注意，Supabase 的管理操作和自己建立的應用程式內的操作是分開的。

例如，「誰變更了 Supabase 的專案設定」可以由服務端記錄，但「誰在自家管理畫面變更了客戶資訊」則需要由應用程式端記錄。

確認 headless CMS 的操作履歷

microCMS、Kuroco、NILTO 等 headless CMS 都提供內容更新履歷和管理畫面的操作日誌。

誰が文章進行更新、何時公開、設定或權限變更等紀錄，對網站運營中的審計日誌相當重要。

不過，紀錄的操作內容、可確認的期間、可使用的方案因服務而異。

內容更新履歷可以確認，但並非所有管理操作都會作為審計日誌保留。

此外，CMS 基本上只記錄 CMS 內部的操作紀錄。公開網站的存取、前端產生的錯誤，需要在託管環境端確認。

在 headless CMS 專案中，不只看 CMS，而是把 CMS、前端、託管和 API 視為一個整體系統會更容易理解。

加入 Datadog 或 Sentry 時

日誌分散在多個服務時，每次發生故障都得開啟各個管理畫面進行調查。

集約到 Datadog 等日誌管理服務，可統一搜尋多環境日誌，偵測異常並發送通知。

Sentry 也經常使用，該服務擅長調查錯誤發生位置和影響範圍。

兩者都很便利，但導入後並不會自動完成審計日誌。

需要由應用程式側決定輸出的內容，如果長期保存所有日誌，成本也會隨著資料量增加而增加。

保存方式	適合的用途	特點
管理面板・日誌管理服務	日常故障調查	可立即搜尋，但費用會隨儲存量增加
R2・S3 等儲存空間	稽核、憑證的長期保管	可低成本保存，但調查時需要提取作業

在實踐上，將日常搜尋的日誌與需要保留以備不時之需的日誌分開是比較合理的做法。