多租户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被攻破，数据边界仍然安全。实际测试中，面对恶意攻击，系统能有效阻止跨租户数据访问。