여러 고객사가 같은 데이터베이스를 사용하는 SaaS에서는 모든 조회가 고객 경계를 지켜야 합니다. 애플리케이션 코드에 조건을 붙이는 것만으로는 누락 위험이 남습니다. PostgreSQL의 행 수준 보안은 DB 차원의 추가 경계가 될 수 있지만 올바른 세션 맥락과 테스트가 필요합니다.
고객 식별자를 데이터 모델에 넣는다
고객별로 분리해야 하는 테이블에 안정된 tenant ID를 두고 외래키 관계도 검토합니다. 고객과 공유하는 공개 데이터, 운영 관리자가 볼 수 있는 데이터는 별도 정책으로 구분합니다.
사용자가 요청에 넣은 tenant ID만으로 권한을 인정하지 않습니다. 로그인 신원과 조직 소속을 확인해 서버가 DB 세션의 맥락을 설정해야 합니다.
행 수준 정책의 범위를 이해한다
조회뿐 아니라 수정, 삭제, 삽입에도 정책이 적용되는지 확인합니다. 관리자 역할, 마이그레이션 계정, 테이블 소유자와 같은 예외 경로도 테스트합니다.
DB 정책을 만들었다고 캐시와 검색 색인, 파일 저장소가 자동으로 분리되는 것은 아닙니다. 데이터가 DB 밖으로 나가는 경로마다 고객 경계를 유지해야 합니다.
연결 풀의 세션 누수를 막는다
연결을 재사용할 때 이전 요청의 고객 맥락이 남으면 심각한 누출이 생깁니다. 트랜잭션 범위에서 값을 설정하고 종료 시 정리되는 방식을 선택합니다.
비동기 작업도 고객 맥락을 명시적으로 전달해야 합니다. 작업자가 현재 로그인 사용자나 전역 변수를 다시 읽지 않도록 합니다.
가상 사례: 관리자 보고서
운영자가 전체 고객 데이터를 집계하는 보고서를 만들었다고 가정해 봅시다. 일반 고객용 연결로 무리하게 정책을 우회하면 예외 권한이 서비스 전반에 퍼질 수 있습니다.
승인된 전용 경로와 최소 권한 계정을 두고 집계 범위와 접근 기록을 남깁니다. 이 사례는 가상의 운영 설계입니다.
교차 고객 테스트를 자동화한다
고객 A의 사용자로 B의 행 ID를 직접 요청하고, 조회·수정·첨부파일 접근을 각각 확인합니다. 정책이 없는 새 테이블을 추가하는 경우도 배포 검사에 넣습니다.
행 수준 보안은 유용한 경계이지만 단독 보안 보장은 아닙니다. 애플리케이션 권한과 저장소 전반의 격리를 함께 점검합니다.
현장에 적용할 때의 순서
- 고객별 행과 공유 행의 범위를 정한다
- DB 역할과 세션 맥락을 시험한다
- 캐시·검색·파일 경계를 확인한다
주의할 실패: 관리자 예외 역할을 일반 요청에 재사용하면 행 수준 정책이 기대와 다르게 작동할 수 있다.
관찰할 지표: 교차 고객 접근 시도와 정책 누락 테이블을 배포 때 검사한다.
적용 전 체크리스트
- 조회·쓰기·관리자 예외를 각각 검증하는가
- 연결 풀에서 고객 세션 맥락이 누수되지 않는가
- 캐시·검색·파일에도 같은 경계가 있는가
참고 자료
PostgreSQL Row Security Policies. PostgreSQL의 행 보안 정책 동작을 참고했습니다. 애플리케이션 세션 맥락과 저장소 간 격리는 별도 설계입니다.
이미지와 도식은 이해를 돕기 위한 개념 시각화입니다. 특정 고객의 실제 설비·데이터·화면을 재현한 것이 아닙니다.
#멀티테넌트 #RLS #PostgreSQL #SaaS보안 #테넌트격리 #접근제어 #데이터보안 #권한관리 #데이터베이스 #백엔드
