外部 FDE 團隊怎麼跟內部 IT/資安協作?權限、稽核與資料邊界的協作模式

去年底,我們準備進一家金控的核心系統做 RAG 導入。第一次會議,對方資安長沒問我們模型多強、Demo 多漂亮,只問了三句話:「你們的工程師會拿到哪些帳號?誰按了什麼,查得到嗎?我們的客戶資料,會不會離開這棟樓?」

這三句話,基本上就是外部 FDE 團隊進場的全部門檻。你答不出來,技術再好也進不了生產環境。所以這篇不談模型,只談一件事:外部工程師進場時,權限、稽核與資料邊界的 FDE 資安協作模式該怎麼設計,才能讓內部 IT 與資安願意放行。

先講結論:好的協作模式,是「假設外部人不可信」也能運作

一句話定義:FDE 資安協作模式,是一套讓外部工程師在最小權限、全程可稽核、資料不落地的前提下,仍能把 AI 系統推上客戶生產環境的協作契約與技術控制組合。

重點在「假設外部人不可信也能運作」。這不是不信任你的工程師,而是資安的基本設計原則——控制不能建立在對個人的信任上,要建立在制度與系統上。一個成熟的外部團隊,反而會主動幫客戶把這道牆砌好,因為這對雙方都是保護。

三根柱子:最小權限、稽核軌跡、資料邊界

我們把資安長的三個問題,拆成三根可以逐項落地的柱子。

第一根,最小權限(Least Privilege)。 外部工程師不該有「管理員帳號」,而該有「剛好夠完成這個 sprint 的帳號」。實務上我們的做法是:所有存取都走客戶自己的身分系統(SSO / IdP),不另開後門帳號;權限按角色綁定(RBAC),FDE 只拿到指定專案的 repo、指定的向量庫 namespace、指定的測試資料集;高風險操作(碰生產資料庫、改權限設定)一律走 JIT(Just-In-Time)臨時授權,用完即收,而不是常駐開著。這樣就算某個帳號外洩,爆炸半徑也被鎖在一個專案裡。

第二根,稽核軌跡(Audit Trail)。 「誰按了什麼查得到嗎」的答案必須是:每一次存取、每一條查詢、每一次 prompt 與模型回應,都有一條帶時間戳與身分的日誌,寫進客戶側(不是我們側)的 SIEM 或日誌平台。關鍵是日誌的擁有權在客戶手上,外部團隊無法刪改自己的軌跡。我們踩過一個雷:早期有個案子把 LLM 呼叫日誌只留在應用層,結果稽核時對不上帳,後來一律要求 API gateway 層留一份不可竄改的存取紀錄。稽核不是事後補的文件,是即時產生的資料。

第三根,資料邊界(Data Boundary)。 「資料會不會離開這棟樓」牽涉三個層次:資料落地(在客戶 VPC / 地端跑,還是出雲)、資料傳輸(有沒有經過外部 API)、以及模型會不會把客戶資料學走。在金融與醫療案子,我們的預設是資料不出客戶環境——模型部署在客戶 VPC 內、或走有 DPA 與零留存(zero-retention)條款的企業版 API;敏感欄位在進模型前做去識別化;開發與測試一律用脫敏資料,絕不把生產資料複製到工程師的本機。

一張表,直接給資安主管當檢核清單

協作模式不是給工程師的限制,是給雙方的護欄

很多人以為這些控制會拖慢外部團隊。實際上剛好相反。當權限邊界、稽核方式、資料規則在專案第一週就白紙黑字寫清楚,後面的每一次上線審批都會快很多——因為資安團隊不用每次重新評估風險,他們只要確認你有沒有照契約走。真正拖慢專案的,是那種「先給我全部權限,我保證只碰該碰的」的模糊地帶,那會讓資安一路踩剎車。

還有一個常被忽略的收尾:offboarding。專案結束那天,帳號要撤、臨時授權要關、runbook 與架構文件要交回內部團隊。外部 FDE 的目標從來不是長期霸佔存取權,而是把系統穩穩交回去,讓內部 IT 自己也能維運。

我們在 Tenten 做 FDE 導入時,會在 kick-off 前就跟客戶資安團隊一起把這張表填完、寫進協作契約,再開始碰任何系統。對我們來說,能不能通過資安這關,和 Demo 好不好看一樣重要——因為上線且有人在用,前提是它得先被允許上線。