多租户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被攻破，數據邊界仍然安全。實際測試中，面對惡意攻擊，系統能有效阻止跨租户數據訪問。