Safety Model

安全機制

核心原則

• 只使用合成資料：商店代號固定在 90001-90004，日期固定在 2026-07-01 ～ 07-04。
• 禁止欄位掃描：每一筆要輸出的資料（情境資料、API 回應、遙測事件、指標列）都會被遞迴檢查，只要出現類似 customer_id、email、phone、address、token、secret、credential、traceback 等關鍵字就會被擋下來。
• 不合法紀錄不會外流：不合法或被排除的訂單，永遠只會以「清洗後的統計數字」呈現，不會把原始那筆資料吐出來。
• 瀏覽器不會直接打 GCP：前端只會呼叫這個後端自己的 API，絕不會拿到雲端憑證或直接呼叫 Google Cloud。

雲端閘門（Cloud Gate）

任何會建立 Pub/Sub、BigQuery、Dataflow 用戶端的程式碼路徑，都必須同時滿足下面三個條件：

flowchart LR
    A["--enable-cloud-mode"] --> D{三個條件<br/>同時成立?}
    B["--execute-cloud-pipeline"] --> D
    C["--confirm-synthetic-sandbox-only<br/>I_CONFIRM_SYNTHETIC_SANDBOX_ONLY"] --> D
    D -->|是| E[允許建立真實的<br/>GCP 用戶端]
    D -->|否| F[直接中止，<br/>只印出 dry-run 指令]

Loading

專案預設三個條件都沒有打開，所以預設情況下不會產生任何真實的雲端動作、也不會有任何費用。

兩層各自的安全邊界

套件	負責什麼
beam_pipeline_toolkit/safety/	通用的 LeakGuard（禁止欄位掃描器）與 assert_gates_open（雲端閘門），沒有寫死任何 Cyberbiz 專屬欄位名稱
demo/shared/safety.py	套用在這個電商展示情境的具體規則（例如允許 name/scenario 這種本來就不是個資的欄位）

例外處理原則

如果安全掃描器誤擋到一個其實安全的欄位（例如 job_name 裡包含 name 字樣），修法永遠是針對那個確切欄位加一條有註解的白名單，而不是放寬整體的比對規則——這樣才能保留其他所有欄位原本的保護力。