멀티테넌트 SaaS에서 로그인과 역할 검사를 통과했다고 고객 데이터가 안전하게 분리되는 것은 아닙니다. 테넌트 경계는 목록 조회, 파일 다운로드, 백그라운드 작업, 캐시까지 이어져야 합니다.
테넌트 문맥의 출처를 정한다
클라이언트가 보낸 tenant_id를 그대로 믿으면 다른 고객 ID를 넣어 조회할 수 있습니다. 인증된 사용자와 서버 측 소속 관계에서 테넌트 문맥을 확정하고, 요청 내 모든 데이터 접근에 같은 문맥을 사용합니다.
조회뿐 아니라 쓰기 경로도 점검한다
목록 화면은 필터를 걸었지만 상세 URL, CSV 내보내기, 첨부 파일 다운로드에는 필터가 빠지는 일이 있습니다. 생성·수정·삭제 대상의 소속도 확인하고, 외부 저장소 키만 알면 열리는 파일 URL을 피합니다.
비동기 작업에 문맥을 전달한다
보고서 생성, 이메일 발송, 검색 색인 작업은 HTTP 요청이 끝난 뒤 실행됩니다. 큐 메시지에 검증 가능한 테넌트 문맥과 작업 ID를 포함하고, 워커도 대상 소속을 다시 확인합니다. 관리자 계정의 넓은 권한을 일반 작업에 재사용하지 않습니다.
캐시와 검색이 경계를 넘는지 본다
캐시 키에 테넌트 식별자가 빠지면 다른 고객의 결과가 섞일 수 있습니다. 검색 색인도 테넌트 필터를 서버에서 강제합니다. 경계를 DB 쿼리 한곳에만 의존하지 않고 다운로드, 캐시, 로그의 데이터 경로를 전체 점검합니다.
교차 접근 테스트를 자동화한다
두 테스트 테넌트에 비슷한 문서를 만들고 다른 테넌트의 ID로 상세 조회·수정·내보내기·파일 접근을 시도합니다. 정상 요청 성공뿐 아니라 금지 요청 실패를 회귀 테스트에 넣어야 배포 때 경계가 무너지지 않습니다.
현장에 적용할 때의 순서
- 인증에서 테넌트 문맥 확정
- 모든 데이터 경로에 경계 적용
- 교차 접근 회귀 테스트
주의할 실패: 목록만 필터링하고 파일은 공개
관찰할 지표: 교차 접근 차단 테스트 통과율
적용 전 체크리스트
- 테넌트 ID를 인증 문맥에서 확정하는가
- 파일·캐시·비동기 작업에도 같은 경계를 적용하는가
- 교차 테넌트 접근 테스트가 자동화되어 있는가
참고 자료
AWS SaaS Tenant Isolation Strategies. 인증과 테넌트 격리가 다른 통제라는 원칙을 참고했습니다. 구현은 서비스 아키텍처별로 달라집니다.
이미지와 도식은 이해를 돕기 위한 개념 시각화입니다. 특정 고객의 실제 설비·데이터·화면을 재현한 것이 아닙니다.
#멀티테넌트 #SaaS보안 #테넌트격리 #접근제어 #B2B소프트웨어 #데이터보호 #API보안 #백그라운드작업 #캐시보안 #보안테스트
