多租戶LLM分析的行級安全：我們在AWS上構建安全代理的方法

PAR Technology Corporation為餐飲行業構建技術，支援超過300家餐飲企業，從獨立經營者到大型多品牌特許經營集團。在這些多樣化客戶群中，我們透過釋放資料價值幫助組織做出更好的決策。當我們開始構建用於自助分析的自然語言文本轉SQL代理時，目標很明確：讓業務使用者（無論技術背景如何）能夠用通俗英語提出業務問題，並在幾秒內獲得可靠的資料支援答案。然而，實現這一承諾需要解決表面之下更復雜的挑戰。

本文展示了PAR如何構建一個生產級的多租戶LLM分析系統，透過三層架構強制執行行級安全：使用AWS SigV4的加密請求籤名、Amazon Bedrock上的語義驗證以及透過Split-Plane SQL實現程式化資料隔離。我們將展示每層如何獨立運作，以降低跨租戶資料暴露的風險，即使LLM本身被攻破或操控。

核心問題在於資料訪問、正確性和安全性的交集。我們的系統必須同時支援數千使用者，每個使用者關聯不同的業務、資料集和許可權邊界。代理生成的每個查詢不僅必須準確，而且必須嚴格限制在該使用者被授權訪問的資料範圍內。換句話說，挑戰不僅僅是生成SQL，而是每次為正確的使用者、針對正確的資料切片生成正確的SQL。

以兩個使用者同時開啟分析代理並詢問完全相同的問題為例：“上週總銷售額是多少？”第一個使用者是特許經營商，在芝加哥經營兩家門店，正確答案是84,000美元（兩家門店總和）。第二個使用者是品牌經理，負責全國200家門店，正確答案是920萬美元。相同問題、相同資料庫，但不同數字，兩者都正確。向特許經營商顯示全國資料不僅是資料治理失敗，還可能暴露其他運營商的商業敏感資訊。而行級安全挑戰每天都在我們的系統中發生，每次查詢都必須返回該特定使用者的正確數字。

最初，我們試圖讓LLM應用正確的過濾器，但問題是LLM是非確定性的。它們可能在一萬次正確應用後突然遺漏過濾器，或產生幻覺。在消費品應用中，非確定性是不便，但在處理敏感業務資料的多租戶分析系統中，它不足以作為安全邊界。我們需要從架構層面確定性強制執行資料邊界。

我們採用的三層架構：第一層，透過AWS SigV4對每個API呼叫進行簽名，確保請求完整性；第二層，在Amazon Bedrock上進行語義輸入驗證，防止惡意查詢；第三層，透過Split-Plane SQL架構在資料庫層強制執行行級安全。每層獨立運作，即使前兩層被繞過，第三層仍能保障資料隔離。

系統架構包括：推理引擎（基於Amazon Bedrock）、模式路由器、SQL生成器和Databricks叢集。所有敏感資料在傳輸和靜態時都加密，使用AWS KMS管理金鑰，並啟用全面審計日誌。AWS服務整合使用IAM角色和臨時憑證，無長期金鑰。

透過這種設計，我們確保即使LLM被攻破，資料邊界仍然安全。實際測試中，面對惡意攻擊，系統能有效阻止跨租戶資料訪問。