安全日誌應記錄時間、事件、主體、結果與關聯 ID，排除密碼、Cookie、Token 與不必要個資，並建立可行動的告警與保留週期。
日誌是事件時間線，不是資料倉庫
沒有日誌時，很難回答問題從何時開始、影響哪些帳號、攻擊者做了什麼；記錄過多則可能把密碼、Session、個資與商業資料複製到更多地方。安全日誌的目標是支持偵測、調查與稽核，而不是保存每個請求的全部內容。
先為登入、權限變更、敏感資料存取、發布、DNS／主機設定、上傳與錯誤定義需要的欄位與保留時間。
每筆事件至少要能串起來
建議包含可信時間、事件類型、結果、主體或匿名識別、來源、目標資源、請求或關聯 ID、應用版本與必要錯誤碼。使用結構化格式，讓搜尋與告警不依賴不穩定文字。
伺服器與服務的時鐘要同步並記錄時區。跨系統使用相同 correlation ID，才能把 CDN、Web、API、資料庫與郵件事件串成一條時間線。
明確列出永遠不記錄的資料
- 密碼、一次性驗證碼、備援碼與私鑰。
- 完整 Cookie、Authorization、Session ID、API Token 與重設連結。
- 信用卡完整號碼、身分證件與不必要的表單內容。
- 可直接存取私人檔案的簽名網址。
對郵件、電話、IP 與帳號 ID 做最小化或假名化，並限制誰能讀取日誌。偵錯模式不能長期在正式環境輸出完整請求。
告警必須能採取行動
高價值告警包括大量登入失敗後成功、MFA 或復原資料變更、新管理員、權限提升、異常匯出、跨租戶拒絕、上傳掃描失敗、CSP 違規激增、Service Worker 或核心檔案雜湊改變。
每個告警要有擁有者、嚴重度、調查步驟與回應時限。只把所有 4xx、5xx 都寄信會迅速造成疲勞，反而讓真正事件被忽略。
保護日誌本身
應用程式只能附加寫入自己的事件，不能任意修改歷史；集中日誌平台使用獨立帳號、最小權限與 MFA。重要稽核資料可採不可變儲存或雜湊鏈，並監控刪除、停送與時間中斷。
傳輸與靜態儲存要加密，設定保留與自動刪除政策。備份日誌同樣受存取控制，不要把公開網站的 log 或錯誤檔留在 Web Root。
定期演練才能知道日誌夠不夠
用無害情境演練：測試帳號連續登入失敗、撤銷工作階段、權限變更與發布回復。確認事件在預期時間內出現、欄位足以判斷、告警送到正確人員，且不含敏感值。
每次事件後檢討缺少與多餘欄位、查詢速度、時間同步與保留週期。日誌設計應隨功能與風險更新，不是一開始開啟 access log 就完成。