發生資安事件時，外部鑑識人員通常第一天就會問：「VPN 登入紀錄能調到幾個月前？網域控制站有沒有開稽核？Microsoft 365 或 Google Workspace 的稽核紀錄留了多久？」很多公司到這時才發現，防火牆日誌只存在設備本機、早就被覆寫；雲端登入紀錄只剩最近幾天；或是攻擊者拿到管理員權限後，順手把伺服器上的事件紀錄清掉了。事件發生後才開始收日誌，只看得到之後的事，看不到攻擊者是怎麼進來的。

這篇寫給沒有大型資安監控中心（SOC）、卻常被問「我們有沒有日誌」的 IT 人員與主管。做法是從調查需求倒推：調查要回答哪些問題、需要哪些日誌、怎麼讓日誌在需要時查得到也信得過，以及該保存多久。事件當下如何保全證據，請見疑似遭入侵的前 24 小時。

為什麼要從調查倒推

Mandiant 依 2025 年處理的事件調查統計，全球入侵潛伏時間（從入侵到被發現）的中位數是 14 天，比前一年的 11 天更長；網路間諜與北韓 IT 人員冒名受雇這兩類事件，中位數都是 122 天，BRICKSTORM 這類威脅更潛伏將近 400 天[1]。Mandiant 指出，面對這樣的潛伏時間，常見的 90 天日誌保存政策會讓組織完全看不到最初的入侵途徑與完整範圍[1]。

澳洲 ASD 與美國 CISA、FBI、NSA 等多國機關在 2024 年 8 月發布的《事件日誌與威脅偵測最佳實務》也提醒，預設的日誌保存期間往往不夠：有些事件可能長達 18 個月才被發現，有些惡意程式會在網路中潛伏 70 到 200 天才造成明顯損害；事件發生時缺少歷史日誌，經常會拖累應變工作[2]。

調查人員能還原的，只有「當時有記錄、而且現在還留著」的部分。事件調查最常要回答的問題，可以直接對應到需要的日誌：

  • 攻擊者從哪裡進來？ VPN 與遠端存取、防火牆、郵件閘道，以及對外服務的日誌。
  • 用了哪些帳號、權限有沒有被提升？ AD、Entra ID、Google Workspace 等身分系統的登入與帳號異動紀錄。
  • 進來之後做了什麼？ 端點的程序執行與 PowerShell 紀錄，以及伺服器、資料庫的管理操作。
  • 連去哪裡、資料有沒有被帶走？ DNS、Proxy、防火牆連線紀錄與雲端服務的稽核紀錄。
  • 最早從什麼時候開始？ 以上每一種都要保存得夠久，而且各系統的時間要對得起來。

這些問題答不出來，就無法判斷要重設哪些帳號、哪些資料可能外洩，也很難向主管機關、客戶或個資當事人說明事件範圍。

先記哪些日誌：依調查價值排序

ASD 等機關的指引依「被鎖定的可能性」與「遭入侵後的影響」，列出企業網路應優先收集的日誌來源，排在最前面的是：可能被鎖定的關鍵系統與資料、對外服務（含遠端存取）、身分與網域管理伺服器、其他關鍵伺服器、邊界路由器與防火牆等邊界設備、管理者工作站；DNS、Web Proxy 與郵件伺服器也在清單上[2]。雲端服務則建議優先記錄使用者帳號存取與管理雲端服務的活動、管理設定變更、帳號與權限的建立、刪除與修改，以及透過 SAML、OAuth 驗證第三方服務的成功與失敗[2]。人力有限的 IT 團隊，可以照下面的順序補起來。

身分：登入、MFA 與特權群組

網域控制站、Entra ID 或 Google Workspace 的登入成功與失敗（含來源 IP）、MFA 驗證方式的新增或變更、帳號建立或已停用帳號被重新啟用，以及特權群組的成員異動。攻擊者幾乎都要經過身分系統，這些紀錄也是判斷「哪些帳號要重設」的主要依據。ASD 列出的異常行為範例就包括：同一個 IP 嘗試以多個不同帳號登入、不可能的移動（短時間內從相距遙遠的地點登入），以及建立帳號或重新啟用已停用帳號，特別是具管理者權限的帳號[2]。

邊界設備與遠端存取

VPN 登入成功與失敗及來源 IP、管理者登入、設定變更、韌體更新，以及設備主動發起的對外連線。邊界設備是常見的入侵起點，本機日誌又可能被竄改或清除，要送到設備以外的地方保存，細節見VPN、防火牆與邊界設備的安全強化清單。

郵件與雲端管理稽核紀錄

Microsoft 365 整合稽核紀錄、Entra ID 稽核與登入紀錄、Google Workspace 的管理員與使用者紀錄。商業郵件詐騙調查需要的收件規則、轉寄設定、應用程式授權與信件存取紀錄都在這裡，追查方式見公司信箱帳號被盜用怎麼辦。這類日誌的預設保存期間往往很短，見後文。

端點：EDR，或至少開啟程序與 PowerShell 紀錄

ASD 等機關建議考慮導入端點偵測與回應（EDR），它能以更詳細的資料記錄程序建立事件，也能發現攻擊者停用監控服務；並建議一律開啟包含程序建立與命令列稽核的詳細日誌，PowerShell 則要記錄指令碼區塊（script block）與模組日誌[2]。沒有 EDR 的 Windows 環境，至少要開啟程序建立稽核：Windows 以事件 ID 4688 記錄新程序，但要同時啟用「Audit Process Creation」稽核原則與「Include command line in process creation events」群組原則，命令列內容才會被記錄，兩者預設都是「未設定」[3]。攻擊者常用系統內建工具「就地取材」，沒有命令列紀錄幾乎看不出異狀，背景見國家級駭客（APT）的常見手法。

DNS、Proxy、重要伺服器與資料庫

DNS 查詢與 Proxy 紀錄可以回答「哪台電腦在什麼時候連到哪個網域」，用來找出連往中繼站的電腦與資料外傳的去向；重要伺服器與資料庫則要記錄管理者登入、權限變更與大量匯出。

讓日誌真的能用：時間、集中、保護、告警與演練

有日誌不等於查得到。ASD 等機關列出的日誌實務四大要素中，有兩項就是「集中收集與關聯分析」與「安全儲存與日誌完整性」[2]。實務上可以檢查五件事：

  • 時間一致：所有系統使用準確可信的時間來源，並採用相同的日期時間格式；指引偏好沒有時區與日光節約時間問題的世界協調時間（UTC），格式採 ISO 8601，可能的話準備多個時間來源[2]。設備之間差幾分鐘，跨系統還原事件順序時就可能判斷錯誤。
  • 送到主機以外集中保存：有些攻擊者會修改或刪除本機日誌來躲避偵測；許多網路設備本機空間有限，空間用盡就覆寫舊日誌。指引建議把日誌轉送到集中、安全的儲存位置，放在獨立或區隔的網段，只讓確有需要的人員擁有刪除或修改日誌的權限，並做備份[2]。換句話說，拿到網域管理員權限的攻擊者，不應該也能刪掉集中保存的日誌。
  • 保護完整性：傳輸與儲存時使用 TLS 1.3 等安全機制與密碼學驗證，確保日誌未遭竄改；SIEM 本身也是攻擊目標，要強化並與一般 IT 環境區隔[2]。
  • 先設少數高價值告警：與其匯入所有日誌卻沒人看，不如先針對幾種「出現了就一定要有人看」的事件告警，例如非預期的日誌清除、新增帳號或重新啟用已停用帳號、資安軟體或日誌管理設定被變更、同一 IP 嘗試多個帳號、不可能的移動[2]。
  • 實際演練查詢：指引把「日誌與日誌平台對分析人員可用、效能足夠」列為目標之一，也強調日誌要及時匯入，延遲匯入就會延後發現事件[2]。可以隨機挑一個四個月前的日期，試著查出「那天誰從哪個 IP 登入 VPN、之後又登入了哪些伺服器」；查不到，或某個來源早就停止傳送日誌卻沒人發現，就是要補的缺口。這個情境也適合放進桌上演練。

要保存多久：國際基準與台灣規範

國際基準

ASD 等機關沒有給單一數字，而是建議保存期間要「長到足以支援資安事件調查」，依系統風險評估決定，也要符合當地法規；能確認入侵與影響範圍的關鍵日誌應優先保存更久，同時檢查儲存空間是否足夠，並以熱儲存（可快速查詢）與冷儲存（成本較低）分層[2]。

美國聯邦機關的規定常被拿來當參考點，但它只適用於美國聯邦機關，而且已經改版。2021 年 8 月的 OMB M-21-31 備忘錄，要求多數日誌類別在主動儲存保存 12 個月、在冷資料儲存保存 18 個月，完整封包擷取資料只需保存 72 小時，並註明這些都是最低值[4]。2026 年 5 月 22 日，OMB 以 M-26-14 廢止 M-21-31，指出大量保存用途不明的日誌，對多數機關既不可行也不符成本效益；新的最低基準是日誌產生後至少 6 個月內可直接搜尋，產生後 1 年內都要能取回（例如從封存或冷儲存還原後分析）[5]。M-26-14 也列出日誌至少要能回答的問題，包括執行操作的身分、來源與目的地網路位址、資料被存取或變更、權限變更，以及初始入侵與橫向移動的途徑[5]。

NIST 的日誌管理指引 SP 800-92 是 2006 年發布的版本；修訂版 SP 800-92 Rev. 1 在 2023 年 10 月發布草案，NIST 表示仍在處理公眾意見，目前還不是定案標準[6]。

台灣規範

  • 資通安全責任等級分級辦法：最近一次修正是 2026 年 1 月 7 日，第 11 條要求各機關依附表十「資通系統防護基準」執行控制措施[7]。附表十的事件日誌要求包括：訂定日誌記錄時間週期與留存政策，並保留日誌至少六個月；決定應記錄的事件，並記錄系統管理者帳號執行的各項功能；日誌應包含事件類型、發生時間、發生位置與使用者身分識別等資訊；時戳要能對應到 UTC 或 GMT，系統時鐘要定期與基準時間源同步。防護需求等級「中」以上，還要定期審查日誌，並以雜湊等方式確保完整性；等級「高」要定期把日誌備份到原系統以外的其他實體系統[7]。這套規定適用於公務機關與特定非公務機關，適用範圍見資通安全管理法重點整理；一般企業不受拘束，但可以當成最低參考。
  • 上市上櫃公司資通安全管控指引：要求建立資通系統與相關設備的監控措施，涵蓋身分驗證存取紀錄（如失敗登入、非作業時間登入、多位使用者從同一來源 IP 登入成功）、存取資源紀錄、重要行為、重要資料異動、偵測攻擊與未授權連線、功能錯誤與管理者行為，並對日誌建立適當的保護機制；遠端存取則要留存完整的使用者操作稽核軌跡[8]。指引沒有規定保存期間，並說明上市櫃公司可依產業特性、規模大小與資安風險適度採行[8]。
  • 個人資料保護法施行細則第 12 條：個資保護的適當安全措施，得包括「使用紀錄、軌跡資料及證據保存」，並以與保護目的之間具有適當比例為原則；條文沒有規定保存多久[9]。

日誌本身也是個人資料

日誌裡有帳號、IP 與登入地點；命令列甚至可能夾帶密碼，開啟命令列稽核後，能讀取安全性事件紀錄的人都看得到[3]。保存越久、越多人能看，外洩時影響越大。ASD 等機關也提醒日誌可能含有敏感資料，使用者只應存取工作需要的日誌[2]。可行的平衡是：在日誌政策中寫明蒐集目的與保存期間，到期刪除；限制誰能查詢，並記錄查詢行為；不需要的內容（例如信件本文）不寫進日誌。

建議的分層做法

綜合以上，可以把身分系統、VPN 與邊界設備、網域控制站與雲端管理稽核紀錄列為第一級：至少 6 個月可直接查詢、1 年以上可以取回，同時滿足附表十的六個月下限與 M-26-14 的最低基準。預算允許的話，邊界設備與身分日誌再保存更久，才涵蓋得到以季、以年計的潛伏案例；其他日誌再依風險縮短。這是起點，不是上限。

雲端與 SaaS：預設保存期間比你想的短

雲端服務的日誌由供應商代管，但只保存一段時間，到期就消失，事後也補不回來：

  • Microsoft Entra ID：稽核紀錄與登入紀錄，Free 版保存 7 天，P1、P2 為 30 天；事後升級授權不會追溯，已過期的資料除非事先封存，否則無法復原。要保存更久，可透過 Azure Monitor 轉送到 Azure 儲存體帳戶；這些紀錄也和 Microsoft 365 整合稽核紀錄分開計算[10]。
  • Microsoft 365 整合稽核紀錄：稽核（標準）保存 180 天（2023 年 10 月 17 日以前產生的紀錄為 90 天）；稽核（進階）預設把 Entra ID、Exchange、OneDrive 與 SharePoint 的稽核紀錄保存 1 年，搭配附加授權最長可保存 10 年；也可以用 Office 365 管理活動 API 把紀錄匯入 SIEM，保存得比 180 天更久[11]。
  • Google Workspace：管理員紀錄、使用者紀錄（原稱登入稽核紀錄）、Gmail 與雲端硬碟紀錄都保存 6 個月，其他報表與紀錄一般也是 6 個月，管理員無法變更保存期間[12]。

對照前面的潛伏時間，7 天、30 天甚至 6 個月都可能不夠。最實際的做法是現在就設定匯出：把雲端稽核與登入紀錄定期送到自己控制的 SIEM 或儲存空間，存放處的管理帳號與雲端租戶管理員分開，並定期確認匯出沒有中斷。事件發生時，也要先把這些紀錄匯出保存，避免在調查期間過期。

行動清單

  • 拿「從哪裡進來、用了哪些帳號、做了什麼、資料去了哪裡、從什麼時候開始」五個問題，逐一對照現有日誌：有沒有記錄、存在哪裡、實際保留幾天。
  • 查清楚 Entra ID、Microsoft 365 與 Google Workspace 的實際保存期間，需要更久的就設定匯出到自己的 SIEM 或儲存空間。
  • 把 VPN、防火牆、網域控制站與雲端稽核紀錄集中到另一套系統，權限與日常管理帳號分開，確保管理員無法刪除。
  • 在 Windows 開啟程序建立稽核與命令列紀錄、PowerShell 指令碼區塊紀錄；有 EDR 的話，確認遙測資料保留多久、能不能匯出。
  • 所有伺服器、網路設備與雲端服務使用同一組 NTP 時間來源，日誌一律以 UTC 或明確標示時區的 ISO 8601 格式記錄。
  • 先設定 5 到 10 個高價值告警：日誌被清除、新增或重新啟用管理者帳號、特權群組異動、MFA 驗證方式變更、資安軟體被停用、同一 IP 嘗試多個帳號。
  • 寫下日誌政策：記哪些、可查詢與封存各保存多久、誰能查詢、到期如何刪除；適用資安法的單位至少符合附表十的六個月下限。
  • 每半年做一次查詢演練，隨機挑一個幾個月前的日期追查 VPN 登入與後續活動，把查不到的缺口列入改善。
  • 發生事件時先匯出、備份相關日誌並暫停覆寫，再開始處置，步驟見疑似遭入侵的前 24 小時；需要外部鑑識與調查協助時，可參考事件應變服務。