역할만으로는 리소스를 지킬 수 없다

한 줄 요약

인증은 요청 주체를 확인하고 인가는 그 주체가 이 조직의 이 리소스에 이 동작을 할 수 있는지 판단한다. writer 역할 하나만 검사하면 같은 역할을 가진 사용자가 다른 사람의 주문을 읽고 바꾸는 수평 권한 상승이 생긴다.

왜 역할 검사가 불충분한가

역할 기반 접근 제어는 기능 범위를 좁히지만 리소스 관계를 표현하지 못한다. Alice와 Bob이 모두 writer여도 Bob이 Alice의 주문을 취소할 이유는 없다. 조직 관리자도 자기 조직 안에서만 관리 권한을 가져야 한다. 따라서 주문의 owner_id와 org_id, 신원의 sub, org_id, role, 요청 동작을 함께 비교한다. 다른 조직이면 관리자라도 먼저 거부하고, 같은 조직이면 소유자 또는 허용된 관리자 정책을 적용한다.

인증 부재는 401, 인증됐지만 관계가 맞지 않으면 403이다. 존재하지 않는 리소스와 권한 없는 리소스의 응답을 같게 만들어 열거 공격을 줄일지 여부도 정책으로 정한다. 이번 과제의 읽기 경계는 권한 없는 ID를 403으로 일정하게 처리한다. 테스트는 같은 조직의 다른 소유자, 다른 조직의 관리자, 정상 소유자 세 가지를 반드시 포함한다.

현장에서 놓치기 쉬운 누출

인증 헤더 전체를 로그에 찍거나 토큰 파싱 오류에 원문을 포함하면 관측 시스템이 비밀 저장소가 된다. 모듈 import 시 디버그 print가 실행되는 것도 채점기나 워커 로그에 민감한 환경값을 흘릴 수 있다. 라이브러리 import는 조용해야 하고, 오류 응답은 unauthorized, forbidden처럼 분류만 제공한다. 감사 로그에는 토큰 대신 비민감 주체 ID와 정책 결과를 기록한다.

실무 판단 기준

권한 테스트는 “writer가 성공한다”에서 끝나면 안 된다. 가장 위험한 이웃 관계와 테넌트 경계를 반례로 고정해야 한다. 리소스 소유권은 데이터베이스 조회 조건에도 포함해 애플리케이션 검사와 저장소 범위가 어긋나지 않게 한다. 다음 모듈에서는 이런 거부와 성공을 같은 trace 문맥으로 관찰하되 비밀은 남기지 않는 방법을 다룬다.