---
title: 設備與資訊系統清冊
eyebrow: Guidant AI 資安檢視 · 模組報告
h1: 設備與資訊系統清冊（jedi-asset）
lede: 客戶有哪些機器、哪些系統——稽核工作指向的對象。這一塊沒有高風險問題，客戶資料隔離也做得比多數模組好；**唯一的重點是一個當初刻意做的產品決定：兩張清冊只要登入就看得到。這個決定已經裁定要推翻，後端要補上權限檢查——而補完會擋掉一個既有角色，修的時候必須一起處理，否則五個地方的下拉選單會安靜變空。**
---

## 這塊在產品裡做什麼

稽核要有對象。客戶說「我要稽核我的人事系統」「這台伺服器要做弱點掃描」，系統得先知道**客戶有哪些機器、哪些系統**——這一塊管的就是這兩張清冊。

::: grid2
::: {.card .plain}
#### 設備清冊
客戶有哪些機器、伺服器。每一筆記著主機名稱、網路位址、作業系統版本、製造商。
:::
::: {.card .plain}
#### 資訊系統清冊
客戶有哪些系統（人事、財務、客服…）。每一筆記著系統名稱、機密性／完整性／可用性等級、部署模式、授權邊界、系統負責人。
:::
:::

這兩張清冊**被別的模組引用**：稽核任務執行時會指向某台設備、某個系統；問卷會引用；合規文件的資源庫也會引用。所以它是一個交叉路口——別的模組會穿過這裡拿資料，畫面上多半以下拉選單的形式出現。**這一點在後面很重要：動到這兩張清冊的讀取權限，會連帶影響那些下拉選單。**

---

## 檢視軌跡

**檢視期間**：2026-09-16（兩輪同日），另 2026-09-23 補一輪｜**範圍**：60 個檔案（設備那半 14、資訊系統那半 15、兩半共用的骨架 27＋三支資料庫腳本，共用骨架兩輪都看）；另加主系統接線（與意見回饋並排查，共 8 個檔）｜**共 3 輪**

> **原始技術報告**放在需求中心的 [FR-098 站](https://guidantai-feature-doc.jedicotech.com/FR-098-2609-asset-security-scan/)，檔名見下表最後一欄。那裡有每一輪的完整技術細節、檔案清單與逐條推理，供需要深究或稽核抽查時查閱。

| 輪次 | 查什麼 | 檔數 | 覆核投票 | 結果 | 原始報告檔名 |
|---|---|---:|---|---|---|
| **A1** | 設備那半的完整路徑＋兩半共用的骨架與資料庫腳本 | 45 | 6 票全投完，**一條三票一致通過、一條三票一致駁回** | 通過 1 條（中） | `scan-A1-device` |
| **A2** | 資訊系統那半＋重疊帶入的共用骨架 | 42 | 9 票全投完，零漏投零中斷 | 通過 3 條，**去重後淨新增只有 1 條**（低） | `scan-A2-information-system` |
| **W6**（主系統接線，與另一塊並排查） | 我們主系統這一端怎麼把設備清冊與意見回饋兩塊接上來 | 8 | 6 票全投完 | **沒有找到新問題**——自動檢視報的兩條都是已登記的舊帳；執行者另查出一件「修好的模組還沒發版」（不是新問題，已記在修正排程裡）。設備清冊這一半的接線範圍內，這一輪沒有新發現 | `scan-W6`（在 [FR-115 站](https://guidantai-feature-doc.jedicotech.com/FR-115-2609-host-wiring-security-scan/)） |

兩輪掃的是**完全相同的程式版本**，兩輪之間這一塊零改動，所以兩份結果可以直接對照。

::: {.callout .warn}
**兩輪的覆核都完整跑完，但有一件事要講明：工具只咬住工作單列的重點的一小部分**

第一輪工作單列了六個重點，**工具只實質碰到一個半**；第二輪列了五個，**工具只碰到一個**。其餘全部是人工開檔與查資料庫補上的。

**所以這兩輪的結果，該怎麼讀**：
- **「報出來的這幾條是真的嗎」→ 可信。** 票全投完，統籌者逐條開檔核對過。
- **「是不是只有這幾條」→ 不可信。** 工具是快篩模式，涵蓋面靠人工補。
:::

::: {.callout .warn}
**第二輪執行者的四件收尾工作全部沒交，由統籌者補**

報告、程式碼提交、工單回寫、狀態更新——四件都沒做。**掃描本身是完整跑完的**（覆核章確認完整），沒交的是「掃完之後」那四件。這是全案第八次發生，如實記錄。
:::

---

## 問題一覽

**排序按風險。**「出事會怎樣」那欄講的是**業務影響**——誰受影響、損失什麼，不是技術現象。

| # | 問題 | 風險 | 分類 | 出事會怎樣（誰受影響） | 怎麼修 | 狀態 |
|---|---|---|---|---|---|---|
| **1** | 兩張清冊的「讀取」功能只檢查有沒有登入、不檢查權限——**而且程式碼裡寫明這是刻意的取捨** | 🟡 中 | 要先做產品決策 | **管理員以為自己收掉了某人的查看權限，其實沒有**。被刻意拿掉權限的帳號（例如約聘人員、外部顧問）只要把網址貼上就進得去，一樣拿得到該客戶完整的設備清冊（主機名稱、網路位址、作業系統版本）與資訊系統清冊（各系統的機密性等級、部署模式、授權邊界、負責人）——**等於把客戶內部網路的組成與整體安全態勢攤開**。跨客戶仍被擋住，外洩範圍在同一家客戶內 | **已修**：七支讀取功能（設備四支、資訊系統三支）各補上一道權限檢查，用的是同一支檔案裡寫入功能既有的那套機制，權限名稱沿用原本就存在的「查看設備」與「查看資訊系統」兩顆，沒有新造。沒有那顆權限的帳號會收到固定的拒絕代碼 GRC_403022（不是空清單） | ✅ **已修（FR-114.1-6）**——權限資料由 FR-114.1-9 先補齊（開發環境已套用；既有客戶要不要一起補仍未裁定），本卡補上七支讀取功能本身的權限檢查。⚠️ 客戶若有自建角色缺這兩顆權限，升級後那五處下拉選單會收到拒絕而不是空資料，前端提示另由 FE 小修卡補 |
| **2** | 只有「修改」權限的人，送一個「停用」欄位就等於做到了「刪除」 | ⚪ 低 | 只驗登入、不檢查歸屬 | **被刻意不給刪除權限的操作人員，可以讓任何一個資訊系統從所有選單與清單裡消失**，稽核專案就選不到它了。可還原（資料還在）、只在自己客戶內、而且畫面上根本沒有這個欄位（要直接呼叫後端才做得到） | **已修（兩個方向一起）**：① 從修改用的資料格式把「停用」欄位整個拿掉——停用只能走刪除功能（需要刪除權限）；② 修改時沒帶這個欄位就維持原值，不再套用程式預設值，已停用的系統不會被悄悄重新啟用 | ✅ **已修（FR-114.1-6）** |
| **3** | 清單一頁要顯示幾筆，沒有上限 | ⚪ 低 | 資源耗盡 | 任何登入帳號送一個很大的數字，就能叫資料庫一次把整張表撈出來 | **這一條的根源不在這一塊**，在所有模組共用的底層——全站清單都吃到。修一處全站生效。實際做法：每頁筆數加上限 1000 | ✅ **已修（CM-2065）** |

---

::: {.callout .plain}
**下面只展開需要你自己判斷、或容易被誤解的幾條。** 其餘的修法明確，看上面表格的「怎麼修」那一欄就夠了——**沒有展開不代表沒查，也不代表不重要。**
:::

## 第 1 條：這不是漏掉，是一個刻意的決定——現在已裁定推翻 {#decision}

### 問題是什麼

兩支清冊的程式碼長得很整齊：**新增、修改、刪除每一支都多一道權限檢查；讀取的那七支一支都沒有**（設備四支：清單、選單、明細、被引用查詢；資訊系統三支：選單、清單、明細）。

> **「九條」和「七支」這兩個數字不衝突**：本頁後面提到的「九條」算的是**網址條數**（設備五條、資訊系統四條），這裡的「七支」算的是**讀取動作的支數**。一條網址上可以掛查、改、刪三個動作，九條網址攤開共 13 個動作，其中七個是讀取。

一般遇到這種形狀，直覺是「漏掉了」。**但這一塊不是。**

程式碼裡有一份「這個模組需要哪些權限」的清單，清單旁邊寫著一句話——

> 讀取那兩項後端不守（守門只在寫入類），但**前端選單與資料庫裡的一張權限對照表**認，漏了會是「選單看不到這個頁面」。

**統籌者已開檔核對，那句話真的在**（本報告撰寫時再次核對，仍在）。換句話說：**當初有人知道、並且決定這樣做。**

::: {.callout .warn}
**「前端認」這句容易被讀成「前端有擋」——它沒有**

真正在認的是**資料庫裡的一張權限對照表**，加上後端依使用者持有的權限算出來的側邊選單；**前端只是把後端算好的結果畫出來**。這兩個資產頁的畫面本身沒有掛任何權限設定，前端只認「是不是管理員」這一個旗標。

**所以實際上會發生的是**：沒有那顆權限的人，**側邊選單看不到入口，但把網址直接貼上就進得去，頁面照樣把整張清冊撈出來**——那兩個頁面裡沒有任何一處在判權限。**不需要會寫程式，把網址複製給同事貼上就行。**

🔴 **驗收時請注意**：不要因為「前端會認」就放鬆後端那一關的驗收——**前端這一關實際上不存在**，唯一的防線只能做在後端。
:::

### 這個決定已經重新裁定：推翻，改成真的守

::: {.callout .decided}
**已裁定：採甲案——七支讀取功能後端補上權限檢查，權限點保留**

當初的取捨大概是這樣：清冊資料在同一家客戶內部本來就該大家看得到，加一道檢查反而讓稽核人員綁手綁腳。**這個邏輯在當時可能成立。**

推翻的理由是——**產品後台已經長出「查看設備」這顆權限開關了**，客戶管理員看到它，會合理地以為「關掉之後那個人就讀不到了」。實際上關掉只是讓選單消失，網址貼上去照樣看得到。**權限開關名不副實，這是會誤導客戶管理員的設計。**

當初列出來比較的兩條路，以及為什麼選了甲：

| 選項 | 做什麼 | 好處 | 代價 |
|---|---|---|---|
| **甲：改成真的守**<br>✅ **已採用** | 七支讀取功能各加一道權限檢查，用的是同一支檔案裡寫入功能已經在用的現成機制 | 權限開關名實相符，客戶管理員的認知與實際行為一致 | 要處理既有客戶的角色相容（見下一段），現在改比出貨後改便宜得多 |
| **乙：維持原決定** | 程式不改，但**文件必須寫明「這個權限只影響畫面選單、後端不擋」** | 零改動、零衝擊 | 等於長期維持一個名不副實的開關，客戶每看一次就誤解一次 |

**同一個方向也適用於弱點檢測那一塊（該頁第 8 條）——兩塊一併裁定採甲案。**
:::

### ⚠️ 修之前一定要先看：補上檢查會擋掉誰

補權限檢查**會擋掉人，而且症狀很難被發現**。這一段是修的時候必須一起做的事。

#### 會被擋到的是誰

兩顆讀取權限的持有狀況完全一致：**14 個角色裡有 13 個持有、1 個沒有**。唯一沒有的是某個客戶的「稽核人員」角色，該角色目前掛著 **1 個使用者**——全庫 41 個使用者裡，只有這 1 人會受影響。

**新裝的客戶踩不到**：出貨的初始資料只建一個管理員角色、八顆權限全給。**踩得到的是已經自訂過角色的既有客戶。**

#### 🔴 影響比表面大：這七支不只服務資產管理頁

它們同時是**別的功能的下拉選單資料來源**。實際查到的使用處有五個：

- **專案規劃頁**與**任務設定頁**（透過設備選單取資料）
- **合規文件的設備分頁**與**資訊系統分頁**
- **合規文件匯入時的資產挑選器**

#### 🔴 症狀是「安靜變空」，不是「跳錯誤」——這點最關鍵

逐一看過這些畫面呼叫後端的地方，**全部都是把錯誤接住、只寫進開發者主控台、然後把清單設成空的**。

> **使用者不會看到「你沒有權限」，只會看到一個空的下拉選單，並且以為公司根本沒建過設備資料。**

🔴 **驗收如果只測「資產管理頁打不打得開」，會完全測不到這個。**

#### 驗收清單（用沒有那顆權限的角色逐一確認）

用**沒有那顆權限的角色**登入，逐一打開下列五處，確認下拉選單**是否仍然有資料**：

1. 專案規劃頁
2. 任務設定頁
3. 合規文件的設備分頁
4. 合規文件的資訊系統分頁
5. 合規文件匯入的資產挑選器

**要保留這些功能，補檢查時必須同時把那顆權限補進「稽核人員」角色**；或者把那幾支「當選單用」的功能排除在守門之外。

⚠️ **別漏掉設備的「被引用查詢」**——就是刪除前顯示「將解除 N 筆關聯」那個。它也是讀取類、目前同樣沒有守門。按得到刪除鍵的人必然已經有刪除權限，所以替它補上讀取檢查沒有實際衝擊，**但漏掉就會變成「四支讀取只補了三支」的不對稱，日後沒人知道為什麼少一支。**

### 這件事不只發生在這一塊

**同一種形狀在另外兩塊也出現了**，建議三處一起裁決：

| 哪一塊 | 情況 |
|---|---|
| **這一塊**（設備與資訊系統） | 七支讀取功能，權限點宣告了但只在畫面生效 |
| **意見回饋** | 十顆權限點裡有五顆只有畫面在認，後端只檢查有沒有登入 |
| **弱點檢測** | 「讀取檢測規則」那顆權限同樣宣告了、後端八支讀取功能一支都沒掛 |

**三處的修法一模一樣，決定的邏輯也一樣**——分開裁三次只會得到三個可能不一致的答案。

**目前進度**：**這一塊**與**弱點檢測**都已裁定「後端補上檢查」；**意見回饋那一塊尚未裁定。**

---

## 第 2 條：兩條路通到同一個結果，卻各驗不同的權限

「刪除一個資訊系統」這個動作，系統實際做的事是**把那筆資料標記成「停用」**（資料列還在，只是從所有選單與清單消失）。

問題是，「修改」功能的資料格式**也開放了同一個「停用」欄位**，而且照單寫進資料庫。**所以兩條路通到完全相同的結果，一條要刪除權限，一條只要修改權限。**

目前實際上碰不到——**畫面上的修改頁根本沒有送這個欄位**，要直接呼叫後端才做得到。所以評為低風險。設備那半的修改格式沒有這個欄位，是另一回事。

### 反向也成立：修改權限還能把停用的系統悄悄開回來

後端存放資料的那份結構，**把這個欄位預設成「啟用」**；而修改流程的做法是「拿送進來的內容重建一份完整的資料，再整筆覆蓋回去」。兩件事湊在一起的結果是——

> **只有修改權限的人，送出一個不帶這個欄位的修改請求，就會把一個已經被停用的資訊系統悄悄重新啟用。**

也就是說，**「刪除」與「復原」兩個方向都能被修改權限繞過**，不是只有刪除那一邊。這讓這條比原本描述的**略重一些**，但**風險等級仍維持低**——理由不變：畫面上根本沒有這個欄位，要直接呼叫後端才做得到，而且只在自己客戶內、資料也還在。

**修的時候兩個方向要一起處理**，只堵住「被停用」不管「被啟用」，等於只修了一半。

**已核對現況**：修改用的資料格式仍然收這個欄位，資料存取層仍然照單寫入，刪除功能做的確實是同一件事。三處都沒有改過。

---

## 這塊的結論

::: {.callout .ok}
**一句話**：這一塊沒有高風險問題，**客戶資料隔離做得比先前幾塊都好**——兩張表都開了隔離、都有客戶歸屬欄位、規則齊全。真正的重點只有一個，而且它不是技術問題：**一個當初做過的產品決定，現在已經裁定推翻——兩張清冊的讀取要在後端真的擋。**

**建議一**：第 1 條與第 2 條**一起排**。第 1 條已裁定採甲案（後端補檢查、權限點保留），第 2 條本身很小，兩條動到的是同一塊程式，分兩次做只是多一輪測試。

**建議二**：🔴 **修第 1 條時，把「補權限會擋掉誰」那一段的五個驗收點逐一走過**。補上檢查會擋掉一個既有角色，而被擋到的症狀是**下拉選單安靜變空、不跳任何錯誤訊息**——只測資產管理頁打不打得開是驗不出來的。

**值得一提的正面發現（兩點）**：

1. 這一塊的守門機制是「吵鬧拒絕」型的——少了必要零件會直接拒絕啟動，錯誤訊息還寫明後果（「掛上去會讓九條清冊功能變成公開的」）。**這與另一塊「零件沒接上就靜默放行」的形狀正好相反，是正面案例。**
2. 客戶資料隔離**不只是有做，而且沒有踩到弱點檢測那一塊查出來的「比對方向寫反」那個坑**——這兩張表用的是產品**正規的那套路徑前綴比對**，不是那 11 張表採用的「把路徑切成編號清單再互相比對」寫法（那種寫法會讓方向反過來，變成子公司看得到母公司的資料）。
:::

| 統計 | |
|---|---|
| 檢視輪數 | 3 輪（模組本體 2 輪 60 個檔案＋主系統接線 1 輪，與意見回饋並排共 8 個檔，**沒有新發現**） |
| 通過的發現 | 4 條（去重後屬於這一塊的 2 條，另 1 條的根源在共用底層） |
| 最嚴重 | 0 條 |
| 高風險 | 0 條 |
| 已修 | 0 條 |
| 已裁定要修 | 2 條（第 1、2 條，一起排） |
| 已開工單 | 0 張（兩條都已裁定，工單待開） |

---

| 你想知道 | 看哪裡 |
|---|---|
| 我們用什麼方法查、結果有多可信 | [檢視方法與工具](GUIDE-01-method-and-tools.html) |
| 其他模組的檢視結果 | [回總報告首頁](index.html) |
