접근통제와 객체 단위 권한 검사

01개념과 구성 요소

• 인가인증된 주체가 특정 자원에 특정 행동을 할 수 있는지 서버가 결정한다.
• 정책 입력사용자·역할·소유자·업무 상태·요청 환경을 필요한 범위에서 판단에 사용한다.
• 보호 범위관리 기능뿐 아니라 개별 객체·필드·파일·상태 전이도 권한 검사 대상이다.

02주문 조회 요청을 처리하는 인가 순서

1. 주체 확정검증된 세션에서 user_id를 얻는다. 요청 본문이 주장하는 사용자 ID를 인증된 주체로 대신 쓰지 않는다.
2. 작업과 대상 식별조회할 주문 ID와 수행할 행동을 분리한다. ID를 안다는 사실은 접근권을 뜻하지 않는다.
3. 허용 범위로 조회서버 정책에 따라 주문 ID와 소유자 또는 허용 역할을 함께 조건으로 사용한다.
4. 상태·필드 검사업무 상태와 민감한 응답 필드의 공개 범위를 평가한다. 상태 변경이 있다면 검사와 변경의 경쟁 조건도 통제한다.
5. 결과 반환과 감사허용한 필드만 반환하거나 거부하고, 검증된 주체·대상·행동·결정 이유를 감사 기록으로 연결한다.

03로그인 성공 뒤에도 권한 검사는 계속된다

• 인증·인가인증은 요청 주체를 계정에 연결하고 인가는 그 계정이 특정 자원에 특정 행동을 해도 되는지 결정한다. 관리자 URL을 일반 사용자 세션으로 열었을 때 관리 기능이 실행된다면 역할별 인가가 빠진 경로일 수 있다.
• 로그인과 권한일반 사용자도 로그인되어 있으므로 핵심은 비밀번호를 몰랐다는 것이 아니라 서버가 역할에 맞는 권한을 집행하지 않았다는 점이다.
• UI와 요청HTTP 경로가 관리자 메뉴에 표시되지 않아도 요청은 직접 만들어질 수 있다. 따라서 버튼 숨김이나 클라이언트 자바스크립트의 role 검사만으로 접근제어를 구현할 수 없다.
• 서버 집행실제 데이터를 반환하거나 변경하는 서버 처리 경로가 검증된 계정과 정책에 따라 행동을 결정해야 한다.

04수평·수직 권한 오류와 객체 단위 검사

• 수평 오류수평 권한 오류는 같은 역할의 사용자 사이에서 타인의 데이터에 접근하는 경우다. /orders/42를 조회하는 정상 기능이 있다고 해도 주문 42의 소유자가 현재 사용자여야 한다는 조건이 별도로 필요하다.
• 수직 오류수직 권한 오류는 일반 사용자가 승인·사용자 삭제 같은 관리자 기능을 실행하는 경우다.
• 객체 식별자식별자가 연속 숫자든 UUID든 소유권 검사는 필요하다. 긴 식별자는 추측을 어렵게 할 수 있지만 이미 알려진 객체나 로그·링크로 노출된 번호에 대한 권한을 대신하지 않는다.
• 모든 입력 경로URL뿐 아니라 JSON 본문, 숨은 폼 필드, 첨부 파일, 일괄 처리 배열 속 ID도 객체 참조가 된다.

05주체·자원·행동·환경을 정책 입력으로 만든다

• 주체·자원인가 판단에 필요한 주체는 서버 세션이나 검증된 토큰에서 얻고, 자원의 소유자·조직·상태는 서버가 관리하는 데이터에서 얻는다. 사용자가 요청 본문에 적은 owner_id나 is_admin을 그대로 신뢰하면 판단의 근거를 사용자가 스스로 바꾸게 된다.
• 행동·환경행동은 조회·수정·삭제·승인처럼 구체적으로 나누어야 한다.
• RBAC·ABACRBAC는 역할에 따른 권한을, ABAC는 주체·자원·환경 속성을 조합한 정책을 설명하는 모델이다. 실제 문서 승인에서는 작성자 역할만으로 충분하지 않고 같은 조직인지, 자기 문서인지, 아직 초안인지 같은 조건이 붙을 수 있다.
• 기본 거부기본 거부는 누락된 규칙이 허용으로 바뀌지 않게 만드는 정책 방향이다.

06객체 조회 조건에서 범위를 제한하는 비교

• 조회 조건취약한 흐름은 번호만으로 주문을 조회한 후 아무 로그인 사용자에게나 반환하는 것이다. 더 좁은 흐름은 주문 번호와 검증된 사용자 범위를 함께 조회 조건에 넣는다.
• 공유·위임다만 관리자·공유 문서·위임 관계 같은 정책이 있다면 이를 명시적으로 표현해야 하며 모든 서비스에 owner 한 조건만 복사해서 해결되는 것은 아니다.
• 인가와 SQLi권한 검사가 DB 조회 후에 있더라도 반환 전 확실히 수행하면 집행할 수 있다. 그러나 여러 경로에 흩어진 수동 검사는 빠뜨리기 쉬우므로 정책과 집행을 재사용하는 구조가 도움이 된다.
• 응답 범위페이지와 API, 다운로드와 미리보기, 단건과 일괄 기능이 같은 자원을 다르게 노출하지 않도록 연결해야 한다.

# 가상 의사코드: 실제 DB API 문법이 아님
actor = verified_session.user_id

# 잘못된 범위: 식별자만으로 찾고 반환
order = find_order(request.order_id)

# 한 사용자 소유 주문의 예
order = find_order(id=request.order_id, owner_id=actor)
if order is None:
    deny()
else:
    return permitted_fields(order)

SQLi 방어와 별개로 조회의 권한 범위를 제한해야 하는 이유를 보여 준다.

07기능·필드·업무 상태에도 권한이 있다

• 작업별 권한조회할 수 있는 문서라고 모든 필드를 바꾸어도 되는 것은 아니다. 사용자가 보낸 JSON 전체를 객체에 자동 반영하면 화면에 없던 role, owner, approved 같은 필드가 변경될 수 있다.
• 필드별 권한허용된 필드를 선택하고 각 행동의 상태 전이를 명확히 하면 입력 데이터가 권한 정책을 덮어쓰는 경로를 줄일 수 있다.
• 소유자·업무 상태예를 들어 작성자는 초안 내용을 수정하지만 제출 후에는 수정이 제한되고, 같은 조직의 승인자는 제출 상태에서만 승인하도록 정한다. 관리자라는 역할 이름도 언제나 모든 상태 전이를 허용한다는 뜻은 아니다.
• 금지된 전이취소된 주문을 다시 결제하거나 이미 승인된 요청을 중복 승인하는 일은 자원 상태까지 포함한 권한·업무 규칙의 문제다.

08검사와 사용 사이에 상태가 바뀌는 문제

• 검사와 변경서버가 문서를 읽어 소유권과 상태를 검사한 뒤 실제 변경하기 전에 다른 요청이 소유자나 상태를 바꾸면 이전 판단이 현재 데이터에 맞지 않을 수 있다. 이처럼 검사 시점과 사용 시점이 분리된 경쟁 조건은 단순 URL 검증과 다른 문제다.
• 원자적 조건변경 조건을 함께 적용하거나 적절한 트랜잭션·동시성 제어로 일관성을 유지한다.
• 테넌트 경계멀티테넌트 시스템에서는 조직 구분 조건도 모든 데이터 경로를 통과해야 한다. 직접 조회는 막았지만 검색·내보내기·캐시에서 다른 조직 자료가 반환되면 보호가 완성되지 않는다.
• 캐시 문맥캐시 키에 필요한 사용자·조직 문맥이 빠진 경우에도 정상 권한으로 생성한 결과가 다른 사용자에게 재사용될 수 있다.

12권한 오류의 응답과 내부 증거

• 응답 정보권한 거부에서는 서버 데이터가 실제로 변하지 않아야 한다. 화면에 오류가 나왔어도 뒤에서 변경을 먼저 수행했다면 사용자 경험과 보안 상태가 다르다.
• 실제 변경 확인상태 코드·본문·저장 결과·감사 기록을 함께 보는 이유다. 403과 404 중 어떤 외부 표현을 쓰는지는 존재 정보 노출 정책과 API 규약에 영향을 받는다.
• 감사 필드내부 감사에는 검증된 주체, 행동, 객체와 결정 이유를 연결한다. 사용자가 주장한 ID와 실제 인증된 ID를 같은 필드로 덮어쓰지 않는다.
• 세션별 분기같은 관리자 URL을 관리자·일반 사용자·비로그인 세션으로 요청하면 서버의 인증·인가 분기 차이를 비교할 수 있다.

13교차 사용자·역할·상태 행렬로 정상 동작 읽기

• 역할·대상 행렬작은 문서 서비스라면 작성자 A, 다른 작성자 B, 승인자 C를 가상 계정으로 두고 초안·제출·완료 문서에 조회·수정·승인을 적용해 표를 만들 수 있다. 표의 각 칸은 기대한 허용 또는 거부와 실제 결과를 연결한다.
• 단일 계정의 한계단일 관리자 계정으로 모든 기능이 열리는지만 시험하면 수평 권한 오류를 놓치게 된다.
• 회귀 검증재검증은 취약 요청을 차단하는 것과 정상 권한이 유지되는 것을 함께 다룬다. 지나치게 넓은 전면 차단은 오류를 숨길 수 있지만 업무 정책을 구현한 결과는 아니다.
• 정책과 구현정책의 조건과 실제 서버 분기가 대응한다는 설명이 접근제어 문서의 중심이 된다.