로그인은 되는데 다른 고객의 주문이 보인다: 멀티테넌트 권한 검증

문제와 판단 기준

2026년 9월 26일 기준

A 고객사의 직원으로 로그인해 주문을 열었는데 B 고객사의 주문이 보입니다. 로그인은 성공했고, API도 정상 응답을 보냈습니다. 설계 예시인 이 상황에서 확인해야 할 것은 비밀번호가 아닙니다. 서버가 그 직원에게 그 주문에 대한 그 행동을 허용해도 되는지 판단했는가입니다.

멀티테넌트 권한 테스트는 사용자와 역할만 바꾸어 끝내면 안 됩니다. 사용자·역할 × 테넌트 × 객체 × 행위를 조합하고 상세 화면에서 파일과 백그라운드 작업까지 같은 경계가 유지되는지 확인해야 합니다. 로그인 성공이나 유효한 토큰은 객체 접근 허가의 충분조건이 아닙니다.^[1][2]

이 글은 여러 고객 조직이 하나의 SaaS를 사용하는 주문 시스템을 예로 듭니다. 아래 계정·주문·권한 정책은 모두 합성한 설계 예시입니다. 실제 고객이나 보안 사고를 나타내지 않습니다. 검증은 소유자가 허용한 격리된 테스트 환경에서만 수행합니다.

로그인, 역할, 주문, 고객사의 경계를 따로 묻는다

인증은 사용자가 누구인지 확인하는 과정입니다. 권한 검증은 그 사용자가 어떤 자원에 어떤 작업을 할 수 있는지 결정합니다. 테넌트는 이 글에서 고객 조직별 데이터와 권한의 경계입니다. 같은 인프라를 공유하더라도 조직 간 접근 제한은 명시적으로 설계해야 합니다.^[1][3]

주문 API에서는 다음 질문을 나누어 확인합니다.

OWASP API Security Top 10의 2023판은 객체 접근 문제를 BOLA, 허용되지 않은 기능 실행 문제를 BFLA로 구분합니다. 주문 조회 기능을 쓸 수 있어도 모든 주문을 읽을 수 있다는 뜻은 아닙니다. 객체 ID가 UUID처럼 추측하기 어려워도 접근 검사는 필요합니다.^[2][4]

객체 전체를 허용한 뒤에도 한 단계가 남습니다. 주문은 읽어도 내부 메모는 읽을 수 없거나, 메모는 수정해도 tenant_id와 owner_id는 바꿀 수 없어야 할 수 있습니다. OWASP의 객체 속성 수준 권한 문제(BOPLA)는 이런 필드별 읽기·쓰기 제한을 다룹니다.^[5]

먼저 우리 서비스의 허용 규칙을 고정한다

“다른 직원의 주문은 모두 차단”도 보편적인 정답은 아닙니다. 공동 담당자나 조직 관리자가 접근해야 하는 서비스라면 그 접근은 정상입니다. 허용 규칙 없이 거부 사례만 늘리면 정상 업무까지 막는 구현을 통과시킬 수 있습니다.

OWASP ASVS 5.0.0의 V8은 기능·데이터·필드별 권한 규칙의 문서화와 적용, 테넌트 간 통제를 구분합니다. 이를 테스트 표로 옮길 때에는 역할 이름보다 어떤 관계 때문에 허용되는지를 적는 편이 낫습니다.^[6]

설계 예시: 주문 시스템의 정책과 합성 데이터

테넌트 A에는 일반 회원 U_A1, U_A2, 관리자 ADM_A, 열람자 VIEW_A가 있습니다. 테넌트 B에는 회원 U_B1과 관리자 ADM_B가 있습니다. 주문 O_A1, O_A2, O_B1은 각각 U_A1, U_A2, U_B1 소유이며 해당 테넌트에 속합니다. 모두 테스트용 초안 주문이며 검색용 이름에는 “합성”이 들어갑니다. 회원·조직관리자·열람자의 조회 응답 필드는 order_id, status, memo로 한정합니다.

이 예시에서는 일반 회원에게 자기 주문 조회·생성·메모 수정을 허용합니다. 조직 관리자는 자기 테넌트의 주문 조회·메모 수정·초안 삭제·내보내기를 수행합니다. 열람자는 배정된 주문만 읽으며, VIEW_A에게는 O_A1만 배정합니다. 같은 테넌트라는 이유만으로 일반 회원끼리 주문을 공유하지는 않습니다.

지원 담당자 SUPPORT_X는 기본 접근권이 없습니다. 별도의 승인이 유효한 동안에만 O_A1의 주문 ID와 상태를 읽을 수 있으며 수정·삭제·내보내기는 할 수 없다고 정합니다. 실제 서비스에 더 넓은 지원 권한이 필요하다면 별도의 승인 범위로 문서화해야 합니다.

테넌트와 소유자 변경은 일반 주문 수정에서 허용하지 않습니다. 일괄 수정은 대상 중 하나라도 권한이 없으면 전체를 거부하는 정책을 선택합니다. 아래 각 사례는 데이터를 초기 상태로 복원한 뒤 독립적으로 확인합니다.

사용자·역할 × 테넌트 × 객체 × 행위를 표로 채운다

다음은 앞의 정책에서 도출한 대표 검증 사례입니다. 공식 표준의 전체 항목이나 실행 완료 결과가 아닙니다. OWASP의 권한 테스트 가이드는 역할·기능·데이터 차원의 매트릭스와 여러 테스트 계정을 이용한 검증을 제시합니다. 여기서는 그 접근을 주문과 고객사 경계에 맞춰 구체화했습니다.^[7][8]

상세 조회와 변경

목록, 일괄 처리, 생성과 지원 접근

M14의 전체 거부는 이 예시의 선택입니다. 서비스가 부분 성공을 지원한다면 허용된 객체만 처리하고 거부된 객체의 내용·변경·부작용이 없다는 별도 기대 결과를 정해야 합니다. 첫 번째 객체만 검사한 뒤 나머지를 처리하는 방식은 어느 정책에도 맞지 않습니다.

거부 응답을 403으로 할지, 존재 여부를 감추기 위해 404로 할지는 API 정책에 맞춰 정합니다. 상태 코드 하나를 권한 검증의 합격 기준으로 삼지는 않습니다. 응답에 데이터가 남거나 저장소가 이미 바뀌었다면 거부한 것이 아닙니다. 역할별로 응답의 비공개 데이터와 실제 동작을 확인하는 접근은 WSTG의 권한 우회 테스트에서도 다룹니다.^[9]

클라이언트의 tenant_id는 선택값이지 권한 증거가 아니다

여러 조직에 가입한 사용자가 화면에서 조직을 선택하는 것은 정상적인 기능입니다. 문제는 서버가 그 선택을 검증 없이 믿는 경우입니다. URL, 요청 본문, 헤더로 받은 테넌트 식별자는 선택한 조직을 알려 줄 뿐, 그 조직에서 행동할 권리를 증명하지 않습니다. 서버는 인증된 주체의 현재 멤버십이나 서비스 권한과 연결해 접근 맥락을 검증해야 합니다.^[10]

검증할 요청 흐름은 다음처럼 잡을 수 있습니다. 아래는 구현 언어에 종속되지 않는 설계 순서의 예시입니다.

세션·토큰 검증 → 선택한 테넌트의 현재 권한 확인 → 행위와 객체 관계 확인 → 허용 필드 결정 → 조회·변경 → 허용 결과만 전달

객체 조회에는 객체 ID뿐 아니라 검증된 테넌트와 필요한 소유·배정 조건을 함께 적용합니다. 여러 조직에 가입한 사용자는 각 조직의 권한을 따로 확인하며 A에서 가진 관리자 역할을 B의 선택 맥락에 그대로 넣지 않습니다. 멤버십을 확인할 수 없거나 접근 맥락이 누락되면 전체 데이터로 조회 범위를 넓히지 말고 실패하도록 설계합니다.

Next.js App Router를 예로 들면 공식 인증 가이드는 Proxy의 빠른 사전 검사와 데이터 접근 계층(DAL)의 권한 검사를 구분합니다. Server Actions도 공개 API와 같은 보안 고려가 필요하며 자체 권한 검사를 해야 한다고 설명합니다. 화면에서 버튼을 숨기는 것만으로 직접 호출을 막았다고 볼 수 없습니다. 가이드의 세션·역할 예제를 적용했더라도 주문 소유권과 테넌트 멤버십 규칙은 서비스에 맞게 추가해야 합니다.^[11]

권한이 바뀐 뒤 같은 세션으로 다시 확인한다

로그아웃 후 다시 로그인하는 테스트만으로는 오래된 권한이 남는 문제를 찾기 어렵습니다. 토큰을 발급받은 다음 멤버십이나 역할을 바꾸고, 기존 세션·토큰을 유지한 요청으로 확인해야 합니다. ASVS 5.0.0의 8.3.2는 권한 결정에 쓰이는 값의 변경 반영을 다룹니다. 자기완결형 토큰 등으로 즉시 반영할 수 없는 경우의 보완 통제도 정보 유출 자체를 되돌리지는 못한다고 명시합니다.^[6]

다음은 권한 변경이 확정된 뒤 시작하는 다음 검사부터 새 정책을 적용한다고 정한 설계 예시입니다. 이미 실행 중인 요청과 이미 전달된 데이터는 별도로 다룹니다. 권한 정보에 전파 지연이 있는 시스템이라면 허용 지연, 위험, 차단 장치를 먼저 결정하고 그 경계를 시험해야 합니다. 단순히 “토큰이 만료될 때까지”를 이유 없이 허용 시간으로 삼지는 않습니다.

지원 접근에서는 고객 계정으로 가장해 흔적을 지우지 말고, 실제 지원 담당자와 대신 수행한 범위가 구분되도록 감사 기록을 설계합니다. 테넌트, 대상 객체, 허용 행위, 승인 만료와 철회가 함께 검증 대상입니다.

상세 화면 밖으로 같은 규칙을 따라간다

권한 표를 완성했다면 각 사례가 지나가는 경로를 확인합니다. 아래는 M01–M20과 T01–T05를 적용할 경로별 검증 설계입니다. 같은 API 정책을 사용한다고 선언했다는 이유로 다른 경로의 검사를 생략하지 않습니다.^[1]

이 예시의 비동기 내보내기는 사용자를 대신하는 작업입니다. 워커의 DB 계정에 전체 접근권이 있다고 해서 사용자도 전체 데이터를 내보낼 수 있는 것은 아닙니다. ASVS 5.0.0의 8.3.3은 중개 서비스의 권한을 원래 요청자의 권한 대신 사용하지 않도록 요구합니다.^[6]

사용자의 클릭과 무관한 정기 정산·백업처럼 서비스 자체 권한으로 수행하는 작업은 정책이 다를 수 있습니다. 그 경우에는 작업의 권한 주체, 대상 테넌트, 데이터 범위, 결과를 받을 사람을 별도로 승인합니다. 두 종류의 작업을 “백그라운드니까 관리자 권한”이라는 한 규칙으로 합치지 않는 것이 이 글의 설계 제안입니다.

캐시 키를 나누어도 권한 검사는 남는다

보호된 캐시를 읽기 전에 요청을 승인해야 합니다. 캐시 값이나 접근 범위가 테넌트별로 달라진다면 키에도 그 구분이 필요합니다. 같은 테넌트 안에서도 결과가 사용자·허용 필드·권한 버전에 따라 달라질 수 있습니다. 반대로 모두에게 동일하게 공개되는 기준 데이터까지 무조건 사용자별로 복제할 필요는 없습니다.^[10]

검증 설계 예시: 먼저 U_A1이 자기 주문을 읽어 캐시를 채웁니다. 이어 U_A2와 U_B1로 같은 합성 객체를 요청해 원문이 섞이지 않는지 확인합니다. 그다음 U_A1의 멤버십을 제거하고 캐시가 남아 있는 상태에서 재요청합니다. 냉각된 캐시에서만 성공하는 권한 테스트는 이 조건을 검증하지 못합니다.

여기서 확인하는 것은 애플리케이션의 권한 경계입니다. 브라우저·CDN의 저장 허용, TTL과 재검증 정책까지 한 가지 캐시 설정으로 해결된다고 가정하지 않습니다.

서명된 다운로드 링크는 별도의 접근 경로다

Amazon S3의 presigned URL은 소지자가 사용할 수 있는 bearer token 성격의 링크이며 유효한 동안 여러 번 사용해도 유효합니다. URL의 유효성에는 만료 시각뿐 아니라 서명에 사용한 자격 증명과 권한도 영향을 줍니다.^[12]

이 동작에서 도출되는 설계상 주의점은 명확합니다. 앱의 A 멤버십을 지웠다는 사실만으로 기존 S3 링크도 무효가 됐다고 가정해서는 안 됩니다. 새 링크를 발급하는 API를 막았는지와, 이미 발급된 링크를 가지고 파일을 받을 수 있는지는 서로 다른 시험입니다.

권한 회수 뒤의 신규 다운로드도 즉시 막아야 한다면, 매번 현재 권한을 확인하는 다운로드 경로나 실제로 적용 가능한 폐기 통제를 설계하고 검증해야 합니다. 짧은 만료 시간만으로 즉시 차단을 보장할 수는 없습니다. 또한 S3는 요청 시작 시 만료를 검사하므로 만료 전에 시작한 다운로드가 계속될 수 있습니다. 이미 내려받은 사본까지 권한 회수로 되찾을 수 있다는 뜻도 아닙니다.^[12]

DB의 RLS는 보강 수단이지 모든 경로의 자동 해결책은 아니다

PostgreSQL 17의 행 수준 보안(RLS)은 행별 접근을 제한할 수 있지만 슈퍼유저와 BYPASSRLS 역할은 우회합니다. 테이블 소유자도 일반적으로 우회하며 FORCE ROW LEVEL SECURITY로 다르게 설정하는 것도 가능합니다. 읽기와 변경 조건도 구분됩니다. 따라서 관리자 계정에서만 시험하지 말고 애플리케이션이 실제 사용하는 DB 역할과 정책으로 조회·삽입·수정을 확인해야 합니다.^[13]

RLS를 사용해도 이미 외부로 복사된 검색 결과, 캐시, 파일의 권한을 자동으로 증명하지는 못합니다. 반대로 RLS를 사용하지 않는 구조를 이 글만으로 취약하다고 판단할 수도 없습니다. 애플리케이션의 일관된 정책 적용, 스키마·DB 분리 등 선택한 구조가 요구 경계를 만족하는지 검증하는 것이 먼저입니다.

테스트는 응답과 실제 결과를 함께 남긴다

먼저 환경 소유자와 대상 시스템·계정·시간·허용 행위를 합의합니다. 운영 데이터 복사 대신 합성 데이터를 넣고, 결제·메일·웹훅은 외부 고객에게 나가지 않는 테스트 수신처로 연결합니다. 테스트할 객체 식별자는 준비한 데이터에서 가져옵니다. 실제 서비스의 다른 사용자 ID를 열거하거나 추측해 찾지 않습니다.

그다음 각 거부 사례와 가까운 허용 사례를 한 쌍으로 확인합니다. M02가 차단됐다는 결과에는 M01의 정상 조회가 함께 있어야 하고 M14의 일괄 거부에는 M13의 정상 일괄 처리가 함께 있어야 합니다. 인증 실패로 모든 요청이 막힌 환경을 권한 구현이 안전한 환경으로 오인하지 않기 위해서입니다. 비로그인 요청과 로그아웃 후 요청도 별도의 세션 시험으로 추가합니다.^[9]

증거에는 사용한 정책·빌드·테스트 데이터 버전, 요청 주체와 테넌트, 대상 객체, 행위, 기대 결과, 실제 응답, 저장 전후 차이와 후속 이벤트를 연결합니다. 응답에 다른 주문이 없는지만 보지 말고 허용된 주문이 정확히 나오는지도 확인합니다. M14라면 예시 정책상 변경 행 수와 업무 이벤트 수는 모두 0이어야 하지만 적절한 거부 감사 기록까지 없어야 하는 것은 아닙니다.

권한 구현 자체를 가짜 승인 함수로 바꾼 테스트만으로 끝내지 않습니다. 실제 인증·권한 경로와 애플리케이션의 DB 역할을 사용하는 통합 검증을 포함하고 외부 부작용만 통제할 수 있도록 환경을 준비합니다. 수정 후에는 실패한 한 요청뿐 아니라 같은 정책을 공유하는 조회·변경·파일·작업 경로와 정상 접근을 다시 확인하는 방식으로 회귀 범위를 잡습니다.

선택한 권한 사례와 제외 이유는 변경별 회귀 테스트 범위 결정 워크북에 연결해 기록합니다. 이 글의 표는 권한별 기대 동작을 정하는 예시이고 워크북은 어떤 검증을 실행하거나 제외했는지 남기는 자료입니다.

합격 기준은 “로그인됨”이 아니라 “허용한 범위와 일치함”이다

먼저 팀이 현재 권한 정책과 합성 데이터를 준비할 수 있다면 기존 테스트 도구로 시작할 수 있습니다. 도구를 새로 구매해야만 매트릭스를 만들 수 있는 것은 아닙니다. 복잡한 위임, 여러 서비스의 권한 전파, 즉시 철회가 필요한 파일 전달처럼 팀이 경계를 설명하기 어려운 부분은 추가 설계 검토의 대상으로 남깁니다.

이 글이 제안하는 출시에 대한 판단 기준은 다음과 같습니다. 다른 고객 데이터가 노출되거나 변경되는 사례는 전체 테스트 통과율로 상쇄하지 않습니다. 원인과 영향 경로를 수정한 뒤 거부와 정상 접근을 함께 재확인합니다. 확인하지 못한 경로는 통과로 바꾸지 않고 남은 위험으로 기록합니다. 이 과정을 거쳤다는 것과 모든 취약점이 없다는 보증은 다릅니다.

권한 시나리오와 검증 범위를 외부 팀과 함께 검토하려면 IXC QA 아웃소싱 서비스의 지원 범위를 확인할 수 있습니다. 수행할 계정·데이터 경계·경로와 산출물은 착수 전에 합의합니다.