本卡屬 FR-098（母卡見子卡清單），第 2 棒：資訊系統全鏈（jedi-asset 套件）。只掃不修。在 A1 驗收完成之後才派。

這一棒在做什麼（白話）

「資訊系統」是客戶的系統清冊——有哪些系統（人事系統、財務系統、客服系統），各自歸誰負責、風險等級多高。合規文件（系統安全計畫）會引用這張清冊，稽核時要對照它。

這一棒掃資訊系統那半的完整路徑（15 個檔案）＋ 共用骨架重疊帶入（27 個檔案），共 42 檔。

要回答的核心問題：誰看得到、誰改得動別家客戶的系統清冊。

為什麼切這一塊

與第 1 棒的風險形狀相近但資料不同：設備是機器，資訊系統是業務系統的清單與風險評級，外洩等於把客戶的系統架構與弱點盤點交出去。而且這張清冊被合規文件引用（主專案的資源庫會查它），是跨模組的接縫。

⚠️ 共用骨架與第 1 棒重疊是刻意的——切在接縫上兩棒都看不到全貌。重複報由首腦驗收時挑掉，接縫沒人看才是真的損失。

重點看什麼

• 🔴 ① 讀取類端點全部沒有權限檢查，寫入類每一個都有。 首腦開檔核對 jedi_asset/api/routes/information_system_route.py：選單（:42）、清單（:59）、明細（:102）只掛 @auth_required；新增（:82）、修改（:114）、刪除（:135）都多掛 @capability_required。與第 1 棒的設備那半、以及 FR-096 第 72 項完全同形。要追：這三支讀取端點回什麼、明細端點吃的是編號（uid）——猜得到別人的編號就讀得到嗎。
• ② 這張表開了「強制隔離」，第 1 棒那張沒有——差別是什麼。 首腦實查：資訊系統表 FORCE ROW LEVEL SECURITY 是開的（連表的擁有者都擋），設備表只開一般模式。腳本檔頭說明強制模式是 CM-1678 補的，起因是「開發環境這張表的擁有者正好是應用程式連線帳號本人，只開一般模式等於沒開——實測擋全部的規則仍讀得到全部 83 筆」。要追：這個修補有沒有留下副作用、以及第 1 棒那張表現在是不是正處於檔頭描述的那個「等於沒開」的狀態（本棒若查出來，請寫進報告並標明它其實屬第 1 棒範圍）。
• ③ 新增規則刻意不抄設備那半的部門維度。 腳本檔頭明寫：資訊系統的新增規則刻意不加部門條件，理由是「部門判定函式收到空值會回否，而部門欄位可為空、確實有部門為空的使用者，抄過來會讓那些人新增時被擋且無逃生門」。要追：少了部門維度之後，新增的範圍是不是變得比讀取寬——有沒有辦法新增到不屬於自己部門的資料。
• ④ 合規文件那條引用路徑。 主專案 app/oscal/service/ssp_resources_context_service.py:148 會 import 資訊系統的查詢物件。要追：那條路徑讀資訊系統時走不走同一套隔離與權限（該檔屬主專案、不在本棒範圍，但若在套件這側看到「給外部呼叫用、不檢查權限」的方法，請標明並指出呼叫者）。
• ⑤ 送空條件會不會回整張表（同第 1 棒重點②）。若命中請標明歸跨 arc 總表第 70 項那條線，不要當獨立發現升級。

🔴 已經查證過的，掃到不要重報

• 兩張表的資料庫隔離都有開、都有客戶歸屬欄位（開發環境實查：資訊系統表開了隔離且是強制模式、四條規則、91 筆資料）。這支的隔離做得比先前幾支好，不要沿用「資料庫層全空」的預期。
• 八個權限點全部是客戶層級，這是正確的——資產清冊本來就該由客戶自己管，不要報成「權限層級標錯」。
• 設備那半（14 檔）不在本棒範圍，屬第 1 棒。共用骨架雖然重疊帶入，但若發現只跟設備有關，請標明「屬第 1 棒範圍」。

怎麼做

第一步：驗 scope 檔數，對上 42 才啟動：