Guidant AI 資安檢視 · 模組報告
客戶有哪些機器、哪些系統——稽核工作指向的對象。這一塊沒有高風險問題，客戶資料隔離也做得比多數模組好；唯一的重點是一個當初刻意做的產品決定：兩張清冊只要登入就看得到。這個決定已經裁定要推翻，後端要補上權限檢查——而補完會擋掉一個既有角色，修的時候必須一起處理，否則五個地方的下拉選單會安靜變空。
稽核要有對象。客戶說「我要稽核我的人事系統」「這台伺服器要做弱點掃描」，系統得先知道客戶有哪些機器、哪些系統——這一塊管的就是這兩張清冊。
客戶有哪些機器、伺服器。每一筆記著主機名稱、網路位址、作業系統版本、製造商。
客戶有哪些系統（人事、財務、客服…）。每一筆記著系統名稱、機密性／完整性／可用性等級、部署模式、授權邊界、系統負責人。
這兩張清冊被別的模組引用：稽核任務執行時會指向某台設備、某個系統；問卷會引用；合規文件的資源庫也會引用。所以它是一個交叉路口——別的模組會穿過這裡拿資料，畫面上多半以下拉選單的形式出現。這一點在後面很重要：動到這兩張清冊的讀取權限，會連帶影響那些下拉選單。
檢視期間：2026-09-16（兩輪同日），另 2026-09-23 補一輪｜範圍：60 個檔案（設備那半 14、資訊系統那半 15、兩半共用的骨架 27＋三支資料庫腳本，共用骨架兩輪都看）；另加主系統接線（與意見回饋並排查，共 8 個檔）｜共 3 輪
原始技術報告放在需求中心的 FR-098 站，檔名見下表最後一欄。那裡有每一輪的完整技術細節、檔案清單與逐條推理，供需要深究或稽核抽查時查閱。
| 輪次 | 查什麼 | 檔數 | 覆核投票 | 結果 | 原始報告檔名 |
|---|---|---|---|---|---|
| A1 | 設備那半的完整路徑＋兩半共用的骨架與資料庫腳本 | 45 | 6 票全投完，一條三票一致通過、一條三票一致駁回 | 通過 1 條（中） | scan-A1-device |
| A2 | 資訊系統那半＋重疊帶入的共用骨架 | 42 | 9 票全投完，零漏投零中斷 | 通過 3 條，去重後淨新增只有 1 條（低） | scan-A2-information-system |
| W6（主系統接線，與另一塊並排查） | 我們主系統這一端怎麼把設備清冊與意見回饋兩塊接上來 | 8 | 6 票全投完 | 沒有找到新問題——自動檢視報的兩條都是已登記的舊帳；執行者另查出一件「修好的模組還沒發版」（不是新問題，已記在修正排程裡）。設備清冊這一半的接線範圍內，這一輪沒有新發現 | scan-W6（在 FR-115 站） |
兩輪掃的是完全相同的程式版本，兩輪之間這一塊零改動，所以兩份結果可以直接對照。
兩輪的覆核都完整跑完，但有一件事要講明：工具只咬住工作單列的重點的一小部分
第一輪工作單列了六個重點，工具只實質碰到一個半；第二輪列了五個，工具只碰到一個。其餘全部是人工開檔與查資料庫補上的。
所以這兩輪的結果，該怎麼讀：
第二輪執行者的四件收尾工作全部沒交，由統籌者補
報告、程式碼提交、工單回寫、狀態更新——四件都沒做。掃描本身是完整跑完的（覆核章確認完整），沒交的是「掃完之後」那四件。這是全案第八次發生，如實記錄。
排序按風險。「出事會怎樣」那欄講的是業務影響——誰受影響、損失什麼，不是技術現象。
| # | 問題 | 風險 | 分類 | 出事會怎樣（誰受影響） | 怎麼修 | 狀態 |
|---|---|---|---|---|---|---|
| 1 | 兩張清冊的「讀取」功能只檢查有沒有登入、不檢查權限——而且程式碼裡寫明這是刻意的取捨 | 🟡 中 | 要先做產品決策 | 管理員以為自己收掉了某人的查看權限，其實沒有。被刻意拿掉權限的帳號（例如約聘人員、外部顧問）只要把網址貼上就進得去，一樣拿得到該客戶完整的設備清冊（主機名稱、網路位址、作業系統版本）與資訊系統清冊（各系統的機密性等級、部署模式、授權邊界、負責人）——等於把客戶內部網路的組成與整體安全態勢攤開。跨客戶仍被擋住，外洩範圍在同一家客戶內 | 已修：七支讀取功能（設備四支、資訊系統三支）各補上一道權限檢查，用的是同一支檔案裡寫入功能既有的那套機制，權限名稱沿用原本就存在的「查看設備」與「查看資訊系統」兩顆，沒有新造。沒有那顆權限的帳號會收到固定的拒絕代碼 GRC_403022（不是空清單） | ✅ 已修（FR-114.1-6）——權限資料由 FR-114.1-9 先補齊（開發環境已套用；既有客戶要不要一起補仍未裁定），本卡補上七支讀取功能本身的權限檢查。⚠️ 客戶若有自建角色缺這兩顆權限，升級後那五處下拉選單會收到拒絕而不是空資料，前端提示另由 FE 小修卡補 |
| 2 | 只有「修改」權限的人，送一個「停用」欄位就等於做到了「刪除」 | ⚪ 低 | 只驗登入、不檢查歸屬 | 被刻意不給刪除權限的操作人員，可以讓任何一個資訊系統從所有選單與清單裡消失，稽核專案就選不到它了。可還原（資料還在）、只在自己客戶內、而且畫面上根本沒有這個欄位（要直接呼叫後端才做得到） | 已修（兩個方向一起）：① 從修改用的資料格式把「停用」欄位整個拿掉——停用只能走刪除功能（需要刪除權限）；② 修改時沒帶這個欄位就維持原值，不再套用程式預設值，已停用的系統不會被悄悄重新啟用 | ✅ 已修（FR-114.1-6） |
| 3 | 清單一頁要顯示幾筆，沒有上限 | ⚪ 低 | 資源耗盡 | 任何登入帳號送一個很大的數字，就能叫資料庫一次把整張表撈出來 | 這一條的根源不在這一塊，在所有模組共用的底層——全站清單都吃到。修一處全站生效。實際做法：每頁筆數加上限 1000 | ✅ 已修（CM-2065） |
下面只展開需要你自己判斷、或容易被誤解的幾條。 其餘的修法明確，看上面表格的「怎麼修」那一欄就夠了——沒有展開不代表沒查，也不代表不重要。
兩支清冊的程式碼長得很整齊：新增、修改、刪除每一支都多一道權限檢查；讀取的那七支一支都沒有（設備四支：清單、選單、明細、被引用查詢；資訊系統三支：選單、清單、明細）。
「九條」和「七支」這兩個數字不衝突：本頁後面提到的「九條」算的是網址條數（設備五條、資訊系統四條），這裡的「七支」算的是讀取動作的支數。一條網址上可以掛查、改、刪三個動作，九條網址攤開共 13 個動作，其中七個是讀取。
一般遇到這種形狀，直覺是「漏掉了」。但這一塊不是。
程式碼裡有一份「這個模組需要哪些權限」的清單，清單旁邊寫著一句話——
讀取那兩項後端不守（守門只在寫入類），但前端選單與資料庫裡的一張權限對照表認，漏了會是「選單看不到這個頁面」。
統籌者已開檔核對，那句話真的在（本報告撰寫時再次核對，仍在）。換句話說：當初有人知道、並且決定這樣做。
「前端認」這句容易被讀成「前端有擋」——它沒有
真正在認的是資料庫裡的一張權限對照表，加上後端依使用者持有的權限算出來的側邊選單；前端只是把後端算好的結果畫出來。這兩個資產頁的畫面本身沒有掛任何權限設定，前端只認「是不是管理員」這一個旗標。
所以實際上會發生的是：沒有那顆權限的人，側邊選單看不到入口，但把網址直接貼上就進得去，頁面照樣把整張清冊撈出來——那兩個頁面裡沒有任何一處在判權限。不需要會寫程式，把網址複製給同事貼上就行。
🔴 驗收時請注意：不要因為「前端會認」就放鬆後端那一關的驗收——前端這一關實際上不存在，唯一的防線只能做在後端。
已裁定：採甲案——七支讀取功能後端補上權限檢查，權限點保留
當初的取捨大概是這樣：清冊資料在同一家客戶內部本來就該大家看得到，加一道檢查反而讓稽核人員綁手綁腳。這個邏輯在當時可能成立。
推翻的理由是——產品後台已經長出「查看設備」這顆權限開關了，客戶管理員看到它，會合理地以為「關掉之後那個人就讀不到了」。實際上關掉只是讓選單消失，網址貼上去照樣看得到。權限開關名不副實，這是會誤導客戶管理員的設計。
當初列出來比較的兩條路，以及為什麼選了甲：
| 選項 | 做什麼 | 好處 | 代價 |
|---|---|---|---|
| 甲：改成真的守 ✅ 已採用 |
七支讀取功能各加一道權限檢查，用的是同一支檔案裡寫入功能已經在用的現成機制 | 權限開關名實相符，客戶管理員的認知與實際行為一致 | 要處理既有客戶的角色相容（見下一段），現在改比出貨後改便宜得多 |
| 乙：維持原決定 | 程式不改，但文件必須寫明「這個權限只影響畫面選單、後端不擋」 | 零改動、零衝擊 | 等於長期維持一個名不副實的開關，客戶每看一次就誤解一次 |
同一個方向也適用於弱點檢測那一塊（該頁第 8 條）——兩塊一併裁定採甲案。
補權限檢查會擋掉人，而且症狀很難被發現。這一段是修的時候必須一起做的事。
兩顆讀取權限的持有狀況完全一致：14 個角色裡有 13 個持有、1 個沒有。唯一沒有的是某個客戶的「稽核人員」角色，該角色目前掛著 1 個使用者——全庫 41 個使用者裡，只有這 1 人會受影響。
新裝的客戶踩不到：出貨的初始資料只建一個管理員角色、八顆權限全給。踩得到的是已經自訂過角色的既有客戶。
它們同時是別的功能的下拉選單資料來源。實際查到的使用處有五個：
逐一看過這些畫面呼叫後端的地方，全部都是把錯誤接住、只寫進開發者主控台、然後把清單設成空的。
使用者不會看到「你沒有權限」，只會看到一個空的下拉選單，並且以為公司根本沒建過設備資料。
🔴 驗收如果只測「資產管理頁打不打得開」，會完全測不到這個。
用沒有那顆權限的角色登入，逐一打開下列五處，確認下拉選單是否仍然有資料：
要保留這些功能，補檢查時必須同時把那顆權限補進「稽核人員」角色；或者把那幾支「當選單用」的功能排除在守門之外。
⚠️ 別漏掉設備的「被引用查詢」——就是刪除前顯示「將解除 N 筆關聯」那個。它也是讀取類、目前同樣沒有守門。按得到刪除鍵的人必然已經有刪除權限，所以替它補上讀取檢查沒有實際衝擊，但漏掉就會變成「四支讀取只補了三支」的不對稱，日後沒人知道為什麼少一支。
同一種形狀在另外兩塊也出現了，建議三處一起裁決：
| 哪一塊 | 情況 |
|---|---|
| 這一塊（設備與資訊系統） | 七支讀取功能，權限點宣告了但只在畫面生效 |
| 意見回饋 | 十顆權限點裡有五顆只有畫面在認，後端只檢查有沒有登入 |
| 弱點檢測 | 「讀取檢測規則」那顆權限同樣宣告了、後端八支讀取功能一支都沒掛 |
三處的修法一模一樣，決定的邏輯也一樣——分開裁三次只會得到三個可能不一致的答案。
目前進度：這一塊與弱點檢測都已裁定「後端補上檢查」；意見回饋那一塊尚未裁定。
「刪除一個資訊系統」這個動作，系統實際做的事是把那筆資料標記成「停用」（資料列還在，只是從所有選單與清單消失）。
問題是，「修改」功能的資料格式也開放了同一個「停用」欄位，而且照單寫進資料庫。所以兩條路通到完全相同的結果，一條要刪除權限，一條只要修改權限。
目前實際上碰不到——畫面上的修改頁根本沒有送這個欄位，要直接呼叫後端才做得到。所以評為低風險。設備那半的修改格式沒有這個欄位，是另一回事。
後端存放資料的那份結構，把這個欄位預設成「啟用」；而修改流程的做法是「拿送進來的內容重建一份完整的資料，再整筆覆蓋回去」。兩件事湊在一起的結果是——
只有修改權限的人，送出一個不帶這個欄位的修改請求，就會把一個已經被停用的資訊系統悄悄重新啟用。
也就是說，「刪除」與「復原」兩個方向都能被修改權限繞過，不是只有刪除那一邊。這讓這條比原本描述的略重一些，但風險等級仍維持低——理由不變：畫面上根本沒有這個欄位，要直接呼叫後端才做得到，而且只在自己客戶內、資料也還在。
修的時候兩個方向要一起處理，只堵住「被停用」不管「被啟用」，等於只修了一半。
已核對現況：修改用的資料格式仍然收這個欄位，資料存取層仍然照單寫入，刪除功能做的確實是同一件事。三處都沒有改過。
一句話：這一塊沒有高風險問題，客戶資料隔離做得比先前幾塊都好——兩張表都開了隔離、都有客戶歸屬欄位、規則齊全。真正的重點只有一個，而且它不是技術問題：一個當初做過的產品決定，現在已經裁定推翻——兩張清冊的讀取要在後端真的擋。
建議一：第 1 條與第 2 條一起排。第 1 條已裁定採甲案（後端補檢查、權限點保留），第 2 條本身很小，兩條動到的是同一塊程式，分兩次做只是多一輪測試。
建議二：🔴 修第 1 條時，把「補權限會擋掉誰」那一段的五個驗收點逐一走過。補上檢查會擋掉一個既有角色，而被擋到的症狀是下拉選單安靜變空、不跳任何錯誤訊息——只測資產管理頁打不打得開是驗不出來的。
值得一提的正面發現（兩點）：
| 統計 | |
|---|---|
| 檢視輪數 | 3 輪（模組本體 2 輪 60 個檔案＋主系統接線 1 輪，與意見回饋並排共 8 個檔，沒有新發現） |
| 通過的發現 | 4 條（去重後屬於這一塊的 2 條，另 1 條的根源在共用底層） |
| 最嚴重 | 0 條 |
| 高風險 | 0 條 |
| 已修 | 0 條 |
| 已裁定要修 | 2 條（第 1、2 條，一起排） |
| 已開工單 | 0 張（兩條都已裁定，工單待開） |