Guidant AI 資安檢視總報告 · 安全需求（SR）
Drive、授權簽發站、外部 AI
幾條「依設定才存在」的外部整合各有特有的守法。這一章 5 條：Drive 不收呼叫者直接給的檔案編號與回呼身分不殘留、Drive webhook 驗證、授權序號與收回的授權檔、外部 AI 的入口與出口守門。4 條有掃描實例、1 條是標準做法。
外部整合的共同風險是「拿公司的鑰匙替外面的人辦事」：Drive 用授權帳號的完整權限去抓檔、授權簽發站替客戶領付費授權、外部 AI 把客戶內容送出去又把回覆收回來。通用要求（逾時、憑證驗證、祕密保管）歸各通用章，本章只放這三組整合特有的。
| # | 要求 | 來源 |
|---|---|---|
| SR-10.1 | Drive 不收呼叫者直接給的檔案編號，OAuth scope 收窄到 drive.file | 掃描驗證 |
| SR-10.2 | Drive 回呼身分只用於這一次寫入，Google 帳號一租戶一綁 | 標準做法 |
| SR-10.3 | Drive webhook 固定時間比對，驗過只排工作不信內容 | 掃描驗證 |
| SR-10.4 | 授權序號夠長、有失敗鎖定，收回的授權檔一律本地驗章 | 掃描驗證 |
| SR-10.5 | 外部 AI 輸入守門與出口守門 | 掃描驗證 |
| 欄位 | 內容 |
|---|---|
| 要求 | Drive 的預覽與查詢不得接受呼叫者直接給的雲端檔案編號：必須先驗該檔案屬於這一批，且呼叫者是該專案成員；查不到對應紀錄必須回 404，不得退回直接讀雲端；OAuth scope 必須收窄到 drive.file（只看得到本應用建立的檔案），不得要整個雲端硬碟 |
| 為什麼 | 任一登入帳號在預覽網址填一個雲端檔案編號，系統就用授權那個 Google 帳號的完整權限去抓，別的專案的證據、人事檔、合約原樣送回；查不到紀錄還退回直接讀雲端，等於守門形同虛設 |
| 適用連線 | C14 api → Google Drive；推及：C04 瀏覽器 → api（Drive OAuth 回呼）（授權階段決定 scope） |
| 對應威脅 | C14 T1 拿到編號就用公司的鑰匙去 Google 抓 🟠、C14 T4 使用者的字拼進 Google 的搜尋語法 🟡 |
| 驗證方式 | 以專案 A 成員的身分，對預覽端點填一個不屬於專案 A 的雲端檔案編號，必須回 404 且後端不得對 Google 發出該檔案的讀取請求；填一個非本應用建立的檔案編號必須同樣被拒；檢查 OAuth 授權畫面與 token，scope 必須只有 drive.file |
| 來源 | 掃描驗證：C14 D1（實例 M07-1、M07-2）；標準做法：C14 D6◇ |
| 欄位 | 內容 |
|---|---|
| 要求 | OAuth 回呼解出的租戶身分只能用於這一次寫入，不得殘留於執行緒、全域或快取；同一個 Google 帳號必須一租戶一綁，已被一家租戶綁定時，第二家的綁定必須被拒 |
| 為什麼 | 回呼完成後身分殘留，後續請求會帶著上一次的租戶身分；同一 Google 帳號被兩家租戶接走時，Google 推通知後背景同步按帳號查到的是另一家的任務，把別家證據標成已刪除 |
| 適用連線 | C04 瀏覽器 → api（Drive OAuth 回呼） |
| 對應威脅 | 無掃描實例（標準做法） |
| 驗證方式 | 完成一次回呼後，在同一執行緒立刻送一個無身分的請求，必須查無任何租戶資料；用同一個 Google 帳號對第二家租戶發起綁定，必須被拒 |
| 來源 | 標準做法：C04 D5◇ |
| 欄位 | 內容 |
|---|---|
| 要求 | Drive webhook 入口必須用固定時間比對（不得逐字比較）驗通行碼；驗過之後只排一個同步工作，不得信任通知內容裡的任何欄位；「驗憑證」按鈕必須疊能力點守門，沒有儲存設定權限的人不得能讓系統替他向 Google 試憑證 |
| 為什麼 | 逐字比對的回應時間差讓攻擊者一個字一個字猜通行碼，猜中就能偽造「硬碟有異動」通知讓系統一直做白工；沒守門的驗憑證按鈕讓任何人替他用系統向 Google 試憑證對錯 |
| 適用連線 | C14 api → Google Drive |
| 對應威脅 | C14 T5 從不需登入的通知入口與驗憑證按鈕下手 ⚪ |
| 驗證方式 | 對 webhook 端點送通行碼開頭不同的多組值，統計回應時間，差異必須不可區分；送通行碼正確但內容夾帶惡意欄位的通知，系統只能排一個同步工作且不得使用該欄位；以沒有儲存設定權限的平台管理員身分按驗憑證，必須被拒 |
| 來源 | 掃描驗證：C14 D5（實例 M24-11、M24-12、M24-15） |
| 欄位 | 內容 |
|---|---|
| 要求 | 授權序號必須約 128 位元隨機值並有有效期；開通失敗鎖定必須按來源計並存資料庫，另必須有全站失敗預算以擋分散式猜測；收回來的授權檔不得因來源是簽發站就信，必須一律在本地驗章並做有界解析 |
| 為什麼 | 序號只有 8 碼（約 43 億組）且鎖定按序號計時，每次換一個序號就永不鎖，攻擊者可撞中別人尚未兌換的序號領走付費授權；簽發站被假扮或攻破時，不驗章就會收下假授權 |
| 適用連線 | C18 api → 授權簽發站 |
| 對應威脅 | C18 T1 大量猜序號，領走別人付費的授權 🟠 |
| 驗證方式 | 對開通 API 連續送隨機序號，同一來源超過鎖定門檻必須被鎖，換序號不得重置；多個來源合計超過全站預算也必須被擋；以簽發站回應一份簽章無效的授權檔，產品必須拒收並不改變現行授權 |
| 來源 | 掃描驗證：C18 D1（實例 M18-3）；標準做法：C18 D4◇ |
| 欄位 | 內容 |
|---|---|
| 要求 | 送外部 AI 前必須過入口守門：私鑰格式一律 block、要密碼或要指令的對話 block、身分證字號等個資 redact；AI 回覆必須過出口守門，對回覆再跑一次規則（遮罩與原文比對）；被 block 的請求不得送出 |
| 為什麼 | 沒有入口守門時，使用者貼上的私鑰與個資直接送到第三方 AI；沒有出口守門時，被注入的回覆把假判定或被誘導輸出的敏感內容原封存進資料庫與畫面 |
| 適用連線 | C13 api → 外部 AI |
| 對應威脅 | C13 T4 AI 儀表板這條路不檢查權限，資料整包送出去 🟡、C13 T5 證據文件裡寫指令給 AI 看 🟡 |
| 驗證方式 | 在聊天框貼一段私鑰格式文字，必須被 block 且外部 AI 端收不到該請求；貼含身分證字號的文字，送出的內容中必須已被遮罩；讓外部 AI 回覆含私鑰格式的內容（用測試替身），顯示給使用者的內容必須已被遮或擋 |
| 來源 | 掃描驗證：C13 D5（實例 M15-2、M15-3、M17-2、M15-4、M15-7、M07-5） |
來源：連線頁的防線（D）；去重對照在 requirements/_drafts/D-to-SR.md。