Your LLM Stack Is a 2008 Database With Better Marketing — Lovina Dmello, NVIDIA

生產環境中 ML 系統的安全危機常被描繪成高深莫測，但實情更具警醒意義：幾乎所有嚴重事件源自基礎設施的配置錯誤。講者以 2023 年 Ray 框架事件開場——安全研究人員發現數千個分布式 ML 集群完全暴露，儀表板與任務 API 對所有人開放，涉及超過 10 億美元資產。驚人的是，這不是什麼零日漏洞或針對神經網路的巧妙攻擊，僅因為部署團隊在上線時忘記啟用默認的身份驗證功能。這個案例揭示了當今 ML 安全的根本矛盾。

傳統軟體應用與 ML 系統的架構差異根本改變了威脅模型。2008 年的應用是確定性的、單租戶的，安全團隊對需要保護什麼有清晰認知。但 ML 系統的行為具有概率性，訓練好的權重本身可被複製，而為降低成本，企業將多個客戶的工作負載打包在同一塊 GPU 上——這些設計決策直接引入了全新的安全風險，卻沒有相應更新安全假設。問題的癥結在於架構：防禦措施由安全專家為安全專家設計，然後交由 ML 團隊部署和維護，而 ML 團隊的核心職責是確保模型準確度而非基礎設施安全。這種角色錯位導致保護措施往往嵌在平台深處，可能因某項配置而被無意中關閉。

研究數據深化了這一現象：對 50 個真實生產環境的審計發現，78% 至少存在一個嚴重安全漏洞。令人震驚的是，反覆出現的問題只有三個——都不涉及複雜技術。第一，權限管理失效，任何帳戶都能執行任何操作；第二，系統缺乏分割隔離，攻擊者一旦入侵任意部分就能控制全部；第三，密鑰與訓練模型檔案暴露在任何人都可訪問的儲存中。這些不是設計缺陷，而是部署前的安全衛生習慣未遵循。

防御的實施面臨一個根本的工程權衡：每項控制措施都會增加成本。在 ML 系統中，延遲與吞吐量是關鍵 SLA 指標。基礎防御（登入、輸入檢查等）成本低於 8%，應無處不在；隔離防御（將工作流彼此隔離）成本 10-20%，可對敏感和不受信任的工作負載選擇性部署；實時檢測防御（即時捕捉惡意輸入）成本 15-30%，因會減慢每個請求，對延遲敏感的系統難以承受。講者強調，指導原則不是「應否實施」，而是「如何以合理成本實施」——目標是讓廉價防御無處不在，昂貴防御專用於高風險系統。同時，實施成本高度取決於構建品質；同樣的檢查，若做得馬虎會導致響應時間翻倍，若處理得當則成本公平合理。

當前實踐的挑戰不在於防御理論的有效性，而在於其成熟度與可部署性。ML 安全工具比傳統軟體安全落後多年——普通軟體團隊幾十年前已透過自動化掃描和密碼管理解決的問題，ML 領域至今未全面應用。專業知識孤島加劇了這個問題：安全團隊不懂 ML、ML 團隊不懂安全、運維團隊不了解模型運作，這些缺口正是漏洞不斷發生的根源。此外，研究與現實存在根本脫節——研究者忙著防範細微的對抗性擾動，現實中卻在對付被盜密鑰與已獲得訪問權限的內部人員濫用。

講者提出的解決方案是採用成熟度模型（對標 NIST AI 風險管理框架）系統評估組織現狀。模型分四個級別，對應不同的防御投資與複雜度。第二級（5-10% 開銷）是生產的最低標準，包含正確的認證、加密、網路隔離與基礎監控。大多數團隊自認處於第三級，實際上多數在第一或第二級。修復的優先清單包括三項核心配置錯誤：首先，實施最小權限原則，每個帳戶只做必要操作，凭证應有有效期限；其次，用防火牆和服務間身份驗證取代平直的網路拓撲，使系統各部分之間需要認證才能通信；第三，使用專業的密鑰管理器、加密和自動掃描在代碼出廠前防止密鑰和模型檔洩露。這些並非新穎防御，而是基本卫生习惯——正是這種基本做法能防止那些真正登上新聞的違規事件。