AWS: 행 수준 보안과 Split-Plane SQL 암호화 데이터 경계를 갖춘 다중 테넌트 AI 에이전트

레스토랑 체인 관리 SaaS 기업 PAR Technology는 공유 시스템에서 300개 이상의 레스토랑 브랜드를 위한 AI 분석 에이전트를 구축했습니다. 요구 사항은 결정론적입니다: 프랜차이즈 소유자는 자신의 판매 데이터만 볼 수 있고(예: 두 지점에서 $84K), 브랜드 매니저는 전체 전국 데이터를 볼 수 있습니다($9.2M) — 동일한 쿼리, 동일한 데이터베이스, 완전히 다른 결과. AWS ML 블로그는 이 시스템의 아키텍처를 개념 증명이 아닌 프로덕션 솔루션으로 설명합니다.

세 가지 보호 계층: 서명부터 암호화 경계까지

다중 테넌트(멀티 테넌트) 환경은 여러 클라이언트가 동일한 데이터베이스 인프라를 공유한다는 것을 의미합니다. LLM 에이전트에서의 행 수준 보안(사용자별로 데이터베이스 행을 필터링하는 메커니즘)은 전통적으로 프롬프트 지시로 구현됩니다. 이는 모델이 프롬프트 인젝션 공격을 통해 무시하거나 우회할 수 있는 방법입니다.

AWS 아키텍처는 세 가지 결정론적 계층을 도입합니다. 1계층은 AWS Signature Version 4(SigV4)를 사용합니다: 각 API 호출에 테넌트 ID, 비즈니스 ID, 관리자 ID를 연결하는 암호화 서명. 페이로드를 수정하면 즉시 서명이 무효화됩니다. 2계층은 Amazon Bedrock을 의미론적 유효성 검사기로 사용합니다 — 쿼리가 SQL 생성기에 도달하기 전에 모델이 사용자의 질문이 명확하고 지원 가능한지 확인합니다. 『모두 보여줘』와 같은 비특정 요청은 거부됩니다. 3계층은 Split-Plane SQL입니다.

Split-Plane SQL이란 무엇이며 프롬프트 보호로는 왜 충분하지 않은가?

Split-Plane SQL(이중 SQL 생성 계획)은 쿼리 생성을 두 개의 독립적인 흐름으로 나눕니다. 보안 흐름은 승인된 행에만 데이터베이스 테이블을 사전 필터링하는 SQL 공통 테이블 표현식(CTE)을 생성합니다. 그런 다음에만 Amazon Bedrock이 기본 테이블의 스키마가 아닌 해당 임시 필터링된 뷰의 스키마를 받습니다. LLM은 생성된 SQL의 내용에 관계없이 물리적으로 샌드박스 외부의 데이터를 참조할 수 없습니다. 기존 방법과의 차이는 구조적입니다: 프롬프트 지시는 모델에게 무엇을 허용할지 알려주고; Split-Plane SQL은 아키텍처 수준에서 암호화적으로 그 경계를 시행합니다.

PAR Technology: 크로스 테넌트 노출 사고 없이 50,000건의 쿼리

프로덕션 구현은 클라이언트 간 데이터 누출 사고 없이 50,000건 이상의 쿼리를 처리했습니다. 인프라에는 네트워크 격리가 있는 Databricks 클러스터, TLS 1.3, 자동 키 교체가 있는 AWS KMS 암호화, 이상 감지가 있는 CloudTrail 감사 로그가 포함됩니다. AWS는 아키텍처의 근본 원칙을 요약합니다: 『LLM은 아키텍처 위가 아닌 내부에 있습니다.』