某 PaaS 平台環境變數外洩，一堆人的 OpenAI、Anthropic API Key 直接躺在外面。 這篇想講三件事：事發第一小時該做什麼、 為什麼「加強防火牆」救不了這類事件， 以及我們蓋 Containarium 時遵守的七條安全邊界規則。
事件一出來，很多人的第一反應是「加強 cluster 之間的防火牆」。方向不能算錯， 但這類多租戶平台外洩的路徑，通常不是 A cluster 橫向打到 B cluster。
而是單一控制平面或秘密儲存，被一次撈走全部租戶。 一個過權的 token、一個沒鎖好的內部 API、一份備份檔——攻擊者根本不需要碰你的網路邊界， 他直接站在所有租戶資料匯集的那一點上。
網路隔離擋不住這件事。租戶之間的封包被擋得再乾淨， 都改變不了「秘密以明文形態集中放在一個地方」這個事實。 隔離做在網路層，洩漏發生在儲存層——兩件事根本不在同一個軸上。
2026 年 8 月 31 日更新：這一段講得太滿。 調查細節顯示，走到匯集點的那條路徑本身就是橫向移動—— 從一個正在停用、卻仍握著核心資料庫內部存取權的共享叢集走出去的。 正確的講法是「光靠網路隔離擋不住」：那是兩道閘門的其中一道，而我們低估了另一道。 上面這段文字原樣保留，沒有改寫。
對付「儲存被整包偷走」，有效的軸不是更多防火牆，而是加密邊界。它說穿了只有三個性質：
加密邊界的三個性質
自測題：如果你的秘密儲存今晚被整包拷走，明天是公關災難，還是一則 status page 公告？
做到這三件事，「儲存被整包偷走」才會從災難降級成事件： 攻擊者拿走的是一堆密文，而解開它們的金鑰在另一個信任邊界裡。
順帶一提，把 Key 從環境變數搬進 Vault，卻在服務啟動時又整包展開成環境變數，
等於白做——秘密還是以明文形態躺在每一個 process 的記憶體和
/proc 裡，
你只是多養了一套 Vault。加密邊界的重點是解密的位置和身分，不是儲存的品牌。
帶著這五題去問你的 PaaS
答得最不順的那一題，就是你真正的邊界所在。
加密邊界處理的是「儲存被偷」。第二個該做的是 AI Gateway，處理的是「執行環境被打」： 把「長期真 Key 散落在 N 個客戶容器」， 換成「真 Key 只存在單一受控邊界，容器拿到的是可即時撤銷的短期憑證」。
一個動作解掉四件事：
這裡有個容易被忽略的推論：egress 白名單救不了已經在容器裡的 Key。 模型服務商的 endpoint 本來就在允許清單上，Key 要外流，走的就是那條被允許的路。 所以理想的 Gateway 不只是一個 proxy——它必須是唯一的路。 做不到「擋掉直連模型商」的 Gateway，只是一條建議路線，繞過去就沒了。 解法不是把網路關得更緊，而是讓 Key 從頭到尾不進容器、讓直連的路不存在。
有了單一受控邊界，偵測才有落點。值得盯的訊號，按強度排：
應變也不要只有「正常／停用」兩態。 觀察 → 降速 → 告警 → 熔斷 → 撤銷—— 中間層很重要，因為誤判一次就把付費客戶整個切掉，你會學到再也不敢開自動應變。
Gateway 集中了所有租戶的真 Key， 它本身就是全平台最高價值的目標。 沒先做好加密邊界，Gateway 只是把風險換個位置，而且更集中—— 你等於親手蓋了一個更值得打的秘密儲存。 這對「平台不動、先買一個 AI Gateway 產品補洞」的做法，同樣成立。
所以順序是：先讓「儲存被整包偷走」只偷得到密文，再把真 Key 收進單一受控邊界。反過來做，是自找的。
我們是多租戶平台，上面那段威脅模型就是我們自己的威脅模型。 與其列功能清單，不如把我們用來蓋 Containarium 的規則寫下來—— 這些規則不需要我們的產品也成立，你拿去蓋自己的平台、或拿去審你正在用的平台，都一樣好用。
我們用這七條要求自己——和所有平台一樣，做得並不完美。而且任何平台在任何一天的真實狀態， 都變得比一篇部落格快。這正是規則比功能清單重要的原因：功能會過時， 規則隨時可以拿出來檢驗、對任何一家都成立。拿這七條來問我們，也拿去問任何你正在評估的平台。
上面那五題不用花錢就能問，答案幾乎就是你要知道的全部。想要有人陪你走一遍——邊界現在畫在哪、到底是什麼在保護什麼——我們提供免費的健檢諮詢。