💡 今日學習目標：學會在開發與架構設計中，落地 NIST CSF 的「識別 (Identify)」資產盤點與「保護 (Protect)」防衛防線，並看懂「分類寫在政策裡」跟「分類被真的落實」是兩件不同的事。

📌 前言：你買下來的系統，可能已經被入侵四年了

2014 年 7 月，攻擊者潛入了喜達屋（Starwood）飯店集團的訂房系統，開始竊取資料。

2016 年 9 月，萬豪（Marriott）併購喜達屋，把喜達屋的整套 IT 系統一併接手過來。

問題是：萬豪接手的不只是系統，還有系統裡那個已經潛伏兩年多的攻擊者，而萬豪完全不知道。

2018 年 9 月 8 日，一套新部署的資安工具偵測到異常的資料庫查詢，這才把整件事挖出來。2018 年 11 月 30 日，萬豪首次對外公告，當時估計最多約 5 億筆房客資料外洩。

調查繼續進行，2019 年 1 月 4 日萬豪更新了數字：實際約 3.83 億筆，其中包含 525 萬筆完全未加密的護照號碼，以及另外 2,030 萬筆已加密的護照號碼。對後者，萬豪的官方說法是「尚未找到證據顯示攻擊者取得了解密所需的主金鑰」，但也沒能證明沒有。

從最初被入侵，到被發現，中間隔了超過四年。

📖 資料來源：萬豪國際向美國證交會申報的官方聲明（2019-01-04，SEC Form 8-K 附件），3.83 億／525 萬／2,030 萬三個數字皆出自此份一手文件；Breachsense — Marriott Data Breach Case Study

這個案例剛好同時踩中今天要講的兩個核心功能：萬豪從一開始就不知道自己「識別（Identify）」到了什麼：併購時沒有完整盤點喜達屋的資產與風險，甚至後來還裁撤了大部分喜達屋原有的 IT 與資安人力，等於把原本可能還記得系統細節的人都送走了；而就算後來想「保護（Protect）」，同樣被列為機密等級的護照號碼，落實起來卻是兩種待遇。

🔍 實務落地一：識別 (Identify) — 盤點家底與資料分級

在開發生命週期中，Identify 代表對系統的所有組件進行徹底的「資產盤點」。這聽起來像是基本功，但萬豪的案例告訴我們：最容易被忽略的資產缺口，往往發生在組織邊界變動的時候：併購、部門重組、廠商交接，任何一次「系統換了主人」，都是資產清冊最容易出現斷層的時刻。

1. API 與服務資產盤點 (API Inventory)

• 作法：維護一份最新的 OpenAPI / Swagger 規格書，並定期清理已經不再使用的廢棄 API (Deprecated Endpoints)。影子 API（Shadow API），也就是那些沒被記錄、沒人記得還在跑的端點，常是駭客最愛的突破口，道理跟萬豪案例是同一件事：你沒辦法保護一個你不知道自己擁有的東西。

2. 第三方元件盤點 (Software Bill of Materials - SBOM)

• 作法：使用開源工具（如 npm audit、OWASP Dependency-Check）盤點專案 import 的所有第三方函式庫，確保沒有高風險已知漏洞。這一項我們會在 Day 29 談 DevSecOps 與供應鏈安全時再深入。Day 15 提過，軟體供應鏈失效（Software Supply Chain Failures）也是 OWASP Top 10:2025 新增的類別，跟資產盤點做不做得完整直接相關。

3. 資料分類與分級 (Data Classification)

光有資產清冊還不夠，每一筆資料還要有明確的機密等級，而且分級寫進政策，不等於分級被真的執行，這正是萬豪案例第二個教訓：

525 萬筆護照號碼完全沒加密，另外 2,030 萬筆雖然加密了，事後卻也無法完全排除金鑰一併外洩的可能。同一個「機密」等級，實際的防護程度卻不是均一的，這跟 Day 22 講的「Security by Design 不是一次性審查」是同一個道理：分類要覆蓋到全部資料，不能有漏網的那一批。

🔍 實務落地二：保護 (Protect) — 打造堅固的防禦堡壘

當資產盤點清楚後，接著進入 Protect（保護） 階段：

1. 身分管理與存取控制 (Identity & Access Control)

• 貫徹 RBAC (Role-Based Access Control) 角色權限矩陣，這正是 Day 16 講 IDOR 時的核心防線：「身分只能從伺服器端拿」。
• 對於管理員或敏感操作，強制要求 MFA（多因素驗證）。

2. 資料安全 (Data Security)

• 靜止資料（Data at Rest）採用 AES-256-GCM 或安全 Hash 儲存，並確保加密涵蓋到每一份複本（含備份與匯出檔）。這正是威脅建模（Day 23）裡 providesConfidentiality、isEncryptedAtRest 這類控制被列進檢查項目的原因。
• 傳輸資料（Data in Transit）全程強制 TLS 1.2 以上。

🧭 順便澄清一個關於萬豪案的常見誤讀。 你可能會看到「萬豪用的是 AES-128」這個細節，然後推論「所以它加密強度不夠」。

不是這樣。AES-128 到今天都沒有被攻破，NIST 與 OWASP 也都仍然認可它，本文建議 AES-256-GCM 是「更保守」而不是「AES-128 不安全」。

萬豪真正的問題是另外兩件事：有 525 萬筆護照號碼根本沒加密，以及已加密的那 2,030 萬筆，官方無法排除金鑰跟密文一起被拿走。

金鑰長度從來不是這起事件的破口，覆蓋率與金鑰管理才是。 這個區別很重要，因為「把 128 換成 256」是一個很容易做、做完會很有成就感、但完全沒有解到問題的動作。

3. 平台與網路硬化 (Platform Security)

• 關閉主機非必要的 Port。
• 資料庫只允許內網指定微服務的 IP 進行連線，禁止開放外網存取，這正是 Day 22 講的「最小攻擊面」在網路層的具體實踐。

💡 常見誤解：「我們資料都有加密，所以是安全的」

這句話在資安檢討會議上很常聽到，但萬豪的案例正好戳破它：「有加密」跟「加密有覆蓋到全部該保護的資料」，是兩件不同的事。

實務上常見的漏網情況包括：

• 舊系統的欄位沒補齊：併購或系統遷移時，舊資料庫的某些欄位在搬遷過程中「先求能動」，加密留到「之後再補」，然後就沒有之後了。
• 加密了，但金鑰管理本身是弱點：萬豪的案例裡，官方無法排除加密金鑰跟被加密的資料一起被拿走的可能。如果金鑰跟密文放在同一個信任邊界裡（呼應 Day 22 的柱石 1），加密提供的保護效果會大打折扣。
• 分級標準本身有模糊地帶：護照號碼、身分證號這類欄位，如果系統裡有超過一個地方在儲存（例如客服工單附件、備份快照、匯出的報表），分級政策很容易只覆蓋到「主要」的那一份，其他複本被漏掉。

資料分類與加密不是「做了就等於做完」的一次性動作，而是需要定期稽核「覆蓋率」的持續工作。

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

• 🔹 心法 1：組織邊界變動，是資產清冊最容易斷層的時刻。併購、交接、重組時，第一件事永遠是先重新盤點，不是先急著整合。
• 🔹 心法 2：分級要問覆蓋率，不是問有沒有做。「機密」等級的資料裡，有沒有漏網的複本、舊欄位、備份檔？
• 🔹 心法 3：加密要跟金鑰管理一起看。密文和金鑰放在同一個信任邊界裡，等於沒加密。

💬 明日預告：【Day 26】NIST CSF 實務落地：偵測 (Detect)、回應 (Respond) 與復原 (Recover) — Log 與應變
明天我們將探討 NIST CSF 的後三棒：當攻擊發生時，如何即時偵測、回應與備份復原！萬豪案例裡「潛伏四年才被發現」的破口，正是明天要處理的問題。