U5 檢查結果：雲端硬碟整合——Google 回呼通知＋同步排程主幹

檢查日期 2026-09-25｜對應卡片 CM-2156（母卡 CM-2152）｜檢查範圍 9 個檔案 1,838 行｜工具 run ID wf_32b5fcb9-978

卡片最擔心的「不登入的回呼入口」是穩的；真正的洞在背景同步：背景工作一律用「可看全部公司」的系統身分在跑，只要有人塞進一個別家公司的專案編號，系統就會照著做。

• 回呼入口（Google 打進來的那支）擋得住偽造：憑證是 256 位元的隨機碼，錯的一律丟掉；找不到公司、憑證錯、憑證對，回應都一模一樣，外人探不出「這個頻道存不存在」。
• 🟠 新發現（中風險，三人面板 3:0）：任何一家公司的登入帳號，只要知道另一家公司某個專案的編號，就能叫系統把那家的專案結構（專案名、稽核輪次名、控制項名、任務名）抄一份建進自己的雲端硬碟，而且之後往那些資料夾丟檔案，會被當成證據寫進別家公司的稽核任務。門檻是要先拿到對方專案的編號（隨機 UUID，猜不到，要從別處外流）。我在 DEV 用唯讀查詢確認了「讀」這一半。
• 🟠 新發現（中風險，面板 3:0）：系統建的每一個雲端硬碟資料夾（含最上層根資料夾），都被設成「任何拿到連結的人都能編輯」。同一家公司裡任何一個登入帳號都能從系統要到根資料夾的編號，打開就能看、改、刪全公司每個專案的證據；刪掉的檔案會同步回系統，變成證據被刪。這是 FR-016 設計時刻意選的做法，所以要決策者裁定要不要改，不是單純寫錯。
• 工具另外撿到 4 條「密碼金鑰寫進版本控制」，全部是既有工單（CM-1607／CM-1629／CM-1631）重現，不另計。
• 我人工另補 3 條低度問題（見總覽 U5-3～U5-5），都不急。

帶著前棒的形狀來看：U1 證實權限地基是穩的。這一棒的兩條中風險都不是地基壞了，而是「沒接上」——背景工作根本沒去用那套地基（改用可看全部的系統身分），手動觸發的入口也刻意不掛專案成員檢查。

客戶可以把系統接上自己公司的 Google 雲端硬碟。接上之後，系統會自動在硬碟裡替每個專案建一整棵資料夾（專案 → 稽核輪次 → 控制項群組 → 控制項 → 評估項目 → 任務），使用者把證據檔丟進任務資料夾，系統就自動抓回來當證據。

這一棒的 9 支程式是這條同步線的「主幹」：

• Google 回呼通知（2 支）：客戶的雲端硬碟一有變動，Google 會主動打我們一支網址通知。這支網址不用登入（打進來的是 Google，不是人），只靠 Google 帶回來的一組「頻道編號＋憑證」認身分。
• 頻道管理（1 支）：向 Google 登記「有變動請通知我」，每 7 天要續約一次。
• 同步排程主幹（5 支）：其他功能（建專案、改名、刪任務）要同步雲端時，先在「同步工作表」排一筆工作，背景工人每 5 秒撈一批出來做。
• Google 連線用戶端（1 支）：實際呼叫 Google API 的那一層（建資料夾、分享權限、下載檔案）。

要回答的核心問題是：回呼憑證從哪來、誰能偽造、偽造了能觸發什麼寫入？背景工作用誰的身分跑？

現況（2026-10-01）：本棒各條後來的處理結果如下（過程紀錄保留，不改）。

• U5-1（重建資料夾跨公司）＝總表第 192 項，✅ 已修（CM-2201，commit 73f5f90af，1.21.0 出貨）。
• U5-2（資料夾任何人可編輯）＝總表第 193 項，🚫 裁定不修（決策者 10-01，分享權限未來由權限管理控管或交客戶自己的 Google 設定）。
• U5-3（註解說會去重）＝總表第 195 項，🚫 裁定不修（同步可重跑、只多跑一次）。
• U5-4（通行碼非常數時間比對）＝總表第 196 項，✅ 已修（CM-2213，commit a5804a990／bde8f9d16，1.21.0 出貨）。
• U5-5（反斜線未跳脫）＝總表第 197 項，✅ 已修（CM-2213，同上 commit，1.21.0 出貨）。
• 工具 F1／F2／F5／F6 舊帳：原卡 CM-1631／CM-1607／CM-1629 已作廢，實際由 CM-2051（Google 密鑰）、第 10／11 項（金鑰）、CM-2049（資料庫密碼）修掉，均 ✅ 已修。

工具一共交回 6 條，三人面板 18 票全投完、零漏投。

F3 → U5-1 🟠 手動重建資料夾可以讀、寫別家公司的專案（中，3:0）

• 位置：入口 api/cloud_integration/routes/google_drive_sync_route.py:108-121 → 排工作 app/cloud_integration/service/drive_sync_orchestration_service.py:145-157 → 背景讀取 app/cloud_integration/service/project_tree_loader.py:87-91 → 建資料夾 app/cloud_integration/service/handlers/init_project_folders_handler.py（U6 範圍）→ 匯入證據 app/cloud_integration/service/handlers/import_drive_file_handler.py:103（U6 範圍）

• 白話說明：專案頁有一顆「重建雲端資料夾」按鈕，會打 POST /integrations/google-drive/projects/<專案編號>/init-folders。這支網址只檢查「有登入、公司有買雲端整合」，刻意不檢查你是不是這個專案的成員（程式註解寫明是怕擋到專案管理者）。它把網址上的專案編號原封不動排進同步工作表，掛在呼叫者自己公司名下。 背景工人撈到這筆工作時，整批工作都跑在「系統身分」底下（core/scheduler.py:177 的 system_context），這個身分會關掉資料庫的公司隔離。接著專案樹載入器用「管理員、看全部」的參數查專案（project_tree_loader.py:53-54 寫死 SYSTEM_IS_ADMIN = True），而查專案的那段只用編號比對、不看公司，所以不管那個專案是哪家公司的都查得到。

• 影響：

  • 讀：B 公司的專案名、每一輪稽核的名稱、控制項群組／控制項／評估項目／任務的名稱，全部變成 A 公司雲端硬碟裡的資料夾名，A 公司的人直接打開就看得到。
  • 寫：系統同時記下「這個資料夾對應 B 公司的某個任務」。A 公司的人往那個資料夾丟檔案，背景工人（一樣是系統身分）會照對應表找到 B 公司的任務，把檔案當成證據寫進去——別家公司的稽核紀錄裡多了一筆來路不明的證據。證據表本身沒有公司欄位、也沒開資料庫隔離（總表第 43 項已記），所以資料庫不會擋。

• 觸發前提：A 公司有「雲端整合」授權、已接上 Google 雲端硬碟；攻擊者是 A 公司任何一個登入帳號；攻擊者要知道 B 公司某個專案的編號——編號是隨機 UUID 猜不到，要從別的地方外流（例如總表裡其他「任何登入者讀得到別家資料」的洞）。

• 🔍 runner 開檔核對：屬實。逐支開檔確認：route 只掛 @jwt_required 與 @require_license；drive_sync_admin_service.py:118-124 的註解明寫刻意不加權限；_enqueue_init_project_folders 只檢查「這家公司有沒有接雲端」；infra/flow_control/repository/flow_control_project_repo_impl.py:384-388 只 filter(Project.uid == uid)，is_admin=True 時整段可見性檢查跳過。

• 🔍 DEV 唯讀驗證（2026-09-25 13:09 +08，BEGIN READ ONLY … ROLLBACK，沒有寫入）：用本機 DEV 的 cm_app 帳號，拿 131 公司的一個專案，照同一個查詢條件在兩種身分下各查一次：

  • 模擬背景工人的系統身分（app.is_super_admin = t）→ 查得到 1 筆
  • 模擬「工作所屬公司 102」的身分（app.allowed_tenant_paths = /1/102/）→ 0 筆

  → 證實：只要把背景工人換成「以工作所屬公司的身分跑」，資料庫就會自己擋掉。原本想直接呼叫專案樹載入器實跑，但本機缺雲端金鑰、DI 組不起來，改成照同一段 SQL 在資料庫層模擬兩種身分。「寫入別家任務」那一半是讀碼推論，沒有實測（要真的接 Google 硬碟才跑得起來）。

• 建議修法（兩層都補）：

  1. 入口：_enqueue_init_project_folders（或 trigger_init_project_folders）排工作前，先用呼叫者自己的身分（受公司隔離）查一次這個專案；查不到或不是成員就拒絕。建專案、發起覆核這兩條自動路徑的專案編號是伺服器剛建好的，不受影響，但同一支函式守住就一起守住了。
  2. 背景：專案樹載入與證據匯入改成在 tenant_context(job.tenant_id)（只看工作所屬公司的身分）底下跑，或讀到專案／任務後比對它的公司是不是工作的公司。這一層補了，將來再多一個入口漏守也不會出事。

F4 → U5-2 🟠 雲端硬碟資料夾全部「任何拿到連結的人都能編輯」（中，3:0）

• 位置：infra/cloud_integration/google_drive/google_drive_api_client.py:285-301（share_anyone_writer）；呼叫點：根資料夾與各層資料夾 init_project_folders_handler.py:448、任務資料夾 create_folder_handler.py:59、封存資料夾 drive_sync_orchestration_service.py:521 與 archive_drive_file_handler.py:157
• 白話說明：系統每建一個資料夾，就對它設一條權限「任何人（anyone）、可編輯（writer）」，只加了「搜尋不到」（allowFileDiscovery: false）——意思是不會被搜尋引擎找到，但任何拿到連結的人都能打開、上傳、刪除，不必登入 Google。子資料夾會繼承根資料夾的權限。 而根資料夾的編號，GET /integrations/google-drive 會回給公司內任何登入帳號（google_drive_integration_route.py:31-35 的註解寫明刻意不掛權限，因為專案頁要用它判斷要不要顯示雲端區塊），這支回傳內容裡就有 root_folder_id。
• 影響：公司內一個沒參與 X 專案的人，要到根資料夾編號、在瀏覽器打開，就能看、下載全公司每個專案的證據；也能刪檔——系統會把刪除同步回來，變成那筆證據在系統裡被刪。連結如果外流（轉寄、瀏覽紀錄、截圖），公司外的人一樣能用。
• 觸發前提：公司已接雲端硬碟；拿到任一資料夾的連結或編號。
• 🔍 runner 開檔核對：屬實，權限寫死、沒有任何設定可切換。但要注意這是刻意設計：docs/features/FR-016-2604-google-drive-sync/design.md 第 52 行把「Drive 端細粒度權限」列為不做，統一用「任何拿到連結的人可編輯」。所以這條要回到決策層：當初的取捨（讓使用者不必有公司 Google 帳號也能丟證據）值不值得這個風險。
• 建議修法：分享對象改成公司的 Google 網域（type: domain）或指定的專案成員帳號（type: user）；GET /integrations/google-drive 不回根資料夾編號給沒有 cloud_integration.read 的人（專案頁判斷「有沒有接」只需要連線狀態，用不到編號）。這條要決策者先裁，改了會影響使用者丟證據的流程。

F1／F2／F5／F6 — 密碼金鑰寫進版本控制（全部是既有工單重現，不另計）

工具的「密碼金鑰專掃」順著雲端硬碟的憑證往外追，在 docs/conversation-history/（過去對話紀錄的原文存檔）找到 4 條。範圍內 9 支程式本身沒有任何寫死的密碼金鑰。

① 回呼憑證比對是不是「常數時間比對」？——🟡 不是，但實務上打不到（→ U5-4）

白話：「常數時間比對」是不管你猜對幾個字，系統回應的快慢都一樣。一般的 != 比對遇到第一個不同的字就停，理論上猜對越多字、回應越慢，量時間就能一字一字試。

google_drive_webhook_service.py:93-96 用的是一般的 !=。但憑證是 secrets.token_urlsafe(32)（webhook_channel_manager.py:113）＝ 256 位元隨機碼，字元比對的時間差是奈秒級，網路往返的抖動是毫秒級，差了百萬倍，實務上量不出來。仍建議改成 hmac.compare_digest，一行就好，也跟 U3 設定碼的做法一致。

② 找不到頻道時，回應會不會洩露「這個頻道存不存在」？——✅ 不會，不成立

四種情況回應完全相同，一律 HTTP 200、{"received": true}：

程式一律回 200 是因為 Google 看到 4xx／5xx 會以為頻道壞了、停止推送（google_drive_webhook_route.py:50-51），順帶也讓外人探不出任何差別。記進 log 的只有公司編號與頻道編號，憑證本身沒進 log；請求標頭的 log 也會把 X-Goog-Channel-Token 遮成 ***（common/middleware/app_mw.py:78-83 的白名單不含它）。

實測（本機直接呼叫驗證邏輯、用假的授權紀錄與假的工作表，不接資料庫）：錯憑證 → 0 筆；空憑證 → 0 筆；不存在的公司 → 0 筆；已斷線的公司（授權紀錄的頻道與憑證都是空的）送空標頭 → 0 筆（空字串 "" 與空值 None 比對不相等，擋得住）。

③ 攻擊者能不能狂打回呼，讓系統無限排同步工作？——🟡 外人不行；持有憑證的人可以（→ U5-3）

• 外人：沒有正確憑證，每一次都在比對那步被丟掉，一筆工作都排不進去。回呼網址本身的成本只是一次資料庫查詢。
• 持有憑證的人：每打一次就多排一筆。實測：用正確憑證連打 200 次 → 排進 200 筆，沒有任何合併；resource_state 標頭塞 5,000 字的亂碼 → 照樣排進去，只記一筆警告，那 5,000 字原樣存進工作內容。
• 註解與程式不符：google_drive_webhook_service.py:6 寫「worker 會依 PENDING 狀態去重」，但工作表的寫入、撈取、分派三處（drive_sync_job_repo_impl.py、drive_sync_worker.py）都沒有去重邏輯。另一支處理變動的程式註解承認「兩筆同時跑沒關係，證據檔編號唯一，重複匯入會被資料庫擋掉」——所以重複工作不會寫壞資料，只是浪費。
• 誰拿得到憑證：只有 Google 與我們資料庫的授權紀錄。所以這條的實際意義是：萬一資料庫外流，或 Google 那邊短時間推大量通知，系統沒有第二道節流。列低。

④ 背景同步用「哪個公司的機器身分」跑？身分從工作紀錄讀，還是從呼叫者帶？——🔴 這是本棒的核心問題（→ U5-1）

• 公司編號從哪來：每筆工作的公司編號都是伺服器自己決定的——網頁入口一律取自登入身分（user.tenant_id），回呼入口取自網址但要通過憑證比對，工作表本身還有資料庫隔離規則擋「寫入別家公司的工作」（DEV 查證：drive_sync_jobs 的新增規則要求公司在呼叫者可見範圍內）。使用者塞不進一筆「指定別家公司」的工作。✅
• 但背景工人不用那個公司的身分跑：core/scheduler.py:177 把整批工作包在 system_context（可看全部公司）裡，公司編號只是當作參數傳下去。只要工作內容裡的其他編號（專案、任務）沒有另外核對公司，就會一路讀寫到別家。U5-1 就是這個形狀的具體實例。
• 其他排工作的入口我逐支追過：

⑤ 使用者能不能在工作紀錄塞一筆指定別家公司的工作？——✅ 不能，不成立

見上一條。所有排工作的呼叫都由伺服器帶公司編號，資料庫層還有一道「只能寫自己看得到的公司」的規則兜底。手動重試（manual_retry）只用工作編號查，但它跑在使用者請求內、受資料庫隔離，別家公司的工作查不到（入口屬 U4 範圍，只讀不報）。

⑥ 通知頻道憑證怎麼產生、夠不夠隨機？——✅ 夠，不成立

webhook_channel_manager.py:112-113：頻道編號 secrets.token_urlsafe(16)（128 位元）、憑證 secrets.token_urlsafe(32)（256 位元），用的是 Python 專門做密碼學隨機的 secrets 模組。每次重新登記都換一組新的，舊頻道先停掉。✅

⑦「有人守了一半」共通疑點

以下三條未經三人面板投票，是 runner 自行開檔核對。

U5-3 — 回呼註解宣稱「會去重」，程式裡沒有

• 嚴重度：🟢 低
• 位置：app/cloud_integration/service/google_drive_webhook_service.py:6（註解）、:118-123（排工作）
• 白話說明：Google 每推一次通知，系統就排一筆「處理變動」工作。註解說背景工人會把狀態還在等待中的重複工作合併掉，實際上沒有這段程式。
• 影響：通知密集時會累積大量重複工作，每一筆都去 Google 拉一次變動清單。重複匯入會被資料庫的唯一約束擋掉，不會寫壞資料，只是浪費 Google 配額與工人時間。
• 觸發前提：要有正確的頻道憑證（外人沒有）；或 Google 本身短時間推大量通知。
• 實測：本機直接呼叫驗證邏輯，用正確憑證連打 200 次 → 工作表收到 200 筆；resource_state 塞 5,000 字 → 照樣排入、原樣存進工作內容。
• 建議修法：排之前先查「同一家公司是否已有還沒開始的『處理變動』工作」，有就跳過；或在資料庫加一條「同公司同類型只能有一筆等待中」的部分唯一索引。順手把 resource_state 限定在已知的幾個值、不認得的就不排。

U5-4 — 回呼憑證比對不是常數時間

• 嚴重度：🟢 低
• 位置：app/cloud_integration/service/google_drive_webhook_service.py:93-96
• 白話說明與影響：見疑點①。256 位元的隨機憑證，實務上量時間猜不出來。
• 觸發前提：能打到回呼網址（對外公開）。
• 建議修法：hmac.compare_digest(entity.webhook_token or "", channel_token)，頻道編號同理。注意授權紀錄的憑證可能是空值，要先轉成空字串，否則會拋錯變成 500（U3-1 同型陷阱）。

U5-5 — 用名字找資料夾時沒跳脫反斜線

• 嚴重度：🟢 低（未實測）
• 位置：infra/cloud_integration/google_drive/google_drive_api_client.py:121（find_folders_by_name）；呼叫點 init_project_folders_handler.py:428
• 白話說明：系統建資料夾前，會先在雲端硬碟用名字找「有沒有同名的舊資料夾可以直接認領」。名字塞進 Google 的查詢語法時，只把單引號 ' 換成 \'，反斜線 \ 本身沒處理。名字如果以反斜線結尾，例如 abc\，查詢會變成 name='abc\'，後面那個引號被當成字面字元，字串一路延伸到下一個引號，查詢條件的結構就被改掉了。我本機組出查詢字串確認了這個結構變化。
• 影響：名字來自專案、稽核輪次、控制項、任務名稱（專案管理者可以改）。精心設計的名字可能讓「只在這個父資料夾底下找」這個限制失效，讓系統把硬碟裡別處的同名資料夾認領成任務資料夾，之後那個資料夾裡的檔案會被當成證據匯入。影響範圍限在這家公司自己接的那個 Google 帳號的硬碟。
• 觸發前提：能改專案／任務名稱；公司已接雲端硬碟；要實際打 Google API 才知道 Google 的查詢解析器吃不吃這個結構——本棒沒有接真的硬碟，未實測。
• 建議修法：先把 \ 換成 \\、再把 ' 換成 \'（順序不能反）。與總表第 110 項（舊證據分類線的同型問題）一起修。

另記一筆（資訊，不列項）

• google_drive_api_client.py:280：下載檔案時「超過大小上限就中止」的檢查，要等整個分塊下載完才做，而 Google 套件預設一塊是 100 MB。所以單次匯入最多會比上限多吃 100 MB 記憶體才被擋下。匯入前另有一道「先看檔案大小」的檢查（import_drive_file_handler.py:173，U6 範圍），一般檔案會在那一步就擋掉。留給 U6 看 Google 文件匯出的路徑是否有大小可看。

第一層：工具正式報告（經三人面板驗證）

• 驗證章：verified（stamp CLAUDE-SECURITY-REVISION-fe7c471f3d7c-dirty.json）
• 研究員 2 派 2 回（全範圍 1＋密碼金鑰專掃 1），failed 0、續跑 0；候選 6、去重後 6，18 票全投完、零漏投。
• 通過 6 條：F1／F2／F3／F4 3:0 一致，F5／F6 2:1。面板主動調降 2 條（F2 高→中、F6 中→低）。
• 工具的每一條都是讀碼推論，工具本身沒有執行任何程式。

第二層：runner 自行開檔核對（未經三人面板投票）

• 範圍 9 支逐支通讀；卡片「重點看什麼」三條、「有人守了一半」八種樣式逐條答完。
• 跨讀了範圍外的相關程式（只讀不報）：所有呼叫同步總指揮的網址入口（7 處）、core/scheduler.py 的背景工人與續約排程、U6 範圍的建資料夾與匯入證據兩支處理器、infra/flow_control/repository/flow_control_project_repo_impl.py 的專案查詢、jedi-common 的 system_context／tenant_context 與資料庫隔離開關、common/middleware/app_mw.py 的標頭遮罩、FR-016 設計文件。
• 實測：回呼驗證邏輯本機直接呼叫（假授權紀錄＋假工作表，六種情境，見疑點②③）；U5-1 在 DEV 以唯讀交易模擬兩種身分查同一個專案；U5-5 本機組查詢字串看結構。
• DEV 資料庫唯讀查證（2026-09-25 13:09 +08，全程 BEGIN READ ONLY … ROLLBACK）：drive_sync_jobs 隔離規則（四條，開啟中）、app_tenant_allowed_for_session 函式內容、專案分布在 102／131 兩家公司、drive_folder_mappings 的唯一約束。
• 打折處：
  1. 本機 BE 當時沒在跑，所有實測都是直接呼叫函式或在資料庫層模擬，沒有對運行中的服務打真的請求。
  2. U5-1「讀」這一半：原想直接跑專案樹載入器，但本機缺雲端權杖加密金鑰、另有一個不相干的容器零件組不起來（FlowControlJobRepoImpl 缺方法），DI 啟動失敗，改成照同一段查詢條件在資料庫層模擬兩種身分。結論（系統身分查得到、公司身分查不到）不受影響，但不是端到端實跑。
  3. U5-1「寫入別家任務」與 U5-2、U5-5 都要接真的 Google 雲端硬碟才驗得出來，本棒沒有實測，是讀碼推論。
  4. 只查了 DEV，沒看 STG／POC。