授權管理（jedi-license-runtime ＋ 簽發站）

產品是賣授權的：客戶買了哪些功能、可以用到哪一天，靠一張授權檔決定。這套機制由兩端組成：

簽發站是一套獨立的系統——它有自己的程式、自己的資料庫，跟客戶手上的產品完全分開，而且簽授權用的那把私鑰就放在它手上。它不是這塊的一個小角落，本頁九條問題裡有五條就出在它身上。

---

檢視期間：2026-09-06（單日完成四輪）｜範圍：118 個檔案（驗證端 43、簽發站 75）｜共 4 輪

原始技術報告放在需求中心的 FR-076 站，檔名見下表最後一欄。那裡有每一輪的完整技術細節、檔案清單與逐條推理，供需要深究或稽核抽查時查閱。

四輪裡有兩輪、共 75 個檔查的是簽發站——它被查的份量比客戶端還重，本頁的發現也大半出自那裡（開通序號太短、序號遮罩失效、防猜機制失靈、登入跳轉沒檢查，以及公鑰清單那條連帶查出的打包守門壞掉）。

---

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

另外一條：不是資安問題，但要一起處理

---

先講背景：資料庫自己也有一道門禁

除了程式裡的權限檢查，資料庫自己還有一道門禁，規定「哪個客戶碰得到哪幾筆資料」。這是最後一道防線：就算程式那層漏了，這一道還擋得住。

這塊一共只有三張資料表——授權檔、授權異動紀錄、停權紀錄，就是全部了。這三張的門禁規則寫法一模一樣，而且方向是反的。

方向整個倒過來了。

但有一半是設計要的，不能改

「子單位看得到母公司的授權」這件事本身是對的，一定要保留。

因為授權的設計就是：照綁在最頂層的那個客戶身上，底下所有子單位共用這一張——子單位不另外發照。系統判斷「你買了沒」的第一步，就是把任何一個子單位換算成它頭上那個持照的客戶，再去讀那張照。

所以如果把方向改成跟其他表一樣（只看得到自己和底下），會發生什麼？每個子單位都查不到頭上那張照，被系統判成「沒買」，打任何功能都被擋掉。 功能當場壞掉。

真正的問題在「改」那一面

這三條規則不是只管「看得到什麼」，它同一條規則連「改得到什麼」「刪得到什麼」一起管，而且沒有另外加任何寫入限制——所以結論是：看得到，就改得到、刪得到。

實際會發生這三件事：

和第 1 條的關係：同一個洞被複製到新表上

本頁第 1 條寫的是「被停權的客戶換一張照就能解除停權」，狀態是已修——程式那一層確實修好了，換照不會再洗掉停權。

但資料庫這一層還開著一扇門，效果一模一樣：一樣是解除停權。

而且更要記住的是：那張停權紀錄表就是修第 1 條時新建的，一出生就帶著這條寫反的門禁規則（三張表的寫法一模一樣）——等於修一個洞的時候，順手把同一個洞複製到新表上了。

第 1 條的狀態仍然是「已修」（程式那層的修正確實完成且有效），但必須並列記住：資料庫那條路還在，已經併進跨模組那一批集中處理。

這也是這一條同樣評為高風險的原因——效果一樣，而且這條走的路更短、更難追：

同樣的結果評不同等級會讓人誤判，所以這一條與第 1 條同列高風險。

怎麼修（決策者已裁定）

「看」保持現狀，「改」和「刪」擋掉。

📎 跨頁對照：11 張表這件事由弱點檢測那塊起頭（那頁第 7 條）。那頁講的是「有 11 張寫反、要一起改」；本頁是唯一講清楚「方向寫反對授權會造成什麼實際後果、以及為什麼其中三張不能照那套改」的地方。 兩頁要一起看。

---

問題是什麼

我們把某個客戶停權（欠費、違約），系統就會把他的產品轉成唯讀——看得到但改不了。

停權這個狀態，原本是記在「那一張授權檔」上的。

而換授權檔的流程是「新增一張、取代舊的」——新的那一張上面，停權標記是空的。

所以整件事變成：

我們停權某個客戶
        ↓
客戶把自己手上那張舊授權檔重新上傳一次
        ↓
系統：「這是一張新的紀錄，停權標記空的」
        ↓
唯讀解除，客戶照常使用

不需要我們同意、不需要管理員、不需要任何特殊權限。 而且有四條路都會走到同一段程式，其中三條是客戶自己就能打的——那三條只要登入、不需要管理員身分，這是刻意的設計，因為開通授權的當下客戶通常還沒有管理員在場，要求管理員會把自己鎖在門外。

為什麼這是一個「設計層」的問題，不是寫錯

程式沒有任何一行寫錯。錯的是「停權這件事該記在哪裡」這個決定。

怎麼修好的

新增一張獨立的停權紀錄表：一列等於一個客戶目前處於停權狀態，解除就刪掉那一列。與授權檔完全脫鉤，換照動不到它。

舊的兩個欄位保留不刪——歷史資料上的值是「當初那一份被停權過」的稽核紀錄，執法只讀新表。

統籌者已開檔確認：新表與讀取邏輯都在，授權狀態查詢與管理後台兩條路都改成讀新表。

---

第 2 條：驗章之前的無上限解壓縮（高，已修）

問題：授權檔是壓縮過的，系統要先解開才能驗章。但解壓縮之前沒有任何上限——送一個「壓得極小、解開極大」的檔案（壓縮比可達千倍），程式會在驗章之前就把記憶體吃光。

關鍵在於順序：簽章簽的是解開後的原文，所以不能先驗章再解壓。唯一的解法是在解壓的過程中就設上限。

怎麼修好的：兩道上限——解碼之前先擋字串長度（連解碼都不做），解壓縮時設定上限並檢查有沒有超過。程式旁邊還寫明了「兩道都不可省、順序不可對調」的理由，這一點做得很好——下一個接手的人看到就知道不能省。

簽發站那一側有同源的一段解壓程式，但它沒有對外入口會收外部送進來的檔案，判定不構成問題。

第 3、4 條：開通序號太短、遮罩等於沒遮（高＋中，已修）

這兩條是同一件事的兩面：

• 序號只有 8 個字（約 43 億組），是簽發站唯一免登入入口的唯一憑證
• 而專門「把序號遮起來再寫紀錄」的那段程式，遮罩取的是前 8 碼——序號剛好 8 碼，等於整串印進紀錄

兩邊各自的假設都合理：寫紀錄那邊假設「前綴太短猜不出剩下的」，簽發那邊假設「夠亂就不必更長」。但沒有任何一處把兩個假設對起來看。

更麻煩的是——守門測試一直是綠燈，因為測試餵進去的假序號長度是 18 個字，剛好蓋不到這個問題。

怎麼修好的：序號改用約 128 位元的隨機值；遮罩那段程式改成純摘要、不留明文前綴。程式旁邊寫明了理由：「做摘要的那段程式本身不該依賴『呼叫的人剛好序號夠長』才安全」——這正確地把責任放回那段程式自己身上。

第 5 條：防猜機制用被猜的序號當鎖定對象（中，已修）

問題：線上開通入口原本有「同一組序號 15 分鐘內失敗 5 次就鎖定」的防猜機制。

但鎖定的對象是「被猜的那組序號」——猜錯一次就換下一組序號繼續猜，永遠不會被鎖。

連同另外兩個問題：計數用的那份暫存沒有上限，而且查詢的時候也會寫入——所以不用登入就能一直打、把伺服器記憶體撐爆。

最能說明問題的是這個對照：同一個專案的後台登入早就做對了（計數存資料庫、按來源位址計、程式旁邊還寫明了為什麼不能存在記憶體裡）。線上開通入口沒有套用那份現成的知識——是遺漏，不是不懂。

怎麼修好的：改成按來源位址鎖定、計數存進資料庫，而且順序改成先查鎖定再查序號（被鎖時連查都不查，猜的人也拿不到「這組序號存不存在」的線索）。取不到來源位址時一律歸到同一個計數槽——否則「取不到位址」就變成免費的無限次嘗試。

第 6 條：登入後的跳轉網址沒有檢查（中，已修）

問題：簽發站登入頁的網址後面可以掛一段「登入完把我送回哪裡」的指示，程式拿到之後完全不檢查就直接跳轉。

為什麼這在簽發站特別危險：誘騙簽發站管理員點一個連結、登入後被導到偽造的頁面，就可能把管理密碼交出去——而簽發站的管理員手上握著簽發私鑰。

怎麼修好的：加一段檢查程式，把跳轉目標收斂成站內相對路徑，擋掉外站與各種繞過寫法。

---

問題是什麼

驗章時用的公鑰是直接編進產品程式裡的，而且三個環境（開發／測試／展示）的公鑰全部並列在同一份清單裡。

驗章的方式是「照上面帶著一個代號，按代號去清單裡查對應的公鑰」——所以任何一個環境簽出來的授權檔，其他環境都會承認。

開發環境的私鑰簽出來的授權檔，正式環境照樣認。

為什麼裁定先不修

程式旁邊的說明寫明了這是刻意設計——為了支援日後換發新公鑰時不中斷服務（新版同時帶新舊兩把過渡）。設計本身沒錯，問題在於「過渡期間並列」與「三個不同環境並列」是兩件事，被同一個機制混在一起了。

---

問題：兩家客戶在極短的時間窗內同時匯入同一張授權檔，兩邊都會成功——因為檢查與寫入之間有一個空檔。

實際發生機率很低，所以評為低風險。

怎麼修好的：資料庫加一道「同一時刻每份授權只能有一份生效」的限制，由資料庫自己保證，不靠程式搶快。

---

---