為什麼要做 DB LOG REVIEW
實務上，只要資料涉及高密級或個人資料，即使欄位本身已採用加密措施，仍必須被納入查核範圍。加密只是降低外洩風險的防護手段，並不等同於去識別化，因此不能因為「資料看不到明碼」就降低查核標準。這類資料的存取紀錄，至少需定期被完整檢視，才能符合內控與資安的基本要求。
另一個常被低估的風險來自帳號管理。若 LOG REVIEW 僅針對少數指定帳號進行抽查，一旦人員異動、權限調整未即時同步，實際發生的存取行為就可能完全不在查核範圍內。DB LOG REVIEW 的核心，不是帳號名稱，而是「所有實際參與維運的人」，是否都被納入同一套檢視邏輯。
此外，系統帳號的使用情境也必須被清楚區分。這類帳號原則上僅供自動化流程使用，任何非 SOP 規範的人為操作，都應被視為高風險行為。透過 LOG 查核確認系統帳號是否僅執行預期行為，是避免責任模糊化的重要一環。
綜上所述，DB LOG REVIEW 的目的是讓組織在面對稽核、資安事件或內部追查時，有一條清楚、可驗證的證據鏈，支撐責任歸屬與決策判斷。
從 Visualize 到 Dev Tools：一次實際走過的 DB LOG REVIEW 路徑
真正開始執行 DB LOG REVIEW 時，第一個遇到的問題往往不是「要不要做」，而是「怎麼做才符合實務需求」。在初期，我同時向前輩請教，也與 AI 反覆討論可能的做法，並逐一嘗試。
最先嘗試的是 Visualize，透過條件設定後，對 LOG 資料進行加總、分組與趨勢觀察，在日常監控場景中相當實用。然而在 DB LOG REVIEW 的情境下，需求是逐筆檢視實際發生的操作行為，尤其是完整的 SQL statement。實際使用後發現，受限於欄位長度與呈現方式，statement 內容容易被截斷，只能針對 user 或 source IP 等欄位進行篩選，無法直接判斷 SQL 中實際涉及哪些 table。最後仍需回到 raw log 一筆一筆檢視並手動整理，整體成本過高，因此被排除。
第二個方法是透過 OpenSearch API 直接拉取資料。從架構與自動化角度來看，這是最乾淨、也最具延展性的作法，但實務上受到內部網路或資安政策限制，無法從日常工作環境直接存取 API。對需要在既有規範下完成任務的人而言，這同樣不是一條能即時落地的方案。
第三個嘗試的是直接在 Discover 中匯出查詢結果。理論上，Discover 最貼近逐筆 LOG 明細的檢視需求，也支援條件篩選與時間區間控制。然而在我的狀況，組織限制匯出功能，最後採用將查詢的結果 json 用 AI 分析擷取我要的資料並轉為 excel。
怎麼做👉【PM/SA】DB Log Review 實戰系列（二）：5 分鐘用 OpenSearch Discover 完成交付
最後一個方法，是使用 Dev Tools。透過 Dev Tools 可以更明確的撰寫特定查詢語法，明確定義所需條件，包含時間範圍、帳號型態、操作行為，以及排除系統自動產生的 metadata 查詢。這些條件在與 AI 反覆確認後，被轉換為可執行的 query，並取得包含完整 statement 的 LOG 明細。
怎麼做👉 【PM/SA】DB Log Review 實戰系列（三）：5 分鐘用 OpenSearch Devtools 完成交付
當資料能被正確撈出後，後續處理反而變得單純。將查詢結果交由 AI 協助整理欄位、轉換格式，快速產出可供檢視與留存的 excel 檔案。整個流程不僅精準對焦查核需求，也具備可重複執行的特性，後續只需調整查詢條件即可再次完成 LOG REVIEW。
【PM/SA】DB Log Review 實戰系列（一）：OpenSearch 結合 AI 不寫程式的試錯過程
回頭看這次經驗，DB LOG REVIEW 真正困難的地方，並不在於工具本身，而在於如何在組織限制、資安規範與時間壓力之下，找到一條「做得到、交得出去、也說得清楚」的實務路徑。
