Guidant AI 資安檢視 · 模組報告
這塊存的不是客戶資料，是系統自己的鑰匙（寄信、員工帳號目錄、檔案儲存的伺服器帳密）與全站生效的總開關。風險形狀跟其他塊不同——別塊問的是「誰能看誰的資料」，這塊問的是「誰能改全公司的規則」。
產品裝好之後，總要有人告訴它：信要從哪台伺服器寄出去、員工帳號要去哪裡驗證、上傳的檔案要放進哪個儲存空間、密碼要多長才算合格、登入幾次失敗要鎖帳號。這些設定就放在這一塊。
畫面上它長得很平凡——幾頁設定表單，填一填按儲存。但填進去的內容有兩種，都很敏感。
這裡放的是鑰匙，不是資料。
一把寄信密碼外流，別人能用公司名義寄釣魚信；一把檔案儲存密碼外流，所有客戶上傳的檔案都在他手上。
而改設定是全站生效的總開關——改掉員工帳號目錄的位址，等於把全公司的登入驗證導去別人的機器。
檢視期間：2026-09-15｜範圍：82 個檔案（模組本體 57、接線 25）｜共 3 輪
原始技術報告放在需求中心的 FR-096 站，檔名見下表最後一欄。那裡有每一輪的完整技術細節、檔案清單與逐條推理，供需要深究或稽核抽查時查閱。
| 輪次 | 查什麼 | 檔數 | 覆核投票 | 結果 | 原始報告檔名 |
|---|---|---|---|---|---|
| P1 | 設定怎麼存、怎麼讀、誰能改——模組本體這一側 | 24 | 12 票全投完，否決一半 | 找到 2 條（1 高 1 低） | scan-P1-config-chain |
| H1 | 我們主系統這端怎麼把它接上來 | 25 | 6 票全投完，兩條都三票一致 | 工具報 2 條、其中 1 條是前一輪同一件事，真正新增 1 條高風險 | scan-H1-host-wiring |
| P2 | 系統選單的字典 | 33 | 3 票全投完，唯一一個疑點被三票一致否決 | 這一輪沒有找到問題 | scan-P2-menu-dictionary |
第一輪的否決率是一半，這件事值得講
工具提了四條，覆核把其中兩條打掉。否決理由具體到打開檔案指出「這個資料結構只有六個固定欄位，多送會直接報錯」。
願意否決，通過的那兩條才有份量。
三輪各有一處要誠實交代
三輪的實質結論都是靠統籌者逐條開檔核對＋連開發環境查資料庫補起來的。
第三輪「沒找到問題」，但有一件事記下來了
被否決的那條是「前台的下拉選單只過濾了『啟用』、沒過濾『公開』」。否決理由是：標成「私有」的資料一列都不存在，也沒有任何一條路會生出來。
統籌者從四個來源逐項復核（出貨預設資料 74 筆全部公開、欄位預設值三處都是公開、寫入端兩支都要平台管理員、開發環境實查 74 筆中私有 0 筆），同意否決。
但仍然記一筆：擋住它的是「現在沒有那種資料」，不是程式。 哪天平台管理員標了一列私有，那一列就會立刻出現在所有登入者的下拉選單裡。修法只要一行。
排序按風險，同風險的同一類排在一起。「出事會怎樣」那欄講的是業務影響——誰受影響、損失什麼，不是技術現象。
| # | 問題 | 風險 | 分類 | 出事會怎樣（誰受影響） | 怎麼修 | 狀態 |
|---|---|---|---|---|---|---|
| 1 | 一個客戶的管理員，可以改掉全公司所有人的登入規則，還能把登入驗證來源指到自己的機器上 | 🟠 高 | 只驗登入、不檢查歸屬 | 開一個新客戶就自動多一個能改全公司規則的人。他可以關掉全公司的雙因子驗證、讓帳號永遠不會鎖定（等於可以無限次猜密碼）、把登入憑證有效期從五分鐘延到一個月。更嚴重的另一半是把員工帳號目錄指到自己的機器——那是直接接管所有人的登入，而且改壞了看不出來 | 已拍板：只開放給客戶自己組織樹第一層（總部）的管理員改，子公司的管理員改不到；三支寫入路徑都要補上這個判斷。實際做法：新增租戶層級判斷，全公司共用的三組設定只開放總部管理員寫入，讀取不變 | ✅ 已修（CM-2054） |
| 2 | 任何登入帳號打一支查設定的功能，就拿到檔案儲存的帳號密碼明文 | 🟠 高 | 只驗登入、不檢查歸屬 | **不必是管理員、不必有任何權限、不必知道任何編號，一個請求就拿到可讀寫所有客戶上傳檔案的鑰匙。 拿到之後可以完全繞過我們的系統直連儲存空間——那時候程式裡補再多檢查都沒用。同一條路還會吐出寄信與員工帳號目錄的位址、埠號、登入帳號 | 讀取端比照同一支檔案裡的寫入端補上權限檢查，三個入口都要補、補一個沒有用** | ✅ 已修（CM-2063） |
| 4 | 第 1 條的修法裡「誰算總部」的判斷，擋得住自己公司的子公司，擋不住另一家不相干客戶的總部 | 🟠 高 | 客戶資料沒隔開 | 寄信設定、員工帳號目錄設定全站只有一份；客戶 B 的總部管理員照樣能改掉客戶 A、甚至原廠平台本身在用的寄信伺服器與帳號目錄——後果與第 1 條相同，只是換一種身分打進來。統籌者在開發環境用實際的公司路徑測過 | 決策者 09-26 裁定：落地版只有「安裝時建的那家客戶」算總部，SaaS 版只有原廠能改 | ✅ 已修（CM-2202，commit 6cfcb116e，1.21.0 出貨） |
| 3 | 密碼遮蓋名單漏掉檔案儲存那一組 | ⚪ 低 | 密碼外流 | 就算第 2 條補好了，有正當權限的客戶管理員打開「儲存設定」頁時，瀏覽器仍會收到那把共用密鑰的明文——任何看得到他瀏覽器流量、存檔或前端錯誤紀錄的人都拿得到 | 把儲存設定加進遮蓋名單、把帳密欄位名加進要遮蓋的清單，並改用寄信與員工帳號目錄那套「不回密碼、沒帶就沿用」的做法。實際做法：儲存設定的密鑰納入遮罩名單，並補上「沒帶就沿用原值」避免存檔抹掉密鑰 | ✅ 已修（CM-2054） |
讀取系統設定有三個入口，三個都只檢查「你有沒有登入」，完全不檢查權限。
這是漏掉、不是刻意：同一支檔案裡的新增、修改、刪除每一個都有權限檢查。檔案自己的說明文字也承認「讀取只要登入即可」。
隔離擋的是「看到別家客戶那一列」。可是——
每個客戶自己那一列裡，裝的是同一把鑰匙。 安裝時產生一組，之後每建一個新客戶就原封不動複製一份過去。
統籌者連開發環境實查（只比對雜湊值、沒有印出明文），確認不同客戶那幾列的密鑰完全相同——「複製給新客戶」從推測變成實證。（查的是開發環境裡我們自己建的測試客戶。）
開發環境有幾筆那一欄是空的，原因要講清楚
開發環境那七筆（全是我們自己建的測試客戶）裡，有幾筆密鑰欄位是空的。那不是因為沒複製，是因為負責複製的程式「失敗不擋建立」——開發環境沒有真的接上檔案儲存，它就靜靜跳過了。
只要儲存空間有正常設定好，那一欄就會有值。
| 要先有什麼 | 一個能登入的帳號。不必是管理員、不必有任何權限、不必知道任何編號 |
| 拿得到什麼 | 檔案儲存的位址、帳號、密碼明文；順帶還有寄信與員工帳號目錄的位址、埠號、帳號 |
| 最麻煩的地方 | 拿到之後可以完全繞過我們的系統，用標準工具直連儲存空間，把所有客戶的檔案列出、下載、覆蓋、刪除 |
本報告撰寫時開檔核對，模組本體那兩個入口與主系統那個入口都還是只驗登入。
| 步驟 | 做什麼 | 為什麼不能省 |
|---|---|---|
| 一 | 三個入口各補上按設定類別分流的權限檢查 | 只補一個沒有用，另外兩個照樣拿得到 |
| 二 | 補的時候沿用同一支檔案既有的「先擋權限、再回報找不到」順序 | 順序對調的話，沒權限的人可以用不存在的編號試探出「這筆存不存在」 |
| 三 | 第 3 條的遮蓋名單一起補 | 權限補好了明文照吐，只修一邊等於沒修乾淨 |
所需的權限項目已經存在，不必新建——這是接線，不是造新東西。
「密碼一律不回傳前端」那條原則，解決不了這一條
檔案上傳那塊已經拍板一條全站原則：設定類的密碼欄位預設一律不回傳給前端。很容易以為套了這條，這裡就沒事了——不是的。
所以這一條的修法不變：三個入口都要補上權限檢查。 兩條要各修各的，不能互相取代。
系統本來有一道「回傳設定前先把密碼欄位刪掉」的遮蓋機制，靠兩份名單決定要遮什麼。兩份都漏掉檔案儲存：類別名單只有寄信、第三方登入、通知、問題單整合四組；要遮的欄位名只寫了兩個，不包含檔案儲存實際使用的那兩個欄位名（本報告撰寫時連開發環境確認，實際欄位名確實不在名單裡）。
寄信與員工帳號目錄是怎麼做的：密碼從來不回傳，前端要表示「密碼沒改」就送一個旗標、後端沿用舊的。儲存設定沒有跟上這套做法。
這條正好是「標記制優於名單制」的實證
檔案上傳那塊拍板的原則是：預設全部遮住，明確標記「這個欄位可以公開」的才回傳——而不是維護一份「哪些要遮」的名單。這一條就是名單制出事的實例：兩份名單（哪幾類設定要遮、哪些欄位名要遮）都漏掉了檔案儲存這一組，而寄信與員工帳號目錄兩組剛好都有登記、所以沒事。
兩種做法漏掉時的後果差很多：名單制漏登記 ＝ 密碼直接外洩；標記制漏標記 ＝ 頂多前端少看到一個欄位。 這就是那條原則該套用到全站的理由。
⚠️ 這是有意識的契約變更、不是單純補漏——名單上方的說明文字明寫「凍結」，動它之前要確認沒有別的地方依賴現在這份名單。記得同步改測試，模組測試裡有一條把現在這份名單釘死了。
「客戶層級的權限，改到的卻是全系統共用的那一份」——這個形狀在日誌那塊也出現了一次。
日誌那塊的情況是：「修改日誌要送去哪台伺服器」這個權限同樣被標成客戶層級、同樣每開新客戶就自動發下去，而寫入時把客戶欄位寫死成空值——等於一個客戶的管理員可以把全公司的日誌改送到他自己的機器。
兩條是同一種病的兩個實例。這代表它不是單一事件，是一種會重複發生的設計模式——把某個設定當成「客戶自己的事」而發出權限，但那份設定實際上全系統只有一份。
已拍板：日誌那塊的這一條，與本頁第 1 條當成同一件事處理、套用同一條規則——一樣只開放給客戶組織樹第一層（總部）的管理員改。
建議：修的時候兩條一起修，並且回頭檢查還有沒有第三個、第四個——判準是「這個權限是客戶層級的嗎？它寫入的那份設定，全系統有幾份？」
一句話：這塊找到四條，數量不多，但它們碰到的是系統自己的鑰匙與全站總開關——一把儲存密碼外流，所有客戶上傳的檔案都不保；一次登入驗證來源被掉包，所有人的登入都被接管。
建議：
| 統計 | |
|---|---|
| 檢視輪數 | 3 輪、82 個檔案 |
| 找到的問題 | 4 條（第 4 條是主系統掃描查出的，出在第 1 條的修法本身） |
| 高風險 | 3 條 |
| 已修 | 4 條（1.21.0 出貨） |
| 未修 | 0 條 |
| 已開工單 | CM-2054、CM-2063、CM-2202 |