マルチテナントLLM分析と行レベルセキュリティ：AWSで安全なエージェントを構築する方法

PAR Technology Corporationはレストラン業界向けのテクノロジーを構築しており、独立系事業者から大規模なマルチブランドフランチャイズグループまで、300以上のレストラン事業をサポートしています。この多様な顧客ベースにおいて、データの価値を引き出すことで組織がより良い意思決定を行えるよう支援しています。私たちがセルフサービス分析用の自然言語テキストtoSQLエージェントの構築に着手したとき、目標は明確でした。技術的背景に関わらず、ビジネスユーザーが平易な英語で質問し、数秒で信頼できるデータに基づく回答を得られるようにすることです。しかし、その約束を果たすには、表面下にあるより複雑な課題を解決する必要がありました。

この記事では、PARがAWS SigV4による暗号化リクエスト署名、Amazon Bedrockでのセマンティック検証、Split-Plane SQLによるプログラム的データ分離という3層アーキテクチャを通じて、行レベルセキュリティを強制する本番環境対応のマルチテナントLLM分析システムを構築した方法を紹介します。各層が独立して動作し、LLM自体が侵害された場合でもテナント間のデータ漏洩リスクを低減する方法を示します。

核心的な問題は、データアクセス、正確性、セキュリティの交点にあります。私たちのシステムは、異なるビジネス、データセット、権限境界に結びついた数千人のユーザーを同時にサポートする必要があります。エージェントが生成するすべてのクエリは、正確であるだけでなく、そのユーザーがアクセスを許可されているデータに厳密に範囲を限定する必要があります。言い換えれば、課題はSQLを生成することだけではありません。毎回、適切なユーザーに対して、適切なデータスライスに対して、適切なSQLを生成することです。

2人のユーザーが同じ朝に分析エージェントを開き、まったく同じ質問「先週の総売上は？」をした場合を考えます。1人目はフランチャイズオーナーで、シカゴで2店舗を運営しています。彼にとっての正しい答えは84,000ドル（2店舗の合計）です。2人目はブランドマネージャーで、全国200店舗を統括しています。彼にとっての正しい答えは920万ドルです。同じ質問、同じデータベース、まったく異なる数字ですが、どちらも正しいです。フランチャイズオーナーに全国データを見せることは、データガバナンスの失敗であるだけでなく、他の事業者の機密情報を露出させる可能性があります。行レベルセキュリティの問題は、毎日何千ものクエリで発生し、すべてのクエリがその特定のユーザーに対して正しい数字を返さなければなりません。

当初、LLMに適切なフィルターを適用させることを試みましたが、問題はLLMが非決定的であることです。10,000回連続で正しく適用しても、10,001回目でフィルターを省略する可能性があります。コンシューマーアプリケーションでは非決定性は不便ですが、機密ビジネスデータを扱うマルチテナント分析システムでは、セキュリティ境界としては不十分です。アーキテクチャレベルでデータ境界を決定的に強制する必要がありました。

採用した3層アーキテクチャ：第1層、AWS SigV4による各API呼び出しの署名でリクエストの整合性を保証。第2層、Amazon Bedrockでのセマンティック入力検証で悪意あるクエリを防止。第3層、Split-Plane SQLアーキテクチャでデータベースレベルに行レベルセキュリティを強制。各層は独立して動作し、第1層や第2層が迂回されても第3層がデータ分離を保証します。

システムアーキテクチャは、推論エンジン（Amazon Bedrockベース）、スキーマルーター、SQLジェネレーター、Databricksクラスターで構成。すべての機密データは転送中および保存中に暗号化され、AWS KMSでキー管理、包括的な監査ログを有効化。AWSサービス統合はIAMロールと一時的な認証情報を使用し、長期キーは使用しません。

この設計により、LLMが侵害されてもデータ境界は安全です。実際のテストでは、悪意ある攻撃に対してシステムはテナント間のデータアクセスを効果的に防止しました。