FR-114.5C-2 客戶端物件儲存密鑰不再回傳真值，連線改預設加密（SUMMARY #14 M02 側／#124，高／高）

本卡屬 FR-114 資安修正（母卡 CM-2019），第 5 批子集 C 卡 5C-2，修 SUMMARY #14 M02 側（M02-5，客戶端物件儲存密鑰外洩）與 #124（M02-11，儲存連線未加密）。#14 高，#124 高。計畫在 docs/features/FR-114-2609-security-fix-dispatch/batches/plan-b5C.md「卡 5C-2」段。#14 的 M22 側（總部管理層）由卡 5A-3 處理，兩張互相註明。

問題是什麼（白話）

#14（M02 側）：客戶自己設定的物件儲存（MinIO／SeaweedFS）連線密鑰，系統會把真實值原樣回傳給前端畫面，任何看得到這個設定頁或攔得到網路封包的人都能拿到密鑰。既有的兩份遮蔽名單都各自漏掉了這組儲存設定，證明「靠名單」這招已經失敗兩次。

#124：系統連線客戶端的物件儲存（MinIO／SeaweedFS）目前是不加密連線，內容與密鑰在客戶內網以明文傳輸。這不是「沒填就預設不加密」——現有 7 組設定全部都是明確設成不加密，改預設值對既有環境完全沒有效果。與 Google Drive 無關（Google 工具自帶加密、沒有開關）。

首腦核對：

app/upload_file/service/managed_file_upload_service.py:104-110 — MinIO 分支，secret_key=v.get('minio_secret_key', '') 明文讀出設定表的值
app/upload_file/service/managed_file_upload_service.py:119-125 — SeaweedFS 分支，同一組密鑰用 secret_key 與 minio_secret_key 兩個名字都收
app/upload_file/service/managed_file_upload_service.py:109/:124 — secure=v.get('secure', False)，MinIO／SeaweedFS 兩分支都預設不加密
scripts/installer/install.sh:1954/:2002/:2644 — 安裝腳本與出貨快照三處都明確寫 'secure', false
jedi-system-jedi-system-core/jedi_system_core/api/guards.py:94-124 — mask_secret_value，唯讀參考，本卡不動（卡 5A-3 的工作）
jedi-system-jedi-system-core/jedi_system_core/plugin/contract.py:61/:65 — DEFAULT_SECRET_MASKED_GROUPS 沒收 STORAGE_CONFIG、DEFAULT_SECRET_VALUE_KEYS 沒收 minio_secret_key/secret_key，唯讀參考，本卡不動

工作區

BE 側：在 /Users/chouraymond/Projects/Billows/Audit-Manager/compliance-manager-be/.claude/worktrees/wt-fix-security（branch fix/security-b1）改，不要碰主 checkout（掃描線正在讀它）。跑服務用 PORT=8001。本卡另涉 FE。
FE 卡：/Users/chouraymond/Projects/Billows/Audit-Manager/compliance-manager-fe/.claude/worktrees/wt-fix-security（branch fix/security-b1；不存在就 git worktree add .claude/worktrees/wt-fix-security -b fix/security-b1 開）。

在哪裡

app/upload_file/service/managed_file_upload_service.py:104-110    MinIO 分支，secret_key=v.get('minio_secret_key', '') 明文讀出，#14
app/upload_file/service/managed_file_upload_service.py:119-125    SeaweedFS 分支，同一密鑰用兩個名字都收，#14
app/upload_file/service/managed_file_upload_service.py:109    MinIO 分支 secure=v.get('secure', False)，#124
app/upload_file/service/managed_file_upload_service.py:124    SeaweedFS 分支同樣寫法，#124
src/views/storage-config/StorageConfigForm.vue:33    passwordHasChange ref，步驟②「是否真的改了密碼」判斷要用它
src/views/storage-config/StorageConfigForm.vue:131    minio_secret_key 驗證規則
src/views/storage-config/StorageConfigForm.vue:353,358    送出邏輯把 minio_secret_key 塞進一般 key 與加前綴 key 兩個欄位
src/views/storage-config/StorageConfigForm.vue:469-491    Password 元件與驗證訊息
scripts/installer/install.sh:1206-1207    讀 GUIDANT_S3_ACCESS_KEY／GUIDANT_S3_SECRET_KEY，步驟⑤盤點起點
scripts/installer/install.sh:1963    psql 變數注入，同上盤點
scripts/installer/install.sh:2607-2608,2640-2645    出貨快照行也寫入密鑰，步驟⑤盤點；:2644 是 'secure', false，#124
scripts/installer/install.sh:1954,2002    另兩處 'secure', false，#124
jedi-system-jedi-system-core/jedi_system_core/api/guards.py:94-124    mask_secret_value，唯讀參考不動（卡 5A-3 工作）
jedi-system-jedi-system-core/jedi_system_core/plugin/contract.py:61,65    DEFAULT_SECRET_MASKED_GROUPS／DEFAULT_SECRET_VALUE_KEYS，唯讀參考不動（卡 5A-3 工作）

怎麼修

D-b5C-3（既有 7 組設定要不要換成加密）決策者已裁照建議：開發期只動 DEV，STG／POC 等各環境明確放行；本卡只交付「怎麼切換與怎麼回滾」的文件，不自己動 STG／POC。

#14 修法（決策者原則：密碼類設定欄位預設一律不回傳真值給前端，只在真正需要時內部讀取真值——不是加進遮蔽清單，允許清單那招已經失敗兩次），五步驟順序不可調換（順序錯會把客戶密碼洗掉）：① 後端先加安全網——存檔時欄位留空要保留原值、絕不覆蓋成空（最先做，保護後面任何步驟出錯）；② 前端改成遮蔽顯示（••••••••），沒填就保留原值（若跳過直接做③，使用者改任何其他欄位存檔都會把密碼靜默清空）；③ 後端停止回傳真實密碼值；④ 加權限檢查前先確認有沒有背景工作在讀這組設定（匯入、排程任務、格式轉換工作常以系統身分執行）——沒查就加檢查，可能悄悄打壞且不報錯；⑤ 盤點這組密鑰還在哪些地方硬編碼（環境變數、其他服務設定檔、部署腳本），收斂成單一真相來源。明確不包含「密鑰輪替」——這組密鑰從未出貨給任何真實客戶（產品尚未出貨），沒有真正外洩過，盤點只當作「密鑰不該寫死在程式／腳本裡」的衛生問題處理，不當事故應變。
#124 修法：安裝時預設改成加密連線；既有環境的切換時機另外評估（要先確認兩端都支援加密，切換過程不會斷線）。