工程師的大腦也需要 Error Budget

寫系統架構的時候，我們對「單點故障」超級敏感。多可用區、Circuit Breaker、Graceful Degradation，一個都不能少。結果排自己的讀書進度表時，卻很誠實地假設大腦是 100% 妥善率、沒有 Latency、更不會 Timeout。這禮拜複盤衝刺進度，發現這個雙標實在有點好笑。

後來想通一件事：Buffer Day 根本不是偷懶的藉口，而是把 SRE 那套「接受中斷必然發生」的思維，搬進讀書計畫裡。現代資安談的 營運韌性（Resilience，Assume Disruption） 核心精神也是這樣——不是幻想自己永遠不會被打斷、不會累、不會臨時加班，而是先承認中斷一定會發生，重點放在 核心任務不能停、其他部分可以優雅降級 。

排進度時硬塞好塞滿，一旦哪天感冒或臨時加班，整條進度就雪崩式延遲，跟系統沒做容錯設計、單一節點掛掉全站陣亡是一樣的道理。留一天 Buffer，就是幫大腦裝一個斷路器。

一 讀書
二 讀書
三 讀書
四 讀書
五 讀書
六 緩衝日
日 複盤

這張表控制在 9 欄以內，手機直屏不用橫滑就看得完整——這件事本身也是一種「優雅降級」的示範。

誰在客廳偷餅乾？誰在金庫改帳本？（XSS vs SQLi ＆ XSS vs MITM）

這組是我這輪複盤裡錯最多次的地雷。三個名詞： XSS、 SQL Injection、 MITM，考題最愛把它們兜在一起互相誘答。

先講清楚一個判斷基準： 看「誰在解析誰的程式碼」。

• XSS（Cross-Site Scripting）：攻擊者把惡意腳本塞進網頁內容，讓瀏覽器去解析、執行。它偷的是瀏覽器裡的同源權限（Origin）——想像成有人混進你家客廳，假冒成你家人翻你抽屜、拿走 Cookie 或 Session。發生地點是前端 DOM。
• SQL Injection：攻擊者把惡意語法塞進輸入欄位，讓 後端資料庫（DBMS） 去解析、執行查詢。這是直接摸進金庫改帳本，動的是伺服器端的資料查詢邏輯。

這兩個的共同點只有「都靠注入惡意內容」，但解析者不同、戰場不同，混為一談是最容易被誘答的地方。

再來是 XSS 不是 MITM 這個常被誤解的點。MITM（中間人攻擊）的定義是攻擊者站在 通訊鏈路的中間，攔截、竊聽甚至竄改雙方往來的封包——像是在電話線上裝竊聽器。但 XSS 的腳本是直接 執行在受害者瀏覽器裡，它不需要站在通訊路徑中間，而是騙瀏覽器「自己人」執行惡意程式碼。一個是路徑上的竊聽者，一個是混進系統內部的臥底，攻擊面完全不同。

⚠️ 看到題目同時出現「網頁」「資料庫」「攔截封包」三個關鍵字時，先問自己： 這段惡意程式碼最後是誰在跑？ 瀏覽器跑的是 XSS，資料庫跑的是 SQLi，路徑上被動攔截的才是 MITM。

存取控制三大門神，誰在什麼時候出場？（RBAC vs MAC vs ABAC）

存取控制模型這題，光靠死背定義很容易在考場上腦袋打結，我後來改用「保全比喻」記得比較牢：

• RBAC（角色型存取控制）：像傳統公司保全，看你的 職稱決定你能進哪些門——「經理」「工程師」「實習生」各自綁定一組權限。優點是好懂好管理，缺點是公司一大、角色一多，就會有「角色爆炸」問題——為了個別例外不斷開新角色，管理成本反而失控。
• MAC（強制型存取控制）：像軍事機構的門禁，每份文件、每個人都貼著固定的 安全標籤（機密、極機密），系統強制比對標籤等級才放行，連系統管理員自己都不能隨便更改規則。這是考題最愛的誘答點——很多人以為「強制」代表「嚴格的角色管理」，其實它強制的是 標籤比對邏輯，跟角色沒有直接關係。
• ABAC（屬性型存取控制）：像 AI 動態門禁，不看你是誰、不看固定標籤，而是 即時運算當下的屬性組合——你的部門、當下時間、裝置是否合規、所在地理位置，通通即時算一遍才決定放不放行。彈性最高，但也最複雜。

判斷口訣：RBAC 看你是誰（職稱）、MAC 看貼了什麼標籤（強制比對）、ABAC 看當下發生了什麼（動態運算）。這三個門神各司其職，出場時機不一樣，不是誰比誰更「進階」的線性關係。

簡訊 OTP 是怎麼在半路失守的？（SIM 劫持 vs 釣魚即時轉填）

「我有收到簡訊驗證碼欸，這樣應該很安全吧？」——這句話本身就是個資安陷阱。 收到簡訊，不等於這條路徑沒被攔截過。

拆成兩條完全不同的失守路徑會清楚很多：

路徑一：通訊層失守（SIM 劫持 / SIM Swap）
攻擊者靠社交工程或偽造證件，跑去電信櫃檯冒名申請 換卡，把受害者的門號轉移到自己手上的 SIM 卡。之後所有簡訊 OTP 都會送到攻擊者手機，受害者反而完全收不到。這一關失守發生在 電信商的身分驗證流程，跟你的網路行為習慣無關。

路徑二：應用層失守（即時釣魚轉填 / Real-time Phishing Relay）
攻擊者做一個一模一樣的假登入頁，受害者輸入帳密後，攻擊者 即時拿去真網站登入，順便觸發真的 OTP 簡訊。受害者收到「真的」驗證碼，填進假頁面，攻擊者立刻轉手拿去完成登入。這裡失守的不是簡訊本身，是 應用層這個傳話筒被攻擊者插了一手。

兩條路徑指向同一個結論：只要驗證碼是「人眼讀出來、手動輸入」，就有被中間轉手的空間。FIDO2 解決這個問題的關鍵在於 Origin 綁定——裝置產生的簽章跟發起請求的網域強制綁死，就算受害者被騙到假網站，簽章也對不上真網站的 Origin，釣魚頁面拿到的東西完全沒用。這不是「驗證碼更長更複雜」的量變，是「拿掉人工轉填這個環節」的質變。

3-2-1 備份的殘酷反差（連線同步被一鍋端 vs 拔掉網路線的真保險）

這段是這次複盤裡最想敲醒過去自己的部分：備份日誌顯示成功，不等於資料真的救得回來。

很多團隊的備份其實是「即時同步」——正式環境資料一變動，備份端幾乎同步跟著變。聽起來很安全，實際上勒索軟體攻進來的時候，加密行為會沿著這條同步線路雙向擴散，正式環境跟備份端幾乎同時淪陷，備份反而變成幫兇。這是備份「有做」跟備份「有用」之間最殘酷的落差。

真正頂用的防線靠兩件事：

• Air-Gap（離線隔離）：備份媒介實體上跟網路斷開，勒索軟體再厲害也伸不進一條沒連上的網路線。
• Immutable / WORM（不可變存儲，Write Once Read Many）：資料寫入後在指定期限內連系統管理員都無法竄改或刪除，從機制上杜絕「加密覆蓋舊備份」這條路。

另一個常被考的細節是還原順序陷阱：Full（全量）+ Incremental（增量）+ Differential（差異）三種備份混用時，還原順序點錯，資料可能對不上、甚至還原失敗。Incremental 要照時間序逐一還原到最後一份，Differential 只需要最新那份差異加上最近一次全量。順序記反，考場上跟救災現場一樣會出包。

⚠️ 備份策略只驗證「有沒有備份」，不代表 救不救得回來——定期做一次實際還原演練，才是真正確認防線活著的方法。

幕後花絮：跨平台雙軌體驗

寫這系列文章有個小堅持：HackMD 那份完整衝刺筆記，我保留了原生直式 Mermaid 圖，因為那邊的編輯器吃得下、看得順。但搬來 iThome 發布時，全部降階成這種緊湊的 ASCII / Unicode 文字框。

原因很單純：iThome 這邊不支援 Mermaid 語法，硬貼上去只會變成一堆看不懂的程式碼區塊。而且很多人是滑手機看鐵人賽文章，如果圖表寬度抓不好，直屏手機上左右橫滑找內容的體驗非常糟。所以這邊看到的每張示意圖，都控制在 20 欄以內的視覺寬度，就是為了讓大家不用轉手機、不用縮放，直接讀完。

雙軌不是為了炫技，是兩邊讀者的閱讀情境本來就不一樣。

今日帶走清單

• Buffer Day 是排程容錯設計，不是偷懶——核心進度不停，緩衝區負責吸收延遲
• XSS vs SQLi：看惡意程式碼最後在誰的環境被解析執行，瀏覽器 vs 資料庫
• XSS 不是 MITM：前者是混進系統內部的臥底，後者是站在通訊路徑上的竊聽者
• RBAC / MAC / ABAC：分別對應「看職稱」「比對強制標籤」「即時運算屬性」三種完全不同的門禁邏輯
• 簡訊 OTP 失守分通訊層（SIM 劫持）與應用層（即時釣魚轉填）兩條路徑，FIDO2 靠 Origin 綁定破局
• 3-2-1 備份要防的是「同步線路雙向加密」，真防線是 Air-Gap 與 Immutable 存儲，還原順序也別點錯

完整衝刺筆記（含原生 Mermaid 圖）都在這裡，歡迎收藏對照：
👉 https://hackmd.io/@lanss/Sy4ABY9dGl