💡 今日學習目標：掌握結構化日誌（Audit Logging）寫作規範，理解 3-2-1 備份原則與資安事件應變流程（Detect, Respond, Recover），並看懂「有備份」跟「真的能復原」中間，還隔著一次演練。

📌 前言：一個沒有人在看的帳號，讓一整條輸油管停了六天

2021 年 4 月 29 日，攻擊者用一組外洩密碼，登入了美國 Colonial Pipeline（科洛尼爾輸油管公司）的員工 VPN 帳號。到 5 月 6 日，資料已經在往外傳了；5 月 7 日勒索軟體引爆。

這組密碼會外洩，是因為那位員工在別的服務也用了同一組密碼，而那個服務先前被駭。而那個 VPN 帳號沒有啟用多因素驗證，所以一組帳號密碼就足夠了。

但真正致命的是另一件事：這個 VPN 帳號早就沒人在用了，卻沒有人把它停用，也沒有人在看它的登入紀錄。 用 Colonial Pipeline 事後的話說：「沒有人在看著這些帳號，也沒有人會注意到它們被使用。」

5 月 7 日，攻擊者部署勒索軟體，公司隨即發現異常。雖然真正控制輸油管線的操作技術（OT）系統沒有被攻破（IT 與 OT 之間的隔離守住了），但公司無法在第一時間確認攻擊範圍，只能出於謹慎，把整條輸油管線直接關閉。這一關，就是將近六天。美國東岸一度陷入油荒恐慌。

Colonial Pipeline 最終支付了 **75 顆比特幣（約 440 萬美元）**贖金；一個月後，FBI 追蹤到贖金流向的錢包，透過法院命令追回了其中 63.7 顆（約 230 萬美元）。

📖 資料來源：TechTarget — Mandiant: Compromised Colonial Pipeline password was reused（入侵日期出自事件調查方 Mandiant）；TechTarget — Colonial Pipeline hack explained

這起事件精準地示範了今天要講的三個功能：Detect 沒做到（沒人看的帳號等於沒有監控）、Respond 被迫用最保守的方式處理（因為看不清攻擊範圍，只好整條線都停）、而 Recover 則決定了公司要付出多少代價換回正常運作。

🔍 實務落地一：偵測 (Detect) — 寫出高價值的資安審計日誌 (Audit Log)

沒有好的 Log，就沒有 Detect 能力。Colonial Pipeline 那個帳號不是沒有登入紀錄，是那份紀錄從來沒有人看過。 Log 存在，但沒有被監控、沒有告警規則，就跟不存在沒有兩樣。

但許多開發新手印 Log 總是隨便寫 console.log("error happens") 或 logger.info(user)，這對資安偵測毫無幫助，甚至可能造成敏感資料洩漏！

1. 結構化資安 Log 必備欄位 (Structured JSON Log)

{
  "timestamp": "2026-08-08T10:15:30Z",
  "event_type": "AUTHENTICATION_FAILURE",
  "severity": "WARNING",
  "user_id": "user_1029",
  "source_ip": "203.0.113.195",
  "user_agent": "Mozilla/5.0...",
  "resource_accessed": "/api/v1/login",
  "status_code": 401,
  "message": "Invalid password attempt for account"
}

2. Log 寫作三大鐵律：

• 🛡️ 鐵律 1：絕不記載敏感資料 ➔ 嚴禁把明文密碼、信用卡號、JWT Token 印進 Log 檔！
• 🛡️ 鐵律 2：包含關鍵人事時地物 ➔ Timestamp (ISO 8601 UTC)、User ID、IP 位址、操作動作、成功/失敗狀態。
• 🛡️ 鐵律 3：集中化管理，而且要有人／有規則在看 ➔ 將 Log 即時串流至集中伺服器（如 ELK / Grafana Loki），並針對閒置帳號突然被使用、異常時段登入等模式設告警規則。這是 Colonial Pipeline 案例裡缺的那一塊：光是把 Log 收集起來還不夠，沒有人看、沒有告警規則，等於白做工。

🔑 這跟 Day 24 講的 Equifax 案例是同一個坑：那次是監控設備因為憑證過期整整 19 個月處於失效狀態沒人發現，這次是閒置帳號的登入紀錄根本沒人在看。兩起事件的共同教訓是：監控機制本身，也需要被監控與定期檢查。

🔍 實務落地二：回應 (Respond) — 事發止血步驟

當系統發出異常告警（例如：1 分鐘內出現 5000 次密碼失敗）：

• 封鎖隔離：即時在 API Gateway 封鎖異常 IP 或暫時停用受害帳號。
• 保留現場：留存事件發生當下的 Memory Dump 與伺服器 Log，做為後續 Forensics（數位鑑識）依據。

Colonial Pipeline 的回應決策，剛好示範了 Detect 品質如何直接決定 Respond 的代價：因為當下無法快速確認攻擊有沒有跨越 IT／OT 的邊界（Day 22 講過的「信任邊界」），公司只能選擇代價最高的選項：整條輸油管線停機。 如果當時的監控能更快、更精準地確認「攻擊止步於 IT 系統，沒有觸及 OT 控制端」，回應範圍或許可以更精準，不必付出六天停擺的代價。這正是「能見度不足，只能用最貴的方式止血」的真實案例。

🔍 實務落地三：復原 (Recover) — 經典 3-2-1 備份原則

當面臨勒索軟體（Ransomware）加密或資料庫毀損時，完美的備份是最終救命稻草：

2017 年的 NotPetya 事件裡，航運巨頭 Maersk 全球 150 台網域控制器（Domain Controller）全數被清空，唯一倖存的一台，在迦納（Ghana）的辦公室。而它倖存的原因，純粹是那間辦公室在攻擊發生前就因為一次不相關的停電而斷網了。 靠著這一台意外躲過一劫的機器，Maersk 才有辦法重建整個網路的身分驗證系統。這次事件最終讓 Maersk 損失了 2.5 到 3 億美元。

📖 資料來源：WIRED — The Untold Story of NotPetya, the Most Devastating Cyberattack in History（迦納那台網域控制器的細節出自此篇深度報導）；Control Engineering — Throwback Attack: How NotPetya Took Down Maersk

🛡️ 演練提醒：只備份而不做復原演練 (Restore Drill) 等於沒備份！Maersk 是靠運氣撿回一條命，不是靠一份經過驗證的復原計畫，這中間的差距，就是「有備份」跟「有復原能力」的距離。必須定期測試備份還原流程，而不是假設備份「應該」是好的。

💡 常見誤解：「我們有做備份，所以資料安全」

跟 Day 25 講的「有加密 ≠ 安全」是同一種思維陷阱：「有備份」不等於「備份能被用來復原」。

Maersk 的案例是最極端的示範：如果那間迦納辦公室當天沒有停電，Maersk 很可能連重建網路身分系統的起點都沒有。 一間全球排名數一數二的航運公司，最後的救命稻草不是精心設計的災難復原計畫，而是一次意外。這不是說 Maersk 沒做備份，而是備份的可用性從沒有被真正驗證過，直到它成了公司唯一的救命稻草，才發現能用。

實務上，備份失敗最常見的原因不是「沒做備份」，而是：備份檔案本身已經損毀卻沒人發現、備份與正式環境用同一組帳密導致被一併加密、或者根本沒人記得復原流程的操作步驟。 這些問題只有在真的執行一次復原演練時才會被揪出來，而不是等到勒索軟體上門那天。

🎯 今日重點小結與防守心法

• 🔹 心法 1：沒人看的 Log，等於沒有 Log。Colonial Pipeline 那個帳號的登入紀錄一直都在，缺的是有人在看、有告警規則。
• 🔹 心法 2：能見度不足，回應只能用最貴的方式止血。Respond 的精準度，直接被 Detect 的品質決定。
• 🔹 心法 3：備份要演練，不能靠運氣。Maersk 靠一次意外停電撿回一條命，你的公司不該把復原計畫寄託在運氣上。

🚀 階段四完結：從「設計」邁向「管理」

恭喜！我們順利完成了 階段四：資安是設計出來的（Day 22 - Day 26）！

在階段四中，我們學習了：

1. Security by Design 核心哲學與 Fail-Closed 設計（Day 22，Capital One 案例）。
2. 手把手用 OWASP pytm 跑一次真正的 STRIDE 威脅建模（Day 23）。
3. 認識 NIST CSF 2.0 的六大功能，Govern 作為治理核心（Day 24，Equifax 案例）。
4. 落實了資產盤點、資料分類與保護機制（Day 25，Marriott 案例）。
5. 結構化 Log、事件回應與 3-2-1 備份機制（今天，Colonial Pipeline 與 Maersk 案例）。

五天五個真實案例，拼出的其實是同一句話：架構、治理、盤點、監控、備份，任何一環是空的，其他環做得再好也擋不住。

架構與設計確定了，最後一步就是**「讓防禦成為長久可持續運行的日常制度」**！

🚀 接下來，我們即將進入終章：階段五 — 資安是「管理」出來的！

從 Day 27 開始，我們將探討 ISO 27001 ISMS 管理精髓，並親手在 GitHub Actions 中打造自動化 DevSecOps 防線！

💬 明日預告：【Day 27】資安是管理出來的：ISO 27001 / ISMS 到底在管什麼？新手也能懂的管理精髓
明天我們將進入最後的階段五，解密國際權威資安標準 ISO 27001 的管理智慧！