當大家都滿分的時候，
你還可以做什麼？
為什麼現在很紅：兩個購物網站的 Lighthouse 都是 100 分，結帳都順。差別只會在第一個零件壞掉的那一刻出現：一個只是結帳變慢，另一個整站打不開。
- 一句話結論
- 網站能用、SEO 滿分、訂單下得了，是現在的及格線，不是終點。當大家都滿分，分數就分不出誰比較耐打。
- 他要的是什麼
- 攻擊者不挑分數最低的網站，他挑一個零件就能牽動全站的網站。一個外掛的漏洞、一把共用的金鑰，在零件彼此綁死的網站上，就是整個網站的鑰匙。
- 你今天做一件事
- 今天把結帳流程依賴的每一個第三方服務和每一把金鑰列出來，各問一句：「這個壞掉或外洩時，影響的是一個功能，還是整個網站？」 直接去做 →
- 哪些能信
- 3 可證明3 推論1 缺口 每個主張都標了等級，缺口是誠實寫出來的。
- 破口速查
- 受害端一律去識別化；寫「未公開」代表公開資料查不到。
- 伺服器服務商
- 不適用：本篇是方法論文章，不對應單一主機或服務商
- 網路服務商
- 不適用
- 漏洞出現的地方
- 架構層：網站只以「能用、分數滿、訂單能下」驗收，多個功能共用同一台主機、同一個資料庫帳號、同一把金鑰、同一個第三方服務，沒有各自的上限與退路；一個零件出事就連鎖擴散到整站
- 馬上自我檢測
列出結帳流程依賴的每一個第三方服務與每一把金鑰 確認前台、後台、排程是不是共用同一個資料庫帳號 在瀏覽器開發者工具封鎖一個第三方網域，看頁面還能不能用- 漏洞修補方式
- 驗收時除了功能與分數，再加一題「這個零件壞掉時會影響誰」：每個服務各自一把金鑰與一組資料庫帳號、第三方呼叫設逾時與退路、API 金鑰設用量上限、前台快取能在源站出問題時撐住、管理後台與前台分開
有 15 分鐘再看：其餘 2 點
- 我們 2008 年的論文研究資源受限的專案排程，主張計畫要考慮穩健性：偏好寬裕彼此獨立的排法，讓一件事延誤時不會拖垮整個專案。在 720 組標準測試題上，這個做法全部優於只追求工期的傳統法則。
- 網站也是一群共用有限資源的零件。穩健的網站讓每個零件有自己的上限與退路：金鑰、資料庫帳號、第三方服務各自隔開，一個壞掉只影響一個功能，不會整站一起倒。
網站能用、SEO 滿分、訂單下得了，這些現在多數團隊都做得到。2008 年我們在《輔仁管理評論》發表一篇專案排程論文，講的是穩健性（robustness）：計畫在紙上都準時，為什麼現實中還是延誤。十八年後回頭看，同一個觀念放在網站上一樣成立：當每個網站都拿到滿分，能分出高下的，是某一個零件壞掉那天，整個網站會不會一起倒。
本篇目錄
兩個都是滿分的網站
週五下午，兩個購物網站同時上線。兩個都跑過 Lighthouse，效能、SEO、無障礙都是 100 分；兩個都測過結帳，從加入購物車到付款完成一路順暢。如果驗收只看「能不能用、分數滿不滿、訂單下不下得了」，兩個都是滿分。
到了週六晚上，兩個網站用的同一家物流查詢 API 開始逾時。第一個網站只有訂單頁的物流狀態顯示「稍後再試」，其他照常；第二個網站每一頁都在等那個 API，連線一條條卡住，十分鐘後首頁也打不開了。再過一週，第二個網站的一個外掛被公開漏洞，攻擊者從那裡讀到設定檔，裡面那一把資料庫帳號，前台、後台、排程全都在用。
兩個網站在分數上沒有差別，差別只在出事的那一刻才看得到。它有一個名字，叫穩健性（robustness）。這個詞我們十八年前在一篇排程論文裡用過，先從那裡講起。
本篇沒有實際外洩的憑證；下表是開頭第二個網站的示意情境，用來說明一把共用的鑰匙會把影響範圍放多大。
| 服務 | 憑證類型 | 用途 | 存在形式 | 放在哪 | 權限範圍 | 狀態 |
|---|---|---|---|---|---|---|
| 網站的 MySQL 資料庫（示意） | 資料庫帳號與密碼 | 前台、管理後台、每晚排程共用同一組帳號連資料庫 | 明文寫在外掛可讀到的設定檔 | 網站主機的設定檔 | 整個資料庫的讀寫與管理權限 | 示意情境，非實際事件；本篇建議拆成每個服務各一組、只給需要的權限 |
同樣一把被讀走，如果它只屬於排程、只能讀一張表，事情就停在那張表。
一篇 2008 年的排程論文
先交代來源。2008 年 9 月，我們在《輔仁管理評論》第 15 卷第 3 期發表〈考慮資源限制與穩健性之專案排程研究〉（黃榮華、楊長林、劉士豪），本站作者是共同作者之一。這篇不是資安論文，也不是網站論文，研究的是工業工程裡一個很經典的問題：資源受限專案排程（RCPSP，resource-constrained project scheduling problem）。
問題長這樣：一個專案有幾十到上百件作業，有些必須先做完才能做下一件，有些可以同時進行；每件作業要用掉一些資源（人力、機台），而資源總量有上限。目標是排出一份最快完工的計畫。
傳統做法只追求一件事：工期最短。論文要指出的是，這樣排出來的計畫在紙上很漂亮，但現實中作業時間常常因為無法控制的因素而變長，計畫一延誤，承諾的完工日就守不住。所以我們把穩健性放進目標：不只問「最快多久做完」，也問「有作業延誤時，這份計畫還守不守得住」。
寬裕時間要彼此獨立
到這裡，其實已經足夠理解這篇的主張：計畫要比的不只是快，還有耐不耐摔。如果你關心的是怎麼套用到自己的網站，可以直接往「網站也是資源受限的系統」繼續閱讀。下面這一節講論文怎麼做，會稍微技術一些。
論文的核心觀念是寬裕時間（slack），也就是一件作業最多可以晚多久，而不影響整個專案完工。兩份工期相同的計畫，寬裕時間的分布可能完全不同。如果好幾件平行作業共用同一段寬裕，一件延誤吃掉了它，其他作業就沒有寬裕可用；如果每件作業的寬裕各自獨立，一件延誤只會用掉它自己那一份。
所以論文偏好寬裕時間比較獨立的排法。做法上，非平行作業與平行作業分開處理排序，平行作業的先後次序是動態決定的，並評估同一群平行作業裡每件作業的寬裕時間。目標函數同時看兩件事：工期，以及延誤發生時要付出的額外成本。
深入閱讀方法與測試設計（論文摘要所列）
求解分兩段。先用 ACTIM（activity time，一種依作業在路徑上的時間位置決定優先次序的傳統法則）排出初始解；遇到平行作業爭用資源的時候，再用禁忌搜尋法（tabu search）找更好的排法。禁忌搜尋是一種會記住最近試過哪些方向、避免繞回原地的啟發式搜尋。
測試資料取自國際通用的排程題庫 PSPLIB，涵蓋 30、60、90、120 件作業四種規模，資源上限分 10 與 15 單位兩種，作業時間增幅分三種，合計 720 組樣本。
結果很一致：同時考慮穩健性的方法，在全部 720 組題目上都比只用傳統法則好。不是某幾題好、某幾題差，是全部。
網站也是資源受限的系統
論文研究的是工廠與工程專案，但把名詞換一換，一個網站就是同一個問題。
一個購物網站是一群零件：前台頁面、會員登入、購物車、金流、物流查詢、寄信、管理後台、每晚的排程。它們共用有限的資源：一台主機的 CPU 與記憶體、資料庫的連線數、一把雲端金鑰、一家第三方服務的額度。排程論文裡的「作業時間變長」，在網站上就是第三方服務逾時、流量突然暴增、一個外掛爆出漏洞、一把金鑰外洩。
只追求「能用」的網站，最常見的寫法是讓所有零件共用同一份餘裕：同一個資料庫帳號、同一把金鑰、同一個連線池、沒有逾時設定的第三方呼叫。平常這很省事，分數也不會扣。但它的餘裕是共用的，就像論文裡集中在最後的寬裕時間：一個零件出事吃掉了它，其他零件就跟著沒有退路。
穩健的寫法看起來沒那麼漂亮，驗收清單也比較長：
- 每個服務各自一把金鑰、一組資料庫帳號，權限只給它需要的。一把外洩，損失只有那一個服務。
- 每一個第三方呼叫都設逾時，並想好壞掉時頁面要顯示什麼。物流查詢掛了，結帳照樣能完成。
- AI、簡訊、寄信這類按量計費的金鑰設用量上限。被盜用時，帳單有天花板。
- 前台有快取，源站出問題時還能撐住瀏覽；管理後台和前台分開，後台不對外公開。
- 能接觸正式環境的人不只一位，但每個人只拿到自己那一段的權限。
這些做完，Lighthouse 不會多一分，SEO 也不會多一分。它們改變的是另一個分數：第一個零件壞掉時，壞掉的範圍有多大。
滿分之後，還可以比什麼
回到標題。現在要做出一個「能用、SEO 滿分、訂單下得了」的網站，門檻比十年前低很多：架站平台、範本、AI 寫程式，多數團隊認真做都能拿到滿分。
問題是，當大家都滿分，這個分數就分不出誰比較耐打了。真正能分出高下的，是網站在現實裡第一次被打亂的時候：第三方服務逾時、雙十一流量、外掛被公開漏洞、一把金鑰被貼到公開的地方。那一刻，一個網站是只壞一個功能，還是整站一起倒、所有資料一起被讀走，就是穩健性。
對資安來說，這個差別更大。攻擊者不挑分數最低的網站，他挑一個零件就能牽動全站的網站。功能與分數是讓客人進得來；穩健性是讓一個零件壞掉時，壞的只有那一個零件。
所以我們的建議是在每一次上線驗收時多問一題。不只問「這個功能能不能用」，也問「這個零件壞掉或外洩時，影響的是誰」。寫得出這張表，你就知道網站的脆弱點在哪；寫不出來，代表那個滿分只量到了好天氣。
這篇提到的項目要花多少錢
讓網站變穩健，多數成本是一次性的盤點與拆分人力；能比較的是「沒有隔開時，一個零件出事會拖垮多少東西」。
| 項目 | 用量 | 單價 | 期間 | US$ | NT$ | 舉證 |
|---|---|---|---|---|---|---|
| 盤點結帳流程的第三方依賴與金鑰，寫成「壞掉影響誰」表 估：取中間值 NT$27,500 的半天 | 約 0.5 人日 | 顧問日費 NT$20,000–35,000（估） | 一次性，之後每次上線更新 | 429.69 | 13,750 | 本站假設值 |
| 拆分資料庫帳號與金鑰、為第三方呼叫加逾時與退路 估：小型購物網站、5 個以內的外部服務；多數雲端與 AI 供應商的用量上限設定免費 | 約 2 人日 | 顧問日費 NT$20,000–35,000（估） | 一次性 | 1718.75 | 55,000 | 本站假設值 |
| 示意情境：零件綁死的網站整站停擺與資料被讀走的損失 示意，非實際事件；停擺營收、資料外洩通報與輪替人力都取決於網站規模，無法事先估 | — | — | 單次事件 | — | — | 無 |
| 合計（僅可證明列） | 0.00 | 0 | ||||
兩天半的人力，換的是最後一格的範圍從「整個網站」縮成「一個功能」。
你可以學到什麼
站在攻擊者的位置看：一個外掛的漏洞、一把共用的金鑰，在零件彼此綁死的網站上，就是整個網站的鑰匙。他不需要打穿每一道防線，只需要找到那個牽一髮動全身的零件。
- 01網站能用、SEO 滿分、訂單下得了是及格線，不是終點；當大家都滿分，分數就分不出誰比較耐打。
- 02兩份工期相同的計畫，寬裕時間的分布可能完全不同；寬裕彼此獨立的計畫，一件延誤只會慢一件。網站的餘裕也一樣，要各自獨立。
- 03每個服務各自一把金鑰、一組資料庫帳號，一把外洩只損失一個服務。
- 04每一個第三方呼叫都要有逾時與退路，按量計費的金鑰都要有用量上限。
- 05上線驗收多問一題「這個零件壞掉或外洩時影響誰」；寫不出答案，那個滿分只量到了好天氣。
- 01穩健性（robustness）本篇的主題：零件出事時，系統還守不守得住它的承諾。
- 02爆炸半徑（blast radius）一個零件壞掉或外洩時，影響範圍有多大；穩健性就是在縮小它。
- 03故障隔離（fault isolation）讓一個零件的問題停在它自己那裡，等同論文的寬裕獨立。
- 04寬裕時間（slack）論文的核心：一件作業最多可以晚多久；網站上的對應是每個零件自己的餘裕。
- 05優雅降級（graceful degradation）第三方壞掉時，頁面只少一個功能，不是整頁打不開。
- 06逾時（timeout）沒有逾時的第三方呼叫，會把自己的故障變成你的故障。
- 07最小權限（least privilege）每個服務只拿到需要的權限，外洩時損失才有邊界。
- 08用量上限（spend limit）按量計費的金鑰被盜用時，帳單有天花板。
- 09RCPSP資源受限專案排程問題；論文研究的問題，也是網站共用資源的形狀。
- 10PSPLIB國際通用的排程題庫；論文 720 組測試的來源，讓結果可以和其他研究比較。
下面四步全部唯讀，做完你會有一張「這個零件壞掉影響誰」的表。
全部唯讀，不改任何設定；做完你會知道自己有沒有同樣的破口。
- 列出結帳流程依賴的每一個第三方服務（金流、物流、簡訊、寄信、分析、客服外掛）看到什麼代表什麼：超過三個卻說不出各自壞掉時頁面會怎樣，代表結帳的穩健性沒有被驗收過。
- 在每一個服務與每一把金鑰旁邊寫上「壞掉或外洩時影響誰」看到什麼代表什麼：答案是「整個網站」的那幾列，就是第一批要拆開的。這張表我們叫「slack-map-r6w」，下一次上線驗收前先開它。
- 確認前台、管理後台、排程是不是共用同一個資料庫帳號
mysql -e "SELECT user, host FROM mysql.user;"看到什麼代表什麼：只有一兩個帳號、而且有管理權，代表任一個零件被打穿，資料庫就整個在對方手上。 - 在瀏覽器開發者工具的 Network 分頁封鎖一個第三方網域（例如物流或客服外掛），重新整理結帳頁看到什麼代表什麼：頁面還能完成下單，代表有退路；整頁卡住或空白，那個第三方的故障就是你的故障。
環境背景、時間線、攻擊鏈對照 ATT&CK、關鍵證據、根因、處置與檢討都在完整版，約 8 分鐘。
來源
- 黃榮華、楊長林、劉士豪（2008）。考慮資源限制與穩健性之專案排程研究。輔仁管理評論，15(3)，1–33。DOI 10.29698/FJMR.200809.0001
- PSPLIB：Project Scheduling Problem Library（論文測試資料來源）
本文為公開報導與官方公告的整理與拆解，非第一手鑑識；證據等級依來源可信度標註。
本文由 AI 團隊協助研究與撰寫，經隱私與事實檢查後發布；證據等級依來源可信度標註。
複製下面這段，貼給你在用的 AI 工具（Claude Code、Cursor、Copilot、ChatGPT 都可以）。它會用本篇的破口位置、自我檢測與學習重點，對你的專案或環境做一次資安掃描，列出潛在問題與建議的調整或加強方式。
預設是唯讀：只發現問題、提出建議，不會改你任何檔案或設定。
M3 對外攻擊面 · M8 結業盤點 · 想在自己的環境做一次同樣的盤點，從 自我盤點 開始。
每篇新文章一封：三點摘要、關鍵字定義、今天能做的一件事。或先 加入會員 記錄你完成的任務。