멀티테넌트 격리: 판단 데이터 보안 설계

멀티테넌시와 데이터 격리란 무엇인가

멀티테넌시(multi-tenancy)는 하나의 소프트웨어 인스턴스를 여러 고객(테넌트)이 공유하는 구조입니다. 자원을 함께 써 비용은 낮아지지만, 한 테넌트의 데이터가 다른 테넌트에게 보이지 않도록 막는 일이 보안의 출발점이 됩니다. 이 경계 보장이 데이터 격리(data isolation)입니다.

Amazon Web Services는 테넌트 격리를 비용·운영 부담과 보안 강도 사이의 스펙트럼으로 봅니다. 가장 가벼운 방식은 모든 테넌트가 같은 테이블을 공유하되 행마다 테넌트 식별자(tenant_id)를 붙여 구분하는 풀(pooled) 모델이고, 더 무거운 방식은 테넌트마다 스키마나 데이터베이스를 분리하는 모델입니다. 핵심은 어느 모델이든 모든 계층에서 테넌트 맥락을 강제하는 것입니다.

다층 방어 — 한 겹에 기대지 않는다

격리를 단일 장치에 맡기면 그 장치 하나가 뚫릴 때 전체가 무너집니다. 그래서 보안 표준은 여러 겹을 겹쳐 쌓는 심층 방어(defense-in-depth)를 권합니다. OWASP의 멀티테넌트 보안 치트시트와 AWS, Redis의 격리 가이드는 공통적으로 데이터 접근 계층마다 테넌트 소유권을 검증하고, 데이터베이스 차원의 행 수준 보안(Row-Level Security) 같은 장치를 보조 방어선으로 둘 것을 권합니다.

• 모든 쿼리·캐시 키·저장 경로에 테넌트 식별자를 포함한다
• 데이터 접근 계층에서 테넌트 소유권을 한 번 더 검증한다
• 행 수준 보안(RLS) 등 DB 엔진 차원의 격리를 보조 방어선으로 둔다
• 모든 작업 로그에 테넌트 맥락을 함께 기록한다

외부 마스킹과 감사 추적 — 판단을 지키는 두 장치

격리가 '누가 보느냐'를 다룬다면, 마스킹은 '무엇을 보여 주느냐'를 다룹니다. 데이터 마스킹은 개인정보 같은 민감 데이터를 실제 값 대신 현실적인 가짜 값으로 가려, 사용성은 유지하면서 노출을 막는 기법입니다. 내부에서는 원문 그대로 쓰되 외부로 나가는 경계에서만 마스킹하는 방식으로, GDPR 같은 규정 준수와 실무 효율을 동시에 잡을 수 있습니다.

감사 추적(audit trail)은 누가 언제 어떤 데이터에 접근했는지를 기록으로 남깁니다. 데이터 마스킹과 감사 로그는 함께 작동해 민감 데이터 접근의 추적 가능한 기록을 만들고, GDPR 제30조의 처리활동 기록 의무 같은 규제 대응의 근거가 됩니다. 판단은 조직의 핵심 자산이므로, 누가 그 판단을 열어 봤는지까지 남기는 일이 격리 못지않게 중요합니다.